Solution générique pour la résolution des problèmes statiques de tournées de véhicules

66

description

 

Transcript of Solution générique pour la résolution des problèmes statiques de tournées de véhicules

ii

DÉDICACES

A mes très chers parents,pour tout l'amour dont vous m'avez entouré, pour vos attachement, j'apporte à vous

beaucoup d'a�ection et de reconnaissance.Je ferais de mon mieu pour rester un sujet de �erté à vos yeux avec

l'espoir de ne jamais vous décevoir.Que ce modeste travail, soit l'exaucement de vos veux tant formulés et de

vos prières quotidienne.A mes très chers frères :Fayçal,Achraf et Malek,

A mon très cher oncle :Mustapha,vous occupez une place particulière dans mon coeur. Je vous dédie ce

travail en vous souhaitant un avenir radieux, plein debonheur et de succès.

A mon oncle Kamel et ma tante Aicha,Je n'oublie pas notre navette chaque matin et l'ambiance familiale qu'on a passé durantles 4 ans de mes études universitaires, en souhaitant que mon dieux vous protège.

A mes très chers amis,En souvenir de nos éclats de rire et des bons moments. En souvenir de

tout ce qu'on a vécu ensemble. J'éspère de tout monCoeur que notre amitié durera éternellement.

Asma Boudhief

DÉDICACES

A ce qu'est toujours mon meilleur exemple dans la viemon très cher père

Pour les sacri�ces qu'il a consentis pour mon éducation et pour l'avenir qu'il n'a cesséd'o�rir.

A ce qui m'a été toujours la garante d'une existence paisible et d'un avenir radieuxma mère

A ce qui a fait de son mieux pour me soutenir durant ce travailma chère soeur : Hanen

A ceux qui m'ont soutenu, encouragé, apprécie mon e�ort et crée le milieu favorable,l'ambiance joyeuse et l'atmosphère joviale pour mon procurer ce travail

mes adorables frères : Salem, Adnen, Ahmed Amine

A toutes ces personnes que j'ai senties redoutable de leur dédier ce modeste travail avecmes vifs remerciements et les expressions respectueuses de ma profonde gratitude.

Slimen Belhaj Ali

Remerciements

Nous remercions, Monsieur Sami ACHOUR, d'avoir accepté de présider notresoutenance de projet de �n d'étude.

Nous tenons également à remercier profondément, MademoiselleNesrine DARRAGI , pour

le temps qu'il a investi pour évaluer notre travail.

Nous remercions particulièrement notre encadreur, Madame Zoulel Kouki et notreco-encadreur, Madame Besma Fayech Châar pour

leur encadrement de qualité dont il nous a fait béné�cier aimablement, leur aideprécieuse, leurs remarques constructives, leur disponibilité et leur soutien inépuisable.

Nos plus sincères remerciement s'adressent aussi à :Tous les enseignants qui nous ont soutenus durant notre cursus universitaire et quinous ont appris les bonnes connaissances pour réussir dans la vie professionnelle.

Nos collègues qui ont contribué à l'aboutissement de ce travail par de nombreusesdiscussions, nous ne citerons pas de noms ici pour ne pas oublier certains.

Table des matières

Introduction générale 1

1 Etat d'art 3

1.1 Le Problème du voyageur de commerce(PVC) . . . . . . . . . . . . . . 3

1.2 Le problème de tournées de véhicules(PTV) . . . . . . . . . . . . . . . 4

1.2.1 Dé�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Les variantes du problème . . . . . . . . . . . . . . . . . . . . . 5

1.2.3 Les caractéristiques et les di�érents types du PTV . . . . . . . . 5

1.2.4 Les méthodes de résolution . . . . . . . . . . . . . . . . . . . . . 8

1.2.4.1 Méthodes de résolution exactes . . . . . . . . . . . . . 8

1.2.4.2 L'utilité des heuristiques . . . . . . . . . . . . . . . . 8

1.2.4.3 Métaheuristiques utiles pour la résolution du PTV . . 9

1.2.4.4 Comparaison de quelques algorithmes heuristiques . . 11

2 Etude théorique 14

