Résolution interactive et compilation de problèmes de ... · matique et Robotique et Micro...

Université Paul Sabatier – Toulouse 3

Institut de Recherche en Informatique de

Toulouse IRIT

Mémoire de master ii informatique

Résolution interactive et

compilation de problèmes de

satisfaction de contraintes

par

Yacine IZZA

Soutenue le 27 Juin 2014

Encadrement : Mme Hélène Fargier

à ma famille

Remerciements

Je voudrais tout d’abord exprimer mes plus profonds remerciements àmon encadrant de stage sans qui rien n’aurai été possible : Mme Hé-

lène Fargier. Merci pour votre disponibilité, vos conseils et de m’avoir faitconfiance durant ces cinq mois de stage.

J’adresse également mes remerciements aux partenaires du projet avecqui j’ai travaillé : Mr Daniel LeBerre, Mr Christophe Lecoutre et NicolasSchmidt.

Je tiens à remercier toutes les personnes de l’équipe ADRIA, mes en-seignants de Master 2 IAICI, mes camarades du stage et mes voisins dubureau pour leurs aides et tout les moments agréables qu’on a partagerau bureau 302.

Merci aux amis Toulousains et Montpellierains pour les momentsde détentes et de compagnie. Une pensée affectueuse à Hien, Yasser,Amayas, Thilleli et Dalila pour qui je souhaite un grand succès à New-York.

Enfin, je tiens à remercier Mr Chermak pour son soutien indéfectibleet ces conseils qui mon toujours aider à aller de devant.

Lieu, le 20 juin 2014.

v

Table des matières

Remerciements v

Table des matières vi

Liste des figures vii

Introduction générale 1

1 Étude bibliographique 31.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Problème de satisfaction de contraintes (CSP) . . . . . 4

1.2.1 Notations et définitions . . . . . . . . . . . . . . . . . . . 4

1.2.2 Exemple de Formalisme . . . . . . . . . . . . . . . . . . 5

1.2.3 Cohérence dans les CSPs . . . . . . . . . . . . . . . . . . 5

1.3 La Configuration par résolution interactive . . . . . . 6

1.3.1 Configuration à base de contraintes . . . . . . . . . . . . 6

1.3.2 La recommandation en configuration interactive . . . . . 8

1.3.3 Méthodes de résolution interactive des problèmes deconfiguration . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3.4 Compilation de CSPs . . . . . . . . . . . . . . . . . . . . 10

1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Problématique 132.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Algorithmes de résolution de problèmes de configu-ration interactive . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 GIC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.3 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Protocole de validation . . . . . . . . . . . . . . . . . . . . 19

2.3.1 Jeux d’essai . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2 Protocole complet FCP . . . . . . . . . . . . . . . . . . . 20

vi

2.3.3 Variantes du protocole complet . . . . . . . . . . . . . . 21

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Outil de validation et d’expérimentation 233.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Approche API et les bibliothèques des approches expé-rimentées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Que tester et pourquoi ? . . . . . . . . . . . . . . . . . . . . 25

3.4 Validation des solveurs . . . . . . . . . . . . . . . . . . . . 26

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Résultats expérimentaux 274.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 Phase d’initialisation dans les trois protocoles . . . . . . . 28

4.1.2 Protocole Complet FCP . . . . . . . . . . . . . . . . . . . 30

4.1.3 Protocole GC . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.4 Protocole GC-At-Minimal-Price . . . . . . . . . . . . . . . 38

4.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Conclusion générale 43

Bibliographie 49

Liste des figures

1.1 Les deux solutions pour le problème de 4-reines . . . . . . . 5

1.2 Schéma d’un système de configuration (Nejsum 2003) . . . . 7

4.1 Temps cpu (en ms) pour la phase d’initialisation (A) d’unprotocole (FCP, GC ou GC-At-Min-Price) avec le problèmesmall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Temps cpu (en ms) pour la phase d’initialisation d’un pro-tocole (FCP, GC ou GC-At-Min-Price) avec le problème me-dium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

vii

4.3 Temps cpu (en ms) pour la phase d’initialisation (A) d’unprotocole (FCP, GC ou GC-At-Min-Price) avec le problèmebig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4 Temps cpu (en ms) pour la phase de propagation (B) duprotocole complet (FCP) avec le problème small . . . . . . . 30

4.5 Temps cpu (en ms) pour la phase de propagation (B) duprotocole complet (FCP) avec le problème medium . . . . . 31

4.6 Temps cpu (en ms) pour la phase de propagation (B) duprotocole complet (FCP) avec le problème big . . . . . . . . 31

4.7 Temps cpu (en ms) pour la phase de dépropagation (C) duprotocole complet (FCP) avec le problème small . . . . . . . 32

4.8 Temps cpu (en ms) pour la phase de dépropagation (C) duprotocole complet (FCP) avec le problème medium . . . . . 32

4.9 Temps cpu (en ms) pour la phase de dépropagation (C) duprotocole complet (FCP) avec le problème big . . . . . . . . 33

