1강 / CHAPTER 02 - 현행 시스템 분석 (일부만 작성)

2024년도 수제비 실기책(6판) 내용 정리

---

1. 현행 시스템 파악

1) 소프트웨어 아키텍처 4 + 1 뷰

뷰	설명
유스케이스 뷰 (Usecase View)	유스케이스 또는 아키텍처를 도출하고 설계, 다른 뷰를 검증하는데 사용되는 뷰 사용자, 설계자, 개발자 테스트 관점
논리 뷰 (Logical View)	시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰 설계자, 개발자 관점
프로세스 뷰 (Process View)	시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰 개발자, 시스템 통합자 관점
구현 뷰 (Implementation View)	개발 환경 안에서 정적인 소프트웨어의 모듈 구성을 보여주는 뷰 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의
배포 뷰 (Deployment View)	컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

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

유형	설명
계층화 패턴 (Layered Pattern)	- 시스템을 계층으로 구분 -> 각 하위모듈이 추상화 제공 하고 각 계층은 상위 계층에 서비스 제공 - 마주보는 두 개의 계층 사이에서만 상호작용이 이루어짐
클라이언트 - 서버 패턴 (Client - Server Pattern)	- 하나의 서버와 다수의 클라이언트로 구성 - 클라이언트 통해 서버에 서비스 요청 -> 서버는 클라이언트에게 서비스 제공 - 서버는 계속 요청을 대기
파이프 - 필터 패턴 (Pipe - Filter Pattern)	- 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능 - 서브시스템이 입력데이터를 받아 처리하고 결과를 다음 서브시스템에 넘겨주는 과정을 반복 - 필터 컴포넌트는 재사용성이 좋고 추가가 쉽기 때문에 확장이 용이
브로커 패턴 (Broker Pattern)	- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용 - 컴포넌트들은 원격 서비스 실행을 통해 상호 작용이 가능함 - 브로커 컴포넌트는 컴포넌트 간의 통신을 조정하는 역할 - 서버가 브로커에 기능을 넘겨주고, 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리다이렉션
모델-뷰-컨트롤러 패턴 (MVC; Model View controller Pattern	- 모델 : 핵심 기능과 데이터 보관 - 뷰 : 사용자에게 정보 표시 (하나이상의 뷰가 정의 될 수 있음) - 컨트롤러 (사용자로부터 요청을 입력받아 처리) - 각 부분이 별도의 컴포넌트로 분리 되어있어서 서로 영향을 받지않고 개발 작업 수행 가능 - 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능하게하고 여러 개의 뷰가 있어야 하는 대화형 애플리케이션 구축에 적합

3) 디자인 패턴 키워드 정리

• 유형 : 생성 - 5개, 구조 - 7개 , 행위 - 11개

(1) 생성패턴

패턴	설명
Builder 빌더	- 생성과 표기를 분리해서 복잡한 객체 생성 - 복잡한 인스턴스를 조립하여 만드는 구조 - 복합 객체 생성시 생성 방법과 구현을 분리하여 동일한 절차에서 서로다른 표현 결과를 만들 수 있음
Prototype 프로토타입	- 기존 객체를 복제함으로써 객체를 생성 - 원형을 만들어놓고 복사하여 필요한 부분을 수정하여 사용 - 객체의 원형 인스턴스에서 생성할 객체들의 타입이 결정 - 객체를 생성할 때 갖추어야 할 기본 형태가 있을 때 사용
Factory Method 팩토리 메서드	- 생성할 객체의 클래스를 국한하지 않고 객체를 생성 - 상위 클래스에서 객체를 생성하는 인터페이스 정의(방법 결정) - 하위 클래스에서 객체를 생성(데이터 생성 및 조작하는 함수들을 오버라이딩해서 구현) - 인터페이스와 실제 객체를 생성하는 클래스를 분리할 수 있는 특성
Abstract Factory 앱스트랙트 팩토리	- 동일한 주제의 다른 팩토리를 묶음 - 클래스에 의존하지 않고 의존적인 객체들의 조합을 만드는 인터페이스를 제공 - 클래스에서는 사용자에게 API 제공하고 구체적 구현은 Concrete Product 클래스에서 이루어짐
Singleton 싱글톤	- 한 클래스에 한 객체만 존재하도록 제한 - 전역 변수 사용 안함, 객체를 하나만 생성, 생성된 객체를 어디서든지 참조할 수 있도록 함

 

(2) 구조패턴

패턴	설명
Bridge 브릿지	- 구현 / 추상화된 부분까지 변경해야 하는 경우 활용 - 클래스의 기능 계층과 구현 계층을 연결 - 구현부에서 추상 계층을 분리 -> 추상화된 부분과 실제 구현부분을 독립적으로 확장 할 수 있음
Decorator 데코레이터	- 객체의 결합을 통해 기능을 동적으로 확장 - 기존에 구현되어있는 클래스에 기능을 추가, 상속의 대안
Facade 퍼사이드	- 통합 인터페이스 제공 - 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게하는 패턴 - 복잡한 시스템에 단순한 인터페이스를 제공
Flyweight 플라이웨이트	- 여러 개의 가상 인스턴스 제공 -> 메모리 절감 - 본질적인 요소를 클래스화하여 공유 -> 메모리 절약, 클래스의 경량화를 목적
Proxy 프록시	- 특정 객체로의 접근을 제어하기 위한 용도 / 정보 은닉 - 대리객체 -> 실체 객체에 대한 접근 이전에 필요한 행동을 취할 수 있게 만듦 - 미리 할당하지 않아도 실제 이용히 할당 -> 메모리 용량 아낄 수 있음 - 실체 객체를 드러나지 않게 함 -> 정보은닉
Composite 컴포지트	- 복합 객체와 단일 객체를 동일하게 취급 - 객체 관계를 트리구조로 구성 (부분 - 전체 계층을 표현)
Adapter 어댑터	- 인터페이스가 호환되지 않은 클래스들을 함께 이용할 수 있도록 타 클래스의 인터페이스를 덧씌움 - 기존 생성된 클래스를 재사용 할 수 있도록 중간에서 맞춤 - 상속을 이용하는 패턴 / 위임을 이용하는 패턴 두가지 형태로 사용됨

 

