[정보처리기사 실기 정리] 1-2. 현행 시스템 분석

전현준·2024년 4월 7일

정처기

정보처리기사 실기

목록 보기

2/12

1. 현행 시스템 파악

1. 현행 시스템 파악 개념

현행 시스템이 어떤 하위 시스템으로 구성, 어떤 기술 요소를 사용하는지 파악하는 활동
SW, HW, 네트워크 구성 등

2. 현행 시스템 파악 절차

구성/기능/인터페이스 파악
아키텍처 및 소프트웨어 구성 파악
하드웨어 및 네트워크 구성 파악

3. 소프트웨어 아키텍처

소프트웨어 구성요소가 외부에 드러나는 특성, 구성요소 간의 관계를 표현하는 구조
소프트웨어 아키텍처 프레임워크
- 아키텍처가 표현해야하는 내용 및 관계를 제공하는 아키텍처 기술 표준
소프트웨어 아키텍처 4+1 뷰
- 유스케이스 뷰 : 유스케이스 또는 아키텍처 도출하고 설계
- 논리 뷰 : 기능적인 요구사항이 어떻게 제공되는지 설명하는 뷰
- 프로세스 뷰 : 비기능적 속성으로서 자원의 효율적 사용, 비동기, 이벤트 처리 등 표현
- 구현 뷰 : 정적인 모듈의 구성, 컴포넌트 구조와 의존성 보여줌
- 배포 뷰 : 물리적인 아키텍처에 어떻게 배치되는가?
소프트웨어 아키텍처 패턴
- 계층화 패턴 : 시스템을 상위-하위 계층으로 구분하여 구성, 하위 모듈은 추상화 제공
- 클라이언트-서버 패턴 : 하나의 서버와 다수의 클라이언트 구성
  - 서버는 계속 클라이언트로부터 요청을 대기
- 파이프-필터 패턴 : 데이터 스트림 생성, 처리하는 시스템에서 사용 가능한 패턴
  - 서브 시스템이 입력 데이터를 받아 다시 서브 시스템으로 넘겨주는 과정
  - 재사용성, 확장 용이
- 브로커 패턴 : 컴포넌트 간의 통신을 조정하는 역할 수행
  - 클라이언트 요청이 브로커에 전달되면, 브로커는 적합한 서버로 전달함.
- MVC 패턴 : 모델, 뷰, 컨트롤러로 구분한 패턴, 컴포넌트 분리하여 코드 재활용 용이
  - 모델 : 핵심 기능과 데이터 보관
  - 뷰 : 사용자에게 정보 표시
  - 컨트롤러 : 사용자의 요청을 입력받아 처리
소프트웨어 아키텍처 비용 평가 모델
- 아키텍처 접근법이 품질 속성에 미치는 영향을 판단, 아키텍처의 적합성을 평가하는 모델
  - SAAM : 변경 용이성과 기능성에 집중, 평가가 용이
  - ATAM : 아키텍처 품질 속성을 만족시키는지, 상충 관계까지 평가하는 모델
  - CBAM : ATAM 바탕의 시스템 아키텍처 분석 중심으로, 경제적 의사결정을 고려한 모델
  - ADR : 소프트웨어 간 응집도 판단
  - ARID : 특정 부분에 대한 품질 요소에 집중하는 비용 평가 모델

4. 디자인 패턴

디자인 패턴 : SW 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법 정리
- 개발의 효율성, 유지보수성, 운용성이 높아짐.
디자인 패턴 구성요소
- 패턴의 이름 / 문제 및 배경 / 솔루션 / 사례 / 결과 / 샘플 코드
디자인 패턴 유형
- 생성 : 객체 인스턴스 생성에 관여, 생성 방식 구조화
- 구조 : 클래스나 객체의 조합을 다루는 패턴
- 행위 : 클래스나 객체들이 상호 작용하는 방법, 역할 분담
[생성] 디자인 패턴 종류
- Builder : 복잡한 인스턴스를 조립하여 만드는 구조
- Prototype : 일반적인 원형을 만들어 놓고, 복사한 후 필요한 부분만 수정하여 사용
- Factory Method : 상위 클래스에서 인터페이스를 정의하고, 하위 클래스에서 인스턴스 생성
  - 하위 클래스에서 오버라이딩하여 구현
- Abstract Factory : 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공
- singleton : 객체를 하나만 생성하여, 생성된 객체를 어디에서든지 참조할 수 있는 패턴
  - 한 클래스에 한 객체만 존재
