Class Diagram

클래스 다이어그램 이란 무엇일까요?
클래스 다이어그램은 곧바로 프로그램 코드로 변환할 수 있는 모델입니다.

예를 들어 볼까요?
아파트 단지를 건축한다고 했을 때 아파트를 짓기 위해서는 여러 가지 설계도를
그리게 되지만, 현장 작업자의 손에 전달되어 그대로만 하면 아파트가 지어지는
그런 도면은 하나입니다. 개념도와 아파트 동 배치도와 같은 것이 아니라, 완전한
아파트 내부의 설계도는 한 종류인 것이죠.

이처럼 건축에서와 같이 프로그래머가 시스템을 구축할 때 곧바로 프로그램
코드로 변환할 수 있는 설계도와 같은 그러한 기능을 하는 것이 바로 클래스
다이어그램입니다. 다른 다이어그램들은 클래스 다이어그램을 이해하는
보조적인 용도로 사용될 뿐입니다.

클래스 다이어그램, 중요하겠지요?
마음을 가다듬고 시작해 볼까요?

 

클래스 다이어그램은 "시스템에서 사용되는 객체 타입(클래스)을 정의하고 그들 간에 존재하는 정적인 관계를 다양한 방식으로 표현한 다이어그램"입니다. 클래스 다이어그램은 객체지향 SW 시스템을 분석하고 설계하는 데 사용되는 핵심적인 모델입니다. 객체지향 SW 시스템은 클래스와 그 관계로 뼈대가 구성되기 때문에 이를 정의한 클래스 다이어그램은 곧 시스템의 구현될 모습을 정의한 것입니다. 클래스 다이어그램은 분석되거나 설계되는 모든 클래스를 한 장의 다이어그램으로 정의한 것입니다. 클래스 다이어그램은 클래스의 정적인 정의와 관계를 표현합니다. 객체가 아닌 클래스는 본질적으로 "정적(靜的)"입니다. 시간과 조건이 개입되지 않기 때문입니다. 그러나 객체는 그 자체가 동적(動的)인 개념을 가집니다. 클래스에서 파생된 것이 객체이고, 객체는 상태와 행위가 시간과 구체적인 조건에 따라 변화하고, 또한 다른 객체와 동적으로 상호 작용하는 것이기 때문입니다.

단연 대표적인 UML의 다이어그램이라고 할 수 있는 클래스 다이어그램을 작성하는 목적은 다음과 같습니다.

객체지향 SW시스템의 기본 단위인 클래스를 식별하고 그 관계를 정의하는 유용한 방식을 제공합니다. 클래스 다이어그램은 객체지향 SW 시스템의 기본 단위인 클래스의 정의를 용이하게 함으로써 시스템을 구축하는 본격적인 단계로 인도합니다. 클래스 간의 정적인 협력관계를 정의함으로써 시스템을 이해하는데 용이하게 합니다. 하나의 클래스가 할 수 있는 일은 적습니다. 한 단위의 임무를 수행하려면 클래스간의 협력은 필수적으로 필요합니다. 클래스 다이어그램은 이러한 클래스간의 정적인 협력관계를 정의함으로써 시스템을 분석하고 이해하는데 도움을 줍니다. 클래스의 오퍼레이션과 속성을 상세히 정의함으로써 SW시스템을 설계합니다. 클래스의 속성과 오퍼레이션을 상세히 정의하는 일은 객체지향 SW 시스템에 있어서의 설계를 의미합니다. 클래스 다이어그램은 이러한 설계관점의 작업을 쉽게 수행하는데 도움을 주어, 시스템 구축 과정에 큰 역할을 합니다. 논리적인 관점으로부터 물리적인 관점까지 시종 일관된 형식으로 SW 시스템을 분석, 설계하는 방식을 제공합니다. 기존 방식의 가장 큰 단점인 분석/설계 모델간의 차이(gab)를 극복하고, 동일한 형식과 관점을 제공함으로써 의미의 소실없이 효과적인 시스템 분석, 설계방식을 제공합니다. 클래스 다이어그램을 적용한 분석설계는 객체지향 프로그래밍에 가장 가깝고 효과적인 방식입니다.

