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