4.10 Tables des temps cpu (en ms) moyens pour le protocolecomplet (FCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.11 Tables des résultats pour le protocole complet (FCP) . . . . . 34

4.12 Temps cpu (en ms) pour la phase de propagation (B) duprotocole greedy (GC) avec le problème small . . . . . . . . 35

4.13 Temps cpu (en ms) pour la phase de propagation (B) duprotocole greedy (GC) avec le problème medium . . . . . . . 35

4.14 Temps cpu (en ms) pour la phase de propagation (B) duprotocole greedy (GC) avec le problème big . . . . . . . . . . 36

4.15 Tables des temps cpu (en ms) moyens pour le protocolegrerdy (GC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.16 Tables des résultats pour le protocole greedy (GC) . . . . . . 37

4.17 Temps cpu (en ms) pour la phase de propagation du pro-tocole GC avec le problème big . . . . . . . . . . . . . . . . . 38

4.18 Temps cpu (en ms) pour la phase de propagation (B) duprotocole greedy at minimal price (GC-At-Min-Price) avecle problème big . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.19 Temps cpu (en ms) pour la phase de propagation (B) duprotocole greedy at minimal price (GC-At-Min-Price) avecle problème medium . . . . . . . . . . . . . . . . . . . . . . . 39

4.20 Temps cpu (en ms) pour la phase de propagation (B) duprotocole greedy at minimal price (GC-At-Min-Price) avecle problème small . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.21 Tables des temps cpu (en ms) moyens pour le protocole atminimal price (GC-At-Min-Price) . . . . . . . . . . . . . . . . 40

viii

4.22 Tables des résultats pour le protocole at minimal price (GC-At-Min-Price) . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

23 Diagramme de classe partiel de l’outil de validation et ex-périmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

ix

Introduction générale

Les problèmes de satisfactions de contraintes (CSP) sont au cœur denombreuses applications en intelligence artificielle et la recherche opé-rationnelle. Un CSP permet de modéliser des problèmes combinatoiresissus du domaine académique et du monde réel, telles que l’allocation deressources, l’ordonnancement, la planification, la configuration de pro-duits, pour ensuite essayer de trouver un ensemble de solutions pour leCSP. Un CSP est défini par un réseau de contraintes impliquant un cer-tains nombres de variables. La résolution d’un CSP consiste à trouver unensembles de valeurs à affecter aux variables, de telle façon que toutes lescontraintes du problèmes soient satisfaites.

Constraint programmaing represents one of the closest approaches computerscience has yet made to the Holy Grail of programming of programming : theuser states the problem, the computer solves it. Eugene C.Freuder.Lorsque la machine se charge de retrouver une solution à problème CSP,on dit que la résolution est automatique. En revanche, dans les applica-tions destinées aux problèmes de configuration de produits basées surles réseaux de contraintes, c’est l’utilisateur (client, vendeur, concepteur)qui construit sa propre solution selon ces préférences et non la machine,qui a pour rôle de l’aider dans la construction d’une solution en lui re-tirant progressivement les choix d’affectations qui risquent de violer lescontraintes du problème et suggérant des choix d’affectations sur des va-riables. Alors ici on parle de résolution interactive.De nombreuses approches par résolution interactive ont été proposées.elles doivent donc guider en ligne l’utilisateur vers la solution 1 qui ré-pond le mieux à ses besoins. Il se trouve que dans certaines applicationsde configuration, elles doivent émettre des suggestion de choix à l’utilisa-teur, ou à partir d’une configuration partielle proposer un produit com-plet. Le but n’est pas de présenter un produit quelconque à l’utilisateurmais le bon produit qui répond à ces préférences et celles du fournisseurs.

C’est La thématique du projet ANR Blanc “BR4CP” (Business Recom-

1. Une solution CSP pour un problème de configuration est produit configurable

1

2 Liste des figures

mendation for Configurable Products) qui réunit un groupe d’industriels,Cameleon software, IBM et Renault et de laboratoires de recherche, le Centrede Recherche en Informatique de Lens (Lens), le Laboratoire en Infor-matique et Robotique et Micro électronique de Montpellier (LIRMM) etl’Institut de Recherche en Informatique de Toulouse (IRIT), où j’effectuemon stage. L’ambition de projet est d’améliorer les systèmes de configura-tion interactive existants sous plusieurs aspects dont la recommandation.Ce projet ANR se positionne donc dans dans deux branches du domainedu e–commerce ; la configuration interactive et la recommandation.

Il s’agit de développer des algorithmes de recommandation, maisaussi des algorithmes de résolution de problèmes de configuration inter-active qui augmenter les performances des solveurs de configuration.

Différentes approches de résolution de problèmes de configuration deproduits ont été développées par les partenaires du projet BR4CP. Afinde réaliser une étude expérimentale comparative de ces différentes ap-proches, un protocole de validation a été défini dans le projet. L’objectifdu stage de Master 2 recherche dont rend compte ce mémoire était de réa-liser une étude expérimentale comparative de ces différentes approches. Ils’agit de (i) réaliser un logiciel qui implémente un protocole de validationdéfini par les partenaires, (ii) de confronter les résultats des différentes bi-bliothèques fournies par les partenaires à des fin de validation (debug) et(iii) de mesurer et comparer les performances de ces approches. L’en-semble des tests devait être réalisés sur des jeux d’essai originaux fournispar la société Renault.

Chapitre 1

Étude bibliographique

Sommaire

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Problème de satisfaction de contraintes (CSP) . . . . . . 4

1.2.1 Notations et définitions . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Exemple de Formalisme . . . . . . . . . . . . . . . . . . . . 5

1.2.3 Cohérence dans les CSPs . . . . . . . . . . . . . . . . . . . . 5

1.3 La Configuration par résolution interactive . . . . . . . 6

1.3.1 Configuration à base de contraintes . . . . . . . . . . . . . 6

1.3.2 La recommandation en configuration interactive . . . . . . 8

1.3.3 Méthodes de résolution interactive des problèmes deconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3.4 Compilation de CSPs . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1 Introduction

Le sujet de ce mémoire porte sur les approches de résolution interac-tive de problèmes de configuration de produits basés sur le formalisme deConstraint Satisfaction Problems (CSP). Il est important pour nous de com-mencer d’exposer la notion de résolution interactive et de compilationde CSPs en toute généralité. Ensuite, nous nous orientons vers les pro-blèmes de configuration de produits, en étudiant comment les résoudrede manière interactive.

3

4 Chapitre 1. Étude bibliographique

Dans le présent chapitre, nous commencerons d’abord par expliquerles notions fondamentales des problèmes de satisfaction de contrainteset par donner quelques exemples de CSP (section 1.2). En second lieu,dans la section 1.3, nous donnerons un aperçu général sur la résolutioninteractive puis nous nous focaliserons sur la configuration interactive àbase de contrainte. Nous évoquerons enfin le concept de recommandationdans le processus de configuration interactive.

1.2 Problème de satisfaction de contraintes (CSP)

1.2.1 Notations et définitions

Un problème de satisfaction de contraintes (Constraint SatisfactionProblem CSP), appelé également “réseau de contraintes” (Montanari 1974)est défini par la donnée d’un ensemble fini de variables à domaine fini, etd’un ensemble fini de contraintes. Chaque contrainte limite les combinai-sons de valeurs que peuvent prendre les variables impliquées dans cettecontrainte. Ainsi, une solution est une affectation complète de valeurssur les variables, de sorte que toutes les contraintes soient satisfaites.Formellement :

Un CSP peut être défini par un triplet P = (X ,D, C) où :• X est un ensemble fini de n variables {x1, x2, ..., xn}.• D est l’ensemble des domaines, qui associe à chaque variable xi ∈X un ensemble fini D(xi) = {d1, d2, ..., dn} de valeurs possibles pourxi.• C est un ensemble fini de m contraintes {c1, c2, ..., cm}. Chaque

contrainte ci porte sur un sous–ensemble de variables Xci ⊆ X ,et est définie par par un sous–ensemble du produit cartésien∏xt∈Xci

D(xt) qui spécifie les combinaisons de valeurs (ou tuples)autorisées pour les variables de Xci .

La cardinalité de |Xci| est l’arité de la contrainte ci. on dit que ci est :� unaire si son arité est égale à 1 (x = 1)� binaire si son arité est égale à 2 (x + y < 3)� n–aire si son arité est égale à n (exemple : all–different)

Soit un CSP (X ,D, C), On appelle une affectation A de XA ={ x1, ..., xk }⊆ X une application qui associe à chaque variable xAi ∈ XA une valeurdu domaine de xAi. On note : A(xi) la valeur que A affecte à xi.Une solution pour (X ,D, C) est une affectation des variables de l’en-

1.2. Problème de satisfaction de contraintes (CSP) 5

semble X qui est complète et valide. Une affectation est complète si elleimplique toutes les variables de X , et valide si toutes les contraintes sontsatisfaites. On note Sol(P) l’ensemble des solutions.Sol(P) = {s ∈ S|∀c ∈ C, s ∈ c}.La question de savoir si un CSP possède une solution définit un problèmeNP–complet.

1.2.2 Exemple de Formalisme

Problème des N-reines

Le problème consiste à placer n reines sur un échiquier de n× n sansqu’aucune d’entre elles ne puisse être prise par les autres, c’est-à-dire quedeux reines ne peuvent pas être sur une même ligne, une même colonneou une même diagonale de l’échiquier.

Une modélisation simple du problème de N-reines :• Variables : X = { xi/1 ≤ i ≤ n }• Domaines : ∀xi ∈ X, D(xi) ={ j/1 ≤ j ≤ n }• Contraintes : C = { cij|(xi 6= xj) ∧ (|xi − xj| 6= |i− j|), 1 ≤ i ≤ n et

1 ≤ j ≤ n }

Pour un problème de 4-reines, les deux solutions possibles sont pré-senté dans la figure 1.1.

Figure 1.1 – Les deux solutions pour le problème de 4-reines

1.2.3 Cohérence dans les CSPs

Dans cette section, nous allons présenter deux types de cohérence dedeux niveaux différents. Le cohérence d’arc Montanari (1974), Mackworth(1977), Waltz (1975) qui la forme de cohérence locale la plus ancienne etla plus utilisée (AC–1/2/3(Mackworth 1977), AC–4 (Mohr et Henderson


1986), AC–6 (Bessière 1994), AC2001 (Bessière et Régin 2001)), et autre deniveau de cohérence globale, qui est la cohérence inverse globale (Bes-siere et al. 2013).

Définition 1.1 Cohérence d’arc :Soit un CSP (X ,D, C), soit une contrainte binaire c ∈ C portant sur les variablex et y avec leur domaine respectif D(x) et D(y), telle que c ⊂ D(x)× D(y).Nous dirons que c est arc cohérent si :� ∀a ∈ D(x), ∀b ∈ D(y), (a, b) ∈ c� ∀b ∈ D(y), ∀a ∈ D(x), (a, b) ∈ c

Un CSP est arc-cohérent si toutes ces contraintes binaires sont sont cohérentes.

Définition 1.2 Cohérence Inverse Globale :Dans un CSP (X ,D, C), une valeur d ∈ D(xi) est globalement cohérente in-verse (GIC) ssi ∃s ∈ S une solution de (X ,D, C) telle que s(xi) = d dansl’instanciation de s. Un CSP (X ,D, C) est globalement cohérent inverse ssi lesvaleurs de toutes ses domaines sont GIC.

1.3 La Configuration par résolution interactive

La programmation par contraintes offre une large variété de méthodesde résolution de problèmes CSP. Néanmoins, les solveurs CSP procèdentcomme des boites noires où l’utilisateur n’a pas la possibilité d’intervenirdans la recherche de solution. Par conséquent, le résultat obtenu risqued’être de mauvaise qualité puisque c’est la machine elle-seule qui s’oc-cupe de la résolution et qu’elle ne prend pas en compte les préférencesde l’utilisateur. Pour remédier à cela, la communauté CP propose uneautre approche de résolution qui est interactive (Gelle 1998). La résolu-tion interactive est une approche de type aide à la décision. L’utilisateurest en charge de fixer (respectivement relaxer) des choix d’affectation devaleurs à des variables. La machine assiste l’utilisateur en propageant lesconséquences de chaque choix qu’il effectue, terminant la résolution (autocomplétion) et filtrant (respectivement en restaurant) des valeurs incohé-rents (respectivement cohérents avec les affectations courante), de sorteà garder pour l’utilisateur uniquement des possibilités d’affectation quimènent à une à solution.

1.3.1 Configuration à base de contraintes

En e-commerce et plus particulièrement dans la vente de produitsstandardisés, l’ensemble des produits est capturé par la base de données

1.3. La Configuration par résolution interactive 7

que le client va explorer à sa guise. Lorsque le produit n’est plus stan-dardisé mais configurable, défini par la sélection d’un certain nombred’options, choix de configuration, . . . etc, une telle approche n’est paspossible : le nombre de produit possibles est généralement exponentiel.En confirmation de véhicule par exemple, l’ensemble des fourgonettes deRenault de type “traffic” comprend 1021 véhicules différents, pas réali-sables.

Pour créer un modèle de configuration à base de contraintes, leconcepteur doit d’abord définir les composants (standard ou paramé-trable) et/ou fonction, et les options de son objet (produit, service ouprocédé). Ces composants sont représentés par des variables dans leformalisme CSP, dont les valeurs sont impliquées dans des contraintesde faisabilité. La modélisation de la gamme de véhicules de Renault (As-tesana et al. 2010) est un exemple typique, où la gamme est l’ensemblede toutes les différentes variant possible d’un modèle

• Une voiture est modélisé par un ensemble de variables, notamment :{carburant, couleur, etc}• Les domaines sont définis par les ensembles de valeurs possibles

pour chacune des variables ({ essence, diesel, gpl }, { blanc, noir, rouge}, ... etc)

Une fois le modèle est crée, il est mis en ligne pour les utilisateurs(clients, vendeurs). Chaque utilisateur peut alors interagir avec le modèle.Cette tâche est appelée configuration interactive (sales configuration).La figure 1.2 donne un aperçu général de la composition d’un système deconfiguration.

Figure 1.2 – Schéma d’un système de configuration (Nejsum 2003)


Lors de la configuration interactive, l’utilisateur sélectionne des com-posants, choisit des options, a aussi la possibilité de revenir en arrièreen retirant des choix. En effet, dans les cas de conflit 1, l’utilisateur estobligé de le faire afin de pouvoir poursuivre sa configuration. De soncôté de le programme intervient après chaque action de l’utilisateur, pouréliminer des futurs choix possibles les choix désormais interdits (ils n’ap-partiennent à aucune configuration complète valide), ou afin de réintro-duire de choix à nouveau possibles, émettre des propositions de pro-duits complets, autrement dit suggérer des configurations complétées.Dans certains configurateurs (où on propose à l’utilisateur un choix noncompatible avec la configuration courante), si le conflit est provoqué, leprogramme identifie les choix à remettre en cause pour rendre la confi-guration cohérente. En termes de CSP, ceci se traduit pour l’utilisateurpar :• L’affectation aux variable des valeurs de leurs domaines, ou• Le relâchement de variables, c’est-à-dire que celles–ci deviennent

libres.Pour le programme par :• La propagation des contraintes induites, ce qui provoque l’élimina-

tion de certaines valeurs dans les domaines des variables, lorsquecelles-ci ne pas GIC cohérentes.• Dépropagation (restauration des domaines après relaxation de

choix)• La complétion d’affectation courante.

De nombreux systèmes de configuration basés sur les approches derésolution interactive ont été réalisées (Vareilles 2005) et appliqués dansun ensemble de domaines très large. Parmi ces domaines on peut citer :

– Conception de pièces mécaniques (Vargas 1995)– Conception d’avion (Mulyanto 2002)– Conception de processus d’usinage (Ruet 2002)– Conception d’un mixer industriel (Gelle 1998)– Conception de produits à forte diversité (Hadj-Hamou 2002)

1.3.2 La recommandation en configuration interactive

La recommandation est une activité largement utilisée dans la ventede produits standardisés (par exemple chez Amazon, Pixmania, . . . etc).

1. On dit qu’il y a une situation de conflit lorsque l’utilisateur décide de forcer unchoix qui est interdit (incompatible avec la configuration courante).

1.3. La Configuration par résolution interactive 9

Elle a pour objectif d’aider l’utilisateur à construire ses préférences, etprendre une décision dans un environnement interactif en lui servant deschoix susceptibles de satisfaire ces préférences.

Dans un système de configuration combiné avec la recommandation,l’idée servant d’émettre des suggestions de choix à l’utilisateur, ou àpartir d’une configuration partielle proposer une configuration validepotentiellement intéressante pour l’utilisateur. Le but n’est pas de pré-senter un produit quelconque à l’utilisateur mais un bon produit quirépond à ses préférences (et celles du vendeur).

1.3.3 Méthodes de résolution interactive des problèmes de confi-guration

Pour filtrer les domaines en cours de session de configuration, leschercheurs ont proposé soit des algorithmes de filtrage complets maispotentiellement inefficaces (maintenir de la GIC défini un problème NP-complet), soit des approches incomplètes approximant la GIC par l’arccohérence par exemple, mais possédant de meilleure performances entermes de temps de résolution. En d’autres termes, les méthodes derésolution interactive peuvent être classées en deux catégories, cellesqui assurent une cohérence inverse globale (Global Inverse Consistency(GIC)) et celles qui sont approximatives, c’est-à-dire se basant sur desalgorithmes de filtrage avec une cohérence locale.

Méthodes de filtrage de cohérence locale

Le filtrage par cohérence d’arc est la plus anciennes technique de cohé-rence locale. Les premiers algorithmes permettant d’établir l’arc–cohérence,ont été proposés par (Mackworth 1977) (AC–1, AC–2, AC–3), par la suiteplusieurs variantes ont été développées, AC–4 (Mohr et Henderson 1986),AC–5 (Hentenryck et al. 1992), AC–6 (Bessière 1994), AC–7 (Bessière et al.1999) et AC2001 (Bessière et Régin 2001)).

Vareilles (2005) dans ses travaux de thèse doctorat sur l’aide à laconception interactive à base de contraintes à construit un outil qui uti-lise quatre types de CSPs (contraintes à variables discrètes, à variablescontinues, mixtes liant des variables discrètes et continues et contraintesdynamiques), rassemblés dans un seul modèle de connaissances. Pour as-


surer l’interactivité de l’outil, elle utilise de trois méthodes de filtrage defaible degré 2 (arc–cohérence, 2B–cohérence 3, discrétisation).

Dans (Becker et Fargier 2013), une nouvelle manière de faire de laconfiguration interactive a été développée. L’idée est d’offrir à l’utilisa-teur la possibilité de pouvoir remplacer par exemple une option par uneautre dans sa configuration courante. Cette méthode s’appelle Calcul dedomaines alternatifs. Le principe est simple, pour une variable xi on chercheà savoir quelles sont les valeurs qu’on peut lui affecter sans changer lesvaleurs des autres variables modulo le niveau de cohérence (locale ouglobale) utilisée dans le système.

Filtrage par cohérence inverse globale

Depuis plusieurs années, les différentes applications de résolutioninteractive, ainsi que différents solveurs génériques de problèmes deconfiguration qui ont été développés n’avaient pas la propriété de lapréservation de la cohérence inverse globale dans un CSP. Or, il estindésirable pour une application de configuration interactive qu’un l’uti-lisateur voulant construire sa solution, risque de partir sur un choix deconfiguration qui ne mène pas à une solution.

Dans (Bessiere et al. 2013), les auteurs décrivent quatre algorithmes demaintien de la cohérence inverse (GIC1, GIC2, GIC3, GIC4). L’algorithmeGIC4 qui est en fait une amélioration de GIC1/2/3 se base sur une table desolutions qu’il maintien durant ce processus interactif entre l’utilisateur etle configurateur. L’objectif est de garder en mémoire toutes les solutionstrouvées après le calcul des valeurs GIC dans cette table de solutions. Lecontenu de cette table est mis à jour à chaque choix de l’utilisateur.

1.3.4 Compilation de CSPs

Une autre manière de préserver la cohérence globale inverse dans uneconfiguration interactive est de faire de la compilation (Hadzic 2004, An-dersen et al. 2007, Fargier et al. 2013) de problèmes CSP. La compilationconsiste à générer à partir d’un problème CSP d’origine un diagramme

2. Faible degré de cohérence signifie cohérence locale3. La 2B–cohérence (Lhomme 1993) est une approximation de l’arc–cohérence qui

considère seulement les borne des domaines (les domaines sont présentés par des inter-valles)

1.4. Conclusion 11

de décision. Ce dernier est perçu comme étant une représentation com-pacte de l’ensemble des solutions correspondants au CSP. Le plus sou-vent, le diagramme de décision est multivalué 4 (Multi–valued DecisionDiagrams (MDD)), car ceci facilite mieux la manipulation des variables,et il est représenté sous forme de graphe acyclique orienté stockant lescombinaisons d’affectations possibles.

La compilation d’un CSP est un processus qui peut être très couteux entemps de calcul. L’idée est donc de pretraiter (“compiler”) le CSP originalen une forme qui permet un traitement efficace de requête. Cette compi-lation (qui peut être chronophage) s’effectue hors ligne, avant la phase deconfiguration.

1.4 Conclusion

Dans ce chapitre que nous nous sommes consacré dans un premiertemps à la présentation des notions fondamentales de la programma-tion par contraintes, le formalisme CSP. Ensuite, nous avons expliquéle concept de configuration interactive et présenter les grandes lignessur des méthodes de résolution de la configuration interactive sous for-malisme CSP et les difficultés ainsi qu’y résidents, à travers quelquestravaux réalisés dans les systèmes de configuration. Finalement, nousconstatons qu’il existe, d’une part des méthodes exactes, le filtrage parcohérence globale (approches GIC et approches utilisant des diagrammesde décision), et d’autre part des approches que nous qualifions d’ap-proximatives, puisque elles n’assurent pas la cohérence globale dans leCSP –(méthodes de filtrage de cohérence locale).

Le chapitre suivant, consacré à la problématique de notre travail,détaille les approches qui ont été développées dans le cadre du projetBR4CP.

4. Dans la majorité des cas, les variables d’un réseau de contraintes ne sont pasbooléennes.

Chapitre 2

Problématique

Sommaire

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Algorithmes de résolution de problèmes de configura-tion interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 GIC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.3 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Protocole de validation . . . . . . . . . . . . . . . . . . . . . . 19

2.3.1 Jeux d’essai . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2 Protocole complet FCP . . . . . . . . . . . . . . . . . . . . . 20

2.3.3 Variantes du protocole complet . . . . . . . . . . . . . . . . 21

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1 Introduction

Dans ce chapitre dédié à notre cadre de travail et la problématique dece stage. Nous décrirons, dans la section 2.2 les algorithmes de résolutioninteractive développées dans le projet BR4CP. Dans la section2.3, nousexposerons le protocole de la simulation de la procédure de configurationinteractive de produit défini dans le projet. La conclusion sera consacréeà la situation de notre problématique.

13

14 Chapitre 2. Problématique

2.2 Algorithmes de résolution de problèmes de

configuration interactive développés dans

BR4CP

Dans cette partie, nous allons présenter trois approches de résolutionde problèmes de configuration qui été étudiées, par la suite implémentéesdans des solveurs, dans le cadre du projet BR4CP.

2.2.1 GIC4

La tâche des solveurs est de maintenir la cohérence globale inverse desdomaines (GIC) des variables de configuration de manière dynamiques,c’est à dire après chaque choix d’affectation par l’utilisateur comme aprèschaque relaxation d’un de ces choix. Parmi les méthodes de filtragesexistantes pour réaliser le maintien de la GIC, on trouve l’algorithmeGIC4 (Bessiere et al. 2013) qui en fait une amélioration des algorithmes(GIC1\2\3) Bessiere et al. (2013).

Nous rappelons que le principe des algorithmes de filtrages pour lemaintien de la cohérence globale inverse consiste à éliminer des domainesdes variables qui n’appartiennent à aucune solution compatible avec leschoix connus. Ceci revient à dire, qu’on garde seulement les valeurs quiappartiennent à un tuple solution du problème courant.

Le principe de GIC4 est de générer une table de solutions qui justi-fient la cohérence inverse globale de chacune des valeurs des domainesapparus dans cette table. Par la suite, à chaque interaction avec l’utilisa-teur dans la résolution interactives, la table des solutions est mise à jourpour lui retirer les affectations qui ne sont plus valides ou introduire denouvelles affectations qui sont des solutions au problème.

L’algorithme 1 décrit le fonctionnement de GIC4. La table des solu-tions courantes est donnée par les éléments du tableau solutions allant del’indice 1 jusqu’à nbSolutions. Afin, d’éviter de tester toutes les variables,deux ensembles de variables appelées Sval et Ssup ont été introduit, oùSval correspond aux variables dont le domaine a changé et Ssup corres-pond aux variables libres 1 pour lesquelles il faut déterminer les valeursGIC et mettre à jour la liste des valeurs GIC dans gicValues[xi] de chaque

1. Une variable de CSP est libre tant qu’elle n’est pas instanciée

2.2. Algorithmes de résolution de problèmes de configuration interactive15

variables libres xi.

Algorithme 1 : GIC4(N : CN)//Initialization of structuresSval ← ∅ foreach variable x ∈ vars(N) do

if |dom(x)| 6=lastSize[x] thenSval ← Sval∪{x}

Ssup ← ∅foreach variable x ∈ vars f ut(N) do

gicValues[x]← ∅Ssup ← Ssup∪{x}

//The table of current solutions is traversedi← 1while i ≤nbSolutions do

if isValid(Sval,solutions[i]) thenhandleSolution4(solutions[i])i ++

elsesolutions[i]←solutions[nbSolutions]nbSolutions−−

//Search for values not currently supported is performedforeach variable x ∈ varssup do

I ←searchSolutionFor(N|x=a)if I = nil then

remove a from dom(x)else

nbSolutions++solutions[nbSolutions]← IhandleSolution4(I)

foreach variable x ∈ vars f ut(N) dolastSize[x]← |dom(x)|

Algorithme 2 : handleSolution4(I : instantiation)foreach variable x ∈ Ssup do

if I|x| /∈gicValues[x] thengicValue[x]←gicValues[x]∪{I[x]}if |gicValue[x] = |dom(x)| then

Ssup ← Ssup \{x}


2.2.2 Backbone

Nous présentons dans cette section une approche proposée par D.LeBerre un calcul itératif de backbone (Marques-Silva et al. 2010). Le pro-blème de configuration modélisé en CSP ayant été traduit en un pro-blème de satisfaction de formule propositionnelle SAT (méthode di-recte (?)).Le problème de configuration (X ,D, C) est traduit en en for-mule propositionnelle F sur l’ensemble de variables propositionnellesP ={xi,d|xi ∈ X ∧ d ∈ Di}.

Une valeur d d’un domaine Di n’est GIC ssi elle n’apparait dans au-cune affectation complète satisfaisant toutes les clauses. D’un point devue propositionnelle, cela peut se traduit par : F |= ¬xi,d.

L’idée de cet l’algorithme 3 (IBB), est de calculer à chaque choix del’utilisateur l’intersection des modèles de la formule propositionnelleafin de détecter les littéraux impliqués (Déharbe et al. 2013) de F, puisd’éliminer les valeurs non GIC, c’est-à-dire correspondant aux littérauximpliquées négatifs. Dans un premier temps l’algorithme suppose quela formule F est satisfiable, c’est-à-dire qu’il est possible de trouver unpremier modèle de F. Les littéraux de ce modèle forment la liste deslittéraux potentiellement impliqués par la formule. Puis, le modèle estréduit en un impliquant premier IP(Φ,modele) afin d’éviter à tester toutles littéraux du modèle (lorsque il y a réponse UNSAT alors cela signifie

2.2. Algorithmes de résolution de problèmes de configuration interactive17

que tous les littéraux sont impliqués).

Algorithme 3 : Calcul de littéraux impliquées IBBinput : Une formule propositionnelle satisfiable Φoutput : L’ensemble de littéraux impliqués par Φ

modele← estSatisfiable(Φ);totest←{¬li|li ∈ IP(Φ,modele)}backbone← ∅;repeat

modele← estSatisfiable(Φ ∧∨totest)

if modele == UNSAT thenbackbone←{¬p|p ∈ totest }totest← ∅

elseimpliquant← IP(Φ,modele)// enlève les littéraux à tster couverts par l’impliquanttotest← totest \impliquant// enlève le littéraux à tester qui n’apparaissent pas dansl’impliquanttotest← totest \{¬li|li ∈ totest ∧¬li /∈ impliquant}

until totest = ∅;return backbone

2.2.3 Compilation

La compilation des CSP est une approche qui a monté de très bonnesperformances en particulier dans la résolution interactive de problèmede configuration de produit. Dans Amilhastre et al. (2002), Hadzic (2004),Andersen et al. (2007), Fargier et al. (2013) les auteurs proposent de repré-senter l’ensemble des solutions d’un CSP par la forme d’un diagrammede décision.

Ce diagramme de décision, donc un automate à état, introduit par(Vempaty 1992) un graphe acyclique orienté constitué d’un état initial Iqui est la racine, un état final F et un ensemble de n états intermédiaires{q1, q2, ..., qn} et relié par des arcs. Chaque sous ensemble de nœuds(états) de même rang est étiqueté par une variable xi du CSP, chaque arcsortant est valué par une valeur di du domaine D(xi). Une solution auCSP est alors un chemin dans l’automate associé allant de I jusqu’à F, et


réciproquement.

En théorie la taille de l’automate peut être exponentiel au pire cas,en revanche en pratique et particulier dans les problèmes réels qui nousconcernent – c’est-à-dire ceux de la configuration de produits leurs dia-grammes associés sont de taille polynomiale. Selon (Fargier et al. 2013),les raisons qui permettent de garder une taille raisonable (souvant plusfaible que celle des CSPs d’origine) sont :◦ L’interchangeabilité des valeurs des domaines◦ La structure du produit formé de sous produits qui sont plus au

moins indépendants les uns des autres.

En outre, le compilateur conçu par (Fargier et al. 2013) permet decompiler des problèmes de satisfaction de contraintes valuées (VCSPs),cela offre la possibilité donc de représenter les fonctions de valuations–fonctions associant une valuation (coût, utilité, probabilité, etc.) aux af-fectations de variables dans un diagramme de décision valué (VDD).Afin, d’obtenir la structure compilé la plus compacte possible, les au-teurs se sont appuyés sont les trois langages de VDD : ADD (?), SLDD? et AADD??. De plus, malgré le fait les AADD soient une généralisationdes SLDD, ce dernier type de diagramme semblerai être plus performantque ce dernier. Au final dans la pratique le SLDD est amplement suffi-sants pour la compilation des problèmes de configuration de produits.L’intérêt de ces langages de compilation est qu’ils permettent une ma-nipulation efficace de l’ensemble des solutions du CSP valué. Dans cetapproche, la résolution interactive du problème de configuration de pro-duits se résume à des opérations de :• Conditionnement (pour l’affectation des variables) :

Cette opération est une transformation du graphe à l’issu d’uneaffectation d’un sous–ensemble de variables. Cette transformation,qui est linéaire dans la taille du graphe, consiste à supprimer toutarc issu d’un noeud étiqueté par la une variable de l’affectation, quiporte une valeur différente de celle indiqué dans l’affectation.• Optimisation (pour le maintien du coût minimal associé à la solution

courante) :L’optimisation s’effectue par un algorithme de plus court chemindans le diagramme. L’idée est parcourir le diagramme en largeurd’abord, et en annotant chaque nœud atteint par la valuation opti-male depuis la source vers ce nœud ; le chemin correspondant estaussi mémorisé au niveau du nœud. On retrouve donc sur le nœud

2.3. Protocole de validation 19

terminal la valuation optimale ainsi que le chemin optimale.

La maintenance du diagramme valué grâce aux deux opérations deconditionnement et d’optimisation permet de préserver la cohérence deschoix d’une configuration courante. En effet, une valeur di du domainede la variable xi est GIC ssi il existe un arc qui support la valeur di pourla variable xi, et qui appartient à un chemin de poids null allant de I à F.

2.3 Protocole de validation

Dans cette section, nous présentons les trois protocoles de validationque nous allons implémenter et les jeux d’essai utilisés dans nos expéri-mentations.

2.3.1 Jeux d’essai

Les jeux d’essai utilisés dans BR4CP ont été fournis par la société Re-nault. Il s’agit trois benchmarks 2 de produits configurables exprimés auxdeux formats Aralia et XCSP 2.1 qui sont :

– small : est un CSP 139 variables et 147 contraintes– medium : est un CSP 148 variables et 174 contraintes– big : est un CSP 268 variables et 332 contraintes.

Ces benchmarks sont des problèmes CSP contenant des variables dis-crètes, représentant chacun une gamme automobile de Renault, où lesnoms des variables ont été modifiés pour dissimuler la sémantique réelledes produits. Le medium par exemple est une petite voiture urbaine et lebig modélise un utilitaire, dont l’ensemble des variables (268 variables) estbeaucoup plus important comparé aux deux autres benchmarks (mediumet small). Donc, pour des tests expérimentaux sur des solveurs le problèmebig se présente comme un bon benchmark pour le te test de performancesdes solveurs

A chaque benchmark, est associé un fichier Prices contenant les don-nées prix du produit. Alors, pour les deux formats (Aralia et XCSP), unbenchmark et le fichier prices correspondant ont été crée.

2. Ces benchmarks peuvent être retrouver sur la page : http://www.irit.fr/~Helene.Fargier/BR4CP/benches.html

http://www.irit.fr/~Helene.Fargier/BR4CP/benches.html

http://www.irit.fr/~Helene.Fargier/BR4CP/benches.html


2.3.2 Protocole complet FCP

Le Full Configuration Protocol (FCP) est une simulation du processus deconfiguration interactive permet de tester la validité et les performancesde chacun des solveurs développés dans le projet BR4CP en simulantune session de configuration interactive. Il consiste à affecter pas à pasdes valeurs aux variables, à chaque pas les domaines sont filtrés pourles rendre GIC–consistant (les valeurs qui ne n’appartiennent à aucuneaffectation complète valide (solution) sont éliminés dans leurs domainescorrespondant) et les prix minimaux et maximaux selon la configurationcourante sont calculés.

Dans le cas où il y a une situation de conflit, càd qu’une valeur dichoisi pour être affectée à une variable xi n’est plus dans le domaineGIC–consistent courant de xi, une séquence de backtrak est effectuée, quirelaxe les choix faits avant jusqu’à ce que di réapparaisse dans le domainexi.

Des version du protocole existent, il peut être scenarized ou statisti-cal. Dans la version statistical un scénario est généré aléatoirement, leschoix d’assignment ou d’unassignment sont aléatoires. Au contraire, danscontrairement à la version scenarized l’ensemble des assignments et unas-signments ont été produit à l’avance.

A) Rendre les domaines originaux GIC

