[StarUML] 클래스 다이어그램이란?(3) - 작성 단계 및 유의사항(feat. 사례)

출처 : https://blog.naver.com/he1000/220725205602

1. 작성 단계 및 유의 사항

1-1. 작성 단계

클래스 다이어그램을 작성하는 순서는 딱 정해진 바는 없습니다.그러나 프로젝트 현장에서는 다음의 순서대로 작성하는 것이 일반적입니다.물론 순서를 꼭 지켜야만 하는 것은 아닙니다

1. 객체를 식별하고 클래스를 정의합니다

- 사용자 문서나 유즈케이스 정의서, 문제 기술서등을 참고하여 객체를 식별합니다
- 식별된 객체를 바탕으로 클래스를 정의합니다
- 이 단계에서는 클래스 명 정도만 표현합니다

2. 속성과 오퍼레이션을 정의합니다
- 클래스의 속성과 오퍼레이션을 정의합니다
- 한번에 상세한 정의를 마치지 못하므로 여러 번 정제과정을 거쳐야 합니다

3. 클래스간 관계를 정의합니다
- 클래스와 클래스간 관계를 정의합니다
- 관계의 종류를 결정하고, 관계 명을 부여합니다
- 관계 수를 정의합니다

4. 정제과정을 반복합니다
- 클래스 다이어그램은 분석과 설계 과정에서 지속적으로 정제되어야 합니다
- 다른 모델을 작성하는 과정에 새로운 클래스가 추가되기도 하고, 관계가 변경되기도 합니다.
- 이러한 변화와 상세화 과정을 클래스 다이어그램에 반영합니다
1-2. 작성시 주의 사항
다음은 클래스 다이어그램 작성시 주의사항입니다
1. 모델의 단순성을 유지하도록 합니다
불필요하게 복잡한 클래스 다이어그램이 되지 않도록 단순성을 유지하는 것이
좋습니다

2. 의미있는 이름을 부여하도록 합니다
클래스 명, 속성 명, 오퍼레이션 명, 관계 명 등은 직관적으로 의미가 이해될 수
있도록 의미있는 이름으로 정해야 합니다. 명칭은 모호하지 말아야 하고 명확해야 함은 물론입니다

3. 포인터나 레퍼런스는 관계성으로 대신합니다
Association은 그 자체가 상대 클래스의 인스턴스에 대한 포인터나 레퍼런스의
의미를 이미 가지고 있기 때문에 별도로 정의할 필요가 없습니다

4. 여러 클래스가 동시에 관계를 가지는 association의 경우는 이를 둘 간의 관계로 분리하는 것이 좋습니다
세 클래스 이상이 한꺼번에 관계를 가지는 것이 가능합니다. 그러나 이는 구현과정이 어렵기 때문에 미리 두 클래스의 관계로 분리하는 것이 좋습니다

5. 관계 수는 복잡하지 않게 정의하는 것이 좋습니다

6. 객체모델은 많은 반복 작업을 통하여 완성합니다
빈번한 클래스 다이어그램의 수정을 두려워하지 않도록 합니다. 클래스
다이어그램은 많은 반복 작업을 통하여 완성되는 것임을 명심합시다

2. 사례 연구

2-1. 사례1
다음은 대학에서 교과목과 교수, 학생을 클래스 다이어그램으로 모델링한 사례입니다.
다이어그램을 잘 살펴보고 의미하는 바를 해석해 봅시다.

대학에서 교과목과 교수, 학생을 클래스 다이어그램으로 모델링한 사례입니다.
  모델링 초기단계라서 속성과 오퍼레이션은 정의되어 있지 않습니다.
  이 모델은 다음과 같은 정보를 줍니다
  - 교수는 교과목을 3개까지 강의할 수 있습니다
  - 학생은 과목은 수강하지 않거나 네 과목까지 수강할 수 있습니다
  - 한 교과목당 적어도 3명이상 많아도 10명까지 수강할 수 있습니다

2-2. 사례2
다음은 정보처리 시스템에서 흔히 볼 수 있는 전형적인 클래스입니다.
다이어그램을 잘 살펴보고 의미하는 바를 해석해 봅시다

  제일 윗쪽의 클래스들은 boundary class입니다. UI를 제어하는 역할을 가집니다.
  Boundary Class들은 UI 이벤트가 발생할 때 MemberManagement 클래스를
  생성시키고, 이 클래스의 오퍼레이션에 적절한 처리를 의뢰하게 됩니다.
  명령을 접수한 MemberManagement 클래스는 실제로 데이터를 관리하는
  <<entity>>형 클래스인 Member 클래스에게 실제 데이터를 저장하고 조회하도록
  의뢰합니다. Member 클래스는 Data Base에 접근하여 접수한 처리를
  수행합니다.

  이 예는 정보처리 시스템에서 흔히 볼 수 있는 전형적인 클래스의 구조이자 형태입니다.

2-3. 사례3
실제 현실에서 경험할 수 있는 사례를 가지고 모델링을 수행한 결과를 살펴보도록
하겠습니다. 아래에 기술된 문제영역은 모델링의 대상이 되는 주제와 이것과 관련된
주변정보를 제공합니다. 이 문제영역을 분석하여 클래스 다이어그램을 작성해 보세요.
그런 다음 다이어그램 보기 버튼을 클릭하여 클래스 다이어그램과 비교해 보시기
바랍니다.

A병원은 이번 기회에 SW 시스템을 구축하여 업무의 일부를 자동화 하기를
원합니다. A병원에는 기존 시스템으로 병원의 수입과 지출을 관리하는
"회계 시스템"이 운영되고 있습니다. 이 시스템과 연계하면서 병원정보, 환자의
병력 및 진료정보, 의료진 정보의 각종 정보 관리와 진료 예약 처리 및 수납지원을
수행하는 신규 시스템을 구축하기를 원하고 있습니다.

병원의 각 관계자는 시스템을 통해 아래와 같은 기능을 수행하기를 원합니다.

- 진료비는 진료정보를 입력하면 자동 산정됩니다
- 환자는 진료 예약을 하고, 환자의 과거병력과 진료정보는 관리됩니다
- 일반사용자는 병원 정보와 의료진 정보를 조회하고 상담 및 문의를 할 수 있습니다.
- 의료진은 자신의 진료스케쥴을 자동 생성하고, 진료 내역을 관리하고, 환자 정보를 조회하기를 원합니다.
- 원무과 직원은 이 시스템을 통해 진료비 청구서를 조회,발행하고, 진료예약을 확정하기를 원합니다

- 오퍼레이션,속성과 관계 수는 생략된 상태입니다
  - 가장 초기상태(Conceptual Level)에 해당되는 모델입니다.
  - 이 클래스들은 모두 <<entity>> 형 클래스입니다
  - 상세화가 진행되면 여기에 추가로 <<control>>과 <<boundary>> 클래스가 부가되어 사례2와 같은 형태가 됩니다