Other actions??”icons turning on or off, time
calculations, setting alarms??”were speci?¬?ed along transitions.
State machines are considerably more complicated than the ?¬‚ow machines above,
especially if we look at full Harel statecharts. Compared to those, the watch example
had no conditions on transitions, no state enter and exit actions, and no state history,
and event transitions in a higher model did not affect lower models. This is a common
state of affairs in a DSM language: we implement only a fairly minimal subset of all
the features a full theoretical modeling language might have. This helps considerably
when building and using the modeling language, but also when building the generator
and domain framework.
Switch??“Case In embedded applications, the most commonly seen code for state
machines consists of nested switch??“case statements. The ?¬?rst switch is based on what
state the application is currently in, and the second is based on what event has
occurred. As we saw in Chapter 9, generating this kind of code from a state machine is
simple. For ease of understanding, we can omit some details here and assume that
EntryAction and ExitAction are properties of State objects, while Condition, Event,
and Action are properties of Transition relationships??”all expressed directly as legal
C code.
Pages:
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544