Software Engineering 3 - Interaction diagram & UP

Code generation
class diagram으로 나타낸 내용은 동등한 코드로 구성할 수 있다. 단, 이 때 association class라는 것은 실제로 C++이나 java에 존재하지 않으므로 실제 구현할 때는 hashtable 등을 이용하여 적절하게 정보를 연결, 입력해주어야 한다.

Interaction Diagram
concrete scenario를 모델링하는데 사용함. 특정 상황의 상호 인터렉션, 정보를 기술함. 이 때 디테일의 정도에 따라 시스템 전체와 환경 사이의 인터렉션 부터 각 클래스 사이의 메소드 콜까지 다양한 스코프를 서술할 수 있다.

Sequence Diagram
interaction : 일련의 발생되는 이벤트
- Horizontal axis : 인터렉션 당사자들 (오브젝트), lifeline 이라는 형태로 나타나며 rolename/classname을 head로 가진다. 일반적으로 오브젝트/클래스의 이름이 롤네임이 되지만, rolename을 사용하면 object보다는 더 넓은 범위를 가리키며 시간에 따라 오브젝트들의 롤은 변경될 수 있다. head와 연결된 body는 점선으로 표현되며 해당 role의 오브젝트가 언제까지 살아있는지 표현한다.
- Vertical axis : 시간적 순서에 따른 인터렉션
특수한 경우로 자기자신의 스레드를 할당받아 인터렉션 없이 독립적으로 활동을 할 수 있는 경우 active object를, system operation을 구현할 때 특정 오퍼레이션을 가지고 있는 당사자는 self 인 life line을 가진다. (this->와 같은 의미)

Order of message
lifeline이 동일하다면 하나의 lifeline에서 일어나는 서로 다른 화살표(인터렉션)는 반드시 상위의 것이 하위의 것보다 먼저 일어난다. 그러나 서로 다른 lifeline에서 발생하는 화살표의 경우 둘 사이의 인터렉션이 명시적으로 나타나지 않았다면 시각적인 높이에 의해 시간관계를 알아내기가 불가능하다. (둘 사이의 연결관계가 없다면 위에 있다고 반드시 먼저 일어난 것은 아니다)
그러나 일반적으로 여러 lifeline 사이의 인터렉션이 다수 존재하기에(event chaining) time trace를 찾는 것은 어렵지 않다.

Message
- Synchronous message(검은 화살표) : sender가 receiver의 response message를 받을 때 까지 기다림.
- Asynchronous message(일반 화살표) : 위와 반대로 sender는 receiver의 메시지를 기다리지 않고 계속 진행함
- Response message (점선 화살표) : receiver가 sender의 메시지를 받았다고 알리는 것. 일반적으로 생략.
- Found message / Lost message(일반 화살표) : 각각 sender/receiver의 존재가 중요하지 않거나 알려지지 않았을 경우 검은 점으로 시작점/끝점을 나타내고 found, lost 키워드를 사용하여 나타낸다. 메시지의 존재가 중요하고 받거나 보낸 주체가 별로 중요하지 않을 때 많이 사용. (broadcast 등)
- Time consuming message : 일반적으로 메시지 transition은 시간지연이 없는 것으로 생각하지만 표기를 해야하는 경우 시간축으로 기울어져 얼마나 걸렸는지 표기해준다.

Object create/destruct
- Creation : message를 보낼 때 해당 객체가 아직 생성되지 않았을 경우 점선 화살표로 새 lifeline의 head를 가리키고 new 키워드를 표기한다.
- Destruction : lifeline의 끝에 가위표를 쳐 해당 lifeline이 종료되었음을 알린다.
Frame : 해당 sequence diagram이 나타내고 있는 class의 간단한 이름이나 operation speci를 적어 놓은 곳. sd 라는 키워드로 나타내고 아래에 local attribute, parameter 등을 추가로 기입할 수 있다.
Self : frame에서 나타내는 객체 자기 자신이 만들어내고 사용하는 인터렉션의 경우 여러 객체 사이에서 해당 interaction을 own 한 객체를 표기하기 위해 head에 self:classname으로 표기.  

Combined Fragment
concrete scenario들을 하나씩 다 나타내기에는 너무 많으므로 큰 틀의 minor variation, 반복하는 경우 등은 한 번에 모아 표현하는 것. 각 Frame(operator)의 operand를 가로 점선으로 구분하여 나타냄. 총 12가지가 존재한며 3가지 카테고리로 나누어진다.

