(Optional) Software Engineering Case Study: Collaboration Among Objects in the ATM System

(Optional) Software Engineering Case Study Collaboration Among Objects in the ATM System

When two objects communicate with each other to accomplish a task, they are said to collaborate. A collaboration consists of an object of one class sending a message to an object of another class. Messages are sent in C# via method calls. In this section, we concentrate on the collaborations (interactions) among the objects in our ATM system.

In Section 7.15, we determined many of the operations of the classes in our system. In this section, we concentrate on the messages that invoke these operations. To identify the collaborations in the system, we return to the requirements document of Section 3.10. Recall that this document specifies the activities that occur during an ATM session (e.g., authenticating a user, performing transactions). The steps used to describe how the system must perform each of these tasks are our first indication of the collaborations in our system. As we proceed through this and the remaining Software Engineering Case Study sections, we may discover additional collaborations.

Identifying the Collaborations in a System

We begin to identify the collaborations in the system by carefully reading the sections of the requirements document that specify what the ATM should do to authenticate a user and to perform each transaction type. For each action or step described in the requirements document, we decide which objects in our system must interact to achieve the desired result. We identify one object as the sending object (i.e., the object that sends the message) and another as the receiving object (i.e., the object that offers that operation to clients of the class). We then select one of the receiving object's operations (identified in Section 7.15) that must be invoked by the sending object to produce the proper behavior. For example, the ATM displays a welcome message when idle. We know that an object of class Screen displays a message to the user via its DisplayMessage operation. Thus, we decide that the system can display a welcome message by employing a collaboration between the ATM and the Screen in which the ATM sends a DisplayMessage message to the Screen by invoking the DisplayMessage operation of class Screen. [Note: To avoid repeating the phrase "an object of class...," we refer to each object simply by using its class name preceded by an article (e.g., "a," "an" or "the")for example, "the ATM" refers to an object of class ATM.]

Figure 8.24 lists the collaborations that can be derived from the requirements document. For each sending object, we list the collaborations in the order in which they are discussed in the requirements document. We list each collaboration involving a unique sender, message and recipient only once, even though the collaboration may occur several times during an ATM session. For example, the first row in Fig. 8.24 indicates that the ATM collaborates with the Screen whenever the ATM needs to display a message to the user.

Figure 8.24. Collaborations in the ATM system.

(This item is displayed on page 380 in the print version)

An object of class...

sends the message...

to an object of class...

ATM

DisplayMessage

Screen

 

GetInput

Keypad

 

AuthenticateUser

BankDatabase

 

Execute

BalanceInquiry

 

Execute

Withdrawal

 

Execute

Deposit

BalanceInquiry

GetAvailableBalance

BankDatabase

 

GetTotalBalance

BankDatabase

 

DisplayMessage

Screen

Withdrawal

DisplayMessage

Screen

 

GetInput

Keypad

 

GetAvailableBalance

BankDatabase

 

IsSufficientCashAvailable

CashDispenser

 

Debit

BankDatabase

 

DispenseCash

CashDispenser

Deposit

DisplayMessage

Screen

 

GetInput

Keypad

 

IsDepositEnvelopeReceived

DepositSlot

 

Credit

BankDatabase

BankDatabase

ValidatePIN

Account

 

AvailableBalance (get)

Account

 

TotalBalance (get)

Account

 

Debit

Account

 

Credit

Account

Let's consider the collaborations in Fig. 8.24. Before allowing a user to perform any transactions, the ATM must prompt the user to enter an account number, then to enter a PIN. It accomplishes each of these tasks by sending a DisplayMessage message to the Screen. Both of these actions refer to the same collaboration between the ATM and the Screen, which is already listed in Fig. 8.24. The ATM obtains input in response to a prompt by sending a GetInput message to the Keypad. Next the ATM must determine whether the user-specified account number and PIN match those of an account in the database. It does so by sending an AuthenticateUser message to the BankDatabase. Recall that the BankDatabase cannot authenticate a user directlyonly the user's Account (i.e., the Account that contains the account number specified by the user) can access the user's PIN to authenticate the user. Figure 8.24 therefore lists a collaboration in which the BankDatabase sends a ValidatePIN message to an Account.

