UML[2/4]

UML 강좌 #2. (ver 0.1)

                                                        

 

 

 

                                                      Written by 심 원도

1998년 2월 1일

                                                                                      copyright  Plasticsoftware. Co.

                                                                                      www.plasticsoftware.com

 

앞의 강좌에서 우리는 UML의 정의와 전반적인 면을 살펴보았습니다. 이번에는 시스템의 정적인 면을 설계할 때 사용하는 Static Structure Diagram에 관하여 알아보도록 하겠습니다. 시스템의 정적인 설계는 시스템의 분석과 설계초기에 먼저 기술 되어야 하는 부분이므로 가장 중요한 부분이라 감히 말 할 수 있을 것입니다. 또한 시스템의 전체 설계시 실제로 가장 많이 사용되는 부분이기도 합니다.

 

1.       Static Structure Diagram

 

Static Structure Diagram은 시스템의 정적 구조를 기술하는 다이어그램 전반을 지칭하며 내부에 class, interface, relationship등의 여러가지 요소로 구성되어있다. 이러한 내부의 요소에 관해 표기법과 그 의미를 알아봄으로써 Static Structure Diagram의 전체적인 이해를 도울 수 있을 것이다.

 

2.       Class

 

n         Notation

 

클래스의 표기는 위 그림과 같다. 직사각형 안에 영역을 세부분으로 나누고 가장 윗 부분은 클래스의 이름, 중간 부분은 attribute들을, 하단 부분은 operation들을 기입한다. 여기서 attribute부분과 operation부분은 생략이 가능하다. 결과적으로 다음의 그림과 같은 형태도 가능하다.

 

 

n         Semantics

 

클래스는 객체의 type을 나타내며 객체가 가져야 할 정보와 행위를 담고 있다. 클래스들사이의 relationship과 함께 클래스 다이어그램을 이루는 중요한 요소이다.

 

n         Attributes

 

Prototype : visibility name : type-expression = initial-value

위의 prototype과 같은 형태로 attribute는 클래스의 인스턴스인 객체가 가져야 할 정보를 나타낸다. 여기서 initial-value부분은 생략이 가능하다. 단 class가 아닌 interface의 표기에서 attribute의 initial-value는 반드시 나타나야 한다.

 

n         Operations

 

Prototype : visibility name (parameter-list) : return-type-expression

Operation은 클래스의 인스턴스인 객체의 행위를 나타내고 위의 형태로 표기된다.

 

n         Visibility

 

Visibility는 클래스 멤버의 접근(access) 범위를 나타내는 요소이다. 접근의 허용은 크게 세가지로 private, public, protected로 나뉜다. Visibility의 표기는 위 operation과 attribute의 prototype에 나타나는 것과 같이 member의 앞에 표기를 한다.

 

-  : private member를 나타내고, 클래스 member 내의 operation만이 접근할 수 있다.

#  : protected member를 나타내고, 클래스 member뿐만 아니라 클래스를 상속받은 subclass에서도 member의 접근이 가능하다.

+  : public member를 나타내고, 어느 곳에서나 이 member의 접근이 허용된다.

 

n         Example

 

 

Class의 예로 위 그림에서는 Toolbar의 예를 들고 있다. attribute로 currentSelection과 toolCount 가  protected member로 정의되어 있다. 그리고 operation들이 각각의 특성에 맞게 visibility가 나타나있다.

 

3.       Relationships

 

당신은 집을 지을 때 문과 창문, 캐비닛, 그리고 조명과 같은  여러가지 내부 구조물을 생각하게 된다. 이러한 것들은 각각 독립적으로 존재하지만 창문과 문이 벽에 붙어있어야 되고 조명이 천장에 있어야 하는 것처럼 서로서로 연관성을 가지고 있다. 이 처럼 각각의 구조물을 클래스와 인터페이스 등등으로 비유한다면 그것들의 연관성이 바로 지금 말하고자 하는 Relationship이다.

Relationship에는 크게 Dependency, Associations, Generalization, Refinment으로 나뉘어지는데 여기서 Association내부에 Composition,  Aggregation의 큰 주제로 나뉘어 진다.

 