2.1 Formulation mathématique . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1 Formulation mathématique du problème du voyageur de com-merce(PVC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

TABLE DES MATIÈRES vi

2.1.2 Formulation mathématique du problème de tournées des véhi-cules(PTV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.3 Formulation mathématique du problème de tournées des véhi-cules à capacités limitées(PTV à capacités) . . . . . . . . . . . . 18

2.1.4 Formulation mathématique du problème de tournées des véhi-cules avec fenêtre de temps(PTV à fenêtre de temps) . . . . . . 19

2.2 Résolution des variantes PTV basée sur la recherche taboue(RT) . . . . 19

2.2.1 Principe de la RT . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.2 Algorithme de la méthode de recherche taboue . . . . . . . . . . 21

2.2.3 Choix de la solution initiale . . . . . . . . . . . . . . . . . . . . 22

2.2.4 La liste taboue . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.5 La Mémoire Adaptative . . . . . . . . . . . . . . . . . . . . . . 23

2.2.6 Le critère d'aspiration . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.7 Le critère d'intensi�cation . . . . . . . . . . . . . . . . . . . . . 24

2.2.8 Les critères d'arrêt . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Etude conceptuelle 26

3.1 Spéci�cation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1.1 Diagramme des cas d'utilisation . . . . . . . . . . . . 27

3.1.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 Structure statique du système . . . . . . . . . . . . . . . . . . . 28

3.2.1.1 Description des classes . . . . . . . . . . . . . . . . . . 28

3.2.1.2 Diagramme de classes pour chaque problème . . . . . . 29

3.2.1.3 Diagramme de classes général . . . . . . . . . . . . . . 33

TABLE DES MATIÈRES vii

3.2.2 Etude dynamique du système . . . . . . . . . . . . . . . . . . . 34

3.2.2.1 Diagramme de séquence : Visualisation d'une solutiond'un problème TSP . . . . . . . . . . . . . . . . . . . . 35

3.2.2.2 Diagramme de séquence : Ajout d'un problème VRP . 36

4 Réalisation 38

4.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . 38

4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.2.1 DotNet . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.2.2 EDraw (conception) . . . . . . . . . . . . . . . . . . . 40

4.1.2.3 Latex (traitement du texte) . . . . . . . . . . . . . . . 40

4.1.2.4 Photoshop cs4 . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.1 Framework 3.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.2 WPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.3 Les langages de programmation . . . . . . . . . . . . . . . . . . 42

4.2.3.1 CSharp.net . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.3.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Réalisation de l'application . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.1 Page d'acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.2 Page principale . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.3 Résolution d'un problème PTV : Choix d'une insatance . . . . . 46

4.3.4 Suppression d'un problème . . . . . . . . . . . . . . . . . . . . . 47

4.3.5 Ajout d'un problème . . . . . . . . . . . . . . . . . . . . . . . . 47

TABLE DES MATIÈRES viii

Conclusion générale 50

Bibliographie 52

A Réalisation de la carte graphique de grand Tunis 54

Liste des �gures

2.1 Représentation graphique du problème TSP . . . . . . . . . . . . . . . 16

2.2 Représentation graphique du problème VRP . . . . . . . . . . . . . . . 18

3.1 Diagramme des cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Diagramme de classes pour le PVC . . . . . . . . . . . . . . . . . . . . 30

3.3 Diagramme de classes pour le PTV . . . . . . . . . . . . . . . . . . . . 31

3.4 Diagramme de classes pour le PTV à capacités . . . . . . . . . . . . . . 32

3.5 Diagramme de classes pour le PTV à fenêtres de temps . . . . . . . . . 33

3.6 Diagramme de classes général . . . . . . . . . . . . . . . . . . . . . . . 34

3.7 DS pour la visualisation d'une solution au problème . . . . . . . . . . . 35

3.8 DS pour l'ajout d'un problème . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 Architecture de framework DotNet . . . . . . . . . . . . . . . . . . . . 40

4.2 Séparation code / design . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 page d'acceuil du problème de transport . . . . . . . . . . . . . . . . . 45

4.4 Interface de la page principale . . . . . . . . . . . . . . . . . . . . . . . 46

4.5 Interface d'a�chage d'une solution . . . . . . . . . . . . . . . . . . . . 46

4.6 Interface de con�rmation de suppression . . . . . . . . . . . . . . . . . 47

4.7 Interface de choix d'un problème . . . . . . . . . . . . . . . . . . . . . 47

LISTE DES FIGURES x

4.8 Interface de saisie des données . . . . . . . . . . . . . . . . . . . . . . . 48

4.9 Interface de saisie du nom du problème . . . . . . . . . . . . . . . . . . 48

4.10 Interface de con�rmation de l'enregistrement . . . . . . . . . . . . . . . 49

A.1 Relation entre altitudes,niveaux et images . . . . . . . . . . . . . . . . 54

A.2 La zone a�chée de l'image . . . . . . . . . . . . . . . . . . . . . . . . . 55

A.3 Directions de déplacement . . . . . . . . . . . . . . . . . . . . . . . . . 55

Liste des tableaux

1.1 Tableau des caractéristiques des problèmes issus des tournées de véhicules. 6

1.2 Comparaison entre la recherche Taboue et l'algorithme génétique appli-qués sur des problèmes de TSP. . . . . . . . . . . . . . . . . . . . . . . 12

Introduction générale

Avec la mondialisation , les délocalisations des centres de productionet l'expansion des marchés, le transport revêt une importance ca-pitale en assurant les liaisons entre ces derniers. Le domaine de

transport soulève un grand nombre de problèmes, très souvent di�ciles à résoudre demanière optimale.Ces problèmes concernent généralement le service d'un ensemble de lieux appelés clients(pouvant être considérés ponctuels comme un site bien précis, ou longiligne comme unerue) à un coût minimum.L'intérêt pour ce genre d'activité est grandissant dans la vie actuelle, puisqu'elle peuts'appliquer à de nombreux domaines, de plus, la mondialisation implique des coûtslogistiques de plus en plus importants pour les entreprises.Ainsi un élément fondamental de tout système logistique, est la gestion et la plani�ca-tion des réseaux de distribution des �ottes de véhicules.L'utilisation des modèles mathématiques d'optimisation des tournées de véhicules, aété l'un des plus beaux succès de la Recherche Opérationnelle au cours de la dernièredécennie. Les recherches récentes incluent des e�orts signi�catifs en formulation duproblème et en construction, analyse et implantation d'algorithmes.L'intérêt du recours à des méthodes pour l'optimisation des activités de transport, de-vient évident dès que l'on se rend compte de l'importance des coûts de distribution.C'est pour cela que des e�orts sont nécessaires a�n de développer des systèmes de trans-

INTRODUCTION GÉNÉRALE 2

port �exibles et e�caces répondant aux préoccupations actuelles relatives à l'économieet à notre qualité de vie.

CHAPITRE1 Etat d'art

Introduction

Le problème de transport est un problème vague qui contient plusieurs variantescommençant par le problème de voyageur de commerce jusqu'à atteindre le problèmede tournées des véhicules et ses di�érentes variantes.La recherche de méthodes e�caces de résolution de ces problèmes a été à l'origined'importants développements en programmation mathématiques et en optimisationcombinatoire. Et comme les algorithmes exacts ne sont applicables qu'à des problèmesde taille souvent trop petite, nous nous concentrons plutôt sur les algorithmes heuris-tiques.Quels sont les di�érents types de problèmes de transport ?Quels sont les algorithmes utilisés pour résoudre ces di�érents problèmes ?Quel est l'algorithme le plus approprié aux problèmes choisis ?

1.1 Le Problème du voyageur de commerce(PVC)

Le problème du voyageur de commerce(PVC) appelé en anglais " Traveling Sales-man Problem "(TSP) est l'un des plus connu des problèmes d'optimisation combina-toire.Son énoncé est le suivant : étant donné n points (des " villes ") et les distances sé-parant chaque point, on va trouver un chemin de longueur totale minimale qui passe

CHAPITRE 1. ETAT D'ART 4

exactement une fois par chaque point et revienne au point de départ.Ce problème est plus compliqué qu'il n'y paraît ; on ne connaît pas de méthode derésolution permettant d'obtenir des solutions exactes en un temps raisonnable pour degrandes instances (grand nombre de villes) du problème. Pour ces grandes instances,on devra donc souvent se contenter de solutions approchées, car on se retrouve face àune explosion combinatoire : le nombre de chemins possibles passant par 69 villes estdéjà un nombre d'une longueur de 100 chi�res. Pour comparaison, un nombre d'unelongueur de 80 chi�res permettrait déjà de représenter le nombre d'atomes dans toutl'univers connu.Rigoureusement, résoudre le problème du voyageur de commerce est une tâche di�cile :on doit trouver le plus petit cycle hamiltonien (au sens qu'on doit prouver qu'il n'enexiste pas de longueur inférieure) dans le graphe d'entrée. Toutefois il arrive qu'on sesatisfasse d'une "bonne solution", c'est-à-dire d'un cycle hamiltonien qui ne soit pastrop loin de la meilleure solution possible.[2]

1.2 Le problème de tournées de véhicules(PTV)

1.2.1 Dé�nition

Le problème de tournées de véhicules(PTV, connu par VRP) est une classe deproblèmes de recherche opérationnelle et d'optimisation combinatoire. Il s'agit de dé-terminer les tournées d'une �otte de véhicules a�n de livrer une liste de clients. Le butest de minimiser le coût de livraison des biens. Ce problème est une extension clas-sique du problème du voyageur de commerce, et fait partie de la classe des problèmesNP-complet(Problème dont on ne peut pas trouver un algorithme polynomial pour lerésoudre).[3]Dans ce qui suit nous nous intéressons uniquement des variantes statiques du PTV.

CHAPITRE 1. ETAT D'ART 5

1.2.2 Les variantes du problème

Quelques variantes classiques du problème de tournées de véhicules :• Problème de tournées de véhicules avec contraintes de capacité : Les véhicules

ont une capacité d'emport limitée (quantité, taille, poids, etc.).• Problème de tournées de véhicules avec fenêtre de temps : Pour chaque client on

impose une fenêtre de temps dans laquelle la livraison doit être e�ectuée.• Problème de tournées de véhicules avec collecte et livraison : Un certain nombre de

marchandises doivent être déplacées de sites de collecte vers des sites de livraisons.

1.2.3 Les caractéristiques et les di�érents types du PTV

Les caractéristiques sont représentées comme suit :a) Une tournée contient des collectes et des livraisons, toutes les livraisons doiventêtre e�ectuées avant les collectesb) Une tournée ne peut contenir uniquement des collectes ou uniquement deslivraisons.c) A tout moment, la capacité du véhicule doit être respectéed) On doit utiliser tous les véhicules disponiblese) Toutes les tournées commencent et se terminent dans le même dépôt (1 dépôt)f) Les véhicules sont homogènes : ont la même capacitég) Pour chaque collecte (client source), une livraison (client destination) lui estassociée, c'est-à-dire qu'il y a des livraisons que l'on ne peut pas faire sans avoir faiten amont des collectes (Contrainte de précédence )h) Si un véhicule arrive sur un client avant la fenêtre le temps de ce dernier alors ildoit attendre le début de la fenêtre de temps pour commencer son service (contraintede fenêtre de temps)i) Un véhicule ne peut e�ectuer son service s'il arrive après la fenêtre de temps(contrainte rigide de fenêtre de temps)j) Pour chaque client, on e�ectue deux services, une livraison puis une collecte

CHAPITRE 1. ETAT D'ART 6

k) Chaque client est lié à un dépôt, il ne peut être servi que par ce dernierl) Tous les véhicules doivent revenir au dépôt à la �n de la tournée.

Dans le tableau de la �gure 1.1, nous récapitulons les di�érents problèmes detournées de véhicules en déterminant les caractéristiques présentées ci-dessus :

a) b) c) d) e) f) g) h) i) j) k) l)VRP X X X

MDVRP X XSDVRP X X XHVRP X XOVRP X X X XVRPB X X X X X X

VRPTW X X X X XMVRPB X X X XVRPPD X X X XVRPSPD X X X XVRPBTW X X X X X XMVRPBTW X X X X XVRPPDTW X X X X X XVRPSPDTW X X X X X X

Tableau 1.1 � Tableau des caractéristiques des problèmes issus des tournées devéhicules.

CHAPITRE 1. ETAT D'ART 7

VRP : Vehicle Routing Problem, problème de tournées de véhicules.MDVRPB : Multi Depot Vehicle Routing Problem, problème de tournées de véhicules,multi-dépôtsSDVRP : Site-Depenent Vehicle Routing Problem, problème de tournées de véhiculesavec a�ectation des dépôtsHVRP : Heterogeneous Vehicle Routing Problem, problème de tournées avec des véhi-cules à capacité variableOVRP : Open Vehicle Routing Problème, problème de tournées de véhicules ouvertVRPB : Vehicle Routing Problem with Backhaul, problème de tournées de véhiculesavec livraison et collecteVRPTW : Vehicle Routing Problem with Time Window, problème de tournées de vé-hicules avec fenêtre de tempsMVRPB : Mix Vehicle Routing Problem with Backhaul, problème de tournées de véhi-cules avec livraison et collecte, mixteVRPPD : Vehicle Routing Problem with PickUp and Delivery, problème de tournéesde véhicules avec livraison et collecteVRPSPD : Vehicle Routing Problem with Simultaneous PickUp and Delivery, problèmede tournées de véhicules avec livraison et collecte simultanéeVRPBTW : Vehicle Routing Problem with Backhaul and Time Window, problème detournées de véhicules avec livraison et collecte et fenêtre de tempsMVRPBTW : Mix Vehicle Routing Problem with Backhaul and Time Window, pro-blème de tournées de véhicules avec livraison et collecte et fenêtre de temps, mixteVRPPDTW : Vehicle Routing Problem with PickUp and Delivery and Time Window,problème de tournées de véhicules avec livraison et collecte et fenêtre de tempsVRPSPDTW : Vehicle Routing Problem with Simultaneous PickUp and Delivery andTime Window.

