Semantics of UML State Machines
Semantics of UML State Machines
复制标题
UML 状态机的语义
DOI:
--
复制
发表时间:
1999
期刊:
影响因子:
--
通讯作者:
Alexander Knapp
中科院分区:
文献类型:
--
作者:
Alexander Knapp
The abstract syntax and semantics of a simplified subclass of UML state machines is defined. 1 UML State Machines We illustrate the main concepts of UML state machines by a simple UML model of an automatic teller machine (ATM), shown in Fig. 1: The class diagram in Fig. 1(a) specifies an (active) class Bank. Classes defineattributes, i.e., local variables of its instances, andoperationsand signals that may be invoked on instances by call and send actions, respectively. The state machine for class Bank is shown in Fig. 1(b), consisting of statesand transitionsbetween states (we number the states for short reference later on). States can besimple(such asIdle and DispenseMoney) or composite(such asVerifying); a concurrentcomposite state contains several orthogonal regions , separated by dashed lines. Moreover,fork andjoin (pseudo-)states, shown as bars, synchronize several transitions to and from orthogonal regions; junction (pseudo-)states, represented as filled circles, chain together multiple transitions. Transitions between states are triggered by events. Transitions may also be guarded by conditions and specify actions to be executed or events to be emitted when the transition is fired. For example, the transition leading from stateIdle to the fork pseudostate requires signal verifyPIN to be present; the transition branch fromVerifyingCard to CardValid requires the guard cardValid to be true; the transition branches to Idle set theBank attributestries andcardValid. Events may also be emitted by entry andexit actions that are executed when a state is activated or deactivated. Transitions without an explicit trigger (e.g. the transition leaving DispenseMoney), are calledcompletion transitionsand are triggered by completion eventswhich are emitted when a state completes all its internal activities. The actual state of a state machine is given by its active state configuration and by the contents of itsevent queue . The active state configuration is the tree of active states; in particular, for every concurrent composite state each of its orthogonal regions is active. The event queue holds the events that have not yet been handled by the machine. The event dispatcher dequeues the first event from the queue; the event is then processed in arun-to-completion(RTC) step. First, a maximally consistent set of enabled transitions is chosen: a transition is enabledif all of its source states are contained in the active state configuration, if its trigger is matched by the current event, and if its guard is true; two enabled transitions are consistentif they do not share a source state. For each transition in the set, its least common ancestor (LCA) is determined, i.e. the lowest composite state that contains all the transition’s source and target states. The transition’s main source state, that is the direct substate of the LCA containing the source states, is deactivated, the transition’s actions are executed, and its target states are activated. The example state machine simulates card and PIN validation of a bank computer. After initialization the bank computer is in state Idle. The reception of signal done leads to finalizing the state machine, whereas on reception of signal verifyPIN the verification process is started in state V rifying. If the card is invalid, the bank computer immediately returns to stateIdle. If the PIN is invalid, it is checked whether the maximum number of trials is exceeded. If this is the case, the card is marked invalid; otherwise the number of trials is incremented by one. In both cases, the bank computer returns to state Idle. If the PIN is valid, the number of trials is reset to zero. If both the PIN and the card are valid, stateDispenseMoney is entered from which the bank computer returns to state Idle. «signal» done «signal» verifyPIN inv: maxTries >= 0 Bank boolean cardValid boolean PINValid int tries = 0 int maxTries