1 2

OBJECTIVES
In this chapter you will learn:
• Some basics of object technology.
• UML—the industry-standard object-oriented system modeling
language.
• UML: ATM Requirements Document
• UML Use Case Diagrams
• UML Class Diagrams
UML: ATM Case Study • UML Class Attributes
• UML Objects’ States and Activities
• UML Class Operations
• UML Collaboration
• Class Programming
• Inheritance and Polymorphism
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

3 4

Outline
1.19 Software Engineering Case Study: Introduction to Object
1.19 Introduction to Object Technology
Technology and the UML and the UML
3.10 Software Engineering Case Study: Examining the ATM
Requirements Document
4.12 Software Engineering Case Study: Identifying the Classes in • Humans think in terms of objects such as telephones,
the ATM Requirements Document
5.14 Software Engineering Case Study: Identifying Class houses, traffic lights, and microwave ovens.
Attributes in the ATM System
6.10 Software Engineering Case Study: Identifying Objects’ States • Objects have attributes (e.g., size, shape, color and
and Activities in the ATM System
weight), and exhibit behaviors (e.g., a ball rolls,
7.15 Software Engineering Case Study: Identifying Class
Operations in the ATM System bounces, inflates and deflates; a baby cries, sleeps,
8.14 Software Engineering Case Study: Collaboration Among crawls, walks and blinks).
Objects in the ATM System
10.22 Software Engineering Case Study: Starting to Program the
Classes of the ATM System
12.9 Software Engineering Case Study: Incorporating Inheritance
and Polymorphism into the ATM System

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

 5 6

1.19 Introduction to Object Technology 1.19 Introduction to Object Technology

and the UML (Cont.) and the UML (Cont.)

• Object-oriented design (OOD) models software in
terms similar to those used to describe real-world
objects.
• New classes of objects can inherit characteristics of
existing classes and add unique characteristics of their
own.
• OOD also models communication between objects,
just as people send messages to one another.
• OOD encapsulates attributes and operations into
objects.
• Objects have the property of information hiding.
– Objects may communicate with one another across well-defined
interfaces, but implementation details are hidden within the
objects themselves.
– Similarly, you can drive a car without knowing the details of how
it works internally.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

7 8

1.19 Introduction to Object Technology 1.19 Introduction to Object Technology

and the UML (Cont.) and the UML (Cont.)

• Languages like C# are object oriented.
– Programming in such a language is called object-oriented
programming (OOP).
– In C#, the unit of programming is the class from which objects
are eventually instantiated (an OOP term for “created”).
– C# classes contain methods that implement operations, and data
that implements attributes.
06/06/52 Dr.Mud-Armeen Munlin
• Classes are to objects as blueprints are to houses—a
class is a “plan” for building objects of the class.
• Just as we can build many houses from one blueprint,
we can instantiate (create) many objects from one
class.
• The data components of a class are called attributes or
fields.
• The operation components of a class are called
methods.
06/06/52 Dr.Mud-Armeen Munlin
 9 10

1.19 Introduction to Object Technology 1.19 Introduction to Object Technology

and the UML (Cont.) and the UML (Cont.)

• Packaging software as classes makes it possible for
future software systems to reuse the classes.
• Groups of related classes often are packaged as
reusable components.
Software Engineering Observation 1.1
Reuse of existing classes when building new classes and programs
saves time, money and effort. Reuse also helps programmers build
more reliable and effective systems, because existing classes and
components often have gone through extensive testing, debugging
and performance tuning.
06/06/52 Dr.Mud-Armeen Munlin
• In the 1980s, many organizations began using OOP to build their
applications.
• In 1994, James Rumbaugh and Grady Booch began working
to unify several processes for representing OOP.
• The Object Management GroupTM (OMGTM ) invited submissions
for a common modeling language.
• Several companies formed the UML Partners—a consortium that
developed the UML version 1.1.
• The OMG accepted the proposal and, in 1997, assumed
responsibility for the continuing maintenance and revision
of the UML.
06/06/52 Dr.Mud-Armeen Munlin

11 12

3.10 Examining the ATM Requirements

1.19 Introduction to Object Technology Document
and the UML (Cont.)
• A requirements document specifies the overall purpose of a
system and what it must do.
• What Is the UML?
• A small local bank intends to install a new ATM (Fig. 3.28).
• The Unified Modeling Language (UML) is the
most widely used graphical representation scheme for
object-oriented systems. Screen

