Validating TOSCA Application Topologies

Antonio Brogi, Antonio Di Tommaso and Jacopo Soldani

Department of Computer Science, University of Pisa, Pisa, Italy

Keywords:

TOSCA, Validation, Cloud Application Topologies.

Abstract:

The Topology and Orchestration Speciﬁcation for Cloud Applications (TOSCA) is a standardised metamodel

that permits specifying cloud applications, and automating their deployment and management. TOSCA per-

mits describing the structure of an application as a topology graph, which can then be exploited by TOSCA-

compliant cloud platforms to automate the deployment of the components forming an application. In this

paper we formalise the conditions that must hold for checking the validity of TOSCA application topologies,

and we present an open-source prototype of validator (called SOMMELIER) that implements such conditions.

1 INTRODUCTION

Cloud computing is revolutionising IT by enabling

on-demand network access to shared pools of conﬁg-

urable computing resources. Current cloud technolo-

gies however suffer from a lack of standardisation,

with different providers offering similar resources in

a different manner (Armbrust et al., 2010). Hence,

how to deploy and ﬂexibly manage complex compos-

ite applications over heterogeneous cloud platforms is

one of the main challenges that have emerged after the

cloud revolution (Brogi et al., 2014a).

OASIS recently released a YAML

version (OA-

SIS, 2016) of TOSCA, the Topology and Orches-

tration Speciﬁcation for Cloud Applications. The

TOSCA Simple Proﬁle in YAML provides a YAML-

based modelling language that permits specifying

portable cloud applications, and to automate their de-

ployment and management.

TOSCA permits describing the structure of a

cloud application as a typed, directed topology graph.

The nodes in a topology graph represent application

components (e.g., a web-based frontend, a web server,

a backend database, a database management system),

and each of them can be also be associated with the re-

quirements, capabilities, and management operations

of the corresponding component. The arcs in a topol-

ogy graph instead model relationships among appli-

cation components (e.g., the frontend is deployed on

the server and connected to the database, which is in

turn hosted on the databased management system) by

associating the requirements of a node with capabili-

ties featured by other nodes.

