N7 2IMA GÉNIE DU LOGICIEL ET DES SYSTÈMES Projet 2 2016-2017 Projet de Génie du Logiciel et des Systèmes : 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 2016-2017 de l UE GLS. 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 conception sur papier et une partie implémentation en utilisant les outils du projet Eclipse Modelling pris en main au cours du module. Deux rapports seront rendus au cours du projet : un dossier préliminaire de conception qui sera suivi d un retour des enseignants et un rapport de projet qui devra contenir les détails d implémentations et les difficultés par rapport au dossier de conception ainsi que toute autre information jugée pertinente par les étudiants. 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 remise sont précisé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 présentation du projet et la remise du présent sujet. Table des matières 1 Objectifs du projet 2 1.1 Modélisation de jeux d exploration........................... 3 1.2 Vérification de l existence de la solution dans un jeu................. 5 1.3 Validation de la transformation en réseau de Petri................... 5 1.4 Génération de prototypes................................ 5 2 Déroulement du projet 6 2.1 Tâches à réaliser.................................... 6 2.2 Documents à rendre................................... 7 2.3 Dates importantes.................................... 8 Projet 2 1/8
Attention : Des informations complémentaires, en particulier concernant les échéances, les documents à rendre, l évaluation... peuvent être données sur la page du module. Ce projet consiste à produire une chaîne de modélisation, de vérification et de génération de code pour des jeux de parcours/découverte. La modélisation consiste à concevoir un langage dédié pour décrire le jeu sous la forme d un modèle et à implanter les outils d édition et de visualisation associés. La vérification permet d assurer qu il existe une solution pour le jeu décrit par un modèle. Pour répondre à cette question, nous utilisons les outils de model-checking définis sur les réseaux de Petri au travers de la boîte à outils Tina. Il nous faudra donc traduire un modèle de jeu en un réseau de Petri. La génération de code permet de construire un prototype avec une interface texte simple permettant de tester le jeu décrit par un modèle et de valider la jouabilité et l intérêt du jeu avant de développer le contenu multimédia. Vous utiliserez les différents outils exploités en TP et pendant le BE : Xtext, Sirius, Acceleo, ATL. Vous réutiliserez le métamodèle des réseaux de Petri et la traduction vers le format Tina qui ont été réalisées pendant les TPs/BE. Contrairement aux TPs/BE, le métamodèle sera généré à partir de la syntaxe concrète du langage définie en Xtext et les contraintes OCL ne seront pas intégrées dans le métamodèle avec OCLinEcore mais spécifiées dans un fichier séparé en utilisant CompleteOCL. 1 Objectifs du projet Ce projet consiste pour l essentiel à définir une chaîne de modélisation, vérification et génération de code pour des modèles de jeux (leur description est donnée en section 1.1). Les principales étapes sont les suivantes : 1. Définition de la syntaxe concrète du langage de modélisation de jeu en utilisant Xtext et génération du métamodèle Ecore. Cette solution permet de travailler plus facilement en équipe et de préserver, autant que possible, les exemples réalisés précédemment lors d évolution du métamodèle (contrairement au format XMI). 2. Définition de la sémantique statique avec OCL dans un fichier séparé du métamodèle créé avec l éditeur CompleteOCL. Vous n utiliserez pas OCLinEcore comme en TP/BE car la combinaison avec la génération du métamodèle avec Xtext est complexe. 3. Utilisation de l infrastructure fournie par EMF pour manipuler les modèles. Celle-ci est généré automatiquement par Xtext. Le code généré peut être modifié pour que la vérification des contraintes OCL soit intégrée à la validation dans l éditeur texte produit par Xtext. 4. Définition d une transformation de modèle à texte (M2T) avec Acceleo, pour engendrer les propriétés LTL à partir d un modèle de jeu. Vous réutiliserez la transformation des réseaux de Petri vers la syntaxe concrète de Tina réalisée pendant les TPs/BE. 5. Définition de syntaxes concrètes graphiques avec Sirius pour les points de vue Territoire et Dialogue. 6. Définition d une transformation de modèles à modèles (M2M) avec ATL pour produire un réseau de Petri à partir d un modèle de jeu. Vous réutiliserez le métamodèle des réseaux de Petri réalisé pendant les TPs/BE. 7. Définition d une transformation de modèle à texte (M2T) avec Acceleo, pour générer un prototype d implantation du jeu à partir d un modèle de ce jeu. Le code généré utilisera le langage et les bibliothèques choisis par chaque groupe. Projet 2 2/8
1.1 Modélisation de jeux d exploration Nous vous proposons de concevoir un langage dédié (Domain Specific Modeling Language) pour modéliser les jeux d exploration. Une analyse des besoins/recueil des exigences a permis d obtenir les informations suivantes : E 1 L objectif d un jeu d exploration est de visiter un territoire composé de lieux connectés par des chemins. E 2 Le joueur unique est l explorateur. E 3 L explorateur possède un nombre illimité de connaissances et un nombre limité d objets. E 4 Un explorateur peut posséder plusieurs exemplaires d un même objet. E 5 Chaque objet est qualifié par sa taille. E 6 Le nombre d objets que peut posséder un explorateur est limité par la taille cumulée des objets possédés. E 7 Les connaissances et les objets que l explorateur possède au début du jeu dépendent du niveau de difficulté choisi. E 8 Les lieux explorés peuvent contenir des connaissances, des objets et des personnes. E 9 Le point de départ et les points de fin de l exploration sont des lieux particuliers. E 10 Les connaissances, les objets et les personnes contenus dans un lieu peuvent être visibles/actifs ou invisibles/inactifs selon des conditions. E 11 Les chemins peuvent être ouverts ou fermés selon des conditions. E 12 Lorsqu il se trouve dans un lieu, l explorateur reçoit les connaissances visibles contenues par le lieu. E 13 Lorsqu il se trouve dans un lieu, l explorateur peut prendre les objets visibles de son choix. E 14 Lorsqu il se trouve dans un lieu, si cela est autorisé par des conditions, l explorateur peut déposer les objets de son choix. E 15 Les objets déposés sur un lieu resteront sur place et pourront être repris ultérieurement par l explorateur. E 16 Les chemins dans un lieu peuvent être obligatoires ou choisis par l explorateur. E 17 Il ne peut y avoir qu un seul chemin obligatoire visible et ouvert par lieu. E 18 Un chemin obligatoire, visible et ouvert est franchi automatiquement par l explorateur dès qu il arrive dans le lieu après les interactions avec les personnes présentes obligatoires. E 19 Lorsqu il se trouve dans un lieu, l explorateur peut emprunter un chemin visible et ouvert de son choix. E 20 Le passage par un chemin peut transmettre à l explorateur des connaissances et des objets. E 21 Le passage par un chemin peut consommer des objets possédés par l explorateur. E 22 Les connaissances transmises et les objets transmis et consommés lors du passage par un chemin peuvent dépendre de conditions. E 23 Les conditions sont des combinaisons logiques des connaissances et objets possédés par l explorateur ainsi que du niveau de difficulté du jeu. Les conditions peuvent dépendre du nombre d exemplaires d un objet (relation de comparaison avec des constantes). Pour des raisons de simplicité, les conditions seront écrites en forme normale disjonctive. Projet 2 3/8
E 24 Une part aléatoire peut être introduite explicitement dans les conditions. E 25 Les personnes visibles dans un lieu peuvent interagir avec l explorateur. E 26 Les personnes peuvent être obligatoires ou choisies par l explorateur. E 27 Il ne peut y avoir qu une seule personne obligatoire par lieu. E 28 Une personne obligatoire débute son interaction dès que le joueur arrive dans le lieu. E 29 Les interactions permettent à l explorateur de recevoir des connaissances et des objets. E 30 Les interactions prennent la forme de choix. E 31 Le choix de début de l interaction peut dépendre de conditions. E 32 Un choix consiste à proposer à l explorateur plusieurs actions. E 33 L explorateur doit choisir une action ou quitter l interaction s il s agit d un choix de fin. E 34 Le fait qu un choix soit un choix de fin peut dépendre de conditions. E 35 Les actions proposées dépendent de conditions et des choix précédents de l explorateur. E 36 Une action peut attribuer à l explorateur des connaissances et des objets. E 37 Les connaissances et objets attribués dépendent de conditions. E 38 Une action peut consommer des objets de l explorateur. E 39 Les lieux, chemins, connaissances et objets sont qualifiés par une description en texte qui peut dépendre de conditions. E 40 Les objets peuvent être transformables selon des conditions. E 41 L explorateur peut décider de transformer un objet ou plusieurs qu il possède. Ceux-ci sont alors consommés et remplacés par d autres objets. E 42 Le résultat de la transformation d objets transformables peut dépendre de conditions. E 43 Les objets transformables peuvent se transformer en objets qui peuvent être transformables. Ces éléments permettent de modéliser un grand nombre de jeux différents. A titre d exemple, les objets peuvent représenter des ressources (points de vie, aliments, soins, carburant, munitions, etc); les interactions peuvent représenter des combats, des déplacements complexes, des énigmes, etc; les objets transformables peuvent représenter des soins qui se transforment en points de vie, des aliments qui se transforment en énergie, des recettes de fabrication d objets à partir de ressources; etc. Exemple 1 : On modélise un jeu d énigme. Le territoire est composé de trois lieux, un de début nommé Enigme et deux de fin qui représentent le succès, nommé Succès, et l échec, Echec. Ces trois lieux sont qualifiés par leur nom. Le nombre de réponses possibles est représenté par un objet Tentative dont l explorateur possède un nombre initial, par exemple 3. Le lieu Enigme contient une personne Sphinx qui est visible et obligatoire. Cette personne est qualifiée par le texte de la question. Son interaction contient un choix dont chaque action est qualifiée par les réponses possibles. L action associée aux mauvaises réponses consomme un objet Tentative. L action associée aux bonnes réponses donne une connaissance Réussite. Il existe un chemin obligatoire allant du lieu Enigme au lieu Succès dont la visibilité est conditionnée par la possession de la connaissance Réussite. Il existe un chemin obligatoire allant du lieu Enigme au lieu Echec dont la visibilité est conditionnée par la possession d un nombre d objet Tentative égal à 0. Projet 2 4/8
1.2 Vérification de l existence de la solution dans un jeu La complexité d un modèle de jeu peut être telle que le concepteur ne pourra plus déterminer si le jeu possède une solution. Nous proposons d utiliser les outils de vérification de modèles de la boite à outils Tina pour vérifier que les états de fin sont atteignables. Il est pour cela nécessaire de traduire les modèles de jeu en réseau de Petri et de générer les propriétés de logique temporelle exprimant l existence d une ou plusieurs solutions pour le jeu. Vous pourrez également générer une propriété permettant de synthétiser un contre-exemple constituant une solution pour chaque lieu de fin du jeu. 1.3 Validation de la transformation en réseau de Petri Comme pour tout programme écrit, il est important de valider la transformation de modèle. Afin de valider la transformation des modèles de jeu en réseau de Petri, une possibilité est de vérifier que la sémantique des éléments d un jeu est préservée par le modèle de réseau de Petri correspondant. Ces invariants sont appelés propriétés de sûreté. En voici quelques exemples : L explorateur ne peut être présent que dans un seul lieu à la fois; une interaction ne peut présenter qu un seul choix à la fois. On peut alors écrire une transformation modèle à texte qui traduit ces propriétés de sûreté sur le modèle de Petri. L outil selt permettra alors de vérifier si elles sont effectivement satisfaites sur le modèle de réseau de Petri. Si ce n est pas le cas, c est que la traduction contient une erreur ou que l invariant n en est pas un! 1.4 Génération de prototypes Le concepteur du jeu doit déterminer si celui-ci est intéressant avant de démarrer le développement de la partie multimédia du jeu (images, sons, musiques, vidéos, etc) qui est la plus coûteuse. Nous proposons dans ce but de générer un prototype interactif en mode texte dans le langage de programmation de votre choix, en utilisant les bibliothèques de votre choix. L objectif est la simplicité du code généré et de la transformation qui génère le code. Le prototype peut être rudimentaire. L analyse des besoins/recueil des exigences a permis d obtenir les connaissances suivantes : P 1 Le prototype doit afficher à la demande du joueur les informations sur les connaissances et les objets possédés par l explorateur ainsi que le nombre d objets et la capacité de stockage disponible. P 2 Le prototype doit afficher le lieu courant dans lequel se trouve l explorateur. P 3 Le prototype doit afficher à la demande du joueur les connaissances, les objets, les personnes et les chemins présents et visibles dans le lieu courant. P 4 Le prototype doit lancer les interactions automatiques avec les personnes présentes dans un lieu dès que l explorateur entre dans ce lieu, y compris pour le lieu de départ du jeu. P 5 Le prototype doit prendre les chemins automatiques visibles et ouverts après avoir lancé les interactions automatiques. P 6 Le prototype doit demander au joueur ce qu il souhaite faire quand il se trouve dans un lieu après avoir exécuté les interactions automatiques : afficher des détails à la demande sur les connaissances et les objets qu il possède. afficher des détails à la demande sur le lieu courant. interagir avec une personne présente et visible dans le lieu courant. prendre un objet présent et visible dans le lieu courant. Projet 2 5/8
déposer un objet dans le lieu courant. utiliser un chemin visible et ouvert dans le lieu courant. P 7 Les données affichées correspondent au qualificatif texte associé aux lieux, connaissances, aux objets et aux personnes. P 8 Lors d une interaction, le prototype doit présenter au joueur les différentes actions possibles dans le choix courant dans l interaction et lui demander soit de choisir une action parmi celles-ci, soit de quitter l interaction si le choix courant est un choix de fin. P 9 Lorsque le joueur a choisi une action, le prototype doit modifier les connaissances et les objets de l explorateur en fonction du choix et modifier le choix courant puis poursuivre l interaction. 2 Déroulement du projet Ce projet est un travail de groupe qui devra être réalisé en quadrinôme constitué au sein d un même groupe de TD. Pour prendre en compte la taille des groupes de TD qui n est pas un multiple de 4, quelques trinômes seront autorisés. La composition des groupes est libre. Elle sera transmise par courrier électronique à Marc.Pantel@enseeiht.fr avant le vendredi 18 novembre 2016. Les techniques mises en œuvre doivent être celles présentées dans le module de GLS : Ecore, EMF, OCL, Xtext, Sirius, Acceleo et ATL ainsi qu un langage de programmation cible de la génération de code qui sera choisi librement par chaque groupe. Pour chaque partie, voici les tâches à réaliser, les documents à rendre par chaque groupe et les dates de remise. 2.1 Tâches à réaliser T 1 Définir une syntaxe concrète textuelle pour les modèles de jeu avec Xtext puis générer le métamodèle associé. T 2 Modéliser l exemple donné en fin de section 1.1 avec la syntaxe textuelle proposée pour votre langage. T 3 Réaliser une conception préliminaire de la transformation de modèles de jeux vers les réseaux de Petri. Il s agit de prendre l exemple précédent et de construire le réseau de Petri correspondant attendus. Le réseau de Petri sera construit avec l outil nd de Tina. T 4 Réaliser une conception préliminaire du générateur de code à partir de modèles de jeux. Il s agit de prendre l exemple précédent et de programmer le code correspondant attendu. L exemple sera exprimé avec la syntaxe textuelle précédente. Le code sera exprimé dans le langage de programmation que le groupe aura choisi. T 5 Valider la pertinence, la complétude et l usabilité de ce langage en rédigeant des tests plus simples pour chaque élement du langage ainsi qu un test réaliste combinant toutes les capacités du langage. Les tests seront exprimés avec la syntaxe concrète textuelle. Il n est pas utile de faire des tests au format XMI avec l éditeur arborescent. Les fichiers XMI seront générés à partir des modèles textuels avec l outil générique de traduction de modèles textes gérés par Xtext vers du XMI inclus dans la distribution Eclipse GLS (dernière entrée du menu en faisant un clic droit sur un fichier texte valide géré par Xtext). T 6 Définir les contraintes OCL pour capturer les contraintes sur les modèles de jeu qui n ont pu l être par les métamodèles. Projet 2 6/8
T 7 Valider la pertinence et la complétude des contraintes en rédigeant des tests élémentaires ne respectant pas les contraintes et en montrant que les tests rédigés précédemment respectent les contraintes. T 8 Développer un éditeur graphique avec une vue présentant la partie territoire d un modèle de jeux, et une vue présentant les parties interaction d un modèle de jeux. Ces vues seront complétées par des contrôleurs pour pouvoir saisir graphiquement des éléments dans les modèles de jeux visualisés. T 9 Implanter la transformation de modèles de jeux vers les réseaux de Petri en utilisant ATL. T 10 Valider cette transformation en utilisant les tests rédigés précédemment. T 11 Implanter le générateur de code pour produire les prototypes dans le langage de votre choix en utilisant Acceleo. T 12 Valider cette transformation en utilisant les tests rédigés précédemment. T 13 Implanter un générateur de propriétés LTL permettant de vérifier l existence d une solution pour un modèle de jeu. T 14 Valider ce générateur en utilisant les tests rédigés précédemment. T 15 Implanter un générateur de propriétés LTL correspondant aux invariants des modèles de jeu pour valider la transformation écrite (voir section 1.3). T 16 Valider ce générateur en utilisant les tests rédigés précédemment. 2.2 Documents à rendre Les consignes pour rendre les documents suivants seront données sur la page du module (les documents seront rendus via SVN). D 1 Le modèle Xtext décrivant la syntaxe concrète textuelle des modèles de jeux (game.xtext). D 2 Une vue graphique mise en page du métamodèle généré par Xtext (game.png). D 3 Le modèle de jeux de l exemple 1 exprimé dans la syntaxe concrète textuelle définie avec Xtext (enigme.suffixe, utilisez le suffixe choisi lors de la création du projet Xtext). D 4 Un réseau de Petri au format Tina représentant le déroulement du jeu de l exemple 1 et les propriétés LTL exprimant l existance d une solution pour ce jeu (enigme.net et enigme.ltl). D 5 Un programme écrit dans le langage de votre choix qui exécute le jeu de l exemple 1 (enigme.suffixe, utilisez le suffixe correspondant au langage de votre choix java, py, ml, ada,...). D 6 D autres exemples de modèles de jeux (en expliquant l intérêt de chaque exemple). Ces modèles serviront à illustrer les différents éléments réalisés dans le cadre du projet. D 7 Les fichiers de contraintes OCL au format CompleteOCL associés à ce métamodèle, avec des exemples (et contre-exemples) qui montrent la pertinence de ces contraintes (game.ocl). D 8 Le code ATL de la transformation modèle à modèle des modèles de jeu vers les réseaux de Petri (game2petrinet.atl). D 9 Le code Acceleo des transformations modèle à texte vers les propriétés LTL (game2ltl.mtl) et vers le prototype dans le langage de votre choix (game2prototype.mtl). D 10 Les modèles Sirius décrivant l éditeur graphique pour les deux points de vue sur les modèles de jeux (le point de vue Territoire et le point de vue Interaction). D 11 Un document concis (rapport) qui explique le travail réalisé. Attention, c est ce document qui servira de point d entrée pour lire les éléments rendus. Projet 2 7/8
2.3 Dates importantes Jeudi 10 novembre 2016 : Présentation du Sujet en cours Mercredi 16 novembre 2016 : Remise du Sujet Vendredi 18 novembre 2016 : Remise de la composition des groupes de projet Vendredi 25 novembre 2016 : Remise du métamodèle et de la syntaxe textuelle (format Xtext et image, délivrable D 1 et D 2 ) Semaine du 28 novembre 2016 : Séance de TP avancement projet Vendredi 2 décembre 2016 : Remise du dossier de conception préliminaire (exemple de la fin de la section 1.1 écrit dans la syntaxe textuelle (délivrable D 3 ), traduction manuelle en réseau de Petri et logique temporelle au format TINA (délivrable D 4 ), traduction manuelle dans le langage de programmation choisi (délivrable D 5 ) Semaine du 5 décembre 2016 : Séance de TP avancement projet Mardi 13 décembre 2016 : Rendu des travaux d implémentation (tous les délivrables sauf D 12 ) Mercredi 14 décembre 2016 : Oral et test du projet Vendredi 16 décembre 2016 : Rendu du rapport (délivrable D 12 ) Projet 2 8/8