Component Models - main characteristics Ivica Crnkovic

Outline Motivation and goals for using components in Software Basic characteristics of component models Classification of component models Component models examples 26-Dec-152

Challanges of Software Engineering Page 3, 26 December December 2015 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

Observations on the practice of SE Page 4, 26 December December 2015 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

Page 5, 26 December December 2015 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

Page 6, 26 December December 2015 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

26-Dec-157 What is component? The component case –Many definitions –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 –Intuitive perception may be quite different at different levels (model, implementation, run-time)

Page 8, 26 December December 2015 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

Page 9, 26 December December 2015 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. –Functional Aspects (API) –Pre- and post-conditions for the operations specified by API. A component may provide / implement several interfaces IBar IFoo IFoo2

Page 10, 26 December December 2015 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? Do existing component models have support for declaring the dependencies? Is it possible to verify if the environment comply with the context required?

Page 11, 26 December December 2015 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). Which problems can occur in relation to late binding? How can we guarantee that a replacement of a component will not affect other parts of the system? What does it mean deployed independently?

Page 12, 26 December December 2015 Example: Interface description: (M)IDL (Microsoft) Interface Definition Language [ uuid( ABBA-ABBA-ABBA-BADBADBADBAD), object ] interface IAddressList { HRESULT addAddress ([in] name, [in] address); HRESULT deleteAddress ([in] name, [in] address); } language independent interface specification can be compiled into language dependent code skeletons

Page 13, 26 December December 2015 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

Page 14, 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; };

Page 15, 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

Page 16, CBSE – graduate course Example: UML Component Specification

Page 17, 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 = (word) context SpellChecker ISpellCheck::words = ICustomSpellCheck::words

Page 18, 26 December December 2015 Contractually specified interfaces in a UML metamodel

Finally- components have attributes Extra functional properties –Memory size –Requires CPU –… –Performance Response time Execution time –Quality attributes Reliability Avaliability 26-Dec-1519ICAT Sarajevo

Components and properties 26-Dec-1520

26-Dec-1521 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

26-Dec-15ICATSarajevo 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?

26-Dec-1523 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.

Classification (i) Commonalities, (ii) Differences Different approaches –Specification of Meta model –List of characteristics –Identification of categories and their characteristics Component Specification C = Component Composition: C = C 1  C 2 Interaction (Interface composition):I(C) = I(C 1 )  I(C 2 ) Property composition: P i (C) = P i (C 1 )  P i (C 2 ) Component Lifecycle 26-Dec-1524

26-Dec-1525 The Classification Framework - Categories 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. Constructs. The constructs dimension identifies (i) the component interface used for the interaction with other components and external environment, and (ii) the means of component binding and communication. 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

The component-based development process

The Component lifecycle

Component lifecycle 26-Dec-15ICAT Sarajevo 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

26-Dec-1529 Lifecycle category Different stages of a component lifecycle Modelling. The component models provide support for the modelling and the design of component-based systems and components. Implementation. The component model provides support for generating and maintaining code. The implementation can stop with the provision of the source code, or can continue up to the generation of a binary (executable) code. Storage & Packaging. Since components can be developed separately from systems, there is a need for their storage and packaging – either for the repository or for a distribution Deployment & Execution. At a certain point of time, a component is integrated into a system. This activity happens at different points of development or maintenance phase.

Constructs – components Interactions Specification of –Interface –Composition (interaction) 26-Dec-1530 > Client > Client > Server Double role of Interface

Constructs – Interface Specification Categories Levels –- Syntactic -Semantic - Behavioral Specification language Distinquish –Provide –Require Interface type –Operation-based –Port-based 26-Dec-1531 > Client > Client > Client

26-Dec-1532 Constructs – compositions (I) > Client Architectural style (client-server, pipe-filter) Communication type (synchronous, asynchronous) > Server

26-Dec-1533 Constructs compositions (II) > Client > Server Exogenous > Client > Server > In between > Server Endogenous C1.x = C2.y a = C2.y C1.x = a

26-Dec-1534 Constructs compositions (III) Composition Horizontal > Client > Server > Server Vertical > Client > Server

Constructs classification Interface –operation-based/port-based –provides/requires –The interface level (syntactic, semantic, behaviour) –distinctive features Connections –Architectural Style –Communication type (synchronous/asynchronous) –Binding type Endogenous, Exogenous Vertical, horisontal 26-Dec-1535