1. Branches & loop
- alt fragment : switch와 비슷한 것. 주어진 상황에서 response에 따라 해야할 행동이 달라지는 경우를 나타낸다.
- opt fragment : if와 비슷한 것. else가 없는 모델링으로 하나의 operand만 가질 수 있다.따라서 주어진 조건이 true/false 일 때만 수행한다와 같은 시나리오를 나타낸다.
- loop fragment : 반복문을 나타냄. 하나의 operand만 가지고 최대, 최소 회수의 반복을 나타내기 위해 (min, max) 를 loop keyword 뒤에 붙여 준다. (디폴트는 (*)로 무한반복) 그리고 반복을 종료하기 위한 조건으로 guard 를 주는데, 최소 반복 회수가 정해져있다면 그 기간 동안은 guard를 확인하지 않는다. 그리고 최소와 최대 사이 반복 회수일 때 guard를 확인하여 false가 된다면 해당 반복을 종료하게 된다.
- break fragment : exception handling 시나리오에 사용되는 것으로 하나의 operand와 guard로 구성된다. 위와 반대로 guard가 true 값일 때 해당 부분이 수행되고, 일반적인 반복문처럼 break 이하의 과정은 수행되지 않는다. 따라서 자신이 포함된 상위 범위의 남은 것은 수행되지 않고 그 다음 상위인 범위의 것을 수행하게 된다.



2. Concurrency & order
- seq fragment : 일반적으로 order fragment의 디폴트가 seq이므로 아무것도 기입이 안되어 있다면 seq로 가정하면 된다. 일반적으로 break 등의 범위를 한정하기 위해 사용.
weak sequencing : 일반적으로 operand와 lifeline 에 따라 순서가 결정되며 같은 lifeline, 같은 operand라면 상위부터 하위로 순서대로 실행된다. 같은 lifeline에 서로 다른 operand 일 경우에도 첫 번째 operand가 두 번째 operand보다 먼저 실행된다. 그러나 서로 다른 lifeline일 경우, 각 lifeline 내에서만 순서가 상위->하위가 되고, 전체는 어떻게 될 지 알 수 없다. (위에서 메세지할 때 했던 것과 동일)
- strict fragment : 서로 다른 operand가 있을 때 다른 lifeline에서 발생한 메시지가 있더라도 operand가 가로 점선에 의해 block 단위로 구분되어 있다면 상위가 먼저 발생함을 나타낸다. 따라서 각 블록 내부는 다시 seq와 동일한 behavior를 가진다. 이를 통해 연결되지 않은 lifeline의 trace를 그릴 때 모호함을 해결할 수 있다.
- par fragment : 위와는 반대로, 가로 점선으로 나누어진 block이 서로 다르다면 (서로 다른 operand) 아예 별개로 취급하여 위에서 lifeline의 공유가 발생했더라도 무시하고 trace를 생각할 수 있다. 이 때 operand의 상/하위도 구분하지 않는다. 단, 여전히 각 block은 seq로 생각하므로 block 내부의 순서는 그대로 유지된다.
- critical fragment : 중간에 다른 interaction이 끼어들지 않고 atomic 하게 수행되어야 하는 부분을 나타낸다. 앞서 par의 경우, 서로 다른 block의 인터렉션이 사이에 막 끼어들 수 있었지만, critical로 보호할 경우, 해당 내부의 interaction은 반드시 따로 함께 수행되어야 한다. (공유하는 lifeline이 없어도 시행 순서에서 떨어질 수 없다) 마찬가지로 내부는 seq로 고려한다.

3. Filtering & assertion
- ignore fragment : 해당 블록 내에서 발생할 수도 있지만 그렇게 중요하지 않고 무시해도 괜찮은 메시지를 ignore { messageName } 을 사용하여 나타낸다.
- consider fragment : 위와 반대로 해당 블록 내에서 중요한 것을 나타냄. 따라서 ignore 메시지를 빼고 기입하여 consider {messageName } 처럼 표현. 둘 중에 기입해야 할 경우가 적어 편리한 것을 사용하면 된다.

- assert fragment : 반드시 주어진 형태의 trace만 적법하다는 것을 나타냄. 나타낸 형태와 다른 시나리오는 올바르지 않다는 것을 가리킨다.
- neg fragment : 위와 반대로 허용되지 않는 시나리오를 나타낸다. 이와 같은 상황이 발생해서는 안된다는 것을 말함.

Interaction Reference
앞서 만들었던 sd(sequence diagram)를 다른 sd를 그릴 때도 사용하고 싶을 경우, frame에 ref라 적고, sd의 이름을 적어 다른 sd를 현재 sd의 내부에 표함시킬 수도 있다.

Time Constraints
after, at, now 등의 키워드를 사용하여 특정 event의 발생시점을 나타낼 수 있다.

State Invariant
특정 객체가 특정 상태일 때만 의미가 있는 경우를 나타내고 싶을 때 해당 lifeline에 상태나 시점 혹은 자연어로 그 상태를 기술할 수 있다. 이 state invariant가 true일 때 계속 진행하고, 이 값이 false라면 모델 혹은 implementation이 틀렸다는 것을 나타낸다.

