Slide 8.1
Object-Oriented and
Classical Software
Engineering
Fifth Edition, WCB/McGraw-Hill, 2002
Stephen R. Schach
srs@vuse.vanderbilt.edu
© The McGraw-Hill Companies, 2002
CHAPTER 8
REUSABILITY,
PORTABILITY, AND
INTEROPERABILITY
© The McGraw-Hill Companies, 2002
Slide 8.2
Overview









Reuse concepts
Impediments to reuse
Reuse case studies
Objects and reuse
Reuse during the design and implementation
phases
Reuse and maintenance
Portability
Techniques for achieving portability
Interoperability
© The McGraw-Hill Companies, 2002
Slide 8.3
Reuse Concepts

Two types of reuse
– Accidental reuse
» First, product is built
» Then, parts put into part database for reuse
– Planned reuse
» First, reusable parts are constructed
» Then, products are built using these parts
© The McGraw-Hill Companies, 2002
Slide 8.4
Why reuse?

Minor Reason
– It is expensive to design, implement, test, and
document software
– Only 15% of new code serves an original purpose
(average)
– Reuse of parts saves
»
»
»
»

Design costs
Implementation costs
Testing costs
Documentation costs
Major Reason
– Maintenance

Maintenance consumes two-thirds of software
cost
© The McGraw-Hill Companies, 2002
Slide 8.5
Impediments to Reuse




Not invented here (NIH) syndrome
Concerns about faults in potentially
reusable routines
Storage–retrieval
Cost of reuse
© The McGraw-Hill Companies, 2002
Slide 8.6
What sort of reuse rates can we expect?



Theoretical maximum is 85%
What can we get in practice?
Consider case studies (1975 through 2000)
© The McGraw-Hill Companies, 2002
Slide 8.7
Raytheon Missile Systems Division


Data-processing
software
Planned reuse of
– Designs
» 6 code templates
– COBOL code
» 3200 reusable
modules

Reuse rate 60%
(1976–1982)
© The McGraw-Hill Companies, 2002
Slide 8.8
Toshiba Fuchu Works, Tokyo


Industrial process control systems
Accidental reuse of
–
–
–
–
–
–



Specifications
Designs
Modules
Contracts
Manuals
Standards
Reuse rate (1985)
33% design
48% code
© The McGraw-Hill Companies, 2002
Slide 8.9
NASA Software



Ground support system for unmanned
spacecraft control
Management permitted (but did not encourage)
accidental reuse
Accidental reuse of
– Modules

Slide 8.10
Reuse rate (1982)
– 28% reused unchanged
– 10% reused with minor changes
© The McGraw-Hill Companies, 2002
GTE Data Services


Slide 8.11
Data-processing software
Strongly encouraged by management
– Cash incentives when module was accepted for reuse
– Cash incentive when module was reused

Accidental reuse of
– Modules

Reuse rate
– (1988) 15% reused code, $1.5 million saved
– (est. 1989) 20% reused code
– (est. 1993) 50% reused code
© The McGraw-Hill Companies, 2002
Hewlett-Packard


Implemented in many divisions of the
company
Software Technology Division
– Accidental reuse of resource planning software
– 4.1 faults per KLOC of new code, 0.9 for reused
code
– Overall fault rate decreased 51%
– Productivity increased 57%
– Cost $1 million, savings $4.1 million (1983–92)
© The McGraw-Hill Companies, 2002
Slide 8.12
Hewlett-Packard (contd)

Slide 8.13
San Diego Technical Graphics (STG)
–
–
–
–
–
–
Planned reuse of firmware for printers
Cost $2.6 million, savings $5.6 million (1987–94)
24% reduction in faults
40% increase in productivity
Cost of developing reusable firmware—11% more
Cost of reusing it—19% of developing from scratch
© The McGraw-Hill Companies, 2002
European Space Agency





