[소프트웨어공학] 클래스 모델링의 방법과 절차

Intro

[ 소프트웨어 개발 과정 ] 

문제정의 - 요구사항 파악 - 유스케이스 작성 단계를 거치면 "클래스 다이어그램"을 작성하게 된다.

즉 클래스 모델링 방법을 알아야 한다.

 

---

클래스 모델링 프로세스

 

1. 객체 파악

2. 클래스 선택

3. 연관관계 파악

4. 상속(단순화, 일반화)

5. 속성 파악

6. 클래스에 책임 주기

7. 오퍼레이션 파악

8. 모델 테스트

9. 반복 및 정제

 

.

.

 

각 과정을 아래서 간단히 설명한다.

 

 

---

1. 객체 파악

문제정의서의 모든 명사에 밑줄을 그으며 객체를 파악하기 시작한다.

유의할 점은, 무작정 명사에 밑줄을 그어야 한다. 명사간 어떠한 관계를 파악하려고 하지 않는다.

entity뿐만 아니라 개념 따위도 밑줄을 긋는다.

이렇게 밑줄 그은 명사들을 기반으로 다음 단계에서 '클래스 선택'을 하게 된다.

 

---

2. 클래스 선택

밑줄 그은 명사들로부터 클래스가 될 것을 추린다.

- 중복 제거

- 문제와 관련 없는 것 제거

- 객체가 아니라 속성이 될 만한 것들을 제거

- 객체가 아니라 오퍼레이션이 될 만한 것들을 제거

- 역할이 되어야할 것들을 제거 (ex. '직원'이 아니라 '웨이터'인 것들을 제거)

- 구현과 관련된 단어 제거 (ex. 트리, CPU 같은 단어들)

- 모호한 클래스를 명확하게 변경

이렇게 추려진 클래스를 통해 '초기 클래스 다이어그램'을 형성하기 시작한다.

클래스를 추렸다면 다음은 클래스간 관계를 파악해야 한다.

 

---

3. 관계 파악

클래스 간 관계를 파악한다. 다음과 같은 과정을 거쳐 최종적인 관계를 파악해낸다.

- 관계 파악

- 관계 제거

- 관계에 대한 다중성 결정

- 관계 세분화

  (잘못된 것 수정, 모호한 관계를 명확히 수정, 고차(order)인 연관관계를 분해하기)

 

▶ 관계 파악

문제정의서를 보면서 클래스간 관계를 잘 파악해낸다.

근데 일단 파악 초기에는 관계의 종류(연관관계, 집합관계 등)을 구분할 필요는 없다.

 

▶ 관계 제거

필요 없거나, 어딘가에서 중복되거나, 무효한 연관관계를 잘 파악해서 제거한다.

 

▶ 관계의 다중성 결정

one-to-one, many-to-one, many-to-many, optional 이런 것을 결정하자는 거다.

참고로 일대일 관계인 연관관계는 거의 존재하지 않는다고 한다. 클래스에 둘 이상의 인스턴스가 연계될 수 있는지 따져서  다중성을 잘 결정하자.

 

▶ 관계 세분화

- 잘못된 연관관계 수정하기

  내가 명시한 것이 관계인지 오퍼레이션인지 구분을 잘 하자.

참고) 

  어떤 오퍼레이션은 클래스 사이에 연관관계가 존재할 수 있다는 지표가 되기도 한다.

  다중 오퍼레이션은 하나의 연관관계로 인해 접근가능해진다.

예시) 인쇄 시스템 : 프린터 클래스 ─ 큐 클래스

  큐는 아래와 같이 큐에 대한 여러 오퍼레이션을 가지고 있다고 하자.

프린터	큐
	op1: 항목 순서를 바꿈 op2: 대기 항목 삭제 op3: 큐 액세스 거부 op4: 오버플로 처리

  프린터와 큐 사이에는 하나의 연관관계만 있다. (상태: 프런터가 큐에 연결됨)

  하나의 연관관계만 맺으면 프린터는 큐에 있는 여러 오퍼레이션을 사용할 수 있다.

