소프트웨어 아키텍처: Difference between revisions

From CS Wiki
No edit summary
No edit summary
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[분류:소프트웨어 공학]]
[[분류:소프트웨어 공학]]
;Software Architecture
;Software Architecture
;SW 컴포넌트들 간의 상호 관계를 정의 및 설계하고 전개하기 위한 구조
;SW 컴포넌트들 간의 상호 관계를 정의 및 설계하고 전개하기 위한 구조


== 특징 ==
==특징==
{| class="wikitable"
{| class="wikitable"
! 특징
!특징
! 내용
!내용
|-
|-
| '''간략성'''
|'''간략성'''
| 이해하고 추론할 수 있을 정도의 간결성 유지
|이해하고 추론할 수 있을 정도의 간결성 유지
|-
|-
| '''추상화'''
|'''추상화'''
| 시스템의 추상적인 표현을 사용(복잡도 관리)
|시스템의 추상적인 표현을 사용(복잡도 관리)
|-
|-
| '''가시성'''
|'''가시성'''
| 시스템이 포함해야 하는 것들을 가시화, 청사진
|시스템이 포함해야 하는 것들을 가시화, 청사진
|}
|}


== 참조 모델 ==
==참조 모델==
=== [[ISO/IEC/IEEE 42010]] ===
===[[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체계 뷰


=== 4+1뷰 아키텍처 ===
; IEEE Paper
{| class="wikitable"
{| class="wikitable"
! style="text-align: center;" | Logical View
! style="text-align: center;" |Logical View
| style="text-align: center;" | →
| style="text-align: center;" |→
! style="text-align: center;" | Development View
! style="text-align: center;" |Development View
(Implement View)
(Implement View)
|-
|-
| style="text-align: center;" | ↓
| style="text-align: center;" |↓
! style="text-align: center;" | Scenarios
! style="text-align: center;" |Scenarios
(Use-Case View)
(Use-Case View)
| style="text-align: center;" | ↓
| style="text-align: center;" |↓
|-
|-
! style="text-align: center;" | Process View
! style="text-align: center;" |Process View
| style="text-align: center;" | →
| style="text-align: center;" |→
! style="text-align: center;" | Physical View
! style="text-align: center;" |Physical View
|}
|}


* [https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf 4+1뷰 아키텍처 원문 보기]
*[https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf 4+1뷰 아키텍처 원문 보기]
 
== [[소프트웨어 아키텍처 스타일]] ==
※ '''소프트웨어 아키텍처 패턴'''으로 불리기도 한다. 본 위키에선 '[[소프트웨어 디자인 패턴|디자인 패턴]]'과의 구분을 위해 '아키텍처 스타일'을 사용한다.


== [[소프트웨어 아키텍처 평가]] ==
* 아키텍처 설계에서 반복해서 나타나는 문제를 해결하고 아키텍처가 만족시켜야 하는 시스템 품질 속성을 달성할 수 있는 방법을 체계화 한 것
=== 평가 모델 개요 ===
* 아키텍처를 구성하는 컴포넌트와 커넥터 종류와 이것들이 결합하는 방법 정의
* 아키텍처 설계시 이용 가능한 베스트 프랙티스
 
==[[소프트웨어 아키텍처 평가]]==
===평가 모델 개요===
[[파일:소프트웨어 아키텍처 평가 모델.png]]
[[파일:소프트웨어 아키텍처 평가 모델.png]]
{| class="wikitable"
{| class="wikitable"
! 평가 모델
!평가 모델
! 설명
!설명
|-
|-
| SAAM
|SAAM
| Software Architecture Analysis Method– 변경 용이성, 기능 집중, 평가 용이
|
*Software Architecture Analysis Method
*변경 용이성, 기능 집중, 평가 용이
|-
|-
| ATAM
|ATAM
| Architecture Trade-off Analysis Method– 품질속성 만족 여부 판단, 이해 관계 평가
|
*Architecture Trade-off Analysis Method
*품질속성 만족 여부 판단, 이해 관계 평가
|-
|-
| CBAM
|CBAM
| Cost Benefit Analysis Method– 의사결정 요구 충족, ATAM바탕 분석
|
*Cost Benefit Analysis Method
*의사결정 요구 충족, ATAM바탕 분석
|-
|-
| ADR
|ADR
| Active Design Review– 아키텍처 구성요소 간 응집도 평가
|
*Active Design Review
*아키텍처 구성요소 간 응집도 평가
|-
|-
| ARID
|ARID
| Active Review for Intermediate Designs– 특정 부분에 대한 품질 요소 집중
|
*Active Review for Intermediate Designs
*특정 부분에 대한 품질 요소 집중
|}
|}
* 일반적으로 ATAM과 CBAM이 가장 많이 쓰임


* ATAM 평가 후 비용/이익 측면 평가 위해 CBAM 수행
*일반적으로 ATAM과 CBAM이 가장 많이 쓰임
 
*ATAM 평가 후 비용/이익 측면 평가 위해 CBAM 수행
 
===[[ATAM]]===


=== [[ATAM]] ===
;Architecture Trade-off Analysis Method
;Architecture Trade-off Analysis Method
* 아키텍처 품질속성 만족 여부 판단
* 품질속성들간 연관관계 및 상충 분석


=== [[CBAM]] ===
*아키텍처 품질속성 만족 여부 판단
* ATAM을 바탕으로 기본 평가
*품질속성들간 연관관계 및 상충 분석
* 아키텍처의 경제적 모델링 방법
 
===[[CBAM]]===
 
;Cost Benefit Analysis Method


== 아키텍처 개발 절차 ==
*ATAM을 바탕으로 기본 평가
*아키텍처의 경제적 모델링 방법
 
==아키텍처 개발 절차==
{| class="wikitable"
{| class="wikitable"
! 단계
!단계
! 주요활동
!주요활동
! 내용
!내용
|-
|-
| colspan="2" | 요구사항 분석
| colspan="2" |요구사항 분석
| 요구사항 취득, 식별, 명세, 분류, 검증 등
|요구사항 취득, 식별, 명세, 분류, 검증 등
|-
|-
| rowspan="3" | 아키텍처 분석
| rowspan="3" |아키텍처 분석
| 품질요소 식별
|품질요소 식별
| ISO9216 품질 요구사항 활용
|ISO9216 품질 요구사항 활용
|-
|-
| 품질요소
|품질요소
우선순위 결정
우선순위 결정
| Utility Tree(시나리오 명세) 작성
|Utility Tree(시나리오 명세) 작성
|-
|-
| 전술개발
|전술개발
| 품질속성별 전술개발 및 명세
|품질속성별 전술개발 및 명세
|-
|-
| rowspan="3" | 아키텍처 설계
| rowspan="3" |아키텍처 설계
| 관점 및 뷰 정의
|관점 및 뷰 정의
| 이해당사자별 관점 정의
|이해당사자별 관점 정의
4+1 아키텍처 활용
4+1 아키텍처 활용
|-
|-
| 아키텍처 스타일 선택
|아키텍처 스타일 선택
| [[MVC]], Pipe-Filter 등 스타일 선택 및 조합
|[[MVC]], Pipe-Filter 등 스타일 선택 및 조합
|-
|-
| 후보 아키텍처 도출
|후보 아키텍처 도출
| SAD(Software Architecture Description) 작성
|SAD(Software Architecture Description) 작성
|-
|-
| rowspan="3" | 검증 및 승인
| rowspan="3" |검증 및 승인
| 아키텍처 평가
|아키텍처 평가
| [[ATAM]], [[CBAM]] 이용
|[[ATAM]], [[CBAM]] 이용
|-
|-
| 아키텍처 상세화
|아키텍처 상세화
| 디자인 패턴 고려, 설계 매커니즘 도출
|디자인 패턴 고려, 설계 매커니즘 도출
|-
|-
| 아키텍처 승인
|아키텍처 승인
| 고객 및 이해당사자 최종 승인
|고객 및 이해당사자 최종 승인
|}
|}
== [[소프트웨어 아키텍처 기술서]] ==
; SW 이해관계자들이 다양한 관점에 따라 [[소프트웨어 아키텍처]]를 기술한 최종 산출물
* 이해관계자들의 시스템 이해 및 의사소통, 의사결정의 수단으로 활용

Latest revision as of 19:39, 3 February 2022


Software Architecture
SW 컴포넌트들 간의 상호 관계를 정의 및 설계하고 전개하기 위한 구조

특징[edit | edit source]

특징 내용
간략성 이해하고 추론할 수 있을 정도의 간결성 유지
추상화 시스템의 추상적인 표현을 사용(복잡도 관리)
가시성 시스템이 포함해야 하는 것들을 가시화, 청사진

참조 모델[edit | edit source]

ISO/IEC/IEEE 42010[edit | edit source]

소프트웨어 아키텍처에 대한 국제 표준

SEI 3 뷰[edit | edit source]

소프트웨어 공학 연구소의 3체계 뷰
  • 모듈 뷰(Module View)
  • 컴포넌트 뷰(Component View)
  • 할당 뷰(Allocation View)

지멘스 4 뷰[edit | edit source]

지멘스사의 4체계 뷰

Siemens Four View.png

RUP 4+1 뷰[edit | edit source]

Rational Unified Process의 4+1체계 뷰
Logical View Development View

(Implement View)

Scenarios

(Use-Case View)

Process View Physical View

소프트웨어 아키텍처 스타일[edit | edit source]

소프트웨어 아키텍처 패턴으로 불리기도 한다. 본 위키에선 '디자인 패턴'과의 구분을 위해 '아키텍처 스타일'을 사용한다.

  • 아키텍처 설계에서 반복해서 나타나는 문제를 해결하고 아키텍처가 만족시켜야 하는 시스템 품질 속성을 달성할 수 있는 방법을 체계화 한 것
  • 아키텍처를 구성하는 컴포넌트와 커넥터 종류와 이것들이 결합하는 방법 정의
  • 아키텍처 설계시 이용 가능한 베스트 프랙티스

소프트웨어 아키텍처 평가[edit | edit source]

평가 모델 개요[edit | edit source]

소프트웨어 아키텍처 평가 모델.png

평가 모델 설명
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[edit | edit source]

Architecture Trade-off Analysis Method
  • 아키텍처 품질속성 만족 여부 판단
  • 품질속성들간 연관관계 및 상충 분석

CBAM[edit | edit source]

Cost Benefit Analysis Method
  • ATAM을 바탕으로 기본 평가
  • 아키텍처의 경제적 모델링 방법

아키텍처 개발 절차[edit | edit source]

단계 주요활동 내용
요구사항 분석 요구사항 취득, 식별, 명세, 분류, 검증 등
아키텍처 분석 품질요소 식별 ISO9216 품질 요구사항 활용
품질요소

우선순위 결정

Utility Tree(시나리오 명세) 작성
전술개발 품질속성별 전술개발 및 명세
아키텍처 설계 관점 및 뷰 정의 이해당사자별 관점 정의

4+1 아키텍처 활용

아키텍처 스타일 선택 MVC, Pipe-Filter 등 스타일 선택 및 조합
후보 아키텍처 도출 SAD(Software Architecture Description) 작성
검증 및 승인 아키텍처 평가 ATAM, CBAM 이용
아키텍처 상세화 디자인 패턴 고려, 설계 매커니즘 도출
아키텍처 승인 고객 및 이해당사자 최종 승인

소프트웨어 아키텍처 기술서[edit | edit source]

SW 이해관계자들이 다양한 관점에 따라 소프트웨어 아키텍처를 기술한 최종 산출물
  • 이해관계자들의 시스템 이해 및 의사소통, 의사결정의 수단으로 활용