Software Engineering 6 - System Sequence Diagram & Operation Contract

 System Sequence Diagram(SSD) : system의 input/output event를 나타내며 operation contract를 표기. object design을 할 때 참고할 수 있고 UML의 sequence diagram이다.
external actor, 그 액터의 system(as blackbox - system 내부는 표기하지 않는다), system event by the actor 등을 표기한다.
즉, use-case의 시나리오를 진행하는 동안, 외부 액터와 시스템 간의 인터렉션을 표현하는 diagram이다. 외부 액터와 이벤트, fault/exception, timer event 등 어떤 외부 input event에 대해 system이 어떻게 반응하는지, 무슨 일을 하는지 (behavior)를 명시한다.
단, 여전히 무엇을 하는지만 명시하고 어떻게 하는지 (해당 시스템 내부에서 발생하는 일)는 관심이 없다.
SSD는 주로 elaboration의 iteration을 거치며 만들어진다. 추후 operation contract를 작성하는데 도움이 되며, 사용하는 액터는 모두 외부 API와 같으므로 이에 대한 위험성을 추측하는데도 사용된다.
Operation contracts
system에 request를 하는 것 = system operation. 이 operation에 의해 domain model의 object 들에 변화가 발생하고, 이런 변화를 pre/post condition과 함께 서술한 것. (post condition = state of object in domain model after the operation)
즉, domain model이 request를 받고 어떻게 변화하는가 를 설명하는 모델. 주로 design model에서 object 들의 method를 수행할 때 나오는 결과를 나타내는데 사용.(design level에서 사용) UP에서는 domain model(object)에서 high level system operation의 의미를 명확하게 하기 위해서도 사용한다. (requirement level)

System Operation (System interface 집합의 원소)
앞서 SSD 를 통해 명시되며, 시스템 내부는 블랙박스이므로 어떻게 작동하는지는 아직 명시하지 않아도 된다.
즉 system 외부로 제공되는 interface, system event를 보여준다. 특히 input event를 담당하는 system operation은 내부의 연산을 호출하여 해당 이벤트를 처리하므로 시스템 전체를 하나의 클래스로 볼 때 제공되는 인터페이스 메서드로 생각할 수 있다.

- post condition : change in state of object in domain model
instance create/delete, association form/break, attribute change 등이 주로 기술되며 system operation의 effect를 가장 명확하게 확인할 수 있는 것이다. 만약 use case에서 해당 operation의 결과가 충분히 이해된다면 굳이 따로 만들 필요 없을 수도 있다.
일반적으로 과거형으로 작성(해당 변화가 일어난 것을 관찰하고 서술한 것이므로)

requirement analysis : Do the Right thing - 요구사항을 분석하는 과정은 클라이언트가 원하는 것을 정확하게 밝혀내는 것이므로 정답이 있는 과정.
Design work : do the thing right - 반면에 해당 요구사항을 충족하는 프로그램을 디자인 하는 것은 정답이 없는 과정. (그렇지만 올바르게 되어야 함)
iterative development에서는 requirement, OOA design, implementation이 각 iteration마다 조금씩, 서로 교환되며 일어난다.
그리고 변화가 발생하기 쉬운 것은 이른 iteration에서 처리하여 빨리 파악하고 해당 변화를 빨리 적용시켜 추후에 rework를 방지하는 것이 좋다. 따라서 elaboration이 끝나면 보통 80% 이상의 requirement가 잘 define되어 있어야 한다.