• The UML is extensible (i.e., capable of being enhanced

with new features). Cash Dispenser

• Developers use the UML to express their designs with

Keypad
a standard set of graphical notations. Deposit Slot

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Fig. 3.28 | Automated teller machine

Dr.Mud-Armeen Munlin user interface.
 13 14

3.10 Examining the ATM Requirements 3.10 Examining the ATM Requirements
Document (Cont.) Document (Cont.)
• The ATM should have the following functionality. • The main menu (Fig. 3.29) displays a numbered option for
– The screen prompts the user to enter an account number. each of the three types of transactions, and the option to
– The user enters a five-digit account number, using the keypad.
exit the system.
– For authentication purposes, the screen prompts the user to enter
the PIN.
– The user enters a five-digit PIN, using the keypad.
– If the user enters a valid account number and the correct PIN for
that account, the screen displays the main menu.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Fig.Dr.Mud-Armeen

3.29 | ATM main menu.
Munlin

15 16

3.10 Examining the ATM Requirements 3.10 Examining the ATM Requirements
Document (Cont.) Document (Cont.)
• The user enters 2 to make a withdrawal (Fig. 3.30). • The user enters 3 to make a deposit:
• If the user enters 1, the screen displays the user’s account balance from
the bank’s database. 1. The screen prompts the user to enter a deposit
amount.
2. The screen displays a message telling the user to
insert a deposit envelope into the deposit slot.
3. If the deposit slot receives a deposit envelope, the
ATM credits the deposit amount to the user’s
account balance in the bank’s database.

Fig. 3.30 | ATM withdrawal menu.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin
 17 18

3.10 Examining the ATM Requirements
Document (Cont.)
• Requirements gathering might include interviews
with potential users of the system and specialists in
fields related to the system.
• The software life cycle specifies the stages through
which software evolves from the time it is conceived
to the time it is retired from use.
– Waterfall models perform each stage once in succession.
– Iterative models may repeat one or more stages several times
throughout a product’s life cycle.
3.10 Examining the ATM Requirements
Document (Cont.)
• To capture what a proposed system should do,
developers often employ a technique known as use
case modeling.
• Use cases represent different capabilities that the
system provides to its clients.
• The simplified ATM system we build in this case
study requires only the first three use cases (Fig. 3.31).

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

19 20

3.10 Examining the ATM Requirements 3.10 Examining the ATM Requirements
Document (Cont.) Document (Cont.)
Use Case Diagrams • The stick figure represents an actor, which defines the
• A use case diagram models the interactions between a roles that an external entity—such as a person or
system’s clients and the system. another system—plays when interacting with the
• Figure 3.31 shows the use case diagram for our ATM system. system.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

Fig. 3.31 | Use case diagram for the ATM system from the user’s perspective.
 21 22

3.10 Examining the ATM Requirements 4.12 Software Engineering Case Study:
Document (Cont.) Identifying the Classes in the ATM
• A design specification should specify how the system should Requirements Document
be constructed to satisfy the system requirements. • We create classes only for the nouns and noun phrases in the
ATM system (Fig. 4.21).
• A system is a set of components that interact to solve a
• We do not need to model some nouns such as “bank” which
problem. are not part of the ATM operations.
• For example, to perform the ATM system’s designated tasks,
our ATM system has a user interface (Fig. 3.28), contains Nouns and noun phrases in the requirements document

software that executes financial transactions and interacts with bank money / funds account number

a database of bank-account information. ATM screen PIN

user keypad bank database
– System structure describes the system’s objects and their
customer cash dispenser balance inquiry
interrelationships.
transaction $20 bill / cash withdrawal
– System behavior describes how the system changes as its objects
account deposit slot deposit
interact with one another.
balance deposit envelope

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen

Fig. 4.21 | Nouns and noun phrases inMunlin
the requirements document.

23 24

