Modeling이란

1. 들어가면서

 

아래 2개의 그림이 있는데, 공통점이 뭘까요?

 

둘다 개집입니다. 이렇게 이야기하면 틀린 답이겠죠. 하나는 진짜 개집이고 하나는 개모양의 집입니다. 두 집을 짓는다고 생각할 때 어느 집을 짓는 것이 어려울 까요? 당연히 오른쪽의 집을 짓는 것이 복잡하겠죠. 왼쪽의 개집은 설계도면도 없이 지을 수 있지만, 오른쪽의 집은 그럴 수가 없겠죠? 오른쪽의 집을 짓기 위해서는 설계도면이 반드시 필요하리라 생각합니다. 그리고 아마 설계하기 전에 집주인이 요구하는 요구사항까지도 잘 듣고 이해해야 할 것입니다. 소프트웨어시스템을 개발할 때도 마찬가지라고 생각합니다.

 

2.  Model의 정의

 

아파트 개발 전에 우리는 모델하우스를 보고 지워질 아파트를 미리 알 수 있습니다. 시스템을 개발할 때도 이와 마찬가지로 시스템의 모델을 설계합니다.

 

Open System의 Model

왼쪽의 그림은 이러한 시스템을 표현하는 하나의 모델입니다. 보통 우리가 다루는 시스템들을 오픈시스템이라고 합니다. 오픈시스템은 외부 환경과 상호작용하여 외부환경으로 부터 자극을 입력받고 뭔가를 처리하여 반응을 출력합니다. 이러한 입출력은 시스템의 범위를 결정합니다. 오른쪽의 그림은 왼쪽의 오픈시스템을 그래픽 언어로 표현한 것입니다. 하얀 사각형이 시스템을 의미하고 파란 사각형들이 외부에 존재하는 객체를 의미합니다. 이들을 연결하는 화살표는 방향에 따라 외부객체와 시스템 간의 인터페이스를 의미합니다.

시스템은 하나의 모델로는 표현하기가 어렵습니다. 시스템을 표현하기 위해서는 다양한 형태의 모델로 표현됩니다. 모델은 "어떤 객체, 사람 또는 시스템의 특정한 정보를 담고 있는 표현"이라고 할 수 있습니다.

 

3. Physical vs. Logical Model

 

시스템의 모델 관점에서 구분해서 이해해야 할 2가지의 모델 개념이 있습니다. 그것은 Physical model과 logical model의 개념입니다. 시스템의 physical model은 현재 구현되어 있거나 기술적으로 구현하고자 하는 모델이고, logical model은 시스템이 개념적으로 갖고 있는 필수 기능들로 구성된 모델을 의미합니다.

이를 예로 들어 설명한 그림이 아래 보시는 두개의 다이어그램입니다.

 

주문처리시스템의 Physcial model과 Logical model의 비교

두 다이어그램은 주문처리시스템이라는 하나의 시스템을  2가지 모델 관점에서 표현하고 있습니다. 보통 Data flow diagram이라고 합니다. 다이어그램의 원은 어떤 일을 처리하는 프로세스를 의미하고, 사각형은 시스템 외부에 존재하는 환경, 즉 외부 시스템을 의미합니다.

왼쪽의 physical model은 주문처리를 수행하는 sales office와 같은 조직과 컴퓨터 등으로 프로세스가 표현되어 있습니다. 즉 주문처리시스템이 구현되어 있거나 설계하고자 하는 물리적인 컴포넌트들로 표현되어 있습니다.

오른쪽의 모델은 주문처리시스템에서 수행해야 할 기능으로 프로세스를 표현하고 있습니다. physical model과 달리 특정 구현방법과 무관한 논리적인 모델로 표현되어 있습니다.

다시 말해 Physical model은 기술로 구현되어 있는 모델로서 주로 설계 이후의 시스템 모델들을 의미합니다. Logical model은 기술을 고려하지 않은 모델로서 주로 분석단계에서의 표현하는 시스템 모델을 의미합니다.

 

4. Static vs. Behavior Model

 

시스템 모델을 표현하는 또 다른 2가지의 관점이 static model과 behavior model입니다. Behavior model은 static model과 대비하여 dynamic model, execution model 이라고 부르기도 합니다.

Static model은 시스템을 구성하는 컴포넌트들의 구조를 표현 할 때 사용합니다. Behavior model은 시스템이 어떻게 동작하는 가를 표현할 때 사용합니다.

 

아래 두개의 다이어그램이 있는데, 왼쪽은 시스템을 구성하는 컴포넌트인 클래스와 그들의 관계를 표현하는 클래스 다이어그램이라고 하는데,  바로 시스템의 static model을 표현하고 있습니다.

