1

ATM Case Study

2005 Pearson Education, Inc. All rights reserved.

OBJECTIVES
..

2005 Pearson Education, Inc. All rights reserved.

2
Requirements

2005 Pearson Education, Inc. All rights reserved.

2.9 (Optional) Software Engineering Case Study: Examining the Requirements Document Object-oriented design (OOD) process using UML
Chapters 3 to 8, 10

Object-oriented programming (OOP) implementation

Appendix J

2005 Pearson Education, Inc. All rights reserved.

2.9 (Optional) Software Engineering Case Study (Cont.)

Requirements Document
New automated teller machine (ATM) Allows basic financial transaction
View balance, withdraw cash, deposit funds

User interface
Display screen, keypad, cash dispenser, deposit slot

ATM session
Authenticate user, execute financial transaction

2005 Pearson Education, Inc. All rights reserved.

Fig. 2.17 | Automated teller machine user interface.

2005 Pearson Education, Inc. All rights reserved.

Fig. 2.18 | ATM main menu.

2005 Pearson Education, Inc. All rights reserved.

Fig. 2.19 | ATM withdrawal menu.

2005 Pearson Education, Inc. All rights reserved.

2.9 (Optional) Software Engineering Case Study (Cont.)

Analyzing the ATM System
Requirements gathering Software life cycle
Waterfall model Interactive model

Use case modeling

Use case Diagram

Model the interactions between clients and its use cases Actor
External entity

2005 Pearson Education, Inc. All rights reserved.

10

Fig. 2.20 | Use case diagram for the ATM system from the user's perspective.

2005 Pearson Education, Inc. All rights reserved.

11

Fig. 2.21 | Use case diagram for a modified version of our ATM system that also allows

users to transfer money between accounts.

2005 Pearson Education, Inc. All rights reserved.

12

2.9 (Optional) Software Engineering Case Study (Cont.)

UML diagram types
Model system structure
Class diagram Models classes, or building blocks of a system screen, keypad, cash dispenser, deposit slot.

2005 Pearson Education, Inc. All rights reserved.

13

2.9 (Optional) Software Engineering Case Study (Cont.)

Model system behavior
Use case diagrams Model interactions between user and a system State machine diagrams Model the ways in which an object changes state Activity diagrams Models an objects activity during program execution Communication diagrams (collaboration diagrams) Models the interactions among objects Emphasize what interactions occur Sequence diagrams Models the interactions among objects Emphasize when interactions occur

2005 Pearson Education, Inc. All rights reserved.

14

3
Begin Designing the ATM System
2005 Pearson Education, Inc. All rights reserved.

15

3.10 (Optional) Software Engineering Case Study: Identifying the Classes in a Requirements Document

Begin designing the ATM system

Analyze the nouns and noun phrases Introduce UML class diagrams

2005 Pearson Education, Inc. All rights reserved.

16

Identifying the Classes in a System

Key nouns and noun phrases in requirements document

Some are attributes of other classes Some do not correspond to parts of the system Some are classes
To be represented by UML class diagrams

2005 Pearson Education, Inc. All rights reserved.

17

Nouns and noun phrases in the requirements document

bank ATM user customer transaction account balance money / funds screen keypad cash dispenser $20 bill / cash deposit slot deposit envelope account number PIN bank database balance inquiry withdrawal deposit

Fig. 3.19 | Nouns and noun phrases in the requirements document.

2005 Pearson Education, Inc. All rights reserved.

18

Modeling Classes

UML class diagrams

Top compartment contains name of the class Middle compartment contains classs attributes or instance variables Bottom compartment contains classs operations or methods

2005 Pearson Education, Inc. All rights reserved.

19

Fig. 3.20 | Representing a class in the UML using a class diagram.

2005 Pearson Education, Inc. All rights reserved.

20

Modeling Classes

UML class diagrams

Allows suppression of class attributes and operations
Called an elided diagram

Solid line that connects two classes represents an association

numbers near end of each line are multiplicity values

2005 Pearson Education, Inc. All rights reserved.

21

Fig. 3.21 | Class diagram showing an association among classes.

2005 Pearson Education, Inc. All rights reserved.

22

Symbol
0 1 m 0..1 m, n m..n * 0..* 1..*

Meaning
None One An integer value Zero or one m or n At least m, but not more than n Any non-negative integer (zero or more) Zero or more (identical to *) One or more

