This section gives an informal description of the FW Profile. The description is done in terms of three main elements.

The first element is the restriction of the state machine model defined by the UML 2.0 standard. The restriction is primarily driven by the requirement that the FW state machine should only cover functional aspects. This restriction is described and justified in the “Restriction to the State Machine Model” sub-section.

The second element is the restriction of the UML2 state machine extension mechanism. The restriction is primarily driven by the requirement that properties defined at framework level should be preserved during the component adaptation phase. This restriction is described and justified in the “Restriction to the State Machine Extension Model” sub-section.

The third element is the definition of an action language for the transition guards, the transition effects, and the state actions. The requirements of this language are described and justified in the “State Machine Action Language” sub-section.

The Restrictions to the State Machine Model

A state machine may be associated to a class to describe its internal behavior. The main driver for the definition of the restrictions on the UML2 state machine profile is the requirement that the state machine is only intended to describe the purely functional part of the behavior of the class.

Behavior that is time-related (e.g. waiting for a time-out) or that implies interaction across thread boundaries (e.g. sending an asynchronous message to another class) should be modeled at the HRT-UML (Hard Real-Time Unified Modeling Language) level. In other words, state machines are proposed here to model the behavior internal to a thread, whereas HRT-UML is proposed to model time-related and inter-thread behavior.

As a consequence, state transitions in the state machine should be exclusively triggered by calls on the operations defined by the class. Other types of transition mechanisms (through signal or time triggers) should be forbidden by the FW Profile. Similarly, no events are allowed in the FW state machines.

The second driver for the definition of the restrictions on the UML2 state machine profile is simplicity and elimination of unnecessary or over-complicated features. This is important to streamline the model validation process and the code generation processes.

UML2 allows three kinds of states: simple states, composite states, and submachine states. Only simple and composite states are allowed by the FW Profile. Submachine states are semantically equivalent to composite states and are only provided to factor common behavior and allow reuse of fragments of state diagrams. This capability is not regarded as important in the framework context where state machines associated to classes are unlikely to be very large.

UML2 defines several kinds of pseudo-states. Of these, only the initial pseudo-state and the choice pseudo-states are retained by the FW Profile. The initial pseudo-state is required to define the state entered by the state machine when an instance of the class whose behavior it describes is created. The choice pseudo-state helps simplify the state diagrams as it can be used to represent dynamic conditional branches. The profile however does not enforce the constraint that at least one of the branches must evaluate to true. Satisfying this constraint (for instance, by always inserting an “else” branch) is the responsibility of the user.

UML2 allows entry, do and exit actions to be associated to states. The entry and exit actions are retained but the do action is not necessary since the FW state machine are purely reactive: they only do something when they are triggered by a call to a trigger operation defined on the class to which they are associated.

The option of having composite states to model parallel state machines is regarded as useful and within the scope of the FW Profile. However, in a first instance, composite states will be forbidden. They may be allowed by a later release of the profile.

The Restrictions to the State Machine Extension Model

The state machine extension mechanism is constrained by the need to ensure that properties that are defined on a base state machine still hold on the derived state machine. We use a terminology that is derived from the terminology of class extension. The base state machine is the state machine that is extended. The derived state machine is the state machine that is obtained by extending the base state machine.

The properties defined on the base state machine capture aspects of the state machine topology and of its state transition logic. Hence, the simplest way of preserving them during the extension process is to constrain the extension to define the internal behavior of one or more of the states of the base state machine without altering its topology and transition logic. This is illustrated in the following figure where the derived state machine differs from the base state machine only in having added an embedded state machine to one of the base states. The derived state machine, in other words, defines the internal behavior of a state that was initially defined as being a simple state.

The FW Profile adopts the extension process of figure shown above and forbids all other kinds of state machine extensions that are allowed by UML2 (redefinition of transition, definition of new transitions between existing states, definition of new states or regions, etc).

In order to completely freeze the transition logic of a state machine, the FW Profile stipulates that the trigger operations that control the state transitions must be defined as final (i.e. they cannot be altered during the class extension process).

In order to ensure the preservation of properties defined on the base state machines, the two state machines – the base state machine and the state machine embedded in one of its states during the extension process – must be completely decoupled. In particular, trigger operations defined on the derived class must act on one and only one of the two state machines. The embedded state machine additionally must not be allowed to trigger transitions in the base state machine.

The extension mechanism sketched above, though very simple, corresponds to a realistic situation that arises often in framework design. This is the case that is described by the well-known template design pattern. This design pattern describes the case of a class that defines some skeleton behavior that offers some hooks where application-specific behavior can be added by overriding virtual methods or by providing implementation for abstract methods. The behavior encapsulated in the skeleton, however, is intended to be invariant.

In terms of the model underlying the FW Profile, the invariant skeleton behavior is encapsulated by the base state machine whereas the variable hook behavior is encapsulated by the nested state machines added by the derived class.

Finally, there is a second way in which state machines could be extended in a property-preserving manner. This illustrated in the following figure. In this case, the derived class splits the to-level region of the base class into two regions to add a parallel state machine to the base state machine. If the two state machines are kept decoupled from each other, then clearly properties defined on the base state machine will still hold on the derived state machine.

This extension mechanism is regarded as useful and within the scope of the FW Profile. However, in a first instance, it will be forbidden. It may be allowed by a later release of the profile.

The State Machine Action Language

The FW Profile assumes that state machines are used to model the behavior of a class. At its most basic level, the link between a class and its associated state machine is defined by the trigger operations, namely the class operations that trigger transitions in the state machine. The profile also defines an action language in order to allow a more complete link to be established between a state machine and its associated class.

The action language is used to define:

• transition guards,

• transition effects,

• state entry actions, and

• state exit actions.

The action language allows the following elements to be manipulated:

• class methods,

• class attributes of integer or boolean type,

• references to associated class instances.

The action language is defined to use a simple Java-like syntax. Conditional or loop constructs are however not included.

The action language allows a guard to be expressed as a boolean expression combining the above elements. Similarly, it allows transition effects and entry and exit actions to be expressed as expressions that combine the above elements and return void.