Rapport de projet d'objet : Gestion des notes d'un

établissement
Florent Kaisser

Sandrine Phcar

Yong Li

janvier 2005 L'intégralité du projet est disponible à : http://florent.kaisser.free.fr/soft/gnep.tar.gz

Table des matières
I Modélisation UML........................................................................................................................ 2
1.Etudes de cas d'utilisations.......................................................................................................2
a)Acteurs................................................................................................................................ 2
b)Cahier des charges...............................................................................................................2
c)Interaction avec le système..................................................................................................4
2.Diagramme de classes.............................................................................................................. 4
a)1er Versions.........................................................................................................................5
b)Seconde version ................................................................................................................. 6
c)Troisième version ............................................................................................................... 7
d)Version finale...................................................................................................................... 8
II Implémentation du système.......................................................................................................... 8
1.Implementation des classes...................................................................................................... 9
2.Base de données....................................................................................................................... 9
a)Systeme de base de données utilisé..................................................................................... 9
b)Modèle relationnel du diagramme de classes....................................................................10
c)Intégration du modèle relationnel dans le modèle objet....................................................10
III Conception de l'IHM................................................................................................................. 11
1.Le logiciel en Java..................................................................................................................11
a)Choix de la gestion des actions possibles par un membre de l’administration................. 12
i. Pour tout ce qui concerne un étudiant.......................................................................... 13
choix pour le formulaire étudiant................................................................................13
après l’inscription, une éventuelle suppression ou recherche d’un étudiant............... 13
une vérification toujours utile..................................................................................... 14
ii. Pour ce qui concerne les diplômes.............................................................................. 14
l’ajout et la suppression d’un diplôme........................................................................ 14
la création de ces modules associés ........................................................................... 15
l’inscription d’un étudiant à un diplôme..................................................................... 16
iii. au niveau des notes.....................................................................................................17
b)intéraction Interface Graphique et Base de Données........................................................ 18
2.Le site web en PHP................................................................................................................ 18
a)Consultation des résultats..................................................................................................19

Introduction
Le projet à pour but de réaliser un logiciel qui permet de stocké des notes d'un établissement
scolaire, et d'obtenir divers information sur ces notes (statistique, classement,...). On a alors séparé
le logiciel en deux grande partie :
• le système : C'est le noyau du logiciel, il permet de stocker et de récupérer les données entrées
par l'utilisateur.
• L'interface homme machine (IHM) : C'est l'interface graphique du noyau, il commande le
système.
Avant d'implémenter le système, on a ajouter une phase préliminaire, qui permettra de modéliser
le système, avant de l'implémenter.

I Modélisation UML
Avant d'écrire le programme nous avons tout d'abord modélisé le problème en UML.
L'organisation de cette tache s'est faite en plusieurs étapes, dans un premier temps, chacun de nous
trois a exposé son diagramme de classe UML, lors de la première réunion. On a ensuite donnée
notre avis sur ces diagrammes. On à alors abouti à la première version du diagramme. Pour savoir si
notre diagramme été correctes nous avons envisagé l'ensemble des cas d'utilisation, ainsi que les
différents acteurs du systèmes.

1.Etudes de cas d'utilisations

Pour mettre en évidence les différent cas d'utilisation du système nous avons décrit les acteurs du
système, puis le cahiers des charges, c'est à dire, ce que le système doit posséder comme
fonctionnalité. Et enfin les interactions entre les acteurs et le système.

a)Acteurs
Les acteurs jouant un rôle dans le systèmes sont au nombre de cinq : Une Personne, un étudiant,
la scolarité, le jury, un examinateur :
1. Une personne
C'est un étudiant qui n'est pas encore inscrit à l'établissement.
2. Un étudiant
Acteur représentant une personne inscrit à l'établissement.
3. La scolarité
Personnel de l'établissement, qui à pour rôle de rentrer l'ensemble des données dans le système.
Elle peux aussi communiquer ces données à un autre acteur
4. le jury
Il peux modifier une moyenne d'un module.
5. Un examinateur
C'est lui qui détermine les notes des étudiants

b)Cahier des charges

Pour pouvoir construire et évaluer notre diagramme de classe, nous avons essayer de recenser
l'ensemble des scénarios possible entre les acteurs et le système.
1. Inscription d'une personne à un diplôme
Deux possibilité peuvent se présenter :
1. La personne n'a jamais été inscrit à l'établissement,
Il est tout d'abord inscrit à l'établissement: Il communique l'ensemble des information sur son
état civil.
Puis ensuite il est inscrit à un diplôme, ce qui correspond à l'autre possibilité puisqu'il
maintenant inscrit à l'établissement.
2. La personne est déjà inscrit à l'établissement.
Il peux donc être inscrit à un diplôme:
• L'étudiant choisi à quel diplôme il souhaite s'inscrire
• Puis il choisi les modules du diplôme auxquels il souhaite s'inscrire
2. Création d'un diplôme
Lorsque l'établissement souhaite créer un nouveau diplôme, la scolarité, doit entrer les
information sur ce diplôme:
• Intitulé du diplôme
• Choix d'un règle d'obtention du diplôme
• Défini les modules du diplôme: Pour chaque module
 • On associe un coefficient
