Software Engineering 2 - Class diagram & relationships

 Class relationship : Dependency < Association <Aggregation < composition < Inheritance
- Inheritance : 상속이 가장 강한 relationship이다. (is-a, 같은 타입), 나머지와 달리 런타임에 내용을 변경할 수 없다.
- composition (contain, 보관) : 어떤 클래스가 다른 클래스의 객체를 가지고 있을 때
- Aggregation(reference를 소유) : 위와 비슷하지만 온전한 소유가 아니라 공유하는 방식으로 가지고 있음. 따라서 다른 클래스도 해당 객체를 참조하고 있을 수 있다.
- Association : 가장 기본적인 상태. 어떤 클래스의 오브젝트가 다른 클래스의 오브젝트와 함께 적당한 기간 동안 작업을 하는 경우. 한 클래스의 멤버 변수로 다른 클래스의 오브젝트를 가지고 있는 경우가 해당.(지속적인 관계)
- Dependency : 위와 비슷하지만 방향성이 존재하며 작업하는 기간이 훨씬 짧다. 어떤 클래스의 메소드 내에서 잠깐 쓰이고 해당 관계가 지속되지 않는 경우. (메소드의 매개변수, 리턴타입, 인스턴스 등으로만 쓰일 경우)


Binary Association : 두 개의 서로 다른 클래스로부터 만들어진 인스턴스를 연결하는 경우. 한 클래스에서 동일한 클래스로 relationship이 생길 경우 Unary, 세 개 이상의 클래스가 관여하는 것도 가능하다. (DB의 relation과 동일)
- 화살표(Navigability) : source의 instance로부터 대응되는 instance를 찾을 수 있다는 의미. 역방향으로는 찾을 수 없음. (X 마크) 일부러 정보를 제한하므로써 필요없는 정보를 제외하기 위해 사용.(굳이 알 필요 없을 경우, 알지 않는 것이 디자인적으로 더 좋음) 상대 object를 찾는다는 것은 visible attribute/operation을 사용할 수 있다는 의미이다.
*일반적으로 화살표나 가위표가 표시되어 있지 않는 경우는 양방향으로 access가 가능하다는 것을 의미한다. 그리고 가위표는 일반적으로 생략한다.
- 이름 : 두 인스턴스 사이에 발생하는 관계와 방향을 자연어로 설명
- Role : 해당 클래스의 인스턴스의 역할, 주어진 상황에서 해당 객체가 해당 관계에서 어떤 역할을 수행하는지 나타내는 것.
- Visibility : +(public), -(private), #(protected)
- Multiplicity : 주어진 상황에서 상응하는 인스턴스가 몇 개까지 가능한가. (DB와 동일) 즉, 연결된 object 한 개에 대해 몇 개의 객체가 대응될 수 있는가. 단, DB의 두 가지 notation 중 자기 것을 자기가 표시하는 방법을 사용한다.
프로그램적으로 어떤 클래스 내부에 다른 클래스의 인스턴스를 가리키는 배열 등이 존재한다면 이런 binary association이 있는 것으로 이해할 수 있다.

클래스 다이어그램의 표시만으로는 어떤 인스턴스의 모든 제약조건을 나타내지 못하는 경우가 생길 수 있다. 이럴 경우 자연어나 OCL 등과 같은 언어로 제약조건을 추가로 서술해야 한다.

Association Class
관계에 attribute를 추가하기 위한 메커니즘.
두 클래스가 어떤 관계를 맺을 때만 해당 관계 속에서 발생하는 속성을 표기하기 위해, 관계 자체를 클래스로 만드는 방법이다. 이는 관계에 점선을 그어 표시하며, 이 것도 class 이므로 또 다른 class와 관계를 맺을 수 있다. 따라서 다른 클래스와 동일하지만, 본질적으로는 어떤 관계 속에서만 의미를 가진다.
일반적으로 이런 association class는 n:m 관계에서는 필요하지만, 1:1 혹은 1:n 관계에서는 굳이 표현하지 않고 각 class 내부에 속성으로 추가하는 것이 좀 더 바람직하다. (표현은 가능하지만 굳이 사용할 필요 없음)
왜냐하면 n:m의 class diagram의 경우, instance를 그릴 때, 각각의 오브젝트가 같은 관계 속에서 여러 개의 오브젝트와 연결될 경우 해당 오브젝트의 속성이 어느 관계에 속하는지 알기 어렵기때문이다.
그리고 association class를 binary association 두 개를 사용하여 나타내는 것은 같은 의미를 가질 수도 있지만 그렇지 않을 수도 있다. (일반적으로 다르므로 혼동하지 않아야 한다)
일반적으로 두 class/instance 사이의 관계는 duplicate 될 수 없는 것이 default이다. (Unique : 두 클래스 사이 pair link는 하나만 존재) 만약 중복을 허용하고 싶다면 non-unique를  선언해서 따로 표기해주어야 한다. (재수강하여 같은 과목에 대해 성적을 두 번 받는 등) 이 경우 각 link에 대해 association class가 따로 발생할 수 있다.

