1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 2 3<html> 4<head> 5 <meta http-equiv="Content-Language" content="en-us"> 6 <meta name="GENERATOR" content="Microsoft FrontPage 6.0"> 7 <meta name="ProgId" content="FrontPage.Editor.Document"> 8 <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> 9 <link rel="stylesheet" type="text/css" href="../../../boost.css"> 10 11 <title>The Boost Statechart Library - Definitions</title> 12</head> 13 14<body link="#0000FF" vlink="#800080"> 15 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary= 16 "header"> 17 <tr> 18 <td valign="top" width="300"> 19 <h3><a href="../../../index.htm"><img alt="C++ Boost" src= 20 "../../../boost.png" border="0" width="277" height="86"></a></h3> 21 </td> 22 23 <td valign="top"> 24 <h1 align="center">The Boost Statechart Library</h1> 25 26 <h2 align="center">Definitions</h2> 27 </td> 28 </tr> 29 </table> 30 <hr> 31 32 <h2>Introduction</h2> 33 34 <p>The Boost.Statechart documentation uses a lot of terminology specific to 35 state machines. Most of it is equal to the one used in the UML 36 specifications. This document contains only definitions for terminology not 37 used by the <a href="http://www.omg.org/cgi-bin/doc?formal/03-03-01">UML 38 standard</a>. A short tour around UML terminology can be found <a href= 39 "http://www.sts.tu-harburg.de/teaching/ws-99.00/OOA+D/StateDiagrams.pdf">here</a>.</p> 40 41 <h2>Definitions</h2> 42 43 <dl class="page-index"> 44 <dt><a href="#Context">Context</a></dt> 45 46 <dt><a href="#InnermostCommonContext">Innermost common context</a></dt> 47 48 <dt><a href="#InnermostState">Innermost state</a></dt> 49 50 <dt><a href="#InStateReaction">In-state reaction</a></dt> 51 52 <dt><a href="#OutermostState">Outermost state</a></dt> 53 54 <dt><a href="#PolymorphicEvents">Polymorphic events</a></dt> 55 56 <dt><a href="#Reaction">Reaction</a></dt> 57 58 <dt><a href="#UnstableState">Unstable state</a></dt> 59 60 <dt><a href="#UnstableStateMachine">Unstable state machine</a></dt> 61 </dl> 62 63 <h3><a name="Context" id="Context">Context</a></h3> 64 65 <p>The contexts of a state define its location in the state hierarchy. A 66 state's <b>direct</b> context is defined by what is passed as the 67 <code>Context</code> template parameter of the <code><a href= 68 "reference.html#ClassTemplatesimple_state">simple_state</a></code> and 69 <code><a href="reference.html#ClassTemplatestate">state</a></code> class 70 templates. This can either be the state machine (which makes the state an 71 <a href="#OutermostState">outermost state</a>) or its direct outer state. A 72 state's <b>indirect</b> contexts follow from the direct context of its 73 direct context and the direct context of the direct context of its direct 74 context and so on. Examples:</p> 75 76 <p><img alt="OutermostUnstableState" src="OutermostUnstableState.gif" 77 border="0" width="467" height="572"></p> 78 79 <ul> 80 <li>A's <b>direct</b> context is the state machine (not visible in this 81 picture). A does not have any indirect contexts</li> 82 83 <li>B's <b>direct</b> context is A. B's <b>indirect</b> context is the 84 state machine (not visible in this picture)</li> 85 86 <li>C's <b>direct</b> context is B. C's <b>indirect</b> contexts are B, A 87 and the state machine (not visible in this picture)</li> 88 89 <li>D's <b>direct</b> context is A. D's <b>indirect</b> context is the 90 state machine (not visible in this picture)</li> 91 </ul> 92 93 <h3><a name="InnermostCommonContext" id="InnermostCommonContext">Innermost 94 common context</a></h3> 95 96 <p>The innermost common context of two states is the first direct or 97 indirect context that both states have in common. Also known as Least 98 Common Ancestor (UML).</p> 99 100 <h3><a name="InnermostState" id="InnermostState">Innermost state</a></h3> 101 102 <p>An innermost state is a state that does not itself have inner states. 103 Also known as leaf state or simple state (UML). Note that <code><a href= 104 "reference.html#ClassTemplatesimple_state">boost::statechart::simple_state<></a></code> 105 is <b>not</b> a model of the UML simple state.</p> 106 107 <h3><a name="InStateReaction" id="InStateReaction">In-state 108 reaction</a></h3> 109 110 <p>An in-state reaction is a <a href="#Reaction">reaction</a> that neither 111 exits nor enters any states. Also known as inner transition or internal 112 transition (UML).</p> 113 114 <h3><a name="OutermostState" id="OutermostState">Outermost state</a></h3> 115 116 <p>An outermost state is a state that does not itself have outer states. 117 Note that an outermost state is different from the UML top state. A state 118 machine can have an arbitrary number of the former but only exactly one of 119 the latter. Boost.Statechart only supports outermost states.</p> 120 121 <h3><a name="PolymorphicEvents" id="PolymorphicEvents">Polymorphic 122 events</a></h3> 123 124 <p>An FSM library supports polymorphic events if events can inherit from 125 each other without restrictions <b>and</b> if it allows the definition of 126 reactions for leafs and nodes of the resulting event inheritance 127 tree.</p> 128 129 <p>Example (using a hypothetical FSM library, as Boost.Statechart does not 130 support polymorphic events):</p> 131 <pre> 132struct EvButtonPressed : Event // node 133{ 134 /* common button pressed properties */ 135}; 136 137struct EvPlayButtonPressed : EvButtonPressed {}; // leaf 138struct EvStopButtonPressed : EvButtonPressed {}; // leaf 139struct EvForwardButtonPressed : EvButtonPressed {}; // leaf 140</pre> 141 142 <p>If a state machine needs to react whenever <b>any</b> button (including 143 the ones that may be added in the future) is pressed, a reaction for 144 <code>EvButtonPressed</code> can be defined.</p> 145 146 <h3><a name="Reaction" id="Reaction">Reaction</a></h3> 147 148 <p>A reaction consists of all the side effects caused by the processing of 149 one event. Reactions can be categorized as follows:</p> 150 151 <ol> 152 <li>In-state reaction</li> 153 154 <li>Event deferral</li> 155 156 <li>Transition</li> 157 158 <li>Termination, also known as transition to the final state (UML)</li> 159 </ol> 160 161 <p>Note that it is possible to mix a reaction of type 1 with one of the 162 other types (the in-state reaction is always executed first) but it is not 163 possible to mix a reaction of type 2-4 with anything else but type 1.</p> 164 165 <p>A reaction is always associated with exactly one state type and exactly 166 one event type.</p> 167 168 <h3><a name="UnstableState" id="UnstableState">Unstable state</a></h3> 169 170 <p>A state is unstable from the moment when it has been entered until after 171 its last <b>direct</b> inner state has been entered. A state is also 172 unstable from the moment just before its first <b>direct</b> inner state is 173 exited until right before the state itself is exited.</p> 174 175 <h3><a name="UnstableStateMachine" id="UnstableStateMachine">Unstable state 176 machine</a></h3> 177 178 <p>A state machine is unstable if at least one of its currently active 179 states is unstable. This is the case during the following three 180 operations:</p> 181 182 <ul> 183 <li>Initiation: From the moment after the first state has been entered 184 until after the last state of the initial state configuration has been 185 entered</li> 186 187 <li>Transition: From the moment just before the first state of the 188 current state configuration is exited until after the last state of the 189 destination state configuration has been entered</li> 190 191 <li>Termination: From the moment just before the first state is exited 192 until right before the last terminated state is exited. A successfully 193 executed termination (no exception was thrown) never leaves any states 194 unstable. For example, consider the active state A with two orthogonal 195 regions in which the inner states B and C are each active. Terminating 196 either B or C does not make A unstable. Neither does terminating both, as 197 that inevitably also terminates A</li> 198 </ul> 199 200 <p>Under normal circumstances a state machine has Run-To-Completion 201 semantics, that is, it is always stable before the machine returns to the 202 client or before the next event is dequeued. So, a state machine is usually 203 only unstable when it is busy processing an event and becomes stable again 204 right before it has finished processing the event. However, this can not be 205 guaranteed when entry, exit or transition actions fail. Such a failure is 206 reported by an event, which must be processed while the state machine is 207 unstable. However, exception event processing rules ensure that a state 208 machine is never unstable when it returns to the client (see <code><a href= 209 "reference.html#process_event">state_machine<>::process_event()</a></code> 210 for details).</p> 211 <hr> 212 213 <p><a href="http://validator.w3.org/check?uri=referer"><img border="0" src= 214 "../../../doc/images/valid-html401.png" alt="Valid HTML 4.01 Transitional" 215 height="31" width="88"></a></p> 216 217 <p>Revised 218 <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->29 December, 2006<!--webbot bot="Timestamp" endspan i-checksum="38526" --></p> 219 220 <p><i>Copyright © 2003-<!--webbot bot="Timestamp" s-type="EDITED" s-format="%Y" startspan -->2006<!--webbot bot="Timestamp" endspan i-checksum="770" --> 221 <a href="contact.html">Andreas Huber Dönni</a></i></p> 222 223 <p><i>Distributed under the Boost Software License, Version 1.0. (See 224 accompanying file <a href="../../../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or 225 copy at <a href= 226 "http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</i></p> 227</body> 228</html> 229
