Chapters 1819

1
Chapters 18/19

• Software Reuse / CBSE

2
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.

3
Topics covered

• The reuse landscape (introduction)
• current practice
• benefits
• requirements
• problems
• Design Patterns
• Component-Based SE (from Chap. 19)
• characteristics
• process
• problems
• Application Families

4
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

5
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.

6
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.

7
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.
• (contd)

8
Benefits of reuse (cont.)

• Standards compliance when standards are
  embedded in reusable elements.
• Accelerated development reduced development and
  validation time. (usually)

9
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.

10
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 elses code.
• (contd)

11
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.

12
Design Patterns (Alexander, mid-70s)

• 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 its solution.
• Should be sufficiently abstract to be reusable in
  different contexts.
• Often utilize OO characteristics such as
  inheritance and polymorphism.

13
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)

14
Example The Observer pattern
15
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.

16
The Observer pattern (contd)
Observer super class (for alternative displays)
Subject super class
one to many
Specific observer sub-class
Specific subject sub-class
17
The Observer pattern (contd)

• 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

18
Component-Based Software Engineering

• Component-Based Software Engineering (CBSE) is a
  development approach based on systematic reuse.
• CBSE emerged in the late 1990s 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)

19
Essentials of CBSE

• Independent components that are completely
  specified by their interfaces.
• Clear separation between interface and
  implementation
• One implementation can replace another without
  changing the system
• 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

(Contd)
20
Essentials of CBSE (contd)

• Middleware to support component integration
• Component communications (e.g., CORBA)
• Resource allocation, transaction management,
  security, concurrency
• A development process geared to CBSE (as opposed
  to a process geared to original software
  production)

21
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.

22
Example Printing services component
Printer Description
Control Interface
23
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.

(Contd)
24
Component characteristics (contd)

• 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.

25
The CBSE process
Modify
Outline
Identify candidate
requirements
system
according to discovered
components
requirements
components
Further component
Compose
Architectural
components to
search and
design
create system
design refinement
26
CBSE problems

• 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
• Component certification should independent
  assessors certify trustworthiness?
• Who would pay for this?
• How would liability be handled?

(Contd)
27
CBSE problems (contd)

• Emergent property prediction when components
  are integrated, the resulting system may have
  undesirable properties that limit its use.
• 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.

28
European Space Agency (ESA) Ariane launcher
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
  Navigation System) that failed because
  assumptions made when that component was
  developed did not hold for Ariane 5.
• The functionality that failed in this com-ponent
  was not required in Ariane 4.

29
Application Families

• 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.

30
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)
31
Family member development
Use existing family member as prototype.
32
Key points

• 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.

(Contd)
33
Key points (contd)

• 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.

but general/flexible
(Contd)
34
Key points (contd)

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

35
Chapter 18

• Software Reuse