소프트웨어를 설계하는 방법 (3) - Design with Functional Viewpoint

Design with Functional Viewpoint

Writer: Harim Kang

SW 설계에 관한 가이드라인을 글로 수록합니다. 해당 내용은 지능형 시스템(Intelligent System) 설계를 위한 가이드라인을 포함하고 있습니다.

앞서 소프트웨어 설계의 순서를 파악하시고자 한다면 다음의 링크를 통해 보고 와주세요!

2019/12/13 - [IT/SW Architecture] - 소프트웨어를 설계하는 방법 (1) - 설계 소개 및 순서

소프트웨어를 설계하는 방법 (1) - 설계 소개 및 순서

---

Functional Viewpoint

---

Definition

Functional Viewpoint는 시스템의 기능적인 설계 결정을 위하여 작성하는 순차적인 Guidelines이다. 다른 View Model들의 기반이 되는 Viewpoint이다.

Goals

1. Identifying Functional Components
   • 결과적으로는, 기능적인 부분들을 구분하는 Functional Components들을 정의한다.
2. Allocating Functional Components
   • 정의된 Functional Components들을 적절한 위치에 할당한다.
3. Designing Functional Components
   • 기능적인 부분을 설계한다.

Process of Functional Viewpoint 요약

1. Observe Functional Characteristics
   • 시스템의 Functional Requirements를 이해하는 단계
2. Refine Use Case Model
   • Use Case를 선정하여 Use Case Diagram을 그리는 단계
3. Derive Functional Components
   • Use Case들을 Group 화하여 Functional Component들을 선정하는 단계
4. Refine Functional Components for Tires
   • 정의한 Functional Component들의 System Tier를 선정하는 단계
5. Allocate Fuctional Components
   • Functional Component들을 System Tier의 Place Holder에 배치하는 단계
6. Design Functional Components
   • Functional Component들의 type을 선정하고 설계하는 단계
7. Define Interfaces of Functional Components
   • Functional Component들의 Interface를 설계하는 단계

---

Step 1. Observe Functional Characteristics

• 시스템의 SRS (Software Requirements Standards)에서 기능을 이해하는 과정이다. SRS를 정확하게 이해할 필요가 있다.

• Clarify the functionality without ambiguity

  애매모호하지 않게 기능을 충분히 이해해야 한다.

• Characteristics of Functionality

  • 기능의 복잡성 : 주로 Computing Power에 의존

  • 기능의 실행 : 실행 또는 실행 요청은 어떻게 할 것인가?

    ex) Event-Driven

  • 기능의 분류

    • 데이터 관련 기능
    • 사용자 Interaction-intensive
    • Hardware적인 기능
    • Others

• 요구사항 : SRS의 Functional Requirements를 이해하기

Step 2. Refine Use Case Model

• Context-level의 Use Case Diagram을 정제하는 단계이다.

• Use Case Diagram 작성법에 대한 구체적인 방법은 추후 포스팅을 하겠습니다.. 간단하게만 설명하고 넘어가겠습니다.

• Instruction

  • Refine Actors

    • Actor란 기능을 수행하거나 관리하는 객체를 의미한다.

    • Add, modify or delete Actors

    • 각 Actor는 일반적으로 CRUD Use cases를 가지고 있다.

      • CRUD : create, read, update, delete //필요에 따라 없어도 된다. (시스템 일 때, 등등)

    • Ex

      쇼핑몰 애플리케이션을 설계한다고 생각해보자.

      애플리케이션을 사용하는 User와 상품을 관리하는 Store, 다양한 서비스를 제공하는 System으로 이루어져 있다.

      User, Store, System이 각각 Actor가 된다.

      

  • Refine Use Cases

    • Add, modify of delete use case.

    • 시스템이 제공하는 모든 기능들을 의미한다.

      

  • Refine Relationships

    • Apply generalization
      • 일반적인 유스케이스간 또는 유스케이스와 Actor와의 관계이다.
    • Include Relationsh
      • A 와 B가 include 관계라고 하면, A기능을 실행하면 반드시 B기능도 함께 실행한다는 의미의 관계입니다.
    • Extend Relationships
      • A 와 B가 extend 관계라고 하면, A기능을 실행했을때, B기능도 선택적으로 실행 가능하다는 의미의 관계입니다.

  • Artifact Template

    • Use Case Diagram을 작성한다.

  • Ex

    

    Ex. FinE Store Use Case

    • TODO : Use Case Diagram 작성법 포스팅

  ---

  Identify Functionality related to Intelligent System

  • Use Cases

    • Acquire Training Sets for ML

      • 훈련 데이터를 얻는 Use Case

    • Generate ML models

      • 모델을 학습시키는 Use Case

    • Predict with ML models

      • 모델 예측(실행)을 하는 Use Case
      • Application (Client) Level

    • Evaluate ML models

      • 모델 평가를 하는 Use Case
      • User FeedBack or Evaluation Metrices

    • Optimize ML models

      • 평가를 토대로 model을 최적화하는 Use Case

      • Hyper-Parameter 수정 (최적화)

      • Regeneration (재학습)

      • Ex

        

