An Aspect-Oriented Model Transformation to Weave Security using CVL

Jose-Miguel Horcas, M

onica Pinto and Lidia Fuentes

CAOSD Group, Departamento de Lenguajes y Ciencias de la Computaci

on, University of M

alaga, M

alaga, Spain

Keywords:

Aspect-Orientation, ATL, CVL, Model Transformations, Security, Variability, Weaving Pattern.

Abstract:

In this paper, we combine the Common Variability Language (CVL) and the ATL Transformation Language

to customize and incorporate a generic security model into any application that requires security. Security

spans a large set of concerns such as integrity, encryption or authentication, among others, and each concern

needs to be incorporated into the base application in a different way and at different points of the application.

We propose a set of weaving patterns using model transformations in ATL to automatically weave the security

concerns with the base application in an aspect-oriented way. Since different applications require different

security requirements, the security model needs to be customized before its incorporation into the application.

We resolve the variability of the security properties and implement the weaving process in CVL. We use an

e-voting case study to illustrate our proposal using the CVL approach.

1 INTRODUCTION

In Component-Based Software Engineering (CBSE),

there are properties of an application that can be dis-

persed and replicated in several modules. Security

is an example of these properties, which are usu-

ally deﬁned in multiple different components cross-

cutting the base functionality of the application. For

instance, access control is deﬁned in each compo-

nent that needs to control the user rights to use a re-

source. An Aspect-Oriented (AO) approach aims to

achieve separation of crosscutting concerns and ad-

dresses the limitation of the traditional software tech-

nologies (e.g. CBSE, Object-Oriented Programming)

to appropriately modularize crosscutting concerns at

the different development stages. From the perspec-

tive of AO, security is a crosscutting concern the be-

havior of which is tangled and/or scattered with the

core behavior of the application being affected by it.

Modeling security separately from the affected ap-

plication has many advantages: high reusability, low

coupled components, high cohesive software archi-

tectures. To beneﬁt from these advantages security re-

quirements need to be taken into account from early

stages in the development process — i.e. at the ar-

chitectural level. Moreover, the software architecture

modeling the security functionality should be deﬁned

separately from the software architecture of the base

applications that need it. Separating security related

concerns from the application base code is also the

main motivation of the INTER-TRUST project

that

is under development. With this project, the industrial

partners demand security solutions easily instantiable

as part of any application. The approach presented in

this paper pursues an answer to these demands. How-

ever, security spans a large set of concerns, including

encryption, authentication, access control, and autho-

rization, among others, and each of these concerns

affects the base application in a different way. For

instance, access control is performed before the exe-

cution of a restricted action by the user, while encryp-

tion is performed before sending a message through a

network in order to encrypt the information, but also

after receiving the message in the target in order to de-

crypt the information. Moreover, not all the applica-

tions require all the security concerns. A ﬁrst applica-

tion may require the integrity and the non-repudiation

concerns, a second application may require only the

encryption concern, and a third application may also

require the encryption concern but using a different

encryption algorithm. The software architecture of

these applications should include only the necessary

security functionality and the concerns that are not

required should not be part of the ﬁnal architecture

of the application.

In this paper, we follow an Aspect-Oriented Mod-

eling (AOM) approach

to incorporate (weave in the

AO terminology) a customized security model into a

http://www.inter-trust.eu//

http://www.aspect-modeling.org

138

Horcas J., Pinto M. and Fuentes L..

An Aspect-Oriented Model Transformation to Weave Security using CVL.

DOI: 10.5220/0004890601380147

In Proceedings of the 2nd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2014), pages 138-147

ISBN: 978-989-758-007-9

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

base application that has been speciﬁed independently

— i.e. the application does not contain any secu-

rity concern and the security model has been deﬁned

generically in order to reuse it in several applications.

This is done automatically without manually modify-

ing the existing elements in the model of the base ap-

plication. To do this, we use the Common Variability

Language (CVL) (Haugen et al., 2012) in combina-

