소프트웨어 아키텍처
▼소프트웨어 아키텍처의 개요
- 요구사항을 기반으로 개발 대상 소프트웨어의 기본틀을 만드는 것이다.
- 다수의 이해관계자가 참여하는 복잡한 개발에서 상호 이해, 타렵, 의사소통을 체계적으로 접근하기 위한 것이다.
- 전체 시스템의 전반적인 구조를 체계적으로 설계하는 것이다.
권형도(2004) : 스프트웨어를 구성하는 컴포넌트들의 상호적용 및 관계, 각각의 특성을 기반으로 컴포넌트들이 상호 유기적으로 결합하는 소프트웨어의 여러가지 원칙들의 집합이다. 설계 및 구현을 위한 구조적/비구조적 프레임을 제공한다.
스트럭처 프래임: 시스템 개발을 위하여 결정된 컴포넌트의 구조 모델이다.
논 스트럭처 프래임 : 해당 구조 모델 이외 다른 아키텍처 설계의 결정들이다.
▼소프트웨어 아키텍처의 특징과 시스템품질의 7가지 속성.
★특징
간략성 : 이해하고 추론할 수 있을 정도로 간결해야 한다.
추성화 : 시스템의 추상적인표현을 사용한다.
가시성: 시스템이 포함해야하는 것들을 가시화해야 한다.
복잡도 관리 종류 : 과정 추상화, 데이터 추상화, 제어 추상화
★ 7가지 속성
성능, 사용운용성, 보환성, 시험 용이성, 가용성, 변경 용이성, 사용성.
★소트프웨어 아키텍처 평가 기준
시스템은 어떻게 모듈로 구성되는가?
시스템은 실행 시에 어떻게 행동하고, 연결되는가?
시스템은 어떻게 비 소프트웨어 구조와 관계하고 있는가?
▼아키텍쳐 프레임워크 구성요소
★프레임워크: 복잡한 소프트웨어 문제를 해결하거나 서술하는데 필요한 기본 구조를 제공함으로서 재사용이 가능하게 해준다.
| 요소 | 설명 |
| 아키텍처 | 아키텍처를 기혹하기위한 산출물이다. 하나의 AD는 하나 이상의 뷰로 구성한다. |
| 이해관계자 | 소프트웽러 시스템 개발에 관련된 모든 사람과 조직을 의미하며, 고객, 개발자, 프로젝트 관리자 등을 포함한다 |
| 관심사 | 같은 시스템에 대해 서로 다른 이해관계자의 의견이다 |
| 관점 | 서로다른 역활이나 책임으로 시스템이나 산출물에 대한 서로 다른 관점이다. |
| 뷰 | vue가 아닌 view. 이해관계자들과 이들이 가지는 생각이나 견해로부터 전체 시스템을 표현한다. |
★소프트웨어 아키텍쳐 4+1 뷰 모델
Kruchten에 의해 오브젝트 표기법을 사용하다가 1995년 부치의 UML이 정의되면서 부치표기법을 포함하여 4+1이 되었다. 다양하고 동시적인 뷰를 기반으로 소프트웨어 위주 시스템의 아키텍처를 묘사하는 View 모형이다. 복잡한 소프트웨어 아키텍처를 다양한 이해관계자들이 바라보는 관점으로 다양한 측면을 고려하기 위해 다양한 관점으로 정의했으며, 로지컬 뷰, 임플리먼트액션, 이플로이먼트 뷰, 유저케이스 뷰 의 5계층으로 분류한 모델이다.
★소프트웨어 아키텍처의 설계원리
단순성 : 다양한 요소를 단순화하여 복잡성을 최소화한다.
효율성 : 활용 자원의 적절성과 효율성을 높인다.
분할,계층화 : 다루기 쉬운 단위를 묶어서 계층화한다.
추상화: 부가적인 기능이 아닌 핵심 기능 위주로 컴포넌트를 정의한다.
모듈화 : 내부 요소의 응집도를 높이고 각 모듈의 외부결합도를 낮춘다.
소프트웨어 아키텍처 설계과정
설계 목표 설정 -> 시스템 타입 결정 -> 스타일 적용 및 커스터마이즈 -> 서브 시스템 기능, 인터페이스 동작 작성 -> 아키텍처 설계 검토
▼소프트웨어아키텍퍼 평가 방법론의 종류
SAAM(Software Architecture Analysis Method) : 다양한 수정 가능성 관점에서 아키텍처를 평가하고 분석하는 방법이다.
수정/변경에 필요한 자원을 가정하고 이를 기반으로 평가한다. ATAM에 비하여 상세하지는 않지만 보다 많은 영역에 적용할 수 있다.
ATAM(Arcitecture Trade Off Analysis Method) : 아키텍처가 품질 속성을 만족하는지 판단하고, 어떻게 절충하면서 상호작용 하는지 분석하는 평가방법으로, 모든 품질 속성을 평가하고, 관심있는 모든 관련 당사자들이 참여한다.
정량적/.정성적 분석/평가를 수행하며, 민감점과 절충점을 찾는 데 중점을 둔다.
CBAM(Cost Benefit Analysis Method) : 소프트웨어 아키텍처를 ROI 관점에서 평가하여 시스템이 제공하는 품질에서 경제적 이득측면을 고려한다. 비용, 이익을 기반으로 계산하여 수익이 최대화 되는 소프트웨어 아키텍처를 선정한다.
ARIDActive Review for Intermediate Design, ATAM과 ADR(Active Design Review의 호합): 전체 아키텍처가 아닌 한 부분에 대한 품질 요소에 집중하여 평가를 진행한다.