You are on page 1of 36

Software Reuse

This is the concept that all or part of a computer program can be re-used at a relater time.  A technique which attempts to save time, energy and money by reducing the duplication of work.
Adapted from http://en.wikipedia.org/wiki/Software_reuse

Software Reuse


The design process in most engineering disciplines is based on component reuse.  Software systems design traditionally assume that components are implemented specifically for the system being developed.

Software Reuse
Examples: Software libraries Subroutines, objects or classes BUT! What about larger portions of code?

Software Reuse


Reusable components and frameworks are inherently abstract, making it hard to create quality components and hard manage their production. The skills required to develop, deploy, and support reusable software have traditionally been a black art, locked in the heads of expert developers. These technical impediments to reuse are compounded by common non-technical problems that add additional organizational, economical, administrative, political, and psychological difficulties.

Adapted from http://www.cs.wustl.edu/~schmidt/reuse-lessons.html

Software Reuse


In principle, organizations recognize the value of systematic reuse and reward internal reuse efforts. In practice, many factors conspire to make systematic software reuse hard.

Software Reuse: Non Technical Issues




Organizational impediments -- Developing, deploying, and supporting systematically reusable software requires a deep understanding of what the application developer needs and business the requirements. Economic impediments -- Supporting organization-wide reusable components requires an economic investment. Administrative impediments Reusable components are hard to catalog, archive, and retrieve, especially across multiple business units within large organizations. Developers often find it hard to locate suitable reusable assets outside or even inside their immediate workgroups.

Software Reuse: Non Technical Issues


 Political impediments -- Groups that develop reusable software are often viewed with suspicion by other application developers.  Psychological impediments  Application developers may also perceive top down reuse efforts as an indication that management lacks confidence in their technical abilities.  The not invented here syndrome is ubiquitous in many organizations, particularly among highly talented programmers.

Software Reuse
Common reuse: -- Components only This is slowly changing: Why?

Software Reuse
   

Demand for lower software costs. Reuse enhances improved reliability Reused components are "proven." Design and implementation faults are discovered and "eliminated."

Software Reuse
Reuse shouldn't focus just on code but on design....

Software Reuse


Code may contain specialized details that make reuse difficult. Designs are by nature more abstract having wider application.

Reuse can occur at different levels:


   

Application system reuse SubSub-system reuse Module or object reuse Function reuse

Application system reuse


The whole application may be reused Key problem ==> portability

SubSub-system reuse
Major sub-system of an application submay be reused.

Module or object reuse




Components of a system might be reused Java object for a binary tree

Function reuse


Software component for a single function (method) might be reused Ex: mathematical function

Software Reuse


Application system reuse is widely practiced. (Billing systems, payroll systems, registration systems) What does this mean in practice?

Software Reuse


Function reuse is also common.


- Individual developer designed tools - Java API - Game components

How is this different from application system reuse?

WHY Reuse?
 Reduce development costs
    

Increase system reliability Reduce overall process risk More effective of specialists Organizational standards can be built-in. builtSoftware development time reduced.

But...


To make effective use of reusable components we cannot first design a system and THEN search for reusable components. The design process MUST be reuse driven.

Software Reuse
System requirements must be modified according to the availability of reusable components.

Reuse Problems:
 Difficult to quantify cost reduction


CASE tools do not really support reuse Some software engineers prefer to rewrite components

Rewrite Components
WHY?
 Poor techniques for classifying,

cataloging and retrieving software components Legal issues

Systematic reuse requires a properly cataloged and documented database of reusable components.

WHY??

Intellectually, we assume that a reuse database exists In most places such databases are fiction!

Components that are created as part of an applications development are NOT likely to be immediately reusable.

WHY??

Software Reuse


Creating reusable components is difficult To make a component truly general, ALL the operation classes that might be needed must be specified.

Software Reuse
Current reuse focuses on portability issues.

Reuse Problems:
Special features of individual machines  Machine architecture  Operating system  Run-time system Run Library problems

Machine architecture
The program makes assumptions about the underlying hardware -- these assumptions are rarely true for ALL machines

Operating system
Program call operating system facilities that are not available on ALL host machines

RunRun-time system
Program uses particular run-time runsystem features which are not universal (ex. dynamic checking)

Library problems


Not all libraries are available on all machines. Not all libraries contain everything you might expect them to include.

Reuse Solutions???
Reduce the use of special features -- Create Standards
 Programming language
  

Operating system Networking Window system

Reuse -- Legal Issues:

Software Reuse
Do we need to Invent or Create a Super- Language? SuperIs Java that language or even that style of language?