Fig. 3.22 | Multiplicity types.

2005 Pearson Education, Inc. All rights reserved.

23

Modeling Classes
UML class diagrams
Solid diamonds attached to association lines indicate a composition relationship Hollow diamonds indicate aggregation a weaker form of composition

2005 Pearson Education, Inc. All rights reserved.

24

Fig. 3.23 | Class diagram showing composition relationships.

2005 Pearson Education, Inc. All rights reserved.

25

Fig. 3.24 | Class diagram for the ATM system model.

2005 Pearson Education, Inc. All rights reserved.

26

Fig. 3.25 | Class diagram showing composition relationships of a class Car.

2005 Pearson Education, Inc. All rights reserved.

27

Fig. 3.26 | Class diagram for the ATM system model including class Deposit.

2005 Pearson Education, Inc. All rights reserved.

28

4
Identifying Class Attributes
2005 Pearson Education, Inc. All rights reserved.

29

4.15 Identifying Class Attributes

Identifying attributes
Look for descriptive words and phrases in the requirements document Create attributes and assign them to classes Each attribute is given an attribute type Some attributes may have an initial value Some classes may end up without any attributes
Additional attributes may be added later on as the design and implementation process continues

Reference-type attributes are modeled more clearly as associations

2005 Pearson Education, Inc. All rights reserved.

30

Class
ATM BalanceInquiry Withdrawal Deposit BankDatabase Account Screen Keypad CashDispenser DepositSlot

Descriptive words and phrases

user is authenticated account number account number amount account number amount [no descriptive words or phrases] account number PIN Balance [no descriptive words or phrases] [no descriptive words or phrases] begins each day loaded with 500 $20 bills [no descriptive words or phrases]

Fig. 4.23 | Descriptive words and phrases from the ATM requirements.

2005 Pearson Education, Inc. All rights reserved.

31

Software Engineering Observation 4.6

At early stages in the design process, classes often lack attributes (and operations). Such classes should not be eliminated, however, because attributes (and operations) may become evident in the later phases of design and implementation.

2005 Pearson Education, Inc. All rights reserved.

32

Fig. 4.24 | Classes with attributes.

2005 Pearson Education, Inc. All rights reserved.

33

5
Identifying Objects State and Activities

2005 Pearson Education, Inc. All rights reserved.

34

5.11 (Optional) Software Engineering Case Study: Identifying Objects State and Activities
State Machine Diagrams
Commonly called state diagram Model several states of an object Show under what circumstances the object changes state Focus on system behavior UML representation
State Rounded rectangle Initial state Solid circle Transitions Arrows with stick arrowheads

2005 Pearson Education, Inc. All rights reserved.

35

Fig. 5.29 | State diagram for the ATM object.

2005 Pearson Education, Inc. All rights reserved.

36

Software Engineering Observation 5.5

Software designers do not generally create state diagrams showing every possible state and state transition for all attributesthere are simply too many of them. State diagrams typically show only key states and state transitions.

2005 Pearson Education, Inc. All rights reserved.

37

5.11 (Optional) Software Engineering Case Study (Cont.)

Activity Diagrams
Focus on system behavior Model an objects workflow during program execution Model the actions the object will perform and in what order UML representation
Action state ( rectangle with its left and right sides replaced by arcs curving outwards) Action order ( arrow with a stick arrowhead) Initial state (solid circle) Final state (solid circle enclosed in an open circle)

2005 Pearson Education, Inc. All rights reserved.

38

Fig. 5.30 | Activity diagram for a BalanceInquiry object.

2005 Pearson Education, Inc. All rights reserved.

39

Fig. 5.31 | Activity diagram for a withdrawal transaction.

2005 Pearson Education, Inc. All rights reserved.

40

Fig. 5.32 | Activity diagram for a deposit transaction.

2005 Pearson Education, Inc. All rights reserved.

41

6
Identifying Class Operations

2005 Pearson Education, Inc. All rights reserved.

42

6.14 (Optional) Identifying Class Operations

Identifying operations
Examine key verbs and verb phrases in the requirements document

Modeling operations in UML

Each operation is given an operation name, a parameter list and a return type:
operationName( parameter1, parameter2, , parameterN ) : return type Each parameter has a parameter name and a parameter type parameterName : parameterType

2005 Pearson Education, Inc. All rights reserved.

43

