This document discusses the differences between component-based engineering (CBSE) and model-driven engineering (MDE). It notes that while CBSE focuses on source code and executable code reuse through composition, MDE takes a more top-down approach. The document argues that MDE and CBSE can be combined, with MDE helping to generate connectors/adapters, transform models, and evolve models in CBSE. CBSE can also benefit MDE by providing runtime feedback and reusing existing component technologies.

1. Component-Based and Model-
Driven Engineering:
what is the difference?
A CBSE perspective
Ivica Crnkovic
http://ivica-crnkovic.net, crnkovic@chalmers.se,
Chalmers University of Technology & University of Gothenburg, Sweden
Mälardalen University, Västerås, Sweden
University of Osijek, Croatia

2. CHALMERS UNIVERSITY
OF TECHNOLOGY
2014-09-29 2

3. MDE CBSE
MDE+CBSE
2014-09-29 3

4. Model-Based Engineering
and Model-Driven Engineering
2014-09-29 4

5. Component – a part of Software Architecture
The software architecture of a program or computing system is the structure
or structures of the system, which comprise software components [and
connectors], the externally visible properties of those components [and
connectors] and the relationships among them.” !
Bass L., Clements P., and Kazman R., Software Architecture in Practice
Palladio Component Model (PCM): http://www.palladio-simulator.com/science/palladio_component_model/
2014-09-29 5

6. Component lifecycle
Component lifecycle
requirements
Modelling
& design
implementation
packaging
deployment
Execution
Component forms
Specification
• Interface
• Models
• Meta data
Code
• Source code
• Executable code
• Executable models
Storage
• Repository
• Package
• Meta data
Installed
Files
Executable
code
2014-09-29 6

7. What is component?
• Some famous definitions
• 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
2014-09-29 7

8. Software Component vs. Component Model
• 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.
Ivica Crnkovic, Severine Sentilles, Vulgarakis Aneta, and Michel R. V. Chaudron,
A Classification Framework for Software Component Models. IEEE Trans. Softw, 2011
2014-09-29 8

9. Component models
Many component models (with different characteristics)
exist today
C1
wcet1
f1
A
<<component>>
Client
C2
wcet2
f2
Output
ports
<<component>>
Server
Input
ports
2014-09-29 9

10. 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?
– (Can we define a (meta)meta component-model?)
2014-09-29 10

11. Attempt – meta component model
• Study of existing component models
• Answer:
• AUTOSAR
• BIP
• COMDES
• CCA
• Corba CM
• EJB
• Fractal
• KOALA
• KobrA
• MS COM
• OpenCom
• OSGi
• PIN
• PECOS
• Palladio
• ROBOCOP
• RUBUS
• SaveCCM
• SOFA 2.0
– No sense to make a common meta component model
2014-09-29 11

12. Classification
• How to describe
– (i) Commonalities?
– (ii) Differences?
• Approach:
– Identification of categories and their
characteristics
2014-09-29 12

13. Some definitions first…
CBS = <C,B,P>
– C = {Ci} - components
– B = {Bj} - bindings
– P = system platform
– Bindings
component component
1
2
<<platform>>
• Between components and the platform -> component deployment
• Between components – component binding
2014-09-29 13

14. More definitions
A Component model defines standards for
1. properties that individual components must satisfy
2. methods for composing components.
• Component Specification
C = <I,P>; I={interfaces}, P={Properties}
• Component compliance: Components conform to a component model
• Component Composition:
• Interface composition (BINDING) : I(C) = I(C1) ⊕ I(C2)
• Property composition: Pi(C) = Pi(C1) ⊕ Pi(C2)
2014-09-29 14

15. The Classification Framework -
Categories
Dimensions
• Lifecycle.
– The support provided by a component model, in
certain points of a lifecycle of components or
component-based systems.
• Construction.
– (i) the component interface used for the interaction
with other components and external environment
(ii) the means of component binding (initiate
communication) (iii) communication.
• Extra-Functional Properties.
– specifications and support that includes the
provision of property values and means for their
composition.
EFP
construction
Domain A Domain B
lifecycle
2014-09-29 15

16. Component lifecycle
Component lifecycle
requirements
modelling
implementation
packaging
deployment
Execution
Component forms
Specification
• Interface
• Models
• Meta data
Code
• Source code
• Executable code
• Executable models
Storage
• Repository
• Package
• Meta data
Installed
Files
Executable
code
2014-09-29 16

