Project

General

Profile

CdC » History » Version 15

« Previous - Version 15/19 (diff) - Next » - Current version
Guillaume Babin, 01/29/2013 06:24 PM


Cahier des charges

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.

Fonctionnalités

Éditeur textuel

  • LE-TXT-001 : projet xText
    L'éditeur textuel doit être techniquement un projet xText
  • LE-TXT-002 : coloration syntaxique
    Il devra offrir une coloration syntaxique automatique adaptée au langage de programmation Lustre
  • LE-TXT-003 : 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
  • LE-TXT-004 : 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
  • LE-TXT-005 : 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

Éditeur graphique

  • LE-GRPH-001 : éditeur de type "boîtes et 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é)
  • LE-GRPH-002 : 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
  • LE-GRPH-003 : 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, ...)
  • LE-GRPH-004 : 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
  • LE-GRPH-005 : 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
  • LE-GRPH-006 : 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
  • LE-GRPH-007 : 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
  • LE-GRPH-008 : possibilité d'afficher le code correspondant à un nœud donné
    Il doit être possible de visualiser le code Lustre correspondant au noeud sélectionné
  • LE-GRPH-009 : 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
  • LE-GRPH-010 : 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
  • LE-GRPH-011: 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

Éditeurs textuel et graphique

  • LE-COM-001 : meta-modèle Ecore
    Les deux éditeurs sont basés sur le méta-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
  • LE-COM-002 : chargement de fichiers Lustre (extension .lus)
    Les éditeurs doivent fonctionner avec des programmes Lustre (extension .lus) classiques à l'ouverture
  • LE-COM-003 : enregistrement de fichiers Lustre
    Les éditeurs doivent enregistrer le programme comme un fichier Lustre (extension .lus) classique
  • LE-COM-004 : possibilité de partir d'une feuille blanche
    Il doit être possible de créer un programme Lustre à partir de 0
  • LE-COM-005 : éditeurs textuel et graphique synchronisés
    Les éditeurs graphique et textuel doivent être synchronisés, c'est à dire qu'une modification dans l'éditeur graphique doit être répercutée dans l'éditeur textuel, et inversement
  • LE-COM-006 : 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 les informations propres au placement des noeuds dans l'éditeur graphique

De manière générale

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

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

  • LE-SUP-001 : é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)
  • LE-SUP-002 : 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