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 4-Jun-162

3. Challanges of Software Engineering Page 3, 4 June 2016 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 Page 4, 4 June 2016 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. Page 5, 4 June 2016 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. Page 6, 4 June 2016 The software architecture of a program or computing system is the structure or structures of the system, which comprise software components [and connectors], the externally visible properties of those components [and connectors] and the relationships among them.” Bass L., Clements P., and Kazman R., Software Architecture in Practice, C1 C4 C2 C5C3 Systems and components – Software Achitectures

7. 4-Jun-167 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

8. Page 8, 4 June 2016 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? Components Glue code System

9. Page 9, 4 June 2016 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 IBar IFoo IFoo2

10. Page 10, 4 June 2016 What is an explicit context dependency? 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. Context dependencies - Specification of the deployment environment and run-time environment –Example: Which tools, platforms, resources or other components are required?

11. Page 11, 4 June 2016 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. 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). What does it mean deployed independently?

12. Page 12, 4 June 2016 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

13. Page 13, CBSE – graduate course 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; };

14. Page 14, CBSE – graduate course 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

15. Page 15, CBSE – graduate course 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

16. Page 16, 4 June 2016 Contractually specified interfaces in a UML metamodel

17. Finally- components have attributes Extra functional properties –Memory size –Requires CPU –… –Performance Response time Execution time –Quality attributes Reliability Avaliability 4-Jun-1617ICAT Sarajevo - 2007-10-29

18. Components and properties 4-Jun-1618

19. 4-Jun-1619 Different solutions A plethora of CB models (with many different characteristics) > Client > Server IdenticalItf C1 wcet1 f1 A C2 wcet2 f2 Input ports Output ports AUTOSAR BIP COMDES CCA Corba CM EJBFractal KOALA KobrA MS COM OpenCom OSGi PIN PECOS ROBOCOP RUBUS SaveCCM SOFA 2.0

20. 4-Jun-16ICATSarajevo - 2007-10-2920 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?

21. 4-Jun-1621 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.

22. 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).

23. 4-Jun-1623 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

24. Classification (i) Commonalities, (ii) Differences Different approaches –Specification of Meta model –List of characteristics –Identification of categories and their characteristics 4-Jun-1624

25. 4-Jun-1625 The Classification Framework - Dimensions 3+1 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. lifecycle EFP Domain ADomain B construction

26. The component-based development process

27. The Component lifecycle

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

29. II. Construction dimension 4-Jun-1629 Includes 3 parts: 1.Connection points i.e. interfaces 2.Mechanisms for establishing interaction i.e. binding 3.Communication i.e. interaction

30. 1. Interface 4-Jun-1630 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) C1C2C3 function1() function2() function0() operation-based C3 trigger1 data1 trigger0 C2C1 trigger0’ trigger2’ trigger2’’ trigger1’ trigger2 trigger3 trigger3’ trigger3’’ port-based > Client provided interface required interface

31. 1. Interface (cont’d) 4-Jun-1631 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 > Client Syntactic Interface levels SemanticBehaviour > Server

32. 4-Jun-1632 Horizontal > Client > Server > Server Vertical > Client > Server 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?

33. 4-Jun-1633 > Client > Server Exogenous > Client > Server > In between > Server Endogenous client.x = server.y a = server.y client.x = a 2. Binding (cont’d) Binding does not need to be one-to-one direct connection between two components

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

35. 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) 4-Jun-1635

36. 4-Jun-1636 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?

37. Management of EFP 4-Jun-16

38. 38 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) IV. Domains

39. 4-Jun-1639

40. 4-Jun-1640 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

41. 4-Jun-1641 Lifecycle table Component Models ModellingImplementationPackagingDeployment AUTOSARN/AC Non-formal specification of container At compilation BIP A 3-layered representation: behavior, interaction, and priority BIP LanguageN/AAt compilation BlueArXN/AC At compilation CCMN/ALanguage independent Deployment Unit archive (JARs, DLLs) At run-time COMDES IIADL-like languageCN/A At compilation CompoNETSBehavour modeling (Petri Nets)Language independent Deployment Unit archive (JARs, DLLs) At run-time EJBN/AJavaEJB-Jar filesAt run-time Fractal ADL-like language (Fractal ADL, Fractal IDL), Annotations (Fractlet) Java (in Julia, Aokell) C/C++ (in Think).Net lang. (in FracNet) File system based repositoryAt run-time KOALAADL-like languages (IDL,CDL and DDL)CFile system based repositoryAt compilation KobrAUML ProfileLanguage independentN/A IEC 61131 Function Block Diagram (FBD) Ladder Diagram (LD) Sequential Function Chart (SFC) Structured Text (ST) Instruction List (IL) N/AAt compilation IEC 61499Function Block Diagram (FBD)Language independentN/AAt compilation JavaBeansN/AJavaJar packagesAt compilation MS COMN/AOO languagesDLL At compilation and at run- time OpenCOMN/AOO languagesDLLAt run-time OSGiN/AJavaJar-files (bundles) At run-time and at compilation PalladioUML profileJavaN/AAt run-time PECOSADL-like language (CoCo)C++ and JavaJar packages or DLLAt compilation PinADL-like language (CCL)CDLLAt compilation ProComADL-like language, timed automataCFile system based repositoryAt compilation ROBOCOPADL-like language, resource management modelC and C++Structures in zip files At compilation and at run- time RUBUSRubus Design LanguageCFile system based repositoryAt compilation SaveCCMADL-like (SaveComp), timed automataCFile system based repositoryAt compilation SOFA 2.0Meta-model based specification languageJavaRepositoryAt run-time