Interaction diagram = sd + communication + timing + overview
일반적인 sequence diagram를 동등한 communication diagram으로 바꿀 수 있다. 결국 둘은 나타내는 것은 동일하며, 상대적으로 communication diagram은 누가 누구와 communicate 하는지에 더 중점을 두며, sd는 시간의 순서에 따른 파트너 사이의 관계에 더 중점을 둔다.
Timing diagram은 sd를 90도 회전시키면 얻을 수 있다. sd를 timing 적으로 더 정확하게 기술할 필요가 있을 경우 사용한다. 혹은 복잡성을 줄이기 위해 label  형태로 나타낼 수도 있다.
Interaction overview diagram은 activity diagram과 sd의 결합이다. 인터렉션의 여러 개의 결합을 통해 오버뷰를 제공한다.
OOAD(object-oriented) = OOA(analysis)+ OOD(design)
OOA에서는 문제의 domain concept를 정의하고, OOD에서는 해당 문제를 어떻게 해결할 수 있는지를 찾아낸다. Domain model에서 각 클래스, 오브젝트, 속성, 관계를 정의하고, design은 그 모델의 이름, visibility 등을 구체적, 논리적으로 생성하는 과정이다. 이 때 domain model에서 생성되지 않았던 클래스를 만들거나, 표현되었던 클래스를 삭제하는 일도 발생가능하다. 일반적으로는 domain에서 표현되지 않은 클래스들을 구체적으로 설계하며 추가되는 경우가 많다.
requirement는 use case를 이용하여 나타냄. 설계는 sd를 여러 개 그리고, 해당 파트를 고려하며 class diagram을 채우는 형식으로 진행된다. (바로 class diagram을 그리는 것도 가능)
일반적으로 UML을 사용할 때는 conceptual - Specification - Implementation perspective 단계로 구분할 수 있다. 개념적은 넓은 범위에서 domain을 정의할 때, specification은 언어에 국한되지 않고 모델링할 때, 구현은 실제 언어를 사용하여 각 클래스의 타입과 operation name 등을 정할 때 사용하게 된다. 가장 많이 사용되는 수준은 개념과 구현 단계이다.

Unified Process(UP)
Iterative, Architecture-centric, Usecase-driven한 특징을 가지는 software development process. 점진적인 플래닝을 하므로 처음부터 모든 계획을 세울 필요는 없다.
- Inception - Elaboration - Construction - Transition 의 순서로 phase가 구분된다. Inception은 러프한 비전, 범위, 비용 등을 측정한다.
- Elaboration은 core architecture를 확립하여 high risk를 빨리 해소하려고 한다. 그리고 위의 것들을 좀 더 구체화한다.
- Construction은 실질적인 제작과 통합이 이루어지며 가장 오랜 시간(반복)이 걸린다.
- Transition은 베타 테스트, 통합, 배포 등을 한다.



* Artifact : UP 과정에서 만들어낸 모든 작업 산출물 (code, DB schema, text doc, diagram, model 등등)
Discipline : 특정 area에 관련된 work activity와 그것에 대한 작업 산출물(work product). 예를 들어 use-case를 작성하는 work activity의 산출물은 use case가 된다. Business modeling, requirement, design, implementation 등등이 UP discipline의 종류가 된다. 각 discipline은 작업 시간에 따라 투입되는 자원의 양이 달라진다.
Development Case : 어떤 프로젝트의 시기별 practice(관행/방법)와 artifact의 choice를 나타낸 표. 프로젝트의 성격마다 사용해야할 방법론이 다를 수 있기에 적절하게 선택해야 함.

iterative development : 일련의 fixed length iteration으로 구성됨. 각 iteration은 각각의 requirement analysis, design, implementation, integration, testing 등을 가지고 있다. 각 iteration에 대해 피드백을 받아 다음 루프에는 더 개선된 결과를 낼 수 있다. (build - feedback - adapt cycle) 이를 통해 조기 위험관리/프로토타입, 피드백 수용/발전, 복잡도 관리 등 다양한 이점을 가질 수 있고 이는 곧 프로젝트 실패율의 감소로 이어진다.
일반적으로 약 2~6주 사이의 fixed length(timeboxing)를 가지는 반복을 하는 것이 가장 좋다. 만약 해당 기간 내에 완료하지 못하면 그 부분은 제외하고 구현한 뒤, 나머지는 다음 반복에 구현하는 식으로 진행한다. (de-scope)

risk driven : 초기부터 가장 위험한 리스크를 밝혀내고 관리하며 클라이언트의 핵심적인 요구사항을 먼저 개발하려고 함. (중요한 것 10% 정도) 이를 위해 아키텍쳐를 초기에 확립하여 리스크 관리하는 방식을 택한다. 아키텍쳐 확립(거시) - 디자인 패턴 적용(중규모) - 세부적인 객체들 상세설계(소규모) 순으로 개발이 이루어진다. 

Agile modeling : 모델링을 전혀 안한다는 것이 아니라 모델의 명세화보다는 개발자들의 이해와 소통을 중점으로 프로젝트를 진행하는 것에 초점을 맞춘다. 그리고 UML모델은 필요한 부분에만 적용하며 복잡한 툴을 사용하지 않고 간단하게 하는 것을 지향한다. 또한 모델링은 완벽하지 않고 틀린 부분이 있다는 것을 인지해야 한다. 일반적으로 모델링은 여러 명이서 같이 하고 병렬적으로 제작할 수 있다. 주의할 점은 모든 디자인이 반드시 개발 전에 완료되어야 하는 것은 아니라는 것이다.