Identification, mod´ elisation et instanciation des acteurs d’un probl` eme

La programmation par rˆole [209] est un paradigme de programmation qui repose sur l’identification des diff´erents rˆoles, d´efinis par leurs interfaces et leurs fonctionnalit´es, qu’un mˆeme objet peut assumer dans un syst`eme logiciel. Les fonctionnalit´es du syst`eme sont alors r´eparties en plusieurs rˆoles et chaque objet assumera un ou plusieurs rˆoles au cours de sa dur´ee de vie.

Cette notion de rˆole est finalement tr`es proche d’un raisonnement d’´elaboration d’un CSP. En effet, formuler un CSP consiste `a identifier les diff´erentes entit´es du probl`eme (e.g., dans un probl`eme d’ordonnancement simple, la seule entit´e est une tˆache dont la date de d´ebut est `a d´eterminer) et `a caract´eriser leurs interactions et contraintes (e.g., tˆaches d´ependantes). Ces entit´es peuvent ˆetre assimil´ees `a des rˆoles qui seront assum´es par des objets issus de l’impl´ementation concr`ete analys´ee (e.g., nœuds d’un graphe). Une fois les rˆoles identifi´es, les contraintes du probl`eme correspondent aux propri´et´es de ces rˆoles ainsi qu’`a leurs interactions. Un des objectifs d’ARCAdE est d’offrir un environnement de mod´elisation tr`es proche d’un raisonnement naturel : un probl`eme est d´ecrit par un ensemble d’acteurs dont les interactions correspondent `a des ensembles de contraintes.

Chaque rˆole d’un probl`eme est d´ecrit par un type abstrait appel´e acteur (d´efinition21). Un acteur est constitu´e d’un ensemble de variables enti`eres `a domaine fini et de r`egles (d´efinition22) exprimant des restrictions sur les valeurs possibles de ces variables.

8.3. Mod´elisation modulaire de CSP 185

1 actor Task {

2 var start : "Start time of a task"; 3 var duration : "Total duration of a task"; 4 var end : "End of a task";

5

6 where {

7 end = start + duration;

8 }

9

10 rule dependency(Task previous) {

11 start >= previous.start + previous.duration;

12 }

13 }

Figure 8.1 – Mod´elisation ARCAdE d’une tˆache caract´eris´ee par trois variables start, duration et end qui d´eterminent respectivement le d´ebut, la dur´ee et la fin d’une tˆache.

D´efinition 21 (Acteur) Un acteur est un type capturant les contraintes s´emantiques d’un ensemble d’entit´es concr`etes r´epondant `a la mˆeme intention pour un CSP donn´e.

D´efinition 22 (R`egle) Une r`egle est une fonction qui produit l’ensemble des contraintes d’une in- teraction particuli`ere entre l’acteur de cette r`egle et d’autres acteurs fournis en param`etre.

La figure8.1est un extrait d’un fichier ARCAdE mod´elisant une tˆache d’ordonnancement. Celle-ci est d´ecrite dans un acteur comportant notamment trois variables `a ´evaluer lors de la recherche d’une solution. Le domaine par d´efaut de chacune de ces variables est N5<sub>, il s’av`ere en effet le plus r´epandu</sub>

en pratique. Les valeurs possibles de ces variables sont restreintes par deux r`egles. La premi`ere r`egle (ligne6) est propre `a la tˆache, elle contraint sa date de fin en fonction de son d´ebut et de sa dur´ee. La seconde r`egle (ligne10) correspond aux contraintes impos´ees quand une tˆache doit ˆetre pr´ec´ed´ee par une autre fournie en param`etre.

Les acteurs d´efinissent des types supportant des fonctionnalit´es logicielles avanc´ees (e.g., aspects, h´eritage multiple, surcharge et red´efinition des r`egles) afin de factoriser les mod`eles de contraintes d´eploy´es dans de multiples contextes. La mise en œuvre de ces fonctionnalit´es est facilit´ee par la nature d’un CSP qui ´elimine notamment le probl`eme du diamant issu de l’h´eritage multiple.

La figure8.2illustre le probl`eme du diamant `a travers une classe D qui h´erite de deux autres classes (B et C) d´efinissant le mˆeme prototype de m´ethode m. Dans ce cas, le comportement de m dans D requiert un choix explicite entre celui d´efini dans B ou C. Or, par d´efinition, un CSP est constitu´e d’un ensemble de variables et d’un ensemble de contraintes. L’ordre dans lequel sont impos´ees ces contraintes n’a aucune importance et si une contrainte s’av`ere ˆetre exclusive avec le reste du probl`eme alors celui-ci reste dans une forme coh´erente, mais n’a pas de solution. Ces caract´eristiques l`event toute ambigu¨ıt´e puisque les r`egles d´efinies dans chaque acteur produisent toutes des ensembles de contraintes. Ainsi, une r`egle m de D qui est d´efinie `a la fois dans l’acteur B et l’acteur C, produit `a la fois les contraintes de m dans B et celles de m dans C. La s´emantique sp´ecifique aux CSP ne requiert donc aucun choix explicite de la part du concepteur : si les contraintes de B et C sont incompatibles, l’instance du CSP final n’aura pas de solution. Autrement dit, les comportements issus de l’h´eritage

5. Abus de notation par souci de lisibilit´e : les domaines ´etant finis, la borne sup´erieure est une constante enti`ere repr´esentant l’infini positif.

186