YAML Ain’t Markup Language (http://yaml.org).

TOSCA applications can be automatically de-

ployed on TOSCA-compliant cloud platforms (Binz

et al., 2013). The processing of a TOSCA applica-

tion is declarative, and strictly depends on the inter-

node relationships in its topology: Initially, (i) all

nodes without requirements on other nodes are de-

ployed. Then, (ii) the nodes whose requirements are

actually satisﬁed (by capabilities offered by the nodes

that have been deployed) are deployed, and their out-

going relationships are properly processed. Step (ii)

is repeated until all the nodes in the application topol-

ogy have been deployed (OASIS, 2013b).

Consider, for instance, the application topology in

Fig. 1. The topology nodes are a frontend, a server, a

database, and a database management systems, while

its relationships specify that the frontend must be de-

ployed on the server and connected to the database,

and that the database must be hosted on the man-

agement system. Step (i) would result in ﬁrst de-

ploying the server and the management system. Step

(ii) would then result in inserting the database among

those hosted by the management system. Finally, step

(ii) would be repeated to deploy the frontend on the

server, and to set up the connection from the frontend

to the database.

The above (toy) example clearly illustrates how

the deployment of a TOSCA application strictly de-

Figure 1: Example of application topology.

Brogi, A., Tommaso, A. and Soldani, J.

Validating TOSCA Application Topologies.

DOI: 10.5220/0006244006670678

In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 667-678

ISBN: 978-989-758-210-3

667

pends on the inter-node relationships in its topology.

This is even more evident if we consider that the pro-

cessing of TOSCA nodes and relationships relies on

the conﬁguration information that they specify, and

which is contextualised with constraints on how to in-

terconnect them (OASIS, 2013b). It is hence impor-

tant to ensure — at design time — that application

topologies are valid, and in particular that the rela-

tionships interconnecting the nodes in such topologies

have been properly speciﬁed.

In this perspective, the main contributions in this

paper are twofold:

(i) We formalise the conditions that must hold

to have valid TOSCA application topologies.

More precisely, since TOSCA permits specify-

ing constraints on how to interconnect nodes

(e.g., which capabilities can satisfy a require-

ment, or which types of relationships can be

used to interconnect them), we systematically

map such constraints into conditions that must

hold to ensure the validity of a TOSCA applica-

tion topology.

(ii) We present SOMMELIER, which is a prototype

of validator for TOSCA application topologies.

SOMMELIER checks whether the topology of a

TOSCA application satisﬁes all interconnection

constraints, and, if this is not the case, it displays

all violations.

Notice that SOMMELIER can be fruitfully exploited

by TOSCA application developers to automatically

validate the topologies of their applications at design

time, as they currently have to do it manually.

It is also worth highlighting that SOMME-

LIER fully integrates with the OpenStack TOSCA

parser (OpenStack, 2016). As both SOMMELIER and

the OpenStack TOSCA parser are open-source, they

can lay the foundations for an open-source toolset for

supporting TOSCA application developers from the

design time till the run time (Brogi et al., 2014b).

In this perspective, the output of SOMMELIER can

be fruitfully exploited for improving the function-

alities of TOSCA editors (e.g., the graphical editor

in Alien4Cloud (Alien4Cloud, 2016)). SOMMELIER

can indeed be useful for validating TOSCA applica-

tion topologies while they are being developed.

The rest of this paper is organised as follows.

In Sect. 2 we provide the necessary background on

TOSCA, and we discuss related work. In Sect. 3 we

formalise the conditions for validating TOSCA ap-

plication topologies by systematically analysing the

component interconnection constraints that can be ex-

pressed in TOSCA. In Sect. 4 we present SOMME-

LIER, and we show how it permits validating TOSCA

application topologies. Finally, in Sect. 5 we draw

some concluding remarks.

2 BACKGROUND AND RELATED

WORK

2.1 Background: TOSCA

TOSCA (OASIS, 2016) is an OASIS standard whose

main goals are to enable (i) the speciﬁcation of

portable cloud applications and (ii) the automation

of their deployment and management. TOSCA pro-

vides a YAML-based, machine-readable modelling

language that permits describing cloud applications.

The obtained application speciﬁcations can then be

processed to automate the deployment and manage-

ment of the speciﬁed applications.

TOSCA permits specifying a cloud application

as a service template, which is in turn composed

by a topology template, and by the types needed

to build such a topology template (Fig. 2). The

topology template is a typed directed graph that

describes the topological structure of the compos-

ite cloud application. Its nodes (called node tem-

plates) model the application components, while its

edges (called relationship templates) model the

relationships occurring among such components. The

topology template may also contain typed poli-

cies, which permit specifying non-functional infor-

mation about the node templates they target.

The node templates and relationship tem-

plates are typed by means of node types and re-

lationship types, respectively. A node type de-

ﬁnes the observable properties and attributes

of a component, its possible requirements, the

Figure 2: TOSCA service template (OASIS, 2016).

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

668

capabilities it may offer to satisfy other compo-

nents’ requirements, and the interfaces through

which it offers its management operations. Capabili-

ties are also typed (by means of capability types),

to permit specifying their properties, attributes,

and valid source types (viz., the node types that

can be satisﬁed by such capabilities).

A relationship type instead describes the observ-

able properties and attributes of a relationship

occurring between two application components, and

the interfaces through which it offers its manage-

ment operations. A relationship type can also put

constraints on its valid target types (viz., the ca-

pability types that can be targeted by a relationship

whose type is that under deﬁnition).

TOSCA type system supports inheritance. A node

type can be deﬁned by extending another, thus per-

mitting the former to inherit the latter’s properties,

attributes, requirements, interfaces, and operations.

Analogously, a relationship type or a capability type

can extend another to inherit all its features.

TOSCA also prescribes the format (called CSAR

— Cloud Service ARchive) to archive application

speciﬁcations along with the installable and exe-

cutable ﬁles needed to properly instantiate the spec-

iﬁed applications. This is because the modelling

language illustrated above only allows developers to

specify the application topology and its management

and to give it in a .tosca document. Such document

must be packaged together with the artefacts imple-

menting its components so as to make all such arte-

facts available to the execution environment

2.2 Related Work

Software systems are assuming a key role in everyday

life, and guaranteeing that such systems satisfy their

functional and non-functional requirements is becom-

ing imperative and increasingly difﬁcult (Marchetti,

2014). Validation techniques are hence crucial, as

their purpose is precisely to evaluate software sys-

tems and to determine whether they satisfy speciﬁed

requirements (Geraci, 1991).

The need for validation is also recognised by

TOSCA (OASIS, 2016). Indeed, TOSCA permits

specifying constraints that must be satisﬁed while

interconnecting application components to form the

topology of a cloud application. However, the cur-

rent support for checking such constraints is limited,

which makes the process of validating TOSCA appli-

cations cumbersome and time-consuming.

A more detailed, self-contained introduction to

TOSCA can be found in (Brogi et al., 2014b).

The OpenStack TOSCA Parser (OpenStack,

2016) can be used to check whether TOSCA applica-

tion speciﬁcations are syntactically correct. More pre-

cisely, the OpenStack TOSCA Parser permits check-

ing that all TOSCA elements have been speciﬁed in

the proper section (e.g., node types in the node ty-

pes section, node templates in the node templates

section, etc.), and that node templates and relation-

ship templates are speciﬁed coherently with the struc-

ture given by the corresponding types (e.g., the ca-

pabilities assigned in a node template are also de-

ﬁned in the corresponding node type, integer prop-

erties contain integer values, etc.). However, despite

the OpenStack TOSCA Parser checks that the actual

value assigned to a template’s ﬁeld is of the proper

type, it does not perform any check about the “mean-

ingfulness” of such value. For instance, it checks

whether the node ﬁeld of a requirement assignment

contains the name of a node template, but it does not

check whether such node template satisﬁes the inter-

connection constraints speciﬁed in the corresponding

requirement deﬁnition. Our objective is instead to

permit checking such a kind of constraints.

Similar considerations apply to other TOSCA

parsers currently available, e.g., the brooklyn-tosca

parser (CloudSoft, 2016), or the TOSCA parser in

Alien4Cloud (Alien4Cloud, 2016).

TOSCA is also available in an XML-based ver-

sion (OASIS, 2013a), which still permits specify-

ing the topology of a composite cloud application,

as well as the constraints to interconnect the com-

ponents forming such topology. TOSCA XML also

permits specifying management plans, in the form of

workﬂows orchestrating the management operations

offered by the application components.

TOSCA XML applications can be edited with the

Winery graphical environment (Kopp et al., 2013),

and executed with the OpenTOSCA engine (Binz

et al., 2013). However, despite Winery and Open-

TOSCA are equipped with parsers checking whether

the XML sources of applications are syntactically cor-

rect, there is no support for validating the interconnec-

tions forming application topologies.

(Hirmer et al., 2014) propose an approach for

automatically completing TOSCA XML application

topologies. The approach is based on some of the

interconnection constraints that can be expressed in

TOSCA XML, which are exploited to decide which

available components can satisfy a dangling require-

ment of a component. The approach of (Hirmer

et al., 2014) is a ﬁrst approach exploiting the intercon-

nection constraints that can be expressed in TOSCA

XML. The aim of (Hirmer et al., 2014) is however

different from ours, as they rely on TOSCA XML,

Validating TOSCA Application Topologies

669

and since they consider only some of the intercon-

nection constraints that can be expressed in TOSCA

XML (viz., those constraining the relationship types

and capability types that can be validly used to fulﬁl

a requirement). Our aim is instead to systematically

map all constraints that can be expressed in TOSCA

to formal conditions, hence enabling a full validation

of TOSCA application topologies.

On the other hand, it is possible to validate man-

agement plans in TOSCA XML. Management proto-

cols (Brogi et al., 2015; Brogi et al., 2016) permit

specifying the management behaviour of the compo-

nents forming an application, which can then be com-

bined (according to the application topology) to ob-

tain the management behaviour of the whole appli-

cation. Such a behaviour permits automating various

useful analyses (e.g., determining the validity and ef-

fects of a management plan, or which plans reach a

given goal). However, despite topologies are crucial

to determine the management behaviour of applica-

tions, they are assumed to be valid, because of the

lack of support for validating application topologies.

In summary, despite TOSCA is designed to per-

mit specifying constraints on how to interconnect

application components to form application topolo-

gies, the support for checking such constraints is cur-

rently lacking. Existing parsers can be used to check

whether TOSCA applications are syntactically cor-

rect, but currently there are no tools that permit val-

idating TOSCA application topologies. Our objec-

tive is to address this lack, by systematically mapping

the interconnection constraints that can be expressed

in TOSCA to formal conditions, and by exploiting

such conditions to devise a ﬁrst support for validat-

ing TOSCA application topologies.

Finally, it is worth mentioning that our approach

shares its baselines with most of existing approaches

for checking the validity of component-based systems

at design time, e.g., (Speck et al., 2002; Caporuscio

et al., 2004; Wu et al., 2003), or for automatically

obtaining valid component-based systems, e.g., (Au-

tili et al., 2007; Pelliccione et al., 2008). Given a

speciﬁcation of a component-based system (a TOSCA

application speciﬁcation, in our case), we try to en-

force that all interconnections between components

are properly settled (which in our case means to check

whether the topology of an application satisﬁes all the

speciﬁed interconnection constraints). The main dif-

ference between such approaches and ours is given

by the context: (Speck et al., 2002; Caporuscio et al.,

2004; Wu et al., 2003; Autili et al., 2007; Pelliccione

et al., 2008) focus on systems that have to offer a cer-

tain functionality by validly composing the function-

alities offered by their components. We instead focus

on ensuring that the dependencies between the com-

ponents forming a TOSCA application are properly

speciﬁed, as such information is the basis for orches-

trating the management of a TOSCA application.

3 VALIDATING TOPOLOGIES

The objective of this paper is to permit validating the

topology of a TOSCA application (viz., its topolo-

gy template). As shown in Sect. 2.1, the topolo-

gy template is a typed directed graph whose nodes

model the application components, and whose edges

model the relationships occurring between such com-

ponents. Each relationship speciﬁes that a require-

ment of the source node must be actually satisﬁed by

(a capability of) the target node.

As we anticipated in Sect. 1, in order to vali-

date the topology of a TOSCA application, we must

check whether all inter-component relationships have

been properly speciﬁed. For each relationship, we

must validate all the TOSCA elements concerning its

source, the relationship itself, and its target. In this

respect, please note that the source of a relationship

is always a requirement of a node, that a relationship

is actually a relationship template, and that the target

of a relationship is either a node or a capability of a

node (OASIS, 2016).

We hereafter systematically map

the interconnec-

tion constraints expressed while deﬁning TOSCA re-

quirements, relationships, and capabilities to formal

conditions. We separately discuss the conditions to

validate the interconnection constraints speciﬁed in

the sources of relationships (Sect. 3.1), in relation-

ships (Sect. 3.2), and in the targets of relationships

(Sect. 3.3). We then combine all such conditions to

deﬁne the notion of validity for a TOSCA application

topology (Sect. 3.4).

3.1 Validating Sources of Relationships

We hereby illustrate how to validate the source of

each relationship appearing in an application topol-

ogy. As the source of a relationship is always a node’s

requirement (OASIS, 2016), we must check that each

relationship outgoing from a requirement is compati-

ble with the requirement deﬁnition itself.

After sistematically reading the whole TOSCA speciﬁ-

cation (OASIS, 2016), we have extracted the portions that

permit specifying interconnection constraints. We hereafter

recall such portions, and we show how to directly map them

to formal conditions that must hold to have valid TOSCA

application topologies.

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

670

req name: cap type name

(a)

req name:

c a p a b i l i t y : cap type name

node: node type name

rel a t i ons h i p: r el t y pe n a me

occurrences: [ min occ , max occ ]

(b)

Figure 3: (a) Simple and (b) extended grammars for require-

ment deﬁnitions (OASIS, 2016).

In the following, we recall how to declare a re-

quirement in TOSCA, and what is its meaning accord-

ing to the TOSCA speciﬁcation. We then single out

the checks that must be performed to ensure that no

relationship is violating the constraints given by a re-

quirement declaration.

3.1.1 How to deﬁne a Requirement in TOSCA

We hereby recall how to deﬁne a requirement in a

TOSCA node type, and how to instantiate a require-

ment in a TOSCA node template.

A node type n

type

deﬁnes the set of named require-

ments that can be exposed by a node template of such

type. Each requirement deﬁnition can be given within

the requirements section of n

type

according to the

(a) simple or (b) extended grammars in Figure 3. In

both cases, a developer can deﬁne the requirement

name (req name), and she can provide constraints for

its satisfaction.

The (a) simple grammar requires to indicate the

name (cap type name) of a valid capability type

that can fulﬁl the requirement under deﬁnition. The

(b) extended grammar also permit indicating three op-

tional constraints.

• node permits indicating the name (node

ty-

pe name) of a valid node type that contains a

capability deﬁnition that can be used to fulﬁl the

requirement under deﬁnition.

• relationship permits providing the name of a

relationship type that can be validly used to build

a relationship template when fulﬁlling the require-

ment.

• occurrences permits instructing the minimum

(min occ) and maximum (max occ) occur-

rences of the requirement under deﬁnition in a

node template of the corresponding node type

Since the focus of this paper is on validating inter-

component dependencies in TOSCA application topologies,

and since occurrences is not giving any constraint con-

cerning inter-component dependencies, we shall not for-

req name: node temp name

(a)

req name:

node: node t emp name | node type name

rel a t i ons h i p: rel temp name | rel t ype n ame

c a p a b i l i t y : cap n ame | cap type name

n o d e f i l t e r : n o d e f i l t e r d e f i n i t i o n

(b)

Figure 4: (a) Simple and (b) extended grammars for require-

ment assignments (OASIS, 2016).

By default, min occ and max occ are both set

to 1.

A node template n

temp

instantiates a node type

type

in a TOSCA application topology, and it permits

declaring the requirements actually exposed by the

application component corresponding to such node

template. Such requirements can be given through so-

called requirement assignments within the require-

ments section of n

temp

. Each requirement assignment

instantiates a corresponding

requirement deﬁnition

in n

type

. The (a) simple and (b) extended grammars for

requirement assignments are displayed in Figure 4.

The (a) simple grammar permits indicating only

the name (node temp name) of the concrete node

template that is actually satisfying the requirement

under assignment. This notation is only valid if

the corresponding requirement deﬁnition (in the node

type of the node template that is being speciﬁed) indi-

cates at least a valid capability type that can be found

in the target node template.

The (b) extended grammar can be used if the re-

quirement assignment has to provide more informa-

tion than just the name of the target node template.

• node is used to identify the target node of a re-

lationship. It can be used to provide either the

name of the node template that is actually ful-

ﬁlling the requirement under assignment, or the

name of a node type that a TOSCA-compliant

cloud provider will use to select a type-compatible

node template to fulﬁl the requirement at run-

time.

• relationship is an optional reserved keyword

that can be used to provide either the name of a

relationship template (to relate the source node to

the — capability in the — target node when fulﬁll-

ing the requirement), or the name of a relationship

type (that will be used by a TOSCA-compliant

malise the trivial condition to validate occurrences.

A node template’s requirement assignment corresponds

to a node type’s requirement deﬁnitions if they have the

same name req name.

Validating TOSCA Application Topologies

671

cloud provider to select a type-compatible rela-

tionship template to relate the source and target

nodes at run-time).

• node filter permits deﬁning additional con-

straints that TOSCA-compliant cloud providers

will use to select a type-compatible target node

that can fulﬁl the requirement under assignment

at run-time.

3.1.2 How to validate a TOSCA Requirement

We hereby single out the conditions that must hold to

validate sources of relationships at design-time

. In

doing so, we exploit the following shorthand notation.

Notation. In the following, we write:

• name(·) and type(·) to denote the name and type

associated to a TOSCA element, respectively,

• t

≥ t to denote that t

extends

or is equal to t,

• e.f to denote the ﬁeld f of the TOSCA element e

(which is ⊥ if f is not deﬁned in e), and

• R(·) and C(·) to denote the requirements and ca-

pabilities assigned by a node template or deﬁned

in a node type.

Given a TOSCA application topology, the sources

of its inter-component relationships are valid if each

of its node templates satisﬁes all the aforementioned

conditions.

Condition 1. Let n

temp

be a node template of type

type

. Then:

∀r

∈ R(n

temp

), ∃r

∈ R(n

type

1) name(r

) = name(r

) ∧

2) r

