Software Analysis and Design - Functional and Data Component

0. Component

Component란 무엇인가? Component란 target system을 구성하는 cohesive unit(응집 단위)이다. Component가 나타내는 것에 따라서 우리는 Component를 Functional component와 Data component로 나눌 수 있다. 각 Component가 무엇을 의미하고 어떻게 얻을 수 있는지에 대해서 알아보자.

 

1. Functional component

1-1. Functional component란?

functional component는 target system에 특정 기능을 제공하는 cohesive unit이다. 예를 들어, Car rental management system에서 유저의 데이터를 관리하는 functionality인 User profile 등이 존재할 것이다.

1-2. Functional component 도출 방법

이 Functionality를 어떻게 하면 얻을 수 있을까? Usecase diagram에서 연관된 Use case끼리 묶어 만들 수 있다. 이때, n개의 usecase와 m개의 functional component가 존재한다고 가정하면 m << n의 관계를 갖는다. 즉, m(functional component)가 n(usecase diagram)보다 큰 영역이다. 이렇게 연관된 usecase를 묶어 component를 표현한 후, 이름을 붙인다. 각 component의 이름은 명사 형태(user manager등)로 설정해야 한다. 이렇게 usecase 그룹화 하여 component를 나타냈다면, 이 functional component와 use cases를 table로 나타내어 visualize함으로서 쉽게 이해가능하게 나타낼 수 있다. 이로써 Functional component 도출을 할 수 있다.

1-3. Functional component를 활용한 class implementation

마무리로 java등과 같은 OOP에서 하나의 functional component는 하나의 class로 implement할 수 있는데, 그 방법에 대해서 알아보자. 구현될 class는 composite class일것이고, functional component를 구현하는 usecases들은 composite class내의 public method가 될 것이다.  class로 구현이 끝났다면 이제 functional component들을 control layer에 allocate한다. (control layer? : MVC Architecture Design에서 모든 functional component를 보관하는 layer! 나중에 더 자세히 알아보자)

1-4. UML에서 어떻게 Component를 나타내는가

UML에서 Component는 잘 정의된 interface 모듈로 표현하며, Self-contained unit이다. 이는 시스템의 Physical하고, Replaceable한 일부이다. UML에서 이를 <<component>>키워드 사용하여 표현한다.

그렇다면 Component를 표현하기 위해서 어떻게 Interface를 정의해야할 지 알아야 한다. Interface는 UML에서 <<interface>>키워드로 정의되어 있고, 이는 class나 component의 protocol을 명시하는 역할을 한다. 여기서 Protocol이란 method의 signatures, method의 functional description 등, skeleton을 정의한다라고 이해하면 된다. 그저 description 이므로, attribute를 갖지 않는다(정확히 말하면, java에선 static값이나 final attribute는 허용됨). 이렇게 정의된 interface를 extend하며 확장하여 큰 interface를 만든다. 그리고 이처럼 정의된 interface를 바탕으로 class는 interface를 realize(실사화)한다. UML에서 이 realization을 다음과 같이 표현한다.

 

1-5. Provided interface와 Required interface

여기서 class나 component가 구현한 service나 functionality가 명시된 Interface 즉, realize할 때 사용되었던 interface를 provided interface라고 한다. Interface를 realize한 class들을 포함하는 다른 class들은 realize한 class에 직접 접근하는 것이 아닌, 이 provided interface를 통해 접근하게 된다.

Provided interface는 interface를 realize한 class에 대한 관점이었다. 이제, 그 class를 접근하는 다른 class(즉, 위 그림에서 보자면 other class)들의 관점에서 보자. Required interface는 현재 class나 component에서 필요로 하는 external services를 의미한다. External service를 사용하는 class들(아래에서 Theft Alarm)는 정상적으로 작동하기 위해서 다른 class(아래에서 Proximity Sensor)의 Interface(아래에서 iSensor)의 구현을 필요로 한다 . 외부 classes가 proximity sensor를 이용하고자 할 때 iSensor를 통해 접근하므로, 외부 Class의 관점에서 iSensor를 Required interface라고 한다.

다음은 이에 대한 전체적인 청사진이다.

 

2. Data component

2-1. Data component란?

Data component는 component의 persisten dataset(영구 데이터셋)을 관리하는 cohesive unit으로, 잘 정의된 related class의 집합이다.  예를 들어 Rental에는 Payment, Rental incident, Return care등의 class가 속할 것이다. 

 

2-2. Data component 도출 방법

Data component가 잘 정의된 related class의 집합이라고 하였다. 따라서 연관된 class를 묶으면 data component가 된다. 여기서 class간의 연관성(relationship)의 strength를 다시한번 리마인드해보자.

이러한 relationship의 stregnth를 고려하여 묶으면 된다. 이제 이렇게 묶은 것을 구현하고, Model Layer에 allocate한다.