Software Reuse

Software Reuse
Course Code : CSE531 Text Book: Software Reuse: Architecture, Process and Organization for Business Success By Ivar Jacobson. Martin 1st Griss, Patrik Johansson, 1st edition. Credits: 3.0

Outline
An introduction to software reuse. Definitions. Types. Benefits. Drawbacks.

Software reuse principles

Hardware reuse
Use the same tool more than once, producing the same product more than once, etc.

Software reuse: dont reinvent the wheel

Use the same knowledge more than once. Create a new software by reusing piece of existing software rather than creating new software from scratch.

What is Software Reuse?

In most engineering disciplines, systems are designed by composing existing components that have been used in other systems. It helps to achieve better software, more quickly and at lower cost.

Reuse concept
Some problems about producing a car:
How to produce a car nowadays? (how to produce the first car?) Will you design and produce an engine from scratch? How to design and produce a new model of a car?

engine

body

wheels

other parts

compose

car

Reuse concept
A new engine model in an existing body model results in a new car model (reuse the design of bodies) A new engine can be designed based on existing engines (reuse the design of engines) As a summary, parts of a car (or the design of the parts) can be reused for new cars (or models). A necessary condition for the reuse: part interface should be compatible.

Software reuse concept

Software reuse refers to reusing existing software to produce new software Software to reuse:
Both documents and code The entire software systems, software architecture, subsystems, classes, modules, and so on

It is possible that some parts of the intended software cannot be produced though reuse. In this case, the parts should be created from scratch.

intended system

reusable components

A+B =

This part should be created from scratch

Opportunistic Reuse

Design system aachitecture

Specify components

Search for reusable components

Incorporate discovered components

Development Reuse as a Goal

Outline system requirements Search for reusable components Modify requirements according to discovered components

Architectural design

Search for reusable components

Specify system components based on reusable components

What can be reused?

1. 2. 3. 4. 5. 6. 7. Code Requirements Architecture/design documents Test Plans Manuals Templates for any assets Design decision

Why Reuse?
Because we (the CS people) are inventing the wheel over and over again and wasting enormous resources doing so. We hope that there is a way to make integration and design of the reusable components cheaper than redevelopment.

The goal of software reuse is to reduce the cost of software production by replacing creation with recycling.

How Reuse Happens?

Accidental reuse
Cut and paste

Deliberate reuse
Visual Basic Stdio.h

Purpose of Reuse
Cheaper products.
Shorter development time. Increase productivity Decrease testing domain. Easier maintenance.

Better quality products.

Code that was written for reuse.
Has better specifications. Is more thoroughly tested.

Software utilizing reused code has to be

Better specified. Well standardized Organized.

Software reuse motivation

Develop software faster (i.e., improve productivity) Develop better software (i.e., improve software quality)
Rationale: the reused software has been verified

Develop cheaper software

In both budget and schedule In both development and maintenance

Software reuse gains

Experiences of the authors:
Time to market: reduction of 2 to 5 times Defect density: reduction of 5 to 10 times Maintenance cost: reduction of 5 to 10 times Overall software development cost: reduction of 15% to 75% (this includes the overhead of developing reusable components)

Steps towards achieving systematic reuse:

1. Reuse is desired, but nothing is done to make it happen. Ad hoc reuse is encouraged, object technology may be introduced, but no formal reuse program is visible. 2. An attempt is made to formally introduce reuse. A code or class library may be set up and publicized, but little attention is paid to handling the "soft factors" or to managing the organization through its adoption of reuse.

Drawbacks of Reuse
1. 2. 3. Code designed for reuse is more expensive to create. Integrating reusable code introduces an overhead in the development process. Maintaining the reusable resources requires added mechanisms.

Ariane launcher failure

In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster when the launcher went out of control 37 seconds after take off.

Photos from: Wikipedia and http://www3.imperial.ac.uk/spat/research/space_missions/cluster/history

Ariane launcher failure

The problem was due to a reused component from Ariane 4.
Component failed because assumptions made for Ariane 4 did not hold for Ariane 5.

Floating point to integer conversion of thrust value caused overflow and triggered an unhandled exception that shut down the Inertial Navigation System.
The value stored in Ariane 4 was never large enough to cause overflow.

