프로젝트 계획(9-1) - 정적 모델링(static modeling) [소프트웨어공학]

 

 

전에 이어서 정적 모델링을 위한 클래스 다이어그램을 작성하려고 한다.

심볼, 규정, 규칙들을 알아봤으니까 이제 실전이다

 

 

---

모델링 할 때 순서없이 생각나는 대로 작업하면 당연히 품질 하락. 노동력 상승의 결과를 낳을 것이다.

그러면 순서를 정하고 작업을 시작해야 한다는 얘기다. 

클래스 다이어그램 작성 순서를 알아보자

 

1. 클래스가 될 만한 후보를 파악

도메인 분석할 때 개념을 장 정리해야 클래스를 쉽게 찾을 수 있다.

++요구 추출 시 사용한 자료들에서도 발견할 수 있다,

 

2. 가장 중요한 클래스를 시작으로 연관, 상속, 속성을 추가

유사한 클래스를 묶어서 슈퍼클래스를 생성하거나

복잡한 클래스를 나누어서 서브클래스를 생성하는 방법이 있다.

각각 상향식, 하향식 관계라고 부른다.

3. 클래스의 주요 임무(responsibility)를 찾아내어 오퍼레이션으로 추가

클래스에 의하여 수행될 기능을 간단한 문장으로 나타낸다.

 

 

이 3단계를 다시 되풀이하면서 추가, 삭제 하면서 다이어그램이 완성된다. 

 

**설계 패턴(design pattern)은 후에 알아보자 ㅎㅎ

 

 

 

---

이제 순서를 알았으니

1단계인 클래스를 어떻게 찾는 알아볼까?

 

클래스를 찾는 작업은 객체 모델링에서 가장 처음으로 하고 가장 중요한 단계라고 볼 수 있다.

첫 단추를 잘못 끼우면 망하듯이 신중하게 정확하게 찾아야 한다.

 

다시 말해서, 도메인 개념, 즉 사용 사례로부터 클래스가 될 만한 것들을 찾는 일이다.

도메인에 있는 추상적인 개념이나 중요한 액터 자체도 클래스가 될 수 있다.

 

클래스가 될 수 있는 후보에는

 

1. 구조 2. 외부 시스템 3. 디바이스 4. 역할 5. 운용 절차

6. 장소 7. 조직 8. 완성된 시스템에 의하여 조작되어야 할 정보

 

들이 있다.

 

 

클래스는 실세계에 존재하는 개체만이 아니라 추상적 개념도 될 수 있다고 위에서 언급한 것과 같이

클래스가 될 수 있는 후보들이 많다. 

 

그래서 조심해야하는 점이 있다. 바로 클래스 이름을 짓는 것인데

(중요하지 않아보이지만 은근히 중요하다)

 

이름을 지을 때 주의 사항을 알아보자  // 알고만 넘어가자 ㅎㅎ

 

1. 중복하지 말자

2. 인스턴스를 명확히 나타낼 수 있어야 한다.

3. 구체적인 정보를 담지 않는 일반적인 이름은 피한다.

ex information //? 무슨 정보인지 알 수 없다.

 

 

 

** 인스턴스(instance)는 같은 클래스에 속하는 하나의 객체로, 하나의 클래스에서 생성된 객체를 말한다.

 

 

 

위에서 클래스를 찾는 법을 알아봤지만 제대로 잘 모를 거같다. 나도 그렇다.

클래스의 종류는 역할에 따라 3가지가 있다고 한다

 

1. 엔티티 클래스(entity class)

2. 경계 클래스(boundary class)

3. 제어 클래스(control class)

 

그래서 나눠서 더 자세히 찾는 방법을 알아보도록 하자

 

 

---

엔티티 클래스부터 찾아봅시다

 

그러면 우선 정의부터 알아보자면

엔티티 클래스란 시스템에서 영구적으로 저장되어 사용될 자료를 보관하는 역할을 하는 클래스라고 한다.

** 영구적으로 저장/검색/활용이 가능한 정보를 넣은 클래스

 

비디오 가게를 예로 들면

다들 실제로 존재하는 개체들은 대부분 복합적인 자료를 가지고 있어서 엔티티 클래스가 될 가능성이 크다.

 

