An approach for constructing a domain definition

metamodel with ATL

Vanea Chiprianov, Yvon Kermarrec, Patrick Alff

To cite this version:

Vanea Chiprianov, Yvon Kermarrec, Patrick Alff. An approach for constructing a domaindefinition metamodel with ATL. 1st International Workshop on Model Transformation withATL, Jul 2009, Nantes, France. 2009. <hal-00460182>

HAL Id: hal-00460182

https://hal.archives-ouvertes.fr/hal-00460182

Submitted on 26 Feb 2010

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinee au depot et a la diffusion de documentsscientifiques de niveau recherche, publies ou non,emanant des etablissements d’enseignement et derecherche francais ou etrangers, des laboratoirespublics ou prives.

An Approach for Constructing a DomainDefinition Metamodel with ATL

Vanea Chiprianov1,3, Yvon Kermarrec1,3 and Patrick D. Alff2

1 Institut Telecom, Telecom Bretagne, UMR CNRS 3192 Lab-STICCTechnopole Brest Iroise, CS 83818 29238 Brest Cedex 3, France{vanea.chiprianov},{yvon.kermarrec}@telecom-bretagne.eu

2 BT-North America, 2160 E. Grand Ave, El Segundo, CA 90245, United States3 Universite europeenne de Bretagne, France

Abstract. Present day Telecommunications competitive market requiresa rapid definition process of new services. To ensure this, we proposeto replace the current paper-based process with a computer-aided one.Central to this later process is an information model that captures do-main specific knowledge. We approach its construction by defining modelquerying and model transformation rules in ATL over existing networkabstraction layers. We also report on the way we used ATL to definethese rules and the benefits of doing so, and pinpoint issues that may beaddressed in future ATL releases.

1 Introduction

Present day Telecommunications customer-centric market is characterized by ahigh demand rate for new services and fierce competition. To remain competitive,service providers need to speed up their service definition process by shorten-ing the concept-to-market time and designing the product right-the-first-time.Currently, this is a paper-based process, relying mainly on trays of documentsbeing exchanged between service designers and programmers. We propose toreplace this process with a computer-aided one, which will iteratively capturedomain specific knowledge in a Domain Definition Metamodel (DDMM) (thecentral entity in Fig. 1; in this figure we represent with filled ellipses what wehave already done; in parentheses we indicate the toolkit we used). A DDMMprovides a sharable, capitalizable, stable and organized structure of information.

Starting from the DDMM, we can define one or several Domain SpecificLanguages (DSLs) (Sect. 2) which increase the performance of service designers.The DDMM can support the service designers in their collaborative work whendefining a new service. It can also be used for verifying properties on models thatwere defined using the aforementioned DSL. Therefore, as highlighted by [1] also,the DDMM is central to our approach. It is essential that it is wide enoughto provide the majority of the concepts service designers need, but also that itis formal and close enough to existing Network Abstraction Layers (NALs) toenable mapping of service specific concepts with network specific components.

Domain DefinitionMeta-Model (UML)

NetworkAbstraction

Layer

ConcreteGraphical/(Topcased)

Textual(TCS)

DSL Syntax

DomainSpecialists

Colaborative Work

GeneralPurpose Programming

Language

ATL(Eclipse M2M)

Direct Mapping(TOPCASED)

FAST

FODA

Domain Analysis

Composition

Code Generation

DSL Syntax D

efinition

Model Reduction

FormalMethods

UMLState

Machines

KnowledgeBase

Templates(OpenArchitectureWare)

ATL(Eclipse M2M)

Prototype(TOPCASED)

Graphical(Topcased)/

Textual(TCS)

Fig. 1. Telecommunications-specific Modeling

Consequently, we decided to construct the DDMM by simplifying existing NALs(Sect. 4) and it constitutes the main focus of this document. The approach ofextracting only the relevant aspects of an information model for the generation ofDSLs has already been used, for example by [2]. However, their method consistsin tagging the information model, whereas we construct a new model by applyingtransformation rules.