• On rentre les coefficient de chaque épreuve
3. Notation
La notation se fait par l'examinateur. Il à pour rôle dévaluer les épreuves de chaque étudiant, et
d'y associer une note. Habituellement, il rentre l'ensemble des notes de tout les étudiant inscrit à
une épreuve particulière. Il procède ainsi:
• Choix d'un diplôme
• Choix d'un module
• Choix de l'épreuve.
• Et pour chaque étudiant
• Il rentre la note
4. Modification d'une moyenne
Après que le jury soit réuni il peux modifier la moyenne à un module (calculer en fonctionne des
notes) Pour cela on différenciera, la moyenne calculé (à partir des notes déjà rentrées), et la
moyenne fixé (Défini par le jury). Cette moyenne clôtura alors le module. Il procède ainsi:
• Choix d'un diplôme
• Choix d'un module
• Pour chaque étudiant
• Modifier ou valider la moyenne
5. Définition de règles d'obtentions pour valider un diplôme
La scolarité peut définir un ensemble de règle à l'obtention d'un diplôme. Pour ajouter une règle
elle doit fournir les informations suivante:
• La moyenne minimum pour valider un modules
• Le nombre minimum de module à valider pour obtenir le diplôme
• La moyenne minimum à chaque module pour valider un diplôme
• Pour chaque mention, la moyenne minimum à un diplôme pour obtenir cette mention.
6. Consultation des résultats
L'ensemble des acteur, peuvent consulter les données du systèmes. Cette consultation peux se
faire également plusieurs années après que les données ont été rentrer. Un historique de
l'ensemble des inscriptions, et des notes, et donc conservé. Pour différencier les inscription à un
diplôme au fil des années, on associe à chaque diplôme une Promotion, qui correspond à l'année
d'inscription au diplôme. La consultation s'effectuera à partir de l'IHM.
Les différentes consultation possibles (avec le scénario)sont :
1. Consultation d'une note à une épreuve:
• Identification (numéro d'étudiant)
• Choix du diplôme
• Choix d'un module.
2. Consultation de moyenne définitive, ou partiel à un module ou à un diplôme
• Identification (numéro d'étudiant)
• Choix du diplôme
 • Choix d'un module.
3. Mention ou moyenne obtenue à un diplôme ou si il à été obtenue ou non.
• Identification (numéro d'étudiant)
• Choix du diplôme
4. Détails sur les diplômes enseignés dans l'établissement.
• Identification (numéro d'étudiant)
• Choix du diplôme
5. Historique des inscriptions d'un étudiants.
• Identification (numéro d'étudiant)
• (Choix d'une inscription)
7. Redoublement à un diplôme
Un étudiant peu redoubler une année, dans ce cas, il repasse les modules de son choix. Il doit
alors se réinscrire à un diplôme (avec une promotion différente), mais il peux conserver certain
module de l'année précédente de son choix. Si il se réinscrit à un module, c'est celui ci
(Promotion la plus récente), qu'il sera utilisé dans la moyenne général.

c)Interaction avec le système

Seule la scolarité pourra interagir avec le système pour des opérations de modification de type
inscription, définition de note ou de moyenne, ajout de diplômes, ect... Pour les opération de
consultation, l'ensemble des acteur pourront y accéder par l'intermédiaire du site web ou de la
scolarité. Si une personne souhaite s'inscrire il faut qu'elle s'adresse à la scolarité. Idem si un
étudiant veux se réinscrire, ou si le jury ou un examinateur veux définir une note ou une moyenne.

2.Diagramme de classes
Le diagramme de classes à permis de modéliser notre problème, sous forme de classe. Les
attributs et les méthodes sont volontairement omis dans les première version, car il semblait plus
important de bien définir les classes et les association être elle avant d'allé plus loin. Les diagramme
de classe qui suivent sont aussi disponible au format GIF dans le répertoire doc/analyse

a)1er Versions
Dans la première réunion, nous avons définie une 1er version d'un diagramme de classes,
comportant les classes suivantes:
• Établissement
• Personne
• Règle : Ensemble de valeurs définissant les règles d'obtention d'un diplôme en fonction des
moyennes obtenues aux modules.
• Matière : Une matière enseigné
• Étudiant : Personnes inscrits à u moins une promotion.
• Promotion : Représentes l'ensemble des étudiants inscrits à un diplôme pour une années.
• Diplôme : Diplôme enseigné par l'établissement.
• Modules : Matière coefficienté, enseigné dans un diplôme
• épreuve : Epreuve d'un module. Possède un coefficients.
• Note : Classes association entre un Étudiant et une épreuve.
• RelevéDeNotes : Ensemble de moyenne de chaque module, fixé à partir des moyennes
calculé. Un objet de cette classe est créé après que le jury a défini les moyennes finals des
modules. Cette classes permet aussi de calculer la moyenne au Diplôme, ainsi que de savoir si
le diplôme est validé, et quel mention est attribué.
• Moyenne : Association entre une relevée de note et un module. Définie une note moyenne
pour un module donnée.
Les associations entre les classes sont :
• Établissement/promotion: Permet de définir les promotions de l'établissement.
• Étudiant/Note: Notes qu'a obtenues l'étudiant
• Promotion/ReleveDeNote : Relevés de notes pour chaque Étudiant inscrit à une promotion.
Elle bidirectionnel, car le Relevée de note doit pouvoir consulter les règles associé au
 diplôme de la promotion.
• Promotion/diplôme : Diplôme associé à la promotion
• Diplôme/Module : Modules enseigné dans le diplôme
• Épreuve/Module : Épreuves qui sanctionnes un module.
• Note/Épreuve : Épreuve associé à la note.
• ReleveDeNote/Moyenne : Ensemble des moyenne du relevée de note.
• Moyenne/Module : Module associé à la moyenne.
• Diplôme/Règle : Règle associé au diplôme
Sur cette version on peux noter plusieurs point litigieux. ReleveDeNotes est associé à une
promotion, mais aussi à un Étudiant, car il possède son numéro, hors on a pas mis d'association
entre ReleveDeNotes et Étudiant. La classes note doit-elle être associé directement à un Étudiant ?
Ca pose problème car on demande pas à un Étudiant d'enregistrer sa note, puis quand on en à
besoin, de lui redemander. Le redoublement est difficilement gérable, car on peut pas conserver un
éventuelle module qu'il a déjà validé.

b)Seconde version

On essayé de résoudre le problème des redoublements en se disant, qu'il faut faire apparaître les
inscription à un module, au lieu des inscriptions à un diplôme. La classes Promotion est retiré pour
ajouter une classes InscriptionModule, qui represente une inscription d'un Étudiant à un module,
pour une année donnée (ce qui permet le redoublement). Comme on à liées les note à l'etudiant, on
décide de faire de même pour le RelevéedeNote. On ajoute aussi une association entre
Établissement et Étudiant pour matérialiser un inscription à l'établissement.

c)Troisième version

On s'est dit, que puisque qu'on à matérialisé une inscription à un module , on pourrai faire de
meme pour un Diplôme avec une classe InscriptionDiplome. Ce qui est plus logique,car un
Étudiant, s'inscrit, et un diplôme, puis à des modules. Si les notes serai associer à l'inscription
module, au lieu d'un étudiant, on à plus besoin de relevée de note, car InscripltionModule peut
calculer la moyenne, ou la fixer. On a alors retiré la classe RelevéeDeNote et la classe moyenne.
Pour qu'un Étudiant puisse s'inscrire à un diplôme on le demande à la classe Diplôme, qui crée un
objet de la classe InscriptionDiplome qui matérialise son inscription. Ensuite on peut demander a
InscriptionDiplome, de s'inscrire à un module du diplôme, elle crée alors un objet
InscritptionModule. Ces deux inscriptions sont toujours liée à une année (Promotion) car, si un
Étudiant veut conserver les notes obtenu à un module, il se réinscrit au diplôme pour l'année
suivante, et ajoute à cette inscription, certaines des inscriptions aux modules de l'année précédente.
On peut remarquer une sipulitude entre le groupe de classes Diplôme/Module/Epreuve et le groupe
InscriptionDiplome/InscriptionModule/Note . Le premier groupe décrit les entités liées à
l'établissement. Et le second des associations entre les classes (Classe d'association) :
• InscriptionDiplome : Association entre un Étudiant et un diplôme pour une année donnée
 • InscriptionModule : Association entre une inscription à un diplôme et un Module, pour une
années données.
• Note : Association entre une InscriptionModule et des Épreuve, pour une valeur de note
donnée.
Après avoir vérifié, si les différent scénarios peuvent être accompli pas se diagramme, nous
avons décidé qu'elle serai la version finale.

d)Version finale

