Enhancing Software Reusability for Efficiency

1. Object-Oriented and Classical Software EngineeringFifth Edition, WCB/McGraw-Hill, 2002Stephen R. Schachsrs@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 • Storage–retrieval • 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% (1976–1982)

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 (1983–92)

13. Hewlett-Packard (contd) • 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

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

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 client–server products • XML (Extensible Markup Language) will probably play a major role