주제

설명 페이지 맨 위

상태 기계는 모델 요소의 동적 작동, 구체적으로 말하면 시스템 작동의 이벤트 기반 특성을 모델링하는 데 사용됩니다(개념: 이벤트 및 신호 참조). 상태 기계는 특히 상태 종속 작동 또는 모델 요소가 존재하는 상태에 따라 변화하는 작동을 정의하는 데 사용됩니다. 요소의 상태와 함께 변화되지 않는 작동의 모델 요소에는 해당 작동을 설명하는 상태 기계가 필요하지 않습니다(일반적으로 이러한 요소는 데이터 관리에 1차적 책임이 있는 수동적 클래스임). 특히 상태 기계는 호출 이벤트와 신호 이벤트를 사용하여 클래스의 상태 기계에서 전이로서 조작을 구현하는 활성 클래스의 작동을 모델링하는 데 사용되어야 합니다.

상태 기계는 전이에서 링크된 상태로 구성됩니다. 상태는 일부 활동을 수행하거나 이벤트를 대기하는 객체의 조건입니다. 전이는 일부 이벤트로 트리거되고 특정 조치 또는 평가를 수행하며 특정 종료 상태로 끝나는 두 개 상태 사이의 관계입니다. 상태 기계의 요소는 그림 1에서 나타나 있습니다.

상태 기계 표기법을 보여주는 다이어그램

그림 1. 상태 기계 표기법.

비어 있음, 명령 대기 중텍스트 대기 중 상태를 보유하는 유한 상태 기계로서 단순 편집기를 볼 수 있습니다. 파일 로드, 텍스트 삽입, 문자 삽입저장 후 종료 이벤트는 상태 기계에서 전이를 발생시킵니다. 편집기에 대한 상태 기계는 아래 그림 2에 나타나 있습니다.

캡션 설명이 있는 다이어그램.

그림 2. 단순 편집기에 대한 상태 기계.

상태 페이지 맨 위

상태는 일부 활동을 수행하거나 이벤트를 대기하는 객체의 조건입니다. 객체는 한정된 시간 동안 특정 상태로 남아 있을 수 있습니다. 상태에는 다음과 같은 여러 개의 등록 정보가 있습니다.

이름 해당 상태를 다른 상태와 구별하는 텍스트 문자열이며 상태는 이름이 없다는 의미에서 익명일 수도 있습니다.
시작/종료 조치 상태 시작 및 종료시 실행되는 조치
내부 전이 상태를 변경하지 않고 처리되는 전이
하위 상태 분리(순차적 활성) 또는 동시(동시 활성) 하위 상태를 수반하는 상태의 중첩 구조.
연기 이벤트 상태에서 처리되지 않지만 또다른 상태의 객체에서 처리하도록 연기되어 대기열에 있는 이벤트 목록.

그림 1에서 나타낸 바와 같이 객체의 상태 기계에 정의할 수 있는 두 개의 특수 상태가 있습니다. 초기 상태는 상태 기계 또는 하위 상태의 기본 시작 위치를 나타냅니다. 초기 상태는 검정색으로 채워진 원으로 표시됩니다. 최종 상태는 상태 기계의 실행 완료 또는 포함 상태의 완료를 나타냅니다. 최종 상태는 채워지지 않은 원 안에 검정색이 채워진 원으로 표시됩니다. 초기 및 최종 상태는 실제로 pseudo 상태입니다. 또한 이름을 제외하고는 정상 상태의 일반적인 부분도 갖출 수 없습니다. 초기 상태에서 최종 상태로의 전이에는 감시 조건과 조치를 포함한 기능의 완전한 보완이 있을 수 있지만 트리거 이벤트는 있을 수 없습니다.

전이 페이지 맨 위

전이는 첫 번째 상태의 객체가 특정 조치를 수행하여 지정된 이벤트가 발생하고 지정된 조건이 충족되면 두 번째 상태로 들어감을 나타내는 두 상태 사이의 관계입니다. 이러한 상태 변경에서 전이는 '점화'라고도 합니다. 전이가 점화할 때까지 객체는 '소스' 상태로 있다고 하며 점화한 후에는 '대상' 상태로 있다고 합니다. 전이에는 다음과 같은 여러 개의 등록 정보가 있습니다.