An NAL captures a lot of information, among which there is a big part ofthe service domain, but in a much more detailed manner than necessary for adesigner (an NAL can have tens of thousands of entities, while the service do-main has hundreds of concepts). This introduces an additional complexity. Thesolution is to present the users only the information that is pertinent for them.By eliminating most of the entities that are unknown to service designers andshrinking the inheritance hierarchies, we elaborate such a model. Some NALsare expressed as large class models in UML, so we use model querying (Sect.3) and transformation techniques and write the model querying and transfor-mation rules using ATL [3] (Sect. 4.2). Because we define more than queries onthe input model, changing relations, we go beyond model querying, into modeltransformation.

2 A Simple Graphical Telecommunications SpecificModeling Language (SGTSML)

If we consider the DDMM corresponding to the abstract syntax of a language(for more details of language definition using model-based tools see [4]), we candefine a modeling language for service definition and generate tools for it (e.g.;graphical or textual editor). Moreover, if needed to describe disparate aspects ofthe service (e.g.; structural, behavioral), the DDMM can be augmented with theinformation needed to define several DSLs. Sharing the DDMM between severalDSLs ensures a consistent view. A similar approach has already been proposedby [2] for policy specification.

We approached the definition of the DDMM with an iterative method inmind, so we started with a simple prototype. This prototype is aimed at defin-ing a simple virtual private network (Fig. 2). The prototype consists of a Net-work, which may contain several inner networks and several Nodes. The nodesare either Computers, Internet or Routers; they are connected by links whichconstitute outlinks for the source nodes, and inlinks for the target nodes. Therouters can be either customer edge routers (CE) or provider edge routers (PE).Each PE and CE has an Interface, which contains a virtual routing and for-warding (VRF) table containing the VrfRouteTargets and information about theneighboring PEs (BgpIpv4AddressFamilyNeighbors). PEs use the Border Gate-way Protocol (BgpRoutingProtocol) to communicate with each other. We alsoenriched the DDMM with validation rules [5], thus enabling domain level valida-tion. As tool for defining the DDMM we chose TOPCASED [6], a strongly modeloriented system engineering toolkit for critical and embedded applications.

For the concrete syntax (see filled ellipses on the right top of Fig. 1) weconsidered that a graphical syntax would be much easier to use by service de-signers, as it provides a synthetic, high-level view of the system being considered.Therefore, we defined one using TOPCASED, which has a feature that allowsautomatic generation of graphical editors for DSLs based on their Metamodel(MM). Using TOPCASED, we also generated the graphical editor for SGTSML.

To describe the semantics of our SGTSML we decided to use the semanticsof an existing general purpose object-oriented programming language, Smalltalk.Consequently, we defined template-based code generation rules towards Smalltalk,using OpenArchitectureWare [7]. More details about the definition of SGTSMLcan be found in [5].

3 Model Querying and Transformation

UML class models can quickly become very large, comprising thousands ofclasses. Viewing the entire model imposes a high cognitive charge on design-ers. They usually need to concentrate only on the classes related to a precisefunctionality (i.e.; a model slice).

Model slicing, as introduced in [8], is a model querying technique, rooted inthe classical definition of program slicing, but extends it to UML class models.

Networkname : EString

Node

Computername : EStringipAddress : EStringportNb : EInt

setPortNb (EInt)

InternetRouter

name : EStringipAddress : EString

configureIpAd... () : ...removeIpAd... () : ...

CE PE

VRFvrfName : EStringrouteDistinguisher : EString

configureVrf () : EIntremoveVrf () : EInt

VrfRouteTargetrouteTarget : EString

configureRt () : EIntremoveRt () : EInt

BgpIpv4AddressFamilyNeighborremoteAsNumber : EIntneighborIpAddress : EString

configureBgpNeighbor () : EIntremoveBgpNeighbor () : EInt

BgpRoutingProtocollocalAsNumber : EInt

InterfacenetMask : EString

attachVrf (VRF) : EIntdetachVrf (VRF) : EInt

innerNetworks0..*

nodes0..*

inLinks0..*

outLinks0..*

attachedToInterfaces

1..*

vrfRouteTargets

1..*

