[UML Class Diagram]

이 글은 Unified Modeling Language(UML)에서 사용되었던 필수 다이어그램에 관한 기술자료 시리즈입니다. 시퀀스 다이어그램에 대해 설명했던 이전 기술자료에서는, UML 1.4 스팩에서OMG의 Adopted 2.0 Draft Specification of UML (UML 2)로 초점을 이동했습니다. 이 글에서는 UML 2에 도입된 새로운 다이어그램 카테고리인 Structure Diagram에 대해 설명합니다. 본 시리즈의 목적은 표기법 요소들과 이들의 의미를 설명하는 것이므로, 이 글에서는 주로 클래스 다이어그램에 초점을 맞춥니다. 이렇게 하는 이유는 곧 명확해 질 것입니다. 후속 기술자료에서는 Structure 카테고리에 포함된 기타 다이어그램을 설명합니다.

이 글을 읽는 독자들에게 다시 한번 당부하고 싶은 것은 UML 표기법 요소들에 관한 것이고, 이 글은 모델링에 대한 최상의 접근 방식에 대한 가이드나 첫 번째로 모델링 되어야 할 것을 결정하는 방법에 대해서는 설명하지 않습니다. 이 글의 목표이자 본 시리즈의 목표는 표기법 엘리먼트에 대한 기본적인 지식, 즉 신택스와 의미를 설명하는 것입니다. 이러한 지식을 기반으로 여러분은 다이어그램을 읽고 알맞은 표기법 요소들을 사용하여 자신만의 다이어그램을 만들 수 있습니다.

여러분은 객체 지향 디자인에 대한 기본적인 지식이 있을 것으로 간주하겠습니다. OO 개념에 대한 설명이 필요하다면http://java.sun.com/docs/books/tutorial/java/concepts/에서 객체 지향 프로그래밍을 다룬 Sun의 튜토리얼을 보시기 바랍니다. "What Is a Class?" 와 "What Is Inheritance?" 섹션에서는 이 글을 읽을 때 도움이 될 만한 정보들이 있습니다. 또한 David Taylor의 Object-Oriented Technologies: A Manager's Guide 역시 객체 지향 디자인을 잘 설명하고 있습니다.

UML 2의 음과 양

UML 2에는 두 가지 기본적인 다이어그램 카테고리가 있다. 모든 UML 다이어그램은 이 두 개의 다이어그램 카테고리들 중 하나에 속해있다. 구조 다이어그램(structure diagram)의 목적은 모델링 되는 시스템의 정적인 구조를 보여주는 것이다. 여기에는 클래스 다이어그램, 컴포넌트 다이어그램, 객체 다이어그램이 포함된다. 작동 다이어그램(Behavioral diagram)은 시스템의 객체들 간 동적인 작동을 보여준다. 여기에는 메소드, 협업, 액티비티 등이 포함된다. 작동 다이어그램 예로는 액티비티 다이어그램, 유스 케이스 다이어그램, 시퀀스 다이어그램 등이 있다.

위로

구조 다이어그램

이미 언급했지만, 구조 다이어그램은 모델링 되는 시스템의 정적인 구조를 보여준다. 시간에 상관 없이 시스템의 요소들에 초점을 맞춘다. 정적 구조는 시스템에 있는 유형들과 이들의 인스턴스를 나타낸다. 시스템 유형과 인스턴스를 보여주는 것 외에도, 구조 다이어그램은 이러한 요소들 간 관계를 보여주고 심지어는 내부 구조까지도 보여준다.

구조 다이어그램은 소프트웨어 라이프 사이클 동안 팀 멤버들에게 유용하게 사용된다. 일반적으로, 이러한 다이어그램은 디자인의 유효성 검사와 개인과 팀들 간 디자인 통신에 사용된다. 예를 들어, 비즈니스 분석가들은 클래스나 객체 다이어그램을 사용하여 계정 대장, 제품, 지리적 계층 같은 비즈니스의 현재 에셋(asset)과 리소스를 모델링 할 수 있다. 아키텍트는 컴포넌트와 전개 다이어그램을 사용하여 자신들의 디자인이 튼튼하다는 것을 테스트 및 입증한다. 개발자들은 클래스 다이어그램을 사용하여 시스템의 코딩 된(또는 곧 코딩 될) 클래스들을 디자인 및 문서화 한다.

클래스 다이어그램

UML 2는 구조 다이어그램을 하나의 범주로 간주한다. "Structure Diagram"이라고 하는 다이어그램은 없다. 하지만, 클래스 다이어그램은 구조 다이어그램 유형의 대표적인 예이며, 다른 모든 구조 다이어그램들이 사용하는 초기 표기법 요소들을 제공한다. 클래스 다이어그램은 너무나도 중요하기 때문에, 이 글에서는 클래스 다이어그램의 표기법 세트를 집중적으로 설명하겠다. 이 글을 다 읽고 나면 여러분은 UML 2 클래스 다이어그램을 그리는 방법을 이해하고, 다음 기술자료에서 다룰 다른 구조 다이어그램을 더욱 잘 이해하게 될 것이다.

