(Optional) Software Engineering Case Study: Identifying Class Operations in the ATM System

(Optional) Software Engineering Case Study Identifying Class Operations in the ATM System

In the "Software Engineering Case Study" sections at the ends of Chapters 46, we performed the first few steps in the object-oriented design of our ATM system. In Chapter 4, we identified the classes that we will likely need to implement, and we created our first class diagram. In Chapter 5, we described some attributes of our classes. In Chapter 6, we examined our objects' states and modeled their state transitions and activities. In this section, we determine some of the class operations (or behaviors) needed to implement the ATM system.

Identifying Operations

An operation is a service that objects of a class provide to clients of the class. Consider the operations of some real-world objects. A radio's operations include setting its station and volume (typically invoked by a person adjusting the radio's controls). A car's operations include accelerating (invoked by the driver pressing the accelerator pedal), decelerating (invoked by the driver pressing the brake pedal or releasing the gas pedal), turning, and shifting gears. Software objects can offer operations as wellfor example, a software graphics object might offer operations for drawing a circle, drawing a line and drawing a square. A spreadsheet software object might offer operations like printing the spreadsheet, totaling the elements in a row or column and graphing information in the spreadsheet as a bar chart or pie chart.

We can derive many of the operations of the classes in our ATM system by examining the verbs and verb phrases in the requirements document. We then relate each of these to particular classes in our system (Fig. 7.20). The verb phrases in Fig. 7.20 help us determine the operations of our classes.

Figure 7.20. Verbs and verb phrases for each class in the ATM system.

Class

Verbs and verb phrases

ATM

executes financial transactions

BalanceInquiry

[none in the requirements document]

Withdrawal

[none in the requirements document]

Deposit

[none in the requirements document]

BankDatabase

authenticates a user, retrieves an account balance, credits an account, debits an account

Account

retrieves an account balance, credits a deposit amount to an account, debits a withdrawal amount to an account

Screen

displays a message to the user

Keypad

receives numeric input from the user

CashDispenser

dispenses cash, indicates whether it contains enough cash to satisfy a withdrawal request

DepositSlot

receives a deposit envelope

 

Modeling Operations

To identify operations, we examine the verb phrases listed for each class in Fig. 7.20. The "executes financial transactions" phrase associated with class ATM implies that class ATM instructs transactions to execute. Therefore, classes BalanceInquiry, Withdrawal and Deposit each need an operation to provide this service to the ATM. We place this operation (which we have named Execute) in the third compartment of the three transaction classes in the updated class diagram of Fig. 7.21. During an ATM session, the ATM object will invoke the Execute operation of each transaction object to tell it to execute.

Figure 7.21. Classes in the ATM system with attributes and operations.

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

