Jflesch.kwain.net

Description

LO43 est une des UVs (Unité de Valeur) proposée par l'UTBM. Il s'agit d'une UV d'initiation à la programmation orienté objet. Comme pour les deux tiers des UVs d'informatique de l'UTBM, il nous a été demandé de réaliser, en binôme, un projet.

Sujet du projet:
Programmer, en Java, une simulation d'un réseau de bus (simulation au sens animation mais en respectant les vrais timings) fonctionnant notamment sous Windows.
Pour cela, différents projets réalisés par des étudiants ayant fait LO43 les semestres précédents nous étaient fournis. La plupart implémentait juste la création d'un réseau et une recherche d'itinéraire basique (relativement inutile en plus, puisqu'elle demandait l'heure de départ à l'utilisateur, et non l'heure d'arrivée). L'un d'entre eux implémentait déjà un début de simulation (ne respectant notamment pas les horaires).
Les réseaux sont sensés être tracés sur des cartes (--> image de fond).

Binôme:
Anderson David.

Réalisation

1. Faire une frayeur au prof: Lui dire que tout les codes sources de projets précédents sont illisibles, faits par des windowsiens avec des retours à la ligne coincoin, des indentations foireuses / aléatoires, mal documentés, avec des noms de variables dépassant rarement deux lettres, etc, le tout ayant été mal architecturé (bon ok, j'admets, c'est un peu exagéré et méchant pour les étudiants en question). Tout ça pour finalement lui annoncer fièrement qu'on va tout refaire (là le monsieur se dit qu'on finira pas avant 2012).
2. Définir grosso modo une architecture: On a décidé de faire classique, et de faire du MVC, même si David et moi ne semblions pas d'accord sur certains points du MVC, m'enfin.
3. Se répartir le travail: David s'est occupé de la partie Modèle, et moi de la partie Vue et Contrôleur
4. Se pointer un ou deux TP plus tard avec un début d'interface graphique et un début de réseau, histoire notamment de rassurer le prof.
5. Pour ma part: Sacrifier une à deux semaines de vacances à bosser comme un sauvage pour rendre l'interface la plus fonctionnelle possible et pour avoir un système de chargement / sauvegarde de réseau efficace.

Résultat

On a majoré \o/.
Enfin, en fait, on a supposé avoir majoré quand on a vu le prof cocher toutes les cases de sa grille d'évaluation (sauf celles pour le rapport, on était à la bourre de ce coté là) et nous dire ensuite qu'il pense éventuellement refiler ce projet aux étudiants du semestre prochain.

Plus précisément, ce qu'on a réussi:

• Interface relativement claire (plus claire que pas mal d'autres projets)
• Simulation opérationnelle
• Prise en charge, sur les itinéraires, des vitesses des véhicules (par segments), et des temps de pauses aux stations
• On peut simuler aussi bien des bus, que trains, des métros, ou des tramways
• Différentes recherches de chemins sont possibles. Le résultat est surligné sur la carte, et un cadre à droite de la fênetre affiche de manière textuelle l'itinéraire.
• Possibilité de nommer les stations
• Possibilité de choisir la couleur de chaque ligne
• Chargement / Sauvegarde dans un format basé sur XML
• Système de log basé sur log4j. Les logs sont aussi reportés dans une console interne au programme
• Pas un seul popup dans tout le programme, à part les dialogues de chargement / enregistrement de fichier (et encore, est-ce vraiment des popups?). Oui, je les déteste.

Là où on s'est raté:

• Les heuristiques de David pour la recherche de chemin ne semblaient pas très au points :) (1 sur 3 semble marcher). Maj: Apparemment David, dans un moment d'égarement, a utilisé l'opérateur == au lieu de la méthode equals()
• Les accents broient. Conclusion, la prochaine fois on utilisera Ant et on spécifiera le charset utilisé au compilateur
• Je ne suis pas certain qu'on ait respecté exactement le modèle MVC. Maj: Après re-discusion avec David, on n'a pas du tout respecté le modèle MVC (c'est notamment la vue qui prend en charge les actions de l'utilisateur alors que normalement c'est l'un des principaux rôles de la partie Contrôleur)
• Pas de DocType pour le XML

Note:
Le script d'éxecution comprend une rustine pour permettre l'éxecution du programme sur les AMD64 sous Linux. Apparamment cette rustine n'est plus nécessaire avec les dernières versions de Swing, mais je l'ai laissé.

Téléchargement

Rapport + sources du projet