Jsu Jets Projets Java

Projets Java – Intitulés
Hugues Mounier
R ÉSUM É . Ce document comporte les parties suivantes. Une partie contenant les desciptifs brefs
des énoncés. Une partie avec le squelette des sections présentes dans un énoncé détaillé. Une
partie fournissant les énoncés détaillés.
A – Brefs descriptifs des projets

Projet n◦ 1 : Régulation de traffic dans les réseaux haut débit
Au sein d’un réseau, tous les utilisateurs – ou tous les couples (source, destination) –
sont contraints de se partager les ressources finies en bande passante aux diférents liens et
en taille de tampons mémoire des routeurs.
L’objectif est ici d’implanter des politiques d’allocation dynamique de bande passante
à chaque couple (source, destination) de façon à assurer une utilisation optimale de la
bande passante totale tout en évitant le débordement (ou congestion) des tampons mémoire
des différents routeurs. Les évolutions temporelles des tampons mémoire (en nombre de
paquets) sont prises comme trajectoires et l’état idéal de fonctionnement du réseau est
représenté par le suivi de ces trajectoires.
Un modèle simple de réseau à partir de briques de bases est fourni, ainsi qu’une poli-
tique de spécification des débits aux différents noeuds du réseau qui assure le suivi des
trajectoires spécifiées à l’avance.
Projet n◦ 2 : Entrainement sportifs

Le but est ici de fournir un générateur d’applications dédiées à l’entrainement à un
sport ou à une activité physique donnée. Différentes parties multimédia, mêlant texte ex-
plicatif, séquences vidéo et sonores doivent permettre un auto-entrainement. L’application
doit être conçue comme une boı̂te à outils permettant de générer ce type d’application,
quelle que soit l’activité physique cible.
Il doit être possible d’effectuer des surimpressions de courbes colorées et de points
colorés en mouvement sur les séquences vidéo. Il devra en outre être possible de zoomer
sur n’importe quelle partie d’une séquence vidéo et de voir la séquence vidéo se poursuivre
1
Projets Java Université Paris Sud
en même temps dans la fenêtre initiale et dans la nouvelle fenêtre contenant la partie
zoomée.
Quelques détailes supplémentaires se trouvent dans la partie détaillé du sujet.
Projet n◦ 3 : Carnet d’adresses distribué dynamique

Il s’agit de gérer un carnet d’adresses distribué, avec possibilité d’e-mail, d’impression
et de fusion de plusieurs carnets.
Projet n◦ 4 : Agenda distribué simple

Chaque acteur a son propre agenda, avec son planning ; il peut : modifier le sien,
consulter celui des autres et être réveillé pour un rendez-vous.
Projet n◦ 5 : Site internet des vins

Un serveur Web sur lequel on donne un cru, et l’on obtient un prix. L’obtention
d’information sera systématiquement graphique ; par exemple, on se trouve devant la
carte de la France et l’on clique su une région. Se retrouvant dans cette région, l’on peut
sélectionner une ou plusieurs sous-régions qui feront l’objet des requêtes suivantes, acces-
sibles à la souris (choix d’un/plusieurs cru(n) parmi n, choix d’un/plusieurs producteur(s),
choix d’un/plusieurs millésime(s), etc.) Des fichiers de son seront associés à chaque de-
scription de cru, avec des séquences vidéo associées (promenenade dans les vignes, dans
les chais, visualisation rapide de la fabrication, etc.)
Projet n◦ 6 : Suivi et gestion de trajectoires de véhicules

On considère le mouvement d’un véhicule et le modèle cinématique associé. Le
véhicule est piloté par la vitesse v de son centre d’inertie et par l’angle de braquage φ
de ses roues avant. On suppose s’être donné une trajectoire pour le point P situé au milieu
de l’essuieu arrière du véhicule. Les lois d’évolution de v et de φ réalisant le suivi de
cette trajectoire seront fournies. Le but de ce projet est de réaliser des outils permettant de
gérer les trajectoires (composition, modification, destruction) et de visualiser le véhicule
suivant une trajectoire.
Projet n◦ 7 : Jeu de vaisseaux spatiaux

Un jeu classique, où plusieurs vaisseaux en réseau peuvent se déplacer en propulsion
et en rotation, peuvent tirer et peuvent se téléporter. Des rochers défilent et une collision
d’un vaisseau sur un rocher fait éclater ce dernier.
2
Projet n◦ 8 : Simulation de porteurs en bourse

L’objet est de simuler la gestion d’actions et d’obligations en bourse, avec des activités
de gestion rattachées aux banques, dans lesquelles chaque client disposera de portefeuilles
de titres. La gestion se fera de manière distante. Interviendront également des gros por-
teurs, qui pourront influer dynamiquement sur le cours des titres, ceci se répercutant sur
le montant des protefeuilles des clients.
Projet n◦ 9 : Évaluation d’algorithmes d’ordonnancement

Le but de ce projet est de créer un mini ordonnanceur d’activités et de pouvoir com-
parer graphiquement divers algorithmes d’ordonnancement. On visualisera quelle activité
occupe le processeur fictif.
Projet n◦ 10 : Flotte d’aéronefs coopératifs

Une flotte de N petits avions autonomes doivent couvrir un territoire donné. La mis-
sion peut être de prendre des photos pour des besoins de cartographie ou de gestion terri-
toriale, de pulvériser de l’engrais, d’effectuer de la surveillance aérienne, etc.
On dispose pour chaque petit avion, d’un modèle simple de dynamique de vol. La
flotte de N avions se voit attribuée une mission au départ, puis au bout d’un temps
indéterminé peut se voir attribué une ou plusieurs autres missions. Chaque mission peut
également être abandonnée en route, par un ou plusieurs des N avions, en cas d’ordre en
ce sens.
Projet n◦ 11 : Dynamique d’avion à décollage vertical

On considère un avion à décollage vertical où la stabilisation de roulis est assurée par
2 réacteurs situés sous les ailes. Le but est ici de faire suivre des trajectoires d’approche,
de décollage et d’aterrissage à l’avion. L’essentiel de la dynamique de vol sera également
considéré et on élaborera une vue de l’avion sous forme synthétique (en synthèse d’images)
Projet n◦ 12 : Gestion concurrente de voies ferrées

L’utilisateur peut construire un trajet de voie ferrée à la souris à l’aide de tronçons
prédéterminés. Plusieurs trains peuvent circuler sur ce trajet. Si deux trains ou plus ar-
rivent sur un tronçon unique de voie ferrée de telle sorte qu’il y ait un risque de colli-
sion, tous les trains sauf un doivent attendre. On pourra également prévoir des gares, des
garages de réparation et des plans horaires pour chaque train.
Projet n◦ 13 : Explorateur d’arborescence distribué et sécurisé

Il s’agit de réaliser un clône de l’explorateur Windows avec possibilité d’explorer des
machines distantes (dont on entre le nom ou l’adresse IP). De plus, l’accès sera contrôlé
3
par des listes de contrôle d’accès (ou ACL, comme “Access Control List”) qui permet
d’obtenir une granularité fine de l’accès.
Projet n◦ 14 : Gestion d’une agence de voyages distribuée

Cette agence de voyages virtuelle doit non seulement être capable d’effectuer des
réservations de vols, mais également d’établir la composition d’un avion et le plan de
vol des pilotes. La composition d’un avion sera disponible sous la forme d’un graphique
interactif, où les places prises et les places disponibles seront différentiées par des codes de
couleur ; en cliquant sur une place, il sera possible d’obtenir – dans le cas où la place a été
réservée – des informations sur la personne ayant effectué la réservation (ces informations
n’étant disponible qu’en accès restreint).
Projet n◦ 15 : Générateur de tâches distribué

Il s’agit de réaliser un démon (programme de service tournant en arrière plan) exécutant
des tâches en différé soit sur la machine locale, soit sur une machine distante. La fréquence
d’exécution des tâches est consignée dans un fichier de configuration, dont on pourra
forcer la relecture dynamiquement. Les démons d’exécution peuvent communiquer de
machine à machine afin de réaliser une tâche distribuée.
Projet n◦ 16 : Simulateur d’algorithme de routage

L’utilisateur pourra composer un réseau à la souris et simuler divers algorithmes de
routage classiques sous Internet. Il devra être possible de visualiser les paquets aux
différents routeurs, de morceler et de réassembler les paquets.
Projet n◦ 17 : Cartographie de site web

