Artigouha Noémy Janvier 2017

Barbier Vivien
Cichocki Guilhem
Girardi Alexis
Wu Di

Rapport
Gestion des stages
A l’attention de Mme Guermouche
 Dans ce rapport, nous allons développer les différentes étapes qui ont été
nécessaires à la réalisation de ce projet. Nous commencerons par détailler la réalisation du
diagramme UML à partir du cahier des charges, en précisant les choix qui ont été effectués
et pour quelles raisons. Ensuite, nous présenterons le travail réalisé sur le XML schéma et le
document XML correspondants au diagramme UML. Enfin, nous nous intéresserons à la
réalisation du site web grâce à la transformation XSLT et aux requêtes qui étaient
demandées dans le cahier des charges.

2
 Plan

I - Conception……………………………………………………………..4
1 - Diagramme UML…………………………………………….....4
2 - Choix faits……………………………………………………….5
II - Schéma XML et XML………………………………………………....5
III - Site web et XSLT……………………………………………………..6
IV - Requêtes……………………………………………………………..10
V - Répartition du travail………………………………………………….11

3
I - Conception : Diagramme UML
1 - Diagramme UML

Fig 1 - Diagramme UML

4
2 - Choix faits

Afin de répondre au cahier des charges, nous avons fait différents choix. Notamment
les héritages pour éviter la duplication d’information. Par exemple pour les personnes, elles
pouvaient être soit des encadrants, soit des enseignants. Comme les enseignants et les
encadrants possèdent les mêmes attributs, nous avons choisi de créer une entité personne
mère de ces deux entités. Nous avons également créé des héritages au niveau de
Encadrants​ et d'​Établissements​.

Pour éviter d’autres redondances, nous avons choisi de ne pas créer des liens
inutiles entre différentes entités quand nous pouvions y accéder par d’autres entités. Par
exemple, dans le cahier des charges il est dit qu’une “soutenance porte sur un stage et un
rapport lui est associé”. Nous avons donc lié l’entité Soutenance avec l’entité ​Stage et au
lieu de créer une redondance entre ​Soutenance et ​Rapport​, nous pouvons accéder à l’entité
Rapport en passant par l’entité ​Stage​. De même pour le jury de la soutenance, nous n’avons
pas créé d’entité ​Jury puisque nous pouvions accéder aux encadrants et au tuteur par
l’entité ​Stage​. Nous avons par contre ajouté un lien entre ​Soutenance et ​Enseignants
puisque d’autres enseignants peuvent faire parti du jury.

De ce fait, nous pouvons constater que l’entité ​Stage est au centre. C’est elle qui met
en lien toutes les autres entités.
Nous avons choisi d’ajouter des ​id à chaque entité pour faciliter les requêtes et le parcours
de la base de données.
Enfin, nous avons rajouté les cardinalités afin de répondre aux besoins du cahier des
charges.

II - Schéma XML et XML

Une fois que nous avions réalisé le diagramme UML complet, il a fallu l’implémenter
en langage XML.
Pour ce faire, nous avons passé tous les attributs des différentes entités
en une séquence d’éléments, par exemple pour l’entité stage :

Fig 1 - Implémentation Stage

Il a ensuite fallu gérer les différentes relations entre les entités suivant les
cardinalités indiquées dans le diagramme UML. Lorsque la cardinalité associée à une entité
était égale à 1, nous ajoutons un attribut à cette entité, attribut qui correspond à l’​id de

5
l’entité associée. Dans le cas des stages, chaque stage n’est associé qu’à une
PO/évaluation/... , nous avons donc inséré les ​id de ces entités dans le XSD associé aux
stages :

Fig 2 - ID en attributs

On remarque l’utilisation du ​“required” qui indique que ces éléments sont obligatoires : il ne
peut y avoir de stage sans PO/... , cependant dès qu’une cardinalité n’était pas à 1 mais à
0,1, nous n’avions plus besoin du ​required. Les clés/ID utilisés à chaque fois sont bien
entendu préalablement déclarés dans chaque XSD de l’entité correspondante.