소스 상태 전이로부터 영향을 받은 상태. 객체가 소스 상태로 있으면 객체가 전이 트리거 이벤트를 받고 감시 조건(있는 경우)이 충족되는 경우 전송 전이가 점화할 수 있습니다.
이벤트 트리거 소스 상태의 객체가 받을 때 전이가 적절히 점화되게(감시 조건이 충족되는 경우) 하는 이벤트.
감시 조건 이벤트 트리거 수신으로 전이가 트리거될 때 평가되는 부울 표현식. 표현식이 true로 평가되면 전이가 적절히 점화될 수 있지만 false로 평가되면 전이가 점화되지 않습니다. 같은 이벤트로 트리거될 수 있는 다른 전이가 없으면 이 이벤트는 유실됩니다.
조치 상태 기계를 소유하는 객체에는 직접적으로 작용하고 이 객체에서 보이는 다른 객체에는 간접적으로 작용할 수 있는 실행 가능한 원자적 계산.
대상 상태 전이 완료 이후의 활성 상태.

전이는 여러 소스를 가질 수 있으며, 이 경우 여러 동시 상태로부터의 결합을 나타냅니다. 마찬가지로 여러 대상도 가질 수 있으며, 이 경우 여러 동시 상태로의 분기를 나타냅니다.

이벤트 트리거

상태 기계의 컨텍스트에서 이벤트는 상태 전이를 트리거할 수 있도록 자극시켜 줍니다. 이벤트는 신호 이벤트, 호출 이벤트, 시간 경과 또는 상태 변경을 포함할 수 있습니다. 신호 또는 호출에는 감시 조건 및 조치 표현식을 포함하여 전이에 사용 가능한 값인 매개변수가 있을 수 있습니다. 또한 이벤트 트리거가 없는 전이도 존재할 수 있습니다. 소스 상태에서 활동을 완료했을 때 이러한 전이(완료 전이라고도 함)는 암시적으로 트리거됩니다.

감시 조건

전이의 트리거 이벤트가 발생한 후에는 감시 조건이 평가됩니다. 감시 조건이 겹치지만 않으면 동일한 이벤트 트리거와 함께 동일한 소스 상태로부터 여러 전이가 나타날 수 있습니다. 전이의 감시 조건은 이벤트 발생시 한 번만 평가됩니다. 부울 표현식에서 객체 상태를 참조할 수 있습니다.

조치

조치는 이벤트로 인터럽트할 수 없으므로 실행하여 완료한다는 의미에서 실행 가능한 원자적 계산입니다. 이는 다른 이벤트로 인터럽트할 수 있는 활동과 대조적입니다. 조치에는 상태 기계 소유자와 기타 가시적 객체에 대한 조작 호출, 또다른 객체의 작성이나 제거 또는 또다른 객체에 신호 전송이 포함될 수 있습니다. 신호 전송의 경우 신호 이름 앞에 접두부로 'send' 키워드를 붙입니다.

시작 및 종료 조치

시작 및 종료 조치를 사용하면 상태가 시작되거나 종료될 때마다 각각 같은 조치를 디스패치할 수 있습니다. 시작 및 종료 조치를 통해 매번 명시적으로 들어오거나 나가는 전이에 명시적으로 조치를 수행하지 않아도 해당 작업을 명확하게 처리할 수 있습니다. 시작 및 종료 조치는 인수 또는 감시 조건을 가질 수 없습니다. 상태 기계의 최상위 레벨에 있는 모델 요소의 시작 조치에는 요소가 작성될 때 이 상태 기계가 받는 인수를 나타내는 매개변수가 있을 수 있습니다.

내부 전이

내부 전이를 사용하면 상태를 종료하지 않고, 이에 따라 시작 또는 종료 조치를 트리거하고도 이벤트를 상태 내부에서 처리할 수 있습니다. 내부 전이에는 매개변수 및 감시 조건이 있는 이벤트가 포함될 수 있으며, 반드시 인터럽트 핸들러를 표시해야 합니다.

