Assistance la conception de modles laide de contraintes

Marie de Roquemaurel , Thomas Polacsek , Jean-Franois Rolland Jean-Paul Bodeveix , Mamoun Filali IRIT CNRS, Universit de Toulouse {deroquemaurel, rolland, bodeveix, lali}@irit.fr, ONERA, Toulouse Thomas.Polacsek@onera.fr, Rsum. La conception systme est une des premires tapes du processus de conception dite amont. Lors de cette tape, il sagit de raisonner un haut niveau de granularit (en faisant abstaction du code) en terme des fonctionnalits implanter et de larchitecture cible. Pour assister cette phase de conception, nous proposons une approche base sur les techniques de lIDM. Le passage lchelle de cette approche est envisag laide doutils issus de la programmation par contraintes. Nous avons adopt le mta modle Ecore pour la description des modles et le langage OCL pour lexpression des contraintes. Nous prsentons dans cet article des approches diffrentes pour exprimer le problme des contraintes sur un modle, puis nous exposons les apports dune approche dans la ligne de la programmation par contraintes.

Introduction

Dans la modlisation oriente objet, les modles graphiques, comme le diagramme de classe, ne sont pas sufsamment expressifs pour pouvoir exprimer lintgralit dune spcication prcise. Si de plus en plus doutils intgrent le langage OCL OMG (2006), pour Object Constraint Language, nous nous sommes rendus compte que face des modles issus du monde aronautique et du monde spatial un vritable problme de performances se pose. Nous allons ici voir des approches diffrentes pour exprimer le problme des contraintes sur un modle, puis, prsenter les apports dune approche dans la ligne de la programmation par contraintes. Dans la seconde partie de cet article, nous dressons une liste des principaux outils qui intgrent le langage OCL. La troisime partie prsente un exemple de problme de sret de fonctionnement. La quatrime partie sintresse au problme de vrication dun modle. Nous traduisons lexemple en un problme dIngnierie dirige par les Modles puis nous prsentons le problme du passage lchelle o comment, sur de grosses instances de modle, linterprtation de requtes OCL savre peu performante ainsi que les possibilits dune rcriture vers Java. La cinquime partie introduit notre approche qui cherche exprimer le problme de validation de modle suivant des contraintes OCL en un problme de satisfaction

Assistance la conception de modles laide de contraintes de contraintes. Nous dcrivons notre mthode et nous montrons comment elle permet de rsoudre lexemple. Puis nous prsentons une fonctionnalit qui dcoule directement de notre approche, la possibilit de complter un modle pour quil valide des contraintes donnes et de prendre en compte un critre minimiser. Enn, la dernire partie montre comment on peut automatiser le processus de traduction dun modle et dune contrainte et prendre en compte les rsultats du solveur au niveau modle.

Exprimer des contraintes

Les modles graphiques malgr leur expressivit ne sufsent gnralement pas pour exprimer toute la complexit de ce quils reprsentent, il est souvent ncessaire de dcrire des contraintes supplmentaires sur les objets des modles. Dans ce cas, ces contraintes sont souvent dcrites en langage naturel. Cependant, la spcication en langage naturel soulve bien des problmes dambigut. Pour faire face cela, des langages formels de spcication de contraintes ont t dvelopps. Gnralement ces langages utilisent des notations complexes qui ncessitent une connaissance mathmatique de la part de ceux qui les utilisent, ce qui peut prsenter un problme majeur si le but de la modlisation est dtre compris et utilis par des acteurs diffrents. Le langage OCL a t dvelopp pour combler cette lacune. Cest un langage formel de modlisation qui a t conu pour tre facile lire et crire. Dans notre approche, nous avons adopt le mtamodle Ecore 1 pour la description des modles et le langage OCL pour lexpression des contraintes. OCL est un langage purement descriptif, par consquent, une expression OCL est sans effet de bord : elle naffecte pas le modle. Il faut bien comprendre que sil est possible dexprimer des contraintes respecter, par contre, le langage ne permet pas dexprimer la faon de programmer une mthode. Dans le cadre dune modlisation objet, le langage OCL sert principalement : dnir des invariants sur les classes ; dcrire les pr et post conditions sur les oprations et les mthodes ; dcrire les gardes sur les transitions dans les diagrammes dtats ou sur les messages dans les diagrammes de squences et de collaborations ; dnir des strotypes. Millan et al. (2009) proposent aussi dutiliser OCL pour contrler la cohrence entre plusieurs modles. Mme si OCL fait totalement partie de lUML, lintgration de celui-ci dans les outils de modlisation ne sest pas encore gnralise. De plus, la smantique associe au langage OCL nest pas exactement la mme, en dautres termes limplmentation diffre, dun outil lautre. Gogolla et al. (2008) tudient diffrentes implmentations et les diffrences de rsultats dune implmentation une autre. Leur tude est mise disposition par Buttelmann et al. (2008). Nous allons ici prsenter certains dentre eux issus, pour la plupart, du monde acadmique. Le Model Development Tools (MDT) est un plugin dvelopp dans le cadre du projet Eclipse. Il vise a fournir une implmentation gnrique paramtrable par un mtamodle dans le cadre industriel. Il fournit un ensemble doutils pour la modlisation et la manipulation de
1. Un mtamodle peut tre dni comme un modle dun langage de modlisation qui permet dexprimer des concepts communs lensemble des modles dun mme domaine. Ecore est un langage dcriture de mtamodles.