Use-case diagram & description
시나리오는 반드시 명확하고 이해가 쉬운 문장 스타일로 기술하며, 개발자의 입장이 아니라 사용자의 입장에서 서술해야 한다. 따라서 개발 용어가 아니라 해당 도메인의 용어를 사용해야 함.
시나리오의 각 스텝의 주어는 시스템/액터로 설정하며 능동태로 서술한다. (카드가 삽입된다 -> ATM 사용자는 카드를 삽입한다) 또한 시스템과 액터의 입/출력이 명확하고 구체적으로 기술되어야 한다.
CRUD는 대안 시나리오로 기술한다. 앞서 살펴보았듯이 각 CRUD를 모두 따로 서술하면 가독성이 너무 떨어지므로 공통된 것으로 묶는 것이 좋다고 하였다. 마찬가지로 use case diagram에서도 각 시나리오에서 이를 모두 기술하면 읽기 힘드므로 C/R/U/D를 작성할 때는 기본 시나리오에서 분기하여 대안 시나리오로 서술한다.(하나의 use-case 안에 합쳐서 작성)
Pre & post condition
pre condition(선행 조건) : 해당 시나리오의 시작 시점에서 필요하고 타당한 조건인가, 시스템이 선행 조건에 대한 판단, 대처를 할 수 있는가? 즉, use case의 시작 전에 수행 시작을 위해 항상 만족되어야 하는 조건이므로 어떤 스텝이 진행되고 얻을 수 있는 정보를 토대로 판단하는 것은 선행 조건이 될 수 없다. (사용자의 정보를 확인하는 등은 로그인을 한 후에나 가능하므로 선행으로 확인 불가능) 이런 조건들은 UI에 반영되는데 자주 사용된다.
post condition(후행 조건) : 해당 시나리오의 종료 시점에서 필요한 조건인가, 시스템이 해당 후행 조건에 대한 판단과 대처를 할 수 있는가? 단, 이 조건은 각각의 스텝의 종료가 아니라 전체 시나리오가 종료될 때 만족되므로 각 스텝이 끝날 때는 만족하지 않을 수도 있다. 이것이 만족되지 않았다면 정상 동작하지 않았다는 것을 알 수 있지만, 해당 조건들이 만족되었다고 유즈케이스가 올바르게 수행되었다고는 판단할 수 없다.
기본 시나리오(happy path) 뿐 아니라 대안 시나리오 별로, 혹은 모두 한 번에 후행 조건을 기술할 수도 있다.

Actor : 사용자/시스템 등이 subject와 interaction할 때 가지는 role(자격/역할), 동일한 사람이 시스템을 사용할 때 서로 다른 기능을 사용한다면, 서로 다른 역할을 가질 수도 있다. actor는 system과 interaction하는 모든 요소이며 system 개발 범위 외부에 존재해야 한다.
Scenario(= use case instance) : specific sequence of action and interaction btw actor and the system.
use-case : 시스템이 제공할 기능이며 사용자 관점의 궁극적인 결과를 바탕으로 이름 지어야 함. use case는 business flow를 나타내지 않는다. (use case 간의 관계는 include, 상속 , extend, generalization만 가능하다) 이들 간의 선 후행 관계는 activity diagram을 통해 나타내야 한다.
association : use-case를 위해 필요한 interaction의 대상 actor와 모든 association이 정의되어야 함.

Use-case relationship(복습)
- include(~포함한다 등으로 서술) : behavior of one use case(included) is integrated in another(base). 서브루틴의 호출처럼 control이 넘어갔다가 다시 돌아오는 방식으로 작동. 단, base는 included가 없으면 완전하지 않다는 것을 기억해야 한다. (공통된 것을 factor out 시킨 것이므로 dependency를 가짐. base -> included) 이는 모듈화를 통해 재사용성을 높임.
다만 작고 디테일한 것들까지(개발자 관점의 decomposition) 기능적 분할을 하는 것은 좋지 않다. 왜냐하면 이는 프로그램을 design 하는 것이 아니라 RA를 하고 사용자 관점을 뽑아내는 것이므로. (actor에게 유용한 goal을 성취하는 것이 use-case)
-extend : base use-case가 extending use를 사용하는 것. 사용방식은 위와 비슷하게 control이 넘어갔다가 돌아오지만, 이 경우에는 extend가 반드시 필요하지 않아 base 혼자 독립적으로 존재할 수 있다.(optional-상황에 따라 필요없을 경우 extended를 제거하면 된다.) 따라서 dependency의 화살표 방향이 extended->base 가 된다.(base는 extend를 모름, extension point만 제공) extended scenario는 base scenario의 한 부분으로서 수행된다. 또한 하나의 base는 여러 개의 extended를 가져 확장성을 높이고 유연하게 최종 기능을 가질 수 있다.
종합하면, dependency(include-base, extend-extended)가 있는 것은 상대방(include-included, extend-base)이 수정될 경우, 자신도 수정되어야 한다.