Projet de Génie Logiciel et Système : Un modèle de scénarios

Projet de Génie Logiciel et Système :
Un modèle de scénarios
Mathieu MONTIN
2015-2016
Résumé
Ce document décrit le travail demandé aux étudiants du département IMA de l’ENSEEIHT inscrits pour la session 1 de l’année universitaire 2015-2016 de l’UE GLS. Il s’agit d’un travail individuel qui
devra être réalisé en autonomie ; à ce titre, des vérifications concernant
l’authenticité du travail pourront être effectuées.
Dans ce projet sont testées les facultés des étudiants à construire
une infrastructure basée modèle autour d’une problématique concrète.
Cette approche s’effectuera en deux axes : une partie modélisation
sur papier et une partie implémentation en utilisant les outils développés dans le cadre du projet Eclipse Modelling Framework (EMF)
pris en main au cours du module.
Deux rapports seront rendus au cours du projet : un dossier préliminaire qui sera suivi d’un retour des enseignants et un rapport de
projet qui devra contenir les difficultés d’implémentations par rapport
à ce dossier ainsi que toute autre information jugée pertinente.
Les travaux relatifs à la partie développement devront fonctionner
sous Linux sur les machines des salles de travaux pratiques, qui sont
pourvues des outils nécessaires à la bonne réalisation de ce travail, et
qui serviront de lieu de test à la fin du projet.
Les dates de rendus sont données à la fin de ce sujet. Il est impératif
de rendre les travaux dans les délais ; Tout retard sera sanctionné.
Les étudiants sont encouragés à travailler de manière régulière, et ce
dès la remise du présent sujet.
1
Table des matières
1 Présentation du sujet
3
2 Analyse Préliminaire
2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Mieux comprendre le besoin . . . . . . . . . . . . . . . . . . .
2.3 Pour aller plus loin . . . . . . . . . . . . . . . . . . . . . . . .
4
4
4
4
3 Partie implémentation
3.1 Introduction . . . . . . . . .
3.2 Le méta-modèle de domaine
3.3 Les autres besoins . . . . . .
3.4 Le consultant technique . .
5
5
5
6
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Barème
7
5 Informations pratiques
5.1 Dates importantes . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Modalités de rendu . . . . . . . . . . . . . . . . . . . . . . . .
8
8
8
2
1
Présentation du sujet
Préambule Une maison de retraite décide de mettre en place un processus
permettant aux résidents atteints de la maladie d’Alzheimer d’améliorer leur
quotidien. L’idée est de leur offrir un moyen simple et intuitif de consigner
les activités passées et de planifier celles des jours à venir à l’aide d’un outil
automatisé. N’ayant pas le personnel qualifié pour accomplir ce genre de
tâche, la maison de retraite s’est tournée vers une jeune pousse (start-up)
toulousaine prometteuse dont vous faites partie.
Exemple Pour préciser son besoin, le client vous donne un exemple de
scénario (en figure 1) qu’il vous présente comme une version simplifiée de son
dimanche habituel. Il avoue avoir fait le croquis assez rapidement, dans le
métro qui l’a conduit jusqu’à vos locaux.
Explications Il commence par se
lever puis effectue deux actions dans
un ordre arbitraire : se doucher et
prendre son petit déjeuner avant de se
laver les dents. Ensuite, il réalise les
plannings de certains de ses pensionnaires avant d’aller faire les courses si
besoin, ou simplement de se détendre.
Arrivé à midi, il prend son repas et
passe l’après midi à faire du sport ou
de la musique, en fonction de ses envies. Il n’a malheureusement pas le
temps de faire les deux. Il prend son
dîner juste après, et finit sa journée
par le visionnage d’un film à la télévision avant d’aller se coucher.
Important Le client vous explique
qu’il veut avoir la possibilité de détailler certaines de ses activités. Par
exemple, l’activité "détente" aurait
pu être décrite comme un choix
entre plusieurs activités, une succession d’activités ou encore diverses activités en parallèle.
Figure 1 – Le croquis du client
3
2
2.1
Analyse Préliminaire
Motivation
Avant de s’engager dans un contrat avec vous, le gérant de la maison de
retraite vous demande de lui présenter un dossier préliminaire contenant un
aperçu des travaux que vous serez en mesure de réaliser. Si le dossier est
concluant, il vous chargera du développement de son projet.
2.2
Mieux comprendre le besoin
D’autres exemples Pour amorcer votre dossier préliminaire, vous décidez
de créer de nouveaux exemples sur lesquels baser vos travaux. Afin de faciliter
la communication avec le client, vous décidez de formater ces exemples de la
même manière que lui. Vous expliquez aussi en quelques mots ce que décrivent
vos nouveaux scénarios d’exemples.
Contraintes informelles De votre compréhension des besoins du client,
vous rédigez en langage naturel des contraintes informelles sur le domaine
étudié (les scénarios). Vous faites figurer ces contraintes dans votre dossier
afin que le client puisse les valider avec vous. Celles-ci doivent uniquement
porter sur les aspects modèle, c’est-à-dire sur votre compréhension des scénarios avec lesquels le client désire travailler.
2.3
Pour aller plus loin
Rendu graphique Le client vous a demandé un moyen élégant d’afficher
les scénarios afin que ses locataires puissent les visualiser convenablement.
Vous décidez de faire figurer dans votre dossier un aperçu de ce que pourra
être la représentation graphique. Cette vue graphique n’est pas définitive
et doit être indépendante de tout outil. Il s’agit ici simplement de montrer
au client le genre d’affichage dont il pourra disposer. En outre, l’exemple
donné par le client est certes présenté de manière graphique, mais votre
représentation graphique proposée n’a pas l’obligation d’y ressembler.
Export HTML Le client veut proposer aux résidents la possibilité de
visualiser dans un navigateur internet une version documentaire textuelle
de leurs scénarios. Vous devez lui proposer donc un export HTML qui lui
permette de réaliser cette fonction. Vous fournissez dans votre dossier une vue
simple qui permet l’affichage documenté des différentes activités composant
un scénario. Elle doit correspondre à ce qu’un navigateur pourra afficher.
4
Syntaxe concrète Vous décidez de ne pas en rester là et de proposer
au client d’autres fonctionnalités auxquelles il n’a pas forcément pensé et
que vous espérez lui être utiles. Dans votre dossier, vous ajoutez donc une
représentation textuelle de la journée du client. Vous lui expliquez qu’il sera
ainsi possible d’éditer de manière textuelle des scénarios afin de simplifier le
travail des résidents.
Requêtes Pour terminer votre dossier préliminaire, vous proposez au client
de réaliser des requêtes sur ses modèles, comme par exemple compter le
nombre d’activités élémentaires effectuées dans la journée. Vous lui proposez
aussi plusieurs autres requêtes de votre choix.
3
3.1
Partie implémentation
Introduction
Quelques jours après avoir remis le dossier préliminaire au client, il décide
de vous confier l’implémentation de son projet (après vous avoir fait part
d’éventuelles modifications à prendre en compte). Satisfait, il désire que vous
commenciez dès à présent pour que la première version puisse être disponible
au plus vite. Après avoir longuement discuté avec votre équipe, vous prenez la
décision d’utiliser les outils fournis par le framework EMF (Eclipse Modelling
Framework) pour réaliser le projet. Il apparaît qu’ils comportent toutes les
caractéristiques nécessaires à la satisfaction des besoins du client.
3.2
Le méta-modèle de domaine
Le méta-modèle Le point d’entrée à l’utilisation des technologies EMF
est la conception d’un méta-modèle. Vous le réalisez en Ecore via l’éditeur
graphique adapté. Celui-ci sera le point d’entrée aux différentes implantations
liées aux besoins du client.
Contraintes additionnelles Le méta-modèle livré au client ne vous convient pas entièrement. Il apparaît que l’expressivité du langage que vous avez
utilisé n’est pas suffisante pour mettre en avant toutes les caractéristiques du
domaine. Vous avez besoin d’autres contraintes, pour garantir par exemple
l’unicité des noms des activités au sein d’un même groupement ou encore
pour limiter l’usage de certains noms que vous jugez non pertinents. Ces
contraintes, ainsi que celles listées dans le dossier préliminaire, sont formalisées en utilisant OCL et plus précisément, OCLinEcore.
5
3.3
Les autres besoins
A partir de votre méta-modèle à présent achevé, vous faites un récapitulatif des technologies dont vous aurez besoin pour poursuivre votre travail :
— La vue graphique (afficheur uniquement) sera réalisée avec Sirius.
— L’export HTML sera mis en place en Acceleo.
— Vous utiliserez Xtext pour définir une syntaxe concrète textuelle.
— Les requêtes se feront en utilisant l’API d’EMF disponible depuis Java.
Le but étant bien sûr de rester le plus proche possible de votre spécification.
3.4
Le consultant technique
Fermeture OCL Vous entrez, au cours de vos travaux, en contact avec
un consultant technique spécialiste des technologies que vous utilisez. Il vous
donne l’indication suivante : "Il existe une opération OCL appelée ’closure’
qui permet de calculer de manière récursive un ensemble d’éléments à partir
d’un objet. Vous trouverez ici les détails liés à cette opération qui pourra
vous être utile dans votre travail : ’http ://modeling-languages.com/closureoperation-added-to-ocl/’. De votre modélisation dépendra l’utilisation (ou
non) de cette primitive dans vos règles OCL."
Container Sirius Selon votre modélisation, le consultant vous explique
qu’il vous faudra peut être utiliser des "containers" pour mener à bien cette
tâche. Les "containers" sont des éléments graphiques intermédiaires permettant à la fois de représenter un objet, mais aussi de contenir d’autres réprésentations. S’il y a des boucles dans la hiérarchie des containers (’A’ qui
contient un élément de type ’A’, qui donc lui-même peut contenir un élément
de type ’A’, etc), il est possible d’importer des mappings existants afin de gérer l’infinité (théorique) des imbrications. Cela se fait dans l’onglet "import"
des propriétés des éléments graphiques. Pour de plus amples informations, le
consultant vous invite à visiter la page suivante :
https ://www.eclipse.org/sirius/doc/specifier/diagrams/Diagrams.html
dans la section ’mapping imports’
Return Xtext Le consultant technique vous informe qu’il est possible de
créer une syntaxe textuelle concrète qui viendra se lier avec le méta-modèle
déjà existant. Pour cela, il faut que chaque règle déclare renvoyer un objet
du méta-modèle. La syntaxe, dans la grammaire, est la suivante : "[nom de
règle] returns [Classe du MM]". Ainsi, vous aurez accès, dans le corps de la
règle, aux affectations d’attributs présents dans la classe précisée en entête.
6
4
Barème
Nous vous proposons ici un barème détaillé pour l’ensemble du projet.
Une petite description accompagne chaque item afin de mieux vous aider
dans votre travail. Attention néanmoins, elle ne correspond pas forcément à
la totalité des aspects qui seront pris en compte.
Nom
Analyse préliminaire
Autres exemples
Contraintes
Rendu graphique
Export HTML
Syntaxe concrète
Requêtes additionnelles
Qualité générale
Implémentation
Méta-modèle
Contraintes OCL
Sirius
Acceleo
Xtext
API EMF
Exemples
Rapport
Soutenance
Description
Exemples pertinents et présentés lisiblement (avec les
explications nécessaires à leur compréhension)
Il contient un ensemble cohérent de contraintes se basant sur l’exemple du client
Un rendu graphique cohérent est présenté
Une vue pouvant résulter de l’affichage d’un fichier
HTML par un navigateur est présentée
Une syntaxe concrète est spécifiée à travers un exemple,
elle contient des mots-clefs et est indentée
Des requêtes additionnelles pertinentes sont proposées
Qualité générale du rapport (forme, orthographe, etc.)
Le méta-modèle Ecore des scénarios
Des contraintes OCL pertinentes sont présentées, qui
doivent, conjointement au méta-modèle, inclure les
contraintes informelles du dossier préliminaire
Une vue graphique développée en Sirius. Elle permet
l’affichage des différents exemples proposés
Un exportateur HTML est fourni, codé en Acceleo.
Une syntaxe concrète, définie dans une grammaire Xtext
permet l’édition de modèle sous forme textuelle.
L’API java EMF est utilisée pour réaliser les requêtes
présentées dans le dossier préliminaire
Pour chaque partie, des exemples pertinents permettront de valider le travail réalisé.
Le rapport est un compte-rendu du travail réalisé. Il
doit être auto-suffisant et contenir les explications nécessaires à la compréhension du travail réalisé.
Les travaux sont présentés à l’oral devant machine de
manière fluide et structurée (donc préparée). L’étudiant
sait répondre aux questions sur ses travaux.
Total
Barème
20 points
3 points
3 points
3 points
3 points
3 points
3 points
2 points
40 points
5 points
5 points
7 points
6 points
7 points
5 points
5 points
20 points
20 points
100 points
7
5
5.1
Informations pratiques
Dates importantes
Date
Mardi 3 novembre 2015
Jeudi 12 novembre 2015 à 14h
Semaine du 16 novembre 2015
Semaine du 7 décembre 2015
Semaine du 11 janvier 2016
Vendredi 15 janvier 2016
Dimanche 17 janvier 2016
Semaine du 18 janvier 2016
5.2
Événement
Remise du Sujet
Rendu dossier préliminaire
Retour des enseignants sur le dossier préliminaire
Premier TP avancement projet
Dernier TP avancement projet
Rendu du rapport
Rendu des travaux d’implémentation
Oral projet
Modalités de rendu
Le dossier préliminaire devra être rendu sur papier. Il devra être remis au
délégué du groupe de TP qui se chargera de récupérer l’ensemble des copies
de son groupe et de les amener à Muriel DE GUIBERT (1er étage bat. F).
Les travaux d’implémentation ainsi que le rapport devront être rendus
via SVN à l’adresse suivante :
http://cregut.svn.enseeiht.fr/2015/2IMA/GLS/$USER
où $USER est votre identifiant ENSEEIHT.
Attention, lorsqu’une date précise de rendu est spécifiée, celle-ci ne doit
pas être dépassée. Tout élément rendu en retard ne sera pas considéré. Nous
prendrons comme référence, pour le SVN, le dernier commit précédant 23h59
du jour de rendu. Vous pouvez faire autant de "commit" que vous voulez,
n’hésitez donc pas à en faire bien avant la date limite !
Les fichiers rendus sur le SVN devront suivre la nomenclature suivante
(une pénalité sera appliquée sur la note dans le cas contraire) :
Ressource
Méta-modèle ecore
Méta-modèle exporté en image
Contraintes OCL
Afficheur Sirius
Exportateur html
Grammaire Xtext
Requêtes java
Exemples édités en xmi
Exemples édités en xtext
Exemples affichés graphiquement
Rapport
Nom
scenario.ecore
scenario.<png/jpg/jpeg>
scenario.OCLInEcore
scenario.design
toHtml.mtl
scenario.xtext
<nomRequete>.java
<nomExemple>.xmi
<nomExemple>.scenario
<nomExemple>.<png/jpg/jpeg>
rapport.pdf
8