tion with the ATL Transformation Language (Jouault

et al., 2008). CVL allows us to specify and resolve the

variability of the security model, and also allows us to

weave the customized security model with the base

application using model transformation rules, auto-

matically generating the complete model of the appli-

cation with the security functionality. CVL includes

the possibility of delegating its control during vari-

ability resolution to a Model-2-Model (M2M) trans-

formation engine such as ATL, QVT (Query/View/-

Transformation), etc. The main contribution of this

paper is that we deﬁne a set of reusable weaving pat-

terns in CVL to incorporate each security concern in

the most suitable place (join point) of the base appli-

cation model. We deﬁne the semantic of each weav-

ing pattern using reusable ATL transformation rules

that are different for each security concern since each

of them need to be woven with the base application in

a different way.

The advantage of using CVL is that it allows us

to deﬁne the models in any language based on Meta-

Object Facility (MOF) meta-models. In this paper we

use the Uniﬁed Modeling Language (UML) to deﬁne

the models (software architectures as component dia-

grams) and the weaving patterns, but our proposal is

suitable for use with any MOF compliant language,

and the weaving patterns are reusable by deﬁning a

previous model transformation between UML and the

language used to deﬁne the application and the se-

curity software architectures. In addition, the secu-

rity software architecture can also be reused with any

other application of the same domain by reusing the

model transformations.

In contrast to other variability techniques used by

traditional Software Product Lines (SPLs), such as

feature models that require an additional process to

generate the customized software architecture from

the feature model conﬁguration, CVL is intended to

be used in conjunction with architectural models, re-

solving the variability and generating the architec-

tural conﬁguration in the same process. Furthermore,

CVL was submitted to the Object Management Group

(OMG) as standard to model variability.

The rest of this paper is structured as follows. In

Section 2 we present the case study used throughout

the paper. Section 3 introduces our proposal using

CVL and brieﬂy describes the CVL terminology. Sec-

tion 4 explains how we perform the conﬁguration of

the security model and the weaving process. In Sec-

tion 5 we provide the weaving patterns for the security

concerns through model transformations. Section 6

surveys related work and in Section 7 we conclude

the paper and consider future directions.

2 CASE STUDY

Our case study is an electronic voting (e-voting) ap-

plication which is one of the demonstrators of the

INTER-TRUST project. E-Voting is one of the en-

vironments where security requirements are complex.

Figure 1 shows a simpliﬁed software architecture in

UML with the main functionality of an e-voting ap-

plication. This architecture does not include any com-

ponent related to the security requirements. The Voter

Application component allows clients to cast their

votes from smart phones, tablets, e-mails, etc. by us-

ing the EVotingInt interface. The Vote Server com-

ponent receives the votes and the Election Data stores

them in a digital ballot box through the VoteStorageInt

interface. Administrators can manage the election

data and get the election results through the VotingM-

ngInt interface that provides access to the functional-

ity of the Election Data and the Vote Counting compo-

nents.

Apart from the base functionality shown in Fig-

ure 1, the e-voting application requires a list of se-

curity extra-functional properties. Concretely, it is of

paramount importance to guarantee that: (1) all the

votes in the digital ballot box belong to an eligible

voter (i.e. integrity of the votes); (2) at the same time

the privacy of the voter must be preserved, even in

the counting process (i.e. votes must be protected by

means of cryptography); (3) the voter must be au-

thenticated using a personal digital certiﬁcate, such

an electronic ID card, and (4) administrators must be

authorized to perform actions over the election data.

With the goal of deﬁning the security functionali-

ties once, and reusing them for several applications,

Figure 2 shows a UML software architecture with

the complete functionality of all the possible security

concerns. This includes the Integrity, Authentication,

Encryption, Authorization, and Digital Signature com-

ponents with all kinds of authentication mechanisms,

encryption algorithms, and the integrity, authoriza-

tion, and digital signature functionality.

However,

To simplify the case study we do not show all the ex-