위로

기초

앞서 언급했던 것처럼, 클래스 다이어그램의 목표는 시스템 내에서 모델링 되는 유형을 보여주는 것이다. 대부분의 UML 모델에서는 다음과 같은 유형들이 있다.

• 클래스
• 인터페이스
• 데이터 유형
• 컴포넌트

UML은 이러한 유형들에 대해 특별한 이름을 사용한다. 바로 "classifier"이다. 일반적으로, 여러분은 classifier를 클래스로 생각할 수 있지만, 기술적으로 classifier는 위에 언급한 다른 세 가지 유형들을 언급하는 보다 포괄적인 용어이다.

클래스 이름

클래스의 UML 표현은 수직적으로 쌓인 세 개의 부분들을 포함하고 있는 직사각형이다. (그림 1) 맨 위 부분은 클래스의 이름을 나타낸다. 중간 부분은 클래스의 애트리뷰트이다. 맨 밑 부분은 클래스의 연산이다. 클래스 다이어그램에 클래스 요소를 그릴 때, 맨 위 부분은 반드시 사용해야 하고 밑에 두 개의 부분은 선택적이다. (밑에 두 부분은 Classifier들 간 관계만 보여주는 것이 목적일 경우 고급 상세를 설명하는 다이어그램에서는 불필요 하다.) 그림 1은 UML 클래스로서 모델링 된 항공 내역을 보여준다. 이름은 Flight이고, 중간 부분에는 Flight 클래스에 세 개의 애트리뷰트, flightNumber, departureTime, flightDuration이 있다. 밑 부분에서는 Flight 클래스가 두 개의 연산, delayFlight과 getArrivalTime을 갖고 있다.

그림 1: Flight 클래스에 대한 클래스 다이어그램

클래스 애트리뷰트 리스트

한 클래스의 애트리뷰트 섹션(중간 부분)은 각 클래스의 애티리뷰트를 각 라인 별로 나열한다. 애트리뷰트 섹션은 선택적이지만, 이것이 사용된다면 하나의 리스트 포맷으로 디스플레이 된 클래스의 애트리뷰트가 포함된다. 이 라인은 다음과 같은 포맷을 사용한다.

name : attribute type

 

flightNumber : Integer

 

이 Flight 클래스 예제에서, 애트리뷰트 유형 정보와 함께 클래스의 애트리뷰트를 기술할 수 있다. (표 1)

표 1: 애트리뷰트 유형 정보를 가진 Flight 클래스의 애트리뷰트 이름

비즈니스 클래스 다이어그램에서, 애트리뷰트 유형들은 다이어그램의 독자들이 이해할 수 있는 단위들에도 상응한다. (예, 분(minute), 달러(dollar) 등). 하지만, 코드를 생성하기 위해 사용될 클래스 다이어그램은 애트리뷰트 유형이 프로그래밍 언어에서 제공하는 유형 또는 시스템에 구현될 모델에 포함되는 유형으로 제한된 클래스가 필요하다.

가끔, 클래스 다이어그램에 특정 애트리뷰트가 기본 값을 갖고 있음을 보여주는 것도 유용하다. (예를 들어, 은행 계정 애플리케이션에서, 새로운 은행 계정은 잔액 0으로 시작한다.) UML 스팩은 다음과 같은 표기법을 사용함으로써, 애트리뷰트 리스트 섹션에 기본 값을 구분한다.

name : attribute type = default value

 

예를 들어:

balance : Dollars = 0

 

애트리뷰트에 대한 기본 값을 보여주는 것은 선택적이다. 그림 2는 기본 값이 0인, balance라고 하는 애트리뷰트를 가진 Bank Account 클래스를 보여준다.

그림 2: 기본 값이 0 달러인 balance 애트리뷰트의 값을 보여주는 Bank Account 클래스 다이어그램

클래스 연산 리스트

클래스의 연산은 클래스 다이어그램의 세 번째(가장 밑에 있는) 부분에 나타난다. 이것 역시 선택적이다. 애트리뷰트와 마찬가지로, 클래스의 연산은 리스트 포맷으로 디스플레이 되고, 각 라인마다 연산이 있다. 연산은 다음과 같은 표기법을 사용하여 문서화 된다.

name(parameter list) : type of value returned

 

Flight 클래스의 연산은 아래 표 2로도 매핑 될 수 있다.

표 2: 그림 2를 표로 나타낸 Flight 클래스의 연산