4.12 Identifying the Classes in the ATM 4.12 Identifying the Classes in the ATM
Requirements Document (Cont.) Requirements Document (Cont.)
• UML class diagrams model the classes in the ATM system and their • Figure 4.23 shows how our classes ATM and Withdrawal relate to
interrelationships (Fig. 4.22). one another.
– The top compartment contains the name of the class. – The line that connects the two classes represents an association.
– The middle compartment contains the class’s attributes. – Multiplicity values indicate how many objects of each class
– The bottom compartment contains the class’s operations. participate in the association.
– One ATM object participates in an association with either zero or
one Withdrawal objects.
• currentTransaction is a role name, which identifies the role
the Withdrawal object plays.
Fig. 4.22 | Representing a class in the UML using a class diagram.

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

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

 25 26

4.12 Identifying the Classes in the ATM

4.12 Software Engineering Case Study:
Requirements Document (Cont.)
Identifying the Classes in the ATM • In Fig. 4.25, the solid diamonds indicate that class ATM has a
Requirements Document (Cont.) composition relationship with classes Screen, Keypad,
CashDispenser and DepositSlot.
Symbol Meaning • Composition implies a whole/part relationship—the ATM “has a”
0 None screen, a keypad, a cash dispenser and a deposit slot.
1 One • The has-a relationship defines composition.
m An integer value
0..1 Zero or one
m, n m or n
m..n At least m, but not more than n
* Any nonnegative integer (zero or
more)
0..* Zero or more (identical to *)
1..* One or more
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin
Fig. 4.24 | Multiplicity types. Fig. 4.25 | Class diagram showing composition relationships.
27 28

4.12 Identifying the Classes in the ATM
Requirements Document (Cont.)
• Composition relationships have the following properties:
– Only one class in the relationship can represent the whole.
– The parts in the composition relationship exist only as long as the
whole.
– A part may belong to only one whole at a time.
• If a “has-a” relationship does not satisfy one or more of
these criteria, hollow diamonds are used to indicate
aggregation.
4.12 Identifying the Classes in the ATM
Requirements Document (Cont.)
• Figure 4.26 shows a class diagram for the ATM system.
• The class diagram shows that class ATM has a one-to-one
relationship with class BankDatabase.
• We also model that one object of class BankDatabase
participates in a composition relationship with zero or
more objects of class Account.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

 29 30

4.12 Identifying the Classes in the ATM

5.14 Identifying Class Attributes in the
Requirements Document (Cont.)
ATM System

• A person’s attributes include height, weight and whether

the person is left-handed, right-handed or ambidextrous.
• We can identify attributes of the classes in our system by
looking for descriptive words and phrases in the
requirements document.

06/06/52 Fig. 4.26 | ClassDr.Mud-Armeen Munlin

diagram for the ATM system model. 06/06/52 Dr.Mud-Armeen Munlin

31 32

5.14 Identifying Class Attributes in the ATM 5.14 Identifying Class Attributes in the
System (Cont.) Class Descriptive words and phrases ATM System (Cont.)
ATM user is authenticated
BalanceInquiry account number
Withdrawal account number
• The class diagram in
amount Fig. 5.19 lists some of
Deposit account number the attributes for the
amount
classes in our system.
BankDatabase [no descriptive words or phrases]
Account account number • We list each attribute’s
PIN name and type,
balance
followed in some cases
Screen [no descriptive words or phrases]
by an initial value.
Keypad [no descriptive words or phrases]
CashDispenser begins each day loaded with 500 $20 bills
DepositSlot [no descriptive words or phrases]

Fig. 5.18 | Descriptive words and phrases from the ATM

06/06/52 requirements
Dr.Mud-Armeen Munlin document. 06/06/52 Dr.Mud-Armeen
Fig.Munlin
5.19 | Classes with attributes.
 33 34
6.10 Software Engineering Case Study:
5.14 Identifying Class Attributes in the
Identifying Objects’ States and Activities
ATM System (Cont.)
in the ATM System
• Consider the userAuthenticated attribute of class ATM:
userAuthenticated : bool = false
• Each object in a system goes through a series of discrete
states.
• This attribute declaration contains:
– the attribute name, userAuthenticated.
• An object’s state is indicated by the values of its attributes
at that time.
– the attribute type, bool.
– an initial value for an attribute, false. • State machine diagrams model key states of an object
and show under what circumstances the object changes
Software Engineering Observation 5.6 state.
Early 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.
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

