5. System modeling

System modeling이란 시스템에대한 추상화된 모델을 개발하는 프로세스를 말한다. 이러한 모델은 Mathmetical model(Formal model) 또는 Grapical Model(UML) 등으로 표현될 수 잇으며, 시스템을 보는 관점에 따라 다르게 표현되기도 한다. 

Requirement Engineering 단계에서 세부 요구사항을 도출하기 위해 모델이 개발된다. 

1) 요구사항 단계에서 사용되는 이미 존재하는 시스템에 대한 모델

2) 요구사항 단계에서 사용되는 새로운 시스템에 대한 모델

 

시스템을 바라보는 관점에 따라 다른 모델을 개발할 수 있다.

1) External perspective : 시스템의 context 또는 environment에 대한 모델

2) Interaction prespective : 시스템이 외부환경과 상호작용하는 방식, 시스템 내부 컴포넌트의 상호작용 방식에 대한 모델

3) Structural perspective : 시스템이 어떻게 구성되는지 또는 처리되는 데이터 구조에 대한 모델

4) Behavioral perspective : 실행중에 시스템이 이벤트에 어떻게 동적으로 반응하고 행동하는지에 대한 모델

 

UML은 Object-oriented model의 표준언어이다. 시스템의 본질을 표현할수 있는 5가지 diagram은 다음과 같다.

1) Activity diagrams : 시스템 프로세스 또는 데이터 처리와 관련된 활동 표현

2) Use case diagrams : Between System and External Actor(User, Other System)  

3) Sequence diagrams : Between System component and System component/External Actor

4) Class diagrams : 클래스, 클래스간의 연관관계

5) State diagrams : 내외부 이벤트에 따라 시스템이 반응하는 방식

 

5.1 Context models

 

Context model은 다른 시스템들과 연결된 환경을 보여준다. 우리는 요구사항 명세의 초기단계에서 시스템에 어떤 기능, 프로세스 등 을 포함할지 boundary를 결정해야 한다. 만약, 요구사항 중 기존에 존재하는 시스템에서 처리하는게 있다면, 개발하고자 하는 시스템에서 중복해 구현하는 것은 불필요한 일이다. 따라서, 새로운 시스템 중심으로한 기존 시스템들의 관계를 Context model의 형태로서 표현함으로서, 더 명확하게 시스템의 역할을 정의할 수 있다.

간단한 형태의 Context model은 주로 다른 model과 함께 표현된다.

UML Activity diagram은 주로 busniess process를 표현하는 모델이다. Activity diagram의 프로세스 단계에서 외부의 시스템이 어느 순간에 연관되는지 표현하는 방식으로, 다른 모델과 함께 사용된다. 또한, 외부와의 상호작용을 표현하는 Use case diagram과 함께 사용되기도 한다.

 

5.2 Interaction model

 

모든 시스템은 interaction을 포함한다. Interaction에는 크게 3종류가 있다. 

1) System and User, 2) System and External System, 3) Between System components

1, 2번 Interaction은 주로 Use Case Model로, 3번은 주로 Sequence Diagram으로 표현한다.

 

5.2.1 Use Case modeling

Actor(External system/User)과 System의 Interaction은 직선으로 연결된 Use Case인 ellipse 도형을 통해 표현된다.

 

5.2.2 Sequence Diagram

Diagram의 Top에는 System components와 Actor가 존재하며, Top에서부터 Bottom까지 화살표의 흐름에 따라가며 상호작용의 순차적 흐름을 표현한다. 

 

5.3 Structural models

 

Structural model은 시스템이 어떻게 구성되어있고 구성요소간에는 어떤 관계가 있는지를 보여준다.

 

5.3.1 Class diagram

Object-oriented system model을 개발할 때 주로 쓰이며 Class에 대한 정보, Class간의 관계를 보여준다. 

Class에 대한 정보는  name, attributes, operations에 대한 정보들이고, Class간의 관계는 1:N, N:M 과 같은 관계를 보여준다. 

5.3.2 Generalization

Generalization(일반화)는 complexity를 관리하기 위해 사용하는 기술이다. Class들은 공통점을 가지고 일반화된 부모 Class의 형태로 표현될 수 있고, 그러한 구조를 통해 계층적인 일반화구조를 갖도록 모델링할 수 있다. 이와 같은 방식을 통해 상속구조의 Class diagram을 만들 수 있다.

 

