Project

General

Profile

CdC » History » Version 14

Version 13 (Guillaume Babin, 01/28/2013 10:52 PM) → Version 14/19 (Romain BOBO, 01/29/2013 02:22 PM)

h1. Cahier des charges

h2. Objectif général

L'objectif est de concevoir un éditeur textuel et graphique pour le langage de programmation Lustre sous une approche basée sur l'ingénierie des modèles, en utilisant l'outil ObeoDesigner. Les deux vues du programme édité doivent être synchronisées.


h2. Fonctionnalités

h3. Éditeur textuel

* A.1 : projet xText
L'éditeur textuel doit être techniquement un projet xText
* A.2 : coloration syntaxique
Il devra offrir une coloration syntaxique automatique
adaptée au langage de programmation Lustre
* A.3 : auto indentation
Le code doit être indenté automatiquement lors de la saisie, et il doit être également possible de réindenter tout le code de la page grâce à un bouton/raccourci
* A.4 : auto complétion
L'éditeur doit pouvoir offrir une fonction d'auto complétion, similaire à celle que l'on peut connaître lorsque l'on développe en Java sous Eclipse
* A.5 : gestion des imports de bibliothèques
L'éditeur doit également gérer les imports de bibliothèques effectués au début de chaque fichier, afin de mettre à jour la fonction d'auto complétion


h3. Éditeur graphique

* B.1 : éditeur de type "boîtes ``boîtes et flèches" flèches''
L'éditeur graphique doit être un éditeur de type "boîtes et flèches", c'est à dire qu'il ne sera composé que de boîtes (noeuds, opérateurs élémentaires), et de flèches (entrées/sorties d'un noeud donné)
* B.2 : utilisation de ObeoDesigner
L'éditeur graphique doit être développé grâce à ObeoDesigner, en adoptant une logique basée sur l'Ingéniérie des Modèles
* B.3 : palette graphique pour les différents opérateurs
Il doit exister une palette graphique proposant l'utilisation de différents opérateurs élémentaires du langage Lustre (+, -, *, /, when, ...)
* B.4 : palette graphique pour les nœuds du fichier en cours d'édition
La palette graphique doit également pouvoir fournir les différents noeuds qui sont déjà développés, ou qui sont actuellement développés dans l'éditeur
* B.5 : un modèle Lustre doit être vu comme une librairie de nœuds
Le programme Lustre est une liste de noeuds, il peut (doit) donc être représenté comme une librairie de noeuds
* B.6 : possibilité d'ouvrir les différents nœuds pour les visualiser
L'éditeur graphique doit permettre de visualiser en détail chaque noeud, et ce récursivement
* B.7 : possibilité de modifier les spécifications (entrées/sorties) d'un nœud donné
Il doit être possible de modifier la signature d'un noeud, supprimer/ajouter des entrées/sorties
* B.8 : possibilité d'afficher le code correspondant à un nœud donné
Il doit être possible de visualiser le code Lustre correspondant au noeud sélectionné
* B.9 : placement automatique basique des nœuds à l'ouverture d'un fichier Lustre (un placement automatique très élégant des nœuds n'est pas un objectif du projet)
Lors de la génération de la vue graphique du programme, les noeuds doivent être placés automatiquement pour gagner en visibilité. Un placement parfait n'est pas nécessaire
* B.10 : la modification du placement des nœuds doit être sauvegardée; en particulier pour les bibliothèques chargées
Les noeuds peuvent être déplacés par l'utilisateur. Le positionnement doit être conservé afin que l'utilisateur n'ait pas à refaire ce travail à chaque ouverture de l'éditeur graphique, surtout lorsque le nombre de noeuds devient important
* B.11: positionnement (si possible) des ports entrée/sortie (input à gauche, sortie à droite)
Les ports des noeuds doivent être organisés, c'est à dire les entrées à gauche, et les sorties à droite


h3. Éditeurs textuel et graphique

* C.1 : meta-modèle Ecore
Les deux éditeurs sont
basés sur le méta-modèle un meta-modèle Ecore du langage Lustre. Le programme est défini par son modèle, défini par le méta-modèle Ecore précédent Lustre
* C.2 : chargement de fichiers Lustre (extension .lus)
Les éditeurs doivent fonctionner avec des programmes Lustre (extension .lus) classiques à l'ouverture
* C.3 : enregistrement de fichiers Lustre
Les éditeurs doivent enregistrer le programme comme un fichier Lustre (extension .lus) classique
* C.4 : possibilité de partir d'une feuille blanche
Il doit être possible de créer un programme Lustre à partir de 0
* C.5 : éditeurs textuel et graphique synchronisés
Les éditeurs graphique et textuel doivent être synchronisés, c'est à dire qu'une
toute modification du code dans l'éditeur graphique textuel doit être répercutée dans l'éditeur textuel, graphique, et inversement vice versa (synchronisation)
* C.6 : le code Lustre doit être propre
Le code Lustre doit être
le plus propre possible, c'est à dire qu'il ne doit pas y figurer possible (notamment, les informations propres relatives au placement graphique des noeuds dans l'éditeur graphique nœuds ne doivent pas s'y trouver)

h3. De manière générale

* D.1 : documentation
Le projet doit être documenté, afin
de permettre qualité permettant l'amélioration future par d'autres équipes (méthode de construction, grammaire)
* D.2 : code de qualité
Le code doit être suffisamment clair pour permettre
permettant une bonne maintenabilité
* D.3 : conception modulaire
La conception du projet doit permettre l'ajout
permettant L'ajout futur d'extension au langage telles que les arguments const, les tableaux, les matrices et les informations de spécification
* D.4 : licence EPL (Eclipse Public License)
Le projet doit à la fin être sous licence EPL, il doit donc être proprement conçu
* D.5 : le programme final sera reversé dans le marketplace Obeo http://marketplace.obeonetwork.com ou sur https://github.com/ObeoNetwork

h3. Éventuellement, les fonctionnalités suivantes pourront être envisagées

* E.1 : éditeur graphique : palette graphique dynamique
Il peut y avoir
la possibilité d'importer des nœuds depuis d'autres fichiers Lustre dans la palette graphique (chargement dynamique de bibliothèque)
* E.2 : gestion de la spécification
Il peut être possible de gérer la spécification
(préconditions, invariants et postconditions) des nœuds stockée en commentaire dans le fichier Lustre. On pourra s'inspirer à cet effet du langage de spécification ACSL pour le C http://frama-c.com/acsl.html