Dans cette version finale nous avons ajouté les principales méthodes et attributs des classes. Les
méthode qui permettent de naviguer entre les classes ont été volontairement omis, en considérant
qu'il sont déjà représenté par les associations du diagramme. Chaque attributs de classes sur le
diagramme sont publique et peuvent être obtenu en lecture seul par une méthode de même nom.

II Implémentation du système
Pour implémenter le système on à choisi Java. L'implémentation en Java suivra scrupuleusement
le diagramme de classe. L'IHM utilisera les objets des classes pour interagir avec le système.
Dans un premier temps, nous avons implémenté le système en stand-alone (les objets etant
stockés dans des vecteurs, et sans possibilité de sauvegarde des données), sans base de donnée pour
effectuer des teste (sans l'IHM). Une fois les testes concluant nous avons intégrer le système de
dialogue avec la base de données (interaction avec le JDBC).
1.Implementation des classes
Pour chaque classe du diagramme, on écrit une classe Java correspondante. Chacun des attributs
de classe peut être obtenue en lecture seul à partir d'une méthode de même nom. Pour chaque
association entre 2 classes, on crée un méthode pour obtenir une Collection d'objet de la classe
opposé. Si cette classe (celle opposé) à une clé, on peux obtenir un seul objet correspondant à cette
clé. La méthode pour obtenir cette objet aura alors comme paramètre la clé et retournera une
instance de la classe correspondante. En résumé si on à 2 classe A et B
A->B : A possédera une méthode : Collection b()
Si B à une clé c ; A possédera en plus la méthode B b(c)
En plus de ces méthodes, la classe A doit posséder une méthode du type ajouterB(B b) pour
ajouter une association entre un objet de A et l'objet b. Selon la situation « ajouter » peux être
nommer « inscrire », si B est une classe d'association. Dans ce cas l'objet à passer en paramètre n'est
plus une instance de classe opposé, mais une instance d' une des classe associer à cette association.
La méthode retourne alors l'instance de la classe d'association crée. Par exemple pour inscrire un
étudiant à un diplôme, on utilise la méthode InscriptionEtudiant inscrireEtudiant(Etudiant e) de la
classe diplôme. InscriptionEtudiant sert de classe d'association entre Etudiant et Diplôme.
InscrireEtudiant n'a donc besoin que d'une instance de la classe Etudiant pour créer une association.
Pour chaque méthode ajouterX on à aussi une méthode supprimerX pour supprimer une
association.
Pour une description plus détaillé sur chacune des méthodes de classes, se référer à la
documentation JavaDoc.
La classes promotion est implémenté comme un entier, représentant l'année de l'inscription. La
classes Mention et implémenté comme un type énuméré, qui est en faite un entier, qui peu prendre
comme valeur une constante défini dans la classe Règle.

2.Base de données
Pour conserver toutes les données rentrées dans le système, elle devront être enregistré sur un
support de sauvegarde. 2 cas ont été envisagé :
• Les données sont enregistré dans un fichier, créer par java, en utilisant le système de
Sérialisation. Dans ce cas la base de donnée ne peux être consulter qu'a partir de l'ihm java
associé, et seulement sur un seul poste.
• Les données sont enregistré sur un serveur de base de données. N'importe quel logiciel peux
accéder à cette base de données, pourvu qu'il respecte le protocole imposé.
Les deuxième solution à été retenue, pour pouvoir utiliser avec l'IHM n'importe où, du moment
qu'elle peux accéder au serveur. Une interface web pourra aussi être ajouté facilement. Pour éviter
de « réinventer la roue » on choisi d'utiliser un serveur de base de donnée existant de type
PostgresSQL ou MySQL.

a)Systeme de base de données utilisé