5.3.3 Aggregation

하나의 Object는 여러 다른 Object들의 Aggregation을 통해 만들어 질 수 있다. 이것은 정적인 클래스 상속구조에 비해 동적으로 Object의 구조를 변경할 수 있으므로 더 유연하다. 이와 같은 방식을 통해 합성의 구조로 Class diagram을 만들 수 있다.

 

5.4 Behavioral models

 

Behavioral model은 시스템이 실행 중 일때 동적으로 발생하는 행위에 대한 모델이다. 

시스템에 어떠한 stimuli에 대해서 응답할 때 어떤 일이 벌어지는지를 보여준다.

시스템에 가해지는 stimuli에는 크게 2종류가 있다.

1) Data의 이용가능한 상태

2) Event의 발생

 

5.4.1 Data-driven modeling 

Data-driven model에서 Data가 이용가능한 상태가 되었을 때, Input이 들어오고 일련의 처리과정을 거쳐 Output이 생성된다. 이러한 model은 data-flow diagrams(DFDs)을 통해 표현될 수 있다. DFD는 UML에서 Activity diagram(프로세스와 데이터 처리과정 표현) 또는 Sequence diagram(System과 Actor과의 상호작용 표현)으로 표현 될 수 있다.

 

5.4.2 Event-driven modeling

Event-driven model에서 시스템은 유한한 상태를 가지며, Event는 이러한 상태의 전이를 발생시킨다. 

UML에서 State diagram을 통해 표현할 수 있다. Real-time system을 design할 때 주로사용되며, Data-flow가 정의되는 것이 아닌, stimuli에 따라 transition되는 상태의 정의와 그 상태가 되었을 때 어떤 동작을 할지를 표현한다. 

한가지 문제는 대규모 시스템에서는 가능한 State의 수가 빠르게 증가하기 때문에 모델의 복잡도가 증가한다는 것이다. 이 때, 몇가지 상태와 전이를 encapsulate시켜 superstate로 만듦으로서 모델을 더 추상적이고 단순하게 만들 수 있다.

 

5.4.3 Model-driven engineering

Model-driven engineering(MDE)은 개발 프로세스의 최종산물이 program이 아닌 model인 소프트웨어 개발 방법론이다. program은 model로부터 자동적으로 생성된다. MDE는 Model-driven architecture(MDA)의 확장이다. MDA가 단지 소프트웨어의 Design과 Implementation에 초점이 맞추어져 있다면, MDE는 Model-based requirement engineering, Model-based development, Model-based testing 등 소프트웨어 프로세스 전체와 관련되어 있다.

하지만, 많은 회사들이 MDA를 받아들인데 비해, 극소수의 회사만이 MDE를 받아들였다.

 

5.5. Model-driven architecture

 

Model-driven architecture은 UML model을 이용한 소프트웨어 Design과 Implementation 구조이다.

MDA에서는 순서대로 3가지 모델이 생성되며, 추상화수준은 높은 레벨에서 낮은 레벨로 변화한다. 

1) Computation independent model(CIM) : 도메인이 추상화된 모델

2) Platform independent model(PIM) : 시스템의 Operation이 정해진 모델

3) Platform-specific model(PSM) : Platform에 종속적인 모델

CIM -> PIM -> PSM으로 변환되는 과정은 자동화된 툴을 통해 이루어되며 최종적으로 PSM은 실행가능한 코드로 변환된다. 하지만, 아직 완전한 변환의 수행은 거의 불가능하며 추상화수준이 높을 수록 변환작업은 어려워진다.

Java와 같은 몇멏 Platform의 경우 PSM -> 실행가능한 코드 와 같은 변환하는 툴을 제공하고 있다. 하지만, 많은 회사들이 이러한 툴을 별도로 개발하기를 꺼려하는 것은 MDA가 주류가 되지못한 하나의 원인이었다.

실제로 복잡한 시스템의 개발에서 주요문제는 Implementation이 아닌 Legacy와의 통합, Requirement engineering 등 에 있기 때문에, 실제로 소프트웨어와 하드웨어를 함께 포함하는 System Product를 생산하는 기업을 제외하고서는 MDA를 적용하기를 꺼려했다.