Le but de ce projet est de représenter l’arborescence d’un site Web sous forme graphique.
Le site pourra être rapatrié à l’aide de robots automatiques et son contenu analysé ensuite
pour produire l’arborescence.
Projet n◦ 18 : Sonde de tests d’un réseau de serveurs

Le but de ce projet est de tester le fonctionnement d’un réseau de machines, notamment
en ce qui concerne la charge, le nombre de paquets perdus, etc.
La visualisation du fonctionnement d’un réseau de serveurs peut être effectuée à l’aide
d’un logiciel de supervision et de sondes installées sur chaque serveur. La sonde : il
s’agit d’un démon client qui est capable d’effectuer les tests indiqués par le serveur de
supervision.
Ces tests sont soit :
4
• des tests standards de type état de la mémoire, état de la charge, nombre de processus
actifs, zombies...
• le résultat d’un programme envoyé par le serveur

Le serveur de supervision : il connaı̂t l’emplacement de chacune de ses sondes et
dispose d’un fichier de configuration qui lui permet d’interroger les sondes sur des points
précis (tests) à des intervalles de temps précis ou à une date précise.
Le fichier de configuration précise en fonction des résultats des tests s’il faut ou non
faire remonter une erreur.
Le logiciel de supervision représente chacune de ses sondes avec leur état et tient à jour
un historique. En cas de problème il doit être capable d’envoyer un e-mail qui indique la
nature de la panne.
Projet n◦ 19 : Génération de trajectoires avec obstacles

Il s’agit d’implanter des algorithmes d’évitement d’obstacle en robotique mobile par
la méthode des potentiels ou celle des lignes de niveau, avec une visualisation 2D ou en
synthèse d’images 3D.
On fournit des points de départ et d’arrivée à la souris ; on construit également des
obstacles à la souris par combinaison de formes géométriques simples. Cette étape est
réalisée en vue de dessus 2D et en perspective 3D. Ensuite, la génération de trajectoires se
réalise ; puis l’on peut suivre le cheminement du véhicule en vue de dessus et en perspec-
tive 3D.
Projet n◦ 20 : Transfert sûr sous UDP

Créer un protocole au dessus d’UDP réalisant un transfert sûr de données avec contôle
de flux à l’instar de ce qui est réalisé sous TCP. Implanter un mécanisme d’acquittement
de données avec contrôle de flux par fenêtre. Fournir un mode de traçage qui affiche de
manière graphique les accusés de réception, la fenêtre de flux. Fournir un exemple de
service echo.
Numéros de pages des descriptifs détailles de projets

Projet n◦ 1 : Régulation de traffic dans les réseaux haut débit 10
Projet n◦ 2 : Entrainement sportifs 12
Projet n◦ 3 : Carnet d’adresses distribué dynamique 13
Projet n◦ 4 : Agenda distribué simple 14
Projet n◦ 5 : Site internet des vins 16
5
Projet n◦ 6 : Suivi et gestion de trajectoires de véhicules 17

Projet n◦ 7 : Jeu de vaisseaux spatiaux 19
Projet n◦ 8 : Simulation de porteurs en bourse 20
Projet n◦ 9 : Évaluation d’algorithmes d’ordonnancement 22
Projet n◦ 10 : Flotte d’aéronefs coopératifs 23
Projet n◦ 11 : Dynamique d’avion à décollage vertical 25
Projet n◦ 12 : Gestion concurrente de voies ferrées 26
Projet n◦ 13 : Explorateur d’arborescence distribué et sécurisé 27
Projet n◦ 14 : Gestion d’une agence de voyages distribuée 29
Projet n◦ 15 : Générateur de tâches distribué 30
Projet n◦ 16 : Simulateur d’algorithme de routage 32
Projet n◦ 17 : Cartographie de site web 33
Projet n◦ 18 : Sonde de tests d’un réseau de serveurs 34
Projet n◦ 19 : Génération de trajectoires avec obstacles 36
Projet n◦ 20 : Transfert sûr sous UDP 37
6
B – Descriptif d’énoncé générique

Une section qui ne figure pas toujours dans un descriptif d’énoncé est suivie de la mention
optionnel entre parenthèses.
Projet n◦ i : titre du projet

1 Description rapide
Brève description, en moins de 20 lignes, des buts et des caractéristiques principales
du projet.
2 Catégorie d’application : Mots clés de catégorie d’application (5 maximum) : Synthèse
d’images, bases de données, algorithmique, jeu, algorithmique distribuée, traitement d’images,
traitement du signal, automatique, électronique, etc.
3 Technologies Java et structures de données : Les technologies Java mises en oeuvre
sont énumérées, ainsi que les champs requis ou les structures de données à utiliser de
préférence.
4 Déroulement en trois étapes
Chaque projet comporte une réalisation en trois étapes :
(i) L’étape de base représente le minimum exigible. Elle correspond à des fonction-
nalités de base, faciles à implanter.
(ii) L’étape intermédiaire représente une réalisation satisfaisante. Elle correspond à des
fonctionnalités de niveau intermédiaire.
(iii) L’étape avancée représente une excellente réalisation. Elle correspond à des fonc-
tionnalités avancées, éventuellement délicates à mettre en oeuvre.
5 Spécifications de comportement (optionnel)

Ici sont décrits des traits généraux de comportement de la réalisation logicielle.
Des spécifications possibles sont la portabilité, l’utilisation en réseau, le caractère uni-
formément réparti, la tolérance aux pannes, la robustesse, l’autonomie, la flexibilité, la
souplesse de maintenance, d’utilisation, l’ergonomie, etc.
6 Variantes en cas de dédoublement possible (optionnel)
Dans le cas où le projet peut être choisi par plusieurs binômes, on indique combien
de binômes au plus peuvent le choisir. Il y a un sujet de base, qui doit être choisi s’il n’y
a qu’un binôme réalisant le projet et une ou plusieurs variantes, dans le cas de plusieurs
binômes.
7
7 Bibliographie (optionnel)
Une bibliographie éventuelle de documents pouvant être utiles à la réalisation du pro-
jet.
8
C – Énoncés détaillés des sujets

Projet n◦ 1 : Régulation de traffic dans les réseaux haut débit
1.1 Description rapide
Au sein d’un réseau, tous les utilisateurs – ou tous les couples (source, destination) –
sont contraints de se partager les ressources finies en bande passante aux diférents liens et
en taille de tampons mémoire des routeurs.
L’objectif est ici d’implanter des politiques d’allocation dynamique de bande passante
à chaque couple (source, destination) de façon à assurer une utilisation optimale de la
bande passante totale tout en évitant le débordement (ou congestion) des tampons mémoire
des différents routeurs. Les évolutions temporelles des tampons mémoire (en nombre de
paquets) sont prises comme trajectoires et l’état idéal de fonctionnement du réseau est
représenté par le suivi de ces trajectoires.
Un modèle simple de réseau à partir de briques de bases est fourni, ainsi qu’une poli-
tique de spécification des débits aux différents noeuds du réseau qui assure le suivi des
trajectoires spécifiées à l’avance.
1.2 Catégorie d’application : réseaux, contrôle de traffic.
1.3 Technologies Java et structures de données : Java2D (pour le graphisme).
1.4 Déroulement en trois étapes
(i) Étape de base
• Implantation des lois d’évolution de débit et visualisation des courbes de tra-

jectoires spécifiées et d’évolution de débit.
• Élaboration d’une politique de partage simple, analogue au temps partagé d’un
algorithme d’ordonnancement.
• Composition à la souris du réseau à étudier, avec 3 types de blocs : source,
destination et intermédiaire ainsi qu’un type de lien.
• Prévoir au moins les cas :
– de machines sources qui sont susceptibles de démarrer après un certain
temps de repos à partir de l’instant initial ;
– de machines sources susceptibles de s’arrêter après un certain temps de
fonctionnement ;
– de machines destination susceptibles de s’arrêter après un certain temps
de fonctionnement.
(ii) Étape intermédiaire
10
• Composition simple de trajectoires par morceaux, par choix de diverses poli-

