Slide 8.

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 Slide 8.2

REUSABILITY,
PORTABILITY, AND
INTEROPERABILITY

© The McGraw-Hill Companies, 2002

 Overview Slide 8.3

● 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

 Reuse Concepts Slide 8.4

● 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

 Why reuse? Slide 8.5

● 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
 Impediments to Reuse Slide 8.6

● Not invented here (NIH) syndrome

● Concerns about faults in potentially
reusable routines
● Storage–retrieval
● Cost of reuse

© The McGraw-Hill Companies, 2002

 What sort of reuse rates can we expect? Slide 8.7

● Theoretical maximum is 85%

● What can we get in practice?
● Consider case studies (1975 through 2000)

© The McGraw-Hill Companies, 2002

 Raytheon Missile Systems Division Slide 8.8

● 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

 Toshiba Fuchu Works, Tokyo Slide 8.9

● 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

 NASA Software Slide 8.10

● Ground support system for unmanned

spacecraft control
● Management permitted (but did not encourage)
accidental reuse
● Accidental reuse of
– Modules
● 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 Slide 8.12

● 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

 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 16-
bit 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 Slide 8.17

● 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

 Objects and Reuse (contd) Slide 8.18

● 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

Reuse During Design and Implementation Slide 8.19

● Design reuse
– Library or toolkit
– Framework
– Design pattern
– Software architecture

© The McGraw-Hill Companies, 2002

 Library or Toolkit Slide 8.20

● 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

 Application Framework Slide 8.21

● 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

 Design Pattern Slide 8.22

● 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

 Widget Generator Slide 8.23

● Tool that uses the

set of classes
created by the
widget generator

© The McGraw-Hill Companies, 2002

 Abstract Factory Pattern Slide 8.24

● 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
 Software Architecture Slide 8.25

● Encompasses a wide variety of design

issues, including:
– Organization in terms of components
– How those components interact

© The McGraw-Hill Companies, 2002

 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 Slide 8.27

● Reuse impacts maintenance more than development

● Assumptions
– 30% of entire product reused unchanged
– 10% reused changed

● Savings during maintenance are nearly 18%

● Savings during development are about 9.3%
© The McGraw-Hill Companies, 2002
 Objects and productivity Slide 8.28

● 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

 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 Slide 8.32

● 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

 Why Portability? Slide 8.33

● Difficulties hampering
portability
– One-off software
– Hardware incompatibility
– Lifetimes of software, hardware
– Multiple copy software
● Portability saves money!

© The McGraw-Hill Companies, 2002

 Portability strategies Slide 8.34

● Portable system software

– Isolate implementation-dependent
pieces
» UNIX kernel, device-drivers
– Levels of abstraction
» Graphics

© The McGraw-Hill Companies, 2002

 Portability Strategies (contd) Slide 8.35

● Portable application software

– Use popular language
– Use popular operating system
– Adhere to language standards
– Avoid numerical incompatibilities
– Excellent documentation

© The McGraw-Hill Companies, 2002

 Portability Strategies (contd) Slide 8.36

● Portable data
– COBOL, Pascal versus ASCII files
– DBMS

© The McGraw-Hill Companies, 2002

 Interoperability Slide 8.37

● 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

 COM Slide 8.38

● 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

 How COM Is Implemented Slide 8.39

● 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
● The COM library instantiates the COM
component

© The McGraw-Hill Companies, 2002

 Warning Slide 8.40

● COM uses object-oriented terminology

– Class
– Object
– Method
● However, COM is currently only object-
based, not object-oriented

© The McGraw-Hill Companies, 2002

 CORBA Slide 8.41

● International standard architecture for object-

oriented 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

 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