'IT 관련/소프트웨어 공학'에 해당되는 글 3건

0. 들어가기에 앞서

 클래스 다이어그램은 시스템 구조를 나타내고, 객체지향 모델링의 빌딩 블록으로 사용된다.

 여러 다이어그램들 중 객체지향 언어와 직접적인 연관을 가지는 유일한 다이어그램이고, 어플리케이션의 구조 디자인, 분석, 시스템의 역할 묘사, 그리고 Reverse Engineering(역공학)에 사용될 수 있다.

 개인적인 프로젝트 경험으로, 시스템이 어떤 요소들로 구성되는지 사람들에게 설명해주고, 시스템 유지 보수를 위해서 많이 사용했었다.

1. 클래스 다이어그램

 클래스 다이어그램은 클래스와 클래스들 사이의 관계를 나타내는 정적 모델이다.

 클래스 다이어그램은 클래스와 그들 사이의 Relationship(관계)로 구성된다.

1.1 클래스(Class)

- 시스템 내의 오브젝트들(사람, 장소, 물건 등등)

- 시스템 내의 정보를 저장/관리한다.

- Attribute(클래스의 특성), Operation(클래스의 동작)을 가진다.

예시

환자 클래스

 이는 진료 예약 시스템에서 환자(Patient)라는 클래스다.

 Patient 클래스는 amount(진료비), insurance carrier(보험회사 명)이라는 Attribute를 가지고, make appointment(진료 예약), calcuate last visit(최근 방문일 계산), change status(상태 변환), provides medical history(진료기록 제공)이라는 Operation을 가진다.

1.2 Relationship

- 클래스들 사이의 관계

- 클래스들 사이의 선으로 표현된다.

예시

 이것도 병원 진료 예약 시스템의 일부분이다.

 Patient는 Appoinment(예약)을 스케줄하는 관계를 가진다.

 Patient 1명이 여러번 진료 예약을 할 수 있으니, Patient는 n (0 <= n)개의 Appointment와 관계를 가진다.

클래스 다이어그램 예시 

 이 그림은 클래스 다이어그램의 한 예시다.

2. Relationship의 종류

 클래스들간의 관계를 나타내는 Relationship에는 다음과 같은 것들이 있다.

 Association은 클래스와 클래스 사이의 관계, 혹은 클래스 자신과의 관계를 나타낸다.

 단순한 줄로 표시하고, 연관된 클래스가 서로 어떤 관계를 나타내는지를 표시하고, Multiplicity Symbol이라는 것을 가진다. 이 예시의 경우 오른쪽 클래스 하나당 왼쪽 클래스가 0개이상 관계를 가지는 예시다.

 Generalization은 a kind of 관계를 나타낸다.

 객체지향 언어에서 부모 클래스 상속, 인터페이스 구현을 이것으로 표현한다.

 Aggregation은 Association의 한 종류로, 논리적인 a part of 관계를 나타낸다. A class is a part of B class라고 하면 A는 논리적으로 B와 Aggregation 관계를 가진다고 표현 할 수 있다.

 Composition은 Association의 한 종류로, 물리적인 a part of 관계를 나타낸다. A class is a part of B class라고 하면 A는 논리적으로 B와 Composition관계를 가진다고 표현 할 수 있다.

Aggregation VS Composition

 Aggregation과 Composition은 모두 포함 관계를 나타내는데, 논리적/물리적인 관계를 나타낸다는 차이만 있다.

 이게 잘 헷갈리는 부분인데, A is a part of B일 때 이 관계가 Aggregation 관계면 B가 소멸되도 A는 소멸되지 않고, Composition 관계면 B가 소멸 되면 A도 함께 소멸된다고 보면 된다.

(그리고 두 경우 모두 A가 소멸되도 B는 소멸되지 않는다.)

 예를 들어, "학생 is a part of 동아리" 관계는 Aggregation 관계이고, "바퀴 is a part of 자동차" 관계는 Composition 관계다. 동아리가 소멸되어도 학생들은 소멸되지 않기 때문에 이는 논리적인 관계고, 자동차가 소멸 될 때는 바퀴도 함께 소멸되므로 물리적인 관계라고 볼 수 있다. (바퀴를 따로 떼서 파는 경우는 생각하지 말도록 하자.)

