-
Class Diagram (클래스 다이어그램) - BasicSoftware/UML 2018. 7. 31. 00:32반응형
Class Diagram은 UML의 구조 다이어그램으로서 클래스 내부 구성 요소 및 클래스 간의 관계를 도식화하여 시스템의 특정 모듈이나 일부 또는 전체 구조를 나타낸다.
1. 목적
- 개념 기술
Class Diagram을 통해 문제 도메인의 구조를 나타낼 수 있다. 이 때의 Diagram은 실제 사물 (Object) 혹은 개념 (추상적 개념 포함) 을 나타낸다. 그렇기에 이렇게 만들어진 Diagram은 실제로 구현될 소스코드와는 다를 수 있으며 그 의미나 해석도 경우에 따라 달라 질 수 있다. - 설계(명세) / 구현
실제 소프트웨어의 설계 혹은 구현을 위한 용도로 사용된다. Class Diagram은 앞으로 구현 할 혹은 구현된 실제 클래스를 의미하므로 소스코드와의 관계가 매우 깊으며 Class Diagram이 가지는 의미가 모호성을 띄지 않도록 주의해야 한다. 앞서 이야기 한 개념 기술의 목적 보다는 지켜야 할 제약 및 규칙 등이 많으며 약속된 형식을 최대한 지켜야 한다.
그림 1. 목적에 따른 Class Diagram(좌: 개념 기술, 우: 설계 및 구현)
2. Class Diagram 구성 요소
-
Class Diagram은 Class name과 Attribute 그리고 Operation으로 구성되어 있다. 기본적으로 이 3가지가 Diagram을 구성 요소로써 존재하고 Class Name, Attribute, Operation 순으로 위에서 아래로 배치된다.
그림 2. 가장 기본적인 형태의 Class Diagram
- 그럼 지금 부터 이 구성 요소들에 대해서 더 자세히 알아 볼텐데 Class Name은 딱히 추가로 설명할 내용이 없으니 생략하고 Attribute와 Operation에 대해서 설명하도록 하겠다.
- 속성 (Attribue)
그림 2를 보면 알 수 있듯이 Class Name과 Operation 사이의 중간 층에 위치한다. 보통 명사형으로 많이 표현이 되며 실제 구현 된 Class를 기준으로 Attribute는 Class의 멤버 변수로 생각하면 쉽게 이해할 수 있을 것이다. 기본적인 문법은 아래와 같다.
| visiblity name : attribute type [ multiplicity ] = default value
| 접근제어자 이름: 속성 타입[ 배열 개수 ] = 기본값
| + mNameCardList : NameCard[10]
| - mSpeed : Integer = 0
- 행동 (Operation)
Diagram에서 가장 하단에 위치하고 있으며 해당 Class가 수행할 수 있는 Operation들을 가진다. Class method를 생각하면 쉽게 이해할 수 있을 것이다. 기본 문법은 아래와 같다.
| visibility name (parameter list) : type of value returned
| 접근제어자 이름 (매개 변수 혹은 인자 리스트) : 반환 타입
| + accelerate(Float) : Float
| - findPerson(String, Integer) : Person
- 참고
| Stereo type: <> 으로 표기.
보통 UML 문법으로 나타낼 수 없는 추가 의미나 목적을 표기
| Static(정적) Attribute / Operation인 경우 밑줄을 그어 표기
| Abstract(추상) Operation(Method)은 이텔릭체로 표기
| 접근제어자
+
Public
#
Protected
-
Private
~
Package
표 1. 접근 제어자
- 예시
-
1) Abstract Class와 Interfac
아래는 Abstract class(추상 클래스)와 Interface(인터페이스)를 Class Diagram으로 표시한 것이다.
Abstract class의 클래스명에 abstract을 나타내는 이텔릭체로 표시, 상수 값인 TAG에는 static 값을 의미하는 밑줄이 표시되어 있음을 확인할 수 있다.그림 3. Abstract Class와 Interface
-
참고 > Interface
: Interface는 Attribute가 없고 구현부가 존재하지 않는 Operation만을 가지는 Abstract Class 이다. 그렇기에 Abstract class와 동일하게 Class name이 이텔릭체로 표현되었다. 또한 Interface가 Class Diagram으로 표현될 때는 일반적으로 해당 클래스가 Interface임을 알리는 Stereo type을 추가한다.
- 2) Nested Class
아래는 Nested Class(중첩 클래스)를 표현한 Diagram 이다. Inner Class의 경우 Outer Class명 뒤에 "."을 찍고 Inner Class 명을 붙이면 된다.그림 4. Nested Class 표현(Outer Class: 좌, Inner Class: 우)
3. Class Relationship (클래스 관계)
-
Class 간의 논리적 / 물리적 관계를 나타낸다. 선과 선 끝의 머리 모양을 통해 관계를 구분짓는다
- Dependency (연관)
클래스가 다른 클래스와의 의존성을 가지고 있는 경우.의존 클래스의 상태 변화는 즉 이를 참조하고 있는 클래스의 상태 변화(의존)를 의미한다.
-
표기 방법: 점선 + 화살표
그림 5. Dependency 예시
-
위 예시를 살펴보면 Vehicle이라는 Abstract Class에 initSeatPosition() method가 있음을 알 수 있다. 해당 Method는 드라이버의 체형에 따라 자동차 시트 포지션을 설정해주는 Operation으로 Method 인자로 Driver라는 객체를 전달 받는다. 이 때 Vehicle과 Driver Class간의 의존 관계가 성립된다고 할 수 있다. 이처럼 의존 클래스(Driver Class)는 Vehicle의 Life cycle하고는 무관하게 해당 Method에서만 존재한다.
- Association / Directed Association (연관)
Association은 객체간의 연관 관계를 나타낸다. 객체 지향에서 Association은 보통 인스턴스 변수로로의 참조를 의미한다. 즉 상대 클래스의 인스턴스를 Attribute로 가질 때 Association Relationship(연관 관계)이 있다고 한다. 이 때의 관계는 명료한 모델링을 필요로 하며 보통 양방향성을 나타내는 Association(Standard)과 단방향성을 나타내는 Directed Assocation이 주로 사용된다.
-
표기 방법: 실선(Association) , 실선 + 화살표 (Directed Association)
그림 6. Association
- 그림 6의 Vehicle과 Driver 클래스는 서로의 인스턴스 객체의 참조 필드를 가진다. (양방향성) 이 때실선 끝에 있는 숫자와 * 표시가 있음을 알 수 있다. 이를 우리는 Multiplicity라고 부르는 데 참조 가능한 인스턴스의 수를 의미 한다. 표기 방법과 의미는 아래와 같다.
Indicator
Meaning
0..1
0 또는 1
1
1 개
*
다수 (0 포함)
1..*
1게부터 다수(0 제외)
N..M
N개부터 M개까지
표 2. Multiplicity
-
이번엔 Directed Association에 대한 예시를 살펴 보자.
-
그림 7. Directed Assocation
-
Driver는 인스턴스화 된 BodyType 객체 필드를 참조하고 있지만 BodyType은 그렇지 않다. 즉 Driver는 BodyType에 대해서 알고 있지만 BodyType은 Driver에 대해서 전혀 알고 있지 않다. 이런 경우 지금과 같이 화살표를 참조되는 클래스쪽 실선 끝에 붙여 방향성을 나타낸다.
- Aggregation (집합연관)
Association 개념에서 조금 더 확장 된 개념으로 전체와 부분의 관계를 나타낸다. 두 개의 클래스가 서로 연관 관계를 가지며 전체 - 부분 관계를 가질 때 Aggregation으로 표기한다. 다만 여기서 중요한 점은 부분이 되는 클래스의 라이프 사이클은 전체가 되는 클래스의 라이프 사이클과 서로 관련성이 없다는 점이다. 즉 전체 클래스가 소멸되었다고 해서 부분 클래스가 사라지는 것은 아님을 의미한다. (서로 독립적으로 존재)
-
표기 방법: 실선 + 속이 빈 마름모
그림 8. Aggregation
public class Tractor {
Attachment mAttachment;
Tractor (Attachment attachment) {
mAttachment = attachment;
}
void attachWorkMachine(Attachment attachment){
mAttachment = attachment;
}
}
- 이해를 돕기 위해 이번에는 코드를 한번 추가해 보았다. Tractor라는 클래스가 있고 이 클래스는 mAttachment라는 멤버 변수를 통해 Attachment 객체를 참조하고 있다. 이 때 mAttachment는 Tractor의 생성자 혹은 attachWorkMachine이라는 method안에서 실질적인 레퍼런스 값을 가지게 되며 Tractor의 라이프 사이클과 무관하게 존재한다. (외부에서 생성된 인스턴스 값을 참조)
- Composition (합성연관)
Composition은 Aggregation처럼 전체와 부분의 관계를 띄고 있지만 부분에 해당하는 클래스의 라이프 사이클이 전체를 의미하는 클래스의 라이프 사이클과 동일하다는 점에서 차이점을 보인다.
(전체에 해당하는 클래스 소멸 시 부분 클래스도 함께 소멸)
-
표기 방법: 실선 + 속이 빈 마름모
그림 9. Composition
public abstract class Vehicle {
PowerSteeringSystem mPowerSteeringSystem;
Vehicle () {
mPowerSteeringSystem = new PowerSteeringSystem();
}
}
-
PowerSteeringSystem(동력조향장치)은 Vehicle 클래스의 생성자에서 인스턴스가 생성되어 Vehicle 클래스가 소멸될 때 함께 소멸된다. 즉 PowerSteeringSystem은 Vehicle 클래스 없이 독립적으로 존재할 수는 없는 것이다.
-
부분을 의미하는 클래스가 독립적으로 존재할 수 있냐 없냐가 Aggregation과 Composition을 구분하는 가장 큰 차이라 할 수 있다.
- Generalization (일반화)
Generalization은 "is A" 관계를 가지는 두 클래스간의 관계를 의미한다. 객체 지향에서는 Generalization (일반화)를 부모 클래스와 자식 클래스간의 "상속" 관계로 해석된다. 자식 클래스들은 부모 클래스가 가지는 공통 특징 (속성 or 행동)을 가진다.
-
표기 방법: 실선 + 속이 빈 삼각형
그림 10. Generalization
-
Vehicle이라는 부모 클래스가 있고 이를 상속 받은 SUV와 Tractor라는 부모 클래스가 있다. SUV와 Tractor는 Vehicle이 가지는 Attributes와 Operations를 공통적으로 지니고 있고 더불어 각자만의 추가 attributes와 operation을 가진다. SUV의 경우 오프로드 모드 전환을 위한 Operation과 Tractor는 작업기 부착을 위한 Operation을 가진다.
- Realization (실체화)
객체지향에서 Realization은 명세화 된 혹은 정의만 된 Operation을 실체화하는 것을 의미한다. 즉 Interface로 명세화 된 기능을 실제 기능으로서 구현하는 것을 말하는데 Interface의 Implement를 생각하면 된다.
- 표기 방법: 점선 + 속이 빈 삼각형
+
그림 11. Realization -
IDrive라는 Inteface는 accerate(), break()라는 operation을 정의(명세) 되어 있고 이를 구현한 Class가 Vehicle이다. Vehicle라는 클래스에서 해당 Operation들은 실제 기능으로써 구현 되어 진다.
그림 12. Class Diagram (전체)
반응형'Software > UML' 카테고리의 다른 글
시퀀스 다이어그램 [Sequence Diagram] (0) 2018.09.10 Use Case Diagram (0) 2018.07.10 댓글
- 개념 기술