UML
UML(Unified Modeling Lauguage)이란 객체지향 프로그래밍이 발전하면서 모델링 언어의 표준화에 따라 만들어진 언어이다. 이거 모르면 객체 지향 언어 해봤다고 말할 자격 없다. UML은 다이어그램으로 표현되며 다이어그램도 여러가지가 있으나 이 중 많이 쓰이는 것은 Class Diagram, Usecase Diagram, Sequence Diagram 정도이다. 아래는 Class Diagram의 예이다.
관련 프로그램
UML을 그릴 수 있는 프로그램 중 무료로 얻을 수 있는 대표적인 프로그램은 StarUML이다. 현재는 상용버전인 StarUML NS도 출시되었지만 무료 버전도 다운로드 가능하다. 아래 주소에서 다운 가능하다.
Class Diagram
UML 중 가장 중요하고 많이 쓰이는 다이어그램이다. 이것만 알아도 프로그램 설계하는데 큰 도움을 준다.
기본 표기 형식
이름 뒤에 붙어있는 type은 생략 가능하다. (그림은 ActionScript 3.0 형식의 변수, 함수 선언) 그림에서 variable과 method 앞에 붙어 있는 기호는 다음을 의미한다.
| 기호 | 의미 |
|---|---|
| + | public |
| - | private |
| # | protected |
클래스의 실제 코드에 들어가는 모든 변수와 함수를 넣을 필요는 없고 중요한 것만 넣으면 된다. 클래스 다이어그램의 목적이 코드 구조를 쉽게 보기 위한 것이기 때문이다. 프로그램의 전체 클래스를 다 표현하는 경우에는 변수, 함수까지 포함하면 너무 많아지므로 suppress 기능을 통해 클래스 이름만 표현하기도 한다.
관계 표현
클래스는 다른 클래스에 포함되기도 하고 상속관계를 이루기도 하는 등 여러 가지 종류의 관계를 가질 수 있다. 이를 유형별로 분류하면 다음 그림과 같다.
연관 관계
일반적으로는 위 그림처럼 표현하나 life cycle(클래스 또는 그 인스턴스의 생성, 소멸 주기)에 따라 aggregation, composition으로 분류할 수도 있다.
aggregation
composition
양방향 연관 관계
연결된 클래스들이 서로의 존재를 알고 있다는 의미이다. 위의 UML 을 해석하자면 House 와 Person 클래스는 서로의 존재를 알고 있으며, 반드시 한 사람 이상이 House에 속해야 한다는 것을 뜻한다.
단방향 연관 관계
House 클래스는 Person 클래스의 존재를 알고 있지만, Person 은 House 클래스의 존재를 모르고 있다고 이해하면 된다. 이와 같은 경우는 House 클래스만 Person 클래스에 대한 참조값을 가지고 있고, Person 은 House 에 대한 어떠한 참조값도 가지고 있지 않는다.
의존 관계