tiques de partage (s’inspirer par exemple d’algorithmes d’ordonnancement).
• Ajouter un attribut de retard de transmission fixe (ne dépendant pas du temps)
sur chaque lien.
• Simulation du système dynamique par intégration simple (un Runge-Kutta
d’ordre 4 sera fourni).
Sujet de base : Visualisation de l’évolution le long du réseau. Chaque lien est visualisé par un
tube dans lequel transite un liquide coloré. Chaque couple (source, destination)
se voit attribué une couleur. Le liquide en transit a pour couleur le mélange des
couleurs des différents couples utilisant le lien. Le taux de remplissage du tube
représentant le lien visualise le taux d’occupation de la bande passante totale
du lien. Le taux de remplissage respectif de chaque couple est rappelé par
un vu-mètre de la couleur associée. Les vu-mètres sont situés en dessous des
liens. Cette visualisation doit être disponible après la composition du réseau
de l’étape de base et insérée dans la simulation dynamique précédente.
Variante n◦ 1 : Implanter des lois de débit dites en boucle fermée, permettant de compenser les
légères imperfections de modèle et méconnaissances de conditions initiales.
(iii) Étape avancée
• Implanter les lois de débit avec des retards variables avec le temps, tenant en
particulier compte de la charge des machines intermédiaires.
• Ces implantations doivent être insérées dans la simulation dynamique avec
visualisation par tubes colorés de l’étape intermédiaire.
1.5 Spécifications de comportement

L’accent doit être mis sur la flexibilité des politiques de partage (de nouvelles poli-
tiques doivent pouvoir être ajoutées simplement).
Un autre aspect important est la tolérance aux pannes des différents noeuds ainsi que
la possibilité de fonctionnement en mode dégradé.
1.6 Variantes en cas de dédoublement possible
Il y a une variante possible en réalisation de l’étape intermédiaire.
1.7 Bibliographie
(i) Contrôle de traffic dans les réseaux haut Internet et ATM, H. Mounier, Transparents
séminaire CESAME, université catholique de Louvain, Louvain la neuve, octobre
1999.
(ii) High Speed Network Congestion Control with a simplified Time-varying Delay
Model, H. Mounier, M. Mboup, N. Petit, P. Rouchon et D. Seret, IFAC Conference
System, Structure and Control, Nantes, 1998.
11
(iii) Pour les tracés graphiques, Java2D MonarchCharts et JSci
Projet n◦ 2 : Entrainement sportifs

Le but est ici de fournir un générateur d’applications dédiées à l’entrainement à un
sport ou à une actiité physique donnée. Différentes parties multimédia, mêlant texte expli-
catif, séquences vidéo et sonores doivent permettre un auto-entrainement. L’application
doit être conçue comme une boı̂te à outils permettant de générer ce type d’application,
quelle que soit l’activité physique cible.
Les activités cibles peuvent être très variées (danse, atléthisme, sports nautiques, sports
d’hiver, sports de balles et de ballons, sports de combat, arts martiaux externes et internes,
etc.).
Il doit être possible d’effectuer des surimpressions de courbes colorées et de points
colorés en mouvement sur les séquences vidéo. Par exemple pour un skieur, des courbes
peuvent montrer sur quelles parties du corps il faut pousser pour effectuer telle ou telle
manoeuvre (pour effectuer un virage avec les skis parallèles, il faut rentrer les genoux
vers l’amont et chasser avec l’arrière du pied extérieur vers l’aval, et ce au moment de
l’anticipation et de la fin du virage) ; pour un nageur, des courbes ou des points colorés en
mouvement peuvent indiquer quels sont les mouvements des mains, des pieds et ceux de
l’eau évacuée.
Il devra en outre être possible de zoomer sur n’importe quelle partie d’une séquence
vidéo et de voir la séquence vidéo se poursuivre en même temps dans la fenêtre initiale et
dans la nouvelle fenêtre contenant la partie zoomée.
2.2 Catégorie d’application : multimédia, surimpression d’images vidéo.
2.3 Technologies Java et structures de données : JMF, JDBC (ou dbSwing).
(i) Étape de base
• Outil de génération de documents multimédia à partir d’un document texte au

format HTML, d’iamges fixes (au format GIF, JPEG, etc.) de séquences vidéo
(au format MPEG2, MPEG4, etc.) et de séquences audio (au format ...)
• La génération doit pouvoir se faire à la souris avec insertion possible de texte,
d’images fixes, animées ou de son.
12
• Outil de génération de surimpression de points et de courbes (splines inter-

polantes, passant par divers points de contrôle) sur images fixes.
• Points fixes et courbes surimprimées sur séquences vidéo. On effectuera des
interpolations à partir d’images fixes de la séquence que l’on aura surimprimé.
• Possibilité de zoom et de visualisation simultanée de la séquence initiale et de
la séquence zoomée défilant en parallèle.
• Plusieurs images de zoom simultanées possibles.

• Techniques d’“anti-aliasing”.
• Plusieurs vitesses de défilement d’une séquence vidéo.
• Possibilité de marquage d’une image dans une séquence et de sauter à cette
marque.
• Gestion des marqueurs : création, destruction, aller à la marque suivante/pré-
cédente, écriture et lecture disque.

L’application doit être très flexible par rapport aux techniques de surimpression (il
doit être facile de les modifier et d’en ajouter). L’ergonomie est ici un point crucial ;
l’application doit être très souple et facile à utiliser.
2.6 Bibliographie
(i) La classe Bidi du paquetage text permettant des manipulations et formattages de
texte.
(ii) Des classes de gestion de texte sur images :

http://www.execpc.com/˜larryhr
Projet n◦ 3 : Carnet d’adresses distribué dynamique

Il s’agit de gérer un carnet d’adresses distribué, avec possibilité d’e-mail, d’impression
et de fusion de plusieurs carnets.
3.2 Catégorie d’application : bases de données, application client/serveur.
13
3.3 Technologies Java et structures de données : JDBC (ou dbSwing), RMI.

(i) Étape de base
• Les adresses (ou enregistrements) doivent au moins comporter les champs :

nom, prénom, catégorie (ami, commerçant, artisan, médecin, connaissance
professionnelle, connaissance de loisirs), adresse, digicode, code postal, ville
numéros de téléphone, e-mail, date de dernière modification de l’enregistrement,
remarques.
• Possibilités d’ajouter, de supprimer, de modifier et de visualiser les enreg-
istrements.
• types de visualisation minimum : par ordre alphabétique des noms, par catégorie,
par ville, par code postal. Pour les 3 derniers, tri sur une clé secondaire, le nom.
• Une personne peut faire partie de plusieurs catégories.
• Développement en local à une machine.
• Développement en distribué, avec un serveur concurrent.

• Accès synchronisé à la base assuré par une thread spéciale de gestion.
• Possibilité d’envoyer un e-mail à une personne.
• Plusieurs serveurs correspondant à plusieurs agendas peuvent converser, selon

un protocole que l’on définira, pour réaliser une fusion/mise à jour de 2 bases
d’adresses en une. La fusion correspond à une concaténation.
• La mise à jour prend en compte les dates de dernière modification pour ne
conserver que les enregistrements les plus récents.

L’application doit être parfaitement portable et la plus autonome possible (en partic-
ulier, elle ne doit dépendre d’aucun logiciel extérieur). Les accès aux agendas doivent être
rapides.
14
Projet n◦ 4 : Agenda distribué simple

Chaque acteur a son propre agenda, avec son planning ; il peut : modifier le sien,
consulter celui des autres et être réveillé pour un rendez-vous.
4.2 Catégorie d’application : bases de données légères et coopératives ; applications
distribuées.
4.3 Technologies Java et structures de données : JDBC (ou dbSwing), Properties, RMI.
(i) Étape de base
• Gestion d’agenda en local à une machine. Possibilité de : prise de rendez-vous,
modification, annulation et rappel de rendez-vous.
• La structure d’un enregistrement de rendez-vous devra au minimum comporter
les champs suivants :
– date (jour, semaine, mois) au format par ex. Mardi 21 janvier 1789,
– heure de début,
– heure de fin,
– catégorie de rendez-vous (personnel, professionnel, etc.),
– commentaire de description.
• Possibilité d’ajouter des catégories de rendez-vous.
• Visualisation avec tri par date et heure, par catégorie de rendez-vous (avec
comme clé secondaire la date et l’heure).
• Rappel de rendez-vous par afficahge des date, heure et commentaire en couleur.
• Gestion d’agenda distribuée, avec des RMI. Chaque gestionnaire d’agenda
sera à la fois client et serveur RMI.
• Rappel de rendez-vous par e-mail aux N personnes concernées par le rendez-
vous.
• Chaque utilisateur peut consulter et modifier son agenda, ainsi que consulter
celui des autres.
• Gestion des conflits lors de la prise et de la modification de rendez-vous.
• Fournir un algorithme d’allocation distribué de rendez-vous à partir d’un cer-
tain nombre de rendez-vous à fixer et de diverses contraintes.
15
• Possibilité de fournir des contraintes de la forme :