The UML represents operations (which are implemented as methods in C#) by listing the operation name, followed by a comma-separated list of parameters in parentheses, a colon and the return type:

operationName( parameter1, parameter2, ..., parameterN ) : returnType

Each parameter in the comma-separated parameter list consists of a parameter name, followed by a colon and the parameter type:

parameterName : parameterType

For the moment, we do not list the parameters of our operationswe will identify and model the parameters of some of the operations shortly. For some of the operations, we do not yet know the return types, so we also omit them from the diagram. These omissions are perfectly normal at this point. As our design and implementation proceed, we will add the remaining return types.

Operations of Class BankDatabase and Class Account

Figure 7.20 lists the phrase "authenticates a user" next to class BankDatabasethe database is the object that contains the account information necessary to determine whether the account number and PIN entered by a user match those of an account at the bank. Therefore, class BankDatabase needs an operation that provides an authentication service to the ATM. We place the operation AuthenticateUser in the third compartment of class BankDatabase (Fig. 7.21). However, an object of class Account, not class BankDatabase, stores the account number and PIN that must be accessed to authenticate a user, so class Account must provide a service to validate a PIN obtained through user input against a PIN stored in an Account object. Therefore, we add a ValidatePIN operation to class Account. Note that we specify a return type of bool for the AuthenticateUser and ValidatePIN operations. Each operation returns a value indicating either that the operation was successful in performing its task (i.e., a return value of true) or that it was not successful (i.e., a return value of false).

Figure 7.20 lists several additional verb phrases for class BankDatabase: "retrieves an account balance," "credits an account" and "debits an account." Like "authenticates a user," these remaining phrases refer to services that the database must provide to the ATM, because the database holds all the account data used to authenticate a user and perform ATM transactions. However, objects of class Account actually perform the operations to which these phrases refer. Thus, class BankDatabase and class Account both need operations that correspond to each of these phrases. Recall from Section 4.11 that, because a bank account contains sensitive information, we do not allow the ATM to access accounts directly. The database acts as an intermediary between the ATM and the account data, preventing unauthorized access. As we will see in Section 8.14, class ATM invokes the operations of class BankDatabase, each of which in turn invokes corresponding operations (which are get accessors of read-only properties) in class Account.

The phrase "retrieves an account balance" suggests that classes BankDatabase and Account each need an operation that gets the balance. However, recall that Fig. 5.19 specified two attributes in class Account to represent a balanceavailableBalance and totalBalance. A balance inquiry requires access to both balance attributes so that it can display them to the user, but a withdrawal needs to check only the value of availableBalance. To allow objects in the system to obtain these balance attributes individually from a specific Account object in the BankDatabase, we add operations GetAvailableBalance and GetTotalBalance to the third compartment of class BankDatabase (Fig. 7.21). We specify a return type of decimal for each of these operations, because the balances that they retrieve are of type decimal.

Once the BankDatabase knows which Account to access, the BankDatabase must be able to obtain each balance attribute individually from that Account. For this purpose, we could add operations GetAvailableBalance and GetTotalBalance to the third compartment of class Account (Fig. 7.21). However, in C#, simple operations such as getting the value of an attribute are typically performed by a property's get accessor (at least when that particular class "owns" the underlying attribute). This design is for a C# application, so rather than modeling operations GetAvailableBalance and GetTotalBalance, we model decimal properties AvailableBalance and TotalBalance in class Account. Properties are placed in the second compartment of a class diagram. These properties replace the availableBalance and totalBalance attributes that we modeled for class Account in Fig. 5.19. Recall from Chapter 4 that a property's accessors are impliedthus, they are not modeled in a class diagram. Figure 7.20 does not mention the need to set the balances, so Fig. 7.21 shows properties AvailableBalance and TotalBalance as read-only properties (i.e., they have only get accessors). To indicate a read-only property in the UML, we follow the property's type with "{readOnly}."

You may be wondering why we modeled AvailableBalance and TotalBalance properties in class Account, but modeled GetAvailableBalance and GetTotalBalance operations in class BankDatabase. Since there can be many Account objects in the BankDatabase, the ATM must specify which Account to access when invoking BankDatabase operations GetAvailableBalance and GetTotalBalance. The ATM does this by passing an account number argument to each BankDatabase operation. The get accessors of the properties you have seen in C# code cannot receive arguments. Thus, we modeled GetAvailableBalance and GetTotalBalance as operations in class BankDatabase so that we could specify parameters to which the ATM can pass arguments. Also, the underlying balance attributes are not owned by the BankDatabase, so get accessors are not appropriate here. We discuss the parameters for the BankDatabase operations shortly.

The phrases "credits an account" and "debits from an account" indicate that classes BankDatabase and Account must perform operations to update an account during deposits and withdrawals, respectively. We therefore assign Credit and Debit operations to classes BankDatabase and Account. You may recall that crediting an account (as in a deposit) adds an amount only to the Account's total balance. Debiting an account (as in a withdrawal), on the other hand, subtracts the amount from both the total and available balances. We hide these implementation details inside class Account. This is a good example of encapsulation and information hiding.

If this were a real ATM system, classes BankDatabase and Account would also provide a set of operations to allow another banking system to update a user's account balance after either confirming or rejecting all or part of a deposit. Operation ConfirmDepositAmount, for example, would add an amount to the Account's available balance, thus making deposited funds available for withdrawal. Operation RejectDepositAmount would subtract an amount from the Account's total balance to indicate that a specified amount, which had recently been deposited through the ATM and added to the Account's total balance, was invalidated (or checks may have "bounced"). The bank would invoke operation RejectDepositAmout after determining either that the user failed to include the correct amount of cash or that any checks did not clear (i.e., they "bounced"). While adding these operations would make our system more complete, we do not include them in our class diagrams or implementation because they are beyond the scope of the case study.

Operations of Class Screen

Class Screen "displays a message to the user" at various times in an ATM session. All visual output occurs through the screen of the ATM. The requirements document describes many types of messages (e.g., a welcome message, an error message, a thank-you message) that the screen displays to the user. The requirements document also indicates that the screen displays prompts and menus to the user. However, a prompt is really just a message describing what the user should input next, and a menu is essentially a type of prompt consisting of a series of messages (i.e., menu options) displayed consecutively. Therefore, rather than provide class Screen with an individual operation to display each type of message, prompt and menu, we simply create one operation that can display any message specified by a parameter. We place this operation (DisplayMessage) in the third compartment of class Screen in our class diagram (Fig. 7.21). Note that we do not worry about the parameter of this operation at this timewe model the parameter momentarily.

Operations of Class Keypad

From the phrase "receives numeric input from the user" listed by class Keypad in Fig. 7.20, we conclude that class Keypad should perform a GetInput operation. Because the ATM's keypad, unlike a computer keyboard, contains only the numbers 09, we specify that this operation returns an integer value. Recall from the requirements document that in different situations, the user may be required to enter a different type of number (e.g., an account number, a PIN, the number of a menu option, a deposit amount as a number of cents). Class Keypad simply obtains a numeric value for a client of the classit does not determine whether the value meets any specific criteria. Any class that uses this operation must verify that the user entered appropriate numbers and, if not, display error messages via class Screen). [Note: When we implement the system, we simulate the ATM's keypad with a computer keyboard, and for simplicity, we assume that the user does not enter nonnumeric input using keys on the computer keyboard that do not appear on the ATM's keypad. In Chapter 16, Strings, Characters and Regular Expressions, you'll see how to examine inputs to determine if they are of particular types.]