isting security properties nor all the existing algorithms for

each concern.

AnAspect-OrientedModelTransformationtoWeaveSecurityusingCVL

139

Figure 1: e-Voting software architecture.

Figure 2: Security software architecture.

the e-voting application only needs a particular con-

ﬁguration of these security functionalities based on

the previous security requirements.

3 OUR PROPOSAL USING CVL

CVL is a domain-independent language for specify-

ing and resolving variability. It makes the speciﬁca-

tion and resolution of variability over any instance of

models deﬁned using a MOF-based meta-model eas-

ier.

Figure 3 shows our proposal using the CVL ap-

proach. The core software architecture of our base ap-

plication and the security software architecture with

all the security functionalities are the Base Models

and can be deﬁned in any MOF-deﬁned language.

The speciﬁcation of the variability for the security

concerns is expressed in an abstract level in the Vari-

ability Model. The speciﬁcation of concrete variability

in the security model and the security weaving pat-

terns for each security concern are also deﬁned in the

variability model. Different conﬁgurations of the se-

curity model are provided in the Resolution Models.

These conﬁgurations are selections of a set of choices

in the variability model.

CVL provides an executable engine to automati-

cally produce the Resolved Models taking as inputs

the variability model, the resolution models and the

base models. In our proposal, the resolved models

are the software architecture of the base application

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

140

Figure 3: Our proposal using the CVL approach.

woven with the requested security conﬁguration. The

process of deriving a resolved model from a base

model given a resolution model is called materializa-

tion. Apart from resolving variability, the CVL en-

gine also has the capability to delegate its control to a

M2M transformation engine. This is especially useful

for deﬁning domain speciﬁc actions the semantics of

which are not deﬁned by CVL, and it is used in our

proposal to implement the weaving process between

the application architecture and the security conﬁgu-

ration architecture by performing models transforma-

tions during the execution of CVL.

In order to implement our proposal we use the fol-

lowing concepts of CVL

Variability Speciﬁcations (VSpecs). They are part

of the variability model. They are tree-based

structures representing choices,

and can have

variation points bound to them. To materialize a

base model with a variability model over it, reso-

lutions for the VSpecs must be provided. Choices

are resolved by deciding them negatively or posi-

tively.

Variation Points. They are part of the variability

model and deﬁne speciﬁc modiﬁcations to be ap-

plied to the base model during materialization.

They refer to base model elements via base mod-

els handles and are bound to VSpecs. The appli-

cation of the variation points depends on the reso-

lution for the VSpecs.

Existence Variation Point. It is a kind of variation

point that indicates the existence of a particular

object, link, or value in the base model. Its neg-

ative application involves deleting elements from

the base model.

Opaque Variation Point (OVP). It is a kind of vari-

ation point the impact of which on the base model

is user-deﬁned through a model transformation

language. OVPs allow extending and customizing

the semantic of the existing CVL variation points.

The complete description of CVL can be found in

http://www.omgwiki.org/variability/.

“Features” in most SPL approaches.

The AO main concepts that we use are:

Join Point. It is a point in the model (e.g. a method

call in an interface) which can be affected by the

crosscutting behavior.

Advice. It is the additional behavior that affects the

base program at the selected join points. There

are usually three kinds of advices based on ‘when’

the behavior takes place in reference to the join

points: before, after, and around. Around ad-

vices allow bypassing the execution of the cap-

tured join points.

Pointcut. It is an expression that describes a set of

join points.

4 SECURITY WEAVING

In order to incorporate a particular conﬁguration of

the security functionality into the base application of

our case study, we implement the weaving process us-

ing CVL and, concretely, using the OVPs of CVL. Be-

fore that, we need to customize the security software

architecture from the security requirements of our e-

voting application. Both processes, the selection of a

security conﬁguration and the weaving are performed

in the same step using CVL.

Figure 4 shows an instance of our proposal us-

ing the CVL approach with our case study and the

