Component Models - main characteristics

1. Component Models- main characteristics Ivica Crnkovic

2. Outline • Motivation and goals for using components in Software • Basic characteristics of component models • Classification of component models • Component models examples

3. Challanges of Software Engineering • The size & complexity of software increases rapidly • Single products become part of product families • Software is upgraded after deployment • Time-to marked must decrease significntely • The costs of (software) products must be reduced

4. Observations on the practice of SE • About 80% of software development deals with changing of existing software • “It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to changes” • Darwin • We need methods that will • Easy incorporate changes • Adaptations • Be able to fast response to the new requirements

5. A possible solution: Component-based Development • Idea: • Build software systems from pre-existing components (like building cars from existing components) • Building components that can be reused in different applications • Separate development of components from development of systems

6. What is software component? • Many definitions • Intuitive perception may be quite different at different levels (model, implementation, run-time) • Some acknowledge ones: • software component is a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties. Szyperski • A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard Heineman and Councill

7. Composition unit A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. –Clemens Szyperski How much components fit together? How much costs the glue code? System Glue code Components

8. IBar IFoo IFoo2 What is a contract? A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. • Contract - A specification attached to an interface that mutually binds the clients and providers of the components. A component may provide/ implement several interfaces

9. What is an explicit context dependency? A software component is a unit of composition with contractuallyspecified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. • Context dependencies - Specification of the deployment environment and run-time environment • Example: Which tools, platforms, resources or other components are required?

10. What does it mean deployed independently? A software component is a unit of composition with contractuallyspecified interfacesand explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. • Late binding - dependencies are resolved at load or run-time. • Replacing of a component independent of the client (main application) if the contract is not broken. • Delegation - interaction with a weak coupling (for example no inheritance).

11. Components and Interfaces - UML definition Component – a set of interfaces required (in-interfaces) provided (out-interfaces) Interface – set of operations Operations – input and output parameters of certain type

12. Example: Specification of a COM component interface ISpellCheck : IUnknown { HRESULT check([in] BSTR *word, [out] bool *correct); }; interface ICustomSpellCheck : IUnknown { HRESULT add([in] BSTR *word); HRESULT remove([in] BSTR *word); }; library SpellCheckerLib { coclass SpellChecker { [default] interface ISpellCheck; interface ICustomSpellCheck; }; }; CBSE – graduate course

13. Semantic Specification • Extension of syntactic specification • A state model is associated with each interface • Operations have pre- and post-conditions • pre: state * in-parameters -> bool • post: state * state * in-parameters * out-parameters -> bool • Invariants on an interface’s state model • state -> bool • Intra-interface conditions for components • state1 * state2 * … -> bool CBSE – graduate course

14. Example: Object Constraint Language (OCL) context ISpellCheck::check(in word : String, out correct : Boolean) : HRESULT pre: word <> “” post: SUCCEEDED(result) implies correct = words->includes(word) context ICustomSpellCheck::add(in word : String) : HRESULT pre: word <> “” post: SUCCEEDED(result) implies words = words@pre->including (word) context SpellChecker ISpellCheck::words = ICustomSpellCheck::words CBSE – graduate course

15. Contractually specified interfaces in a UML metamodel

16. Finally- components have attributes • Extra functional properties • Memory size • Requires CPU • … • Performance • Response time • Execution time • Quality attributes • Reliability • Avaliability ICAT Sarajevo - 2007-10-29

17. Components and properties

18. <<component>> Client <<component>> Server A Output ports Input ports C1wcet1f1 C2wcet2f2 Different solutions • A plethora of CB models (with many different characteristics) MS COM OpenCom OSGi PIN PECOS ROBOCOP RUBUS SaveCCM SOFA 2.0 AUTOSAR BIP COMDES CCA Corba CM EJBFractal KOALA KobrA IdenticalItf

19. Questions • What is common to component models? • It is possible to identify common principles and common features? • Is it possible to utilize/instantiate these principles for particular component models in particular domains? ICATSarajevo - 2007-10-29

20. Definitions: Software Component – Component Model Definition: • A Software Component is a software building block that conforms to a component model. • A Component Model defines standards for • (i) properties that individual components must satisfy and • (ii) methods, and possibly mechanisms, for composing components.

21. A Classification framework for component model Based on Ivica Crnkovic, Séverine Sentilles, Aneta Vulgarakis, and Michel Chaudron. ”A Classification Framework for Component Models”. Accepted to IEEE Transactions on Software Engineering (in the process of revision).

22. Motivation • Questions: • What is common to component models? • It is possible to identify common principles and common features? • Is it possible to utilize/instantiate these principles for particular component models in particular domains? • Goal: • Increase the understanding of the basic concepts of component models • Easier differentiate and group component models according to several characteristics