Marie de Roquemaurel et al.

mtamodle. Plus particulirement, le plugin MDT propose une implmentation dun valuateur OCL sur des modles exprims dans diffrents langages comme EMF 2 ou UML. Cette implmentation fournit des APIs en Java qui permettent notamment de construire, de valider et dinterprter une requte OCL sur une instance dun mtamodle exprim en EMF. Un autre plugin Eclipse pour la cration et lvaluation de contraintes OCL est RoclET prsent par Jeanneret et al. (2006a). Il comprend un diteur graphique pour les diagrammes de classe UML et pour les diagrammes dobjets. Il dispose dun diteur pour les chiers OCL qui ralise la vrication de type et dun interprteur OCL. RoclET est implment partir de transformations QVT 3 . Jeanneret et al. (2006b) proposent des oprations de refactoring du modle mettant automatiquement jour les contraintes OCL dpendant des lments de modlisation modis. USE (UML-based Specication Environment), dvelopp par Gogolla et al. (2007), est une application part entire qui permet de manipuler et dinterprter des contraintes OCL sur des mtamodles dnis directement dans le langage USE ou imports depuis dautres outils. Les langages de transformations de modles comme ATL, ou de mta modlisations comme Kermeta (Mottu et al. (2007)) utilisent OCL ou un langage trs proche pour dcrire des rgles de transformations. Il est possible de dtourner leur usage et de les utiliser comme interprtes OCL.

Un exemple tir des architectures de systmes embarqus

Cette section propose un problme issu de vrication de proprits darchitectures dans le cadre de la sret de fonctionnement que nous utiliserons dans les sections suivantes. Nous avons un systme dcompos en deux parties, une partie logique et une partie physique, et nous devons vrier certaines proprits de sret de fonctionnement. La partie logique de larchitecture correspond des instances de processus et leurs liens logiques et la partie physique aux processeurs et les bus les reliant. A cela, nous rajoutons une relation binaire qui apparie ensemble deux deux les lments de la couche logique ceux de la couche physique. Nous cherchons vrier que pour tous les liens logiques entre deux processus, il existe un chemin physique entre les deux composants physiques lis aux composants logiques. Nous focalisons notre exemple sur cette unique contrainte mais notons que, sans rentrer plus en dtail, dautres contraintes sont ncessaires, comme par exemple le nombre maximal de processus apparis sur un processeur, pour liminer les solutions triviales o tous les processus sont lis un unique processeur. Pour rsoudre ce problme, nous considrons une architecture o le chemin physique nest pas toujours unique et o il ne correspond pas toujours un lien logique et nous cherchons vrier quil existe pour chaque lien logique un chemin physique. Nous reprsentons ce problme darchitecture comme un problme de mapping entre deux graphes tel que le systme est dcompos en un graphe darchitecture logique Gl = Nl , Al et un graphe darchitecture physique Gp = Np , Ap o les nuds sont respectivement les
2. Eclipse Modeling Framework est un plugin pour lIDE Eclipse qui permet, partir de la dnition dun modle objet, de faciliter sa manipulation et de gnrer automatiquement lditeur de modles utilisateur. 3. Queries View Transformation est un standard, dni par lOMG, pour la transformation de modle. En ingnierie des modles une transformation de modle consiste passer dun modle A conforme un mtamodle M A en un modle B conforme un mtamodle M B.

Assistance la conception de modles laide de contraintes

processus et les processeurs et o les arcs sont respectivement les liens logiques et les bus. Nous allons dnir le mapping entre ces deux graphes de manire vrier facilement que pour tout arc logique a, il existe un arc ou une succession darcs physiques qui permettent daller de limage de la source de a limage de la destination de a. Ainsi, le mapping sera un morphisme du graphe darchitecture logique dans la fermeture rexive transitive du graphe darchitecture physique. Avant de dnir formellement le mapping, nous introduisons une relation qui nous permet de construire un ensemble de nuds successeurs. Dnition 1 (Relation) Soit un graphe G = N, A et un ensemble de nuds N N . La relation RG (N ) est lensemble des nuds destinations des arcs ayant leurs nuds sources dans N : RG (N ) = {d | s N (s, d) A}. La relation RG (N ) est lensemble des nuds accessibles par un ou une succession darcs partir des nuds de N , i.e. lensemble des nuds destinations des arcs de la fermeture rexive transitive de G et ayant leurs nuds sources dans N : RG (N ) = RG (N ) = {d | s N (s, d) A } avec G = N, A . Dnition 2 (Mapping simple) Le mapping simple est dni sur les nuds dun graphe logique Gl = Nl , Al dans un graphe physique Gp = Np , Ap par la fonction mapping : Nl Np telle que 4 : a Al , mapping(dst(a)) RGp (mapping(src(a))). Cette dnition correspond au morphisme du graphe Gl dans Gp . Dnition 3 (Mapping rexif transitif) Le mapping rexif transitif est dni sur les nuds dun graphe logique Gl = Nl , Al dans la fermeture rexive transitive G = Np , A p p du graphe physique Gp = Np , Ap par la fonction mapping : Nl Np telle que a Al , mapping(dst(a)) RG (mapping(src(a))). Cette dnition correspond au morphisme du p graphe Gl dans G . p