After the user is authenticated, the ATM displays the main menu by sending a series of DisplayMessage messages to the Screen and obtains input containing a menu selection by sending a GetInput message to the Keypad. We have already accounted for these collaborations. After the user chooses a type of transaction to perform, the ATM executes the transaction by sending an Execute message to an object of the appropriate transaction class (i.e., a BalanceInquiry, a Withdrawal or a Deposit). For example, if the user chooses to perform a balance inquiry, the ATM sends an Execute message to a BalanceInquiry.

Further examination of the requirements document reveals the collaborations involved in executing each transaction type. A BalanceInquiry retrieves the amount of money available in the user's account by sending a GetAvailableBalance message to the BankDatabase, which sends a get message to an Account's AvailableBalance property to access the available balance. Similarly, the BalanceInquiry retrieves the amount of money on deposit by sending a GetTotalBalance message to the BankDatabase, which sends a get message to an Account's TotalBalance property to access the total balance on deposit. To display both measures of the user's balance at the same time, the BalanceInquiry sends DisplayMessage messages to the Screen.

A Withdrawal sends DisplayMessage messages to the Screen to display a menu of standard withdrawal amounts (i.e., $20, $40, $60, $100, $200). The Withdrawal sends a GetInput message to the Keypad to obtain the user's menu selection. Next, the Withdrawal determines whether the requested withdrawal amount is less than or equal to the user's account balance. The Withdrawal obtains the amount of money available in the user's account by sending a GetAvailableBalance message to the BankDatabase. The Withdrawal then tests whether the cash dispenser contains enough cash by sending an IsSufficientCashAvailable message to the CashDispenser. A Withdrawal sends a Debit message to the BankDatabase to decrease the user's account balance. The BankDatabase in turn sends the same message to the appropriate Account. Recall that debiting an Account decreases both the total balance and the available balance. To dispense the requested amount of cash, the Withdrawal sends a DispenseCash message to the CashDispenser. Finally, the Withdrawal sends a DisplayMessage message to the Screen, instructing the user to take the cash.

A Deposit responds to an Execute message first by sending a DisplayMessage message to the Screen to prompt the user for a deposit amount. The Deposit sends a GetInput message to the Keypad to obtain the user's input. The Deposit then sends a DisplayMessage message to the Screen to tell the user to insert a deposit envelope. To determine whether the deposit slot received an incoming deposit envelope, the Deposit sends an IsDepositEnvelopeReceived message to the DepositSlot. The Deposit updates the user's account by sending a Credit message to the BankDatabase, which subsequently sends a Credit message to the user's Account. Recall that crediting an Account increases the total balance but not the available balance.

Interaction Diagrams

Now that we have identified a set of possible collaborations between the objects in our ATM system, let us graphically model these interactions. The UML provides several types of interaction diagrams that model the behavior of a system by modeling how objects interact with one another. The communication diagram emphasizes which objects participate in collaborations. [Note: Communication diagrams were called collaboration diagrams in earlier versions of the UML.] Like the communication diagram, the sequence diagram shows collaborations among objects, but it emphasizes when messages are sent between objects.

Communication Diagrams

Figure 8.25 shows a communication diagram that models the ATM executing a BalanceInquiry. Objects are modeled in the UML as rectangles containing names in the form objectName : ClassName. In this example, which involves only one object of each type, we disregard the object name and list only a colon followed by the class name. Specifying the name of each object in a communication diagram is recommended when modeling multiple objects of the same type. Communicating objects are connected with solid lines, and messages are passed between objects along these lines in the direction shown by arrows with filled arrowheads. The name of the message, which appears next to the arrow, is the name of an operation (i.e., a method) belonging to the receiving objectthink of the name as a service that the receiving object provides to sending objects (its "clients").

Figure 8.25. Communication diagram of the ATM executing a balance inquiry.

(This item is displayed on page 381 in the print version)

The filled arrow in Fig. 8.25 represents a messageor synchronous callin the UML and a method call in C#. This arrow indicates that the flow of control is from the sending object (the ATM) to the receiving object (a BalanceInquiry). Since this is a synchronous call, the sending object cannot send another message, or do anything at all, until the receiving object processes the message and returns control (and possibly a return value) to the sending object. The sender just waits. For example, in Fig. 8.25, the ATM calls method Execute of a BalanceInquiry and cannot send another message until Execute finishes and returns control to the ATM. [Note: If this were an asynchronous call, represented by a stick arrowhead, the sending object would not have to wait for the receiving object to return controlit would continue sending additional messages immediately following the asynchronous call. Such calls are beyond the scope of this book.]

Sequence of Messages in a Communication Diagram

