Class Diagram 기본
참고 http://www.uml-diagrams.org/class-diagrams-overview.html
1. 개요
1.1 UML 다이어그램 종류
- Structure Diagram : 정적이고, 구조 표현을 위한 다이어그램
- Behavior Diagram : 동적이고, 시퀀셜한 표현을 위한 다이어그램
- 다른 사람들과의 의사소통 또는 설계 논의
- 전체 시스템의 구조 및 클래스의 의존성 파악
- 유지보수를 위한 설계의 back-end 문서
- Access : 다이어그램을 보고 직관적으로 이해할 수 있도록 의미있고 명확한 이름을 부여한다.
- Simplicity : 불필요한 내용을 제외하고 모델을 간결하게 그려야 한다. (Getter, Setter, Constructor는 생략이 가능하다)
- Cost : UML을 작성하는 것이 개발비용보다 더 들어가는 경우도 있으므로 비용을 고려하여 작성여부를 검토하는 것이 좋다.
- Class
- Relationship
Class name should be centered and in bold face, with the first letter of class name capitalized (if the character set supports upper case).
- 상자의 가운데에 위치해야 한다.
- 굵은 글씨체로 기입해야 한다.
- 첫번째 글자는 대문자로 기입해야 한다.
[visiblity] property-name : property-type
- + : public
- - : private
- # : protected
- ~ : package
class diagram |
source code |
|
package com.tistory.devdasom;
public class SearchService {
private SearchEngine engine;
private SearchRequest query;
...
}
|
[visiblity] operation-name (property1, property2, ...) : return-type
operation-name은 메서드명이다. 메서드의 파라미터는 ( ) 괄호 안에 작성하면 되고 작성방법은 property와 동일하다. 리턴타입은 : 콜론 뒤에 작성한다. 다음 클래스 다이어그램과 소스코드를 비교하며 확인해보자.
class diagram |
source code |
|
package com.tistory.devdasom;
public class SQLStatement {
public ResultSet executeQuery(String sql) { ... }
protected Boolean isPoolable() { ... }
int getQueryTimeout() { ... }
void clearWarnings() { ... }
}
|
4. Relationship
UML에서 Relationship은 클래스의 관계를 표현하기 위한 모델링 언어이다.
4.1 Relationship 종류
이름 |
의미 |
표기법 |
설명 |
|
Generalization |
상속관계 |
|
class A가 Super class class B가 Sub class |
|
Dependency |
지역변수로 사용하거나, 파라미터로 사용하는 등 멤버변수로 갖지 않고 사용하는 관계 |
|
class A의 메서드가 class B의 메서드를 호출하거나, class B를 메서드의 인자로 받는 등 사용하는 경우 |
|
Realization |
Dependency의 한 종류이고, 인터페이스를 구현하는 관계 |
|
interface A가 있고, class B가 interface A를 구현한 경우 |
|
Association |
Dependency와 달리 멤버변수로 가지고 사용하는 관계 |
|
class A가 class B를 멤버변수로 가지고 있고, 사용하는 경우 |
|
Aggregation |
Association의 한 종류이며 전체와 부분의 관계를 가지는 클래스에 적용된다. 멤버변수로 가지고 있지만, new를 직접하지 않는 관계 |
|
class A가 class B를 멤버변수로 가지고 있는 경우. class A가 전체개념이고, class B가 부분의 개념이다. 하지만 class A가 직접 class B를 new 하지는 않는다. |
|
Composition |
Association의 한 종류이며 전체와 부분의 관계를 가지는 클래스에 적용된다. 멤버변수로 가지고 있고, Aggregation과 달리 직접 new를 하는 관계 |
|
class A가 class B를 멤버변수로 가지고 있는 경우. class A가 전체개념이고, class B가 부분의 개념이다. class A가 직접 class B를 new 해서 생성한다. |
|
Nested |
Inner Class의 관계 |
|
class A의 안에 class B가 이너클래스로 존재하는 경우 |
|
4.2 Generalization
상속관계의 클래스를 실선으로 연결하고 Super class 쪽에 빈 삼각형을 그린다.
4.3 Dependency
4.3.1 Dependency
Dependency는 의존관계이다. 단, 한 클래스가 다른 클래스를 멤버변수로 가지지 않고 지역변수, 파라미터 등 일시적으로 사용하는 경우에 성립되는 관계이다.
다음 클래스 다이어그램과 소스코드를 비교해보자.
Sale 클래스가 ProductDescription 클래스를 사용하고 있지만 멤버변수로 가지고 있지는 않다.
class diagram |
source code |
|
public class Sale {
...
void updatePriceFor(ProductDescription description) {
description.xx();
...
}
}
|
4.3.2 Realization
Realization은 인터페이스와 구현 관계이다. 두 클래스를 점선으로 연결하고 인터페이스쪽에 화살표를 그린다.
다음 클래스 다이어그램과 소스코드를 비교해보자.
class diagram |
source code |
|
class Person {
String firstName;
String lastName;
}
class Professor extends Person {
Dollars salary;
}
class Student extends Student {
String major;
}
|
4.4 Association
4.4.1 Association
Association은 한 클래스가 다른 클래스를 멤버변수로 가지는 경우이다. 두 클래스를 실선으로 연결하고 사용 당하는 클래스쪽에 화살표를 그린다.
다음 클래스 다이어그램과 소스코드를 비교해보자.
이 클래스 다이어그램은 화살표 근처에 -address 라는 표현이 되어 있다. 이것은 Person이 Address라는 클래스를 address라는 변수명으로 가지고 있다는 것을 의미한다. - 표시는 private으로 가지고 있다는 것을 의미한다. 그래서 class diagram에서의 Person에는 address라는 필드가 없지만 코드를 구현할 때에는 -address를 필드로 구현해야 한다.
class diagram |
source code |
|
class Person {
private String name;
private Address address;
public void doSomething() { ... }
}
class Address {
...
}
|
여기서 중요한 것은, 화살표가 없거나 한쪽만 있거나 양쪽 다 있는 경우 등 다양하게 있다. 화살표가 아예 없다는 것은 Unspecifiy로 구현하는 사람이 적절하게 구현하면 되는 것이다. 한쪽만 있다는 것은 그 한쪽은 확실하게 구현해야 한다는 것이고 양쪽 다 있는 경우는 서로를 멤버변수로 가지고 있다는 것을 의미한다. (심화편에서 자세하게 설명할 예정입니다!)
4.4.2 Aggregation
Aggregation은 한 클래스가 전체의 역할을 하고 다른 클래스가 부분의 역할을 하는 전체-부분 관계일 때 사용되는 표현이다. Composition 또한 전체-부분 관계에서 사용되는 표현이며 둘의 차이는 전체가 부분 클래스를 new 하는지 여부이다. Aggregation은 전체 클래스가 부분 클래스를 new하지 않고 외부에서 주입받는다. 반면 Composition은 전체가 부분 클래스를 직접 new 하여 사용한다. 이 차이를 기억하며 다음 클래스 다이어그램과 코드를 비교해보자.
다음 코드 중 Car 클래스에는 Wheel이나 Engine을 new하는 코드가 없는 것을 볼 수 있을 것이다. 이는 부분 클래스(Engine, Wheel)을 외부에서 생성한 뒤 Car 클래스에 주입해준다는 의미이고, 결국 이들은 서로 다른 생명 주기를 가지게 된다. 이것이 Composition과의 차이이다.
class diagram |
source code |
|
class Car {
private Engine m_Engine;
private Wheel[] m_Wheel;
public void setEngine(Engine m_Engine) {
this.m_Engine = m_Engine;
}
public void setWheel(Wheel[] m_Wheel) {
this.m_Wheel = m_Wheel;
}
}
|
4.4.3 Composition
Composition은 Aggregation과 거의 동일하고 다른점은 사용하는 클래스에서 직접 new를 해준다는 점이다. 정확히 말하자면 부분 클래스의 생명주기를 관리하는 경우이다. 다음 클래스 다이어그램과 소스코드를 비교해보자. Aggregation과 비교하여 보자.
Telephone의 생성자에서 new를 통해 각 클래스를 생성하는 것을 볼 수 있다. Aggregation관계에서는 new가 없지만, Composition 관계에서는 전체클래스가 부분클래스의 생명주기를 관리하는 것이다. 이 차이점을 확실하게 이해하자!
그리고, 정확하게는 Composition관계에서는 전체 클래스가 부분 클래스의 생명주기를 관장하는 것이지 new를 할때만 Composition 관계가 아니라는 것을 이해해야 한다. 그렇다면 new를 하는 위치가 꼭 생성자가 아니어도 상관없다는 것도 이해할 수 있어야 한다.
class diagram |
source code |
|
class Telephone {
private Button m_Button;
private Headset m_Headset;
public Telephone () {
m_Button = new Button();
m_Headset = new Headset();
}
}
|
5. 연습
다음 클래스 다이어그램은 도서관 관리 시스템이다. 이 다이어그램을 코드로 구현해보고, 구현한 코드를 UML 툴로 표현하였을 때 동일한 결과가 나오는지 확인해보자. (궁금한 것은 다솜이에게 질문주세요!ㅋㅋ)
(*이나 0..* 등 앞서 설명하지 않은 내용은 건너뛰고 구현해도 된다!)
코드 하이라이터 정보
<pre class="prettyprint linenums lang-java" style="font-size: 10pt; font-family:Consolas, 'Liberation Mono', Menlo, Courier, monospace !important;">
여기에 코드
</pre>
'UML' 카테고리의 다른 글
| [UML] Class Diagram 심화 (편집중) (0) | 2017.04.15 |
|---|
Comments