.node 6= ⊥ ⇒ type(r

.node) ≥ r

.node ∧

3) r

.capability 6= ⊥ ⇒

typ e(r

.capability) ≥ r

.capability ∧

4) r

.capability = ⊥ ⇒

∃c ∈ C(r

.node) : type(c) ≥ r

.capability ∧

5) r

.relationship 6= ⊥ ∧ r

.relationship 6= ⊥ ⇒

typ e(r

.relationship) ≥ r

.relationship

We hence exclude all constraints that permit deﬁning

how to automatically complete the topology of a TOSCA

application (by selecting type-compatible node templates

and relationship templates to satisfy pending require-

ments — e.g., node: node type name, relation-

ship: rel type name, and capability: cap ty-

pe name in Figure 4.(b)). Our validation approach can

however be useful for double-checking automatically com-

pleted TOSCA application topologies (as well as for help-

ing the automatic completion itself).

Given that t and t

are TOSCA types, t

extends t if t

(directly or indirectly) derived from t.

Firstly, we must check that, for each requirement

assigned r

in a node template n

temp

(of type n

type

there exists a corresponding requirement deﬁnition r

in n

type

(Condition 1..1).

We can then check that no requirement assignment

is violating the constraints indicated by the corre-

sponding requirement deﬁnition r

• The (optional) ﬁeld node of a requirement deﬁ-

nition r

permits indicating the name of a valid

node type that can be used to fulﬁl a requirement.

Hence, if node is speciﬁed in r

, the type of the

node template targeted by each corresponding re-

quirement assignment r

has to extend or to be

equal to that indicated in node (Condition 1..2.)

• A requirement deﬁnition r

indicates (either in-

line or with the keyword capability) the name

of a valid capability type that can fulﬁl the re-

quirement. This is ensured if each correspond-

ing requirement assignment r

directly targets a

capability whose type extends or is equal to that

indicated in the requirement deﬁnition (Condi-

tion 1..3). Alternatively, if a requirement assign-

ment r

is only indicating the target node template

(but not pointing to any of its capabilities), we

must check whether such node template is offer-

ing at least one type-compatible capability (Con-

dition 1..4).

• Finally, the (optional) ﬁeld relationship of a

requirement deﬁnition r

permits indicating the

name of a relationship type that can be validly

used to build a relationship template when ful-

ﬁlling the requirement. Hence, if relationship

is speciﬁed in r

, the type of a relationship tem-

plate outgoing from a corresponding requirement

assignment r

(if any) extends or is equal to that

indicated in relationship (Condition 1..5).

3.2 Validating Relationships

We hereby illustrate how to validate the relationships

occurring between the nodes appearing in an applica-

tion topology. As such relationships are expressed by

typed relationship templates (OASIS, 2016), we must

check that each relationship template is instantiated

without violating any of the constraints given in the

corresponding relationship type.

In the following, we recall how to declare a re-

lationship type in TOSCA, and which is its meaning

according to the TOSCA speciﬁcation. We then illus-

trate the conditions that must hold to ensure that no

relationship template is violating the constraints given

by the corresponding relationship type.

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

672

3.2.1 How to deﬁne a Relationship in TOSCA

A relationship template instantiate a relationship type

to specify the actual occurrence of a manageable re-

lationship between two node templates in an applica-

tion topology. A relationship type can be deﬁned with

the grammar in Figure 5, which permits specifying

the name (rel type name) of a relationship type,

as well as the features and constraints characterising

such relationship type.

rel type name:

derived from: p a rent r e l t y p e n a m e

version: version number

de scrip ti on: r e l d e s c r i p t i o n

pr opert ie s: p r o p e r t y d e f i n i t i o n s

a t t r i b u t e s : a t t r i b u t e d e f i n i t i o n s

int e r fa c e s: i n t e r f a c e d e f i n i t i o n s

v a l i d t a r g e t t y p e s : [ cap type names ]

Figure 5: Grammar for relationship types (OASIS, 2016).

• The (optional) ﬁeld derived from permits indi-

cating the name (parent rel type name) of

the parent relationship type

. The relationship

type under deﬁnition inherits all the features the

parent relationship type, and it can override some

of them (OASIS, 2013b).

For instance, if the relationship type under deﬁ-

nition does not specify a new list of valid tar-

get types, then it takes that of the parent rela-

tionship type. Otherwise, the parent’s list of va-

lid target types is overridden by that speciﬁed

in the relationship type under deﬁnition.

• version and description are optional ﬁelds

that permit versioning and describing (in natural

language) a relationship type.

• The (optional) ﬁelds properties and

attributes permit describing the structure

of the desired and actual state of a relationship,

respectively. Concrete state values will be then

given in the relationship templates instantiating

the relationship type under deﬁnition.

• interfaces is a (optional) ﬁeld that permits

declaring the management operations that can be

offered by relationship templates whose relation-

ship type is that under deﬁnition.

• valid target types is a (optional) list of one

or more names (cap type names) of capabil-

ity types that are valid targets for the relationship

under deﬁnition.

All TOSCA relationship types should be derived (di-

rectly or indirectly) from the tosca.relationships.Root

relationship type (OASIS, 2016).

3.2.2 How to validate a TOSCA Relationship

Since a relationship template instantiates a relation-

ship type in an application topology, it has to not vi-

olate the constraints given when deﬁning the corre-

sponding relationship type.

Notice that the only constraints that can be given

while deﬁning a relationship type are those concern-

ing its valid target types. The latter can either be

speciﬁed inline or inherited from the parent type.

Notation. In the following, we write T(·) to denote

the set of capability types that are valid targets for a

relationship type. Given a relationship type rel

type

• If rel

type

.valid target types 6= ⊥, then

T(rel

type

) is the set containing all elements

in rel

type

.valid target types,

• otherwise, if rel

type

.derived from 6= ⊥, then

T(rel

type

) = T(rel

type

.derived from),

• otherwise, T(rel

type

) is the set containing all ca-

pability types (meaning that all capability types

are valid targets for rel

type

Given a TOSCA application topology, its relationship

templates are valid if they satisfy the following con-

dition.

Condition 2. Let rel

temp

be a relationship template of

type rel

type

. If there exists a requirement assignment

that is source of rel

temp

, then:

1) r

.capability 6= ⊥ ⇒

∃c

type

∈ T(rel

type

): type(r

.capability) ≥ c

type

∧

2) r

