A Classification Framework For Component Models


Published on

Professor Ivica Crnkovic gave a lecture on "A Classification Framework for Software Component Models" in the Distinguished Lecturer Series - Leon The Mathematician.

More Information available at:

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

A Classification Framework For Component Models

  1. 1. A Classification Framework for Component ModelsIEEE Transaction on Software EngineeringPrePrint ISSN: 0098-5589P P i t ISSN 0098 5589Ivica Crnković, Séverine Sentilles, Aneta Vulgarakis, MälardalenUniversity, Västerås yMichel R.V. Chaudron, Universiteit Leiden, Leiden Mälardalen University, Sweden
  2. 2. Essential principles of CB approach• C Component-Based D tB d Development l t – Build software systems from pre-existing “elements” called components – Building components that can be reused in different applications – Maintain systems by replacement of components and introducing new components into the system g p y – Separate development of components from development of systems R e q u ir e m e n ts D e s ig n S y s t e m D e v e lo p m e n t F in d I m p le m e n t a t i o n I n te g r a tio n S e le c t Test V e r if y R e q u ir e m e n ts R e le a s e R e q u ir e m e n ts R e q u ir e m e n ts S to re M a in t e n a n c e D e s ig n D e s ig n D e s ig n Im p le m e n ta tio n C om ponent Im p le m e n ta tio n Im p le m e n ta tio n A ssessm ent In t e g r a tio n In t e g r a tio n I n te g r a tio n Test Test Test R e le a s e R e le a s e C o m p o n e n t D e v e lo p m e n t R e le a s e M a in te n a n c e M a in t e n a n c e M a in te n a n c e 2-May-11 2
  3. 3. What is component?• The component case – Many definitions – Some known ones: • software component is a unit of composition with contractually specified i t f ifi d interfaces and context dependencies only. A software d t td d i l ft component can be deployed independently and is subject to composition by third parties. yp Szyperski • A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according t a composition standard ith t difi ti di to iti t d d Heineman and Councill – Intuitive perception may be quite different at different levels (model (model, implementation, run-time) 2-May-11 3
  4. 4. Different solutionsMany Component models (with many different characteristics) exist today A Input Output ports ports C1 C2 wcet1 wcet2 f1 f2 AUTOSAR MS COM BIP OpenCom COMDES OSGi PIN CCA PECOS Corba CM ROBOCOP EJBFractal RUBUS<<component>> p <<component>> KOALA SaveCCM Client Server KobrA SOFA 2.0 IdenticalItf 2-May-11 4
  5. 5. Questions– What is common to component models? p– It is possible to identify common principles and common features? f t ?– Is it possible to utilize/instantiate these principles for particular component models in particular domains? 2-May-11 ICATSarajevo - 2007-10-29 5
  6. 6. Goal• A classification framework for component models – Identify characteristics and categorize them – Illustrate its use by providing a survey of a number of component models 2-May-11 6
  7. 7. Definitions: Software Component – Component ModelDefinition:• A Software Component is a software building block that conforms to a component model. f t t d l• AC Component Model defines standards for f f – (i) properties that individual components must satisfy and – (ii) methods, and possibly mechanisms, for composing components methods mechanisms components. 2-May-11 7
  8. 8. Some definitions first… Component- based S t b d Systems 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 p p g 2 May 11
  9. 9. More definitions - Components• Component Specification C={Properties} C = <{Interfaces} {ExtraFunctionalProperties}> <{Interfaces}, • Component compliance to component model • Component Composition: • Interface composition (BINDING) : I(C) = I(C1)  I(C2) • Property composition: Pi(C) = Pi(C1)  Pi(C2) 2-May-11 9
  10. 10. Classification• How to describe – (i) Commonalities? – (ii) Diff Differences? ?• Different approaches – Specification of Meta model – List of characteristics – Identification of categories and their characteristics 2-May-11 10
  11. 11. The Classification Framework - Categories• Three dimensions – Lifecycle. y – Construction. EFP – Extra-Functional Properties. lifecycle construction 2-May-11 11
  12. 12. The Classification Framework - Categories EFPThree dimensions• 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 lifecycle other components and external environment, and (ii) the means of component binding (initiate communication )a d )and (iii) communication.• Extra-Functional Properties. The extra-functional properties di ti dimension id tifi specifications and support i identifies ifi ti d t that includes the provision of property values and means for their composition. Domain A Domain B 2-May-11 12
  13. 13. Component lifecyclerequirements modelling Component lifecycle Component lifecycle implementation packaging Component forms deployment Execution Specification Code Storage • Interface • Source code • Repository •M d l Models •EExecutable code t bl d •P k Package Installed I t ll d Executable E t bl • Meta data • Executable models • Meta data Files code 2-May-11 ICAT Sarajevo - 2007-10-29 13
  14. 14. Lifecycle categoryDifferent 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 code, generation of a binary (executable) code.• Storage & Packaging Since components can be developed Packaging. 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 p p phase. 2-May-11 14
  15. 15. Construction (I) ()1. the component interface used for the interaction with other components and external environment2. the2 th means of component binding (i iti t communication) f t bi di (initiate i ti )3. communication. <<component>> Client• Specification of C= <{I}{P}> – Interface – Composition <<component>> <<component>> Client Server • Binding • i t interaction ti I1 I2 2-May-11 15
  16. 16. Interface Specification Categories<<component>> • Distinquish Client – Provide – Require • Interface type<<component>> – Operation based Operation-based Client – Port-based<<component>> Client • Specification language • L Levels l – - Syntactic - Functional Semantic - Behavioral 16
  17. 17. Binding Horizontal<<component>> <<component>> Client Server Vertical <<component>> Server (delegation,agregation) <<component>> <<component>> Client Server 2-May-11 17
  18. 18. Binding & composition Vertical Composite component <<component>> Server (delegation,agregation) <<component>> <<component>> Client Server 2-May-11 18
  19. 19. Binding (II) Endogenous<<component>> <<component>> Client Server Exogenous<<component>> <<component>> <<Connector>> <<component>> Client In Server between Server 2-May-11 19
  20. 20. Interactions <<component>> <<component>> Client ServerArchitectural style(client-server, pipe-filter) <<component>> <<component>> A BCommunication type(synchronous, asynchronous) 20
  21. 21. Construction classification• Interface – operation-based/port-based – provides/requires – The interface level (syntactic, semantic, behaviour) – distinctive features• Binding – Horisontal, Vertical – Endogenous, Exogenous• I t Interaction ti – Architectural Style – Communication type (synchronous/asynchronous) 2-May-11 21
  22. 22. Extra-Functional Extra Functional PropertiesComponent models can provide support fC t d l id t for1.Management of extra-functional properties – Does a component provide any support for extra-functional properties? – What are the mechanisms? – Which properties are managed?1.Composition of extra-functional properties – P(C1 o C2) = P(C1) o P(C2) – What kind of composition is supported? – Which properties? 2-May-11 22
  23. 23. Management of EFP A B component componentEndogenous EFP EFP Management EFP Management component component management EFP Management EFP Management EFP Management Component Execution Platform Component Execution Platform C D component componentExogenous EFP component component g management EFP Management EFP Management EFP Management Component Execution Platform Component Execution Platform EFP Managed per collaboration EFP Managed systemwide
  24. 24. EPF – compositionsPi(C) = Pi(C1)  Pi(C2)Problems:1. C Composition operators? ?2. Influence of external factors2-May-11 24
  25. 25. EPF – composition types (II)1. Directly composable properties. A property of an assembly i a1 Di l bl i f bl is 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 so a e architecture. software a c ec u e – P(A) = f(SA, …P(Ci)…), i=1…n – SA = software architecture ft hit t 2-May-11 25
  26. 26. 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 = components4 Usage-depended properties. A property of an assembly is properties determined by its usage profile. – P(A,U) = f(SA, …Pi(Cj,U)…), i=1…m, j=1…n – U = Usage profile5 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 2-May-11 26
  27. 27. Modelling Implementatio n Lifecycle Packaging At compilation Deployment At run-timeClassification Interface type Operation-based Operation basedsummary Distinction of Provides / Port-based Requires Interface Interface Syntax y specification Language L Interface Levels Semantic Distinctive Behaviour features Component model Interaction Constructs Interaction Styles Synchronous Communication Type Asynchronous Exogenous / Endogenous Binding type Vertical Endogenous Collaborative Endogenous Management Systemwide Exogenous Extra functional Specification Collaborative properties Exogenous Composition Systemwide 2-May-11 27
  28. 28. Illustration of the Classification Framework use• Survey of 25 component models• Selection of documentation for each component model – Satisfies criteria – Disposability the definition (Interfaces, composition) – S Some points in the table have been subject our interpretation. 2-May-11 28
  29. 29. Component models evaluationsSelection i iS l i criteria:1. A component model includes a component definition;2.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. 2-May-11 29
  30. 30. Chosen component models p (25 component models)• AUTOSAR • MS COM• BIP • OpenCOM• BlueArX • OSGi• CCM • Palladio• COMDES II • PECOS• CompoNETS• EJB • Pin• Fractal • ProCom• KOALA • ROBOCOP• KobrA • RUBUS• IEC 61131 • SaveCCM• IEC 61499 • SOFA 2.0• JavaBeans 2-May-11 30
  31. 31. 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 p y 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 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 2-May-11 31
  32. 32. Lifecycle tableComponent Modelling Implementation Packaging Deployment Models AtAUTOSAR N/A C N/A compilation A 3-layered Source code, , representation: t ti 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, (JARs DLLs) model: CIDL ADL-like language Julia, (Fractal ADL, Fractal Aokell(Java) File system based Fractal At run time run-time IDL), IDL) Think(C/C++) Thi k(C/C ) repository i Annotations (Fractlet) FracNet(.Net) ADL-like languages File system based At KOALA C (IDL,CDL d (IDL CDL and DDL) repository it compilation il ti EJB N/A Java binary code EJB-Jar files At run-time 2-May-11 32
  33. 33. Constructs table - Interface Distinction InterfaceComponent Interface of Interface Levels Models type Provides / Distinctive features Language (Syntactic, Semantic, Requires Behaviour) Operation 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- O ti No N/A Programming P i 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 2-May-11 33
  34. 34. Constructs table – Binding & interaction g BINDING TYPE COMPONENT INTERACTION COMMUNICATION MODELS STYLES TYPE 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 F t l Multiple Synchronous, Synchronous Yes Y Delegation, Delegation interaction styles Asynchronous Aggregation KOALA Request response Synchronous No Delegation, Aggregation 2-May-11 34
  35. 35. EFPComponent p Management of g Properties p Composition and p 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” 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 2-May-11 Memory consumption, Memory consumption 35
  36. 36. DomainsApplications and business domain of the Component Models• General-purpose: – Basic mechanisms for the production and the composition of componentst – Provide no guidance, nor support for any specific architecture.• Specialised: – Specific application domains (i.e. consumer electronics, automotive, …) 2-May-11 36
  37. 37. purpose M Models General- Specialised x AU UTOSAR R2-May-11 x BIP x B BlueArX purpose M Models General- x CCM Specialised x CO OMDES II I x x PE ECOS Com mpoNET TS x x Pin EJB x x Pr roCom F Fractal x x R Robocop K KOALA x x Domains RU UBUS KobrA x x Sav veCCM IE 61131 EC x x SO 2.0 OFA IE 61499 EC 9 x Ja avaBeasns s x M MS COM x Op penCOM M x OSGi x P Palladio37
  38. 38. 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. style – Composition of extra-functional properties is rather scarce. – Behaviour & Semantic rarely supported – Al Almost never repository t it• Summary – The classification framework helps in understanding component models principles – Enables comparison – Can be used as a check-list when development new component models check list 2-May-11 38
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.