Software Engineering Issues: Reusability, Portability and Interoperability

1
Software Engineering Issues Reusability,
Portability and Interoperability

• MSIT 182 Software Engineering
• Topic 5

2
Reuse Concepts

• Two types of reuse
• Accidental reuse
• First, the product is built
• Then, parts are put into the part database for
  reuse
• Planned reuse
• First, reusable parts are constructed
• Then, products are built using these parts

3
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 total software
  cost

4
Impediments to Reuse

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

5
What Sort of Reuse Rates Can We Expect?

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

6
Raytheon Missile Systems Division

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

7
Toshiba Fuchu Works, Tokyo

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

8
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

9
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

10
Hewlett-Packard

• Implemented in many divisions of the company
• Software Technology Division
• Accidental reuse of resource planning software
• 4.1 faults per KLOC (1,000 lines of code) of new
  code, 0.9 for reused code
• Overall fault rate decreased by 51
• Productivity increased by 57
• Cost 1 million, savings 4.1 million (198392)

11
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

12
European Space Agency

• Ariane 5 rocket blew up 37 seconds after lift-off
• Cost 500 million
• Reason Attempt to convert a 64-bit integer into
  a 16-bit unsigned integer
• The Ada exception handler was omitted
• The on-board computers crashed, and so did the
  rocket

13
European Space Agency (contd)

• The conversion was unnecessary
• Computations on the inertial reference system can
  stop 9 seconds before lift-off
• But, if there is a subsequent hold in the
  countdown, it takes several hours to reset the
  inertial reference system
• Computations therefore continue 50 seconds into
  the flight

14
European Space Agency (contd)

• The cause of the problem
• Ten years before, it was mathematically proved
  that overflow was impossibleon the Ariane 4
• Because of performance constraints, conversions
  that could not lead to overflow were left
  unprotected
• The software was used, unchanged and untested, on
  the Ariane 5
• However, the assumptions for the Ariane 4 did not
  hold for the Ariane 5
• Lesson
• Software developed in one context needs to be
  retested when integrated into another context

15
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

16
Objects and Reuse

• Claim of CS/D
• An ideal module has functional cohesion
• Problem
• The data on which the module operates
• We cannot reuse a module unless the data are
  identical

17
Objects and Reuse (contd)

• Claim of CS/D
• The 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

18
Reuse During Design and Implementation

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

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)

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

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)

22
Widget Generator

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

23
Abstract Factory Pattern

• Abstract classes and abstract (virtual) methods
• The interfaces between the client and the
  generator are abstract
• The application program is uncoupled from the
  specific operating system

24
Software Architecture

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

25
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 a factor of
  3
• Reuse has increased to over 70 of components

26
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

27
Objects and Productivity

• Reuse achieved
• Not via modules with functional cohesion,
• but via objects (informational cohesion)
  classes
• In general, as a consequence of reuse of objects
• Software costs have decreased
• Overall quality has improved
• Large products are essentially collection of
  smaller products

28
Difficulties and Problems

• Learning curve
• Particularly noticeable with a GUI
• Problems with inheritance
• A 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

29
Difficulties and Problems (contd)

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

30
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

31
Incompatibilities

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

32
Why Portability?

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

33
Portability Strategies

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

34
Portability Strategies (contd)

• Portable application software
• Use popular language
• Use popular operating system
• Adhere to language standards
• Avoid numerical incompatibilities
• Document meticulously

35
Portability Strategies (contd)

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

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

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)

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

39
Warning

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

40
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

41
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

42
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