Projet Java : Simulateur de vol

Projet Java : Simulateur de vol
Ocan Sankur & Guillaume Scerri
15 février 2013
1
Implémentation
Ce projet consiste en l'implémentation d'un planicateur de vol. Il devra comprendre deux
composantes principales, un simulateur qui devra simuler les vols de avions et un contrôleur
qui devra décider des trajectoires à suivre pour les avions, ainsi que de leurs dates de départ
et d'arrivée.
1.1
Le simulateur
Le simulateur devra simuler le vol d'un certain nombre d'avions en temps réel.
D'une part, il agira comme un simulateur du monde physique en mettant à jour la trajectoire des avions en fonction des conditions météorologiques données. Il maintiendra également
des données globales comprenant la position et le statut des aéroports. Les données globales se
trouvent dans un objet
GlobalData, et le simulateur, étant un simulateur du monde physique,
a accès complet à cet objet (contrairement au contrôleur, voir plus loin).
D'autre part, il simulera la communication entre les avions et le contrôleur. Pour ce faire,
il implémentera l'interface SimulatorCommandInterface dénie dans le diagramme UML en
annexe. Cette interface sera utilisée par le contrôleur pour communiquer avec les avions. Elle
contient des requêtes par exemple sur la trajectoire, la vitesse, le status des avions. Ainsi,
l'appel d'une de ces méthodes par le contrôleur correspond à l'envoie d'un message (par radio)
à un avion.
Par ailleurs, c'est le simulateur qui décidera, selon un scénario donné, la création de nouveaux vols et leur fréquence. Pour ce rôle, il fera des requêtes auprès du contrôleur pour créer
des nouveaux vols et pour demander des autorisations décollage et d'atterrissage. L'appel de
ces méthodes-là correspond encore à l'envoie d'un message par un avion au contrôleur.
Vous remarquerez que toutes les méthodes de requêtes dans l'interface SimulatorCommandInterface sont de type de retour
void. En eet, le but est de simuler une communication
asynchrone, où la réponse à la requête n'est pas immédiate. Ainsi, (plus tard dans le projet)
certains avions pourraient disparaître (disons, dans le triangle des Bermudes) et ne revenir
que plus tard.
La classe
points
l
Trajectory
dénit la trajectoire des avions. Elle est composée d'une liste de
(formant une suite de segments) et d'une date
d.
Il est supposé que l'avion est au
d. Pour le simulateur, faire évoluer l'avion entre d et
d + dt consiste en calculer la position de l'avion à t + dt sachant qu'il était au premier point de
l à la date d puis à modier la trajectoire en celle commençant et d + dt. Quand le contrôleur
premier point de la trajectoire à la date
modie la trajectoire d'un avion, le premier point de la trajectoire modiée reste la position
actuelle de l'avion, la trajectoire prévue par le contrôleur est ensuite concaténée à ce point.
1
t
t + dt
Figure 1 À gauche, l'évolution d'une trajectoire entre les temps t et t + dt. À droite, un
changement de trajectoire (demandé par le contrôleur) au temps
t.
L'avion se dirige vers le
point de départ de la nouvelle trajectoire (dessiné en pointillé).
1.2
Le contrôleur
Le contrôleur devra répondre aux requêtes de décollage et d'atterrissage des diérents
avions, décider des trajectoires à suivre et gérer les événements exceptionnels pouvant se
produire (nous ne considérerons pas d'événements exceptionnels dans la première partie du
projet). Il implémentera l'interface ControlerCommandInterface dénie dans le diagramme
UML en annexe. Comme pour le simulateur, cette interface correspond à la communication
entre le contrôleur et les avions. Ainsi, le contrôleur agit comme une tour de contrôle globale :
il décide des trajectoires et résoud les conits.
Vous devrez implémenter trois (dont un optionnel) types de contrôleurs diérents.
Un contrôleur graphique où l'utilisateur prendra les décisions de réponse aux diérentes
requêtes, (entre autres choisira la trajectoire). Il est attendu de ce contrôleur graphique
soit simple d'utilisation. Vous pouvez donner à l'utilisateur le choix d'automatiser ou
non certaines décisions, comme le choix de la trajectoire, l'ordre d'atterrissage etc.
Un contrôleur automatique qui choisira les trajectoires et réponses aux diverses requêtes
an de minimiser le temps de vol et d'attente des diérents avions.
Bonus :
Un contrôleur réseau qui devra pouvoir déléguer ses requêtes à une autre
machine en réseau local avec la machine sur laquelle il s'exécute et transmettre les
réponses à ces requêtes au simulateur. Il est attendu que la partie distante et la partie
locale de ce contrôleur soient implémentées.
Suivant la même logique qu'avec le simulateur, l'interface de communication du contrôleur sera
implémentée comme une communication asynchrone. Le contrôleur n'aura donc pas accès libre
sur les données des avions, mais devra passer par l'interface
SimulatorCommandInterface du
simulateur pour y accéder. Il aura également accès aux données sur les aéroports à travers
l'interface
ControllerDataInterface. Celle-ci est une vue limitée pour un objet GlobalData,
qui cache certaines informations physiques sur les aéroports ; celles-là devront être obtenues
par une communication avec le simulateur.
2
Déroulement du projet
2.1
Organisation
Le projet se fera par groupe de 3 personnes (si le nombre de participants n'est pas divisible
par 3 il sera possible de faire un groupe de cardinal diérent). Vous devez nous informer de
vos choix de groupe au plus tard le 22 février prochain. Le projet se fera en deux phases :
1ère phase se nissant le
5 avril
: implémentation de la partie décrite ici. Il vous sera
demandé de rendre un rapport pour cette première partie.
2
2ème phase se nissant le
27 mai
: implémentation d'un extension de la spécication
donnée ici (attention à faire du code facilement réutilisable pour éviter d'avoir à tout
reprendre du début !). Il vous sera demandé de rendre un rapport nal, et une soutenance
sera organisée.
Il vous est également demandé d'utiliser un gestionnaire de version tel que git ou svn pour ce
projet. Vous devrez nous donner l'accès (en lecture) à votre repository avant le 27 février.
Il est conseillé d'appliquer des tests systématiques pendant et après le développement
de votre logiciel. Une bonne idée est d'utiliser les tests unitaires, qui consistent à écrire des
générateurs et validateurs de tests séparément pour chaque module (c-à-d classe ou ensemble
de classes qui réalise un tâche). Ces tests permettent de s'assurer, après une modication,
que les diérentes modules ont toujours le bon comportement individuellement. Une fois une
première version du projet accompli, il faudra faire des tests d'intégration où vous testerez le
comportement de l'ensemble du logiciel. En général, il faudra inventer des scénarios simples
et diciles et écrire des générateurs qui créent ces scénarios. Il est recommendé d'inclure dans
1
votre projet les programmes qui réalisent les tests .
2.2
Ressources
Les classes générées par le diagramme UML en annexe sont disponibles sur la page du
cours.
Un serveur ssh avec git et svn est disponible à l'adresse suivante :
ens-cachan.fr
repository.dptinfo.
Le diagramme UML est généré avec TopCoder UML Tool, un tel outil pourrait vous
être utile pour vos rapports ou pour générer du code.
3
Évaluation et rapports
Vos rapports (partiel et nal) devront comprendre au moins les trois choses suivantes :
Qui a fait quoi sur le projet : cela doit être cohérent avec l'historique du gestionnaire de
version.
Un javadoc documentant votre code. Vous soignerez particulièrement la documentation
des parties susceptibles d'être réutilisées (dans la suite du projet, ou bien dans une
nouvelle version ctive du logiciel). Vous pouvez prendre l'exemple sur le Java API :
aucun élément superu n'apparaît dans la doc, le rôle de chaque méthode est clairement
décrit.
Une justication de vos choix de design et d'implémentation. Ainsi, vous pouvez argumenter par exemple sur la gestion de la concurrence, la séparation entre traitement de
données et le contrôle (GUI ou autre).
La méthodologie de test. Vous présenterez des arguments en faveur de la correction de
votre logiciel. Comment l'avez-vous testé ? Quelles sont les limites de performance ?
Et toute autre information que vous jugez utile sera la bienvenue dans ce rapport.
La première évaluation portera sur la qualité de votre rapport, ainsi que sur la clarté, la
réutilisabilité et la concision du code que vous aurez produit.
Si vous avez des questions n'hésitez pas à nous contacter par mail.
1. On peut envisager de faire un petit TP pour présenter ces approches.
3
4