대학교때 C++을 통해서 객체지향을 배우면서 Class와 Class와의 관계를 어떻게 정의하고 코드로 어떻게 표현하는지 배웠다. Class와 class와의 관계중에 가장 기본적이고 대표적인것이 아마도 Aggregation과 Association일것이다. 학교에서 객체지향에 대한 개념 배울때 그것만 중점적으로 배워서 그런지 (사실 처음 배울때는 그런 관계도 명확히 하는것이 어렵기도 하지) 아직까지도 UML 그릴때 aggregation과 association만 사용한다. 

하지만 요즘에 회사에서 일하면서 간혹 class diagram을 그리기 위해 공짜 UML 툴 중에 Star UML이라는 Tool을 사용하는데, 그 툴을 통해서 평소에 알지 못했던 Composition이라는 관계를 class간에 정의 할 수 있음을 발견하였다. Composition과 Aggregation의 관계를 보여주는 기호도 비슷했다.


그렇다면 이 둘의 차이점은 무엇인가? 보통 Association은 "knows-a" 관계라고 부른다. 반면 Aggregation은 "has-a" 관계라고 배워왔다. 하지만 내가 이해한 composition에 대해서 우선적으로 대략적으로 말하자면 그동안 내가 알아왔던 aggregation이 사실은 composition이고, aggregation은 association의 탈을 쓴 composition이다.

내가 그동안 이해했던 aggregation이라는것은 다음과 같다.
어떤 클래스가 다른 클래스를 member로 가지고 있다면 그것은 "has-a"관계이고 곧 aggregation이다. 하지만 이것이 composition이고, 가끔 "has-a"관계가 더 맞지만 동적으로 그 object을 생성해야 하는 경우가 있었고, 그럴때는 pointer를 사용해야 해서 모양새가 association인것과 같은 경우가 있었는데, 이런 경우에 aggregation을 사용해야 한다. 그래서 Aggregation은 composition과 같이 "has-a"관계이지만 동적으로 할당해야 해서 pointer를 사용해야 하는 경우 정의된다고 할 수 있는것 같다.

그렇다면 두 경우 모두 pointer 형을 사용하는 association과 aggregation의 차이는 다음과 같이 말할 수 있다. Association은 클래스 내에서 포인터를 통해서 다른 object로의 access를 가능하게 해주지만 이 관계를 성립해주는 곳은 두 클래스의 scope 밖이다. 반면 aggregation은 한 object로의 access를 가능하게 해주는 곳이 그 class 내이다. 즉, 동적으로 할당되는 위치도 그 class의 scope 내이다.

class A_composition
{
private:
   B pb;
public:
   A_composition();
   ~A_composition();
};

class A_aggregation
{
private:
    B* pb;
public:
    A_aggregation();
    ~A_aggregation();
};

class A_association
{
private:
    B* pb;
public:
    A_association();
    ~A_association();
    void AknowsB(B* b);
};

class B
{
public:
    B();
    ~B();
};


위와 같이 네 class가 있다면...
Composition은 class A_composition과 같이 그 class 내에서 다른 class object를 멤버를 가지고 있는것 만으로 성립되는 관계이고, 

Aggregation은 class A_aggregation처럼 class 내에 class B의 포인터형을 member로 가지고 있으며 그 pointer를 통해서 class B의 object로의 액세스를 가능하게 해준다. Class B object는 class A_aggregation에서 동적으로 할당되어 사실상 class A_aggregation이 class B object를 가지고 있는 형태가 되어야 하고, 꼭class A_aggregation의 scope내에서 동적으로 할당되어야 한다. 
예를 들면...
A_aggregation::A_aggregation()과 같은 constructor나 A_aggregation의 method 내애서 
pb = new B()

와 같은 구문을 사용해서 동적으로 할당되어야 한다.

반면 Association은 Aggregation처럼 class 내에 다른 class object로의 pointer를 member로 가지고 있지만, 그 object가 생성되는 위치는 Aggregation의 예와는 다르다. Association은 class A_Association처럼 memeber로 class B의 pointer형을 member로 가지고 있지만, Aggregation의 예에서와는 다르게 class B의 object는 A_association의 scope 밖에서 생성되어야지만 class A_association과 class B와의 관계가 association이라고 할 수 있다. 
그래서 aggregation에서의 예와는 다르게

A_association a;
B b;
a.AknowsB(&B);