23. Classification • (i) Commonalities, • (ii) Differences • Different approaches • Specification of Meta model • List of characteristics • Identification of categories and their characteristics

24. The Classification Framework - Dimensions 3+1 EFP • Lifecycle.The lifecycle dimension identifies the support provided (explicitly or implicitly) by the component model, in certain points of a lifecycle of components or component-based systems. • Construction. The construction dimension identifies (i) the component interface used for the interaction with other components and external environment, and (ii) the means of establishing interaction between the components(binding) and means for intercommunication (interactions). • Extra-Functional Properties. The extra-functional properties dimension identifies specifications and support that includes the provision of property values and means for their composition. • Domains. This dimension shows in which application and business domains component models are used. construction lifecycle Domain A Domain B

25. The component-based development process

26. The Component lifecycle

27. I. Lifecycle dimension Component lifecycle deployment requirements modelling implementation packaging execution • Specification • Interface • Models • Meta data • Code • Source code • Executable code • Executable models • Storage • Repository • Package • Meta data Installed Files Executable code Component forms in a component lifecycle

28. II. Construction dimension • Includes 3 parts: • Connection points i.e. interfaces • Mechanisms for establishing interaction i.e. binding • Communication i.e. interaction

29. <<component>> Client 1. Interface C3 C1 C2 • provided interface • Defines a set of actions that are understood by both the provider component and the user component • Provided interface- actions that the interface provides to the environment • Required interface – requires from the environment • Two types of interfaces: • Operation-based (e.g. method invocation) • Port-based (e.g. data passing) C1 C3 • required interface C2 trigger2 trigger0 trigger3 trigger1 trigger2’ data1 trigger3’ trigger0’ trigger2’’ function0() function1() trigger1’ trigger3’’ function2() • operation-based • port-based

30. <<component>> Client <<component>> Server 1. Interface (cont’d) Interface specification (IDL, state charts, programming languages, etc.) Dinstictive features E.g. special types of ports, optional operations, … Interface levels – compatability checking between interfaces i.e. contract Syntatic level – type checking Semantic level – value checking (pre- and post-conditions and invariants) Behavior level – dynamic behavior of component services Syntactic Semantic Behaviour Interface levels

31. Horizontal <<component>> Client <<component>> Server <<component>> Server <<component>> Client <<component>> Server Vertical 2. Binding • Enables connection of components through their interfaces and interaction channels • Can an assembly, i.e. set of components mutually connected, be treated as a component itself?

32. <<component>> Client <<component>> Server <<component>> Client <<component>> Server <<Connector>> In between <<component>> Server 2. Binding (cont’d) Endogenous client.x = server.y Exogenous a = server.y client.x = a • Binding does not need to be one-to-one direct connection between two components

33. <<component>> Client <<component>> Server 3. Interaction Architectural style (request-response, pipe-filter) Communication type (synchronous, asynchronous) • Components communicate with each other through different architectural (interaction) styles • E.g. pipe and filter, request-response, broadcast, blackboard, etc.

34. Construction classification • Interface • operation-based/port-based • provides/requires • interface specification • distinctive features • interface level (syntactic, semantic, behaviour) • Binding • vertical, horizontal • endogenous, exogenous • Interaction • architectural style • communication type (synchronous/asynchronous)

35. III. Extra-functional properties dimension • Management of extra-functional properties • Does a component provide any support for management of extra-functional properties? • What are the mechanisms? • Which properties are managed? • Extra-functional properties specification • Does the component model contains means for specification of EFP properties? • Which properties? • Composition of extra-functional properties • P(C1 o C2) = P(C1) o P(C2) • What kind of composition is supported? • Which properties?

36. Management of EFP

37. IV. Domains • General-purpose: • Basic mechanisms for specification and composition of components • Provide no guidance, nor support for any specific architecture. • Specialized: • Specific application domains (i.e. consumer electronics, automotive, …) • Generative: • Instantiation of particular component models • Provide common principles and some common parts of technologies (for example modelling) • Other parts are specific (for example different implementations)

39. Illustration of the Classification Framework use • List of 23 component models that have been classified according to the classification framework • AUTOSAR • BIP • BlueArX • COMDES II • CompoNETS • CCM • EJB • Fractal • Koala • KobrA • IEC 61131 • JB • Microsoft COM • OpenCOM • OSGi • Palladio • Pecos • Pin • ProCom • Robocop • Rubus • SaveCCM • SOFA

40. Lifecycle table

41. Lifecycle table

42. Constructs table - Interface

43. Constructs table – interaction

44. EFP

45. Domains

46. Conclusion • From the results we can recognize some recurrent patterns such as: • general-purpose component models utilize client-server style • Specialized domains (mostly embedded systems) pipe & filter is the predominate style. • Composition of extra-functional properties is rather scarce. • Behaviour & Semantic rarely supported • Almost never repository