Operations of Class CashDispenser and Class DepositSlot

Figure 7.20 lists "dispenses cash" for class CashDispenser. Therefore, we create operation DispenseCash and list it under class CashDispenser in Fig. 7.21. Class CashDispenser also "indicates whether it contains enough cash to satisfy a withdrawal request." Thus, we include IsSufficientCashAvailable, an operation that returns a value of type bool, in class CashDispenser. Figure 7.20 also lists "receives a deposit envelope" for class DepositSlot. The deposit slot must indicate whether it received an envelope, so we place the operation IsEnvelopeReceived, which returns a bool value, in the third compartment of class DepositSlot. [Note: A real hardware deposit slot would most likely send the ATM a signal to indicate that an envelope was received. We simulate this behavior, however, with an operation in class DepositSlot that class ATM can invoke to find out whether the deposit slot received an envelope.]

Operations of Class ATM

We do not list any operations for class ATM at this time. We are not yet aware of any services that class ATM provides to other classes in the system. When we implement the system in C# (Appendix J, ATM Case Study Code), however, operations of this class, and additional operations of the other classes in the system, may become apparent.

Identifying and Modeling Operation Parameters

So far, we have not been concerned with the parameters of our operationswe have attempted to gain only a basic understanding of the operations of each class. Let's now take a closer look at some operation parameters. We identify an operation's parameters by examining what data the operation requires to perform its assigned task.