.capability = ⊥ ⇒

∃c

∈ C(r

.node):

∃c

type

∈ T(rel

type

) : type(c

) ≥ c

type

Namely, if a relationship template rel

temp

is target-

ing a speciﬁc capability

, then the type of such capa-

bility has to be compatible with at least one of those

indicated in valid target types (Condition 2..1).

If the source of a relationship template rel

temp

instead only indicating the target node template (but

not pointing to any of its capabilities), we must check

whether such node template is offering at least one

type-compatible capability (Condition 2..2).

3.3 Validating Targets of Relationships

While the source of a relationship is always a require-

ment, the target of a relationship can be either a capa-

bility or a node template. In the latter case, the node

Please recall that a relationship is outgoing from a re-

quirement assignment r

. The latter can either indicate the

speciﬁc capability satisfying r

, or a node template offering

(at least) a capability satisfying r

(see Figure 4).

Validating TOSCA Application Topologies

673

template must offer at least a capability capable of sat-

isfying the source requirement (OASIS, 2016).

In the following we recall how to specify a capa-

bility in TOSCA, and which is its meaning according

to the TOSCA speciﬁcation. We then illustrate the

conditions that must hold to ensure that no relation-

ship is violating the constraints given by its target.

3.3.1 How to deﬁne a Capability in TOSCA