클래스 다이어그램을 작성하는 시기는 정확히 언제라고 단정할 수는 없습니다. 보통 SW시스템의 분석단계와 설계단계에서 여러 번 작성됩니다. 여러 번에 걸쳐 클래스 다이어그램이 작성되면서 점점 상세화되고 정련되는 과정을 거칩니다. 이렇게 여러 번 작성하는 이유는 이 다이어그램을 작성하는 시기마다 그 관점이 변화하기 때문입니다. 분석단계에서는 분석의 관점에서 클래스를 정의하고 설계단계에서는 설계의 관점에서 클래스를 정의하게 됩니다. 그래서 클래스 다이어그램은 작성이 반복될 때마다 진화하지만, 단계 단계마다 작성되는 클래스 다이어그램 자체도 나름대로 의미가 있습니다. 보통의 경우 아래와 같은 시기에서 클래스 다이어그램이 작성됩니다. 클래스 다이어그램을 작성하려면 사용자의 요구사항이 정의되고, 개발할 SW 시스템에 대한 범위가 정의되어야 합니다.

 

Class diagram을 처음부터 상세하게 정의할 수는 없습니다. 그래서 상세한 class diagram을 얻기 위해 단계적으로 상세화시켜 나가는 방식을 사용합니다. Class Diagram은 다음과 같이 3가지 관점으로 반복적이면서 점증적인 방식으로 작성해 나갑니다.   Conceptual level - 개발범위에 속해있는 문제영역에 대해 단순한 관계를 도출하는데 중점 - 업무 관점의 class 들만 도출하고, 구현에 관련된 시각은 최대한으로 배제   Specification level - 구현관점을 살려 모델링을 수행 - 어떻게 코딩할 건지에 대한 관점을 배제 - 클래스의 속성과 오퍼레이션을 될 수 있는 한 상세히 정의하고, 구체적인 플랫폼(개발언어의 특성 등)특성을 반영하지 않음.   Implementation level - 언어와 개발플랫폼이 가진 특성 및 제한 사항을 반영 - 정의된 class를 보고 정해진 개발언어로 개발자가 코딩을 하기에 충분한 정보를 모두 표현   클래스 다이어그램의 구성요소는 다음과 같습니다. 일반적인 클래스 표기법 클래스는 일반적인 표기와 icon 표기 두 가지의 표기가 가능합니다. 일반적인 표기는 단순형 표기와 정규형 표기등 두 가지가 있습니다. 단순형 표기 정규형 표기 직사각형에 클래스 명을 표기 Conceptual Level(개념 단계)의 클래스 다이어그램을 작성할 경우나, 클래스가 많아 그림이 복잡할 경우의 생략형 표현 세 개의 가로 간이 있는 사각형에 각각 클래스 명, 속성, 오퍼레이션을 차례로 표기 스테레오 타입이 정의된 클래스 표기법 스테레오 타입이 정의된 클래스의 경우 그 표기법은 달라집니다. 클래스의 스테레오 타입 중 대표적인 것은 <<boundary>> , <<control>> , <<entity>>, <<interface>> 입니다. 이를 일반형 표기와 icon 표기로 나타낸 것은 다음과 같습니다. 클래스는 크게 대별하면 Boundary, Entity, Control 다음 세 가지 종류로 구분할 수 있습니다. Boundary Class 사용자와 인터페이스를 담당하는 클래스입니다. 주로 UI(User Interface)에 짝을 이루어 정의됩니다. 이 클래스의 역할은 다음과 같습니다. 사용자로부터 UI 이벤트를 직접 받아서 시스템 내부에 처리를 의뢰합니다. 시스템으로부터의 응답을 UI를 조작하여 사용자에게 보여 줍니다. 사용자의 적절치 못한 입력에 대해서는 오류 메시지 등을 통해 직접 처리합니다. Control Class Boundary Class와 Entity Class사이의 처리를 중재하고 제어하는 클래스입니다. 이 클래스의 역할은 다음과 같습니다. 여러 클래스간의 협력작업을 제어하고 클래스간의 실행순서를 통제합니다. 결과를 조합하여 Boundary Class에 전달합니다. 데이터를 처리하는 도중에 발생하는 Transaction을 관리합니다. Entity Class 원하는 처리에 필요한 정보(데이터)를 관리하는 클래스입니다. 이 클래스의 역할은 다음과 같습니다. 처리에 필요한 데이터를 읽어 옵니다. 데이터를 저장합니다. 데이터를 삭제합니다. 데이터를 수정합니다. 정의 및 특징 Association은 두 클래스간 일반적인 협력 관계가 있을 경우 정의됩니다. Association은 두 클래스의 객체들 사이에 존재하는 공통의 성질 및 의미를 갖는 링크들의 집합에 대한 표현입니다. 두 클래스가 서로 Association관계가 있다면 한쪽 객체에서 다른 객체를 참조할 수 있음을 의미합니다. Association은 향후 다른 클래스에 대한 포인터나 레퍼런스로 구현됩니다. 표기법 화살표 없는 실선(양방향 관계) - 제품과 공급자는 Association관계 - 보통 분석단계에서 정의하는 형태 - 아직 참조방향이 결정되지 않은    의미적인 관련성만을 표현한 형태 한쪽 화살표를 가진 실선으로 표현(단방향-Navigation 관계) - 화살표는 참조의 방향을 나타냄 - 공급자는 제품을 참조할 수 있지만,    그 반대는 참조할 수 없음을    나타냄 (Navigation) - 참조방향을 정의하는 것은    모델링 과정에서 진전함을 의미 - 클래스간 참조 방향을 정의하는    것이 구현 과정에서 편리 여러가지 장식(adornment)이 부가된 상세한 표현 - Association관계에 대해 표현할 수 있는 모든 것을 표현한 형식 - 실무에서는 모든 클래스 다이어그램에서 위와 같은 상세한 표기를 전부    적용하지는 않음 - 일반적으로 역할 명 > 관계 명 > 관계 수의 순서로 생략하는 비율이 높음 - 관계 수는 가른 두 종류의 부가표현보다 훨씬 의미가 중요하기 때문에,    상세화가 진행되면서 반드시 정의하고 있음 정의 및 특징 Aggregation 관계는 Association관계의 일종입니다. Aggregation은 두 클래스간에 "전체-부분(whole-part)"의 관계가 있을 경우 정의됩니다. Aggregation 관계는 클래스 각각이 독립적인 생명주기를 가집니다. 즉, 전체에 해당되는 클래스가 소멸되더라도 부분에 해당되는 클래스는 소멸하지 않고 계속 존재할 수 있습니다. 표기법 속이 빈 마름모가 붙은 실선 - 마름모가 붙은 쪽이 "전체" 클래스,    반대쪽은 "부분" 클래스 - 왼쪽의 예는 자동차는 1개의    엔진과 1개의 변속기와 4개의    바퀴로 구성된다는 의미 자동차가    소멸되더라도 부품으로서의 엔진,    변속기,바퀴는 소멸되지 않음 정의 및 특징 Composition 관계 역시 Association 관계의 일종입니다. Composition 관계는 Aggregation 관계와 유사하게 두 클래스 간에 "부분-전체" (part-of)의 관계가 있을 경우 정의됩니다. 그러나 Composition 관계는 부분의 생명주기가 전체의 생명주기에 종속적인 관계입니다. 즉, 전체가 생성될 때 부분도 생성되고, 전체가 소멸될 때 부분도 함께 소멸합니다. 표기법 속이 찬 마름모가 붙은 실선 - Aggregation관계와 "전체-부분"의   의미는 동일 - 이 관계는 생명주기가 서로 같은   관계 - 왼쪽 예에서 고객등록 윈도우가   생성될 때 저장버튼,취소버튼도   생성됨 - 고객등록 윈도우가 소멸될 때 저장버튼, 취소 버튼도 소멸. 즉, 부분의   생명주기는 전체의 생명주기에 종속적 정의 및 특징 generalization 관계는 두 클래스는 일반화-특수화 관계가 있을 때 정의합니다. 즉, 보다 보편적인 것과 보다 구체적인 것 사이의 관계입니다.(is-a 관계라고도 합니다) generalization관계는 상속(inheritance) 특성을 가집니다. 표기법 삼각형 화살표가 붙은 실선 - 결재 클래스는 보다 일반적인 클래스 (Generalized Class)이고, 금결재,    카드결재, e-cash결재는 보다 특수화(Specialized Class)된 관계임 - 결재 클래스의 속성과 오퍼레이션은 공통적이고 일반적인 것으로 정의되고,    하위의 3개의 클래스는 자신만의 특수한 속성과 오퍼레이션을 정의함 - 일반화된 속성, 오퍼레이션과 동일한 것을 하위의 클래스가 정의해야할    필요가 있더라도 이를 정의하지 않음. (상속되어 따로 정의하지 않더라도    일반 클래스의 것을 그대로 사용할 수 있기 때문) 정의 및 특징 한 쪽 클래스가 실행 도중 다른 쪽 클래스의 실행을 요청하는 경우에 정의합니다. Dependency 관계는 클래스간의 사용 관계를 표현합니다. Association 관계에 비해 훨씬 종속적입니다. (Association은 존재하는 단순히 다른 객체를 참조하고 실행을 의뢰하지만, Dependency 관계는 다른 객체를 생성하고,소멸시키는 등 보다 종속적인 관계에 대해 정의합니다.) 표기법 화살표 붙은 점선 - TransactionManager 클래스와 Course    클래스 사이에 Dependency 관계가 존재 - 위의 예는 TransactionManager 클래스의    오퍼레이션에서 Course 클래스가    파라메터로 사용됨 Dependency 관계로 정의되는 사례 클래스 사이에 Dependency 관계가 정의되는 경우는 다음과 같습니다. (A 클래스와 B 클래스 사이에 A-->B의 Dependency 관계를 가정합니다.) B 객체가 A 객체의 오퍼레이션에서 파라메터로 사용될 경우 B 객체가 A 객체의 오퍼레이션에서 지역 변수(local variable)로 선언될 경우 B 객체가 전역 객체일 경우 (속성과 오퍼레이션 모두 public 접근선언)    클래스 식별방법   클래스를 식별하는 것은 객체지향 패러다임에 익숙하지 않은 초보자에게 쉬운 일은 아닙니다. 클래스를 식별하는 쉽고 확실한 방법은 경험이 가져다 주는 직관입니다. 그러나 초보자에게는 막막하기만 합니다. 가장 효과적인 방법은 후보 클래스에서 부적합한 것을 탈락시키는 방법입니다. 초보자가 사용할 수 있는 적절한 방법은 클래스가 될 수 있는 후보 클래스를 가능한 한 많이 나열한 후 부적합한 것들을 제거해 나가는 방법입니다. 후보 클래스를 나열하기 위해서는 문제영역을 잘 분석하여 이해하는 것이 선행되어야 합니다. 클래스를 식별하기 위해서 다음 순서로 진행합니다. ※ 아래의 번호를 순서대로 클릭하세요 다음은 SW 시스템에 대한 문제영역 기술서입니다. 아래의 기술서를 읽어 보고 클래스를 식별해 봅시다. "An automatic teller machine accepts a cash card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash, and prints receipts. The system requires appropriate record keeping and security provisions. The system must handle concurrent accesses to the same account correctly. The banks will provide their own software for their own computers; you are to design the software for the ATMs and the network. The cost of the shared system will be apportioned to the banks according to the number of customers with cash cards." 후보 클래스 나열 (명사) 위 문제 기술서를 토대로 찾아낸 후보 클래스는 다음과 같습니다. Software , Banking Network , cashier ATM , Bank , Bank Computer Account, Transaction, Account Data Central Computer, User, Cash, Receipt System , Record Keeping , Security Provision Access , Cost , Customer 부적합한 것들 탈락시킴 문제영역과 상관없는 것 Banking Network , Recording Keeping, System, Security Provision 속성에 해당하는 것 : Receipt , Cash , Account Data 모호한 : Cost 중복된 것 : User 클래스로 채택된 것 Account , ATM , Bank Bank Computer, Cash Card , Cashier Central Computer, Customer , Transaction    관계수와 특별한 클래스 간 관계   정의 클래스와 클래스가 인스턴스화 되어 연결 관계를 맺을 때, 관계에 참여하는 객체의 개수를 정의한 것입니다. 특정 클래스의 인스턴스에 대해 Association 관계에 있는 다른 클래스의 인스턴스가 몇 개 관련되어 있는가를 의미합니다. 관계수의 유형 Many (* 또는 n ) 클래스 B의 인스턴스 하나에 A 인스턴스 여러 개와 관계 Exactly five(5) 클래스 B의 인스턴스 하나에 A 인스턴스 다섯 개와 관계 Zero or more (0..n) 클래스 B의 인스턴스 하나에 관계된 A 인스턴스가 없거나 여러 개 One to Ten (1..10) 클래스 B의 인스턴스 하나에 관계된 A 인스턴스가 1개보다 많고 10개 보다 적음 Exactly two, three or five(2,3,5) 클래스 B의 인스턴스 하나에 관계된 A 인스턴스가 2개 혹은 3개 혹은 5개임 다중 연관관계 (Multiple Association) 두 클래스간에 두 가지 이상의 Association이 존재하는 경우를 말합니다. 이 경우 Association에는 반드시 관계 명이 정의되어야 합니다. 일반적으로 다중 연관관계는 바람직하지 않으며, 클래스를 분할하는 방식으로 이를 해소하는 것이 좋습니다. 사람과 교과목 사이에는 수강하다(사람이 수강생일 경우)와 강의하다(사람이 교수인 경우)의 두 가지 Association이 존재할 수 있습니다. 재귀 연관관계(Reflexive Association) 같은 클래스끼리 맺어지는 관계가 존재합니다. 과목에는 선수과목이라는 과목이 0개 혹은 다수 개가 존재합니다. Qualifier 연관관계 관계 수가 복잡할 때 사용합니다. (one-to-many, many-to-many) Qualifier - 속성 혹은 속성의 집합이며 이들 값으로 Association에서 객체의 집합을    구별하는 목적으로 쓰입니다. - Association에서 객체를 분리하기 위한 Key의 일종으로 간주되기도 합니다. - 복잡한 관계 수를 간략하게 하기 위해 정의합니다. 한번의 주문(주문 클래스)에는 여러 가지의 주문상품 Item(주문Item)이 있을 수 있습니다. 원래는 주문에 대한 주문 Item의 관계는 0..n 이었지만, Qaulifier로 "제품"이 정의된 후의 관계는 0..1로 되었습니다. 왜냐하면 어떤 주문에서 특정 제품에 대한 주문 Item은 없거나 하나이기 때문입니다. 연관 클래스(Association Class) 연관 클래스는 Many-to-many Association 관계에서 도출됩니다. Association 관계가 고유의 속성이나 오퍼레이션이 필요할 경우에 정의됩니다. Association 관계당 하나의 연관 클래스만이 도출 가능합니다. 첫 번째 모델에서 기술수준이라는 속성을 추가하고 할 때, 그 대상은 사람 클래스도 부적절하고 기술 클래스도 부적절합니다. Association에 추가해야 하는데, 이렇게 해서 연관 클래스가 새롭게 정의되었습니다.    사례연구   다음은 대학에서 교과목과 교수, 학생을 클래스 다이어그램으로 모델링한 사례입니다. 다이어그램을 잘 살펴보고 의미하는 바를 해석해 봅시다. 대학에서 교과목과 교수, 학생을 클래스 다이어그램으로 모델링한 사례입니다. 모델링 초기단계라서 속성과 오퍼레이션은 정의되어 있지 않습니다. 이 모델은 다음과 같은 정보를 줍니다. 교수는 교과목을 3개까지 강의할 수 있습니다. 학생은 과목은 수강하지 않거나 네 과목까지 수강할 수 있습니다. 한 교과목당 적어도 3명이상 많아도 10명까지 수강할 수 있습니다.   다음은 정보처리 시스템에서 흔히 볼 수 있는 전형적인 클래스입니다. 다이어그램을 잘 살펴보고 의미하는 바를 해석해 봅시다. 제일 윗쪽의 클래스들은 boundary class입니다. UI를 제어하는 역할을 가집니다. Boundary Class들은 UI 이벤트가 발생할 때 MemberManagement 클래스를 생성시키고, 이 클래스의 오퍼레이션에 적절한 처리를 의뢰하게 됩니다. 명령을 접수한 MemberManagement 클래스는 실제로 데이터를 관리하는 <<entity>>형 클래스인 Member 클래스에게 실제 데이터를 저장하고 조회하도록 의뢰합니다. Member 클래스는 Data Base에 접근하여 접수한 처리를 수행합니다. 이 예는 정보처리 시스템에서 흔히 볼 수 있는 전형적인 클래스의 구조이자 형태입니다.   실제 현실에서 경험할 수 있는 사례를 가지고 모델링을 수행한 결과를 살펴보도록 하겠습니다. 아래에 기술된 문제영역은 모델링의 대상이 되는 주제와 이것과 관련된 주변정보를 제공합니다. 이 문제영역을 분석하여 클래스 다이어그램을 작성해 보세요. 그런 다음 다이어그램 보기 버튼을 클릭하여 클래스 다이어그램과 비교해 보시기 바랍니다. A병원은 이번 기회에 SW 시스템을 구축하여 업무의 일부를 자동화 하기를 원합니다. A병원에는 기존 시스템으로 병원의 수입과 지출을 관리하는 "회계 시스템"이 운영되고 있습니다. 이 시스템과 연계하면서 병원정보, 환자의 병력 및 진료정보, 의료진 정보의 각종 정보 관리와 진료 예약 처리 및 수납지원을 수행하는 신규 시스템을 구축하기를 원하고 있습니다. 병원의 각 관계자는 시스템을 통해 아래와 같은 기능을 수행하기를 원합니다. 진료비는 진료정보를 입력하면 자동 산정됩니다. 환자는 진료 예약을 하고, 환자의 과거병력과 진료정보는 관리됩니다. 일반사용자는 병원 정보와 의료진 정보를 조회하고 상담 및 문의를 할 수 있습니다. 의료진은 자신의 진료스케쥴을 자동 생성하고, 진료 내역을 관리하고, 환자 정보를 조회하기를 원합니다. 원무과 직원은 이 시스템을 통해 진료비 청구서를 조회,발행하고, 진료예약을 확정하기를 원합니다. 오퍼레이션,속성과 관계 수는 생략된 상태입니다. 가장 초기상태(Conceptual Level)에 해당되는 모델입니다. 이 클래스들은 모두 <<entity>> 형 클래스입니다. 상세화가 진행되면 여기에 추가로 <<control>>과 <<boundary>> 클래스가 부가되어 사례2와 같은 형태가 됩니다.     작성단계 및 유의사항     클래스 다이어그램을 작성하는 순서는 딱 정해진 바는 없습니다. 그러나 프로젝트 현장에서는 다음의 순서대로 작성하는 것이 일반적입니다. 물론 순서를 꼭 지켜야만 하는 것은 아닙니다. 객체를 식별하고 클래스를 정의합니다. 사용자 문서나 유즈케이스 정의서, 문제 기술서등을 참고하여 객체를 식별합니다. 식별된 객체를 바탕으로 클래스를 정의합니다. 이 단계에서는 클래스 명 정도만 표현합니다. 속성과 오퍼레이션을 정의합니다. 클래스의 속성과 오퍼레이션을 정의합니다. 한번에 상세한 정의를 마치지 못하므로 여러 번 정제과정을 거쳐야 합니다. 클래스간 관계를 정의합니다. 클래스와 클래스간 관계를 정의합니다. 관계의 종류를 결정하고, 관계 명을 부여합니다. 관계 수를 정의합니다. 정제과정을 반복합니다. 클래스 다이어그램은 분석과 설계 과정에서 지속적으로 정제되어야 합니다. 다른 모델을 작성하는 과정에 새로운 클래스가 추가되기도 하고, 관계가 변경되기도 합니다. 이러한 변화와 상세화 과정을 클래스 다이어그램에 반영합니다. 다음은 클래스 다이어그램 작성시 주의사항입니다. 모델의 단순성을 유지하도록 합니다. 불필요하게 복잡한 클래스 다이어그램이 되지 않도록 단순성을 유지하는 것이 좋습니다. 의미있는 이름을 부여하도록 합니다. 클래스 명, 속성 명, 오퍼레이션 명, 관계 명 등은 직관적으로 의미가 이해될 수 있도록 의미있는 이름으로 정해야 합니다. 명칭은 모호하지 말아야 하고 명확해야 함은 물론입니다. 포인터나 레퍼런스는 관계성으로 대신합니다. Association은 그 자체가 상대 클래스의 인스턴스에 대한 포인터나 레퍼런스의 의미를 이미 가지고 있기 때문에 별도로 정의할 필요가 없습니다. 여러 클래스가 동시에 관계를 가지는 association의 경우는 이를 둘 간의 관계로 분리하는 것이 좋습니다. 세 클래스 이상이 한꺼번에 관계를 가지는 것이 가능합니다. 그러나 이는 구현과정이 어렵기 때문에 미리 두 클래스의 관계로 분리하는 것이 좋습니다. 관계 수는 복잡하지 않게 정의하는 것이 좋습니다. 객체모델은 많은 반복 작업을 통하여 완성합니다. 빈번한 클래스 다이어그램의 수정을 두려워하지 않도록 합니다. 클래스 다이어그램은 많은 반복 작업을 통하여 완성되는 것임을 명심합시다.