3.클래스 다이어그램 간소화

 클래스에는 Concrete Class와 Abstract Class가 있다. 그 중 Concrete Class만 묘사하여 다이어그램을 간소화하는 방법인데, 이는 잘 고려해보고 써야한다.

 어떤 Concrete Class인 CClass가 Abstract Class인 AClass를 상속받고 있고, 다른 외부 클래스들이 주로 AClass와 관계를 가지는 경우, 이 방법을 쓰면 다이어그램을 이해하기 어려워지는 원인이 될 수 있기 때문이다.

 View 메커니즘은 원래 데이터베이스에 나오는 개념이다.

 데이터베이스에서 View는 필요한 데이터만을 원하는 형태로 골라서 본다는 개념인데, 이를 클래스 다이어그램에도 적용하여 상황에 따라 필요한 클래스들만 묘사하여 다이어그램을 간소화하는 방법이다.

 연관된 클래스들끼리 묶어 패키지로 만드는 방법이다. 패키지로 취급하면 다이어그램이 더 간단해질 수 있다.

4. 레퍼런스

System Analysis & Design 5th - WILEY

https://ko.wikipedia.org/wiki/%ED%81%B4%EB%9E%98%EC%8A%A4_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8 - 위키피디아 클래스 다이어그램

https://www.tutorialspoint.com/uml/uml_class_diagram.htm - Tutorial Point. Class Diagram

1. Activity Diagram이란?

 액티비티 다이어그램은 일련의 Activity들로 어떤 프로세스를 표현하는 다이어그램으로, 모든 종류의 프로세스를 표현하는데 사용 될 수 있다.

2. Acitvity Diagram의 구성

 Action/Activity - 어떤 Action이나 Action의 집합. 동사 + 명사로 이름이 붙여짐.

 Object Node - 한 Activity에서 다른 Activity로 이어지는 flow of information을 나타내는 것.

 Control Flow - 실행 순서를 나타내는 화살표.

 Object Flow - Flow of Object를 나타내는 것.

 Initial Node - Activity Diagram의 시작점(Action 들의 시작점)

 Final Node - Activity Diagram 종료지점(Activity의 Flow들이 모두 끝나는 시점)

 Decision Node - 분기점.

 Merge Node - Decision Path들을 하나로 모으는 노드.(Decision Node로 나눠진 Control flow를 다시 합침)

 Fork Node - 평행적으로 수행되는 Flow를 나누는 노드

 Join Node - Fork Node로 나눠진 Control Flow를 다시 하나로 합치는 노드

 구성 요소들을 정리해놓고 보니 너무 많고 애매한 정의가 많아서 정의를 달달달 외우는 것 보다는 예시를 보면서 이해하고, 나중에 필요할 때는 예시와 정의를 같이 찾아보는게 좋겠다.

 컨트롤 노드

 Initial node, Final node, Decision node, Merge node, Forke node, Join node를 컨트롤 노드(Control Node)라고 부른다.

 예제

 다음 액티비티 다이어그램은 병원의 진료 예약 관리 기능에 대한 것이다.

 진료 예약 관리에서는 예약, 예약 취소, 예약 변경 기능을 제공한다.

 처음 이 액티비티가 시작되면 환자의 정보를 받는다.(Get Patient Onformation)

 이 때 예약정보(Appt Request Info) 오브젝트가 생성되어 이후 예약 할 지, 예약을 취소 할 지, 예약을 변경 할 지 결정할 때 사용된다.(기존 환자)

 또, 이 오브젝트는 신규 환자가 예약을 잡을 때도 사용된다.

 환자의 정보를 받은 이후에는 기존에 등록된 환자인지, 신규환자인지에 따라 다른 프로세스가 진행된다.

3. Swimlanes

 Swimlane은 오브젝트들간의 역할 분리를 나타낸다. 분리된 역할들이 서로다른 오브젝트에서 평행적으로 수행된다.

 Swimlane은 가로로 그려도 되고 세로로 그려도 된다.

 예제

 이 예제는 학교 점심 도시락을 만드는 Activity에 대한 액티비티 다이어그램이다.

 이 액티비티가 시작되면 바로 firstParent와 secondParent로 flow가 분할되어 평행적으로 진행된다.

 firstParent를 보면 내부에서 다시 GetJelly, GetPeanutButter, GetBread로 flow가 분할되어 평행적으로 수행되는데, 처음에 firstParent, secondParent로 나뉜것과는 달리 모든 flow가 오브젝트 내부에서 수행된다는 차이가 있다.

4. Activity Diagram 작성 가이드라인

5. Activity Diagram과 Usecase의 관계

6. 레퍼런스

System Analysis & Design 5th - WILEY

