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 • Storage–retrieval • 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% (1976–1982)

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

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

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