Chapitre 8. ARCAdE : Un environnement orient´e aspect pour la mod´elisation modulaire de probl`emes de satisfaction de contraintes

B m() : EInt D C m() : EInt A

Figure 8.2 – Probl`eme du diamant : quel est le comportement de m dans D ?

multiple sont implicites et l’analyse de leur coh´erence est d´eport´ee sur le solveur, ce processus est donc transparent `a l’utilisateur.

Une autre caract´eristique d’ARCAdE est d’offrir un lien direct entre une impl´ementation concr`ete et les mod`eles de contraintes utilis´es pour r´esoudre un probl`eme de satisfaction ou d’optimisation. Ce lien est mis en œuvre `a travers le polymorphisme param´etrique des acteurs : les classes concr`etes d’un probl`eme mod´elis´e sont des param`etres des acteurs. Le polymorphisme param´etrique (ou g´en´ericit´e) consiste `a d´efinir des classes ou des m´ethodes param´etr´ees par des types g´en´eriques. Ainsi, une classe

Apeut d´efinir un attribut sur un type g´en´erique T si ce dernier est un param`etre de A (en Java, on note A<T>). Dans notre cas, la classe d’un acteur mod´elisant une tˆache pour un probl`eme d’ordon- nancement est Task<A> o`u A est un type g´en´erique qui symbolise n’importe quelle classe concr`ete des objets ordonnanc´es.

Instancier un CSP mod´elis´e pour une impl´ementation concr`ete n´ecessite trois ´etapes de la part du concepteur.

1. Typer les classes concr`etes par des acteurs. Par exemple, si l’on cherche `a ordonnancer un graphe, les nœuds du graphe sont typ´es en acteur tˆaches. Si la classe d’un nœud est Node, la

classe de l’acteur des tˆaches est alorsTask<Node>.

2. Initialiser, si besoin, les domaines des variables en fonction de l’´etat des objets concrets. Pour un ordonnancement de graphe, cela consiste `a initialiser les domaines des variables duration (cf. figure8.1) `a une dur´ee constante pour chaque nœud.

3. Imposer les contraintes du probl`eme en appelant les r`egles d´efinies dans les acteurs. L’appel explicite des r`egles associe les interactions possibles des acteurs `a la s´emantique concr`ete des objets. Par exemple, toujours dans le cas d’un ordonnancement de graphe, la r`egle de d´ependance entre deux tˆaches (cf. figure8.1, ligne 10) est appel´ee pour chaque lien du graphe. L’appel de cette r`egle est fait sur l’acteur correspondant au nœud destination, son unique param`etre est le nœud source du lien (l’acteur correspondant est r´ecup´er´e automatiquement).

Le code Java de la figure 8.3 illustre l’instanciation d’un probl`eme d’ordonnancement (cf. fi- gure 8.1) `a une impl´ementation concr`ete d’un graphe. Les nœuds constituent les ´el´ements `a ordon- nancer, ils sont typ´es en acteur Task par la cr´eation (ligne1) d’un objet SolveScheduling param´etr´e par la classe Node. Cet objet contient toutes les instances des acteurs du probl`eme, il se charge ´ega- lement d’associer chaque objet concret (Node) `a son instance d’acteur respective (Task<Node>). Par

8.3. Mod´elisation modulaire de CSP 187

1 SolveScheduling<Node> scheduling = SchedulingFactory.eINSTANCE.createSolveScheduling(); 2

3 for (Node n : graph.getNodes()) { 4 int d = n.getLatency();

5

6 ITask<Node> task = scheduling.getTask(n); 7 task.getDuration().setDomain(d,d); 8

9 for(Node predecessor: n.getPredecessors()){

10 scheduling.impose(task.buildDependencyConstraints(predecessor));

11 }

12 }

Figure 8.3 – Instantiation d’un probl`eme d’ordonnancement pour un graphe. La s´emantique du graphe est exprim´ee en Java par un appel explicite de la r`egle de d´ependance entre deux tˆaches (cf. figure8.1).

exemple, la ligne6 r´ecup`ere l’instance de l’acteur Task<Node> d’un nœud du graphe `a ordonnancer. S’il s’agit du premier acc`es `a l’acteur de ce nœud, un nouvel objet Task<Node> est automatiquement cr´e´e et initialis´e en se basant sur la description des domaines de variables de cet acteur.

Dans l’exemple (cf. figure8.1), aucun domaine n’est associ´e explicitement aux variables de l’acteur Task, les domaines sont alors N (domaine par d´efaut). Si le domaine d’une variable varie selon l’ins- tance de son acteur, il est n´ecessaire d’initialiser son domaine en fonction des ´etats et des contextes des objets concrets. C’est le cas des dur´ees des tˆaches qui sont initialis´ees `a la ligne 7 `a la valeur fournie par chaque nœud.

Le code initialisant le domaine d’une variable d´epend ´evidemment du solveur cibl´e par le g´e- n´erateur de code d’ARCAdE (ici il s’agit du solveur JaCoP). Une fois que tous les domaines des variables sont initialis´es, l’utilisateur appelle explicitement les diff´erentes r`egles `a appliquer. L’objet SolveScheduling contient l’ensemble des contraintes impos´ees pour chaque r`egle appliqu´ee. Dans l’exemple, la seule r`egle appliqu´ee (ligne10) est celle qui exprime une d´ependance entre un nœud et chacun de ses pr´ed´ecesseurs.