시스템 모델

모델은 개선이 필요한 기존의 시스템을 명확히 이해하기 위해 요구 분석단계에서 사용하거나 새롭게 요구되는 시스템을 명세하는데 사용된다. 모델은 아래와 같은 다양한 관점으로 표현 가능하다.

1. 외부적 관점(external perspective) : 시스템의 문맥이나 환경에 대한 모델링
2. 행동적 관점(behavioral perspective) : 시스템의 동적인 면에 대한 모델링
3. 구조적 관점(structural perspective) : 시스템의 아키텍쳐(architecture)나 처리되는 데이터의 구조 부분에 대한 모델링

이러한 다양한 관점을 모델링하는 대표적인 방법중 하나가 UML(Unified Modeling Language)를 이용하는 것이다.

1. 모델의 종류
1) 배경 모델(Context Model)
① 요구사항 수집이나 분석 단계에서 시스템의 범위(boundary)를 정한다.
② 사회 또는 조직의 영향력에 의해 시스템의 범위가 영향을 받는 경우도 있다.
③ 아키텍쳐 모델(Architectural model)은 시스템(system)과 다른 시스템들간의 관계(relationship)를 보여준다.
④ 고수준(high-level)의 아키텍쳐 모델은 블록(block) 다이어그램으로 표현되는 경우가 많으며, 각각의 서브 시스템(sub-system)은 이름이 표기된 사각형으로 표현하고 관계가 있는 것들끼리 선으로 연결한다.

※ 시스템의 전체적인 그림을 통해 초기에 범위를 정하는 것은 분석에 필요한 시스템 비용과 시간을 한정짓기 위해서 중요하다.

p.151 Figure 7.1 The context of the ATM system

2) 행동적 모델(Behavioral model)
(1) 시스템의 전반적 행위에 대해 표현하는데 필요하다.
(2) 행동적 모델의 2 가지 종류
대부분의 비즈니스 시스템은 데이터 처리위주라 시스템 행위를 표현하는데 DFD 로 충분하나, 실시간 시스템에서는 데이터 처리부분이 적고 이벤트 중심이다. 시스템 유형에 따라 결정해야 한다.

① 데이터 흐름 모델 (Data-flow model)
+ DFD(Data flow diagrams)가 시스템의 데이터 처리를 모델링하는데 주로 사용된다. +
+  데이터가 시스템을 따라 흐르면서 발생하는 단계적 처리를 보여준다.
+  시스템간의 데이터의 교환뿐 아니라 외부 시스템과의 교환 정보도 보여준다.
 

p. 154 Figure 7.3 Data-flow diagram of order processing (주문처리를 DFD 로 나타낸 그림)

② 상태머신 모델(State machine model)
+ 내부 또는 외부의 이벤트(events)에 대한 시스템의 행동(behavior)를 모델링한다.
+ 특히 실시간 시스템(real-time system)을 모델링 하는데 많이 사용한다.
+ 시스템의 상태(states)는 노드(nodes)로 표시하고, 이벤트(events)는 화살표(arc)로 표현한다. 특정 이벤트가 발생할 경우 시스템은 상태를 바꾸게 된다.
+ 상태도(statechart)는 UML 의 주요 다이어그램 중 하나이다.

p.155 Figure 7.5 State machine model of a simple microwave oven (전자렌지를 상태머신 모델(State machine model)로 나타낸 그림)

 
<전자렌지 상태 설명>

