UML state machine diagrams describe the behavior of a class over time through illustrations of the states and transitions of a single object progressing through its lifetime. State machine diagrams are a traditional object-oriented way to show behavior and to document how an object
responds to events, including internal and external stimuli.
In this section we discuss the two important parts of UML state machine; states and the transi- tions.
4.3.1 States
A state is a condition or situation during the life of an object, which it satisfies some condition, performs some activity, or waits for some event. An object remains in a state for a finite amount of time. For example, the ATM machine in the bank might be in any of six states CardEnry (waiting for somebody to enter his Bank Card), PINEntry(Waiting for customer to enter his pin number),Verification(the ATM determine where the card and the pin number are satisfied) AmountEntry (Waiting for the customer to enter the required amount), GivingMoney (the ATM machine will give the required money to the customer) and the ReturningCard state (Returning the card to the customer).
When an object’s state machine is in a given state, the object is said to be in that state. For example, an instance of ATM might be CardEntry or perhaps ReturningCard. A state has several properties Fig 4.10. TheNameof the state which is a textual string that distinguishes the state from other states; a state may be anonymous, meaning that it has no name. Entry/Exitactions which are executed on entering and exiting the state, respectively. Internal transitions are transitions that are handled without causing a change in state. The Substates is the nested structure of a state, involving disjoint (sequentially active) or concurrent (concurrently active) substates. and finally theDeferred eventswhich are a list of events that are not handled in that state but, rather, are postponed and queued for handling by the object in another state.
entry / Print("Welcom to our Bank"); exit / Print("Card Entered");
do / ("Enter your card");
CardEntry
name do activity exit action
entry action
Figure 4.10: Properties of the State in UML State Machine
Initial and Final States There are two special states that may be defined for an object’s state machine. First, the initial state, which indicates the default starting place for the same machine or substate. An initial state is represented as a filled black circle. Second, the final state, which indicates that the execution of the state machine or the enclosing state has been completed. A final state is represented as a filled black circle surrounded by an unfilled circle as shown in figure 4.11.
Initial State Final State
Figure 4.11: Initial and final States in UML State Machine
4.3.2 Transitions
A transition is a relationship between two states indicating that an object in the first state will perform certain actions and enter the second state when a specified event occurs and specified conditions are satisfied. On such a change of state, the transition is said to fire, it is said to be in the target state. For example, in our case study the state machines of ATM the transition from theVerificationstate toReturningCardstate will be done when an event such as abort occurs. The properties of transitions are as follows; thesource statewhich mean if an object is in the source state, an outgoing transition may fire when the object receives the trigger event of the transition and if the guard condition, if any, is satisfied. The Event triggeris an event whose reception by the object in the source state makes the transition eligible to fire, providing its guard condition is satisfied. TheGuard conditionis a boolean expression evaluated when the transition is triggered by the reception of the event trigger; if the expression evaluates True, the transition is eligible to fire; if the expression evaluates False, the transition does not fire and if there is no other transition that could be triggered by that same event, the event is lost. the Action is an executable atomic computation that may directly act on the object that owns the same machine, and indirectly on other objects that are visible to the object. Finally theTarget statewhich is a state that is active after the completion of the transition. As figure 4.12 shows, a
State State
trigger [Condition] / event
source state target state event trigger
quard condition
action self transition
Figure 4.12: The Transition in UML State Machine
transition is rendered as a solid directed line from the source to the target state. A self−transition is a transition whose source and target states are the same.
Note: A transition may have multiple sources (in which case, it represents a join from multiple concurrent states) as well as multiple targets (in which case, it represents a fork to multiple concurrent states).
4.3.3 State Machines of 2PC-Protocol
We have already discussed in the first chapter section 2.2.6, the two-phase commit protocol which is a distributed algorithm which lets all sites in a distributed system agree to commit a transaction. The protocol results in either all nodes committing the transaction or aborting, even in the case of site failures and message losses. The two phases of the algorithm are bro- ken into the COMMIT−REQUEST phase, where thecoordinator attempts to prepare all the participants, and the COMMIT phase, where thecoordinatorcompletes the transactions at all participants.
In this section we introduce the two-phase protocol as UML state machines diagrams as follows:
Coordinator State Machine At the beginning of the interaction between the client and the server, the coordinator is in the preparing transaction state (figure 4.13 at the left), it waits for re- sponses from each of the participant. If any participant responds vote abort() then the transaction must be aborted and proceed to the Abort state. In this case the coordinator sends thePartic- ipant.Abort() message to each participant. If all participants respond vote commit() then the
Log_begin Log_ready Log_abort Prepare Commit Abort Ready /^coordinator.vote_abort() Commit /^coordinator.vote_commit() Abort prepare Log_begin_commit Log_commit Log_abort Prepare Abort Commit /Participant.Abort /Participant.Commit vote_abort() vote_commit() /^participant.prepare
transaction may be committed, and proceed to stateCommit, then sends theparticipant Commit
message to all participants.
Participant State Machine If a prepare message is received from the coordinator state ma- chine (figure 4.13 at the right), the participant must be ready to make his decision, either he responds withyesand go to the next stateLog Ready, or it decides withnoand go to the state
log begin. If the participant is in theLog Readystate, it sends the messageCoordinator.vote com- mit to the coordinator state machine and be in the state Ready waiting for a message from the coordinator state machine. If the participant is in the Log begin state, it sends the signal
Coordinator.vote abortto the coordinator state machine, and it removes to the stateAbort. In the Readystate if an abortmessage is received then it finishes the transition and go to the
Abortstate. If acommitmessage is received then the transaction is prepared for committal and go to theCommitstate.