A capability type is a reusable entity that describes a

kind of capability that a node type can declare to ex-

pose (OASIS, 2016). A capability type can be deﬁned

according to the grammar in Figure 6, which permits

specifying the name (cap type name) of a capabil-

ity type, as well as with the features and constraints

characterising such capability type.

cap type name:

derived from: p arent cap type n ame

version: version number

de scrip ti on: c a p a b i l i t y d e s c r i p t i o n

pr opert ie s: p r o p e r t y d e f i n i t i o n s

a t t r i b u t e s : a t t r i b u t e d e f i n i t i o n s

va lid so urce t yp es: [ node type names ]

Figure 6: Grammar for capability types (OASIS, 2016).

• The (optional) ﬁeld derived from permits indi-

cating the name (parent cap type name) of

the parent capability type

. The capability type

under deﬁnition inherits all the features the par-

ent capability type, and it can override some of

them (OASIS, 2013b).

For instance, if the capability type under deﬁni-

tion does not specify a new list of valid sour-

ce types, then it takes that of the parent capabil-

ity type. Otherwise, the parent’s list of valid so-

urce types is overridden by that speciﬁed in the

capability type under deﬁnition.

• version and description are optional ﬁelds

that permit versioning and describing (in natural

language) a capability type.

• The (optional) ﬁelds properties and

attributes permit describing the structure

of the desired and actual state of a capability,

respectively. Concrete state values will be

then given by the node templates instantiating

capabilities whose type is that under deﬁnition.

• valid source types is a (optional) list of one or

more names (node type names) of node types

All TOSCA capability types should be derived (directly

or indirectly) from the tosca.capability.Root capabil-

ity type (OASIS, 2016).

cap name: cap type name

(a)

cap name:

type: cap type name

de scrip ti on: c a p a b i l i t y d e s c r i p t i o n

pr opert ie s: p r o p e r t y d e f i n i t i o n s

a t t r i b u t e s : a t t r i b u t e d e f i n i t i o n s

va lid so urce t yp es: [ node type names ]

(b)

Figure 7: (a) Simple and (b) extended grammars for capa-

bility deﬁnitions (OASIS, 2016).

cap name:

pr opert ie s: pr ope r ty a s si g nm e nts

a t t r i b u t e s : a t t r i b u t e a s s i g n m e n t s

Figure 8: Grammar for capability assignments (OASIS,

2016).

that are valid sources for relationships whose tar-

get capability is of the type under deﬁnition.

Capability types are then referred by node types

to deﬁne the set of named capabilities that can be ex-

posed by a node template of such type. Each capabil-

ity deﬁnition can be given within the capabilities

section of a node type n

type

according to the (a) simple

or (b) extended grammars in Figure 7. In both cases, a

developer can deﬁne the capability name (cap name),

and she can specify the type (cap type name) of

the capability under deﬁnition. With the extended

grammar, a developer can also specify the (optional)

ﬁelds description, properties, attributes, and

valid source types (whose meaning is analogous

to that of their homonym ﬁelds in the grammar for

specifying capability types — see Figure 6).

A node template n

temp

instantiates a node type

type