familyNeighbors 1..*bgpRoutingProtocol

1..*

customerFacingInterface

1vrf0..1

attachedVrf1

providerFacingInterface

1

Domain DefinitionMeta-Model (UML)

Prototype(TOPCASED)

Fig. 2. Abstract Syntax of SGTSML

Program slicing, as defined by [9], applies a slicing criteria on a program tocompute a slice (i.e.; a subset of the source code). Model slices are as well definedusing a slicing criterion that is specified with predicates over the model’s features.Consequently, model querying and model slicing in particular constitute a goodstarting point for our approach. However, because we will change elements in theoutput model (e.g.; for hierarchy shrinkage we will change the parent class in ageneralization relation), we need mechanisms more powerful than just querying,we need model transformations.

As we mentioned in Sect. 1, we construct the DDMM by eliminating classesand shrinking inheritance hierarchies from NALs expressed as UML class models.We think that the most significant reductions will be due to hierarchy shrinkage.Therefore, we are particularly interested in hierarchy shrinkage methods. A morefocused technique of program slicing is the class hierarchy slicing. An algorithmfor slicing class hierarchies in C++ programs is described in [10]. This algorithmeliminates from an C++ class hierarchy the data and function members, classesand inheritance relations that are unnecessary for ensuring that the semanticsof a program P that uses the hierarchy is maintained. However, this type ofalgorithm is context-sensitive, as it needs the program P that uses the hierarchy.The DDMM that we build is intrinsically context-free, as it has no knowledge andshould not depend on the future models that will be defined using it. Therefore,such an approach is not suitable for us.

4 Enlarging the Domain Definition Metamodel

As we argued in Sect. 1, the DDMM is central for our approach. We startedby defining a simple prototype, presented in Sect. 2. In order to enlarge theDDMM, we considered using domain analysis methods such as Family-orientedAbstractions Specification and Translation [11] or Organization Domain Mod-eling version 2 [12]. However, these methods require a lot of time. Moreover,the models defined using the language constructed around the DDMM shouldbe easy to map towards existing models of network components (i.e.; NALs).Consequently, we decided to start from an NAL, specified as a large UML classmodel (Fig. 3), and define model querying (Sect. 3) rules such that the outputmodel will correspond to the needs of service designers.

Ecore

UML UML

NAL (LargeHierarchy) DDMM (SmallHierarchy )

HierarchyReduction

ATL

Fig. 3. Model Transformation

In Fig. 3, we exemplify the NAL through an UML class model called Large-Hierarchy. LargeHierarchy conforms to its MM, which is UML. The UML MMcan be written in several MM definition languages: MOF4, Ecore5, etc. We in-dicate here Ecore because we use Eclipse Modeling Tools6 as toolkit and, con-sequently, the UML MM written in Ecore7. The output MM is also UML, andwe call the output model SmallHierarchy, which is an example of a DDMM.Because the transformation has the same metamodel (i.e.; UML) for input andoutput, it is an endogenous transformation [13]. The transformation rules arewritten in the module HierarchyReduction, in ATL.4 http://www.omg.org/technology/documents/modeling spec catalog.htm#MOF5 http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/org/eclipse/emf/ecore/

package-summary.html#details6 http://www.eclipse.org/downloads/packages/

eclipse-modeling-tools-includes-incubating-components/ganymedesr17 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org.eclipse.uml2/plugins/

org.eclipse.uml2.uml/model/UML.ecore?root=Modeling Project&view=log

The example we chose to illustrate the NAL, LargeHierarchy, is presentedin Fig. 4. On one hand, an NAL’s components are entities with attributes butno methods. The most frequent types of relation between these components areassociation and generalization. On the other hand, the service designers describea service as a chain of calls to entities named capabilities, much as calls tofunctions. Therefore, a preliminary operation of mapping the capabilities (somehundreds) on the entities of the NAL (some tens of thousands) is done manually.This results in some of the NAL’s classes having methods. They are representedin LargeHierarchy by the classes B, C, E, F, G, H. These classes will be part ofthe DDMM. We call this type of NAL classes, that after slicing appear in theDDMM, generators.

