SlideShare une entreprise Scribd logo
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

        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'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.
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 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
CHAPITRE 1. ETAT D'ART                                                                    6


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.
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ô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.
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ç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) !
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 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
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 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
CHAPITRE 1. ETAT D'ART                                                             11


     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
CHAPITRE 1. ETAT D'ART                                                                     12


     à 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.
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 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
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 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
CHAPITRE 2.        ETUDE THÉORIQUE                                                     17




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
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 des
           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
CHAPITRE 2.        ETUDE THÉORIQUE                                                   19


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



2.1.4 Formulation mathématique du problème de tournées des
           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
CHAPITRE 2.       ETUDE THÉORIQUE                                                        20


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
CHAPITRE 2.         ETUDE THÉORIQUE                                                    21


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.
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 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.
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 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
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 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.
CHAPITRE 2.       ETUDE THÉORIQUE                                                       25


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
CHAPITRE 3. ETUDE CONCEPTUELLE                                                         28


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
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 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...
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 nombre
des 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 pour
PTV à capacités le client possède une quantité et l'attribut  capacité  de la classe
Vé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 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).
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 rassembler
ensemble 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 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.
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'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
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  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.
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 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]
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 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-
CHAPITRE 4. RÉALISATION                                                                  41


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
CHAPITRE 4. RÉALISATION                                                              42


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
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 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.
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 (é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é.
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. 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.
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
  • 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
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 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
CHAPITRE 4. RÉALISATION                                                                48


   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
CHAPITRE 4. RÉALISATION                                                               49


   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.
   • 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 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

Contenu connexe

Tendances

Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
Anouar Kacem
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Salma Gouia
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
Nader Somrani
 
Rapport PFE faten_chalbi
Rapport PFE faten_chalbiRapport PFE faten_chalbi
Rapport PFE faten_chalbi
Faten Chalbi
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
Siwar GUEMRI
 
Rapport de stage pfe odoo 8
Rapport de stage pfe odoo 8 Rapport de stage pfe odoo 8
Rapport de stage pfe odoo 8
ayoub damir
 
Mise en-place-d-une-gestion-electronique-de-document
Mise en-place-d-une-gestion-electronique-de-documentMise en-place-d-une-gestion-electronique-de-document
Mise en-place-d-une-gestion-electronique-de-document
Cyrille Roméo Bakagna
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
Oussama Yoshiki
 
Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étude
Donia Hammami
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Hajer Dahech
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Raoua Bennasr
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'études
Majdi SAIBI
 
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
GHITAMASROUR
 
Conception et réalisation d’un robot de supervision : acquisition et échange ...
Conception et réalisation d’un robot de supervision : acquisition et échange ...Conception et réalisation d’un robot de supervision : acquisition et échange ...
Conception et réalisation d’un robot de supervision : acquisition et échange ...
BADDOU mohamed
 
Page de garde
Page de gardePage de garde
Page de garde
Nizar Mohammed
 
Présentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobilePrésentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobile
Nader Somrani
 
Présentation PFE Hachem Selmi et Ahmed Dridi Big data
Présentation PFE Hachem Selmi et Ahmed Dridi Big data Présentation PFE Hachem Selmi et Ahmed Dridi Big data
Présentation PFE Hachem Selmi et Ahmed Dridi Big data
HaShem Selmi
 
Projet de Fin d'études
Projet de Fin d'études Projet de Fin d'études
Projet de Fin d'études
Ghizlane El Karchouli
 
Rapport projet conception et la réalisation d'une application web gestion des...
Rapport projet conception et la réalisation d'une application web gestion des...Rapport projet conception et la réalisation d'une application web gestion des...
Rapport projet conception et la réalisation d'une application web gestion des...
SAAD SARHANI
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFE
Nadir Haouari
 

Tendances (20)

Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
Rapport PFE faten_chalbi
Rapport PFE faten_chalbiRapport PFE faten_chalbi
Rapport PFE faten_chalbi
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Rapport de stage pfe odoo 8
Rapport de stage pfe odoo 8 Rapport de stage pfe odoo 8
Rapport de stage pfe odoo 8
 
Mise en-place-d-une-gestion-electronique-de-document
Mise en-place-d-une-gestion-electronique-de-documentMise en-place-d-une-gestion-electronique-de-document
Mise en-place-d-une-gestion-electronique-de-document
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
 
Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étude
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'études
 
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
 
Conception et réalisation d’un robot de supervision : acquisition et échange ...
Conception et réalisation d’un robot de supervision : acquisition et échange ...Conception et réalisation d’un robot de supervision : acquisition et échange ...
Conception et réalisation d’un robot de supervision : acquisition et échange ...
 
Page de garde
Page de gardePage de garde
Page de garde
 
Présentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobilePrésentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobile
 
Présentation PFE Hachem Selmi et Ahmed Dridi Big data
Présentation PFE Hachem Selmi et Ahmed Dridi Big data Présentation PFE Hachem Selmi et Ahmed Dridi Big data
Présentation PFE Hachem Selmi et Ahmed Dridi Big data
 
Projet de Fin d'études
Projet de Fin d'études Projet de Fin d'études
Projet de Fin d'études
 
Rapport projet conception et la réalisation d'une application web gestion des...
Rapport projet conception et la réalisation d'une application web gestion des...Rapport projet conception et la réalisation d'une application web gestion des...
Rapport projet conception et la réalisation d'une application web gestion des...
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFE
 

En vedette

Le problème de voyageur de commerce: algorithme génétique
Le problème de voyageur de commerce: algorithme génétiqueLe problème de voyageur de commerce: algorithme génétique
Le problème de voyageur de commerce: algorithme génétique
Rima Lassoued
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
Oussama Djerba
 
Chapitre 4 heuristiques et méta heuristiques
Chapitre 4 heuristiques et méta heuristiquesChapitre 4 heuristiques et méta heuristiques
Chapitre 4 heuristiques et méta heuristiques
Sana Aroussi
 
Expérimentation véhicules électriques infini drive erdf
Expérimentation véhicules électriques infini drive erdfExpérimentation véhicules électriques infini drive erdf
Expérimentation véhicules électriques infini drive erdf
Interconsulaire 909
 
Mapotempo
MapotempoMapotempo
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrierGestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
HORIYASOFT
 
Conception et développement d’un Système de réservation en ligne
Conception et développement d’un Système de réservation en ligneConception et développement d’un Système de réservation en ligne
Conception et développement d’un Système de réservation en ligne
Aydi Nébil
 
Algorithme génétique
Algorithme génétiqueAlgorithme génétique
Algorithme génétique
Ilhem Daoudi
 
expocision de funciones
expocision de funciones expocision de funciones
expocision de funciones
Arturo Gutierrez Ramos
 
El exito
El exitoEl exito
Características enfoques de investigacion
Características enfoques de investigacionCaracterísticas enfoques de investigacion
Características enfoques de investigacion
Mmgpantoja
 
Análisis de un proyecto parte I
Análisis de un proyecto  parte IAnálisis de un proyecto  parte I
Análisis de un proyecto parte I
AlexitaMx
 
Cómo crear una cuenta de blogger
Cómo crear una cuenta de bloggerCómo crear una cuenta de blogger
Cómo crear una cuenta de blogger
laojerosa
 
Proyecto artesanal
Proyecto  artesanalProyecto  artesanal
Proyecto artesanal
shanned
 
Protocolo de investigación
Protocolo de investigaciónProtocolo de investigación
Protocolo de investigación
Elizabeth Ggutierrez
 
Tiempos en frances por silvia carrera
Tiempos en frances por silvia carreraTiempos en frances por silvia carrera
Tiempos en frances por silvia carrera
chivaverito
 
En griego Sophoklës. Poeta griego (Colona, entre 496 y 494−Atenas 406 a.d.C.)
En griego Sophoklës. Poeta griego (Colona, entre 496 y 494−Atenas 406 a.d.C.)En griego Sophoklës. Poeta griego (Colona, entre 496 y 494−Atenas 406 a.d.C.)
En griego Sophoklës. Poeta griego (Colona, entre 496 y 494−Atenas 406 a.d.C.)
Panadero Toplero
 
Caso enron
Caso enronCaso enron
Caso enron
26051991jimena
 

En vedette (20)

Le problème de voyageur de commerce: algorithme génétique
Le problème de voyageur de commerce: algorithme génétiqueLe problème de voyageur de commerce: algorithme génétique
Le problème de voyageur de commerce: algorithme génétique
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
ERP Universitaire
ERP UniversitaireERP Universitaire
ERP Universitaire
 
Chapitre 4 heuristiques et méta heuristiques
Chapitre 4 heuristiques et méta heuristiquesChapitre 4 heuristiques et méta heuristiques
Chapitre 4 heuristiques et méta heuristiques
 
Expérimentation véhicules électriques infini drive erdf
Expérimentation véhicules électriques infini drive erdfExpérimentation véhicules électriques infini drive erdf
Expérimentation véhicules électriques infini drive erdf
 
Mapotempo
MapotempoMapotempo
Mapotempo
 
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrierGestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
 
Conception et développement d’un Système de réservation en ligne
Conception et développement d’un Système de réservation en ligneConception et développement d’un Système de réservation en ligne
Conception et développement d’un Système de réservation en ligne
 
Algorithme génétique
Algorithme génétiqueAlgorithme génétique
Algorithme génétique
 
expocision de funciones
expocision de funciones expocision de funciones
expocision de funciones
 
El exito
El exitoEl exito
El exito
 
Características enfoques de investigacion
Características enfoques de investigacionCaracterísticas enfoques de investigacion
Características enfoques de investigacion
 
Análisis de un proyecto parte I
Análisis de un proyecto  parte IAnálisis de un proyecto  parte I
Análisis de un proyecto parte I
 
Cómo crear una cuenta de blogger
Cómo crear una cuenta de bloggerCómo crear una cuenta de blogger
Cómo crear una cuenta de blogger
 
Proyecto artesanal
Proyecto  artesanalProyecto  artesanal
Proyecto artesanal
 
Protocolo de investigación
Protocolo de investigaciónProtocolo de investigación
Protocolo de investigación
 
Tiempos en frances por silvia carrera
Tiempos en frances por silvia carreraTiempos en frances por silvia carrera
Tiempos en frances por silvia carrera
 
En griego Sophoklës. Poeta griego (Colona, entre 496 y 494−Atenas 406 a.d.C.)
En griego Sophoklës. Poeta griego (Colona, entre 496 y 494−Atenas 406 a.d.C.)En griego Sophoklës. Poeta griego (Colona, entre 496 y 494−Atenas 406 a.d.C.)
En griego Sophoklës. Poeta griego (Colona, entre 496 y 494−Atenas 406 a.d.C.)
 
Caso enron
Caso enronCaso enron
Caso enron
 
Réalisation
RéalisationRéalisation
Réalisation
 

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

Implémentation de la QoS au sein d'un IP/MPLS - Rapport
Implémentation de la QoS au sein d'un IP/MPLS - RapportImplémentation de la QoS au sein d'un IP/MPLS - Rapport
Implémentation de la QoS au sein d'un IP/MPLS - Rapport
Rihab Chebbah
 
Génération automatique de questions à partir de textes en français
Génération automatique de questions à partir de textes en françaisGénération automatique de questions à partir de textes en français
Génération automatique de questions à partir de textes en français
louisdv
 
Conception et implémentation d'un nouveau langage de programmation
Conception et implémentation d'un nouveau langage de programmationConception et implémentation d'un nouveau langage de programmation
Conception et implémentation d'un nouveau langage de programmation
Aymen Bouein
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Yosra ADDALI
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
nesrine haloui
 
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Rim ENNOUR
 
Rapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdfRapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdf
RihabBenSalem5
 
2009 these servant (1)
2009 these servant (1)2009 these servant (1)
2009 these servant (1)
bessem ellili
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Yasmine Lachheb
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
Adem Amen Allah Thabti
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Houssem Eddine Jebri
 
Mémoire.pdf
Mémoire.pdfMémoire.pdf
Mémoire.pdf
MOHAMEDAITBLAL
 
Mr phd thesis
Mr phd thesisMr phd thesis
Mr phd thesis
AbirHezzi
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
fehmi arbi
 
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdfRapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
JihenBenfredj
 
courspython3.pdf
courspython3.pdfcourspython3.pdf
courspython3.pdf
Dendouga1
 
Maaouia Hamza Rapport de stage
Maaouia Hamza Rapport de stageMaaouia Hamza Rapport de stage
Maaouia Hamza Rapport de stage
Maaouia Hamza
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 

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

Implémentation de la QoS au sein d'un IP/MPLS - Rapport
Implémentation de la QoS au sein d'un IP/MPLS - RapportImplémentation de la QoS au sein d'un IP/MPLS - Rapport
Implémentation de la QoS au sein d'un IP/MPLS - Rapport
 
Génération automatique de questions à partir de textes en français
Génération automatique de questions à partir de textes en françaisGénération automatique de questions à partir de textes en français
Génération automatique de questions à partir de textes en français
 
Conception et implémentation d'un nouveau langage de programmation
Conception et implémentation d'un nouveau langage de programmationConception et implémentation d'un nouveau langage de programmation
Conception et implémentation d'un nouveau langage de programmation
 
Memoire_final
Memoire_finalMemoire_final
Memoire_final
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
 
Rapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdfRapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdf
 
2009 these servant (1)
2009 these servant (1)2009 these servant (1)
2009 these servant (1)
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Mémoire.pdf
Mémoire.pdfMémoire.pdf
Mémoire.pdf
 
Mr phd thesis
Mr phd thesisMr phd thesis
Mr phd thesis
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
 
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdfRapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
 
courspython3.pdf
courspython3.pdfcourspython3.pdf
courspython3.pdf
 
Maaouia Hamza Rapport de stage
Maaouia Hamza Rapport de stageMaaouia Hamza Rapport de stage
Maaouia Hamza Rapport de stage
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 

Plus de Slimen Belhaj Ali (18)

BPMN,jBPM,BPEL
BPMN,jBPM,BPELBPMN,jBPM,BPEL
BPMN,jBPM,BPEL
 
Websphere
WebsphereWebsphere
Websphere
 
Sécurisation des services WCF avec WS-Security
Sécurisation des services WCF avec WS-SecuritySécurisation des services WCF avec WS-Security
Sécurisation des services WCF avec WS-Security
 
JasperReport
JasperReportJasperReport
JasperReport
 
JSF 2.0
JSF 2.0JSF 2.0
JSF 2.0
 
Tutorial
TutorialTutorial
Tutorial
 
Spring security
Spring securitySpring security
Spring security
 
Spring mvc 3.0 web flow
Spring mvc 3.0 web flowSpring mvc 3.0 web flow
Spring mvc 3.0 web flow
 
Share point 2010
Share point 2010Share point 2010
Share point 2010
 
TFS
TFSTFS
TFS
 
objective C
objective Cobjective C
objective C
 
Android
AndroidAndroid
Android
 
Hibernate 3
Hibernate 3Hibernate 3
Hibernate 3
 
WPF MVVM
WPF MVVMWPF MVVM
WPF MVVM
 
Jboss Seam
Jboss SeamJboss Seam
Jboss Seam
 
Google appengine&guice
Google appengine&guiceGoogle appengine&guice
Google appengine&guice
 
Sonar-Hodson-Maven
Sonar-Hodson-MavenSonar-Hodson-Maven
Sonar-Hodson-Maven
 
Administration glassfish 3
Administration glassfish 3Administration glassfish 3
Administration glassfish 3
 

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

  • 2. 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
  • 3. 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
  • 4. 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.
  • 5. 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
  • 6. 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'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
  • 7. 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
  • 8. TABLE DES MATIÈRES viii Conclusion générale 50 Bibliographie 52 A Réalisation de la carte graphique de grand Tunis 54
  • 9. 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
  • 10. 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
  • 11. 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
  • 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-
  • 13. INTRODUCTION GÉNÉRALE 2 port exibles et ecaces répondant aux préoccupations actuelles relatives à l'économie et à notre qualité de vie.
  • 14. 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
  • 15. 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.
  • 16. 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 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
  • 17. CHAPITRE 1. ETAT D'ART 6 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.
  • 18. 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ô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.
  • 19. 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ç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) !
  • 20. 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 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
  • 21. 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 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
  • 22. CHAPITRE 1. ETAT D'ART 11 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
  • 23. CHAPITRE 1. ETAT D'ART 12 à 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.
  • 24. 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 recherche taboue que nous avons choisie pour les performances qu'elle présente comparées aux autres heuristiques.
  • 25. 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.
  • 26. 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
  • 27. 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 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
  • 28. CHAPITRE 2. ETUDE THÉORIQUE 17 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
  • 29. 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 des 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
  • 30. CHAPITRE 2. ETUDE THÉORIQUE 19 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 2.1.4 Formulation mathématique du problème de tournées des 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
  • 31. CHAPITRE 2. ETUDE THÉORIQUE 20 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
  • 32. CHAPITRE 2. ETUDE THÉORIQUE 21 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.
  • 33. 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 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.
  • 34. 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 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
  • 35. 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 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.
  • 36. CHAPITRE 2. ETUDE THÉORIQUE 25 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.
  • 37. 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.
  • 38. 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
  • 39. CHAPITRE 3. ETUDE CONCEPTUELLE 28 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
  • 40. 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 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...
  • 41. 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 nombre des véhicules dans le PTV passe de 1 à plusieurs.
  • 42. 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 pour PTV à capacités le client possède une quantité et l'attribut capacité de la classe Véhicule va avoir une valeur nie.
  • 43. 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 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).
  • 44. 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 rassembler ensemble dans un seul diagramme, en cherchant des propriétés communes entre eux.
  • 45. 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 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.
  • 46. 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'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
  • 47. 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 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.
  • 48. 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 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.
  • 49. 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
  • 50. 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]
  • 51. 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 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-
  • 52. CHAPITRE 4. RÉALISATION 41 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
  • 53. CHAPITRE 4. RÉALISATION 42 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
  • 54. 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 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.
  • 55. 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 (é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é.
  • 56. 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. 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.
  • 57. 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 • 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
  • 58. 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 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
  • 59. CHAPITRE 4. RÉALISATION 48 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
  • 60. CHAPITRE 4. RÉALISATION 49 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.
  • 61. 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
  • 62. 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.
  • 63. 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.
  • 64. 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.
  • 65. 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. • 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
  • 66. 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