System Sequence Diagram & Operation Contract
이번 포스트에는 System Sequence Diagram과 Operation Contract에 대해 다룬다.
System Sequence Diagram
SSD (System Sequence Diagram)
- 시스템 외부의 actor와 시스템 간의 상호작용을 시간 흐름에 따라 표현한 다이어그램
- 시스템을 하나의 Black Box로 보고, 외부 사용자와의 이벤트 흐름을 시각화한 것
- 대부분 Elaboration 단계에서 생성되어, 시나리오별로 SSD를 작성하고, 점진적으로 확장됨.
SSD의 구성
- External Actor : 외부 사용자로 시스템과 직접적으로 상호작용
- System : 하나의 사각형 Black Box로 표현
- System Event : Actor가 시스템에 보내는 메시지
- External Events, Timer Events, Faults or Exception 들이 있음.
SSD의 목적
- 시스템에 입력되는 이벤트 명확화
- Operation Contract의 도출 근거를 제공함
- 객체 설계를 지원함.
Operation Contracts
- 시스템의 연산이 수행되었을 때, 시스템의 상태가 어떻게 바뀌어야 하는지를 명확하게 서술한 문서
- 시스템 동작에 따른 객체 상태 변화를 Pre/Post-condition 형식으로 명세
- 도메인 모델 또는 설계 모델에 적용
Domain Model 에서 고수준 시스템 연산의 계약으로도 사용 가능
- 고수준 시스템 연산(High-level system operation) : 사용자나 외부 액터가 시스템에 요청하는 주요 기능
System Operation (시스템 연산)
- Actor가 System에 요청하는 기능 또는 작업 단위
- 즉, 시스템이 응답해야 할 고수준 동작
System Interface
- 시스템이 외부 Actor에게 제공하는 연산들의 집합
- 즉, 시스템이 외부와 상호작용할 수 있도록 열어둔 출입구
Postconditions
- 시스템 연산이 수행된 결과로써 시스템 내부의 객체 상태가 어떻게 변했는지를 설명하는 것
- 다음 3가지 변경사항을 기술함.
- 인스턴스의 생성 또는 삭제
- 연관(association)의 생성 또는 삭제
- 속성(attribute)의 값 변화
- 사용 이유 : Use Case 의 설명만으로는 시스템이 정확히 무엇을 해야 하는지 불명확할 때, 개발자와 설계자가 같은 이해를 갖기 위해서 명확한 post conditions가 필요함.
- 작성 요령 : 반드시 과거 시제 (past tense)로 작성해야 함.
요약 : Requirements to Design Iteratively
목표 : 설계 단계로의 자연스러운 전환, UML 문법 보다는 객체 지향 설계 스킬이 더 중요함
핵심 원칙
- 요구사항은 초기에 다 알 수 없다.
- 현실적으로 모든 요구사항을 처음부터 완벽하게 정의하는건 불가능
- 반복적인 개발을 통해, 점점 더 명확하게 만들어 가는 것이 중요함.
- 변화를 두려워하지말고, 적극적으로 수용해야한다.
- Elaboration 단계가 끝날 쯤에는 전체 요구사항의 80% 정도가 명확해지고 안정된다는 뜻
즉, 반복을 통해 점차 불확실성을 제거해가는 과정이 핵심