UML 작동 다이어그램(Behavioral Diagram)

UML 2(시퀀스 다이어그램)

1. 서론
   1. OMG가 UML을 개선했던 두 가지 이유.
      1. OMG(Object Management Architecture) : 객체지향 기법의 적용과 증진, 분산 컴퓨팅 환경에서의 하드웨어 플랫폼과 운영체제에 영향을 받지 않고, 애플리케이션 통합을 위한 프레임워크 제공을 목표
      2. UML 모델이 Model Driven Architecture (MDA)를 다루기 바랬기 때문이다. 즉, UML이 모델 중심의 표기법으로서 쓰여야 한다는 것을 의미한다.
      3. UML 1.x 표기법 세트는 큰 어플리케이션에 적용하기 어려웠으며, 다이어그램을 보다 읽기 쉽도록 만들기 위해서는 표기법 엘리먼트들이 개선될 필요도 있었다.
2. 다이어그램의 목적
   1. 시퀀스 다이어그램은 객체들 간 인터랙션을 발생 선서대로 보여줄 때 쓰인다.
   2. 개발자 뿐만 아니라 영업 부서에서도 비즈니스가 어떻게 돌아가고 있는지를 설명할 때, 시퀀스 다이어그램을 이용할 수 있다.
   3. 시스템 구현에 필요한 요구 사항들을 기록하는 문서로서 사용된다.
   4. 시퀀스 다이어그램은 주로 형식적인 정련 단계에서 사용된다.
   5. 사용 케이스들은 한 개 이상의 시퀀스다이어그램으로 세분화된다.
   6. 새로운 시스템을 설계할 때 사용되기도 하지만, 시원스 다이어그램은 기존 "레거시(legacy)" 시스템의 객체들이 현재는 어떻게 인터랙팅 하는지를 문서화 하는데 사용될 수 있다.
   7. 시스템을 이동할 때 문서화는 매우 유용하다.
3. 표기법
   1. 프레임
      1. 프레임 엘리먼트는 다이어그램의 레이블을 위한 지정된 장소를 제공하고, 다이어그램의 그래픽 영역을 제공한다.
      2. 프레임 엘리먼트는 UML 다이어그램에서는 선택 사항이다.
      3. 
      4. (그림1)에서 보듯이 다이어그램의 레이블은 프레임의 "네임박스(namebox)"라고 부르게 될 왼쪽 코너의 상단에 놓인다.
      5. 
      6. (그림2)에서 다이어그램 레이블이 Sequence Diagram을 의미하는 "sd"로 시작한다는 것에 주목할 필요가 있다.
      7. 다이어그램을 위한 프레임 엘리먼트를 사용할 때 다이어그램의 레이블은 다음 포맷을 따라야 한다.
         1. Diagram Type Diagram Name
