¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Méthode d’intégration de modèles
Ce dossier reprend des données d’un article portant sur DIVA, une méthode d’intégration de modèles. Cet article est paru lors de la conférence de l’iEMSs 2004 (International Environmental Modelling and Software Society) :
« DIVA : An Iterative Method for
Building Modular Integrated Models »
Jochen Hinkel
http://www.iemss.org/iemss2004/
Il
y est question de la démarche d’intégration de plusieurs sous modèles dans un
modèle :
-
Caractéristiques de la
démarche d’intégration : une sensibilisation à la modularité et à l’itérativité du
processus.
-
Découpage d’un processus de modélisation
en étapes cette décomposition sert à situer le niveau auquel les
différentes équipes pourront livrer les sous modèles (sous forme d’expressions
mathématiques, sous forme de code source …).
-
Intégration modulaire décrit
la démarche d’intégration modulaire, en particulier étudie à quelle étape du
processus de modélisation effectuer l’intégration entre les sous modèles.
-
La méthode DIVA un exemple de méthode (dans un contexte d’architecture comportant une IHM, un
noyau, des modules, une base de données).
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Caractéristiques de la démarche d’intégration ( Ù )
Lorsqu’il s’agit d’intégrer des modèles, les modèles issus de diverses disciplines sont souvent hétérogènes, incompatibles, développés par des équipes dispersées. Les interactions entre les sous systèmes ne sont pas complètement connues dès le début.
Une approche modulaire aide à surmonter ces difficultés. Reste alors à définir la méthode de modularisation (comment découper le système en modules ?) et d’intégration (comment intégrer les différents modules dans le système ?).
La méthode doit être flexible pour permettre d’incorporer au fur et à mesure du développement de nouvelles connaissances sous diverses formes (données, algorithmes). Une approche de développement itératif permet, au fil des collaborations, de comprendre les interactions entre les sous systèmes, et de construire ainsi le système progressivement.
Au bilan, la démarche d’intégration de modèles repose sur la modularité et sur des méthodes d’organisation (en terme de communication et de coopération, d’harmonisation des concepts, de processus de développement rigoureux).
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Découpage
d’un processus de modélisation en étapes ( Ù )
Le processus de modélisation est ici décomposé en 4 étapes chronologiques.
Etape 1. Ontologie
C’est la formulation explicite (spécification, définition) du concept qui est à la base du modèle.
Etape 2. Problème
mathématique
C’est la mise en équation de l’ontologie, la formulation (l’expression) mathématique.
Etape 3. Algorithme
C’est l’algorithme traduisant le problème mathématique, l’approximation de l’équation mathématique par application de méthodes numériques.
Etape 4. Le programme
du modèle, le logiciel
C’est le logiciel implémentant l’algorithme dans un langage de programmation. Le logiciel aboutit à un exécutable, l’applicatif du modèle.
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Intégration
modulaire ( Ù )
Le système complet est composé de sous modèles livrés par chaque équipe sous forme modulaire.
A quelle étape du
processus de modélisation effectuer l’intégration entre les modèles ?
Au départ il y a forcément une réflexion autour d’une ontologie commune. Il reste ensuite à choisir si les modèles seront assemblés en tant que problèmes mathématiques (étape 2.), algorithmes (étape 3.), ou logiciels (étape 4.).
· Intégration en tant que problèmes mathématiques (étape 2.)
C’est le niveau d’intégration « idéal ». Le système est alors représenté par une formulation mathématique complète et l’algorithme qui en découle est d’autant plus exact, stable, efficace.
Dans la pratique l’intégration se fait rarement à ce niveau :
- Qui ne permet pas de réutiliser les logiciels existants.
- Qui nécessite une forte collaboration tôt dans le projet.
- Le problème mathématique complet est difficilement formulable car les liens entre les sous systèmes sont encore mal déterminés en début de projet.
- Il est plus habituel de raisonner en terme d’intégration au niveau des algorithmes et des logiciels qu’au niveau du problème mathématique.
· Intégration en tant que logiciels (étape 4.)
L’intégration au niveau des logiciels a pour avantage de permettre de réutiliser des logiciels existants.
Par contre les logiciels hérités risquent d’être hétérogènes : au niveau des plates-formes, des langages de programmation, des compilateurs, des formats des données …
Un inconvénient de cette approche est qu’il n’est pas certain que la juxtaposition des algorithmes retenus pour chaque sous-système offre une bonne représentativité du système complet.
· Intégration en tant qu’algorithmes (étape 3.)
Dans cette approche, chaque équipe résout son problème mathématique de manière indépendante. Ensuite la concertation a lieu lorsque les algorithmes sont implémentés sous forme de modules, dans un langage de programmation commun imposé.
Cette solution ne permet pas de réutiliser les logiciels existants.
Comment décomposer
le système en modules ?
Du fait que les interactions entre sous systèmes ne sont pas entièrement déterminées dès le début du projet, il est nécessaire de définir entre les modules des interfaces générales suffisamment flexibles. La mise au point de ces interfaces demande une forte collaboration entre les équipes et s’appuie sur la définition d’un processus de développement rigoureux.
Quelles
technologies et méthodes informatiques utiliser ?
La programmation orientée objet est particulièrement adaptée à la mise en œuvre de la modularité.
Selon l’environnement de développement choisi (langage informatique …), il pré-existe des composants et bibliothèques plus ou moins riches. Le fait de les utiliser permet d’accélérer les développements.
Si l’implémentation fait partie du processus d’intégration (intégration au niveau de l’étape 3. ou avant) il peut être offert aux équipes une structure commune pour implémenter les modules (un « squelette »). Cela aboutit à un système homogène et permet de mutualiser les développements. La structure partagée doit être la plus complète possible dans l’idée de partager le maximum de choses. Toutefois elle doit rester flexible et souple, pas trop contraignante. Elle doit se limiter à un niveau de détail qui permette à chaque équipe d’implémenter facilement ses spécificités.
Organisation du
processus d’intégration des modules
Le processus d’intégration repose sur des collaborations au fur et à mesure desquelles le système se construit. Les aspects organisationnels font ainsi partie intégrante du processus d’intégration.
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
La méthode
DIVA ( Ù )
La méthode générique DIVA comprend :
- Un cadre de conception.
- Un processus de développement itératif.
- Un modèle générique.
- Un outil de génération et de documentation.
Un cadre de
conception
La représentation conceptuelle du système comprend une représentation statique (modèle des données) et une représentation dynamique.
Un processus de
développement itératif
Le processus est itératif, les trois étapes suivantes sont répétées à chaque évolution ou ajout d’un élément (objet) dans le système complet :
- La première étape consiste à définir l’ontologie du modèle. Il s’agit de spécifier les éléments (objets) qui constituent le système, leurs propriétés et relations. A partir de cette spécification, il est généré automatiquement du code source Java qui constitue la structure de base commune dans laquelle seront intégrés les sous modules.
- Dans la seconde étape, chaque équipe code ses algorithmes en langage Java, les regroupe et les classe dans des modules. Une fois exécuté, testé et validé individuellement, un module est inclus dans le système commun.
- En dernière étape, les modules sont analysés dans leur ensemble et assemblés, et le modèle complet est validé.
Il faut veiller à ne rentrer dans une itération du processus qu’à condition de garder suffisamment de temps pour la validation et les essais finaux.
Une limite de la méthode est le fait que le problème mathématique est spécifié pour chaque sous module indépendamment les uns des autres. Il n’est pas formulé une spécification complète du problème mathématique. Il se pose alors la question de la pertinence et de la représentativité du modèle complet. D’autre part le choix (une à une) des méthodes numériques d’implémentation n’est pas optimisé.
Un modèle
Le modèle comprend :
- Un noyau générique. Celui-ci gère les données en entrée et en sortie du système, le séquencement des traitements. Il initialise le système, les données et variables, il configure les paramètres. Il gère le chargement en temps réel et les appels des modules, conformément aux scénarios d’enchaînements définis dans un fichier de configuration.
- Un ensemble de modules spécifiques qui sont invoqués par le noyau (ce sont les modules que livrent les équipes).
Un outil de
génération et de documentation
La méthode met en œuvre la génération automatique de code source (cf la structure commune partagée) et de documentation. Cela accélère le développement tout en en améliorant la qualité (assure la cohérence du système).
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Vue informatique du système ( Ù )
En terme informatique, le système dans son ensemble comprend :
- Une IHM.
- Le noyau générique du modèle.
- L’ensemble des modules spécifiques du modèle.
- Une base de données.
L’information d’entrée pour le développement du logiciel est la conception du modèle complet et les algorithmes des sous modules. La documentation est générée automatiquement.
-
mise en ligne le 17/10/05 -
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