6.14 (Optional) Identifying Class Operations (Cont.)

Some operations may not have return types yet
Remaining return types will be added as design and implementation proceed

Identifying and modeling operation parameters

Examine what data the operation requires to perform its assigned task Additional parameters may be added later on

2005 Pearson Education, Inc. All rights reserved.

44

Class
ATM BalanceInquiry Withdrawal Deposit BankDatabase Account Screen Keypad CashDispenser DepositSlot

Verbs and verb phrases

executes financial transactions [none in the requirements document] [none in the requirements document] [none in the requirements document] authenticates a user, retrieves an account balance, credits a deposit amount to an account, debits a withdrawal amount from an account retrieves an account balance, credits a deposit amount to an account, debits a withdrawal amount from an account displays a message to the user receives numeric input from the user dispenses cash, indicates whether it contains enough cash to satisfy a withdrawal request receives a deposit envelope

Fig. 6.20 | Verbs and verb phrases for each class in the ATM system.

2005 Pearson Education, Inc. All rights reserved.

45

Fig. 6.21 | Classes in the ATM system with attributes and operations.

2005 Pearson Education, Inc. All rights reserved.

46

Fig. 6.22 | Class BankDatabase with operation parameters.

2005 Pearson Education, Inc. All rights reserved.

47

Fig. 6.23 | Class Account with operation parameters.

2005 Pearson Education, Inc. All rights reserved.

48

Fig. 6.24 | Class Screen with operation parameters.

2005 Pearson Education, Inc. All rights reserved.

49

Fig. 6.25 | Class CashDispenser with operation parameters.

2005 Pearson Education, Inc. All rights reserved.

50

7
Collaboration Among Objects

2005 Pearson Education, Inc. All rights reserved.

51

7.14 (Optional) Software Engineering Case Study: Collaboration Among Objects

Collaborations
When objects communicate to accomplish task
Accomplished by invoking operations (methods)

One object sends a message to another object

2005 Pearson Education, Inc. All rights reserved.

7.14 (Optional) Software Engineering Case Study (Cont.)

Identifying the collaborations in a system
Read requirements document to find
What ATM should do to authenticate a use What ATM should do to perform transactions

52

For each action, decide

Which objects must interact Sending object Receiving object

2005 Pearson Education, Inc. All rights reserved.

53

An object of class
ATM

sends the message

displayMessage getInput authenticateUser execute execute Execute

to an object of class
Screen Keypad BankDatabase BalanceInquiry Withdrawal Deposit BankDatabase BankDatabase Screen Screen Keypad BankDatabase CashDispenser BankDatabase CashDispenser Screen Keypad DepositSlot BankDatabase Account Account Account Account Account

BalanceInquiry getAvailableBalance getTotalBalance displayMessage Withdrawal displayMessage getInput getAvailableBalance isSufficientCashAvailable debit dispenseCash displayMessage getInput isEnvelopeReceived Credit validatePIN getAvailableBalance getTotalBalance debit Credit

Deposit

BankDatabase

Fig. 7.25 | Collaborations in the ATM system.

2005 Pearson Education, Inc. All rights reserved.

7.14 (Optional) Software Engineering Case Study (Cont.)

Interaction Diagrams
Model interactions use UML Communication diagrams
Also called collaboration diagrams Emphasize which objects participate in collaborations

54

Sequence diagrams
Emphasize when messages are sent between objects

2005 Pearson Education, Inc. All rights reserved.

7.14 (Optional) Software Engineering Case Study (Cont.)

Communication diagrams
Objects
Modeled as rectangles Contain names in the form objectName : className

55

Objects are connected with solid lines Messages are passed alone these lines in the direction shown by arrows Name of message appears next to the arrow

2005 Pearson Education, Inc. All rights reserved.

56

Fig. 7.26 | Communication diagram of the ATM executing a balance inquiry.

2005 Pearson Education, Inc. All rights reserved.

7.14 (Optional) Software Engineering Case Study (Cont.)

Sequence of messages in a communication diagram
Appear to the left of a message name Indicate the order in which the message is passed Process in numerical order from least to greatest

57

2005 Pearson Education, Inc. All rights reserved.

58

Fig. 7.27 | Communication diagram for executing a balance inquiry.

2005 Pearson Education, Inc. All rights reserved.

7.14 (Optional) Software Engineering Case Study (Cont.)

