| <html><head> | |
| <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | |
| <title>Concepts</title><link rel="stylesheet" href="boostbook.css" type="text/css"><meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.2"><link rel="home" href="index.html" title="Meta State Machine (MSM) V2.12"><link rel="up" href="ch02.html" title="Chapter 2. UML Short Guide"><link rel="prev" href="ch02.html" title="Chapter 2. UML Short Guide"><link rel="next" href="ch02s03.html" title="State machine glossary"></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">Concepts</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02.html">Prev</a> </td><th width="60%" align="center">Chapter 2. UML Short Guide</th><td width="20%" align="right"> <a accesskey="n" href="ch02s03.html">Next</a></td></tr></table><hr></div><div class="sect1" title="Concepts"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e206"></a>Concepts</h2></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><div class="sect2" title="State machine, state, transition, event"><div class="titlepage"><div><div><h3 class="title"><a name="d0e211"></a>State machine, state, transition, event </h3></div></div></div><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 deferred events. One can provide entry and exit behaviors | |
| (also called actions) 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 behavior 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 fired. </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 executes when the transition fires, the guard is a Boolean operation | |
| executed first and which can prevent the transition from firing by 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="sect2" title="Submachines, orthogonal regions, pseudostates"><div class="titlepage"><div><div><h3 class="title"><a name="d0e241"></a>Submachines, orthogonal regions, pseudostates </h3></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 submachine 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" width="60%"></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" width="60%"></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 submachine (apart the obvious and | |
| more common case of a transition terminating on the submachine 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. An explicit exit is a transition | |
| from an inner state to a state outside the submachine (not supported by | |
| MSM). I would not recommend using explicit entry or exit. </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" width="70%"></span></p></div><div class="sect2" title="History"><div class="titlepage"><div><div><h3 class="title"><a name="d0e284"></a> | |
| <span class="command"><strong><a name="uml-history"></a></strong></span>History </h3></div></div></div><p>UML defines two kinds of history, shallow history and deep history. | |
| Shallow history is a pseudo state representing the most recent substate of a | |
| submachine. A submachine 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" width="60%"></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 this useful concept. </p></div><div class="sect2" title="Completion transitions / anonymous transitions"><div class="titlepage"><div><div><h3 class="title"><a name="d0e298"></a><span class="command"><strong><a name="uml-anonymous"></a></strong></span>Completion transitions / anonymous | |
| transitions</h3></div></div></div><p>Completion events (or transitions), 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 making it easier 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 tasks | |
| 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="sect2" title="Internal transitions"><div class="titlepage"><div><div><h3 class="title"><a name="d0e310"></a><span class="command"><strong><a name="UML-internal-transition"></a></strong></span> Internal transitions </h3></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="sect2" title="Conflicting transitions"><div class="titlepage"><div><div><h3 class="title"><a name="d0e316"></a> | |
| <span class="command"><strong><a name="transition-conflict"></a></strong></span>Conflicting transitions </h3></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" width="60%"></span></p><p>MSM handles both 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="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch02s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 2. UML Short Guide </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> State machine glossary</td></tr></table></div></body></html> |