security speciﬁcations. The variability model for se-

curity is speciﬁed in an abstract level using VSpecs

(top of Figure 4). Security properties are decomposed

into choices in the VSpecs, indicating which secu-

rity concerns are optional and which are mandatory.

In our case study, for simplicity, security is decom-

posed only into the choices of Integrity, Access Con-

trol which in turn contains the Authentication and Au-

thorization concerns, and Cryptography that contains

the Encryption and Digital Signature concerns. Each

of them is also composed by the available methods

and algorithms. For instance, there are three kinds of

methods to verify the integrity of the data: Password

veriﬁcation, Data identiﬁer, and Hash veriﬁcation. The

last one can be performed by using the MD5 or the

SHA-1 algorithm. The resolution of all these choices

require a yes/no decision, and the security conﬁgura-

tion (the resolution model) is a selection of this set of

choices in the VSpecs — i.e. the security concerns

that are decided positively (darkened choices in Fig-

ure 4).

The concrete variability of security and the weav-

ing patterns are speciﬁed using variation points (mid-

dle of Figure 4): “object existence” variation points

to realize the variability and OVPs to do the weav-

AnAspect-OrientedModelTransformationtoWeaveSecurityusingCVL

141

Figure 4: Security conﬁguring and weaving using CVL.

ing. The object existence variation points are bound to

choices of the VSpecs and refer to components of the

security software architecture (bottom of Figure 4).

This kind of variation point indicates the existence of

a particular object (component) that will be included

or removed from the security software architecture

based on the resolution provided for the associated

VSpec. For instance, the variation point bound to

the Integrity concern in the VSpecs (:ObjectExistence)

indicates that if the Integrity choice is decided posi-

tively (i.e. is selected in the resolution model) in a

conﬁguration, the related elements (the Integrity com-

ponent and its interfaces with their attachments) in

the security software architecture will exist in the re-

solved model and if integrity is decided negatively

(i.e. is not selected in the resolution model) those

related elements will be removed from the resolved

model.

The OVPs are also bound to the VSpecs but have

two or more references in the base models: (1) one

reference (source objects) to the interface in the secu-

rity software architecture the behavior of which we

want to incorporate in our base application — i.e.

the advice, and (2) one or more references (target

objects) to the interfaces in the application software

architecture where we want to incorporate the secu-

rity concern — i.e. the join points. For instance,

OVP2 has a reference (sourceObject) to the Encryp-

tionInt interface in the security model and two targets

(targetObjects): one for encrypting (that references

to the EvotingInt interface in the application model)

and one for decrypting (that references to the Voting-

DataInt interface).

OVPs are also bound to an OVPType, where this

type explicitly deﬁnes the semantic of the special sub-

stitution — i.e. the transformation rules to weave the

security concerns into the base application. Each se-

curity concern needs to be woven with the base ap-

plication following a different transformation pattern

based on the aspectual information of the concern: the

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

142

kind of the advice that the concern implements: be-

fore, after, or around; the method (advice) that must

be executed by the concern; and the intercepted meth-

ods (join points) in the base application. So, using

CVL we need to use several variation points, with

different semantics, to indicate how the elements of

the models are adapted in order to generate the re-

solved model. During variability materialization, the

CVL engine will delegate its control to a M2M trans-

formation engine (ATL in our proposal) whenever it

encounters an OVP. The M2M transformation engine

executes the semantic speciﬁcation associated with

the OVP and resolves the variability accordingly.

The resolved model is automatically generated

(Figure 5) and the security conﬁguration is woven

with our application software architecture: the com-

ponents related to the security concerns are clearly

visible in the static part of the architecture, and the

relationships between the security elements and the

elements of the base application (“crosscuts” depen-

dency relationship) explicitly indicate that the sources

of the relationships crosscut the architectural level,

and the targets are the point of the application where

they take place. However, the aspectual information

with the interactions between the components is not

represented in the software architecture of Figure 5.

To complete the design we complement the software

