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.

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 solutions
Many 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 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.
4 Apr 2013 6

7. Some definitions first…
2
CBS = <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 lifecycle
requirements
requirements
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 environment
2. 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 & Deployment
4 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. Interactions
Architectural 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 component
Endogenous 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 component
Exogenous 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 – compositions
Pi(C) = Pi(C1) ⊕ Pi(C2)
Problems:
1. Composition operators?
2. Influence of external factors
4 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 = components
3 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
3 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. Classification
summary
4 Apr 2013 27

26. 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.
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 table
Component
Modelling Implementation Packaging Deployment
Models
AUTOSAR 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 archive
CompoNETS 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 compilation
JavaBeans N/A Java Jar packages At compilation
At compilation and at run-
MS COM N/A OO languages DLL
time
OpenCOM 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 table
Component
Modelling Implementation Packaging Deployment
Models
At
AUTOSAR 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 Interface
Component 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 Syntactic
COMDES II Port-based Yes N/A State charts Behaviour
diagrams
Facets and receptacles
CompoNET 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 Hierarchical
AUTOSAR 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 Asynchronous
COMDES II Pipe&filter Synchronous No No
CompoNETS 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. EFP
Component 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. 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, …)
4 Apr 2013 36

34. Domains
4 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