연관토픽
- [하위] 소프트웨어 아키텍처 스타일(SW Architecture Style)
- [하위] 소프트웨어 아키텍처 패턴(SW Architecture Pattern)
- [하위] 소프트웨어 아키텍처 드라이버
- [하위] 소프트웨어 아키텍처 평가
- [하위] IEEE 1471(ISO/IEC/IEEE 42010:2011)
- [연관] 콘웨이 법칙(Conway's Law)
기출문제
회차 | 문제 |
관리120-3 | 5. 소프트웨어 아키텍처(Architecture)의 모델 유형에 대하여 설명하시오. |
개념
- “한 시스템의 소프트웨어 아키텍처란 시스템의 한 구조나 구조들로 각 요소들과 외부에 보이는 특성들 그리고 그들 간의 관계를 절충하는 활동” [SEI]
- 소프트웨어를 구성하는 컴포넌트와 컴포넌트의 관계를 추상적인 수준에서 정의하여 시스템 설계와 개발 시 적용되는 원칙과 지침을 제공함
- 개발하려고 하는 소프트웨어의 큰 밑그림을 그리는 것으로, 소프트웨어 개발에 직간접적으로 영향을 미치면서 복잡도를 높이는 다양한 요소들을 체계적으로 다루기 위한 청사진
- 컴포넌트와 컴포넌트 상호 간 그리고 환경과의 관계, 설계와 개선시 지켜야 하는 원칙을 포함하는 시스템의 기본적인 구조[ISO/IEC 42010: 2007]
소프트웨어 아키텍처의 중요성
중요성 | 내용 |
커뮤니케이션 수단 |
- 소프트웨어 아키텍처를 통해 이해관계자들(프로젝트 관리자, 품질 담당자, 테스터, 고객 등)은 보다 원활한 커뮤니케이션 수행 |
초기 설계 방향 가이드 |
- 전체적인 관점에서 품질 속성을 고려하여 목표 시스템의 설계 방향을 조기에 결정할 수 있도록 지원하고 향후 발생할 수 있는 위험 요소를 감소 시킴 |
상위수준의 재사용 지원 |
- 재사용 가능한 시스템의 추상화를 제공하여 소프트웨어 아키텍처가 시스템을 구성하는 요소와 이들간의 관계를 간략하고 명확하게 나타냄 |
품질속성 조정 | - 요구 사항들 간의개념 상의, Trade off 관계의 품질속성 간의 충돌 조정 - 우선 순위결정과 요구 사항들간의 Trade off 분석을 위한작업 필요 |
개발 및 유지보수 비용절감 |
- 설계 레벨에서 재사용이 가능하고 전체시스템에대한 이해도를 높이고 시스템진화에 기본 데이터제공하여개발 및유지보수비용 절감 |
개발의 위험 대처 가능 |
- 이해관계자들과 같이 대화할수 있는기초 자료로 활용하고 요구사항의 변화가 발생하였을 때Impact를예측하기쉬움 |
조직 재편 가능 | - 소프트웨어 아키텍처를 기준으로 개발조직을 기술의 흐름을 파악하여 재편 |
소프트웨어 아키텍처의 특징
- 소프트웨어 아키텍처는 소프트웨어 시스템의 구조를 결정
- 소프트웨어 시스템은여러 소프트웨어 요소또는 컴포넌트로 구성
- 소프트웨어 요소 또는 컴포넌트는 외부로 드러나는 속성 즉, 인터페이스를 갖음
- 소프트웨어 요소 또는 컴포넌트는 다른 소프트웨어 요소 또는 컴포넌트 와 관계를 가지며 인터페이스를 통해 서로 통신
- 소프트웨어 아키텍처는 소프트웨어 요소 또는 컴포넌트를 설계하고 변경하는 것에 대한 원리와 가이드 라인을 제공
소프트웨어 아키텍처 주요 요소(3가지)
중요성 | 내용 |
컴포넌트 | 구체화된시스템의기본조직, SW 개별구성요소 |
관계 | 각 종SW 컴포넌트간의관계, 이해관계자 뷰에 따라 관계 설정 |
원리 | SW 디자인과진화를 이끄는기본적인이론(결정세트) |
소프트웨어 아키텍처 결정요인
결정요인 | 내용 |
기능요구사항 | 시스템이반드시 수행해야 되는 기능 |
제약사항 | 기간, 비용(예산) 등 소프트웨어개발시, 이미결정된 사항들 |
품질속성 | 가용성, 성능, 보안과 같은 소프트웨어개발시 요구되는 품질 속성 |
소프트웨어 아키텍처 구성도
종류 | 내용 | 항목 |
메타 아키텍처 (Meta Architecture) |
아키텍처를설계하기위한 일반적인 지침 | 아키텍처정의, 아키텍처 명세서, 설계패턴, 플랫폼 |
소프트웨어 아키텍처 (Software Architecture) |
최종적인뷰(View)와설계의 결과물로 구성 | 4+1 View, Context Diagram, 컴포넌트, 인터페이스 명세 |
가이드라인 및정책 | 아키텍처를기반의 프로젝트 진행 기준 | 설계, 코딩, 테스트, 배포, 유지보수, 운영가이드 |
소프트웨어 아키텍처 수립 프로세스
단계 | 활동 | 세부내용 |
요구사항 분석 |
요구사항분석 | - 요구사항 수집, 식별, 명세, 분류, 검증 - 기능적/비기능적요구사항 분류및 명세 |
아키텍처분석 | 품질요소식별 | - 기능성, 신뢰성, 효율성, 유지보수성, 이식성 등 |
품질요소 우선순위결정 |
- 유틸리티 트리(품질요소의 목표 및 영향도 식별) - 품질속성 시나리오 작성 |
|
전술개발 | - 품질속성별 전술개발 및 명세 | |
아키텍처설계 | 관점 및 뷰의 정의 | - 이해당사자 파악및 이해당사자별 관점, 뷰 정의 |
아키텍처 스타일(패턴) 선택 | - 파이프-필터스타일, MVC, 레이어 등 혼용 적용 | |
후보아키텍처도출 | - 컨텍스트 다이어그램 및 각종 뷰별로 다이어그램작성 - SAD(Software Architecture Description) 기술 |
|
검증 및 승인 | 아키텍처 평가 | - 아키텍처의 요구사항 만족 적합도 평가 - 품질속성 간의 Tradeoff 관계 평가(ATAM) |
아키텍처상세화 | - 설계 매커니즘도출(Persistency, Transaction 등) | |
아키텍처 승인 | - 고객 및 이해당사자 최종 승인 |
다양한 아키텍처 구조와 뷰
- 구조: 아키텍처적인 요소들의 집합이며 이러한 구조의 표현이 뷰(View)
- 뷰(View): 시스템을 이루는 요소들의 집합과 그들의 연관관계를 추상적으로 표현한 것
3단계 아키텍처 구조
구조 | 내용 |
모듈구조 (Module Structures) |
구현과 관련된 모듈의 집합으로 시스템을 표현 § How is it structured as a set of code unit? |
컴포넌트와 커넥터 구조 (Component-and-Connector Structures) |
런타임 행위와 상호작용을 갖는 요소의 집합으로 시스템을 표현 How is it structured as a set of elements that have run-time behavior and interacts? |
할당구조 (Allocation Structures) |
소프트웨어 요소가 환경적인 구조에Mapping §How does it relate to non-software structures in its environment? |
다양한 아키텍처와 관계
소프트웨어 아키텍처 수립시 고려사항
- 좋은 아키텍처와 나쁜 아키텍처를 나누는 기준은 없으며 특정 목적에 접합한 아키텍처와 그렇지 않은 아키텍처가 존재할 뿐
프로세스 측면 | 구조적 측면 |
아키텍트 팀에 의한 아키텍처 수립 요구 사항에 따른QA 우선 순위화 아키텍처 문서화 - Static view, Dynamic view 포함 이해 당사자를 통한 아키텍처 검증 성능 품질→ 정량적 수치로 평가 골격 시스템은 최소한의 기능만을 포함 자원 경쟁 → 정확하고 명확하게 명시 |
기능 모듈 단위로 구분 잘 정의된 인터페이스 제공 QA정의 및QA 목표 달성 특정 상용 제품이나 도구에 독립적 데이터 생성과 사용 모듈 구분 병렬 처리 시스템- 모듈을 하나의 컴포넌트나 커넥터로 표시X 특징적인 상호작용 패턴 |
Reference
- [외부] 소프트웨어 아키텍처 개론(11'42")
- [외부] SW 아키텍처 설계예시편_Part 1
- [외부] SW 아키텍처 설계예시편_Part 2