slide 20.1 copyright © 2004 by the mcgraw-hill companies, inc. all rights reserved. an introduction...

1

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

An Introduction toObject-Oriented

Systems Analysis and Design with UML and

the Unified Process

McGraw-Hill, 2004

Stephen R. Schach

[email protected]

2


CHAPTER 20

TECHNICAL TOPICS

3


Chapter Overview

Source Code and Compiled Code Modularity Polymorphism and Dynamic Binding Example of Polymorphism and Dynamic Binding Maintenance Implications of Polymorphism and

Dynamic Binding

4


Source Code and Compiled Code

Programmers do not write all the code themselves– They invoke run-time routines as needed

A program exists in three forms– Source code– Compiled code– Executable load image

5


Source Code and Compiled Code (contd)

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

6



Transformation of source code into an executable load image

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

8



Recompiling one module, then relinking

9


Modularity

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

10


Modularity (contd)

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

11


Modularity (contd)

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

12


Modularity (contd)

Cohesion was first put forward in 1976

Best: Functional cohesion– 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

13


Modularity (contd)

A class is a module with informational cohesion

14


Modularity (contd)

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

15


Modularity (contd)

(a) Incorrect and (b) correct implementation of objects

16


Polymorphism and Dynamic Binding

The term polymorphism comes from two Greek words meaning “many shapes”

Example: Bank Card Class

17


Polymorphism and Dynamic Binding (contd)

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

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

19



In an object-oriented information system, choice of method is handled automatically

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

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

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

23


Example of Polymorphism and Dynamic Binding

While performing the design workflow, allocation of methods to classes is based on three factors– Responsibility-driven design– Inheritance– Polymorphism and dynamic binding

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

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

26



Object-oriented paradigm– Method printAsset utilizes polymorphism and dynamic

binding

27



Version 1: Wrong allocation of method printAsset

28


Polymorphism and Dynamic Binding Example

Version 1 uses inheritance instead of polymorphism– Method printAsset in class Asset Class is inherited

unchanged by the two subclasses

29



Version 2: Correct allocation of method printAsset

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

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

32


Maintenance Implications of Polymorphism

Consider Version 2 again:

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

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

35



Polymorphism and dynamic binding are extremely powerful aspects of object-oriented technology that – Promote development, but– Can have a deleterious impact on maintenance

slide 20.1 copyright © 2004 by the mcgraw-hill companies, inc. all rights reserved. an introduction...

Documents