Software Reuse and Componentbased Design

1
Software Reuse and Component-based Design
Andrew Ireland School of Mathematical Computer
Sciences Heriot-Watt University Edinburgh
2
Outline

• Motivations Challenges
• Definitions
• Component models
• Process Issues
• Composition
• Predictability Trustworthiness

3
Motivations

• A key principle of manufacturing is reuse, e.g.
  reuse of ideas, techniques, components,
• Benefits of reuse
• Increased system reliability
• Reduced time-to-market
• Risk reductions, i.e. project over-runs
  failures
• Effective reuse requires well defined
• Functionality preconditions and services
• Interfaces how to plug-and-play
• Dependences no unknown side-effects

4
Motivations

• A selling point for Object-orientation was that
  it would promote software reuse
• But Object-orientation did not live up to this
  expectation
• Component-based software engineering (CBSE)
  emerged in the 90s with the specific aim of
  addressing reuse
• Note design patterns also aim to promote reuse

5
Reuse via Components
Catalogue of software components
Customer requirements
Component integrator
Software application
Component Providers
6
What is a Component?
an independently deliverable set of reusable
services (Short 97) a unit of composition
with contractually specified interfaces and
explicit context dependencies only. A software
component can be deployed independently and is
subject to third-party composition. (Szyperski
98) a software element that conforms to a
component model and can be independently deployed
and composed without modification according to a
composition standard (Heinemand Councill 01)
7
What is a Component?
an independently deliverable set of reusable
services (Short 97) a unit of composition
with contractually specified interfaces and
explicit context dependencies only. A software
component can be deployed independently and is
subject to third-party composition. (Szyperski
98) a software element that conforms to a
component model and can be independently deployed
and composed without modification according to a
composition standard (Heinemand Councill 01)
8
What is a Component?

• Well defined service (functionality)
• Well defined interface
• Explicit dependences
• Standardization

- component model
9
What is a Component Model?

• A standard which defines components, i.e.
• How components can be constructed
• How components can be composed (assembled)
• How components are deployed
• But there are many competing standards, e.g.
• Enterprise JavaBeans (EJB) - Sun
• Component Object Model (COM) .NET - Microsoft
• CORBA Component Model (CCM) OMG
• Note CORBA Common Object Requesting Broker
  Architecture

10
Challenges

• Requirements trade-offs how do we decide
  between alternative component solutions?
• Trustworthiness without access to source code
  how can a component be trusted?
• Emergent properties how can emergent properties
  of component compositions be predicated?

11
Component-based Process

• Develop initial application requirements
• Search for candidate components
• Modify requirements given the functionality of
  the candidate components OR continue the search
  for a better match
• Trade-off between ideal requirements and the
• functionality of the available components -
  requirements
• engineering design go hand-in-hand

12
Composition Problems

• Overlapping functionality
• Multiple-components that can provide the same
  functionality
• Designer needs to select the most appropriate and
  ensure that only it provides the functionality
• Missing functionality
• Search for an appropriate component OR
• Develop a component that fills the gap

13
Composition Problems

• Redundant functionality
• Composition may deliver additional functionality
• Either incorporate OR disable the additional
  functionality
• Architectural mismatch
• Mismatch between what a component offers and what
  is expected within the application context

14
Component Interfaces
component
Provides interface
Requires interface

• Requires interface defines the services that must
  be available for the component to operate
  correctly
• Provides interface defines the services that the
  component provides

15
Component Interfaces
Requires 3 sensor signals Provides majority
signal value
Majority vote

• Requires
• Enables/disables input
• Speed sensor input
• Provides
• Brake setting
• Speed setting

Controller
16
Component Interfaces
Requires Brake setting (on/off) Provides Brake
activator setting
Brake ctrl
Requires Speed setting Provides Speed
activator setting
Speed ctrl
17
Component Interfaces
Brake ctrl
Majority vote
Controller
Speed ctrl
Cruse control system
18
Interface Mismatch

• Typically interface incompatibilities will arise,
  e.g.
• Mismatch between parameter types
• Mismatch between operator names
• Incomplete interface requires and/or provides
• Possible solutions
• Write glue code which bridges the gaps OR
• Use an adaptor component to bridge the gap

Speedo kmph
Display mph
Adaptor kmph2mph
19
The Cost of Component Design

• The cost of developing a reusable component will
  typically be greater than for developing a
  specific equivalent so from the perspective of
  development costs the longer term benefits of
  effective reuse must be taken into account
• Components by definition will be generic, and
  therefore may not be optimized with respect to
  time and space depending on the sector, there
  may be a cost attached to such inefficiencies

20
Predicating Emergent Behaviours

• Ideally if a system is developed from components
  with well-defined behaviours then it should be
  possible to predict the emergent behaviour of the
  system but reality is far from the ideal!
• Providing tool support for predicating emergent
  behaviour is a major area of research, e.g.
• The Carnegie Mellon Software Engineering
  Institute (SEI)
• Predictable Assembly from Certifiable Code (PACC)
• http//www.sei.cmu.edu/pacc/

21
Trustworthiness

• Given a component with no access to the source
  code, how do you decide if it is safe to execute?
• Execute it and see latent bugs may only come to
  light once the system is deployed
• Trust the provider does not take account of
  defects, honest mistakes (or otherwise) and
  tampering during distribution
• Certification who provides the certification,
  why trust them, why trust the certificate?

22
Trust-based Certification
23
Evidence-based Certification
Safety policy
code
certifying compiler
proof checker
code proof
execute code
pass
user interaction may be required in general
fail
Customer
Provider
Proof Carrying Code
24
Proof Carrying Code (PCC)

• Customer and provider agree on a shared security
  policy
• Provider develops code and a mathematical proof
  that the code satisfies the security policy may
  involve skilled user guidance for sophisticated
  policies!
• Proof code sent to the customer no need for
  encryption!
• Customer checks the proof code against the
  shared security policy checking is fully
  automatic
• Only run the code if the check succeeds
• Note that PCC is robust in that it does not
  matter if someone tampers with the proof/code
  during distribution
• But the proof checker needs to be held securely!

25
Summary

• Learning outcomes
• Components as a basis for software reuse
• Component models standards for providers
  integrators
• Trade-offs and compositionality issues
• Predictability, trustworthiness and certification
  
• Recommended reading
• D. Budgen, Software Design, Addison-Wesley 2003
• K-K. Lau Z. Wang A Survey of Software
  Component Models University of Manchester
  Preprint Series CSPP-30
• http//www.cs.man.ac.uk/kung-kiu/pub/cspp38.pdf
• I. Sommerville, Software Engineering,
  Addison-Wesley 2007