1)        Association

 

n        
Notation

 

Association의 표기는 위 그림과 같이 클래스 사이를 실선으로 표기한다.

Association은 연결된 클래스 사이의 관계를 나타낼 수 있는 이름을 가질 수 있고 또한 클래스는 관계에서 적합한 이름으로 role name으로 나타내어질 수 있다.

 

n         Semantics

 

Association은 하나의 객체와 다른 객체들 사이가 관련되어있을 때  그 특징을 구체화하기 위해 사용된다.

 

n        
Example

 

 

위 그림의 예에서 보는 바와 같이 person은 company내에서 일을 하게된다. 이와 같이 company는 person과 관련이 있고 이것을 나타내기 위해 association relationship을 사용하였다. Relationship이름으로 ‘works for’로 나타내었고 이에 해당하는 각 클래스의 역할로 employee와 employer를 사용하였다. 연결상태에서 다중의 연결이 가능한 관계일 경우 위 그림처럼 ‘1..*’나 ‘*’등으로 다중의 표시를 하게 된다.

 

2)        Aggregation

 

n         Notation

 

 

위 그림과 같이 aggregation은 다이아몬드 머리를 가진 실선으로 표기한다. 이 외의 표기규칙은 association과 같다.

 

n         Semantics

 

Aggregation은 association의 일종이다. Association중 전체와 부분의 관계를 표시하기 위해서 Aggregation relationship을 사용한다.  예를 들어 회사와 업무부서의 관계일 경우 업무부서는 회사의 부분이 되고 회사는 업무부서의 전체가 된다.

 

n         Example

 

회사와 업무부서의 관계를 표시하기 위해 aggregation relationship을 사용하였다.

여기서 다이아몬드 도형이 나가는 쪽이 부분이 되고 다이아몬드 도형이 들어가는 쪽이 전체가 되도록 표기한다. 그외에 나머지 표기는 association과 같다.

 

3)        Composition

 

n         Notation

 

 

Composition의 표기는 위 그림과 같이 속인 찬 다이아몬드 도형을 머리로 하는 실선으로 표시한다.

 

n         Semantics

 

Composition은 aggregation의 한 형태이다. 단순한 aggregation의 경우 부분이 여러 개의 전체에 의해 공유될 수 있는 반면에 composition의 경우 전체에 대해 부분이 강한 소속감을 가지고 동일한 생명기간을 가질 때를 나타내다.

 

n        
Example

 

위 그림의 예에서 보는 바와 같이 윈도우 시스템에서 하나의 프레임은 하나의 윈도우에 속하게 된다. 이처럼 반드시 하나의 윈도우에 소속되고 그 윈도우와 생명을 같이 하게 되므로 이 경우 composition으로 나타낸다. 여기서 다이아몬드 도형의 머리가 나가는 쪽이 부분이 되고 들어가는 쪽이 전체가 된다. 그 외에 표기법은 aggregation과 같다.

 

4)        Refinment

 

n        
Notation

 

Refinment의 표기는 삼각형 점선 화살표로 표기를 한다.

 

n         Semantics

 

Refinment relationship은 동일한 것에 대하여 다른 추상화 레벨들에서 기술할 때 나타난다.

 

n        
Example

 

위 그림의 예에서 보는 바와 같이 analysis 추상화 레벨과 design추상화 레벨에서의 다른 기술을 보일 때 refinment relationship을 사용한다.

 

5)        Generalization

 

n        
Notation

 

Generalization의 표기는 삼가형 실선 화살표로 한다.

 

n         Semantics

 

Generalization은 일반적인(general) 것과 이 일반적인 것에서 특화된(specific) 것 사이의 관계를 나타낼 때 사용한다. 객체 지향 언어에서 흔히 볼 수 있는 상속(inheritance)의 의미와 동일하다. 상속의 시점에서 볼 때 일반적인 것은 parent 가 되고 특화된 것은 child가 되는 것이다. 그러므로 특화된 것은 일반적인 것의 모든 attribute와 operation을 가지게 된다.

 

n         Example

 

 

