i∈ids(B)
vari=n
Cette seconde version est plus complexe et requiert un solveur capable de faire de la réification de contraintes. En effet, cette version génère une contrainte par valeur possible par propriété considérée.
Il est possible de trouver des encodages pour tous les types de relations existant dans les modèles utilisés en IDM.
3.3 Définition du comportement par des contraintes
Dans la sous-section 3.1.2 nous avons présenté la notion de comportement comme étant la stratégie de réparation utilisée lors de la réparation d’un modèle invalide. Par exemple, nous avons présenté le comportement le plus simple qui consiste à annuler tout changement effectué par l’utilisateur.
D’un point de vue théorique un comportement est une fonction qui, à partir d’un delta ap-pliqué à un modèle, calcule une série de deltas à appliquer. Dans notre contexte, nous ne considérons que les explorations d’ensembles de modèles valides. Il faut donc que notre com-portement génère une exploration d’ensemble de modèles correcte, c’est à dire une Exploration dont le modèle terminal appartient à l’ensemble des modèles.
Avant de proposer une façon d’encoder ces comportements sous la forme de contraintes, nous illustrerons les différents comportements souhaités avec un exemple.
3.3. Définition du comportement par des contraintes
3.3.1 Le problème du contenant et du contenu
Le problème du contenant et du contenu est un problème récurrant, apparaissant dans de nombreux diagrammes avec lesquels l’utilisateur peut interagir. Il est courant, dans les dia-grammes, d’associer à la notion de contenance d’un élément graphique dans un autre un sens dépendant du diagramme.
Par exemple, considérons deux classesAetB et un packagePauquel la classe A appar-tient. La Figure 3.4 donne une représentation sous la forme d’un diagramme de classes de ces classes et ce package. L’appartenance de la classe Aau package Pest encodé dans le diagramme par le fait que la représentation visuelle de la classeAsoit contenue dans la repré-sentation visuelle du package P. De plus, le fait que la représentation visuelle de la classe ˘aB ne soit contenue dans rien indique que celle-ci n’appartient à aucun package.
P
A B
FIGURE3.4 – Exemple de diagramme de classes
Toujours sur cet exemple du package contenant les classes lui appartenant, imaginons que ce diagramme puisse être modifié par l’utilisateur. On imagine facilement qu’il est pos-sible de déplacer librement les classes tant que ces déplacements n’altèrent la signification du diagramme. Par exemple, déplacer la classe Bvers la droite ne change pas les classes ni le package. Le diagramme de classes est valide par rapport au modèle de classe qu’il représente. Cependant, si l’utilisateur déplace la classe A hors du packageP alors la signification du diagramme change. Ainsi, le diagramme n’est plus un diagramme valide par rapport au modèle de classes original. Il faut alors réparer, au choix, le modèle de classes (en modifiant la classe Ade façon à ce qu’elle n’appartienne plus au packageP) ou le diagramme. Pour cet exemple considérons que la première solution (modifier le modèle de classes) ne soit pas possible. Il faut donc réparer le diagramme.
Cependant il existe de multiple façon de réparer le diagramme de façon à ce que celui-ci redevienne valide. Voici quelques exemple de réparation possibles :
1. Déplacement du packagePde façon à ce que la classeAsoit contenue dans celui-ci. 2. Agrandissement du packagePde façon à ce que la classeAsoit contenue dans celui-ci.
3. Réduction de la taille de la classeApour qu’elle reste dans les limites du packageP. 4. Déplacement de la classeApour qu’elle reste dans les limites du packageP.
3.3.2 Modélisation d’un comportement par des contraintes
Dans le formalisme vu dans les sections précédentes, le diagramme appartient à un espace de modèles. Les interactions de l’utilisateur sur le diagramme (déplacement des éléments gra-phiques) correspondent à des explorations de cet espace de modèles. Enfin, les règles de construction d’un diagramme de classes correspondant au modèle de classe présenté plus tôt forment les règles de validation nous permettant de créer un ensemble de modèles. Cet ensemble contient donc tous les diagrammes de classes représentant ce modèle de classe.
La seconde interaction de l’utilisateur, sortant la classeAdu packageP, correspond à une exploration de modèle dont le modèle initial appartient à l’ensemble de modèles mais dont le modèle terminal n’appartient pas à cet ensemble de modèles.
Nous avons vu qu’il est possible de définir un ensemble de modèles par des contraintes. Un solveur est capable de calculer un modèle respectant ces contraintes (si une solution au problème de contraintes existe) et appartenant donc à l’espace de modèles. Nous avons éga-lement vu qu’un solveur de contraintes peut être utilisé pour réparer un modèle rendu invalide par une interaction de l’utilisateur. Par exemple ici, de déplacement de la classe Aen dehors du packageP.
Cependant, sans indication, le solveur calculera une nouvelle solution sans prendre en compte les changements effectués par l’utilisateur. En effet, pour lui le modèle de contraintes n’a pas changé. C’est pourquoi nous avons repris les idées de contraintesstayet de sugges-tion de valeurs présentes dans les solveurs de HCSP.
La contraintestay est une contrainte spéciale dans le sens où elle minimise les change-ments d’une variable d’une résolution à l’autre. Si on applique la contraintestayà une variable
x et que l’on note prev(x) la valeur de la variable x dans la solution précédente. Alors, en interne le solveur crée une contrainte x−prev(x) = 0. Lors de la résolution, les solveurs de HCSP minimisent l’erreur pondérée des contraintes. Une contrainte ayant un poids plus élevé aura une erreur plus faible.
La suggestion de valeur à une variable correspond à l’ajout temporaire d’une contrainte. Par exemple, si l’on suggère la valeur5à une variable x, le solveur ajoute la contraintex = 5 au problème. Il recalcule une solution et enlève ensuite la contraintex= 5.
Avec ces deux contraintes ainsi que les poids il est possible de définir des préférences que le solveur devra prendre en compte lors de la résolution. Par exemple, pour reprendre le cas de la classe et du package, voici une partie des contraintes définissant un diagramme de classes valide :
Contrainte 1 : Le nom de la classe doit être positionné au centre du rectangle correspondant à la classe.