B) Phase de propagation :* Passer le prochain assignment (vi, di)* Si la valeur (di) n’apparait pas dans le domaine courant de la

variable vi Alors aller vers (C).* Sinon :

1. Assigner la valeur di à la variable vi

2. Calculer le prix minimal et maximal correspondant à la confi-guration courante.

3. Maintenir la cohérence globale dans les domaines.

4. Si une incohérence dans les choix courants est détectée, alorsil y a un bug dans votre solveur : l’opération de maintien dela GIC dans les domaine a échoué.

C) Phase de restauration de la valeur

1. Passer la prochaine variable affectée ui, et dépropager

2.3. Protocole de validation 21

2. Calculer le prix minimal et maximal correspondant à la confi-guration courante après dépropagation.

3. Maintenir la cohérence globale dans les domaines.

4. Si la valeur désirer est réapparu dans le domaine courant de vialors terminer, sinon allez vers (C.1)

Donc, la résolution du CSP dans ce protocole est répartie en trois étapedistinctes, une première pour l’initialisation, la seconde celle d’affectationdite Assignement phase (ou B dans le protocole) et une dernière étape Va-lue Restauration qui consiste à relâcher certaines variables explicitementaffectées 3 à la phase B afin rendre la valeur di Gic.

2.3.3 Variantes du protocole complet