– pas de rendez-vous le matin (ou l’après-midi),
– pas de rendez-vous tel jour de la semaine.

Il doit y avoir une grande flexibilité par rapport aux catégories de rendez-vous. L’application
doit être portable et “légère” au sens de temps de réponse rapides. Le caractère uni-
formément réparti (c.à.d. sans architecture privilégiant l’une des entités, telle un serveur
et N clients, mais chaque gestionnaire ayant un code similaire) est important. La tolérance
aux pannes est également une caractéristique notable.
Projet n◦ 5 : Site internet des vins

Un serveur Web sur lequel on donne un cru, et l’on obtient un prix. L’obtention
d’information sera systématiquement graphique ; par exemple, on se trouve devant la
carte de la France et l’on clique su une région. Se retrouvant dans cette région, l’on peut
sélectionner une ou plusieurs sous-régions qui feront l’objet des requêtes suivantes, acces-
sibles à la souris (choix d’un/plusieurs cru(n) parmi n, choix d’un/plusieurs producteur(s),
choix d’un/plusieurs millésime(s), etc.) Des fichiers de son seront associés à chaque de-
scription de cru, avec des séquences vidéo associées (promenenade dans les vignes, dans
les chais, visualisation rapide de la fabrication, etc.)
5.2 Catégorie d’application : multimédia, bases de données.
5.3 Technologies Java et structures de données : JDBC (ou dbSwing), JMF, Servlets.
(i) Étape de base
• Gestion de la base de donnée des crus. Cette base devra au minimum com-
porter les champs suivants : région, sous-région, appellation, cru, adresse du
producteur.
• la base des millésimes devra comporter au minimum les champs suivants : cru,
millésime1, prix1 , millésime2, prix2 , etc. S’il semble y avoir une meilleure
solution que celle-ci (tout a fait simpliste) la spécifier et l’implanter.
• Création d’une carte de France cliquable avec régions et sous-régions. Lorsque
l’on clique sur une région (resp. une sous-région) apparaı̂t une carte de la sous-
région (resp. des appellations, ou des villages) correspondante.
16
• Gestion graphique de la base des crus. Raffiner la carte précédente jusqu’au

niveau des parcelles. Lorsque l’on clique sur une parcelle, l’étiquette du cru
apparaı̂t ainsi que diverses informations : adresse du producteur, ainsi qu’une
liste de millésimes/prix.
• Possibilité de recherches par appellation, millésime, fourchette de prix, etc.
avec obtention de listes de millésimes/prix.
• Réaliser un algorithme d’accord automatique vin/plat. Pour cela, créer une

base de données de plats réopertoriés, puis créer des règles d’accord. Réaliser
l’interface graphique corresondante.

L’ergonomie graphique doit être particulièrement soignée. La rapidité d’accès aux
bases de données est également importante.
5.6 Bibliographie
(i) Guide Bettane/Desseauve et/ou Parker.
(ii) Encyclopédie Hachette des vins.
(iii) L’Accord parfait de Philippe Bourguignon
Projet n◦ 6 : Suivi et gestion de trajectoires de véhicules

On considère le mouvement d’un véhicule et le modèle cinématique associé. Le
véhicule est piloté par la vitesse v de son centre d’inertie et par l’angle de braquage φ
de ses roues avant. On suppose s’être donné une trajectoire pour le point P situé au milieu
de l’essuieu arrière du véhicule. Les lois d’évolution de v et de φ réalisant le suivi de
cette trajectoire seront fournies. Le but de ce projet est de réaliser des outils permettant de
gérer les trajectoires (composition, modification, destruction) et de visualiser le véhicule
suivant une trajectoire.
6.2 Catégorie d’application : CGAD, NURBS (Non Uniform Rational B-Splines), tra-
jectographie, synthèse d’images.
17
6.3 Technologies Java et structures de données : structure de NURBS, Java 2D (graphisme),

Java3D (véhicule se déplaçant).
(i) Étape de base
• Composition d’une NURBS interpolante par ajout de points de contrôle à la

souris. Visualisation de la courbe composée. Visualisation/composition dans
deux JPanel : l’un pour xP (t), l’autre pour yP (t). Visualisation dans un
troisième JPanel de la courbe paramétrée (xP (t), YP (t)). Les compositions
de l’une des vues doivent se rṕercuter immédiatement sur les autres.
• Possibilité d’ajouter et d’enlever un point de contrôle. Visualisation de la
courbe correspondante.
• Réalisation d’une vue de dessus très simple du véhicule stylisé suivant sa tra-
jectoire. Le véhicule est représenté par un rectangle avec 4 segments pour les
roues.
• Opérateurs de modification d’une NURBS : modification de poids (ou ten-

sion locale de la courbe), applatissement, déformation (selon une courbe motif
donnée), modification de courbure.
• Visualisation par synthèse d’images du véhicule en train de suivre sa trajec-

toire. La visualisation se fera en perspective.
• Possibilité de changer de point de vue autour du véhicule pendant son déplacement,
avec sélection dynamique du point de vue à la souris.
• Possibilité de modifier la position des points de contrôle de la trajectoire pen-
dant le déplacement du véhicule.
• Schéma de suivi du pointeur de la souris. Le véhicule génère une trajectoire
qui suit le pointeur en temps réel.

Il doir y avoir une grande flexibilité par rapport au type de représentation d’une courbe.
L’ergonomie, la souplesse d’utilisation de la partie manipulation de courbes est impor-
tante.
18
6.6 Bibliographie
(i) The NURBS Book, par Les PIEGL et Wayne TILLER, 2e édition, Springer-Verlag,
Berlin, 1997.
(ii) Une bibliothèque de NURBS. À utiliser de préférence à autre chose.

http://www.ocnus.com/NURBS/index.html
(iii) Tracking kinemnatic models of the πCar manoeuvrable vehicle using flatness, par
Patrice BRAULT, Hugues MOUNIER, Nicolas PETIT et Pierre ROUCHON, rap-
port interne IEF.
(iv) Commande des systèmes non-linéaires, le point de vue des systèmes plats, par
Philippe MARTIN et Nicolas PETIT, notes de cours à l’école centrale de Paris,
1998.
(v) Applets de génération de courbe simple avec des Splines et des NURBS
http://web.tampabay.rr.com/gemini
(vi) Pour les tracés graphiques, Java2D MonarchCharts et JSci
(vii) Pour l’animation en synthèse d’images, Java3D sur le site Sun

http://java.sun.com/products/java-media/3D/
et, au sein de ce lien, un ouvrage en ligne
forDevelopers/j3dguide/j3dTOC.doc.html
Projet n◦ 7 : Jeu de vaisseaux spatiaux

Un jeu classique, où plusieurs vaisseaux en réseau peuvent se déplacer en propulsion
et en rotation, peuvent tirer et peuvent se téléporter. Des rochers défilent et une collision
d’un vaisseau sur un rocher fait éclater ce dernier.
7.2 Catégorie d’application : jeu, graphisme, application réseau.
7.3 Technologies Java et structures de données : Sockets, Java2D (pour le graphisme).
(i) Étape de base
• Déplacement en propulsion et rotation ; possibilité de tirer
19
• Un seul type de rocher

• L’accent doit être mis sur la synchronisation des joueurs
• Possibilité de téléportation
• Présence d’une réserve d’essence avec affichage de la jauge. Possibilité d’accélération,
en consommant plus d’essence.
• Plusieurs types de rochers.
• Possibilité de jeu en réseau à N joueurs.
• Création d’un mini langage permettant de programmer un vaisseau et de le

faire jouer en robot.
• Présence au sein de ce langage des instructions spécialisées : avancer, tourner,
accélérer, freiner, tirer, se téléporter.

L’application doit être flexible quant aux types de rocher et de vaisseaux, ainsi qu’au
type d’opérateurs que peut effectuer un vaisseau. Le caractère uniformément réparti est
de première importance : chacun des vaisseaux doit être à la fois client et serveur. Enfin
la synchronisation temporelle est un aspect crucial.
7.6 Bibliographie
(i) Une bibliothèque graphique pour le déveleppement de jeux de ce style se trouve à
http://www.hipbone.com/GameletToolkit/README.html
À utiliser de préférence à toute autre applet de ce type de jeu.
Projet n◦ 8 : Simulation de porteurs en bourse

