LO QUE COMPRENDÍ

s2 s1 / p.z(1) p.x/ s1 s2 s0 / p.z(1) «tau» p.x/

FIGURE7.7. Internal actions with relaxed run-to-completion semantics

numCopies = |cds|of the stereotype stores the required number of copies. In the concrete

example the multiplicity of the set of ports cds as declared by the type specification of Coordinatorin Fig. 8.2b is supposed to provide this information. In the translation to tran-

sition systems below, the parameter is used to generate indexed and thus different labels. 3. Frame Specifications and UML Protocol State Machines

Figure 7.8 summarise features of UML2 protocol state machines (PSM) that are rele- vant for frame specifications within our component model. In contrast to state machines, PSMs do not allow for the direct specification of effects. Instead, pre- and post-conditions are supposed to be used to specify behavioural aspects in a more declarative way. Since our formal model does not consider pre- and post-conditions we will, however, not make use of this feature. Therefore there are no action related features in Fig. 7.8. In particular, transitions do not show effects and guards use signal attributes only. Without internal ac- tions we can not specify port or component attribute assignments and therefore it does not make sense to include them in guard expressions.

(1) States are initial, simple, submachine, choice or final states. (2) Transitions comprise guards and triggers.

(3) Guards are boolean expressions with signal attributes.

(4) Transition trigger events are signal events only (signal trigger). (5) Submachines follow the same restrictions.

FIGURE7.8. Relevant protocol state machine features

Making PSMs applicable for the specification of component frames requires exten- sions in two respects. First, our specifications describe a temporal ordering of messages received and sent. Therefore, we allow transitions with guards, triggers and sequences of send actions analogous to transitions with send actions of UML state machines as described above. Moreover, we allow for the specification of anonymous internal actions using the stereotype «tau» and parameterised specification of multiple copies using the stereotype

«orthogonal». Second, we add a further stereotype «opt» for the specification of optional

transitions. Anoptional transitionmust not necessarily exist in the implementation while ordinary transitions will be interpreted as mandatory. It is an obligation for correct im- plementations to provide a corresponding transition. In contrast to UML state machine semantics, the UML semantics of PSMs considers the reaction to receptions of unexpected events as a semantic variation point [OMG09, pp. 538]. Thus, our direct interpretation for the translation of PSMs to PIOs described below is in accordance with the UML semantics. As an example consider the frame specification of a bank component, depicted in Fig. 7.9. The example is taken from the CoCoME in Chap. 8 and included here for conve- nience. The specification describes a simple protocol for PIN validation with a succeeding debit of the particular account. The positive answers to the respective requests are both optional. By this means, implementations that always deny avalidationordebitrequest (or

120 7. UML2 – APPLIED FEATURES AND EXTENSIONS component frame Bank[ ] / b.notOk b.validateCard/ b.debitCard/ / b.debitOk «opt» / b.denied «opt» / b.ok(randomVal)

FIGURE7.9. Frame specification of a bank component

with trigger for the signalsvalidateanddebitas well as transitions with negative answers

are mandatory for correct implementations.

4. From State Machines to Transition Systems

Even within our restricted class of simple UML (protocol) state machines there are some features which can not immediately be translated to I/O-transition systems (IOTS), input-persistent I/O transition systems (PIO) respectively. State machines use guards and attributes which both are not available with transition systems. Moreover, state machines use a form of hierarchical construction with submachines that neither exist within our formalism.

Guards and attributes need to be manually translated in a preprocessing step either by abstraction or by instantiation in case of finite data domains as given, for instance, by boolean typed variables or enumerations. The translation of submachine states is, due to their macro semantics straightforward by complete expansion and could be automated. In the following we describe the translation from state machines (STM) to IOTSs and after that extend the approach for the translation of protocol state machines (PSM) to PIOs. The necessary preprocessing comprises the following steps:

1. Abstract data variables 2. Abstract and resolve guards 3. Expand submachine states

We explain these steps by pattern-like translations. First, we consider labels involv- ing data variables such as a send action of the form/p.z(x). If the type ofxhas a finite domain one may generate labels and transitions for each value within this domain. If no guards are involved the distinction does not play a role and it suffices to consider just one abstracted transition labelled/p.zwithout any parameter value. This pattern is exemplified

in Fig. 7.10a. In case succeeding transitions depend on the values sent, for instance using guards that involve the variablex, the concrete values need to be taken into account for

each of these transitions. Figure 7.10b shows the corresponding situation after a signal has been sent. The translation generates internal labels and transitions that allow to distinguish the different paths. This approach, however, is not correct if the receiver behaviour also de- pends on the attributes of the signal sent. For this case, exemplified by a receiver as given in Fig. 7.10c, the transitions need to be aligned such that both, sender and receiver, use matching transition labels. The sender in Fig. 7.10b then uses transitions labelled/p.zPos

and/p.zNeg0instead of the given send transition with succeeding internal transitions.

The translation of UML submachine states is straightforward by expanding the partic- ular state as illustrated in Fig. 7.11. The transitionp.cancel/is added to any stable subma-

chine state. The submachine transition to its final state triggers the unlabelled completion transition to states1.

The result of the preprocessing is an intermediate STM with new labels, transitions and states, that maps directly to an IOTS. The states of the IOTS, including the initial state are given by the STM states. STM signal trigger translate to input labels, the send actions to