CHAPITRE 1. ETAT D'ART 8

1.2.4 Les méthodes de résolution

1.2.4.1 Méthodes de résolution exactes

Les méthodes exactes reposent sur l'utilisation d'algorithmes qui mènent de façonsûre vers la solution optimale. Le principe essentiel de ces méthodes est d'énumérer demanière implicite l'ensemble des solutions de l'espace de recherche.Malgré l'important temps de calcul que nécessitent, généralement, ces approches, plu-sieurs méthodes ont été développées. Elles permettent de résoudre e�cacement desproblèmes allant jusqu'à 50 clients.Mais vu que les méthodes exactes restreignent le nombre des clients envisageables dansles problèmes et impliquent, dans la plupart des cas, un temps de calcul important,l'élaboration et l'utilisation des heuristiques se sont avérées d'une grande utilité. Cesméthodes permettent de gérer des problèmes de grandes tailles avec des temps derésolution et des résultats acceptables et admissibles.

1.2.4.2 L'utilité des heuristiques

Comme pour la plupart des problèmes NP-complet il est di�cile de résoudre desinstances de grande taille de façon optimale. On se contente alors de trouver des so-lutions de " bonne qualité ". A�n d'obtenir des solutions dans des temps de calculsraisonnables, on se tourne généralement vers des méthodes approchées à base d'heu-ristique pour construire une première solution que l'on améliore ensuite avec d'autresheuristiques ou des méthodes de recherche locale.L'utilisation des heuristiques est nécessaire pour résoudre des problèmes appelés NP-Complet soit non-déterministe polynomial. Cette appellation vient du fait que plus onaugmente le nombre de clients à visiter lors d'une tournée plus on a de la di�culté àdonner une bonne réponse dans un temps respectable. De plus, on ne peut déterminerune réponse exacte pour ces problèmes puisque cela prendrait beaucoup trop de tempset cause un nombre e�arant de possibilités.Voici la formule pour calculer le nombre de possibilités : 1/2(n-1) !

CHAPITRE 1. ETAT D'ART 9

1.2.4.3 Métaheuristiques utiles pour la résolution du PTV

Les métaheuristiques étant très généralistes, elles peuvent être adaptées à tout typede problème d'optimisation pouvant se réduire à une " boîte noire ". Elles sont souventmoins puissantes que des méthodes exactes sur certains types de problèmes. Elles negarantissent pas non plus la découverte de l'optimum global en un temps �ni. Cepen-dant, un grand nombre de problèmes réels n'est pas optimisable e�cacement par desapproches purement mathématiques, les métaheuristiques peuvent alors être utiliséesavec pro�t.

• Algorithme de colonies de fourmis :Un algorithme de colonies de fourmis est un algorithme itératif à population oùtous les individus partagent un savoir commun qui leur permet de guider leursfuturs choix et d'indiquer aux autres individus des directions à suivre ou aucontraire à éviter.Fortement inspiré du déplacement des groupes de fourmis, cette méthode a pourbut de construire les meilleures solutions à partir des éléments qui ont été explo-rés par d'autres individus. Chaque fois qu'un individu découvre une solution auproblème, bonne ou mauvaise, il enrichit la connaissance collective de la colonie.Ainsi, chaque fois qu'un nouvel individu aura à faire des choix, il pourra s'appuyersur la connaissance collective pour pondérer ses choix.[4]

• L'algorithme génétique :Il s'agit plus précisément d'une classe des algorithmes évolutionnistes. Les al-gorithmes génétiques sont des algorithmes d'optimisation s'appuyant sur destechniques dérivées de la génétique et des théories de Darwin sur l'évolution :croisements, mutations, sélection...Les algorithmes génétiques travaillent sur unepopulation et peuvent être décomposés en trois phases : une phase d'évaluation,une phase de sélection et une phase de recombinaison.[5]

• Recuit simulé :Le recuit simulé s'appuie sur l'algorithme de Metropolis-Hastings, qui permet dedécrire l'évolution d'un système thermodynamique. Par analogie avec le processus

CHAPITRE 1. ETAT D'ART 10

physique, la fonction à minimiser deviendra l'énergie E du système. On introduitégalement un paramètre �ctif, la température T du système.Partant d'une solution donnée, en la modi�ant, on en obtient une seconde. Soitcelle-ci améliore le critère que l'on cherche à optimiser, on dit alors qu'on a faitbaisser l'énergie du système, soit celle-ci le dégrade. Si on accepte une solutionaméliorant le critère, on tend ainsi à chercher l'optimum dans le voisinage de lasolution de départ.L'acceptation d'une " mauvaise " solution permet alors d'explorer une plus grandepartie de l'espace de solution et tend à éviter de s'enfermer trop vite dans larecherche d'un optimum local.[6]

• Algorithme d'optimisation par essaims particulaires :Cette méthode d'optimisation se base sur la collaboration des individus entreeux. Elle a d'ailleurs des similarités avec les algorithmes de colonies de fourmis,qui s'appuient eux aussi sur le concept d'auto-organisation. Cette idée veut qu'ungroupe d'individus peu intelligents puisse posséder une organisation globale com-plexe.Ainsi, grâce à des règles de déplacement très simples (dans l'espace des solu-tions), les particules peuvent converger progressivement vers un minimum local.Cette métaheuristique semble cependant mieux fonctionner pour des espaces envariables continues.[7]

• Recherche taboue :La méthode taboue est une méthode de recherche locale. Son principe reposesur une méthode de déplacement sur l'espace des solutions, tout en cherchantconstamment à améliorer la meilleure solution courante et en conservant en mé-moire la liste des précédents déplacements et ainsi guider la recherche en dehorsde zones précédemment parcourues. En général, on ne va pas garder tous les dé-placements (trop couteux en mémoire), mais on va seulement empêcher l'accès àcertaines solutions pendant un certain nombre d'itérations.La méthode consiste à se déplacer d'une solution vers une autre par observation

CHAPITRE 1. ETAT D'ART 11

du voisinage de la solution de départ et à dé�nir des transformations taboues quel'on garde en mémoire.[8]

1.2.4.4 Comparaison de quelques algorithmes heuristiques

Dans notre projet on a choisi de travailler avec la méthode de recherche tabouepuisque :

• Les algorithmes génétiques sont coûteux en temps de calcul, à cause qu'ilsmanipulent plusieurs solutions simultanément. C'est le calcul de la fonction deperformance qui est le plus pénalisant, et on optimise généralement l'algorithmede façon à éviter d'évaluer trop souvent cette fonction.Ensuite, l'ajustement d'un algorithme génétique est délicat. L'un des problèmesles plus caractéristiques est celui de la dérive génétique, qui fait qu'un bonindividu se met, en l'espace de quelques générations, à envahir toute la popu-lation. On parle dans ce cas de convergence prématurée, qui revient à lancer àune recherche locale autour d'un minimum... qui n'est pas forcément l'optimumattendu. Les méthodes de sélection proportionnelle peuvent en particulierfavoriser ce genre de dérive.Un autre problème surgit lorsque les di�érents individus se mettent à avoir desperformances similaires : les bons éléments ne sont alors plus sélectionnés, etl'algorithme ne progresse plus.

• Pour le recuit simulé, une fois l'algorithme piégé à basse température dans unminimum local, il lui est impossible de s'en sortir tout seul.Plusieurs solutions ont été proposées pour tenter de résoudre ce problème, parexemple en acceptant une brusque remontée de la température, de temps entemps, pour relancer la recherche sur d'autres régions plus éloignées. Il estégalement possible d'empêcher la température de descendre trop bas : on luidonne une valeur minimale au delà de laquelle on ne change plus de palier detempérature. Mais si cette valeur est trop grande, l'algorithme passera son temps

CHAPITRE 1. ETAT D'ART 12