[구조] 디자인 패턴 종류
- Builder : 추상화 된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 패턴
- Decorater : 기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 패턴
  - 상속의 대안으로, 기능 확장이 필요할 때 결합을 통해 동적으로 확장
  - ⭐ 보통 코드에서는 Decorator Class 선언 후, 일반화 개념으로 사용하는 것 같음.
- Facade : 단순한 인터페이스 제공, 결합도를 낮추고, 사용자에게는 접근성을 높임
- Flyweight : 다수의 객체를 클래스 화하여 공유함으로 메모리 절약. 가상 인스턴스 기능
- Proxy : 실제 객체에 대한 대리 객체, 미리 메모리에 할당하지 않고, 사용할 때 할당
- Composite : 트리 구조로 구성하여, 부분-전체 계층 표현
- Adapter : 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
  - 인터페이스로 감싸서, 구현
[행위] 디자인 패턴 종류
- Mediator : 객체의 수가 많아지면, 복잡하기에 통제하고 지시하는 중재자를 둠
- Interpreter : 언어의 다양한 해석, 구문을 나누고, 해석을 맡는 클래스를 작성
- Iterator : Collection에 대해서 반복자를 사용하여 접근 할 수 있는 디자인 패턴
- Template Method : 서브 클래스로 캡슐화 구조는 바꾸지 않고, 특정 단계에서 수행 내역
  - 추상 클래스는 추상 메소드를 통해 기능의 골격 제공
- Observer : 객체에 의존하는 다른 객체에 연락이 가는 패턴
- State : 객체 상태를 캡슐화 하여 클래스화
- Visitor : 각 클래스를 돌아다니며 특정 작업을 수행하도록 만드는 패턴
- Command : 실행 기능을 캡슐화, 명령이 들어오면 특정 서브 클래스가 선택 됨
- Strategy : 알고리즘 군으로 정의하고, 같은 알고리즘을 각각의 클래스로 캡슐화
- Mememto : Undo 기능을 개발할 때 사용하는 디자인 패턴
- Chain of Responsibility : 정적은 기능 처리의 연결 변경이 불가한데,
  - 동적으로 연결되어 있는 경우에 따라 다르게 처리

2. 요구사항

1. 요구사항 개요

요구공학 개요 : 요구공학의 사용자의 요구가 반영된 시스템을 개발하기 위하여, 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동
목적
- 이해관계자 사이의 의사소통 수단 제공
- 요구사항 누락 방지 및 이해 오류로 인한 불필요한 비용 절감
- 초기 요구사항 관리, 비용과 시간 절약
요구사항의 분류
- 기능적 요구사항 : 기능 관련된 요구사항
  - 기능성, 완전성, 일관성
- 비기능적 요구사항 : 제약사항
  - 품질 속성, 제한 조건
  - 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항

2. 요구공학 프로세스

프로세스
- 요구사항 개발 단계 : 도출 → 분석 → 명세 → 확인 및 검증
- 요구사항 관리 단계 : 요구사항 협상, 요구사항 기준선 설정 (형상 관리)
  - 요구사항 변경관리, 요구사항 확인 및 검증
요구사항 개발 단계
- [요구사항 도출]
  - 인터뷰 : 이해관계자와 대화를 통해 정보를 얻는 방식
  - 브레인스토밍 : 편한 분위기에서, 비판없이 아이디어 수용
  - 델파이 기법 : 전문가의 지식을 통한 문제 해결
  - 롤 플레잉 : 현실에 일어나는 장면을 설정하고, 연기함으로 요구사항 분석
  - 워크숍 : 단기간의 노력을 통해, 다양하고 전문적인 정보 획득, 공유
  - 설문 조사 : 설문지 또는 여론조사를 이용해 간접적으로 정보 수집
- [요구사항 분석]
  - 데이터 흐름도 : 데이터가 각 프로세스를 따라 흐르면서 변환되는 그림
    - 시스템 분석과 설계에서 유용
  - 자료 사전 : 자료 요소, 흐름, 자료 저장소의 의미와 그들 간의 관계를 명시한 사전
  - UML : 명세화, 시각화를 모델링 기술과 방법론을 통합한 모델링 언어
- [요구사항 명세]
  - 비정형 명세 기법 : 자연어 기반으로 서술하는 기법
  - 정형 명세 기법 : 수학적인 원리와 표기법으로 서술
- [요구사항 확인 및 검증]
  - 동료 검토
  - 워크 스루 : 회의 전에 배포하여 사전 검토후, 리뷰를 통해 오류 수정
  - 인스펙션 : 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 방법