TER – Projet de Génie Logiciel

Réalisation d’un prototype de simulation d’un système de navigation (GPS-Like)

L’objectif de ce projet est de réaliser un prototype capable de guider le conducteur d’un véhicule qui souhaite se rendre d’une ville à une autre et qui peut exprimer des préférences sur le trajet à suivre (le plus court, le plus rapide…). On souhaite guider l’utilisateur durant son trajet, en le conseillant s’il se trompe de chemin. Le système n’est pas équipé d’une antenne GPS, c’est donc l’utilisateur qui indiquera le lieu où il se trouve.

Description du réseau

Le réseau routier est formé d’un ensemble de villes et de routes qui les relie. Chaque ville est caractérisée par son nom, par le fait qu’elle possède ou non des atouts touristiques et par sa taille (grande, moyenne, petite). Chaque route a un classement (elle peut être départementale, nationale, autoroute…) et un nom (N7, A6..). Elle est décomposée en tronçons : sur chaque tronçon, une route a une vitesse maximum autorisée, on peut savoir si des radars y sont présents. Un tronçon possède également une taille, exprimée en kilomètres et possède ou non des attraits touristiques.

Itinéraire

Lorsque le conducteur fait une demande d’itinéraire, il doit obligatoirement indiquer une ville de départ et une ville d’arrivée. Il peut, en outre, exprimer un certain nombre de préférences :

• Spécifier les villes intermédiaires (en nommant ces villes) à suivre ou à éviter ou indiquer le type de villes intermédiaires (grosses ville, villes touristiques…) à suivre ou à éviter ;
• Spécifier les caractéristiques (type de route, avec/sans radar, vitesse…) des routes à suivre ou à éviter ;
• Choisir le chemin le plus court (en kilomètres) ou le plus rapide (en temps).

Toute combinaison de ces préférences doit pouvoir être prise en compte.

Déroulement d’une simulation

Une fois que le conducteur a fait sa demande d’itinéraire, le système lui renvoie le premier trajet possible (à vous de choisir comment sélectionner un trajet parmi plusieurs si plusieurs trajets sont possibles). Ensuite, la simulation débute : le système indique au conducteur la prochaine étape du trajet puis il le questionne pour savoir si cette étape a été atteinte. Deux cas de figure peuvent alors se produire :

• Si le conducteur est bien arrivé à l’étape, celui-ci répond OUI et le système pose sa question pour l’étape suivante.
• Si le conducteur s’est perdu, celui-ci répond NON et le système doit le guider pour rattraper son erreur. Dans ce cas :
• Le système demande à l’automobiliste d’indiquer la prochaine ville vers laquelle il se dirige.
• Le système doit alors proposer à l’utilisateur un nouvel itinéraire (en « rattrapant » l’itinéraire initial ou en changeant d’itinéraire si besoin).

Ce nouvel itinéraire doit au maximum respecter les préférences de l’utilisateur. Si certaines d’entres elles ne peuvent plus l’être (par exemple "impossible d'éviter les radars"), l’utilisateur doit en être informé.

La simulation s’arrête lorsque la ville destination est atteinte.

Entrées / Sorties

Les cartes que vous aurez à charger dans votre système auront toutes le même format XML (cf ANNEXE I). Pour faire simple, il n'y aura que trois types de routes (Autoroute, Nationale et Départementale) et trois tailles de villes ( Petite, Moyenne et Grande).
Il est impératif que votre système soit capable de charger ce format. Les fichiers de cartes pourront avoir plusieurs ordres de grandeur (de quelques kilo-octets à un giga). Votre système ne doit pas être obligatoirement capable de tous les lire et les traiter.

Afin de simplifier le test de votre algorithme de calcul par un agent extérieur, il vous est demandé de concevoir un format XML de requêtes, que votre système sera capable de lire et de traiter. Ce format doit permettre de spécifier :

• Le fichier XML de carte dans laquelle doit se dérouler la ou les recherche(s) d'itinéraire
• Une ou plusieurs recherches d'itinéraires, dans lesquelles devront apparaitre :
  • Les villes de départ et d'arrivée
  • La possibilité de spécifier l'ensemble des paramètres d'itinéraires accessibles depuis votre interface graphique

Vous devrez donner à votre encadrant une commande système permettant de lancer votre programme sans l'interface graphique.
Exemple : java nom_projet fichier_requete.xml

A chaque exécution de votre(vos) algorithme(s) de Plus Court Chemin, que ce soit en fonctionnement normal ou via un fichier XML de requête, vous devrez générer un fichier qui décrit le meilleur itinéraire, sur le modèle donné en ANNEXE II.

Développement

Le logiciel devra être écrit en JAVA à partir d’une modélisation UML.

On vous demande de réfléchir aux interfaces du système, afin de les rendre les plus agréables et ergonomiques possibles.

Le réseau routier (entrées du logiciel) vous est communiqué sous la forme d’un document XML (extrait en annexe).

Attention : Vous devez être en mesure de réaliser la démonstration finale dans les locaux du PUIO (sans installation spécifique de la part de l’équipe système).

Planning et détails des rendus

Dès le début du projet, vous devez former des groupes de 2 ou 3 personnes, désigner un chef de projet, un responsable des archives et prévoir un planning précis des rendus (et vous y tenir !).

Trois rendus sont attendus, destinés à trois commenditaires : Votre encadrant, votre commanditaire (l'entreprise qui va commercialiser votre produit) et les utilisateurs finaux de vore système (les conducteurs). Vous trouverez >> ici << des conseils de rédaction et de présentation.

1. Analyse UML, destinée au commanditaire

• Diagrammes de classes
• Diagrammes des cas d’utilisation
• Diagrammes de séquence
  
  
• Un document présentant les principaux choix de modélisation.

On ne vous demande pas d’être exhaustifs pour les deux derniers diagrammes mais de choisir des cas d’utilisation et des diagrammes de séquence pertinents pour le logiciel.

2. Conception

• Description de l’algorithme de calcul (et re-calcul) de l’itinéraire, écrit en pseudo-code
• Description justifiée du format XML de requêtes
• Diagrammes UML mis à jour
• Squelette de code, sous la forme d'une Javadoc (à faire en dernier)
• Un document décrivant votre environnement de développement (génération de code ?, IDE, librairies graphiques …)
  
  
• Un manuel utilisateur, qui constituera un document à part et qui est destiné aux utilisateurs finaux

3. Rendu final, destiné à votre encadrant

• Diagrammes UML mis à jour (on ne vous demande pas de représenter les classes liées aux interfaces graphiques).
• Document de test décrivant la stratégie d’intégration des classes (définition des incréments d’intégration), les tests fonctionnels des principaux modules du logiciel (avec le résultat de leur exécution).
  
  
• Un manuel utilisateur final, destiné aux utilisateurs finaux
• Vous enverrez par email (nancel@lri.fr) l’ensemble de vos sources ainsi que l’ensemble de vos fichiers de tests.

Le rendu final aura lieu au cours de la dernière semaine d'Avril.

La soutenance finale aura lieu au cours de la première semaine de Mai.

Annexe I : Fichier XML pris en entrée (exemple à télécharger)

Annexe II : Fichier XML requis en sortie (exemple à télécharger)

Annexe III : Exemples de cartes. Le titre indique le nombre de villes (v), de tronçons (t), de routes (r), et si le graphe est complet.

Sujet de Sarah Cohen-Boulakia repris par Mathieu Nancel - 2008/2009
nancel@lri.fr