먼저, 시나리오를 보면서 클래스로 정의할 것들을 조사해 봅시다. 시나리오에 나타나는 명사들을 먼저 살펴보고 무언가를 수행할 역할이 있다면 클래스로 정의할 후보가 될 것입니다. 그리고 하나의 클래스가 너무 많은 멤버 필드나 너무 많은 역할을 한다면 좀 더 세부적으로 나누는 것이 효과적일 것입니다. 어느 정도의 멤버 필드가 있을 때 세부적으로 나눌 것인지에 대한 자신의 원칙이 있다면 설계 능력을 키우는 데 도움이 됩니다.
시나리오에 있는 것 중에 여기서는 다음과 같이 클래스를 만들려고 합니다.
| 클래스 명 | 설명 |
| CampusLife | 캠퍼스 생활 |
| Campus | 캠퍼스 |
| Place | 강의실, 도서관, 기숙사의 기반 클래스 |
| LectureRoom | 강의실 |
| Library | 도서관 |
| Dormitory | 기숙사 |
| Student | 학생 – 추상 클래스 |
| CStudent | 도전적인 학생 |
| MStudnet | 보수적인 학생 |
| PStudent | 수동적인 학생 |
먼저, CampusLife와 관련된 클래스들과의 관계를 살펴보기로 합시다. CampusLife는 캠퍼스와 각 장소로 이루어진다고 할 수 있을 것입니다. 또한, CampusLife는 학생 개체를 생성하는 역할도 수행합니다. 그리고 CampusLife는 실제 프로그램에 해당하는 클래스이므로 단일체로 정의할게요.
Place는 강의실, 도서관, 기숙사의 기반 클래스로만 사용하기 때문에 추상 클래스로 정의하면 될 것입니다.
Student 클래스도 CStudent, MStudnet, PStudent의 기반 클래스로만 사용하기 때문에 추상 클래스로 정의하면 될 것입니다.
Campus와 각 장소에서는 학생에게 명령을 내릴 수 있습니다. 강의실에서는 도전적인 학생이 질문할 수 있습니다. 또한, 기숙사에서는 수동적인 학생이 잠꼬대할 수 있습니다. (강의실에서 수동적인 학생이 꾸벅꾸벅 졸면서 자유 토론을 하는 것은 재정의로 표현하기로 하겠습니다.)
[그림 31]은 캠퍼스 생활 프로그램의 클래스 다이어그램입니다. 클래스 다이어그램은 시나리오를 분석하는 방법이나 개발자의 성향에 따라 다르게 나올 수가 있으므로 여러분의 비판적인 사고를 통해 자신에게 맞게 정의한 후에 도식하십시오.
