11.1 Pattern Statemachine

Motivation

This pattern is aimed to be a frontend to generation of statemachines, that follow a notation as described in [Nol99] . The statemachine is given as a file, that is read during generation of the according support structures.

After modelling a statemachine (e.g. with a certain editor but also via conversion from sdl), this pattern can be used to apply the modelled statemachine to the class hierarchy to deine the reactive behaviour of a class.

Applicability

There is no general limitation in applying this pattern. however certain bindings (e.g. ParallelMachine to parallelity) may need certain support structures to exist (in that case: activeObject).

Using multiple statemachines with one object class and inappropriate bindings to parallelity , accumulation , init and establish may cause unexpected behaviour.

Structure

This pattern is mainly a frontend: it aggregates subpatterns for generation of object side elements (given via parameters parallelity and accumulation ) on the one hand and a bundle of subpatterns for the generation of the different states.

Currently the only generation activity performed by this pattern is creation of an own Statemachine class and provide a list of possible states for it.

Participants

Objects:

(target ) - (modify)
The object class to generate a statemachine for.
(baseNameOfStatemachine) - (create)
The name of the generated statemachine class.

Relations:

(activeObject) - (use)
Target's relation to an ActiveObject to be used for parallelity purposes.

Attributes:

(nameOfStatemachine) - (create)
Target's reference to the generated statemachine.

Methods:

receiveEvent: - (create)
Target's frontend for receiving incoming events
receiveEventNow: - (create)
ReceiveEvent's backend to be called internally
(establish) - (create)
Dependent on parallelity prepare usage of (all) statemachines of a target instance. (keep this name constant inside one object class)
(init) - (create)
Method to create a statemachine instance for a target instance. (use also this to overload a statemachine of a superclass)

Expressions:

(parallelity) (values: ParallelMachine, SequentialMachine , ImmediateMachine, StatesideParallelity; refer to an aggregated subpattern)
Decides in which form of parallelity the statemachin will be run.
(accumulation) (values: MultipleStatesPropagateToAll, SingleState , FlexibleState; refer to an aggregated subpattern)
Decides, if more than one statemachine may be connection to target.
(subStateClass) (values: SymbolsNestedIf, NoninheritingClasses , InterpretingStates; refer to aggregated subpatterns)
Decides about the manner, the statemachine's code is generated in.
(states)
The Slang-file containing the statemachine to be applied.

Collaborations

The different subclasses of MachineParallelity may be used as parameter to parallelity to influence the parallelity behaviour of the statemachines of an object. The different subclasses of StatesInterface have the same purpose for the ability of using one or more statemachine in one object; they are used via the accumulation directive. In a similar way the different Substate subclasses (applied via the parameter statesgeneration ) control the style, code is generated in. While for MachineParallelity and StatesInterface subclasses there is aggregated exactly one subpattern for each Statemachine pattern, the number of aggregated Substate subclass aggregations depends on the number of states in the statemachine.

Consequences

As stated above, this pattern can be added to nearly every object in the model. Indeed it should be used rarely as it creates some overhead for each active object.

Applicating this pattern, the SimulatorKernel described in [Hei96] must be implemented into the system. This kernel serves all used functionality for event- and thread-handling.

AG VLSI Design and Architecture

SFB 501 - Project D1: Application System "Buildings"

PSiGene

Pattern Catalog