클래스 다이어그램 관계도

클래스 다이어그램이란

시스템을 구성하는 클래스들 사이의 관계를 표현해주는 그림 도식.

클래스의 표현

클래스는 3가지 칸으로 구성된다. 가장 윗 부분에는 클래스 명이 들어가고, 중간 부분에는 속성(클래스의 특징, 변수)이 들어가고 마지막 부분에는 연산(메서드, 클래스가 수행하는 책임)이 들어간다. 

• + public
• - private
• # protected

변수는 : 뒤에 타입 명시

함수는 (파라미터) : 반환값을 사용

 

Player

+ moveSpeed : float - moveDir : Vector3 # targetPosition : Vector3

- Move() : void + TraceTarget() : void

 

const 변수 일땐 전체를 대문자로 표기, 함수는 단순히 파라미터 괄호 닫히는 부분 옆에 const로 표기

TraceTarget와 같이 밑줄 그어진건 static

가상함수는 {virtual} 또는 {override}로 표기

 

Player

+ MOVESPEED : float

+ TraceTarget() : void - Move() const : void # DealDmg() : void {virtual}

속성으로 흐름을 분석하기 위한 다이어그램일땐 속성(변수)과 연산(함수)부분은 생략하기도 한다. 

이렇게 다이어그램을 표현할 때 분석 단계와 설계 단계에서의 표현 방식이 다소 다르다.

클래스 간 관계

이와 같이 숫자로 표기할 때가 있다, 이 숫자의 의미는 참조 대상 개수이며 다음과 같다. 일반화 실체화 예외.

• 1 : 1개
• n : n개
• 0..1 : 없거나 1개
• 0..* 또는 * : 없거나 많다
• 1..* : 적어도 1개 이상
• n..* : 적어도 n개 이상
• n..m : 적어도 n개부터 m개

1. 연관 관계(association)

표시 : 실선이나 화살표
설명 : 클래스들이 개념상 서로 연결됐음을 나타낸다. 보통은 한 클래스가 다른 클래스에서 제공하는 기능을 사용하는 상황일 때 표시한다. 

- 한 클래스가 다른 클래스와 연관 관계를 가지면 각 클래스의 객체는 해당 연관 관계에서 어떤 역할을 수행한다. 이 때 두 클래스의 역할 표현을 역할 관계 이름이라 부른다. 또한 연관관계는 방향성을 가지고 있다. 양방향은 실선으로, 단방향은 화살표로 표시된다.
- 단방향(화살표)의 경우 한 쪽은 알지만 다른 쪽은 상대방의 존재를 모른다. 사람과 핸드폰의 관계를 예로 들 수 있다.
- 양방향(실선)의 경우 두 클래스의 객체들이 서로를 인지한다. 상담의사와 환자를 예로 들 수 있다.

2. 일반화 관계(generalization)

표시 : 속이 빈 화살표
설명 : 객체지향 개념에서 상속관계이다. 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 이를 IS-A 관계라고 하며 UML에서는 일반화 관계로 모델링한다.

- 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 두 클래스 사이에는 일반화 관계가 존재한다. 이를 객체지향 개념에선 상속관계라고 합니다.
- 부모 클래스는 추상적인 개념이며, 삼각형 표시가 있는 쪽을 의미한다.
- 자식 클래스는 추상적인 개념을 물려받은 구체적인 개념입니다. 삼각형 표시가 없는 쪽입니다. 부모 클래스는 자식 클래스의 공통적인 속성과 연산을 제공하는 틀이다.

3-1. 집합관계 - 집약 관계(aggregation)

표시 : 속이 빈 다이아몬드
설명 : 클래스들 사이의 전체 또는 부분 같은 관계를 나타낸다. 전체 객체의 라이프타임과 부분 객체의 라이프 타임은 독립적이다. 즉, 전체 객체가 사라져도 부분 객체는 남아있다. (라이프 타임 독립적)

3-2. 집합관계 - 합성 관계(composition)

표시 : 속이 찬 다이아몬드
설명 : 클래스들 사이의 전체 또는 부분 같은 관계를 나타낸다. 전체 객체의 라이프 타임과 부분 객체의 라이프 타임이 의존적이다. 즉, 전체 객체가 사라지면 부분 객체도 함께 사라진다. (라이프 타임 의존적)