그림 3을 보면 delayFlight 연산이 Minutes 유형의 인풋 매개변수 numberOfMinutes를 갖고 있다는 것을 알 수 있다. 하지만 delayFlight 연산에는 리턴 값이 없다.

 ¹ 하나의 연산이 매개변수를 갖고 있을 때, 매개변수들은 연산의 괄호 안에 놓이게 된다. 각 매개변수는 "parameter name : parameter type" 포맷을 사용한다.

그림 3: Flight 클래스 연산 매개변수들에는 "in" 표시가 포함된다.

연산의 매개변수들을 문서화 할 때, 매개변수가 연산의 인풋인지 또는 아웃풋인지를 보여주기 위해 선택적인 인디케이터를 사용할 수도 있다. 이러한 선택적인 인디케이터는 그림 3의 연산 부분에 나타난 것처럼 "in" 또는 "out"으로 나타난다. 일반적으로, 이러한 인디케이터는 Fortran 같은 오래된 프로그래밍 언어가 사용되지 않는 한 불필요하다. 하지만, C++과 자바에서, 모든 매개변수들은 "in" 매개변수들이고, "in"은 UML 스팩에 따라 매개변수의 기본 유형이기 때문에 대부분의 사람들은 인풋/아웃풋 인디케이터를 생략한다.

상속(Inheritance)

객체 지향 디자인의 가장 중요한 개념인 상속(inheritance)은 하나의 클래스(자식 클래스)가 또 다른 클래스(슈퍼 클래스)의 동일한 기능을 상속받을 수 있고 고유의 새로운 기능을 추가할 수 있다는 것을 의미한다. (기술적인 비유법은 아니지만, 필자는 어머니의 음악적 재능을 물려받았고, 우리 가족 중에서 전자 기타를 연주할 수 있는 사람은 필자뿐이다.) 클래스 다이어그램에 상속을 모델링 하려면, 속이 투명한 화살표(또는 삼각형)가 슈퍼 클래스를 향하도록 하여 자식 클래스(작동을 상속받는 클래스)로부터 직선이 그려진다. Bank Account 유형을 생각해 보자. 그림 4는 CheckingAccount와 SavingsAccount가 BankAccount 클래스에서 상속을 받는 모습이다.

그림 4: 투명 삼각형 모양의 화살표가 슈퍼 클래스를 가리키면서 직선으로 상속이 표시된다.

그림 4에서, 상속 관계는 각 하위 클래스 마다 개별 라인으로 그려지는데, 이것은 IBM Rational Rose와 IBM Rational XDE에서 사용되는 방식이다. 하지만, 트리 표기법(tree notation)으로 상속을 그리는 방법도 있다. 그림 4처럼 두 개 이상의 자식 클래스들이 있을 때 트리 표기법을 사용할 수 있다. 나무 가지처럼 상속 라인들이 합쳐지는 경우는 예외이다. 그림 5는 그림 4의 상속을 트리 표기법으로 다시 그린 것이다.

Figure 5: 트리 표기법을 사용한 상속

추상 클래스와 연산 
주의력이 깊은 독자라면 그림 4와 5의 다이어그램이 BankAccount 클래스 이름과 withdrawal 연산에 이탤릭 체를 사용하고 있음을 알아챘을 것이다. BankAccount 클래스는 추상 클래스이고, withdrawal 메소드는 추상 연산이라는 것을 나타내는 것이다. 다시 말해서, BankAccount 클래스는 withdrawal의 추상 연산을 제공하고 CheckingAccount와 SavingsAccount의 두 개의 자식 클래스들은 각각의 연산 버전을 구현한다.

하지만, 슈퍼 클래스(부모 클래스)는 추상 클래스일 필요가 없다. 일반적으로 표준 클래스가 슈퍼 클래스가 된다.

제휴(Association) 
시스템을 모델링 할 때, 특정 객체들은 서로 연관될 것이고, 이러한 관계들이 명확하게 모델링 되어야 한다. 다섯 가지 제휴 유형들이 있다. 이 섹션에서는 두 가지 유형-양방향(bi-directional) 제휴와 일방향(uni-directional) 제휴를 설명하고, 나머지 세 가지 제휴 유형들은 기초를 넘어서 섹션에서 설명하도록 하겠다. 각각의 제휴 유형을 사용할 시기까지는 이 섹션에서는 설명하지 않겠다. 각 제휴 유형의 목표에 초점을 맞춰, 클래스 다이어그램에 제휴를 그리는 방법을 설명하도록 하겠다.

양방향 (표준) 제휴 
제휴는 두 클래스들간 연결이다. 제휴는 언제나 양방향(bi-directional)으로 간주된다. 다시 말해서, 일부 다른 유형으로 수정하지 않는 한, 두 개의 클래스들이 서로를 인식하고 있고 그 관계를 알고 있다는 의미이다. 그림 6은 Flight 클래스와 Plane 클래스 간 표준 제휴 유형이다.

그림 6: Flight 클래스와 Plane 클래스간 양방향 제휴 예제

