A State-Based Programming Model for Wireless Sensor Networks

102 Chapter 6. Implementation
specified action is executed. If the target state is missing, the specification of an
action is mandatory.
Incoming Transitions and Entry Actions
As stated previously, transitions are defined in the scope of the transition’s
source state together with the transition’s exit action. In order to specify entry
actions, part of the transition must be again declared in the transition’s target
state. That is, if a transition is to trigger both an exit and an entry action,
the transition appears twice in the OSM code: It must be defined in the transition’s
source state, together with the exit action. And it must be declared again
as incoming transition in the target state (together with the entry action). Both
declarations denote the same transition, if source state, target state, trigger and
guard are equal. If only the exit action of a transition is required, its declaration
as incoming transition is obsolete.
The reason for this seeming redundancy is the intent to reflect OSM’s scoping
of actions in the programming language. In OSM, exit actions are executed in
the context of a transition’s source state, whereas entry actions are executed in
the context of a transition’s target state. This separation is reflected in the syntax
and clearly fosters modularity, as changes to the incoming action do not require
changes in the transition’s source state (and vice versa) at the price of slightly
more code.
The general form of entry actions is (where S is the source state, e is the trigger
event, g is the guard, and aentry() is the entry action to be triggered):
onEntry: S -> [g]e / aentry();
In Prog. 6.1, a transition from B to C triggered by f has an entry action inC1().
The actual transition is defined in line 12. The corresponding entry action is
declared in transition’s target state C in line 18. The declaration of the entry
action includes the transition’s source state B and its trigger f. However, the
declaration of the transition’s exact source state as well as its trigger event and
guard are optional and only required to identify the exact incoming transition
should there be multiple incoming transitions. This information can be left out
where this information is not required to identify the transition, for example if
there is only one incoming transition. In our example, state C has two incoming
actions, both invoked on transitions from the same source state B. Therefore
the specification of the source state is not strictly required in the declaration and
line 18 could be replaced with “onEntry: f / inC1();” without changing
the program’s semantic. Missing source states, trigger events, and guards, in
entry-action declarations are considered to match all possibilities. Therefore, in
the declaration “onEntry: / a();” in the definition of a state S, action a()
would be executed each time S was entered. When multiple declarations match,
all matching entry actions are executed.
Entry Actions on Initial State Entry
In order to trigger computational actions when entering the initial state of a
state machine (either at the start of the entire program or because a superstate