Software Reuse

Objectives
• To explain the benefits of software reuse and some reuse problems
• To discuss several different ways to implement software reuse
• To explain how reusable concepts can be represented as patterns or embedded in
program generators
• To discuss COTS reuse
• To describe the development of software product lines
 Software reuse
• In most engineering disciplines, systems are designed by composing existing
components that have been used in other systems.
• Software engineering has been more focused on original development but it is now
recognised that to achieve better software, more quickly and at lower cost, we need
to adopt a design process that is based on systematic software reuse.
 Reuse-based software engineering
• Application system reuse
• The whole of an application system may be reused either by incorporating it without change
into other systems (COTS reuse) or by developing application families.
• Component reuse
• Components of an application from sub-systems to single objects may be reused. Covered
in Chapter 19.
• Object and function reuse
• Software components that implement a single well-defined object or function may be
reused.
Benefits of software reuse
 Problems with reuse
• Creating, maintaining and using a component library
• Finding, understanding and adapting reusable components
• Increased maintenance costs
• Lack of tool support
• “Not-invented-here” syndrome
 The reuse landscape
• Although reuse is often simply thought of as the reuse of system components,
there are many different approaches to reuse that may be used.
• Reuse is possible at a range of levels from simple functions to complete application
systems.
• The reuse landscape covers the range of possible reuse techniques.
Figure of the reuse landscape
 Reuse planning factors
• The development schedule for the software.
• The expected software lifetime.
• The background, skills and experience of the development team.
• The criticality of the software and its non-functional requirements.
• The application domain.
• The execution platform for the software.
 Application frameworks
• Frameworks are moderately large entities that can be reused. They are somewhere
between system and component reuse.
• Frameworks are a sub-system design made up of a collection of abstract and
concrete classes and the interfaces between them.
• The sub-system is implemented by adding components to fill in parts of the design
and by instantiating the abstract classes in the framework.
 Web application frameworks
• Most widely used application framework.
• Support the construction of dynamic websites as a front- end for web applications.
• WAFs are now available for all of the commonly used web programming languages
e.g. Java, Python, Ruby, etc.
• Interaction model is based on the Model-View-Controller composite pattern.
 Model-view controller
• System infrastructure framework for GUI design.
• Allows for multiple presentations of an object and separate interactions with these
presentations.
• MVC framework involves the instantiation of a number of patterns
The model-view-controller pattern
 Web application framework features
• Security
• Dynamic web pages
• Database integration
• Session management
• User interaction
 Software product line
• Software product lines or application families are applications with generic functionality
that can be adapted and configured for use in a specific context.
• A software product line is a set of applications with a common architecture and shared
components, with each application specialized to reflect different requirements.
• Adaptation may involve:
a. Component and system configuration
b. Adding new components to the system
c. Selecting from a library of existing components
d. Modifying components to meet new requirements.
 Application system reuse
• An application system product is a software system that can be adapted for
different customers without changing the source code of the system.
• Application systems have generic features and so can be used/reused in different
environments.
• For example, in a hospital patient record system, separate input forms and output
reports might be defined for different types of patient.
 Benefits of application system reuse
• As with other types of reuse, more rapid deployment of a reliable system may be possible.
• It is possible to see what functionality is provided by the applications and so it is easier to
judge whether or not they are likely to be suitable.
• Some development risks are avoided by using existing software. However, this approach
has its own risks, as I discuss below.
• Businesses can focus on their core activity without having to devote a lot of resources to
IT systems development.
• As operating platforms evolve, technology updates may be simplified as these are the
responsibility of the COTS product vendor rather than the customer.
 Conclusion
• Software product lines are related applications that are developed from one or more base
applications. A generic system is adapted and specialized to meet specific requirements for
functionality, target platform or operational configuration.
• Application system reuse is concerned with the reuse of large-scale, off-the-shelf systems.
These provide a lot of functionality and their reuse can radically reduce costs and
development time. Systems may be developed by configuring a single, generic application
system or by integrating two or more application systems.
• Potential problems with application system reuse include lack of control over functionality
and performance, lack of control over system evolution, the need for support from
external vendors and difficulties in ensuring that systems can inter-operate.