Chapter 15: Software Reuse (3705)

Chapter 15: Software Reuse (3705)

1. 15.1 The reuse landscape

   • Figure 15.3 shows the “reuse landscape”—different ways of implementing software reuse.
   • Key factors that you should consider when planning reuse are:
     • 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 platform on which the system will run

2. 15.2 Application frameworks

   • Early enthusiasts for object-oriented development suggested that one of the key benefits of using an object-oriented approach was that objects could be reused in different systems
     • It often takes longer to understand and adapt the object than to reimplement it
     • It has now become clear that object-oriented reuse is best supported in an object-oriented development process through larger-grain abstractions called frameworks
     • a framework is a generic structure that is extended to create a more specific subsystem or application
       • an integrated set of software artifacts (such as classes, objects and components) that collaborate to provide a reusable architecture for a family of related applications.†
   • Frameworks support design reuse in that they provide a skeleton architecture for the application as well as the reuse of specific classes in the system.
   • Frameworks support design reuse in that they provide a skeleton architecture for the application as well as the reuse of specific classes in the system.
   • The most widely used application frameworks are web application frameworks (WAFs), which support the construction of dynamic websites. The architecture of a WAF is usually based on the Model-View-Controller (MVC) Composite pattern shown in Figure 15.5.
     • An MVC framework supports the presentation of data in different ways and allows interaction with each of these presentations.
   • Frameworks are often implementations of design patterns
     • MVC framework includes the Observer pattern, the Strategy pattern, the Composite pattern, and a number of others
   • While each framework includes slightly different functionality, web application frameworks usually provide components and classes that support:
     • Security
     • Dynamic web pages
     • Dynamic web pages
     • Session management
     • User interaction
   • To implement a system using a framework, you add concrete classes that inherit operations from abstract classes in the framework. In addition, you define “callbacks”—methods that are called in response to events recognized by the framework. The framework objects, rather than the application-specific objects, are responsible for control in the system.
     • call this “inversion of control.”
   • In response to events from the user interface and database framework objects invoke “hook methods” that are then linked to user-provided functionality
     • Signals and slots
   • three other classes of framework:
     • System infrastructure frameworks
       • communications, user interfaces, and compilers.
     • Middleware integration frameworks
       • set of standards and associated object classes that support component communication and information exchange
     • Enterprise application frameworks
       • specific application domains such as telecommunications or financial systems
   • Frameworks are a very effective approach to reuse

3. 15.3 Software product lines

   • When a company has to support a number of similar but not identical systems, one of the most effective approaches to reuse is to create a software product line.
   • A software product line is a set of applications with a common architecture and shared components, with each application specialized to reflect specific customer requirements.
   • Software product lines usually emerge from existing applications.
   • Testing is simplified because tests for large parts of the application may also be reused
   • decision to design a generic product line
     • This involves identifying common functionality in product instances and developing a base application, which is then used for future development.
   • This base application (Figure 15.7) is designed to simplify reuse and reconfiguration. Generally, a base application includes:
     • Core components that provide infrastructure support.
     • Configurable components that may be modified and configured to specialize them to a new application.
     • Specialized, domain-specific components some or all of which may be replaced when a new instance of a product line is created.
   • Application frameworks and software product lines have much in common
     • both support a common architecture and components, and require new development to create a specific version of a system.
     • main differences between these approaches are as follows:
       • Application frameworks rely on object-oriented features such as inheritance and polymorphism to implement extensions to the framework.
       • Software product lines are not necessarily created using an object-oriented approach. Application components are changed, deleted, or rewritten
       • Most application frameworks provide general support rather than domain-specific support.
       • A software product line usually embeds detailed domain and platform information.
       • Software product lines are often control applications for equipment
       • Application frameworks are usually software-oriented, and they do not usually include hardware interaction components.
       • Software product lines are made up of a family of related applications, owned by the same organization.
   • The architecture of a software product line often reflects a general, applicationspecific architectural style or pattern
     • For example, consider a product-line system that is designed to handle vehicle dispatching for emergency services. Operators of this system take calls about incidents, find the appropriate vehicle to respond to the incident, and dispatch the vehicle to the incident site. The developers of such a system may market versions of it for police, fire, and ambulance services.
       • This vehicle dispatching system is an example of a generic resource allocation and management architecture (Figure 15.8).
         • You can see how this four-layer structure may be instantiated in Figure 15.9,
           • The components at each level in the product-line system are as follows:
     • To create a new instance of this system, you may have to modify individual components.
       • Various types of specialization of a software product line may be developed:
         • Platform specialization
         • Environment specialization
         • Functional specialization
         • Process specialization
       • Figure 15.10 shows the process for extending a software product line to create a new application. The activities in this process are:
     • Software product lines are designed to be reconfigurable. This reconfiguration may involve adding or removing components from the system
       • This configuration may occur at different stages in the development process:
         • Design-time configuration
           • modifies a common product-line core by developing, selecting, or adapting components to create a new system for a customer.
         • Deployment-time configuration
           • A generic system is designed for configuration by a customer or consultants working with the customer.
           • Several levels of deployment-time configuration may be provided in a system:
             • Component selection
               • select the modules in a system that provide the required functionality
             • Workflow and rule definition
               • define workflows (how information is processed, stage by stage), and validation rules
             • Parameter definition
               • specify the values of specific system parameters that reflect the instance of the application that you are creating