연기 이벤트

연기 이벤트는 이벤트를 연기하지 않은 상태가 활성화될 때까지 처리가 연기되는 이벤트입니다. 이 상태가 활성되면 이벤트 발생이 트리거되어 마치 방금 일어났던 것처럼 전이를 발생시킬 수 있습니다. 연기 이벤트를 구현하려면 이벤트의 내부 대기열이 있어야 합니다. 이벤트가 발생하지만 연기로 표시되면 이 이벤트는 대기열에 있습니다. 객체가 이러한 이벤트를 연기하지 않는 상태로 들어가면 바로 해당 이벤트는 이 대기열에서 벗어납니다.

하위 상태 페이지 맨 위

단순 상태는 하위 구조가 없는 상태입니다. 하위 상태(중첩된 상태)가 있는 상태를 합성 상태라고 합니다. 하위 상태는 어떠한 레벨로도 중첩될 수 있습니다. 중첩된 상태 기계에는 하나의 초기 상태와 하나의 최종 상태만 존재할 수 있습니다. 하위 상태는 특정 컨텍스트 안에서만 가능할 수 있는 일부 상태(포함 상태)를 표시하여 복잡한 플랫 상태 기계를 단순화하는 데 사용됩니다.

하위 상태를 표시하는 다이어그램.

그림 3. 하위 상태.

전이는 포함 합성 상태 외부의 소스에서 합성 상태 또는 하위 상태를 대상으로 지정할 수 있습니다. 대상이 합성 상태이면 중첩된 상태 기계는 합성 상태가 시작된 후와 시작 조치(있는 경우)를 디스패치한 후 제어의 전달 대상이 되는 초기 상태를 포함해야 합니다. 대상이 중첩된 상태이면 제어는 합성 상태의 시작 조치(있는 경우)를 디스패치한 다음 중첩된 상태의 시작 조치(있는 경우)를 디스패치한 후 중첩된 상태로 전달됩니다.

합성 상태를 발생시키는 전이는 해당 소스로서 합성 상태 또는 하위 상태를 가질 수 있습니다. 어느 경우이든 제어는 먼저 중첩된 상태를 나온(종료 조치가 있으면 디스패치됨) 다음 합성 상태를 나오게 됩니다(종료 조치가 있으면 디스패치됨). 합성 상태인 소스의 전이는 반드시 중첩된 상태 기계의 활동을 인터럽트합니다.

히스토리 상태 페이지 맨 위

특별히 지정되지 않으면 전이가 합성 상태로 들어갈 때 중첩된 상태 기계의 조치가 초기 상태에서 처음부터 다시 시작합니다(전이에서 하위 상태를 직접 대상으로 지정하지 않는 경우). 히스토리 상태를 사용하면 상태 기계가 합성 상태를 나오기에 앞서 활성화된 마지막 하위 상태로 다시 들어갈 수 있습니다. 그림 4는 히스토리 상태 사용의 한 예입니다.

히스토리 상태를 표시하는 다이어그램

그림 4. 히스토리 상태.

공통 모델링 기술 페이지 맨 위

상태 기계는 지속 기간에 걸쳐 객체의 작동을 모델링하는 데 가장 공통적으로 사용됩니다. 객체에 상태 종속 작동이 있을 경우에 특히 필요합니다. 인터페이스를 실현하는 객체에서 충족시켜야 하는 상태를 선언하기 위해 상태 기계를 가질 수 있는 객체에는 클래스, 서브시스템, 유스 케이스 및 인터페이스가 포함됩니다.

모든 객체에 상태 기계가 필요한 것은 아닙니다. 단지 데이터를 저장하거나 검색하는 것처럼 객체의 작동이 간단한 경우 해당 객체의 작동은 상태 불변이며 상태 기계에는 거의 관련되지 않습니다.

객체의 지속 기간을 모델링하는 데에는 세 가지, 즉, 객체가 응답할 수 있는 이벤트, 이 이벤트에 대한 응답, 그리고 현재 작동에 대한 과거의 영향이 필요합니다. 또한 객체의 지속 기간을 모델링하는 데에는 객체의 작성 시점에서 시작하여 삭제될 때까지 객체가 이벤트에 의미있게 응답할 수 있는 순서의 결정도 필요합니다.