à augmenter et diminuer son énergie car il acceptera trop de perturbationsdégradantes et il n'arrivera pas à explorer à fond une vallée.Ainsi, il est fort possible que l'algorithme arrive à "trouver" la vallée danslaquelle se cache un minimum global, mais il aura beaucoup de mal à l'ex-plorer et donc risque de s'en éloigner sans avoir décelé la solution au problème...[9]

Meme si on a essayé de tester le problème de voyageur de commerce (TSP) par appli-cation de recherche taboue et de l'algorithme génétique pour la comparaison entre eux,on a obtenu la variation du cout en fonction de la solution optimale présenté dans letableau 2.

Problème Taille Solution optimaleRT AG

cout pourcentage cout pourcentageEil76 76 545 545 100 572 95Eil101 101 642 657 97 711 90Gr96 96 512 527 97 558 91

KroA100 100 21285 21521 98 22638 94KroC100 100 20750 20940 99 22626 91KroD100 100 21249 21835 97 24134 88Lin105 105 14382 14878 96 15490 92Pr76 76 108159 109044 99 115553 93

Tableau 1.2 � Comparaison entre la recherche Taboue et l'algorithme génétiqueappliqués sur des problèmes de TSP.

CHAPITRE 1. ETAT D'ART 13

Conclusion

Pour récapituler, on peut dire que le problème de voyageur de commerce (TSP)et les instances de grande taille du problème de tournées de véhicules (VRP, CVRP,VRPTW,...) sont NP-complet ; pour les résoudre il faut utiliser des méthodes heuris-tiques.Dans le cadre de notre projet de �n d'études nous nous focalisons sur " la recherchetaboue " que nous avons choisie pour les performances qu'elle présente comparées auxautres heuristiques.

CHAPITRE2 Etude théorique

Introduction

Dans ce chapitre, nous nous focalisons sur l'étude théorique de quelques problèmesprésentés dans le premier chapitre. Nous déterminons en premier lieu les formulationsmathématiques qui les concernent et nous nous intéressons aussi à l'étude de l'algo-rithme de recherche taboue.

2.1 Formulation mathématique

Les problèmes de tournées de véhicules �gurent parmi les problèmes d'optimisationcombinatoire où l'ensemble de paramètres soumis à des contraintes.Le but de résolution de ces problèmes est l'amélioration d'un certain critère ou unensemble de critères.

2.1.1 Formulation mathématique du problème du voyageur decommerce(PVC)

Plusieurs modèles de tournées de véhicules sont des variantes et extensions du fa-meux problème du voyageur de commerce (PVC, connue par :TSP). Le TSP consisteen la détermination du parcours de coût minimal (distance, temps, etc.), d'un seulvéhicule partant d'une localité, visitant " n " autres localités, et revenant à son départ.

CHAPITRE 2. ETUDE THÉORIQUE 15

En théorie de graphe, le problème consiste à chercher le circuit hamitonien de coûtminimal dans un graphe complet G= (V, A) valorisé (cout cij associé a chaque arc (i,j)de A).voici la signi�cation des notations qu'on va utilisé dans la formulation du problème :n=|V|, nombre de sommets du réseaucij=cout de l'arcs (i,j)bj= nombre de s arcs incidents au sommet jai =nombre des arcs partant de sommetxij = 1 si l'arc (i,j) appartient à la tournéexij = 0 sinonDonc la fonction objective a pour formulation :

minimiser

n∑i=1

n∑j=1

cijxij

Mais cette formulation nécessite des contraintes à respecter qui sont :• Tout les villes doit être visitée et quittée une et une seul fois, soit mathématique-

ment :n∑

i=1

xij = bj = 1

n∑j=1

xij = ai = 1

• Il faut assurée la continuité d'un tournée : une véhicule entre un sommet, il faudraqu'il sort.Soit mathématiquement :

n∑i=1

xip

n∑j=1

xpj = 0 p = 1, 2, 3, ...n

CHAPITRE 2. ETUDE THÉORIQUE 16

La �gure 2.1 consiste en une représentation graphique du TSP :

Figure 2.1 � Représentation graphique du problème TSP

2.1.2 Formulation mathématique du problème de tournées desvéhicules(PTV)

Le problème de tournées des véhicules (PTV, connu par VRP) est une généralisationdu TSP au cas où on désire construire " m " circuit hamiltoniens de coût total minimal,ayant un sommet (le dépôt). Ce problème peut être considéré comme une versionsimpli�ée de CVRP où la capacité de chaque véhicule est supérieure à la totalité de lademande (ou considérée in�ni) et où les " m " véhicules sont utilisés.On va travailler avec les mêmes variables utilisés dans le TSP mais en posant :

a1 = b1 <= m

ai = bi = 1

CHAPITRE 2. ETUDE THÉORIQUE 17

Donc la fonction objective à pour formulation :

minimiser

n∑i=1

n∑j=1

cij

m∑

k=1

xijk

Cette formulation nécessite des contraintes à respecter qui sont :• Tout les villes doit être visitées et quittées une et une seule fois et par une seule

véhicule, soit mathématiquement :n∑

i=1

m∑

k=1

xkij = 1 j = 1, 2, 3, ...n

n∑j=1

m∑

k=1

xkij = 1 i = 1, 2, 3, ...n

• Il faut assurée la continuité d'un tournée : une véhicule entre un sommet, il faudraqu'il sort.Soit mathématiquement :

n∑i=1

xkip −

n∑j=1

xkip = 0 p = 1, 2, 3, ...n k = 1, 2, 3, ...m

• Respect du nombre de véhicules : la disponibilité des véhicules n'est pas dépassée :n∑

i=1

xki1 ≤ 1 j = 1, 2, 3, ...n

n∑j=1

xk1j ≤ 1 i = 1, 2, 3, ...n

CHAPITRE 2. ETUDE THÉORIQUE 18

La �gure 2.2 consiste en une représentation graphique du VRP :

Figure 2.2 � Représentation graphique du problème VRP

2.1.3 Formulation mathématique du problème de tournées desvéhicules à capacités limitées(PTV à capacités)

Le problème de tournées de véhicules à capacités (connu par CVRP) est une géné-ralisation du VRP au cas où chaque sommet est a�ecté d'un poids (demande) connu.On va utiliser les mêmes variables que VRP en ajoutant quelques uns.Soient :m= nombre de véhicule k.Dk = capacité du véhicule k.di= demande du sommet i (d1=0)Pour le Variable de décision :xk

ij = 1 si l'arc (i,j) est parcouru par la véhicule kxk

ij = 0 sinon

CHAPITRE 2. ETUDE THÉORIQUE 19

Donc la fonction objective a pour formulation :

minimiser

n∑i=1

n∑j=1

cij

m∑

k=1

xijk

Tout les contraintes de m-TSP doit être véri�er. En plus la capacité des véhicules doitêtre respectée :

n∑i=1

di(n∑

j=1

xijk) ≤ Dk

2.1.4 Formulation mathématique du problème de tournées desvéhicules avec fenêtre de temps(PTV à fenêtre de temps)

Ce problème est connu par VRPTW et c'est une généralisation du CVRP qui mo-délise les contextes de transport du monde réel en prenant compte à l'aspect temporeldes opérations de transport. Chaque client possède un intervalle de temps, c'est-à-dire,il exige un intervalle de temps dans lequel il soit servi.Toutes les contraintes de CVRP doit être véri�eés.Soient :tki =temps nécessaire au véhicule k pour décharger ou charger dans le sommet i (tk1 = 0)tkij = temps nécessaire au véhicule k pour traverser l'arc (i,j) (tkij =in�ni).En assurant la non-violation des contraintes temporelles [10] :

xkij(Dateservicei + tkij + tki Dateservicej) ≤ 0

oi ≤ Dateservicei ≤ ci

2.2 Résolution des variantes PTV basée sur la re-cherche taboue(RT)

En optimisation combinatoire, de nombreux problèmes s'avèrent souvent di�ciles àrésoudre de manière exacte. Ceci n'est pas dû à un manque de connaissances mathéma-tiques, mais plutôt à des problèmes techniques. En e�et, la résolution d'un problème

CHAPITRE 2. ETUDE THÉORIQUE 20

dans lequel on considère des instances de taille comparable à celle rencontrées dans lapratique conduit souvent à se heurter à des problèmes de taille mémoire et de tempsde calcul trop importants.La méthode taboue ou aussi la recherche taboue a été développée respectivement par" Glover " et " Hansen ".Cette méthode fait appel à un ensemble de règles et de mécanismes généraux pourguider la recherche de manière intelligente à travers l'espace des solutions. Elle s'est ré-vélée particulièrement e�cace et a été appliquée avec succès à de nombreux problèmesNP-complets.

2.2.1 Principe de la RT