(3) 행위패턴

패턴	설명
Mediator 메디어터(중재자)	- 상호 작용의 유연한 변경을 지원 - 객체 수가 많아져 느슨한 결합을 해칠 수 있을 때 이를 해결하는 방법 - 중간에 이를 통제하고 지시할 수 있는 역할을 하는 중재자를 두고, 중재자가 통신의 빈도수를 줄임
Interpreter 인터프리터	- 문법 자체를 캡슐화 - 언어의 해석, 구문을 나누고 해석을 맡는 클래스를 각각 작성 -> 여러 형태의 언어를 해석
Iterator 잇터레이터(반복자)	- 자료구조(컬렉션)의 내부 구조를 노출하지 않고 원소를 순차적으로 접근 가능 - 컬렉션 구현 방법을 노출시키지 않고 집합체 안의 항목을 iterator를 사용하여 접근
Template Method 템플릿 메소드	- 상위 작업의 구조를 바꾸지 않고, 서브 클래스로 작업의 일부분을 수행 - 작업을 처리하는 부분을 서브 클래스로 캡슐화 -> 일을 수행하는 구조는 바꾸지 않고 특정 단계에서 수행하는 내역을 바꿈 - 상위 클래스에서는 추상메서드로 골격 제공 - 하위 클래스에서의 메서드에는 세부 처리를 구체화(구현) - 코드 양을 줄이고 유지보수가 용이해짐
Observer 옵서버	- 객체의 상태 변화에 따라 다른 객체의 상태도 연동, 일대다 의존 - 객체 상태 바뀌면 의존하는 다른객체에 연락 -> 자동으로 내용이 갱신 - 상호작용하는 객체 사이에서는 가능하면 느슨하게 결합
State 상태	- 객체의 상태에 따라 행위 내용을 변경 / 객체 상태를 캡슐화 -> 그것을 참조 - 상태에 따라 다르게 처리할 수 있도록 행위 내용을 변경 - 원시 코드 수정 최소화, 유지보수 편의성갖음
Visitor 방문자	- 복합 객체의 원소 특성에 따라 동작을 수행할 수 있도록 지원 - 처리 기능을 분리하여 별도의 클래스 생성 -> 해당 클래스의 메서드가 돌아다니며 특정 작업 수행 - 객체의 구조는 변경하지 않고 기능만 따로 추가하거나 확장
Command 커맨드	- 요구사항을 캡슐화 / 실행될 기능을 캡슐화 - 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계 - 하나의 추상클래스에 메서드를 만들어 명령이 오면 서브 클래스가 선택됨
Strategy 스트레티지	- 행위 객체를 클래스로 캡슐화 / 알고리즘 군을 정의 -> 각각 하나의 클래스로 캡슐화 - 캡슐화된 알고리즘 클래스를 필요할 때 서로 교환해서 사용
Memento 메멘토	- 객체를 이전 상태로 복구시켜야 하는 경우, 작업 취소(Undo) 요청 가능 - 객체의 정보를 저장할 필요가 있을 때 적용, Undo기능 개발 시 사용
Chain of Responsibility 책임연쇄	- 한 요청을 2개이상의 객체에서 처리 / 하드코딩 - 기능에 대한 연결이 하드코딩 되어있을 때 동적으로 연결되어 있는 경우에 따라 다르게 처리 될 수 있도록 연결

---

2. 요구사항

1) 요구사항 분석 단계 기법

• 데이터 흐름도(DFD; Data Flow Diagram) : 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림으로 시스템 분석과 설계에서 유용하게 사용됨
• 자료 사전(DD; Data Dictionary) : 자료 요소 및 자료 요소들의 집합, 자료 저장소의 의미, 관계 등의 단위들을 구체적으로 명시하는 사전
• UML(Unified Modeling Language) : 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해 만든 표준화된 범용 모델링 언어

2) 요구사항 명세 단계

• 산출물로 요구사항 명세서가 있음
• 비정형 명세 기법 : 자연어를 기반으로 서술, 사용자와 개발자의 이해가 용이하나 명확성 및 검증에 문제가 발생할 수 있음
• 정형 명세 기법 : 수학적인 원리와 표기법으로 서술, 표현이 간결하고 명확성 및 검증이 용이하나 기법의 이해가 어려움

3) 요구사항 확인 및 검증 단계의 주요 기법

• 동료 검토(Peer Review) : 2~3명이 진행하는 리뷰의 형태, 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견
• 워크 스루(Walk Through) : 오류를 조기에 검토하는 목적, 검토 자료를 회의 전에 배포해서 사전 검토 -> 짧은 시간 동안 회의를 진행하는 형태, 리뷰를 통해 오류를 검출하고 문서화하는 비공식적인 검토방법
• 인스 펙션(Inspection) : 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전무가 또는 팀이 검사하여 오류를 찾아내는 공식적인 검토 방법
  절차: 계획 -> 사전 교육 -> 준비 -> 인스펙션 회의 -> 수정 -> 후속 조치