5.10. (Optional) Software Engineering Case
Study: Identifying Objects' States and Activities in the ATM System
In Section
4.11, we identified many of the class attributes needed
to implement the ATM system and added them to the class diagram in Fig.
4.20. In this section, we show how these attributes
represent an object's state. We identify some key states that our objects may
occupy and discuss how objects change state in response to various events
occurring in the system. We also discuss the workflow, or activities, that objects
perform in the ATM system. We present the activities of BalanceInquiry
and Withdrawal transaction objects in this
section, as they represent two of the key activities in the ATM system.
State Machine Diagrams
Each object in a system goes
through a series of discrete states. An object's current state is indicated by
the values of the object's attributes at a given time. State machine diagrams (commonly called state diagrams) model
key states of an object and show under what circumstances the object changes
state. Unlike the class diagrams presented in earlier case study sections, which
focused primarily on the structure of the system, state diagrams model some of
the behavior of the system.
Figure
5.20 is a simple state diagram that models some
of the states of an object of class ATM. The UML
represents each state in a state diagram as a rounded rectangle with
the name of the state placed inside it. A solid
circle with an attached stick arrowhead
designates the initial state. Recall that we modeled this state information as the
Boolean attribute userAuthenticated
in the class diagram of Fig.
4.20. This attribute is initialized to false, or the "User not
authenticated" state, according to the state diagram.
The arrows with stick arrowheads indicate transitions between
states. An object can transition from one state to another in response to
various events that occur in the system. The name or description of the event
that causes a transition is written near the line that corresponds to the
transition. For example, the ATM object changes from
the "User not authenticated" state to the "User authenticated" state after the
database authenticates the user. Recall from the requirements specification that
the database authenticates a user by comparing the account number and PIN
entered by the user with those of the corresponding account in the database. If
the database indicates that the user has entered a valid account number and the
correct PIN, the ATM object transitions to the
"User authenticated" state and changes its userAuthenticated attribute
to a value of true. When the user exits the
system by choosing the "exit" option from the main menu, the ATM object returns to the "User not authenticated" state
in preparation for the next ATM user.
Software Engineering Observation 5.2
 |
