Slide 20.1
An Introduction to
Object-Oriented
Systems Analysis and Design
with UML and
the Unified Process
McGraw-Hill, 2004
Stephen R. Schach
srs@vuse.vanderbilt.edu
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CHAPTER 20
TECHNICAL TOPICS
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 20.2
Chapter Overview





Slide 20.3
Source Code and Compiled Code
Modularity
Polymorphism and Dynamic Binding
Example of Polymorphism and Dynamic Binding
Maintenance Implications of Polymorphism and
Dynamic Binding
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Source Code and Compiled Code

Programmers do not write all the code themselves
– They invoke run-time routines as needed

Slide 20.4
A program exists in three forms
– Source code
– Compiled code
– Executable load image
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Source Code and Compiled Code (contd)
Slide 20.5

Source code
– Written in a language such as COBOL, C, C++, or Java

Source code has to undergo two transformations
– It is compiled into compiled code (“object code”)
– The compiled code is combined (linked) with the run-time
routines it needs to form an executable load image
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Source Code and Compiled Code (contd)
Slide 20.6

Transformation of source code into an executable
load image
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Source Code and Compiled Code (contd)
Slide 20.7

Monolithic information systems are inefficient
– Changing a single line requires complete recompilation

Instead, a large information system should consist of
a number of smaller code artifacts (or modules)
– Now, only one model needs to be recompiled, followed by
– The relinking of all the compiled code modules into an
executable load image
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Source Code and Compiled Code (contd)
Slide 20.8

Recompiling one module, then relinking
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modularity

Slide 20.9
A large information system must be decomposed
into modules
– How is this decomposition to be performed?

Ensure that functionality coincides with module
boundaries, that is,
– All modules must have high cohesion
– The methods (implementations of the operations) must be
strongly related to one another, and weakly related to the
methods of the other modules
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modularity (contd)

Slide 20.10
The traditional paradigm is:
– Determine the client’s needs (requirements phase)
– Draw up the specifications (analysis phase)
– Design the information system as a set of modules with
high cohesion (design phase)
– Code the modules (implementation phase)

Cohesion is a fundamental principle of traditional
design
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modularity (contd)

Slide 20.11
The design criterion of maximizing the cohesion of a
module
– Relates to solely to operations, and
– Ignores data

This is the weakness of the traditional paradigm

What is needed is a paradigm that gives equal
weight to data and operations
– The object-oriented paradigm
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modularity (contd)

Cohesion was first put forward in 1976

Best: Functional cohesion
Slide 20.12
– A module has functional cohesion when it performs only
one operation

Second best: Informational cohesion
– A module has informational cohesion when it performs a
number of related operations, all on the same data
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modularity (contd)

Slide 20.13
A class is a module with informational cohesion
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modularity (contd)

Slide 20.14
There are two possible ways multiple objects
(instances of classes) could be implemented:
– (a) Multiple instances of the attributes, multiple instances
of the code for the methods
– (b) Multiple instances of the attributes, a single instance of
the code for each method

Approach (b) is automatically achieved by using an
object-oriented programming language
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modularity (contd)

Slide 20.15
(a) Incorrect and (b) correct implementation of objects
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Polymorphism and Dynamic Binding


The term polymorphism comes from two Greek
words meaning “many shapes”
Example: Bank Card Class
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 20.16
Polymorphism and Dynamic Binding (contd)
Slide 20.17

In a traditional information system, there have to be
two different functions (methods),
– print_monthly_statement_for_credit_card, and
– print_monthly_statement_for_debit_card
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Polymorphism and Dynamic Binding (contd)
Slide 20.18

At run-time, each card is examined in turn
– If it is a credit card, the monthly statement is printed by
» Function print_monthly_statement_for_credit_card
– If it is a debit card, the monthly statement is printed by
» Function print_monthly_statement_for_debit_card
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Polymorphism and Dynamic Binding (contd)
Slide 20.19