On utilise une base de donnée de type relationnelle. Pour se connecter à cette base on utilise le
midle-ware JDBC de java, qui servira d'interface entre le système et la base de donnée. Pour des
raisons de flexibilité, le système pourra se connecter au choix, à une base de données PostgreSQL
ou MySQL. Ces deux logiciels on été choisi, car ils sont libre, et un serveur MySQL étant mis à
notre disposition à l'Université. Dans un premier temps le logiciel à été testé sur PostgreSQL, car
ont avait un serveur personnel prêt à l'emploi, à notre disposition (le serveur MySQL de l'université
étant inaccessible de l'extérieur). Avec JDBC, le portage à MySQL n'a pas posé beaucoup de
problème. Quelques différences subsistes : Lorsqu'on veux définir un clé auto-increpmentable,
MySQL utilise le mot clé AUTO_INCREMENT, alors que PostGreSQL à son propre type
BIGSERIAL. Pour obtenir la dernière clé généré ou la prochaine clé qui sera généré, MySQL
implémente une méthode dans JDBC, mais c'est pas la cas de PostGreSQL, on doit alors envoyer
une requête sur une table pour obtenir la clé.
Le choix de la base de données se fait lors de l'établissement de la connexion ensuite plus aucune
différence ne sera faite entre les deux. L'utilisateur spécifiera la base de données à utiliser dans un
fichier de configuration (type, adresse du serveur, login).

