Chapters 18/19

©Ian Sommerville 2000 Software Engineering. Chapter 18 Slide 1

Chapters 18/19

Software Reuse / CBSE


Objectives

To explain the benefits and some potential problems with software reuse.

To describe different types of reusable elements and processes for reuse.

To understand what is meant by CBSE To introduce application families as a

route to reuse. To describe design patterns as high-level

abstractions that promote reuse.


Topics covered

The reuse landscape (introduction) current practice benefits requirements problems

Design Patterns Component-Based SE (from Chap. 19)

characteristics process problems

Application Families


Topics / sections we will skip

18.3 Generator-based reuse 18.4 Application frameworks 18.5.1 COTS product reuse 19.1.1 Component models 19.1.2 Component development for reuse 19.3 Component composition


Reuse-based software engineering

In most engineering disciplines, systems are routinely designed by composing elements that have been used in other systems.

This has not been true in SE, but to reduce risks and accelerate develop-ment, it is now recognized that we need to adopt design processes based on systematic reuse.


Software reuse practice Application System reuse – widely practised as

software systems are implemented as application families. COTS reuse is also becoming increasingly common.

Component reuse – medium grain elements (usually between objects/functions and application systems) are reused in Component-Based Software Engineering (CBSE). Increasingly being adopted as a mainstream SE approach.

Object and function reuse – libraries of reusable functions have been common for 40 years.

Design Pattern reuse – a way of reusing “accumulated knowledge and wisdom” about a problem and its solution. Closely tied to OO design principles. Requires relatively sophisticated design skills, so use is limited.


Benefits of reuse

Increased reliability – when reused elements have been tried and tested in a variety of working systems.

Reduced process risk – less uncertainty of cost compared to new development.

More effective use of specialists – re-use elements instead of experts.

(cont’d)


Benefits of reuse (cont.)

Standards compliance – when standards are embedded in reusable elements.

Accelerated development – reduced development and validation time. (usually…)


Requirements for design with reuse Must be possible to find appropriate

reusable elements. Must be confident that the elements will

be reliable and will behave as specified. Elements must be documented so that

they can be understood and, when necessary, modified.


General Reuse problems

Increased maintenance costs – especially if source code / documentation absent. (otherwise, could be much lower)

Lack of tool support – most CASE toolsets do not support development with reuse. (What support could be provided?)

Not-invented-here syndrome – the resistance against using “someone else’s” code.

(cont’d)


General Reuse problems (cont.)

Repositories of reusable elements – techniques for classifying, cataloguing, and retrieving elements are immature.

Difficulty of finding, understanding, and adapting reusable elements – this takes time.


Topics covered






Design Patterns (Alexander, mid-70’s)

A way of reusing “accumulated knowledge and wisdom” about a problem and its solution.

A design pattern is a description of some problem and the “essence” of a solution.

Should be sufficiently abstract to be reusable in different contexts.

Often utilize OO characteristics such as inheritance and polymorphism.


Pattern elements (Gamma, ‘95)

Name: a meaningful pattern identifier Problem description Solution description: a template for a

design solution that can be instantiated in different operational contexts (often illustrated graphically)

Consequences: the results and trade-offs of applying the pattern (analysis and experience)


Example: The Observer pattern

Subject

A: 40B: 25C: 15D: 20

Observer 1 Observer 2

0

50

25

A B C D

A

B

C

D


The Observer pattern

Name: Observer Description: Separates the display of

object state from the object itself allowing alternative displays.

Problem description: Used when multiple displays of state are needed.

Solution description: (See UML description)

Consequences: Object optimizations to enhance the performance of a particular display are impractical.


The Observer pattern (cont’d)

Subject Observer

Attach (Observer)Detach (Observer)Notify ()

Update ()

ConcreteSubject

GetState ()

subjectState

ConcreteObserver

Update ()

observerState

return subjectState

for all o in observers o -> Update ()

observerState = subject -> GetState ()

Observer super class (for alternative displays)Subject super class

Specific subject sub-class

Specific observer sub-class

one to many


The Observer pattern (cont’d)

Concrete Subject Has any number of observers Provides an interface to attach and detach

observer objects at run-time Sends notification to its observers

Concrete Observer Provides an update interface to receive

signals from subject Implements update operation


Topics covered






Component-Based Software Engineering

