CSC 395 –Software Engineering

Lecture 12:

Reusability –or–

Programming was Bjarne Again

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

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