L’objet est de simuler la gestion d’actions et d’obligations en bourse, avec des activités
de gestion rattachées aux banques, dans lesquelles chaque client disposera de portefeuilles
de titres. La gestion se fera de manière distante. Interviendront également des gros por-
teurs, qui pourront influer dynamiquement sur le cours des titres, ceci se répercutant sur
le montant des protefeuilles des clients.
20
8.2 Catégorie d’application : Bases de données, application client/serveur, application

distribuée.
8.3 Technologies Java et structures de données : JDBC, RMI, JavaSpaces.
(i) Étape de base
• Gestion de comptes multi-activités (multi-thread) en local à une machine.Il y
aura une activité banque, de gestion, et une activité par client de la banque.
• Toutes les opérations seront des requêtes. On définira un protocole à en-tête.
• Les opérations permises sur un compte comprendront au minimum : les re-
traits, virements, ouverture, clôture et consultation (avec liste des 10 dernières
opérations).
• Les opérations administratives sur la base de donnée des comptes compren-
dront au minimum : la liste des comptes et la fermeture d’un compte négatif
depuis N unités de temps.
• Gestion en réseau, l’activité de gestion résidant sur un serveur, les clients
accédant de manière distante au serveur.
• Envois de messages au client lorsque le compte est négatif depuis N unités
de temps ou lorsque le solde est supérieur à un certain montant et qu’aucune
opération n’a eu lieu depuis M unités de temps.
• Ajouter une gestion de protefeuille avec actions et obligations.
• Les opérations permises sur un portefeuille comprendront au minimum : acaht,
vente, consultation du montant et consultation des dernières opérations.
• Ajout d’un portefeuille de gestion différentié par client ; par exemple : autori-
sation de découvert, virement automatique (avec seuils) du portefeuille sur le
compte, etc.
• Création de gros porteurs pouvant influer sur le cours des actions et des obliga-
tions. Chaque gros porteur est associé à une activité (une thread) qui va influer
sur le cours des actions.
• Chaque action (resp. obligation) a une activité (thread) associée qui gère sa
valeur sur le marché international ; la valeur de l’action sera obtenue par une
fonction paramétrique. Ces activités effectueront des requêtes de mise à jour
des valeurs des actions auprès des gestionnaires de banque. Ces gestionnaires,
après communication avec les gros porteurs, mettront à jour les valeurs des
actions et obligations pour tous leurs clients.
21
• Traçé de l’évolution graphique de chacune des composantes du portefeuille en

fonction des gros porteurs.
• Ajouter une possibilité d’options à terme, où l’actionnaire peut acheter (ou
vendre) des titres et ne régler (ou encaisser) qu’à la fin du mois où l’option a
été passée.
• Implanter les gestionnaires de banque (avec plusieurs banques), les gros por-
teurs et les gestionnaires de valeur de chaque titre avec la technologie des
espaces (JavaSpaces).

L’application doit être flexible quant au type d’actif géré (il doit être facile d’ajouter
d’autres titres – actions et obligations – ainsi que d’autres catégories d’actifs) et quant au
comportement algorithmique des gros porteurs.
8.6 Bibliographie
(i) Pour la technologie JavaSpaces, voir sur le site développeur de Sun
http://developer.java.sun.com/developer/ l’URL contenant un article
sur la mise en route de JavaSpaces
technicalArticles/Programming/javaspaces/index.html
Projet n◦ 9 : Évaluation d’algorithmes d’ordonnancement

Le but de ce projet est de créer un mini ordonnanceur d’activités et de pouvoir com-
parer graphiquement divers algorithmes d’ordonnancement. On visualisera quelle activité
occupe le processeur fictif.
9.2 Catégorie d’application : Algorithmique d’ordonnancement.
9.3 Technologies Java et structures de données : Techologies Java standard (activités et
groupes d’activités).
(i) Étape de base
• Création d’un ordonnanceur avec 1 niveau de priorité en temps partagé (atten-

tion au comportement des activités concernant la commutation).
• Visualisation graphique du processeur actif.
22
• Algorithme à plusieurs niveaux de priorité, avec une option en temps partagé

au sein d’une même priorité. Par défaut préemption d’un niveau de priorité sur
un autre et deux tâches de même priorité s’exécutent séquentiellement.
• Algorithme en temps partagé avec vieillissement de tâches.
(iii) Étape avancée Écriture d’un gestionnaire d’activités complet, avec
• création d’activités,
• destruction d’activités,
• intégration à l’ordonnanceur déja développé (élection, mise en file d’attente
prète, bloquage par une autre activité)
• modification de priorité,
• mise en sommeil,
• moniteur de hoare intégré,
• gestion d’un groupe d’activités.

L’application créée devra être très flexible par rapport au changement d’algorithmes
d’ordonnancement.
Elle doit également être souple à utiliser en ce qui concerne l’évaluation d’un algorithme
à l’aide du logiciel.
9.6 Bibliographie
(i) Principes des systèmes d’exploitation par Abraham SILBERSCHATZ et Peter B.
GALVIN, Addison-Wesley, 4e édition, Paris, 1994.
(ii) Une applet primaire de visualisation d’ordonnancement en temps partagé à

http://choices.cs.uiuc.edu/f-kon/RoundRobin/
Projet n◦ 10 : Flotte d’aéronefs coopératifs

Une flotte de N petits avions autonomes doivent couvrir un territoire donné. La mis-
sion peut être de prendre des photos pour des besoins de cartographie ou de gestion terri-
toriale, de pulvériser de l’engrais, d’effectuer de la surveillance aérienne, etc.
23
On dispose pour chaque petit avion, d’un modèle simple de dynamique de vol. La
flotte de N avions se voit attribuée une mission au départ, puis au bout d’un temps
indéterminé peut se voir attribué une ou plusieurs autres missions. Chaque mission peut
également être abandonnée en route, par un ou plusieurs des N avions, en cas d’ordre en
ce sens.
10.2 Catégorie d’application : Agents coopératifs, systèmes distribués.
10.3 Technologies Java et structures de données : JavaSpaces ou JDMK (Java Dynamic
Management Kit).
(i) Étape de base
• Possibilité de composition d’une zone polygonale à la souris.

• Élaboration d’un algorithme de couverture d’une seule zone. Chaque avion
couvre une bande de la zone.
• Visualisation aérienne.
• Possibilité de couvrir plusieurs zones avec la zone 1 au début, la zone i au bout

du temps ti définie par l’utilisateur.
• Élaborer un protocole d’échange de messages ainsi qu’un algorithme simple
entre avions en cas d’attribution d’une nouvelle zone de réadaptation de zone
à couvrir ou d’abandon de mission.
• Créer des gestionnaires de mission distribués, chaque gestionnaire étant re-

sponsable d’au plus 3 missions et pouvant se trouver sur une machine différente
des autres gestionnaires. Les gestionnaires doivent dialoguer entre aux lorsque
peu d’avions sont disponibles. à ce moment-là, il doit y avoir un rééquilibrage
de charge, chaque mission devant avoir un nombre d’avions tel que le temps
pris pour la terminer soit presque le même. Ce rééquilibrage assigne à certains
avions d’autres missions en fonction des missions “sinistées” (missions qui ne
disposent que de peu d’avions).
• Élaborer divers algorithmes de rééquilibrage par communication entre les ges-
tionnaires de mission.
• Visualisation graphique simultanée des différentes missions en cours d’évolu-
tion dans différentes fenêtres.
24

Les protocoles d’échange et la mise en oeuvre d’algorithmes de couverture et de com-
munication entre gestionnaires doit être flexible. Il doit donc être facile de modifier et de
raffiner le protocole d’échange et de changer l’algorithme de couverture.
10.6 Bibliographie
(i) Pour la technologie JavaSpaces, voir sur le site développeur de Sun
http://developer.java.sun.com/developer/ l’URL contenant un article
sur la mise en route de JavaSpaces
technicalArticles/Programming/javaspaces/index.html
Projet n◦ 11 : Dynamique d’avion à décollage vertical

On considère un avion à décollage vertical où la stabilisation de roulis est assurée par
2 réacteurs situés sous les ailes. Le but est ici de faire suivre des trajectoires d’approche,
de décollage et d’aterrissage à l’avion. L’essentiel de la dynamique de vol sera également
considéré et on élaborera une vue de l’avion sous forme synthétique (en synthèse d’images)
11.2 Catégorie d’application : Suivi de trajectoires, synthèse d’images.