Component-Based Software Engineering (CBSE) is a development approach based on systematic reuse.

CBSE emerged in the late 1990’s due to failure of OO development (alone) to lead to extensive reuse.

Components are designed to be general service providers.

A multi-level paradigm: components are “medium grain” elements (usually between objects/functions and application systems)


Essentials of CBSE

1. Independent components that are completely specified by their interfaces Clear separation between interface and

implementation One implementation can replace another without

changing the system

2. Component standards that facilitate integration Embodied in a component model - EJB (Enterprise

Java Beans), COM+ (.NET model), CCM (Corba Component Model)

Define how interfaces should be specified and how components communicate

(cont’d)


Essentials of CBSE (cont’d)

3. Middleware to support component integration

Component communications (e.g., CORBA) +

Resource allocation, transaction management, security, concurrency

4. A development process geared to CBSE (as opposed to a process geared to original software production)


2-part component interface

“Provides interface” – defines the services that are provided by the component to other system elements.

“Requires interface” – defines the services that must be made available to the component by other system elements in order to operate.

Component Provides interfaceRequires interface


Example: Printing services component

Provides interfaceRequires interface

Print

PrintService

GetQueue

Remove

Transfer

Register

Unregister

GetPDfile

PrinterInt

Printer Description

Control Interface


Component characteristics

Standardized – must conform to some component model defining their interfaces, metadata, documentation, composition, and deployment.

Independent – it should be possible to compose and deploy components without having to use other specific components.

Composable – external interactions must take place through publicly defined interfaces.

(cont’d)


Component characteristics (cont’d)

Deployable – must operate on a component platform that implements the component model. Component are usually in binary and do not have to be compiled.

Documented – syntax and (ideally) semantics of interfaces must be specified so potential users can decide if their needs will be met.


The CBSE process

Identify candidatecomponents

Outlinesystem

requirements

Modifyrequirementsaccording to

discoveredcomponents

Further componentsearch andArchitectur

al design

Composecomponents tocreate systemdesign refinement


CBSE problems

1. Component trustworthiness – a component is a black-box program unit… There may be undocumented failure modes Non-functional behavior may not be as expected Could be a Trojan horse containing malicious code

2. Component certification – should independent assessors certify trustworthiness? Who would pay for this? How would liability be handled?

(cont’d)


CBSE problems (cont’d)

3. Emergent property prediction – when components are integrated, the resulting system may have undesirable properties that limit its use.

4. Requirements trade-offs – it is usually necessary to make compromises between ideal requirements and available components. Largely an intuitive process…

Need a more structured, systematic trade-off analysis method to help designers select and configure components.


European Space Agency (ESA) Ariane launch failure

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

The problem was due to a reused com-ponent from a previous version of the rocket (the Inertial Guidance System) that failed.

Assumptions made when the component was developed for Ariane 4 did not hold for Ariane 5.


Topics covered







An application family or product line is a related set of applications that has a common, domain-specific architecture.

The common core of the application family is reused each time a new application is required.

Each specific application is specialized in some way.


Application Family specialization

Platform specialization – different versions of the application are developed for different platforms. (e.g., Windows, Sun OS, Linux)

Configuration specialization – different versions of the application are created to handle different peripheral devices. (I/O devices, etc.)

Functional specialization – different versions of the application are created for customers with different requirements. (e.g., Word users vs. PowerPoint

users)


Family member development

Elicitstakeholderrequirements

Choose closest-fit familymember Deliver new

family member

Re-negotiaterequirements

Adapt existingsystem

Use existing family member as prototype.


Design with reuse involves designing software around existing examples of good design and making use of existing software elements.

(Potential) advantages are lower costs, faster development, and lower risks.

Design Patterns are high-level abstractions that document successful design solutions.

Key points

(cont’d)


CBSE relies on black-box components with defined requires- and provides- interfaces.

Software components for reuse should be independent, reflect stable domain abstractions, and provide access to state through interface operations.

COTS product reuse is concerned with the reuse of large-scale, off-the-shelf systems.

Key points (cont’d)

(cont’d)


Key points (cont’d)

Application Families are related applications that have a common, domain-specific architecture.


Chapter 18

Software Reuse

Date post:	20-Jan-2016
Category:	Documents
Upload:	nike
View:	33 times
Download:	0 times

Chapters 18/19

Documents