소프트웨어 아키텍처 편집하기

IT위키

경고: 로그인하지 않았습니다. 편집을 하면 IP 주소가 공개되게 됩니다. 로그인하거나 계정을 생성하면 편집자가 사용자 이름으로 기록되고, 다른 장점도 있습니다.

편집을 취소할 수 있습니다. 이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 게시해주세요.

최신판 당신의 편집
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 이해관계자들이 다양한 관점에 따라 [[소프트웨어 아키텍처]]를 기술한 최종 산출물
* 이해관계자들의 시스템 이해 및 의사소통, 의사결정의 수단으로 활용
IT위키에서의 모든 기여는 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 라이선스로 배포된다는 점을 유의해 주세요(자세한 내용에 대해서는 IT위키:저작권 문서를 읽어주세요). 만약 여기에 동의하지 않는다면 문서를 저장하지 말아 주세요.
또한, 직접 작성했거나 퍼블릭 도메인과 같은 자유 문서에서 가져왔다는 것을 보증해야 합니다. 저작권이 있는 내용을 허가 없이 저장하지 마세요!
취소 편집 도움말 (새 창에서 열림)