Written by 심 원도
1998년 2월 1일
copyright Plasticsoftware. Co.
우리는 앞 강좌에서 staticstructure diagram의 기본요소와 기본 개념에 관하여 알아보았습니다. 이번에는 staticstructure diagram요소들의 확장된 표기법과 의미, 확장되는 relationship의 의미를 알아보는 것으로 강좌를 할것입니다.
이러한 확장된 내용을 하기 전에 우리는 UML전반에 걸쳐 적용할 수 있는 mechanism을 알아보겠습니다. 이러한 mechanism에 대한 설명은 강좌의 초반에 언급했어야 하지만 필자또한 공부하며 정리하는 형식으로 강좌를 올리는 상황이라 어쩔 수 없이 이렇게 강좌 틈틈히 이러한 추가적인 내용을 같이 올리도록 하겠습니다.
1. Common Mechanism
UML에서는 시스템 설계의 표기를 깔끔하고 명확한 의미를 가지게 하는 specifications, adornments, common divisions, extensibility mechanisms과 같은 4가지 mechanism을 제공한다.
1) Specifications
앞의 강좌에서 우리는 클래스와 relationship을 위한 여러가지 표기를 배웠다. 클래스 notation속에는 여러가지 문자적인 기술을 함으로써 다양한 specification을 가지게 된다. 이처럼 우리는 시스템에 관한 여러가지 내용을 notation과 문자적인 기술로서 나타내게된다. UML 전반에 걸쳐서 우리는 이러한 specification으로 시스템의 설계를 표기하게 된다.
2) Adornments
UML에서는 대부분의 요소가 graphical notation으로 표기가 가능하다. 클래스를 예로 보면 하나의 사각형으로 표시하고 attribute와 operation, visibility등을 추가적으로 넣을 수 있다. 이 처럼 하나의 개념적 내용을 단순한 notation으로 시작하여 추가적인 장식들(adornments)을 붙여 나감으로서 완벽한 의미를 전달하게 된다.
3) Common Divisions
객체지향 시스템을 모델링함에 있어서는 하나의 물체가 대한 다양한 방법으로 나타내어진다.
n 클래스 and 객체
클래스는 추상화이고 객체는 이러한 클래스의 일례이다. UML전반에 걸쳐 동일한 물체에 대한 클래스와 객체의 표기는 나눠지게 된다.
Customer jan : Customer
name address phone :Customer
위 그림의 예에서 하나의 클래스를 Customer로 표기하였고, 나머지 Custormer의 객체 세개를 표기하였다 하나는 심원도의 객체로 클래스의 이름이 나타나 있다. 다음으로 객체의 이름은 나타나지 않고 클래스의 이름만 나타나있다. 다음으로 클래스의이름은 없고 객체의 이름만 나타나 있다.
Elyse
n Interface and Implementation
Interface는 어떠한 외부와의 약정을 선언하는 것이고 Implementation에서는 이 interface 의 의미를 기술하는 것이다. UML에서 만들어지는 모든 block은 interface와 implementation으로 나뉘어진다.
4) Extensibility Mechanisms
UML은 소프트웨어의 설계를 위한 언어이다. 하지만 모든 상황에서의 어떤 의미를 표현하기 위해서는 하나의 언어로는 부족하다. UML 또한 마찬가지로 어떤 미묘한 의미의 차이를 표현하기에는 부족한 면이 있고 이를 위해 다음과 같은 Extensibility Mechanisms을 가지고 있다.
n Tagged Value
Tagged Value는 UML에서 어떠한 building block의 특징들을 확장한다. 예를 들어 어떠한 제품이 있고 이 제품이 시간이 지남에 따라 확장된 제품임을 표시하고 싶어진다. 이때 우리는 tagged value로서 제품의 버전과 어떤 부분의 저자를 나타낼 수 있다.
n Constraints
Constraint는 UML의 building block의 의미를 확장한다. 이러한 constraint는 기존의 의미를 고치거나 새로운 rule을 적용하게 된다.
n Streotype
Streotype은 UML의 어휘의 확장이다. 어휘의 확장이란 streotype을 사용하여 기존의 buliding block을 새로운 종류의 block들을 만드는 것을 말한다.
아래 그림의 예에서 보듯이 tagged value로 version과 author를 사용하였고 constraint로 add operation에 ordered를 사용하여 의미를 추가하였다. 또한 기존의 overflow의 클래스에 streotype으로 exception을 사용하여 EventQueue의 예외상황을 처리하도록 하였다.
<<exception>> Overflow EventQueue {version = 3.2 author = egb } Add() remove() flush() {ordered}
2. 클래스 의 깊은 곳
위에서 우리는 staticstructure diagram뿐만 아니라 UML전반에 적용되는 mechanism에 관하여 알아보았다. 이제부터 실제 staticstructure diagram에 관하여 좀 더 자세히 알아 보기로 하겠다.
1) Classfiers
우리는 실세계를 표현하기 위해 추상화를 사용한다. 이렇게 추상화된 것으로부터 실례화(instance)시켜서 사용하게 된다. 예를 들어 고객의 추상화로써 customer 클래스를 사용하고 이의 instance로써 각 개인의 고객으로 대응시키게 된다. 이와 같이 UML에서 추상화를 위한 modeling element를 classifier라고 총칭한다. UML에서 가장 대표적인 classifier로써 클래스를 사용한다. 하지만 클래스이외의 classifier로 다음과 같이 다양하게 존재한다.
n Interface
Interface
클래스와 컴포너트의 서비스를 구체화하기 위해 사용되는 operation의 집합.
n Datatype
Datatype
<<type>> int {value range form 100 to +100}
n Signal
<<signal>> OffHook signal
인스턴스 사이에 비동기적인(asynchronous) 신호의 기술
n Component
시스템에서 교체가능한 물질적인 부분으로 realization이 가능한 인터페이스를 제공한다.
Component
kernel32.dll
n Node
실행시간에 존재하는 물질적인 요소로써 resource를 차지하고 메모리와 프로세스를 일부분 차지하게 된다.
egb_server node
n Subsystem
요소들의 집합으로 포함되어 있는 요소의 행위를 포함하고 있다.
<<subsystem>> Customer Service subsystem SubSystem
2) Multiplicity
NetworkController 1
클래스에서 instance화 되는 객체의 수를 제한할 필요성이 생길 때 클래스 box의 왼쪽위에 instance의 수를 기입하여 나타낸다.
consolePort[2..*]Port
위 그림의 예에서 클래스 사각형의 오른쪽 위에 multiplicity로서 하나의 인스턴스 만을 가짐을 나타내었다.
3) Attributes
추상화의 정도가 높은 수준의 모델링에서의 클래스에서 attribute는 이름만으로 모델링의 의도를 충분히 나타낼 수 있다. 하지만 UML에서는 attribute의 이름 이외에 여러가지 특징을 부가적으로 표현할 수 있다.
n Attribute의 full form :
[Visibility] name [multiplicity] [: type] [= initial-value] [ {property-string} ]
n example
Origin -> 이름만 명시
+ Origin -> 이름과 visibility 명시
Origin : Point -> 이름과 type 명시
Name[0..1] : String -> 이름, multiplicity, type명시
Origin : Point = (0,0) -> 이름, type, 초기값 명시
Id : Integer {frozen} -> 이름 과 property명시
n property-string의 종류.
changeable : attribute의 값의 변화가 가능하다.
addonly : attribute의 추가가 가능하다. 반면에 한번 생서의 이후 제가가 불가능 하다.
frozen : 객체의 객체가 초기화 된 이후에 attribute의 값은 변화가 불가능하다.
4) Operations
Operation또한 attribute와 마찬가지로 좀 더 상세한 정보를 표현할 수 있다.
n Operation의 full form :
[Visibility] name [(parameter-list)] [:return-type]
n Parameter의 형태
[direction] name : type [= default-value]
이러한 parameter가 모여서 parameter-list로 이뤄진다.
n Direction의 종류
in : parameter가 input parameter임을 나타내고 operation의 수행중 변화가 불가능하다.
out : parameter가 output parameter임을 나타내고 변화가 가능하다. 이 operation을 호출자에게 변화의 사실을 알린다.
inout : parameter가 input parameter임을 나타내고 변화가 가능하다.
5) Template Classes
Template는 parameterized element를 나타낸다. 여기에서 Parameterrized란 의미는 어떠한 클래스가 있을 경우 내부에 멤버로 쓰이는 attribut나 operation의 parameter의 type을 parameter화 시켜서 사용하는 것이다. 이런 의미의 template는 C++이나 Ada의 template 클래스와 동일한 개념이다.
Map +bind(in i : Item; in v : Value) :Booleam +is Bound(in i : item) : Booleam {isquery} Item Value Buckets : int
Map<Customer, Order, 3> Order Map <<bind>>(Customer, Order, 3)
위 그림에서 보는 바와 같이 template의 표시는 클래스 사각형 왼쪽 위에 점선 사각형
안에 template의 parameter를 적어 넣으면 된다. Template의 instant화는 두가지의 방법이다. Implicit한 방법으로 위 왼쪽 아래처럼 표시하는 것이고 explicit한 방법으로 stereotype을 사용하여 오른쪽 아래처럼 표시한다.
3. Relationship의 깊은 곳
앞의 강의에서 우리는 relationship의 종류와 의미에 관해서 대략 알아보았다. 이곳에서는 각각의 relationship에 대하여 자세히 그리고 내부에 더 추가될 수 있는 의미에 관하여 알아볼 것이다.
1) Dependency
UML에서는 Dependency의 관계에 Stereotype을 붙임으로써 의미를 확장할 수 있다.
n 첫번째 부류로 클래스와 클래스들 사이의 관계에서의 stereotype을 들 수 있다.
bind : template container 클래스와 여기에서 instance화 되는 관계사이를 bind의 stereotype으로 특징화 시킬수 있다.
derive : derive stereotype은 source에 의해 target가 계산되어질 때 사용된다. 예로써 사람의 클래스에서 Age와 BirthDate의 attribute 서로에게 나타내어진다.
friend : friend의 stereotype은 target에 의해 source의 특수한 visibility가 형성된다. 예로써 C++의 friend의 member의 경우에 해당된다.
Instanceof : instanceof의 stereotype의 경우 target에 의해서 객체가 인스턴스화 되는 경우에 해당된다.
powertype : 대상이 source의 powertype일 경우이다 여기서 powertype의 의미는 모든 자식 클래스의 부모클래스가 되는 type을 말한다.
d와 e의 경우 클래스와 클래스의 관계가 아닌 클래스와 객체의 관계에서 나타날 수 있는 stereotype이다.
refine : source 가 target보다 추상화 정도가 더 높을 때 사용한다.
use : source의 의미가 target의 public부분의 의미에 의해 의존적일 때 사용한다.
n 두번째 그룹으로 객체와 객체사이의 관계에서 나타날 수 있는 stereotype이다.
become : source와 target은 동일한 객체이다 하지만 시간의 흘러 지난 시점에서 다른 상태와 값을 가지고 다른 역할을 할 경우에 표시한다.
call : source의 operation이 target의 operation을 호출할때 나타난다.
copy : target의 객체가 소스의 복사본으로 독립적으로 존재할 때 나타낸다.
2) Generalization
Generalization의 관계에는 1개의 stereotype과 2개의 constraint를 적용시킬 수 있다.
n Stereotype
implementation : 추가적인 public member나 interface를 만들지 않고 부모의 implementation만을 추가하는 경우에 해당된다.
n Constraint
complete : 더 이상의 자식 클래스를 허용하지 않는 것으로 최종으로 상세화(specific)된 것임을 나타낼 때 사용한다.
incomplete : 추가적인 자식 클래스를 허용하는 것이다. 단 자식 클래스가 항상 상세화를 하는 것은 아니다.
3) Association
Association에도 몇가지 특징으로 navigation, qualification, 다양한 형태의 aggregiation등의 추가적인 모델링을 할 수가 있다.
n Navigation
두 클래스들 navigationg할 수 있다. 두 클래스가 단 방향 또는 양방향의 navigating이 가능하다. 예를 들어 user와 passwd의 클래스 경우 사용자에 해당하는 passwd을 찾기 위해 passwd 클래스를 navigating할 수 있다.
Passwd 1 * Association navigation
User owner
위 그림에서 보는 바와 같이 navigating의 방향을 나타낸다.
n Visibility
* 1 * *
두 클래스 간의 navigating을 member의 visibility로서 제한 할 수 있다.
UserGroup User Password +user +owner -key
위 그림의 예로써 설며하면 usergroup, user, passwd의 관계에서 passwd는 user의 private이므로 외부에서는 access가 불가능하다. 반면에 usergroup에서 user의 navigating은 가능하나 user의 passwd에 대하여서는 navigating이 불가능하다.
n Qualification
jobID : Int ReturnItem * 0..1
UML에서 일대다수의 관계에서 다수의 객체중 하나의 객체와 의 관계를 구별할 수 있게하는 identifier로써 qualifier를 사용한다.
WorkDeskㅏsk
위 그림에서 jobID로 returnItem중 해당되는 returnitem을 구별한다.
n Interface Specifier
Person * worker : IEmployee
하나의 클래스가 다양한 interface를 가지면서 존재할 수 있다. 예를 들어 person의 경우 manager와 employee, officer의 인터페이스를 가질 수 있다.
1 supervisor : IManager
위 그림에서와 같이 인터이스에 해당하는 rolename을 같이 적어서 각 역할에 해당하는 인터페이스를 취할 수 있다.
n Association Classes
두개의 클래스 사이관계인 association에서 association자체도 property들을 가질 수 있다. 예를 들어 employer/employee의 관계에서 company와 person사이에 job을 나타내는 association class가 존재할 수 있다. 이러한 association class는 다음의 그림과 같이 나타낸다.
UserGroup Person * 1..* job
description dateHired salary
Association에서도 몇 가지 constraint가 존재한다.
n implicit : 관계가 개념적이거나 암시적일 때 사용한다.
n ordered : 객체의 집합과의 관계를 가질 경우 그 객체의 집합은 순서를 가지고 있다는 것을 표시한다.
n changeable : 객체들 사이의 링크가 변화가능할 때 사용한다.
n addonly : 새로운 링크가 첨가 될 수 있다.
n frozen : 링크가 생기면 이러한 링크는 변화가 불가하고 지울 수도 없다.
5) Realization
Realization은 dependeny와 generalization관계의 중간정도되는 관계로 어떠한 클래스와 interface와 관계나 component와 여기서 제공하는 서비스와의 관계를 나타낼 때 사용한.
<<Interface>> IRuleAgent Realization
위 그림에서는 IRuleAgent라는 인터페이스와 association관계를 가진 accountbusinessrules의 클래스를 나타낸다.
addRule() changeRule() explainAction() AccountBusinessRules
v 강좌를 마치며 개인적으로 아쉬움이 남는 강좌입니다. 실제로 시간이 많이 늦었고 또 내용의 구성이 상당히 방만함을 느낍니다. 하지만 글을 올린다는 약속도 있고 주위의 압력에 의해 이렇게 부랴부랴 글을 올립니다. 다음의 강좌에 더욱 충실한 내용으로 채울 것을 약속합니다. 내용중 틀린 내용이나 오타등이 있으면 다음으로 멜 주십시요.
Wideeye@www.plasticsoftware.com
다음 강좌는 개발 process의 초반부에 해당되는 user case에 관한 부분을 올리도록하겠 습니다. 많은 기대 바랍니다.