11.3 Technologies Java et structures de données : Splines (pour les courbes), Java2D
(pour le graphisme), Java3D (pour la synthèse).
(i) Étape de base Considérons un repère lié à l’avion, avec l’axe des x de l’arrière à
l’avant de l’appareil (axe de roulis), l’axe des y selon les ailes (axe de tanguage) et
l’axe des z du bas vers le haut de l’appareil (axe de lacet).
• Implanter les lois d’évolution de débit des gaz sous les ailes de l’avion pour
suivre une trajectoire 2D dans le plan y–z prédéterminée.
• Fournir un tracé graphique de l’évolution temporelle des débits de gaz ainsi
que des paramètres de roulis et de position du centre de gravité.
• Effectuer une visualisation 2D de l’avion (en coupe, dans le plan y–z) en
évolution.
• Création de courbes splines à la souris, par ajout de points de contrôle. Ces
courbes seront les trajectoires à suivre.
25

• Considérer la dynamique de vol. Implanter les lois d’évolution de propulsion
afin de réaliser un suivi d’une courbe tridimensionnelle.
• Visualiser l’évolution de l’avion selon cette courbe.
• Création/modification de courbes splines 3D à la souris, pour les trajectoires à
suivre. Possibilité de sauvegarder/charger sur disque une courbe.
• Effectuer une visualisation de l’appareil en évolution en images de synthèse.
• Implanter des lois dites en boucle fermée, permettant de compenser les légères
imperfections de modèle et les légères méconnaissances de conditions ini-
tiales.

Flexibilité quant au type de représentation d’une trajectoire (Spline, βSpline, NRBS,
Spline d’ondelette). Esthétique des représentations en image de synthèse.
11.6 Bibliographie
(i) Commande des systèmes non-linéaires, le point de vue des systèmes plats, par
Philippe MARTIN et Nicolas PETIT, notes de cours à l’école centrale de Paris,
1998.
(ii) Pour les tracés graphiques, Java2D MonarchCharts et JSci
(iii) Pour l’animation en synthèse d’images, Java3D sur le site Sun
http://java.sun.com/products/java-media/3D/
et, au sein de ce lien, un ouvrage en ligne
forDevelopers/j3dguide/j3dTOC.doc.html
Projet n◦ 12 : Gestion concurrente de voies ferrées

L’utilisateur peut construire un trajet de voie ferrée à la souris à l’aide de tronçons
prédéterminés. Plusieurs trains peuvent circuler sur ce trajet. Si deux trains ou plus ar-
rivent sur un tronçon unique de voie ferrée de telle sorte qu’il y ait un risque de colli-
sion, tous les trains sauf un doivent attendre. On pourra également prévoir des gares, des
garages de réparation et des plans horaires pour chaque train.
26
12.2 Catégorie d’application : Programmation concurrente, graphisme 2D.

12.3 Technologies Java et structures de données : Technologies Java standard.
(i) Étape de base
• Génération graphique de voies à la souris.

• Trois types de tronçons : droit, courbe (1/8 de cercle) et aiguillage 2x1.
• Circulation d’un seul train.
• Ajouter les trançons de type aiguillage 3x1 et 4x1.