17. 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
generation of a binary (executable) code.
• Storage & Packaging. Since components can be developed
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 phase.
2014-09-29 17

18. Construction (I)
1. the component interface used for the interaction with other components
and external environment
2. the means of component binding
3. communication
• Specification
– Interface
– Composition
• Binding
• interaction
<<component>>
Client
<<component>>
Client
<<component>>
Server
2014-09-29 18

19. Interface Specification
Categories
• Levels
– Syntactic
– Functional Semantics
– Behavioural
• Specification language
• Distinguish
– Provide
– Require
• Interface type
– Operation-based
– Port-based
<<component>>
Client
<<component>>
Client
<<component>>
Client
2014-09-29 19

20. Binding
Horizontal
<<component>>
Client
<<component>>
Server
Vertical
<<component>>
Server
<<component>>
Client
<<component>>
Server
(delegation, agregation..)
2014-09-29 20

21. Binding vs. component composition
Vertical
<<component>>
Server
Composite
component
<<component>>
Client
<<component>>
Server
2014-09-29 21

22. Binding (II)
Endogenous
<<component>>
Client
<<component>>
Server
Exogenous
<<component>>
Client
<<component>>
<<Connector>>
In Server
between
<<component>>
Server
2014-09-29 22

23. Interactions
Architectural style
(client-server, pipe-filter)
Communication type
(synchronous, asynchronous)
<<component>>
Client
<<component>>
Server
<<component>>
Server
<<component>>
Client
2014-09-29 23

24. 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)
2014-09-29 24

25. Extra-Functional Properties
• Management of extra-functional properties
– Does a component provide any support for extra-functional
property specification?
– What are the mechanisms?
– Which properties are managed?
• Composition of extra-functional properties
Pi(C) = Pi(C1) ⊕ Pi(C2)
– What kind of composition is supported?
– Which properties?
2014-09-29 25

26. Management of EFP
component
component
EFP Management EFP Management
component component
EFP Management EFP Management
Component Execution Platform
component
component
EFP Management EFP Management
EFP Management
Component Execution Platform
component component
EFP Management
Component Execution Platform
Component Execution Platform
EFP Managed per collaboration EFP Managed systemwide
Endogenous EFP
management
Exogenous EFP
management
A B
C D
2014-09-29 26

27. EPF – compositions
Pi(C) = Pi(C1) ⊕ Pi(C2)
Problems:
1. Composition operators?
2. Influence of external factors
3. Emerging properties
2014-09-29 27

28. 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))
2. 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
2014-09-29 28

29. EPF – composition types (III)
3 Emerging (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
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
2014-09-29 29

30. Component
model
Lifecycle
Modelling
Implementation
Packaging
Deployment
At compilation
At run-time
Constructs
Interface
specification
Interface type
Operation-based
Distinction of Port-based
Provides /
Requires
Interface
Syntax
Language
Interface Levels
Semantic
Distinctive Behaviour
features
Interaction
Interaction
Styles
Communication
Type
Synchronous
Asynchronous
Binding type
Exogenous /
Endogenous
Vertical
Extra
functional
properties
Management
Endogenous
Collaborative
Endogenous
Systemwide
Exogenous
Collaborative
Exogenous
Systemwide
Specification
Composition
Classification
summary
2014-09-29 30

31. Challenge to the audience
• Challenge 1:
– Can we, based on the classification, define a
metamodel of component models (“component
metamodel”)?
• Challenge 2:
– Practice of today: Component models are built in
DSLs
– Can we (if 1 solved) provide a transformation from
component metamodel to a DSL component
model?
2014-09-29 31

32. 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)
– Some points in the table have been subject our interpretation.
2014-09-29 32

33. Which models are component
models?
Selection criteria:
1. A component model includes a component definition;
2. Component functional properties are unambiguously specified by
component interface;
3. A component model provides rules for component interoperability;
4. A component interface is used in the interoperability mechanisms;
5. A component is an executable piece of software;
6. The component model either directly specifies the form of the
executable unit or unambiguously transform its model to the
executable code.
7. The component model unambiguously defines (or generate)
component binding and interaction execution
2014-09-29 33

