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'aection 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 de
bonheur 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é durant
les 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 mon
Coeur que notre amitié durera éternellement.

Asma Boudhief

DÉDICACES

A ce qu'est toujours mon meilleur exemple dans la vie
mon très cher père
Pour les sacrices qu'il a consentis pour mon éducation et pour l'avenir qu'il n'a cessé
d'orir.
A ce qui m'a été toujours la garante d'une existence paisible et d'un avenir radieux
ma mère
A ce qui a fait de son mieux pour me soutenir durant ce travail
ma chère soeur : Hanen
A ceux qui m'ont soutenu, encouragé, apprécie mon eort 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 avec
mes 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 notre
soutenance de projet de n d'étude.

Nous tenons également à remercier profondément, Mademoiselle
Nesrine DARRAGI , pour
le temps qu'il a investi pour évaluer notre travail.

Nous remercions particulièrement notre encadreur, Madame Zoulel Kouki et notre
co-encadreur, Madame Besma Fayech Châar pour
leur encadrement de qualité dont il nous a fait bénécier aimablement, leur aide
pré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 qui
nous 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 nombreuses
discussions, 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

cules à capacités limitées(PTV à capacités) . . . . . . . . . . . . 18

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'intensication . . . . . . . . . . . . . . . . . . . . . 24

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

3 Etude conceptuelle 26
3.1 Spécication 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 solution
d'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'achage d'une solution . . . . . . . . . . . . . . . . . . . . 46

4.6 Interface de conrmation 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 conrmation de l'enregistrement . . . . . . . . . . . . . . . 49

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

A.2 La zone aché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

A vec la mondialisation , les délocalisations des centres de production
et 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 diciles à résoudre de
maniè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 une
rue) à un coût minimum.
L'intérêt pour ce genre d'activité est grandissant dans la vie actuelle, puisqu'elle peut
s'appliquer à de nombreux domaines, de plus, la mondialisation implique des coûts
logistiques de plus en plus importants pour les entreprises.
Ainsi un élément fondamental de tout système logistique, est la gestion et la planica-
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ère
décennie. Les recherches récentes incluent des eorts signicatifs en formulation du
problè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 eorts sont nécessaires an de développer des systèmes de trans-

INTRODUCTION GÉNÉRALE 2

port exibles et ecaces répondant aux préoccupations actuelles relatives à l'économie
et à notre qualité de vie.

1
CHAPITRE

Etat d'art

Introduction

Le problème de transport est un problème vague qui contient plusieurs variantes
commençant par le problème de voyageur de commerce jusqu'à atteindre le problème
de tournées des véhicules et ses diérentes variantes.
La recherche de méthodes ecaces de résolution de ces problèmes a été à l'origine
d'importants développements en programmation mathématiques et en optimisation
combinatoire. Et comme les algorithmes exacts ne sont applicables qu'à des problèmes
de 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 de
résolution permettant d'obtenir des solutions exactes en un temps raisonnable pour de
grandes 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 est
déjà un nombre d'une longueur de 100 chires. Pour comparaison, un nombre d'une
longueur de 80 chires permettrait déjà de représenter le nombre d'atomes dans tout
l'univers connu.
Rigoureusement, résoudre le problème du voyageur de commerce est une tâche dicile :
on doit trouver le plus petit cycle hamiltonien (au sens qu'on doit prouver qu'il n'en
existe pas de longueur inférieure) dans le graphe d'entrée. Toutefois il arrive qu'on se
satisfasse d'une bonne solution, c'est-à-dire d'un cycle hamiltonien qui ne soit pas
trop 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 de
problèmes de recherche opérationnelle et d'optimisation combinatoire. Il s'agit de dé-
terminer les tournées d'une otte de véhicules an de livrer une liste de clients. Le but
est 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èmes
NP-complet(Problème dont on ne peut pas trouver un algorithme polynomial pour le
résoudre).[3]
Dans ce qui suit nous nous intéressons uniquement des variantes statiques du PTV.


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 eectué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 eectuées avant les collectes
b) Une tournée ne peut contenir uniquement des collectes ou uniquement des
livraisons.
c) A tout moment, la capacité du véhicule doit être respectée
d) On doit utiliser tous les véhicules disponibles
e) 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 est
associée, c'est-à-dire qu'il y a des livraisons que l'on ne peut pas faire sans avoir fait
en 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 il
doit attendre le début de la fenêtre de temps pour commencer son service (contrainte
de fenêtre de temps)
i) Un véhicule ne peut eectuer son service s'il arrive après la fenêtre de temps
(contrainte rigide de fenêtre de temps)
j) Pour chaque client, on eectue deux services, une livraison puis une collecte