b)Modèle relationnel du diagramme de classes

Pour créer la base de donnée, on à besoin de définir son modèle relationnelle. Il est calqué sur le
diagramme de classe. Chaque objet correspondant à une table, les attributs d'une table
correspondant aux attributs de la classe. Par contre les héritage étant pas permis les super classe
n'ont pas de tables correspondante. Dans notre cas seule deux cas simple ce sont présenté : Personne
n'a pas de table correspondante, par contre la tables étudiant contient les attribut de personne et
d'étudiant. Idem pour Matiere et Module.
Les associations unidirectionnel 1 à N (les seules pressente dans notre diagramme) entre les
classes peuvent être vu comme une relation entre 2 tables.
Établissement n'ayant pas d'attribut, il n'a pas de table correspondante.

Schéma de la base de donnée

c)Intégration du modèle relationnel dans le modèle objet

Le désavantage à l'utilisation d'une base de donnée relationnel, est son intégration difficile dans le
modèle de classe définit. Le travails à été de trouver la solution la plus élégante pour faire cohabiter
le modèle objet et le modèle relationnelle. Pour pouvoir retrouver les données enregistrées, la plus
part des classes auront besoin d'accéder à la base, donc elle devront avoir accès à une instance de
classes permettant d'accéder à cette base. Cette classe pourrai être Statement de JDBC, mais par
soucis d'abstraction, on créera une classes appelé BD, qui servira à interroger la base de donnée.
Lors de sa création on lui fournie les différents paramètres pour se connecter à la base de données.
A partir de l'objet BD on peut effectuer 2 types de requêtes : les requêtes d'actualisation
(INSERT,UPDATE,DELETE), et les requêtes d'interrogations (SELECT).Une méthode pour
obtenir la dernière clé primaire généré est aussi disponible.
Un autre problème à été de définir pour chaque tables sa clé primaire, qui permettra de définir
plus facilement les relations entre les tables. On pourrai utiliser les clé des classes, mais chaque
classes n'a pas forcément sa clé. On à donc décider d'ajouter un attribut entier id à chaque classe (et
donc à chaque table), id sera la clé primaire de la table. Cette attribut n'appairait pas dans le
diagramme de classe car il est seulement utile pour la base de donnée du modèle relationnelle.
Chaque classe possédera donc un attribut publique id (lecture et écriture par des méthodes), et un
attribut privée bd correspondant à une instance de la classe BD. Ces 2 attributs seront initialisé par
le constructeur des classes. Il est alors judicieux de définir un classe BDTable possédant ces
attributs, chaque classes (sauf Établissement), hérite alors de BDTable.
Les méthodes utilisé pour parcourir les associations, ont pour rôle de créer le ou les objets à partir
d'une requête SQL de type SELECT. A partir des données de la base, ont crée alors les objets
associée, puis ont les retourne. Les méthodes de type ajouter et inscrire, exécute des requête
d'actualisation de type INSERT, pour créer ou supprimer une nouvelle association entre 2 objets.
Avec ce type d'implémentation le modèle relationnelle et sa base de donnée associée est
totalement invisible à l'utilisateur du système.
L'interrogation de la base par l'intermédiaire du système (pour conserver le concept objet), peut
pénaliser les performances sur l'obtention des données. Par exemple pour calculer la moyenne d'un
étudiant inscrit à un diplôme, la méthode utilise une autre méthode des inscription à chaque module
pour obtenir la moyenne à ce module. La méthode calculant la moyenne à un module, interroge la
base de donnée pour obtenir les notes. Donc si on a 8 modules, on effectuera 9 requêtes (1 pour
obtenir les modules, et 8 pour calculer chaque moyenne au module), alors que si on aurai voulu
obtenir la même information en interrogeant la base directement, on aurai pu réduire le nombre de
requête à une seule. Mais il y a pire, pour obtenir la moyenne sur une promotion entière, on aura 9
fois le nombre d'étudiant, de requête effectué, donc dans un cas réel, avec 200 étudiant on va avoir
1800 requêtes d'effectuer, ça devient inacceptable. Heureusement, lorsque le module à été clôturé
(aucune note ne seront ajouter dans l'avenir), la moyenne est fixé, et donc les requête d'obtention de
notes ne sont plus utilisée, ce qui réduit le nombre de requête.
diagramme partiel entre une classe et BDTable, BD, Statement

III Conception de l'IHM

L'ihm se décompose en deux parties : le logiciel en Java, et le site web. Le logiciel sera utilisé
uniquement par la secrétaire, alors que le site web pourra être consultable par tous les utililistaurs.

1.Le logiciel en Java

Le projet devait permettre de gérer tout le domaine administratif pour un étudiant. En effet, il a
été établi qu'il devait être possible:
• de saisir toutes les informations sur l'état civil d'un étudiant,
• celui devait pouvoir s'inscrire à un (voire plusieurs) diplôme(s),
• de saisir des notes de validation d'une matière pour un diplôme,
• de consulter au final:
 les moyennes générales,
 la moyenne de la population ayant obtenu le diplôme,
 la moyenne de la population ayant obtenu la mention,
 les statistiques de réussite.
• d'archiver des promotions,
• des diplômes,
• ...
Le mieux pour interagir avec toutes ces données était de créer une interface graphique “facile”
d'utilisation. En effet, le mieux pour un utilisateur éventuel est de ne pas à avoir à communiquer
avec le système par un nombre trop grand de fenêtres à gérer. C'est pourquoi il a été décidé que tout
se ferait dans une unique fenêtre dont la taille est maximale par rapport à la taille de l'écran de
l'ordinateur utilisé.

Dés la deuxième réunion de projet, des idées pour l’interface graphique ont été évoquées. Ces
idées consistaient à n’avoir pour un utilisateur éventuel qu’une seule fenêtre de gestion des actions
et des données à saisir ou à vérifier !
De plus, seule une personne de l’administration sera apte à utiliser ce logiciel.

a)Choix de la gestion des actions possibles par un membre de l’administration