객체의 지속 기간을 모델링하려면 다음을 수행하십시오.

  • 상태 기계, 클래스인지 여부, 유스 케이스 또는 전체 시스템에 대한 컨텍스트를 설정하십시오.
    • 컨텍스트가 클래스 또는 유스 케이스인 경우 상위 클래스 또는 연관이나 종속성으로 접근 가능한 클래스를 포함하여 인접하는 클래스를 수집하십시오. 이러한 인접 클래스는 조치를 위한 후보 대상이며 감시 조건에 포함시킬 후보 대상입니다.
    • 컨텍스트가 전체 시스템인 경우 시스템의 한 작동으로 집중시켜 범위를 좁힌 다음 해당 특성과 관련되는 객체의 지속 기간을 고려하십시오. 전체 시스템의 지속 기간은 너무 커 의미있는 초점이 될 수 없습니다.
  • 객체의 초기 및 최종 상태를 설정합니다. 초기 및 최종 상태의 사전 조건 또는 사후 조건이 있을 경우 이러한 조건도 정의하십시오.
  • 객체가 응답하는 이벤트를 판별합니다. 이러한 이벤트는 객체의 인터페이스에서 찾을 수 있습니다.
  • 초기 상태에서 시작하여 최종 상태에 이르기까지 객체가 존재할 수 있는 최상위 레벨 상태를 배치하십시오. 이러한 상태를 해당 이벤트로 트리거되는 전이와 연결하십시오. 이 전이를 추가하면서 계속 진행하십시오.
  • 시작 또는 종료 조치를 식별하십시오.
  • 하위 상태를 사용하여 상태 기계를 확장하거나 단순화하십시오.
  • 상태 기계에서 전이를 트리거하는 모든 이벤트가 객체에서 실현하는 인터페이스로 예상되는 이벤트와 일치하는지 확인하십시오. 이와 유사하게 상태 기계에서 객체의 인터페이스로 예상되는 모든 이벤트를 처리하는지 확인하십시오.
  • 포함하는 객체의 관계, 메소드 및 조작으로 상태 기계의 모든 조치가 지원되는지 확인하십시오.
  • 이벤트 및 해당 응답의 예상된 순서와 비교하면서 상태 기계를 철저하게 추적하십시오. 접근 불가능한 상태와 상태 기계에서 시작하는 상태를 검색하십시오.
  • 상태 기계를 재배열하거나 재구조화하는 경우 의미론이 변경되지 않도록 확인하십시오.

