Software Reuse and Componentbased Design Andrew Ireland School

Software Reuse and Component-based Design Andrew Ireland School of Mathematical & Computer Sciences Heriot-Watt University Edinburgh Software Design F 28 SD 2 © Andrew Ireland

Outline • • • Motivations & Challenges Definitions Component models Process Issues Composition Predictability & Trustworthiness Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

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 `90 s with the specific aim of addressing reuse Note: design patterns also aim to promote reuse Software Design F 28 SD 2 © Andrew Ireland

Reuse via Components Catalogue of software components Customer requirements Component integrator Component Providers Software Design F 28 SD 2 Software application © Andrew Ireland

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) Software Design F 28 SD 2 © Andrew Ireland

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) Software Design F 28 SD 2 © Andrew Ireland

What is a Component? • • Well defined service (functionality) Well defined interface Explicit dependences Standardization - component model Software Design F 28 SD 2 © Andrew Ireland

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 Java. Beans (EJB) - Sun • Component Object Model (COM). NET - Microsoft • CORBA Component Model (CCM) – OMG Note: CORBA = Common Object Requesting Broker Architecture Software Design F 28 SD 2 © Andrew Ireland

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? Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

Component Interfaces component Requires interface • • Provides 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 Software Design F 28 SD 2 © Andrew Ireland

Component Interfaces Majority vote Controller Software Design F 28 SD 2 Requires: 3 sensor signals Provides: majority signal value Requires: • Enables/disables input • Speed sensor input Provides: • Brake setting • Speed setting © Andrew Ireland

Component Interfaces Brake ctrl Requires: Brake setting (on/off) Provides: Brake activator setting Speed ctrl Requires: Speed setting Provides: Speed activator setting Software Design F 28 SD 2 © Andrew Ireland

Component Interfaces Majority vote Brake ctrl Controller Speed ctrl Cruse control system Software Design F 28 SD 2 © Andrew Ireland

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 Software Design F 28 SD 2 Adaptor kmph 2 mph Display mph © Andrew Ireland

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 Software Design F 28 SD 2 © Andrew Ireland

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/ Software Design F 28 SD 2 © Andrew Ireland

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? Software Design F 28 SD 2 © Andrew Ireland

Trust-based Certification Software Design F 28 SD 2 © Andrew Ireland

Evidence-based Certification code certifying compiler Safety policy code + proof pass user interaction may be required in general Provider Software Design F 28 SD 2 proof checker execute code fail Proof Carrying Code Customer © Andrew Ireland

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! Software Design F 28 SD 2 © Andrew Ireland

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/cspp 38. pdf – I. Sommerville, “Software Engineering”, Addison-Wesley 2007 Software Design F 28 SD 2 © Andrew Ireland