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

CHALMERS UNIVERSITY OF TECHNOLOGY

2014-09-29 2

2014-09-29 3

MDE CBSE

MDE+CBSE

Model-Based Engineering and Model-Driven Engineering

2014-09-29 4

Component – a part of Software Architecture

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

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.” !

Component lifecycle

2014-09-29 6

Component lifecycle

requirements

Modelling & design

implementation

packaging

deployment

Execution

Specification •  Interface •  Models •  Meta data

Code •  Source code •  Executable code •  Executable models

Storage •  Repository •  Package •  Meta data

Installed Files

Executable code

Component forms

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

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

Component models

2014-09-29 9

Many component models (with different characteristics) exist today

<<component>>

Client

<<component>>

Server

C1 wcet1 f1

A

C2 wcet2 f2

Input ports

Output ports

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

Attempt – meta component model

•  Study of existing component models

•  Answer: –  No sense to make a common meta component model

2014-09-29 11

•  AUTOSAR •  BIP •  COMDES •  CCA •  Corba CM •  EJB •  Fractal •  KOALA •  KobrA

•  MS COM •  OpenCom •  OSGi •  PIN •  PECOS •  Palladio •  ROBOCOP •  RUBUS •  SaveCCM •  SOFA 2.0

Classification

•  How to describe –  (i) Commonalities? –  (ii) Differences?

•  Approach: –  Identification of categories and their

characteristics

2014-09-29 12

Some definitions first…

2014-09-29 13

CBS = <C,B,P> –  C = {Ci} - components –  B = {Bj} - bindings –  P = system platform

–  Bindings •  Between components and the platform -> component deployment •  Between components – component binding

1

2

component component

<<platform>>

More definitions

•  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

A Component model defines standards for 1.  properties that individual components must satisfy 2.  methods for composing components.

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.

2014-09-29 15

construction

EFP

Domain A Domain B

lifecycle

Component lifecycle

2014-09-29 16

Component lifecycle

requirements

modelling

implementation

packaging

deployment

Execution Specification •  Interface •  Models •  Meta data

Code •  Source code •  Executable code •  Executable models

Storage •  Repository •  Package •  Meta data

Installed Files

Executable code

Component forms

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

Construction (I)

•  Specification –  Interface

–  Composition •  Binding •  interaction

2014-09-29 18

<<component>>

Client

<<component>>

Client

<<component>>

Server

1.  the component interface used for the interaction with other components and external environment

2.  the means of component binding 3. communication

Interface Specification Categories

•  Levels –  Syntactic –  Functional Semantics –  Behavioural

•  Specification language

•  Distinguish –  Provide –  Require

•  Interface type –  Operation-based –  Port-based

2014-09-29 19

<<component>>

Client

<<component>>

Client

<<component>>

Client

Binding

2014-09-29 20

Horizontal

<<component>>

Client

<<component>>

Server

Vertical

<<component>>

Server

<<component>>

Client

<<component>>

Server

(delegation, agregation..)

Binding vs. component composition

2014-09-29 21

Vertical

<<component>>

Server

<<component>>

Client

<<component>>

Server

Composite

component

Binding (II)

2014-09-29 22

<<component>>

Client

<<component>>

Server

Exogenous

<<component>>

Client

<<component>>

Server

<<Connector>>

In between

<<component>>

Server

Endogenous

Interactions

2014-09-29 23

Architectural style

(client-server, pipe-filter)

Communication type

(synchronous, asynchronous)

<<component>>

Client

<<component>>

Server

<<component>>

Server

<<component>>

Client

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

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

Component Execut ion Plat form

component component

EFP Management EFP Management

Component Execut ion Plat form

EFP Management

component component

Component Execut ion Plat form

component

EFP Management

EFP Management EFP Management

component

Component Execut ion Plat form

component

EFP Management EFP Management

component

EFP Managed systemwideEFP Managed per collaboration

Exogenous EFPmanagement

Endogenous EFPmanagement

A B

C D

Component Execut ion Plat form

component component

