지난 포스팅에서는 UML의 역사 및 구성 요소에 대해 간단히 알아보았다. 오늘은 지난 포스팅에 이어 UML의 구성 요소중 도해(Diagram)에 관해 이야기 하겠다. 'UML에 대해 하나도 몰라!'라고 한다면 지난 포스팅을 먼저 참고하길 바란다.
UML Diagram
여기서는 주요 Diagram 몇 가지에 대한 간단한 설명 및 표기법을 알아본다.
1. Use Case Diagram
시스템이 제공할 서비스(Use Case)와 그 이용자(Actor)의 관계(Association)를 표현한 것으로 주로 개발 주기 초기에 사용자의 기능적 요구 사항을 기술하는데 사용한다.
Use Case Diagram의 표기법은 다음 그림1과 같다.
<그림1. Use Case Diagram, http://en.wikipedia.org/wiki/File:Use_case_restaurant_model.svg>
2. Activity Diagram
Activity(또는 Action)의 실행 순서나 실행 조건, 실행자의 관계를 표현한 것으로 업무 영역, 시스템 영역의 처리 흐름을 파악하기 위한 Diagram이다. 주로 특정 비즈니스 프로세스, 오퍼레이션, Use Case의 내부 업무 흐름 등을 파악할 때 사용한다.
Activity Diagram의 표기법은 다음 그림2와 같다.
<그림2. Activity Diagram, http://en.wikipedia.org/wiki/File:Activity_conducting.svg>
3. Sequence Diagram
객체(Object) 사이의 메시지 교환을 나타내는 Diagram으로 객체 간의 동적인 상호 관계를 시간 순서에 따라 표현한 것이 특징이다. 또한 Use Case의 기능을 구체적으로 실현하며 실제 프로그램으로 구현 가능하게 자세히 작성해야 한다.
Sequence Diagram의 표기법은 다음 그림3과 같다.
<그림3. Sequence Diagram, http://en.wikipedia.org/wiki/File:CheckEmail.svg>
4. Class Diagram
Class 구조를 나타내는 Diagram으로 Class들을 정의하고 그들 간에 존재하는 관계를 다양한 방식으로 표현하는 것이 특징이다.
Class의 표기 및 Class간의 다양한 관계 표기법은 다음과 같다. 하나씩 살펴보도록 하자.
Class 표기
UML에서 Class Members 표기는 다음과 같다.
+ |
Public |
- |
Private |
# |
Protected |
/ |
Derived (can be combined with one of the others) |
_ |
Static |
~ |
Package |
<표1. Class Members 표기법>
Class는 크게 Class Name, Attributes, Operation 이 세 가지로 나누며 Class의 표기는 다음 그림4와 같다.
<그림4. Class 표기법1, http://www.uml-diagrams.org/class-diagrams.html>
Class Members도 사용하며 Class 좀 더 자세히 표현하자면 다음 그림5와 같다.
<그림5. Class 표기법2, http://www.uml-diagrams.org/class-diagrams.html>
위의 Class를 Code로 구현해보자면 다음 그림6과같이 표현할수 있으며, 각 용도에 맞게 Body 부분을 채우면 된다.
<그림6. 그림5에 대한 Java Code >
Class간 관계 표기
Class Diagram에서 절대 빼놓을수 없는것 중 하나가 Class사이의 관계라고 할수 있다. 따라서 여기서는 Class 사이의 관계 표기법과 이를 어떻게 Code로 구현하는지 알아보고자 한다.
먼저 Class 사이의 관계는 다음 그림7과같이 표현하며, 차례대로 하나씩 설명하겠다.
<그림7. Class간 관계 표기법>
(1) Generalization (일반화)
일반화란 Super(부모) Class와 Sub(자식) Class 사이의 관계를 나타낸다. Super Class는 여러 Sub Class들의 공통적인 특징을 뽑아내어 담고 있는 Class로서, Super Class와 Sub Class사이에는 'is a' 관계가 성립한다. 이 관계는 객체 지향에서 상속을 의미한다.
아래 그림8은 일반화 표기법과 그 표기에 따라 Code로 구현한 예제이다. 이 예제에서 Super Class는 User이고, Sub Class는 Customer와 Admin이며, 이를 통해 두 Class사이에 'is a'관계가 성립함을 알수 있다.
- Customer is a User.
- Admin is a User.
<그림8. 일반화>
위의 그림8과 같이 일반화(상속)는 실선과 속이 빈 삼각형을 이용하여 삼각형이 Super Class쪽을 향하도록 표시하며, 자바에서 extends 키워드를 사용하여 구현한다.
또한 Sub Class에서는 Super Class의 Attributes(필드)와 Operation(메소드)을 상속 받아 사용할수 있으며, 추가로 필요한 Attributes와 Operation을 추가하거나 Operation을 Overriding(오버라이딩)하여 재정의를 할수도 있다.
(2) Realization (실체화)
실체화란 Interface(인터페이스)의 Signature만 있는 Operation(메소드)을 Overriding(오버라이딩)하여 Class마다 알맞은 기능을 할수 있도록 구현하는 것을 의미한다.
아래 그림9는 실체화 표기법과 그 표기에 따라 Code로 구현한 예제이다.
<그림9. 실체화>
위의 그림9와 같이 실체화의 표기법은 2가지가 있다.
- Interface(인터페이스)를 Class처럼 표시하고 스테레오 타입 «interface»를 Class Name 위에 적는다. 또한 실체화는 점선과 비어있는 삼각형을 이용하여 삼각형이 Interface(인터페이스)쪽을 향하도록 표시한다.
- Interface(인터페이스)를 원으로 표시하고 원 밑에 인터페이스의 이름을 적는다. 또한 Interface(인터페이스)와 Class 사이의 관계는 실선으로 연결하여 나타낸다.
이와 같은 실체화는 자바에서 implements 키워드를 사용하여 구현한다.
(3) Dependency (의존)
의존은 Class Diagram에서 가장 많이 사용되는 관계로서 어떤 Class가 다른 Class를 참조하는 것을 나타낸다. 참조되어지는 Class가 변경될 경우 참조하는 Class는 영향을 받지만 그 반대의 경우는 성립되지 않는다.
아래 그림10은 의존 표기법과 그 표기에 따라 Code로 구현한 예제이다. 이 예제에서 참조되어지는 Class는 User이고, User Class를 참조하는 Class는 Schedule이다.
<그림10. 의존>
위 그림10과 같이 의존은 점선 화살표를 이용하여 화살표의 끝이 참조하는 Class쪽을 향하도록 표시하며, 자바에서 참조의 형태는 Operation(메소드) 안에서 참조되어지는 Class의 객체의 생성, 사용, 반환 및 Operation(메소드) 호출 및 매개변수로 참조되어지는 Class의 객체를 받아 구현하는 방법 등 여러가지가 있다.
단, 해당 객체의 참조를 계속 유지하지는 않는다.
(4) Association (연관), Directed Association (방향성 있는 연관)
연관은 Class로 부터 생성된 Instance(인스턴스)들 사이의 관계를 나타낸다. 상대 Instance를 가리킬수 있는 속성을 가지며 표현은 Role Name(역할명)을 사용한다. 또한 각 Instance의 수(Multiplicity : 다중도)도 표시할수 있다.
아래 그림11은 연관 표기법과 그 표기에 따라 Code로 구현한 예제이다.
<그림11. 연관>
Instance 수(다중도) 표현
0..1 |
0 또는 하나의 Instance |
0..* 또는 * |
0부터 무한까지의 Instance |
1 |
하나의 Instance |
1..* |
적어도 하나 이상의 Instance |
n..m | n부터 m까지의 Instance |
<표2. Instance 수 표기법>
방향성
연관의 방향성에는 양방향과 단방향 두 가지가 있다.
첫 번째로 양방향은 Association(연관)으로 실선 하나로 Class사이를 연결하여 표시하며, 위 그림11의 가장 왼쪽 예제에 해당한다. 이는 'User와 Address는 관련이 있다'는 의미이다. User가 Address를 참조할 수도, Address가 User를 참조할 수도 있다.
두 번째로 단방향은 Directed Association(방향성있는 연관)으로 실선과 화살표로 Class 사이를 연결하여 표시하며 위 그림11의 가운데 예제에 해당한다. 이는 'User가 Address를 참조한다'는 의미이다.
참고로 위 그림11의 가장 오른쪽 예제는 가운데 Diagram과 비슷한 의미를 가지고 있지만 조금 다른 형태인 속성 표기법으로 나타낸 것이다. 보이는 바와 같이 Role Name(역할명)은 보통 Class의 Attributes(필드)명이 된다. 가운데 Diagram과 다른 점은 Data Type이 List라는것까지 알려준다는 것이다.
가운데 예제와 가장 오른쪽 예제가 같은 의미를 가지도록 가운데 예제를 고쳐본다면 아래 그림12와 같다.
<그림12. 같은 의미의 연관 관계 표기법>
(5) Aggregation(집합 연관)
집합 연관은 연관의 한 종류로서 '전체-부분' 관계를 나타내며, '전체-부분' 관계는 'has a'관계가 성립한다. 유의해야할 것은 전체와 부분이 서로 독립적이라는 점이다. 즉, 부분이 없다고해서 전제에 큰 영향을 미치지 않는다.
아래 그림13은 집합 표기법과 그 표기에 따라 Code로 구현한 예제이다.
<그림13. 집합>
위 그림13과 같이 집합 연관은 속이 빈 다이아몬드를 전체 쪽을 향하도록 하며, 이를 실선 화살표로 부분 쪽에 연결하여 표시한다. 이를 통해 전체와 부분을 알수 있다. 위 예제에서 전체는 Computer이고, 부분은 각각 Monitor, Keyboard, Body이다.
위에서 전체와 부분은 서로 독립적이라고 설명 했는데, 이에 대해 위 그림13의 예제로 설명하자면 부분이 되는 Keyboard가 없다고해서 Computer가 아니라고 할수 없다. 한마디로 Keyboard가 없어도 Computer는 Computer이다.
이는 전체와 부분이 서로 생명 주기가 다르다는 것을 의미하기도 한다.
(6) Composition(복합 연관)
복합 연관도 집합 연관과 마찬가지로 연관의 한 종류로서 '전체-부분' 관계를 나타내며, '전제-부분' 관계는 'has-a'관계가 성립한다. 하지만 주의해야할 점은 집합과 다르게 전제와 부분이 독립적이지 않다. 즉, 부분이 전체에 매우 큰 영향을 미친다.
아래 그림14는 합성 표기법과 그 표기에 따라 Code로 구현한 예제이다.
<그림14. 합성>
위 그림14와 같이 복합 연관은 속이 채워진 다이아몬드가 전체쪽으로 향하도록 하며, 이를 실선 화살표로 부분 쪽에 연결하여 표시한다. 집합 연관과 마찬가지로 이를 통해 전체와 부분을 알수 있다. 위 예제에서 전체는 Player이고, 부분은 각각 Screen, Controller이다.
위에서 전체와 부분은 서로 독립적이지 않다고 설명 했는데, 이에 대해 위 그림14의 예제로 설명하자면 부분이 되는 Controller가 없다면 Player는 Player가 아니다. 이해를 좀 더 돕기 위해 전체인 자동차와 부분인 엔진을 예로 들자면 자동차에 엔진이 없다면 자동차의 생명은 끝난다고 할수 있고, 엔진이 없는 자동차는 자동차라 할수 없다.
이는 전체와 부분이 서로 생명 주기를 같이 한다는 것을 의미한다.
결론
지난 포스팅에서는 UML이 왜, 어떻게 탄생했으며 무엇인지 맛보았고, 이번 포스팅에서는 UML에서 꼭 알아두어야 할 Diagram에 대해 설명하였다.
특히 Class Diagram에 대해 꼭 익혀두길 바라는 바다. Class Diagram을 어떻게 그리는지도 중요하지만 Class Diagram을 Code로 옮길수 있어야 한다.
Class Diagram을 그리면서 동료와 함께 실컷 설계해 두었는데 이를 Code로 옮기지 못한다면 다 무슨 소용이겠는가.
맨 마지막에 설명한 집합과 합성은 명확한 정의가 없어 많은 사람들이 혼란스러워하고 있고 아직도 논란이 되고있는 부분중에 하나 이다. 때문에 집합과 합성을 사용할 때에는 더 각별한 주의를 요한다.
참고 문헌
위키 : http://en.wikipedia.org/wiki/Class_diagram