힌트 및 팁 페이지 맨 위

  • 선택항목이 있으면 자세한 전이 코드를 작성하는 대신 상태 기계의 시각적 의미론을 사용하십시오. 예를 들어, 여러 신호에서 하나의 전이를 트리거하지 않고, 세부 코드를 사용하여 신호에 따라 다르게 제어 플로우를 관리하십시오. 별도의 신호로 트리거되는 별도의 전이를 사용하십시오. 전이 코드에서 추가 작동을 숨기는 조건부 논리는 피하십시오.
  • 대기 중인 내용 또는 상태에서 발생하는 내용에 따라 이름 상태를 지정하십시오. 상태는 '시점'이 아니라 상태 기계가 발생하는 무엇인가를 대기하는 동안의 기간입니다. 예를 들어, 'waitingForEnd' 및 'timingSomeActivity'는 각각 'end' 및 'timeout'보다 더 나은 이름입니다. 마치 조치인 것처럼 이름 상태를 지정하지 마십시오.
  • 상태 기계 안에 있는 모든 상태 및 전이 이름을 고유하게 지정하십시오. 그러면 소스 레벨 디버깅을 더 쉽게 수행하게 됩니다.
  • 상태 변수(작동 제어에 사용되는 속성)를 사용하십시오. 새 상태 작성을 대신하여 이 변수를 사용하지는 마십시오. 상태 종속 작동이 거의 또는 전혀 없이 소수의 상태만 있는 경우와 상태 기계를 포함하는 객체와 동시에 발생하거나 종속되지 않을 수 있는 작동이 거의 또는 전혀 없는 경우에 상태 변수가 사용될 수 있습니다. 잠재적으로 동시에 발생할 수 있는 복잡한 상태 종속 작동인 경우 또는 처리되어야 하는 이벤트가 상태 기계를 포함하는 객체 외부에서 시작될 수 있는 경우에는 둘 이상의 활성 객체를 함께(복합으로 정의될 수 있음) 사용하도록 고려하십시오.
  • 하나의 다이어그램에 5 ± 2보다 많은 상태가 있을 경우 하위 상태 사용을 고려하십시오. 일반적으로 절대 정규 패턴에서 열 개 상태이면 양호할 수 있지만 그 중에서 40개 전이를 포함하는 두 개 상태는 분명히 재고할 필요가 있습니다. 상태 기계를 쉽게 이해할 수 있도록 하십시오.
  • 이벤트를 트리거하는 내용 및/또는 전이에서 발생하는 내용에 대한 전이 이름을 지정하십시오. 이해가 용이한 이름을 선택하십시오.
  • 선택점이 보일 경우 작용될 일련의 고유한 신호(예: msg->데이터 > x에 대한 선택사항 대신)로서 해당 객체에 나타나게 되는 것처럼 해당 선택사항의 책임을 또다른 컴포넌트에 위임할 수 있는지 질문하고, 송신자 또는 일부 다른 중간 액터가 신호 이름에 명시적 결정이 있는 신호(예: 신호 이름 지정 값을 사용하지 않고 메시지 데이터를 확인하지 않고 isFull 및 isEmpty 이름의 신호 사용)를 전송하도록 결정해야 합니다.
  • 선택점에서 응답되는 질문의 이름을 서술적으로 지정하십시오(예: 'isThereStillLife' 또는 'isItTimeToComplain').
  • 지정된 객체 안에서 선택점 이름을 고유하게 유지하도록 하십시오(전이 이름을 고유하게 유지하는 것과 동일한 이유임).
  • 전이에 너무 긴 코드 단편이 있습니까? 대신 함수가 사용되어야 합니까? 그리고 공통 코드 단편이 함수로서 캡처됩니까? 전이는 상위 레벨 의사 코드와 같은 방식으로 판독해야 하며, C++ 함수와 같거나 엄격한 길이 규칙을 준수해야 합니다. 예를 들어, 26행 이상의 코드를 가진 전이는 긴 것으로 간주합니다.
  • 함수 이름은 수행 작업에 따라 지정되어야 합니다.
  • 시작 및 종료 조치에 특별히 주의하십시오. 특히 시작 및 종료 조치를 변경하거나 이 변경을 잊어버리기가 쉽습니다.
  • 종료 조치는 안전 기능을 제공하는 데 사용할 수 있습니다. 예를 들어, 'heaterOn' 상태에서 종료 조치를 수행하면 난방기가 꺼지며(heater off), 여기에서 이 조치는 확인을 강제적으로 실행하는 데 사용됩니다.
  • 일반적으로 상태 기계가 추상적이지 않으면 하위 상태는 둘 이상의 상태를 포함해야 하며, 포함 요소의 서브클래스로 개선됩니다.
  • 선택점이 조치 또는 전이의 조건부 논리 대신에 사용되어야 합니다. 선택점은 쉽게 보이는 반면, 코드의 조건부 논리는 보기에서 숨겨져 있어 간과하기가 쉽습니다.
  • 감시 조건은 사용하지 마십시오.
    • 이벤트에서 여러 개의 전이를 트리거하는 경우 먼저 평가되는 감시 조건은 제어하지 않습니다. 따라서 결과는 예측할 수 없습니다.
    • 둘 이상의 감시 조건이 'true'일 수 있지만 하나의 전이만 추적될 수 있습니다. 선택된 경로는 예측할 수 없습니다.
    • 감시 조건은 보이지 않습니다. 따라서 해당 존재를 '확인하기'가 더 어렵습니다.
  • 플로우 도표와 비슷한 상태 기계는 사용하지 마십시오.
    • 여기에서는 다음과 같이 실제로 상태 기계에 없는 추상성을 모델링하려는 시도를 나타낼 수 있습니다.
      • 활성 클래스를 사용하여 수동(또는 데이터) 클래스에 가장 적합한 작동을 모델링하거나
      • 매우 긴밀하게 결합되는 데이터 클래스 및 활성 클래스를 사용하여 데이터 클래스를 모델링합니다(데이터 클래스는 유형 정보 전달에 사용되었지만 활성 클래스는 이 데이터 클래스와 연관되어야 하는 대부분의 데이터를 가지고 있음).
    • 이러한 상태 기계의 오용은 다음 증상으로 인식될 수 있습니다.
      • 주로 코드를 재사용하여 '자신'에게 보내진 메시지
      • 많은 선택점을 가지고 있는 소수의 상태
      • 일부의 경우에서 주기가 없는 상태 기계. 이러한 상태 기계는 프로세스 제어 어플리케이션에서 또는 이벤트 순서를 제어하려는 경우에 유효합니다. 분석 중에 이 상태 기계가 나타나면 보통 플로우 도표에 상태 기계의 저하가 나타납니다.
    • 문제를 식별한 경우 다음을 수행하십시오.
      • 더 명확한 책임을 가지는 더 작은 단위로 활성 클래스 분할을 고려하십시오.
      • 더 많은 작동을 문제가 있는 활성 클래스와 연관되는 데이터 클래스로 이동시키십시오.
      • 더 많은 작동을 활성 클래스 함수로 이동시킵니다.
      • 데이터에 의존하는 대신 의미 있는 신호를 만듭니다.