k) Chaque client est lié à un dépôt, il ne peut être servi que par ce dernier
l) 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 de
tourné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 X
SDVRP X X X
HVRP X X
OVRP X X X X
VRPB X X X X X X
VRPTW X X X X X
MVRPB X X X X
VRPPD X X X X
VRPSPD X X X X
VRPBTW X X X X X X
MVRPBTW X X X X X
VRPPDTW X X X X X X
VRPSPDTW X X X X X X

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


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ôts
SDVRP : Site-Depenent Vehicle Routing Problem, problème de tournées de véhicules
avec aectation des dépôts
HVRP : Heterogeneous Vehicle Routing Problem, problème de tournées avec des véhi-
cules à capacité variable
OVRP : Open Vehicle Routing Problème, problème de tournées de véhicules ouvert
VRPB : Vehicle Routing Problem with Backhaul, problème de tournées de véhicules
avec livraison et collecte
VRPTW : Vehicle Routing Problem with Time Window, problème de tournées de vé-
hicules avec fenêtre de temps
MVRPB : Mix Vehicle Routing Problem with Backhaul, problème de tournées de véhi-
cules avec livraison et collecte, mixte
VRPPD : Vehicle Routing Problem with PickUp and Delivery, problème de tournées
de véhicules avec livraison et collecte
VRPSPD : Vehicle Routing Problem with Simultaneous PickUp and Delivery, problème
de tournées de véhicules avec livraison et collecte simultanée
VRPBTW : Vehicle Routing Problem with Backhaul and Time Window, problème de
tournées de véhicules avec livraison et collecte et fenêtre de temps
MVRPBTW : 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, mixte
VRPPDTW : 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 temps
VRPSPDTW : Vehicle Routing Problem with Simultaneous PickUp and Delivery and
Time Window.


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çon
sûre vers la solution optimale. Le principe essentiel de ces méthodes est d'énumérer de
maniè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 ecacement des
problèmes allant jusqu'à 50 clients.
Mais vu que les méthodes exactes restreignent le nombre des clients envisageables dans
les 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é. Ces
méthodes permettent de gérer des problèmes de grandes tailles avec des temps de
ré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 dicile de résoudre des
instances de grande taille de façon optimale. On se contente alors de trouver des so-
lutions de bonne qualité . An d'obtenir des solutions dans des temps de calculs
raisonnables, 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'autres
heuristiques 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 on
augmente le nombre de clients à visiter lors d'une tournée plus on a de la diculté à
donner une bonne réponse dans un temps respectable. De plus, on ne peut déterminer
une réponse exacte pour ces problèmes puisque cela prendrait beaucoup trop de temps
et cause un nombre earant de possibilités.
Voici la formule pour calculer le nombre de possibilités : 1/2(n-1) !


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 type
de problème d'optimisation pouvant se réduire à une boîte noire . Elles sont souvent
moins puissantes que des méthodes exactes sur certains types de problèmes. Elles ne
garantissent 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 ecacement par des
approches purement mathématiques, les métaheuristiques peuvent alors être utilisées
avec prot.
• 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 leurs
futurs choix et d'indiquer aux autres individus des directions à suivre ou au
contraire à éviter.
Fortement inspiré du déplacement des groupes de fourmis, cette méthode a pour
but 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 au
problè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'appuyer
sur 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 des
techniques 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 une
population 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 de
décrire l'évolution d'un système thermodynamique. Par analogie avec le processus


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 modiant, on en obtient une seconde. Soit
celle-ci améliore le critère que l'on cherche à optimiser, on dit alors qu'on a fait
baisser l'énergie du système, soit celle-ci le dégrade. Si on accepte une solution
améliorant le critère, on tend ainsi à chercher l'optimum dans le voisinage de la
solution de départ.
L'acceptation d'une mauvaise solution permet alors d'explorer une plus grande
partie de l'espace de solution et tend à éviter de s'enfermer trop vite dans la
recherche d'un optimum local.[6]
• Algorithme d'optimisation par essaims particulaires :
Cette méthode d'optimisation se base sur la collaboration des individus entre
eux. 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'un
groupe 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 en
variables continues.[7]
• Recherche taboue :
La méthode taboue est une méthode de recherche locale. Son principe repose
sur une méthode de déplacement sur l'espace des solutions, tout en cherchant
constamment à 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 dehors
de 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