양방향 제휴는 두 클래스들 간 일직선으로 표시된다. 각 라인의 양 끝에 역할과 값을 표시한다. 그림 6은 Flight이 특정 Plane과 연결되어 있고, Flight 클래스는 이러한 관계를 알고 있다는 것을 보여준다. Plane은 이 제휴 관계에서 "assignedPlane"의 역할을 담당하고 있다. Plane 클래스 옆에 있는 역할 이름이 이를 말해주고 있다. Plane 옆에 있는 Multiplicity 값 0..1은 Flight의 인스턴스가 있을 때, Plane의 한 인스턴스가 이것과 연결되었거나, 어떤 Plane도 이것과 연결되지 않았다(비행기가 아직 지정되지 않았을 경우)는 것을 의미한다. 그림 6에서는 Plane이 Flight 클래스와의 제휴 관계를 인식하고 있음을 보여준다. 이러한 제휴 관계에서, Flight은 "assignedFlights"의 역할을 맡는다. 그림 6의 다이어그램은 Plane 인스턴스가 어떤 비행 스케줄과도 제휴될 수 없거나(새로운 비행기일 경우) 또는 많은 비행 스케줄(이 비행기가 지난 5년 동안 사용 중일 경우)과 연결될 수 있다는 것을 나타낸다.

표 3에는 Multiplicity 값들과 이것의 의미를 정리했다.

표 3: Multiplicity 값과 인디케이터

일방향 제휴 
일방향 제휴에서는, 두 개의 클래스들은 관련이 있지만, 단 하나의 클래스만 그 관계를 인식하고 있다. 그림 7은 일방향 제휴의 예제이다.

그림 7: 일방향 제휴 예제: OverdrawnAccountsReport 클래스는 BankAccount 클래스에 대해 알고 있지만, BankAccount 클래스는 제휴 관계에 대해 모른다.

일방향 제휴는 알려진 클래스를 가리키는 개방된 화살표(상속을 나타내는데 사용되었던 닫힌 또는 삼각형 화살표가 아니다.)가 있는 직선으로 그려진다. 표준 제휴와 마찬가지로, 일방향 제휴에는 역할 이름과 Multiplicity 값이 포함되지만, 표준 양방향 제휴와는 달리, 일방향 제휴에는 알려진 클래스에만 역할 이름과 Multiplicity 값이 포함된다. 그림 7의 예제를 보면, OverdrawnAccountsReport는 BankAccount 클래스에 대해 알고 있고 BankAccount 클래스는 "overdrawnAccounts"의 역할을 수행한다. 하지만, 표준 제휴와는 달리, BankAccount 클래스는 이것이 OverdrawnAccountsReport와 제휴되어 있다는 사실을 모른다. ²

패키지 
대형 시스템 또는 비즈니스의 큰 유형을 모델링 한다면, 모델에 다양한 Classifier가 있을 것이다. 이 모든 클래스들을 관리하기란 매우 어렵다. 따라서, UML은 패키지(package)라고 하는 요소를 제공한다. 패키지는 모델러가 모델의 Classifier를 네임스페이스로 구성할 수 있도록 하는데, 이는 일종의 파일링 시스템의 폴더와 같은 것이다. 시스템을 다중 패키지들로 나무면 시스템은 더욱 이해하기 쉽고, 특히 각 패키지가 시스템의 특정 부분을 나타낼 때 더욱 그렇다. ³

다이어그램에 패키지들을 그리는 두 가지 방법이 있다. 어떤 표기법을 사용할 것인지 결정하는 규칙은 없다. 여러분이 그리는 클래스 다이어그램을 가장 쉽게 읽을 수 있는 방법을 기준으로 삼으면 된다. 두 가지 방법 모두 큰 직사각형이 있고 좌측 상단 코너 쪽에 작은 직사각형(탭)시작한다. (그림 8) 모델러는 패키지의 멤버쉽이 보여지는 방법을 결정해야 한다.

• 큰 직사각형 안에 패키지의 멤버들을 보여주기로 결정했다면, 모든 멤버들 ⁴ 은 직사각형 안에 놓여야 한다. 또한 패키지의 이름은 패키지의 작은 직사각형에 놓여야 한다. (그림 8)
• 모델러가 큰 직사각형 밖에 패키지의 멤버들을 보여주기로 결정했다면, 다이어그램에 나타날 모든 멤버들은 직사각형 밖에 놓여야 한다. 어떤 Classifier들이 패키지에 속했는지를 보여주려면, 각 Classifier부터 패키지에 붙은 원 안에 플러스 부호가 있는 원으로 선을 그어야 한다. (그림 9)

그림 8: 패키지의 직사각형 바운더리 안에 멤버들을 보여주는 패키지 엘리먼트 예제

그림 9: 연결된 선들을 통해 멤버쉽을 보여주는 패키지 엘리먼트 예제