La méthode taboue est perçue comme une généralisation des méthodes d'améliora-tion locales traditionnelles. En e�et, tout comme celles-ci explore itérativement l'espaceS des solutions du problème à optimiser jusqu'à atteindre un optimum local. Toutefois,contrairement aux méthodes itératives classiques qui s'arrêtent dès qu'il n'y a plus desolutions permettant d'améliorer la fonction objective, ici, la solution suivante retenueest dé�nie comme étant la moins mauvaise solution parmi les éléments du voisinage.Ceci permet à la méthode taboue de poursuivre la recherche de solutions meilleuresmême si cela entraine une dégradation de la fonction objective. Autrement dit, on choi-sit parmi les solutions voisines de la solution courante, celle dont la valeur de la foctionobjective est inférieure ou légèrement supérieure.Cette modi�cation du processus d'exploration rend donc la méthode taboue insensibleaux optima locaux, mais elle introduit le risque de cycler dès que l'on sort de l'unde ces optima, en y retournant aussitôt. C'est là que la notion de mémoire trouve sajusti�cation.Pour régler ce problème, la méthode taboue conserve des informations sur le chemi-nement récent e�ectué à travers l'ensemble des solutions a�n de s'introduire certainestransformations de la solution courante qui pourrait ramener la procédure vers dessolutions déjà rencontrées. Ces transformations sont alors déclarées taboue, d'où le

CHAPITRE 2. ETUDE THÉORIQUE 21

nom de la méthode. Ceci a pour e�et de restreindre l'accès à certaines solutions et parsuite d'orienter en quelques sorte la recherche. Néanmoins, pour conserver l'approchesu�samment de �exibilité, le caractère tabou de ces transformations ne doit pas êtremaintenu en permanence.En limitant la durée de vie des tabous, on permet à la méthode de remettre en questionses choix passés (une fois le risque de cycler disparus) et ainsi de mener une explorationbeaucoup plus large du domaine des solutions.Dans la description que nous venons de faire, il est clair que le type de voisinage ainsique les paramètres de la méthode taboue sont déterminants pour avoir une bonnesolution.

2.2.2 Algorithme de la méthode de recherche taboue

1. Choisir une solution initiale X0 et l'insérer dans la mémoire adaptative et dans laliste taboue.

2. Poser f ∗=f(X0) et k=0 (k étant le nombre d'itérations e�ectuées).

3. Tant que critère d'arrêt non satisfait (k ≤ nombre d'itérations maximal) faire :

(a) k=k+1.

(b) Choisir une solution aléatoire L de la mémoire adaptative.

(c) Faire des permutations à l'intérieur de la liste L.

(d) Véri�er que la liste L satisfait les conditions après les permutations.

(e) Ajouter L à la liste Taboue si elle n'existe pas auparavant.

(f) Si L est une bonne solution, l'ajouter ou la remplacer par la mauvaise solutionde la mémoire adaptative.

(g) Si f(L) < f ∗ alors f ∗ = f(L).

4. Fin tant que.

Nous allons donc, dans ce qui suit, décrire chacun des paramètres nécessaires à laméthode taboue et de dégager son importance vis-à-vis du processus de la recherche.

CHAPITRE 2. ETUDE THÉORIQUE 22

2.2.3 Choix de la solution initiale

Etant donné que la recherche avec tabous n'est en fait qu'un algorithme de des-cente un peu plus élaboré, il soit évident que le choix de la solution de départ in�ueconsidérablement sur la qualité de la solution ainsi que sur le temps d'exécution. Ene�et, partir d'une solution médiocre nous demanderait plus de temps pour atteindrela meilleure solution, mais débuter avec une bonne solution impliquerait l'utilisationd'une autre heuristique (classique) pour sa construction. En outre, commencer par unebonne solution ne voudrait en aucun cas dire qu'elle soit assez proche de la meilleuresolution.

2.2.4 La liste taboue

La dé�nition et la gestion de la liste taboue jouent un rôle primordial dans laméthode taboue. Celle-ci correspond à une sorte de mémoire à court terme qui indiqueà la procédure où elle est déjà été, lui permettant donc de diriger son exploration versdes régions du domaine des solutions non encore visitées.La façon le plus simple de mettre en oeuvre cet élément de la méthode consiste à garderune liste des derniers k solutions visitées et d'interdire à la procédure d'y retourner.Malheureusement, si cette méthode empêche de retourner immédiatement à la solutionprécédente, elle ne permet pas d'éliminer complètement le risque de cyclage. De plus,elle empêche la procédure de visiter certaine partie de l'espace qui aurait pu nousdonner de bons résultats.Tout ceci fait en sorte que la taille de cette liste taboue doit convenablement êtrechoisie de façon à avoir un compromis entre la �exibilité (petite taille de la liste) etl'élimination du risque de cyclage (grande taille de la liste). Cette taille est d'autantplus di�cile à déterminer qu'elle peut dépendre de la taille et de la nature du problème.

CHAPITRE 2. ETUDE THÉORIQUE 23

2.2.5 La Mémoire Adaptative

C'est une mémoire centrale chargée de stocker les composantes des meilleures solu-tions rencontrées. Ces composantes sont combinées a�n de créer de nouvelles solutions.Au début de la recherche, la mémoire centrale contient des composantes provenant desolutions très diverses et le processus de combinaison aura donc tendance à créer unediversité de nouvelles solutions.Plus la recherche avance et plus la mémoire centrale aura tendance à ne mémoriser queles composantes d'un sous-ensemble très restreint de solutions. La recherche devientdonc petit à petit un processus d'intensi�cation.

2.2.6 Le critère d'aspiration

Les tabous sont un mécanisme dont le but principal est d'empêcher le cyclage de laméthode, mais ceux-ci peuvent s'avérer parfois trop forts et restreindre ainsi inutilementl'exploration du domaine des solutions. En particulier, lorsque les tabous sont dé�nis enfonction des transformations, ils n'interdisent pas seulement de retourner à la solutionprécédente, mais à tout un sous ensemble de solutions dont certaines peuvent ne pasavoir été encore visitées.Il faut donc qu'il y ait un mécanisme inverse à celui des tabous qui permettre derévoquer le statut taboue d'une transformation si son application à la solution courantepermet d'atteindre une solution jugée intéressante, sans pour autant introduire unrisque de cyclage dans le processus.C'est le concept de critère d'aspiration (ou fonction d'aspiration) qui remplit ce rôle.Il est à noter toutefois, que le critère d'aspiration perd toute son utilité si l'on stockela solution entière dans la liste taboue. En e�et, dans ce cas, toute annulation d'uncritère tabou amène à un cyclage.De nombreux critères d'aspiration ont été proposés dont certains sont très sophistiqués.Le critère le plus simple à mettre en oeuvre consiste à révoquer le statut tabou associé àune transformation si cela permet d'obtenir une solution plus béné�que que la meilleure

CHAPITRE 2. ETUDE THÉORIQUE 24

solution rencontrée jusqu'à présent. C'est évidement un critère très sévère qui ne devraitpas être souvent véri�é. Il n'ajoute donc pas beaucoup de �exibilité à la méthode, maisil lui évite de commettre des oublis �agrants lorsque ce genre de situation se présente.

2.2.7 Le critère d'intensi�cation

L'idée à la base de l'intensi�cation consiste à retourner périodiquement visiter deszones de l'espace de recherche qui semblent particulièrement prometteuses.De nombreuses techniques ont été proposées :

• Repartir de bonnes solutions déjà rencontrées .• Reconstruire une solution de départ qui tente de combiner des attributs qui ont

été présents souvent dans les con�gurations visitées .• Geler certains attributs qui ont été souvent présents dans les con�gurations visi-

tées ou dans les con�gurations d'élite relevées.

2.2.8 Les critères d'arrêt

Le critère ou la condition d'arrêt est très importante dans n'importe quel algorithmeet en particulier pour les algorithmes d'optimisation combinatoire dont le temps d'exé-cution est un facteur primordial. Dans le cas de la recherche avec tabous, on peut citerdeux critères d'arrêts essentiels.Le premier consisterait à �xer un nombre maximal d'itérations (solutions visitées) à nepas dépasser et ce en fonction de la taille du problème. Ce critère n'est toutefois pastrès signi�catif.Le deuxième serait de s'arrêter si après un nombre d'itérations donné, aucune amélio-ration de la meilleure solution n'a eu lieu.

CHAPITRE 2. ETUDE THÉORIQUE 25

Conclusion

Dans ce chapitre on a parlé dans une première partie de formules mathématiquesspéci�ées au problème de voyageur de commerce et aux problèmes des tournées desvéhicules, ces formules nous ont aidé à mieux comprendre les di�érentes contraintes etde traités ces problèmes. En deuxième partie, on a détaillé l'algorithme de recherchetabou en spéci�ant son principe de base, son comportement, et ses critères d'amélio-ration tel que l'aspiration, l'intensi�cation et ses critères d'arrêt, ainsi que les listesutilisées tel que la liste taboue et la mémoire adaptative.

