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