- 모호한 관계를 명확히 하기

  관계를 식별하게끔 역할명을 화살표에 추가하면 명확해진다. 이것은 특히 재귀 연관관계에 중요하다.

  Boss가 Worker를 관리하는 경우를 생각해보자. Person이 Person을 관리하는 상황이라서 재귀 연관관계로 나타내게 된다. 이런 경우 역할(role name)을 명시해서 어떤 관계인지를 명확히 해주자. 동사구로 표시하는 관계의 이름도 명시해줄 수 있다. 

ex) 아래는 role name으로 worker, boss를 명시했고, association name으로 manages를 명시했다.

 

- 고차의 관계를 분해

만일 클래스 3개 이상이 연관관계가 맺어져있다면, 대부분 2개 클래스간 관계로 다시 표현할 수 있다.

 

 

---

4. 상속을 통한 단순화, 일반화

 

- 하위 클래스를 생각해보기 (Top down)

  기존의 클래스를 세분화해야 할 경우 하위 클래스로 쪼개보자.

 

- 상위 클래스를 생각해보기 (Bottom up)

  공통적인 것들을 상위 클래스에 할당하려고 노력해보자.

 

 

 

---

5. 속성 파악

- 문제정의서에 기술된 내용을 보고 속성을 파악할 수 있다.

- 그러나 대부분 문제정의서에 없는 내용이 속성이 된다. 이런 속성을 정할 때는 관련된 지식이 수반된다.

  중요한 속성부터 파악해나가면 된다.

 

속성을 파악했다면, 그 속성들이

- 다른 속성에서 파생되는 속성인지 확인한다.

- 링크 속성인지 확인한다.

  링크 속성은 일반적으로 many-to-many 연관관계에서 자주 발견된다.

  ex) 동아리-학생 관계의 링크 속성은 학생의 동아리에서의 역할쯤이 되겠다.

 

그리고 불필요한 속성을 삭제하는 것과, 그것이 과연 실제로 속성이 맞는지, 해당 속성이 해당 클래스에 들어가는 것이 정말 적절한지 잘 판단하는 것도 중요하다.

 

 

---

6. 클래스에 책임 주기

- 요구사항 명세에서 파악한 각 기능적 요구사항은 클래스 중 하나에 들어간다.

- 책임을 결정하여 클래스에 주기 위해 유스케이스를 분석할 수 있다.

- 클래스의 책임을 적정 수준으로 주어야 한다. 

 

책임을 클래스에 적절히 주었다면, 그 책임을 다하기 위한 오퍼레이션을 파악해낼 차례이다.

 

 

---

7. 오퍼레이션 파악

클래스의 각 책임을 구현하기 위해 오퍼레이션을 정의한다.

책임의 주요 오퍼레이션은 public이 되고, 책임을 위한 부수적인 오퍼레이션은 private으로 선언하자.

 

 

---

8. 모델 테스트

모델이 잘 만들어졌는지 테스트한다.

- 모델 다이어그램을 통해 접근경로 추적해보기

- 어떠한 결과를 예상해보고, 모델이 그 결과를 산출하는지 확인하기

- 모든 질문에 모델이 대답 가능한지 확인하기

 

모델 테스트 후 팀원이나 최종 사용자와 산출물을 검토하자. (워크쓰루) 

 

 

---

9. 반복 및 정제

지금까지 

1. 객체를 파악하고

2. 클래스 선택하고

3. 연관관계 파악하여

모델을 잘 만들었지만, 부족한 부분은 충분히 있을 수 있다.

 

누락된 부분 때문에 발생하는 징후들을 파악하여 올바른 방향으로 수정해나가자.

 

 

 

 

---

여기까지 클래스 모델링의 전체적인 절차와 방법을 정리해보았다.