A Classification Framework for Component Models Ivica Crnkovic

A Classification Framework for Component Models Ivica Crnkovic, Séverine Sentilles, Aneta Vulgarakis, Michel Chaudron Mälardalen University, Sweden

What is component? • The component case – Many definitions – Some known 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) 17 -Sep-21 2

Different solutions Many CB models (with many different characteristics) exist today Input ports A <<component>> Server <<component>> Client Identical. Itf 17 -Sep-21 C 1 wcet 1 f 1 C 2 wcet 2 f 2 AUTOSAR BIP COMDES CCA Corba CM EJB Fractal KOALA Kobr. A Output ports MS COM Open. Com OSGi PIN PECOS ROBOCOP RUBUS Save. CCM SOFA 2. 0 3

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? 17 -Sep-21 ICATSarajevo - 2007 -10 -29 4

Goal • Propose a classification framework for component models – Identify characteristics and categorize them – Illustrate its use by providing a survey of a number of component models 17 -Sep-21 5

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. 17 -Sep-21 6

Some definitions first… 2 CBS = <C, B, P> component – C = {Ci} - components – B = {Bj} - bindings – P = system platform component 1 <<platform>> – Bindings • Between components and the platform -> components deployment • Between components – components binding A Component model defines standards for (i) properties that individual components must satisfy methods for composing components. 17 -Sep-21 7

More definitiones • Component Specification C = <{Interfaces}, {Properties}> • Component compliance to component model • Component Composition: • Interface composition (BINDING) : I(C) = I(C 1) Å I(C 2) • Property composition: Pi(C) = Pi(C 1) Å Pi(C 2) 17 -Sep-21 8

Classification • How to describe – (i) Commonalities? – (ii) Differences? • Different approaches – Specification of Meta model – List of characteristics – Identification of categories and their characteristics 17 -Sep-21 9

The Classification Framework Categories • Three dimensions – Lifecycle. – Construction. – Extra-Functional Properties. EFP lifecycle construction 17 -Sep-21 10

Component lifecycle requirements modelling Component lifecycle implementation packaging Component forms Specification • Interface • Models • Meta data 17 -Sep-21 Code deployment • Source code • Executable models Execution Storage • Repository • Package • Meta data Installed Files ICAT Sarajevo - 2007 -10 -29 Executable code 12

Construction (I) 1. the component interface used for the interaction with other components and external environment 2. the means of component binding (initiate communication) 3. communication. • Specification of <<component>> Client – Interface – Composition • Binding • interaction 17 -Sep-21 <<component>> Client <<component>> Server 14

Interface Specification Categories • Levels – - Syntactic - Functional Semantic - Behavioral <<component>> Client • Specification language • Distinquish – Provide – Require <<component>> Client • Interface type – Operation-based – Port-based <<component>> Client 17 -Sep-21 15

Binding & Deployment 17 -Sep-21 ICAT Sarajevo - 2007 -10 -29 16

Binding Horizontal <<component>> Client <<component>> Server Vertical <<component>> Server <<component>> Client 17 -Sep-21 (delegation, agregation) <<component>> Server 17

Binding & composition Vertical Composite component <<component>> Server <<component>> Client 17 -Sep-21 (delegation, agregation) <<component>> Server 18

Binding (II) Endogenous <<component>> Client <<component>> Server Exogenous <<component>> Client 17 -Sep-21 <<component>> <<Connector>> In Server between <<component>> Server 19

Interactions Architectural style (client-server, pipe-filter) <<component>> Client <<component>> Server Communication type (synchronous, asynchronous) 20 17 -Sep-21

Construction classification • Interface – operation-based/port-based – provides/requires – The interface level (syntactic, semantic, behaviour) – distinctive features • Binding – Horisontal, Vertical – Endogenous, Exogenous • Interaction – Architectural Style – Communication type (synchronous/asynchronous) 17 -Sep-21 21

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(C 1 o C 2) = P(C 1) o P(C 2) – What kind of composition is supported? – Which properties? 17 -Sep-21 22