오른쪽은 이 클래스들이 어떤 특정 이벤트가 발생하여 이를 어떻게 처리하는 가를 표현하는 sequence diagram이라고 하는데, 시스템의 behavior model을 표현하고 있습니다.

 

class diagram(Static model) vs. Sequence diagram(Behavior model)

 

5. Software System Modeling

 

Software 개발의 최종 결과물은 아래 보시는 가장 왼쪽과 같은 프로그램 코드일 것입니다.

 

software system의 프로그램과 이의 특징을 표현하는 model들

Super programmer 혼자 시스템을 개발하거나 규모가 그리 크지 않을 때는 software의 모델을 별도로 만들 필요가 없을 수 있습니다. 또한 프로젝트의 참여자가 모두 프로그램 개발자이면 가능할 수도 있습니다.

그러나 규모가 큰 시스템의 경우는 참여자들이 다양한 이해관계자로 구성되고, 신뢰성과 복잡성이 있는 시스템의 개발은 프로그램 코드를 개발하는 것 만으로는 거의 불가능한 경우가 있습니다.

모델링은 시스템의 모델들을 만들어서 최종적으로 구현될 프로그램 코드를 만들어 내는 과정이라 할 수 있습니다. 따라서 코딩이 최종 목적이기는 하지만  소프트웨어 시스템의 개발을 위해서는 모델링 과정이 필요합니다. 따라서 모델링은 코딩을 제외한 시스템을 분석하고 설계하는 행위를 모델링이라고 할 수 있습니다.

가운데 2개의 다이어그램은 시스템 설계의 결과물인 설계 모델로서 하나는 시스템의 구조를 표현한 static model이고,  밑에 다이어그램은 시스템의 동작을 나타내는 behavior model을 표현하고 있습니다. 오른쪽에 있는 다이어그램은 시스템의 분석모델로서 시스템이 수행할 기능을 나타내는 behavior model을 표현하고 있습니다.

 

6. UML (Unified Modeling Language)

 

시스템의 이러한 다양한 모델을 표현하기 위한 도구가 UML입니다. UML은 unified modeling language의 약자로서 Object Management Group이라는 비영리 표준화 단체에서 소프트웨어 시스템의 모델을 표현하기 위해서 제정한 표준 모델링 언어입니다.

총 11개의 다이어그램으로 구성되어 있으며, 시스템의 다양한 static model과 behavior model들을 표현하고 있습니다.

 

UML도구인 Sparx사의 Enterprise Architect에서의 UML diagram의 ㅖ

 

특히 UML은 stereotype 같은 언어를 확장하는 개념을 갖고 있어 내가 표현하고자 하는 다양한 모델을 표현할 수 있습니다. 설명하고자 하는 개발방법론에서는 주로 class diagram, state diagram, use-case diagram, sequence diagram, component diagram 정도 사용하게 됩니다.

특히 시스템 분석가나 software architect를 꿈꾸시는 분은 부산대 채흥석 교수님이나 동국대 최은만 교수님이 저술한 UML 관련 책을 별도로 보시기를 권장합니다.

 

7. SysML (System Modeling Language)

 

SysML은 시스템엔지니어링그룹인 INCOSE와 함께 OMG에서 제정한 모델링언어로서 소프트웨어 시스템 뿐만 아니라 일반적인 시스템 개발에 필요한 추가적인 diagram을 정의하고 있습니다.

UML의 일부 다이어그램과 아래와 같은 requirement diagram, class diagram들을 확장한 block diagram과 같은 추가적인 diagram으로 구성되어 있습니다.

 

 

8. UAF(Unified Architecture Framework)

 

UAF는 Enterprise Architecture 또는 Systems-of-Systems 의 대규모 시스템을 모델링하기 위한 도구입니다. 물론 시스템의 규모에 따라 SysML과 UML로 모델링이 가능하기는 하지만, 대규모의 조직의 업무를 시스템화하거나 단일의 대규모의 시트템을 모델링 하기에는 한계가 존재합니다.

 

UAF는 기존의 Enterprise Architecture Framework들을 통합하여 OMG에서 표준화한 모델링 도구라고 할 수 있습니다. 따라서 UAF modeling language는 SysML을 확장한 다양한 스테레오타입을 활용하여 정의되었습니다. UAF 자체는 약간의 방법론을 포함하여 모델의 종류만이 아니라 이를 활용하는 사용자의 도메인에 따라 다양한 모델을 제공합니다. (이를 UAF grid라고 합니다.)

 

UAF V1.2 domain vs. model kinds Grid