Slide 8.14
Ariane 5 rocket blew up 37 seconds after lift-off
Cost: $500 million
Reason: attempt to convert 64-but integer into 16bit unsigned integer, without Ada exception
handler
On-board computers crashed, so did rocket
Conversion was unnecessary
– Computations on the inertial reference system can stop
9 seconds before lift-off
– But, if there is a subsequent hold in countdown, it takes
several hours to reset the inertial reference system
– Computations therefore continue 50 seconds into flight
© The McGraw-Hill Companies, 2002
European Space Agency (contd)

Slide 8.15
Cause of problem
– Ten years before, it was mathematically proven that
overflow was impossible—on the Ariane 4
– Because of performance constraints, conversions that
could not lead to overflow were left unprotected
– Software was used, unchanged and untested, on
Ariane 5
– But, the assumptions for the Ariane 4 no longer held

Lesson
– Software developed in one context needs to be
retested when integrated into another context
© The McGraw-Hill Companies, 2002
Size of Reused Components

Slide 8.16
NASA
– Most reused components were small

Toshiba
– Many large components were reused

GTE
– Many large components were reused

Reason
– A strong managerial commitment for reuse is needed
© The McGraw-Hill Companies, 2002
Objects and Reuse

Claim of CS/D
– Ideal module has functional cohesion

Problem
– The data on which the module operates

We cannot reuse a module unless the
data are identical
© The McGraw-Hill Companies, 2002
Slide 8.17
Objects and Reuse (contd)

Claim of CS/D:
– Next best module has informational cohesion
– This is an object (an instance of a class)


An object comprises both data and action
This promotes reuse
© The McGraw-Hill Companies, 2002
Slide 8.18
Reuse During Design and Implementation

Design reuse
–
–
–
–
Library or toolkit
Framework
Design pattern
Software architecture
© The McGraw-Hill Companies, 2002
Slide 8.19
Library or Toolkit


Set of reusable routines
Examples:
– Scientific software
– GUI class library or toolkit

The user is responsible
for the control logic (white
in figure)
© The McGraw-Hill Companies, 2002
Slide 8.20
Application Framework





Control logic of the design
“Hot spots” (white in figure)
Faster than reusing toolkit
More of design is reused
The logic is usually harder to
design than the operations
© The McGraw-Hill Companies, 2002
Slide 8.21
Design Pattern



A solution to a
general design
problem
In the form of a set
of interacting
classes
The classes need
to be customized
(white in figure)
© The McGraw-Hill Companies, 2002
Slide 8.22
Widget Generator

Tool that uses the set
of classes created by
the widget generator
© The McGraw-Hill Companies, 2002
Slide 8.23
Abstract Factory Pattern



Abstract classes
and abstract
(virtual) methods
The interfaces
between client and
program and
generator are
abstract
The application
program is
uncoupled from the
specific operating
system
© The McGraw-Hill Companies, 2002
Slide 8.24
Software Architecture

Encompasses a wide variety of design
issues, including:
– Organization in terms of components
– How those components interact
© The McGraw-Hill Companies, 2002
Slide 8.25
Reuse of Software Architecture


Slide 8.26
Architecture reuse can lead to large-scale reuse
One mechanism:
– Software product lines

Case study:
– Hewlett-Packard printers (1995 to 1998)
» Person-hours to develop firmware decreased by a factor of 4
» Time to develop firmware decreased by factor of 3
» Reuse has increased to over 70% of components
© The McGraw-Hill Companies, 2002
Reuse and Maintenance


Reuse impacts maintenance more than development
Assumptions
– 30% of entire product reused unchanged
– 10% reused changed


Slide 8.27
Savings during maintenance are nearly 18%
Savings during development are about 9.3%
© The McGraw-Hill Companies, 2002
Objects and productivity

Reuse achieved
– Not via modules with functional cohesion,
– but via objects (informational cohesion)
[classes]

In general
– Software costs have decreased
– Overall quality has improved
– Large products are essentially collection of
smaller products
© The McGraw-Hill Companies, 2002
Slide 8.28
Difficulties and Problems

Slide 8.29
Learning curve
– Particularly noticeable with GUI