42. 4-Jun-1642 Component Models ModellingImplementationPackagingDeployment AUTOSARN/AC At compilation BIP A 3-layered representation: behavior, interaction and priority Source code, implementation in BIP language N/A At compilation CCM Abstract model:OMG-IDL, Programming model: CIDL Language independent. Deployment Unit archive (JARs, DLLs) At run-time Fractal ADL-like language (Fractal ADL, Fractal IDL), Annotations (Fractlet) Julia, Aokell(Java) Think(C/C++) FracNet(.Net) File system based repository At run-time KOALA ADL-like languages (IDL,CDL and DDL) C File system based repository At compilation EJBN/AJava binary codeEJB-Jar filesAt run-time Lifecycle table

43. 4-Jun-1643 Constructs table - Interface Component Models Interface type Distinction of Provides / Requires Distinctive features Interface Language Interface Levels ( Syntactic, Semantic, Behaviour) AUTOSAR Operation-based Port-based YesAUTOSAR Interface*C header filesSyntactic BIPPort-basedNo Complete interfaces, Incomplete interfaces BIP Language Syntactic Semantic Behaviour BlueArXPort-basedYes N/A CSyntactic CCM Operation-based Port-based Yes Facets and receptacles Event sinks and event sources CORBA IDL, CIDLSyntactic COMDES II Port-basedYes N/A C header files State charts diagrams Syntactic Behaviour CompoNETS Operation-based Port-based Yes Facets and receptacles Event sinks and event sources CORBA IDL, CIDL, Petri nets Syntactic Behaviour EJBOperation-basedNoN/A Java Programming Language + Annotations Syntactic FractalOperation-basedYes Component Interface, Control Interface IDL, Fractal ADL, or Java or C, Behavioural Protocol Syntactic Behaviour KOALAOperation-basedYes Diversity Interface, Optional Interface IDL, CDLSyntactic

44. 4-Jun-1644 Constructs table – interaction COMPONENT MODELS INTERACTION STYLESCOMMUNICATION TYPE BINDING TYPE EXOGENOUS HIERARCHICAL i.e. VERTICAL AUTOSAR Request response, Messages passing Synchronous, Asynchronous NoDelegation BIP Triggering Rendez-vous, Broadcast Synchronous, Asynchronous NoDelegation BlueArXPipe&filterSynchronousNoDelegation CCM Request response, Triggering Synchronous, Asynchronous No COMDES IIPipe&filterSynchronousNo CompoNETSRequest response Synchronous, Asynchronous No EJBRequest response Synchronous, Asynchronous No Fractal Multiple interaction styles Synchronous, Asynchronous Yes Delegation, Aggregation KOALARequest responseSynchronousNo Delegation, Aggregation

45. 4-Jun-1645 EFP Component Models Management of EFPProperties specification Composition and analysis support BlueArXEndogenous per collaboration (A)Resource usage, Timing propertiesN/A EJB 3.0Exogenous system wide (D)N/A FractalExogenous per collaboration (C) Ability to add properties (by adding “property” controllers) N/A KOALAEndogenous system wide (B)Resource usageCompile time checks of resources KobrAEndogenous per collaboration (A)N/A PalladioEndogenous system wide (B)Performance properties specificationPerformance properties PECOSEndogenous system wide (B) Timing properties, generic specification of other properties N/A PinExogenous system wide (D)Analytic interface, timing properties Different EFP composition theories, example latency ProComEndogenous system wide (B)Timing and resources Timing and resources at design and compile time RobocopEndogenous system wide (B) Memory consumption, Timing properties, reliability, ability to add other properties Memory consumption and timing properties at deployment RubusEndogenous system wide (B)TimingTiming properties at design time SaveCCMEndogenous system wide (B) Timing properties, generic specification of other properties Timing properties at design time SOFA 2.0Endogenous system wide (B)Behavioural (protocols)Composition at design

46. 4-Jun-1646 Domains Domain AUTOSAR BIP BlueArX CCM COMDES II CompoNETS EJB Fractal KOALA KobrA IEC 61131IEC 61499 JavaBeasns MS COM OpenCOM OSGi Palladio PECOS Pin ProCom Robocop RUBUS SaveCCM SOFA 2.0 General-purposexxxxxxxxxxx Specialisedxx x xx xx xxxxxx Generativexxx

47. 4-Jun-1647 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