8. Architecture Viewpoints

View 란?

시스템을 이루는 SW요소들의 집합 과 SW요소들의 연관 관계를 추상적 으로 표현한 것

 

Module View 무엇인가요?

Module간의 상호 연결 관계

 

Runtime View = Component and Connector View(C&C View)

예를 들어 뭐가 있을까요?
split lower upper merge 등

파이프-필터 스타일(Pipe-and-Filter Style)
공유-데이터 스타일(Shared-Data Style)
게시-구독 스타일(Publish-Subscribe Style)
클라이언트-서버 스타일(Client-Server Style)
피어 투 피어 스타일(Peer-to-Peer Style)

 

Allocation View 무엇인가요?

Software Architecture와 환경을 매핑시키는 역할을 한다. 우선 Deployment Style와 Work Assignment Style을 살펴 보자. Deployment Style은 Software Element가 어떤 물리적 장치에 탑재되는지 보여 준다. 시스템 동작 시, Deployment 내용이 변경 될 수 있으므로 할당은 동적일 수 있다. Work Assignment Style은 Module View의 내용 중 구현 책임이 있는 개인이나 그룹에 할당하는 것이다. 즉, 구조와 작업하는 개발 그룹간의 관계를 보여 주는 모습이라고 할 수 있다.

 

4+1 View

Logical View
Process View
Development View
Physical View
+Use Cases/Scenarios

 

유스케이스 뷰

(Usecase View)
다른 뷰를 검증하는데 사용
사용자, 설계자, 개발자, 테스트 관점
유스케이스 다이어그램

논리 뷰
(Logical View)
시스템 기능 적인 요구사항이 어떻게 제공되는지
클래스나 컴포넌트의 종류와 관계를 설명하고 설계가 실제로 구현 되는지 설명
설계자 관점 (순서도나 UML 그리는 시점)
클래스/시퀀스 다이어그램

프로세스 뷰
(Process View)
시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
성능, 확장성, 효율성 관련
시스템 통합자의 관점
시퀀스/협력 다이어그램

Development 뷰
개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의
실제 구현할 수 있는지 여부를 확인
직접 만드는 개발자의 관점
컴포넌트 다이어그램

Physical 뷰
컴포넌트가 물리적 환경에서 배치 연결 작업이 어떻게 실행 되는지를 매핑해서 보여주는 뷰
배치(배포) 다이어그램

 

Context View 무엇인가요?

시스템과 환경사이의 상호작용과 의존성 관계를 표현한다

 

DFD - Data Flow Diagram 무엇인가요?

특정 기능을 나타냅니다. 레벨 0 DFD에서는 전체 대상 시스템을 나타냅니다
공통 터미널 - .사용자, 외부 시스템,  하드웨어 장치
데이터 저장소
데이터 흐름 정의

 

DFD의 터미널에 유스케이스 액터가 안되는 경우가 있는지

DFD에서 터미널이란 입력 정보를 주는 주체, 인풋 아웃풋
usecase에서 엑터는 특정 기능을 인보크하는 주체 또는 인보크를 당하는 주체
= 터미널에 있었다고 해서 전부 액터로 쓸필요는 없다

 

Functional Viewpoints

시스템의 기능을 정의

1. Functional Characteristics를 관찰
2. Skeleton Architecture로부터 UseCase Diagram을 정제
3. Functional Components를 도출
   - 유즈케이스를 Functional Components 단위로 할당
   - Functional Components 테이블 도출.
4. Tier로 Functional Components를 할당하기 위하여 정제
5. Tier별로 Functional Components를 할당

각각의 Functional Components를 디테일하게 디자인
Criterion 1. Visibility of Functional Component
Whitebox Component or Blackbox Component

Criterion 2. Type of Interface (for Blackbox Components)
Façade-type or Mediator-type

facade-type

• 각각의 객체들을 숨긴 Representative API set
• API에 50개의 기능이 있을 때, 다 사용 위해서는 50개의 request가 필요하다.
• Component의 Method 수가 많다.
• Workflow가 가변적이다.

  

mediator type

• 각각의 객체들을 숨긴 Representative API set + Workflow automation 제공
• Workflow는 재사용 가능하며, 자동적이다. (공통)
• API에 50개의 기능이 있을 때, 한 번의 요청으로 사용 가능
• 상대적으로 적은 Method 수

  

 

1. •  
2. 
   Criterion 3. Variability of Functional Component
   Closed Component or Open Component
   
   Criterion 4. Variation Points (for Open Component)
   Variation point where the variability occurs.
3. Functional Component의 인터페이스 정의
   provided interface, required interface 정의

 

Information Viewpoints

Architecture design for Information View is to make decisions about persistent datasets, properties and their management. This activity includes a number of tasks including identifying data components, allocating data components, defining their data contents, ownership, data distribution, replication, migration, data security, and data timeliness.

 

1. 타겟 시스템의 Informational Characteristics 을 관찰
2. Skeleton Architecture로부터 Persistent Object Model 을 정제
3. Data Components 를 도출
   클래스간의 상호 작용이 강한 경우, data component의 그룹으로 도출.
4. Tier로 Data Components를 할당하기 위하여 정제
5. Data Components 를 tier에 할당.
6. Design Data Components
   Data Component의 내부 상세를 디자인한다. persistent attribute 정의.
7. Data Components의 인터페이스 정의
   각각의 Data Component의 인터페이스를 정의. 대부분 CRUD가 됨.

 

Behavioral Viewpoints

아키텍처의 Behavioral View는 시스템의 런타임 동작에 초점을 맞춘 시스템의 동적 측면을 설명한다.

 

1. Behavioral Characteristics 관찰
   Explicit Invocation, Event-driven, Parallel Processing, Closed-loop control flow, time based invocation, etc...
2. 전체 시스템에 대한 Control Flow 를 정제
3. 상세한 Control Flow를 정의

Deployment Viewpoints

아키텍처의 Deployment View는 물리적 계층의 소프트웨어 구성 요소 토폴로지와 이러한 구성 요소 간의 물리적 연결에 관한 것입니다.

 

1. Deployment Characteristics 관찰
2. Nodes 정의
3. Network Connectivity 정의
   티어간의 http, https 등
4. 배포할 Artifacts 정의
5. 노드별로 Artifacts를 할당
   Deployment Diagram 활용