The functionality that failed in this component was not required in Ariane 5.

Software development with reuse

23

Software development for reuse

24

Software reuse categorization

1. 2. 3. 4. 5. Ad hoc reuse Library or repository based reuse Generator Framework Systematic reuse

Ad hoc reuse
No planning, no engineering (for reuse), no tool support, and even no component base Example: copy and paste program code developed before

Library or repository based reuse

Reusable components are stored in a library (or repository) Classification and retrieval techniques/tools should be provided Example: libraries in programming language, software ICs, and so on.

Library or repository based reuse

Classification and retrieval techniques:
based on names (e.g., library in programming languages) based on keywords based on attributes based on behavior etc.

Generator
Reusable components are parameterized. When reuse a component, parameters should be offered. Then, the generator generates software for the reuser Example: wizards in setting up a driver or application (e.g., MS Word)

Program Generation
Application description Program generator Generated program

Application domain knowledge

Database

Framework
A framework is reused. The detailed contents should be created by the reuser Example: VB components

Systematic reuse
Domain engineering for designing components for reuse Application system engineering for developing software through reuse Reuse starts from the requirement analysis phase down to the implementation (and even testing and maintenance) phase We focus on this reuse

Reuse approaches
Design patterns Generic abstractions that occur across applications are represented as design patterns that show abstract and concrete objects and interactions. Systems are developed by integrating components (collections of objects) that conform to component-model standards. This is covered in Chapter 19. Collections of abstract and concrete classes that can be adapted and extended to create application systems. Legacy systems (see Chapter 2) that can be wrapped by defining a set of interfaces and providing access to these legacy systems through these interfaces. Systems are developed by linking shared services that may be externally provided. Component-based development Application frameworks Legacy system wrapping Service-oriented systems

Reuse approaches
Application product lines COTS integration Configurable vertical applications Program libraries Program generators An application type is generalised around a common architecture so that it can be adapted in different ways for different customers. Systems are developed by integrating existing application systems. A generic system is designed so that it can be configured to the needs of specific system customers. Class and function libraries implementing commonly-used abstractions are available for reuse. A generator system embeds knowledge of a particular types of application and can generate systems or system fragments in that domain. Shared components are woven into an application at different places when the program is compiled.

Aspect-oriented software development

Reuse success Factors

Effective Teamwork Working alongside some very interesting and highperformance teams, I have come to believe that success with reuse is more than technical brilliance or elegant design. Great teams produce high quality work, understand each other, their strengths, their limitations, and most importantly harness conflict as a medium for healthy constructive dialogue, creativity, and innovation.

Reuse success Factors

Managing Domain Complexity Your domain might be complex and rich in variations that need to be supported. Trying to capture all the complexity is neither pragmatic nor feasible given the constraints you might be under. Instead, focus on the essential complexity.

Reuse failure Factors

Organizational impediments -- e.g., developing, deploying, and supporting systematically reusable software assets requires a deep understanding of application developer needs and business requirements. As the number of developers and projects employing reusable assets increases, it becomes hard to structure an organization to provide effective feedback loops between these constituencies. Economic impediments -- e.g., supporting corporate-wide reusable assets requires an economic investment, particularly if reuse groups operate as cost-centers. Many organizations find it hard to institute appropriate taxation or charge-back schemes to fund their reuse groups. Administrative impediments -- e.g., it's hard to catalog, archive, and retrieve reusable assets across multiple business units within large organizations. Although it's common to scavenge small classes or functions opportunistically from existing programs, developers often find it hard to locate suitable reusable assets outside of their immediate workgroups.

Reuse failure Factors

Political impediments -- e.g., groups that develop reusable middleware platforms are often viewed with suspicion by application developers, who resent the fact that they may no longer be empowered to make key architectural decisions. Psychological impediments -- e.g., application developers may also perceive ``top down'' reuse efforts as an indication that management lacks confidence in their technical abilities. In addition, the ``not invented here'' syndrome is ubiquitous in many organizations, particularly among highly talented programmers.

Topics Covered
Software reuse Types What can be reused? Why reused? Purpose of reuse Benefits Drawbacks