[C++] OOP 프로그래밍 실습 - 설계 (클래스 다이어그램)

10.4 설계

 

 설계 단계에서는 클래스 다이어그램과 시퀀스 다이어그램을 작성해 봅시다.

 

 먼저 프로그램에 클래스로 정의할 후보를 조사하고 이들에 대하여 클래스 명과 역할을 결정합니다. 그리고 각 클래스간의 관계를 포함하여 클래스 다이어그램을 작성합니다. 이 작업이 수행되고 나서 각 유즈케이스 별로 시퀀스 다이어그램을 작성할 것입니다. 시퀀스 다이어그램을 작성하기 위해서는 해당 유즈케이스를 수행하기 위해서 어떠한 순으로 진행해야 하는지와 진행 단계에서 어느 개체가 어느 개체에게 어떠한 메시지를 보내고 받아야 하는지에 대해서 결정을 할 것입니다. 이를 통해 클래스에 public으로 접근 수준을 설정할 멤버 메서드의 시그니쳐가 약속되게 됩니다.

 

10.4.1 클래스 다이어그램 작성

 

 먼저, 시나리오를 보면서 클래스로 정의할 것들을 조사해 봅시다. 시나리오에 나타나는 명사들을 먼저 살펴보고 이들이 무언가를 수행할 역할이 있다면 클래스로 정의할 후보가 될 것입니다. 그리고, 하나의 클래스가 너무 많은 멤버 필드나 너무 많은 역할을 한다면 좀 더 세부적으로 나누는 것이 효과적일 것입니다. 어느 정도의 멤버 필드가 있을 때 세부적으로 나눌 것인지 자신의 원칙이 있다면 좋은 디자인 능력을 익히는 데 도움이 될 것입니다. 시나리오에 있는 것 중에 여기서는 다음과 같이 클래스를 만들려고 합니다.

 

클래스 명	설명
EHLand	이 에이치 나라
UnitFactory	유닛 공장(유닛의 생성과 소멸에 대한 책임을 지님
Place	장소 (주거지와 공연장이 있음)
Village	주거지
Hall	공연장
Unit	유닛(마법사, 예술가, 회사원이 있음), IRelax와 IPlay를 구현 약속함
Magician	마법사
Artist	예술가
Worker	회사원
IRelax	주거지에서 할 수 있는 행위에 대한 약속
IPlay	공연장에서 할 수 있는 행위에 대한 약속
Arr	배열을 템플릿 클래스 화

 

 그리고 주거지와 공연장에서 유닛이 할 수 있는 행위가 다르므로 각 장소에서 할 수 있는 추상적인 약속도 추상 클래스로 정의하려고 합니다. 주거지에서 할 수 있는 행동에 대한 추상적인 정의를 IRelax, 공연장에서 할 수 있는 행동에 대한 추상적인 정의를 IPlay라 명명하도록 하였습니다. IRelax나 IPlay와 같이 특정 행위에 대한 추상적인 약속들로 구성된 클래스를 다른 OOP언어에서는 interface라는 형식으로 제공하는 경우가 많이 있습니다. 이와 같은 클래스는 내부에 순수 가상 함수들로만 구성되게 됩니다. 이처럼 행위에 대해 약속함으로써 주거지에서 유닛들이 공연을 관람하는 행위를 호출하는 것과 같이 시나리오에 맞게 특정 장소에서 특정 행위만을 수행할 수 있게 할 수 있습니다.

 

 이처럼 무엇을 클래스로 만들 것인지 결정을 하였으면 각 클래스의 관계를 약속하여 클래스 다이어그램을 작성해 봅시다. 여기에서는 Arr클래스는 단순히 개체를 보관하기 위한 컨테이너 용도이기 때문에 클래스 다이어그램에서 생략하도록 하겠습니다.

 

 먼저, 일반화 관계를 살펴보면 Place의 종류로 Village와 Hall이 있으므로 이들은 일반화 관계에 있다고 할 수 있을 것입니다. 그리고 Unit의 종류로 Magician, Artist, Worker가 있으므로 이들 또한 일반화 관계에 있다고 할 수 있을 것입니다.

[그림 10.4]

 

 그리고 Unit은 IRelax와 IPlay를 구현 약속을 해야 하므로 이들의 관계는 실현 관계로 표현할 수 있을 것입니다.

[그림 10.5]

 

 EHLand와 관계가 있는 클래스 먼저 생각해 봅시다. EHLand는 UnitFactory와 각 장소를 생성하고 이들 개체와 UnitFactory 개체를 통해 생성된 Unit 개체들을 사용하게 됩니다. 하지만, EHLand에서는 유닛이 어떠한 종류의 유닛인지를 판단하여 해당 형식에 맞는 행위를 사용하지는 않습니다. 이에 대한 관계를 도식한다면 [그림 10.5]와 같이 표현할 수 있을 것입니다.

[그림 10.6]

 

 이번에는 UnitFactory와 관계가 있는 클래스들을 생각해 봅시다. UnitFactory는 Magician, Artist, Worker 개체들을 생성하고 생성한 이들 Unit 개체들에 관한 소멸의 책임을 지니고 있습니다. 이들 개체들에 관한 소멸의 책임을 지기 위해서는 이들을 보관하고 있어야 합니다.

[그림 10.7]

 

 이번에는 각 장소와 관련된 클래스들을 살펴볼게요. 각 장소에는 유닛이 들어올 수 있어야 하며 공연장에서는 IPlay에 대한 구현 약속된 행위를 사용하고 주거지에서는 해당 유닛의 IRelax에 대한 구현 약속된 행위를 사용해야 하며 합니다. 또한, 공연장에서는 예술가가 논평할 수 있어야 하고 주거지에서는 회사원이 알람 설정, 마법사는 달나라 여행을 할 수 있어야 합니다. 이를 클래스 다이어그램으로 표현한다면 [그림 10.8]과 같이 도식할 수 있을 것입니다.

[그림 10.8]

 

 [그림 10.9]는 전체 클래스 다이어그램의 모습입니다.

[그림 10.9]

 

 클래스와 클래스 사이의 관계는 개발자에 따라 바라보는 관점에 따라 조금씩 다르게 생각할 수도 있고 클래스 다이어그램에서 나타내는 정도도 차이가 있을 수 있습니다. 완벽한 정답을 구하려는 것보다는 특정 수준을 정하여 해당 수준에 맞게 해 나가는 것이 필요할 것입니다.

10장 OOP 프로그래밍 실습 Part1

10장 OOP 프로그래밍 실습 Part2

10장 OOP 프로그래밍 실습 Part3

(모든 동영상 강의는 무료입니다.)