in a TOSCA application topology, as well as all

the capabilities it deﬁnes. A node template can also

assign concrete values to the properties and attributes

of such capabilities, to provide additional information

concerning their desired and actual state, respectively.

Such assignments can be given through so-called ca-

pability assignments within the capabilities sec-

tion of n

temp

(Figure 8).

3.3.2 How to validate a TOSCA Capability

While deﬁning a capability in TOSCA, the only con-

straints that can be given are those concerning the

valid

source types. Such constraints can be

speciﬁed within the speciﬁcation of a capability type,

or within the capability deﬁnitions of a node type. The

constraints given while deﬁning a capability type can

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

674

Table 1: Conditions to validate inter-component relationships in TOSCA application topologies.

Validating

sources

of relationships

(Condition 1.)

Let n

temp

be a node template of type n

type

. Then, ∀r

∈ R(n

temp

), ∃r

∈ R(n

type

(1.1) name(r

) = name(r

) ∧

(1.2) r

.node 6= ⊥ ⇒ type(r

.node) ≥ r

.node ∧

(1.3) r

.capability 6= ⊥ ⇒ type(r

.capability) ≥ r

.capability ∧

(1.4) r

.capability = ⊥ ⇒ ∃c ∈ C(r

.node): type(c) ≥ r

.capability ∧

(1.5) r

.relationship 6= ⊥ ∧ r

.relationship 6= ⊥ ⇒

typ e(r

.relationship) ≥ r

.relationship

Validating

relationships

(Condition 2.)

Let rel

temp

be a relationship template, and let rel

type

be its relationship type. If there

exists a requirement assignment r

that is source of rel

temp

, then:

(2.1) r

.capability 6= ⊥ ⇒ ∃c

type

∈ T(rel

type

): type(r

.capability) ≥ c

type

∧

(2.2) r

.capability = ⊥ ⇒ ∃c

∈ C(r

.node), c

type

∈ T(rel

type

): type(c

) ≥ c

type

Validating targets

of relationships

(Condition 3.)

Let c

be a capability assignment, whose corresponding type and deﬁnition are c

type

and c

. For each node template n

temp

having a requirement assignment r

such that

.capability = c

(3.1) ∃n

type

∈ S(c

type

): type(n

temp

) ≥ n

type

∧

(3.2) ∃n

type

∈ S(c

): type(n

temp

) ≥ n

type

either be speciﬁed inline or they can be inherited from

the parent capability type.

Notation. In the following, we write S(·) to denote

the set of node types that are valid sources for a capa-

bility type. Given a capability type c

type

• If c

type

.valid source types 6= ⊥, then

S(c

type

) is the set containing all elements in

type

.valid source types,

• otherwise, if c

type

.derived from 6= ⊥, then

S(c

type

) = S(c

type

.derived from),

• otherwise, S(c

type

) is the set containing all node

types (meaning that all node types are valid tar-

gets for c

type

Given a capability assignment c

, in a TOSCA

application topology there might be multiple node

templates (having requirement assignments) that are

sources of relationship templates targeting c

. All

such node templates must not violate any of the con-

straints imposed by c

• Neither those indicated by its capability type c

type

(Condition 3..1),

• nor those speciﬁed within the corresponding ca-

pability deﬁnition c

(Condition 3..2).

Condition 3. Let c

be a capability assignment,

whose corresponding type and deﬁnition are c

type

and

. For each node template n

temp

having a require-

ment assignment r

such that r

.capability = c

1) ∃n

type

∈ S(c

type

): type(n

temp

) ≥ n

type

∧

2) ∃n

type

∈ S(c

): type(n

temp

) ≥ n

type

3.4 Valid TOSCA Application

Topologies

In Sects. 3.1, 3.2, and 3.3 we have illustrated the con-

ditions that permit validating sources, instances, and

targets of TOSCA relationships, respectively. The fol-

lowing deﬁnition gathers all such conditions to permit

validating all inter-component relationships appear-

ing in a TOSCA application topology.

Deﬁnition 1. A TOSCA application topology is valid

if all its node templates and relationship templates

satisfy Conditions 1., 2., and 3..

For the convenience of readers, Conditions 1., 2., and

3. are recapped in Table 1.

Figure 9: Open-source toolchain for validating TOSCA ap-

plication topologies.

Validating TOSCA Application Topologies

675

4 THE SOMMELIER PROTOTYPE

We hereby illustrate SOMMELIER, an open-source

prototype for validating TOSCA application topolo-

gies (as we discussed in the previous section). The

prototype of SOMMELIER is implemented in Python,

and it is fully integrated with the OpenStack TOSCA

parser (OpenStack, 2016).

Figure 9 illustrates how SOMMELIER performs

the validation of a TOSCA application topology:

1 SOMMELIER inputs a CSAR package or a .tosca

document containing the TOSCA application

topology to be validated.

As the current prototype of SOMMELIER is a

command-line tool, the CSAR or .tosca ﬁles can

be passed to SOMMELIER with a dedicated com-

mand line option.

2 The input is forwarded by SOMMELIER to the

OpenStack Parser.

3 The OpenStack Parser checks whether the

TOSCA application is syntactically correct, i.e. it

checks whether all TOSCA elements have been

speciﬁed in the proper section (e.g., node types

in the node types section) and that each tem-

plate respects the structure given by the corre-

sponding type (e.g., the capabilities assigned in a

node template are also deﬁned in the correspond-

ing node type). If this is the case, the OpenStack

Parser generates a representation of the TOSCA

application in Python, according to its object-

model (OpenStack, 2016).

4 The Python objects representing the TOSCA ap-

plication are returned to SOMMELIER.

5 SOMMELIER validates the topology of the

TOSCA application by checking whether all (the

Python objects representing) its nodes and rela-

tionships satisfy all conditions

in Table 1.

SOMMELIER then generates a Python dictionary

whose abstract structure is illustrated in Figure 10.

Namely, SOMMELIER associates each require-

ment of each node template with a list contain-

ing all validation errors affecting the relationship

outgoing from such requirement. Each error is in

turn represented as a list, whose ﬁrst element is a

The source code of SOMMELIER is publicly available

on GitHub at https://github.com/di-unipi-socc/Sommelier.

SOMMELIER is distributed along with unit tests il-

lustrating that it is capable of recognising the viola-

tion of all such conditions. The unit tests are pub-