Vrier un modle

La phase de conception systme ncessite de raisonner un haut niveau de granularit (en faisant abstraction du code) en terme des fonctionnalits implanter et de larchitecture cible. Il sagit dexprimer et de prendre en compte des proprits globales lies au placement des fonctions sur larchitecture. Pour assister cette phase de conception, nous proposons de traiter lexemple par une approche base sur les techniques de lingnierie dirige par les modles, de mettre en vidence le problme de passage lchelle sur cet exemple puis daborder une piste doptimisation.

4.1

Notre exemple par lingnierie dirige par les modles

La gure 1 donne le mta-modle correspondant lexemple dcrit dans la section prcdente, cest--dire un problme de mapping entre deux graphes Gl = Nl , Al et Gp =
4. Nous dnissons src, respectivement dst, comme la source et la destination dun arc. Soit un graphe G, pour tout arc a de G, src(a) dsigne le nud source de larc a et dst(a) le nud destination de larc a.

Marie de Roquemaurel et al.

1..1 src N_l 1..1 name : EString dst 0..* 0..* ndl ndp prev 0..* next prev 0..*

next 0..* A_l name : EString 0..* arl Graphe

mapping 1..1

N_p 1..1 name : EString dst 1..1 src

A_p arp name : EString 0..*

0..*

F IG . 1 Mta-modle du problme de mapping entre deux graphes Gl = Nl , Al et Gp = Np , Ap Np , Ap . Nous cherchons vrier que pour tout arc a de Al , il existe un arc ou une succession darcs de A qui permettent daller de limage de la source de a limage de la p destination de a. Cette contrainte correspond exactement la dnition du mapping donne prcdemment. Cette contrainte peut scrire sous la forme dune formule mathmatique : x, y Nl : (x, y) Al mapping(y) {d | (mapping(x),d) A } et qui correspond un p morphisme du graphe logique dans la fermeture rexive transitive du graphe physique. Nous pouvons la traduire en OCL avec la notion de fermeture (borne dans notre cas par le nombre de nuds physiques) : Listing 1 Contrainte exprime en OCL
P o u r c h a q u e a r c l o g i q u e context A_l i n v : p a r t i r du mapping de l a s o u r c e de l ' a r c self . src . mapping l a f e r m e t u r e d e s n o e u d s a c c e s s i b l e s > closure ( x : N_p | x . next . dst ) d o i t c o n t e n i r l e mapping de l a d e s t i n a t i o n de l ' a r c > includes ( self . dst . mapping )

4.2

Le problme du passage lchelle

Comme nous lavons vu, le langage OCL permet dexprimer une contrainte et de tester si un modle la satisfait. Si le temps dvaluation par une machine ne pose pas rellement de problme sur des exemples simples et, plus prcisment, sur des modles peu volumineux, nous avons t confronts des problmes de performance avec des modles issus du monde aronautique et du monde spatial. Face a des modles de plusieurs milliers dobjets et des contraintes imbriquant plusieurs boucles, il nest pas toujours possible avec les valuateurs actuels de disposer dune rponse dans un temps acceptable. Aujourdhui, plusieurs pistes doptimisations sont envisages avec dun ct le travail de Snchez Cuadrado et al. (2008a) sur la formule OCL et de lautre celui de Mezei et al. (2006) sur les algorithmes dvaluation. Les travaux de Snchez Cuadrado et al. (2008b) ont mis

Assistance la conception de modles laide de contraintes

en vidence les diffrences de performances pour lvaluation dune formule OCL suivant la faon dont elle est forme. Ainsi, ils prconisent diffrentes techniques adhoc comme lusage du court-circuit, qui consiste ne pas valuer une expression qui ne peut pas modier le rsultat de lopration logique, pour les formules utilisant le and et le or. Nous allons illustrer ici le problme du passage lchelle laide de notre exemple et nous utilisons le mtamodle prsent dans la gure 1. Nous dnissons un N -modle comme un modle de notre exemple avec N instances de nuds logiques et de nuds physiques et N 2 arcs logiques et arcs physiques. Pour tester les performances dun interprteur OCL, nous utilisons Model Development Tools (MDT) avec la contrainte OCL portant sur les mappings de graphes logiques sur les graphes physiques. Pour viter toute optimisation due au fait que le mcanisme de court circuit nest pas implment dans les valuateurs nous nous intressons seulement des exemples o la contrainte est satisfaite. Plus N grandit, plus linterprteur a dobjets manipuler. Comme nous ne voulons pas seulement avoir des performances brutes, mais pouvoir les comparer ce que lon pourrait qualier doptimum, nous avons crit un programme Java qui est la traduction exacte de notre contrainte. Ce programme ne comporte pas doptimisation et nest pas gnr automatiquement. Nous pouvons considrer quil est un talon et quune solution idale pour la validation dun modle suivant des contraintes devrait nous donner les mmes temps de rponses. 104
Temps (millisecondes) OCL JAVA

20

40

60

80
2

Taille du modle (2N nuds et 2N arcs)