35 36
6.10 Software Engineering Case Study: 6.10 Software Engineering Case Study:
Identifying Objects’ States and Activities Identifying Objects’ States and Activities
in the ATM System (Cont.) in the ATM System (Cont.)
• Figure 6.26 is a simple state machine diagram that models two of • An activity diagram models an object’s workflow
the states of an object of class ATM. during application execution.
• The activity diagram in Fig. 6.27 models the actions
involved in executing a BalanceInquiry
transaction.
Fig. 6.26 | State machine diagram for some of the states of the ATM object.

Software Engineering Observation 6.5

Software designers do not generally create state machine diagrams
showing every possible state and state transition for all attributes—there
are simply too many of them. State machine diagrams typically show only
the most important or complex
06/06/52
states and state transitions.
Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin
 37 38
6.10 Software Engineering Case Study: 6.10 Software Engineering Case Study:
Identifying Objects’ States and Activities Identifying Objects’ States and Activities
in the ATM System (Cont.) in the ATM System (Cont.)
• Figure 6.28 shows an activity diagram for a
Withdrawal transaction.
• We assume that a Withdrawal object has already been
assigned a valid account number.

06/06/52
Fig. 6.27 | Activity diagram for a BalanceInquiry
Dr.Mud-Armeen Munlin
transaction. 06/06/52 Dr.Mud-Armeen Munlin

39 40

6.10 Software
7.15 Software Engineering Case Study:
Engineering Case Identifying Class Operations in the ATM System
Study: Identifying
Objects’ States and • An operation is a service that objects of a class provide to
clients of the class.
Activities in the ATM
• The verbs and verb phrases in Fig. 7.20 help us determine the
System (Cont.) operations of our classes.

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]

Fig. 7.20| Verbs and verb phrases for each class in the ATM system. (Part 1 of 2.)
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin
Fig. 6.28 | Activity diagram for a Withdrawal transaction.
 41 42

7.15 Software Engineering Case Study: 7.15 Software Engineering Case Study:
Identifying Class Operations in the ATM System Identifying Class Operations in the ATM System
(Cont.) (Cont.)
Class Verbs and verb phrases
BankDatabase authenticates a user, retrieves an account balance, credits an account, Modeling Operations
debits an account
Account retrieves an account balance, credits a deposit amount to an account,
• We place operations in the third compartment of the
debits a withdrawal amount to an account three transaction classes in the updated class diagram
Screen displays a message to the user of Fig. 7.21.
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

Fig. 7.20| Verbs and verb phrases for each class in the ATM system. (Part 2 of 2.)

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

43 44

7.15 Software Engineering Case Study: 7.15 Software Engineering Case Study:
Identifying Class Operations in the ATM System Identifying Class Operations in the ATM System
(Cont.) (Cont.)

• UML operations are implemented as methods in C#.

• The UML represents operations by listing the
operation name, followed by a comma-separated list
of parameters in parentheses, a colon and the return
type.
• Each parameter in the comma-separated parameter
list consists of a parameter name, followed by a colon
and the parameter type:

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

Fig. 7.21 | Classes in the ATM system with attributes and operations.
 45
7.15 Software Engineering Case Study:
Identifying Class Operations in the ATM System
(Cont.)
Operations of Class BankDatabase and Class
Account
• 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.
• We add a ValidatePIN operation to class Account.
• Note that we specify a return type of bool for the
Authenticate-User and ValidatePIN operations.
• The database acts as an intermediary between the ATM and the
account data, preventing unauthorized access.
06/06/52 Dr.Mud-Armeen Munlin
47
7.15 Software Engineering Case Study:
Identifying Class Operations in the ATM System
(Cont.)
Operations of Class Screen
• All visual output occurs through the screen of the ATM.
• We simply create one operation that can display any message
specified by a parameter.
Operations of Class Keypad
• Class Keypad should perform a GetInput operation.
Operations of Class CashDispenser and Class DepositSlot
• We create operations DispenseCash and
IsSufficientCashAvailable for class CashDispenser.
06/06/52 Dr.Mud-Armeen Munlin
46
7.15 Software Engineering Case Study:
Identifying Class Operations in the ATM System
(Cont.)
• Class Properties are placed in the second compartment of a class
diagram.
• To indicate a read-only property in the UML, we follow the property’s
type with “{readOnly}.”
• We modeled GetAvailableBalance and GetTotalBalance as
operations in class BankDatabase so that we could specify
parameters to which the ATM can pass arguments.
• We assign Credit and Debit operations to classes BankDatabase
and Account.
– Crediting an account adds an amount only to the Account’s total
balance.
– Debiting an account, subtracts the amount from both the total and
available balances.
06/06/52 Dr.Mud-Armeen Munlin
48
7.15 Software Engineering Case Study:
Identifying Class Operations in the ATM System
(Cont.)
Identifying and Modeling Operation Parameters
• We identify an operation’s parameters by examining what data the
operation requires to perform its assigned task.
• The class diagram in Fig. 7.22 models class BankDatabase.
Fig. 7.22 | Class BankDatabase with operation parameters.
06/06/52 Dr.Mud-Armeen Munlin
 49 50