CHAPITRE3 Etude conceptuelle

Introduction

Ce chapitre est consacré à la conception de la structure et du fonctionnement denotre système. Nous dé�nissons, tout d'abord, les besoins de l'application en termesd'exigences fonctionnelles et non fonctionnelles, puis nous décrivons une vue appro-fondie qui explique les diagrammes des classes en abordant la partie de conceptiondétaillée. En�n nous développons quelques scénarios en se basant sur les diagrammesde séquences qui représentent une vue dynamique de notre application.

3.1 Spéci�cation des besoins

Dans cette partie nous étudions les besoins fonctionnels et non fonctionnels de notresystème.

3.1.1 Besoins fonctionnels

Les besoins fonctionnels constituent une sorte de promesse ou de contrat au com-portement d'application générée.Donc dans cette partie nous représentons une description du diagramme des cas d'uti-lisation.

CHAPITRE 3. ETUDE CONCEPTUELLE 27

3.1.1.1 Diagramme des cas d'utilisation

Ce diagramme permet de formaliser les besoins. C'est le diagramme principal dumodèle UML, celui où s'assure la relation entre l'utilisateur et les objets que le systèmemet en oeuvre.Dans notre projet nous avons localisé un principal acteur qui est : l'utilisateur.Un utilisateur peut gérer un problème, c.à.d. qu'il peut l'ajouter ou le supprimer.Il peut aussi résoudre un problème en choisissant son type et l'instance qu'il va larésoudre.Une autre fonctionnalité consiste dans la visualisation de la solution résolue.Il peut aussi gérer une instance du problème soit par l'ajout, soit par la suppression,soit par la modi�cation.

Figure 3.1 � Diagramme des cas d'utilisation

CHAPITRE 3. ETUDE CONCEPTUELLE 28

3.1.2 Besoins non fonctionnels

Les besoins non fonctionnels peuvent être considérés comme des besoins fonctionnelsspéciaux. Parfois, ils ne sont pas rattachés à un cas d'utilisation particulier, mais ilscaractérisent tout le système (l'architecture, la sécurité, le temps de réponse, etc.). Lesystème doit garantir les besoins opérationnels suivants :

• Le temps de réponse de l'application doit être rapide.• Les interfaces doivent être conviviales et claires.• Le système doit être souple pour une extension future (ajouter des nouvelles

fonctionnalités).• L'application doit préserver une bonne qualité en termes de gestion d'erreur.

3.2 Conception

3.2.1 Structure statique du système

Elle est représentée sous forme d'un diagramme de classe car c'est le plus utiliséet le plus indispensable. Il représente l'architecture conceptuelle du système : il décritles classes que le système utilise, ainsi que leurs liens. Ces derniers représentent unemboîtage conceptuel (héritage) ou une relation organique (agrégation).

3.2.1.1 Description des classes

Dans notre projet, on a détecté 9 classes dont quatre représentent les problèmestraités dans notre projet. Ces classes sont :

• Classe Dépôt : qui est caractérisé par un numéro et des coordonnées XD et YD.• Classe Client : qui est caractérisé par un numéro et des coordonnées x et y.• Classe ClientQuantite : qui hérite de "Client ", mais elle est caractérisée de plus

par une quantité.• Classe ClientTw : qui hérite de " ClientQuantite ", mais elle est caractérisée de

CHAPITRE 3. ETUDE CONCEPTUELLE 29

plus par une fenêtre de temps.• Classe PVC : c'est une classe qui représente le problème de voyageur de commerce.• Classe PTV : c'est une classe qui représente le problème de tournées des véhicules,

elle hérite de PVC et elle est liée à un nombre �ni des véhicules qui ont unecapacité in�nie.

• Classe PTVC : c'est une classe qui représente le problème de tournées des véhi-cules à capacités, elle hérite de PTV et elle est liée à un nombre �ni des véhicules,mais qu'ils ont une capacité �nie.

• Classe PTVFT : c'est une classe qui représente le problème de tournées des véhi-cules avec fenêtres de temps, elle hérite de PTVC et elle est caractérisée par unecontrainte de temps qu'il faut la respecter.

• Classe véhicule : qui est caractérisée par une capacité �nie ou in�nie.

3.2.1.2 Diagramme de classes pour chaque problème

Dans la �gure 3.2 on a une classe PVC qui constitue un agrégat pour les deux classeClient et Dépôt.Elle a aussi un lien avec la classe Véhicule et elle à des méthodes tel que la rechercheTabou, chercherChemin...

CHAPITRE 3. ETUDE CONCEPTUELLE 30

Figure 3.2 � Diagramme de classes pour le PVC

Dans la �gure 3.3 on a la même présentation que celle de PVC sauf que le nombredes véhicules dans le PTV passe de 1 à plusieurs.

CHAPITRE 3. ETUDE CONCEPTUELLE 31

Figure 3.3 � Diagramme de classes pour le PTV

Dans la �gure 3.4 on a aussi le même principe que les précédentes sauf que pourPTV à capacités le client possède une quantité et l'attribut " capacité " de la classeVéhicule va avoir une valeur �nie.

CHAPITRE 3. ETUDE CONCEPTUELLE 32

Figure 3.4 � Diagramme de classes pour le PTV à capacités

Dans la �gure 3.5 on a une présentation du PTV à fenêtres de temps dans laquelleune classe PTVFT est liée à la classe Véhicules, Dépôt et ClientTw (qui posséde à partla quantité, une fenetre de temps).

CHAPITRE 3. ETUDE CONCEPTUELLE 33

Figure 3.5 � Diagramme de classes pour le PTV à fenêtres de temps

3.2.1.3 Diagramme de classes général

Après qu'on a détaillé les diagrammes de classes chacun à part, on va les rassemblerensemble dans un seul diagramme, en cherchant des propriétés communes entre eux.

CHAPITRE 3. ETUDE CONCEPTUELLE 34

Figure 3.6 � Diagramme de classes général

3.2.2 Etude dynamique du système

Un diagramme de séquence montre les interactions entre les systèmes arrangés enséquences dans le temps et les messages échangés. Dans cette partie, nous présenteronsdeux diagrammes de séquences illustrant deux scénarios de notre application.

CHAPITRE 3. ETUDE CONCEPTUELLE 35

3.2.2.1 Diagramme de séquence : Visualisation d'une solution d'un pro-blème TSP

Dans le diagramme de séquence : visualisation d'une solution Tsp, lorsque l'utilisateurclique sur un problème tsp existant dans l'arbre des problèmes, une méthode selection-nerTsp() de la classe " choix " est invoqué.Dans le code de cette méthode on fait appel à la méthode chargerFichier de la classeTsp qui a le rôle de chargement du �chier XML, ensuite elle invoque la méthode des-sinerRoute de la classe Tsp pour dessiner les routes et en�n elle invoque la méthodedessinerVille pour dessiner les villes.

Figure 3.7 � DS pour la visualisation d'une solution au problème

CHAPITRE 3. ETUDE CONCEPTUELLE 36

3.2.2.2 Diagramme de séquence : Ajout d'un problème VRP

Dans ce diagramme de séquence, une méthode " ajouter " de la classe " choix " estinvoquée, dans laquelle on fait appel aux méthodes :

• "SaisirNbVehicule" : dans laquelle on fait appel à " SetNbVehicule " de la classeVrp.

• "SaisirDonnées" : cette méthode est invoquée n fois jusqu'à satisfaire la conditiond'arrêt. Dans cette méthode on test si le compteur==-1, on appel " a�ecterDepot" de la classe Vrp, sinon on appel " a�ecterClient ".Aussi il y'a appel à la méthode " ajouterLigne " de la classe Vrp.Dans le cas où le bouton supprimer est clicker,une méthode " suppDonnées " dela classe choix est invoquée. Et dans le cas où le bouton enregistrer est clicker,une méthode " EnregDonnées " est invoqueé dans laquelle on appel la méthode" enregistrer " de la classe Vrp.

CHAPITRE 3. ETUDE CONCEPTUELLE 37

Figure 3.8 � DS pour l'ajout d'un problème

Conclusion

Dans ce chapitre, nous avons passé à la conception détaillée pour expliquer lesclasses de notre application.Ensuite, nous avons conçu quelques aspects dynamiquesde notre application en se basant sur les diagrammes de séquence. Dans le prochainchapitre, nous passerons à une description de l'état de la réalisation du projet.

CHAPITRE4 Réalisation

Introduction