Un autre aspect sur lequel il a fallu réfléchir lors de l’implémentation a été celui des
héritages. On retrouve des héritages dans les ​Établissements et dans les ​Personnes puis
Encadrants​. Nous avons eu quelques difficultés à mettre en place ces héritages. Nous
avons fait le choix d’utiliser des balises ​“choice” pour implémenter ces derniers. Nous avons
également trouvé sur Internet d’autres méthodes pour gérer l’héritage, avec des balises de
restriction ou d’extension, mais lors de nos essais ces méthodes n’ont pas fonctionné
comme prévu et nous avons préféré l’utilisation des ​“choice”. Cette implémentation à
l’inconvénient de dupliquer les attributs communs aux entités qui héritent des attributs d’une
classe mère, mais cette duplication n’est présente que dans le code où il a fallu déclarer par
exemple l’attribut nom à la fois pour les labos ou pour les entreprises au lieu de ne l'avoir
que pour l’établissement. C’est un choix qui a été possible car toutes les entités qui
possèdent des héritages ne pouvaient exister seules. On n’a pas d’entités “​Etablissement​”
seule ou de “​Personnes​” etc, ces éléments étaient forcément (respectivement) soit un labo
soit une entreprise ou soit un encadrant soit un enseignant. Dans le cas où des entités
mères auraient été utilisées, nous aurions eu duplication des attributs communs entre l’entité
mère et les entités qui héritent de ces attributs. Il aurait fallu repasser les attributs communs
dans la classe mère, ou changer la manière d’implémenter l’héritage avec des extensions.

L’autre problème que nous avons rencontré dans cette partie concerne la liste de
mots clefs, et l’endroit où il fallait l’ajouter au document XML ainsi que sous quelle forme.
Nous avons fait le choix de l’intégrer comme un type à part entière constitué d’une séquence
de mots clefs.

III - Site web et XSLT

Pour présenter les résultats d’une façon plus conviviale nous avons réalisé un site web
présentant le contenu de la base de données XML.

6
Nous avons donc écrit des pages XSLT traduisant le XML en balises HTML. La principale
difficulté rencontrée a été de récupérer des informations en faisant le lien avec l’​id. Par
exemple pour l’affichage des stages, notre base contient seulement des ​id référençant
l’étudiant et les encadrants. Cependant pour l’utilisateur final il ne serait pas très lisible
d’afficher uniquement ces id, nous avons donc trouvé une solution permettant de récupérer
le nom et prénom de l’étudiant/encadrant, et de l’afficher proprement.

Pour nous faciliter la tâche lors du développement du site web et nous éviter d’écrire le CSS
from-scratch nous avons utilisé Bootstrap. Ce qui nous a permis de rapidement obtenir une
page au design soigné. De plus les différents composants nous ont permis de réaliser le
tableau paginé, une barre de recherche et la possibilité de trier le tableau selon différents
critères.

La première idée de design pour le site était une page de menu et une ​single page app c’est
à dire un site d’une seule page affichant tout le contenu de la base de données.

Fig 4 - Maquette du design initial de la présentation des résultats

Cependant ce design pose un problème de scalabilité. En effet avec une petite base il est
adapté et offre une navigation fluide. Mais de le cas d’une base plus grosse, ce design
impose à l’utilisateur de défiler sur la page pour chercher l’information qu’il recherche et ce
malgré nos tableaux paginés qui n’affichent que les ​x premiers résultats (​x étant un nombre
que l’utilisateur peut choisir).

Nous avons donc décidé de changer de design et sommes partis sur le concept d’une page
par classe (page étudiant, page stage, page encadrant …).

7
 Fig 5 - Maquette du design final du site

Nous n’avons qu’un XML représentant notre base, pour mettre en place il faudrait pouvoir
appeler un XSLT sur ce XML en fonction de la demande du client.
La première idée que nous avons eu est de faire une page XML par page de site qui appelle
un XSLT et inclut la base XML. Malheureusement XML ne permet pas ce genre d’inclusion.
Pour faire cela il faut passer par un autre langage réalisant l’inclusion.