Tout d’abord, nous avons dû choisir une méthode de représentation simple qui permettrait à la
fois de voir certaines données du système comme les différents diplômes actuels de l’établissement,
pour chacun les modules définis, … mais également d’insérer de nouvelles données. Ces dernières
peuvent se résoudre à :
 une inscription d’un nouvel étudiant à un établissement
 une création d’un nouveau diplôme avec les modules qui lui seront associés
 …
Pour cela, un seul composant graphique y répondait : un arbre !

Cet arbre, à l’état actuel se décompose de la manière suivante :

De manière complètement étendue, l’arbre contient :
 i. Pour tout ce qui concerne un étudiant

choix pour le formulaire étudiant

Comme nous pouvons le voir à chaque rentrée scolaire, un dossier nous est remis dans le but de
fournir à l’établissement toutes les données de notre état civil, autrement dit, notre nom, …
Les champs principaux les plus importants étant :
 le numéro d’étudiant
 son nom
 et son prénom
Seuls ces derniers ont été implémentés au niveau de la base de données. En effet, pour connaître
un étudiant, il suffit de connaître son numéro d’étudiant et par celui on peut retrouver le nom et le
prénom de celui-ci.

après l’inscription, une éventuelle suppression ou recherche d’un étudiant

Pour ces deux actions : suppression et recherche, nous avons choisi d’élaborer une sorte de
« questionnaire ». En effet nous avons dit plus haut qu’il suffisait de connaître le numéro d’étudiant
pour retrouver la personne qu’il caractérise. Ainsi nous avons choisit de commander ces deux
actions par uniquement la valeur de celui-ci.
Au niveau graphique, nous obtenons deux panneaux presque identiques à un bouton près !

une vérification toujours utile

Mais aussi, comme éventuellement on peut faire une erreur maladroite (un numéro mal rentrer et
ça supprime un autre étudiant !), on a choisit de faire en sorte que les informations concernant
l’étudiant qui a été précédemment supprimé devaient être affichées dans le but d’une simple
vérification formelle.

Ce panneau d’affichage d’information a été construit sur une JTable dont les champs ne sont en
aucun modifiable puisqu’il s’agit d’une simple vérification pouvant, par exemple, être de la forme
suivante dans le cas d’une inscription :

ii. Pour ce qui concerne les diplômes

l’ajout et la suppression d’un diplôme

Considérons l’ensemble de tous les diplômes existant pour un établissement. L’ajout et la
suppression sont loin d’avoir une répercussion « locale » puisqu’il modifie l’état de tout un
ensemble. Pour opérer, il fallait donc attribuer à ces actions un endroit dans l’arbre ! Le plus logique
était de le faire au niveau du nœud « Diplômes ». Ceux-ci sont ensuite rendus visible par un
panneau du type:
 Pour la suppression, une « List » avait été choisit, de même pour tout ce qui concerne le listing