기초 이해의 중요성

UML 2에서는 클래스 다이어그램의 기초를 이해하는 것이 더 중요해졌다. 클래스 다이어그램은 컴포넌트나 객체 다이어그램 등 모든 구조 다이어그램에 대한 기본 구현 블록을 제공하기 때문이다.

위로

기초를 넘어서

지금까지 클래스 다이어그램의 기초를 설명했다. 아직 끝나지 않았으니 계속 읽어주기 바란다. 이어지는 섹션에서는 클래스 다이어그램의 더 중요한 측면들을 설명하겠다. 인터페이스와, 남아있는 세 가지 제휴 유형들, 가시성(visibility), UML 2 스팩의 추가 요소들을 설명하겠다.

인터페이스 
이 글 초반에, 여러분이 classifiers를 단순히 클래스로 간주할 것이라고 말한바 있다. 사실, Classifier는 보다 일반적인 개념이고, 여기에는 데이터 유형과 인터페이스가 포함된다.

시스템의 구조 다이어그램에서 데이터 유형과 인터페이스를 효과적으로 사용할 시기와 방법을 설명하는 것은 이 글의 범위를 벗어난다. 그렇다면, 왜 데이터 유형과 인터페이스를 언급했을까? 가끔은 구조 다이어그램에 이러한 Classifier 유형들을 모델링 해야 할 때가 있고, 이를 수행할 때 올바른 표기법을 사용하는 것이 중요하며, 적어도 Classifier 유형들에 대해서는 알고 있어야 한다. 이러한 Classifier들을 부정확하게 그리면 구조 다이어그램을 읽는 사람들이 혼란을 겪을 것이고, 시스템은 요구 사항을 채우지 못하게 된다.

클래스와 인터페이스는 다르다. 클래스는 그 유형의 실제 인스턴스를 가질 수 있지만, 인터페이스는 이를 실행할 적어도 한 개의 클래스를 가져야 한다. UML 2에서, 인터페이스는 클래스 모델링 요소를 특화 한 것으로 간주한다. 따라서, 인터페이스는 클래스처럼 그려지지만, 직사각형의 맨 위 부분에는 "«interface»" 라는 텍스트가 붙는다. 그림 10 ⁵

그림 10: Professor와 Student 클래스들이 Person 인터페이스를 구현하는 클래스 다이어그램 예제

그림 10의 다이어그램에서, Professor와 Student 클래스들은 Person 인터페이스를 구현하는 것이지, Person 인터페이스에서 상속을 받지 않는다. 이렇게 말하는 데는 두 가지 근거가 있다. 1) Person 객체는 인터페이스로서 정의된다. 객체의 이름 영역에 "«interface»" 텍스트가 있고, Professor와 Student 객체들이 클래스 객체를 그리는 규칙에 따라 레이블링 되고 있기 때문에 이들이 클래스 객체들이라는 것을 알고 있다. (이름 영역에 추가적인 구분 텍스트가 없다.) 2) 화살표로 이어진 선이 점으로 되어있고 직선이 아니기 때문에 상속이 아니다. 그림 10에서 보듯, 속이 비어있는 폐쇄 화살표가 연결된 점선은 구현을 의미한다. 그림 4에서 보듯, 속이 비어있는 폐쇄 화살표로 연결된 직선은 상속을 의미한다.

기타 제휴 유형들 
앞서 양방향 제휴와 일방향 제휴를 설명했다. 이제는 나머지 세 가지 제휴 유형들을 설명하도록 하겠다.

제휴 클래스 
제휴를 모델링 할 때, 관계에 대한 중요한 정보를 포함하고 있기 때문에 또 다른 클래스를 포함시켜야 할 때가 있다. 이러한 이유로, 여러분은 기본 제휴에 연결할 제휴 클래스를 사용해야 한다. 제휴 클래스는 일반 클래스처럼 표현된다. 차이점은, 기본 클래스들간 제휴 라인은 제휴 클래스로 연결된 점선을 횡단한다. 그림 11은 항공 관련 예제의 제휴 클래스 모습이다.

그림 11: 제휴 클래스 MileageCredit 추가하기

그림 11의 클래스 다이어그램에서, Flight 클래스와 FrequentFlyer 클래스간 제휴는 MileageCredit라고 하는 제휴 클래스라는 결과를 만들어 낸다. Flight 클래스의 인스턴스가 FrequentFlyer 클래스의 인스턴스와 제휴될 때, MileageCredit 클래스의 인스턴스도 생긴다.

애그리게이션(Aggregation) 
애그리게이션은 "전체와 부분들(whole to its parts)" 관계를 모델링 하는데 사용되는 특별한 제휴 유형이다. 기본적인 애그리게이션 관계에서, 부분(part) 클래스의 라이프 사이클은 전체(whole) 클래스의 라이프 사이클과는 무관하다.