Sequence diagrams
Help model the timing of collaborations Lifeline
Dotted line extending down from an objects rectangle Represents the progression of time

59

Activation
Thin vertical rectangle Indicates that an object is executing

2005 Pearson Education, Inc. All rights reserved.

60

Fig. 7.28 | Sequence diagram that models a Withdrawal executing.

2005 Pearson Education, Inc. All rights reserved.

61

Fig. 7.29 | Sequence diagram that models a Deposit executing.

2005 Pearson Education, Inc. All rights reserved.

62

8
Starting to Program the Classes of the ATM System
2005 Pearson Education, Inc. All rights reserved.

63

8.18 (Optional) GUI and Graphics Case Study: Using Objects with Graphics
To create a consistent drawing that remains the same each time it is drawn
Store information about the displayed shapes so that they can be reproduced exactly the same way each time paintComponent is called

2005 Pearson Education, Inc. All rights reserved.

64

8.19 Starting to Program the Classes of the ATM System

Visibility
Attributes normally should be private, methods invoked by clients should be public Visibility markers in UML
A plus sign (+) indicates public visibility A minus sign (-) indicates private visibility

Navigability
Navigability arrows indicate in which direction an association can be traversed Bidirectional navigability
Associations with navigability arrows at both ends or no navigability arrows at all can be traversed in either direction
2005 Pearson Education, Inc. All rights reserved.

65

8.19 Starting to Program the Classes of the ATM System (Cont.)

Implementing the ATM system from its UML design (for each class)
Declare a public class with the name in the first compartment and an empty no-argument constructor Declare instance variables based on attributes in the second compartment Declare references to other objects based on associations described in the class diagram Declare the shells of the methods based on the operations in the third compartment
Use the return type void if no return type has been specified

2005 Pearson Education, Inc. All rights reserved.

66

Fig. 8.24 | Class diagram with visibility markers.

2005 Pearson Education, Inc. All rights reserved.

67

Fig. 8.25 | Class diagram with navigability arrows.

2005 Pearson Education, Inc. All rights reserved.

1 2 3 4 5 6 7 8

// Class Withdrawal represents an ATM withdrawal transaction public class Withdrawal { // no-argument constructor public Withdrawal() {

68

Class for Withdrawal

Outline

Empty no-argument constructor

withdrawal.java

} // end no-argument Withdrawal constructor } // end class Withdrawal

2005 Pearson Education, Inc. All rights reserved.

1 2 3 4 5 6 7 8 9 10 11

// Class Withdrawal represents an ATM withdrawal transaction public class Withdrawal { // attributes private int accountNumber; // account to withdraw funds from private double amount; // amount to withdraw

69

Outline

withdrawal.java

// no-argument constructor public Withdrawal() { } // end no-argument Withdrawal constructor

Declare instance variables

12 } // end class Withdrawal

2005 Pearson Education, Inc. All rights reserved.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

// Class Withdrawal represents an ATM withdrawal transaction public class Withdrawal { // attributes private int accountNumber; // account to withdraw funds from private double amount; // amount to withdraw // references to associated objects private Screen screen; // ATMs screen private Keypad keypad; // ATMs keypad private CashDispenser cashDispenser; // ATMs cash dispenser private BankDatabase bankDatabase; // account info database // no-argument constructor public Withdrawal() { } // end no-argument Withdrawal constructor

70

Outline

withdrawal.java

Declare references to other objects

18 } // end class Withdrawal

2005 Pearson Education, Inc. All rights reserved.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

// Class Withdrawal represents an ATM withdrawal transaction public class Withdrawal { // attributes private int accountNumber; // account to withdraw funds from private double amount; // amount to withdraw // references to associated objects private Screen screen; // ATMs screen private Keypad keypad; // ATMs keypad private CashDispenser cashDispenser; // ATMs cash dispenser private BankDatabase bankDatabase; // account info database // no-argument constructor public Withdrawal() { } // end no-argument Withdrawal constructor // operations public void execute() { } // end method execute

71

Outline

withdrawal.java

23 } // end class Withdrawal

Declare shell of a method with return type void

2005 Pearson Education, Inc. All rights reserved.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

// Class Keypad represents an ATMs keypad public class Keypad { // no attributes have been specified yet // no-argument constructor public Keypad() { } // end no-argument Keypad constructor // operations public int getInput() { } // end method getInput

72

Outline

withdrawal.java

