comp3521 Ch15

Software Reuse Overview

• Software reuse involves designing systems by assembling existing components already used in other systems
• Focus on original development in software engineering has shifted as software reuse has been recognised as a means to improve software quality, speed, and cost
• There has been a substantial shift toward reuse-based development in the last decade

Reuse-Based Software Engineering Types

• System reuse comprises reusing entire systems that may include multiple application programs
• Application reuse includes incorporating applications without changes or developing application families
• Component reuse includes reusing application components from subsystems down to individual objects
• Object and function reuse covers reusing small components implementing specific objects or functions

Benefits of Software Reuse

• Accelerated development enables quicker time to market
• Reusing software speeds up system production due to reduced development and validation time
• Effective use of specialists allows application experts to develop reusable software that encapsulates their knowledge
• Increased dependability arises from using well-tested software with identified and fixed faults
• Lower development costs result from needing to write fewer lines of code
• Reduced process risk is achieved because the cost of existing software is already known when compared to estimated development costs
• Standards compliance can be implemented through reusable components, such as consistent user interface menus, which improves dependability by creating familiar interfaces

Problems With Reuse

• Creating, maintaining, and using a component library can be expensive
• Development processes must be adapted to ensure library usage
• Finding, understanding, and adapting reusable components can be difficult with Engineers needing confidence in finding components before including a component search
• Increased maintenance costs occur when the source code of reused software is unavailable as reused elements become incompatible with system changes
• Lack of tool support occurs because some software tools do not support development with reuse and may be hard to integrate with component library systems
• The Not-invented-here syndrome stems from some engineers preferred to rewrite components, believing they can make improvements; this is partly due to confidence and partly due to the idea that writing original code is more challenging

The Reuse Landscape

• Reuse involves various approaches beyond merely reusing system components
• Reuse is possible at different levels ranging from simple functions to total application systems
• The reuse landscape encompasses a variety of potential reuse techniques

Approaches That Support Software Reuse

• Application Frameworks are collections of abstract and concrete classes adapted and extended to create application systems
• Application System Integration includes two or more application systems integrated to provide extended functionality
• Architectural Patterns are standard software architectures supporting common application system types and used as the basis for applications
• Aspect-Oriented Software Development concerns shared components woven into an application at different compilation places
• Component-Based Software Engineering builds Systems by integrating components conforming to component-model standards
• Configurable Application Systems are domain-specific systems designed to be configured to meet specific customer needs
• Design Patterns include generic abstractions occurring across applications, are represented as design patterns, and show abstract and concrete objects and interactions
• ERP Systems are large-scale systems encapsulating generic business functionality with rules configured for an organization
• Legacy System Wrapping entails legacy systems ‘wrapped’ by defining interfaces to provide access to these systems
• Model-Driven Engineering means software is represented as domain models, and implementation-independent models and code are then generated
• Program Generators include a generator system embedding knowledge of an application type and generates systems via a user-supplied system model
• Program Libraries are class and function libraries that implement commonly used abstractions for reuse
• Service-Oriented Systems include systems developed by linking shared services, which may be externally provided
• Software Product Lines are an application type generalized around a common architecture for adaptation to different customers
• Systems of Systems integrate two or more distributed systems to create a new system

Reuse Planning Factors

• Consider the software's development schedule
• Consider the software's expected lifetime
• Take into account the development team's background, skills, and experience
• Consider the criticality of the software and its non-functional requirements
• Consider the application domain
• Take into account the software's execution platform

Application Frameworks

• Frameworks are moderately large entities, somewhere between system and component reuse, that can be reused
• Frameworks are subsystem designs made of abstract and concrete classes, plus the interfaces between them
• The subsystem is implemented by adding components to fill parts of the design and by instantiating the abstract classes in the framework

Web Application Frameworks (WAFs)

• WAFs support the construction of dynamic websites as front-ends for web applications
• WAFs are available for commonly used web programming languages like Java, Python and Ruby
• Interaction models are based on the Model-View-Controller composite pattern

Model-View-Controller (MVC)

• MVC is a system infrastructure framework for GUI design
• MVC allows for multiple object presentations and separate interactions with these presentations
• The MVC framework includes instantiating several patterns

WAF Features

• Security includes classes that implement user authentication and access
• Dynamic Web Pages involve classes to create web page templates and populate with dynamic content from system database
• Database Support involves frameworks offering classes with abstract interfaces to different databases
• Session management involves classes for creating and managing sessions with classes usually inside the WAF implementation
• User interaction includes web frameworks with AJAX support, that allows more interactive web pages

Extending Frameworks

• Frameworks are generic and extended to create specific applications or subsystems and provide a skeleton architecture for the system
• Extending frameworks involves adding concrete classes inheriting operations from abstract classes and adding methods called in response to recognized events
• A problem with frameworks is their complexity, which means it takes time to use them effectively