des modules, des règles, …! Dès que l’on veut visualiser un ensemble, de préférence fini et de
cardinal pas trop important, il est plus esthétique de lister tous ses éléments dans une « List ». La
sélection d’un « Item » suivit d’un effet sur le bouton « supprimer » permet de supprimer un élément
de la liste et, par là même, une modification de l’arbre.

la création de ces modules associés

Le problème est très simple à résoudre ! Mais là encore pas le droit à d’autres éventuelles
fenêtres ! Nous avons donc choisit de mettre en œuvre un système de panel dans lequel toutes les
actions possibles sur un diplôme donné seraient visibles :
 création de modules associés,
 destruction de certains d’entre eux,
 …
On obtient donc un panneau d’affichage de la forme suivante :
 Étant donné que pour ajouter un module à une liste déjà existante (vide si le diplôme vient d’être
créé), un problème de savoir à quel diplôme ce module devait être raccroché. Mais heureusement
l’arbre simplifie bien les choses. En effet pour connaître le diplôme auquel il se réfère, il suffit de
savoir quel nœud de l’arbre on a préalablement sélectionné. Pour se faire une fonction de la classe
IHM y répond :

public Diplome diplomeSelectionne(){

int numDiplome = 0;
for(int j=0;j<node.getParent().getChildCount();j++){
if(node.toString().compareTo(entree.menuArbre().diplomeIHM(j).toString()) == 0){
numDiplome = j;
}
}
// on récupère le diplome correspondant
return entree.menuArbre().diplome(numDiplome);
}
En ce qui concerne la suppression d’un module, il suffit de le sélectionner dans la liste et de
cliquer sur le bouton « supprimer »

l’inscription d’un étudiant à un diplôme

Comme on peut le remarquer sur le panneau précédent, un champ inscription a été conçu pour
rattacher un étudiant inscrit au préalable à l’établissement de choisir le diplôme qu’il souhaite
acquérir. Mais celle-ci ne peut se faire qu’à partir, du moins en l’état actuel des choses, de son
numéro d’étudiant. Puis pour ce dernier, le choix de ces modules devra être établie.
Cependant ce choix étant fait à partir d’une liste préconçu, pour chacun de ces choix, l’étudiant
aura juste à le sélectionné dans une liste. Cette interaction se fera à l’aide d’un panneau de la
forme :

A tout instant, cette configuration permet de voir quel(s) module(s) a (ont) déjà été sélectionné(s),
il suffira de lire la liste de droite ! Un module choisit consiste en un ajout dans la liste de droite et à
une suppression dans la liste de gauche.

Mais plus on descend dans l’arbre (au niveau de la hauteur), plus les choses se corsent. Et c’est
notamment le cas pour l’insertion des notes.

iii. au niveau des notes

Pour les notes, tout devient plus compliqué. En effet, une note est rattachée à une épreuve. Pour
l’instant, ça paraît plutôt logique. Mais l’instant où la difficulté commence est le moment à partir
duquel on se pose la question de savoir à quel module il est une épreuve, mais ensuite de savoir à
quel diplôme ce module dont il y a référence fait appel ! Pour cela, nous avons choisit de créer une
fonction dans la class IHM de résolution suivante du problème :
 public Module moduleCorrespondant(){
int numModule = 0;
int numDiplome = 0;
for(int j=0;j<node.getParent().getParent().getChildCount();j++){
// on recherche le diplome correspondant:
if(node.getParent().getParent().toString().compareTo(entree.menuArbre().diplomeIHM(j).
toString())==0){
numDiplome = j;
}
}
for(int j=0;j<node.getParent().getParent().getChildCount();j++){
// on recherche le module correspondant:
if(node.getParent().toString().compareTo(entree.menuArbre().moduleIHM(entree.menuArbre().
diplomeIHM(numDiplome),j).toString())==0){
numModule = j;
}
}
// on récupère le diplome correspondant
return entree.menuArbre().module(entree.menuArbre().diplomeIHM(numDiplome),numModule);
}

En effet, ces problèmes sont facilement résolvables à partir du notre arbre :

 le module correspond au père du nœud de l’épreuve considérée
 et le diplôme, le parent du module correspondant.

b)intéraction Interface Graphique et Base de Données

Pour des raisons de simplification de programmation, on a choisit de faire en sorte que tout ce qui
pouvait faire une liaison avec la base de données se ferait au niveau d’une unique classe qui gérerait
tous les « Listener » associés.
Comme vous avez pu le remarquer à travers deux exemples de problèmes sous-jacents (le cas de
la recherche du diplôme correspondant et celui du module), nous avons abordé le fait que la solution
(du moins la fonction associée programmée) se trouvaient toutes deux dans la même classe : IHM.
Cette classe a la particularité de gérer les « listener » associés à :
 l’enregistrement d’un étudiant au niveau de l’établissement,
 l’ajout d’un nouveau diplôme, voire également une suppression
 …
