Definition

The previous section gave an overview and informal definition of the FW Profile. The present section defines the profile formally. The profile is essentially implemented as a restriction on the state machine concept defined by the UML2 meta-model. It is defined in terms of:

  • a set a stereotypes,

  • a set of tags, and

  • a set of constraints

Each of the above items is discussed in the following subsections.

The FW Profile Stereotypes

The FW Profile is defined in terms of concepts like “state” or “state machine” that are already present in the UML2 meta-model. The profile restricts the way these concepts can be used. In order to allow these restrictions to be more clearly expressed and in order to demarcate the FW versions of these concepts from their standard version, stereotypes are used. The stereotypes thus redefine the standard state machine-related concepts.

The following stereotypes are defined by the FW Profile:

Stereotype Applies to Description

<<FWStateMachine>>

StateMachine

Represents a framework state machine describing a behaviour of an associated framework class.

<<FWRegion>>

Region

Represents a framework region that is a part of either a framework state machine or a composite state.

<<FWState>>

State

Represents a framework state.

<<FWTransition>>

Transition

Represents a framework transition linking together source and target framework vertices.

<<FWTriggerOperation>>

Operation

Represents a framework trigger operation that invokes a state transition.

The FW Profile Tags

At present, no tags are defined for the FW Profile.

The FW Profile Constraints

Constraints restrict the way in which the profile elements can be interact with each other and with standard UML2 elements. They define the legality rules against which a model must be validated.

Each FW constraint is expressed at three levels. At the first level, it is expressed in natural language. At the second level, it is expressed in OCL. Finally, at the third level, it is expressed using the UML2 API of the RSM. The latter formulation of the constraints is useful to build a constraint validator as explained in the Profile Enforcement section. Note that all three expressions of the same constraints are intended to be equivalent. In fact, the UML2 API expression could in principle be derived automatically by compiling the OCL expression.

In some cases, the OCL description is missing. This is because there is uncertainty about how and whether the constraint can be expressed in OCL.