1. 유즈케이스(Use case)

 사용자가 시스템을 어떻게 사용하는지를 나타내는 것.

 시스템의 기본적인 기능들(사용자가 시스템을 사용하여 어떤 일들을 할 수 있는지, 시스템이 어떤 방식으로 반응하는지)를 나타내는 것.

 하나의 유즈케이스는 사용자가 어떤 작업을 처리할 때 수행하는 일련의 과정들이다.

 유즈 케이스는 소프트웨어를 설계하는 과정에서, 건축용 블록과 같은 역할을 한다.

 각각의 유즈케이스들은 각각 하나의 역할만을 설명한다.

2. Usecase 다이어그램

2.1 Usecase 다이어그램의 기본 구성

 유즈케이스는 다음과 같은 요소들로 구성되는 다이어그램으로, UML(Unified Modeling Language)로 표현한다.

- 액터 : 시스템을 이용하려고 하는 서브젝트 외부의 사람, 혹은 시스템. 스틱맨으로 표현하기도 하고, 박스로 표현하기도 함

- 유즈케이스 : 시스템 기능의 주요한 조각.

- 서브젝트 : 주제의 범위를 나타내는 것.

예시

병원 진료 예약 시스템의 유즈케이스 다이어그램

 이 예시에서 시스템은 예약 조율, 스케줄 제공, 가능한 시간 입력이라는 기능을 제공한다.

 각각의 기능들은 유즈케이스로 표현, 진료예약 시스템이라는 Subject로 범위 제한, 액터는 환자, 관리자, 의사 이렇게 3명이다.

 각각의 유즈케이스들은 환자, 관리자, 의사라는 액터와 상호작용하므로 Association 관계로 표현한다.

2.2 Usecase 간의 관계

 유즈케이스들 간에 서로 Genalization, Inclusion, Extension 관계를 가질 수 있다.

- Genalization : 일반화(generalized)된 유즈케이스는 좀 더 자세하게 정의된 유즈케이스다.

- Inclusion : A가 B를 Include한다는 것은, A의 작업이 B를 포함한다는 것을 나타낸다.

- Extension : 예외적인 상황을 커버하기 위해 사용되는 관계.

예제

병원 진료 예약시스템 확장판

 몇 가지만 살펴보자.

 우선 환자가 예약을 하는 유즈케이스(Manage Appointments)는 환자가 신규 환자, 기존 환자 두 가지 타입으로 늘어났으니, 신규 환자 예약(Make New Patient Appt)과 기존 환자 예약(Make Old Patient Appt) 두 가지로 나누어야한다. 그래서 Genalization 관계를 적용해 두 가지 유즈케이스로 나누었다.

 새로운 환자가 예약을 잡는 유즈케이스는(Make New Patient Appt) 신규 환자 등록이라는 유즈케이스(Create New Patitent)를 포함하므로 includsion 관계로 표현한다.

 환자 정보를 업데이트하는 유즈케이스(Update Patient)는 기존 환자가 예약을 잡는 유즈케이스(Make Old Patient Appt)에서 특별한 경우(환자 데이터를 업데이트 해야하는 경우)에만 사용되므로 Make Old Appt 유즈케이스에서 확장되어 extension 관계로 표현된다. (화살표 방향을 쉽게 헷갈리므로, 헷갈리지 않게 주의)

3. UseCase Description

 유즈케이스를 문서에 포함할 땐 유즈케이스 다이어그램은 필수로 들어가야하고, 유즈케이스 Description은 선택적으로 넣는다. 유즈케이스 Description은 유즈케이스 다이어그램 작성에 필요한 모든 정보들을 담는 것으로, 하나의 UseCase Description이 하나의 UseCase를 설명한다. (유즈케이스 다이어그램 전체를 설명하는 것이 아니다.)

 개인적인 경험상 유즈케이스들마다 일일히 Description을 작성하려면 시간 소모가 커서 굳이 필요하지 않다면 생략하는게 나을 듯 싶다.

 UseCase Description은 다음의 세 부분으로 구성된다.

- Overview : 이름, ID, 종류, 가장 중요한 액터, 간략한 요약, 중요도 레벨, Stakeholders(관계자들), 트리거

- Relationships : 유즈케이스들 간의 Association, Extend, Include, Generalization.

- The flow of events : Normal flow(보통의 활동들), Sub flow(유즈케이스를 간단하게 하기 위해 Normal flow를 분해한 것), Alternate/Exceptional flow()

- 기타 사항들

예시

4. 유즈케이스 작성 요령

* Kiss 원칙 : Keep It Simple Stupid의 약자. 원칙이라기보다는 복잡한 것 보다는 간단한 게 좋다는 일종의 격언이다.

5. Use Case Description 작성 요령(순서)

6. 레퍼런스

System Analysis & Design 5th - WILEY

https://ko.wikipedia.org/wiki/KISS_%EC%9B%90%EC%B9%99 - KISS 원칙