26-Dec-1536 Extra-Functional Properties Management of extra-functional properties –Does a component provide any support for extra-functional properties? –What are the mechanisms? –Which properties are managed? Composition of extra-functional properties –P(C1 o C2) = P(C1) o P(C2) –What kind of composition is supported? –Which properties?

Management of EFP

EPF – composition types (I) 1.Directly composable properties. 2.Architecture-related properties 3.Derived properties. 4.Usage-depended properties. 5.System environment context properties. 26-Dec-1538

EPF – composition types (II) 1.Directly composable properties. A property of an assembly is a function of, and only of, the same property of the components involved. –P(A) = f(P(C1),…P(Ci),…,P(Cn)) 2.Architecture-related properties. A property of an assembly is a function of the same property of the components and of the software architecture. –P(A) = f(SA, …P(Ci)…), i=1…n –SA = software architecture 26-Dec-1539

EPF – composition types (III) 3Derived properties. A property of an assembly depends on several different properties of the components. –P(A) = f(SA, …Pi(Cj)…), i=1…m, j=1…n –Pi = component properties –Cj = components 4Usage-depended properties. A property of an assembly is determined by its usage profile. –P(A,U) = f(SA, …Pi(Cj,U)…), i=1…m, j=1…n –U = Usage profile 5System environment context properties. A property is determined by other properties and by the state of the system environment. –P(S,U,X) = f(SA, …Pi(Cj,U,X)…), i=1…m, j=1…n –S= system, X = system context 26-Dec-1540

26-Dec-1541 Domains Applications and business domain of the Component Models General-purpose: –Basic mechanisms for the production and the composition of components –Provide no guidance, nor support for any specific architecture. Specialised: –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)

26-Dec-1542 Component model LifecycleModelling Implementatio n PackagingDeploymentAt compilationAt run-timeConstructs Interface specification Interface typeOperation-basedPort-based Distinction of Provides / Requires Interface Language Interface LevelsSyntaxSemanticBehaviour Distinctive features Interaction Interaction Styles Communication Type SynchronousAsynchronousBinding type Exogenous / Endogenous Hierarchical Extra functional properties Management Endogenous Collaborative Endogenous Systemwide Exogenous Collaborative Exogenous Systemwide Specification Composition and analysis support DomainsGenerative General purpose Specialised

26-Dec-1543 Illustration of the Classification Framework use Survey of 20 component models Selection of documentation for each component model –Satisfies criteria –Disponibility the definition (Interfaces, composition) –Some points in the table have been subject our interpretation.

26-Dec-1544 Chosen component models AUTOSAR BIP COMDES Common Component Architecture (CCA) CompoNETS CORBA Component Model (CCM) The Entreprise JavaBeans (EJB Fractal The K-Component Model KobrA Koala PIN Microsoft Component Object Model (COM) OpenCOM The Open Services Gateway Initiative (OSGi) Palladio Pin Robocop Rubus SaveCCM

26-Dec-1545 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 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

26-Dec-1546 Lifecycle table 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

26-Dec-1547 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, CIDL Syntactic COMDES II Port-basedYes N/A C header files State charts diagrams Syntactic Behaviour CompoNET S Operation- based Port-based Yes Facets and receptacles Event sinks and event sources CORBA IDL, CIDL, Petri nets Syntactic Behaviour EJB Operation- based NoN/A Java Programming Language + Annotations Syntactic Fractal Operation- based Yes Component Interface, Control Interface IDL, Fractal ADL, or Java or C, Behavioural Protocol Syntactic Behaviour KOALA Operation- based Yes Diversity Interface, Optional Interface IDL, CDLSyntactic

26-Dec-1548 Constructs table - interaction COMPONENT MODELS INTERACTION STYLES COMMUNICATION TYPE BINDING TYPE EXOGENOUSHIERARCHICAL 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

26-Dec-1549 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

26-Dec-1550 Domains Domain AUTOSAR BIP BlueArX CCM COMDES II CompoNETS EJB Fractal KOALA KobrA IEC IEC JavaBeasns MS COM OpenCOM OSGi Palladio PECOS Pin ProCom Robocop RUBUS SaveCCM SOFA 2.0 General- purpose xxxxxxxxxxx Specialisedxx x xx xx xxxxxx Generativexxx

26-Dec-1551 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