UML 상태 기계

UML 다이어그램 유형
구조 UML 다이어그램
클래스 다이어그램 컴포넌트 다이어그램 복합구조도 도입도 오브젝트 다이어그램 패키지 다이어그램 프로파일 다이어그램
동작 UML 다이어그램
액티비티 다이어그램 커뮤니케이션 다이어그램 상호작용 개요도 시퀀스 다이어그램 상태도 타이밍 다이어그램 사용 사례도
v t

UML 상태 머신(^[1]UML 상태 차트라고도 함)은 Unified Modeling Language(UML) 표기법으로 표현되는 컴퓨터 과학 응용 프로그램에서 유한 자동화의 수학적 개념을 확장한 것입니다.

이 개념의 배후에 있는 것은, 디바이스, 컴퓨터 프로그램, 또는 그 외의(종종 기술적인) 프로세스가 동작하는 방법을 정리하는 것으로, 엔티티 또는 그 서브 엔티티가 항상 가능한 몇개의 상태 중 하나이며, 이러한 상태 사이에 명확하게 정의된 조건부 천이가 존재하는 경우에 한정됩니다.

UML 스테이트 머신은 Harel 스테이트 ^[2]차트의 객체 기반 변형으로 UML에 의해 채택 ^[1]및 확장됩니다.^[3]UML 스테이트 머신의 목표는 기존의 유한 스테이트 머신의 주요 한계를 극복하면서 그 주요 이점을 유지하는 것입니다.UML 상태 차트는 계층적으로 중첩된 상태와 직교 영역의 새로운 개념을 소개하면서 동작 개념을 확장합니다.UML 스테이트 머신은 Maly 머신과 Moore 머신 양쪽의 특성을 가지고 있습니다.Maly 머신과 같이 시스템 상태와 트리거 이벤트에 따라 달라지는 액션과 Moore ^[4]머신과 같이 전환이 아닌 상태와 관련된 진입 및 종료 액션을 지원합니다.

"UML 상태 머신"이라는 용어는 동작 상태 머신과 프로토콜 상태 머신의 두 가지 종류의 상태 머신을 나타낼 수 있습니다.동작 상태 머신을 사용하여 개별 엔티티(클래스 인스턴스 등), 서브시스템, 패키지 또는 시스템 전체의 동작을 모델링할 수 있습니다.프로토콜 상태 시스템은 사용 프로토콜을 표현하는 데 사용되며 분류자, 인터페이스 및 포트의 법적 사용 시나리오를 지정하는 데 사용할 수 있습니다.

기본 상태 기계 개념

많은 소프트웨어 시스템은 이벤트 구동형입니다.즉, 마우스 클릭, 버튼 누름, 시간 틱, 데이터 패킷 도착 등 외부 또는 내부 이벤트가 발생할 때까지 지속적으로 대기합니다.이벤트를 인식한 후 이러한 시스템은 하드웨어 조작이나 다른 내부 소프트웨어 컴포넌트를 트리거하는 "소프트" 이벤트를 생성하는 등 적절한 계산을 수행함으로써 반응합니다(이 때문에 이벤트 구동 시스템을 반응 시스템이라고 합니다).이벤트 처리가 완료되면 시스템은 다음 이벤트 대기 상태로 돌아갑니다.

이벤트에 대한 응답은 일반적으로 이벤트 유형과 시스템 내부 상태에 따라 달라지며 상태 천이를 초래하는 상태 변화를 포함할 수 있습니다.이러한 스테이트간의 이벤트, 스테이트, 및 스테이트 천이의 패턴을 추상화해, Finite-State Machine(FSM; 유한 상태 머신)으로서 나타낼 수 있습니다.

FSM의 개념은 이벤트 처리를 이벤트유형과 시스템 상태에 따라 명시적으로 의존하게 하기 때문에 이벤트 드리븐 프로그래밍에서 중요합니다.올바르게 사용하면 스테이트 머신은 코드를 통과하는 실행 경로의 수를 대폭 줄이고 각 분기점에서 테스트된 조건을 간소화하며 다양한 ^[5]실행 모드 간의 전환을 간소화할 수 있습니다.반대로 기본 FSM 모델 없이 이벤트 기반 프로그래밍을 사용하면 프로그래머가 오류를 일으키기 쉽고 확장하기 어렵고 지나치게 복잡한 애플리케이션 ^[6]코드를 생성할 수 있습니다.

기본 UML 상태 다이어그램

UML은 기존 상태 다이어그램의 일반적인 형식을 유지합니다.UML 상태 다이어그램은 노드가 상태를 나타내고 커넥터가 상태 천이를 나타내는 방향 그래프입니다.예를 들어 그림 1은 컴퓨터 키보드 상태 기계에 대응하는 UML 상태도를 나타낸다.UML에서 상태는 상태 이름으로 레이블이 지정된 둥근 직사각형으로 표시됩니다.화살표로 표시되는 전환에는 트리거 이벤트가 표시된 후 선택적으로 실행된 작업 목록이 표시됩니다.초기 전환은 솔리드 원에서 시작되며 시스템이 처음 시작될 때 기본 상태를 지정합니다.모든 상태 다이어그램에는 이러한 전환이 있어야 합니다. 이러한 전환은 이벤트에 의해 트리거되지 않으므로 라벨이 부착되어서는 안 됩니다.초기 이행에는 관련된 액션이 있을 수 있습니다.

이벤트