Figure 8.26 shows a communication diagram that models the interactions among objects in the system when an object of class BalanceInquiry executes. We assume that the object's accountNumber attribute contains the account number of the current user. The collaborations in Fig. 8.26 begin after the ATM sends an Execute message to a BalanceInquiry (i.e., the interaction modeled in Fig. 8.25). The number to the left of a message name indicates the order in which the message is passed. The sequence of messages in a communication diagram progresses in numerical order from least to greatest. In this diagram, the numbering starts with message 1 and ends with message 3. The BalanceInquiry first sends a GetAvailableBalance message to the BankDatabase (message 1), then sends a GetTotalBalance message to the BankDatabase (message 2). Within the parentheses following a message name, we can specify a comma-separated list of the names of the arguments sent with the message (i.e., arguments in a C# method call)the BalanceInquiry passes attribute accountNumber with its messages to the BankDatabase to indicate which Account's balance information to retrieve. Recall from Fig. 7.22 that operations GetAvailableBalance and GetTotalBalance of class BankDatabase each require a parameter to identify an account. The BalanceInquiry next displays the available balance and the total balance to the user by passing a DisplayMessage message to the Screen (message 3) that includes a parameter indicating the message to be displayed.

Figure 8.26. Communication diagram for executing a BalanceInquiry.

(This item is displayed on page 382 in the print version)

Note that Fig. 8.26 models two additional messages passing from the BankDatabase to an Account (message 1.1 and message 2.1). To provide the ATM with the two balances of the user's Account (as requested by messages 1 and 2), the BankDatabase must send get messages to the Account's AvailableBalance and TotalBalance properties. A message passed within the handling of another message is called a nested message. The UML recommends using a decimal numbering scheme to indicate nested messages. For example, message 1.1 is the first message nested in message 1the BankDatabase sends the get message to the Account's AvailableBalance property during BankDatabase's processing of a GetAvailableBalance message. [Note: If the BankDatabase needed to pass a second nested message while processing message 1, the second message would be numbered 1.2.] A message may be passed only when all the nested messages from the previous message have been passed. For example, the BalanceInquiry passes message 3 to the Screen only after messages 2 and 2.1 have been passed, in that order.

The nested numbering scheme used in communication diagrams helps clarify precisely when and in what context each message is passed. For example, if we numbered the five messages in Fig. 8.26 using a flat numbering scheme (i.e., 1, 2, 3, 4, 5), someone looking at the diagram might not be able to determine that BankDatabase passes the get message to an Account's AvailableBalance property (message 1.1) during the BankDatabase's processing of message 1, as opposed to after completing the processing of message 1. The nested decimal numbers make it clear that the get message (message 1.1) is passed to an Account's AvailableBalance property within the handling of the GetAvailableBalance message (message 1) by the BankDatabase.

Sequence Diagrams

Communication diagrams emphasize the participants in collaborations but model their timing a bit awkwardly. A sequence diagram helps model the timing of collaborations more clearly. Figure 8.27 shows a sequence diagram modeling the sequence of interactions that occur when a Withdrawal executes. The dotted line extending down from an object's rectangle is that object's lifeline, which represents the progression of time. Actions typically occur along an object's lifeline in chronological order from top to bottoman action near the top happens before one near the bottom.

Figure 8.27. Sequence diagram that models a Withdrawal executing.

Message passing in sequence diagrams is similar to message passing in communication diagrams. An arrow with a filled arrowhead extending from the sending object to the receiving object represents a message between two objects. The arrowhead points to an activation on the receiving object's lifeline. An activation, shown as a thin vertical rectangle, indicates that an object is executing. When an object returns control, a return message, represented as a dashed line with a stick arrowhead, extends from the activation of the object returning control to the activation of the object that initially sent the message. To eliminate clutter, we omit the return-message arrowsthe UML allows this practice to make diagrams more readable. Like communication diagrams, sequence diagrams can indicate message parameters between the parentheses following a message name.

The sequence of messages in Fig. 8.27 begins when a Withdrawal prompts the user to choose a withdrawal amount by sending a DisplayMessage message to the Screen. The Withdrawal then sends a GetInput message to the Keypad, which obtains input from the user. We have already modeled the control logic involved in a Withdrawal in the activity diagram of Fig. 6.28, so we do not show this logic in the sequence diagram of Fig. 8.27. Instead, we model the best-case scenario, in which the balance of the user's account is greater than or equal to the chosen withdrawal amount, and the cash dispenser contains a sufficient amount of cash to satisfy the request. For information on how to model control logic in a sequence diagram, please refer to the Web resources and recommended readings listed at the end of Section 3.10.