15 } // end class Keypad

2005 Pearson Education, Inc. All rights reserved.

73

10
Incorporating Inheritance into the ATM System
2005 Pearson Education, Inc. All rights reserved.

74

10.9 (Optional) Software Engineering Case Study: Incorporating Inheritance into the ATM System
UML model for inheritance
The generalization relationship
The superclass is a generalization of the subclasses The subclasses are specializations of the superclass

Transaction superclass
Contains the methods and fields BalanceInquiry, Withdrawal and Deposit have in common
execute method accountNumber field

2005 Pearson Education, Inc. All rights reserved.

75

Fig. 10.19 | Attributes and operations of classes BalanceInquiry,

Withdrawal and Deposit.

2005 Pearson Education, Inc. All rights reserved.

76

Fig. 10. 20 | Class diagram modeling generalization of superclass Transaction and subclasses BalanceInquiry, Withdrawal and Deposit. Note that abstract class names (e.g., Transaction) and method names (e.g., execute in class Transaction) appear in italics.
2005 Pearson Education, Inc. All rights reserved.

77

Fig. 10.21 | Class diagram of the ATM system (incorporating inheritance). Note that abstract class names (e.g., Transaction) appear in italics.

2005 Pearson Education, Inc. All rights reserved.

78

Software Engineering Observation 10.12

A complete class diagram shows all the associations among classes and all the attributes and operations for each class. When the number of class attributes, methods and associations is substantial (as in Fig. 10.21 and Fig. 10.22), a good practice that promotes readability is to divide this information between two class diagramsone focusing on associations and the other on attributes and methods.

2005 Pearson Education, Inc. All rights reserved.

79

10.9 (Optional) Software Engineering Case Study: Incorporating Inheritance into the ATM System (Cont.)
Incorporating inheritance into the ATM system design
If class A is a generalization of class B, then class B extends class A If class A is an abstract class and class B is a subclass of class A, then class B must implement the abstract methods of class A if class B is to be a concrete class

2005 Pearson Education, Inc. All rights reserved.

80

Fig. 10.22 | Class diagram with attributes and operations (incorporating inheritance). Note that abstract class names (e.g., Transaction) and method names (e.g., execute in class Transaction) appear in italic
2005 Pearson Education, Inc. All rights reserved.

1 2 3 4

// Class Withdrawal represents an ATM withdrawal transaction public class Withdrawal extends Transaction { } // end class Withdrawal

81

Outline

Subclass Withdrawal extends superclass Transaction

Withdrawal.java

2005 Pearson Education, Inc. All rights reserved.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

// Withdrawal.java // Generated using the class diagrams in Fig. 10.21 and Fig. 10.22 public class Withdrawal extends Transaction { // attributes private double amount; // amount to withdraw private Keypad keypad; // reference to keypad private CashDispenser cashDispenser; // reference to cash dispenser // no-argument constructor public Withdrawal() { } // end no-argument Withdrawal constructor // method overriding execute public void execute() { } // end method execute

82

Outline

Subclass Withdrawal extends superclass Transaction

Withdrawal.java

19 } // end class Withdrawal

2005 Pearson Education, Inc. All rights reserved.

83

Software Engineering Observation 10.13

Several UML modeling tools convert UML-based designs into Java code and can speed the implementation process considerably. For more information on these tools, refer to the Internet and Web Resources listed at the end of Section 2.9.

2005 Pearson Education, Inc. All rights reserved.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

// Abstract class Transaction represents an ATM transaction public abstract class Transaction { // attributes

84

Outline
Declare abstract superclass Transaction
Transaction.java

private int accountNumber; // indicates account involved private Screen screen; // ATMs screen private BankDatabase bankDatabase; // account info database // no-argument constructor invoked by subclasses using super() public Transaction() { } // end no-argument Transaction constructor // return account number public int getAccountNumber() { } // end method getAccountNumber

(1 of 2)

2005 Pearson Education, Inc. All rights reserved.

19 20 21 22 23 24 25 26 27 28 29 30

// return reference to screen public Screen getScreen() { } // end method getScreen

85

Outline

// return reference to bank database public BankDatabase getBankDatabase() { } // end method getBankDatabase

Transaction.java

(2 of 2)

// abstract method overridden by subclasses public abstract void execute();

31 } // end class Transaction

Declare abstract method execute

2005 Pearson Education, Inc. All rights reserved.