예를 들어, Car를 전체 엔터티로, Car Wheel을 전체 Car의 부분으로 생각할 수 있다. 바퀴는 몇 주 먼저 만들어 질 수 있고 조립하는 동안 자동차에 부착되기 전에 웨어하우스에 놓일 수 있다. 이 예제에서, Wheel 클래스의 인스턴스는 Car 클래스의 인스턴스와는 독립적으로 존재한다. 하지만, 부분 클래스의 라이프 사이클이 전체 클래스의 라이프 사이클과 무관하지 않을 때가 있다. 이를 composition aggregation이라고 한다. 회사와 부서의 관계를 생각해 보면 된다. 회사와 부서들은 클래스로 모델링 되고, 회사가 존재하기 전에 부서는 존재할 수 없다. 이 경우 Department 클래스의 인스턴스는 Company 클래스의 인스턴스에 종속적이다.

기본 애그리게이션과 Composition Aggregation을 자세히 살펴보도록 하자.

기본 애그리게이션 
애그리게이션 관계와의 제휴는 하나의 클래스가 또 다른 클래스의 일부라는 것을 나타낸다. 애그리게이션 관계에서, 자식 클래스 인스턴스는 부모 클래스보다 오래 살아남는다. 애그리게이션 관계를 나타내려면, 부모 클래스에서 부분 클래스로 직선을 그리고, 부모 클래스의 제휴의 끝에 속이 비어있는 다이아몬드 모양을 그린다. 그림 12는 Car와 Wheel간 애그리게이션 관계 예제를 나타낸다.

그림 12: 애그리게이션 제휴 예제

Composition aggregation 
Composition Aggregation 관계는 애그리게이션 관계의 한 형태이지만, 자식 클래스의 인스턴스 라이프 사이클은 부모 클래스의 인스턴스 라이프 사이클에 종속적이다. 그림 13은 Company 클래스와 Department 클래스 간 컴포지션 관계를 보여주는데, 컴포지션 관계는 애그리게이션 관계처럼 그려지지만, 이번에는 다이아몬드 속이 채워졌다.

그림 13: composition 관계 예제

그림 13에서 모델링 된 관계에서, Company 클래스 인스턴스에는 한 개 이상의 Department 클래스 인스턴스가 있다. 이 관계는 composition 관계이기 때문에, Company 인스턴스가 제거될 때, Department 인스턴스도 자동적으로 제거된다. Composition Aggregation의 또 다른 중요한 특징은 부분 클래스는 부모 클래스의 한 인스턴스와만 연결될 수 있다는 점이다. (우리 예제의 경우, Company 클래스)

반사 제휴(Reflexive association) 
지금까지, 모든 제휴 유형들에 대해서 살펴보았다. 여러분도 알다시피, 이 모든 예제들은 두 개의 다른 클래스들간 관계를 보여주었다. 하지만, 반사 제휴(reflexive association)를 사용하여 하나의 클래스가 그 자체로 제휴될 수도 있다. 언뜻 이해가 되지 않지만, 클래스들이 추상적이라는 것을 기억하라. 그림 14는 Employee 클래스가 manager 역할을 통해 스스로 연결되는 방법을 보여주고 있다. 하나의 클래스가 스스로 제휴를 맺을 때, 클래스의 인스턴스도 스스로 제휴를 맺는 것이 아닌, 클래스의 인스턴스는 그 클래스의 다른 인스턴스와 연결된다는 것을 의미한다.

그림 14: 반사 제휴 관계 예제

그림 14의 관계도는 Employee의 인스턴스가 또 다른 Employee 인스턴스의 매니저가 될 수 있다는 것을 의미한다. 하지만, "manages"의 관계 역할이 0..*의 Multiplicity를 가질 수 있기 때문에 Employee는 관리할 다른 Employee가 없을 수 있다.

가시성 
객체 지향 디자인에서, 애트리뷰트와 연산에 대한 가시성 표기법이 있다. UML은 네 가지 가시성 유형을 정의하고 있다: Public, Protected, Private, Package

UML 스팩에서는 클래스 다이어그램에 디스플레이 되는 애트리뷰트와 연산 가시성을 요하지 않지만, 각 애트리뷰트나 연산에 대해 정의되어야 한다고 정하고 있다. 클래스 다이어그램에 가시성을 디스플레이 하려면, 애트리뷰트 또는 연산의 이름 앞에 가시성 부호를 붙여야 한다. UML이 네 가지 가시성 유형을 정의하지만, 실제 프로그래밍 언어는 추가 가시성들을 추가하거나, UML에서 정의된 가시성은 지원하지 않을 수도 있다. 표 4는 UML에서 지원되는 가시성 유형에 대한 부호를 정리한 것이다.

표 4: UML 지원 가시성 유형에 대한 부호