D’autres protocoles dérivés du FCP avec moins fonctionnalités ou par-fois une simplification du FCP, ont été proposé. Parmi ces variantes nousavons sélectionné le Gic–Approx et Greedy pour les présenter.

Greedy Configuration Protocol (Priced/Unpriced)

Le Greedy Configuration protocol (GC) protocole inclut uniquement lesdeux premiers étapes A et B du FCP, car ici les choix ne sont jamais remisen cause. En effet, les valeurs sont tirées à partir des domaines courants,et non des domaines originaux, ce qui permet d’éviter de choisir des va-leurs non GIC. Lors que les prix maximum et minimum des configurationcompatibles avec les choix courants sont calculés après chaque affectation,on parle de protocole Greedy priced noté GC-P sinon le protocole Greedyunpriced (noté GC-U).

Greedy Configuration Protocol At Minimal Price

Dans cette simulation, le but est de construire des solutions dont lecoût est le moins cher : avant chaque affectation de variable, la palette desprix associés aux valeurs possible de la variable est calculée, ce qui permetde choisir la valeur conduisant à une configuration de prix minimal.

3. Une variable est explicitement affectée quand elle est sélectionnée par le pro-gramme FCP pour être affectée à une valeur de son domaine, et non pas affectée parl’algorithme de propagation du solver