dans lesquels se feront tous les appels de méthodes sur des objets du système. Aucune requête
vers la base de données ne sera donc exécuté dans la partie de l'IHM.
Mais à cet avantage de tout gérer dans une classe s’ajoute un inconvénient majeur la
surpopulation de classes traitantes des ActionListener et autres.

2.Le site web en PHP

Le site web permet à n'importe qui d'obtenir des information sur l'établissement, mais aussi de
consulter les note d'un étudiant.
Le langage de script utilisé est PHP, car il possède des modules pour mySQL et PostgreSQL ainsi
que pour la plus part des serveur Web. Sa syntaxe ressemblant au C, il est simple à utiliser. Pour
récupérer les donnée de la base, PHP interrogera directement le serveur de base de donnée. La
notion d'objet n'est donc pas pris en compte dans le site Web.

a)Consultation des résultats

Calqué sur les cas d'utilisations, l'étudiant doit avant tout s'identifier en entrant son numéro. Cette
étape se fait dans le fichier identification.php. Une fois identifié, le numéro de l'étudiant est transmis
en la page liste_inscription.php par POST . liste_inscription.php affiche alors (après avoir vérifié
l'existence de l'étudiant) l'historique de l'ensemble des inscription à l'établissement. L'utilisateur n'a
plus qu'a choisir son l'inscription pour pouvoir afficher ses résultats.

Conclusion:
A la fin de ce projet, on s'est demandé si ça valait vraiment la peine de conserver le concept objet
stricte, pour implémenter le système. Les données aurai pu être obtenue directement par l'ihm
(comme avec le site). Mais la maintenance du logiciel aurai été d'autant plus difficile, car pour
modifier l'IHM il aurai fallu que le programmeur s'intéresse aux requêtes à utiliser, ce qui n'est pas
le cas avec notre système, qui cache toutes les requêtes.
On a aussi remarqué certain problème d'intégrité des données, par exemple si on oublie d'entrée
une note pour un étudiant, la moyenne sera calculé seulement à partir des notes entrées, et la
moyenne sera faussé. On peux résoudre le problème en vérifiant combien il y a d'épreuve, dans le
module. Des règles aurai pu être également ajouté, comme par exemple le nombre minimum de
module, auxquels l'étudiant doit être inscrit.
La réalisation du diagramme de classe, nous a permis de mieux comprendre la manière de penser
pour modéliser le monde réel en UML. La remise en question permanente de notre schéma nous à
sans doute permis d'aboutir à un modèle qui se rapproche de ce que doit remplier le système.
Néanmoins on se rend compte qu'il est difficile d'être sur à 100 % que notre diagramme colle bien à
la réalité. La réalisation par la suite de la base de données, nous a amené à utiliser les driver JDBC,
et à essayé d'intégrer au Modèle objet les requêtes pour récupéré les données dans la base.
La deuxième partie, qui est la réalisation de l'IHM, nous a pousser à utiliser les composant
SWING, et à mieux appréhender la réalisation d'une interface utilisateur, et à mieux comprendre les
liens qui peuvent exister être les données que l'utilisateur souhaite connaître, et leurs représentations
dans celle-ci.
Nous avons sous estimé le temps qu'on allé passer sur l'IHM, sans doute à cause du manque
d'expérience dans ce domaine. Elle n'est donc par terminé, et de nombreux bug de placement reste à
corriger. L'affichage des statistique reste très succin, et est seulement présent dans le site web. Le
site web aurai pu être agrémenter d'information sur l'établissement (diplôme enseignée,
renseignement divers). Il n'est également pas possible de gérer les rattrapage et le redoublement à
partir de l'IHM.

Annexe
Outils utilisés:
ArgoUML 0.16.1 : Logiciel libre prometeur pour la réalisation de diagramme UML. Il nous à pas
permis d'indiquer les attributs clés d'une classe.
Eclipse 2.1.2 : Environnement intégré, permettant, les principales fonctionnalité qu'on attend
d'un IDE. Le mode debugage est très pratique (-;
JDK 1.4 : Indispensable pour programmer en JAVA
OpenOffice 1.1.0 : Pour réaliser ce présent document.
JCreator : Autre Environnement intégré.
Références:
P. -A. MULLER, N. GAERTNER, Modélisation objet avec UML, Eyrolles 2004
Laura LEMAY, Rogers CADENHED Java 2 en 21 jours , Campus Presse 2002