Spécifications Non Fonctionnelles P. C h a b r i e r, H.Raynal Rapport Projet RECORD N 2007/2- Juin 2007 Départements EA & MIA 1/9
Institut National de la Recherche Agronomique Département Environnement et Agronomie Département Mathématiques et Informatique Appliquées. Plate-forme RECORD Spécifications non Fonctionnelles Auteurs Patrick Chabrier1 & Hélène Raynal2 Contributeurs 3 Nicolas Donès, Mark R. Irvine4, Nathalie Moitrier5, Nicolas Moitrier6 Date: 15 juin 2007 1 Table des matières Introduction...3 Éléments d'architecture générale...3 Propriété intellectuelle & licence...4 Type de machine & Système d'exploitation...4 Performances...5 Langages de programmation...5 Autres logiciels & bases de données...5 Persistance...6 Documentation et support...6 Plate-forme de développement...7 Références:...7 Annexe: Glossaire...8 1 Département MIA, Unité BIA-Toulouse - Patrick.Chabrier@toulouse.inra.fr 2 Département EA, Unité BIA-Toulouse - Helene.Raynal@toulouse.inra.fr 3 UMR PIAF INRA-UBP - Nicolas.Dones@clermont.inra.fr 4 UR EFPE - Mark.Irvine@bordeaux.inra.fr 5 UMR CSE INRA-UAPV - Nathalie.Moitrier@avignon.inra.fr 6 UR PSH - Nicolas.Moitrier@avignon.inra.fr 2/9
Introduction Ce document appelé «Spécifications non fonctionnelles», constitue le 2ème volet du cahier des charges pour le projet de plate-forme RECORD. Il est constitué d'une liste de caractéristiques techniques favorables aux objectifs du projet RECORD. Il existe déjà un grand nombre d'environnements de modélisation (confer Document «Analyse de l'existant»), Comme nous souhaitons privilégier l'approche qui consiste à utiliser un logiciel existant dont on étendrait les fonctionnalités pour répondre au cahier des charges de RECORD cette grille pourra intervenir lors du choix du logiciel à réutiliser. Au final, l'architecture logicielle devra prendre en compte l'ensemble de ces critères afin d'être le plus possible en adéquation avec les objectifs du projet. Ce document a été constitué en concertation avec les ingénieurs informaticiens du département Environnement et Agronomie, et plus particulièrement avec les contributeurs mentionnés en 1ère page Les spécifications non-fonctionnelles sont présentées sous forme de listes de caratéristiques techniques organisées par grands domaines: Éléments d'architecture générale Propriété intellectuelle et licence Système d'exploitation Performances Langages de programmation Les autres logiciels et bases de données Persistance Documentation et support Plate-forme de développement Les * indiquent le niveau de priorité de la spécification ( très prioritaire, moyennement prioritaire, * intéressant mais non prioritaire). Éléments d'architecture générale 1.1 L'architecture de la plate-forme sera générique. Elle ne dépendra donc pas d'un projet de modélisation en particulier. Cette partie générique comportera : 1.2 des librairies de classes(exemples : des schémas de module de type; «équations aux différences», «événement discret», «topologie spatiale») un simulateur sous la forme d'un programme en mesure d'exécuter des modèles structurellement différents. des interfaces vers des logiciels existants de type statistique, les SGBD, les tableurs.(r, Excel, Scilab,...). des interfaces graphiques facilitant la paramétrisation des simulations, la visualisation de la dynamique des états, l'analyse des résultats des simulations. 3/9
1.3 Un modèle ou un module se présentera sous la forme d'un composant. 1.4 RECORD disposera d'un système permettant d'organiser la communication entre les modules en spécifiant explicitement leur couplage. 1.5 * Une application ergonomique et graphique permettra d'inspecter les simulateurs. L'inspection permet de visualiser toute la structure du simulateur, les modules et les relations statiques et dynamiques entre eux. 1.6 Une application ergonomique et graphique permettra de piloter les simulations avec des fonctionnalités comme; pas à pas, suivi graphique, sauvegarde à chaud. 1.7 Une interface de type «glue» (perl, python, tcl,...)sera disponible pour modéliser, afin d'écrire rapidement différentes logiques d'utilisations d'un modèle. 1.8 Un simulateur devra être exécutable sous la forme d'une ligne de commande. 1.9 Un simulateur bénéficiera d'un fichier de configuration portant à la fois sur les paramètres et la structure du modèle(approche déclarative). * Une application ergonomique et graphique permettra d'éditer un modèle sans programmation(comme avec Modelmaker, Simile, Vensim) avec des fonctionnalités classiques comme; gestion de version, undo/redo, persistance. Cette proposition est complémentaire à l'approche modélisation par la programmation. 1.10 Propriété intellectuelle & licence 1.1 Les développements de la plate-forme effectués par l'équipe RECORD porteront un copyright INRA. 1.2 La licence de la plate-forme sera de type Open-Source. 1.3 Les projets choisiront leur licence. Type de machine & Système d'exploitation 1.4 La plate-forme de modélisation devra être utilisable sur un poste de travail individuel de type PC. 1.5 Les simulateurs devront être exécutables directement sur des postes de travail individuels. 1.6 La plate-forme devra bénéficier d'un serveur de calcul dédié, avec tous les outils nécessaires installés en permanence pour pouvoir effectuer des simulations. 1.7 La plate-forme de modélisation sera disponible sous Unix et sous Windows. 4/9
Performances La performance des simulateurs est une question très importante, notamment lorsque l'on veut modéliser des interactions spatiales et utiliser des méthodes de méta-modélisation. Dans ces 2 cas le nombre de simulations atomiques peut-être très important. Il est très difficile d'avoir des éléments en terme de performance à priori. Record devra être vigilant à cet aspect, surtout en phase de construction. 1.8 Sur la base d'un certains nombre de cas, des tests de performance seront disponibles. Ils permettront à l'utilisateur de «se faire une idée» des performances dont-il pourra bénéficier en extrapolant à son modèle. 1.9 La plate-forme doit bénéficier d'un langage de programmation natif, autorisant des optimisations au niveau de la programmation. Langages de programmation Il faut distinguer le langage de programmation pour développer la plate-forme de modélisation, du langage de programmation pour développer un simulateur. Autant au niveau plate-forme, il est difficile d'imaginer de la flexibilité, autant au niveaux des langages utilisés dans les projets, cette contrainte sera moins forte. En effet, il existe plusieurs technologies qui permettent de s'affranchir plus ou moins de la contrainte du langage. Certaines de ces technologies seront implémentées sur RECORD.. Le langage de développement de la plate-forme sera Orienté Objet 1.11 Les simulateurs pourront être programmés dans différents langages directement dans le langage de la plate-forme ou avec un autre langage ( dans la limite des capacités de l'outils SWIG par exemple, http://www.swig.org/) 1.12 La plate-forme de modélisation doit être en mesure de s'interfacer avec des simulateurs développés dans d'autres langages (par exemple en fortran). 1.10 Autres logiciels & bases de données. Un certain nombre d'applications existantes seront utiles pour travailler avec les simulateurs construits sous RECORD. Pour cela, la plate-forme proposera des interfaces spécifiques, voire même une intégration dans le système. On distingue clairement deux types d'interface Interface d'entrée/sortie de type fichier, permettant d'échanger des données entre des logiciels classiques et RECORD. 1.13 CSVpour excel 1.14 Data-frame pour R 1.15 ShapeFile pour les sig 1.16 Ascii 1.17 XML/SQL pour les entrées/sorties de type SGBD Interface intégrée et dédiée aux logiciels. 1.18 Paquetage R 5/9
1.19 * Macro VBA access/excel 1.20 Composant SQL permettant d'interroger une BD en cours de simulation. Persistance Dans cette partie on exprime la liste des éléments constituant un simulateur dans RECORD. 1.21 Fichiers sources pour les parties programmées. 1.22 Fichiers binaires pour les exécutables et les librairies. 1.23 Fichiers XML pour la configuration de la structure (Plan d'expérience??) et des paramètres. 1.24 Fichiers de données spécifiques. Documentation et support Dans cette partie on propose une liste de tout ce qui peut accompagner la plate-forme et les projets de modélisation en terme de documentation et de service. Pour la plate-forme 1.25 Le code source et les commentaires feront l'objet d'un effort de qualité; session de revue de code, notation, 1.26 La plate-forme bénéficiera d'un suivi de version, de bug, de demande de support. 1.27 La plate-forme bénéficiera d'une application d'installation facile. 1.28 1.29 La plate-forme bénéficiera d'exemples d'utilisation, d'un tutoriel, d'un site web, d'un manuel utilisateur et d'une documentation technique. La plate-forme bénéficiera d'un système de tests, publics et utilisables à chaque instant. Pour les projets de modélisation 1.30 La plate-forme bénéficiera d'un séminaire, d'une formation, d'une animation. 1.31 Un système de documentation configurable, optionnel, intégré et automatique sera proposé. 1.32 * Des contrôles sémantiques pourront être mis en œuvre. 1.33 Les modèles bénéficieront d'un système de gestion de version. 1.34 Les modèles seront auto-descriptifs. 1.35 Les projets dans leurs différentes phases bénéficieront d'un appui de la plate-forme sous une forme à définir. 6/9
Plate-forme de développement 1.36 La plate-forme de modélisation, doit-être indépendante de la plate-forme de développement et plus précisément de tout IDE. Cela signifie que la communauté des informaticiens de RECORD doit pouvoir programmer à l'aide d'un simple éditeur de fichier, ou en utilisant Eclipse, voire Visual. 1.37 1.38 Les projets de modélisation, ainsi que le projet RECORD devront se conformer à un processus de gestion de version.(cvs,svn,...) 1.39 Tous les développements RECORD bénéficieront d'un service de type Forge. Références: CAPSIS :CAPSIS - étude générale, http://coligny.free.fr/textes/etudegenerale.htm SEAMLESS : Modelling Framework (SeamFrame) requirements, www.seamlessip.org/reports/report_06_pd5.2.2.pdf 7/9
Annexe: Glossaire Spécifications non-fonctionnelles : Les spécifications non-fonctionnelles sont toutes les spécifications qui n'expriment pas une fonction du logiciel. Utilisateur de la plate-forme RECORD : modélisateur, et plus précisément, les chercheurs-ingénieurs modélisant des systèmes de cultures. Simulateur : Programme exécutable implémentant un modèle. Plate-forme de modélisation : Une suite logicielle comprenant à la fois des exécutables (exe) et des librairies (dll). Elle fournit un ensemble de services cohérents aux modélisateurs. Plate-forme de développement : Une suite logicielle qui fournit un ensemble d'outils utiles à l'activité des développeurs de logiciels. Une plate-forme de développement peut servir pour développer la plate-forme de modélisation, et pour développer les simulateurs (ex : Eclipse + SVN + javadoc..). IDE : Environnement de développement intégré (ex : Eclipse) fournissant une interface graphique avancée. Modèle : Représentation d'un système, résultat de l'activité de modélisation. Module : Unité de décomposition d'un modèle. Exemples : module de décision, module spatial, module de racine, module de sol. Composant : Élément logiciel dont le comportement est clairement spécifié, intégrable, et donc utilisable dans des modèles différents. 8/9 facilement
Le projet à l'initiative des départements Environnement et Agronomie (EA) et Mathématiques et Informatique Appliquées (MIA)de l'inra, a pour objectif la création d'une plate-forme informatique de modélisation et simulation pour l'aide à la conception et l'évaluation de systèmes de culture innovants. Cette plate-forme vise à devenir un outil de simulation informatique partagé par l'ensemble des agronomes modélisateurs de l'inra étudiant les systèmes de culture, facilitant de la sorte le développement, le partage et la réutilisabilité des modèles développés en agronomie. Les systèmes de culture sont des systèmes complexes, où la logique d'action est fortement présente, et dont l'étude relève de plusieurs disciplines. Le projet RECORD entend alors répondre aux nombreuses difficultés soulevées aujourd'hui par l'emploi de la modélisation et la simulation pour l'étude de ces systèmes. INRA Unité BIA, Chemin de Borde Rouge - BP 52627, 31326 Castanet-Tolosan cedex Tél : 05 61 28 52 75 Fax : 05 61 28 53 35 http://record.toulouse.inra.fr 9/9