상태 머신은 모델 요소의 동적 동작을 모델링하는 데 사용됩니다. 보다 구체적으로는 시스템 동작의 이벤트 기반 측면을 모델링합니다(개념: 이벤트 및
신호 참조). 상태 머신은 구체적으로 상태 종속적 동작, 즉 모델 요소의 상태에 따라 달라지는 동작을 정의하는 데 사용됩니다. 요소의 상태에 따라 동작이 변하지 않는 모델 요소의 경우에는 상태 머신이 동작을
설명할 필요가 없습니다(일반적으로 이러한 요소는 데이터 관리를 기본적으로 책임지는 수동 클래스임). 특히 호출 이벤트 및 신호 이벤트를 사용하여 오퍼레이션을 구현하는 활성 클래스의 동작을 모델링하려면 상태 머신을
사용해야 합니다(클래스의 상태 머신에서의 전이).
상태 머신은 전이에 의해 링크된 상태로 구성됩니다. 상태는 일부 타스크를 수행하거나 이벤트를 대기하는 오브젝트의 조건입니다. 전이는 일부 이벤트로 트리거되는 두 상태 사이의 관계이며, 이는 특정 조치나 평가를
수행한 후 특정 종료 상태가 됩니다. 상태 머신의 요소가 그림 1에 표시됩니다.
그림 1. 상태 머신 표기법.
간단한 편집기는 상태가 비어 있음, 명령 대기 및 텍스트 대기인 한정된 상태 머신으로 보여질 수 있습니다. 파일 로드, 텍스트 삽입, 문자
삽입 및 저장 및 종료 이벤트는 상태 머신의 전이를 유발합니다. 편집기에 대한 상태 머신은 아래의 그림 1에서 설명합니다.
그림 2. 단순 편집기에 대한 상태 머신.
상태는 일부 타스크를 수행하거나 이벤트를 대기하는 오브젝트의 조건입니다. 오브젝트는 한정된 시간 동안 어느 한 상태에 머무를 수 있습니다. 상태에는 여러 특성이 있습니다.
이름
|
상태와 기타 상태를 구별하는 텍스트 문자열. 상태에는 이름이 없을 수 있습니다.
|
시작/종료 조치
|
상태에 들어가고 나갈 때 실행되는 조치.
|
내부 전이
|
상태 변경을 유발하지 않고 처리되는 전이.
|
하위 상태
|
분리(순차적 활성화) 또는 동시(동시 활성화) 하위 상태를 포함한 중첩 상태 구조.
|
연기된 이벤트
|
해당 상태에서 처리되지 않지만 연기되어 다른 상태에 오브젝트가 처리하도록 대기열에서 기다리는 이벤트의 목록.
|
그림 1에 보이는 대로 오브젝트의 상태 머신에 정의할 수 있는 두 가지 특수 상태가 있습니다. 초기 상태는 상태 머신이나 하위 상태에 대한 기본 시작 위치를 나타냅니다. 초기 상태는 채워진 검은색 원으로 보입니다.
최종 상태는 상태 머신의 실행 완료나 엔클로징 상태가 완료되었음을 나타냅니다. 최종 상태는 채워지지 않은 원으로 둘러싸인 채워진 검은색 원으로 표현됩니다. 초기 및 최종 상태는 진정한 Pseudo 상태입니다.
이름을 제외하면 두 상태 모두 정상 상태의 일반적인 부분을 포함하지 않을 수 있습니다. 초기 상태에서 최종 상태로의 전이에는 보호 조건 및 조치를 포함하여 전체 기능 보충이 있지만 트리거 이벤트는 없을 수도
있습니다.
전이는 두 상태 사이의 관계이며, 지정된 이벤트가 발생하고 지정된 조건이 충족될 때 첫 번째 상태의 오브젝트가 특정 조치를 수행한 후 두 번째 상태에 들어감을 나타냅니다. 이러한 상태의 변경에서는 전이가
'시작(fire)'된다고 합니다. 전이가 시작될 때까지 오브젝트는 '소스' 상태에 있으며 시작된 후에는 '대상' 상태에 있다고 합니다. 전이에는 여러 특성이 있습니다.
소스 상태
|
전이의 영향을 받는 상태. 오브젝트가 소스 상태에 있는 경우 출력 상태 전이는 오브젝트가 전이의 트리거 이벤트를 수신할 때 및 보호 조건(있는 경우)이 충족되는 경우에
시작(fire)됩니다.
|
이벤트 트리거
|
소스 상태의 오브젝트가 수신할 때 전이를 시작(fire)하기 적합하게 만드는(보호 조건이 충족된 경우) 이벤트.
|
보호 조건
|
이벤트 트리거의 수신으로 전이가 트리거될 때 평가되는 부울 표현식. 표현식이 참으로 평가되면 전이가 시작(fire)되기 적합하고 거짓으로 평가되면 전이가 시작되지 않습니다. 동일한
이벤트로 트리거할 수 있는 다른 전이가 없으면 이벤트가 유실됩니다.
|
조치
|
상태 머신을 소유하는 오브젝트에 대해 직접적으로 조치하고 오브젝트에 가시적인 기타 오브젝트에 대해 간접적으로 조치하는 실행 가능한 자동 계산.
|
대상 상태
|
전이가 완료된 후에 활성화되는 상태.
|
전이에는 여러 동시 상태로부터의 결합을 나타내는 복수 소스와 여러 동시 상태로의 분기 실행(fork)을 나타내는 복수 대상이 있을 수 있습니다.
상태 머신의 컨텍스트에서 이벤트는 상태 전이를 트리거할 수 있는 자극의 발생입니다. 이벤트에는 신호 이벤트, 호출 이벤트, 시간의 경과 또는 상태 변경이 포함될 수 있습니다. 신호 또는 호출에는 보호 조건과 조치에
대한 표현식을 포함하여 전이에 사용할 수 있는 값을 가지는 매개변수가 있을 수 있습니다. 이벤트 트리거가 없는 전이로 표현되는 트리거 없는 전이도 가질 수 있습니다. 완료 전이라고 부르는 이러한 전이는 소스 상태가
타스크를 완료할 때 내재적으로 트리거됩니다.
보호 조건은 전이에 대한 트리거 이벤트가 발생한 후에 평가됩니다. 보호 조건이 겹치지만 않으면 소스 상태가 동일하고 이벤트 트리거가 동일한 여러 전이를 가질 수 있습니다. 보호 조건은 이벤트가 발생할 때 전이에
대해 한 번만 평가됩니다. 부울 표현식은 오브젝트의 상태를 참조할 수 있습니다.
조치는 실행 가능한 자동 계산이며, 이벤트로 인터럽트할 수 없으며 따라서 완료될 때까지 계속 실행됨을 의미합니다. 이는 다른 이벤트가 인터럽트할 수 있는 타스크와 반대되는 개념입니다. 조치에는 오퍼레이션 호출(기타
가시적 오브젝트 및 상태 머신의 소유자에 대한), 다른 오브젝트의 작성이나 파기 또는 다른 오브젝트로의 신호 전송이 포함될 수 있습니다. 신호 전송의 경우 신호 이름의 접두부에 'send'라는 키워드가 붙습니다.
시작 및 종료 조치는 상태로 들어가거나 상태로부터 나갈 때마다 각각 동일한 조치가 디스패치되도록 합니다. 시작 및 종료 조치를 사용하면 모든 입력 또는 출력 전이에 명시적으로 조치를 지정할 필요 없이 이를 분명하게
수행할 수 있습니다. 시작 및 종료 조치에는 인수 또는 보호 조건이 없을 수도 있습니다. 모델 요소에 대한 상태 머신의 최상위 레벨에 있는 시작 조치에는 요소가 작성될 때 머신이 수신하는 인수를 나타내는 매개변수가
있을 수 있습니다.
내부 전이는 상태를 떠날 필요 없이 해당 상태 내에서 이벤트를 처리하도록 합니다. 따라서 시작 또는 종료 조치 트리거를 피할 수 있습니다. 내부 전이는 매개변수 및 보호 조건이 있는 이벤트를 가질 수 있으며
본질적으로 인터럽트 핸들러를 나타냅니다.
연기된 이벤트는 이벤트가 연기되지 않는 상태가 활성화될 때까지 처리가 연기되는 이벤트입니다. 이 상태가 활성화되면 이벤트 발생이 트리거되고 방금 발생한 것처럼 전이를 유발할 수 있습니다. 연기된 이벤트를 구현하려면
이벤트의 내부 대기열이 있어야 합니다. 이벤트가 발생하지만 연기로 나열되지 않는 경우 이는 대기열에 있는 것입니다. 오브젝트가 이벤트를 지연시키지 않는 상태에 들어가자마자 이 대기열에서 이벤트를 꺼냅니다.
단순 상태는 하위 구조가 없는 상태입니다. 하위 상태(중첩 상태)가 있는 상태는 컴포지트 상태라고 합니다. 하위 상태는 어떤 레벨로든 중첩될 수 있습니다. 중첩 상태 머신에는 많아야 하나의 초기 상태와 하나의 최종
상태가 있을 수 있습니다. 하위 상태는 일부 상태는 특정 컨텍스트 내(엔클로징 상태)에서만 가능함을 표시하여 복잡한 일반 상태 머신을 단순화하는 데 사용됩니다.
그림 3. 하위 상태.
엔클로징 컴포지트 상태 외부의 소스로부터, 전이는 컴포지트 상태를 대상으로 하거나 하위 상태를 대상으로 할 수 있습니다. 컴포지트 상태가 대상인 경우 중첩 상태 머신은 컴포지트 상태가 시작된 다음 시작 조치(있는
경우)를 디스패치한 후에 제어가 전달되는 초기 상태를 포함해야 합니다. 중첩 상태가 대상인 경우에는 컴포지트 상태의 시작 조치(있는 경우)를 디스패치한 다음 중첩 상태의 시작 조치(있는 경우)를 디스패치한 후에
중첩 상태에 제어가 전달됩니다.
컴포지트 상태 외부로 이끄는 전이는 소스로 컴포지트 상태나 하위 상태를 가질 수 있습니다. 두 경우 모두, 제어는 먼저 중첩 상태를 떠난 다음(종료 조치가 있으면 디스패치됨) 컴포지트 상태를 떠납니다(종료 조치가
있으면 디스패치됨). 소스가 컴포지트 상태에 있는 전이는 본질적으로 중첩 상태 머신의 타스크를 인터럽트합니다.
다르게 지정되어 있지 않으면, 전이가 컴포지트 상태에 들어갈 때 중첩된 상태 머신의 조치가 초기 상태에서 다시 시작합니다(전이가 하위 상태를 직접 대상으로 하지 않는 경우). 히스토리 상태는 상태 머신이 컴포지트
상태를 떠나기 전에 활성화되었던 최종 하위 상태에 다시 들어가게 합니다. 히스토리 상태 사용의 예제가 그림 3에서 표시됩니다.
그림 4. 히스토리 상태.
상태 머신은 오브젝트 수명 중의 동작을 모델링하는 데 가장 일반적으로 사용됩니다. 이는 특히 오브젝트에 상태 종속적 동작이 있을 때에 필요합니다. 상태 머신이 있을 수 있는 오브젝트에는 클래스, 서브시스템, 유스
케이스 및 인터페이스(인터페이스를 실현하는 오브젝트가 충족시켜야 할 상태를 주장)가 포함됩니다. 실시간 시스템의 경우 상태 머신은 캡슐 및 프로토콜(프로토콜을 실현하는 오브젝트가 충족시켜야 할 상태를 주장)에도
사용됩니다.
모든 오브젝트에 상태 머신이 필요한 것은 아닙니다. 오브젝트의 동작이 간단한 경우(예: 단순히 데이터를 저장하거나 검색) 오브젝트의 동작은 상태 불변이며 상태 머신이 거의 불필요합니다.
오브젝트의 수명 모델링은 오브젝트가 응답할 수 있는 이벤트 지정, 이들 이벤트에 대한 응답 및 현재 동작에 대한 과거의 영향 등 세 가지 사항을 포함합니다. 오브젝트의 수명 모델링은 오브젝트가 이벤트에 의미있게
응답할 수 있는 순서를 결정하고, 오브젝트의 작성 시간에 시작하며, 파기될 때까지 계속 진행하는 등의 사항과도 관련이 있습니다.
오브젝트의 수명을 모델링하려면 다음을 수행하십시오.
-
클래스, 유스 케이스 또는 전체 시스템인지에 따라 상태 머신에 대한 컨텍스트를 설정하십시오.
-
컨텍스트가 클래스 또는 유스 케이스이면 연관 또는 종속성으로 도달 가능한 클래스 또는 상위 클래스를 포함하여 이웃 클래스를 수집하십시오. 이웃은 조치에 대한 후보 대상이며 보호 조건에 포함하기
위한 후보 대상입니다.
-
컨텍스트가 전체 시스템인 경우에는 시스템의 한 동작으로 초점을 좁힌 다음 해당 측면과 관련된 오브젝트의 수명을 고려하십시오. 전체 시스템의 수명은 단순히 너무 커서 초점을 맞추기 어렵습니다.
-
오브젝트에 대한 초기 및 최종 상태를 설정하십시오. 초기 및 최종 상태의 전제 조건 또는 사후 조건이 있으면 이들도 정의하십시오.
-
오브젝트가 응답하는 이벤트를 판별하십시오. 오브젝트의 인터페이스에서 찾을 수 있습니다. 실시간 시스템의 경우 오브젝트의 프로토콜에서도 찾을 수 있습니다.
-
초기 상태에서 시작해서 최종 상태에 이르기까지 오브젝트가 있을 수 있는 최상위 레벨 상태를 레이아웃하십시오. 이들 상태를 해당 이벤트가 트리거한 전이와 연결하십시오. 이들 전이를 계속 추가하십시오.
-
시작 또는 종료 조치를 식별하십시오.
-
하위 상태를 사용하여 상태 머신을 확장하거나 단순화하십시오.
-
상태 머신에서 전이를 트리거하는 모든 이벤트가 오브젝트가 인식한 인터페이스에서 예상한 이벤트와 일치하는지 확인하십시오. 마찬가지로 오브젝트의 인터페이스에서 예상된 모든 이벤트를 상태 머신이 처리하는지
확인하십시오. 실시간 시스템의 경우 캡슐의 프로토콜에 대해 동일한 확인을 수행하십시오. 마지막으로 이벤트를 명시적으로 제외하려는 지점을 찾으십시오(예: 연기된 이벤트).
-
엔클로징 오브젝트의 오퍼레이션, 메소드 및 관계가 상태 머신의 모든 조치를 지원하는지 확인하십시오.
-
상태 머신을 이벤트 및 응답의 예상된 시퀀스와 비교하면서 추적하십시오. 도달 불가능한 상태 및 머신이 고정되는 상태를 검색하십시오.
-
상태 머신을 다시 배열하거나 다시 구조화하는 경우 시맨틱이 변경되지 않도록 하십시오.
-
선택사항이 제공되면 세부사항 전이 코드를 쓰는 대신 상태 머신의 시각적 시맨틱을 사용하십시오. 예를 들어, 여러 신호에서 한 전이를 트리거하지 마십시오. 그러한 경우에는 세부 코드를 사용하여 신호에 따라
제어 플로우를 다르게 관리하십시오. 별도의 신호로 트리거되는 별도의 전이를 사용하십시오. 추가 동작을 숨기는 전이 코드의 조건부 로직을 사용하지 마십시오.
-
상태 중에 발생 또는 대기 중인 사항에 따라 상태의 이름을 지정하십시오. 상태는 한 '시점'이 아니라 상태 머신이 무언가가 발생하기를 기다리는 동안의 기간임을 기억하십시오. 예를 들어, 'end'보다는
'waitingForEnd'가, 'timeout'보다는 'timingSomeTask'가 더 나은 이름입니다. 상태가 조치인 것처럼 이름을 지정하지 마십시오.
-
상태 머신 내의 모든 상태와 전이의 이름을 고유하게 지정하십시오. 그러면 소스 레벨 디버깅을 보다 수월하게 수행할 수 있습니다.
-
상태 변수(동작을 제어하는 데 사용되는 속성)는 주의해서 사용하십시오. 새 상태를 작성하는 대신 이들을 사용하지 마십시오. 상태 종속적 동작이 거의 없거나 전혀 없는 상태가 적은 경우 및 상태 머신을
포함하는 오브젝트에 독립적이거나 동시적일 수 있는 동작이 거의 없거나 전혀 없는 경우에 상태 변수를 사용할 수 있습니다. 잠재적으로 동시적이며 복잡한 상태 종속적 동작이 있는 경우 또는 처리해야 하는
이벤트가 상태 머신을 포함하는 오브젝트 외부에서 생성될 수 있는 경우 둘 이상의 활성 오브젝트의 협업을 사용하는 것을 고려하십시오(컴포지션으로 정의될 수 있음). 실시간 시스템에서는 하위 캡슐을 포함하는
캡슐을 사용하여 복잡한 상태 종속적, 동시 동작을 모델링해야 합니다.
-
5 ± 2 이상의 상태가 단일 다이어그램에 있으면 하위 상태를 사용하는 것을 고려하십시오. 상식적으로도 알 수 있듯이, 절대적 정규 패턴에는 열 가지 상태로도 좋을 수 있지만 두 상태 및 해당 상태 간의
전이가 40가지인 경우에는 분명히 다시 생각해 볼 필요가 있습니다. 상태 머신을 이해 가능하도록 만드십시오.
-
이벤트를 트리거하는 사항 및/또는 전이 중 발생하는 사항에 대해 전이의 이름을 지정하십시오. 이해하기 쉬운 이름을 선택하십시오.
-
선택점이 보이면 해당 선택사항에 대한 책임을 다른 컴포넌트에 위임할 수 있는지 여부를 물어서 조치가 수행될 별개의 신호 세트로 오브젝트에 표시되도록 하고(예: msg->data > x에 대한
선택사항 대신), 송신자나 일부 다른 중간 액터가 결정한 후 신호 이름에 명시적 결정이 포함된 신호를 전송하도록 해야 합니다(예: 신호 이름 값을 포함하고 메시지 데이터를 확인하는 대신 isFull 및
isEmpty라는 신호를 사용함).
-
선택점에서 설명적으로 응답한 질문에 이름을 지정하십시오(예: 'isThereStillLife' 또는 'isItTimeToComplain').
-
제공된 오브젝트 내에서 선택점 이름을 고유하게 유지하도록 노력하십시오(전이 이름을 고유하게 유지하는 이유와 동일함).
-
전이에 너무 긴 코드 단편이 있습니까? 함수를 대신 사용해야 하고 공통 코드 단편이 함수로 캡처됩니까? 전이는 상위 레벨 Pseudo 코드처럼 읽히고 C++ 함수와 동일하거나 훨씬 엄격한 길이 규칙을
준수해야 합니다. 예를 들어, 코드 행이 25를 초과하는 전이는 너무 긴 것으로 간주됩니다.
-
함수는 수행하는 사항에 따라 이름을 지정해야 합니다.
-
시작 및 종료 조치에 특별히 주의하십시오. 특히 변경한 다음 시작 및 종료 조치를 변경하는 것을 잊기 쉽습니다.
-
종료 조치는 안전 기능을 제공하는 데 사용할 수 있습니다. 예를 들어, 'heaterOn' 상태에서의 종료 조치는 난방기를 끄며 여기서의 조치는 주장을 시행하는 데 사용됩니다.
-
일반적으로 하위 상태는 상태 머신이 추상이 아닌 한 둘 이상의 상태를 포함해야 하며 엔클로징 요소의 하위 클래스로 정제됩니다.
-
조치 또는 전이의 조건부 로직 대신 선택점을 사용해야 합니다. 선택점은 쉽게 알 수 있는 반면 코드의 조건부 로직은 숨겨져 있어서 간과하기 쉽습니다.
-
보호 조건을 사용하지 마십시오.
-
이벤트가 여러 전이를 트리거하는 경우 어떤 보호 조건이 먼저 평가되는지에 대한 제어가 없습니다. 결과적으로 결과를 예측할 수 없습니다.
-
둘 이상의 보호 조건이 '참'인 경우에도 한 전이만이 뒤따릅니다. 선택된 경로를 예측할 수 없습니다.
-
보호 조건은 비가시적이며 존재하는지 '보기'가 더 어렵습니다.
-
플로우 차트와 비슷한 상태 머신은 사용하지 마십시오.
-
이는 다음과 같이 사실은 존재하지 않는 추상을 모델링하려는 시도를 나타낼 수 있습니다.
-
활성 클래스를 사용하여 수동 또는 데이터 클래스에 가장 적합한 동작 모델링
-
매우 긴밀하게 결합된 데이터 클래스와 활성 클래스를 사용하여 데이터 클래스 모델링(즉, 주변의 유형 정보를 전달하는 데 데이터 클래스가 사용되었지만 활성 클래스가 데이터 클래스와
연관시켜야 하는 대부분의 데이터를 포함함).
-
상태 머신의 올바르지 않은 사용은 다음 증상으로 알 수 있습니다.
-
주로 코드 재사용 용도로만 '자신'에게 전송된 메시지
-
상태는 적고 선택점은 많음
-
주기가 없는 상태 머신의 일부 경우. 이러한 상태 머신은 프로세스 제어 응용프로그램에서 또는 이벤트의 시퀀스를 제어할 때 올바릅니다. 분석 중 이들이 나타나면 일반적으로 상태
머신이 플로우 차트로 퇴보합니다.
-
문제점이 식별되면 다음을 수행하십시오.
-
책임을 보다 명확히 해서 활성 클래스를 보다 작은 단위로 분할하는 것을 고려하십시오.
-
문제점 활성 클래스와 연관된 데이터 클래스로 더 많은 동작을 이동시키십시오.
-
활성 클래스 기능으로 더 많은 동작을 이동시키십시오.
-
데이터에 의존하는 대신 신호를 보다 의미있게 하십시오.
추상 상태 머신은 실질적 목적으로 사용하려면 더 많은 세부사항을 추가할 필요가 있는 상태 머신입니다. 추상 상태 머신은 일반적이고 재사용가능하며 후속 모델 요소에서 더욱 정제되는 동작을 정의하는 데 사용할 수
있습니다.
그림 5. 추상 상태 머신.
그림 5의 추상 상태 머신을 고려하십시오. 표시된 단순 상태 머신은 이벤트 기반 시스템의 여러 다른 유형의 요소에 대한 동작의 가장 추상적인 레벨("제어" 자동화)을 대표합니다. 이들 모두가 이 상위 레벨 양식을
공유하지만 다른 요소 유형에는 목적에 따라 실행 중인 상태에 있는 광범위하게 다른 자세한 동작이 있을 수 있습니다. 따라서 이 상태 머신은 다른 특수 활성 클래스에 대한 루트 클래스 역할을 하는 일부 추상 클래스로
정의될 가능성이 가장 높습니다.
따라서 상속을 사용하여 이 추상 상태 머신의 두 가지 다른 정제를 정의합니다. 이들 두 정제 R1 및 R2가 그림 6에 표시되어 있습니다. 명확히 표현하기 위해 상위 클래스에서 상속한 요소는 회색으로 표시했습니다.
그림 6. 그림 5의 상태 머신에 대한 두 가지 정제.
두 가지 정제는 실행 중 상태를 분해하는 방식 및 원래 "시작" 전이를 확장하는 방식에서도 분명하게 차이가 납니다. 이러한 선택은 물론 정제가 일단 알려진 후에만 작성할 수 있으며, 따라서 추상 클래스에서 단일
단말 간 전이로 수행할 수 없습니다.
입력 전이 및 출력 전이를 모두 "계속"할 수 있는 능력은 위에서 설명한 정제의 유형의 근본입니다. 연속 전이와 결합된 시작점 및 최종 상태로 이러한 시맨틱을 충분히 제공할 수 있는 것처럼 보일 수도 있습니다.
그러나 불행하게도 확장해야 할 여러 다른 전이가 있는 경우 이는 충분하지 않습니다.
추상 동작 패턴에는 단일 RTC(Run-to-completion) 단계의 범위에서 모두 실행되는 둘 이상의 전이 세그먼트를 체인화하는 방법이 필요합니다. 이는 계층 구조 상태에 들어선 전이가 상태 경계에서
효과적으로 종료되는 입력 파트 및 상태 내에서 계속되는 확장으로 분할됨을 의미합니다. 이와 마찬가지로 계층 구조상 중첩 상태에서 나온 출력 전이는 엔클로징 상태 경계에서 종료되는 파트와 상태 경계에서 대상 상태로
계속하는 파트로 분할됩니다. 이는 UML에 체인 상태 개념을 도입하여 수행할 수 있습니다. 이는 UML 상태 개념의 스테레오타입(<<chainState>>)으로 모델링됩니다. 이
상태의 유일한 목적은 추가 자동(트리거 없는) 전이를 입력 전이로 "체인화"하는 것입니다. 체인 상태에는 내부 구조 즉, 시작 조치, 내부 타스크, 종료 조치 등이 없습니다. 이벤트로 트리거되는 전이도 없습니다.
임의의 수의 입력 전이는 있을 수 있습니다. 트리거 이벤트가 없는 출력 전이가 있을 수 있으며 이 전이는 입력 전이가 상태를 활성화할 때 자동으로 시작됩니다. 상태의 목적은 입력 전이를 개별 출력 전이로 체인화하는
것입니다. 입력 전이와 체인화된 출력 전이 사이에서 하나는 포함 상태 내의 다른 상태에 연결하고 다른 하나는 포함 상태 외부의 다른 상태에 연결합니다. 체인 상태를 도입하는 목적은 포함 상태의 내부 스펙을 외부
환경에서 분리하기 위한 것이며, 이는 캡슐화의 문제입니다.
사실 체인 상태는 한 전이를 특정 연속 전이로 체인화하기 위한 "통과(pass through)" 상태를 나타냅니다. 정의된 연속 전이가 없으면 전이는 체인 상태에서 종료되고 진행을 위해 결국 엔클로징 상태의 일부
전이를 시작(fire)해야 합니다.
그림 7의 상태 머신 세그먼트 예제는 체인 상태와 해당 표기법을 설명합니다. 상태 머신 다이어그램에서 체인 상태는 해당 계층 구조 상태 내에 있는 작은 흰색 원으로 표시됩니다(이 표기법은 서로 닮은 초기 및 최종
상태와 유사함). 원은 체인 상태 스테레오타입의 스테레오타입 아이콘이며 일반적으로 편의상 경계 가까이에 그립니다. (사실, 엔클로징 상태의 경계에 이를 그려서 표기상의 변화를 줄 수 있습니다.)
그림 7. 체인 상태 및 체인화된 전이.
이 예제에서 체인화된 전이는 세 가지 체인화된 전이 세그먼트인 e1/a11-/a12-/a13으로 구성됩니다. 신호 e1이 수신되면 e1/a11이란 레이블이 붙은 전이가 발생하고 조치 a11이 실행된 다음 상태
c1에 도달합니다. 그런 다음 c1 및 c2 사이의 연속 전이가 발생하고 c2도 체인 상태이기 때문에 결국 c2에서 S21로 전이가 일어납니다. 이들 경로의 상태에 모두 종료 및 시작 조치가 있으면 조치 실행의
실제 시퀀스는 다음과 같이 진행됩니다.
-
S11의 종료 조치
-
조치 a11
-
S1의 종료 조치
-
조치 a12
-
S2의 시작 조치
-
조치 a13
-
S21의 시작 조치
이들 모두는 단일 RTC(Run-to-completion) 단계의 범위에서 실행됩니다.
다음과 같은 직접 전이 e2/a2의 조치 실행 시맨틱에 대해 이를 비교해야 합니다.
-
S11의 종료 조치
-
S1의 종료 조치
-
조치 a2
-
S2에 대한 시작 조치
-
S21에 대한 시작 조치
|