F IG . 2 Test de performance sur le problme de graphe

La gure 2 prsente lvolution du temps de rsolution mis par linterprteur OCL de MDT et par le programme Java qui traduit la contrainte teste pour diffrents N -modles. Ce graphique montre que linterprteur OCL est loin des performances idales et il nest plus capable de donner de rponses ds que le modle comporte une grande quantit dobjets. La diffrence de performance entre le code Java et linterprtation dune formule OCL quivalente nest pas inhrente MDT. En effet, les outils que nous avons pu tester qui ralisent une interprtation, et non une transformation vers un langage excutable, restent dans la mme chelle de grandeur en terme de temps pour la validation dune contrainte.

Marie de Roquemaurel et al.

4.3

Java, le problme de lexpressivit

Comme nous venons de le voir si le langage OCL est trs expressif, les diffrentes implmentations dinterprteurs qui existent prsentent un problme de performance face de gros modles avec des contraintes rcursives. Une solution possible serait dcrire directement des contraintes dans un langage compil. Si cette solution prsente lavantage dajouter un gain en temps dexcution, elle entrane une perte dexpressivit. Une contrainte crite dans un langage comme par exemple Java est beaucoup moins comprhensible quen langage OCL. Une piste possible, que nous avons voque, est dcrire des contraintes en OCL et de les traduire automatiquement en Java. Notons que traduire automatiquement le problme de validation dun modle en fonction de contraintes OCL en un programme excutable nest pas nouveau. Si la plupart des approches relvent de linterprtation, notons que ds 1999 Demuth et Hussmann (1999) cherchaient transformer des expressions OCL en SQL et Finger (2000) donnait les bases dune traduction vers Java. Depuis le langage OCL a volu et dautres travaux Octopus ont cherch formaliser une transformation de OCL vers du code excutable. En pratique, le plupart de ces approches vont vers Java. Ainsi, le projet Key de Ahrendt et al. (2003) fournit des mthodes de spcication et vrication de programmes dvelopps en utilisant UML. La spcication formelle utilise OCL et Key ralise la traduction de cette spcication vers un code excutable en Java Card. Citons aussi les travaux de Dzidek et al. (2005) qui tudie les diffrents problmes soulevs par la gnration de code partir dune formule OCL, mais leur outil, OCL2J approach, nest pas disponible. Notons que toutes ces approches restent pour le moment non exhaustives et aucun outil ne permet le passage de OCL Java sans aucune restriction. Parmi les projets existants, Dresden OCL2 semble nettement simposer, cette remarque sappuyant sur deux constats. Premirement la vitalit du projet qui contrairement Octopus fournit rgulirement des mises jour. Deuximement, Dresden OCL2 sert de base de nombreux projets importants comme : Borland Together, Poseidon ou Rational Rose. Dresden OCL2 Toolkit est un outil dvelopp par luniversit de Dresden qui permet de transformer un modle UML2, mtamodle de Eclipse Model Development Tools Project, ou un mtamodle Ecore avec ses contraintes OCL en Aspect Java. Cette transformation seffectue en essayant de traduire, autant que faire ce peu, les types OCL en types Java. Par exemple, le type Integer devient int, Real devient oat et Boolean devient boolean. Cependant, OCL dispose aussi de diffrentes collections Bag, OrderedSet, Sequence, et Set qui ne se traduisent pas de faon adquat dans des types Java existant. Cest pourquoi ils introduisent un plugin Eclipse, tudresden.ocl20.pivot.ocl2-java.types qui contient une implmentation en Java des collections de OCL. Si la piste dcrire des contraintes en OCL et de les traduire automatiquement en Java est prometteuse, nous aimerions dans la suite de cet article proposer une autre traduction : valider des contraintes sur un modle en un problme de satisfaction de contraintes.

Vrier un modle laide de contraintes

Cette section montre comment nous pouvons utiliser le formalisme des problmes de satisfaction de contraintes pour vrier des contraintes exprimes en OCL sur des modles. Si, dans un premiers temps, cette approche est motive par un gain possible de performance, nous ver-

Assistance la conception de modles laide de contraintes

rons dans la section suivante quelle ouvre surtout de nouvelles perspectives dans le domaine de laide au design.

5.1

Le problme de satisfaction de contraintes

Le formalisme des problmes de satisfaction de contraintes (CSP) prsent par Montanari (1974) offre un cadre puissant pour la reprsentation et la rsolution efcace de nombreux problmes. Ces problmes sont reprsents par un ensemble de variables qui doivent, chacune, tre affectes dans leur domaine respectif, tout en satisfaisant un ensemble de contraintes qui expriment des restrictions sur les diffrentes affectations possibles. Aujourdhui, de nombreux solveurs CSP existent et ne cessent dtre perfectionns. Des amliorations aussi bien au niveau algorithmique quau niveau des structures de donnes sont sans cesse proposes et une comptition internationale 5 mettant en jeu les performances de chaque prouveur contribuent lvolution de ceux-ci. La librairie CHOCO dveloppe par Jussien et al. (2008) est une librairie Java qui permet de modliser et de rsoudre efcacement des CSP. Rgulirement amlior et complt, CHOCO est devenu un outil de plus en plus utilis dans le cadre dautres domaines de recherche. Cest dans la droite ligne de cette approche que nous cherchons exprimer le problme de la validation de modle suivant des contraintes OCL en un problme CSP et nous ferons appel CHOCO pour le modliser sous forme de contraintes puis pour le rsoudre. Notons que notre approche nest pas unique puisque loutil UMLtoCSP de Cabot et al. (2008) permet, partir dun diagramme UML et de contraintes OCL associes, de vrier des invariants OCL ainsi que des proprits UML, en transformant tout le diagramme de classes UML et les invariants OCL associs en un problme de satisfaction de contraintes. Par contre, leur approche ncessite de fournir en paramtre lespace de recherche pour obtenir une recherche complte. De plus, alors que cette approche se limite laspect vrication dune contrainte, nous cherchons en plus faire de la synthse et prendre en compte un critre minimiser.