licly available within the tests folder in the SOMME-

LIER Github repository (i.e., at https://github.com/di-unipi-

socc/Sommelier/tree/master/tests).

https://docs.python.org/3/tutorial/datastructures.html.

{

node template1 name : {

req1 name : [

[ e r r o r 1 c o d e , e r r o r 1 i n f o ] ,

[ e r r o r 2 c o d e , e r r o r 2 i n f o ] ,

. . .

]

req2 name : [ . . . ] ,

. . .

} ,

node template2 name : { . . . } ,

. . .

}

Figure 10: Structure of the Python dictionary containing the

results of the validation.

$ python s o m m e l i e r . py −−t e m p l a t e −f i l e =

. . / t o s c a −p a r s e r / t o s c a p a r s e r / t e s t s / d a t a

/ t o p o l o g y t e m p l a t e / t o s c a e l k . yaml

The a p p l i c a t i o n t o p o l o g y i s v a l i d .

(a)

$ python s o m m e l i e r . py −−t e m p l a t e −f i l e =

. . / t o s c a −p a r s e r / t o s c a p a r s e r / t e s t s / d a t a

/ t o p o l o g y t e m p l a t e / t r a n s a c t i o n s s u b s y s

tem s . yaml

NODE TEMPLATE: app

REQUIREMENT: host

1 . 2 − NODE TYPE NOT COHERENT: The type

"tosca .nodes . WebServer" o f t h e t a r g e t

node "websrv " i s n o t v a l i d ( a s i t d i f f

e r s from t h a t i n d i c a t e d i n t h e r e q u i r e

ment d e f i n i t i o n ) .

(b)

Figure 11: Example of runs of SOMMELIER.

numeric code (e.g., 1.2 if the requirement is vio-

lating Condition 1..2), and whose remaining ele-

ments may be used to provide further information

about the error (e.g., the type and name of the tar-

get node, which is not satisfying Condition 1..2).

6 The results of the validation are displayed by

SOMMELIER. The current prototype of SOM-

MELIER either states that the service template’s

topology is valid, or it lists all the detected vali-

dation errors (by also explaining why such errors

occurred).

Example. We now illustrate how to use SOMMELIER

to validate existing TOSCA application topologies.

As SOMMELIER is a command-line tool, running an

instance of SOMMELIER just requires to type the fol-

lowing command in a command shell:

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

676

$ python somme li er . py

−−template−file = template−file−path

(where template − file − path is the absolute path

where the TOSCA ﬁle to be validated is stored).

Concrete examples of run of SOMMELIER are

shown in Figure 11.

In the ﬁgure, the application speciﬁcation that

are passed to SOMMELIER are taken among those

available in the GitHub repository of the OpenStack

TOSCA parser. Figure 11.(a) shows that the TOSCA

application topology speciﬁed in tosca elk.yaml

valid.

Figure 11.(b) instead shows that the TOSCA

application topology speciﬁed in transactionsubsys-

tem.yaml

is not valid, because the relationship out-

going from requirement host of the node template app

is violating Condition 1..2 (since it targets the node

template websrv, whose type is not compatible with

those indicated in the requirement deﬁnition corre-

sponding to host). Such a kind of inconsistencies

would be really hard to be manually detected, with-

out the availability of a tool like SOMMELIER.

5 CONCLUDING REMARKS

TOSCA provides a standardised language that per-

mits specifying portable cloud applications, and to au-

tomate their deployment and management. As the au-

tomated deployment of TOSCA applications is based

on their topologies (OASIS, 2013b), it is fundamental

to ensure that such topologies are valid.

TOSCA permits specifying the constraints that

must be satisﬁed while interconnecting application

components to form the topology of a cloud applica-

tion. In this paper:

(i) We have systematically mapped such con-

straints to formal conditions that must hold to

ensure the validity of a TOSCA application

topology. The obtained conditions are recapped

in Table 1.

The tosca elk.yaml ﬁle has been devel-

oped within the OpenStack TOSCA parser

community, and it is publicly available at

https://raw.githubusercontent.com/openstack/tosca-

parser/master/toscaparser/tests/data/tosca elk.yaml (last

accessed on November 13th, 2016).

The transactionsubsystem.yaml ﬁle has

been developed within the OpenStack TOSCA

parser community, and it is publicly available at

https://raw.githubusercontent.com/openstack/tosca-

parser/master/toscaparser/tests/data/topology template/

transactionsubsystem.yaml (last accessed on November

13th, 2016).

(ii) We have also presented SOMMELIER, an open-

source prototype of validator for TOSCA appli-

cation topologies.

SOMMELIER implements all the aforementioned val-

idation conditions (as one can readily check by run-

ning the unit tests available in its repository). SOM-

MELIER can hence be fruitfully exploited by TOSCA

application developers to automatically validate the

topologies of their applications.

SOMMELIER is fully integrated with the Open-

Stack TOSCA parser (OpenStack, 2016). As they are

both open-source, they can lay the foundations for an

open-source toolset for supporting TOSCA applica-

tion developers. This is in line with the research direc-

tions indicated in (Brogi et al., 2014b), and in partic-

ular with the development of tools to support TOSCA

developers from the design time till the run time.

It is worth noting that SOMMELIER can be

fruitfully exploited for improving the functionalities

of existing graphical editors (such as that in the

Alien4Cloud platform (Alien4Cloud, 2016), for in-

stance). SOMMELIER can indeed be useful for vali-

dating TOSCA application topologies while they are

being developed. Its output could also be exploited

for suggesting how to ﬁx errors (e.g., which capabil-

ity can actually satisfy a misplaced requirement) or to

drive the development itself (e.g., warning the user if

she is connecting a requirement to a wrong capability

— or impeding her to do so). As part of our future

work, we plan to integrate SOMMELIER with a graph-

ical editor, with the long-term objective of providing

a full-ﬂedged support for the development of TOSCA

applications (Brogi et al., 2014b).

It is also worth highlighting that the elements that

can be expressed in TOSCA YAML (OASIS, 2016)

are a subset of those that can be deﬁned in TOSCA

XML (OASIS, 2013a), as the former is a simpliﬁed

proﬁle of the latter. We plan to investigate whether

the validation conditions contained in this paper are

enough to validate also the topologies of TOSCA

XML applications, and to (extend and) adapt them to

work with TOSCA XML, if necessary. This would

