Software Reuse and Component-based 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 code + proof proof checker pass execute code 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