이벤트는 시스템에 영향을 미치는 것입니다.엄밀히 말하면, UML ^[1]규격에서 사건이라는 용어는 발생의 구체적인 경우를 지칭하는 것이 아니라 발생 유형을 지칭합니다.예를 들어, 키 입력은 키보드의 이벤트이지만 키를 누를 때마다 이벤트가 아니라 키 입력 이벤트의 구체적인 인스턴스입니다.키보드의 다른 관심사는 전원 켜기일 수 있지만 내일 10:05:36에 전원을 켜는 것은 전원 켜기 이벤트의 한 예에 불과합니다.

이벤트에는 관련된 파라미터를 가질 수 있으므로 이벤트인스턴스는 대상 사고의 발생뿐만 아니라 해당 발생에 관한 정량적 정보도 전달할 수 있습니다.예를 들어 컴퓨터 키보드의 키를 눌러 생성되는 키 스트로크 이벤트에는 문자 스캔 코드와 Shift, Ctrl 및 Alt 키의 상태를 전달하는 관련 파라미터가 있습니다.

이벤트 인스턴스는 이벤트 인스턴스를 생성한 순간 발생보다 오래 지속되며 이 발생을 하나 이상의 상태 시스템에 전달할 수 있습니다.이벤트 인스턴스가 생성되면 최대 3단계로 구성될 수 있는 처리 라이프 사이클을 거칩니다.첫 번째로 이벤트인스턴스가 받아들여지고 처리를 대기할 때(이벤트큐에 배치되는 등) 이벤트인스턴스가 수신됩니다.나중에 이벤트인스턴스가 상태 머신으로 디스패치되고 이 시점에서 현재 이벤트가 됩니다.마지막으로 스테이트 머신의 이벤트인스턴스 처리가 완료되면 소비됩니다.사용된 이벤트 인스턴스를 더 이상 처리할 수 없습니다.

미국.

각 상태 시스템에는 이벤트에 대한 상태 시스템의 반응을 제어하는 상태가 있습니다.예를 들어 키보드에서 키를 누르면 Caps Lock이 활성화되었는지 여부에 따라 생성된 문자 코드가 대문자 또는 소문자 중 하나가 됩니다.따라서 키보드의 동작은 "기본" 상태와 "caps_locked" 상태의 두 가지 상태로 나눌 수 있습니다.(대부분의 키보드에는 키보드가 "caps_locked" 상태임을 나타내는 LED가 포함되어 있습니다).키보드의 동작은 Caps Lock 키를 눌렀는지 여부 등 키보드의 이력에 따라 달라질 뿐 이전에 눌렀던 다른 키의 수와 정확한 수에 따라 달라지지 않습니다.상태는 가능한 모든 이벤트시퀀스를 추상화하고 관련 이벤트시퀀스만 캡처할 수 있습니다.

소프트웨어 상태 기계(특히 고전적 FSM)의 맥락에서 상태라는 용어는 종종 제한된 수의 선험적 결정 값(키보드의 경우 두 개의 값 또는 더 일반적으로 많은 프로그래밍 언어의 열거형 변수)만을 가정할 수 있는 단일 상태 변수로 이해된다.상태 변수(및 고전적인 FSM 모델)의 개념은 상태 변수의 값이 특정 시간에 시스템의 현재 상태를 완전히 정의하는 것입니다.상태 개념은 코드에서 실행 컨텍스트를 식별하는 문제를 많은 변수 대신 상태 변수만 테스트하는 것으로 줄여 많은 조건부 논리를 제거합니다.

확장 상태

그러나 실제로는 상태 머신의 전체 상태를 단일 상태 변수로 해석하는 것은 매우 단순한 상태를 넘어 모든 상태 머신에 대해 실용적이지 않게 됩니다.실제로 머신 상태에 32비트 정수가 1개라도 40억 개 이상의 다른 상태에 영향을 미칠 수 있으며, 이는 조기 상태 폭발로 이어질 수 있습니다.이 해석은 실용적이지 않기 때문에 UML 스테이트 머신에서는 스테이트 머신의 전체 상태가 일반적으로 (a) 열거 가능한 스테이트 변수와 (b) 확장 스테이트라고 하는 다른 모든 변수로 분할됩니다.이를 확인할 수 있는 또 다른 방법은 열거 가능한 상태 변수를 질적 측면으로 해석하고 확장된 상태를 전체 상태의 양적 측면으로 해석하는 것입니다.이 해석에서 변수의 변화는 항상 시스템 동작의 질적 측면의 변화를 의미하는 것은 아니므로 ^[7]상태 변화로 이어지지 않는다.

확장 상태 변수를 보완하는 상태 머신을 확장 상태 머신이라고 하며 UML 상태 머신은 이 카테고리에 속합니다.확장 상태 기계는 확장 상태 변수를 포함하지 않고 실제보다 훨씬 더 복잡한 문제에 기본 형식주의를 적용할 수 있습니다.예를 들어 FSM에 어떤 제한(키보드 키 입력 수를 1000으로 제한)을 실장해야 하는 경우 확장 스테이트가 없으면 1000개의 스테이트를 작성 및 처리해야 합니다.이것은 실용적이지 않습니다만, 확장 스테이트 머신을 사용하면 도입할 수 있습니다.key_countvariable: 상태 변수를 변경하지 않고 1000으로 초기화되며 키 입력마다 감소합니다.

