Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
A Classification Framework for     Component Models              Ivica Crnkovic,        Ivica.crnkovic@mdh.se    Mälardale...
What is component?• The component case  – Many definitions  – Some known ones:     • software component is a unit of compo...
Different solutionsMany CB models (with many different characteristics) exist  todayy                                     ...
Questions– What is common to component models?– It is possible to identify common principles and common  features?– Is it ...
Goal• Propose a classification framework for  component models  – Identify characteristics and categorize them  – Illustra...
Definitions:        Software Component – Component ModelDefinition:• A Software Component is a software building block tha...
Some definitions first…                                               2CBS = <C,B,P>                      component       ...
More definitiones•   Component Specification           C = <{Interfaces}, {Properties}>           • Component compliance t...
Classification• How to describe  – (i) Commonalities?  – (ii) Differences?• Different approaches  – Specification of Meta ...
The Classification Framework -            Categories• Three dimensions – Lifecycle. – Construction.                     EF...
Component lifecyclerequirementsrequirements                     modelling                     modelling                   ...
Construction (I)1. the component interface used for the interaction with other components   and external environment2. the...
Interface Specification                               Categories                                •   Levels                ...
Binding & Deployment4 Apr 2013   ICAT Sarajevo - 2007-10-29   16
Binding   Horizontal <<component>>                     <<component>>     Client                            Server   Vertic...
Binding & composition   Vertical Composite component                       <<component>>                           Server ...
Binding (II)        Endogenous<<component>>             <<component>>    Client                    Server         Exogenou...
InteractionsArchitectural style            <<component>>   <<component>>                                   Client         ...
Construction classification• Interface   – operation-based/port-based   – provides/requires   – The interface level (synta...
Extra-Functional Properties• Management of extra-functional properties  – Does a component provide any support for extra-f...
Management of EFP                 A                                                  B     component                      ...
EPF – compositionsPi(C) = Pi(C1) ⊕ Pi(C2)Problems:1. Composition operators?2. Influence of external factors4 Apr 2013     ...
EPF – composition types (II)1. Directly composable properties. A property of an assembly is a   function of, and only of, ...
EPF – composition types (III)3   Derived properties. A property of an assembly depends on    several different properties ...
Classificationsummary                 4 Apr 2013   27
Component models evaluationsSelection criteria:1. A component model includes a component definition;2. A component model p...
Chosen component models                (25 component models)•   AUTOSAR                •   MS COM•   BIP                  ...
Lifecycle tableComponent                              Modelling                              Implementation               ...
Lifecycle tableComponent                 Modelling           Implementation         Packaging        Deployment Models    ...
Constructs table - Interface                           Distinction                                               Interface...
Constructs table – Binding & interaction                                                                 Binding Type Comp...
EFPComponent        Management of               Properties              Composition and Models              EFP           ...
DomainsApplications and business domain of the Component Models•   General-purpose:    – Basic mechanisms for the producti...
Domains4 Apr 2013             37
Conclusion•   From the results we can recognize some recurrent patterns such as     – general-purpose component models uti...
Literature• Ivica Crnkovic, Séverine Sentilles, Aneta Vulgarakis,  Michel Chaudron,  A Classification Framework for Compon...
Upcoming SlideShare
Loading in …5
×

A classification framework for component models

748 views

Published on

In the last decade a large number of different software component models have been developed, with different aims and using different principles and technologies. This has resulted in a number of models which have many similarities, but also principal differences, and in many cases unclear concepts. Component-based development has not succeeded in providing standard principles, as has, for example, object-oriented development. In order to increase the understanding of the concepts, and to differentiate component models more easily, this paper identifies, discusses and characterises fundamental principles of component models, and provides a Component Model Classification Framework based on these principles. Further, the paper classifies a large number of component models using this framework.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

A classification framework for component models

  1. 1. A Classification Framework for Component Models Ivica Crnkovic, Ivica.crnkovic@mdh.se Mälardalen University, Sweden
  2. 2. 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) 4 Apr 2013 2
  3. 3. Different solutionsMany CB models (with many different characteristics) exist todayy A Input Output ports ports C1 C2 wcet1 wcet2 f1 f2 AUTOSAR MS COM BIP OpenCom COMDES OSGi CCA PIN Corba CM PECOS EJB ROBOCOP<<component>> <<component>> Fractal RUBUS Client Server KOALA SaveCCM IdenticalItf KobrA SOFA 2.0 4 Apr 2013 3
  4. 4. 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? 4 Apr 2013 ICATSarajevo - 2007-10-29 4
  5. 5. 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 4 Apr 2013 5
  6. 6. Definitions: Software Component – Component ModelDefinition:• 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. 4 Apr 2013 6
  7. 7. Some definitions first… 2CBS = <C,B,P> component component – C = {Ci} - components – B = {Bj} - bindings 1 – P = system platform <<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. 4 Apr 2013 7
  8. 8. More definitiones• Component Specification C = <{Interfaces}, {Properties}> • Component compliance to component model • Component Composition: • Interface composition (BINDING) : I(C) = I(C1) ⊕ I(C2) • Property composition: Pi(C) = Pi(C1) ⊕ Pi(C2) 4 Apr 2013 8
  9. 9. Classification• How to describe – (i) Commonalities? – (ii) Differences?• Different approaches – Specification of Meta model – List of characteristics – Identification of categories and their characteristics 4 Apr 2013 9
  10. 10. The Classification Framework - Categories• Three dimensions – Lifecycle. – Construction. EFP – Extra-Functional Properties. lifecycle construction 4 Apr 2013 10
  11. 11. Component lifecyclerequirementsrequirements modelling modelling Component lifecycle implementation implementation packaging packaging Component forms deployment deployment Execution Execution Specification Specification Code Code Storage Storage • Interface • Interface • Source code • Source code • Repository • Repository • Models • Models • Executable code • Executable code • Package • Package Installed Installed Executable Executable • Meta data • Meta data • Executable models • Executable models • Meta data • Meta data Files Files code code 4 Apr 2013 ICAT Sarajevo - 2007-10-29 12
  12. 12. Construction (I)1. the component interface used for the interaction with other components and external environment2. the means of component binding (initiate communication)3. communication. <<component>> Client• Specification of – Interface – Composition <<component>> <<component>> Client Server • Binding • interaction 4 Apr 2013 14
  13. 13. Interface Specification Categories • Levels – - Syntactic - Functional Semantic - Behavioral<<component>> • Specification language Client • Distinquish – Provide<<component>> Client – Require • Interface type – Operation-based<<component>> Client – Port-based 4 Apr 2013 15
  14. 14. Binding & Deployment4 Apr 2013 ICAT Sarajevo - 2007-10-29 16
  15. 15. Binding Horizontal <<component>> <<component>> Client Server Vertical <<component>> Server (delegation,agregation) <<component>> <<component>> Client Server 4 Apr 2013 17
  16. 16. Binding & composition Vertical Composite component <<component>> Server (delegation,agregation) <<component>> <<component>> Client Server 4 Apr 2013 18
  17. 17. Binding (II) Endogenous<<component>> <<component>> Client Server Exogenous<<component>> <<component>> <<Connector>> <<component>> Client In Server between Server 4 Apr 2013 19
  18. 18. InteractionsArchitectural style <<component>> <<component>> Client Server(client-server, pipe-filter)Communication type(synchronous, asynchronous) 20 4 Apr 2013
  19. 19. 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) 4 Apr 2013 21
  20. 20. 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? 4 Apr 2013 22
  21. 21. Management of EFP A B component componentEndogenous EFP EFP Managem ent EFP Managem ent com ponent component management EFP Management EFP Management EFP Managem ent Component Ex ecut ion Plat form Component Ex ecut ion Platform C D component componentExogenous EFP component component management EFP Managem ent EFP Management EFP Managem ent Component Ex ecut ion Plat form Component Ex ecut ion Platform EFP Managed per collaboration EFP Managed systemwide
  22. 22. EPF – compositionsPi(C) = Pi(C1) ⊕ Pi(C2)Problems:1. Composition operators?2. Influence of external factors4 Apr 2013 24
  23. 23. 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))1. 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 4 Apr 2013 25
  24. 24. EPF – composition types (III)3 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 = components3 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 profile3 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 4 Apr 2013 26
  25. 25. Classificationsummary 4 Apr 2013 27
  26. 26. Component models evaluationsSelection 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. 4 Apr 2013 29
  27. 27. Chosen component models (25 component models)• AUTOSAR • MS COM• BIP • OpenCOM• BlueArX • OSGi• CCM • Palladio• COMDES II • PECOS• CompoNETS• • Pin EJB• Fractal • ProCom• KOALA • ROBOCOP• KobrA • RUBUS• IEC 61131 • SaveCCM• IEC 61499 • SOFA 2.0• JavaBeans 4 Apr 2013 30
  28. 28. Lifecycle tableComponent Modelling Implementation Packaging Deployment ModelsAUTOSAR N/A C Non-formal specification of container At compilation A 3-layered representation: behavior, interaction, BIP BIP Language N/A At compilation and priority BlueArX N/A C N/A At compilation Deployment Unit archive CCM N/A Language independent At run-time (JARs, DLLs)COMDES II ADL-like language C N/A At compilation Deployment Unit archiveCompoNETS Behavour modeling (Petri Nets) Language independent At run-time (JARs, DLLs) EJB N/A Java EJB-Jar files At run-time ADL-like language Java (in Julia, Aokell) Fractal (Fractal ADL, Fractal IDL), C/C++ (in Think) File system based repository At run-time Annotations (Fractlet) .Net lang. (in FracNet) KOALA ADL-like languages (IDL,CDL and DDL) C File system based repository At compilation KobrA UML Profile Language independent N/A N/A Function Block Diagram (FBD) Structured Text (ST)IEC 61131 Ladder Diagram (LD) N/A At compilation Instruction List (IL) Sequential Function Chart (SFC)IEC 61499 Function Block Diagram (FBD) Language independent N/A At compilationJavaBeans N/A Java Jar packages At compilation At compilation and at run- MS COM N/A OO languages DLL timeOpenCOM N/A OO languages DLL At run-time At run-time and at OSGi N/A Java Jar-files (bundles) compilation Palladio UML profile Java N/A At run-time PECOS ADL-like language (CoCo) C++ and Java Jar packages or DLL At compilation Pin ADL-like language (CCL) C DLL At compilation ProCom ADL-like language, timed automata C File system based repository At compilation At compilation and at run-ROBOCOP ADL-like language, resource management model C and C++ Structures in zip files time RUBUS Rubus Design Language C File system based repository At compilation SaveCCM ADL-like (SaveComp), timed automata C File system based repository At compilation SOFA 2.0 Meta-model based specification language Java Repository At run-time 4 Apr 2013 31
  29. 29. Lifecycle tableComponent Modelling Implementation Packaging Deployment Models AtAUTOSAR N/A C N/A compilation A 3-layered Source code, representation: At BIP implementation in N/A behavior, interaction compilation BIP language and priority Abstract model: Deployment Unit OMG-IDL, Language CCM archive At run-time Programming independent. (JARs, DLLs) model: CIDL ADL-like language Julia, (Fractal ADL, Fractal Aokell(Java) File system based Fractal At run-time IDL), Think(C/C++) repository Annotations (Fractlet) FracNet(.Net) ADL-like languages File system based At KOALA C (IDL,CDL and DDL) repository compilation EJB N/A Java binary code EJB-Jar files At run-time 4 Apr 2013 32
  30. 30. Constructs table - Interface Distinction InterfaceComponent Interface of Interface Levels Models type Provides / Distinctive features Language (Syntactic, Semantic, Requires Behaviour) Operation-AUTOSAR based Yes AUTOSAR Interface* C header files Syntactic Port-based Complete interfaces, Syntactic BIP Port-based No BIP Language Semantic Incomplete interfaces Behaviour BlueArX Port-based Yes N/A C Syntactic Operation- Facets and receptacles CCM based Yes CORBA IDL, Syntactic Event sinks and event CIDL Port-based sources C header files SyntacticCOMDES II Port-based Yes N/A State charts Behaviour diagrams Facets and receptaclesCompoNET Operation- based Yes CORBA IDL, CIDL, Syntactic Event sinks and event Behaviour S Port-based Petri nets sources Java EJB Operation- No N/A Programming Syntactic based Language + Annotations IDL, Fractal Operation- Component Interface, ADL, or Java or Syntactic Fractal based Yes C, Behaviour Control Interface Behavioural Protocol KOALA Operation- Yes Diversity Interface, IDL, CDL Syntactic based Optional Interface 4 Apr 2013 33
  31. 31. Constructs table – Binding & interaction Binding Type Component Interaction Styles Communication Type Models Exogenous HierarchicalAUTOSAR Request response, Synchronous, No Delegation Messages passing Asynchronous Triggering Synchronous, BIP Rendez-vous, Asynchronous No Delegation Broadcast BlueArX Pipe&filter Synchronous No Delegation CCM Request response, Synchronous, No No Triggering AsynchronousCOMDES II Pipe&filter Synchronous No NoCompoNETS Request response Synchronous, No No Asynchronous EJB Request response Synchronous, No No Asynchronous Fractal Multiple Synchronous, Yes Delegation, interaction styles Asynchronous Aggregation KOALA Request response Synchronous No Delegation, Aggregation 4 Apr 2013 34
  32. 32. EFPComponent Management of Properties Composition and Models EFP specification analysis support Endogenous per Resource usage, Timing BlueArX N/A collaboration (A) properties Exogenous system wide EJB 3.0 N/A N/A (D) Ability to add properties Exogenous per Fractal (by adding “property” N/A collaboration (C) controllers) Endogenous system wide Compile time checks of KOALA Resource usage (B) resources Endogenous per KobrA N/A N/A collaboration (A) Endogenous system wide Performance properties Palladio Performance properties (B) specification Timing properties, generic Endogenous system wide PECOS specification of other N/A (B) properties Different EFP Exogenous system wide Analytic interface, timing Pin composition theories, (D) properties example latency Timing and resources Endogenous system wide ProCom Timing and resources at design and compile (B) time 4 Apr 2013 Memory consumption, 35
  33. 33. DomainsApplications 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, …) 4 Apr 2013 36
  34. 34. Domains4 Apr 2013 37
  35. 35. 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 4 Apr 2013 38
  36. 36. Literature• Ivica Crnkovic, Séverine Sentilles, Aneta Vulgarakis, Michel Chaudron, A Classification Framework for Component Models, Software Engineering, IEEE Transactions on 37 (5), 593- 615• Ivica Crnkovic, Magnus Larsson: Classification of Quality Attributes, Architecting Dependable Systems III, 257-278 4 Apr 2013 39

×