architecture with a set of sequence diagrams that rep-

resent the aspectual information and that are also au-

tomatically generated by the weaving patterns (Pinto

et al., 2009). The following section shows the weav-

ing patterns, in detail, for each security concern.

5 SECURITY WEAVING

PATTERNS

The nature of each security concern avoids having to

have a unique and homogeneous weaving pattern. As

we explained in the previous section each concern

needs different aspectual information and the weav-

ing patterns (i.e. the transformation rules) needed to

perform the weaving are different.

The semantic speciﬁcation associated with each

OVP must include transformation rules to: (1) in-

corporate the security components into the software

architecture of the base application; (2) create the

“crosscuts” relationships between the interface of the

concern (the advice) and the interface of the applica-

tion where the crosscuts take places (the join point);

and (3) generate the sequence diagram that represents

the behavior of the crosscutting relationship.

We deﬁne a set of ATL transformations for each

of the security concerns: authentication, encryption,

authorization, integrity, and digital signature. Weav-

ing patterns for other security or crosscutting con-

cerns may be deﬁned in a similar way. To perform

the weaving between the models, each ATL transfor-

mation takes as input the two models (the application

model and the security model) and generates as output

the same application model with the appropriate secu-

rity concern merged. The elements of the application

model remain unchanged in the output model. So, we

can focus on the generation of the security elements

in the ATL transformations.

The transformation rules (weaving patterns) are

deﬁned only once and can be reused in each appli-

cation. However, there is speciﬁc information of the

base application that the software architect must pro-

vide because it is different for each application. For

instance, the software architect must deﬁne the con-

crete pointcuts (e.g. the method signature) for the

join points in the base application. To simplify the

case study, we only use method call/execution point-

cut designators. In order to make the transformation

rules more reusable, we deﬁne the aspectual informa-

tion as attributes (helpers) in ATL that must be ﬁlled

in for each application with the signature of the inter-

cepted method by the crosscut relationship.

5.1 Authentication

The semantic of the special substitution for the au-

thentication concern is shown in the Listing 1. The

transformation rule: (1) copies the authentication se-

curity elements: the component (sourceComp) and

interface (sourceInt) from the SecurityModel to the

application model (AppModel in the rule); (2) cre-

ates the “crosscut” relationship between the source

(sourceInt) and the target (targetInt) interfaces; and

(3) generates the sequence diagram with the interac-

tions between the authentication and the base applica-

tion elements.

The aspectual information is coded in the trans-

formation pattern and is used to generate the inter-

actions. For instance, to generate the authentication

sequence diagram we use a called rule of ATL with

the aspectual information: the intercepted method

vote(Object) (provided with the helper operation), the

advice (‘authenticate()’), and the kind of the advice

(‘around’), apart from the interfaces and components

related.

The sequence diagram generated is shown in

Figure 6. Authentication is usually performed before

a method call, however we use an around advice in

order to abort the call to the method vote(Object) if

the authentication fails.

AnAspect-OrientedModelTransformationtoWeaveSecurityusingCVL

143

Figure 5: Application with security functionality woven.

Listing 1: SemanticSpec1 (SpecialSubstitutionAuthen)

module a uth e n t ica t i on ;

create OU T : U ML from A p pMo d el : UM L ,

Sec u r ity M o del : U ML ;

