0. Process Model의 초기 단계
: Requirements capturing 및 analysis
- 초기 requirment 분석의 중요성?
: 초기 설계가 부족하면 계속해서 덧붙이게 됨. 이는 지저분한 결과를 초래한다(SW quality 저하)
Requirement Capturing를 통해 requirement list와 use case diagram을 제작하게 된다. 그러나 아직 Implementation 하기에는 과정이 불충분하다. 구현에 더 가까운 또 다른 모델을 작성해야한다.
Use case model alone is not enough !
1. Why Analysis Requirements
: 다양한 requirements finding 기법을 통해 functional/non-functional/usability requirement를 찾아낸 후 requirement list와 use case diagram으로 정리
- Fact Finding Techniques
① Background Reading
② Interviewing
③ Observation
④ Questionnaires
- use case diagram (1)
- analysis class diagram (3)
- communication diagram (2)
use case diagram-(1)을 그린 후 communication diagram-(2)을 그리면 Tool이 자동으로 최종 design class diagram-(3)을 완성해준다.
use case class diagram : 특정 use case에 대해 그린 diagram
Analysis class diagram : use case class diagram의 class 기준 합집합
design class diagram : analysis class diagram에 return type, return value, parameter등을 디자인 (detailed design)
2. Realize a Specific use case
1) Single Use case
: 아래와 같은 Use case "Add a new advert to a campaign"을 구현하기 위해서는 다수의 object가 협력(Collaboration)해야함
2) Collaboration
: 그렇다면 위 그림에서 협력(Collaboration)은 무엇을 포함하는가?
- boundary object, control object, entity object의 collaboration으로 구성
=> 이와 같이 Collaboration을 통해 Single Use case를 구현할 수 있다.Collaboration에는 Use case를 구현하기 위해 필요한 모든 object와 그 관계를 표시 (물론 object는 다른 Use case를 realize하는 데에도 사용될 수 있음)
3) Class Stereotypes
: Collaboration에 사용되는 object의 종류
1) Class Stereotypes
- Notations for boundary class
① Boundary class
외부(actor,system,device,person,, etc.)와 interaction을 위한 클래스
=> 외부에서 input을 받고 내부의 처리 결과를 전달
=> Control로 전달
② Control class
Use Case realize를 위한 모든 동작 시나리오를 알고 Entity object와 Boundary object를 시나리오에 맞게 호출하도록 함
③ Object class
(일반적)특정 정보를 관리하고 그에 대한 서비스를 제공
=> behavior & state로 구성
※ 모든 Use case마다 Boundary 와 Control object가 존재
3. Communication diagram
다음의 예시를 통해 use case diagram으로부터 communication diagram을 작성하는 방법을 확인해보자.
- Single Use Case
다음은 'Campagin Manager' 라는 actor가 'Add a new advert to a campaign'라는 use case 사용을 의미하는 Use case diagram(1)이다.
그러나 “add a new advert to a campaign” 기능을 사용하려면 Client(광고주)를 찾고 그 광고주가 의뢰한 Campaign찾고 그리고 Advert(신문광고, 라이도 광고, TV광고 등)를 추가해야한다.
(위 Use Case Diagram은 이러한 내용을 모두 포함)
-
Communication Diagram
Use case realize를 위한 oject간 interaction을 나타낸 Diagram
AddAdvertUI : boundary object
AddAdvert : control object
else : entity object
nested call
e.g 3 -> 3.1 호출 -> 3.1.1 호출
collaboration (object간)을 통해 use case를 realize -
Use case Class diagram
class diagram for single use case
4. Class Diagram
Use case마다 boundary와 control 클래스가 존재
entity class의 instance는 다수의 communication diagram에 중복되어 사용될 수 있음
=> 이러한 use case class diagram의 합집한이 최종적인 class diagram으로 발전
- Generalization
- Association : instance간 연결(link)가 생길 가능성이 있다면 class 사이에는 association이 존재
1) Association - Multiplicity
: Cardinality를 정해줘야함 (1:1, 1:다, 다:다, 즉 mapping 관계)
class StaffMember {
private :
Client *m_client;
- e.g)
1.. : 1이상
3.. : 3이상
0..1 : 0 or 1
1..7 : 1,2,3,4,5,6,7
3,5,19 : 3,5,19
1,3,5..* : 1,3,5,6,7,8,9
2) Types of Association
- object 간 관계와 마찮가지로 2가지 타입이 존재
- IS-A
상속 관계
- HAS-A
A object has B instance
(speacial type)
=> Aggregation & Composition = whole(전체)와 part(부분)
① Aggregation(집합) : 빈 마름모 기호
- whole-part 개념
e.g : A campaign is made up of adverts
② Composition(구성) : stronger than aggregation
- 조건-i) 각 part는 한 시점에 반드시 하나의 whole에만 속하여야함
- 조건-ii) whole이 삭제되면 part 또한 삭제된다
※ When you are working with class diagram..
1. association 관계를 생성
2. 이름을 붙이고
3. 방향을 명시
4. multiplicity 작성
5. special case(aggregation/composition) 확인
3) Generalization
- 둘 이상의 class가 비슷한 기능을 제공할 때, 'Bottom-up' 혹은 'Top-Down' 방식을 통해 Generalization을 찾을 수 있다
