]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
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> | |
132 | struct EvButtonPressed : Event // node | |
133 | { | |
134 | /* common button pressed properties */ | |
135 | }; | |
136 | ||
137 | struct EvPlayButtonPressed : EvButtonPressed {}; // leaf | |
138 | struct EvStopButtonPressed : EvButtonPressed {}; // leaf | |
139 | struct 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> |