IT 위키 - 사용자 기여 [ko]

RUP 4+1 뷰

2019-10-18T14:27:13Z

영원한도비: 새 문서: 분류:소프트웨어 공학 ;Philippe Kruchten이 Rational Unified Process(RUP)에서 제안한 소프트웨어 아키텍처 뷰 모델 파일:4+1뷰.png * 표준이...

[[분류:소프트웨어 공학]]
;Philippe Kruchten이 Rational Unified Process(RUP)에서 제안한 [[소프트웨어 아키텍처]] 뷰 모델

[[파일:4+1뷰.png]]
* 표준이 아니므로 설명하는 사람마다 조금씩 차이가 있다.
* Implementation View cf. Development View, Deployment View cf. Physical View

== 구성 ==
== 유스케이스 뷰 ==
;사용자, 설계자, 개발자 및 테스터의 관점
* 외부 액터가 인식하는 시스템의 기능성을 설명
* 주로 UseCase Diagram, Activity Diagram으로 표현
* 유스케이스 뷰는 시스템 검증 시에도 활용

== 논리 뷰 ==
;설계자와 개발자 관점
* 시스템 내부를 조망하고 시스템의 기능성이 어떻게 제공되는지 설명
* 정적 구조와 동적 구조를 다룸
** 정적 구조: 클래스, 객체, 관계(Class Diagram, Object Diagram)
** 동적 구조: 객체가 다른 객체에게 메시지를 전달할 때 발생하는 협동구조(Statechart Diagram, Sequence
Diagram, Collaboration Diagram, Activity Diagram)

== 프로세스 뷰 ==
;개발자와 시스템 통합자 관점
* 프로세스와 프로세서로 구분되는 시스템의 분할을 설명
* 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행 및 비동기, 이벤트의 처리 등
* 상태 다이어그램, 순차 다이어그램, 협동 다이어그램, 활동 다이어그램, 컴포넌트 다이어그램(Component Diagram)과 배치 다이어그램(Deployment Diagram) 등으로 표현

== 구현 뷰 ==
* 구현 모듈과의 의존성 표현
* 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의

== 배치 뷰 ==
;개발자, 시스템 통합자 및 테스터 관점
* 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 보여주는 맵핑
* 배치 다이어그램으로 표현

파일:4+1뷰.png

2019-10-18T14:26:12Z

영원한도비: 출처: 소프트웨어 공학 센터

출처: 소프트웨어 공학 센터

SEI 3 뷰

2019-10-18T14:15:15Z

영원한도비: 새 문서: 분류:소프트웨어 공학 ;미 소프트웨어 공학 연구소의 소프트웨어 아키텍처 뷰 모델 Module, Component & Connector, Allocation 3가지 관점으...

[[분류:소프트웨어 공학]]
;미 [[소프트웨어 공학 연구소]]의 [[소프트웨어 아키텍처]] 뷰 모델
Module, Component & Connector, Allocation 3가지 관점으로 아키텍처 서술

== 구성 ==
=== Module Structure(View) ===
;모듈은 시스템의 주요한 구현 단위(implementation unit)이며, 각 모듈들은 기능적 책임을 갖는다.
* '''분할(Decomposition)''' : 하나의 모듈이 보다 작은 모듈들로 분해된다.
* '''사용(Uses)''' : 사용구조의 unit들은 서로 uses 관계로써 연관되며, 사용 구조는 기능 추가를 위해 쉽게 확장이 가능한 공학 시스템에 사용된다. 사용구조의 시스템은 증분적(incremental) 개발이 용이하다.
* '''레이어(Layered)''' : 레이어는 관련 기능성의 coherent한 집합이다. 이 경우 Layer n은 Layer n-1의 서비스만을 사용(use)할 수 있다.
* '''클래스(Class)''' 또는 일반화(Generalization): 일반화 구조에서의 모듈 유닛을 클래스라 지칭한다. 이 구조는 유사한 행위나 능력의 집합에 관한 이론을 지원한다.

=== Component and Connector Structure(View) ===
;런타임 컴포넌트와 커넥터로 시스템의 실행단위를 기술한다.
* '''Pipe-and-Filter''': 데이터 스트림을 연속적으로 변환한다.
* '''공유 데이터(Shared Data, or repository)''': 이 구조는 영구적인 데이터를 생성, 저장, 접근하는 컴포넌트와 커넥터로 구성된다.
* '''발행 구독(Publish-Subscribe)''': 이벤트의 공표를 통하여 컴포넌트들이 상호작용 한다.
* '''Client-Server''' : 이 구조에서는 클라이언트와 서버가 컴포넌트이며, 프로토콜과 메시지가 커넥터가 된다.
* '''Peer-to-Pee'''r: 컴포넌트들이 동등한 입장에서 서비스를 교환하며 상호작용한다.
* '''프로세스 통신(Communicating processes)''': 모든 C&C구조와 마찬가지로, 이 구조도 모듈 기반 구조와 orthogonal하며 구동(running) 시스템의 동적인 면을 다룬다. 이 구조에서는 프로세스나 쓰레드가 구성 유닛이 된다.

=== . Allocation Structure(View) ===
;시스템의 소프트웨어 구성요소와 소프트웨어가 생성되고 실행되는 외부 환경사이의 관계를 기술한다.
* '''배치(Deployment)''' : 배치 구조는 소프트웨어가 하드웨어와 통신 요소에 할당되는 내용을 나타낸다. 이 구조의 요소는 소프트웨어(주로 C&C 뷰에서의 프로세스), 하드웨어(프로세서), 통신 경로 등이다.
* '''구현(Implementation)''' : 이 구조는 소프트웨어 요소(주로 모듈)와 시스템 개발, 통합, 형상관리 환경에서 파일 구조와의 맵핑 관계를 나타낸다.
* '''작업 할당(Work assignment)''': 이 구조는 모듈의 구현 및 통합에 대한 책임을 적절한 개발 팀에 할당한다.