PackagePackage

A

attributesoperations

classes

C

attributesoperations

M2( )classes

M

attributesoperations

classes

N

attributesoperations

classes

O

attributesoperations

classes

B

attributesoperations

M1( )classes

P

attributesoperations

classes

X

attributesoperations

classes

Q

attributesoperations

classes

E

attributesoperations

M3( )M4( )

classes

G

attributesoperations

M11( )classes

R

attributesoperations

classes

F

attributesoperations

M10( )classes

H

attributesoperations

M12( )classes

srcdst

srcdst

srcdst

Generalization

Association

Fig. 4. Example of NAL: Large Hierarchy

The model transformation rules are presented, written in natural language,in Sect. 4.1 and written in ATL, in Sect. 4.2. The output model resulted fromapplying the model transformation rules on LargeHierarchy is presented in Fig.5. We call it SmallHierarchy and it constitutes an example of DDMM. Onecan observe that all classes from LargeHierarchy that have at least one method(i.e.; B, C, E, F, G, H ) exist in SmallHierarchy too. The initial relations betweenthem (e.g.; the association relation from F and G and the generalization relationbetween F and H ) also appear in the output model. The most interesting relationin SmallHierarchy is the association from classes B and C, resulted from theshrinkage of the initial hierarchy between A and B.

PackagePackage

C

attributesoperations

M2( )classes

B

attributesoperations

M1( )classes

E

attributesoperations

M3( )M4( )

classes

G

attributesoperations

M11( )classes

F

attributesoperations

M10( )classes

H

attributesoperations

M12( )classes

src

dst

src

dst

srcdst

Generalization

Association

Fig. 5. Example of DDMM: Small Hierarchy

4.1 Model Transformation Rules

Our main idea for querying an NAL is to start from a set of initial generators (i.e.;the classes that have at least one method) and select as generators other classesthat are related to the initial generators in a way that is relevant for servicedesigners. The types of relation between classes from NAL, that we considerimportant for service designers, are association and generalization.

The rule to select the set of initial generators, in natural language:

1. Select all classes from NAL that have at least one method.

The rules for selecting associations, in natural language:

1. Select all direct associations from NAL that relate two generator classes.2. We define the notion of least derived generator (ldSAG) as the generator

which, in a hierarchy that contain generators in a generalization relation, isthe highest in the hierarchy. Move association relations down in the hierarchy(i.e.; towards the more derived classes) to the least derived generator.

The rules for selecting generalizations, in natural language:

1. Select all direct generalizations from NAL that relate two generator classes.2. Select all generators implementing an abstract generator.

4.2 Model Transformation Rules in ATL

In this section we present the rules for model transformation, written in ATL.The rule to select the set of initial generators:

1 module HierarchyReductionUML ; −− Module Template2 c r e a t e SmallHierarchyUML : UML from LargeHierarchyUML :

UML;34 r u l e Package {5 from6 ps : UML! Package7 to8 pt : UML! Package (9 name <− ps . name)

10 }1112 r u l e Class {13 from14 cs : UML! Class (15 cs . ownedOperation−>notEmpty ( ) )16 to17 ct : UML! Class (18 name <− cs . name ,19 package <− cs . package ,20 ownedOperation <− opera t i onLst21 ) ,22 opera t i onLst : d i s t i n c t UML! Operation fo r each23 ( oper in cs . ownedOperation . asSequence ( ) ) (24 name <− oper . name)25 }

The rules related to association are DirectAssociation and moveAssocDown-Hierarchy:

1 r u l e D i r e c t A s s o c i a t i o n {2 from3 as : UML! Assoc i a t i on (4 thisModule . a l l Sag s−>i n c l u d e s ( as . memberEnd .

asSequence ( )−> f i r s t ( ) . type ) and5 thisModule . a l l Sag s−>i n c l u d e s ( as . memberEnd .

asSequence ( )−> l a s t ( ) . type ) )

6 to7 at : UML! As soc i a t i on (8 name<−as . name ,9 package <− as . package ,

10 memberEnd<−memberLst11 ) ,12 memberLst : d i s t i n c t UML! Property fo r each ( asMember

in as . memberEnd . asSequence ( ) ) (13 name<−asMember . name ,14 type<−asMember . type )15 }