4. 기초
   1. 서론
      1. 시퀀스 다이어그램의 주요 목적은 어떤 결과를 만들어내는 이벤트 시퀀스를 정의하는 것이다.
      2. 메시지 보다는 메시지가 발생하는 순서에 초점이 더 맞춰진다.
      3. 대부분 시퀀스 다이어그램은 system 객체들 간 어떤 메시지를 보내지는지, 그리고 어떤 순서로 발생하는지를 나타낸다.
      4. 다이어그램은 메시지 발생 순서 정보를 수직적, 수평적 측면으로 전달한다.
         1. 수직적 측면에서는 탑 다운(top down)
         2. 수평적 측면에서는 왼쪽에서 오른쪽으로 메시지/호출이 발생한 시간 순서를 나타낸다.
   2. Lifelines
      1. 시퀀스 다이어그램을 그릴 때 Lifeline 표기법 엘리먼트는 다이어그램 상단에 놓인다.
      2. Lifeline은 모델링 되는 시퀀스에 개입된 역할 또는 개게 인스턴스들을 나타낸다.
      3. 
      4. Lifeline의 UML의 네이밍 표준은 다음 포맷을 따른다.
         1. Instance Name : Class Name
      5. (그림3)에서는 Lifeline은 Student 클래스의 인스턴스를 나타낸다.
      6. (그림3)처럼 Lifeline 이름 밑에 밑줄이 그어지는 경우는 Lifeline이 한 시퀀스 다이어그램에서 클래스의 특정 인스턴스를 나타낸다는 것을 의미한다.
      7. (그림3)의 Lifeline 예제는 네이드 객체이다. 하지만 모든 Lifeline이 네임드 객체를 나타내는 것은 아니다. 익명 또는 이름없는 인스턴스를 나타는데도 사용될 수 있다.
   3. 메시지
      1. 시퀀스 다이어그램에서 첫 번째 메시지는 언제나 상단에서 시작하고 다이어그램의 왼쪽에 위치한다.
      2. 
      3. 메시지의 호출과 반환을 (그림4)를 통해 볼 수 있다.
      4. 
      5. (그림)5에서는 자기자신을 호출하는 객체를 방법을 확인할 수 있다.
      6. 
      7. 비동식 메시지도 가능하다. 메시지 라인은 막대화살로 대신한다.
   4. 가드(guard)
      1. 객체 인터랙션을 모델링 할 때 객체로 보내지는 메시지 조건이 부합해야 할 때도 있다.
      2. 가드(guard)는 흐름을 제어하는 UML 다이어그램에서 쓰인다.
      3. 
      4. (그림7)에서 가드는 텍스트 "[pastDueBalance = 0]"이다. 이 메시지가 가드이기 때문에, addStudent메시지는 시스템 계정이 [pastDueBalance = 0]을 리턴할 경우에만 보내진다.
   5. Combined fragments (대안, 옵션, 루프)
      1. 대부분의 시퀀스 다이어그램에서 UML 1.x "in-line" 가드는 모델링 되는 시퀀스에 필요한 로직을 핸들하기엔 조금 부족했다.
      2. UML 2는 "in=line" 가드를 없애고, Combined Fragment라고 하는 표기법 엘리먼트를 추가하여 이러한 문제를 다루고 있다.
      3. Combined Fragment는 시퀀스 다이어그램에서 조건의 흐름을 보여주기 위해 메시지들을 하나로 그룹핑하는데 사용된다.
      4. UML 2 스팩은 Combined Fragment에 11개의 인터랙션 유형을 정의하고 있다.
      5. 대안
         1. 대안은 두 개 이상의 메시지 시퀀스들간 상호 배타적인 선택을 나타낼 때 사용된다.
            1. 대안은 전통적인 "if then else" 직 모델링이 가능하다.
            2. 예시. 만일 3개의 아이템을 구매한다면 구매금액의 20%를 할인 받고 그 외에는 10%의 할인을 받는다.
         2. 
         3. (그림8)은 대안에 대한 예시로 프레임 표기법이 사용되었으며, 구분은 대시(dash)라인으로 된다. 각 피연산 함수에는 가드가 주어지고, 이 가드는 lifeline 상단에 피연산 함수의 왼쪽 상단 부분을 향해 배치된다.
      6. 옵션
         1. 옵션 Combined Fragment는 특정 상황에서 발생하는 시퀀스를 모델링 할 때 사용된다. 다른 경우는 발생하지 않는다.
         2. 간단히 "if then" 문장을 모델링 하는데 쓰인다.
         3. 
      7. 루프(loop)
         1. 가끔 반복적인 시퀀스를 모델링 해야 할 때도 있다.
         2. 외형상 옵션과 흡사하다.
         3. 프레임의 네임박스에 "loop"라고 쓴다.
         4. 루프의 가드는 lifeline의 상단에, 왼쪽 상단 코너 쪽을 향해서 놓인다. 그런 다음 루프의 메시지 시퀀스는 프레임의 나머지 콘텐트 영역에 배치된다.
         5. 루프의 가드는 두가지 특별한 조건을 가질 수 있다.
            1. "minint = [the number]" ("minint = 1")라고 하는 최소 반복 값
            2. "maxint = [the number]" ("maxint = 5")라고 하는 최대 반복 값
         6. 
         7. (그림10)의 예제는 bool 값에 대한 예제이다.
5. 결론
   1. 시퀀스 다이어그램은 시스템 요구사항을 문서화하고 시스템 디자인을 한꺼번에 볼 수 있는 좋은 다이어그램이다.
   2. 우용한 이유는 인터랙션이 발생하는 시간 순서로, 시스템의 객체들간 인터랙션 로직을 보여주기 때문이다.