La solution est possible dans une application web complète (application php, Nodejs, …). En
utilisant le routeur qui capture la requête de l’utilisateur, on peut charger le XSLT
correspondant et l’appliquer à la base XML pour retourner le résultat au client.

8
 Fig 6 - Principe de fonctionnement d’une application web utilisant un XSLT différent pour chaque
page

Cependant cette solution technique n’a pas été retenue puisque le sujet ne demandait pas
de créer une application complète et le temps imparti ne nous permet pas de réaliser cette
application.

La solution que nous avons choisi est une solution simple, nous allons dupliquer notre base
de données XML, c’est à dire un XML associé à un XSLT par page du site. Cette solution
est satisfaisante pour le rendu graphique même si elle présente une forte duplication de
code. Par exemple la barre de menu est réécrite dans chaque page. Une modification d’un
élément de ce menu impliquerait forcément une réécriture dans chaque page du site ! De
plus la non utilisation de ​front-controller+routeur nous oblige à faire des liens entre chaque
page du site.

Fig 7 - Schéma de fonctionnement effectif de notre site

9
IV - Requêtes

Ici sera présenté la méthode suivie pour construire les requêtes, le code des requêtes est
quant à lui disponible sur le Drive.

1) Le nombre de stages soutenus

Il est égal au nombre de soutenances donc il suffit de compter le nombre de
soutenances.

2) Le nombre de stages sans soutenance

Nous comptons le nombre de stages qui n’ont pas l’attribut “id_soutenance”

3) Le nombre d'industriels qui ont encadré des stages

Nous avons fait une jointure entre personne et encadrant de stage ensuite nous
avons vérifié si la personne est un industriel. La fonction distinct-values sert à enlever les
données dupliquées. Nous pouvons utiliser les prédicats au lieu d’utiliser la fonction
distinct-values.

4) Pour chaque PO, on veut récupérer le nombre d'étudiants ayant la moyenne et le nombre
d'étudiants n'ayant pas la moyenne de toutes leurs notes (rapport, soutenance, ...etc)
​Pour chaque PO, nous avons trouvé tous les stages effectués et vérifié si la
moyenne est atteinte. Il retourne l’élément étudiant. La fonction distinct-values sert à enlever
les données dupliquées.

5) Le nombre d'étudiants ayant fait des stages en industrie

Pour chaque étudiant, nous avons trouvé son établissement et vérifié si c’est une
entreprise.

6) Le nombre d'étudiants ayant fait des stages en laboratoire de recherche

Même principe que la requête précédente en changeant l’élément industrie par
l’élément laboratoire.

7) Pour chaque PO, le nombre de stages effectués

Pour chaque PO, nous avons parcouru la table des stages et compté le nombre de
stages si le stage est dans cette PO.

8) Pour chaque PO, le nombre d'enseignants tuteurs

​ Idem parce qu’un stage n’a qu’un seul tuteur, on a juste rajouté l’id_tuteur.

9) Pour chaque PO, la moyenne des soutenances

10
 ​ ous avons cherché pour chaque PO, les stages qui ont des soutenances et nous les
N
avons mis dans une variable. Nous avons pris la moyenne de cette variable.

10) Pour chaque entreprise, on veut retourner le nombre de stages ayant plus de 14 comme
moyenne et le nombre d'étudiant ayant une moyenne moins de 11 effectués au sein de cette
entreprise.
Même principe que la requête 4.

V - Répartition du travail

Artigouha Barbier Cichocki Girardi Wu Di

Noémy Vivien Guilhem Alexis

Diagramme 20% 20% 20% 20% 20%

UML

XML Schéma 10% 10% 35% 35% 10%

XML 30% 5% 30% 30% 5%

XSLT et Site 25% 5% 55% 5% 10%

web

Requêtes 5% 30% 5% 5% 55%

Rapport 20% 20% 20% 20% 20%

Nous avons choisi de nous répartir les tâches ainsi, de façon à ce que chacun de nous
puisse travailler sur un peu toutes les tâches tout en faisant avancer les différentes tâches
en parallèles pour que le travail soit plus productif.

11