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
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
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
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
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
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
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
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
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
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…
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
Inheritance
OO method of specializing generic behavior Place all the common actions in the superclass Rely on polymorphism to call correct class
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?
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?
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
Top Related