The rule DirectAssociation uses the attribute allSags:

1 −−a t t r i b u t e s2 he lpe r de f : a l l S a g s : Set (UML! Class ) =3 l e t a l l C l a s s e s : Set (UML! Class ) = UML! Class .

a l l I n s t a n c e s ( ) in4 a l l C l a s s e s−>s e l e c t ( i | i . ownedOperation−>notEmpty ( ) ) ;

1 r u l e moveAssocDownHierarchy{2 −−moves an a s s o c i a t i o n3 −−does NOT promote an element to an SAG4 from5 ps : UML! Property (6 −−the source element should have i t s p a r t i c i p a n t in

a h i e ra r chy7 i f ( ps . ldSagToMoveAssocDownHierarchyTo = ’ ’ )8 −−the downHierarchy should have at l e a s t one SAG9 −−(to s i m p l i f y the problem , I con s id e r here only

the ldSAGs )10 then f a l s e11 e l s e12 i f ( ps . doesDownHierarchyContainSeveralLdSags ( ps .

ldSagToMoveAssocDownHierarchyTo ) )13 −−the h i e ra r chy should have only one ldSAG14 −−( i t can have a SAG on only one branch )15 then f a l s e16 e l s e t rue17 e n d i f18 e n d i f )19 us ing {20 targetLdSag : UML! Class = ps .

ldSagToMoveAssocDownHierarchyTo ;}21 to22 at : UML! As soc i a t i on (

23 −−in the t a r g e t model , we cons t ruc t an a s s o c i a t i o nbetween one i n i t i a l c l a s s and ,

24 −−i n s t ead o f the other c l a s s , from the hierarchy ,the ldSAG from i t s downHierarchy

25 name<−ps . a s s o c i a t i o n . name ,26 package <− ps . a s s o c i a t i o n . package ,27 memberEnd<−memberLst28 ) ,29 memberLst : d i s t i n c t UML! Property30 fo r each ( asMember in ps . a s s o c i a t i o n . memberEnd .

asSequence ( ) ) (31 name <− asMember . name ,32 type <− i f asMember=ps33 then asMember . type34 e l s e targetLdSag35 e n d i f )36 }

The rule moveAssocDownHierarchy exemplifies the fact that we go beyondmodel slicing. Not only that we select elements and relations from the inputmodel, but we also change attributes on some of these relations (e.g.; the typeof the memberEnd of the association is changed to the targetLdSag). This ruleuses the helpers ldSagToMoveAssocDownHierarchyTo, doesDownHierarchyCon-tainSeveralLdSags:

1 he lpe r context UML! Property de f :ldSagToMoveAssocDownHierarchyTo : UML! Class =

2 l e t otherMemberEnd : UML! Property =3 i f ( s e l f . a s s o c i a t i o n . memberEnd−>asSequence ( )−> f i r s t ( )

= s e l f )4 then s e l f . a s s o c i a t i o n . memberEnd−>asSequence ( )−> l a s t ( )5 e l s e s e l f . a s s o c i a t i o n . memberEnd−>asSequence ( )−> f i r s t

( )6 e n d i f7 in8 thisModule . ldSags−>i t e r a t e ( ldSag ; goodLdSag : UML! Class

= ’ ’ |9 i f ( ldSag . upperHierarchy−>i n c l u d e s ( otherMemberEnd .

type ) )10 then ldSag11 e l s e goodLdSag12 e n d i f ) ;1314 he lpe r context UML! Property de f :

doesDownHierarchyContainSeveralLdSags ( f i r s tLdSag : UML! Class ) : Boolean =

15 l e t otherMemberEnd : UML! Property =16 i f ( s e l f . a s s o c i a t i o n . memberEnd−>asSequence ( )−> f i r s t ( )

= s e l f )17 then s e l f . a s s o c i a t i o n . memberEnd−>asSequence ( )−> l a s t ( )18 e l s e s e l f . a s s o c i a t i o n . memberEnd−>asSequence ( )−> f i r s t