상태	설명
Waiting	전자렌지가 입력을 기다리고 있으며, 현재 시각을 보여준다.
Half power	전자렌지의 전력이 300 와트로 지정되었으며, "Half power"라는 표시를 보여준다.
Full power	전자렌지의 전력이 600 와트로 지정되었으며, "Full power"라는 표시를 보여준다.
Set time	요리시간이 사용자가 입력한 값으로 지정되었으며, 선택된 요리시간을 표시한다.
Disabled	안전(safety)을 위해 전자렌지가 동작하지 않으며, 내부 조명이 켜지며, “ Not ready"라는 표시를 보여준다.
Enabled	전자렌지 조작이 가능한 상태이며, 내부 조명이 꺼진다. "Ready to cook" 표시를 보여준다.
Operation	전자렌지가 동작중이다. 내부 조명이 켜지며, 시간에 대한 카운트다운(count down)을 보여준다. 요리가 완료되면, 5 초 동안 벨이 울리며, “ Cooking complete" 표시를 보여주게 된다.

3) 데이터 모델(Data models)
(1) 시스템이 처리하는 데이터의 논리적 구조를 보여준다.
(2) 대표적인 데이터 모델링 기술에는 ERA(Entity-relation-attribute)모델링이 있으며, 이는 데이터 엔티티 및 관련한 속성, 엔티티간의 관계를 보여준다.
(3) 주로, 데이터베이스 모델링에 사용된다.

 

※ UML 은 객체지향개발 프로세스를 위한 것으로 이러한 종류의 데이터 모델링은 다루지 않는다. 대신, 클래스 모델을 통해 객체들 간의 관계 및 속성, 오퍼레이션들을 파악하기 위한 모델링 기법을 사용한다.

p.159 Figure 7.8 Semantic data model of a software design

 

(4) 데이터 사전(Data dictionary)
① 시스템 모델에서 사용되는 모든 이름(name)에 대한 리스트(list)이며, 엔티티(entities), 관계(relationships) 및 속성(attributes)에 대한 자세한 설명이 포함되어 있다.
② 이름을 관리할 수 있기 때문에 중복(duplication)을 피할 수 있다.
③ 분석, 설계 및 구현을 연관지울 수 있는 통합 정보의 저장소 기능을 한다.
④ 대부분의 CASE 워크벤치(workbenches)가 데이터 사전(data dictionary)를 지원한다.

p.160 Figure7.9 Examples of data dictionary entries

4) 객체 모델(Object models)
① 특히 상호작용적(interactive) 시스템 개발에 널리 사용된다.
② 실세계를 묘사하기 적합한 모델이다.
③ 도메인 엔티티를 반영하는 객체 클래스는 재사용이 쉽다.
※ 구체적 엔터티(car, book 등)가 아닌 경우는 모델링이 어렵다.
※ 응용 도메인의 이해없이는 객체모델을 이해하기 힘들며 DFD 로 보충할 수 있다.
④ 객체의 특성을 이용한 다양한 모델이 만들어질 수 있다.
+ 상속 모델(Inheritance models)
+ 집합연관 모델(Aggregation models)
+ 상호작용 모델(Interaction models)
※ 객체 모델을 보여주는 다이어그램은 UML 부분의 설명을 참고하세요.
 

2. UML(Unified Modeling Language)
들어가기
1) 모델(Model)
분할(Decomposition), 통합(Integration), 추상화(Abstraction), 계층(Hierarchy) 등의 개념을 이용하여 복잡한 실제 대상을 간단하게 표현한 것

2) 표현하는 방법
초기 시스템 연구자들은 이러한 모델을 자연어(Natural Language)를 이용하여 표현하였는데, 시스템을 명세하는데 다음과 같은 문제점이 있었습니다.

① 모호성(Lack of clarity - Ambiguity) : 한가지 표현이 여러 가지 뜻을 담고 있는 경우가 있다.
② 요구사항 혼합(Requirements amalgamation) : 한 문장의 요구사항이 실제로는 여러 개의 요구사항을 복합적으로 가지고 있는 경우가 있다.
③ 과도한 유연성(Over-flexibility) : 동일한 의미를 표현하는 다양한 방법이 존재한다.
④ 모듈화 어려움(Lack of modularization) : 정형적으로 모듈화가 어렵다.

위와 같은 이유로 시스템 언어(System language)를 사용하며 UML 도 시스템 언어의 한 종류입니다.
 

