A State-Based Programming Model for Wireless Sensor Networks

106 Chapter 6. Implementation
state definition may be substituted using the incarnate keyword followed by
the name of the actual state declaration. In order to adapt the actual state definition
to the program context of its incarnation, a number of name-substitutions
and additions can be made to the original declaration in the incarnation statement.
The full declaration of a state incarnation has the following form (where
S is the name of the state incarnation, and I is the state to be incarnated):
state S incarnate I (name substitutions) {
additional entry actions
additional transitions
additional preemption actions
}
Additionally, state definitions may be marked with the template keyword
in order to denote that the definition is not a complete program but instead is a
template definition meant for incarnation elsewhere in the program. Though not
strictly required, state templates should specify their complete interface including
variables, events, and actions. The example Prog. 6.4 shows the definition
of a template state I (lines 1-9) and its incarnation as a direct substate of the
top-level state P ROG_4 (lines 14-19). Additionally, P ROG_2 (which we have
defined previously in Prog 6.2) is also inserted as a direct substate of P ROG_4
(lines 21-26). We will use this example to explain the various elements of the
above incarnation statement in the following subsections.
Name Substitution
A state can be incarnated as a substate of a regularly defined (i.e., nonincarnated)
state. The incarnation has the same name as the incarnated state
unless given a new name in the incarnation statement. If the a state definition is
incarnated more than once, the incarnation should be given a new name in order
to distinguish it from other incarnations. Lines 14 and 21 of Prog. 6.4 shows
how to rename incarnations.
Just like regular states, incarnated states may access the variables of their superstates.
The external variables of the incarnation (i.e., the ones used but not
defined in the incarnation, see lines 2 and 3) are bound to the variables of the
embedding superstates at compile time. External variables must have the same
name and type as their actual definitions. However, since the incarnated state
and the superstate may be specified by different developers, a naming convention
for events and variables would be needed. In order to relieve programmers
from such conventions, OSM supports name substitutions for events and external
variables in the incarnation of states. This allows to integrate states that were
developed independently. Line 15 of Prog. 6.4 shows how the external variable x
of the original definition (line 2) is renamed to u in the incarnation. Renaming of
events is done analogously. Lines 16, 22, and 23 show how events are renamed.
Note that in the incarnation of PROG_2 the event names e and f are exchanged
with respect to the original definition.