Problems with inheritance
– New subclass does not affect its superclass
– But, any change to a superclass affects all its
subclasses
– Subclasses low in the inheritance tree can be huge
(inherited attributes)

Polymorphism and dynamic binding
– Maintenance problems were already discussed
© The McGraw-Hill Companies, 2002
Difficulties and Problems (contd)

Slide 8.30
Advantages far outweigh the problems
– Numerous refereed (e.g., [Capper et al., 1994]) and
informal (OOPSLA Addendum) reports
© The McGraw-Hill Companies, 2002
Portability



Slide 8.31
Product P: Machine M1 Op. Sys. O1 Compiler C1
Need P': Machine M2 Op. Sys. O2 Compiler C2
P is portable if it is cheaper to port P than to write
P' from scratch
© The McGraw-Hill Companies, 2002
Incompatibilities




Hardware (disk, tape, characters, parity)
Operating system (JCL, virtual memory)
Numerical software (word size, Ada)
Compiler
–
–
–
–
–
–
–
FORTRAN
Pascal
COBOL
C
Ada
C++
Java
© The McGraw-Hill Companies, 2002
Slide 8.32
Why Portability?

Difficulties hampering
portability
–
–
–
–

One-off software
Hardware incompatibility
Lifetimes of software, hardware
Multiple copy software
Portability saves money!
© The McGraw-Hill Companies, 2002
Slide 8.33
Portability strategies

Portable system software
– Isolate implementation-dependent
pieces
» UNIX kernel, device-drivers
– Levels of abstraction
» Graphics
© The McGraw-Hill Companies, 2002
Slide 8.34
Portability Strategies (contd)

Portable application software
–
–
–
–
–
Use popular language
Use popular operating system
Adhere to language standards
Avoid numerical incompatibilities
Excellent documentation
© The McGraw-Hill Companies, 2002
Slide 8.35
Portability Strategies (contd)

Portable data
– COBOL, Pascal versus ASCII files
– DBMS
© The McGraw-Hill Companies, 2002
Slide 8.36
Interoperability

The mutual cooperation of object code
– From different vendors
– Written in different languages
– Running on different machines

Example:
– Nation-wide network of ATMs
»
»
»
»
Server runs database software
Clients (ATMs) run C++
Communications software
Security
© The McGraw-Hill Companies, 2002
Slide 8.37
COM

Common Microsoft mechanism for all
component services
– Within the same process
» Invocation
– Different processes on the same machine
» Interprocess communication
– Between different machines
» Remote process call (RPC)
© The McGraw-Hill Companies, 2002
Slide 8.38
How COM Is Implemented




Each piece is implemented as a COM
component (“object”)
Each component has one or more interfaces
Each interface supports one or more functions
(“methods”)
The client calls the COM library and specifies
– The class of the component
– The specific interface

Slide 8.39
The COM library instantiates the COM
component
© The McGraw-Hill Companies, 2002
Warning

COM uses object-oriented terminology
– Class
– Object
– Method

However, COM is currently only objectbased, not object-oriented
© The McGraw-Hill Companies, 2002
Slide 8.40
CORBA



International standard architecture for objectoriented systems
Object request broker (ORB) allows client to
invoke a method of any object in the system
“The mother of all client/server middleware”
© The McGraw-Hill Companies, 2002
Slide 8.41
Comparing COM and CORBA

Slide 8.42
CORBA is an international standard
– Implemented on a wide variety of platforms

COM is a Microsoft product
– Hard to use with non-Microsoft products

Integration of COTS software is easier with COM
– Most COTS software is supplied by Microsoft

CORBA is much simpler than COM
© The McGraw-Hill Companies, 2002
Future Trends in Interoperability




Slide 8.43
COM and CORBA are currently the “big two”
Other interoperability products may succeed,
such as JavaBeans
Web-based applications need to be integrated
into client–server products
XML (Extensible Markup Language) will probably
play a major role
© The McGraw-Hill Companies, 2002