Le présent chapitre décrit la réalisation de notre application d'optimisation de pro-blème de transport. L'organisation de ce chapitre commence tout d'abord, par la pré-sentation de l'environnement matériel et logiciel suivi par la description des interfaceshomme-machine de l'application réalisée toute en détaillant la fonctionnalité de notreapplication. Nous présenterons à la �n les problèmes rencontrés lors de l'élaborationde ce travail.

4.1 Environnement de travail

4.1.1 Environnement matériel

Pour implémenter notre application, nous avons utilisé 2 PCs dont leurs con�gura-tions sont les suivantes :

• Systèmes d'exploitation : Microsoft Windows Vista service Pack1/Microsoft Win-dows Vista service Pack2.

• Processeurs : Processeur Intel(R) Pentium R© DUAL CPU 2.00GHz / Intel R©Centrino Core 2 Duo CPU 1.66 GHz

• Mémoires : 3 GO RAM / 2 GO RAM• Disque dur : 250 GO

CHAPITRE 4. RÉALISATION 39

4.1.2 Environnement logiciel

Notre projet doit être basé sur une bonne conception et réalisé à l'aide des logicielsperformants, ce qui facilite la phase de la réalisation et de la maintenance. Nous avonschoisi :

4.1.2.1 DotNet

Le .NET Framework permet le développement d'applications fonctionnelles sur ma-chine Windows équipée de ce Framework. Malgré la simplicité de développement appa-rente, il n'en est pas moins complexe à connaître et à maitriser tant les outils proposéssont nombreux..NET se base sur plusieurs technologies :

• Des protocoles de communication basée sur le Framework .NET et non plus surles modèles COM ou OLE.

• Des langage de programation telque C++.net, VB.NET, JSharp et CSharp...• Une bibliothèque compatible Framework .NET et non plus MFC, GDI...• une machine virtuelle basée sur la CLI multi-langage.• MSBuild : un outil de gestion de projet avec plusieurs compilateurs.• Windows Live ID,Framework .NET : un ensemble de bibliothèques de haut ni-

veau.• Une portabilité pour les systèmes d'exploitation Windows et Windows Mobile.• Des composants facilitant le développement de services (MapPoint) et d'applica-

tions locales ou web (ASP.NET).[11]

CHAPITRE 4. RÉALISATION 40

Figure 4.1 � Architecture de framework DotNet

4.1.2.2 EDraw (conception)

Edraw Max est un logiciel de graphiques polyvalent, avec des fonctionnalités quile rendent parfait non seulement pour des diagrammes d'allure professionnelle, que cesoit pour des diagrammes réseau, d'a�aires, d'idées, de travaux, UML, de structure, debase de données, des plans de batîment, designs de mode, cartes directionnelles...[12]

4.1.2.3 Latex (traitement du texte)

LaTeX est un ensemble de programmes libres pour le traitement de texte scienti-�que. Il a été initialement développé en 1984 à la suite de TeX (développé par DonaldKnuth en 1977).Toute une communauté de développeurs (informaticiens et mathématiciens ; étudiantset chercheurs) a contribué ensuite à mettre au point la version actuelle LaTeX2e :un coeur générique, auquel peuvent s'ajouter des extensions spécialisées. Cette com-

CHAPITRE 4. RÉALISATION 41

munauté demeure très active et l'on trouve beaucoup de sites Internet proposant destutoriels et des exemples (principalement en anglais).[13]

4.1.2.4 Photoshop cs4

Photoshop est un logiciel de retouche, de traitement et de dessin assisté par ordina-teur édité par Adobe. Il est principalement utilisé pour le traitement de photographiesnumériques, mais sert également à la création d'images.Reconnu aussi par les infographistes professionnels à travers sa puissante galerie de�ltres et d'outils graphiques performants, il est maintenant utilisé par une grande ma-jorité des studios et agences de créations.[1]

4.2 Choix technologiques

4.2.1 Framework 3.5

De même que la version 3.0, la version 3.5 utilise la version 2.0 de la CLR. Cette versiondu Framework inclut le .NET Framework 2.0 SP1 qui ajoute des méthodes et des pro-priétés aux bibliothèques de bases de la version 2.0. Celles-ci sont nécessaires à certainesfonctionnalités du framework 3.5 telle que le framework Language Integrated Query(LINQ) permettant des requêtes objet sur des Data, des Collections, du XML ou desDataSets. Elle intègre également le framework Ajax.Net avec de nouveaux protocoles(AJAX, JSON, REST, RSS, Atom) et d'autres standards WS.[14]

4.2.2 WPF

Il est basé sur Direct3D (dont il n'utilise pas toutes les possibilités) et entièrementvectoriel, pour le dessin comme pour le texte. Cela permet d'augmenter la taille des

CHAPITRE 4. RÉALISATION 42

objets en fonction de la résolution de l'écran sans e�et de pixelisation.Il supporte l'a�chage de nombreux formats d'images ou vidéo comme MPEG, AVI, etbien sûr WMV de Microsoft.Séparation code / designWPF nous permet de séparer en couches notre application, il va se charger de séparerle code designer du code behind (classe d'arrière plan). C'est à dire que le designer vapouvoir travailler sur le design de l'application, via un langage commun basé sur duXML qui est le XAML .Quant au développeur de son côté via le code behind il va pouvoir travailler sur lacouche métier. Cela va permettre une meilleure productivité et un support de l'appli-cation plus facile.[15]

Figure 4.2 � Séparation code / design

4.2.3 Les langages de programmation

4.2.3.1 CSharp.net

CSharp.net est le langage par excellence de .Net, apparu en 2001. Ce langage estun langage de programmation orientée objet, étant un carrefour entre di�érent langage

CHAPITRE 4. RÉALISATION 43

comme le Java, le C++ ou encore le Visual Basic, tout en restant un langage à part.Le CSharp est très polyvalent, Il permet de coder de simples applications consolesjusqu'à de gros programmes avec une multitude de fenêtres, en passant par les jeux.C'est donc au �l des années que ce langage devint de plus en plus e�cace et plusfacile d'accès que beaucoup d'autres langages orientés objet, ce qui fait aujourd'hui sapopularité.[16]

4.2.3.2 XML

• Dé�nition du XMLXML (eXtensible MarKup language) est en quelque sorte un langage HTMLamélioré permettant de dé�nir de nouvelles balises. La force de XML réside danssa capacité à pouvoir décrire n'importe quel domaine de données grâce à sonextensibilité. Il va permettre de structurer, poser le vocabulaire et la syntaxe desdonnées qu'il va contenir.

• Structure de nos documents XMLUn document XML doit suivre scrupuleusement les conventions de notation XMLet donc appelé document bien formé.Dans notre projet, un document XML est caractérisé par une balise racine appelée" Villes " qui contient ou non des attributs tel que le nombre des véhicules ou lacapacité de la véhicule.Cette balise racine, contient un nombre �ni des balises appelées " Client ".Un client est caractérisé par des cordonnées "x" et "y" et parfois un temps dedébut et un temps de �n.On trouve aussi dans la balise "Villes " une balise " dépôt" qui est lui-mêmecaractérisé par des coordonnées "x" et "y".

• XAMLLe XAML (eXtensible Application Markup Language) est un langage déclaratifbasé sur la syntaxe du XML. Il permet grâce à des balises et des attributs decréer très facilement des objets.

CHAPITRE 4. RÉALISATION 44

Pour cela, le compilateur XAML se charge de déclarer et dé�nir des objets dyna-miquement grâce aux balises (équivalent des classes) et aux attributs (équivalentsaux propriétés) XAML.Malgré sa syntaxe simple, le XAML permet de restituer des graphiques vectoriels,ou des modèles 3D aisément. Les possibilités graphiques sont donc in�nies.

• XPathC'est le résultat d'un e�ort d'homogénéisation de la syntaxe et de la sémantiquede fonctions communes à [XSLT] et [XPointer].L'objectif premier de XPath est de dé�nir la manière d'adresser des parties d'undocument [XML]. En vue de pourvoir à cet objectif premier, cette spéci�cationfournit également les moyens pour traiter des chaînes de caractères, des nombreset des booléens.XPath représente les documents XML comme un arbre de noeuds. Il y a plusieurstypes de noeuds, parmi lesquels les noeuds d'éléments, d'attributs et de texte.XPath fournit un mécanisme pour associer une valeur de type chaîne de caractèresà chaque type de noeud. Certains ont également un nom.[17]

4.3 Réalisation de l'application

Le but de cette partie est de présenter quelques aspects visuels de notre application.Les di�érentes fonctionnalités et les principaux objets constituant les interfaces serontdécrits dans ce qui suit.

4.3.1 Page d'acceuil

La �gure 4.3 présente l'entrée de notre application dans laquelle est indiqué le typedu problème traité.