2.4 Conclusion

Dans ce chapitre nous avons pu exposer le contexte de travail danslequel se position ce mémoire. Nous avons décrit trois approches (baséessur SAT, sur CSP, ou sur des techniques de compilation de connaissances)de résolution interactive des problèmes de configuration de produits, quiont été développés et implémentées dans le cadre du projet BR4CP. Puis,nous avons présenter la partie validation des différentes approches deconfiguration interactive, où un protocole d’expérimentation a été pro-posé par les partenaires de BR4CP. Ainsi, l’objectif de ce stage est deréaliser cette étude comparative expérimentale des ces approches, à par-tir du protocole de validation et les benchmarks fournis par la sociétéRenault. Il s’agit donc de réaliser un logiciel qui implémente ce protocoleet l’execute en faisant appel aux packages (AbsCon, Sat4J et Compila-teurSLDD) à tester. Les performances (temps cpu) et les résultats serontensuite analysés statistiquement afin de dégager les approches les plusfiables et les plus efficaces.

Chapitre 3

Outil de validation etd’expérimentation

Sommaire

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Approche API et les bibliothèques des approches expé-rimentées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Que tester et pourquoi ? . . . . . . . . . . . . . . . . . . . . . . 25

3.4 Validation des solveurs . . . . . . . . . . . . . . . . . . . . . . 26

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1 Introduction

Ce chapitre se propose de présenter notre outil de validation quenous avons implémenté. Nous décrirons dans un premier temps notreapproche et les trois bibliothèques qui implémentent chacune une desapproches décrites dans la section 2.2, puis nous présenterons les para-mètres de tests sur lesquels on s’est basé et finir par la validation desbibliothèques.

3.2 Approche API et les bibliothèques des ap-proches expérimentées