Consider the AuthenticateUser operation of class BankDatabase. To authenticate a user, this operation must know the account number and PIN supplied by the user. Thus we specify that operation AuthenticateUser takes int parameters userAccountNumber and userPIN, which the operation must compare to the account number and PIN of an Account object in the database. We prefix these parameter names with user to avoid confusion between the operation's parameter names and the attribute names that belong to class Account. We list these parameters in the class diagram in Fig. 7.22, which models only class BankDatabase. [Note: It is perfectly normal to model only one class in a class diagram. In this case, we are most concerned with examining the parameters of this particular class, so we omit the other classes. In class diagrams later in the case study, parameters are no longer the focus of our attention, so we omit the parameters to save space. Remember, however, that the operations listed in these diagrams still have parameters.]

Figure 7.22. Class BankDatabase with operation parameters.

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

Recall that the UML models each parameter in an operation's comma-separated parameter list by listing the parameter name, followed by a colon and the parameter type. Figure 7.22 thus specifies, for example, that operation AuthenticateUser takes two parametersuserAccountNumber and userPIN, both of type int.

Class BankDatabase operations GetAvailableBalance, GetTotalBalance, Credit and Debit also each require a userAccountNumber parameter to identify the account to which the database must apply the operations, so we include these parameters in the class diagram. In addition, operations Credit and Debit each require a decimal parameter amount to specify the amount of money to be credited or debited, respectively.

The class diagram in Fig. 7.23 models the parameters of class Account's operations. Operation ValidatePIN requires only a userPIN parameter, which contains the user-specified PIN to be compared with the PIN associated with the account. Like their counterparts in class BankDatabase, operations Credit and Debit in class Account each require a decimal parameter amount that indicates the amount of money involved in the operation. Note that class Account's operations do not require an account number parametereach of these operations can be invoked only on the Account object in which they are executing, so including a parameter to specify an Account is unnecessary.

Figure 7.23. Class Account with operation parameters.

Figure 7.24 models class Screen with a parameter specified for operation DisplayMessage. This operation requires only string parameter message, which indicates the text to be displayed.

Figure 7.24. Class Screen with an operation parameter.

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

The class diagram in Fig. 7.25 specifies that operation DispenseCash of class CashDispenser takes decimal parameter amount to indicate the amount of cash (in dollars) to be dispensed. Operation IsSufficientCashAvailable also takes decimal parameter amount to indicate the amount of cash in question.

Figure 7.25. Class CashDispenser with operation parameters.

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

Note that we do not discuss parameters for operation Execute of classes BalanceInquiry, Withdrawal and Deposit, operation GetInput of class Keypad and operation IsEnvelopeReceived of class DepositSlot. At this point in our design process, we cannot determine whether these operations require additional data to perform their tasks, so we leave their parameter lists empty. As we progress through the case study, we may decide to add parameters to these operations.

In this section, we have determined many of the operations performed by the classes in the ATM system. We have identified the parameters and return types of some of the operations. As we continue our design process, the number of operations belonging to each class may varywe might find that new operations are needed or that some current operations are unnecessaryand we might determine that some of our class operations need additional parameters and different return types. Again, all of this is perfectly normal.

Software Engineering Case Study Self-Review Exercises

7.1

Which of the following is not a behavior?

  1. reading data from a file
  2. printing output
  3. text output
  4. obtaining input from the user
7.2

If you were to add to the ATM system an operation that returns the amount attribute of class Withdrawal, how and where would you specify this operation in the class diagram of Fig. 7.21?

7.3

Describe the meaning of the following operation listing that might appear in a class diagram for an object-oriented design of a calculator:

Add( x : int, y : int ) : int

Answers to Software Engineering Case Study Self-Review Exercises

7.1

c.

7.2

An operation that retrieves the amount attribute of class Withdrawal would typically be implemented as a get accessor of a property of class Withdrawal. The following would replace attribute amount in the attribute (i.e., second) compartment of class Withdrawal:

«property» Amount : decimal
7.3

This is an operation named Add that takes int parameters x and y and returns an int value. This operation would most likely sum its parameters x and y and return the result.

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