( )19 e n d i f20 in21 thisModule . ldSags−>i t e r a t e ( ldSag ; has : Boolean = f a l s e

|22 i f ( ldSag <> f i r s tLdSag )23 then24 i f ( ldSag . upperHierarchy−>i n c l u d e s ( otherMemberEnd .

type ) )25 then true26 e l s e has27 e n d i f28 e l s e29 has30 e n d i f ) ;

The helper doesDownHierarchyContainSeveralLdSags uses the attributes ld-Sags and upperHierarchy, the latter using at its turn the helpers ancestors andparents to navigate through the hierarchy:

1 he lpe r de f : ldSags : Set (UML! Class ) =2 l e t sags : Set (UML! Class ) = thisModule . a l l S a g s3 in sags−>s e l e c t ( sag | sag . upperHierarchy−>i t e r a t e (4 i ; no tEx i s t s : Boolean = true |5 i f ( sags−>i n c l u d e s ( i ) )6 then notEx i s t s = f a l s e7 e l s e notEx i s t s8 e n d i f ) ) ;9 −−sag . upperHierarchy−>exc lude sA l l ( sags ) ) ;

1011 he lpe r context UML! Class de f : upperHierarchy : Set (UML!

Class ) =12 s e l f . an c e s t o r s ( ) ;1314 he lpe r context UML! Class de f : a nc e s t o r s ( ) : Set (UML!

Class ) =15 l e t pars : Set (UML! Class ) = s e l f . parents ( ) in16 pars−>union (17 pars−>i t e r a t e ( parent ; ances t : Set (UML! Class ) = Set {}

|18 ancest−>union ( parent . an c e s t o r s ( ) ) ) ) ;

1920 he lpe r context UML! Class de f : parents ( ) : Set (UML! Class )

=21 l e t a l lGens : Set (UML! Class ) = s e l f . g e n e r a l i z a t i o n in22 al lGens−>i t e r a t e ( gen ; par : Set (UML! Class ) = Set {} |

par−>union ( Set {gen . g ene ra l }) ) ;

The rules related to generalization are DirectGeneralization and markAs-Sag:

1 r u l e D i r e c t G e n e r a l i z a t i o n {2 from3 gs : UML! Gene ra l i z a t i on (4 gs . g ene ra l . ownedOperation−>notEmpty ( ) and gs .

s p e c i f i c . ownedOperation−>notEmpty ( ) )5 to6 gt : UML! Gene ra l i z a t i on (7 genera l<−gs . genera l ,8 s p e c i f i c <−gs . s p e c i f i c )9 }

1 r u l e markAsSag{2 −−promotes an element to an SAG3 −−updates the allSAG and ldSAG l i s t s4 −−c r e a t e s an a s s o c i a t i o n to the new SAG5 −−c r e a t e s g e n e r a l i z a t i o n s to the new SAG ( i f nece s sa ry )6 from7 ps : UML! Property (8 i f ( ps . ldSagToMoveAssocDownHierarchyTo = ’ ’ )9 then f a l s e

10 e l s e11 i f ( ps . doesDownHierarchyContainSeveralLdSags ( ps .

ldSagToMoveAssocDownHierarchyTo ) )12 then true13 e l s e f a l s e14 e n d i f15 e n d i f )16 us ing {17 otherMemberEnd : UML! Property =18 i f ( ps . a s s o c i a t i o n . memberEnd−>asSequence ( )−> f i r s t

( ) = ps )19 then ps . a s s o c i a t i o n . memberEnd−>asSequence ( )−> l a s t

( )20 e l s e ps . a s s o c i a t i o n . memberEnd−>asSequence ( )−>

f i r s t ( )21 e n d i f ;

22 futureLdSag : UML! Class = otherMemberEnd . type ;23 auxLdSags : Set (UML! Class ) = thisModule . ldSags ;}24 to25 ct : UML! Class (26 name <− futureLdSag . name ,27 package <− ps . a s s o c i a t i o n . package28 ) ,29 at : UML! As soc i a t i on (30 name<−ps . a s s o c i a t i o n . name ,31 package <− ps . a s s o c i a t i o n . package ,32 memberEnd<−memberLst33 ) ,34 memberLst : d i s t i n c t UML! Property35 fo r each ( asMember in ps . a s s o c i a t i o n . memberEnd .

asSequence ( ) ) (36 name <− asMember . name ,37 type <− asMember . type )38 do{39 thisModule . a l l S a g s <− thisModule . a l l Sag s−>i n c l u d i n g (

futureLdSag ) ;40 thisModule . ldSags <− thisModule . ldSags−>i n c l u d i n g (

futureLdSag ) ;41 f o r ( ldSag in thisModule . ldSags ) {42 i f ( ldSag . upperHierarchy−>i n c l u d e s ( futureLdSag ) ) {43 auxLdSags<−thisModule . ldSags . exc lud ing ( ldSag ) ;44 thisModule . c r e a t e G e n e r a l i z a t i o n ( ldSag ,

futureLdSag ) ;45 }46 }47 thisModule . ldSags<−auxLdSags ;48 }49 }

