[소프트웨어 분석 및 설계] 11. Architecture Design For Functional View

Functional Viewpoint는 Design for Views의 ViewPoint들 중 가장 중요한 Viewpoint다.

Functional Viewpoint

: 타깃 시스템의 functional view에 대한 architecture decision을 만드는 것.

-> View Model들의 Corner stone임

 

- Input Artifacts

1) SRS

2) System Context Model

3) Skeleton Architecture

- Output Artifacts

1) Architecture with Functional Components allocated

2) Design Specification of Functional Components

 

Functional Viewpoint의 생성에 있어서의 순서

1. Refine Use Case Model

2. Define Functional Components

3. Allocate Functional Components

4. Design Functional Components

 

STEP 1. Refine Use Case Model

: 처음에 모델링할 때 High-level 언어로 Use Case Model을 짜는데 이를 이제 구체화(개발)해야 하는 단계이기에 Refine함.

 

Task 1. Observe Functional Characteristics

- 설계 결정하기 전에 충분히 기능에 대해서 알고 있어야 함.(ex. 누가 이 기능을 쓰는지, input이 뭔지, output이 뭔지)

- 기능의 타입도 알아야 함.

이런 의료 영상 분석 시스템에 대한 예시

Task 2. Refine Actors

- Actor들을 정제할 필요가 있음.

- 일반적으로 User Groups, External Systems, HW Device, SW Agents 등의 Actor의 타입이 있음.

- Actor는 active/passive 둘 다 가능함.

Task 3. Refine Use Cases

- 기능 그룹들에 대한 정제를 해야 함.

 

Task 4. Refine Invocations(메소드 호출)

- actors와 use cases 간의 invocation도 정제해야 함.

ex. Consumer(actor)가 제품을 구매(invocation)하는 것.

Task 5. Refine Relationships

- Use Case 다이어그램에는 Generalization, Includes, Extends 총 3가지 관계가 있는데 이것들도 정제해야 함.

 

Task 6. Write Use Case Description

- workflow(=control flow)를 정의함.

- Use Case에는 3가지 타입의 flow가 있음. - Main flow / Alternative flow / Error flow

- Use Case Description은 workflow에 대한 textural description임. 이는 table형태로 쓰는 것이 편함.

 

STEP 2. Define Functional Components

- Functional Components는 두 요소로부터 파생될 수 있음. - SRS, Architecture Styles

 

야야! 그러면 Use Case랑 Functional Component 차이가 뭔데!?!?!?

- 둘 다 Funtionality unit이긴한데 Functional Component는 Functionality를 제공하는 SW Module unit이다.

- Use Case는 verb로, Functional Component는 noun으로 씀.

 

Task 1. Define Functional Components from SRS

: SRS의 기능적 요구사항을 가지고 Functional component를 정의함.

-> 이미 Use Case 다이어그램에서 관련된 기능끼리 Functional Group으로 묶여있음. 이걸 그대로 Functional Component로 사용하면 됨.(근데 반드시 항상 1:1로 대응하는 것은 아님.)

- Interface Component를 정의하기도 함.

-> 인터페이스 중심의 Functional Component는 구체화/실현될 stable, public한 interface를 만듦.

ex. HW Abstraction Layer(HAL)이라는 것은 HW를 실현하지 않고 interface만 만듦. 이것의 아래 layer에서 실현하지.

- Interface-centric Component는 Interface 위주로 만들어진 컴포넌트로 각 Abstraction 요소들을 정의함.

왜 Interface Component가 Useful한지 아는게 중요하다!!!!!!!

n개의 Use Case들은 m개의 Functional Component로 묶임.

m <= n(보통은 m<<n)

Task 2. Define Functional Components from Architecture Styles

: Architecture Styles를 Skeleton Structure로 구현하는데 필요한게 Funtional Component다.

Architecture Style은 components와 connectors로 구성되어 있고 얘네는 Functional Component로 구현됨.

ex. pipe-n-filter Architecture Style에서 Filter와 Pipe는 Functional Component임.

 

Task 3. Refine Components for Tiers

: 복수개의 tier들로 정의된 skeleton architecture의 경우엔 Functional Component를 tier에 따라 정제함.

이때, 한 FC가 여러 tier에 들어갈 수 있음. 이때는 이름을 달리 해줘야 함!!(다른 tier에 들어간 FC들은 그 기능이 조금씩 다르기 때문)

Step 3. Allocate Functional Components

: skeleton architecture의 기능이 들어가는 장소에다가 FC를 할당하는 것.

 

Task 1. Identify Functionality Placeholders

: skeleton architecture 안에 FC가 들어갈 placeholder를 지정해둠.

 

Task 2. Allocate Functional Components

: 적절한 기능적 placeholder에 FC를 할당함.

Task 3. Define Responsibility of Functional Components

 

Step 4. Design Functional Components

: 할당된 FC들에 대해 Visibility(가시성), Variability(가변성), Interface를 정의함.

 

Task 1. Define Visilbility of Functional Components

: 각 FC의 타입을 결정함.

Whitebox Component(외부에서 직접 접근 가능)

VS.

Blackbox Component(외부에서 접근 불가, 대신 interface가 있어서 그걸로 접근)

 

Task 2. Define Interface of Blackbox Components

: 각 FC에 대해 Interface를 설정하는데,

얘는 public protocol이고 / FC의 메소드를 유도할 뿐 실제 구현은 X / 주로 앞에 i를 붙여서 FC Interface를 명명함.

FC의 각 Use Case들은 Interface들의 여러 메소드로 표현이 됨.

Task 3. Define Required Interface for Variability

 

Quality of Interface

1) Comprehensibility

2) Consistency

3) Discoverability

4) Simple Tasks Should Be Easy