엔티티 클래스는 다시 말하자면 시스템에서 계속 추적해야할 자료가 들어 있는 클래스다. 

ex) 비디오 대여 정보는 반납되더라도 데이터 베이스에 계속 저장하고 내역으로 저장할만한 자료다. >> 엔티티클래스

 

그렇지만 저기 위에 가능성이 크다라고 적어놓은 만큼 아닌 것도 존재하는데 

시스템의 요구에 따라 엔티티 클래스로 분류할 지를 정한다.

 

그래서 엔티티 클래스인지 알아보기 위해 간단한 질문을 던져본다

1. 사용 사례를 이해하기 위하여 사용자와 개발자가 명확히 규정한 용어인가?
2. 사용 사례에서 반복되어 나오는 용어인가? (예를 들면 Video Tape)

3. 시스템이 계속 추적하여야 하는 실세계의 엔티티인가? (예를 들면 Rental, Title)
4. 자료저장소 또는 단말인가?(예를 들어 Scanner)
5. 자주 사용하는 응용 도메인의 용어인가? (예를 들어 Customer)

 

 

요약하자면 저 질문들에 답에 yes라고 답할 수 있다면 엔티티 클래스로봐도 무방하다는 것이다.

 

 

 

---

이번엔 경계 클래스를 알아보자

 

경계 클래스는 주로 시스템 외부의 액터와 상호 작용하는 클래스로 사용자 인터페이스를 제어하는 역할을 한다.

다시, 경계 클래스는 액터와 연결된 시스템 인터페이스를 나타낸다.

 

경계 클래스는 액터로부터 정보를 수집하여 엔티티 객체나 제어객체가 사용할 수 있는 형태로 바꾼다.

 

경계 클래스를 정하기 위해서 적당한 기준을 가져왔다 

 

1. 사용자가 자료를 시스템에 입력하기 위하여 필요한 양식과 윈도우를 찾음 (예를 들면 RentalUI, ReportRental)
2. 시스템이 사용자에게 반응하는 메시지나 알림을 찾음(예를 들어 PendingRentalNotice)
3. 인터페이스가 어떻게 보이는지는 경계 객체에 모형화 하지 않음
4. 인터페이스를 나타내는 사용자 언어는 구현 기술과 관련 없는 용어 사용

 

시스템과 액터 사이의 인터페이스를 경계 클래스로 정의함으로써 시스템 분석 작업이 되었지만

액터와 시스템 사이의 대화 순서와 같은 더 중요한 사항이 남아있으니까.. 또 알아보자

 

---

위에서 말한 바로 제어클래스를 알아보자

 

제어클래스는 경계 클래스와 엔티티 클래스 사이에 중간 역할을 하는 클래스다. 

제어 클래스는 실체가 존재하진 않지만 사용 사례와 제어 클래스 사이에는 밀접한 관계가 있다.

 

**제어 클래스는 사용 사례의 초기에 생성되고 끝까지 존재한다. 그래서 경계 클래스로부터 정보를 받아 엔티티 클래스에게 전달해준다.

 

 

또 기준을 가져왔다 ㅎㅎ

 

1. 사용 사례가 복잡하여 소규모의 이벤트로 분할해야 한다면 하나 이상의 사용 사례 당 1개의 제어 클래스를 찾음
2. 사용 사례에서 액터 하나 당 하나의 제어 클래스를 찾음
3. 제어 클래스는 사용 사례 또는 사용자 세션 안에서만 유효. 제어 클래스가 활성되는 시점과 끝이 명확하지 않다면

    사용 사례가 명확히 파악되지 못한 것

 

다시 말해서 제어 클래스는 비즈니스 로직을 담고 있는 클래스다.

바로 자료를 다른 클래스로 받아 처리하는 클래스.

 

 

---

클래스를 다 찾았나?? 그럼 이제 2단계인 관계 찾기를 해보자

먼저 연관부터 찾자.

 

클래스 다이어그램은 클래스 사이의 구조적인 연결을 나타내는 만큼 클래스 사이의 연관을 찾는 것이 중요하다.

 

연관에 대해서 다시 설명하자면

연관이란 2 개 이상의 클래스 사이에 어떤 관계가 있음을 나타내는 것이다. 