34. MDD vs. CBSE (1)
• CBSE characteristics
– a more specific understanding of component
models
– Reusability - reuse any assent in component
lifecycle
• Focus on source code reuse or executable code
reuse (better reuse of assets from later phase of
development cycle)
– Bottom-up (composition) rather than top-down
approach
2014-09-29 34

35. MDD vs. CBSE (2)
• Need for MDD in CBSE
– Connectors/adapters/wrappers generation
– Transformation and integration of different
models (for functional and extra-functional
properties)
– Executable/source code/ generation from
models for different platforms/technologies
– Model evolution (models consistency
checking)
2014-09-29 35

36. MDD vs. CBSE (3)
• Need for CBSE in MDD
– RunTime feedback
• Measurement of extra-functional properties and
feedback information to the model
– Wrapping COTS and existing components
and providing seamless integration on the
model level
– Use some of the existing technologies in the
code generation
– Use results about composition reasoning
2014-09-29 36

37. thanks
This is a pipe
René Magritte
2014-09-29 37

38. Chosen component models
(25 component models)
• AUTOSAR
• BIP
• BlueArX
• CCM
• COMDES II
• CompoNETS
• EJB
• Fractal
• KOALA
• KobrA
• IEC 61131
• IEC 61499
• JavaBeans
• MS COM
• OpenCOM
• OSGi
• Palladio
• PECOS
• Pin
• ProCom
• ROBOCOP
• RUBUS
• SaveCCM
• SOFA 2.0
2014-09-29 38

39. Lifecycle table
Component
Models
Modelling
Implementation
Packaging
Deployment
AUTOSAR
N/A
C
2014-09-29 39
Non-formal specification of container! At compilation
BIP
A 3-layered representation: behavior, interaction,
and priority
BIP Language
N/A
At compilation
BlueArX
N/A
C
N/A
At compilation
CCM
N/A
Language independent
Deployment Unit archive
(JARs, DLLs)! At run-time!
COMDES II
ADL-like language
C
N/A
At compilation!
CompoNETS
Behavour modeling (Petri Nets)
Language independent
Deployment Unit archive
(JARs, DLLs)
At run-time!
EJB
N/A
Java
EJB-Jar files
At run-time
ADL-like language
Fractal
(Fractal ADL, Fractal IDL),
Annotations (Fractlet)
Java (in Julia, Aokell)
C/C++ (in Think)
.Net lang. (in FracNet)
File system based repository
At run-time
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)
IEC 61131
Ladder Diagram (LD)
Sequential Function Chart (SFC)
Structured Text (ST)
Instruction List (IL)
N/A
At compilation
IEC 61499
Function Block Diagram (FBD)
Language independent
N/A
At compilation
JavaBeans
N/A
Java
Jar packages
At compilation
MS COM
N/A
OO languages
DLL
At compilation and at run-time
OpenCOM
N/A
OO languages
DLL
At run-time
OSGi
N/A
Java
Jar-files (bundles)
At run-time and at
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
ROBOCOP
ADL-like language, resource management model
C and C++
Structures in zip files
At compilation and at run-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

40. Lifecycle table
Component
Models Modelling Implementation Packaging Deployment
AUTOSAR N/A C
2014-09-29 40
N/A At
compilation
BIP
A 3-layered
representation:
behavior, interaction
and priority
Source code,
implementation in
BIP language
N/A At
compilation
CCM
Abstract model:
OMG-IDL,
Programming
model: CIDL
Language
independent.
Deployment Unit
archive
(JARs, DLLs ) At run-time
Fractal
ADL-like language
(Fractal ADL, Fractal
IDL),
Annotations (Fractlet)
Julia,
Aokell(Java)
Think(C/C++)
FracNet(.Net)
File system based
repository At run-time
KOALA ADL-like languages
(IDL,CDL and DDL) C File system based
repository
At
compilation
EJB N/A Java binary code EJB-Jar files At run-time

