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

From IT위키
(새 문서: 분류:소프트웨어 공학 ;Software Architecture == 4+1 뷰 == {| class="wikitable" |- | Logical View || → || Development View (Implement View) |- | ↓ || Scenarios (Use-C...)
 
No edit summary
 
(18 intermediate revisions by 3 users not shown)
Line 1: Line 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)
|-
|-
| ↓ || Scenarios
| style="text-align: center;" |↓
! style="text-align: center;" |Scenarios
(Use-Case View)
(Use-Case View)
|| ↓
| style="text-align: center;" |↓
|-
|-
| Process View || → || Physical View
! style="text-align: center;" |Process 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 이해관계자들이 다양한 관점에 따라 [[소프트웨어 아키텍처]]를 기술한 최종 산출물
* 이해관계자들의 시스템 이해 및 의사소통, 의사결정의 수단으로 활용

Latest revision as of 09:39, 4 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체계 뷰

400px

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 이해관계자들이 다양한 관점에 따라 소프트웨어 아키텍처를 기술한 최종 산출물
  • 이해관계자들의 시스템 이해 및 의사소통, 의사결정의 수단으로 활용
Retrieved from "https://itwiki.kr/index.php?title=소프트웨어_아키텍처&oldid=27681"