다시말해서, 어떤 클래스의 인스턴스가 작업을 수행하기 위하여 다른 클래스를 알아야 한다.

 

Rental 클래스에 어떤 고객이 어떤 테이프를 얼마동안 빌려갔는지 기록해야 한다. 

따라서 Rental 클래스는 Customer와 Video Tape 클래스와 연관이 있다.

 

연관 관계는 속성을 갖는다.

1. 이름 - 두 클래스 사이의 연관 관계를 나타냄
2. 역할 - 연관 관계의 양쪽 끝에 있는 클래스의 기능을 나타냄
3. 다중도 - 연관 관계를 구성하는 인스턴스의 개수

 

한 번 완성된 클래스 다이어그램을 보고 어떤 연관 관계를 알 수 있는 지 살펴보자

 

대부분의 클래스와 연관 관계를 포함해서 거의 완성 단계에 이르면

**액터가 각 클래스를 접근할 수 있는지 조사해야 한다. 이런 것들을 정확히 정의해야 클래스의 인스턴스들을 찾고 연관 관계에 따라 추적가능하다.

 

---

이제 속성을 추가해야한다. 

 

속성은 개별 객체들이 가지는 특성이다. 

 

위에 있는 Receipt처럼

Date, Title, Total 같은 것들이 속성이다. 

 

**속성은 시스템과 관련된 것만을 추가해야 한다.

ex) Receipt에 굳이 customer의 주민등록번호가 나올 필요는 없다.

 

**클래스에 의하여 이미 표현된 특징은 속성이 아니다. 

 

속성은 3가지 요소를 가지는데

 

1. 이름 - 객체 안에서 구별할 수 있는 속성의 이름.

예를 들어 VideoTape은 PurchaseDate와 Supplier 속성을 가짐. PurchaseDate은 테이프를 구매한 날짜이며 Supplie는 비디오 공급업체를 나타냄

2. 간단한 설명 - 구현하는 프로그래머를 위하여 간단히 설명을 첨가

3. 속성값의 타입 - 예를 들어 Name 속성은 스트링.

   또한 Status는 열거형으로 rentable, rented, returned라는 값을 가질 수 있음

 

 

**엔티티 객체의 경우 시스템에 의하여 저장될 필요가 있는 것들은 모두 속성이다.

 

 

 

이제 3단계 다 공부해봤으니 실제로 예를 보고 살펴보자

 

 

---

클래스 다이어그램 작성 예시

ex) 항공권 예매 시스템 클래스 다이어그램

 

항공예매 시스템의 도메인분석

 

1. 항공권 예매시스템은 고객이 항공편을 조회, 예약할 수 있는 시스템

2. 항공사는 정기적인 항공편(flight)을 개설하고 운항한다

3. 고객은 원하는 항공편을 찾아 동행 탑승자와 함께 예약(booking), 좌석(seat)을 지정할 수 있어야한다.

또한 취소, 확약할 수 있다.

4. 항공편은 일정, 즉 출발 공항과 도착 공항이 있고, 출발 및 도착 시간이 표시 되어야 한다.

5. 공항은 주변 여러 도시를 커버한다. 어떤 항공편은 중간 기착지(stopover)가 있을 수도 있다.

 

 

위의 도메인 분석을 바탕으로, 다중도, 역할, 속성을 정한다. 

 

 

 

 

 

 

 

좌측 그림: 고객은 원하는 항공편을 찾아 동행 탑승자와 함께 예약, 좌석을 지정할 수 있다.

여기서 나오는 관계

 

customer와 passenger는 booking을 통해 이루어진다. // customer와 passenger는 다를 수 있다.

 

 

 

우측 그림: 항공편은 일정, 즉 출발 공항과 도착 공항이 있고, 출발 및 도착 시간이 표시 되어야 한다.

공항은 주변 여러 도시를 커버한다. 어떤 항공편은 중간 기착지(stopover)가 있을 수도 있다. 

 

여기서 나오는 관계

 

departure, arrival, stopover 다중도, 속성, 역할 설정 stopoverInfo는 연관 관계 추가

 

 

 

 

 

 

 

전체적으로의 관계 

 

 

다음에는 동적모델링을 배워보자