Framework Classes

• System infrastructure frameworks support the development of system infrastructures, like communications, user interfaces, and compilers
• Middleware integration frameworks encompass standards and classes supporting component communication and information exchange
• Enterprise application frameworks supports the development of specific application types, such as telecommunications or financial systems

Software Product Lines

• Software product lines, or application families, are applications with generic functionality adapted and configured for use in a specific context
• Software product lines consist of applications with a common architecture and shared components, each specialized to reflect different requirements
• Adaptation to the software may include component and system configuration, adding new components, selecting components from a library, or modifying components to meet new requirements

Base Applications

• Core components provide infrastructure support and are typically not modified
• Configurable components are modified and configured to specialize them to a new application; they can sometimes be reconfigured without changing code using a built-in component configuration language
• Specialized, domain-specific components may be replaced when creating product lines

Application Frameworks and Product Lines

• Application frameworks use object-oriented features like polymorphism for extensions, while product lines do not need to be object-oriented
• Application frameworks provide technical support, while product lines embed domain and platform information
• Product lines often control equipment applications
• Software product lines consist of a family of applications that are generally owned by the same organization

Product Line Architectures

• Architectures must be structured in a way so as to separate different subsystems and be modifiable
• Architectures should separate entities and their descriptions, with higher-level access to the entities via descriptions, not directly

Vehicle Dispatching

• Specialized resource management system aims to allocate resources (vehicles) to handle incidents
• Adaptations occur at the UI level (operator display and comms), I/O management level (authentication, reporting, and route planning), and resource management level (vehicle location and dispatch, managing vehicle status and incident logging)
• The database includes equipment, vehicle, and map databases

Product Line Specialization

• Platform specialization includes different application versions developed for different platforms
• Environment specialization includes different application versions created to handle different operating environments
• Functional specialization concerns unique application versions for each customer’s specific requirements
• Process specialization supports application versions supporting unique business processes

Product Instance Development

• Elicit stakeholder requirements use existing family member as a prototype
• Choose closest-fit family member entails finding the family member that best meets requirements
• Renegotiate requirements involves adapting requirements as necessary to work within software capabilities
• Adapt the Existing System includes developing new modules and making changes for family members
• When delivering a new family member, document key features for further member development

Product Line Configuration Types

• Design time configuration focuses on developing, selecting, or adapting components by the software org
• Deployment time configurations designs the system configuration by incorporating customer specific knowledge

Levels of Deployment Time Configuration

• Component selection is selecting the modules in a system what provide the required functionality
• Workflow and rule definition entails defining workflows and validation rules for information entered by system users
• Parameter definition includes specifying values of specific system parameters that reflect the created application instance

Application System Reuse

• Application system products are software systems adapted for different customers without changing the source code
• Application systems have generic features and can be reused in different environments
• Application system products are adapted using built in configuration mechanisms to tailor functionality to customer needs
• An example is a hospital patient record system with separate input forms and output reports defined for unique types of patient

Benefits of Application System Reuse

• Rapid deployment of reliable systems
• Easier to determine if applications are suitable due to visibility of functionality
• Avoids some development risks
• Businesses can focus on their core activities without needing to allocate IT resources heavily
• Technology updates are simplified as they the COTS vendor's responsibility

Problems of Application System Reuse

• Requirements may need to be adapted to reflect functionality and mode of operation of COTS products
• The COTS product may be based on assumptions practically impossible to change
• Selecting the right COTS system can be difficult, especially as many products lack adequate documentation
• There may be a lack of local expertise to support systems development
• The COTS product vendor controls system support and evolution

Configurable Application Systems

• Configurable application systems are generic systems designed to support a specific business type, activity, or complete enterprise
• For example, systems that support dentists handle appointments, dental records, and patient recall
• Domain-specific systems support specific business functions (e.g. document management) and are likely to be required by common users

COTS Solutions and Integrated Systems

• Configurable application systems are single products which provide the functionality a customer requires
• These are based around generic solutions and standardized processes
• Development focuses on system configuration while the System vendor is responsible for maintenance and also provides the platform

ERP Systems

• Enterprise Resource Planning (ERP) systems are generic systems that support common business processes, for instance, ordering, invoicing, and manufacturing
• ERPs are widely used in large companies, representing the most common form of software reuse
• The generic core is adapted by including modules and incorporating business processes and rules knowledge

ERP Architecture

• A number of modules support business functions
• Each module is associated with defined business processes, which also relate to activities inside that module
• All modules share a common database that maintains business function information
• Sets of business rules apply to all data in the database

ERP Configuration

• Select required functionality from the system
• Establish a data model that defines data structure in