permit providing the OpenTOSCA open-source envi-

ronment (Kopp et al., 2013; Binz et al., 2013) also

with validation capabilities. It would also permit re-

ﬁning the automated topology completion approach

by Hirmer et al. (Hirmer et al., 2014), by ensuring the

validity of obtained topologies.

Finally, as TOSCA permits describing not only

the technological requirements of application com-

ponents, but also their non-functional requirements

(e.g., scalability constraints, in terms of minimum and

maximum amount of occurrences of a node replica,

or QoS requirements speciﬁed in policies applied to

Validating TOSCA Application Topologies

677

nodes), TOSCA applications should also be validated

also from a non-functional perspective. We plan to

systematically map the non-functional constraints of

that can be expressed in TOSCA to formal conditions

that will permit carrying out such a validation.

ACKNOWLEDGEMENTS

Work partly supported by the project Through the fog

(PRA 2016 64) funded by the University of Pisa.

REFERENCES

Alien4Cloud (2016). Alien4cloud.

https://github.com/alien4cloud/alien4cloud.

Armbrust, M., Fox, A., Grifﬁth, R., Joseph, A. D., Katz,

R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A.,

Stoica, I., and Zaharia, M. (2010). A view of cloud

computing. Commun. ACM, 53(4):50–58.

Autili, M., Inverardi, P., Navarra, A., and Tivoli, M. (2007).

Synthesis: A tool for automatically assembling cor-

rect and distributed component-based systems. In

Proc. of the 29th International Conference on Soft-

ware Engineering, ICSE ’07, pages 784–787. IEEE

Computer Society.

Binz, T., Breitenb

ucher, U., Haupt, F., Kopp, O., Ley-

mann, F., Nowak, A., and Wagner, S. (2013). Open-

tosca – a runtime for tosca-based cloud applications.

In Proc. of the 11th International Conference on

Service-Oriented Computing, ICSOC’13, pages 692–

695. Springer.

Brogi, A., Canciani, A., and Soldani, J. (2015). Mod-

elling and analysing cloud application management.

In Dustdar, S., Leymann, F., and Villari, M., edi-

tors, Service Oriented and Cloud Computing: 4th Eu-

ropean Conference, ESOCC 2015, Taormina, Italy,

September 15-17, 2015, Proceedings, pages 19–33.

Springer International Publishing.

Brogi, A., Canciani, A., Soldani, J., and Wang, P. (2016).

A Petri net-based approach to model and analyze the

management of cloud applications. In Koutny, M.,

Desel, J., and Kleijn, J., editors, Transactions on Petri

Nets and Other Models of Concurrency XI, LNCS

Transactions on Petri Nets and Other Models of Con-

currency, pages 28–48. Springer Berlin Heidelberg.

Brogi, A., Carrasco, J., Cubo, J., D’Andria, F., Ibrahim,

A., Pimentel, E., and Soldani, J. (2014a). EU Project

SeaClouds - Adaptive management of service-based

applications across multiple clouds. In CLOSER 2014

- Proceedings of the 4th International Conference on

Cloud Computing and Services Science, pages 758–

763. SciTePress.

Brogi, A., Soldani, J., and Wang, P. (2014b). TOSCA

in a nutshell: Promises and perspectives. In Vil-

lari, M., Zimmermann, W., and Lau, K.-K., editors,

Service-Oriented and Cloud Computing: Third Eu-

ropean Conference, ESOCC 2014, Manchester, UK,

September 2-4, 2014. Proceedings, pages 171–186.

Springer Berlin Heidelberg.

Caporuscio, M., Inverardi, P., and Pelliccione, P. (2004).

Compositional veriﬁcation of middleware-based soft-

ware architecture descriptions. In Proc. of the 26th

International Conference on Software Engineering,

ICSE ’04, pages 221–230. IEEE Computer Society.

CloudSoft (2016). brooklyn-tosca.

https://github.com/cloudsoft/brooklyn-tosca.

Geraci, A. (1991). IEEE Standard Computer Dictionary:

Compilation of IEEE Standard Computer Glossaries.

IEEE Press.

Hirmer, P., Breitenb

ucher, U., Binz, T., and Leymann, F.

(2014). Automatic topology completion of TOSCA-

based cloud applications. In INFORMATIK 2014, vol-

ume 232 of LNI, pages 247–258. Gesellschaft f

ur In-

formatik (GI).

Kopp, O., Binz, T., Breitenb

ucher, U., and Leymann, F.

(2013). Winery – a modeling tool for tosca-based

cloud applications. In Proc. of the 11th Interna-

tional Conference on Service-Oriented Computing,

ICSOC’13, pages 700–704. Springer.

Marchetti, E. (2014). Foreword of the thematic track: ICT

veriﬁcation and validation. In Proc. of the 9th In-

ternational Conference on the Quality of Information

and Communications Technology, QUATIC’14, pages

208–209. IEEE.

OASIS (2013a). Topology and Orchestration Speciﬁca-

tion for Cloud Applications. URL: http://docs.oasis-

open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.pdf.

OASIS (2013b). Topology and Orchestration Speciﬁ-

cation for Cloud Applications (TOSCA) Primer.

URL: http://docs.oasis-open.org/tosca/tosca-

primer/v1.0/tosca-primer-v1.0.pdf.

OASIS (2016). TOSCA Simple Proﬁle in YAML, Version

1.0. URL: http://docs.oasis-open.org/tosca/TOSCA-

Simple-Proﬁle-YAML/v1.0/TOSCA-Simple-Proﬁle-

YAML-v1.0.pdf.

OpenStack (2016). TOSCA parser.

https://github.com/openstack/tosca-parser.

Pelliccione, P., Tivoli, M., Bucchiarone, A., and Polini,

A. (2008). An architectural approach to the correct

and automatic assembly of evolving component-based

systems. J. Syst. Softw., 81(12):2237–2251.

Speck, A., Pulvermuller, E., Jerger, M., and Franczyk, B.

(2002). Component composition validation. Interna-

tional Journal of Applied Mathematics and Computer

Science, 12(4):581–590.

Wu, Y., Chen, M.-H., and Offutt, J. (2003). Uml-based

integration testing for component-based software. In

Proc. of the 2nd International Conference on COTS-

Based Software Systems, ICCBSS’03, pages 251–260.

Springer Berlin Heidelberg.

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

678