Software
designers do not generally create state diagrams showing every possible state
and state transition for all attributes—there are simply too many of them. State
diagrams typically show only the most important or complex states and state
transitions. |
Activity Diagrams
Like a state diagram, an activity
diagram models aspects of system behavior. Unlike a state diagram, an activity
diagram models an object's workflow (sequence of events) during program
execution. An activity diagram models the actions the object will perform and in
what order. Recall that we used UML activity diagrams to illustrate the flow of
control for the control statements presented in Chapter
4 and this chapter.
The activity diagram in Fig. 5.21 models the actions involved in executing a
BalanceInquiry transaction. We assume that a BalanceInquiry object has already been initialized and assigned a valid
account number (that of the current user), so the object knows which balance to
retrieve. The diagram includes the actions that occur after the user selects a
balance inquiry from the main menu and before the ATM returns the user to the
main menu—a BalanceInquiry object does not perform
or initiate these actions, so we do not model them here. The diagram begins with retrieving the
available balance of the user's account from the database. Next, the
BalanceInquiry retrieves the total balance of
the account. Finally, the transaction displays the balances on the screen. This
action completes the execution of the transaction.
The UML represents an action in an
activity diagram as an action state modeled by a rectangle with its left and
right sides replaced by arcs curving outward. Each action state contains an
action expression—for example, "get available balance of user's account from
database"—that specifies an action to be performed. An arrow with a stick
arrowhead connects two action states, indicating the order in which the actions
represented by the action states occur. The solid circle (at the top of Fig. 5.21) represents the activity's initial state—the beginning
of the workflow before the object performs the modeled actions. In this case,
the transaction first executes the "get available balance of user's account from
database" action expression. Second, the transaction retrieves the total
balance. Finally, the transaction displays both balances on the screen. The
solid circle enclosed in an open circle (at the bottom of Fig. 5.21)
represents the final state—the end of the workflow after the object performs the
modeled actions.
Figure
5.22 shows an activity diagram for a
Withdrawal transaction. We assume that a Withdrawal object has been assigned a valid account number. We do not
model the user selecting a withdrawal from the main menu or the ATM returning
the user to the main menu because these are not actions performed by a
Withdrawal object. The transaction
first displays a menu of standard withdrawal amounts (Fig.
2.13) and an option to cancel the transaction. The
transaction then inputs a menu selection from the user. The activity flow now
arrives at a decision symbol. This point determines the next action based on the
associated guard conditions. If the user cancels the transaction, the system
displays an appropriate message. Next, the cancellation flow reaches a merge
symbol, where this activity flow joins the transaction's other possible activity
flows (which we discuss shortly). Note that a merge can have any number of
incoming transition arrows, but only one outgoing transition arrow. The decision
at the bottom of the diagram determines whether the transaction should repeat
from the beginning. When the user has canceled the transaction, the guard
condition "cash dispensed or user canceled transaction" is true, so control
transitions to the activity's final state.
If the user selects a withdrawal amount from the menu,
the transaction sets amount (an attribute of class
Withdrawal originally modeled in Fig.
4.20) to the value chosen by the user. The
transaction next gets the available balance of the user's account (i.e., the
availableBalance attribute of the user's
Account object) from the database. The
activity flow then arrives at another decision. If the requested withdrawal
amount exceeds the user's available balance, the system displays an appropriate
error message informing the user of the problem. Control then merges with the
other activity flows before reaching the decision at the bottom of the diagram.
The guard decision "cash not dispensed and user did not cancel" is true, so the
activity flow returns to the top of the diagram, and the transaction prompts the
user to input a new amount.
If the requested withdrawal
amount is less than or equal to the user's available balance, the transaction
tests whether the cash dispenser has enough cash to satisfy the withdrawal
request. If it does not, the transaction displays an appropriate error message
and passes through the merge before reaching the final decision. Cash was not
dispensed, so the activity flow returns to the beginning of the activity
diagram, and the transaction prompts the user to choose a new amount. If sufficient cash is
available, the transaction interacts with the database to debit the withdrawal
amount from the user's account (i.e., subtract the amount from both the
availableBalance and totalBalance attributes of the user's
Account object). The transaction then
dispenses the desired amount of cash and instructs the user to take the cash
that is dispensed. The main flow of activity next merges with the two error
flows and the cancellation flow. In this case, cash was dispensed, so the
activity flow reaches the final state.
We've taken the first steps in
modeling the behavior of the ATM system and have shown how an object's
attributes participate in the object's activities. In Section
6.22, we investigate the operations of our classes
to create a more complete model of the system's behavior.
Software Engineering Case Study
Self-Review Exercises
| 5.1 |
State whether the following
statement is true or false, and if false,
explain why: State diagrams model structural aspects of a system. |
| 5.2 |
An activity diagram models the_________
that an object performs and the order in which it performs them.
|
| 5.3 |
Based on the
requirements specification, create an activity diagram for a deposit
transaction. |
Answers to Software Engineering
Case Study Self-Review Exercises
| 5.1 |
False. State diagrams model some of the
behavior of a system. |
| 5.2 |
a. |
| 5.3 |
Figure
5.23 presents an activity diagram for a
deposit transaction. The diagram models the actions that occur after the user
chooses the deposit option from the main menu and before the ATM returns the
user to the main menu. Recall that part of receiving a deposit amount from the
user involves converting an integer number of cents to a dollar amount. Also
recall that crediting a deposit amount to an account involves increasing only
the totalBalance attribute of the user's Account object. The bank updates the availableBalance attribute
of the user's Account object only after
confirming the amount of cash in the deposit envelope and after the enclosed
checks clear—this occurs independently of the ATM system.
|