HIERARCHICAL COMPONENT BEHAVIOURS 131 component behaviour

LightDisplay[ ] cda.expressModeDisabled() cda.expressModeEnabled() cda.expressModeDisabled() / showBlack() cda.expressModeEnabled() / showGreen() cda.emd/ green cda.eme/ black cda.eme/ cda.emd/

FIGURE8.6. Behaviour of theLightDisplaycomponent

waits to receive information concerning the amount of money paid by the current customer. As long as this information is not explicitely finished, a loop is entered that is left either if asaleSuccessevent is received or the the entered amount is explicitely finalised. After

that change is calculated and the the closing the of cash box registered. The choice state uses a boolean guard that is resolved to a loop in the IOTS in a straightforward way.

Figure 8.7b shows the behaviour specification of the componentCardReaderas a first

example of a more complex behaviour. There are two main functional regions in the be- haviour specification. On the one hand, the card reader may be deactivated by receiving a messageexpressModeEnabled. On the other hand, within the lower region reached by the

reception of a signalactivate, the port possibly engages in sending credit card information.

From any of the “active” states the card reader may be again be deactivated by the mes- sageexpressModeEnabled. The IOTS-translation is depicted in Fig. 8.7d. The transitions

for reception ofexpressModeEnabledandactivateleaving the complex state in UML state

machine are translated to one transition for each of the substates in the IOTS-translation. The behaviour specification of the componentCashBoxis more involved compared to

the other devices attached to theCDA, but it does not introduce new features. Therefore,

we defer the discussion of its behaviour to Sect. 4. The same holds for the specification of the componentCashDeskApplication. Even though this component plays an application-

specific key role as the centre of a star topology (withinCashDesk), we directly switch to

theCoordinatorcomponent which resides on the hierarchical level ofCashDesk.

TheCashDeskLineof a store consists of a number of cash desks and an instance of

the componentCoordinatorwhose behaviour is specified in Fig. 8.8. The coordinator de-

cides on the mode of the cash desks which is either express or normal. Note that even if the coordinator decided to signalexpressModeEnabled, the component may receive yet

another sale registration from the same cash desk because the communication partners are executing concurrently. In this case the sale registration has precedence over the coordina- tor’s decision: the behaviour receives the signalsaleRegisteredand recomputes its internal

decision. The component keeps track of the particular sale history for each cash desk and decides upon this history to signal an express mode switch for this particular cash desk.

The update of the sale history is required to be synchronised (not described in the behaviour) due to the potentially concurrent execution of several requests via port declara- tioncd:cds(specified with multiplicity*). Due to this feature, the STM specification uses

the stereotype «orthogonal» and assigns the required number of copies of the given be-

haviour to the multiplicity ofcd:cds. The translation takes this parameter into account and

computes a corresponding product of the translated transition system. The computation applies a relabelling of each copy such that the final transition system results in a complete interleaving of the|cds|copies.

4. Hierarchical Component Behaviours

The state machines for the components CashBoxandCashDeskApplicationresult in

transition systems too large to be depicted graphically. However, we believe that the be- haviours nicely illustrate a real-world application of our component model and therefore we include a brief presentation, though without a translation to transition systems. The

132 8. THE COMMON COMPONENT MODELLING EXAMPLE (COCOME) (a)Printer component behaviour Printer[ ] [cashAmountEntered.final] cda.saleSuccess/ cda.saleStarted/ [not cashAmountEntered.final] cda.cashAmountEntered/ cda.changeAmountCalculated/ cda.cashBoxClosed/ cda.saleFinished/ cda.runningTotalChanged/ (b)CardReader component behaviour CardReader[ ] ca.pullCard/ / cda.cardInfo = pullCard.cardInfo cu.enterPin/ / cda.pin = enterPin.pin / cda.creditCardScanned(cda.cardInfo) / cda.pinEntered(cda.pin) cda.expressModeEnabled/ cda.expressModeDisabled/

cda.activate/ cda.activate/ cda.expressModeEnabled/ cda.expressModeEnabled/ cda.activate/ (c)Printer cda.cbc/ cda.sst/ cda.rtc/ cda.ssu/ cda.cac/ cda.caef/ cda.cae/ cda.sf/ (d)CardReader cda.emd/ cda.a/ ca.pc/ /cda.ccs cu.ep/ bufPin

cda.eme/ cda.eme/ cda.eme/ cda.a/ cda.a/ cda.eme/ cda.a/ cda.a/ cda.eme/ bufInfo /cda.pe cda.a/ cda.eme/

FIGURE8.7. Behaviour of thePrinterand theCardReadercomponent

examples clearly indicate the importance of hierarchical constructions and guards for a comprehensible modelling of more complex behaviours.

The componentCashBoxuses two ports, an optional operator portcaof typeCB-Cashier

and a mandatory portcdaof typeCB-CDA; cf. Fig. 8.3. The former allows to connect the

component to inputs of the cashier, the latter specifies the behaviour with regard to the cash desk application. The messageproductBarcodeEnteredat theCB-Cashierport is not

mentioned in the sequence diagrams of the CoCoME but in the standard process and also in an exceptional process of Use Case 1. It allows the cashier to manually enter a product bar code in case there are problems with the bar code scanner. The component behaviour ofCashBoxin Fig. 8.9a maps the cashier’s input at thecaport essentially directly to corre-