1. Reusability and Portability Chapter 8 CSCI 4320

2. Reusability and Portability  The length of the development process is critical.  No matter how high the quality of a software product, it will not sell if it takes 2 years to get it onto the market when a competitive product can be delivered in only one year.

3. Reusability and Portability  Reuse Using the components of one product to develop a different product.  Portable Easily modifying a product as a whole to run it on another hardware/ system configuration rather than to recode it from scratch.

4. Examples of Reuse  Musicians “sampling” other well-known music  Using existing C++ or Java libraries to find square root of a number C++ Standard Template Library (STL) Java Application Programming Interface (API)

5. Reuse Concepts  Opportunistic Reuse (accidental reuse) Developers of new product realize that a previously developed product component can be reused in new product  Systematic Reuse (deliberate reuse) Software constructed specifically for possible future reuse More likely to be easy and safe to reuse Generally well documented and thoroughly tested Initial overhead is expensive – it takes time to thoroughly test

6. What can be reused?  [Jones, 1984] only 15% of any software is original.  The other 85% in theory could be standardized and reused in future products.

7. Why Not Reuse?  Many software professionals would rather rewrite a routine from scratch that reuse a routine written by someone else.  Believe routine may introduce faults – it may not be fully tested  A large organization may have hundreds of thousands of routines. How do you store these to be easily retrieved? How do you know which one to reuse?

8. Why not Reuse  Legal issues A product may be developed for a particular client. Reusing a component for a different client may constitute a copyright violation.  If commercial off-the-shelf (COTS) components are used, source code may not be known. Limited modifiability.

9. Testing is still needed…  Software developed in one context must be retested when used in another context.  The software module does not have to be retested by itself; it must be retested after it has been integrated into the product.  Case Study: European Space Agency launched and Ariane 5 rocket with components from Ariane 4 rocket. The rocket crashed about 37 seconds after lift off. Assumptions true for the Ariane 4 rocket were not true for the Ariane 5 rocket.

10. Reuse during Design and Implementation  Use a class (Customer) from an earlier design Good if organization develops software in one specific application domain, banking, air traffic control systems  Reusing graphical user interface  Application Framework – incorporates the control logic of a design Microsoft Foundation Class Library (MFC) allow you to build GUIs in Windows-based applications.  Moving/resizing windows, handling events: mouse clicks or menu selection  Domain components  Use case templates

11. Reuse and Postdelivery Maintenance  The major impact of reuse is on postdelivery maintenance rather than development Reused components are generally  well designed,  thoroughly tested,  comprehensively documented thereby simplifying postdelivery maintenance

12. Portability  Reasons to make software portable Commercial off-the shelf software  Recoup development costs with new clients that have different hardware/ system configurations Every 4 years or so, when the client organization purchases new hardware all of its software must be converted to run on the new hardware. A product is considered portable if its significantly less expensive to adapt the product to run on new computer than to develop it from scratch.

13. Portability –Potential Incompatibilities  Hardware Current product backs up data on a DAT tape, new computer system uses Zip drive for backup Different coding schemes ASCII, EBCDIC, UnicodeASCIIEBCDICUnicode  Operating Systems (Windows, Mac)  Data types Depending on the language, when a data type is complied the memory size allocated may differ.  Depending on the machine, a Pascal integer may be represented as 16- bits or 32 bits Java solves this problem with 8 primitive data types that are always the same memory size.  Compilers Some programming languages do not have compilers for all hardware (CLU)CLU

14. Techniques for Achieving Portability  Isolate implementation-dependent pieces The original UNIX operating system consisted of 10,000 lines of code  2000 lines - rewritten for each implementation Kernel: 1000 lines of code written in assembler Device Drivers: 1000 lines of code written in C  The remaining 8000 lines of code written in C remained largely unchanged  Use levels of abstraction High-level code artifacts reference abstract drawLine() Low-level code – written for the different types of hardware

15. Techniques for Achieving Portability  Write product in high-level language (not assembler)  Provide installation manual and lists of changes to be made  Provide routines to convert database into an unstructured sequential file (example: excel file converted into a text file)

16. Summary  Why Reusability? Shorter development time Lower development cost Higher quality software Shorter maintenance time Lower maintenance cost  Why Portability? The life of a software product is generally longer than the life of the hardware for which it was first written.