After obtaining a withdrawal amount, the Withdrawal sends a GetAvailableBalance message to the BankDatabase, which in turn sends a get message to the Account's AvailableBalance property. Assuming that the user's account has enough money available to permit the transaction, the Withdrawal next sends an IsSufficientCashAvailable message to the CashDispenser. Assuming that there is enough cash available, the Withdrawal decreases the balance of the user's account (both the total balance and the available balance) by sending a Debit message to the BankDatabase. The BankDatabase responds by sending a Debit message to the user's Account. Finally, the Withdrawal sends a DispenseCash message to the CashDispenser and a DisplayMessage message to the Screen, telling the user to remove the cash from the machine.

We have identified collaborations among objects in the ATM system and modeled some of these collaborations using UML interaction diagramscommunication diagrams and sequence diagrams. In the next Software Engineering Case Study section (Section 9.17), we enhance the structure of our model to complete a preliminary object-oriented design, then we begin implementing the ATM system in C#.

Software Engineering Case Study Self-Review Exercises

8.1

A(n) __________ consists of an object of one class sending a message to an object of another class.

  1. association
  2. aggregation
  3. collaboration
  4. composition
8.2

Which form of interaction diagram emphasizes what collaborations occur? Which form emphasizes when collaborations occur?

8.3

Create a sequence diagram that models the interactions among objects in the ATM system that occur when a Deposit executes successfully. Explain the sequence of messages modeled by the diagram.

Answers to Software Engineering Case Study Self-Review Exercises

8.1

c.

8.2

Communication diagrams emphasize what collaborations occur. Sequence diagrams emphasize when collaborations occur.

8.3

Figure 8.28 presents a sequence diagram that models the interactions between objects in the ATM system that occur when a Deposit executes successfully. Figure 8.28 indicates that a Deposit first sends a DisplayMessage message to the Screen (to ask the user to enter a deposit amount). Next, the Deposit sends a GetInput message to the Keypad to receive the amount the user will be depositing. The Deposit then prompts the user (to insert a deposit envelope) by sending a DisplayMessage message to the Screen. The Deposit next sends an IsDepositEnvelopeReceived message to the DepositSlot to confirm that the deposit envelope has been received by the ATM. Finally, the Deposit increases the total balance (but not the available balance) of the user's Account by sending a Credit message to the BankDatabase. The BankDatabase responds by sending the same message to the user's Account.

Figure 8.28. Sequence diagram that models a Deposit executing.

Preface

Index

    Introduction to Computers, the Internet and Visual C#

    Introduction to the Visual C# 2005 Express Edition IDE

    Introduction to C# Applications

    Introduction to Classes and Objects

    Control Statements: Part 1

    Control Statements: Part 2

    Methods: A Deeper Look

    Arrays

    Classes and Objects: A Deeper Look

    Object-Oriented Programming: Inheritance

    Polymorphism, Interfaces & Operator Overloading

    Exception Handling

    Graphical User Interface Concepts: Part 1

    Graphical User Interface Concepts: Part 2

    Multithreading

    Strings, Characters and Regular Expressions

    Graphics and Multimedia

    Files and Streams

    Extensible Markup Language (XML)

    Database, SQL and ADO.NET

    ASP.NET 2.0, Web Forms and Web Controls

    Web Services

    Networking: Streams-Based Sockets and Datagrams

    Searching and Sorting

    Data Structures

    Generics

    Collections

    Appendix A. Operator Precedence Chart

    Appendix B. Number Systems

    Appendix C. Using the Visual Studio 2005 Debugger

    Appendix D. ASCII Character Set

    Appendix E. Unicode®

    Appendix F. Introduction to XHTML: Part 1

    Appendix G. Introduction to XHTML: Part 2

    Appendix H. HTML/XHTML Special Characters

    Appendix I. HTML/XHTML Colors

    Appendix J. ATM Case Study Code

    Appendix K. UML 2: Additional Diagram Types

    Appendix L. Simple Types

    Index



    Visual C# How to Program
    Visual C# 2005 How to Program (2nd Edition)
    ISBN: 0131525239
    EAN: 2147483647
    Year: 2004
    Pages: 600

    Flylib.com © 2008-2020.
    If you may any questions please contact us: flylib@qtcs.net