rule A uth e n t ica t i on {

from s ou r c eI n t : U ML ! I n ter f ace in Sec uri t yM o de l ,

sou r c eC o m p : UML ! C omp o nen t in S e cu r it y Mod e l ,

tar g etI n t : U ML ! I nte r fac e in A pp Mod el ,

( s o u rc e I nt . name = ‘ Au t hen t ica t io n I nt ’ an d

sou r c eC o m p . na me = ‘ Au the n tic ati o n ’ and

tar g etI n t . na me = thisModule. ta r g etO b j ect )

to s ecu r i tyC o m p : UML ! C omp o nen t ( .. . ) ,

sec u r ity I nt : UML ! I nt e r fac e ( .. . ) ,

cro s s cut A s soc : UML ! D epe n d en c y (

cl i ent < - s o ur ceI nt ,

sup p li e r <- t ar g et Int , . .. )

do { c ros s c utA s s oc . a ppl y S ter e o t ype (

thisModule. ge t S ter e o typ e ( ‘ c ro s sc uts ’ ) ) ;

thisModule. Cr e a t eAut h I n ter a c t i on ( ta rge tI nt ,

so urc eIn t , sou rc e Co mp , ‘ a ro un d ’ ,

thisModule. o per at ion , ‘ au t h en t i cat e () ’) ;}

}

5.2 Encryption

The semantic of the special substitution for the en-

cryption concern (Listing 2) is different since it

uses two different advices (‘encrypt(Object)’ and ‘de-

crypt(Object)’) in two different points of the appli-

cation. The votes are encrypted in the vote(Object)

method of the EVotingInt interface (provided by

the operEncrypt helper), and are decrypted in the

getVote() method of the VotingDataInt interface (pro-

Figure 6: Authentication sequence diagram.

vided by the operDecrypt helper). The transformation

rule automatically generates two different sequence

diagrams with that information: one for encrypting

(Figure 7) and one for decrypting (Figure 8).

Listing 2: SemanticSpec2 (SpecialSubstitutionEncrypt)

module e ncr y pti o n ;

create OU T : U ML from A p pMo d el : UM L ,

Sec u r ity M o del : U ML ;

rule E ncr y pti o n {

from s ou r c eI n t : U ML ! I n ter f ace in Sec uri t yM o de l ,

sou r c eC o m p : UML ! C omp o nen t in S e cu r it y Mod e l ,

tar g e t Enc r y p In t : UM L ! Int e rfa c e in App Mo del ,

tar g e t Dec r y p In t : UM L ! Int e rfa c e in App Mo del ,

( s o u rc e I nt . name = ‘ En cry p ti o nI n t ’ and

sou r c eC o m p . na me = ‘ E n cr y pt ion ’ a nd

tar g e t Dec r y p In t . n ame = thisModule.

tar g e tOb j e ct1 a nd

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

144

tar g e t Enc r y p tIn t . n am e = thisModule.

tar g e tOb j e ct2 )

to s ecu r i tyC o m p : UML ! C omp o nen t ( .. . ) ,

sec u r ity I nt : UML ! I nt e r fac e ( .. . ) ,

cro s s c utA s s oc1 : UML ! D epe n den c y (

cl i ent < - s o ur ceI nt ,

sup p li e r <- t a rge t Enc r yp t I nt , ... ) ,

cro s s c utA s s oc2 : UML ! D epe n den c y (

cl i ent < - s o ur ceI nt ,

sup p li e r <- t a rge t Dec r yp t I nt , ... )

do { c ros s c utA s s o c1 . a pp l y S ter e o t ype (

thisModule. ge t S ter e o typ e ( ‘ c ro s sc uts ’ ) ) ;

cro s s c utA s s oc2 . app l y Ste r e o typ e (

thisModule. ge t S ter e o typ e ( ‘ c ro s sc uts ’ ) ) ;

thisModule. Cr e a t e Enc r y p t Int e r a c tio n (

tar g et E n cr y ptI n t , s ou r ce Int , s our ceC om p ,

‘ ar ou nd ’ , thisModule. op e rE n cr y pt ,

‘ e ncr y pt ( O b jec t ) ’) ;

thisModule. Cr e a t e Enc r y p t Int e r a c tio n (

tar g et D e cr y ptI n t , s ou r ce Int ,

so u rc eCo mp , ‘ a ro un d ’,

thisModule. o p er D ec r yp t ,

‘ d ecr y pt ( O b jec t ) ’) ; }

}

Figure 7: Encryption sequence diagram for encrypting.

Figure 8: Encryption sequence diagram for decrypting.

