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

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

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

Chapters 18/19

Documents

Transcript of Chapters 18/19

Chapters 18, 19, 20, 21 (part 1)

Chapters 18, 19, 20, 21 (part 2)

Unit 7—Chapters 18 – 19 The Gilded Age CSS 11.2, 11.3.

Financial Statement Presentation Accounting Changes Subsequent Events Statement of Cash Flows Chapters 18 and 19.

Chapters 1-18

Alternating Current Electricity NCEA A.S 3.6 Text Chapters 18-19.

CAPTAIN NOBODY FORM 5 NOVEL chapters 18-19

Chapters 18 - 19

Chapters 17, 18, 19

Absolutism, Enlightenment, Revolution, and Napoleon Chapters 17, 18, 19.

Unit 6: Business, Factors, & Economies Chapters 18, 19, & 26.

Recap Period 6 Chapters 16, 17, 18, and beginning of 19.

Science- Chapters 10-18

Lecture 8 Options on Futures Primary Text Edwards and Ma: Chapters 18, 19, & 20.

Chapters 19 & 20 Applications of Standard Electrode Potentials …sites.usm.edu/electrochem/Analytical Chemistry/Lecture... · 2020-04-18 · 1 Chapters 19 & 20 Applications of Standard

Mata Chapters 1-8-10!16!18 19 21 22 29 32 Dissertation Judit Torzsok

Chapters 17, 18 and 19 life span development

Chapters 18 & 19 Contracts in Writing & Third-Party Rights.

Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapters 18 & 19 Slide 1 Software Reuse.

THIS IS With Hosts... Your 100 200 300 400 500 Chapter 11 Chapter 12 Chapters 13-14 Chapters 15-17 Chapters 18-19 Literary Elements.