[OOP/UML] UP - Elaboration 단계 / OOA

# 개요

중요하고 리스크있는 아키텍쳐를 구현하고 테스트하는 단계

• 요구사항이 수정될 수는 있지만 이 단계가 끝날때는 확정되어야 한다. 
• 아키텍쳐/클라이언트 관점에서 리스크를 줄여나간다. 

 

# Artifacts

Iteration마다 리스크 관점에서 중요한 Use-case를 선택하여 아래와 같은 작업들을 한다. 

 

OOA에서는 Domain Model을 작성하는데, 그 전에 Use-case Model 작성이 필요하다.

• Inception 단계에서는 Brieft 레벨이였다면 Elaboration에서는 Casual, Fully dressed up 레벨로 작성한다.  

 

OOD에서는 Design Model을 작성한다. 

• Sequence Diagram을 그리고 그것을 바탕으로 Class Diagram을 그린다. 

 

# Domain Model

도메인에 대한 이해를 돕기 위해 작성하는 것으로, Class diagram과 비슷하게 생겼다. 

• operation이 없으며, 클래스가 실제 오브젝트가 아닌 도메인에 대한 개념일 수 있다.  
• 만약 도메인에 대한 이해가 있다면 거의 Class diagram과 같다고 볼 수 있다. 

도메인 모델이 없다면 바로 Class diagram을 그리기가 쉽지 않다. 

 

어떤 역할을 가진 사람이 그렸냐에 따라 다를 수 있으므로 정답이라는게 없다. 

 

도메인 모델은 Elaboration 단계에서 시작하며,

Construction 단계에서는 Class Diagram이 있으므로 더 이상 사용하지 않는다. 

 

# System Sequence Diagram

System Operation을 찾기 위해 그리는 것으로, Sequence diagram의 notation을 사용한다. 

• System Operation이란 시스템이 외부 인터페이스에 제공하는 Operation을 뜻한다. 

 

External actor가 시스템과 상호작용 하는 것을 표현하며, 시스템은 블랙박스로 표현한다. 

 

아직은 GUI, 하드웨어 등이 구체적으로 결정되지 않은 단계이므로 추상적으로 표현한다. 

• 아래와 같이 Enter, Scan 정도로만 표현한다. 

Elaboration 단계에서도 대부분이 Brief 레벨로 표현되어있다. 

그러므로 Construction 단계에서 상세화가 필요한데, 여기서 r은 상세화가 아닌 자체를 수정하는 것을 의미하므로 아래 표에 r이 적혀있지 않다. 

 

# Operation Contracts

어떤 Operation이 구현되어야 할지, 어떻게 구현해야 할지를 명시한 계약서

• pre-condition, post-condition을 작성한다. 
• Use case나 도메인 모델을 보고 확실히 유추할 수 있다면 필수는 아니다. 
• 필수는 아니지만 프로젝트에 따라 매우 중요할 수 있다. 

 

# QUIZ

정답: 4번. propose뿐만 아니라 구현과 평가까지 진행되어 fix되어야 한다. 

2번 - 요구사항이 수정되면 안되지만 서술 하는 레벨이 바뀔수는 있다. 

 

정답: 2, 3번. 

1번 - 도메인에 대해 잘 알고 있을때만 맞다. 

4번 - 도메인 모델은 그리는 사람에 따라 다르고 정답이 없다. 

 

정답: 1번. 

2번 - 모든 Interaction이 아니라 들어오는 것만 System operation

3번 - 내부 동작까지는 Elaboration 단계에서 고려하지 않는다. 

4번 - UML 2.0은 Sequence Diagram이고 System Sequence Diagram은 아니다. 

 

정답: 3번. Use case를 통해 확인할 수 있는 것은 만들지 않고 복잡한 것만 만든다.