mirror of
https://github.com/boostorg/msm.git
synced 2026-02-19 02:22:17 +00:00
122 lines
18 KiB
HTML
122 lines
18 KiB
HTML
<html><head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
|
<title>UML Short Guide</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.2"><link rel="home" href="index.html" title="Meta State Machine (MSM)"><link rel="up" href="index.html" title="Meta State Machine (MSM)"><link rel="prev" href="ar01s02.html" title="Founding idea"><link rel="next" href="ar01s04.html" title="User's Guide"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">UML Short Guide</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ar01s02.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ar01s04.html">Next</a></td></tr></table><hr></div><div class="sect1" title="UML Short Guide"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e198"></a>UML Short Guide</h2></div></div></div><div class="sect2" title="What are state machines?"><div class="titlepage"><div><div><h3 class="title"><a name="d0e201"></a>What are state machines?</h3></div></div></div><p>State machines are the description of the lifeline of a thing. They describe the
|
|
different stages of the lifeline, the events influencing it, and what it does when a
|
|
particular event is detected at a particular stage. They offer the complete
|
|
specification of the dynamic behavior of the thing.</p></div><div class="sect2" title="Concepts"><div class="titlepage"><div><div><h3 class="title"><a name="d0e206"></a>Concepts</h3></div></div></div><div class="sect3" title="State machine, state, transition, event"><div class="titlepage"><div><div><h4 class="title"><a name="d0e209"></a>State machine, state, transition, event </h4></div></div></div><p>Thinking in terms of state machines is a bit surprising at first, so let us
|
|
have a quick glance at the concepts.</p><p>A state machine is a concrete model describing the behavior of a system. It is
|
|
composed of a finite number of states and transitions.</p><p>
|
|
<span class="inlinemediaobject"><img src="../images/sm.gif"></span></p><p>A simple state has no sub states. It can have data, entry and exit behaviors
|
|
and deferrable events. One can add entry and exit conditions to states (or state
|
|
machines), which are executed whenever a state is entered or left, no matter
|
|
how. A state can also have internal transitions which cause no entry or exit
|
|
action to be called. A state can mark events as deferred. This means the event
|
|
cannot be processed if this state is active, but it must be retained. Next time
|
|
a state not deferring this event is active, the event will be processed, as if
|
|
it had just been detected. </p><p><span class="inlinemediaobject"><img src="../images/state.gif"></span></p><p>A transition is the switching between active states, triggered by an event.
|
|
Actions and guard conditions can be attached to the transition. The action is
|
|
executes when the transition fires, the guard is a Boolean operation executed
|
|
first and which can prevent the transition from firing if returning
|
|
false.</p><p>
|
|
<span class="inlinemediaobject"><img src="../images/transition.jpg"></span></p><p>An initial state marks the first active state of a state machine. It has no
|
|
real existence and neither has the transition originating from it.</p><p>
|
|
<span class="inlinemediaobject"><img src="../images/init_state.gif"></span></p></div><div class="sect3" title="Submachines, orthogonal regions, pseudostates"><div class="titlepage"><div><div><h4 class="title"><a name="d0e241"></a>Submachines, orthogonal regions, pseudostates </h4></div></div></div><p>A composite state is a state containing a region or decomposed in two or more
|
|
regions. A composite state contains its own set of states and regions. </p><p>A submachine is a state machine inserted as a state in another state machine.
|
|
The same state machine can be inserted more than once. </p><p>Orthogonal regions are parts of a composite state or submachine, each having
|
|
its own set of mutually exclusive set of states and transitions. </p><p><span class="inlinemediaobject"><img src="../images/regions.gif"></span></p><p>UML also defines a number of pseudo states, which are considered important
|
|
concepts to model, but not enough to make them first-class citizens. The
|
|
terminate pseudo state terminates the execution of a state machine (MSM handles
|
|
this slightly differently. The state machine is not destroyed but no further
|
|
event processing occurs.). </p><p><span class="inlinemediaobject"><img src="../images/terminate.gif"></span></p><p>An exit point pseudo state exits a composite state or a submachine and forces
|
|
termination of execution in all contained regions.</p><p><span class="inlinemediaobject"><img src="../images/exit.gif"></span></p><p>An entry point pseudo state allows a kind of controlled entry inside a
|
|
composite. Precisely, it connects a transition outside the composite to a
|
|
transition inside the composite. An important point is that this mechanism only
|
|
allows a single region to be entered. In the above diagram, in region1, the
|
|
initial state would become active. </p><p><span class="inlinemediaobject"><img src="../images/entry_point.gif"></span></p><p>There are also two more ways to enter a composite state (apart the obvious and
|
|
more common case of a transition terminating on the composite as shown in the
|
|
region case). An explicit entry means that an inside state is the target of a
|
|
transition. Unlike with direct entry, no tentative encapsulation is made, and
|
|
only one transition is executed. Needless to say, I would not recommend using
|
|
this. </p><p><span class="inlinemediaobject"><img src="../images/explicit.gif"></span></p><p>The last entry possibility is using fork. A fork is an explicit entry into one
|
|
or more regions. Other regions are again activated using their initial state. </p><p><span class="inlinemediaobject"><img src="../images/fork.gif"></span></p></div><div class="sect3" title="History"><div class="titlepage"><div><div><h4 class="title"><a name="d0e284"></a>
|
|
<span class="command"><strong><a name="uml-history"></a></strong></span>History </h4></div></div></div><p>UML defines two sorts of history, shallow history and deep history. Shallow
|
|
history is a pseudo state representing the most recent substate of a composite
|
|
or submachine. A composite can have at most one shallow history. A transition
|
|
with a history pseudo state as target is equivalent to a transition with the
|
|
most recent substate as target. And very importantly, only one transition may
|
|
originate from the history. Deep history is a shallow history recursively
|
|
reactivating the substates of the most recent substate. It is represented like
|
|
the shallow history with a star (H* inside a circle).</p><p>
|
|
<span class="inlinemediaobject"><img src="../images/history.gif"></span></p><p>History is not a completely satisfying concept. First of all, there can be
|
|
just one history pseudo state and only one transition may originate from it. So
|
|
they do not mix well with orthogonal regions as only one region can be
|
|
“remembered”. Deep history is even worse and looks like a last-minute addition.
|
|
History has to be activated by a transition and only one transition originates
|
|
from it, so how to model the transition originating from the deep history pseudo
|
|
state and pointing to the most recent substate of the substate? As a bonus, it
|
|
is also inflexible and does not accept new types of histories. Let's face it,
|
|
history sounds great and is useful in theory, but the UML version is not quite
|
|
making the cut. And therefore, MSM provides a different version of it. </p></div><div class="sect3" title="Completion events / anonymous transitions"><div class="titlepage"><div><div><h4 class="title"><a name="d0e298"></a><span class="command"><strong><a name="uml-anonymous"></a></strong></span>Completion events / anonymous
|
|
transitions</h4></div></div></div><p>Completion events, also called anonymous transitions, are defined as
|
|
transitions having no defined event triggering them. This means that such
|
|
transitions will immediately fire when a state being the source of an anonymous
|
|
transition becomes active, provided that a guard allows it. They are useful in
|
|
modeling algorithms as an activity diagram would normally do. In the real-time
|
|
world, they have the advantage of being able to estimate how long a periodically
|
|
executed action will last. For example, consider the following diagram. </p><p><span class="inlinemediaobject"><img src="../images/completion.gif"></span></p><p>The designer now knows at any time that he will need a maximum of 4
|
|
transitions. Being able to estimate how long a transition takes, he can estimate
|
|
how much of a time frame he will need to require (real-time applications are
|
|
often executed at regular intervals). If he can also estimate the duration of
|
|
actions, he can even use graph algorithms to better estimate his timing
|
|
requirements. </p></div><div class="sect3" title="Internal transitions"><div class="titlepage"><div><div><h4 class="title"><a name="d0e310"></a><span class="command"><strong><a name="UML-internal-transition"></a></strong></span> Internal transitions </h4></div></div></div><p>Internal transitions are transitions executing in the scope of the active
|
|
state, being a simple state or a submachine. One can see them as a
|
|
self-transition of this state, without an entry or exit action called.</p></div><div class="sect3" title="Conflicting transitions"><div class="titlepage"><div><div><h4 class="title"><a name="d0e316"></a>
|
|
<span class="command"><strong><a name="transition-conflict"></a></strong></span>Conflicting transitions </h4></div></div></div><p>If, for a given event, several transitions are enabled, they are said to be in
|
|
conflict. There are two kinds of conflicts: </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>For a given source state, several transitions are defined,
|
|
triggered by the same event. Normally, the guard condition in each
|
|
transition defines which one is fired.</p></li><li class="listitem"><p>The source state is a submachine or simple state and the conflict
|
|
is between a transition internal to this state and a transition
|
|
triggered by the same event and having as target another
|
|
state.</p></li></ul></div><p>The first one is simple; one only needs to define two or more
|
|
rows in the transition table, with the same source and trigger, with a different
|
|
guard condition. Beware, however, that the UML standard wants these conditions
|
|
to be not overlapping. If they do, the standard says nothing except that this is
|
|
incorrect, so the implementer is free to implement it the way he sees fit. In
|
|
the case of MSM, the transition appearing last in the transition table gets
|
|
selected first, if it returns false (meaning disabled), the library tries with
|
|
the previous one, and so on.</p><p>
|
|
<span class="inlinemediaobject"><img src="../images/conflict1.gif"></span></p><p>In the second case, UML defines that the most inner transition gets selected
|
|
first, which makes sense, otherwise no exit point pseudo state would be possible
|
|
(the inner transition brings us to the exit point, from where the containing
|
|
state machine can take over). </p><p><span class="inlinemediaobject"><img src="../images/conflict2.gif"></span></p><p>Msm handles all these cases itself, so the designer needs only concentrate on
|
|
its state machine and the UML subtleties (not overlapping conditions), not on
|
|
implementing this behavior himself. </p></div></div><div class="sect2" title="State machine glossary"><div class="titlepage"><div><div><h3 class="title"><a name="d0e344"></a>State machine glossary</h3></div></div></div><p>
|
|
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>state machine: the lifecycle of a thing. It is made of states,
|
|
regions, transitions and processes incoming events.</p></li><li class="listitem"><p>state: a stage in the lifecycle of a state machine. A state (like a
|
|
submachine) can have an entry and exit action.</p></li><li class="listitem"><p>event: an incident provoking (or not) a reaction of the state
|
|
machine</p></li><li class="listitem"><p>transition: a specification of how a state machine reacts to an event.
|
|
It specifies a source state, the event triggering the transition, the
|
|
target state (which will become the newly active state if the transition
|
|
is triggered), guard and actions.</p></li><li class="listitem"><p>action: an operation executed during the triggering of the
|
|
transition.</p></li><li class="listitem"><p>guard: a boolean operation being able to prevent the triggering of a
|
|
transition which would otherwise fire.</p></li><li class="listitem"><p>transition table: representation of a state machine. A state machine
|
|
diagram is another but incomplete representation of the same
|
|
model.</p></li><li class="listitem"><p>initial state: The state in which the state machine starts. Having
|
|
several orthogonal regions means having as many initial states.</p></li><li class="listitem"><p>composite / submachine: A composite state is a state which is itself a
|
|
state machine. A submachine is an instance of a composite state and can
|
|
be found several times in a same state machine.</p></li><li class="listitem"><p>orthogonal regions: (logically) parallel flow of execution of a state
|
|
machine. Every region of a state machine gets a chance to process an
|
|
incoming event.</p></li><li class="listitem"><p>terminate pseudo-state: when this state becomes active, it terminates
|
|
the execution of the whole state machine.</p></li><li class="listitem"><p>entry/exit pseudo state: defined for composites / submachines and are
|
|
defined as a connection between a transition outside of the composite
|
|
and a transition inside the composite. It is a way to enter or leave a
|
|
submachine through a predefined point.</p></li><li class="listitem"><p>fork: a fork allows explicit entry into several orthogonal regions of
|
|
a submachine.</p></li><li class="listitem"><p>history: a history is a way to remember the active state of a
|
|
submachine so that the submachine can proceed in its last state next
|
|
time it becomes active.</p></li><li class="listitem"><p>completion events (also called completion transitions): when a
|
|
transition has no named event triggering it, it automatically fires when
|
|
the source state is active, unless a guard forbids it.</p></li><li class="listitem"><p>transition conflict: a conflict is present if for a given source state
|
|
and incoming event, several transitions are possible. UML specifies that
|
|
guard conditions have to solve the conflict.</p></li><li class="listitem"><p>internal transitions: transition from a state to itself without having
|
|
exit and entry actions being called.</p></li></ul></div><p>
|
|
</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ar01s02.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ar01s04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Founding idea </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> User's Guide</td></tr></table></div></body></html> |