A State-Based Programming Model for Wireless Sensor Networks

7.2. Modular and Well-Structured Program Design 125
Program 7.2: OSM code fragment implementing the transition from FOLLOWER
to MEMBER upon a join event. The code also includes the timer
initialization of the target state (line 6).
1 state FOLLOWER {
2 join_ev / op7() -> MEMBER;
3 // [...]
4 }
5 state MEMBER {
6 onEntry: / reset_timer( wait_receive() );
7 // [...]
8 }
Comparison
There are two main differences between the event-driven and the state-based
programming model regarding program structure. Firstly, the order of structuring
devices—states and events—is reversed. In the event-driven model, the
first-level structuring device is events, or rather event handlers. In the event
handlers, control flow is then manually multiplexed (with switch statements)
according to the (manually coded) program state. In the state-based model of
OSM, on the other hand, programs are essentially constructed from hierarchically
structured states, in which the control flow is multiplexed according to
events. Allowing programmers to specify their programs in terms of freely arrangeable
hierarchical states offers more freedom and a better way of structuring,
rather than being confined to a few predetermined event handlers. OSM
program code can be divided into multiple functional units, each implemented
in a state or state hierarchy. Because of the clearly defined interfaces of states,
their implementation can be easily replaced by another implementation with
the same interface. In general, using state machines is a more natural way to
describe programs (see Sect. 4.2).
The second difference between both models is that program state in OSM is a
first-class abstraction and state management can thus be automated. The highlevel
state notation is much more concise compared to the code in the eventdriven
model, which is lacking such an abstraction and thus state has to be managed
manually. From the high-level description of the program’s state structure,
code for multiplexing the control flow is generated automatically and transparently
for the programmer. The programmer is saved from having to manually
code the control flow. The amount of code that can be saved is significant, as we
will show for our EnviroTrack example.
The code structure of the EnviroTrack group-management implementation in
NesC (see Appendix B.1) is clearly dominated by manual stack management
necessitated by the event-driven programming model. As can be seen from
Tab. 7.1, out of the 426 code lines of the original NesC implementation, 187 lines
(i.e., about 44%) are dedicated to manual state management. The remaining
239 lines mainly contain the actual program logic (but also some declarations
and interface declarations). That is, out of 9 lines of code, 4 lines are required