4. 15.4 Application system reuse

   • An application system product is a software system that can be adapted to the needs of different customers without changing the source code of the system.
   • These system products are sometimes known as COTS (Commercial Off-the Shelf System) products
     • call these system products application systems.
   • Application system products are adapted by using built-in configuration mechanisms that allow the functionality of the system to be tailored to specific customer needs
   • This approach to software reuse has been very widely adopted and offers significant benefits over customized software development:
     • rapid deployment of a reliable system
     • see what functionality is provided by the applications
     • Some development risks are avoided
     • Businesses can focus on their core activity without having to devote a lot of resources to IT systems development.
     • technology updates may be simplified
   • this approach to software engineering has its own problems:
     • Requirements usually have to be adapted to reflect the functionality and mode of operation of the off-the-shelf application system
     • The application system may be based on assumptions that are practically impossible to change.
     • Choosing the right application system for an enterprise can be a difficult process
     • lack of local expertise to support systems development
     • system vendor controls system support and evolution
   • Application systems may be used as individual systems or in combination, where two or more systems are integrated
     • Individual systems consist of a generic application from a single vendor that is configured to customer requirements
       • Individual systems consist of a generic application from a single vendor that is configured to customer requirements
       • Integrated systems involve integrating the functionality of individual systems, often from different vendors, to create a new application system
   • Configurable application systems
     • Configurable application systems are generic application systems that may be designed to support a particular business type, business activity, or, sometimes, a complete business enterprise
   • Integrated application systems
     • You may use this approach when no single application system meets all of your needs or when you wish to integrate a new application system with systems that you are already using.
     • component systems may interact through their APIs or service interfaces or composed by connecting the output of one system to the input of another or by updating the databases used by the applications.
     • component systems may interact through their APIs or service interfaces or composed by connecting the output of one system to the input of another or by updating the databases used by the applications.
     • you have to make a number of design choices:
       • Which individual application systems offer the most appropriate functionality?
       • How will data be exchanged?
       • What features of a product will actually be used?
     • The company has a legacy ordering system that is used by a central procurement office. This order processing software is integrated with an existing invoicing and delivery system. To create the new ordering system, the legacy system is integrated with a web-based e-commerce platform and an email system that handles communications with users
     • Boehm and Abts (Boehm and Abts 1999) highlight four important system integration problems:
       • Lack of control over functionality and performance
       • Problems with system interoperability
       • No control over system evolution
       • Support from system vendors
       • System maintenance and evolution may be greater for integrated application systems
     • Service Wrapper
       • you have to program a wrapper that hides the application and provides externally visible services (Figure 15.15). This approach is particularly valuable for legacy systems that have to be integrated with newer application systems

5. Introduction

   • Reuse-based software engineering is a software engineering strategy where the development process is geared to reusing existing software
   • They are promoting reuse of existing systems to increase their return on software investments.
   • The software units that are reused may be of radically different sizes. For example:
     • System reuse
     • Application reuse
     • Component reuse
     • Object and function reuse
     • Sometimes too much effort to convert a system component to what you require
       • you can reuse the ideas that are the basis of the software. This is called concept reuse.
         • In concept reuse you do not reuse a software component; rather, you reuse an idea, a way of working, or an algorithm.

Imagens e arquivos do mapa