mirror of
https://github.com/boostorg/statechart.git
synced 2026-01-22 17:52:16 +00:00
133 lines
6.5 KiB
HTML
133 lines
6.5 KiB
HTML
<html>
|
|
|
|
<head>
|
|
<meta http-equiv="Content-Language" content="en-us">
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link rel="stylesheet" type="text/css" href="../../../boost.css">
|
|
<title>The boost::fsm 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="../../../c++boost.gif" border="0" width="277" height="86"></a></h3>
|
|
</td>
|
|
<td valign="top">
|
|
<h1 align="center">The boost::fsm library</h1>
|
|
<h2 align="center">Definitions</h2>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<hr>
|
|
<h2>Introduction</h2>
|
|
<p>The boost::fsm 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 UML.</p>
|
|
<h2>Definitions</h2>
|
|
<dl class="page-index">
|
|
<dt><a href="#Context">Context</a></dt>
|
|
<dt><a href="#Innermost common outer state">Innermost common outer state</a></dt>
|
|
<dt><a href="#Innermost state">Innermost state</a></dt>
|
|
<dt><a href="#In-state reaction">In-state reaction</a></dt>
|
|
<dt><a href="#Outermost state">Outermost state</a></dt>
|
|
<dt><a href="#Polymorphic events">Polymorphic events</a></dt>
|
|
<dt><a href="#Reaction">Reaction</a></dt>
|
|
<dt><a href="#Unstable state">Unstable state</a></dt>
|
|
<dt><a href="#Unstable state machine">Unstable state machine</a></dt>
|
|
</dl>
|
|
<h3><a name="Context">Context</a></h3>
|
|
<p>The direct context of a state is either its outer state or the state
|
|
machine. In the latter case the state is an outermost state.</p>
|
|
<h3><a name="Innermost common outer state">Innermost common outer state</a></h3>
|
|
<p>The innermost common outer state of two states is the first direct or
|
|
indirect outer state that both states have in common. Also known as Least
|
|
Common Ancestor (UML).</p>
|
|
<h3><a name="Innermost state">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>
|
|
boost::fsm::simple_state</code> is <b>not</b> a model of the UML simple state.</p>
|
|
<h3><a name="In-state reaction">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="Outermost state">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 a UML top state. A state machine can
|
|
have an arbitrary number of the former but only exactly one of the latter.
|
|
boost::fsm only supports outermost states.</p>
|
|
<h3><a name="Polymorphic events">Polymorphic events</a></h3>
|
|
<p>An FSM library supports polymorphic events if events can inherit from each
|
|
other without restrictions <b>and</b> allows the definition of reactions for
|
|
leafs <b>and</b> nodes of the resulting event inheritance tree.</p>
|
|
<p>Example (using a hypothetical fsm library, as boost::fsm 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">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="Unstable state">Unstable state</a></h3>
|
|
<p>A state is unstable from the moment when it has been entered until just
|
|
before its last direct inner state is entered.</p>
|
|
<h3><a name="Unstable state machine">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
|
|
right before the last state of the initial state configuration is entered</li>
|
|
<li>Transition: From the moment after the first state has been exited until
|
|
right before the last state is entered</li>
|
|
<li>Termination: From the moment after the first state has been exited until
|
|
right before the last state is exited</li>
|
|
</ul>
|
|
<p>Under normal circumstances a state machine has Run-To-Completion semantics,
|
|
that is, processing of an event is fully completed before the machine returns
|
|
to the client or before the next event is dequeued. Therefore, 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 either transition actions or entry actions fail
|
|
(exit actions cannot 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 cannot be unstable when it
|
|
returns to the client (see <code>state_machine<>::process_event</code> for
|
|
details).</p>
|
|
<hr>
|
|
<p>Revised
|
|
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->11 January, 2004<!--webbot bot="Timestamp" endspan i-checksum="38695" -->
|
|
</p>
|
|
<p><i>Copyright © <a href="mailto:ah2003@gmx.net">Andreas Huber Dönni</a>
|
|
2003-2004. Use, modification and distribution are subject to 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>
|