5.2

Mthode

Pour valider un modle et faire une synthse partielle de solution, nous transformons la contrainte crite en OCL et le modle associ en un problme de satisfaction de contraintes, puis rsolvons le problme avec le solveur CHOCO. 5.2.1 Sous-ensemble dOCL considr

Dans cette tude prliminaire, nous considrons seulement un extrait dOCL mais nous travaillons actuellement augmenter ce sous-ensemble. Nous dnissons comme langage source le sous-ensemble du langage OCL que nous pouvons transformer. Les contraintes OCL sont dnies comme des invariants. Les expressions OCL sont bases sur les types entier, boolen et les collections. Les oprateurs sur les collections pris en compte sont forAll, exists, select, reject, collect, includesAll, excludesAll, union, intersection, notEmpty, isEmpty, includes, excludes, sum, size et count.De plus, nous considrons les itrations sous la forme normalise suivante :
5. Pour plus dinformation voir le site : http://www.cril.univ-artois.fr/CPAI09/

Marie de Roquemaurel et al.

iterate ( x , acc : T = a_0 | let z_1 = f_1 ( x ) in ... let z_n = f_n ( x ) in i f cond ( x ) then f ' ( x , i , acc ) e l s e acc endif )

o f est une fonction associative et cumulative et i le nombre doccurences de llment x. 5.2.2 Traduction des donnes en CSP

Pour vrier des contraintes sur un modle, nous avons besoin dextraire une partie des donnes contenues dans le modle. An de limiter la taille du CSP, nous traduisons en CSP seulement les donnes qui sont partiellement connues, les lments totalement connus sont stocks dans des structures de donnes comme des constantes. Pour manipuler des entiers, nous associons un identiant chaque objet et chaque attribut utilis. Exemple Prenons comme exemple le problme de graphe dni dans la sous-section 4. Nous noterons nl le nombre de nuds logiques et np le nombre de nuds physiques. Dans ce problme, nous avons besoin des arcs logiques et physiques qui sont xs dans le modle. Ces deux donnes sont stockes dans deux collections de couples de nuds : al pour les arcs logiques et ap pour les arcs physiques. Nous considrons galement comme x le calcul de la fermeture transitive rexive du graphe physique car elle est base sur les arcs physiques qui sont connus. Le calcul est effectu avec lalgorithme de Warshall et son rsultat est stock dans un tableau de constantes boolennes closure : closure[i, j] = (i, j) al (i = j) (k {0, .., np 1} : closure[i, k] closure[k, j]) (1)

Nous modlisons par des variables du CSP le mapping du graphe logique dans le graphe physique qui est partiellement connu. A chaque nud logique x Nl , le mapping associe un et un seul nud physique y Np . Nous crons un tableau de variables entires mapping :{0, .., nl 1} {0, .., np 1} o lindice reprsente lidentiant du nud logique et la case contient lidentiant de limage de ce nud. Le domaine de chacune de ces variables est lensemble des identiants des nuds physiques. Lorsque le mapping est dni, les variables sont affectes, sinon laffectation dune valeur du domaine chaque variable est cone au solveur. Le listing 2 donne la traduction du mapping en CHOCO et laffectation au nud didentiant 0 limage didentiant 1 : Listing 2 Mapping exprim en C HOCO
d e f i n i t i o n du mapping IntegerVariable [ ] mapping = new IntegerVariable [ nl ] ; f o r ( int i = 0 ; i < nl ; i++) { mapping [ i ] = Choco . makeIntVar ( " M"+i , 0 , np1) ; csp . addVariables ( mapping [ i ] ) ; } a f f e c t a t i o n : mapping [ 0 ] = 1 csp . addConstraint ( Choco . eq ( mapping [ 0 ] , 1 ) ) ;

Assistance la conception de modles laide de contraintes

Cette traduction des donnes introduit nl variables, dont la taille du domaine est np , et autant de contraintes unaires que de mappings connus. 5.2.3 Traduction des contraintes en CSP

Une fois dnies les constantes et les variables ncessaires au problme, nous pouvons traduire les contraintes OCL sous forme de contraintes CSP. Exemple La contrainte qui cherche vrier que, pour tout arc logique (i, j), il existe un chemin entre limage de i et limage de j peut se traduire avec notre reprsentation par : (i, j) Al , closure[mapping[i]][mapping[j]] (2)

Nous obtenons la traduction de lquation 2 en CHOCO par lintroduction de Card(al) contraintes binaires comme le montre le listing 3. Listing 3 Contrainte exprime en C HOCO
p o u r t o u s l e s a r c s l o g i q u e s f o r ( Couple c : al . getCouples ( ) ) { int i=c . getFirst ( ) ; int j=c . getSecond ( ) ; a j o u t c o n t r a i n t e : c l o s u r e [ mapping [ i ] ] [ mapping [ j ] ] = t r u e csp . addConstraint ( Choco . feasPairAC ( mapping [ i ] , mapping [ j ] , closure ) ) ; };

Cette modlisation en un problme de satisfaction de contraintes produit un CSP qui contient nl variables entires dont le domaine a une taille np , autant de contraintes unaires que de mappings connus et Card(al) contraintes binaires.

5.3

Rsultats

Pour comparer notre approche avec un interprteur OCL et une solution idale code en Java, nous reprenons le test de performance effectu dans la sous-section 4.2. La gure 3 montre que notre mthode permet un gain en temps dexcution par rapport aux OCL checker et que nous sommes capable de traiter un grand nombre dobjets dans des temps raisonnables par rapport la solution idale reprsente en Java. Lorsque le modle comporte 2 802 arcs, notre mthode est mme plus rapide que Java, ce qui peut sexpliquer par un traitement diffrent pour le calcul de la fermeture. En Java les fermetures sont calcules pour chaque nud dun arc logique lors de lvaluation de la contrainte OCL, augmenter le nombre darcs augmente les possibilits de recalculer plusieurs fois la mme fermeture. Dans notre mthode, nous calculons pralablement les fermetures de chaque nud avant dvaluer la contrainte, augmenter le nombre darcs diminue les possibilits de calculer des fermetures inutilises. Ainsi, plus le modle contient dobjets et notamment darcs, plus notre mthode est avantageuse en terme de temps dxcution. Sur cet exemple, la traduction du problme de validation de modles en un problme de satisfaction de contraintes permet dviter le problme du passage lchelle. Il semble alors

Marie de Roquemaurel et al.

104
Temps (millisecondes) OCL JAVA CHOCO

20

40

60

80
2

Taille du modle (2N nuds et 2N arcs)

F IG . 3 Test de performance sur le problme de graphe pertinent dtudier une traduction automatique du problme de validation dune contrainte OCL sur un modle en CSP pour tester notre mthode sur dautres problmes. La section suivante montre que notre approche ne se limite pas valider des modles mais permet daider lutilisateur lors de la conception de modles.

Complter un modle partiel et minimiser un critre

Nous avons montr comment utiliser un solveur CSP pour valider un modle. CHOCO ne se contente pas de savoir si une contrainte est satisfaite ou non, mais peut nous donner un modle pour cette contrainte sil existe. Lide ici est dutiliser le solveur CHOCO pour proposer une modication du modle lutilisateur. Les valeurs inconnues du modle sont dcrites laide de variables an de raliser une synthse partielle de solution pour une contrainte OCL. Ds lors, il est possible dexprimer le problme sous forme de contraintes et que CHOCO nous renvoie un modle solution qui valide ces contraintes. A laide de transformations inverses, la solution nous revient dans un format comprhensible. Nous avons donc un mcanisme qui nous permet de synthtiser une solution. Dans lexemple prcdent, cette mthode nous permet de complter un mapping partiel tout en respectant les contraintes donnes. Dautre part, CHOCO peut prendre en compte un critre minimiser dcrit par une variable objective comme nous lillustrons dans lexemple suivant. Exemple Nous cherchons minimiser, dans le problme prcdent, le cardinal de limage de lensemble des nuds logiques par la fonction mapping : Card({y | x Nl , y = mapping(x)}). Ce critre consiste compter le nombre de nuds physiques lis par un mapping. Le listing 4 montre la traduction de ce critre en OCL.

Assistance la conception de modles laide de contraintes

Listing 4 Critre de minimisation exprim en OCL

N_l . allInstances ( ) . mapping>asSet ( ) >count ( )

Pour prendre en compte ce critre dans le CSP, comme le montre le listing 5, nous crons la variable images dont la valeur reprsente lensemble des nuds physiques lis par un mapping, nous ajoutons np contraintes spciant que toutes les images du mapping appartiennent lensemble images. Nous dclarons comme variable minimiser, une variable entire cardImages qui reprsente la cardinalit de la variable images. Listing 5 Critre de minimisation exprim en C HOCO
D e f i n i t i o n de l ' e n s e m b l e d e s i m a g e s SetVariable images = Choco . makeSetVar ( " s " , 0 , np ) ; f o r ( int i = 0 ; i<np ; i++) { csp . addConstraint ( Choco . member ( images , mapping [ i ] ) ) ; }; D e f i n i t i o n du c r i t e r e IntegerVariable cardImages = Choco . makeIntVar ( " CardImages " , 0 , np , "cp : objective " ) ; csp . addConstraint ( Choco . eqCard ( images , cardImages ) ) ;

Lorsquil existe plusieurs solutions au problme, CHOCO retourne une solution qui minimise notre critre. La traduction de cette solution nous permet de complter le modle initial en satisfaisant les contraintes et le critre. A travers cet exemple, nous montrons que notre mthode permet de faire de la vrication mais surtout daider la conception de modles en compltant des modles partiels ou en minimisant un critre.

Vers une automatisation du processus de traduction

Dans la partie prcdente, on a montr que lon pouvait exprimer une contrainte OCL et le modle qui lui est associ en Choco. On travaille actuellement lautomatisation de cette traduction grce diffrentes techniques. Les contraintes ntant pas intgres au modle, nous avons pris le parti de grer leur traduction indpendamment. La contrainte est traduite en utilisant des mthodes de rcriture supportes par le langage Tom prsent par Moreau et al. (2002). On gnre la partie donnes partir du modle source grce des outils de transformations de modles. Tom est une extension de langages htes comme Java, c, ou Python, permettant de manipuler des structures arborescentes par rcriture. Tom apporte un mcanisme de reconnaissance de motifs avanc qui facilite lcriture des rgles de transformations permettant de passer des expression OCL aux expressions Choco. De plus, il dnit des stratgies de parcours gnriques an dappliquer des rgles de transformations simples toutes les sous-expressions dune formule OCL. Le MDT OCL nous permet danalyser le texte dune contrainte OCL, et de la reprsenter sous la forme dun arbre abstrait dobjets Java. On sait interprter les objets Java comme des

Marie de Roquemaurel et al.

termes Tom. La description de cette correspondance est en cours, elle nous permettra dimplanter en Tom les rgles de transformation des expressions OCL. La traduction des donnes en Choco est effectue par une transformation de modles. Son but est double : gnrer une partie du code Choco, et modier le modle source en fonction des rsultats synthtiss par le solveur de contraintes. En effet, dans le cas ou on souhaite complter un modle suivant un critre de minimisation, on veut pouvoir intgrer la solution propose au niveau du modle. On doit donc dnir une transformation bidirectionnelle permettant dans un premier temps de gnrer le code Choco, puis de complter le modle source. Le langage QVT dnit par lOMG (2005) permet de dnir des transformations de modles relationnelles ou oprationnelles. Les implantations de ce standard ne couvrent pas tout le langage, souvent seule la partie oprationnelle est utilise. Une implantation de ce langage, MediniQvt dvelopp par ikv++ developers (2008), prend en compte la partie relationnelle de QVT et nous autorise donc dcrire des transformations bidirectionnelles. La premire tape, avant de dcrire la transformation, est de dnir un mtamodle pour les donnes Choco. Les types de donnes manipuls peuvent tre de trois sortes, entier, rel, ou ensemble. On peut ensuite dnir des tableaux, et enn on doit prciser la nature de notre donne, variable ou constante. La transformation est ensuite implante suivant les rgles dnies dans la partie 5. Une fois que le problme est exprim sous la forme de contraintes Choco, la rsolution peut tre lance. On doit encore inclure le rsultat dans notre modle choco, puis le remonter au niveau du modle de graphe. La gure 4 reprsente le processus complet propos dans cette partie.
Excution Choco Contrainte OCL Modle de graphe source Rcriture Tom Code Choco Modle de donnes Choco complt Modle de graphe source complt

Modle de donnes Choco

Transformation QVT Transformation QVT

F IG . 4 Processus de compltion dun modle bas sur Choco.

Conclusion

Dans cet article, nous avons tudi un cadre de travail bas sur les formalismes et outils de lingnierie dirige par les modles pour valider et synthtiser des modles. Pour supporter le passage lchelle de ces derniers, nous avons tudi ladaptation de techniques issues de la programmation par contraintes. Cette approche nous semble intressante car elle offre une

Assistance la conception de modles laide de contraintes

continuit avec les chanes de conception dites aval (plus concerne par les aspects gnration de code et dploiement) qui sont aussi de plus en plus bases sur les outils de lingnierie des modles. Il sagit l dune tude prliminaire. Dans le futur, nous envisageons doffrir un meilleur support pour lanalyse de proprits du domaine de lembarqu, e.g., celles dnies pour le placement par AADL et par la suite des plateformes avioniques prsent par Bieber et al. (2008). Une voie qui nous semble prometteuse est lamlioration du codage des structures de donnes du mta modle et du modle en prenant en compte des contraintes structurelles mtier.

Rfrences
Ahrendt, W., T. Baar, B. Beckert, R. Bubel, M. Giese, R. Hhnle, W. Menzel, W. Mostowski, A. Roth, S. Schlager, et P. H. Schmitt (2003). The key tool. Technical report in computing science no. 2003-5, Department of Computing Science, Chalmers University and Gteborg University. ATL. Atlas transformation language. http ://www.eclipse.org/m2m/atl/. Bieber, P., J. Bodeveix, C. Castel, D. Doose, M. Filali, F. Minot, et C. Pralet (2008). Constraint-based design of avionics platform - preliminary design exploration. In ERTS, Toulouse. SEE. Buttelmann, B., L. Hamann, F. Jolk, B. Sun, H. Wang, et L. Xia (2008). Evaluating a benchmark for ocl engine accuracy, determinateness, and efciency. http ://db.informatik.unibremen.de/publications/Buettelmann_2008_BMEVAL.pdf. Cabot, J., R. Claris, et D. Riera (2008). Verication of uml/ocl class diagrams using constraint programming. In Proceedings of ICST Workshop on Model Driven Engineering, Verication and Validation : Integrating Verication and Validation in MDE (MoDeVVa2008). Demuth, B. et H. Hussmann (1999). Using UML/OCL constraints for relational database design. In R. France et B. Rumpe (Eds.), UML99 - The Unied Modeling Language. Beyond the Standard. Second International Conference, Fort Collins, CO, USA, October 28-30. 1999, Proceedings, Volume 1723 of LNCS, pp. 598613. Springer. Dzidek, W., L. Briand, et Y. Labiche (2005). Lessons learned from developing a dynamic ocl constraint enforcement tool for java. In J.-M. Bruel (Ed.), MoDELS Satellite Events, Volume 3844 of Lecture Notes in Computer Science, pp. 1019. Springer. Finger, F. (2000). Design and Implementation of a Modular OCL Compiler. Ph. D. thesis, Technische Universitt Dresden. Gogolla, M., F. Bttner, et M. Richters (2007). Use : A uml-based specication environment for validating uml and ocl. Sci. Comput. Program. 69(1-3), 2734. Gogolla, M., M. Kuhlmann, et F. Bttner (2008). A benchmark for ocl engine accuracy, determinateness, and efciency. In MoDELS08 : Proceedings of the 11th international conference on Model Driven Engineering Languages and Systems, Berlin, Heidelberg, pp. 446459. Springer-Verlag. ikv++ developers (2008). Medini QVT. http ://projects.ikv.de/qvt : ikv++ technologies ag. Jeanneret, C., L. Eyer, S. Markovi, et T. Baar (2006a). RoclET-A Tool for Wrestling with OCL Specications. In Model Driven Engineering Languages and Systems, 9th International Conference, MoDELS 2006. Jeanneret, C., L. Eyer, S. Markovi, et T. Baar (2006b). RoclET : Refactoring OCL Expressions by Transformations. In Software & Systems Engineering and their Applications,19th International Conference, ICSSEA 2006.

Marie de Roquemaurel et al.

Jussien, N., G. Rochart, et X. Lorca (2008). The choco constraint programming solver. In CPAIOR08 Workshop on Open-Source Software for Integer and Contraint Programming (OSSICP08), Paris, France. MDT. Model development tools. http ://www.eclipse.org/modeling/mdt/. Mezei, G., L. Lengyel, T. Levendovszky, et H. Charaf (2006). Optimization algorithms for ocl compilers. In Proceedings of the 5th WSEAS International Conference on Software Engineering, Parallel and Distributed Systems, Stevens Point, Wisconsin, USA, pp. 5560. WSEAS. anglais Millan, T., L. Sabatier, T. T. Le Thi, P. Bazex, et C. Percebois (2009). An OCL extension for checking and transforming UML Models. In WSEAS - International Conference on Software Engineering, Parallel and Distributed Systems (SEPADS09), Cambridge, United Kingdom, 21/02/09-23/02/09, http ://www.wseas.org/, pp. 144150. WSEAS Press. (Confrencier invit). Montanari, U. (1974). Networks of constraints : Fundamental properties and applications to picture processing. Information Sciences 7, 95132. Moreau, P.-E., C. Ringeissen, et M. Vittek (2002). A Pattern Matching Compiler for Multiple Target Languages. Technical report, INRIA. Mottu, J., O. Barais, M. Skipper, D. Vojtisek, et J. Jzquel (2007). Intgration du support ocl dans kermeta. spciez la smantique statique de vos mta-modles. 10ime Anniversaire de la Confrence Francophone sur les Approches Formelles dans lAssistance au Dveloppement de Logiciels (AFADL07). Octopus. http ://sourceforge.net/projects/octopus/. OMG (2005). MOF QVT Final Adopted Specication. Object Modeling Group. OMG, O. M. G. (2006). Object Constraint Language Object Constraint Language, OMG Available Specication, Version 2.0. Snchez Cuadrado, J., F. Jouault, J. Garca Molina, et J. Bzivin (2008a). Deriving ocl optimization patterns from benchmarks. In Proceedings of the 8th International Workshop on OCL Concepts and Tools (OCL 2008) at MoDELS 2008. Electronic Communications of the EASST. Snchez Cuadrado, J., F. Jouault, J. Garca Molina, et J. Bzivin (2008b). Optimization patterns for ocl-based model transformations. In Models in Software Engineering, Workshops and Symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008. Reports and Revised Selected Papers, pp. 273284. Springer-Verlag.

Summary
System design is one of the rst steps of high level design. During this step, we have to reason at a coarse grain (making abstraction of coding aspects) in terms of functions to be implemented on a given target. Then, we have to take into account global properties related to the mapping of the functions on a given architecture. In order to assist the designer during this step, we propose an model driven engineering based approach. The scalability of such an approach is considered through the use on constraint programming concepts and tools. We have adopted the Ecore metamodel for the description of models and the OCL language for the expression of constraints. Although many tools rely on the OCL language, we have observed that actual models from the aeronautic domain are the source of severe performance problems. In this paper, we review approaches for handling this problem and present the benets of an approach based on constraint programming.