추상적 상태 기계를 통한 설계페이지 맨 위

추상적 상태 기계는 세부사항을 더 많이 추가해야 실제 목적으로 사용될 수 있는 상태 기계가 됩니다. 추상적 상태 기계는 후속 모델 요소에서 개선되는 일반 재사용 가능 작동을 정의하는 데 사용할 수 있습니다.

캡션 설명이 있는 다이어그램.

그림 5. 추상적 상태 기계.

그림 5의 추상적 상태 기계를 고려하십시오. 표시된 간단한 상태 기계는 이벤트 기반 시스템에서 수많은 다양한 유형 요소의 가장 추상적인 레벨에 있는 작동("제어" 자동화)을 대표적으로 나타낸 것입니다. 모든 요소에서 이러한 상위 레벨 양식을 공유하지만 다양한 요소 유형에는 실행 중 상태에서 해당 목적에 따라 매우 다양한 세부 작동이 있을 수 있습니다. 따라서 이 상태 기계는 특수화된 다양한 활성 클래스의 루트 클래스로 역할을 수행하는 일부 추상적 클래스에서 정의될 가능성이 높습니다.

여기에서는 상속을 사용하여 이 추상적 상태 기계의 다른 개선사항 두 개를 정의하겠습니다. 그림 6에서 이러한 두 개의 개선사항인 R1 및 R2를 보여줍니다. 명확하게 설명하기 위해 회색 펜으로 상위 클래스에서 상속되는 요소를 그렸습니다.

캡션 설명이 있는 다이어그램.

그림 6. 상태 기계(그림 5)에서 두 개의 개선사항.

이 두 개의 개선사항은 실행 중 상태를 분해하는 방법에서와 원래의 "시작" 전이를 확장하는 방법에서도 분명히 다릅니다. 개선사항이 알려지고 이로 인해 추상적 클래스에서 하나의 엔드-투-엔드 전이로 수행될 수 없으면 당연히 이러한 선택만 수행될 수 있습니다.

체인 상태 페이지 맨 위

들어오는 전이와 전송 전이 모두를 "지속할 수 있는" 기능은 위에서 설명하는 개선 유형의 기본입니다. 연속 전이와 결합된 출발점 및 최종 상태가 이러한 의미론을 제공하기에 충분한 것으로 생각할 수 있습니다. 불행히도 확장되어야 하는 여러 개의 다른 전이가 있을 경우 이 방법으로는 충분하지 않습니다.