Step 3. Derive Functional Components

• Use Case들 중에서 연관성 있는 기능들을 모아서 Functional Components로 정의한다.

• Functional Component

  • Unit of software Module providing Functionality
  • 기능을 제공하는 Module단위
  • Use Case는 Functional Component안의 가장 작은 기능 단위
  • Use Case를 Group으로 묶으면 된다!

• Functional Components relevant to Intelligent System

  • Dataset Manager → DM

  • ML Model Manager → MM

  • Detection and Feedback Manager → DF

  • Ex : Intelligent를 위한 Use Case들의 예시

    

• Ex : 제가 기획한 옷 스타일 분류 어플리케이션의 Use Case Diagram입니다.

  

  

Step 4. Refine Functional Components for Tiers

• Functional Components을 Tier에 맞게 정제하는 과정이다.

• Tier는 Skeleton Architecture에서 정의한 것을 기준으로 사용하며, 1개의 Tier인 경우 생략한다.

• Tier란?

  흔한 2 Tier인 Server (고성능 컴퓨터) - Client (사용자 컴퓨터 or 모바일)를 생각하면 된다.

• Ex

  

  Skeleton Architecture (왼쪽이 Client, 오른쪽이 Server)

  • Ex

    

    예제의 경우, ML model Manager를 Server에, Data Manager는 Client와 Server 양쪽에 배치하였다. 양쪽 배치 시, Client Component 앞에는 c를, Server Component 앞에는 s를 붙인다.

Step 5. Allocate Functional Components

• 정제된 Functional Component들을 Skeleton Architecture위에 배치하는 단계이다.

• Skeleton Architecture는 Functional Component들을 담는 장소인 Place holder들을 가지고 있어야 한다. i.e. Functionality Place Holder

• Functionality Place Holder는 Layer, Partition in a Layer, Other이 될 수 있다.

• Ex : 제가 참여한 SMS(Smart Mirror System)의 설계중 일부입니다.

  

  Ex. Smart Mirror System

  예제에서는 Client Control Layer와 Server Control Layer를 Place Holder로 사용하였다.

Step 6. Design Functional Components

• 목적

  더 Detail 한 디자인을 위한 단계로, functional Component들의 Type과 Openness를 결정한다.

• Type of functional component

  • Whitebox Component

    • No Component-level API

    • 그냥 그룹의 기능만 하는 정도 : UML Package Diagram

    • Component 안은 Classes/objects들로 이루어져 있다.

      

  • Blackbox Component

    • Fassade type

      • 각각의 객체들을 숨긴 Representative API set

      • API에 50개의 기능이 있을 때, 다 사용 위해서는 50개의 request가 필요하다.

      • Component의 Method 수가 많다.

      • Workflow가 가변적이다.

        

    • Mediator type

      • 각각의 객체들을 숨긴 Representative API set + Workflow automation 제공

      • Workflow는 재사용 가능하며, 자동적이다. (공통)

      • API에 50개의 기능이 있을 때, 한 번의 요청으로 사용 가능

      • 상대적으로 적은 Method 수

        

Step 7. Design Functional Components

• 각각의 Functional Component들의 Interface들을 정의하는 단계이다.

• Interface

  인터페이스는 Functional Component들의 메서드를 부르는 공통적인 Protocol을 의미한다.

  Method들의 추상 집합이라고 생각하면 된다. (a set of Method signatures and descriptions)

  Method signature : Method의 이름, input parameters, output type의 정의

  

  • Provided Interface

    이미 정해진 interface 규칙을 따라야 한다. 여러 방면으로 제공되지 않는다.

    

  • Required Interface

    여러 방식으로 interface를 사용할 수 있다.

    

  • Ex

    

    Ex. InterfaceFace Recognizer Functional Component

  • TODO : Interface 부분 내용 추가해야 함

  • TODO : Table of functional Component Interfacces

    TODO : HAL - Hardware Abstraction Layer

---

기능적인 View에 관한 설계 순서를 정리한 포스팅이었습니다. 다음에는 Informational view인 데이터와 관련된 뷰 설계에 대해 포스팅 하도록 하겠습니다.

2019/12/14 - [IT/SW Architecture] - 소프트웨어를 설계하는 방법 (4) - Design with Information Viewpoint

소프트웨어를 설계하는 방법 (4) - Design with Information Viewpoint