The rule markAsSag uses the rule createGeneralization:

1 r u l e c r e a t e G e n e r a l i z a t i o n ( de : UML! Class , a : UML! Class ) {2 to3 gt : UML! Gene ra l i z a t i on (4 genera l<−a ,5 s p e c i f i c <−de )6 }

4.3 Preliminary performance results

In order to have an idea of the performance of the transformation, we did somepreliminary tests. We used as machine a Dell Latitude E4300, with an IntelCore2 Duo CPU P9300 @ 2.26GHz 1.58GHz, 3.45Go RAM, with Microsoft XPSP3. As input model we used the model presented in Fig. 4, which we dupli-cated several times to obtain a bigger model. Table 1 shows on each line a modelwith increasing dimensions. The ’Factor’ column represents the number of timesthe initial model has been duplicated. The column ’File’ represents the dimen-sion of the input model file, in bytes. The columns ’Classes’, ’Associations’ and’Generalizations’ represent the number of classes, associations and generaliza-tions respectively contained by each model. The column ’Execution time’ repre-sents the execution time, in seconds, of the transformation rules applied on eachmodel respectively. To measure the execution time we used the Eclipse facilities(Run→Run Configurations, Advanced tab, and select ’Run mode only: print ex-ecution times to console: 1) transformation only, and 2) total (including modelloading and saving)’; we mention that there was only one time printed at theconsole). The result of under 3 minutes for a model containing approximately20.000 entities encourages us to think that, when applied on industrial-scaleNALs, the transformation will have satisfactory execution times.

Crt. Factor File (B) Classes Associations Generalizations Execution time (s)1 1 6,105 14 2 8 0.0932 8 42,400 104 16 64 0.3123 64 306,348 832 128 256 6.54 1,024 2,120,162 14,336 2,048 8,192 161.531

Table 1. Performance results

5 Lessons Learned

High level of abstraction. We have found that using ATL to describe our modelquerying algorithm offers a high level of abstraction, especially when comparedto hierarchy slicing algorithms like the one presented in [10], due to its declarativeconstructions (i.e.; the matching of model elements).

Expressive code. The code written to implement the algorithm is much morecompact and expressive than if written in a general purpose programming lan-guage, like C++; this is a direct consequence of ATL being a DSL for modeltransformation.

Code modularization and change management. Rule definition provides astrong mechanism for code modularization (i.e.; a rule encodes by itself all thefunctionality) and change management (e.g.; adding new behavior to the algo-rithm is as simple as writing new rules).

Performance. The preliminary results we obtained encourage us to think ofATL as applicable to industrial-size models.

Tool support. ATL comes with a virtual machine, an editor with syntax high-lighting and code completion for metamodel elements, a debugger. Although suf-ficiently mature to support development, these tools have missing features thatwould increase their efficiency (e.g.; adding a breakpoint has to be done from theoutline view, there is no code completion for rules, attributes, helpers definedin the same module, no code completion for data types). Also, there are minorbugs (e.g.; the operation excludesAll on a collection does not work in the ATLversion8 we used - we had to find a workaround - see helper ldSags).