Qualified Association
Association class의 포함된 attribute가 qualifier 가 되는 종류, qualifier는 여러 개의 관계가 연결된 객체 쪽에서 모호함을 해결해주는 역할을 한다.
이 경우 qualifier를 통해 multiplicity의 쪽의 특정 객체에 좀 더 정확하게 접근할 수 있다. 다만 이런 qualifier를 사용하는 것이 반드시 좋은 것은 아니고 사용하지 않아도 틀린 것이 아니다. 더 많은 정보를 담고 있는 것 뿐이므로 상황에 알맞게 사용해야 된다.

Aggregation
Association과 비슷하지만(일종) 어떤 클래스가 다른 클래스의 part가 되는 것을 표현한다. 이들은 property로 Transitive와 Asymmetric을 가진다. (Transitive : B가 A의 part이고, C가 B의 part이면 C는 A의 part 이다. Asymmetric : A와 B가 동시에 서로의 part 일 수는 없다. 어떤 하나는 반드시 나머지에 속해야 한다.) 따라서 방향성이 있는 acyclic graph를 생성하게 된다.
- type
Shared aggregation : 여러 파트가 서로 독립적이지만 모여서 전체를 구성함.(weak belonging) 컴퓨터 시스템의 프린터/모니터/키보드 등등. 이 경우 각 파트가 whole의 lifecycle에 종속되어 있지 않다.
whole을 나타내는 클래스/오브젝트에 빈 마름모를 붙여 표현한다. 이 때 마름모가 붙어 whole을 나타내는 객체의 multiplicity의 제한은 없다. 왜냐하면 어떤 객체가 1번 클래스의 part인 동시에 2번 클래스의 part로 교집합 처럼 될 수도 있기 때문이다.

Composition : 파트가 전체(whole 객체)에 종속되어 있다. 따라서 whole이 종료되면 part도 모두 종료된다. 나무와 나뭇가지, 빌딩과 룸 등의 관계를 생각해보면 whole이 없이 part가 존재할 수 없으며 여러 개의 whole에 하나의 part가 속할 수도 없다.
composition은 위와 동일하게 whole을 나타내는 객체에 꽉 찬(검은색) 마름모를 붙여 나타낸다. 단, 이 경우는 위의 shared와 달리, whole 을 나타내는 객체의 multiplicity는 0 또는 1로 고정된다. 왜냐하면 whole 이 없어지면 part도 모두 사라지므로 완전히 종속되어 있는 관계이기 때문이다.
둘 중에 상황에 맞게 적절한 constraint와 자유도를 줄 수 있는 것을 사용하여 모델링 해야 함.

Generalization
객지프의 상속과 동일한 개념. General class(superclass)의 attribute, operation, association, aggregation 등이 모두 subclass로 전달되는 것.(private 제외)  그리고 subclass의 instance는 superclass의 indirect instance로 사용될 수 있다. Generalization도 역시 transitive 한 특성을 가지고 있다.
Abstract Class : 객지프에서 배운 것과 동일하게 direct instance를 생성할 수 없는 클래스. UML에서는 {abstract}를 쓰거나 이탤릭체로 표현한다.
Java는 불가능하지만 c++에서는 다중 상속이 가능하다. UML은 모든 언어를 표현가능해야 하므로 다중상속 역시 표현가능하다.

Class diagram Creation
명사를 class의 이름으로, 형용사를 attribute로, 동사는 operation으로 추상화하여 생각하면 언어로 기술된 명세서를 클래스 다이어그램으로 만들어낼 수 있다.