Cahier des Charges - Ebauche¶

Présentation générale du projet¶

Finalités¶

Définir une plateforme de gestion d'expériences en évolution artificielle contenant :

• un système d'information pour l'archivage des expériences
• un système de préparation des expériences
• un système de lancement des expériences grâce à des exécutables externes
• un système d'archivages des expériences
• des outils statistiques et graphiques permettant l'analyse des expériences.

Cette plateforme doit être conçue et implémentée de façon à ce qu'elle soit opérationnelle à la fin du projet.

• Situation du projet
  A ce jour, il n'existe aucune plateforme proposant ces fonctionnalités. Ce qui se rapproche le plus sont les interfaces graphiques développées sur les framework comme EO (http://eodev.sourceforge.net/) et ECJ (http://cs.gmu.edu/~eclab/projects/ecj/).
  Les techniques utilisées sont pour le moment un formalisme d'archivage propre à chaque chercheur, difficilement partageable et réutilisable.

• Suites prévues
  Une gestion plus avancée des exécutions des expériences :
  • le serveur choisira l'expérience à lancer en fonction de sa charge actuelle
  • une exécution répartie

• Caractère confidentiel
  L'accès (créations, modifications, suppressions) aux expériences doit être réservé aux utilisateurs habilités.

• Définitions
  • Expérience (≡ projet) :
    • Un ensemble de simulations
    • Réponse à une question
  • Simulation :
    • Exécution de l'algorithme
    • Issu d'un modèle
    • Résultats bruts
  • Analyse :
    • Traitements
    • Résultats (courbes, tableaux, ...) observables par des humains

Fonctionnalités¶

• La plate-forme est une architecture n-tiers (client, serveur Web, serveur, base de données) sur lequel les utilisateurs enregistrés pourront créer, modifier, supprimer une expérience consultable par tous les utilisateurs.

• Les paramètres de simulation ainsi que les traitements à effectuer sur les résultats obtenus seront directement configurables à partir de l'interface en utilisant un formulaire. De plus si un utilisateur trouve les traitements déjà disponibles insuffisants ou non pertinents pour son expérience, il pourra ajouter de nouveaux traitements génériques (mécanisme similaire aux Plugins).

• Une fois l'expérience exécutée le site proposera un système d'archivage des résultats et de la description des traitements effectués (et leurs significations) pour que n'importe quel utilisateur puissent recréer cette expérience et retrouver ces résultats s'il le souhaite.
  Un utilisateur aura donc la possibilité de consulter les archives du site et toute autre donnée mise à disposition (comme le code source d'une expérience s'il a été fournis avec).

• Il sera aussi possible de voir l'état de toutes les expériences lancées sur le serveur, à savoir si elles sont en attente, en cours d'exécution, ou terminées (ordonnancement des expériences).

• Enfin pour l'archivage de chaque expérience lancée il sera possible de supprimer ou non les fichiers générés par les traitements ou les fichiers de données brutes pour ne garder que le fichier de description des traitements de l'expérience.

Contraintes non fonctionnelles¶

• Plate-forme matérielle
  • Serveur web.

• Annexes techniques - Choix de la technologie :
  • Ruby : Langage de programmation orienté objet, multi-plate-forme.
  • Ruby On Rails : Framework web libre en Ruby
  • YAML : Langage informatique de balisage générique pour le transfert de contenus entre systèmes d'informations lisible par un humain
  • MySQL : Base de données libre

Gestion du projet¶

Priorités¶

• version 1 :
  • Évaluer un fichier de description et de configuration
  • Archiver les données générées
  • Donner accès aux données de l'archive (et à l'archive elle-même)
  • Création via l'interface web du fichier de description des traitements de l'expérience
• version 2 (prévue):
  • Ordonnancement basique des tâches
  • Ajouter des traitements génériques
• version 3 :
  • Importer une archive contenant une expérience déjà exécutée.
  • Affichage plus intuitif pour la création/modification du fichier de description des traitements
• version 4 :
  • Ordonnancement amélioré des tâches
  • Exécution répartie

Limites et interfaces¶

• La charge du serveur n'est pas gérée par la plate-forme.
• L'exécution des programmes est déléguée au système.

Hypothèses, dépendances, contraintes¶

• Les fichiers de configuration et de descriptions des traitements doivent être au format YAML. L’utilisateur aura deux possibilités :
  • fournir un fichier YAML en plus du programme
  • fournir le programme seul, la plate-forme permettra alors la création de la description et de la configuration via son interface
• L’interface doit être écrite en anglais afin de permettre une utilisation internationale de la plate-forme
• Les compilations nécessaires (non multi-plate-forme) seront réalisées sur le serveur
• Les exécutions seront commandées par le serveur
• Concernant la sécurité, une gestion basique des utilisateurs (administrateur/membres/visiteurs) sera mise en place
• La plate-forme devra supporter des envois de données de grande taille (de l'ordre de la centaine du MégaOctet)

Gestion du risque¶

• La réalisation de prototypes de la norme de description afin de faire ressortir les problèmes éventuelle nécessitant la validation des encadrants
• La réalisation de prototypes des fonctionnalités jugées critiques de l'interface Web (Formulaire dynamique, gestion de la session, ...)
• La réalisation de prototypes d'envoi des données de grande taille (script CGI) avant de commencer le développement de la version 4
• La réalisation de prototypes d'exécution d'un programme externe délégué au système d'exploitation depuis notre plate-forme
• L’interface étant écrite en Anglais, une vérification par une personne anglophone permettra d’éviter des erreurs de grammaire ou de style

Moyens de contrôle¶

Les moyens de contrôle du bon fonctionnement de notre application sont :

• Des fichiers d'exemples qui nous permettrons de vérifier que la requête d'un utilisateur à bien été transformée en la bonne suite d'actions, cela en comparant les appels obtenus par l'interprétation du fichier YAML et les appels réalisés par les scripts dans ces fichiers d'exemple (vérification de la norme YAML)
• Des scénarios d'utilisation qui nous montreront si notre application couvre bien les attentes des utilisateurs
• Une vérification régulière par les encadrants

Méthodes et outils employés¶

• La description et la configuration d'une expérience et de ses traitements seront sous la forme d'un fichier YAML. Ce fichier répondra donc à une norme qui lui permettra d'être générée par l'application suite à l'envoi d'un formulaire par l'utilisateur ou bien édité à la main; il sera ensuite analysé pour être converti en une suite d'actions sur le serveur.
• Ruby est multi-plate-forme et permettra une plus grande souplesse dans les relations entre le serveur web et les parties fonctionnelles (analyseur, ordonnanceur)
• Ruby On Rails est un framework web libre
• MySQL permettra le stockage des données de la plate-forme

Planning¶