[정보처리기사 실기] 1. 요구사항 확인 - 현행 시스템 분석

현행 시스템 파악 절차

1단계: 시스템 구성, 기능, 인터페이스 파악
2단계: 아키텍처, 소프트웨어 구성 파악
3단계: 하드웨어, 네트워크 파악
 

소프트웨어 아키텍처 프레임워크

아키텍처가 표현해야 하는 내용과 관계를 표현하는 아키텍처 기술 표준
 
소프트웨어 아키텍처 4+1 뷰 
고객의 요구사항을 정리한 시나리오를 4개의 관점에서 바라보는 접근 방법으로, 4개 구조가 서로 충돌하지 않는지/ 요구사항 충족하는지 확인
 

 
 

• 유스케이스 뷰: 사용자, 개발자, 테스트 관점이고 다른 뷰를 검증하는데 사용
• 논리 뷰: 설계자, 개발자 관점이고 시스템의 기능적 요구사항 제공을 설명
• 프로세스 뷰: 개발자, 시스템 통합자 관점이고 시스템의 비기능적 속성 표현
• 구현 뷰: 정적인 소프트웨어 모듈 구성을 보여주고 컴포넌트 구조와 부가정보 포함
• 배포 뷰: 컴포넌트가 물리적 아키텍쳐에서 표현되는 것을 매핑해서 보여줌

 

소프트웨어 아키텍처 패턴 유형

계층화 패턴	하위 모듈은 추상화를 제공하고 다음 상위 계층에 서비스를 제공
클라이언트-서버 패턴	하나의 서버와 다수의 클라이언트로 구성되어 있음. 사용자가 서버에 서비스를 요청하면 서버는 클라이언트에 서비스 제공
파이프-필터	서브 시스템이 입력 데이터를 처리하면 다음 서브 시스템으로 넘김
브로커 패턴	서버가 자신의 기능을 브로커에 넘겨주고 클라이언트가 브로커에 서비스 요청
모델-뷰-컨트롤러(MVC) 패턴

 
 

디자인 패턴 유형

: 생성/구조/행위 세 가지로 나뉨
 
1. 생성 패턴 종류

Builder	객체 생성/구현 방법을 분리해 서로 다른 결과를 만들고, 복잡한 인스턴스 조립으로 복잡한 객체 생성
Prototype	원형을 만들어놓고 복사한 후에 필요한 부분만 수정해서 사용
Factory Method	상위클래스는 객체생성 정의, 하위클래스는 인스턴스 생성
Abstract Factory	구체적 클래스에 의존하지 않고 서로 연관있는 객체들의 조합을 만드는 인터페이스 제공
Singleton	객체를 하나만 생성해서 어디서든 참조 가능

 
2. 구조 패턴 종류

Bridge	기능/구현의 각 클래스 계층을 연결
Decorator	기존 클래스에 필요한 기능을 추가해나가는 동적으로 유연한 패턴
Facade	복잡한 시스템을 단순한 인터페이스로 제공
Flyweight	메모리 절약, 클래스의 경량화
Proxy	객체로의 접근제어가 목적이고 정보은닉의 역할
Composite	객체들의 관계를 트리 구조로 복합/단일 객체를 동일하게 취급
Adapter	기존 클래스를 재활용할 수 있도록 중간에서 맞춰주는 역할

 
3. 행위 패턴

Mediator	느슨한 결합 특성 유지를 위해 중재자에 요구해 통신의 빈도수를 줄임
Interpreter	언어를 해석, 구문을 나누고 여러 형태의 언어 구문을 해석할 수 있게 만듬
Iterator	내부구조 노출 없이 복잡 객체 원소를 순차적으로 접근
Template Method	상위 작업의 구조는 안 바꾸고 서브클래스로 작업 일부 수행
Observer	한 객체 상태가 바뀌면 의존 객체도 갱신
State	객체 상태를 캡슐화
Visitor	처리 기능을 분리한 별도의 클래스가 있고 해당 클래스의 메서드가 클래스들을 돌아다님
Command	실행될 기능을 캡슐화
Strategy	알고리즘 군을 정의하고 같은 알고리즘을 하나로 캡슐화

 
 

요구공학 프로세스

도출 -> 분석 -> 명세 -> 확인 및 검증
-----> 요구사항 변경 관리, 추적 관리
 

요구사항 도출 기법

자주 나오는 것만 적음

• 브레인스토밍: 회의 참석자들이 아이디어를 공유
• 델파이 기법: 전문가의 경험적 지식으로 문제 해결
• 워크숍: 단기간 집중적인 노력으로 전문적 정보 공유

 
요구사항 분석 단계

• DFD: 데이터가 프로세스를 따라 변환되는 모습
• DD: 자료 요소/흐름/저장소/관계/범위 등 정보를 명시하는 사전
• UML: 산출물을 명세화, 시각화, 문서화할 시 사용되는 모델링 기술 통합