5.3 Digital Signature

The weaving pattern for the digital signature concern

is very similar to the encryption pattern, but we only

need the ‘sign(Object)’ advice. We use an after advice

to sign the votes in the server side after sending them

in order to prevent device clients with lower resources

from casting their votes. The sequence diagram of

Figure 9 shows that the advice ‘sign(Object)’ is per-

formed after the execution of the method vote(Object).

Figure 9: Digital signature sequence diagram.

5.4 Integrity

The integrity concern guarantees the votes belong to

an eligible voter. The weaving pattern is also similar

to the encryption pattern. We use an around advice

over the method storeVote(Object) of the VotingStor-

eInt interface with the purpose of verifying the au-

thenticity of the vote and rejecting it if the vote be-

longs to an invalid voter (see the sequence diagram of

Figure 10).

Figure 10: Integrity sequence diagram.

5.5 Authorization

The authorization weaving pattern is similar to the au-

thentication case, and in most security approaches the

authorization concern is based on different authenti-

cation mechanisms. In our e-voting application we

use a before advice in order to grant or deny permis-

sions to access privileged data of the election process.

The sequence diagram (Figure 11) shows that the au-

thorization logic veriﬁes the permissions of the ad-

ministrator before calling any method of the VotingM-

ngInt interface.

6 RELATED WORK

Security is usually achieved in several ways, but most

of the approaches present the security as a set of non-

AnAspect-OrientedModelTransformationtoWeaveSecurityusingCVL

145

Figure 11: Authorization sequence diagram.

functional properties, instead of focusing on the func-

tional part of the security concerns as we do. For in-

stance, in (Georg et al., 2002), the authors analyze the

impact of security properties on other functional con-

cerns of the base application using an AO approach.

Model Driven Engineering (MDE) has also been

used in the ﬁeld of SPLs (Sijtema, 2010). Sijtema

proposes a strategy to let ATL handle the variability

by extending the concrete syntax of ATL with the con-

cept of variability rules. Variability rules are used in

the context of a transformation sequence which suc-

cessively reﬁnes models. However, they ﬁrst model

the variability separately in a feature diagram and

have to make the correspondence between the feature

selections and the realization of the artefacts. In com-

parison with our proposal, using CVL we model the

variability and bind the features directly to the ele-

ments in the software architecture. We use the basic

ATL without the need to extend it, but our proposal

can also be used with other transformation languages

such as QVT or ETL (Epsilon Transformation Lan-

guage) (Kolovos et al., 2008).

Recently, CVL has been applied in multiple ap-

proaches. For instance, CVL is used to manage

the variability in the context of software processes

(Rouill

e et al., 2012), business process (Ayora et al.,

2012), or even for synthesizing an SPL using model

comparison (Zhang et al., 2011). In (Combemale

et al., 2012) CVL is used to specify and resolve the

variability of a software design, and the Reusable

Aspect Model (RAM) technique is used to specify

and compose the detailed structural and behavioral

design models corresponding to the chosen variants.

Our approach, in contrast, focuses on the architectural

level in the development process, and we perform the

weaving process with the CVL engine, instead of us-

ing an external RAM weaver.

7 CONCLUSIONS AND FUTURE

WORK

We have deﬁned a set of security weaving patterns

through model transformations in ATL that allows

the automatic incorporation of a customized security

model into the base application model by using CVL

and AOSD. CVL makes our proposal suitable for use

with any MOF based model. We have implemented

our proposal and used it with several case studies such

as the e-voting application presented in this paper or

in a vehicle-to-vehicle and vehicle-to-infrastructure

application that is another of the demonstrators of the

INTER-TRUST project. In all cases, we have used

UML as the modeling language for the software archi-

tectures and we conclude that our proposal improves

the modularity and reusability of both software archi-

tectures, the core architecture of the application and

the security software architecture.

As part of our future work, we plan to make the

transformation rules more reusable by using a third