• Prévoir le cas de plusieurs trains en circulation concurrente (chaque train étant
une activtité (thread) séparée.
• Gérer le cas de conflit d’accès de 2 trains ou plus à un tronçon de voir unique.
Prévoir l’ajout de gares et de garages de réparation.
• Gérer les plans horaires pour chaque train.

• Prévoir des communications entre les trains de façon que la gestion des col-
lisions soit anticipatives ; à savoir que chaque train, en communiquant avec
les autres, doit pouvoir détecter un conflit d’accès et doit pouvoir ralentir de
manière appropriée (de façon que la collision n’ait pas lieu et qu’aucun train
ne soit stoppé.
• Visualisation graphique de la gestion de collision anticipative.

12.6 Bibliographie
(i) Éventuellement l’applet
http://www-itg.lbl.gov/vbart/
27
Projet n◦ 13 : Explorateur d’arborescence distribué et sécurisé

Il s’agit de réaliser un clône de l’explorateur Windows avec possibilité d’explorer des
machines distantes (dont on entre le nom ou l’adresse IP). De plus, l’accès sera contrôlé
par des listes de contrôle d’accès (ou ACL, comme “Access Control List”) qui permet
d’obtenir une granularité fine de l’accès.
13.2 Catégorie d’application : Accès réseau sécurisé.
13.3 Technologies Java et structures de données : RMI, paquetage Perl, JAAS (Java
Authentication and Authorization Service).
(i) Étape de base
• Réalisation d’un clone de l’explorateur Windows en local à une machine.

Prévoir 2 Threads. L’une pour l’affichage et l’autre fournissant les infor-
mations.
• Possibilité d’accéder à et d’explorer une machine distante quelconque en four-
nissant son nom ou son adresse IP. Le client effectue l’affichage sur la machine
locale des informations fournies par le serveur sur la machine distante.
• Possibilité de rechercher un fichier ou un répertoire par son nom.
• Recherche d’une expression régulière dans toute une arborescence. Affichage

graphique des icônes représentant les fichiers et des lignes de ces fichiers con-
tenant l’xepression régulière.
• Implantation de lsites de contrôle d’accès permettant un accès différentié par
groupe et par utilisateur. Prévoir la création de groupes et la gestion des droits
au niveau utilisateur et groupe.
• Navigation avec gestion d’une liste des répertoires déja visités. Affichage
graphique de la liste en dynamique. Possibilité de revenir à un répertoire déjà
visité en cliquant sur l’icône correpondante.
• Créer un robot allant effectuer une recherche de fichier ou d’expression régulière

de manière distribuée. Dans un premier temps, on maintiendra une liste de ma-
chines à visiter.
• Rechercher des algorithmes de proximité sémantique lorsqu’un mot exact n’est
pas trouvé. on pourra se servir de catégories pour classifier les mots.
28

L’application doit être pensée et réalisée avec un souci de sécurité en tête. Elle doit en
outre être tolérante aux pannes.
13.6 Bibliographie
(i) Paquetage Perl OROMatcher à :
http://www.oroinc.com
(ii) Un tutoriel, au site de Sun

http://java.sun.com/docs/ sur la sécurité en Java 1.2 :
books/tutorial/security1.2/index.html
Projet n◦ 14 : Gestion d’une agence de voyages distribuée

Cette agence de voyages virtuelle doit non seulement être capable d’effectuer des
réservations de vols, mais également d’établir la composition d’un avion et le plan de
vol des pilotes. La composition d’un avion sera disponible sous la forme d’un graphique
interactif, où les places prises et les places disponibles seront différentiées par des codes de
couleur ; en cliquant sur une place, il sera possible d’obtenir – dans le cas où la place a été
réservée – des informations sur la personne ayant effectué la réservation (ces informations
n’étant disponible qu’en accès restreint).
14.2 Catégorie d’application : bases de données, application client/serveur.
14.3 Technologies Java et structures de données : JDBC (ou dbSwing).
(i) Étape de base
• Possibilité de créer/modifier/détruire une réservatuon pour un vol.

• Visualisation graphique des places occupées et prises dans l’avion (en vue de
dessus).
• Le serveur sera concurrent et l’accès à la base de données des vols sera syn-
chronisé.
• Trois catégories d’utilisateurs :
29
– le personnel de l’agence,
– les clients de l’agence,
– les pilotes.
qui auront des droits d’accès différents aux diverses informations.
• Lorsque l’on clique sur une place occupée, demande d’authentification (parce
qu’information à accès restreint), puis affichage des informations du client
ayant réservé la place.
• Gestion du plan de vol des pilotes
• Plusieurs agences distribuées, avec un seul aéroport. Communication des

serveurs des différentes agences entre eux afin de trouver une place libre dans
un vol.
• Algorithme d’optimisation des plans de vols à partir de N vols et P pilotes.
Communication des serveurs à cet effet.
• Prise en compte de contraintes d’impossibilités des pilotes pour certaines dates.

L’application doit être tolérante aux pannes (erreurs dans la base de données, agences
indisponibles) et ergonomique.
Projet n◦ 15 : Générateur de tâches distribué

Il s’agit de réaliser un démon (programme de service tournant en arrière plan) exécutant
des tâches en différé soit sur la machine locale, soit sur une machine distante. La fréquence
d’exécution des tâches est consignée dans un fichier de configuration, dont on pourra
forcer la relecture dynamiquement. Les démons d’exécution peuvent communiquer de
machine à machine afin de réaliser une tâche distribuée.
15.2 Catégorie d’application : gestion concurrente de tâches, équilibrage de charge
réparti.
15.3 Technologies Java et structures de données : technologies Java standard (activités
(threads) et groupe d’activités ; sockets).
30

(i) Étape de base
• Générateur de tâches local à une machine et tournant en tant que démon, que
l’on nommera jcron (comme “Java cron”, cron étant un générateur de tâches
connu sous Unix). Les tâches à accomplir sont consignées dans un fichier de
configuration nommé jcrontab.
• Le fichier jcrontab est constitué d’enregistrements, séparés par une ligne
commençant par le caractère #. Le format de chaque enregistrement est le
suivant :
– Chaque enregistrement est constituée de 7 champs séparés par un retour à
la ligne. Chaque champ est constitué d’un descripteur textuel (une chaı̂ne
de caractères) suivi d’un ou plusieurs espaces et/ou tabulations, suivi du
caractère : suivi d’un ou plusieurs espaces et/ou tabulations, suivi d’une
valeur numérique avec caractères spéciaux éventuels.
– Les 5 premiers champs, de valeur numérique, déterminent la périodicité
d’exécution.
– Dans l’ordre, on a : le champ des minutes (de descripteur “Minutes”, de 0
à 59), l’heure (de descripteur “Heures”, de 0 à 23), la date (de descripteur
“Date”, de 1 à 31), le mois (de descripteur “Mois”, de 1 à 12) et le jour
(de descripteur “Jour”, de 1 à 7).
– On dispose des caractères spéciaux suivants susceptibles d’intervenir dans
la valeur d’un des 5 premiers champs : une *, qui correspond à toutes les
valeurs autorisées ; deux valeurs numériques séparées par un tiret sig-
nifient un intervalle de temps (2-5 dans le champ “Heure” signifie de 2
heures à 5 heures) ; des valeurs numériques séparées par des virgules sig-
nifie que la tâche doit être réalisée pour toutes ces valeurs.
– Le 6e champ est celui de l’utilisateur voulant exécuter la tâche, de de-
scripteur “Utilisateur” ; le 7e champ est chemin de la tâche à exécuter, de
descripteur “Tache”.
• Possibilité de modification dynamique du fichier jcrontab
• Interface graphique conviviale de gestion du fichier jcrontab.
• Inclure une valeur de priorité associé à une tâche, comme 8e champ, de de-
scripteur “Priorite”. Cette valeur de priorité est utilisée lors du lancement de
l’activité (thread) exécutant la tâche.
• Générateur éventuellement distant. Un client jcron reçoit de l’utilisateur au
travers de l’interface graphique les informations du fichier jcrontab. Puis il
31
envoie des informations au serveur jcrond qui met à jour son jcrontab. À
partir de cette étape, l’architecture, même en cas de communication purement
locale, est client/serveur. Le serveur devra être concurrent.
• Possibilité de tâche sous forme d’URL de la forme :
jcron://nom machine.nom domaine/cheminTache
Le serveur de la machine locale va alors converser avec ceux des machines
distantes figurant dans son fichier jcrontab.
• Possibilité de tâches exécutées sur plusieurs machines. Plus précisément, une

tâche est décomposée en atomes. des groupes d’atomes, des molécules, sont
envoyées pour exécution sur chaque machine.
• Fonction d’équilibrage de charge. Une tâche spéciale, dite d’équilibrage, de-
mande périodiquement aux différents serveurs quelle est la charge de leur
machine. En cas de déséquilibrage constaté, il y a rééquilibrage : migration
d’atomes vers les machines les moins chargées.

Dans le cas de plusieurs machines, caractère uniformément réparti (c.à.d. l’architecture
réseau ne doit privilégier aucune entité, comme c’est le cas d’un serveur et de N clients).
L’application doit être tolérante aux pannes.
15.6 Bibliographie
(i) Code source d’un cron Linux
Projet n◦ 16 : Simulateur d’algorithme de routage

L’utilisateur pourra composer un réseau à la souris et simuler divers algorithmes de
routage classiques sous Internet. Il devra être possible de visualiser les paquets aux
différents routeurs, de morceler et de réassembler les paquets.
16.2 Catégorie d’application : routage, algorithmique répartie.
16.3 Technologies Java et structures de données : technologies Java standard (activités
(threads)).
32

(i) Étape de base
• Composition d’un réseau à la souris en utilisant 2 types de composants :
– des noeuds (machines terminales ou routeurs),
– des liens entre les noeuds.
Chaque noeuds pouvant être aussi bien une machine terminale qu’un routeur.
• Un seul transport de messages, sans fragmentation, en utilisant un algorithme
de routage de type vecteur de distance.
• Visualisation graphique des messages en transit.
• Possibilité de fragmenttation des messages.
• Plusieurs transports de messages en parallèle possible.
• Implantation de plusieurs algorithmes de routage.
• Visualisation graphique des messages (éventuellement fragmentés) en transit.
• Possibilité de pannes de machines terminales ou de routeurs.
• Simulation d’algorithmes simples de contrôle de congestion avec visualisation
graphique des paquets en transit.

L’appliaction doit être flexible quant au changement d’algorithme de routage. Elle doit
également être tolérante aux pannes de routeurs et de machines finales.
16.6 Bibliographie
(i) Le routage dans l’Internet par Christian HUITEMA, Eyrolles, Paris, 1995.
Projet n◦ 17 : Cartographie de site web

Le but de ce projet est de représenter l’arborescence d’un site Web sous forme graphique.
Le site pourra être rapatrié à l’aide de robots automatiques et son contenu analysé ensuite
pour produire l’arborescence.
33
17.2 Catégorie d’application : moteurs de recherche.

17.3 Technologies Java et structures de données : technologies Java standard.
(i) Étape de base
• Génération d’un arbre dans le style de celui d’un explorateur Windows, possi-
bilité de navigation au sein du site à l’aide de cet arbre.
• Recherche d’un mot au sein du site et pointage automatique vers les pages le
contenant avec dépassement du mot en couleur.
• Rapatriement à l’aide d’un robot automatique et production de l’arborescence.
• Élaboration de méta-arborescence de sites à partir d’une recherche de mots à

l’aide de divers opérateurs.
• Élaborer une recherche avec une spécification par catégorie
• Opérateurs recquis : ET, OU, NON, PARMI (opérateur de catégorie de ter-
mes).

L’application doit être ergonomique et tolérante aux pannes.
17.6 Bibliographie
(i) Sur le site Gamelan
http://www.gamelan.com/downloads/freeware/dir.java1.html
l’applet HtmlSearch effectuant des recherches sur des sites Web.
Projet n◦ 18 : Sonde de tests d’un réseau de serveurs

Le but de ce projet est de tester le fonctionnement d’un réseau de machines, notamment
en ce qui concerne la charge, le nombre de paquets perdus, etc.
La visualisation du fonctionnement d’un réseau de serveurs peut être effectuée à l’aide
d’un logiciel de supervision et de sondes installées sur chaque serveur. La sonde : il
34
s’agit d’un démon client qui est capable d’effectuer les tests indiqués par le serveur de
supervision.
Ces tests sont soit :
• des tests standards de type état de la mémoire, état de la charge, nombre de processus
actifs, zombies...
• le résultat d’un programme envoyé par le serveur

Le serveur de supervision : il connaı̂t l’emplacement de chacune de ses sondes et
dispose d’un fichier de configuration qui lui permet d’interroger les sondes sur des points
précis (tests) à des intervalles de temps précis ou à une date précise.
Le fichier de configuration précise en fonction des résultats des tests s’il faut ou non
faire remonter une erreur.
Le logiciel de supervision représente chacune de ses sondes avec leur état et tient à jour
un historique. En cas de problème il doit être capable d’envoyer un e-mail qui indique la
nature de la panne.
18.2 Catégorie d’application : réseau, algorithmique distribuée.
18.3 Technologies Java et structures de données : sockets, Java2D (pour les graphiques).

(i) Étape de base
• Programme de tests d’un serveur sonde en local à une machine qui effectue :
– des tests d’occupation mémoire et processeur (par ex. sous Linux par
top)
– des tests processus (par ex. sous Linux par ps)
– des tests de paquets IP, de connexions sockets (par ex. sous Linux par
netstat)
• Affichage graphique des courbes de tests de charge
• Fonctionnement avec un client qui interroge les sondes distantes dont les adresses
sont consignées dans un fichier de sondes.
• Tests réseau de sonde à sonde : temps d’aller-retour, porcentage de paquets
perdus, etc.
• Tests réseau distribués sur tout le réseau des sondes. Développer des algo-
rithmes distribués permettent d’effectuer des tests :
35
– d’efficacité : temps d’aller-retour au sein de l’arbre recouvant minimal ;

– de bon fonctionnement :paquets perdus sur paquets envoyés
– de robustesse : tests sur paquets erronés, sur paquets manquants

La tolérance aux pannes sera un aspect important, et plus encore la flexibilité par
rapport aux tests effectués par chaque sonde (il doit être aisé d’ajouter ou de modifier un
test existant).
18.6 Bibliographie
(i) code de traceroute sous Linux
Projet n◦ 19 : Génération de trajectoires avec obstacles

Il s’agit d’implanter des algorithmes d’évitement d’obstacle en robotique mobile par
la méthode des potentiels ou celle des lignes de niveau, avec une visualisation 2D ou en
synthèse d’images 3D.
On fournit des points de départ et d’arrivée à la souris ; on construit également des
obstacles à la souris par combinaison de formes géométriques simples. Cette étape est
réalisée en vue de dessus 2D et en perspective 3D. Ensuite, la génération de trajectoires se
réalise ; puis l’on peut suivre le cheminement du véhicule en vue de dessus et en perspec-
tive 3D.
19.2 Catégorie d’application : lignes de niveau, potentiels fictifs, génération de trajec-
toires.
19.3 Technologies Java et structures de données : Java2D, Java3D.
(i) Étape de base
• Implantation d’un algorithme de génération de trajectoire en utilisant la méthode

des lignes de niveau ; génération d’obstacles parallélépipédiques à la souris.
• Implantation d’un algorithme de génération de trajectoire en utilisant la méthode
des potentiels ; génération d’obstacles parallélépipédiques à la souris.
36
• Génération d’obstacles de formes géométriques simples : triangle, rectan-

gle, ellipse, polygone. Présence d’une grille graduée avec possibilité de fixer
précisément la taille des obstacles.
• Prendre en compte des informations de courbure et d’oscillation dans la génération

des trajectoires. Plus précisément, se servir d’une repésentation de type Splines
ou NURBS afin d’obtenir des trajectoires respectant des contraintes de cour-
bure maximale et d’oscillation maximale.

La flexibilité par rapport au type d’algorithme (facilité d’ajout et de modification d’un
algorithme existant) est essentielle. L’ergonomie d’utilisation est importante.
19.6 Bibliographie
(i) Projet Robotvis a l’INRIA Sophia-Antipolis Posant robotvis égal à
http://www-sop.inria.fr/robotvis/personnel/vthierry/Enseign
Les URLs suivantes fournissent d’utiles renseignements
robotvis/DemoPotentiels
robotvis/SujetsTps/TpPotentielsParam/TpPotentielsParam.html
robotvis/SujetsTps/TpPotentiels/TpPotentiels.html
Projet n◦ 20 : Transfert sûr sous UDP

Créer un protocole au dessus d’UDP réalisant un transfert sûr de données avec contôle
de flux à l’instar de ce qui est réalisé sous TCP. Implanter un mécanisme d’acquittement
de données avec contrôle de flux par fenêtre. Fournir un mode de traçage qui affiche de
manière graphique les accusés de réception, la fenêtre de flux. Fournir un exemple de
service echo.
20.2 Catégorie d’application : réseaux couche transport.
37
20.3 Technologies Java et structures de données : technologies Java standard (Datagram

et DatagramSocket).
(i) Étape de base
• Tansfert sûr par mécanisme d’acquittement de données.

• Contrôle de flux par fenêtre.
• Prévoir un niveau de sûreté en effectuant des vérifications/acquittements réalisés

tous les N fenêtres de flux.
• Traçage graphique des datagrammes en transit avec différentiation colorée de
ceux non acquittés et acquittés.
• Implantation d’un exemple de service echo.
• Implanter divers algorithmes de code correcteurs d’erreurs pour la vérification

et la correction d’erreurs de transmission.
• Implanter des algorithmes de compression de données.
• Réaliser un cryptage par algorithme à clé publique elliptique.

L’ensemble logiciel doit être parfaitement générique, de façon à être réutilisable dans
n’importe quelle architecture réseau.
20.6 Bibliographie
(i) Sécification TCP : “Transmission Control Protocol Darpa Internet Program Protocol
Specification”, RFC n◦ 793, sept. 1981 (disponible à
http://www.cis.ohio-state.edu/htbin/std/INDEX.std.html)
(ii) Évetuellement, le cours de l’UREC

http://www.urec.fr/cours/Reseau/tcp-ip/index.html
38

Jsu Jets Projets Java

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Jsu Jets Projets Java

Transféré par

Droits d'auteur :

Formats disponibles

Projets Java – Intitulés

A – Brefs descriptifs des projets

Projet n◦ 2 : Entrainement sportifs

Projet n◦ 3 : Carnet d’adresses distribué dynamique

Projet n◦ 4 : Agenda distribué simple

Projet n◦ 5 : Site internet des vins

Projet n◦ 6 : Suivi et gestion de trajectoires de véhicules

Projet n◦ 7 : Jeu de vaisseaux spatiaux

Projet n◦ 8 : Simulation de porteurs en bourse

Projet n◦ 9 : Évaluation d’algorithmes d’ordonnancement

Projet n◦ 10 : Flotte d’aéronefs coopératifs

Projet n◦ 11 : Dynamique d’avion à décollage vertical

Projet n◦ 12 : Gestion concurrente de voies ferrées

Projet n◦ 13 : Explorateur d’arborescence distribué et sécurisé

Projet n◦ 14 : Gestion d’une agence de voyages distribuée

Projet n◦ 15 : Générateur de tâches distribué

Projet n◦ 16 : Simulateur d’algorithme de routage

Projet n◦ 17 : Cartographie de site web

Projet n◦ 18 : Sonde de tests d’un réseau de serveurs

• le résultat d’un programme envoyé par le serveur

Projet n◦ 19 : Génération de trajectoires avec obstacles

Projet n◦ 20 : Transfert sûr sous UDP

Numéros de pages des descriptifs détailles de projets

Projet n◦ 6 : Suivi et gestion de trajectoires de véhicules 17

B – Descriptif d’énoncé générique

Projet n◦ i : titre du projet

5 Spécifications de comportement (optionnel)

C – Énoncés détaillés des sujets

• Implantation des lois d’évolution de débit et visualisation des courbes de tra-

(ii) Étape intermédiaire

• Composition simple de trajectoires par morceaux, par choix de diverses poli-

1.5 Spécifications de comportement

(iii) Pour les tracés graphiques, Java2D MonarchCharts et JSci

Projet n◦ 2 : Entrainement sportifs

• Outil de génération de documents multimédia à partir d’un document texte au

(ii) Étape intermédiaire

• Outil de génération de surimpression de points et de courbes (splines inter-

(iii) Étape avancée

• Plusieurs images de zoom simultanées possibles.

2.5 Spécifications de comportement

(ii) Des classes de gestion de texte sur images :

Projet n◦ 3 : Carnet d’adresses distribué dynamique

3.3 Technologies Java et structures de données : JDBC (ou dbSwing), RMI.

• Les adresses (ou enregistrements) doivent au moins comporter les champs :

(ii) Étape intermédiaire

• Développement en distribué, avec un serveur concurrent.

(iii) Étape avancée

• Plusieurs serveurs correspondant à plusieurs agendas peuvent converser, selon

3.5 Spécifications de comportement

Projet n◦ 4 : Agenda distribué simple

• Possibilité de fournir des contraintes de la forme :

4.5 Spécifications de comportement

Projet n◦ 5 : Site internet des vins

(ii) Étape intermédiaire

• Gestion graphique de la base des crus. Raffiner la carte précédente jusqu’au

(iii) Étape avancée

• Réaliser un algorithme d’accord automatique vin/plat. Pour cela, créer une

5.5 Spécifications de comportement

(ii) Encyclopédie Hachette des vins.

(iii) L’Accord parfait de Philippe Bourguignon

Projet n◦ 6 : Suivi et gestion de trajectoires de véhicules

6.3 Technologies Java et structures de données : structure de NURBS, Java 2D (graphisme),

• Composition d’une NURBS interpolante par ajout de points de contrôle à la

(ii) Étape intermédiaire