최신판 |
당신의 편집 |
1번째 줄: |
1번째 줄: |
| [[분류:소프트웨어 공학]] | | [[분류:소프트웨어 공학]] |
|
| |
| ;Software Architecture | | ;Software Architecture |
| ;SW 컴포넌트들 간의 상호 관계를 정의 및 설계하고 전개하기 위한 구조
| |
|
| |
|
| ==특징== | | == 4+1 뷰 == |
| {| class="wikitable" | | {| class="wikitable" |
| !특징
| |
| !내용
| |
| |-
| |
| |'''간략성'''
| |
| |이해하고 추론할 수 있을 정도의 간결성 유지
| |
| |-
| |
| |'''추상화'''
| |
| |시스템의 추상적인 표현을 사용(복잡도 관리)
| |
| |- | | |- |
| |'''가시성'''
| | | Logical View || → || Development View |
| |시스템이 포함해야 하는 것들을 가시화, 청사진
| |
| |}
| |
| | |
| ==참조 모델==
| |
| ===[[ISO/IEC/IEEE 42010]]===
| |
| | |
| ;소프트웨어 아키텍처에 대한 국제 표준
| |
| | |
| ===[[SEI 3 뷰]]===
| |
| | |
| ;미 [[소프트웨어 공학 연구소]]의 3체계 뷰
| |
| | |
| *모듈 뷰(Module View)
| |
| *컴포넌트 뷰(Component View)
| |
| *할당 뷰(Allocation View)
| |
| | |
| ===[[지멘스 4 뷰]]===
| |
| | |
| ;지멘스사의 4체계 뷰
| |
| | |
| [[파일:Siemens Four View.png|400px]]
| |
| | |
| ===[[RUP 4+1 뷰]]===
| |
| | |
| ;Rational Unified Process의 4+1체계 뷰
| |
| | |
| {| class="wikitable"
| |
| ! style="text-align: center;" |Logical View
| |
| | style="text-align: center;" |→ | |
| ! style="text-align: center;" |Development View
| |
| (Implement View) | | (Implement View) |
| |- | | |- |
| | style="text-align: center;" |↓ | | | ↓ || Scenarios |
| ! style="text-align: center;" |Scenarios
| |
| (Use-Case View) | | (Use-Case View) |
| | style="text-align: center;" |↓ | | || ↓ |
| |- | | |- |
| ! style="text-align: center;" |Process View
| | | Process View || → || Physical View |
| | style="text-align: center;" |→ | |
| ! style="text-align: center;" |Physical View
| |
| |} | | |} |
|
| |
| *[https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf 4+1뷰 아키텍처 원문 보기]
| |
|
| |
| == [[소프트웨어 아키텍처 스타일]] ==
| |
| ※ '''소프트웨어 아키텍처 패턴'''으로 불리기도 한다. 본 위키에선 '[[소프트웨어 디자인 패턴|디자인 패턴]]'과의 구분을 위해 '아키텍처 스타일'을 사용한다.
| |
|
| |
| * 아키텍처 설계에서 반복해서 나타나는 문제를 해결하고 아키텍처가 만족시켜야 하는 시스템 품질 속성을 달성할 수 있는 방법을 체계화 한 것
| |
| * 아키텍처를 구성하는 컴포넌트와 커넥터 종류와 이것들이 결합하는 방법 정의
| |
| * 아키텍처 설계시 이용 가능한 베스트 프랙티스
| |
|
| |
| ==[[소프트웨어 아키텍처 평가]]==
| |
| ===평가 모델 개요===
| |
| [[파일:소프트웨어 아키텍처 평가 모델.png]]
| |
| {| class="wikitable"
| |
| !평가 모델
| |
| !설명
| |
| |-
| |
| |SAAM
| |
| |
| |
| *Software Architecture Analysis Method
| |
| *변경 용이성, 기능 집중, 평가 용이
| |
| |-
| |
| |ATAM
| |
| |
| |
| *Architecture Trade-off Analysis Method
| |
| *품질속성 만족 여부 판단, 이해 관계 평가
| |
| |-
| |
| |CBAM
| |
| |
| |
| *Cost Benefit Analysis Method
| |
| *의사결정 요구 충족, ATAM바탕 분석
| |
| |-
| |
| |ADR
| |
| |
| |
| *Active Design Review
| |
| *아키텍처 구성요소 간 응집도 평가
| |
| |-
| |
| |ARID
| |
| |
| |
| *Active Review for Intermediate Designs
| |
| *특정 부분에 대한 품질 요소 집중
| |
| |}
| |
|
| |
| *일반적으로 ATAM과 CBAM이 가장 많이 쓰임
| |
|
| |
| *ATAM 평가 후 비용/이익 측면 평가 위해 CBAM 수행
| |
|
| |
| ===[[ATAM]]===
| |
|
| |
| ;Architecture Trade-off Analysis Method
| |
|
| |
| *아키텍처 품질속성 만족 여부 판단
| |
| *품질속성들간 연관관계 및 상충 분석
| |
|
| |
| ===[[CBAM]]===
| |
|
| |
| ;Cost Benefit Analysis Method
| |
|
| |
| *ATAM을 바탕으로 기본 평가
| |
| *아키텍처의 경제적 모델링 방법
| |
|
| |
| ==아키텍처 개발 절차==
| |
| {| class="wikitable"
| |
| !단계
| |
| !주요활동
| |
| !내용
| |
| |-
| |
| | colspan="2" |요구사항 분석
| |
| |요구사항 취득, 식별, 명세, 분류, 검증 등
| |
| |-
| |
| | rowspan="3" |아키텍처 분석
| |
| |품질요소 식별
| |
| |ISO9216 품질 요구사항 활용
| |
| |-
| |
| |품질요소
| |
| 우선순위 결정
| |
| |Utility Tree(시나리오 명세) 작성
| |
| |-
| |
| |전술개발
| |
| |품질속성별 전술개발 및 명세
| |
| |-
| |
| | rowspan="3" |아키텍처 설계
| |
| |관점 및 뷰 정의
| |
| |이해당사자별 관점 정의
| |
| 4+1 아키텍처 활용
| |
| |-
| |
| |아키텍처 스타일 선택
| |
| |[[MVC]], Pipe-Filter 등 스타일 선택 및 조합
| |
| |-
| |
| |후보 아키텍처 도출
| |
| |SAD(Software Architecture Description) 작성
| |
| |-
| |
| | rowspan="3" |검증 및 승인
| |
| |아키텍처 평가
| |
| |[[ATAM]], [[CBAM]] 이용
| |
| |-
| |
| |아키텍처 상세화
| |
| |디자인 패턴 고려, 설계 매커니즘 도출
| |
| |-
| |
| |아키텍처 승인
| |
| |고객 및 이해당사자 최종 승인
| |
| |}
| |
|
| |
| == [[소프트웨어 아키텍처 기술서]] ==
| |
|
| |
| ; SW 이해관계자들이 다양한 관점에 따라 [[소프트웨어 아키텍처]]를 기술한 최종 산출물
| |
|
| |
| * 이해관계자들의 시스템 이해 및 의사소통, 의사결정의 수단으로 활용
| |