Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu

Description:

Title: The Software Process Author: Stephen R. Schach Last modified by: McGraw-Hill Higher Education Created Date: 9/28/2000 7:34:01 PM Document presentation format – PowerPoint PPT presentation

Number of Views:792
Avg rating:3.0/5.0
Slides: 44
Provided by: Step194
Learn more at: http://www.mhhe.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu


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
About PowerShow.com