COMP 325 Lecture 7: Reuse, Reusability, and Portability
major resources: Object-Oriented and Classical Software Engineering 6ed, Schach 2005, Object-Oriented Software Engineering, Schach 2008.

[ previous | schedule | next ]

Definitions

• reuse: using components from an existing product in development of different product
• reusability: quality measure of a component regarding how easily it can be reused
• portability: quality measure of a product regarding how easily it can be adapted to run in a different operating environment

Reuse

• reuse not limited to code; any artifact/component can potentially be reused
• internally-developed components can be designed for reuse systematically, with several benefits
  • encourages reuse as a culture
  • benefit from time savings
  • components likely to be well-designed and robust
  • components likely to be well-tested and documented
  • components more likely to contribute to loose coupling when integrated
  • in short, such components are likely to be of high quality
• Reuse sounds great! What are some of the downsides?
• it is expensive to develop components of the high quality required
• it is expensive to organize, find, and retrieve reusable components
• NIH (not invented here) syndrome; prefer to reinvent wheel
• external client ownership of component may prohibit its reuse
• license terms may impede reuse (e.g. GNU Public License)
• false sense of security could lead to reduced testing of reused component and subsequent failure due to new product environment
• good OO design leads to strong cohesion, which promotes reuse
• OO inheritance is double-edged sword. Inherited methods are re-used, but subclass is coupled to its parent class.

Design Reuse

• reusing design artifact from previous project
• Why?
• saves development and maintenance time and money
• good chance that component will be of high quality
• How?
• library or toolkit, typically set of functions or classes. These are implementation oriented but their organization can guide design
• framework, which provides control logic design. Example: framework for compiler design that forms basis for lex, yacc (you provide language specification, they contain compiling logic)
• design patterns, design solution to recurring situations specified as set of generic classes and relationships. You customize according to pattern.
• Example of observer pattern used in many contexts. When observable changes, all observers are notified and can respond
• Example of template pattern used in many frameworks (framework provides algorithm written to interface, you implement the interface)
• Example of adapter pattern, which defines a wrapper to make one kind of object behave like another
• sw architecture combines the above (description of system elements, their interactions, patterns to compose them) to permit highest level of reuse.

Reuse in Implementation and Post-Delivery Maintenance

• in OO world, implementation follows directly from design
• similar motivations and solutions as above
• reused components generally require less corrective maintenance because of bugs having already been discovered and corrected
• the same qualities that lead to development savings also result in lower post-delivery maintenance costs

Reusability

• measure of "how reusable" a component is
• enhanced through use of techniques described above

Portability Issues

• portability important because successful software outlasts the hardware it was developed on/for
• some hardware issues include
• device types
• machine word length
• machine languages
• machine architecture in general, mac-pc-sparc
• some operating system issues include
• job control language and API
• memory models (page size, overlays)
• OS standards, or lack thereof (UNIX as example)
• numeric issues include
• floating pt results differ slightly depending on representation and implementation of operations
• language standards, or lack thereof, for numeric formats (e.g. for int, float sizes)
• compiler issues include
• variations in language recognized, unless there is language standard
• variations in data type storage and operations (mentioned above)
• data issues include
• character encoding
• data format (e.g. structured vs stream)
• DB and DBMS technology

Achieving Portability

• use of language standards
• isolating non-portable parts (e.g. UNIX asm kernel)
• abstraction layers (e.g. Java Swing)
• choice of popular OS as target platform
• unstructured (stream) data storage
• choice of popular DBMS

Reuse, reusability, and portability

• how are each related to the others?
• does highly portable infer highly reusable?
• does highly reusable infer highly portable?
• does designing for reuse enhance portability as well as reusability?