In an object-oriented information system, choice of
method is handled automatically
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Polymorphism and Dynamic Binding (contd)
Slide 20.20

In superclass Bank Card Class
– declare an abstract (or virtual) method printMonthlyStatement

In each of the subclasses
– Implement a method for printing that type of monthly
statement, also called printMonthlyStatement

When the monthly statements are being printed, the
system
– Automatically detects the card type, and
– Invokes the appropriate version of printMonthlyStatement
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Polymorphism and Dynamic Binding (contd)
Slide 20.21

There are two different implementations of method
printMonthlyStatement
– Polymorphism

The relevant version of printMonthlyStatement is “bound”
to the credit or debit card while the information
system is running
– Dynamic binding
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Polymorphism and Dynamic Binding (contd)
Slide 20.22

Polymorphism and dynamic binding make
development easier

There is no need to write code to
– Test whether an object is (say) a credit card or a debit
card, and then
– Invoke the appropriate function

Instead, the decision is made automatically by the
object-oriented run-time system
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Example of Polymorphism and Dynamic Binding
Slide 20.23

While performing the design workflow, allocation of
methods to classes is based on three factors
– Responsibility-driven design
– Inheritance
– Polymorphism and dynamic binding
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Example of Polymorphism and Dynamic Binding
Slide 20.24

Example: MSG Foundation case study
– Interaction diagrams include the messages:
» Print list of mortgages, and
» Print list of investments

Method printAsset must be able to print either an
investment or a mortgage
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Example of Polymorphism and Dynamic Binding
Slide 20.25

Traditional paradigm
– Two different functions are needed, namely
» Function print_investment, and
» Function print_mortgage

The information system must
– First determine the type of the asset, then
– Invoke the appropriate function
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Example of Polymorphism and Dynamic Binding
Slide 20.26

Object-oriented paradigm
– Method printAsset utilizes polymorphism and dynamic
binding
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Example of Polymorphism and Dynamic Binding
Slide 20.27

Version 1: Wrong allocation of method printAsset
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Polymorphism and Dynamic Binding Example
Slide 20.28

Version 1 uses inheritance instead of polymorphism
– Method printAsset in class Asset Class is inherited
unchanged by the two subclasses
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Example of Polymorphism and Dynamic Binding
Slide 20.29

Version 2: Correct allocation of method printAsset
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Example of Polymorphism and Dynamic Binding
Slide 20.30

Version 2 uses polymorphism and dynamic binding
– Method printAsset in class Asset Class is abstract (or
virtual)
– There are two actual implementations of printAsset
» One in class Investment Class, and
» One in class Mortgage Class
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Example of Polymorphism and Dynamic Binding
Slide 20.31

When method printAsset is invoked
– The object-oriented run-time system determines the class
of the object that is invoking method printAsset
– The object can be an instance of
» Class Investment Class, or
» Class Mortgage Class
– The run-time system must go to the appropriate class, and
– Execute the implementation of method printAsset found there
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Maintenance Implications of Polymorphism
Slide 20.32

Consider Version 2 again:
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Maintenance Implications of Polymorphism
Slide 20.33

Suppose the information system fails
– The run-time system prints a message stating that the
cause of the failure is “method printAsset”

The maintainer cannot tell which was responsible:
– The version of method printAsset in subclass Investment
Class, or
– The version of method printAsset in subclass Mortgage
Class
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Maintenance Implications of Polymorphism
Slide 20.34

The strength of polymorphism and dynamic binding
– The object-oriented run-time system automatically handles
which version of printAsset is to be invoked
– The potential ambiguity is automatically resolved

However, when something goes wrong at run-time
– There is no way to tell which of the two identically named
methods is the cause of the problem
– The ambiguity cannot be resolved
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Maintenance Implications of Polymorphism
Slide 20.35

Polymorphism and dynamic binding are extremely
powerful aspects of object-oriented technology that
– Promote development, but
– Can have a deleterious impact on maintenance
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.