EFP Management EFP Management

Component Execut ion Plat form

EFP ManagementEFP Management

component component

Component Execut ion Plat form

component

EFP ManagementEFP Management

EFP ManagementEFP Management EFP ManagementEFP Management

component

Component Execut ion Plat form

component

EFP ManagementEFP Management EFP ManagementEFP Management

component

EFP Managed systemwideEFP Managed per collaboration

Exogenous EFPmanagement

Endogenous EFPmanagement

A B

C D

Management of EFP

2014-09-29 26

EPF – compositions

Pi(C) = Pi(C1) ⊕ Pi(C2) Problems: 1. Composition operators? 2. Influence of external factors 3. Emerging properties

2014-09-29 27

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

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

Component model

Lifecycle

Modelling

Implementation

Packaging

Deployment

At compilation

At run-time

Constructs

Interface specification

Interface type Operation-based

Port-based Distinction of Provides / Requires Interface

Language

Interface Levels

Syntax

Semantic

Behaviour Distinctive 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

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

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

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

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

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

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

thanks

2014-09-29 37

This is a pipe

René Magritte

2014-09-29 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 39

Lifecycle table Component

Models Modelling Implementation Packaging Deployment

AUTOSAR N/A C 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

Fractal ADL-like language

(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

IEC 61131 Function Block Diagram (FBD)

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

2014-09-29 40

Lifecycle table Component

Models Modelling Implementation Packaging Deployment

AUTOSAR N/A C 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

2014-09-29 41

Constructs table - Interface

Component Models

Interface type

Distinction of

Provides / Requires

Distinctive features 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!

CompoNETS

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! Yes! Component Interface,

Control Interface

IDL, Fractal ADL, or Java or

C, !Behavioural

Protocol!Syntactic!Behaviour!

KOALA! Operation-based! Yes! Diversity Interface,

Optional Interface IDL, CDL! Syntactic!

2014-09-29 42

Constructs table – Binding & interaction COMPONENT

MODELS!INTERACTION

STYLES!COMMUNICATION

TYPE!

BINDING TYPE !

EXOGENOUS! HIERARCHICAL!

AUTOSAR! Request response, Messages passing! Synchronous, Asynchronous! No! Delegation!

BIP! Triggering!Rendez-vous, Broadcast!

Synchronous, Asynchronous! No! Delegation!

BlueArX! Pipe&filter! Synchronous! No! Delegation!CCM! Request response, Triggering! Synchronous, Asynchronous! No! No!

COMDES II! Pipe&filter! Synchronous! No! No!CompoNETS! Request response! Synchronous, Asynchronous! No! No!

EJB! Request response! Synchronous, Asynchronous! No! No!

Fractal! Multiple interaction styles! Synchronous, Asynchronous! Yes! Delegation, Aggregation!KOALA! Request response! Synchronous! No! Delegation, Aggregation!

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

Robocop Endogenous system wide (B)

Memory consumption, Timing properties,

reliability, ability to add other properties

Memory consumption and timing properties at

deployment

Rubus Endogenous system wide (B) Timing Timing properties at

design time

SaveCCM Endogenous system wide (B)

Timing properties, generic specification of other

properties Timing properties at

design time

SOFA 2.0 Endogenous system wide (B) Behavioural (protocols) Composition at design

2014-09-29 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 45

Domains M

odel

s

AU

TOSA

R

BIP

Blu

eArX

CC

M C

OM

DE

S II

Com

poN

ET

S

EJB

Fr

acta

l K

OA

LA

Kob

rA

IEC

611

31

IEC

614

99

Java

Bea

sns

MS

CO

M O

penC

OM

OSG

i Pa

lladi

o

G e n e r a l -purpose! x! x! x! x! x! x! x! x! x!Specialised! x! x! x! x! x! x! x! x!

Mod

els

PEC

OS

Pin

ProC

om

R

oboc

op

RU

BU

S Sa

veC

CM

SOFA

2.0

G e n e r a l -purpose! x! x!Specialised! x! x! x! x! x!

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

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