Software reuse and component based design
Download
1 / 25

Software Reuse and Component-based Design - PowerPoint PPT Presentation


  • 162 Views
  • Updated On :

Software Reuse and Component-based Design. Andrew Ireland School of Mathematical & Computer Sciences Heriot-Watt University Edinburgh. Outline. Motivations & Challenges Definitions Component models Process Issues Composition Predictability & Trustworthiness. Motivations .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Reuse and Component-based Design' - barto


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software reuse and component based design l.jpg

Software Reuse and Component-based Design

Andrew Ireland

School of Mathematical & Computer Sciences

Heriot-Watt University

Edinburgh


Outline l.jpg
Outline

  • Motivations & Challenges

  • Definitions

  • Component models

  • Process Issues

  • Composition

  • Predictability & Trustworthiness


Motivations l.jpg
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


Motivations4 l.jpg
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


Reuse via components l.jpg
Reuse via Components

Catalogue of

software

components

Customer

requirements

Component

integrator

Software

application

Component

Providers


What is a component l.jpg
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)


What is a component7 l.jpg
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)


What is a component8 l.jpg
What is a Component?

  • Well defined service (functionality)

  • Well defined interface

  • Explicit dependences

  • Standardization

- component model


What is a component model l.jpg
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


Challenges l.jpg
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?


Component based process l.jpg
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


Composition problems l.jpg
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


Composition problems13 l.jpg
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


Component interfaces l.jpg
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


Component interfaces15 l.jpg
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


Component interfaces16 l.jpg
Component Interfaces

Requires: Brake setting (on/off)

Provides: Brake activator setting

Brake

ctrl

Requires: Speed setting

Provides: Speed activator setting

Speed

ctrl


Component interfaces17 l.jpg
Component Interfaces

Brake

ctrl

Majority

vote

Controller

Speed

ctrl

Cruse control system


Interface mismatch l.jpg
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


The cost of component design l.jpg
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


Predicating emergent behaviours l.jpg
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/


Trustworthiness l.jpg
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?



Evidence based certification l.jpg
Evidence-based Certification

Safety

policy

code

certifying

compiler

code

+

proof

proof

checker

pass

execute

code

user interaction

may be required

in general

fail

Customer

Provider

Proof Carrying Code


Proof carrying code pcc l.jpg
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!


Summary l.jpg
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