1. 개요
Single use case로부터 Collaboration을 고려해 communication diagram과 class diagram을 작성할 수 있다. 그렇다면 이제 '코드를 짜면' 되는건가?
- Things left to do
Class Analysis Diagram 작성 후 design & implentation 단계 이전에 detailed design 과정을 거쳐야한다. 해당 단계에서는 클래스의 변수와 함수의 파라미터, 반환 값 등을 구체적으로 디자인 하는 과정으로 Detailed design이 완료된 후 실제 Implementation 과정을 수행하게 된다.
2. Detailed Design 이란?
:Object-Oriented detailed design 과정은 다음의 항목에 대한 디테일을 추가한다.
- types of attributes
- operation signatures
- assigning responsibilities as operations
- additional classed to handle user interface (추후 자세히 다룰 예정)
1) Attributes
- uml에서 변수 선언 및 초기화
※ 변수명 : 변수형 = 초기값 {property-string}
e.g. BankAccount class
nextAccountNumBER : Integer
/availableBalance : Money
accountName : String {not null}
quealification[0..10] : string
- 밑줄 : static 변수 (class-scope)
- / : derived 변수 (base class에서 가져온 속성)
- {not null} : option 값, null을 허용하지 않음
- array : [0..10] => 길이가 11인 배열 선언
2) Operations
-
uml의 함수 선언 및 정의
※ 함수명 (params list) : 반환형e.g. BankAccount class
open(accountName:String):Boolean
getAccountName():Sting -
모든 함수를 다 나타내지 않음
-
기본 생성자, 소멸자, get, set 함수는 표현하지 않음
매개변수가 존재하는 생성자는 나타냄
3) Visibility
: attribute와 operation의 access level을 나타냄
| symbol | visibility | description |
|---|---|---|
| + | Public | 외부에서 접근 가능 |
| - | Private | class 내부에서만 access |
| # | Protected | class와 subclass에서 access |
| ~ | Package | package area에서 access |
3. Good Design이란?
- 그렇다면 good design이란 무엇인가
다음 2가지 기준으로 good design을 평가할 수 있다.
① Coupling : degree of interconnectedness (object간 dependency)
② Cohesion : degree to which an element (operation, class, subsystem, system) contributes to a single purpose
①가 낮을수록 모듈화가 잘 되어있는(의존도가 낮은) 좋은 디자인이며 하나의 목적을 달성하도록 설계하여 ②를 만족해야함.
1) Interation Coupling
-
coupling의 정도를 어떻게 판단하는가?
ⓐ number of message types (얼마나 여러 종류의 function을 호출하는가 )
ⓑ number of parameters
ⓐ, ⓑ 를 minimize 하여 coupling(의존도)를 낮추는 방향으로 design하여야함 -
coupling을 최소화하여 최대한 change가 적도록 & reuse가 용이하도록 설계할 것
2) Operation/Class Cohesion
- operation과 class는 하나의 목적 달성을 위해 설계하여야함.
다음의 예를 들어, 왜 이러한 design이 좋은 design인지 확인해보자.
e.g. 다음과 같은 Lecturer class의 경우 'poor' class cohesion을 가진다. roomLength, roomWidth, calculateRoomSpace와 같은 속성은 lecturer class(강사 클래스)에서 굳이 제공할 필요가 없는 변수/함수이다.
Lecturer
lecturerName
lecturerAddress
roomNumber
roomLength
roomWidth
calculateRoomSpace()
그렇다면 위 class를 2개의 class로 분할하면 더 나을까?
Lecturer
lecturerName
lecturerAddress
Room
roomNumber
roomLength
roomWidth
calculateRoomSpace()
만약, Room을 사용하는 lecturer가 최대 3명이라고 하자.
i. 전자('poor' cohesion)의 경우, lecturer object를 3개 생성 & 3개의 object는 동일한 room 속성을 가짐
ii. 후자의 경우, room object 1개 생성해서 같은 방을 쓰는 lecturer이 이 object reference를 가지기만 하면됨 (better!)
※ 즉, 하나의 클래스에 가능한 많은 속성과 함수를 넣는 것이 인스턴스의 개수를 줄여 효율적일거 같지만, 결국 더 많은 instance를 생성하게 한다. 'poor' cohesion is bad!
You should do
- Requiremetns Capturing
- Requirements Analysis
- Use case diagram
- communication diagram from use case diagram(description)
- Class diagram (union of use case class diagram)
- Add details to class (attribute, operations considering 'good' design)
- Now you are ready to implement (이제 코딩을 하는 것)