Functional programming style. The functional programming style (e.g.; usedto specify the conditions for matching) may be difficult for many programmers touse. Moreover, this programming style produces complex and long expressions,hard to read and understand. Having the documentation of an element appearas a tool tip when hovering over it may be highly useful.

Factorization limits. When comparing the rules moveAssocDownHierarchyand markAsSag, one observes that the from parts are very similar. We haveactually tried to write only one rule, but did not succeed. However, havingdifferent rules contributes to the modularity and readability of the code, as eachaddresses different functionality.

6 Conclusion and Future Work

In this work we were interested in defining a Domain Definition Metamodel(DDMM) for Telecommunications service definition by model querying and trans-forming large Network Abstraction Layers (NALs) expressed as UML models.We defined the querying and transformation rules in ATL, finding this approachwell suited. In the future, we intend to measure the performance of our modeltransformation rules on industrial-scale NALs (tens of thousands of classes). Wealso plan to evaluate the DDMM against service designers and use their inputto further enlarge and refine it.

References

1. Fahy, C., Davy, S., Boudjemil, Z., van der Meer, S., Loyola, J., Serrat, J., Strass-ner, J., Berl, A., de Meer, H., Macedo, D.: Towards an Information Model ThatSupports Service-Aware, Self-managing Virtual Resources. In: Proceedings of the3rd IEEE international workshop on Modelling Autonomic Communications En-vironments, Springer (2008) 102–107

2. Barrett, K., Davy, S., Strassner, J., Jennings, B., van der Meer, S., Donnelly, W.:A Model Based Approach for Policy Tool Generation and Policy Analysis. In:Proceedings of the IEEE Global Information Infrastructure Symposium. (2007)99–105

8 org.eclipse.m2m.atl.engine.vm 2.0.0

3. Bezivin, J., Dupe, G., Jouault, F., Pitette, G., Rougui, J.: First experiments withthe ATL model transformation language: Transforming XSLT into XQuery. In:2nd OOPSLA Workshop on Generative Techniques in the context of Model DrivenArchitecture. (2003)

4. Kurtev, I., Bezivin, J., Jouault, F., Valduriez, P.: Model-based DSL frameworks.In: OOPSLA ’06:. (2006) 602–616

5. Chiprianov, V., Kermarrec, Y.: Model-based DSL Frameworks: A Simple GraphicalTelecommunications Specific Modeling Language. In: Actes des 5 emes journeessur l’Ingenierie Dirigee par les Modeles. (2009)

6. Farail, P., Gaufillet, P., Canals, A., Le Camus, C., Sciamma, D., Michel, P., Cregut,X., Pantel, M.: The TOPCASED project: a Toolkit in Open source for CriticalAeronautic Systems Design. In: ERTS. (2006)

7. Features, C.: openArchitectureWare 4.2. Technical report, Eclipse (2007)8. Kagdi, H., Maletic, J., Sutton, A.: Context-Free Slicing of UML Class Models. In:

Software Maintenance, 2005. ICSM’05. Proceedings of the 21st IEEE InternationalConference on. (2005) 635–638

9. Weiser, M.: Program Slicing. In: Proceedings of the 5th international conferenceon Software engineering, IEEE Press Piscataway, NJ, USA (1981) 439–449

10. Tip, F., Choi, J., Field, J., Ramalingam, G.: Slicing class hierarchies in C++.ACM SIGPLAN Notices 31(10) (1996) 179–197

11. Coplien, J., Hoffman, D., Weiss, D.: Commonality and Variability in SoftwareEngineering. IEEE Softw. 15 (1998) 37–45

12. Simos, M., Anthony, J.: Weaving the Model Web: A Multi-Modeling Approach toConcepts and Features in Domain Engineering. In: ICSR ’98. (1998)

13. Mens, T., Van Gorp, P.: A taxonomy of model transformation. Electronic Notesin Theoretical Computer Science 152 (2006) 125–142