4. 의존 관계(dependency)

표시 : 점선 화살표
설명 : 연관 관계와 같이 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때 나타낸다. 연관 관계와 차이점은 두 클래스의 관계가 한 메서드를 실행하는 동안과 같은, 매우 짧은 시간만 유지된다는 점이다.

연관 관계와 의존 관계가 헷갈릴 수 있습니다. 둘 모두 한 클래스에서 다른 클래스를 사용하기 때문입니다. 결정적인 차이는 연관 관계는 클래스A가 클래스B를 멤버 변수로 가지고 있고, 의존 관계는 클래스A가 클래스 B의 메서드를 가지고 있습니다. 혹은 클래스 B를 메서드의 인자로 받습니다. 

5. 실체화 관계(realization)

표시 : 빈 삼각형과 점선
설명 : 책임들의 집합인 인터페이스와 이 책임들을 실제로 실현한 클래스들 사이의 관계를 나타낸다.

인터페이스란 책임이다. 어떤 객체의 책임이란 객체가 해야 하는 일 혹은 객체가 할 수 있는 일을 의미한다. 인터페이스의 경우 클래스 명에 <<interface>>를 달아준다. 그리고 인터페이스도 마찬가지로 객체 지향 개념에서 일반화 관계에 속한다.

클래스간 관계 : EX 스타크래프트

마지막으로 클래스간의 관계 일반화 관계(Generalization), 실체화 관계(Realization), 연관 관계(Association), 의존 관계(Dependency)에 대해서 스타크래프트 예제를 통해 살펴본다.

1. 일반화 관계 (Generalization)

이 경우 마린이나 매딕이 상위 클래스인 Unit을 상속받는다. Unit에선 Name, Health를 추상적으로 선언한다. 그리고 메소드로 Move()를 선언한다. 마린과 매딕은 유닛에서 상속받은 것 말고도 각자의 특수한 스킬이나 액션에 따른 다른 멤버 변수를 선언 할 수 있다. 이는 메서드를 추가하여 구현하거나, 상속받은 메서드를 추상 오버라이드해서 구현할 수 있다.

2. 실체화 관계 (Realization)

위 내용을 보면 Building을 Barracks, Factory, Bunker에서 상속받는다. 고로 세 건물은 Building의 Health와 Ammor 멤버 변수를 받아오고 Construct(), UnderAttak()기능도 부여받는다. 이 때 테란의 특수기능 건물 띄어서 이동하기를 구현하려한다. 이 기능을 똑같이 Building에 메서드로 추가하게 되면 Bunker도 띄어지는 건물이 되버리는 상황이 되버립니다. Bunker는 이동이 불가능해야합니다. 이 문제 해결을 위해 인터페이스를 사용하여 특정 기능을 특정 클래스에 약속 시킬 수 있습니다. Barracks와 Factory는 IBuilingMove의 Move(), Land(), Fly()를 반드시 사용해야한다.

개인적인 생각엔 Building 클래스를 부모로 두고 MovableBuilding, NonMovableBuilding으로 두개 나누는게 바람직할거 같다.

3. 연관 관계(Associaion)

단방향과 양방향이 존재한다. 단방향은 대상이 자신의 클래스를 모르는 상황에 쓰이며, 양방향은 서로 연관돼 있는 상태에 쓰인다.

첫 번째 연관관계에서 마린은 총이라는 클래스를 멤버 변수로 가지고 있지만, Gun은 마린이 있다는 사실을 모른다.

두 번째 집합관계 - 집약관계를 나타낸다. Factory가 파괴돼도 FactoryAddOn은 독립적으로 남아있다.

세 번째 집합질문 - 합성관게를 나타낸다. 라이프 사이클이 서로 같다.

4. 의존 관계(Dependency)

위 경우 한 객체가 다른 객체를 소유하진 않지만, 다른 객체의 변경에 따라 같이 변경을 해줘야한다. 일반적으로 아래의 상황일때 사용하게 됩니다.

1. 다른 객체를 파라미터로 받아서 그 메서드를 사용한다.
2. 객체의 메서드 안에서 다른 객체를 생성해서 리턴한다.

참고 : https://morm.tistory.com/88

참고 : https://www.uml-diagrams.org/class-reference.html