41. Constructs table - Interface
Component
Models
Interface
type
Distinction
of
Provides /
Requires
Distinctive features
! Yes! Component Interface,
! Yes! Diversity Interface,
2014-09-29 41
Interface
Language
Interface
Levels
(Syntactic,
Semantic,
Behaviour)!
AUTOSAR!
Operation-based
Port-based!
Yes! AUTOSAR Interface*! C header files! Syntactic!
BIP! Port-based! No! Complete interfaces,
Incomplete interfaces
BIP Language!
Syntactic! Semantic!
Behaviour!
BlueArX! Port-based! Yes! N/A
C! Syntactic!
CCM!
Operation-based
Port-based!
Yes!
Facets and receptacles
Event sinks and event
sources
CORBA IDL,
CIDL! Syntactic!
COMDES II
Port-based! Yes! N/A
C header files! State charts
diagrams!
Syntactic! Behaviour!
CompoNET
S
Operation-based
Port-based!
Yes!
Facets and receptacles
Event sinks and event
sources
CORBA IDL,
CIDL,
Petri nets!
Syntactic! Behaviour!
EJB! Operation-based
! No! N/A!
Java
Programming
Language +
Annotations!
Syntactic!
Fractal! Operation-based
Control Interface
IDL, Fractal
ADL, or Java or
C, ! Behavioural
Protocol!
Syntactic! Behaviour!
KOALA! Operation-based
Optional Interface
IDL, CDL! Syntactic!

42. Constructs table – Binding & interaction
COMPONENT
MODELS!
INTERACTION
STYLES!
COMMUNICATION
TYPE!
2014-09-29 42
BINDING TYPE !
EXOGENOUS! HIERARCHICAL!
AUTOSAR! RMeeqsuseasgte rse sppaossnisneg,!
ASysnycnhcrhornoonuosu,s ! No! Delegation!
BIP!
ReTnrdigegze-vrionug!s,
Broadcast!
ASysnycnhcrhornoonuosu,s ! No! Delegation!
BlueArX! Pipe&filter! Synchronous! No! Delegation!
CCM! RequTerisgt greersipnognse,
!ASysnycnhcrhornoonuosu,s ! No! No!
COMDES II! Pipe&filter! Synchronous! No! No!
CompoNETS! Request response! ASysnycnhcrhornoonuosu,s! No! No!
EJB! Request response! ASysnycnhcrhornoonuosu,s! No! No!
Fractal! interMacutlitoinp lset yles!
ASysnycnhcrhornoonuosu,s ! Yes! ADgelgergeagtaiotino,n !
KOALA! Request response! Synchronous! No! ADgelgergeagtaiotino,n !

43. EFP
Component
Models
Management of
EFP
Properties
specification
Composition and
analysis support
BlueArX
Endogenous per
collaboration (A)
Resource usage, Timing
properties
N/A
EJB 3.0
Exogenous system wide
(D)
N/A
N/A
Fractal
Exogenous per
collaboration (C)
Ability to add properties (by
adding “property”
controllers)
N/A
KOALA
Endogenous system wide
(B)
Resource usage
Compile time checks of
resources
KobrA
Endogenous per
collaboration (A)
N/A
N/A
Palladio
Endogenous system wide
(B)
Performance properties
specification
Performance properties
PECOS
Endogenous system wide
(B)
Timing properties, generic
specification of other
properties
N/A
Pin
Exogenous system wide
(D)
Analytic interface, timing
properties
Different EFP
composition theories,
example latency
ProCom
Endogenous system wide
(B)
Timing and resources
Timing and resources
at design and compile
time
2014-09-29 43
Robocop
Endogenous system wide
(B)
Memory consumption,
Timing properties,
reliability, ability to add
Memory consumption
and timing properties at

44. 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, …)
2014-09-29 44

45. Domains
Models
AUTOSAR
BIP
BlueArX
CCM
COMDES II
CompoNETS
EJB
Fractal
KOALA
KobrA
IEC 61131
IEC 61499
JavaBeasns
MS COM
OpenCOM
OSGi
Palladio
pGuerpnoseer a l - ! x! x! x! x! x! x! x! x! x!
Specialised! x! x! x! x! x! x! x! x!
Models
PECOS
Pin
ProCom
Robocop
RUBUS
SaveCCM
SOFA 2.0
pGuerpnoseer a l - ! x! x!
Specialised! x! x! x! x! x!
2014-09-29 45

46. 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
2014-09-29 46

47. Literature
• Ivica Crnkovic, Séverine Sentilles, Aneta Vulgarakis,
Michel Chaudron,
A Classification Framework for Component Models
• Ivica Crnkovic, Magnus Larsson:
Classification of Quality Attributes
2014-09-29 47