binding model in the weaving patterns (Dur

an et al.,

2013). The binding model allows deﬁning the aspec-

tual information (e.g. pointcut deﬁnitions, advices)

as external parameters to use them in the transforma-

tion rules independently from the input models. We

also plan to take into account the existing dependen-

cies between the security concerns (e.g. authentica-

tion is usually needed by the authorization concern),

and how these dependencies affect the weaving pat-

terns and the sequence diagrams when two or more

concerns are applied in the same point of the appli-

cation. Moreover, we plan to deﬁne weaving patterns

for other crosscutting concerns such as usability, per-

sistence, context-awareness, etc.

ACKNOWLEDGEMENTS

Work supported by the European Project INTER-

TRUST 317731 and the Spanish Projects TIN2012-

34840 and FamiWare P09-TIC-5231.

REFERENCES

Ayora, C., Torres, V., Pelechano, V., and Alf

erez, G. H.

(2012). Applying CVL to business process variabil-

ity management. In Proceedings of the VARiability

for You Workshop: Variability Modeling Made Use-

ful for Everyone, VARY ’12, pages 26–31, New York,

NY, USA. ACM.

Combemale, B., Barais, O., Alam, O., and Kienzle, J.

(2012). Using CVL to Operationalize Product Line

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

146

Development with Reusable Aspect Models. In

VARY@MoDELS’12: VARiability for You, Innsbruck,

Autriche. ACM. VaryMDE (bilateral collaboration

between Inria and Thales).

Durn, F., Zschaler, S., and Troya, J. (2013). On the reusable

speciﬁcation of non-functional properties in DSLs. In

Czarnecki, K. and Hedin, G., editors, Software Lan-

guage Engineering, volume 7745 of Lecture Notes in

Computer Science, pages 332–351. Springer Berlin

Heidelberg.

Georg, G., France, R., and Ray, I. (2002). An aspect-based

approach to modeling security concerns. In Proceed-

ings of the Workshop on Critical Systems Develop-

ment with UML, pages 107–120.

Haugen, O., Wa¸sowski, A., and Czarnecki, K. (2012).

CVL: common variability language. In Proceedings

of the 16th International Software Product Line Con-

ference - Volume 2, SPLC ’12, pages 266–267, New

York, NY, USA. ACM.

Jouault, F., Allilaire, F., B

ezivin, J., and Kurtev, I. (2008).

ATL: A model transformation tool. Sci. Comput. Pro-

gram., 72(1–2):31–39.

Kolovos, D., Paige, R., and Polack, F. (2008). The ep-

silon transformation language. In Vallecillo, A., Gray,

J., and Pierantonio, A., editors, Theory and Practice

of Model Transformations, volume 5063 of Lecture

Notes in Computer Science, pages 46–60. Springer

Berlin Heidelberg.

Pinto, M., Fuentes, L., Fernndez, L., and Valenzuela, J.

(2009). Using AOSD and MDD to enhance the ar-

chitectural design phase. In Meersman, R., Herrero,

P., and Dillon, T., editors, On the Move to Meaning-

ful Internet Systems: OTM 2009 Workshops, volume

5872 of Lecture Notes in Computer Science, pages

360–369. Springer Berlin Heidelberg.

Rouill

e, E., Combemale, B., Barais, O., Touzet, D.,

and J

equel, J.-M. (2012). Leveraging CVL to

Manage Variability in Software Process Lines. In

Asia-Paciﬁc Software Engineering Conference, Hong

Kong, Chine.

Sijtema, M. (2010). Introducing variability rules in atl

for managing variability in MDE-based product lines.

Proc of MtATL, 10:39–49.

Zhang, X., Haugen, O., and Moller-Pedersen, B. (2011).

Model comparison to synthesize a model-driven soft-

ware product line. In Software Product Line Confer-

ence (SPLC), 2011 15th International, pages 90–99.

AnAspect-OrientedModelTransformationtoWeaveSecurityusingCVL

147