CHAPITRE 4. RÉALISATION 45

Figure 4.3 � page d'acceuil du problème de transport

4.3.2 Page principale

La �gure 4.4 présente la page principale de gestion du problème de transport. Atravers cette interface l'utilisateur peut soit ajouter, soit supprimer un problème.Elle contient aussi une carte graphique de grand Tunis accompagnée d'un " Slider "permettant de faire un zoom.L'interface contient de plus un arbre des problèmes existants dans notre base commele montre la �gure.

CHAPITRE 4. RÉALISATION 46

Figure 4.4 � Interface de la page principale

4.3.3 Résolution d'un problème PTV : Choix d'une insatance

• A�chage d'une solution :Sur l'interface de la �gure 4.5 s'a�che une solution à un problème sélectionné, endonnant le cout total de la solution ainsi que les informations relatives à chaqueclient.

Figure 4.5 � Interface d'a�chage d'une solution

CHAPITRE 4. RÉALISATION 47

4.3.4 Suppression d'un problème

Si on appuie sur le bouton de suppression indiqué dans la �gure 4.4, une boite dedialogue qui s'a�che, soit pour con�rmer soit pour annuler l'action, comme l'indiquela �gure 4.6.

Figure 4.6 � Interface de con�rmation de suppression

4.3.5 Ajout d'un problème

Lors de l'appuie sur le bouton d'ajout présentée dans la �gure 4.4, une nouvelleinterface de la �gure 4.7 s'a�che, dans laquelle il y'a un choix entre des problèmes detransport.

Figure 4.7 � Interface de choix d'un problème

CHAPITRE 4. RÉALISATION 48

Ensuite lorsque l'utilisateur appuie sur le bouton " valider " de la �gure 4.7, s'a�chel'interface représentée par la �gure 4.8. Dans cette interface s'e�ectue la saisie desdonnées relatives au problème choisi en donnant la possibilité de supprimer une ligneerronée.

Figure 4.8 � Interface de saisie des données

Quand l'utilisateur appuie sur la disquette de l'enregistrement, une boite s'a�chepour la saisie du nom du �chier contenant les données déjà saisie, comme le montre la�gure 4.9.

Figure 4.9 � Interface de saisie du nom du problème

CHAPITRE 4. RÉALISATION 49

En�n lorsque l'utilisateur appuie sur le bouton " enregistrer " de la �gure 4.9 unenouvelle boite s'ouvre représentée par la �gure 4.10.Cette boite a le rôle de con�rmationde l'enregistrement.

Figure 4.10 � Interface de con�rmation de l'enregistrement

Conclusion

Dans ce chapitre, nous avons passé de la spéci�cation de l'environnement matérielet logiciel au présentation de quelques interfaces graphiques de notre application pourmieux comprendre sa déroulement.

Conclusion générale

ce rapport s'inscrit dans le cadre de notre projet de �n d'étude élaboré ausein de l'Ecole Supérieure des Sciences et Techniques de Tunis (ESSTT).Il s'agit de la réalisation d'une solution générique pour la résolution des

problèmes statiques de tournées de véhicules.Pour la réalisation de notre application, nous nous sommes impliqués sur une étudeminutieuse des outils de travail a�n de dégager les di�érents besoins et exigences et dechoisir l'architecture informatique la mieux adaptée. Ainsi, nous nous sommes baséssur UML pour la spéci�cation et la conception, sur CSharp pour la programmation etsur XML pour le stockage des informations.Nous avons essayé, dans ce rapport de présenter tout ce qui s'avère indispensable pourdécrire clairement toutes étapes du projet : Etat d'art, étude théorique, spéci�cationet conception et en�n la réalisation.l'élaboration de ce projet, nous a été béné�que sur divers plans :

- Sur le plan théorique, il nous a permis de découvrir des nouvelles technologies(commele WPF) et le langage de programmation CSharp.

- Sur le plan pratique, ce projet nous a été favorable en nous o�rant la possibilitéd'approfondir nos connaissances acquises tout au long du cursus universitaire àl'ESSTT et de nous familiariser avec la conduite des projets informatiques.

- De façon générale : nous sommes contents à la fois du travail réalisé, mais égalementd'avoir e�ectué un projet qui a enrichi nos connaissances dans le développementd'applications .Net. Ce dé� n'était pas gagné d'avance, car nous avons dû nousformer en toute autonomie à la plupart des outils et techniques utilisés pendantce projet, chose qui nous a fait douter sérieusement de nos capacités pendant les

CONCLUSION GÉNÉRALE 51

premières semaines.

Plusieurs améliorations restent envisageables dans ce travail, ces améliorations touchentessentiellement l'ergonomie des interfaces, ainsi que l'extensibilité de notre applicationpour prendre en charge d'autres problèmes.En e�et, le fait d'avoir développé cette application en suivant une plateforme .Net, larend facilement évolutive, ce qui est primordial, car une application �gée est, tôt outard, vouée à ne plus être utilisée.Finalement, nous avons fait de notre mieux pour bien laisser une bonne impression ausein de notre école et présenter un bon travail digne de notre préparation et de nosétudes et restera dans la bibliothèque de l'école pour les futurs promotions.

Bibliographie

[1] Utilisation d'ADOBE PHOTOSHOP CS4 , Adobe Systems Incorporated, 2008.

[2] http ://fr.wikipedia.org/wiki/Problème-du-voyageur-de-commerce, Février 2010.

[3] http ://fr.wikipedia.org/wiki/Problème-de-tournées-de-véhicules, Février 2010.

[4] ftp ://ftp-developpez.com/khayyam/articles/algo/ voyageur-de-commerce/colonies-de-fourmis/colonies-de-fourmis.pdf, Février 2010.

[5] http ://hal.archives-ouvertes.fr/docs/00/13/56/51/PDF/TheseBourazza.pdf, Fé-vrier 2010.

[6] http ://fr.wikipedia.org/wiki/Recuit-simulé, Février 2010.

[7] http ://fr.wikipedia.org/wiki/Optimisation-par-essaims-particulaires, Février2010.

[8] http ://hal.archives-ouvertes.fr/docs/00/14/37/82/PDF/These-KAMMARTI-Ryan.pdf, Février 2010.

[9] http ://www.baptisteautin.com/.../Rapport-Metaheuristiques-Optimisation-Combinatoire.doc, Février 2010.

[10] http ://hal.archives-ouvertes.fr/docs/00/07/44/74/PDF/RR-2197.pdf, Février2010.

[11] http ://www.dotnet-france.com/Documents/Framework/Framework.NET-Notions-fondamentales.pdf, Avril 2010.

[12] http ://fr.giveawayoftheday.com/edraw-max-43/, Avril 2010.

[13] http ://euler.ac-versailles.fr/webMathematica/LaTeX/index.htm, Avril 2010.

BIBLIOGRAPHIE 53

[14] http ://fr.wikipedia.org/wiki/Framework-.NEThttp ://www.xaml.fr/windows-wpf.html, Avril 2010.

[15] http ://www.dotnet-france.com/Documents/WPF/Introduction à WPF.pdf,Avril 2010.

[16] http ://rangiroa.polytech.unice.fr/riveill/2009-10/dotnet/CSharp-base.pdf, Avril2010.

[17] http ://xmlfr.org/w3c/TR/xpath/, Avril 2010.

ANNEXEA Réalisation de la cartegraphique de grandTunis

Pour réaliser la carte de grand Tunis, on a besoin de trois images avec des altitudesdi�érentes : 30 Km(N1), 15Km(N2) et 7.5 Km(N3).Chaque altitude est reliée à un niveau et chaque niveau est représenté par une image :

• L'imageN1 de résolution 640*680.• L'imageN2 de résolution 1220*1320.• L'imageN3 de résolution 2530*2710.

Voici la �gure A.1 qui illustre la description ci-dessus.

Figure A.1 � Relation entre altitudes,niveaux et images

ANNEXE A. RÉALISATION DE LA CARTE GRAPHIQUE DE GRAND TUNIS55

Dans notre carte, chaque image possède un intervalle de dimension, il est propor-tionnel par rapport a l'attitude. Donc à chaque situation de la carte, une zone �xe del'image 600*600 est a�chée. Pour préciser l'altitude de l'image, on utilise un 'Slider'.

Figure A.2 � La zone a�chée de l'image

A chaque variation de ce dernier on détermine l'altitude puis on a�che l'image corres-pondante et si on a des clients et des chemins déjà dessinés, on les dessine une autrefois.Pour se déplacer sur la carte, il su�t de positionner le curseur sur la carte et de mainte-nir le bouton gauche de souris foncé. La direction de déplacement est déterminée selonla position de souris.

Figure A.3 � Directions de déplacement