Your SlideShare is downloading. ×
0
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
A classification framework for component models
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A classification framework for component models

370

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 …

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
370
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Emphasize on a more precise detail
  • We want to revisite the definitions… cpt more general… cm more focus and new Not any properties (not maintability, usability…)
  • Shall I also put the disctinctive features
  • Shall I also put the disctinctive features
  • Shall I also put the disctinctive features
  • Shall I also put the disctinctive features
  • Shall I also put the disctinctive features
  • Most of cm support implementation and deployment (how the cpt becomes part of system )
  • Sofa Composition of protocols Saveccm composition of rt at design time
  • How OSGI can be general and specialised ?
  • refine
  • Transcript

    • 1. A Classification Framework for Component Models Ivica Crnkovic, Ivica.crnkovic@mdh.se Mälardalen University, Sweden
    • 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. 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. 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. 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. 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. 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. 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. 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. The Classification Framework - Categories• Three dimensions – Lifecycle. – Construction. EFP – Extra-Functional Properties. lifecycle construction 4 Apr 2013 10
    • 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. 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. 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. Binding & Deployment4 Apr 2013 ICAT Sarajevo - 2007-10-29 16
    • 15. Binding Horizontal <<component>> <<component>> Client Server Vertical <<component>> Server (delegation,agregation) <<component>> <<component>> Client Server 4 Apr 2013 17
    • 16. Binding & composition Vertical Composite component <<component>> Server (delegation,agregation) <<component>> <<component>> Client Server 4 Apr 2013 18
    • 17. Binding (II) Endogenous<<component>> <<component>> Client Server Exogenous<<component>> <<component>> <<Connector>> <<component>> Client In Server between Server 4 Apr 2013 19
    • 18. InteractionsArchitectural style <<component>> <<component>> Client Server(client-server, pipe-filter)Communication type(synchronous, asynchronous) 20 4 Apr 2013
    • 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. 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. 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. EPF – compositionsPi(C) = Pi(C1) ⊕ Pi(C2)Problems:1. Composition operators?2. Influence of external factors4 Apr 2013 24
    • 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. 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. Classificationsummary 4 Apr 2013 27
    • 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. 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. 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. 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. 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. 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. 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. 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. Domains4 Apr 2013 37
    • 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. 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

    ×