1. CSC 395 – Software Engineering Lecture 12: Reusability –or– Programming was Bjarne Again

2. Today’s Goal Why reusability & portability are important What this has to do with OO goals How OO can improve reuse & portability Begin thinking about next stage of project Must develop analysis & design from your requirements document These are make-or-break parts of any project

3. Thought Experiment Suppose you could use an approach Already tested in many environments Many/most bugs have been found & documented Several teams already know extensively Available for less than entirely new development Only 15% of new code is really original 85% could be standardized and reused Actual reuse rates usually about 40% Lack of design prevents capitalizing gains Ignoring closest thing to a free lunch

4. Barriers to software reusability Not-invented-here (NIH) syndrome Egos and personalities prefer code they wrote Concerns about reliability of others’ code Need accessible library of reusable modules This may requires lots of time & money Need people to maintain and update code (bit rot) May discover hard-to-fix regression failures Modules may have low cohesiveness or coupling Developing reusable modules can be expensive

5. Barriers to software reusability Legal issues may arise over components Clients often place restrictions on completed project Assumes client does not own modules used Can introduce more sophisticated library demands COTS components place additional restrictions May not be able to modify software Licensing may restrict how COTS software used Cost of reuse can be high Must understand module’s finer points Still need some testing if data/environment are new

6. Reuse From Design Workflow Designs are good source of reuse Opportunistic reuse within an application domain Create framework containing common logic Develop toolkit of commonly used routines Specify expected patterns of behavior Must keep modules independent Clearly specify how modules should be used Also state what plug-ins responsibilities are

7. Reuse Architecture Create software product lines Examples include: Word, Excel, Madden Very common in drivers, BIOS, & other firmware Firmware for HP printers (95-98) 75% fewer person–hours to develop firmware 70% of components could be reused

8. Biggest Reuse Gain Impacts maintenance most of all But over 50% of budget spent on maintenance! Reused products cheaper to maintain Must be clearly & exhaustively documented Will have been tested in variety of situations Design is relatively clean and uncomplicated Even reusing just 40% of a product ¼ th of which (10% of total) had to be modified Could easily save 18% of total development costs

9. Data Encapsulation

10. Data Encapsulation Benefits OO places functions for data in single class Limits amount of coupling that can occur Encourages creating high level of cohesion Reduces development & maintenance costs Properly encapsulated modules are reusable Move class to any system where data reappears Since data is similar, expectations are that functionality should also be unchanged Encourages abstraction Work at highest levels until latest possible time

11. Stepwise Refinement Split project into high-level, abstract concepts Splitting should not consider implementation issues Assume that all needed functionality exists Looking for project’s key ideas and concerns Develop each of the concepts separately Create the ideal implementation of this concept Only (limited) external concern is supporting functionality used by other concepts Creating reusable component so do not focus on current project

12. STEPwise Refinement May create several layers of abstraction Continue until concepts are ridiculously simple Few complaints about “too good” or “too easy” Identify project aspects most likely to change This is typically in implementation details Work on these parts as late as possible and rely on them as little as possible Rarely are these details reusable anyway…

13. Information Hiding Reusable components limit what is known Design considers functionality, not implementation Should generalize data types whenever possible Never expose fields directly Makes changing implementation easy to do During implementation use interfaces & private Items likely to change minimally available Changes localized to within a module Minimize porting between projects

14. Inheritance OO method of specializing generic behavior Place all the common actions in the superclass Rely on polymorphism to call correct class

15. Why OO is Bad Overhead for development can be large Increases learning curve for first-time coders More required “magic” than in other paradigms Inheritance can cause problems Design needs to be good from the start Small changes to superclass have huge impact Hard to pick and choose what is inherited Objects low in tree can become large What should be done when 3 of 4 children have code in common?

16. Discussion Question A module has coincidental cohesion; to improve the opportunities for reuse, you suggest splitting each of its actions into its own module. Is this a good idea? Are there any other tasks that you would need to do?

17. For Next Lecture Begin discussion OO analysis Where do these classes and ideas come from? How do we express them in UML? Why should we express them in UML? Keep thinking about next stage of project Must develop analysis & design from your requirements document These are make-or-break parts of any project