1) UML 의 역사

(1) UML 의 태동

1970 년 중반 ~ 1980 년 후반	객체지향 모델링 언어 등장하기 시작 (5~10 개 정도 존재)
1989 년~1994 년	· 1970 년 중반~1980 년 후반 -   객체지향 모델링 언어 등장하기 시작 (5~10개 정도 존재)   · 1989년~1994년 -     “ 방법론의 전쟁시대(Method wars)” (50개 이상) -   대표적인 방법론 : ① Booch : Booch, Booch'93 → 설계, 구성 단계, 공학관련 응용에 적합 ② Rumbaugh : OMT(Object Modeling Technique), OMT-2 → 분석 단계 및 데이터 정보 시스템에 적합 ③ Jacobson : OOSE(Object-Oriented Software Engineering) → 쓰임새(Use case) 중심 접근법, 비즈니스 모델링 및 요구사항 분석에 용이 -   서로의 장단점을 분석하여 취합하기 시작하였음.

(2) 객체지향방법론 삼인방(Three Amigo's) 의 결합

1994 년 10 월	· Jim Rumbaugh(OMT)가 Grady Booch(Booch)에 합세하여, Rational Software Corporation 에 들어옴.
1995 년 10 월	· UML 0.8 발표
1995 년 가을	· Ivar Jacobson (Objectory company)이 Rational 사에 합세함.
1996 년 6 월	,·    UML 0.9 발표 , 이 버전부터 일반인들의 피드백(feedback)을 받기 시작했음.
1997 년 1 월	· UML 1.0 발표 (UML Partners)
1997 년 9 월	· UML 1.1 발표
1997 년 11 월	· UML 1.1 : OMG 에서 표준으로 공식 채택

2) UML 이란 무엇인가?
소프트웨어 시스템(Software system)의 요소들(artifacts)을 명세화(Specifying), 시각화(Visualizaing), 구조화(Constructing), 문서화(Documenting)하는 언어(language)이다.

3) UML 의 구성요소(UML Building Blocks)
(1) 사물(Things)
① 구조사물(Structural Things)

[ UML_structural ]

클래스(class) : 객체지향모델에서의 실제 클래스를 시각적으로 표현한 것으로 이름, 속성, 오퍼레이션을 차례로 적어준다. 구현에 대한 내용은 오지 않는다.

인터페이스(interface) : 스테레오타입(stereotype)으로 <<interface>>를 가지는 클래스의 특수한 형태로 원형 아이콘으로 표기한다.

쓰임새(use case) : 시스템이 수행하는 순차적 활동을 기술해준다. 특정 어플리케이션 프로그램의 상위 메뉴 구분과 비슷하다.

컴포넌트(component) : 시스템의 물리적이고 대체 가능한 부분으로, DLL 이나 EXE 와 같은 물리적 단위에 해당한다.
노드(node) : 실행시에 존재하는 실제 전산자원을 의미하며, 대부분의 경우 자체적인 메모리와 처리 능력을 가진 시스템을 의미한다.  

② 행동사물(Behavioral Things)

[UML_behavioral ]

교류(interaction) : 객체들 간에 주고받는 메시지 상태머신(state machine) : 상태의 순서를 지정하는 행동

③ 그룹사물(Grouping Things)

[UML_grouping ]

패키지(package) : 요소들을 묶어준다. 구조사물, 행동사물을 포함한 다른 그룹사물까지도 포함할 수 있다. 컴포넌트가 물리적인 것임에 비해 패키지는 개념적이다.

④ 주해사물(Annotational Things)

[UML_annotational ]

노트(note) : UML 모델의 주석에 해당하는 것으로, 점선으로 노트와 설명할 대상을 연결한다.
 
(2) 관계(Relationships)
① 의존(Dependency)

