Object-Oriented%20and%20Classical%20Software%20Engineering%20%20Fifth%20Edition,%20WCB/McGraw-Hill,[e-mail]

1
Object-Oriented and Classical Software
Engineering Fifth Edition, WCB/McGraw-Hill,
2002Stephen R. Schachsrs_at_vuse.vanderbilt.edu
2
CHAPTER 8
REUSABILITY, PORTABILITY, AND INTEROPERABILITY
3
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

4
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

5
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

6
Impediments to Reuse

• Not invented here (NIH) syndrome
• Concerns about faults in potentially reusable
  routines
• Storageretrieval
• Cost of reuse

7
What sort of reuse rates can we expect?

• Theoretical maximum is 85
• What can we get in practice?
• Consider case studies (1975 through 2000)

8
Raytheon Missile Systems Division

• Data-processing software
• Planned reuse of
• Designs
• 6 code templates
• COBOL code
• 3200 reusable modules
• Reuse rate 60 (19761982)

9
Toshiba Fuchu Works, Tokyo

• Industrial process control systems
• Accidental reuse of
• Specifications
• Designs
• Modules
• Contracts
• Manuals
• Standards
• Reuse rate (1985)
• 33 design
• 48 code

10
NASA Software

• 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

11
GTE Data Services

• 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

12
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 (198392)

13
Hewlett-Packard (contd)

• San Diego Technical Graphics (STG)
• Planned reuse of firmware for printers
• Cost 2.6 million, savings 5.6 million (198794)
• 24 reduction in faults
• 40 increase in productivity
• Cost of developing reusable firmware11 more
• Cost of reusing it19 of developing from scratch

14
European Space Agency

• 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

15
European Space Agency (contd)

• Cause of problem
• Ten years before, it was mathematically proven
  that overflow was impossibleon 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

16
Size of Reused Components

• 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

17
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

18
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

19
Reuse During Design and Implementation

• Design reuse
• Library or toolkit
• Framework
• Design pattern
• Software architecture

20
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)

21
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

22
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)

23
Widget Generator

• Tool that uses the set of classes created by the
  widget generator

24
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

25
Software Architecture

• Encompasses a wide variety of design issues,
  including
• Organization in terms of components
• How those components interact

26
Reuse of Software Architecture

• 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

27
Reuse and Maintenance

• 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

28
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

29
Difficulties and Problems

• 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

30
Difficulties and Problems (contd)

• Advantages far outweigh the problems
• Numerous refereed (e.g., Capper et al., 1994)
  and informal (OOPSLA Addendum) reports

31
Portability

• 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

32
Incompatibilities

• Hardware (disk, tape, characters, parity)
• Operating system (JCL, virtual memory)
• Numerical software (word size, Ada)
• Compiler
• FORTRAN
• Pascal
• COBOL
• C
• Ada
• C
• Java

33
Why Portability?

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

34
Portability strategies

• Portable system software
• Isolate implementation-dependent pieces
• UNIX kernel, device-drivers
• Levels of abstraction
• Graphics

35
Portability Strategies (contd)

• Portable application software
• Use popular language
• Use popular operating system
• Adhere to language standards
• Avoid numerical incompatibilities
• Excellent documentation

36
Portability Strategies (contd)

• Portable data
• COBOL, Pascal versus ASCII files
• DBMS

37
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

38
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)

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

40
Warning

• COM uses object-oriented terminology
• Class
• Object
• Method
• However, COM is currently only object-based, not
  object-oriented

41
CORBA

• 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

42
Comparing COM and CORBA

• 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

43
Future Trends in Interoperability

• COM and CORBA are currently the big two
• Other interoperability products may succeed, such
  as JavaBeans
• Web-based applications need to be integrated into
  clientserver products
• XML (Extensible Markup Language) will probably
  play a major role