2-1. 현행 시스템 파악
(1) 현행 시스템 파악 개념
- 현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 어떤 기술요소를 사용하는지를 파악하는 활동
(2) 현행 시스템 파악 절차
[구성/기능/인터페이스 파악] -> [아키텍처 및 소프트웨어 구성 파악] -> [하드웨어 및 네트워크 구성 파악]
(3) 소프트웨어 아키텍처
1. 소프트웨어 아키텍처 개념
- 여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조가 구조체이다.
2. 소프트웨어 아키텍처 프레임워크 구성요소
| 구성요소 | 설명 |
|---|---|
| 아키텍처 명세서 (Architectural Description) | 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등 |
| 이해관계자 (Stakeholder) | 시스템 개발에 관련된 모든 사람과 조직 |
| 관심사 (Concerns) | 시스템에 대해 이해 관계자들의 서로 다른 의견과 목표 |
| 관점 (Viewpoint) | 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식 |
| 뷰 (View) | 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현 |
| 근거 (Rationale) | 아키텍처 결정 근거 |
| 목표 (Misson) | 시스템의 목적, 사용 운영 방법 |
| 환경 (Environment) | 외부 요인 등으로 시스템에 영향을 주는 요인 |
| 시스템 (System) | 각 애플리케이션 서브 시스템, 시스템의 집합, 제품군 등의 구현체 |
3. 소프트웨어 아키텍처 4+1 뷰
- 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근방법
- 4개 구조가 충돌되거나 요구사항을 충족하는지 증명하기 위해 유스케이스를 사용한다.
- [논리, 구현, 프로세스, 배포 뷰] + 유스케이스
| 뷰 | 설명 |
|---|---|
| 유스케이스 뷰 (Usecase View) | 다른 뷰를 검증하는 데 사용되는 뷰 사용자, 설계자, 개발자, 테스트 관점 |
| 논리 뷰 (Logical View) | 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰 설계자, 개발자 관점 |
| 프로세스 뷰 (Process View) | 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰 개발자, 시스템 통합자 관점 |
| 구현 뷰 (Implementation View) | 정적인 소프트웨어 모듈의 구성을 보여주는 뷰 |
| 배포 뷰 (Deployment View) | 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰 |
4. 소프트웨어 아키텍처 패턴
- 소프트웨어 아키텍처에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션이다.
- 소프트웨어 아키텍처의 필요성
- 고객의 요구사항을 만족시키고, 소프트웨어 개발 생산성과 품질 확보가 가능하다.
- 시행착오를 줄여 개발시간을 단축하고, 높은 품질의 소프트웨어 생산이 가능하다.
- 이미 검증된 구조로 개발하기 때문에 소프트웨어 개발을 안정적으로 수행할 수 있다.
- 시스템의 특성을 개발 전에 예측이 가능하다.
- 소프트웨어 아키텍처 패턴 유형
| 유형 | 설명 |
|---|---|
| 계층화 패턴 (Layered Pattern) | 시스템을 계층으로 구분하여 구성하는 패턴 |
| 클라이언트-서버 패턴 (Client-Server Pattern) | 하나의 서버와 다수의 클라이언트로 구성된 패턴 |
| 파이프-필터 패턴 (Pipe-Filter Pattern) | 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴 |
| 브로커 패턴 (Broker Pattern) | 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 원격 서비스 실행을 통해 상호작용이 가능한 패턴 |
| 모델-뷰-컨트롤러 패턴 (MVC Pattern) | 모델, 뷰 , 컨트롤러 3개의 서브 시스템으로 구조화하는 패턴 |
5. 소프트웨어 아키텍처 비용 평가 모델
- 아키텍처의 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델이다.
| 종류 | 설명 |
|---|---|
| SAAM (Software Architecture Analysis Method) | 변경 용이성과 기능성에 집중, 평가가 용이한 모델 |
| ATAM (Architecture Trade-off Analysis Method) | 아키텍처 품질 속성을 만족 시키는지 판단 및 이해 상충관계까지 평가하는 모델 |
| CBAM (Cost Benefit Analysis Method) | 경제적 의사결정에 대한 요구를 충족하는 모델 |
| ADR (Active Design Review) | 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델 |
| ARID (Active Reviews for Intermediate Designs) | 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 모델 |
(4) 디자인 패턴
- 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴이다.
1. 디자인 패턴 구성요소
| 구성요소 | 설명 |
|---|---|
| 패턴의 이름 | 디자인 패턴을 부를 때 사용하는 이름과 디자인 패턴의 유형 |
| 문제 및 배경 | 디자인패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미 |
| 솔루션 | 디자인 패턴을 이루는 요소들, 관계, 협동 과정 |
| 사례 | 디자인 패턴의 간단한 적용 사례 |
| 결과 | 디자인 패턴을 사용하면 얻게 되는 이점이나 영향 |
| 샘플 코드 | 디자인 패턴이 적용된 원시 코드 |
2. 디자인 패턴 유형
| 구분 | 유형 | 설명 |
|---|---|---|
| 목적 | 생성 | 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴 |
| 구조 | 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴 | |
| 행위 | 클래스나 객체들이 상효작용하는 방법과 역할 분담을 다루는 패턴 | |
| 범위 | 클래스 | - 클래스 간 관련성 (상속 관계를 다루는 패턴) - 컴파일 타임에 정적으로 결정 |
| 객체 | - 객체 간 관련성을 다루는 패턴 - 런타임에 동적으로 결정 |
3. 디자인 패턴 종류
작성하다가 너무 길어서 poiuyy0420님의 벨로그로 대체한다. (...) https://velog.io/@poiuyy0420/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-%EA%B0%9C%EB%85%90%EA%B3%BC-%EC%A2%85%EB%A5%98