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: http://dls.csd.auth.gr

1. A Classification Framework for
Component Models
IEEE Transaction on Software Engineering
PrePrint ISSN: 0098-5589
P P i t ISSN 0098 5589
Ivica Crnković, Séverine Sentilles, Aneta Vulgarakis, Mälardalen
University, Västerås
y
Michel R.V. Chaudron, Universiteit Leiden, Leiden
Mälardalen University, Sweden

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. 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. Different solutions
Many 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. 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. 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. Definitions:
Software Component – Component Model
Definition:
• 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. Some definitions first… Component-
based S t
b d Systems
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
p p g
2 May 11

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. 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. The Classification Framework -
Categories
• Three dimensions
– Lifecycle.
y
– Construction. EFP
– Extra-Functional
Properties.
lifecycle
construction
2-May-11 11

12. The Classification Framework -
Categories
EFP
Three 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. Component lifecycle
requirements
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. Lifecycle category
Different 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. Construction (I)
()
1. the component interface used for the interaction with other components
and external environment
2. the
2 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. 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. Binding
Horizontal
<<component>> <<component>>
Client Server
Vertical
<<component>>
Server
(delegation,agregation)
<<component>> <<component>>
Client Server
2-May-11 17

18. Binding & composition
Vertical
Composite
component
<<component>>
Server
(delegation,agregation)
<<component>> <<component>>
Client Server
2-May-11 18

19. Binding (II)
Endogenous
<<component>> <<component>>
Client Server
Exogenous
<<component>> <<component>>
<<Connector>> <<component>>
Client In Server
between Server
2-May-11 19

20. Interactions
<<component>> <<component>>
Client Server
Architectural style
(client-server, pipe-filter)
<<component>> <<component>>
A B
Communication type
(synchronous, asynchronous)
20

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. Extra-Functional
Extra Functional Properties
Component models can provide support f
C t d l id t for
1.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. Management of EFP
A B component component
Endogenous EFP EFP Management EFP Management
component component
management EFP Management EFP Management
EFP Management
Component Execution Platform
Component Execution Platform
C D component component
Exogenous 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. EPF – compositions
Pi(C) = Pi(C1)  Pi(C2)
Problems:
1. C
Composition operators? ?
2. Influence of external factors
2-May-11 24

25. EPF – composition types (II)
1. Directly composable properties. A property of an assembly i a
1 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. 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
4 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 profile
5 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. Modelling
Implementatio
n
Lifecycle
Packaging At compilation
Deployment At run-time
Classification Interface type
Operation-based
Operation based
summary 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. 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. Component models evaluations
Selection i i
S 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. 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. 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
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 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
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
2-May-11 31

32. Lifecycle table
Component
Modelling Implementation Packaging Deployment
Models
At
AUTOSAR 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. Constructs table - Interface
Distinction Interface
Component 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 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-
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. Constructs table – Binding & interaction
g
BINDING TYPE
COMPONENT INTERACTION COMMUNICATION
MODELS STYLES TYPE
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
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. EFP
Component
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. Domains
Applications 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. purpose
M
Models
General-
Specialised
x
AU
UTOSAR
R
2-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
Palladio
37

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