du voisinage de la solution de départ et à dénir des transformations taboues que
l'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 taboue
puisque :
• Les algorithmes génétiques sont coûteux en temps de calcul, à cause qu'ils
manipulent plusieurs solutions simultanément. C'est le calcul de la fonction de
performance qui est le plus pénalisant, et on optimise généralement l'algorithme
de 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èmes
les plus caractéristiques est celui de la dérive génétique, qui fait qu'un bon
individu 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'optimum
attendu. Les méthodes de sélection proportionnelle peuvent en particulier
favoriser ce genre de dérive.
Un autre problème surgit lorsque les diérents individus se mettent à avoir des
performances similaires : les bons éléments ne sont alors plus sélectionnés, et
l'algorithme ne progresse plus.

• Pour le recuit simulé, une fois l'algorithme piégé à basse température dans un
minimum 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, par
exemple en acceptant une brusque remontée de la température, de temps en
temps, 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 lui
donne une valeur minimale au delà de laquelle on ne change plus de palier de
température. Mais si cette valeur est trop grande, l'algorithme passera son temps


à augmenter et diminuer son énergie car il acceptera trop de perturbations
dégradantes et il n'arrivera pas à explorer à fond une vallée.
Ainsi, il est fort possible que l'algorithme arrive à trouver la vallée dans
laquelle 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 le
tableau 2.

RT AG
Problème Taille Solution optimale
cout pourcentage cout pourcentage
Eil76 76 545 545 100 572 95
Eil101 101 642 657 97 711 90
Gr96 96 512 527 97 558 91
KroA100 100 21285 21521 98 22638 94
KroC100 100 20750 20940 99 22626 91
KroD100 100 21249 21835 97 24134 88
Lin105 105 14382 14878 96 15490 92
Pr76 76 108159 109044 99 115553 93

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


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 recherche
taboue que nous avons choisie pour les performances qu'elle présente comparées aux
autres heuristiques.

2
CHAPITRE

Etude théorique

Introduction

Dans ce chapitre, nous nous focalisons sur l'étude théorique de quelques problèmes
présentés dans le premier chapitre. Nous déterminons en premier lieu les formulations
mathé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'optimisation
combinatoire 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 un
ensemble de critères.