그림 2의 상태 다이어그램은 확장 상태 기계의 한 예입니다. 여기서 시스템의 전체 조건(확장 상태라고 함)은 질적 측면(상태 변수)과 양적 측면(양적 측면)의 조합입니다.

확장 스테이트 머신의 명백한 장점은 유연성입니다.예를 들어, 다음에 의해 제어되는 제한 변경key_count1000 ~ 10000 의 키 스트로크를 사용하면 확장 스테이트 머신이 전혀 복잡해지지 않습니다.필요한 변경은 의 초기화 값을 변경하는 것뿐입니다.key_count초기화 중 확장 상태 변수.

그러나 확장 상태의 "질적" 측면과 "양적" 측면 사이의 복잡한 결합 때문에 확장 상태 기계의 이러한 유연성에는 대가가 따른다.연결은 그림 2와 같이 전환에 부착된 가드 조건을 통해 발생합니다.

가드 조건

가드 조건(또는 단순히 가드)은 확장 상태 변수 및 이벤트 파라미터의 값에 따라 동적으로 평가되는 부울식입니다.가드 조건은 TRUE로 평가될 때만 작업 또는 전환을 활성화하고 FALSE로 평가될 때만 비활성화함으로써 상태 시스템의 동작에 영향을 줍니다.UML 표기법에서 가드 조건은 대괄호(예:[key_count == 0]를 참조해 주세요.

가드의 필요성은 메모리 확장 상태 변수를 상태 기계 형식주의에 추가하는 즉각적인 결과입니다.확장 상태 변수와 가드는 드물게 사용되며 설계를 단순화할 수 있는 강력한 메커니즘을 구성합니다.반면에, 확장된 상태와 가드를 꽤 쉽게 남용할 수 있습니다.^[8]

액션과 이행

이벤트 인스턴스가 디스패치되면 상태 시스템은 변수 변경, I/O 수행, 함수 호출, 다른 이벤트 인스턴스 생성 또는 다른 상태로 변경 등의 작업을 수행하여 응답합니다.현재 이벤트와 관련된 파라미터 값은 해당 이벤트로 인해 직접 발생하는 모든 액션에 사용할 수 있습니다.

어떤 상태에서 다른 상태로 전환되는 것을 상태 전이라고 하며, 그 원인이 되는 이벤트를 트리거링 이벤트 또는 단순히 트리거라고 합니다.키보드 예에서 CapsLock 키를 눌렀을 때 키보드가 "기본" 상태이면 키보드는 "caps_locked" 상태가 됩니다.그러나 키보드가 이미 "caps_locked" 상태일 경우 CapsLock을 누르면 "caps_locked" 상태에서 "default" 상태로 전환됩니다.두 경우 모두 CapsLock을 누르면 트리거 이벤트가 발생합니다.

확장 스테이트 머신에서는 트랜지션에는 가드가 TRUE로 평가되었을 경우에만 트랜지션이 "발화"할 수 있습니다.상태는 오버랩되지 않는 가드를 가지고 있는 한 같은 트리거에 응답하여 많은 트랜지션을 가질 수 있습니다.다만, 이 상황은 가드의 평가 시퀀스에 문제를 일으킬 수 있습니다.Ommon 트리거가 발생합니다.UML 규격은^[1] 의도적으로 특정 순서를 규정하지 않고 오히려 설계자가 평가 순서가 중요하지 않도록 가드를 고안해야 하는 부담을 준다.사실상, 이것은 가드 표현에 부작용이 없어야 하며, 적어도 동일한 트리거를 가진 다른 가드들의 평가를 바꾸지 않아야 한다는 것을 의미합니다.

실행에서 완료까지의 실행

UML 스테이트 머신을 포함한 모든 스테이트 머신의 형식은 일반적으로 스테이트 머신이 다음 이벤트 처리를 시작하기 전에 각 이벤트의 처리를 완료한다고 가정합니다.이 실행 모델을 Run to Complete(RTC)라고 합니다.

RTC 모델에서는, 시스템은 이벤트를 분할할 수 없는 개별의 RTC 스텝으로 처리합니다.새로운 착신 이벤트는 현재 이벤트의 처리를 중단할 수 없으며 상태 머신이 다시 아이돌 상태가 될 때까지 (일반적으로 이벤트큐에) 저장해야 합니다.이러한 시멘틱스에 의해, 단일의 스테이트 머신내의 내부 동시성의 문제가 완전하게 회피됩니다.또한 RTC 모델은 작업 기간 동안 상태 머신이 제대로 정의된 상태(두 상태 사이)가 아닌 천이와 관련된 작업 처리의 개념적인 문제를 해결합니다.이벤트 처리 중에는 시스템이 응답하지 않기 때문에(관측할 수 없음), 그 시간 동안 잘못 정의된 상태는 실질적으로 의미가 없습니다.

단, RTC가 RTC 스텝이 ^[1]완료될 때까지 스테이트 머신이 CPU를 독점할 필요는 없습니다.프리엠프션 제한은 이미 이벤트를 처리하고 있는 상태 머신의 작업 컨텍스트에만 적용됩니다.멀티태스킹 환경에서는 다른 태스크(비지 상태 머신의 태스크 컨텍스트와 관련되지 않음)를 실행할 수 있으며, 현재 실행 중인 상태 머신이 우선될 수 있습니다.다른 상태 기계들이 변수나 다른 자원을 서로 공유하지 않는 한, 동시성 위험은 없습니다.

RTC 처리의 주요 장점은 단순함입니다.가장 큰 단점은 스테이트 머신의 응답성이 가장 긴 RTC 스텝에 의해 결정된다는 것입니다.짧은 RTC 단계를 달성하면 실시간 설계가 상당히 복잡해질 수 있습니다.

전통적인 FSM 형식주의에 대한 UML 확장

기존의 FSM은 작은 문제에 대처하기 위한 뛰어난 도구이지만, 일반적으로는 어느 정도 관련된 시스템에서도 관리가 불가능해지는 경향이 있는 것으로 알려져 있습니다.상태 및 이행의 폭발로 알려진 현상으로 인해 기존 FSM의 복잡성은 시스템이 설명하는 복잡성보다 훨씬 빠르게 증가하는 경향이 있습니다.이것은 전통적인 국가 시스템 형식주의가 반복을 가하기 때문에 일어난다.예를 들어 기존의 FSM을 사용하여 단순한 포켓 계산기의 동작을 나타내려고 하면 많은 이벤트(Clear 버튼 누름 또는 Off 버튼 누름 등)가 여러 상태에서 동일하게 처리된다는 것을 즉시 알 수 있습니다.아래 그림에 나타난 기존 FSM은 이러한 공통성을 포착하는 수단이 없으며 많은 상태에서 동일한 동작과 전환을 반복해야 합니다.전통적인 상태 기계에는 없는 것이 많은 상태 간에 공유하기 위해 일반적인 동작을 배제하는 메커니즘입니다.

UML 스테이트 머신은, 종래의 FSM 의 이러한 단점에 정확하게 대응합니다.UML 스테이트 머신의 복잡성이 더 이상 폭발하지 않도록 반복을 배제하기 위한 많은 기능을 제공하지만 UML 스테이트 머신이 설명하는 반응 시스템의 복잡성을 충실하게 나타내는 경향이 있습니다.이러한 기능은 소프트웨어 개발자에게 매우 흥미롭습니다. 왜냐하면 이러한 기능만이 실제 문제에 대해 상태 머신 전체의 접근방식을 진정으로 적용할 수 있도록 하기 때문입니다.

계층적으로 중첩된 상태

기존의 FSM보다 UML 스테이트 머신의 가장 중요한 혁신은 계층적으로 중첩된 스테이트의 도입입니다(그래서 스테이트 차트는 계층형 스테이트 머신(HSM)이라고도 불립니다).스테이트 네스트와 관련된 의미는 다음과 같습니다(그림3 참조).예를 들어, 시스템이 네스트 상태에 있는 경우(서브스테이트라고 불립니다), 그 시스템도 (암묵적으로) 주변 상태에 있는 경우(슈퍼스테이트라고 불립니다).이 스테이트 머신은 하위 스테이트의 컨텍스트(개념상 하위 레벨)에서 이벤트를 처리하려고 합니다.단, 서브스테이트 "result"가 이벤트 처리 방법을 규정하지 않으면 이벤트는 기존의 "Flat" 스테이트 머신에서처럼 조용히 폐기되지 않고 슈퍼스테이트 "on"의 상위 레벨 컨텍스트에서 자동으로 처리됩니다.이것은, 시스템이 「결과」와「온」의 상태가 되는 것을 의미합니다.물론 상태 네스팅이 한 수준에만 제한되는 것은 아니며 이벤트 처리의 단순한 규칙이 모든 수준의 네스팅에 재귀적으로 적용됩니다.

다른 상태를 포함하는 상태를 복합 상태라고 하며, 반대로 내부 구조가 없는 상태를 단순 상태라고 합니다.내포된 상태는 다른 상태에 의해 포함되지 않은 경우 직접 서브스테이트라고 불리며, 그렇지 않은 경우 과도적으로 중첩된 서브스테이트라고 불립니다.

복합상태의 내부구조는 임의로 복잡할 수 있기 때문에 계층적 상태기계는 어떤 (상위 수준의) 복합상태의 내부구조로 볼 수 있다.하나의 복합 상태를 상태 시스템 계층의 궁극적인 루트로 정의하는 것이 개념적으로 편리합니다.UML ^[1]사양에서는 모든 상태 머신은 상위 상태(모든 상태 머신 계층의 추상 루트)를 가지며, 여기에는 상태 머신 전체의 다른 모든 요소가 포함됩니다.이 모든 것을 포함하는 상단 상태의 그래픽 렌더링은 옵션입니다.

보시는 바와 같이 계층적 상태 분해의 의미는 동작의 재사용을 용이하게 하도록 설계되어 있습니다.서브스테이트(내포된 상태)는 슈퍼스테이트(포함 상태)와의 차이만 정의하면 됩니다.서브스테이트는 일반적으로 처리되는 이벤트를 무시하기만 하면 슈퍼스테이트에서 일반적인 동작을 쉽게^[6] 상속할 수 있습니다.이러한 이벤트는 상위 레벨의 스테이트에 의해 자동으로 처리됩니다.즉, 계층적 상태 중첩은 차이에 ^[9]의한 프로그래밍을 가능하게 합니다.

가장 자주 강조되는 국가 계층의 측면은 추상화이며, 이는 복잡성에 대처하기 위한 오래되고 강력한 기술이다.복잡한 시스템의 모든 측면에 동시에 대처하는 것이 아니라 시스템의 일부 부분을 무시(추출)하는 경우가 많습니다.계층 상태는 설계자가 중첩된 상태를 숨기거나 표시하기 위해 쉽게 축소 또는 축소할 수 있으므로 내부 세부 정보를 숨기기에 이상적인 메커니즘입니다.

그러나 복합 상태는 단순히 복잡성을 숨길 뿐만 아니라 계층적 이벤트 처리라는 강력한 메커니즘을 통해 복잡성을 적극적으로 줄입니다.이러한 재사용이 없으면 시스템의 복잡성이 다소 증가하더라도 상태 및 전환 수가 폭발적으로 증가할 수 있습니다.예를 들어 포켓계산기를 나타내는 계층형 상태기(그림3)는 거의 모든 상태에서 Clear 및 Off 전환을 반복하지 않는다.반복을 회피함으로써 HSM의 성장은 시스템의 복잡성 증가에 비례합니다.모델링된 시스템이 성장함에 따라 재사용 기회도 증가하므로 기존 FSM의 전형적인 상태 및 전환 수가 불균형적으로 증가하는 것을 잠재적으로 상쇄할 수 있습니다.

직교 영역

계층적 상태 분해에 의한 분석에는 임의의 상태에 대한 연산 'exclusive-OR' 적용을 포함할 수 있다.예를 들어, 시스템이 "on" 슈퍼 상태(그림 3)인 경우, 시스템이 "operand1" 서브스테이트 또는 "operand2" 서브스테이트 또는 "opered" 서브스테이트 또는 "result" 서브스테이트에 있을 수도 있습니다.이는 "on" 슈퍼 상태를 "OR 상태"로 기술하는 것으로 이어질 것이다.

또한 UML 상태 차트는 보완적인 AND 분해 기능을 도입합니다.이러한 분해는 복합 상태가 2개 이상의 직교 영역(이 문맥에서 호환성이 있고 독립적)을 포함할 수 있으며, 그러한 복합 상태에 있는 것이 모든 직교 영역에 ^[10]동시에 존재하는 것을 의미한다.

직교 영역은 시스템의 동작이 독립적이고 동시에 활성화된 부분으로 분할될 때 상태 수의 조합적 증가 문제를 해결합니다.예를 들어 메인 키패드와는 별도로 컴퓨터 키보드에는 독립된 숫자 키패드가 있습니다.이전 설명에서 이미 식별된 메인 키패드의 두 가지 상태, "default"와 "caps_locked"를 떠올립니다(그림 1 참조).숫자 키패드는 Num Lock의 활성화 여부에 따라 "numbers"와 "arrows"의 두 가지 상태일 수도 있습니다.따라서 표준 분해에서 키보드의 완전한 상태 공간은 2개의 컴포넌트(메인 키패드와 숫자 키패드)의 데카르트 곱이며 "default-numbers", "default-arrows", "caps_locked-numbers" 및 "caps_locked-arrows"의 4가지 상태로 구성됩니다.단, 숫자 키패드의 동작은 메인 키패드의 상태에 따라 달라지지 않기 때문에 이는 부자연스러운 표현입니다.직교 영역을 사용하면 그림 4와 같이 독립적인 동작이 데카르트 곱으로 혼합되는 것을 피할 수 있으며, 대신 분리되는 상태를 유지할 수 있다.

직교 영역이 서로 완전히 독립되어 있는 경우, 이들의 복합 복잡도는 단순히 가법적이기 때문에 시스템을 모델링하는 데 필요한 독립 상태의 수는 단순히 k + l + m + ...이라는 것을 의미합니다. 여기서 k, l, m, ...는 각 직교 영역의 OR 상태 수를 나타냅니다.그러나, 반면에, 상호의존성의 일반적인 경우는 곱셈 복잡성을 초래하므로, 일반적으로 필요한 상태의 수는 곱 k × l × m × ...이다.

대부분의 실제 상황에서 직교 영역은 거의 직교할 뿐이다(즉, 진정으로 독립적이지 않음).따라서 UML 상태 차트는 직교 영역이 동작을 통신하고 동기화할 수 있는 여러 방법을 제공합니다.이러한 풍부한(때로는 복잡한) 메커니즘 세트 중 가장 중요한 기능은 직교 영역이 서로 이벤트인스턴스를 전송함으로써 동작을 조정할 수 있다는 것입니다.

직교 영역은 실행의 독립성을 의미하지만(거의 동시성을 허용), UML 사양에서는 각 직교 영역에 별도의 실행 스레드를 할당할 필요가 없습니다(필요에 따라 실행할 수 있습니다).실제로 대부분의 경우 직교 영역은 동일한 ^[11]스레드 내에서 실행됩니다.UML 사양에서는 설계자가 이벤트인스턴스를 관련 직교 영역으로 디스패치하기 위한 특정 순서에 의존하지 않아야 합니다.

진입 및 종료 액션

UML 상태도 내의 모든 상태에는 상태 진입 시 실행되는 옵션 엔트리 액션과 상태를 종료할 때 실행되는 옵션 종료 액션이 있습니다.시작 및 종료 액션은 전환이 아닌 상태와 관련지어집니다.상태의 시작 또는 종료 방법에 관계없이 모든 시작 및 종료 액션이 실행됩니다.이 특성으로 인해 상태 차트는 무어 기계처럼 작동합니다.상태 진입 및 종료 액션의 UML 표기법은 이름 구획 바로 아래의 상태에 예약된 단어 "entry"(또는 "exit")를 배치한 후 슬래시 및 임의 액션 목록을 표시합니다(그림 5 참조).

진입 및 종료 액션의 가치는 객체 지향 프로그래밍의 클래스 컨스트럭터 및 소멸자와 마찬가지로 확실한 초기화 및 정리를 위한 수단을 제공한다는 것입니다.예를 들어, 도어가 열려 있는 동안 토스터 오븐의 동작에 해당하는 그림 5의 "door_open" 상태를 생각해 보십시오.이 상태에는 안전에 매우 중요한 요건이 있습니다.도어가 열려 있을 때는 항상 히터를 비활성화하십시오.또한 문이 열려 있는 동안에는 오븐을 비추는 내부 램프가 켜져야 합니다.

물론 이러한 동작은 "door_open" 상태로 이어지는 모든 전환 경로에 적절한 동작(히터 비활성화 및 조명 켜기)을 추가하여 모델링할 수 있습니다(사용자는 "베이킹" 또는 "토스트" 중 또는 오븐이 전혀 사용되지 않을 때 언제든지 문을 열 수 있습니다)."door_open" 상태가 될 때마다 내부 램프를 꺼야 합니다.그러나 그러한 해결책은 많은 전환에서 행동의 반복을 야기할 것이다.더 중요한 것은, 이러한 접근 방식은 이후의 동작 수정 과정에서 설계에 오류가 발생하기 쉽다는 것입니다(예를 들어, 상위 브라우징과 같은 새로운 기능에 대해 작업하는 다음 프로그래머는 단순히 "door_open"으로 전환될 때 히터를 비활성화하는 것을 잊어버릴 수 있습니다).

진입 및 종료 액션을 통해 원하는 동작을 보다 안전하고 단순하며 직관적인 방법으로 구현할 수 있습니다.그림 5와 같이, "난방"으로부터의 출구 작용은 히터를 무효화시키고, "door_open"으로의 진입 작용은 오븐 램프를 점등시키며, "door_open"으로부터의 출구 작용은 램프를 소등시키는 것을 지정할 수 있다.승하차 조치의 사용은 반복 코딩을 피하고 안전 위험을 제거하여 기능을 개선하므로 전환에 조치를 취하는 것보다 선호된다. (문이 열려 있는 동안 히터가 켜짐)종료 동작의 의미는 전환 경로에 관계없이 토스터가 "가열" 상태가 아닐 때 히터가 비활성화됨을 보장합니다.

엔트리 액션은 관련된 상태가 입력될 때마다 자동으로 실행되기 때문에 클래스 생성자가 생성 중인 객체의 ID를 결정하는 것과 마찬가지로 동작 조건이나 상태의 ID를 결정하는 경우가 많습니다.예를 들어 히터가 켜져 있다는 사실에 따라 가열 상태의 동일성이 결정됩니다."난방"의 서브스테이트에 들어가기 전에 이 조건을 확립해야 한다.왜냐하면 "토스트"와 같이 "난방"의 서브스테이트에 대한 진입 동작은 "난방" 슈퍼스테이트의 적절한 초기화에 의존하며 이 초기화와의 차이만 수행되기 때문이다.따라서 엔트리 액션의 실행 순서는 항상 가장 바깥쪽 상태에서 가장 안쪽 상태(하향식)로 진행되어야 합니다.

당연히 이 순서는 클래스 생성자가 호출되는 순서와 유사합니다.클래스 구축은 항상 클래스 계층의 바로 그 루트에서 시작하여 모든 상속 수준을 거쳐 인스턴스화되는 클래스까지 이어집니다.소멸자 호출에 해당하는 종료 액션의 실행은 정확한 역순서(상향식)로 진행됩니다.

내부 이행

매우 일반적으로 이벤트로 인해 일부 내부 작업만 수행되고 상태 변경(상태 전환)은 발생하지 않습니다.이 경우 실행되는 모든 액션은 내부 천이를 구성합니다.예를 들어 키보드로 입력하면 다른 문자 코드를 생성하여 응답합니다.단, Caps Lock 키를 누르지 않는 한 키보드 상태는 변경되지 않습니다(상태 전환은 발생하지 않습니다).UML에서는 이 상황을 그림 6과 같이 내부 천이를 사용하여 모델링해야 합니다.내부 전환의 UML 표기법은 종료(또는 입력) 액션에 사용되는 일반적인 구문을 따릅니다.단, 내부 전환에는 트리거 이벤트가 라벨로 표시됩니다(예: 그림 6의 ANY_KEY 이벤트에 의해 트리거된 내부 전환을 참조하십시오).

시작 및 종료 액션이 없는 경우 내부 천이는 자체 천이와 동일합니다(타깃 상태가 소스 상태와 동일한 천이).실제로 기존의 Maly 머신에서는 액션은 상태 천이와만 관련지어지기 때문에 상태를 변경하지 않고 액션을 실행할 수 있는 유일한 방법은 자가 천이를 사용하는 것입니다(이 문서의 선두에서 그림 1의 다이렉트루프로 정의).그러나 UML 상태 차트에서와 같이 진입 및 종료 액션이 존재하는 경우, 자가 전환은 종료 및 진입 액션을 실행하는 것과 관련되므로 내부 전환과는 확연히 다릅니다.

자기 전이와는 대조적으로 내부 천이가 현재 활성 상태보다 높은 계층 수준에서 상속되어도 내부 천이의 결과로서 진입 또는 종료 액션은 실행되지 않는다.모든 네스트레벨에서 슈퍼스타에서 상속된 내부 천이는 현재 활성 상태에서 직접 정의된 것처럼 동작합니다.

이행실행순서

상태 네스팅과 진입 및 종료 액션을 조합하면 기존의 FSM에 비해 HSM의 상태 전이 의미가 크게 복잡해집니다.계층적으로 중첩된 상태 및 직교 영역을 다룰 때 단순 용어 현재 상태는 상당히 혼란스러울 수 있습니다.HSM 에서는, 복수의 스테이트를 동시에 액티브하게 할 수 있습니다.상태 머신이 복합 상태(상위 복합 상태 등)에 포함되는 리프 상태일 경우 리프 상태를 직접 또는 과도적으로 포함하는 모든 복합 상태도 활성화됩니다.또한 이 계층의 일부 복합 상태가 직교 영역을 가질 수 있기 때문에 현재 활성 상태는 루트의 단일 최상위 상태에서 시작하여 잎의 개별 단순 상태에 이르기까지 실제로 상태의 트리로 표현됩니다.UML 사양은 상태 트리를 상태 ^[1]설정이라고 부릅니다.

UML 에서는, 스테이트의 천이에 의해서, 임의의 2개의 스테이트를 직접 접속할 수 있습니다.이 두 가지 상태는 복합적일 수 있으며, 전환의 주요 소스와 주요 타깃으로 지정됩니다.그림 7은 간단한 이행 예시와 이행 시의 상태 역할에 대해 설명합니다.UML 사양에서는 상태 천이를 실시하려면 다음 순서로 다음 액션을 수행해야 한다고 규정하고 있습니다(OMG Unified Modeling Language(OMG UML), 인프라스트럭처 버전 2.2의^[1] 섹션 15.3.14 참조).

1. 이행과 관련된 가드 조건을 평가하고 가드가 TRUE로 평가된 경우에만 다음 절차를 수행합니다.
2. 송신원스테이트 설정을 종료합니다.
3. 이행과 관련된 액션을 실행합니다.
4. 타겟 스테이트 설정을 입력합니다.

주 소스 및 주 타깃이 동일한 수준에 중첩된 단순한 경우 전환 시퀀스를 해석하기 쉽습니다.예를 들어, 그림 7에 나타낸 트랜지션 T1에 의해 가드 g()가 평가되고 이어서 일련의 액션이 발생합니다.a(); b(); t(); c(); d();그리고.e(); 경비원이g()TRUE로 평가합니다.

단, 상태 계층의 다른 레벨에 중첩된 소스 상태와 타깃 상태의 일반적인 경우 종료해야 하는 중첩 수준의 수가 즉시 명확하지 않을 수 있습니다.UML 사양에서는^[1], 현재의 액티브 상태(메인 소스 상태의 직접적 또는 전이적 서브 스테이트일 가능성이 있음)로부터, 메인 소스 및 메인 타겟 상태의 최소 공통 조상(LCA) 상태(포함하지 않음)까지, 모든 중첩 상태를 종료하는 것을 규정하고 있습니다.이름에서 알 수 있듯이 LCA는 송신원 및 타깃스테이트 양쪽의 슈퍼스테이트(조상)인 가장 낮은 복합스테이트입니다.앞에서 설명한 바와 같이 종료 액션의 실행 순서는 항상 가장 깊이 중첩된 상태(현재 활성 상태)에서 LCA에 대한 계층 위쪽으로 올라가지만 LCA를 종료하지 않습니다.예를 들어 그림 7에 나타낸 상태 "s1"과 "s2"의 LCA(s1,s2)는 상태 "s"입니다.

타겟 스테이트 설정의 입력은, 종료 액션이 중단된 레벨로부터 개시됩니다(즉, LCA 내부로부터).앞에서 설명한 바와 같이 엔트리 액션은 상태 계층에서 주 타깃 상태로 가장 높은 레벨의 상태부터 실행해야 합니다.메인 타깃 상태가 복합인 경우 UML 시멘틱스는 로컬 초기 전환을 사용하여 반복적으로 서브머신에 "드릴"하도록 규정합니다.타겟 스테이트의 설정은, 초기 천이가 없는 리프 스테이트가 발생한 후에만 완전하게 개시됩니다.

로컬과 외부로의 이행

UML ^[1]2 이전에 사용된 유일한 전환 의미론은 외부 전환이었습니다. 이 경우 전환의 주 소스가 항상 종료되고 전환의 주 대상이 항상 입력됩니다.UML 2는 하위 호환성을 위해 "외부 전환" 시멘틱스를 유지하면서도 로컬 전환이라는 새로운 종류의 전환을 도입했습니다(UML (Unified Modeling Language), 인프라 버전 2.2 섹션^[1] 15.3.15 참조).많은 이행 토폴로지에서 외부 이행과 로컬 이행은 실제로 동일합니다.단, 메인 타깃 상태가 메인소스의 서브스테이트인 경우 로컬 천이로 인해 메인소스 상태로부터의 출구와 메인소스 상태로의 재진입은 발생하지 않습니다.또, 메인 타겟이 메인 소스 스테이트의 슈퍼 스테이트인 경우, 로컬 상태의 이행에 의해서, 메인 타겟 스테이트로부터의 출구와 메인 타겟 스테이트로의 재진입이 발생하지 않습니다.

그림 8은 국소(a)와 외부(b)의 천이를 대비시킨다.맨 위 행에는 주 표적이 들어 있는 주 소스 케이스가 표시됩니다.로컬 천이에 의해 소스로부터의 출구는 발생하지 않지만 외부 천이에 의해 소스로의 출구와 재엔트리가 발생합니다.그림 8의 맨 아래 행에는 메인 소스를 포함하는 메인 타깃의 케이스가 표시됩니다.로컬 천이에서는 타겟으로의 엔트리는 발생하지 않지만 외부 천이에서는 타깃으로의 종료와 재엔트리가 발생합니다.

이벤트 연기

스테이트 머신이 이벤트를 처리할 수 없는 상태일 때 이벤트가 특히 불편한 시간에 도착할 수 있습니다.대부분의 경우 이벤트의 특성은 시스템이 원래 이벤트를 처리할 준비가 더 잘 되어 있는 다른 상태가 될 때까지(제한 범위 내에서) 연기될 수 있습니다.

UML 스테이트 머신은 스테이트의 이벤트를 지연시키기 위한 특별한 메커니즘을 제공합니다.모든 주에 절을 포함할 수 있습니다.[event list]/defer현재 상태의 지연 이벤트 목록에서 이벤트가 발생한 경우 지연 이벤트 목록에 이벤트를 나열하지 않는 상태가 입력될 때까지 이후 처리를 위해 이벤트가 저장(연기)됩니다.이러한 상태가 되면 UML 스테이트 머신은 지연되지 않게 된 저장된 이벤트를 자동으로 호출하여 이러한 이벤트를 소비하거나 폐기합니다.슈퍼스테이트는 서브스테이트에 의해 지연된 이벤트에 대해 정의된 천이를 가질 수 있습니다.UML 스테이트 머신의 사양의 다른 영역과 일관되게, 서브스테이트가 슈퍼스테이트보다 우선하며, 이벤트는 지연되고 슈퍼스테이트로의 이행은 실행되지 않습니다.하나의 직교 영역이 이벤트를 지연시키고 다른 영역이 이벤트를 소비하는 직교 영역의 경우 소비자가 우선하며 이벤트가 소비되고 지연되지 않습니다.

UML 스테이트 머신의 제한

UML 상태 기계의 선구자인 Harel 상태 차트는 "복잡한 시스템을 위한 시각적 형식주의"^[2]로 발명되었기 때문에 초기부터 상태 다이어그램 형태의 그래픽 표현과 분리할 수 없이 연관되어 왔다.단, UML 상태 머신의 개념은 그래픽 또는 텍스트의 특정 표기법을 초월한다는 것을 이해하는 것이 중요합니다.UML 사양에서는^[1] 스테이트 머신의 의미와 표기법을 명확하게 분리함으로써 이 차이를 명확하게 하고 있습니다.

그러나 UML 상태 차트의 표기법은 완전히 시각적인 것은 아니다.중요하지 않은 상태 머신에는 대량의 텍스트 정보(예: 액션 및 가드 지정)가 필요합니다.UML 사양에는 액션과 가드 표현의 정확한 구문이 정의되어 있지 않기 때문에 많은 사람들이 구조화된 영어 또는 C, C++, Java ^[12]등의 구현 언어로 표현식을 사용합니다.실제로는 UML 상태도 표기법이 특정 프로그래밍 언어에 크게 의존한다는 것을 의미합니다.

그럼에도 불구하고, 대부분의 상태 차트 의미론들은 그래픽 표기법에 크게 치우쳐 있다.예를 들어, 상태 다이어그램은 가드 평가 순서나 직교 영역에 이벤트를 보내는 순서 등 처리 순서를 제대로 나타내지 못합니다.UML 사양에서는 설계자에게 특정 시퀀스에 의존하지 않도록 하는 부담을 줌으로써 이러한 문제를 회피하고 있습니다.그러나 실제로 UML 상태 머신이 구현되면 실행 순서에 대한 완전한 제어가 불가피하게 이루어지기 때문에 UML 시멘틱스가 불필요하게 제한될 수 있다는 지적이 제기됩니다.마찬가지로 상태 차트 다이어그램에서는 제어 흐름을 그래픽으로 표현하기 위해 많은 배관 장비(조인트, 포크, 접합부, 선택점 등)가 필요합니다.즉, 그래픽 표기법의 이러한 요소는 일반 구조화된 코드에 비해 제어 흐름을 나타내는 데 큰 가치를 추가하지 않습니다.

UML 표기법과 의미론은 실제로 컴퓨터화된 UML 도구에 맞춰져 있습니다.UML 스테이트 머신은 툴로 표현되는 상태 다이어그램뿐만 아니라 상태 토폴로지와 액션을 모두 정확하게 캡처하는 그래픽과 텍스트 표현의 혼합입니다.생성된 코드는 사용 가능한 많은 보기 중 하나에 불과하지만 툴 사용자는 동일한 상태 머신의 여러 보완 뷰를 시각적으로나 텍스트적으로나 얻을 수 있습니다.

「 」를 참조해 주세요.

계층형 유한 상태 머신 전용 지원을 제공하는 소프트웨어 응용 프로그램 목록

레퍼런스

외부 링크

• 오브젝트 관리 그룹(OMG)별 현재 UML 사양
• UML 2 스테이트 머신 다이어그램