0. 들어가기에 앞서


 클래스 다이어그램은 시스템 구조를 나타내고, 객체지향 모델링의 빌딩 블록으로 사용된다.

 여러 다이어그램들 중 객체지향 언어와 직접적인 연관을 가지는 유일한 다이어그램이고, 어플리케이션의 구조 디자인, 분석, 시스템의 역할 묘사, 그리고 Reverse Engineering(역공학)에 사용될 수 있다.


 개인적인 프로젝트 경험으로, 시스템이 어떤 요소들로 구성되는지 사람들에게 설명해주고, 시스템 유지 보수를 위해서 많이 사용했었다.


1. 클래스 다이어그램


 클래스 다이어그램은 클래스클래스들 사이의 관계를 나타내는 정적 모델이다.

 클래스 다이어그램은 클래스와 그들 사이의 Relationship(관계)로 구성된다.


1.1 클래스(Class)

- 시스템 내의 오브젝트들(사람, 장소, 물건 등등)

- 시스템 내의 정보를 저장/관리한다.

- Attribute(클래스의 특성), Operation(클래스의 동작)을 가진다.


예시

환자 클래스


 이는 진료 예약 시스템에서 환자(Patient)라는 클래스다.


 Patient 클래스는 amount(진료비), insurance carrier(보험회사 명)이라는 Attribute를 가지고, make appointment(진료 예약), calcuate last visit(최근 방문일 계산), change status(상태 변환), provides medical history(진료기록 제공)이라는 Operation을 가진다.



1.2 Relationship

- 클래스들 사이의 관계

- 클래스들 사이의 선으로 표현된다.


예시


 이것도 병원 진료 예약 시스템의 일부분이다.

 Patient는 Appoinment(예약)을 스케줄하는 관계를 가진다.

 Patient 1명이 여러번 진료 예약을 할 수 있으니, Patient는 n (0 <= n)개의 Appointment와 관계를 가진다.


클래스 다이어그램 예시 


 이 그림은 클래스 다이어그램의 한 예시다.



2. Relationship의 종류


 클래스들간의 관계를 나타내는 Relationship에는 다음과 같은 것들이 있다.

 


 

 Association

Generalization 

 

 

Aggregation 

Composition 


 Association은 클래스와 클래스 사이의 관계, 혹은 클래스 자신과의 관계를 나타낸다.

 단순한 줄로 표시하고, 연관된 클래스가 서로 어떤 관계를 나타내는지를 표시하고, Multiplicity Symbol이라는 것을 가진다. 이 예시의 경우 오른쪽 클래스 하나당 왼쪽 클래스가 0개이상 관계를 가지는 예시다.


 Generalizationa kind of 관계를 나타낸다.

 객체지향 언어에서 부모 클래스 상속, 인터페이스 구현을 이것으로 표현한다.


 Aggregation은 Association의 한 종류로, 논리적인 a part of 관계를 나타낸다. A class is a part of B class라고 하면 A는 논리적으로 B와 Aggregation 관계를 가진다고 표현 할 수 있다.


 Composition은 Association의 한 종류로, 물리적인 a part of 관계를 나타낸다. A class is a part of B class라고 하면 A는 논리적으로 B와 Composition관계를 가진다고 표현 할 수 있다.


Aggregation VS Composition

 Aggregation과 Composition은 모두 포함 관계를 나타내는데, 논리적/물리적인 관계를 나타낸다는 차이만 있다.


 이게 잘 헷갈리는 부분인데, A is a part of B일 때 이 관계가 Aggregation 관계면 B가 소멸되도 A는 소멸되지 않고, Composition 관계면 B가 소멸 되면 A도 함께 소멸된다고 보면 된다.

(그리고 두 경우 모두 A가 소멸되도 B는 소멸되지 않는다.)


 예를 들어, "학생 is a part of 동아리" 관계는 Aggregation 관계이고, "바퀴 is a part of 자동차" 관계는 Composition 관계다. 동아리가 소멸되어도 학생들은 소멸되지 않기 때문에 이는 논리적인 관계고, 자동차가 소멸 될 때는 바퀴도 함께 소멸되므로 물리적인 관계라고 볼 수 있다. (바퀴를 따로 떼서 파는 경우는 생각하지 말도록 하자.)


3.클래스 다이어그램 간소화


 클래스 다이어그램이 너무 복잡하면 이해하기가 어려울 수 있기 때문에, 클래스 다이어그램은 간소화 과정을 거칠 필요가 있다.
 클래스 다이어그램은 다음과 같은 방법으로 간소화 할 수 있다.

- Concrete Class만 묘사한다.

- view 메커니즘을 적용하여 필요한 클래스 몇가지만 골라서 묘사한다.

- 일부 클래스들을 패키지로 묶어서 취급한다.


 클래스에는 Concrete Class와 Abstract Class가 있다. 그 중 Concrete Class만 묘사하여 다이어그램을 간소화하는 방법인데, 이는 잘 고려해보고 써야한다.

 어떤 Concrete Class인 CClass가 Abstract Class인 AClass를 상속받고 있고, 다른 외부 클래스들이 주로 AClass와 관계를 가지는 경우, 이 방법을 쓰면 다이어그램을 이해하기 어려워지는 원인이 될 수 있기 때문이다.


 View 메커니즘은 원래 데이터베이스에 나오는 개념이다.

 데이터베이스에서 View는 필요한 데이터만을 원하는 형태로 골라서 본다는 개념인데, 이를 클래스 다이어그램에도 적용하여 상황에 따라 필요한 클래스들만 묘사하여 다이어그램을 간소화하는 방법이다.


 연관된 클래스들끼리 묶어 패키지로 만드는 방법이다. 패키지로 취급하면 다이어그램이 더 간단해질 수 있다.



4. 레퍼런스

System Analysis & Design 5th - WILEY

https://ko.wikipedia.org/wiki/%ED%81%B4%EB%9E%98%EC%8A%A4_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8 - 위키피디아 클래스 다이어그램

https://www.tutorialspoint.com/uml/uml_class_diagram.htm - Tutorial Point. Class Diagram

'IT 관련 > 소프트웨어 공학' 카테고리의 다른 글

Activity Diagram (액티비티 다이어그램)  (0) 2019.11.06
Use Case Diagram  (1) 2019.10.30
블로그 이미지

서기리보이

,