🎫소프트웨어 공학 part10~11. SSD(System Sequence Diagram + System Operation Contracts)

[10장 – SSD System Sequence Diagram]

■ SSD

외부 엑터가 발생시키는 이벤트, 이벤트의 순서를 보여주는 그림이다. 각 유즈 케이스의 주요 성공 시나리오 및 자주 발생하거나 복잡한 대안 시나리오 대해서 각각 SSD를 그린다.

■ SSD 작성 동기

어떻게 동작하는가 보다는 무엇을 하는가에 초점을 맞춘 설명.
UML에는 “시퀀스 다이어그램”은 있지만, “시스템 시퀀스 다이어그램”은 없다
시퀀스 다이어그램은 설계 시 사용하는 것이다.

■ 시스템 이벤트와 오퍼레이션의 이름

■ SSD를 용어집에 쓸 때

용어집은 SDD의 구성요소들(오퍼레이션 이름, 매개변수 ,반환데이터)에 대한 적당한 설명을 쓴다.
용어집에서는 많은 산출물들에 대한 자세한 설명을 보여준다.
ex.) 영수증 -> 영수증의 견본을 용어집에 만든다.

■ UP에서의 SSD

도입 단계에서는 그려지지 않는다 (타당성 검토이기 때문)
정련단계에서 대부분의 SSD가 작성된다.

■ 프로젝트 규모 산정 은 근삿값으로 추정한다.

이전에는 본(本)수로 산정하였다. 본이란 보고서 및 화면의 개수의 총합이다.

[11장 – SSD System Operation Contracts]

■ Operation Contracts

유즈케이스나 시스템 피쳐만으로도 시스템의 행위를 충분히 기술할 수 있다.
시스템이 행위를 좀 더 구체적이고 정교하게 기술할 필요가 있을 때 시스템 약정을 기술
대부분의 Contracts는 elaboration(핵심 아키텍쳐)단계에서 끝낸다.
Contracts는 시스템의 행위를 설명한다.

■ enterItem에서의 시스템 약정

[Preconditions] (연산이 진행되기 위해 만족되어야 하는 조건)

1. 판매 과정이 진행 중.

[PostCondtions] (끝나고 만족되어야 하는 조건 – 사후조건)

생성되거나 삭제되거나, class간 association이 연결되거나 끊기거나, attribute가 변하거나

1. SalesLineItem 인스턴스 sli 생성 (class가 생성)
2. sli가 현재의 Sale과 연관 (class – class 연관)
3. sli.수량이 수량으로 변경 (attribute의 변경)
4. sli가 입력한 item ID와 매칭되는 제품설명과 연관. (class – class 연관)

■ 시스템 약정의 실 사용

[도메인 모델의 갱신 예]
도메인 모델에 판매 완료에 대한 표현이 없다는 사실을 약정에서 발견
→ 도메인 모델의 개선

■ 언제 약정이 유용한가?

세부적인 상태의 변화를 기술할 때 유즈케이스가 복잡해 지는 경우
예.) addNewReservation
유즈케이스로 무엇을 해야 하는가를 충분히 나타낼 수 있는 경우에는 약정을 기술할 필요가 없다.

■ Operation vs Method

오퍼레이션은 what으로 구체적이지 않다.
Method는 How로 구체적으로 어떻게 행동하는지이다.

■ OCL ： Object Constraint Language

UML과 연관된 형식 언어이다.
오브젝트가 만족하는 제약 조건을 표현하는데 사용되는 언어.