7.15 Software Engineering Case Study: 7.15 Software Engineering Case Study:
Identifying Class Operations in the ATM System Identifying Class Operations in the ATM System
(Cont.) (Cont.)

• The class diagram in Fig. 7.23 models the parameters of • Figure 7.24 models class Screen with a parameter for
class Account’s operations. operation Display-Message.

Fig. 7.24 | Class Screen with an operation parameter.

06/06/52 Fig. 7.23 | ClassDr.Mud-Armeen

Account withMunlin
operation parameters. 06/06/52 Dr.Mud-Armeen Munlin

51 52

7.15 Software Engineering Case Study: 8.14 Software Engineering Case Study:
Collaboration Among Objects in the ATM
Identifying Class Operations in the ATM System
(Cont.) System

• 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.
• 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.

Fig. 7.25 | Class CashDispenser with operation parameters.

• Operation IsSufficientCashAvailable also takes

decimal parameter amount to indicate the amount of cash
in question.
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin
 53 54
8.14 Software Engineering Case Study: 8.14 Software Engineering Case Study:
Collaboration Among Objects in the ATM Collaboration Among Objects in the ATM
System (Cont.) System (Cont.)
Identifying the Collaborations in a System • Figure 8.24 lists the collaborations that can be derived from the
requirements document.
• For each action or step described in the requirements
An object to an object
document, we decide which objects in our system of class... sends the message... of class...
must interact to achieve the desired result. ATM DisplayMessage Screen
• We identify one object as the sending object and GetInput Keypad
AuthenticateUser BankDatabase
another as the receiving object.
Execute BalanceInquiry
• We then select one of the receiving object’s operations Execute Withdrawal

that must be invoked by the sending object to produce Execute Deposit

BalanceInquiry GetAvailableBalance BankDatabase
the proper behavior. GetTotalBalance BankDatabase
DisplayMessage Screen

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

Fig. 8.24 | Collaborations in the ATM system. (Part 1 of 2.)

55 56
8.14 Software Engineering Case Study: 8.14 Software Engineering Case Study:
Collaboration Among Objects in the ATM Collaboration Among Objects in the ATM
System (Cont.) System (Cont.)
An object to an object
of class... sends the message... of class... Interaction Diagrams
Withdrawal DisplayMessage Screen
• The UML provides several types of interaction
GetInput Keypad
GetAvailableBalance BankDatabase diagrams that model the behavior of a system by
IsSufficientCashAvailable CashDispenser modeling how objects interact with one another.
Debit BankDatabase
DispenseCash CashDispenser • The communication diagram emphasizes which
Deposit DisplayMessage Screen
GetInput Keypad
objects participate in collaborations.
IsDepositEnvelopeReceived DepositSlot
Credit BankDatabase • The sequence diagram emphasizes when messages
BankDatabase ValidatePIN
AvailableBalance (get)
Account
Account
are sent between objects.
TotalBalance (get) Account
Debit Account
Credit Account
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin
Fig. 8.24 | Collaborations in the ATM system. (Part 2 of 2.)
 57 58
8.14 Software Engineering Case Study: 8.14 Software Engineering Case Study:
Collaboration Among Objects in the ATM Collaboration Among Objects in the ATM
System (Cont.) System (Cont.)
Communication Diagrams • Communicating objects are connected with solid lines.
• Figure 8.25 shows a communication diagram that models the • Messages are passed between objects along these lines
ATM executing a BalanceInquiry. in the direction shown by arrows with filled
arrowheads.
• The filled arrow in Fig. 8.25 represents a message—or
synchronous call—in the UML and a method call in
Fig. 8.25 | Communication diagram of the ATM executing a balance inquiry. C#.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

