01.아키텍처설계
가) 소프트웨어 아키텍처 개요
- 소프트웨어 개발에 직간접적으로 영향을 미치고 복잡도를 높이는 다양한 요소들을 체계적으로 다루기 위한 개발 대상 소프트웨어 청사진이라고 볼 수 있다.
- Booth : 소프트웨어 구조에 대한 중요한 의사결정 집합
- Myon Ahn : 모듈 , 프로세스 , 데이터 , 이들의 구조, 구성 요소들 간의 관계, 이러한 구성요소와 관계가 어떻게 확장 및 수정 될 수 있을지, 사용하는 기술은 무엇으로 이루어져 있으며 소프트웨어 아키턱처를 통해 시스템 유연성과 성능 및 시스템을 어떻게 구현하고 수정할 수 있는지를 판단할 수 있다
- 소프트웨어 아키턱처는 의사소통 수단 및 프로젝트 초기 의사결정 도구로 활용되며, 시스템 전체 구조 및 개발 프로젝트 조직 결정 시 참조되기도 한다.
| 구성요소 | 설명 |
| Mission | -이해관계자의 목적 달성을 위해 시스템이 수행하는 연산 |
| System | -시스템은 비즈니스 목적(Mission)을 완수해야 함 -특정 기능이나 기능 세트를 달성하기 위해 조직된 컴포넌트 집합 |
| Environment | -시스템에 대한 개발, 작동, 정책, 기타 여향요소들의 설정과 환경, 내부제약조건(내규), 외부제약조건(법규,제도), 하드웨어 시스템 등 |
| Stakeholder | -이해관계자들의 관심은 아키텍처로 수렴 -시스템에 관심을 갖는 사람이나 조직, 고객, 최종사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등 |
| Architecture | -모든 시스템은 아키텍처를 가지고 아키텍처 기술서로 문서화되어 구체화, 아키텍처 결정의 근거(Rationale) 제시가 필수 |
| Architecture Description | -아키텍처를 기록하기 위한 산출물 의미 -이해관계자들의 시스템에 대한 관심을 관점(viewpoint)에 맞춰 작성한 뷰(view)로 구성 |
| Rationale | -아키텍처 기술서는 아키텍처 결정의 명확하 근거를 제시 -이해당사자간 불필요한 논쟁 감소, 아키텍처 평가 시 주요 판단 기준 |
| View & Viewpoint | -뷰포인트는 뷰를 구성하기 위한 규칙을 정의하는 패턴 -뷰포인트는 서로 다른 역할이나 책임으로 시스템이나 산출물에 대해 서로 다른 관점을 의미하고 뷰는 이런 이해관계자들과 이들이 가지는 생각이나 견해로부터 전체시스템을 표현하고 도식화한 것 |
| Library Viewpoint | -미리 정의해 놓은 뷰포인트, 이를 참조하여 해당 소프트웨어에 적합한 뷰포인트 결정 |
| Concern | -동일한 시스템에 대해 이해관계자들의 서로다른 의견과 목표 소유 -사용자는 기본적 기능 이외에 신뢰성, 보안, 사용성 등에 관심이 많고, 유지보수자는 유지보수 용이성에 , 개발자는 적은 비용과 인력으로 개발이 가능해야 함 |
나) 소프트웨어 아키텍처 설계 절차
| 단계 | 활동 | 설명 |
| 요구사항분석 | 요구사항 분석 | - 요구사항 수집, 식별, 명세, 분류, 검증 - 기능적/비기능적요구사항 분류및 명세 |
| 아키텍처분석 | 품질요소 식별 | - 기능성, 신뢰성, 효율성, 유지보수성, 이식성 등 |
| 품질요소 우선순위 결정 | - 유틸리티 트리(품질요소의 목표 및 영향도 식별) - 품질속성 시나리오 작성 |
|
| 아키텍처설계 | 관점 및 뷰의 정의 | - 이해당사자 파악및 이해당사자별 관점, 뷰 정의 |
| 아키텍처 스타일(패턴) 결정 | - 파이프-필터스타일, MVC, 레이어 등 혼용 적용 | |
| 후보 아키텍처 도출 | - 컨텍스트 다이어그램 및 각종 뷰별로 다이어그램작성 - SAD(Software Architecture Description) 기술 |
|
| 아키텍처 평가 및 상세화 | 아키텍처 평가 | - 아키텍처의 요구사항 만족 적합도 평가 - 품질속성 간의 Tradeoff 관계 평가(ATAM) |
| 아키텍처 상세화 | - 설계 매커니즘도출(Persistency, Transaction 등) | |
| 아키텍처 승인 | - 고객 및 이해당사자 최종 승인 |
- 설계 초기 단계에서는 문제를 해결하기 위해 기능을 분할하거나 사용자 인터페이스를 논리적으로 분할한다.
- 상위레벨에서 분할한 시스템 구성 요소를 서브시스템(Subsystem)이라 부른다. 서브시스템은 일반적으로 자료와 제어구조를 포함하며, 독립적으로 기능을 수행할 수 있고 컴파일 될 수 있는 프로그램 구성요소를 일컫는다,
- 또한, 서브시스템은 어떠한 서비스 또는 기능을 제공하는가에 의해 구별된다.
- 프레임워크(Framework)는 서브시스템 설계 시 반복적으로 아키텍처 설계에 반영할 수 있는 지식을 모아 놓은 자원 단위.
- 프레임워크는 구체적인 서브시스템을 만들기 위해 확장될 수 있는 일반 구조를 나타내며, '프레임워크는 구체적인 구현방법 등을 제공함으로써 설계 추상화의 수준을 높인다.
- 아키텍처 설계는 시스템 요구사항을 만족시키기 위해 시스템 구성을 설정하는 프로세스이다. 요구사항 분석과정의 결과를 이용하여 프로그램 구조상에 있는 각 구성요소(모듈)들 사이의 관계를 기술한다.
02.소프트웨어 아키텍처 스타일
| 스타일 | 개념도 | 설명 |
| 가) 저장소 구조 |  |
-모든 공유데이터를 한 곳에 보관 -모든 서브시스템들이 데이터 공유 -다량의 데이터를 저장하는데 적합 |
| 나) MVC(Model-View-Controller) 구조 |  |
-GUI설계에 많이 활용 -한 객체에 여러 가지 표현이 상호작용하도록 지원 -한 객체 수정시 다른 모든 표현도 따라서 갱신 , 이 방법으로 수정 단순화되며 재사용이 수월 |
| 다) 클라이언트-서버 모델 |  |
-서버와 클라이언트 집합으로 구성 -클라이언트가 서비스를 요구, 서버는 서비스를 제공 -분산 시스템에 적용 -네트워크 시스템을 효과적으로 이용 |
| 라) 계층구조 |  |
-시스템을 여러 계층으로 구성 -각 계층은 특정 서비스 제공 -계층구조는 문제해결 용이 -문제 발생하는 경우 각 층마다 단계적 확인되고, 장비가 표준화 되어 상호 호환 가능 -(예)osi 7 layer |
03.소프트웨어 아키텍처 설계 표현 방법
| 설계 표현 방법 | 개념도 | 설명 |
| 가) 컨텍스트(Context) 모델 |  |
- 요구사항 분석 초기 시스템과 외부 환경의 경계 식별 - 분할되기 이전의 시스템을 하나의 큰 프로세스로 이해 - (목적) 1.개발해야할 시스템 영역 기술 2.시스템과 외부와 경계 결정 3.외부와의인터페이스 제시 |
| 나) 컴포넌트 다이어그램 |  |
- 컴포넌트(Component) : 소프트웨어 개발 속도와 생산성을 높이기 위해 재사용성(Reuseability)을 고려한 부품 - 컴포넌트 호환을 위해 컴포넌트 구현, 문서화 등에 대한 표준 정의 요구 - 컴포넌트 결합은 컴포넌트를 조립하는 프로세스 - 순차적 결합, 계층적 결합, 부가적 결합 등의 유형 |
| 다) 패키지 다이어그램 |  |
- 패키지(Package) : 다수의 사용자를 위해 개발된 상업용 소프트웨어 - 패지지로 정의되면 패키지 내부의 자세한 사항을 외부에 감추어 패키지 사이의 의존 관계를 최소화 할 수 있다 - 패키지는 기능적으로 관련있는 클래스를 모아 놓은 것이다 - 패키지는 보통 서브시스템 형태로 나타난다 - 서브시스템들 사이의 연관 관계가 최소화되도록 서브시스템을 분할하면 객체사이의 의존을 최소화하고 복잡도를 줄일 수있다. |
'TOPCIT > TOPCIT교재' 카테고리의 다른 글
| X. 사용자 인터페이스(UI)/사용자 경험(UX) 설계 - 윤정우 (0) | 2022.07.18 |
|---|---|
| VI. 객체 지향 설계 - 김정옥 (0) | 2022.07.18 |
| 소프트웨어 설계 원리와 구조적 설계 - 손기봉 (0) | 2022.07.18 |
| 자료구조와 알고리즘 - 이강욱 (0) | 2022.07.18 |
| II.소프트웨어 재사용 - 손선희 (0) | 2022.07.18 |