Dans notre étude comparative expérimentale nous avons eu à expéri-menter les trois approches (GIC4, Backbone et Compilation de problème CSP

23

24 Chapitre 3. Outil de validation et d’expérimentation

décrites dans la section 2.2, en faisant appel à des bibliothèque dévelop-pées en Java :• La bibliothèque de AbsCon 1 (http://www.cril.univ-artois.fr/~lecoutre/software.html#) implémente l’algorithmeGIC4 (section 2.2.1).• La bibliothèque Sat4j 2 (http://www.sat4j.org/) implémente

l’algorithme du backbone (section 2.2.2).• La bibliothèque CompilateurSLLD qui se base sur l’approche de

Compilation de CSP (section 2.2.3).

Afin de pouvoir interagir avec ces différentes bibliothèques, une APIConfigurator commune a été crée lors de la rencontre qui nous a réuni àLens quelques jours après le début de notre stage. Cette API définit desméthodes (voir en annexe page 45) qui seront implémentées par chacunedes bibliothèques qui nous ont été fourni. Ces méthodes sont :◦ Le chargement d’un problème.◦ L’assignation d’une valeur à une variable puis propagation.◦ Détermination de l’existence d’une valeur dans le domaine courant

d’une variable.◦ La relaxation de variable et dépropagation.◦ Le calcul du prix minimal (respectivement maximal) correspondant

à la configuration courante.◦ Le calcul des prix minimaux (respectivement maximaux) pour

chaque valeur possible du domaine courant de la prochaine variableà assigner.◦ L’affichage du domaine courant pour une variable.◦ L’affichage de l’ensemble des variables libres.◦ Détermination de la complétude de la configuration courante.◦ Détermination de la cohérence de la configuration courante.

Notre outil de validation développé en langage Java, implémente lesprotocole de validation(section 2.3) définis dans BR4CP. Une premièredifficulté nous a paru quand nous avons voulu, pour des raisons de gé-nie logiciel, crée un programme générique qui implémente les différentsprotocoles. En effet, chacun des protocoles, existe en deux version, une

1. AbsCon est un solveur CSP réalisé par C.Lecoutre, ce solveur qui est très per-formant a notamment arrivé en second place à la International CSP Solver Competitionhttp://cpai.ucc.ie/06/Competition.html de 2006

2. Sat4j est un solveur SAT réalisé par D.Le berre, ce solveur n’est pas connu poursa rapidité de résolution comparé aux autres solveurs SAT, mais reste un solveur trèsrobuste et complet

http://www.cril.univ-artois.fr/~lecoutre/software.html#

http://www.cril.univ-artois.fr/~lecoutre/software.html#

http://www.sat4j.org/

http://cpai.ucc.ie/06/Competition.html

3.3. Que tester et pourquoi ? 25

version scenarized (les scénarios de configuration sont connu à l’avance)et une autre version statistical (les scénarios sont produits aléatoirement,pendant la simulation), avec calcul de prix ou sans. De plus, un protocoleGreedy 3 reprend le même principe que le protocole FCP, néanmoins sansdans la partie Restauration de valeur du FCP mais il est différent en ce quiconcerne les choix d’assignments, tel est le cas pour le GC-At-Min-P oùil faut prendre la valeur qui mène vers la configuration de prix minimal.Pour remédier à cette difficulté nous avons conçu un diagramme de classeque nous pensons pouvoir être le plus adéquat pour rassembler au mieuxces différents protocoles de configuration (voir en annexe page 47).

3.3 Que tester et pourquoi ?

Lorsque l’outil de validation exécute un des algorithmes du protocole,le solveurs à qui il fait appel doit être capable de répondre à un certainsnombres de critères de validation, afin de pouvoir évaluer l’approche derésolution du solveur. Les tests portent sur les performances des tempsd’exécutions des différente étapes dans la configuration, et sur des para-mètres de validation permettant de vérifier la validité des résultats retour-nés par ces différents solveurs. Pour chacun des types de configurationdu protocole nous avons une liste de tests, alors pour la configurationcomplète (FCP) nous calculons le :• Nombre de d’affectations explicites effectuées avant d’avoir un

conflit• Nombre de valeurs supprimées dans les domaines• Prix minimaux et maximaux moyen de la configuration courante• Nombre de de relaxation de variables nécessaire pour restaurer la

valeur du conflit• Nombre de valeurs réintroduites dans les domaines• Temps d’exécution de la phase d’initialisation (A)• Temps d’exécution des étapes d’affectation et propagation et de cal-

cul de prix (B2 + B3)• Temps d’exécution des étapes de désaffectation et propagation et de

calcul de prix (C2 + C3)• Temps d’exécution total

3. On parle des protocoles Greedy pour désigner le : Greedy Configuration Unpriced(GC-U), Greedy Configuration Priced (GC-P) et Greedy Configuration At Minimal Price (GC-At-Min-P)

26 Chapitre 3. Outil de validation et d’expérimentation

Pour les protocoles de GC d’execution d’un scénario de configurationil faut calculer le :• Nombre de d’affectations explicites effectuées dans la configuration• Nombre de valeurs supprimées dans les domaines• Les prix minimaux et maximaux de la configuration courante ainsi

que, pour le protocole GC-At-Min-Price le prix minimal associé àchaque valeur possible du domaine de la prochaine variable à affec-ter• Temps d’exécution de la phase d’initialisation (A)• Temps d’exécution des étapes d’affectation et propagation et de cal-

cul de prix• Temps d’exécution total

3.4 Validation des solveurs

Une tâche importante qu’il fallait réaliser est de détecter les bugs dessolveurs qu’ils nous ont été fourni. En effet, tout au long de cette étudeexpérimentale nous avons travaillé en collaboration avec les auteurs destrois bibliothèques afin de corriger les incohérences de résultats détectéeslors de nos tests de validation (et donc les bugs dans les bibliothèquesfournies). En outre, durant les premières versions des bibliothèques four-nies n’implémentaient pas toutes les méthodes de l’interface Configurator,alors il nous a fallu s’adapter à chacune des bibliothèques, et apporter lesmodification après chaque nouvelle version. Les premiers résultats d’ex-périmentation de notre outil ont été obtenu deux mois après le début dece stage.

3.5 Conclusion

A l’issu de ce travail de validation et debugging, nous pouvons testertous les protocoles sur la librairie CompilateurSLDD dans leurs versionsPriced et Unpriced. Le solveur AbsCon-br4cp a également été validé, maisn’implémente pas les fonctionnalités liées à la gestion des prix – les pro-tocoles FCP et GC peuvent être testés, mais seulement dans leur versionUnpriced. En ce qui concerne le solveur Sat4j-br4cp, les fonctionnalités liéesau retrait de choix restent encore problématiques. Seuls donc les proto-coles greedy sont testables dans leurs version Priced et Unpriced.

Chapitre 4

Résultats expérimentaux

Sommaire

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 Phase d’initialisation dans les trois protocoles . . . . . . . 28

4.1.2 Protocole Complet FCP . . . . . . . . . . . . . . . . . . . . . 30

4.1.3 Protocole GC . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.4 Protocole GC-At-Minimal-Price . . . . . . . . . . . . . . . . 38

4.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Introduction

Ce chapitre présente et analyse nos résultats expérimentaux.

Dans ces expérimentations, nous avons testé les trois approches(GIC4Compilation, et Bachbone) implémentées dans les bibliothèques(AbsCon-br4cp, CompilateurSLDD et Sat4j-br4cp) sur le protocole completFCP et les deux variantes GC et GC-At-Minimal-Prices en version Statisti-cal avec les trois problèmes (small, medium et big) . Afin de comparer lesperformances (temps cpu) des solveurs et vérifier la compatibiltés des ré-sultats de configuration retournés, nous utilisons les mêmes scénarios deconfiguration pour les trois solveurs. Dans Sat4j-br4cp, comme on n’arri-vait pas à reproduire les mêmes scénarios en version statistical, pour desraisons expliquées dans la section 3.4, nous avons choisi d’exécuter le pro-tocole en version scenarized en utilisant nos propres scénarios que nous

27

28 Chapitre 4. Résultats expérimentaux

avons créer à partir de la bibliothèque CompilateurSLDD), ils sont iden-tiques à ceux scénarios produis en version statistical par (AbsCon-br4cp etCompilateurSLDD).

Les expérimentations sont réalisées sur cent scénarios pour chaqueproblèmes. Toutes les expérimentation sont effectuées sur une machineIntel Xeon(R) E5620 2.40GHz sous Linux.

4.1.1 Phase d’initialisation dans les trois protocoles

Dans les trois protocoles (FCP, GC et GC-At-Min-Price) que nous avonsexpérimenté, la phase d’initialisation (A) est la même pour tous les trois :il s’agit de charger les données et de s’assurer que tous les domainessont GIC-cohérents. Alors, nous avons choisi d’illustrer pour un seul proto-cole 1, les temps d’exécutions de (A) sur les trois solveurs. Les figures 4.1,4.2 et 4.3 présentent les résultats d cette phase d’initialisation dans chaquebenchmarks. Nous voyons clairement que sur les trois problèmes (small,medium et big) que le solveurs CompilateurSLDD est le meilleure. Ceciest d’autant plus évident puisque pour la bibliothèque CompilateurSLDDla phase d’initialisation consiste à charger le fichier compilé. En outre, lesolveurs Sat4j-br4cp, qui le moins performant dans cette phase, est trèslent lorsqu’il s’agit du problème big (20000 millisconde).

1. Nous avons choisi le protocole greedy pour avoir les temps des trois solveurs surles mêmes scénarios

4.1. Introduction 29

Figure 4.1 – Temps cpu (en ms) pour la phase d’initialisation (A) d’un protocole (FCP,GC ou GC-At-Min-Price) avec le problème small

Figure 4.2 – Temps cpu (en ms) pour la phase d’initialisation d’un protocole (FCP, GCou GC-At-Min-Price) avec le problème medium

Figure 4.3 – Temps cpu (en ms) pour la phase d’initialisation (A) d’un protocole (FCP,GC ou GC-At-Min-Price) avec le problème big


4.1.2 Protocole Complet FCP

Dans cette section dédiée à l’expérimentation du protocole completFCP, nous faisons une comparaison des tests entre les deux bibliothèquesAbsCon-br4cp et CompilateurSLDD. La bibliothèque sat4j-br4cp n’a pas étéinclus car implémentation de phase de dépropagation (C) du protocoleFCP n’a pas été validé (existence des bugs).

Les figures 4.6, 4.5 et 4.4 présentent les temps (cpu) d’exécutions de laphase (B) du protocole FCP sur un ensembles de cents scénarios simuléssur les solveurs AbsCon-br4cp et CompilateurSLDD. Nous constatons clai-rement que dans la phase de propagation (B) l’approche Compilation estnettement plus rapide que le GIC4 du AbsCon-br4cp dans les trois jeuxd’essai, et les variations en fonction des différents scénarios sont beau-coup plus brutales pour le AbsCon-br4cp, ce qui n’apparait pas tellementdans le CompilateurSLDD.

Dans la figure 4.10 des tables reprenant les temps d’exécutions pourle protocole FCP, nous remarquons que sur les trois benchmarks le Com-pilateurSLDD est cinq fois plus rapide pour la phase B.

Figure 4.4 – Temps cpu (en ms) pour la phase de propagation (B) du protocole complet(FCP) avec le problème small


Figure 4.5 – Temps cpu (en ms) pour la phase de propagation (B) du protocole complet(FCP) avec le problème medium

Figure 4.6 – Temps cpu (en ms) pour la phase de propagation (B) du protocole complet(FCP) avec le problème big

Les figures 4.9, 4.8 et 4.7 présentes les temps (cpu) d’executions de laphase de dépropagation (C). Dans ces figures, les courbes des deux sol-veurs montrent que les temps d’executions de la phase de dépropagationest pratiquement constante chez CompilateurSLDD et très instable pourAbsCon-br4cp. Nous remarquons aussi que dans le AbsCon-br4cp cette


phase est plus coûteuse que la phase (B) à l’inverse du CompilateurSLDDoù elle un plus plus rapide.

Figure 4.7 – Temps cpu (en ms) pour la phase de dépropagation (C) du protocole complet(FCP) avec le problème small

Figure 4.8 – Temps cpu (en ms) pour la phase de dépropagation (C) du protocole complet(FCP) avec le problème medium


Figure 4.9 – Temps cpu (en ms) pour la phase de dépropagation (C) du protocole complet(FCP) avec le problème big

En résumé nous obtenons pour le protocole FCP :

(a) Problème small (b) Problème medium

(c) Problème big

Figure 4.10 – Tables des temps cpu (en ms) moyens pour le protocole complet (FCP)

4.1.3 Protocole GC

Nous avons experimenté le protocole GC sur les trois bibliothèquesavec trois les jeux d’essai (small, medium et big). Nous simulons centscénarios dans chaque benchmark et nous mesurons les temps cpu de la



(c) Problème big

Figure 4.11 – Tables des résultats pour le protocole complet (FCP)

phase de propagation (B). Les résultats sont présentés dans les figures4.12, 4.13 et 4.14, donc nous constatons que, pour les trois bechmarks lessolveurs AbsCon-br4cp et CompilateurSLDD sont nettement plus perfor-mant que Sat4j-br4cp.

Dans la figure 4.15, les tables présentent le temps moyen du déroule-ment des scénarios du problème small, medium et big. Nous remarquonsque pour les trois problèmes que, le CompilateurSLDD est le meilleur destrois solveurs. En effet dans le small et medium CompilateurSLDD est dixfois plus rapide que le AbsCon-br4cp et cent fois plus rapide que Sat4j-br4cp.

Par ailleurs avec le problème big, le coefficient d’augmentation duAbsCon-br4cp par rapport au CompilateurSLDD est plus inférieur aux casdes problèmes small et medium.

La figure des tables 4.16 présente les mesures des paramètres de va-lidation, où nous calculons les moyennes pour l’ensemble des cent scé-narios simulés dans le GC. Nous observons dans ces trois tables que lesrésultats retournés par les solveurs sont tous compatibles sauf dans l pro-


Figure 4.12 – Temps cpu (en ms) pour la phase de propagation (B) du protocole greedy(GC) avec le problème small

Figure 4.13 – Temps cpu (en ms) pour la phase de propagation (B) du protocole greedy(GC) avec le problème medium


Figure 4.14 – Temps cpu (en ms) pour la phase de propagation (B) du protocole greedy(GC) avec le problème big

blème medium où le prix minimum moyen est différent entre Compila-teurSLDD et Sat4j-br4cp.

Dans ces expérimentation, nous comparons les trois solveurs sur l’évo-lution du temps de propagation de l’ensemble des choix dans les scéna-rios pour un problème big, où nous calculons une moyenne pour chaqueniveau de choix. La figure 4.17 présente les courbes des trois solveurs,scénario par scénario.

Dans cette expérimentation on s’intéresse moins à la comparaison desperformances entre les trois solveurs, mais plus à l’évolution de la courbedes temps de propagation dans chacune des trois approches. Nous nousapercevons donc que de manière générale les deux courbes des solveursAbsCon-br4cp et Sat4j-br4cp suivent la même progression, c’est-à-dire quedans les deux premières propagations les temps sont élevés puis unediminution très brusque jusqu’à arriver un seuil (6 propagation) où lescourbes décroit plus lentement. Pour le solveur AbsCon-br4cp nous remar-quons que la courbe devient régulière après légère décroissance pendantles 3 premieres propagations. Nous observons aussi que la courbe dusolveur AbsCon-br4cp peut être légèrement au dessous de celle du Compi-lateurSLDD après le seuil.



(c) Problème big

Figure 4.15 – Tables des temps cpu (en ms) moyens pour le protocole grerdy (GC)


(c) Problème big

Figure 4.16 – Tables des résultats pour le protocole greedy (GC)


Figure 4.17 – Temps cpu (en ms) pour la phase de propagation du protocole GC avec leproblème big

4.1.4 Protocole GC-At-Minimal-Price

Dans ce dernier protocole (GC-At-Minimal-Price) nous avons réalisénos tests uniquement sur les deux solveurs CompilateurSLDD et Sat4j-br4cp, car le AbsCon-br4cp n’implémente pas le maintien des prix. Noussimulons un ensemble de cent scénarios dans chaque benchmark. Ainsi,nous évaluons les performances (temps cpu) des deux solveurs (Compi-lateurSLDD et Sat4j-br4cp), présentées dans les figures 4.18, 4.19 et 4.20

et la figure 4.21 des tables des temps moyens d’exécution de l’ensembledes scénarios simulés dans ce protocole. Puis, nous comparons les résul-tats obtenus dans les paramètres de validation et en particulier les prixminimaux.

Nous pourrons fait les mêmes observation dans les deux protocolesGC-Priced et GC-Unpriced. Dans les deux cas, le solveur CompilateurSLDDest beaucoup plus rapide que le solveur Sat4j-br4cp.

Dans cette figure 4.22, nous remarquons que dans les trois cas deproblème, les deux solveurs trouvent les mêmes prix minimaux, ce quine prouve que les deux solveurs sont valides dans le protocole GC-At-Minimal-Price.


Figure 4.18 – Temps cpu (en ms) pour la phase de propagation (B) du protocole greedyat minimal price (GC-At-Min-Price) avec le problème big

Figure 4.19 – Temps cpu (en ms) pour la phase de propagation (B) du protocole greedyat minimal price (GC-At-Min-Price) avec le problème medium


Figure 4.20 – Temps cpu (en ms) pour la phase de propagation (B) du protocole greedyat minimal price (GC-At-Min-Price) avec le problème small


(c) Problème big

Figure 4.21 – Tables des temps cpu (en ms) moyens pour le protocole at minimal price(GC-At-Min-Price)

4.2. Conclusion 41


(c) Problème big

Figure 4.22 – Tables des résultats pour le protocole at minimal price (GC-At-Min-Price)

4.2 Conclusion

Sans surprise l’approche compilée est la plus efficace, mais l’ap-proches GIC4 fournit d’exellentes resultats contrairement à ce que l’onpourrait croire croire, il est envisageable de maintenir de la GIC en ligne :les problème de configuration de voiture fournissent des instances “fa-ciles" dans cette problématique. De plus, cette étude a permis de dé-montrer que l’approche basée sur la recherche du premier impliquant(Backbone) est faisable pour la maintien de la cohérence inverse globale.Mais l’approche Backbone fait appel au solveur Sat4j qui désavantage cettedernière, car pour des raisons d’efficacités ce solveur ne permet pas destatuer sur les performances de temps.

Conclusion générale

Au cours de ce mémoire, nous avons réalisé un outil de validation etd’expérimentation des approches de résolution interactive de problèmesde configuration de produits, proposées dans le cadre du projet BR4CP.Cet outil implémente trois protocoles (le protocole complet (FCP), les pro-tocoles greedy (GC et GC-At-Min-Price) ) de validation définis par les par-tenaires de BR4CP. Nous avons fait une validation des trois bibliothèquesimplémentant chacune une approche développée dans se projet :• La bibliothèque de AbsCon-br4cp implémentant l’approche GIC4• La bibliothèque Sat4j-br4cp implémentant l’approche de recherche

de premier impliquant backbone.• La bibliothèque CompilateurSLLD qui se base sur l’approche de

Compilation de CSP.

A l’issu de cette phase de validation et de debugging, nous avons puexécuter tous les protocoles sur la bibliothèque CompilateurSLLD sousles deux versions (Priced et Unpriced). La bibliothèque AbsCon-br4cp aégalement été validé, mais n’implémente pas les fonctionnalités de calculdes prix – le protocole complet et le protocole greedy peuvent être testémais uniquement sous leur version Unpriced. En ce qui concerne lesolveur Sat4j-br4cp, les fonctionnalités liées au retrait de choix, n’ont pasété validées. Ainsi, seulement les protocoles greedy ont été testés dansleur deux versions Priced et Unpriced.

Nos expérimentations, montrent que, comme prévu l’approche decompilation de problèmes CSPs est la méthode la plus efficace des troisapproches étudiées. Nous avons également constater que la méthode di-recte (GIC4) offre également de très bonnes performances. Donc, il estenvisageable de maintenir la cohérence inverse globale en ligne. En fin,pour l’approche basé sur le calcul de premier impliquant (Backbone) nerépondait pas dans temps raisonnables quand il s’agit de tester des pro-blèmes durs mais cela est dû au fait que la bibliothèque de Sat4j (connu

43


comme une bibliothèque très complete mais moins efficaces comparée àd’autres solveurs SAT) à qui elle fait appel, ne statué pas sur les tests deperformances.

Perspectives

Dans la continuité directe de notre travail, on pourra chercher à mo-difier le jeu d’essai / construire d’autres jeux afin de durcir les problèmeset comprendre jusqu’où ces approches peuvent aller et quels sont les pa-ramètres qui les mettent en échec. Pour ce faire, nous avons deux propo-sitions :• Retirer des tuples dans les contraintes, où• Rajouter des contraintes aléatoires.

Annexe

�1

2 publ ic i n t e r f a c e Configurator {3

4 void readProblem ( S t r i n g problemName ) ;5

6 void assignAndPropagate ( S t r i n g var , S t r i n g val ) ;7

8 void unassignAndRestore ( S t r i n g var ) ;9

10 i n t minCost ( ) ;11

12 Map<Str ing , Str ing > minCostConfiguration ( ) ;13

14 i n t maxCost ( ) ;15

16 Map<Str ing , Str ing > maxCostConfiguration ( ) ;17

18 i n t getSizeOfCurrentDomainOf ( S t r i n g var ) ;19

20 boolean isPresentInCurrentDomain ( S t r i n g var , S t r i n g val ) ;21

22 Set <Str ing > getCurrentDomainOf ( S t r i n g var ) ;23

24 Map<Str ing , Integer > minCosts ( S t r i n g var ) ;25

26 Map<Str ing , Integer > maxCosts ( S t r i n g var ) ;27

28 Set <Str ing > g e t F r e e V a r i a b l e s ( ) ;29

30 boolean isConfigurationComplete ( ) ;31

32 boolean i s P o s s i b l y C o n s i s t e n t ( ) ;33

34 Set <Str ing > getAlternativeDomainOf ( S t r i n g var ) ;35 } �

Listing 1 – Extraits du code source de l’API Configurator

45


�1 publ ic i n t e r f a c e Conf iguratorFactory {2

3 /∗∗4 ∗ Create a c o n f i g u r a t o r o b j e c t s u i t a b l e f o r a5 ∗ given protoco l .6 ∗/7 Configurator make ( Protoco l p ) ;8

9 } �Listing 2 – Extraits du code source de l’API Configurator�

1 publ ic i n t e r f a c e Conf iguratorFactory {2

3 publ ic enum Protoco l {4 /∗∗ Bas ic Tes ts ∗/5 BT ,6 /∗∗ F u l l Configurat ion Protoco l ∗/7 FCP ,8 /∗∗ Greedy , unpriced , c o n f i g u r a t i o n ∗/9 GC_U,

10 /∗∗ Greedy c o n f i g u r a t i o n at minimal p r i c e ∗/11 GC_p,12 /∗∗ Approximating Global Inverse Consistency ∗/13 } �

Listing 3 – Extraits du code source de l’API Configurator

4.2. Conclusion 47

Figure 23 – Diagramme de classe partiel de l’outil de validation et expérimentation

Bibliographie

Jérôme Amilhastre, Hélène Fargier, et Pierre Marquis. Consistency resto-ration and explanations in dynamic csps application to configuration.Artif. Intell., 135(1-2) :199–234, 2002. (Cité page 17.)

Henrik Reif Andersen, Tarik Hadzic, John N. Hooker, et Peter Tiedemann.A constraint store based on multivalued decision diagrams. Dans CP,pages 118–132, 2007. (Cité pages 10 et 17.)

Jean-Marc Astesana, Laurent Cosserat, et Hélène Fargier. Constraint-based vehicle configuration : A case study. Dans ICTAI (1), pages 68–75,2010. (Cité page 7.)

Caroline Becker et Hélène Fargier. Maintaining alternative values inconstraint-based configuration. Dans IJCAI, 2013. (Cité page 10.)

Christian Bessière. Arc-consistency and arc-consistency again. Artif. In-tell., 65(1) :179–190, 1994. (Cité pages 6 et 9.)

Christian Bessiere, Hélène Fargier, et Christophe Lecoutre. Global inverseconsistency for interactive constraint satisfaction. Dans CP, pages 159–174, 2013. (Cité pages 6, 10 et 14.)

Christian Bessière, Eugene C. Freuder, et Jean-Charles Régin. Usingconstraint metaknowledge to reduce arc consistency computation. Ar-tif. Intell., 107(1) :125–148, 1999. (Cité page 9.)

Christian Bessière et Jean-Charles Régin. Refining the basic constraintpropagation algorithm. Dans IJCAI, pages 309–315, 2001. (Cité pages 6

et 9.)

David Déharbe, Pascal Fontaine, Daniel Le Berre, et Bertrand Mazure.Computing prime implicants. Dans FMCAD, pages 46–52, 2013. (Citépage 16.)

49

50 Bibliographie

Hélène Fargier, Pierre Marquis, et Nicolas Schmidt. Compacité pratiquedes diagrammes de décision valués : normalisation, heuristiques et ex-périmentations (regular paper). Dans Journées Francophones de Program-mation par Contraintes (JFPC), Aix en Provence, 14/06/2013-16/06/2013,pages 123–132, http ://www.lsis.org, 2013. (Cité pages 10, 17 et 18.)

E Gelle. On the generation of locally consistent solution spaces in mixed dyna-mic constraint problems. PhD thesis, Thèse de doctorat, École Polytech-nique Fédérale de Lausanne, 1998. (Cité pages 6 et 8.)

K Hadj-Hamou. Contribution à la conception de produits à forte diversité etde leur chaîne logistique : une approche par contraintes. PhD thesis, Thèsede doctorat, Institut National Polytechnique de Toulouse, France., 2002.(Cité page 8.)

Tarik Hadzic. A bdd-based approach to interactive configuration. DansCP, page 797, 2004. (Cité pages 10 et 17.)

Pascal Van Hentenryck, Yves Deville, et Choh-Man Teng. A generic arc-consistency algorithm and its specializations. Artif. Intell., 57(2-3) :291–321, 1992. (Cité page 9.)

Olivier Lhomme. Consistency techniques for numeric csps. Dans IJCAI,pages 232–238, 1993. (Cité page 10.)

Alan K. Mackworth. Consistency in networks of relations. Artif. Intell., 8

(1) :99–118, 1977. (Cité pages 5 et 9.)

João Marques-Silva, Mikolás Janota, et Inês Lynce. On computing back-bones of propositional theories. Dans ECAI, pages 15–20, 2010. (Citépage 16.)

Sanjay Mittal et Felix Frayman. Towards a generic model of configuratontasks. Dans IJCAI, pages 1395–1401, 1989.

Roger Mohr et Thomas C. Henderson. Arc and path consistency revisited.Artif. Intell., 28(2) :225–233, 1986. (Cité pages 5 et 9.)

U. Montanari. Networks of constraints : fundamental properties and ap-plication to picture processing. In Information sciences, 7 :95–132, 1974.(Cité pages 4 et 5.)

T Mulyanto. Utilisation des techniques de programmation par contraintes pourla conception d’avions. PhD thesis, Thèse de doctorat, École Nationale

Bibliographie 51

Supérieure de l’Aéronautique et de l’Espace, Toulouse, France, 2002.(Cité page 8.)

J.M Nejsum. Methods for interactive constrainte satisfation. Master’sthesis, University of Copenhag, 2003. (Cité pages vii et 7.)

Olivier Roussel et Christophe Lecoutre. Xml representation of constraintnetworks : Format xcsp 2.1. CoRR, abs/0902.2362, 2009.

M Ruet. Capitalisation et réutilisation d’expériences dans un contexte multiac-teur. PhD thesis, Thèse de doctorat, Institut National Polytechnique deToulouse, France., 2002. (Cité page 8.)

Daniel Sabin et Rainer Weigel. Product configuration frameworks - asurvey. IEEE Intelligent Systems, 13(4) :42–49, 1998.

Camille Salinesi, Raouia Triki, et Raúl Mazo. Combining configurationand recommendation to define an interactive product line configurationapproach. CoRR, abs/1206.2520, 2012.

Elise Vareilles. title. PhD thesis, shcool, 2005. (Cité pages 8 et 9.)

C Vargas. Modélisation du processus de conception en ingeniérie des systèmesmécaniques. Mise en oeuvre basée sur la propagation de contraintes. Applica-tion à la conception d’une culasse automobile. PhD thesis, Thèse de docto-rat, École Normale Supérieure de Cachan,France, 1995. (Cité page 8.)

Nageshwara Rao Vempaty. Solving constraint satisfaction problems usingfinite state automata. Dans AAAI, pages 453–458, 1992. (Cité page 17.)

Mathieu Véron. Modélisation et résolution du problème de configuration indus-trielle : utilisation des techniques de satisfaction de contraintes. PhD thesis,Thèse de doctorat, Institut National Polytechnique de Toulouse, France,2001.

David Waltz. Understanding line drawings of scenes with shadows. DansThe Psychology of Computer Vision, page pages. McGraw-Hill, 1975. (Citépage 5.)

Titre Résolution interactive et compilation de problèmes de satisfactionde contraintes

Résumé Les problèmes de configuration sont des exemples typiquesdes approches de résolution interactive. Dans le cadre d’un projet de re-cherche qui rassemblent laboratoires de recherche et industriels, plusieursapproches différentes de ce problème on été proposées et implémentées(recherche de premier impliquant basée sur SAT, GIC4 basée sur CSP etapproche basée sur la compilation de CSP) . Notre travail était de faireune étude comparative expérimentale des ces approches à partir d’unprotocole défini dans le projet. Nous avons donc implémenté un outil devalidation et d’expérimentation à partir de ce protocole. Dans un premier,nous avons donc valider les bibliothèque implémentant ces approches,par la suite l’expérimentation. Nos expérimentation ont montré que l’ap-proches compilé est la plus efficaces, mais l’approche GIC4 fournit d’ex-cellents résultats contrairement à ce que l’on s’attendait. Pour l’approchesbasée sur la recherche de premier impliquant nous constatons qu’elle estfaisable pour ce types de problèmes mais comme elle fait appel au sol-veur Sat4j qui est moyennement efficace, cela a était un désavantage auniveau performance.

Mots-clès décision, méthodes et algorithmes, satisfaction decontraintes, compilation, théorie de la complexité

Résolution interactive et compilation de problèmes de ... · matique et Robotique et Micro...

Documents

Transcript of Résolution interactive et compilation de problèmes de ... · matique et Robotique et Micro...