59 60
8.14 Software Engineering Case Study: 8.14 Software Engineering Case Study:
Collaboration Among Objects in the ATM Collaboration Among Objects in the ATM
System (Cont.) System (Cont.)
Sequence of Messages in a Communication Diagram
• Note that Fig. 8.26 models two additional messages passing
• Figure 8.26 shows a communication diagram that models the
from the BankDatabase to an Account (message 1.1 and
interactions among objects in the system when an object of class
BalanceInquiry executes.
message 2.1).
• 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. If the BankDatabase needed to
pass a second nested message while processing message 1, it
would be numbered 1.2.
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin
Fig. 8.26 | Communication diagram for executing a BalanceInquiry.
 61 62
8.14 Software Engineering Case Study: 8.14 Software Engineering Case Study:
Collaboration Among Objects in the ATM Collaboration Among Objects in the ATM
System (Cont.) System (Cont.)
Sequence Diagrams
• 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.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

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

63
8.14 Software Engineering Case Study:
Collaboration Among Objects in the ATM
System (Cont.)
• 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 bottom.
• An activation, shown as a thin vertical rectangle, indicates
that an object is executing.
64
10.22 Software Engineering Case Study:
Starting to Program the Classes of the ATM
System
Visibility
• Access modifiers determine the visibility, or
accessibility, of an object’s attributes and operations
to other objects.
• The UML employs visibility markers for modeling
the visibility of attributes and operations.
– Public visibility is indicated by a plus sign (+).
– A minus sign (–) indicates private visibility.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

 65 66

10.22 Software Engineering Case Study:

10.22 Software Engineering Case Study: Starting
Starting to Program the Classes of the ATM
to Program the Classes of the ATM System (Cont.)
System (Cont.)
• Figure 10.30 shows Navigability
our updated class
• The class diagram in
diagram with Fig. 10.31 further
visibility markers refines the relationships
included. among classes in the
ATM system by adding
navigability arrows to
the association lines.

Fig. 10.31 | Class diagram with navigability arrows.

06/06/52 Dr.Mud-Armeen
Fig. 10.30 | Class Munlin
diagram with visibility markers. 06/06/52 Dr.Mud-Armeen Munlin

67 68

10.22 Software Engineering Case Study: Outline

Starting to Program the Classes of the ATM
System (Cont.)
• Navigability arrows indicate in which direction an
association can be traversed and are based on
collaborations.
• Programmers use navigability arrows to help
Implementing the ATM System from Its UML Design
• We follow these four guidelines for each class, using
Withdrawal as an example: • Withdrawal.cs
• Use the name located in the first compartment of a class in a
class diagram to declare the class as a public class with an
empty parameterless constructor.
• Class Withdrawal initially yields the code in Fig. 10.32.
1
2
// Fig. 10.32: Withdrawal.cs
// Class Withdrawal represents an ATM withdrawal transaction

determine which objects need references to other 3

4
public class Withdrawal
{

objects. 5
6
// parameterless constructor
public Withdrawal()
7 {
• Associations in a class diagram that have navigability 8 // constructor body code
9 } // end constructor
arrows at both ends or do not have navigability arrows 10 } // end class Withdrawal

at all indicate bidirectional navigability. Fig. 10.32 | Initial C# code for class Withdrawal based on
Figs. 10.30 and 10.31.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

 69 70
