2. Component Behaviour and UML State Machines
UML state machines provide a convenient means for the concrete representation of the implementation behaviour of port-based components. We consider a particular, re- stricted class of UML state machines along features as shown in Fig. 7.4. Their seman- tics is given by the superstructure specification [OMG09]; their informal meaning is dis- cussed also in the reference manual [RJB05]. The behaviour of the CoCoME component
CashDeskApplicationin Fig. 8.9b provides an example which applies all of the mentioned
features.
(1) States are initial, simple, submachine, choice or final states.
(2) State entry and exit actions are sequences of send and internal actions. (3) Transitions comprise guards, triggers and effects.
(4) Guards are boolean expressions component, port or signal attributes. (5) Transition trigger events are signal events only (signal trigger). (6) Effects are sequences of send and internal actions.
(7) Submachines follow the same restrictions.
FIGURE7.4. Relevant state machine features
The only deviation from the UML concerns the "input-enabled" execution semantics that discards events if no matching transition is enabled. There is an event pool associated with a state machine which is used to check for event occurrences. The order of event processing is a semantic variation point, but usually a FIFO order is assumed. Events are ignored, that is, removed from the pool without any effect if the current stable state does not show an outgoing transition whose trigger matches the given event. Stability means that currently there is no run-to-completion step executing [RJB05, pp. 604 ff.], [OMG09, pp. 565–566]. As illustrated in Fig. 7.5, discarding events corresponds to triggering a self- loop. In particular this means that the machine is not blocked but continues to process received events. (a) Specification simple example [ ] p.y/ / p.z(1) (b) Semantics simple example [ ] not p.y/ p.y/ / p.z(1)
FIGURE7.5. UML execution semantics for unspecified receptions
Ignoring events conceptually means that received events are definitely lost if a stable state without matching signal trigger is reached. Since such a behaviour is rather an imple- mentation issue, we prefer to use a looser approach that does not rely on a fixed (default) behaviour for unspecified receptions. One of the important aims of the development of our formal component model with asynchronous communication is to prevent unexpected loss of signals by an analysis for communication errors (cf. Chap. 2, Sect. 1.3). For this rea- son we fix the processing order to use a FIFO policy and interpret a state machine "as-is" without adding any default behaviour for missing event receptions. We rely on our notion of asynchronous output compatibility to guarantee that events that have been sent are not ignored at the receiver’s site.
118 7. UML2 – APPLIED FEATURES AND EXTENSIONS
Beyond existing UML features we use additional notations and fix some semantic vari- ation points as follows. Sequences of actions are interpreted as a shorthand for an explicit sequential specification with one transition and successor state for each action. For guards the usual boolean connectivities and simple arithmetic operators such as+or≤are used. For internal actions we use attribute assignment, simple arithmetic operators and private helper functions. Signal trigger and send actions of state machine transitions use a notation that includes the port name where the particular signal is sent or received:
(1) Signal trigger are writtenp.m/, meaning that the behaviour is ready to receive signal
mat portp. The signal’s attributes are specified by the operation signature formas given by the provided interface of port pand may be accessed for data values after this event occurred.
(2) Send actions are written/p.m(x1, . . . , xn), meaning that a signalmis sent via portp.
The values represented by variablesx1, . . . , xn are assigned to the signal’s attributes ac-
cording to the order of the formal parameters as specified by the operation signature form
in the required interface of portp.
Figure 7.6 shows an example to illustrate the data-related aspects of signal trigger and send actions. A signal trigger of portp:Pdeclared in the context of component typeCis
defined with regard to the signatures of the provided interfaceI. The trigger are written p.x/andp.y/. The values of the latter are accessible using the attributes according to the
signal typeY, that is, by an expressiony.n. As an example application we consider the
send action according to the signature given in the required interfaceG. The send action is
written/p.z(y.n)meaning that we pass the current value of the signal’s attribute further with
a signal of typeZ(not shown in Fig. 7.6) whose attribute valuehequalsy.n. In the same
vein we use constants, simple arithmetics or helper functions to describe attribute values of signals sent. «component» C p : P «signal» z( h : int ) G «signal» x() y( n : int ) I n : int «signal» Y «port» P I G
FIGURE7.6. Data associated with a signal
We define and use two stereotypes, «orthogonal» in the context of a state machine
and «tau» in the context of transitions. The latter is a means to specify an anonymous
internal action in case further internal details should either be hidden for the purpose of encapsulation or are not relevant for a precise understanding of the behaviour at hand. In contrast to UML internal actions we do not interpret «tau» transition along the usual
run-to-completion semantics [OMG09, pp. 565 ff.]. If a mixed choice state with both, an outgoing transition with signal trigger and a transition without trigger and only a send action is encountered, the UML semantics always triggers the send transition, even though there is a transition with a signal trigger specified. Figure 7.7 illustrates this point with mixed choice states0. In order to allow the reception transition to be triggered, we insert
a «tau» transition before the send action, in fact resolving the mixed choice state to a state
with an internal choice. Note that a state machine interpreter would need to implement the «tau» using a timeout or the like, that decides on the time spent waiting for an event that
matches the signal trigger.
The stereotype «orthogonal» is explained along its application in the state machine
for the CoCoME component Coordinatorin Fig. 8.8. The stereotype is parametrised and
is used to derive a common global behaviour of several independent copies of the given state machine that are supposed to be executed in parallel to each other. The parameter
3. FRAME SPECIFICATIONS AND UML PROTOCOL STATE MACHINES 119