소프트웨어 아키텍처

2019-10-18T13:28:07Z

영원한도비: /* SEI 3 뷰 */

[[분류:소프트웨어 공학]]
;Software Architecture
;SW 컴포넌트들 간의 상호 관계를 정의 및 설계하고 전개하기 위한 구조

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

== 참조 모델 ==
=== [[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)
|-
| style="text-align: center;" | ↓
! style="text-align: center;" | Scenarios
(Use-Case View)
| style="text-align: center;" | ↓
|-
! 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]] 이용
|-
| 아키텍처 상세화
| 디자인 패턴 고려, 설계 매커니즘 도출
|-
| 아키텍처 승인
| 고객 및 이해당사자 최종 승인
|}

소프트웨어 아키텍처

2019-10-18T13:26:33Z

영원한도비:

[[분류:소프트웨어 공학]]
;Software Architecture
;SW 컴포넌트들 간의 상호 관계를 정의 및 설계하고 전개하기 위한 구조

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

== 참조 모델 ==
=== [[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)
|-
| style="text-align: center;" | ↓
! style="text-align: center;" | Scenarios
(Use-Case View)
| style="text-align: center;" | ↓
|-
! 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]] 이용
|-
| 아키텍처 상세화
| 디자인 패턴 고려, 설계 매커니즘 도출
|-
| 아키텍처 승인
| 고객 및 이해당사자 최종 승인
|}

소프트웨어 아키텍처

2019-10-18T13:26:21Z

영원한도비:

[[분류:소프트웨어 공학]]
;Software Architecture
;SW 컴포넌트들 간의 상호 관계를 정의 및 설계하고 전개하기 위한 구조

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

== 참조 모델 ==
=== [[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)
|-
| style="text-align: center;" | ↓
! style="text-align: center;" | Scenarios
(Use-Case View)
| style="text-align: center;" | ↓
|-
! 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]] 이용
|-
| 아키텍처 상세화
| 디자인 패턴 고려, 설계 매커니즘 도출
|-
| 아키텍처 승인
| 고객 및 이해당사자 최종 승인
|}

지멘스 4 뷰

2019-10-18T13:19:03Z

영원한도비:

[[분류:소프트웨어 공학]]
;Siemens Four View
;지멘스의 4가지 뷰; [[소프트웨어 아키텍처]] 뷰

[[파일:Siemens Four View.png]]

== 구성 ==
* 개념적 아키텍처 뷰(Conceptual Architectural View)
* 모듈 아키텍처 뷰(Module Architecture View)
* 코드 아키텍처 뷰 (Code Architecture View)
* 실행 아키텍처 뷰(Execution Architecture View)

지멘스 4 뷰

2019-10-18T13:18:27Z

영원한도비: 새 문서: 분류:소프트웨어 공학 ;Siemens Four View ;지멘스의 4가지 뷰 파일:Siemens Four View.png == 구성 == * 개념적 아키텍처 뷰(Conceptual Architectural Vi...

[[분류:소프트웨어 공학]]
;Siemens Four View
;지멘스의 4가지 뷰

[[파일:Siemens Four View.png]]

== 구성 ==
* 개념적 아키텍처 뷰(Conceptual Architectural View)
* 모듈 아키텍처 뷰(Module Architecture View)
* 코드 아키텍처 뷰 (Code Architecture View)
* 실행 아키텍처 뷰(Execution Architecture View)

파일:Siemens Four View.png

2019-10-18T13:17:17Z

영원한도비:

Software Engineering Institute

2019-10-18T13:06:34Z

영원한도비: 소프트웨어 공학 연구소 문서로 넘겨주기

#넘겨주기 [[소프트웨어 공학 연구소]]

SEI

2019-10-18T13:06:04Z

영원한도비: 소프트웨어 공학 연구소 문서로 넘겨주기

#넘겨주기 [[소프트웨어 공학 연구소]]

소프트웨어 공학 연구소

2019-10-18T13:05:46Z

영원한도비: 새 문서: 분류:소프트웨어 공학분류:조직/단체 ;Software Engineering Institute; SEI * 미국 펜실베니아 피츠버그 카네기 멜론 대학에 위치한다. * 미...

[[분류:소프트웨어 공학]][[분류:조직/단체]]
;Software Engineering Institute; SEI

* 미국 펜실베니아 피츠버그 카네기 멜론 대학에 위치한다.
* 미 국방부가 후원한다.
* 소프트웨어와 관련된 각종 프레임워크, 아키텍처, 표준 등을 연구한다.

MVC 패턴

2019-10-18T12:52:10Z

영원한도비:

[[분류:소프트웨어 공학]]
;Model-View-Controller Pattern

== 구성 ==
[[파일:MVC Pattern.png]]
{| class="wikitable"
|-
! 구분 !! 설명
|-
| Model || 데이터와 그 처리 로직
|-
| View || UI 구현
|-
| Controller || 입력 정보를 이벤트 형태로 수신
|}

== MVC 패턴의 변형 ==
[[파일:MVC패턴의 변형.png]]
* [[PAC 패턴]]
* [[Document-View 패턴]]
* [[MVP 패턴]]
* [[MVVM 패턴]]

파일:MVC패턴의 변형.png

2019-10-18T12:51:23Z

영원한도비: 출처: 소프트웨어 공학 센터

출처: 소프트웨어 공학 센터

파일:MVC Pattern.png

2019-10-18T12:48:41Z

영원한도비: 출처: 소프트웨어 공학 센터

출처: 소프트웨어 공학 센터