추상적 작동 패턴에 필요한 것은 하나의 실행 후 완료 단계에 속하는 범위에서 모두 실행되는 둘 이상의 전이 세그먼트를 체인화하는 방법입니다. 이는 계층 구조 상태로 들어가는 전이를 상태 경계에서 효과적으로 종료하는 들어오는 파트와 상태 안에서 지속되는 확장으로 분할한다는 것을 의미합니다. 유사하게 계층 구조적 중첩된 상태에서 발산하는 전송 전이는 포함 상태 경계에서 종료하는 파트와 상태 경계에서 대상 상태로 지속되는 파트로 세그먼트화됩니다. 이 효과는 체인 상태 개념을 소개하는 UML로 얻어질 수 있습니다. 이러한 세그먼트화는 UML 상태 개념의 스테레오타입(<<chainState>>)으로 모델링됩니다. 이 상태는 더 많은 자동(트리거 없음) 전이를 하나의 입력 전이에 "체인"시키는 것을 유일한 목적으로 합니다. 체인 상태에는 내부 구조, 즉, 시작 조치, 내부 활동 및 종료 조치가 없습니다. 또한 이벤트로 트리거되는 전이도 없습니다. 임의 수의 입력 전이가 있을 수 있습니다. 트리거 이벤트가 없는 전송 전이가 있을 수 있으며 입력 전이가 상태를 활성화할 때 이 전송 전이가 자동으로 점화됩니다. 이 상태의 목적은 입력 전이를 별도의 출력 전이에 체인시키는 것입니다. 입력 전이와 체인된 출력 전이 사이에서 하나는 포함 상태 안에 있는 또다른 상태와 연결되고 나머지는 포함 상태 외부에 있는 또다른 상태와 연결됩니다. 체인 상태를 소개하는 목적은 포함 상태의 내부 스펙을 외부 환경으로부터 분리하는 것인데, 이는 캡슐화의 문제입니다.

실제로 체인 상태는 전이를 특정 연속 전이에 체인시키도록 역할을 수행하는 "통과" 상태를 나타냅니다. 연속 전이가 정의되어 있지 않으면 전이는 체인 상태에서 종료되고 결국에는 포함 상태에 있는 일부 전이가 점화되어 어떤 것을 이동시켜야 합니다.

그림 7의 상태 기계 세그먼트의 예는 체인 상태 및 해당 표기법을 나타냅니다. 체인 상태는 상태 기계 다이어그램에서 해당 계층 구조 상태 안에 있는 흰색 작은 원으로 표시됩니다(이 표기법은 초기 및 최종 상태와 유사함). 원은 스테레오타입 체인 상태 유형의 스테레오타입 아이콘이며 일반적으로 경계 근처에 표시됩니다. (실제로 표기 상 변형이 포함 상태의 경계에서 이와같이 표시됩니다.)

텍스트 설명이 첨부된 다이어그램.

그림 7. 체인 상태 및 체인된 전이.

이 예에서 체인된 전이는 세 개의 체인된 전이 세그먼트로 구성됩니다(e1/a11-/a12-/a13). e1 신호가 수신되면 e1/a11 레이블의 전이를 선택하고, a11 조치를 실행한 다음, c1 체인 상태에 도달합니다. 그런 후에 c1과 c2 사이의 연속 전이를 선택하고, 최종적으로 c2도 체인 상태이므로 c2에서 S21로의 전이를 선택합니다. 이러한 경로를 따르는 상태 모두에 시작 및 종료 조치가 있으면 조치 실행의 실제 순서는 다음과 같이 진행됩니다.

  • S11 종료 조치
  • a11 조치
  • S1 종료 조치
  • a12 조치
  • S2 시작 조치
  • a13 조치
  • S21 시작 조치

이러한 모든 조치가 하나의 실행 후 완료 단계 범위에서 실행됩니다.

이 경우 다음과 같은 e2/a2 직접 전이의 조치 실행 의미론과 비교되어야 합니다.

  • S11 종료 조치
  • S1 종료 조치
  • a2 조치
  • S2 상태에 대한 시작 조치
  • S21 상태에 대한 시작 조치


Rational Unified Process   2003.06.15