2.1.1 Formulation mathématique du problème du voyageur de
commerce(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 consiste
en la détermination du parcours de coût minimal (distance, temps, etc.), d'un seul
vé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ût
minimal dans un graphe complet G= (V, A) valorisé (cout cij associé a chaque arc (i,j)
de A).
voici la signication des notations qu'on va utilisé dans la formulation du problème :
n=|V|, nombre de sommets du réseau
cij =cout de l'arcs (i,j)
bj = nombre de s arcs incidents au sommet j
ai =nombre des arcs partant de sommet
xij = 1 si l'arc (i,j) appartient à la tournée
xij = 0 sinon
Donc la fonction objective a pour formulation :
n n
minimiser cij xij
i=1 j=1

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
xij = bj = 1
i=1
n
xij = ai = 1
j=1

• Il faut assurée la continuité d'un tournée : une véhicule entre un sommet, il faudra
qu'il sort.
Soit mathématiquement :
n n
xip xpj = 0 p = 1, 2, 3, ...n
i=1 j=1


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 des
véhicules(PTV)

Le problème de tournées des véhicules (PTV, connu par VRP) est une généralisation
du 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 version
simpliée de CVRP où la capacité de chaque véhicule est supérieure à la totalité de la
demande (ou considérée inni) 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


Donc la fonction objective à pour formulation :
n n m
minimiser cij xij k
i=1 j=1 k=1

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 m
xk = 1 j = 1, 2, 3, ...n
ij
i=1 k=1

n m
xk = 1 i = 1, 2, 3, ...n
ij
j=1 k=1

• Il faut assurée la continuité d'un tournée : une véhicule entre un sommet, il faudra
qu'il sort.
Soit mathématiquement :
n n
xk
ip − xk = 0 p = 1, 2, 3, ...n k = 1, 2, 3, ...m
ip
i=1 j=1

• Respect du nombre de véhicules : la disponibilité des véhicules n'est pas dépassée :
n
xk ≤ 1 j = 1, 2, 3, ...n
i1
i=1

n
xk ≤ 1 i = 1, 2, 3, ...n
1j
j=1


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

Figure 2.2 Représentation graphique du problème VRP

vé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 aecté 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 = 1 si l'arc (i,j) est parcouru par la véhicule k
ij

xk = 0 sinon
ij


Donc la fonction objective a pour formulation :
n n m
minimiser cij xij k
i=1 j=1 k=1

Tout les contraintes de m-TSP doit être vérier. En plus la capacité des véhicules doit
être respectée :
n n
di ( xij k ) ≤ Dk
i=1 j=1

vé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 temporel
des 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érieés.
Soient :
tk =temps nécessaire au véhicule k pour décharger ou charger dans le sommet i (tk = 0)
i 1

tk = temps nécessaire au véhicule k pour traverser l'arc (i,j) (tk =inni).
ij ij

En assurant la non-violation des contraintes temporelles [10] :

xk (Dateservicei + tk + tk Dateservicej ) ≤ 0
ij ij i

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 diciles à
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 eet, la résolution d'un problème


dans lequel on considère des instances de taille comparable à celle rencontrées dans la
pratique conduit souvent à se heurter à des problèmes de taille mémoire et de temps
de 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 pour
guider la recherche de manière intelligente à travers l'espace des solutions. Elle s'est ré-
vélée particulièrement ecace et a été appliquée avec succès à de nombreux problèmes
NP-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 eet, tout comme celles-ci explore itérativement l'espace
S 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 de
solutions permettant d'améliorer la fonction objective, ici, la solution suivante retenue
est 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 meilleures
mê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 foction
objective est inférieure ou légèrement supérieure.
Cette modication du processus d'exploration rend donc la méthode taboue insensible
aux optima locaux, mais elle introduit le risque de cycler dès que l'on sort de l'un
de ces optima, en y retournant aussitôt. C'est là que la notion de mémoire trouve sa
justication.
Pour régler ce problème, la méthode taboue conserve des informations sur le chemi-
nement récent eectué à travers l'ensemble des solutions an de s'introduire certaines
transformations de la solution courante qui pourrait ramener la procédure vers des
solutions déjà rencontrées. Ces transformations sont alors déclarées taboue, d'où le


nom de la méthode. Ceci a pour eet de restreindre l'accès à certaines solutions et par
suite d'orienter en quelques sorte la recherche. Néanmoins, pour conserver l'approche
susamment de exibilité, le caractère tabou de ces transformations ne doit pas être
maintenu en permanence.
En limitant la durée de vie des tabous, on permet à la méthode de remettre en question
ses choix passés (une fois le risque de cycler disparus) et ainsi de mener une exploration
beaucoup plus large du domaine des solutions.
Dans la description que nous venons de faire, il est clair que le type de voisinage ainsi
que les paramètres de la méthode taboue sont déterminants pour avoir une bonne
solution.

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 la
liste taboue.

2. Poser f ∗ =f (X0 ) et k=0 (k étant le nombre d'itérations eectué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érier 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 solution
de 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 à la
méthode taboue et de dégager son importance vis-à-vis du processus de la recherche.


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 inue
considérablement sur la qualité de la solution ainsi que sur le temps d'exécution. En
eet, partir d'une solution médiocre nous demanderait plus de temps pour atteindre
la meilleure solution, mais débuter avec une bonne solution impliquerait l'utilisation
d'une autre heuristique (classique) pour sa construction. En outre, commencer par une
bonne solution ne voudrait en aucun cas dire qu'elle soit assez proche de la meilleure
solution.

2.2.4 La liste taboue

La dénition et la gestion de la liste taboue jouent un rôle primordial dans la
mé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 vers
des 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 à garder
une 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 solution
pré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 nous
donner de bons résultats.
Tout ceci fait en sorte que la taille de cette liste taboue doit convenablement être
choisie de façon à avoir un compromis entre la exibilité (petite taille de la liste) et
l'élimination du risque de cyclage (grande taille de la liste). Cette taille est d'autant
plus dicile à déterminer qu'elle peut dépendre de la taille et de la nature du problème.


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 an de créer de nouvelles solutions.
Au début de la recherche, la mémoire centrale contient des composantes provenant de
solutions très diverses et le processus de combinaison aura donc tendance à créer une
diversité de nouvelles solutions.
Plus la recherche avance et plus la mémoire centrale aura tendance à ne mémoriser que
les composantes d'un sous-ensemble très restreint de solutions. La recherche devient
donc petit à petit un processus d'intensication.

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 la
méthode, mais ceux-ci peuvent s'avérer parfois trop forts et restreindre ainsi inutilement
l'exploration du domaine des solutions. En particulier, lorsque les tabous sont dénis en
fonction des transformations, ils n'interdisent pas seulement de retourner à la solution
précédente, mais à tout un sous ensemble de solutions dont certaines peuvent ne pas
avoir été encore visitées.
Il faut donc qu'il y ait un mécanisme inverse à celui des tabous qui permettre de
révoquer le statut taboue d'une transformation si son application à la solution courante
permet d'atteindre une solution jugée intéressante, sans pour autant introduire un
risque 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 stocke
la solution entière dans la liste taboue. En eet, dans ce cas, toute annulation d'un
critè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


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

2.2.7 Le critère d'intensication

L'idée à la base de l'intensication consiste à retourner périodiquement visiter des
zones 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 congurations visitées .
• Geler certains attributs qui ont été souvent présents dans les congurations visi-
tées ou dans les congurations 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 algorithme
et 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 citer
deux critères d'arrêts essentiels.
Le premier consisterait à xer un nombre maximal d'itérations (solutions visitées) à ne
pas dépasser et ce en fonction de la taille du problème. Ce critère n'est toutefois pas
très signicatif.
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.


Conclusion

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

3
CHAPITRE

Etude conceptuelle

Introduction

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

3.1 Spécication des besoins

Dans cette partie nous étudions les besoins fonctionnels et non fonctionnels de notre
systè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 du
modèle UML, celui où s'assure la relation entre l'utilisateur et les objets que le système
met 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 la
ré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 modication.

Figure 3.1 Diagramme des cas d'utilisation


3.1.2 Besoins non fonctionnels

Les besoins non fonctionnels peuvent être considérés comme des besoins fonctionnels
spéciaux. Parfois, ils ne sont pas rattachés à un cas d'utilisation particulier, mais ils
caractérisent tout le système (l'architecture, la sécurité, le temps de réponse, etc.). Le
systè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écrit
les classes que le système utilise, ainsi que leurs liens. Ces derniers représentent un
emboî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èmes
traité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


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 une
capacité innie.
• 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 une
contrainte de temps qu'il faut la respecter.
• Classe véhicule : qui est caractérisée par une capacité nie ou innie.

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 classe
Client et Dépôt.
Elle a aussi un lien avec la classe Véhicule et elle à des méthodes tel que la recherche
Tabou, chercherChemin...


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 nombre
des véhicules dans le PTV passe de 1 à plusieurs.


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 pour
PTV à capacités le client possède une quantité et l'attribut capacité de la classe
Véhicule va avoir une valeur nie.


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 laquelle
une classe PTVFT est liée à la classe Véhicules, Dépôt et ClientTw (qui posséde à part
la quantité, une fenetre de temps).


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 rassembler
ensemble dans un seul diagramme, en cherchant des propriétés communes entre eux.


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 en
séquences dans le temps et les messages échangés. Dans cette partie, nous présenterons
deux diagrammes de séquences illustrant deux scénarios de notre application.


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'utilisateur
clique 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 classe
Tsp 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 enn elle invoque la méthode
dessinerVille pour dessiner les villes.

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


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 est
invoquée, dans laquelle on fait appel aux méthodes :
• SaisirNbVehicule : dans laquelle on fait appel à SetNbVehicule de la classe
Vrp.
• SaisirDonnées : cette méthode est invoquée n fois jusqu'à satisfaire la condition
d'arrêt. Dans cette méthode on test si le compteur==-1, on appel aecterDepot
de la classe Vrp, sinon on appel aecterClient .
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 de
la 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.


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 les
classes de notre application.Ensuite, nous avons conçu quelques aspects dynamiques
de notre application en se basant sur les diagrammes de séquence. Dans le prochain
chapitre, nous passerons à une description de l'état de la réalisation du projet.

4
CHAPITRE

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 interfaces
homme-machine de l'application réalisée toute en détaillant la fonctionnalité de notre
application. Nous présenterons à la n les problèmes rencontrés lors de l'élaboration
de 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 congura-
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 logiciels
performants, ce qui facilite la phase de la réalisation et de la maintenance. Nous avons
choisi :

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és
sont nombreux.
.NET se base sur plusieurs technologies :
• Des protocoles de communication basée sur le Framework .NET et non plus sur
les 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]


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 qui
le rendent parfait non seulement pour des diagrammes d'allure professionnelle, que ce
soit pour des diagrammes réseau, d'aaires, d'idées, de travaux, UML, de structure, de
base 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 Donald
Knuth en 1977).
Toute une communauté de développeurs (informaticiens et mathématiciens ; étudiants
et 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-


munauté demeure très active et l'on trouve beaucoup de sites Internet proposant des
tutoriels 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 photographies
numé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 version
du 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 à certaines
fonctionnalité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 des
DataSets. 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èrement
vectoriel, pour le dessin comme pour le texte. Cela permet d'augmenter la taille des


objets en fonction de la résolution de l'écran sans eet de pixelisation.
Il supporte l'achage de nombreux formats d'images ou vidéo comme MPEG, AVI, et
bien sûr WMV de Microsoft.
Séparation code / design
WPF nous permet de séparer en couches notre application, il va se charger de séparer
le code designer du code behind (classe d'arrière plan). C'est à dire que le designer va
pouvoir travailler sur le design de l'application, via un langage commun basé sur du
XML qui est le XAML .
Quant au développeur de son côté via le code behind il va pouvoir travailler sur la
couche 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 est
un langage de programmation orientée objet, étant un carrefour entre diérent langage


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 consoles
jusqu'à 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 ecace et plus
facile d'accès que beaucoup d'autres langages orientés objet, ce qui fait aujourd'hui sa
popularité.[16]

4.2.3.2 XML

• Dénition du XML
XML (eXtensible MarKup language) est en quelque sorte un langage HTML
amélioré permettant de dénir de nouvelles balises. La force de XML réside dans
sa capacité à pouvoir décrire n'importe quel domaine de données grâce à son
extensibilité. Il va permettre de structurer, poser le vocabulaire et la syntaxe des
données qu'il va contenir.
• Structure de nos documents XML
Un document XML doit suivre scrupuleusement les conventions de notation XML
et 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 la
capacité 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 de
début et un temps de n.
On trouve aussi dans la balise Villes une balise dépôt qui est lui-même
caractérisé par des coordonnées x et y.
• XAML
Le XAML (eXtensible Application Markup Language) est un langage déclaratif
basé sur la syntaxe du XML. Il permet grâce à des balises et des attributs de
créer très facilement des objets.


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 (équivalents
aux 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 innies.
• XPath
C'est le résultat d'un eort d'homogénéisation de la syntaxe et de la sémantique
de fonctions communes à [XSLT] et [XPointer].
L'objectif premier de XPath est de dénir la manière d'adresser des parties d'un
document [XML]. En vue de pourvoir à cet objectif premier, cette spécication
fournit également les moyens pour traiter des chaînes de caractères, des nombres
et des booléens.
XPath représente les documents XML comme un arbre de noeuds. Il y a plusieurs
types 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 seront
dé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 type
du problème traité.


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. A
travers 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 comme
le montre la gure.


Figure 4.4 Interface de la page principale

4.3.3 Résolution d'un problème PTV : Choix d'une insatance
• Achage d'une solution :
Sur l'interface de la gure 4.5 s'ache une solution à un problème sélectionné, en
donnant le cout total de la solution ainsi que les informations relatives à chaque
client.

Figure 4.5 Interface d'achage d'une solution


4.3.4 Suppression d'un problème

Si on appuie sur le bouton de suppression indiqué dans la gure 4.4, une boite de
dialogue qui s'ache, soit pour conrmer soit pour annuler l'action, comme l'indique
la gure 4.6.

Figure 4.6 Interface de conrmation 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 nouvelle
interface de la gure 4.7 s'ache, dans laquelle il y'a un choix entre des problèmes de
transport.

Figure 4.7 Interface de choix d'un problème


Ensuite lorsque l'utilisateur appuie sur le bouton valider de la gure 4.7, s'ache
l'interface représentée par la gure 4.8. Dans cette interface s'eectue la saisie des
données relatives au problème choisi en donnant la possibilité de supprimer une ligne
erronée.

Figure 4.8 Interface de saisie des données

Quand l'utilisateur appuie sur la disquette de l'enregistrement, une boite s'ache
pour 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


Enn lorsque l'utilisateur appuie sur le bouton enregistrer de la gure 4.9 une
nouvelle boite s'ouvre représentée par la gure 4.10.Cette boite a le rôle de conrmation
de l'enregistrement.

Figure 4.10 Interface de conrmation de l'enregistrement

Conclusion

Dans ce chapitre, nous avons passé de la spécication de l'environnement matériel
et logiciel au présentation de quelques interfaces graphiques de notre application pour
mieux comprendre sa déroulement.

Conclusion générale

c e rapport s'inscrit dans le cadre de notre projet de n d'étude élaboré au
sein 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 étude
minutieuse des outils de travail an de dégager les diérents besoins et exigences et de
choisir l'architecture informatique la mieux adaptée. Ainsi, nous nous sommes basés
sur UML pour la spécication et la conception, sur CSharp pour la programmation et
sur XML pour le stockage des informations.
Nous avons essayé, dans ce rapport de présenter tout ce qui s'avère indispensable pour
décrire clairement toutes étapes du projet : Etat d'art, étude théorique, spécication
et conception et enn 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(comme
le WPF) et le langage de programmation CSharp.

- Sur le plan pratique, ce projet nous a été favorable en nous orant 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 également
d'avoir eectué un projet qui a enrichi nos connaissances dans le développement
d'applications .Net. Ce dé n'était pas gagné d'avance, car nous avons dû nous
former en toute autonomie à la plupart des outils et techniques utilisés pendant
ce 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 touchent
essentiellement l'ergonomie des interfaces, ainsi que l'extensibilité de notre application
pour prendre en charge d'autres problèmes.
En eet, le fait d'avoir développé cette application en suivant une plateforme .Net, la
rend facilement évolutive, ce qui est primordial, car une application gée est, tôt ou
tard, vouée à ne plus être utilisée.
Finalement, nous avons fait de notre mieux pour bien laisser une bonne impression au
sein 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évrier
2010.

[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évrier
2010.

[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, Avril
2010.

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

A
ANNEXE

Réalisation de la carte
graphique de grand
Tunis

Pour réaliser la carte de grand Tunis, on a besoin de trois images avec des altitudes
dié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.
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 TUNIS
55

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 de
l'image 600*600 est achée. Pour préciser l'altitude de l'image, on utilise un 'Slider'.

Figure A.2 La zone achée de l'image

A chaque variation de ce dernier on détermine l'altitude puis on ache l'image corres-
pondante et si on a des clients et des chemins déjà dessinés, on les dessine une autre
fois.
Pour se déplacer sur la carte, il sut 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 selon
la position de souris.

Figure A.3 Directions de déplacement

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

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

Similaire à Solution générique pour la résolution des problèmes statiques de tournées de véhicules (20)

Plus de Slimen Belhaj Ali

Plus de Slimen Belhaj Ali (18)

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