3. OOA - Elaboration

Elaboration Iteration은 3주간 mini waterfall로 OOA → OOD → OOI ... 로 진행되는데

우선 OOA에서 Elaboration을 다뤄보고자 한다.

 

 

Elaboration

Elaboration 단계에서는 아래 일들이 진행되어야 한다.

• 핵심적이고 risky한 소프트웨어 구조를 우선 프로그래밍/테스팅
• 대부분 요구사항 식별 및 fix (iteration 돌면서 increment하게 만들어짐)
• 주요한 risk 해결

 

Artifacts Start in Elaboration

• Software Architecture Document : 정해진 Architecture 작성

 

 

Domain Models

visual representation of conceptual classes or real-situation object in a domain

 

class diagram과 비슷하지만 operation이 없고, class뿐만 아니라 사람 등 domain object를 작성하고 보통 object간의 관계는 association 선으로만 작성한다. (implementation detail 고려할 필요 없음)

 

목적

1. SW 외에 전반적인 도메인(비즈니스 로직 등)을 이해하기 위해서 작성
2. representation gap을 감소 : 도메인 layer와 design layer와의 차이를 줄이기 위해 가볍게 domain model 작성해야 class diagram 작성이 용이함
3. stakeholder 간의 이해와 커뮤니케이션 도구 (정확도는 크게 중요하지 않음)

 

 

작성 가이드라인
class diagram 작성 순서와 비슷하다.

• Use case에서 functional requirement description를 보고 큰 명사는 class object, 작은 명사는 attribute(동사는 operation이지만 현 단계에서 작성X)로 생각하여 conceptual classes를 찾는다.

 

예시

 

Use case model

UP에서 Elaboration에서는 Use case model을 작성하게 되는데 이 Use case model은 Use case Diagram과 System Sequence Diagram을 합친 것(operation contract는 optional)이다.

 

Inception 단계에서 시작해서 Elaboration 단계에서 refine(format변경이 아니라 use case 자체가 변경될 수 있음)되고 fix된다.

 

System Sequence Diagram(SSD)

시스템 수준에서 작성하는 Sequence Diagram으로 시스템을 black box로 작성하여 내부는 그리지 않고 system과 external actor 간의 (system) event를 보여준다.

 

목적

• System operation(external actor에서 system으로 들어오는 event. 즉, system이 제공하는 operation(interface))을 찾기 위해

작성 가이드라인

• OOA에서는 HW, GUI, UI가 정해져있지 않을 가능성이 커서 system event는 추상적인 level로 작성

 

 

 

propose까지 뿐만 아니라 programming되고 test되어야 한다.

domain model은 해당되는 도메인에 대해 익숙해보고 많이 개발해봤을 때에만 Design class diagram의 일종이 될 수 있다. 

 

2) System에서 external actor로 나가는 interaction은 system operation 아님  3) 내부적인 동작은 OOD-SD에서 고려  4) UML에는 SD만 있음 SSD는 단순 SD notation사용하는 것

 

3) domain model 기준으로 복잡한 것만 작성