Project

General

Profile

CdC » History » Version 12

Version 11 (Pierre-Loïc Garoche, 01/28/2013 04:41 PM) → Version 12/19 (Guillaume Babin, 01/28/2013 10:51 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
* A.2 : coloration syntaxique adaptée au langage Lustre
* A.3 : auto indentation
* A.4 : auto complétion
* A.5 : gestion des imports de bibliothèques

h3. Éditeur graphique

* B.1 : éditeur de type ``boîtes et flèches''
* B.2 : utilisation de ObeoDesigner
* B.3 : palette graphique pour les différents opérateurs
* B.4 : palette graphique pour les nœuds du fichier en cours d'édition
* B.5 -B.5 : un modèle Lustre doit pouvoir être vu comme un programme avec un nœud principal- (Non, uniquement comme une librairie, cf B.6 - PLG)
* B.6 : un modèle Lustre doit pouvoir être vu soit comme une
librairie de nœuds
* B.6 B.7 : possibilité d'ouvrir les différents nœuds pour les visualiser
* B.7 B.8 : possibilité de modifier les spécifications (entrées/sorties) d'un nœud donné
* B.8 B.9 : possibilité d'afficher le code correspondant à un nœud donné
* B.9 B.10 : 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)

*Rajout - PLG*

* B.10 : *B.10 bis: la modification du placement des nœuds doit être sauvegardée; en particulier pour les bibliothèques chargées chargées*
* B.11: *B.11: positionnement (si possible) des ports entrée/sortie (input à gauche, sortie à droite) droite)*

h3. Éditeurs textuel et graphique

* C.1 : basés sur un meta-modèle Ecore du langage Lustre
* C.2 : chargement de fichiers Lustre (extension .lus)
* C.3 : enregistrement de fichiers Lustre
* C.4 : possibilité de partir d'une feuille blanche
* C.5 : toute modification du code dans l'éditeur textuel doit être répercutée dans l'éditeur graphique, et vice versa (synchronisation)
* C.6 : le code Lustre doit être le plus propre possible (notamment, les informations relatives au placement graphique des nœuds ne doivent pas s'y trouver)

h3. De manière générale

* D.1 : documentation de qualité permettant l'amélioration future par d'autres équipes (méthode de construction, grammaire)
* D.2 : code de qualité permettant une bonne maintenabilité
* D.3 : conception permettant d'ajout futur d'extension au langage telles que les arguments const, les tableaux, les matrices *et les informations de spécification (PLG)*
* D.4 : licence EPL (Eclipse Public License)
* 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 textuel : l'enroulage de code (folding)- (inutile - PLG)
* E.2 :
éditeur graphique : la possibilité d'importer des nœuds depuis d'autres fichiers Lustre dans la palette graphique (chargement dynamique de bibliothèque)
* E.2 E.3 : gestion de 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