Management of EFP

EPF – compositions Pi(C) = Pi(C 1) Å Pi(C 2) Problems: 1. Composition operators? 2. Influence of external factors 17 -Sep-21 24

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(C 1), …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 17 -Sep-21 25

EPF – composition types (III) 3 4 5 Derived 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 Usage-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 System 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 17 -Sep-21 26

Modelling Implementation Lifecycle Packaging At compilation Deployment At run-time Interface specification Interface type Distinction of Provides / Requires Interface Language Classification summary Component model Operation-based Constructs Interaction Binding type Port-based Syntax Interface Levels Semantic Distinctive features Behaviour Interaction Styles Communication Type Synchronous Asynchronous Exogenous / Endogenous Vertical Management Extra functional properties Specification Composition 17 -Sep-21 Endogenous Collaborative Endogenous Systemwide Exogenous Collaborative Exogenous Systemwide 27

Component models evaluations Selection criteria: 1. A component model includes a component definition; 2. A component model provides rules for component interoperability; 3. Component functional properties are unambiguously specified by component interface; 4. A component interface is used in the interoperability mechanisms; 5. A component is an executable piece of software and the component model either directly specifies its form or unambiguously relates to it via interface and interoperability specification. 17 -Sep-21 29

Chosen component models (25 component models) • • • • AUTOSAR BIP Blue. Ar. X CCM COMDES II Compo. NETS EJB Fractal KOALA Kobr. A IEC 61131 IEC 61499 Java. Beans 17 -Sep-21 • • • MS COM Open. COM OSGi Palladio PECOS Pin Pro. Com ROBOCOP RUBUS Save. CCM SOFA 2. 0 30

Lifecycle table Component Models Modelling AUTOSAR N/A Implementation Packaging Deployment C Non-formal specification of container At compilation BIP Language N/A At compilation C N/A Deployment Unit archive (JARs, DLLs) At compilation N/A Deployment Unit archive (JARs, DLLs) EJB-Jar files At compilation File system based repository At run-time Blue. Ar. X A 3 -layered representation: behavior, interaction, and priority N/A CCM N/A Language independent COMDES II ADL-like language C BIP At run-time Compo. NETS Behavour modeling (Petri Nets) Language independent EJB N/A ADL-like language (Fractal ADL, Fractal IDL), Annotations (Fractlet) Java (in Julia, Aokell) C/C++ (in Think). Net lang. (in Frac. Net) ADL-like languages (IDL, CDL and DDL) C File system based repository At compilation Language independent N/A Structured Text (ST) Instruction List (IL) N/A At compilation Language independent N/A At compilation Fractal KOALA Kobr. A IEC 61131 IEC 61499 UML Profile Function Block Diagram (FBD) Ladder Diagram (LD) Sequential Function Chart (SFC) Function Block Diagram (FBD) Java. Beans N/A Java Jar packages MS COM N/A OO languages DLL Open. COM N/A OO languages DLL OSGi N/A Java Jar-files (bundles) Palladio PECOS Pin Pro. Com UML profile ADL-like language (Co. Co) ADL-like language (CCL) ADL-like language, timed automata Java C++ and Java C C N/A Jar packages or DLL File system based repository ROBOCOP ADL-like language, resource management model C and C++ Structures in zip files RUBUS Save. CCM SOFA 2. 0 Rubus Design Language ADL-like (Save. Comp), timed automata Meta-model based specification language C C Java File system based repository Repository 17 -Sep-21 At run-time At compilation and at runtime At run-time and at compilation At run-time At compilation and at runtime At compilation At run-time 31

Lifecycle table Component Models AUTOSAR BIP CCM Fractal KOALA EJB Modelling N/A A 3 -layered representation: behavior, interaction and priority Abstract model: OMG-IDL, Programming model: CIDL ADL-like language (Fractal ADL, Fractal IDL), Annotations (Fractlet) ADL-like languages (IDL, CDL and DDL) N/A 17 -Sep-21 Implementation C Packaging N/A Deployment At compilation Source code, implementation in BIP language N/A At compilation Language independent. Deployment Unit archive (JARs, DLLs) At run-time Julia, Aokell(Java) Think(C/C++) Frac. Net(. Net) File system based repository At run-time File system based repository EJB-Jar files At compilation At run-time C Java binary code 32