이제 애트리뷰트와 연산에 대한 가시성 유형을 보여주는 클래스를 보자. 그림 15에서, 모든 애트리뷰트와 연산들은 Public이고, updateBalance 연산만 예외이다. updateBalance 연산은 Protected이다.

그림 15: 애트리뷰트와 연산의 가시성을 보여주는 BankAccount 클래스

위로

UML 2 추가

지금까지 기본적인 내용과 고급 주제들을 다루었다. 이제 UML 1.x에 추가된 새로운 표기법에 대해 알아보자.

인스턴스 
시스템의 구조를 모델링 할 때, 클래스의 예제 인스턴스를 보여주는 것이 가끔 유용하다. 이것을 모델링 하기 위해, UML 2는 엘리먼트를 제공하는데, 이것은 시스템의 예시(또는 실제) 인스턴스를 사용하여 흥미로운 정보를 보여준다.

인스턴스의 표기법은 클래스와 같지만, 맨 위 부분에 클래스 이름 대신, 이름에는 밑줄이 생긴다.

Instance Name : Class Name

 

예를 들어,

Donald : Person

 

인스턴스를 보여주는 이유가 관심이 있거나 관련이 있는 정보를 보여주는 것이기 때문에, 모델 안에 전체 인스턴스의 애트리뷰트와 연산을 포함시킬 필요는 없다. 대신, 그림 16에서처럼 관심이 있는 애트리뷰트와 값들만 보여주는 것이 좋다.

그림 16: Plane 클래스의 인스턴스 예제 (관심 있는 애트리뷰트 값들만 보인다.)

하지만, 단순히 관계에 대한 설명 없이 몇 가지 인스턴스들만 보여주는 것은 쓸모가 없다. 따라서, UML 2는 인스턴스 레벨에서 관계/제휴 모델링을 적용한다. 제휴를 그리는 규칙은 일반 클래스 관계와 같지만, 제휴를 모델링 할 때 한 가지 추가 요구 사항이 있다. 제휴 관계는 클래스 다이어그램의 관계와 매치해야 하고, 제휴의 역할 이름 역시 클래스 다이어그램과 매치되어야 한다. 이것의 예제는 그림 17에 나타나 있다. 이 예제에서, 인스턴스는 그림 6의 클래스 다이어그램의 인스턴스 예제이다.

그림 17: 클래스 대신 인스턴스를 사용하는 그림 6의 예제

그림 17은 Flight 클래스의 두 개의 인스턴스를 갖고 있다. 클래스 다이어그램이, Plane 클래스와 Flight 클래스간 관계를 zero-to-many라고 명시했기 때문이다. 따라서, 우리 예제에서는 NX0337 Plane 인스턴스가 연관된 두 개의 Flight 인스턴스를 보여주고 있다.

역할 
클래스의 인스턴스를 모델링 하는 것은 기대 이상으로 상세하다. 가끔, 보다 일반적인 레벨에서 클래스의 관계를 모델링하고 싶을 때가 있다. 이 같은 경우, 역할(role) 표기법을 사용해야 한다. 역할 표기법은 인스턴스 표기법과 매우 비슷하다. 클래스의 역할을 모델링 하려면, 박스를 그린 다음, 인스턴스 표기법에서처럼 그 안에 클래스의 역할 이름과 클래스 이름을 놓는다. 하지만, 이 경우, 단어에 밑줄을 그어서는 안된다. 그림 18은 그림 14의 다이어그램에서 설명한 Employee 클래스의 역할 예제이다. 그림 18에서, Employee 클래스가 스스로와 연결되었더라도, 그 관계는 매니저의 역할을 하는 Employee와 팀 멤버의 역할을 하는 Employee간 관계이다.

그림 18: 각자 다른 역할을 가진 그림 14의 클래스를 보여주는 클래스 다이어그램

평범한 클래스 다이어그램에서 클래스의 역할을 모델링 할 수 없다. 심지어, 그림 18은 가능한 것처럼 보여도 모델링은 불가능하다. 역할 표기법을 사용하려면, Internal Structure 표기법을 사용해야 한다.

Internal Structures 
UML 2 구조 다이어그램의 유용한 기능들 중 하나는 새로운 Internal Structures 표기법이다. 클래스와 또 다른 Classifier가 내부에서 구성되는 방법을 보여주고 있다. 이것은 UML 1.x에서는 불가능 했다. 이 표기법 세트는 클래스가 가진 애그리게이션 관계만 보여주기 때문이었다. 이제, UML 2에서 Internal Structures 표기법으로 클래스의 부분들이 서로 어떻게 연관되는지를 명확히 보여줄 수 있다.