위 그림의 예에서 볼수 있듯이 shape에서 더 특화된 rectangle, circle, polygon이 있고 rectangle에서 더 특화된 square 있다. shape의 모든 attribute와 operation은 rectangle, circle, polygon이 가지고 있고 각기 자기만의 정보를 attribute와 operation으로 개별적으로 가지고 있다.

화살표 방향의 표기에 있어서 일반적인 클래스로 화살표가 들어가고 특화된 쪽에서 화살표가 나오게 표기함을 알수 있다.

 

6)        Dependency

 

n         Notation

 

 

Dependency의 표기는 점선 화살표로 표기한다.

 

n         Semantics

 

Dependency는 하나의 특징이 변화함에 따라 다른 하나에 영향을 미칠 때의 관계를 표시할 때 사용한다. 예를 들어 event클래스의 변화는 window 클래스에 바로 영향을 미침으로 이 둘의 관계를 dependency로 표시할 수 있다.

 

n         Example

 

 

위 그림의 예에서 보는 바와 같이 의존을 하게 되는 클래스로부터 화살표가 나가고 의존성을 가지게 하는 클래스로 화살표가 들어가게 된다.

FilmClip에서 playOn operation의 argument로 channel의 타입이 들어가게 된다. 이로써 channel의  변화는 FilmClip에 영향을 주게 되는 것이다.

 

4.       Notes

 

n         Notation

 

 

위 그림 처럼 Notes의 표시는 한 쪽 꼭지가 접혀진 사각형으로 표시한다.

 

n         Semantics

 

Notes는 Static Structure 다이어그램만 적용되는 것이 아니라 다이어그램 전반적으로 사용되며 다이어그램에 대한 주석이 필요한 경우 사용한다.

 

5.       Constraint

 

n         Notation and Semantics

 

Constraint는 특별한 형태의 표기를 가지고 있지 않고 무형의 text로 표시하게 된다. Constraint는 UML에서 의미를 갖는 모든 것에 새로운 의미를 부여하거나 존재하는rule들을 변화시킬 때 사용한다.  또한 Constraint는 참인 상황을 포함하는 조건을 나타낼때도 사용된다.

 

n         Example

 

위 그림에서 보는 바와 같이 portfolio와 bankAccount의 association relationship에 {secure}의 Constraint를 첨가하여 의미를 더하게 된다. 그리고  bankaccount와 corporation, person과의 관계를  {or}의 constraint를 사용하여 의미를 더하게 된다.

이 처럼 기존의 것에 constraint로 의미를 더하게 된다.

 

6.      
Example

실제로 모든 요소를 포함해서 하나의 회사에 대한 정적인 구조를 diagram으로 나타내었다. Company와 department, office의 관계는 composition으로 관계를 이루고 있다.

Department와 Person은 두가지의 association관계로 이루어져 있다. 하나는 person의 역할이 manager로서 하나는 member로서 이루어져 있다. 여기에 Constraint를 첨가하여 manager로서의 관계가 member로서의 관계의 부분 집합이라는 의미를 더하였다.

Person의 operation인 getContactInformation(), getPersonalRecords()는 ContactInformation과 personnelRecord의 변화에 따라 영향을 받게 됨으로 Person과 ContactInformation, PersonnelRecord는 dependency의 관계를 이루고 있다.

실제로 이외에 여러가지 부분을 추가하고 삭제함으로써 더욱 완벽한 회사의 정적인 구조를 만들 수 있다.

 

 

v 여기서 두번째 강좌를 마칠까 합니다. 여러가지 일이 바쁘다는 핑계  때문에 두번째의 강좌가 늦어진 것 같습니다.  이번 강좌는 정적인 구조를 나타내는 다이어그램의 기본적인 요소에 대해 알아보았습니다. 다음 강좌는 정적인 구조를 나타내는 다이어그램의 좀 더 깊은 부분을 다뤄볼려고 합니다. 다음의 강좌도 기다려 주세요.

 

v 이글을 인용하거나 포스팅하실분은 저한테 연락주세요.  또한 오타나 잘못된 점이 있으면 이리로 메일 주세요.

   

wideeye@www.plasticsoftware.com