Outline Outline
• Use the attributes located in the class’s second • Use the associations described in the class diagram to
compartment to declare the instance variables. declare references to other objects. Fig. 10.34 declares
• The private attributes accountNumber and • Withdrawal.cs the appropriate references as private instance • Withdrawal.cs
amount of class Withdrawal yield the code in variables. • (1 of 2 )
Fig. 10.33.
1 // Fig. 10.34: Withdrawal.cs
2 // Class Withdrawal represents an ATM withdrawal transaction
1 // Fig. 10.33: Withdrawal.cs
3 public class Withdrawal
2 // Class Withdrawal represents an ATM withdrawal transaction
4 {
3 public class Withdrawal
5 // attributes
4 {
6 private int accountNumber; // account to withdraw funds from
5 // attributes
7 private decimal amount; // amount to withdraw
6 private int accountNumber; // account to withdraw funds from
8
7 private decimal amount; // amount to withdraw from account
9 // references to associated objects
8
10 private Screen screen; // ATM’s screen
9 // parameterless constructor
11 private Keypad keypad; // ATM’s keypad
10 public Withdrawal()
12 private CashDispenser cashDispenser; // ATM’s cash dispenser
11 {
13 private BankDatabase bankDatabase; // account-information database
12 // constructor body code
13 } // end constructor
14 } // end class Withdrawal Fig. 10.34 | Incorporating private reference handles for the associations
of class Withdrawal based on Figs. 10.30 and 10.31. (Part 1 of 2.)
Fig. 10.33 | Incorporating private variables for class Withdrawal
based on Figs. 10.30–10.31.
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

71 72
Outline Outline
• Use the operations located in the third compartment of
Fig. 10.30 to declare the shells of the methods. If we have not
yet specified a return type for an operation, we declare the
• Withdrawal.cs method with return type void. Refer to the class diagrams to • Withdrawal.cs
14
15 // parameterless constructor • (2 of 2 ) declare any necessary parameters. • (1 of 2 )
16 public Withdrawal()
17 {
• Adding the public operation Execute (which has an
18 // constructor body code empty parameter list) in class Withdrawal yields the code
19 } // end constructor
20 } // end class Withdrawal
in Fig. 10.35.
1 // Fig. 10.35: Withdrawal.cs
Fig. 10.34 | Incorporating private reference handles for the associations 2 // Class Withdrawal represents an ATM withdrawal transaction
of class Withdrawal based on Figs. 10.30 and 10.31. (Part 2 of 2.) 3 public class Withdrawal
4 {
5 // attributes
6 private int accountNumber; // account to withdraw funds from
7 private decimal amount; // amount to withdraw
8
9 // references to associated objects
10 private Screen screen; // ATM’s screen
11 private Keypad keypad; // ATM’s keypad
12 private CashDispenser cashDispenser; // ATM’s cash dispenser
13 private BankDatabase bankDatabase; // account-information database

Fig. 10.35 | C# code incorporating method Execute in class

06/06/52 Dr.Mud-Armeen Munlin Dr.Mud-Armeen
06/06/52Withdrawal based on Figs. Munlin(Part 1 of 2.)
10.30 and 10.31.
 73 74
Outline 12.9 Software Engineering Case Study:
14
15 // parameterless constructor Incorporating Inheritance and Polymorphism
16 public Withdrawal()
17 {
• Withdrawal.cs into the ATM System
18 // constructor body code
} // end constructor
19
20
• (1 of 2 ) • The UML specifies a relationship called a generalization to
21
22
// operations
// perform transaction
model inheritance.
23 public void Execute()
24 {
• Figure 12.20 is the class diagram that models the inheritance
25
26
// Execute method body code
} // end method Execute
relationship between base class Transaction and its three
27 } // end class Withdrawal derived classes.
Fig. 10.35 | C# code incorporating method Execute in class
Withdrawal based on Figs. 10.30 and 10.31. (Part 1 of 2.)

•Software Engineering Observation 10.13

•Many UML modeling tools can convert UML-based designs into
C# code, considerably speeding up the implementation process.
For more information on these “automatic” code generators, refer
to the web resources listed at the end of Section 3.10. Fig. 12.19 | Attributes and operations of classes BalanceInquiry,
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen
Withdrawal Munlin
and Deposit.

75 76

12.9 Software Engineering Case Study:
Incorporating Inheritance and Polymorphism
into the ATM System (Cont.)
• The arrows with triangular hollow arrowheads indicate
that classes BalanceInquiry, Withdrawal and
Deposit are derived from class Transaction by
inheritance.
– Class Transaction is said to be a generalization of its derived
classes.
– The derived classes are said to be specializations
Transaction .
06/06/52 Dr.Mud-Armeen Munlin
12.9 Software Engineering Case Study:
Incorporating Inheritance and Polymorphism
into the ATM System (Cont.)
• As Fig. 12.19 shows, classes BalanceInquiry,
Withdrawal and Deposit share private int attribute
accountNumber.
• Because the derived classes in this case do not need to modify
attribute accountNumber, we have chosen to replace private
attribute accountNumber in our model with the public
of class read-only property AccountNumber.
• Since this is a read-only property, it provides only a get
accessor to access the account number.
• We declare Execute as an abstract operation in base class
Transaction—it will become an abstract method in the
C# implementation.
06/06/52 Dr.Mud-Armeen Munlin
 77 78

12.9 Software Engineering Case Study: 12.9 Software Engineering Case Study:
Incorporating Inheritance and Polymorphism Incorporating Inheritance and Polymorphism
into the ATM System (Cont.) into the ATM System (Cont.)
• Figure 12.21 presents an updated class diagram of our model that incorporates
inheritance and introduces abstract base class Transaction.

Fig. 12.20 | Class diagram modeling the generalization (i.e., inheritance)

relationship between the base class Transaction and its
derived classes BalanceInquiry, Withdrawal and Deposit.
Fig. 12.21 | Class diagram of the ATM system (incorporating inheritance).
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Note that abstract class name Transaction
Dr.Mud-Armeen Munlin appears in italics.

79 80

12.9 Software Engineering Case Study:
Incorporating Inheritance and Polymorphism
into the ATM System (Cont.)
• We model an association between class ATM and class
Transaction to show that the ATM, at any given moment,
either is executing a transaction or is not.
• Because a Withdrawal is a type of Transaction, we no
longer draw an association line directly between class ATM and
class Withdrawal—derived class Withdrawal inherits
base class Transaction’s association with class ATM.
• Derived classes BalanceInquiry and Deposit also
inherit this association, which replaces the previously omitted
associations between classes BalanceInquiry and
Deposit, and class ATM.
12.9 Software Engineering Case Study:
Incorporating Inheritance and Polymorphism
into the ATM System (Cont.)
• We also add an association between Transaction and
BankDatabase (Fig. 12.21). All Transactions require a
reference to the BankDatabase so that they can access and
modify account information.
• We include an association between class Transaction and
the Screen because all Transactions display output to the
user via the Screen.
• Class Withdrawal still participates in associations with the
CashDispenser and the Keypad.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

 81 82

12.9 Software Engineering Case Study: 12.9 Software Engineering Case Study:
Incorporating Inheritance and Polymorphism Incorporating Inheritance and Polymorphism
into the ATM System (Cont.) into the ATM System (Cont.)

Software Engineering Observation 12.12

• We present a modified
class diagram in A complete class diagram shows all the associations
Fig. 12.22 that includes among classes, and all the attributes and operations
abstract base class for each class. When the number of class attributes,
Transaction. operations and associations is substantial, a good
practice is to divide this information between two class
diagrams—one focusing on associations and the other
on attributes and operations.

06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin

Fig. 12.22 | Class diagram after incorporating inheritance into the system.

83 84

Implementing the ATM System Design Incorporating

Outline • Figure 12.24 contains the portions of the C# code for
Outline
Inheritance class Withdrawal.
• If a class A is a generalization of class B, then class B • Withdrawal.cs 1 // Fig. 12.24: Withdrawal.cs
• Withdrawal.cs
is derived from (and is a specialization of) class A. 2 // Class Withdrawal represents an ATM withdrawal transaction.
public class Withdrawal : Transaction
• Figure 12.23 contains the shell of class Withdrawal, 3
4 {
in which the class definition indicates the inheritance 5 // attributes
6 private decimal amount; // amount to withdraw
relationship between Withdrawal and Transaction. 7 private Keypad keypad; // reference to keypad
8 private CashDispenser cashDispenser; // reference to cash dispenser
1 // Fig. 12.23: Withdrawal.cs 9
2 // Class Withdrawal represents an ATM withdrawal transaction. 10 // parameterless constructor
3 public class Withdrawal : Transaction 11 public Withdrawal()
4 {
12 {
5 // code for members of class Withdrawal 13 // constructor body code
6 } // end class Withdrawal 14 } // end constructor
15
16 // method that overrides Execute
• If class A is an abstract class and class B is derived from 17 public override void Execute()
class A, then class B must implement the abstract 18 {
19 // Execute method body code
operations of class A if class B is to be a concrete class. 20 } // end method Execute
21 } // end class Withdrawal
Fig. 12.23 | C# code for shell of class Withdrawal. Fig. 12.24 | C# code for class Withdrawal based on
Figures 12.21 and 12.22.
06/06/52 Dr.Mud-Armeen Munlin 06/06/52 Dr.Mud-Armeen Munlin