이런식으로 A_association과 b가 서로의 scope가 아닌 곳에서(위의 예에서 처럼 같은 scope에서 생성될 필요는 없다) 생성되고, A_association의 AknowsB와 같은 method를 통해서 association의 관계를 성립시켜주어야 한다.

이것이 내가 이해한 Composition, Aggregation, 그리고 Association의 차이다...


[출처 : http://dansoonie.tistory.com/entry/SE-How-is-Aggregation-and-Composition-different]

UML(Unified Modeling Language)는 시스템을 객체지향적(Object-Oriented)으로 분석(Analysis) 및 설계(Design)를 하기 위한 언어이다. 이 언어는 어떤 시스템의 상세(SPECIFICATION)를 만들고 시각화(VISUALIZATION)하고 문서화(DOCUMENTATION)하는데 도움이 된다.

 

Use case diagram

 

시스템이 무엇을(WHAT) 하느냐를 기술한다. 그러나 어떻게(HOW) 하느냐를 기술하는 것은 아니다.

 

액터(ACTOR)는 시스템과 상호작용(INTERACTION)하면서 이벤트를 발생시키는 주체이며, 액터는 사람(USER)일 수도 있고, 사물(THING)일 수도 있고 다른 시스템(OTHER SYSTEM)일 수도 있다. 유스케이스(USECASE)는 액터가 사용하는 시스템기능에 대한 서술이다. 액터와 유스케이스들 사이에는 관계(ASSOCIATION)가 맺어진다. 하나의 액터는 다수개의 유스케이스와 관계를 맺을 수 있으며, 하나의 유스케이스도 다수개의 액터와 관계를 맺을 수 있다.

 

유스케이스끼리도 관계를 맺을 수 있다. 첫째, 하나의 유스케이스는 다른 유스케이스의 일종일 수 있는데, 이들은 일반화관계(GENERALIZATION)로 표시되며 is a kind of의 관계가 있다. 둘째, 여러 개의 유스케이스들은 수학에서의 공약수처럼 공통된 하나의 유스케이스를 포함할 수 있는데, 이들은 포함관계(INCLUDE) 관계로 표시된다. 셋째, 하나의 유스케이스는 다른 유스케이스의 변종일 수가 있는데, 이들은 확장관계(EXTEND) 관계로 표시된다.

 

유스케이스가 많이 존재하는 그림에서는 복수개의 유스케이스를 하나의 시스템영역으로 묶을 수 있으며, 이때 시스템에는 고유한 이름이 붙여진다.

 

유스케이스 기술서(DESCRIPTION)를 통해서 한 유스케이스가 어떠한 이벤트들의 흐름을 가질 수 있으며, 하부흐름(SUBFLOW) 또는 다른 흐름(ALTERNATIVE FLOW) 등도 가질 수 있다는 것을 표현한다.

 

유스케이스는 요구사항(REQUIREMENT)을 기술하는데 도움이 되는 그림이며, 이 그림을 바탕으로 사용자, 설계자, 개발자, 테스트 팀 모두가 의사소통을 하는 도구가 된다.

 

Class diagram

 

시스템에서 발생할 수 있는 클래스들과 그 클래스들간의 관계를 표현하는 그림이다. 이는 유스케이스와 달리 시스템의 정적인 표현이다.

 

클래스는 클래스명(CLASS NAME), 속성들(ATTRIBUTES), 그리고 오퍼레이션들(OPERATIONS)을 가진다. 클래스의 속성과 오퍼레이션들은 그 보안레벨에 따라 PUBLIC, PRIVATE, PROTECTED 등으로 구분될 수 있다. 각 속성은 데이터타입(, Date 등등)을 지정할 수도 있고 제약조건(CONSTRAINT)을 지정할 수도 있다. (, {A,B,C}) 각 오퍼레이션들에는 시그니처(SIGNATURE)를 지정할 수 있는데, 시그니처란 INPUT PARAMETER, INPUT PARAMETER DATATYPE, 오퍼레이션의 RETURN DATATYPE을 의미한다.

 

클래스간의 관계(ASSOCIATION)는 관계명(ROLE NAME)과 방향성(NAVIGABILITY), 관계수(MULTIPLICITIES), 제약조건(CONSTRAINT)을 가진다.

 

관계수는 n..m (n>=0,n<m) 또는 그냥 n (n>=1)으로 표시될 수 있는데, n..m 관계는 n개에서 m개까지의 관계를 맺을 수 있다는 것을 의미하고 이때 m은 정해진 개수가 아니라 그냥 MANY를 의미하면 *(ASTERISK) 로 표현할 수 있다. 관계수가 n으로 표시되는 것은 정확히 n개의 관계를 맺어야 한다는 것을 의미한다.

 

제약조건은 그 조건을 만족하는 경우에만 관계가 의미가 있다는 뜻이다. 배타적(EXCLUSIVE) 관계도 제약조건을 이용하여 표시된다.

 

관계에는 크게 ASSOCIATION, AGGREGATION, GENERALIZATION, DEPENDENCY 4가지 타입이 있다.

 

ASSOCIATION 관계는 클래스가 다른 클래스와 관계를 맺고 있다는 뜻인데, 이 관계는 인스턴스를 생성시켜서 이용하고 이용당하는 관계, 또는 메시지를 주고 받는 관계 등을 말한다.

 

ASSOCIATION 관계는 방향성(NAVIGABILITY)을 가질 수 있는데, 한 클래스와 다른 클래스의 관계가 쌍방향이 아닌 단방향인 경우에 NAVIGABLE ASSOCIATION 관계가 된다.

 

AGGREGATION 관계는 여러 클래스가 집합(COLLECTION)으로 모여서 하나의 클래스를 이루고 있다는 관계를 표현한다. 그래서 한 클래스는 다른 클래스의 is-a-part-of의 관계에 있다. 예를 들어 자동차라는 클래스는 핸들, 바퀴, 샤시, 윈도우 등의 클래스들과 AGGREGATION 관계를 맺을 수 있다. AGGREGATION 관계는 이미 has 또는 contains 의 의미를 가지므로 관계명(ROLE NAME)을 정의하지는 않는다. 그러나 관계수(MULTIPLICITIES)는 지정할 수 있다.

 

AGGREGATION과 유사한 집합관계로서 COMPOSITION 관계가 있는데, 이는 한 클래스는 다른 클래스에 속하는데 그 클래스 없이는 존재할 수 없는 밀접한(STRONG) 집합관계를 맺고 있음을 의미한다.

 

GENERALIZATION 관계는 한 클래스는 다른 클래스의 서브관계로서 상속을 받음을 의미한다. 그래서 한 클래스는 다른 클래스의 is-a-kind-of의 관계에 있다. 예를 들어 자동차라는 클래스는 승용차, 트럭, 버스 등의 클래스들과 GENERALIZATION 관계를 맺을 수 있다.

 

DEPENDENCY 관계는 한 클래스가 변경되면 다른 클래스도 따라서 변경될 가능성이 있는 관계를 의미한다. 대개는 한 클래스가 다른 클래스의 오퍼레이션의 파라메터로 사용되는 경우에 DEPENDENCY 관계가 맺어질 수 있다.

 

클래스와 다른 클래스간에 맺고있는 ASSOCIATION 관계 자체가 하나의 클래스를 형성할 수 있는데 이를 ASSOCIATION 클래스라고 한다. 대개 관계수가 양쪽 다 MANY에 해당되는 경우에 이 클래스가 나올 수 있다.

 

인터페이스(INTERFACE)는 클래스 또는 시스템을 외부에서 어떻게 사용할 수 있는가를 정의하기 위한 오퍼레이션들의 집합으로 정의한다. 이 오퍼레이션들을 클래스가 실제로 구현을 하게 되는데 인터페이스와 구현되는 클래스는 실체화(REALIZATION)관계를 맺는다. 인터페이스는 스테레오타입(STEREOTYPE)으로 표시되며, 그 이름은 I라는 대문자로 시작된다.

 

클래스 다이어그램은 시스템을 정적(STATIC)으로 표현해주는 그림이다.

 

Package diagram

 

서로 연관성이 있는 클래스들을 사각형으로 묶을 수 있는데 이를 패키지라 한다. 패키지는 패키지명을 가진다. 한 패키지에 속한 클래스는 다른 패키지에 속한 클래스와 DEPENDENCY 관계를 맺을 수도 있는데, 이러한 경우에는 패키지간의 DEPENDENCY 관계가 된다.

 

Object diagram

 

클래스간에 순환(RECURSIVE) 관계 등 복잡한 관계를 맺고 있을 때, 클래스 다이어그램의 이해를 돕기 위해서 클래스의 인스턴스(INSTANCE)를 그림으로 표현한다. 인스턴스명:클래스명이 밑줄쳐진(UNDERLINE) 상태로 이름이 표현되며, 인스턴스간에는 일반적인 ASSOCIATION 관계가 맺어진다.

 

따라서 클래스 다이어그램은 오브젝트 다이어그램의 추상화(ABSTRACTION)된 그림이라고 할 수 있다. 오브젝트 다이어그램도 클래스 다이어그램과 마찬가지로 시스템을 정적(STATIC)으로 표현하는 그림이다.

 

Sequence diagram

 

객체들간의 동적인 상호관계를 시간의 흐름순서에 따라 보여준다. 상호작용을 하는 객체는 액터일 수도 있고, 클래스의 인스턴스일 수도 있다. 각 객체들은 메시지를 주고 받으면서 호출하는데 객체는 자기 자신에게 메시지를 던져 호출할 수도 있다. 메시지들은 시간 순으로 정렬되어진다.

 

객체는 다른 객체들에게 비동기적(ASYNCHRONOUS) 메시지를 보낼 수 있으며 이는 반쪽 화살촉을 가지는 화살표로 그린다. 메시지들이 비동기적 관계에 있으면 그 메시지들은 시간에 관계없이 보내어지고 받을 수 있다는 것이다.

 

하나의 유스케이스의 복수개의 시나리오를 가질 수 있는데, 각 시나리오별로 시퀀스 다이어그램이 하나씩 그려질 수 있다. 시퀀스 다이어그램은 시스템을 동적으로 표현해주는 그림이다.

 

Collaboration diagram

 

상호협동 다이어그램은 시퀀스 다이어그램과 비슷한 의미를 제공하는 그림이다. 그러나 여기에서는 시간에 따른 정렬보다는 객체의 역할(ROLE)에 비중을 두어서 그리는 그림이다. 그리고 각 메시지에는 일련번호를 부여할 수 있다.

 

이 다이어그램도 시퀀스 다이어그램과 마찬가지로 시스템을 동적으로 표현하는 그림이다.

 

Statechart diagram

 

상태 다이어그램은 객체가 생성되어서 소멸되기까지 다른 객체와의 상호작용에 의해 그 객체의 상태가 변화되어가는 것을 표현한 그림이다. 한 순간에 어떤 상태에 머물러있는 객체에 특정 이벤트(EVENT)가 발생되면 다른 상태로 전이하는 것을 화살표로 표현하는데 상태가 전이되기 위한 조건(CONDITION)이 있을 수 있다.

 

각 상태(STATE)는 중복되지 않아야 한다. , 한 객체는 한 순간에 하나의 상태에 머물러 있어야 한다. 그러나 여러 개의 연관성 있는 상태들을 모아서 하나의 복합상태(COMPOSITE STATE)를 만들 수는 있다.

 

Activity diagrams

 

액티비티 다이어그램은 상태 다이어그램과 유사한 기능을 하지만, 상태 다이어그램은 한 객체의 상태에 초점을 맞추는 것이고 액티비티 다이어그램은 객체가 수행하는 행동에 초점을 맞추는 것이다.

 

객체가 행동을 수행할 때에는 다른 객체에 메시지가 전달되어 그 객체의 행동을 유발시킬 수도 있다. 따라서 액티비티 다이어그램은 한 프로세스(PROCESS)의 시작부터 종료까지 여러 객체들이 어떤 행동들을 하는가를 표현하는 그림이다.

 

Component diagrams

 

컴포넌트란 클래스가 실제 구현되어져 나오는 결과물을 얘기하는 것으로 소스코드, 실행코드, 라이브러리 등을 말한다. 컴포넌트 다이어그램은 구현되어진 모듈들의 이름이나 의존관계 등을 표현한다.

 

Deployment diagrams

 

배치 다이어그램은 시스템의 하드웨어 또는 소프트웨어의 물리적인 구조를 보여준다.

 

ER Diagram vs. Class Diagram

 

* class method의 정의

class가 가질 수 있는 attribute 뿐만 아니라 method까지 동시에 정의할 수 있다.

 

* Relationship cardinality

UML모델링에서는 cardinality를 정확하게 지정할 수 있다.

예를 들어 각 회원은 인증문답을 3개까지만 지정할 수 있다는 biz rule이 있다고 가정하면,

rule UML에서는 명확하게 표현할 수 있지만 ERD에서는 단순히 one-to-many로만 표현한다.



[출처 : http://iclickyou.com/1340]

+ Recent posts