한쪽 사물의 변화가 다른 사물에 영향을 줄 수 있는 관계일때 사용한다. 만약 A->B 인 경우 B 의 변화가 A 에게 영향을 미치는 것이다. 보다 상세한 정보를 전달하기 위해 라벨(label)을 넣는 경우도 있다.

② 연관(Association)

구조적 관계로서, 객체들간의 연결이 있는 경우를 나타낸다.

 

특별한 경우로 aggregation 은 실선의 한쪽 끝에 마름모를 표시한 것으로 전체와 부분간의 구조적 관계를 나타낸다. 이와 비슷한 것으로 composition 은 마름모 내부를 채워서 표시하며, 물리적 포함관계를 의미한다.

③ 일반화(generalization)

특수화(specialization)/일반화(generalization) 관계로서, 부모(parent)/자식(child)관계에 해당한다. 즉, 상속(inheritance)과 같은 개념이다. 화살표를 받는 쪽이 부모가 된다.

④ 실체화(realization)

인터페이스와 그것을 실제로 구현하는 클래스와의 관계로 화살표를 받는 쪽이 인터페이스가 된다. 쓰임새(use case)를 실체화하는 경우에도 사용한다.

(3) 다이어그램(Diagram)
① Use case diagram

 

쓰임새(use case)와 행위자(actor)들의 관계를 나타낸다.

② Class diagram

클래스 , 인터페이스 및 그들간의 정적인 관계를 표현하며, 시스템 모델링에서 가장 공통적인 다이어그램이다.

③ Behavior diagrams
 Statechart diagram

시스템의 동적인 뷰를 다루며, 객체 행동에 초점이 맞추어져 있기 때문에 실시간 시스템을 모델링할 때 특히 유용하다.

 Activity diagram

시스템 내부에 있는 활동간의 흐름을 나타낸다.
 

□ Interaction diagrams
객체와 그들간의 관계 및 그들 사이에서의 메시지를 표현하는 것으로, sequence 다이어그램은 시간흐름에 따른 메시지 뷰(view)를 보여주고, collaboration 다이어그램은 특정 객체의 메시지를 쉽게 확인할 수 게 해준다.

Sequence diagram

Collaboration diagram

□  Implementation diagrams 

Component diagram

컴포넌트간의 구성과 의존관계를 나타냄


Deployment diagram

실행시 처리하는 노드와 그 노드에 있는 컴포넌트들의 구성을 나타냄
 

4) 프로젝트가 성공하기 위한 조건
UML 은 표기법일 뿐이다. UML 만 안다고 해서 시스템 설계를 성공적으로 할 수 있는 것이 아니다.

① 표기법(Notation)
프로젝트를 수행하는 사람들 또는 외부 관련자들과 의사소통을 하기 위해서 필수적이다.

② 프로세스(Process)
표기법을 언제, 어디서, 어떻게 사용해야 하는지에 대한 것을 알아야한다.

③ 도구(Tool)
표기법에 따른 작업을 수작업으로 해서는 성공하기 어렵다. 이를 지원하는 적절한 도구가 필요하다.


[ 정리하기 ]

1. 요약정리
■ 환경적 모델(Context model)은 환경에서의 시스템의 위치와 다른 시스템들간의 관계 및 프로세스에 대하 보여준다.
■ 데이터 흐름 모델(Data flow models)는 시스템의 데이터 처리를 모델링하는데 사용된다.
■ 상태 머신 모델(State machine models)는 내부 또는 외부 이벤트에 대한 시스템의 행위를 모델링하는 것이다.
■ 객체 모델은 논리적인 시스템의 엔티티와 분류 및 포함관계를 보여준다.
■ UML(Unified Modeling Language)는 소프트웨어 시스템(Software system)의 요소들(artifacts)을 명세화(Specifying), 시각화(Visualizaing), 구조화(Constructing), 문서화(Documenting)하는 언어(language)이다.

2. 참고자료
OMG 의 UML 사이트 http://www.uml.org