Constructs table - Interface Distinction of Provides / Requires Distinctive features Interface Language Interface Levels (Syntactic, Semantic, Behaviour) Yes AUTOSAR Interface* C header files Syntactic Component Models Interface type AUTOSAR Operationbased Port-based BIP Port-based No Complete interfaces, Incomplete interfaces BIP Language Syntactic Semantic Behaviour Blue. Ar. X Port-based Yes C Syntactic CCM Operationbased Port-based Yes N/A Facets and receptacles Event sinks and event sources CORBA IDL, CIDL Syntactic COMDES II Port-based Yes N/A C header files State charts diagrams Syntactic Behaviour Compo. NET Operationbased Port-based S Yes Facets and receptacles Event sinks and event sources Syntactic Behaviour EJB Operationbased No N/A Fractal Operationbased Yes Component Interface, Control Interface KOALA Operationbased Yes Diversity Interface, Optional Interface CORBA IDL, CIDL, Petri nets Java Programming Language + Annotations IDL, Fractal ADL, or Java or C, Behavioural Protocol IDL, CDL Syntactic 17 -Sep-21 Syntactic Behaviour 33

Constructs table – Binding & interaction Component Models Binding Type Interaction Styles Communication Type Exogenous Hierarchical AUTOSAR Request response, Messages passing Synchronous, Asynchronous No Delegation BIP Triggering Rendez-vous, Broadcast Synchronous, Asynchronous No Delegation Blue. Ar. X Pipe&filter Synchronous No Delegation CCM Request response, Triggering Synchronous, Asynchronous No No COMDES II Pipe&filter Synchronous No No Compo. NETS Request response Synchronous, Asynchronous No No EJB Request response Synchronous, Asynchronous No No Fractal Multiple interaction styles Synchronous, Asynchronous Yes KOALA Request response Synchronous No Delegation, Aggregation 17 -Sep-21 34

EFP Component Models Blue. Ar. X EJB 3. 0 Fractal KOALA Kobr. A Palladio Management of EFP Properties specification Composition and analysis support Endogenous per collaboration (A) Exogenous system wide (D) Resource usage, Timing properties N/A N/A Ability to add properties (by adding “property” controllers) N/A Resource usage Compile time checks of resources N/A Exogenous per collaboration (C) Endogenous system wide (B) Endogenous per collaboration (A) Endogenous system wide (B) PECOS Endogenous system wide (B) Pin Exogenous system wide (D) Pro. Com Endogenous system wide (B) 17 -Sep-21 Performance properties specification Timing properties, generic specification of other properties Analytic interface, timing properties Timing and resources Memory consumption, Performance properties N/A Different EFP composition theories, example latency Timing and resources at design and compile time 35

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, …) 17 -Sep-21 36

17 -Sep-21 Generalpurpose Specialised x x x x SOFA 2. 0 x Save. CCM x RUBUS Fractal x x Open. COM x x x Palladio OSGi MS COM x Java. Beasns IEC 61499 IEC 61131 Kobr. A KOALA EJB COMDES II CCM Blue. Ar. X BIP x Robocop x Pro. Com x Pin x Compo. NETS x PECOS Models Generalpurpose Specialised AUTOSAR Models Domains x x 37

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 • Summary – The classification framework helps in understanding component models principles – Enables comparison – Can be used as a check-list when development new component models 17 -Sep-21 38

Literature • Ivica Crnkovic, Séverine Sentilles, Aneta Vulgarakis, Michel Chaudron, A Classification Framework for Component Models • Ivica Crnkovic, Magnus Larsson: Classification of Quality Attributes 17 -Sep-21 39