예제를 보자. 그림 18에서는 Plane 클래스가 네 개의 엔진들과 두 개의 컨트롤 소프트웨어 객체들로 구성되는 방법을 보여주는 클래스 다이어그램을 보았다. 이 다이어그램에서 빼먹은 것은 비행기의 부품들이 조립되는 방법에 대한 정보이다. 그림 18의 다이어그램에서, 컨트롤 소프트웨어 객체들이 두 개의 엔진들을 제어하는지, 하나의 컨트롤 소프트웨어 객체가 세 개의 엔진들을 제어하고 다른 컨트롤 소프트웨어가 하나의 엔진을 제어하는지를 알 수 없다.

그림 19: 객체들 간 관계만 보여주는 클래스 다이어그램

클래스의 내부 구조를 그린다면 상황은 더 나아질 것이다. 두 개의 칸을 가진 박스를 그린다. 윗칸에는 클래스 이름이, 아래칸에는 클래스의 내부 구조가 포함되어 있고, 각각의 역할에 부모 클래스의 부분 클래스들을 보여주고 있고, 각각의 특정 클래스가 그 역할에서 서로서로 연관되는 방법을 보여주고 있다. 그림 19는 Plane 클래스의 내부 구조를 보여주고 있다. 내부 구조가 혼란을 어떻게 종식시키는지 주목하라.

그림 20: Plane 클래스의 내부 구조 예제

그림 20에서, Plane은 두 개의 ControlSoftware 객체들을 갖고 잇고, 각각 두 개의 엔진들을 제어하고 있다. 이 다이어그램의 왼쪽에 있는 ControlSoftware(control1)는 엔진 1과 엔진 2를 제어한다. 오른쪽에 있는 ControlSoftware(control2)는 엔진 3과 4를 제어한다.

위로

결론

클래스 다이어그램일 이해해야 하는 두 가지 중요한 이유가 있다. 첫 번째는 시스템에서 Classifier의 정적 구보를 보여주는 것이고, 두 번째 이유는 다이어그램이 UML에서 정한 다른 구조 다이어그램에 대한 기본적인 표기법을 제공하기 때문에다. 개발자들은 클래스 다이어그램이 자신들을 위해 특별히 만들어졌다고 생각할 것이다. 하지만 다른 팀 멤버들 역시 이것을 유용하게 사용할 수 있다. 비즈니스 분석가들은 클래스 다이어그램을 사용하여 비즈니스 관점에서 시스템을 모델링 할 수 있다. 본 시리즈의 다른 기술자료를 참조하면 알겠지만, 다른 다이어그램들(액티비티, 시퀀스, statechart 다이어그램)은 이 클래스 다이어그램에서 모델링 및 문서화 된 클래스들을 참조하고 있다.

다음 시리즈는 "UML 기초:" 컴포넌트 다이어그램이다.

위로

주

¹ delayFlight은 리턴 값이 없다. delay 연산이 새로운 도착 시간을 리턴 해야 하고, 이것이 그러한 경우라면, 연산 시그너처는delayFlight(numberOfMinutes : Minutes) : Date가 될 것이다.

²BankAccount 클래스가 OverdrawnAccountsReport 클래스에 대해 모르고 있다는 사실이 이상할 것이다. 이 모델링은 report 클래스가 자신들이 리포팅 하는 비즈니스 클래스만 알 수 있도록 하지만, 비즈니스 클래스는 자신들이 리포팅 되고 있다는 것을 모른다. 이로써, 객체들의 커플링이 느슨해지고, 시스템은 변화에 대한 적응성이 빨라진다.

³ 패키지는 모델의 클래스들을 구성하는데 탁월하지만, 클래스 다이어그램은 모델링 되는 시스템에 대한 정보와 쉽게 통신한다. 패키지에 많은 클래스가 있는 경우, 하나의 큰 클래스 다이어그램을 만드는 대신 주제 별 클래스 다이어그램을 여러 개 사용하는 것이 더 낫다.

⁴필자가 "all those members"라고 말할 때, 현재 다이어그램이 보여줄 클래스만 의미한다는 것을 알아야 한다. 콘텐트가 있는 패키지를 보여주는 다이어그램은 모든 콘텐트를 보여줄 필요가 없다. 일정 기준에 따라 포함된 엘리먼트의 일부만 보여줄 수 있다.

⁵ 클래스 다이어그램을 그릴 때, 직사각형의 맨 윗칸에 «class»라고 표기해야 한다. 하지만 UML 스팩에서는 "class" 라는 텍스트를 표기하는 것은 선택 사항이고, «class»가 디스플레이 되지 않는 것으로 간주된다.

 

참고자료

UML의 기초: Unified Modeling Language 소개 (한글)

UML의 기초: Part II: The activity diagram

UML의 기초: Part III: The class diagram

필자소개

Donald Bell은 IBM Global Services의 IT 전문가이고, 웹 기반 기술 애플리케이션 분야에서 고객을 지원하고 있다. (bellds@us.ibm.com)

 

원문 게재일:  2007 년 5 월 22 일 

출처 : http://www.ibm.com/developerworks/kr/library/sep04/bell/index.html