CAPSIS - Etude générale

Croissance d'Arbres en Peuplement et Simulation d'Interventions Sylvicoles

Unité CIRAD/INRA de Modélisation des Plantes
François de Coligny - Mai 1999.

Sommaire

1. Introduction.

2. Etude des logiciels existants.
    2.1. CAPSIS 2.4.
        2.1.1. Présentation.
        2.1.2. Fonctionnalités principales.
        2.1.3. Description technique.
        2.1.4. Interfaces avec autres logiciels.
        2.1.5. Modèles disponibles.
        2.1.6. Discussion.
    2.2. CAPSIS 3.0.
        2.2.1. Présentation.
        2.2.2. Fonctionnalités principales.
        2.2.3. Description technique.
        2.2.4. Interfaces avec d'autres logiciels.
        2.2.5. Modèles disponibles.
        2.2.6. Discussion.
    2.3. Selva.
        2.3.1. Présentation.
        2.3.2. Fonctionnalités principales.
        2.3.3. Description technique.
        2.3.4. Interfaces avec autres logiciels.
        2.3.5. Modèles disponibles.
        2.3.6. Discussion.

3. Spécifications fonctionnelles.

4. Spécifications techniques.

5. Propositions de solutions.
    5.1. Reprise de CAPSIS 3.0.
    5.2. Architecture multi-agents.
    5.3. Architecture objet.
        5.3.1. Présentation.
        5.3.2. Notions de bases et structures de données.
        5.3.3. Architecture - partie générique.
        5.3.4. Architecture - partie spécifique.
        5.3.5. Modèle Objet.
        5.3.6. Aspects techniques.
            5.3.6.1. Liaison dynamique des modèles.
            5.3.6.2. Structure des données en mémoire et sur disque.
            5.3.6.3. Langage.

1. Introduction.    

Cette étude concerne le projet de création d'une plate-forme logicielle générique d'étude de la croissance des arbres en peuplements de l'Unité CIRAD/INRA de Modélisation des Plantes.

Ce projet est la continuation du projet CAPSIS (Croissance d'Arbres en Peuplement et Simulations d'Interventions Sylvicoles) mené à l'INRA, centre d'Avignon par Philippe Dreyfus et François-Régis Bonnet de 1994 à 1997 avec le soutien de l'ONF, la DERF, l'ENGREF, l'AFOCEL et le Cemagref.

Le projet CAPSIS a donné naissance à deux plate-formes de simulation d&eaormes de simulation développées en langage C++ pour des environnements PC sous MS-Windows. CAPSIS 2.4 concerne les modèles type "arbres, indépendants des distances" (MAID), alors que CAPSIS 3.0 prévoit de traiter également les modèle type "arbres, dépendants des distances" (MADD). Le projet CAPSIS 3.0 constitue une refonte de la première application se voulant plus générique, mais il n'a pas été mené à son terme.

Parallèlement, le Cirad a développé la plate-forme de simulation Selva (1994) pour la "modélisation individuelle spatialement explicite de la dynamique d'un peuplement de forêt dense tropicale humide" (thèse de Sylvie Gourlet-Fleury, développement de Dario Caruso). Ce logiciel est spécifique au modèle défini par Sylvie Gourlet-Fleury (1997) et s'appuie sur la plate-forme multi-agents Maleva (M. Lhuillier) développée avec le langage orienté objet SmallTalk-80 au laboratoire LAFORIA de l'Université Paris VI. Il fonctionne sous des environnement stations Unix.

Après une étude des fonctionnalités de ces trois logiciels et analyse de leurs point forts et faibles (section 2), un cahier des charges fonctionnel (section 3) et technique (on 3) et technique (section 4) est proposé pour la future plate-forme. La section 5 présente les perspectives envisagées pour la suite du projet. Ce rapport servira de support pour les décisions concernant les suites à donner au projet.

2. Etude des logiciels existants.    

2.1. CAPSIS 2.4.    

2.1.1. Présentation.    

La première version de CAPSIS a été développée par François-Régis Bonnet autour du modèle de type "arbre, indépendant des distances" pour le Pin noir de Philippe Dreyfus. Elle proposait un gestionnaire de scénarios sylvicoles (4 simulations de 7 étapes chacune) avec trois opérations possibles : croissance, éclaircie systématique ou sélective. Le scénario permettait de définir des étapes successives de croissance et d'éclaircie

Des évolutions successives ont permis d'introduire un moteur de bases de données (Borland) pour résoudre les problèmes de m&eacoblèmes de mémoire liés au grand nombre d'états intermédiaires du peuplement et une fenêtre de contrôle pour présenter les graphiques et tableaux récapitulatifs. Cette fenêtre représente une succession de feuilles A4 dans lesquelles l'utilisateur peut positionner les résultats à loisir avant impression. Un mécanisme à base de bibliothèques dynamiques permet de lier plusieurs modules (contenant chacun l'information scientifique liée à une essence forestière : modèle de croissance, modèle de branchaison, modèle de profil de tige ou de cerne...) à CAPSIS.

La dernière version de CAPSIS "1ère génération" est numérotée 2.4. Elle ne traite pas les modèles de type "arbres, dépendants des distances". Elle permet de traiter jusqu'à 10 scénarios de sylviculture de 50 étapes chacun. Elle permet de faire des comparaisons entre des peuplements, des modèles de croissances, des essences, des fertilités stationnelles différents. Les données dendrométriques calculées par le logiciel sont exportables au format texte pour traitement dans d'autres logiciels (tableurs, analyseurs statistiques...). Des formats de fichiers spéciaux peuvent êaux peuvent être générés pour être relus par le logiciel de qualité des bois Win-Epifn.

L'interface graphique est très soignée. Elle permet de gérer les scénarios (nouveau scénario, création, suppression, visualisation d'étape...) et de suivre les évolutions intermédiaires du peuplement par des histogrammes d'effectifs par classes de diamètre ou de circonférence et des tableaux de données dendrométriques pour l'étape en cours et la précédente (pour comparaison). La fenêtre de contrôle permet de déposer les graphiques, courbes, tableaux ou dessins prévus spécifiquement pour le modèle à l'emplacement souhaité pour une mise en page personnalisée.

Une aide en ligne est disponible par menu, la touche <F1> ou l'icône "?". Elle concerne tous les objets graphiques de l'interface, notamment les fenêtres et menus. Certains paramètres de l'interface graphique sont personnalisables (couleurs).

2.1.2. Fonctionnalités principales.    

Scénario initial : créé en début d; en début de session par "ouvrir un fichier" peuplement (nouvelle simulation) ou simulation (ancienne simulation) et saisies complémentaires de données spécifiques au modèle, puis "initialisation des simulations". On peut également créer un premier peuplement fictif par "création d'un nouveau peuplement", puis "initialisation des simulations".

Il est possible d'afficher les résultats de calculs pour la placette considérée ou par hectare.

Choix au début de la simulation de paramétrer le mode de calcul du tarif de cubage (cubage à deux entrées ou volume géométrique tenant compte du profil de la tige).

A la création du scénario, la croissance passée du peuplement est reconstituée (simulation sans éclaircies).

Le gestionnaire de scénario permet d'ajouter, de supprimer ou de consulter une étape par action de la souris. On peut ajouter une nouvelle étape après la dernière d'un scénario ou après l'une quelconque des étapes déjà créées. Dans ce cas, une branche de scénario parallèle est ajoutée pour sjoutée pour simuler une autre sylviculture.

Nouveau scénario : possibilité de créer un nouveau scénario dans la même session, avec trois possibilités : changer de module, changer de station, ajouter un peuplement existant (voir ci-après). Les nouveaux scénarios peuvent par la suite être supprimés, sauf le premier créé.

Changer de module : création d'un nouveau scénario reprenant le même peuplement (classes, effectifs, hauteurs, surface, age) que le précédent en utilisant un nouveau modèle de simulation (éventuellement pour une essence différente). Cela sous-entend que le peuplement initial soit compatible dans son format de données avec le nouveau module choisi. Dans le cas contraire, il peut y avoir dysfonctionnement du logiciel.

Changer de station : création d'un nouveau scénario pour le même peuplement/modèle avec des modifications concernant la fertilité stationnelle, le tarif de cubage, la région ou le pays.

Ajouter un peuplement : création d'un nouveau scénario à partir d'un fichier peuplement pour un nouement pour un nouveau peuplement/module. Des dialogues permettent d'initialiser les paramètres spécifiques au modèle choisi.

Ajouter un peuplement fictif : création d'un nouveau scénario à partir d'un modèle (sans fichier peuplement). Cela sert à comparer des densités de départ, des fertilités stationnelles, des essences ou des modèles différents. Le peuplement est créé de toutes pièces.

Eclaircie sélective : choix d'une densité à respecter après éclaircie (tiges/ha, ou surface terrière, ou volume, ou facteur d'espacement, ou RDI) et d'une valeur fixée pour le rapport de la surface terrière de l'arbre moyen de l'éclaircie à la surface terrière de l'arbre moyen avant éclaircie (Kg). Il est possible d'intervenir directement dans un histogramme avec la souris pour diminuer l'effectif dans certaines classes de diamètre / circonférence en maintenant ou pas la densité à respecter après éclaircie. Après validation, le peuplement est modifié en conséquence et le rectangle figurant l'étape indique le facteur d'espacement après éclaircie en pourcentage.

Eclaircie Systématique : choix d'un ratio d'arbres à couper (n/N, ex : 1/3).

Croissance : on spécifie le critère d'arrêt de l'étape de croissance (âge, hauteur dominante) et le logiciel calcule l'état du peuplement à la fin de l'étape. Le rectangle figurant l'étape contient l'âge atteint.

Valeurs limites : spécification de valeurs limites pour le scénario pour certaines des grandeurs évoluant pendant la croissance. Si l'une de ces valeurs est atteinte (seuil ou plafond), une boîte de dialogue propose à l'utilisateur de stopper l'étape de croissance.

Résultats : tableaux, graphiques, courbes, histogrammes, dessins, sections d'arbres... permettant d'obtenir des informations précises sur le déroulement de la simulation (voir ci-après). Ces sorties graphiques ou tableaux sont statiques (concernent l'étape pour lesquels on les a créés) ou dynamiques (modifiés pour correspondre en permanence à l'étape courante). Les dynamiques sont repérés par un carré noir dans la partie supérieure. On peut modifier l'état dynamique/statique de chmique/statique de chaque sortie. Il est possible de changer certains éléments de la sortie : titre..., rajouter un commentaire, changer la forme de la sortie graphique/tableau, dupliquer une sortie (pour en consulter plusieurs formes simultanément ou en garder une version statique tandis que l'autre continue d'évoluer au fil de la simulation), faire apparaître des données de plusieurs scénarios sur un même graphique (une courbe par scénario)...

Rapport d'étape : constitué d'un tableau et d'un diagramme concernant la dernière étape de simulation.

Graphique d'évolution : permet de construire des courbes d'évolution de données concernant un arbre ou tout le peuplement pour un ou plusieurs scénarios (superpositions de courbes sur le même graphique) en fonction de l'âge ou de la hauteur dominante (ex : nombre de tiges à l'hectare, surface terrière à l'hectare, circonférence moyenne...).

Table de production : paramétrable pour ne présenter que les données choisies pour le peuplement final, les éclaircies et/ou la production, pour un ou plusieurs scénarios.

Dessin d'arbre : choix sur un histogramme des classes de diamètre/circonférence dont on veut dessiner (schématiquement) le représentant.

Profil de tige / empilement de cernes : choix d'un arbre pour lequel on veut le dessin de la distribution verticale des cernes (selon le module, tous les cernes sont représentés, ou bien 1 cerne sur 3 seulement).

Section de tige : dessin de la section de la tige à 1,3 m (on peut changer à volonté la hauteur de cette section) pour un arbre sélectionné.

Graphiques d'évolution : présentent des courbes pour plusieurs scénarios simultanément. Les courbes sont référencées sur le graphique par le numéro de scénario.

Classement bois ronds : choix de valeurs pour la découpe fin bout, la hauteur de souche et la longueur des billons. Le classement concerne le peuplement restant sur pied ou le peuplement éclairci. Il prend en compte la dimension de chaque billon, la décroissance, la largeur moyenne des cernes sur le tiers externe du billon, le diamètre maximum des branches vertes et des branches mortes dans le billon (proche de la norme Cproche de la norme CTBA pour le classement des bois ronds résineux). Le résultat a la forme d'un tableau donnant le nombre de billons et le volume correspondant pour les classes de diamètre/circonférence (en ligne) et les classes de qualité de 1 à 4 (en colonne).

Impression : imprime le contenu des pages de la fenêtre de contrôle qui contiennent des graphiques. Possibilité de configurer l'imprimante.

Sauvegarde dendrométrie : sauve dans un fichier .TXT les valeurs dendrométriques, année par année, pour le scénario considéré. Le séparateur est la tabulation, les données sont lisibles par MS Excel.

Sauvegarde arbres : sauve dans un fichier .TXT les dimensions d'un arbre type par classe, année par année, pour le scénario considéré (lisible par MS Excel).

2.1.3. Description technique.    

CAPSIS 2.x est une application mono plate-forme pour Windows 95 (recompilable pour Windows NT) développée en C++ avec Borland C++ development suite 5.01.

Le logiciel s'appuie sur la biel s'appuie sur la bibliothèque Borland OWL (ObjectWindows Library) pour l'interface graphique et sur l'outils BDE (Borland DataBase Engine) pour l'écritures sur disque des simulations.

Les modèles sont construits comme des DLL (Dynamic Link Libraries Windows) utilisées par l'application.

2.1.4. Interfaces avec autres logiciels.    

Il est possible de générer des fichiers d'interfaces avec le logiciel d'évaluation de la qualité de la ressource en bois Win-Epifn de l'équipe de recherche sur la qualité des bois de l'INRA de Champenoux. Une version plus générique portable sur plusieurs plates-formes (Epifn) a été développée par l'unité de modélisation des plantes du Cirad AMAP.

Pour Win-Epifn et Epifn, ces fichiers sont au format texte, séparés par des virgules (.csv sous Excel). Les paramètres entre crochets sont optionnels et peuvent être mis à zéro :

- Fichier .cap : fournit la liste des fichiers générés par CAPSIS à charger par Win-Epifn (non utilisé par E utilisé par Epifn) ;

- Fichier inventaire (.ifn) : une ligne par arbre, liste des arbres d'une placette (même âge) et leurs caractéristiques à l'âge final :
numéro arbre, âge, diamètre1.3 [Epifn], [épaisseur écorce1.3], hauteur totale (cm), [hauteur d'élagage (cm)][Epifn : non utilisé], [âge d'élagage][Epifn : non utilisé], [hauteur 1ère branche morte (cm)], [hauteur 1ère branche vivante (cm)], [hauteur 1er verticille vert (cm)], nombre d'arbres à l'hectare représentés par l'individu (poids)[Epifn : non utilisé], [surface placette (ha)] [Epifn : non utilisé] ;

- Fichier hauteurs (.csv / .uc) : une ligne par UC : pour chaque arbre à chacun des âges calculés, contient les informations de hauteur de chaque unité de croissance et la remontée de houppier :
numéro arbre, âge, hauteur UC, hauteur de la 1ère branche morte [Epifn], hauteur de la 1ère branche vivante [Epifn], hauteur du 1er verticille vert [Epifn] ;

- Fichier diamètres (.csv / .dia) : une ligne par UC et par cerne : pour cha par cerne : pour chaque arbre, diamètre de chaque unité de croissance pour tous les âges cambiaux :
numéro arbre, numéro UC, âge cambial (i.e. numéro cerne), diamètre (cm).

- Fichier branches (.csv / .br) : une ligne par branche : pour chaque arbre, contient les informations sur les branches :
numéro arbre, numéro UC, numéro branche, hauteur insertion (cm), diamètre (cm), angle insertion (degrés), azimut (degrés), état (vivante/morte) [Win-Epifn].

2.1.5. Modèles disponibles.    

Espèce	Sigle	Organismes
Pinus nigra nigricans	pnn	INRA - ERTI
Fagus silvatica	fs1	ENGREF - INRA
Pinus pinaster (modèle peuplement)	pp1	INRA
Picea abies	pa1	AFOCEL
Pinus nigra laricio	pnl	Cemagref - IDF - INRA - CIRAD
Quercus petraea	qs1	ENGREF - INRA - ONF
Pinus halapensis	ph1	INRA - IFN - ONF
Pinus pinaster (MAID)	pp3	INRA
Pseudolsuga menziesii	pm1	AFO>pm1	AFOCEL
Pinus pinaster	pp2	AFOCEL
Cedrus atlantica	ca1	INRA (en préparation)

2.1.6. Discussion.    

CAPSIS 2.4 peut accepter des modèles de croissance type "arbre, indépendant des distances", "arbre moyen" et "modèle peuplement".

Avantages de CAPSIS 2.4 :

- La souplesse du gestionnaire de scénarios est suffisante pour mettre au point facilement des scénarios de sylviculture. La possibilité de scinder un scénario en plusieurs options à partir d'une étape donnée offre une grande facilité de comparaisons ;

- Les comparaisons entre modèles, peuplements ou paramétrages différents ;

- Les comparaisons d'arbres dans plusieurs scénarios ou d'états successifs d'arbres dans un même scénario ;

- Facilités liées à l'utilisation de la POO ;

- Performance d'un langage compilé ;

- La facilité d'ajout de modèles nouveaux ;

- Une certaine liberté de structure pour les modèles (données et traitements) ;

- L'exportation possible vers d'autres logiciels ;

- L'assistance à l'éclaircie ;

- Les nombreuses possibilités de sorties et rapports ;

- La richesse et la convivialité de l'interface graphique.

Inconvénients de CAPSIS 2.4 :

- Les spécifications du logiciel ne prennent pas en compte les modèles type "arbres, dépendants des distances" (MADD) ;

- CAPSIS 2.4 est mono plate-forme et construit à partir de composants non portables (bibliothèques Borland C++ pour Windows pour l'interface graphique et les bases de données relationnelles) ;

- La création d'un nouveau module de modélisation nécessite une modification dans le source de l'application et une recompilation, ce qui peut entraîner la diffusion de versions pouvant faire fonctionner certains modules et pas d'autres ;

- Pas de documentation technique ;

- Complexité du langage C++ ;

- Instabilité relative, accompagnée d'un bon comportement au redémarrage après plantage.

Le logiciel remplit très bien ses fonctions. Il est largement utilisé par des chercheurs et des forestiers des organismes contributeurs. Il donne toute satisfaction pour la recherche et l'enseignement. Son principal défaut vient du fait qu'il ne traite pas les modèles type "arbres, dépendants des distances".

2.2. CAPSIS 3.0.    

2.2.1. Présentation.    

CAPSIS 3.0 a été développé en 1997 pour remplacer CAPSIS 2.32 (qui a depuis évolué de son côté jusqu'à la version 2.4). Ilve; la version 2.4). Il prévoit dans son cahier des charges de traiter les modèles spatialement explicites et de viser une plus grande généricité.

Le nouveau logiciel est basé sur une application gérant des objets graphiques développée par F.-R. Bonnet fin 1996. Ces objets peuvent être combinés ensemble pour produire des sorties graphiques de tous types, tableaux, histogrammes, courbes, ou des dessins (arbres ou autres). Le développement de la version 2.x ayant fait apparaître des difficultés pour l'impression des sorties et résultats (taille), ces objets utilisent les possibilités des bibliothèques Borland (OWL) pour disposer d'un caractère redimensionables.

Le logiciel s'appuie toujours sur OWL pour l'interface graphique et sur BDE pour l'enregistrement des états intermédiaires du peuplement considéré sur disque. La cinématique des traitements est régie par une "messagerie" permettant de diffuser des ordres à travers l'arborescence des "objets forestiers" de CAPSIS (peuplement, forestier, arbres, autres...).

Pour faciliter la tâche aux développeurs de modèles, la description des structures de données propres à chaque mo à chaque modèle et la diffusion des messages se font par l'intermédiaire de macros prédéfinies et paramétrables, étendues dans les sources par le précompilateur C++ avant compilation.

Le développement de l'application n'a pas pu être terminé. La version 3.0 est donc très instable et elle a été distribuée à quelques modélisateurs seulement qui développent encore aujourd'hui leurs modèles. Le premier modèle rentré a été celui de Benoît Courbaud (modélisation de l'éclairement et de la croissance de l'Épicéa). Il a servi à la mise au point du logiciel.

2.2.2. Fonctionnalités principales.    

CAPSIS 3.0 reprend en théorie les spécifications de la version 2.4. En plus, il est prévu pour traiter les modèles type "arbres, dépendants des distances". Nous étudions donc ici les fonctionnalités nouvellement introduites. Nous verrons dans la section discussion que la nouvelle version n'étant pas terminée, elle ne présente pas toutes les fonctionnalités escomptées.

Le logiciel s'articule autour de deux bibliothèques concernant d'une part les sorties graphiques (Tags) et d'autre part la persistance (DBFObject). Les Tags sont ou non spécialisés dans le domaine forestier. La dll dbobjects contient les Tags génériques. Les Tags spécifiques à un modèle font partie de la dll du module de modélisation.

Les objets forestiers d'un module de modélisation héritent de classes de base de la dll dbobjects. Un objet forestier (OF) peut être constitué de plusieurs entités forestières (EF).

Les OF forment une arborescence dont la racine est le peuplement. Un OF particulier, le forestier, diffuse des ordres (opérations sylvicoles) aux autres OF à travers l'arborescence. Il tient à jour la dendrométrie du peuplement (la dendrométrie est un OF fils du forestier). Les OF statiques ne varient pas au cours de la simulation, à la différence des OF dynamiques. Chaque OF de l'arborescence peut avoir zéro ou plusieurs enfants et tous les OF de même niveau sont frères (chaque OF du niveau possède la référence de son frère suivant). ère suivant). Ce mécanisme permet de représenter les animaux ou insectes dont l'influence peut être prise en compte dans la simulation. CAPSIS connaît le peuplement et le forestier. Les ordres sont diffusés dans l'arborescence par une messagerie. Le module de modélisation doit gérer le fonctionnement et les échanges entres les autres OF de la simulation.

La finalité de CAPSIS est de visualiser les évolutions de l'état des OF dynamiques dont les états successifs sont enregistrés pendant et après les opérations sylvicoles. Durant la croissance, c'est le module de modélisation qui détermine quand les états des objets du peuplement matérialisant l'évolution des attributs des OF doivent être enregistrés. Ces sauvegardes sont effectuées dans une base de données relationnelle concernant plusieurs simulations. Chaque module forestier dispose d'un type d'OF et donc d'une base de données à un format propre.

Par exemple, pour le module Cemagref, les différents OF sont les suivants :

- La placette, qui contient les données stationnelles du modèle (nom, surface, date, fertilité, orientation, pente, latintation, pente, latitude) ;

- L'épicéa (diamètre, hauteur, position 3D, âge, noyau, éclairage pour la croissance en diamètre, en hauteur, dernier accroissement en diamètre et en hauteur) ;

- Les rayons solaires, qui représentent le rayonnement annuel moyen sur la placette : directs et diffus. Ils sont calculés au début de la simulation une fois pour toute (azimut, hauteur angulaire, intensité, diffus/direct) ;.

- L'ensoleilleur est un OF abstrait : il encapsule les paramètres et le processus d'éclairage des arbres (hauteur d'interception pour la croissance en hauteur, en diamètre, coefficient de passage pour les arbres jeunes, pour les arbres vieux, paramètres d'enveloppe du houppier, hauteur angulaire minimale, nombre de couronnes du ciel, tableau de déclinaison...) ;

- L'objet croissance possède des paramètres et des méthode de croissance. Il permet de connaître l'accroissement en diamètre et la hauteur d'un arbre du noyau ou de la périphérie. Lors d'un cycle de croissance, un lien est transmis à chacun des arbres par un message de diffusion. Chaque arbre utilise cet objet pour calculer son accroissement courant en diaement courant en diamètre et en hauteur.

Les messages sont des objets porteurs d'information qui sont transmis à travers l'arborescence à tous les OF. Certains OF ont été rendus sensibles à certains messages et les interceptent quand ils se présentent. Il effectuent alors des actions correspondant au genre du message intercepté. Les messages contiennent des liens vers deux objets dont la nature change en fonction de leur genre. Ils représentent des informations supplémentaires ou des services particuliers offerts à l'OF destinataire. L'expéditeur peut attendre ou pas une réponse de la part du premier OF concerné.

Les messages standards de CAPSIS sont les suivants :

- Le message peut concerner la "prise de responsabilité", c'est à dire la demande du déclenchement d'une opération sylvicole (OPERATE). La réponse attendue est OPERATIONMADE ou OPERATIONCANCELED. Ce message est en général à destination du forestier ;

- Un autre type de message (ADDCHILDTAG / ADDTREETAG) informe aux OF souhaitant se dessiner dans la cartographie qu'ils peuvent le faire ;

- Le message GROWTHA>- Le message GROWTHAGE demande aux OF sachant se faire pousser de le faire. Les OF répondent TRUE ou FALSE en fonction de leur capacité à croître ;

- Le message TREEINFO est diffusé quand le dialogue d'éclaircie sélective demande des informations sur les OF sélectionnés ;

- La réponse à un message quelconque DBOBJECT peut servir à retransmettre un lien vers un DBOBJECT.

La présentation du logiciel a beaucoup changé. Les fenêtres de commande et de contrôle sont remplacées par un bloc de pages à onglets permettant de visualiser un très grand nombre d'objets graphiques. Ceux ci sont de plusieurs types : cartouches, gestionnaires de scénarios, cartographies, courbes... Ils sont disposés sur les pages au choix de l'utilisateur juste après leur création en les déchargeant de la souris avec des clics droits successif. Chaque clic pose un objet à l'emplacement du pointeur, chaque objet étant par la suite déplaçable. Chaque objet déposé est un "Tag" (objets graphiques développés pour l'occasion) qui peut être redimensionné, sauvegardé et rdé et imprimé facilement. Les Tags sont combinables entre eux pour construire des Tags plus complexes. Ainsi, on peut par exemple construire une courbe en combinant des Tags élémentaires et des données.

Le Tag base de données se présente sous la forme d'un cartouche spécifiant le nom du modèle utilisé pour la simulation, le chemin d'accès des tables de la base de données et son nom. Cet objet graphique représente la base de données qui enregistre les grandeurs calculées au cours de la simulation.

Le gestionnaire de scénarios permet de gérer les états du peuplement étudier correspondant à chaque étape de croissance ou d'éclaircie de la simulation. Ce gestionnaire permet d'ajouter des étapes et de relire les anciennes en agissant dessus avec la souris.

La cartographie représente le peuplement vu de dessus. Les arbres sont représentés par un point de diamètre proportionnel à la taille du tronc et un cercle de diamètre proportionnel à la surface du houppier. La cartographie se construit pour un peuplement, avec les extensions en abscisses et ordonnées de ordonnées de la placette et une marge. Des onglets avec titres permettent de visualiser les différents états de la cartographie au cours du temps.

La dendrométrie présente les grandeurs dendrométriques du peuplement dans un état donné. Elle peut concerner une dendrométrie sur pied ou d'éclaircie. Elle présente le nombre d'individus, la surface terrière, le cubage, la hauteur (arbre moyen et dominant), le "crown ratio" (idem), etc...

Les développeurs de modules peuvent réutiliser les Tags standards, les spécifier (au sens objet : redéfinir, compléter) ou en créer de nouveaux en fonction de leurs besoins.

L'OSV (sélection et Visualisation d'Objets) est un dispositif destiné à générer des courbes en croisant des données choisies par l'utilisateur. Il s'appuie sur les tables de bases de données relationnelles de la simulation et permet de sélectionner un module, une base, une simulation, un objet et une colonne, en abscisse et en ordonnée, puis de générer une courbe. Cet utilitaire permet à l'utilisateur de croiser des données de manière non prévue.

2.2.3. Description technique.    

CAPSIS 3.0 est une application mono plate-forme pour Windows 95 (recompilable pour Windows NT) développée en C++ avec Borland C++ development suite 5.01.

Le logiciel s'appuie comme CAPSIS 2.x sur la bibliothèque Borland OWL (ObjectWindows Library) pour l'interface graphique et sur l'outils BDE (Borland DataBase Engine) pour l'écritures sur disque des simulations. Une bibliothèque d'objets graphiques redimensionables appuyée sur OWL a été développée pour cette application. Il permettent par combinaison de construire des sorties graphiques de tous types destinée à l'évaluation des modèles et scénarios. Ils ont été conçus pour s'imprimer facilement.

Les modèles sont également construits comme des DLL (Dynamic Link Libraries Windows) utilisées par l'application.

2.2.4. Interfaces avec d'autres logiciels.    

Non encore développées.

2.2.5. Modèles disponibles.    

Ces modules de modélisation sont toujours en cours de développement, du fait de la suspension momentanée des travaux sur CAPSIS 3.0.

Espèce	Auteur (organisme)
6 espèces	Philippe Dreyfus (INRA)
Épicéa (montagne)	Benoît Courbaud (Cemagref)
Pin maritime (massif Landais)	Philippe Ancelin (LRBB)
Pin sylvestre	François Goreaud (Cemagref)
Epicéa	Christine Deleuze (AFOCEL)

2.2.6. Discussion.    

CAPSIS 3.0 n'est pas terminé. Beaucoup de fonctionnalités de la version 2.4 ne sont donc pas présentes. Ainsi, le gestionnaire de scénario ne permet pas de construire des variantes à partir d'une étape de référence comme celui de la version 2.4. Les sorties graphiques sont beaucoup moins riches que celles de la version 2.4. Elles restent à développer en s'appuyant sur des Tags de base, eux même à développer. La fenêtre de commande des MAID ou un équivalent reste à développer.

Avantages de CAPSIS 3.0 :

- Multi modèles, comparaisons possibles entre les scénarios ;

- Possibilité de modifier et compléter la cartographie et tous les outils proposés en standard ;

- Possibilité de créer de nouveaux concepts tels que les cellules de terrain en les intercalant entre le peuplement et l'arbre. Il faut pour cela gérer les dialogues harmonieusement entre les intervenants : forestier -> peuplement -> cellule -> arbre (...) ;

- Le modélisateur a une liberté totale de programmation dans son module. Ainsi, il peut par exemple , il peut par exemple utiliser des envois de messages objets classiques pour décrire la cinématique dans son module ;

- Le logiciel n'étant pas terminé, on peut ajouter des fonctionnalités (on ne dispose cependant pas d'un état de l'avancement des travaux énumérant les tâches non terminées).

Inconvénients de CAPSIS 3.0 :

- La documentation ne couvre que le développement des modules et de nouvelles sorties graphiques (Tags). On ne trouve pas de documentation technique expliquant l'architecture de l'application et l'organisation des traitements ;

- L'organisation de l'interface graphique est globalement bizarre. La relation entre les différents concepts manipulés par le logiciel n'est pas évidente. Les Tags, qui représentent des sorties graphiques, sont en fait des objets de premier plan, puisque le menu Fichier permet de les manipuler, là où on s'attendait à ouvrir une "session" ou une "simulation". De même, quand on veut quitter, un message propose de sauver les Tags, et non la session en cours. La session est en fait enregistrée au fur et à mesure de sa progression dans les tables d'une base de dles d'une base de données. Par ailleurs, la prolifération d'objets graphiques de toutes sortes sur les pages d'un cahier sans organisation imposée (on dépose les objets où l'on veut à l'aide de la souris) impose un effort d'organisation particulier de la part de l'utilisateur s'il veut pouvoir s'y retrouver ;

- La marche à suivre pour développer certaines fonctionnalités n'est pas claire. Si on rajoute des structures de données supplémentaires (liste de voisins), faut-il les intégrer à l'arbre (quel format de sauvegarde en base de données), ou faut-il créer autant d'OF que de voisins (très grand nombre) ?

- Les structures de données et la messagerie sont décrites à l'aide d'un très grand nombre de macro-instructions disséminées dans tous les sources. Ces macros sont étendues dans les sources par le précompilateur, complétant les programmes avant la compilation. Ces compléments concernent des ajouts de classes et de méthodes. Cette utilisation des macros rend le code extrêmement opaque au développeur comme aux outils de "debuggage". Les macros servent d'habitude à la définition de constantes, à la compilation sélective : sélective : version démo, version complète, version PC ou Unix (avec inclusion de telle ou telle fonctionnalité) ou à l'évitement des inclusions multiples d'un fichier entête ("si déjà défini, ne pas l'inclure"), etc... L'utilisation qui en est faite dans CAPSIS peut être à juste titre considérée comme très abusive et détournée ;

- Les données du modèle objet sont sauvegardées dans un modèle relationnel (base de données, format Paradox). Il eu peut-être été plus judicieux d'utiliser une base de données orientée objets (O2 par exemple). Les transferts ne se font pas de manière simple (ni claires avec des macros) ;

- Genre de système multi-agent, mais demi-mesure. Une plate-forme multi-agents (Maleva, MadKit...) offre un meilleur support pour ce genre de développement (identité des agents, existence de l'environnement en tant que tel, gestion des messages centralisée (garantie de délivrance), fonctionnement de chaque agent dans un "thread" séparé (parallélisme), organisation (ex : en groupes et rôles)...). Aucune mention n'est faite à l'ordre de délivrance des messages qui semble &ecages qui semble être considéré comme équivalent à l'ordre d'émission. Si ce n'est pas le cas, il faut gérer les accusés de réception à bon escient sous peine d'obtenir des résultats aléatoires.

CAPSIS 3.0 a de nombreux inconvénients dus à son état de prototype en développement d'une part, et à son architecture et les choix techniques effectués d'autre part.

Ainsi, la version étudiée est-elle très instable. Une recompilation sous Windows NT a fait apparaître de nouvelles erreurs faisant planter l'application dès le début. Les sources des classes du logiciel sont parfois enregistrés dans des fichiers avec des noms différents, ce qui rend difficile la localisation de l'information.

En définitive, on constate que le développeur du logiciel n'a manifestement pas eu le temps nécessaire à l'élaboration d'une version suffisamment stable et documentée pour être réutilisable. Les choix techniques qui ont été faits vont à l'encontre de l'idée de répartition du développement entre plusieurs développeurs (qui exige une grande clarté de l'architecture) et d'une diffusion auprès d'un public non spécialisé dans la recherche (forestiers, enseignement), cette dernière impliquant un mode de fonctionnement plus organisé et convivial.

2.3. Selva.    

2.3.1. Présentation.    

Selva est un logiciel développé spécifiquement par Dario Caruso à l'occasion de la thèse de Sylvie Gourlet-Fleury (CIRAD Forêt) "Modélisation individuelle spatialement explicite de la dynamique d'un peuplement de forêt dense tropicale humide" s'appuyant sur le dispositif de Paracou en Guyane Française.

Il ne connaît donc qu'un modèle de croissance en peuplement, mais qui a la particularité de considérer des sous-modèles de croissance spécifiques pour des groupes d'espèces. Le modèle considère une liste des voisins de chaque arbre pour les calculs de concurrence. Il propose des modèles pour la mortalité et la régénération.

Le support de chaque simulation est une parcelle carr&eact une parcelle carrée de superficie variable (Paracou : 6,25 ha), découpée en placeaux carrés de 10 mètres de côté. Le peuplement peut provenir d'un fichier d'inventaire réel d'une des 12 parcelles de Paracou. On peut également choisir de commencer sans inventaire de départ et cinq individus sont créés par placeau.

L'unité de temps est le cycle de trois ans, le nombre de cycles pour la simulation est paramétrable. La simulation peut être répétée plusieurs fois pour étudier le comportement des composantes aléatoires.

2.3.2. Fonctionnalités principales.    

En début de traitement, choix d'options pour la simulation dans les fenêtres "Selva launcher" et "Lancement", puis démarrage de la simulation par un bouton Lancement:

Fenêtre "Lancement : positionnement de toutes les options (voir ci-dessous), puis bouton Lancement :

- Choix du fichier d'entrée ;

- Positionnement de préférences : auto lancement, forêt partient, forêt partielle (un certain nombre d'arbres), stade juvénile inactif, utilisation des fichier binaires pour reprendre une ancienne simulation.

Fenêtre "Options lancement" :

- Choix du fichier d'entrée, nombre d'individus à charger si le travail ne concerne qu'une forêt partielle (0 implique une génération automatique de peuplement) ;

- Nombre de répétitions de la simulation à partir du même état initial ;

- Nombre de cycles pendant lequel garder la trace des individus morts ;

- Nombre de cycles de trois ans ;

- Répertoire où stocker les résultats ;

- Arrêt ou non de la simulation quand la moitié de l'effectif initialement vivant a disparu ;

- Propagation ou non de l'effet d'un chablis primaire ;

Fenêtre "Regroupement d'espèces" :

- Utilisation ou non de groupes d'espèces. Définition des groupes : attribution d'roupes : attribution d'un libellé, association à des codes espèces, à un module de "délibération", à un diamètre d'élimination (option) et à une couleur (option) ;

Fenêtre "Options couleurs" :

- Personnalisation des couleurs utilisées pour les différents éléments apparaissant dans les cartographies (graines, plantules, chablis primaires, morts sur pied...), les différents groupes d'espèces, le fond et la sélection...

Fenêtre "Options sauvegarde" : types de fichiers de sorties attendus à la fin de la simulation (la sauvegarde peut ne concerner qu'un cycle sur n (n défini par l'utilisateur) :

- Fichier simplifié (pour chaque arbre, liste des diamètres) ;

- Fichier complet (idem + valeur des indices de compétition) ;

- Fichier "juvéniles" (par espèce, placeau et cycle, stock de graines, plantules, gaules et perches) ;

- Fichiers binaires stockant toute la configuration de l'environnement de la simulation (Evolution et (Evolution et Environnement).

Au départ, un peuplement est créé à partir d'un fichier inventaire ou automatiquement. Le logiciel crée des placeaux de 10 mètres de côté. Les placeaux sont utilisés pour le recrutement et pour optimiser la recherche du voisinage des arbres dans un rayon de 30 mètres (méthode non détaillée ici, cf. thèse de S. G.-F.).

Les arbres de l'inventaires donnent lieu à l'instanciation d'objets (Espèce Grise) rattachés à leur placeau en fonction de leurs coordonnées géographiques. Chaque objet arbre se voit attribuer en fonction de son groupe d'espèce un lien vers ses "modules de vie" qui permettent d'analyser son environnement, décider de son avenir et de mettre en oeuvre les décisions (déroulement en plusieurs phases).

Un objet "Evolution" (dictionnaire de l'évolution du peuplement) est instancié pour stocker toutes les informations liées au peuplement virtuel, il permet notamment d'alimenter les visualisations. Une fois l'environnement de simulation mis en place, une fenêtre de visualisation (d'une partie) de la parcelle apparaît sous la forme d'une cars la forme d'une cartographie (voir ci-après).

Un cycle de simulation se déroule comme suit :

- Chaque arbre analyse son voisinage par dialogue avec son placeau (module de vie d'analyse) ;

- Il décide ensuite de son avenir (module délibération) : mort, accroissement diamètre, reproduction ;

- Ceux qui ont décidé de se reproduire disséminent des graines vers leurs placeaux qui mettent à jour leur stock de graines et activent un module de gestion de la régénération pour l'espèce ;

- Chaque placeau décide après dialogue avec ses voisins du nombre d'individus de plus de 10 cm qu'il fait apparaître ;

- Chaque arbre met en oeuvre sa décision et en informe son placeau pour qu'il tienne à jour sa liste d'arbres vivants et morts (le peuplement dispose également de ces informations). Les morts sont éliminés des listes de voisins de leurs voisins lointains ;

- Les placeaux recrutent effectivement les individus de plus de 10 cm de diamètre (instanciatirave;tre (instanciation avec coordonnées, liaisons aux modules de vie et information du peuplement).

- le dictionnaire d'évolution est mis à jour : effectifs totaux des vivants, surface terrière cumulée, effectifs des morts sur pied, chablis primaires et secondaires et recrutés pendant le cycle écoulé et distribution par classes de diamètre de 5 cm des vivants et différents types de morts.

Le découplage des opérations d'analyse / choix et de mise en oeuvre du destin de chaque arbre permet de passer en revue les arbres dans un ordre quelconque (impératif du système multi-agents). La configuration de l'environnement n'est mise à jour que quand les opérations réalisées par les arbres et les placeaux sont terminées.

La fenêtre "Parcelle" propose un plan de la parcelle, avec un quadrillage figurant les placeaux. On peut y consulter à tout moment :

- la position et taille de tous les individus vivants et morts (depuis un nombre de cycle prédéfini) ;

- le type de l'individu, repéré par sa couleur : recruté, espèce, groupeespèce, groupe d'espèce, mort sur pied, chablis primaire ou secondaire (relié au chablis primaire initiateur par un segment de droite) ;

- les différents stades de la régénération sur chaque placeau dans le cas de l'étude d'une espèce particulière.

Les attributs de l'objet peuplement sont consultables par une option de menu ("Outils")de la fenêtre Parcelle. Ce sont les paramètres fixés par l'utilisateur, les listes de placeaux et d'arbres vivants et morts.

L'action sur un bouton "Effectifs" ouvre une fenêtre "Effectifs par classe de diamètre" proposant trois histogrammes permettant de représenter les effectifs d'arbres de types différents (choix par action sur une liste déroulante : arbres, morts sur pied, total chablis, chablis primaires, chablis secondaires) par classes de diamètres, pour un cycle choisi (saisie ou curseur).

L'action sur un bouton "Evolution" ouvre une fenêtre "Evolution" proposant un histogramme du nombre d'arbres par cycles (plus de 10 cm, ramené à hectare). Une liste déroulante permet de représenter à la place la surface terri&egri>la surface terrière, le recrutement, le total des morts, le total chablis, les chablis primaires ou secondaires.

On peut ouvrir plusieurs fenêtres Effectifs par classe de diamètre et Evolution par actions successives sur les boutons Effectifs et Evolution de la fenêtre Parcelle. Toutes les fenêtres ouvertes sont remises à jour à la fin de chaque cycle, montrant ainsi l'évolution du peuplement en temps réel.

Les interventions sylvicoles possibles sont l'éclaircie sélective ou systématique. Dans le cas de l'éclaircie systématique, on peut choisir l'exploitation ou la dévitalisation. Une intervention d'éclaircie donne lieu à la création d'un cycle ou les arbres ne peuvent que mourir. L'âge des arbres n'est pas modifié pendant ce cycle.

Par l'option de menu Eclaircie > Sélective, on ouvre une fenêtre "Eclaircie sélective" qui permet de choisir un placeau (un plan et une liste apparaissent montrant les arbres qu'il contient), puis de sélectionner des arbres à empoisonner avec la souris. Une fois la sélection effectuée sur tous les placeaux de la parcelle (avec dese la parcelle (avec des flèches de déplacement), on élimine les arbres grâce au bouton (analogie avec le martelage). Un message donne alors le nombre d'arbres éliminés à l'hectare après l'intervention. les arbres sélectionnés apparaissent également dans la fenêtre Parcelle pour faciliter le contrôle de l'opération.

L'éclaircie systématique nécessite au début de la simulation un paramétrage dans la fenêtre "Regroupement d'espèces". Il s'agit de l'association à chaque groupe d'espèce d'un diamètre limite au dessous duquel l'individu est préservé. Le menu Eclaircie > Systématique déclenche le repérage des individus au diamètre supérieur à la limite pour leur espèce. L'effectif total est fournis à l'utilisateur pour confirmation. Après validation, les individus identifiés meurent en déclenchant la mise à jour des listes d'arbres de la Parcelle et de leur Placeau, ainsi que la mise à jour des cartographies. L'activation d'une option "sans propagation de chablis" permet d'interdire la propagation des chablis pour simuler l'empoisonnement des arbres. Une éclaircie combinant exploitation et empation et empoisonnement doit se faire en deux phases, en activant puis en désactivant l'option.

Le menu Fichier de la fenêtre Parcelle permet à tout moment de demander la sortie de plusieurs types de fichiers, indépendamment des sorties de fin de simulation prédéfinies. On peut ainsi obtenir l'état complet de l'environnement à un instant jugé important de la simulation.

Le positionnement de la souris sur un placeau de la fenêtre Parcelle donne la possibilité de choisir parmi plusieurs options :

- attributs du peuplement (voir ci-dessus) ;

- attributs des arbres (Espèce Grise) ;

- attributs du placeau ;

- zoom sur le placeau. Une fenêtre "Placeau" est ouverte, montrant un plan des arbres vivants et une liste de leurs caractéristiques individuelles (référence, diamètre, nombre de voisins dominants dans un rayon de 30 mètres, âge en nombre de cycles).

Sur la fenêtre Placeau, on peut sélectionner un arbre dans la liste et, par action sur un bouton "Evolution" un bouton "Evolution", visualiser dans une fenêtre "Arbre" des histogrammes représentants l'évolution de son diamètre et du nombre de ses voisins en fonction des cycles successifs.

2.3.3. Description technique.    

Selva est un logiciel écrit langage objet Smalltalk-80 avec VisualWorks 1.0. Il fonctionne au Cirad Forêt sur station Unix HP9000 modèle J210XC avec processeur PA-7200 à 120 MHZ et 64 Mo de mémoire vive. Il est mono plate-forme.

Il considère le problème d'un point de vue multi-agents et s'appuie sur la plate-forme de développement multi-agents MALEVA de M. Lhuillier, elle même développée en Smalltalk.

Selva est dédié au modèle de type "arbres, dépendants des distances" de S. Gourlet-Fleury qui peut prendre en compte des sous-modèles correspondant à des regroupements d'espèces.

2.3.4. Interfaces avec autres logiciels.    

Il n'est pas prévu d'interface aeacute;vu d'interface avec d'autres logiciels de simulation dans le domaine. Les sorties fichiers Selva peuvent être repris par des tableurs ou des logiciels de statistiques (SAS) à des fins de présentation et d'analyse.

2.3.5. Modèles disponibles.    

La forêt Guyanaise compte 68 familles et plus de 1050 espèces d'arbres de plus de 10 cm de diamètre à 1m30. On estime qu'il reste environ 10% d'espèces d'arbres non décrites ou répertoriées.

S. Gourlet-Fleury considère des "espèces ou groupes d'espèces" (EGE) qui représentent une espèce réellement identifiée (ex : Dicorynia guianensis) ou un groupe d'espèces (ex : Licania spp). Son travail concerne un jeu de 87 EGE, représentés par plus de 30 individus sur les douze parcelles de Paracou, et représentant 88,4% de l'effectif total vivant sur ces parcelles en 1988.

Le dispositif de Paracou donne des informations quantifiées sur la croissance, la mortalité, le recrutement et les structures de populations. Un modèle de régénération spatialisé implique de connaîtreue de connaître pour chaque point de l'espace la probabilité d'apparition d'un nouvel individu, très difficile connaître en forêt dense tropicale humide, du fait du nombre d'espèces impliquées. S'il est possible de distinguer quelques espèces dans un simulateur, il n'est pas possible de les distinguer toutes. S. Gourlet-Fleury travaille donc provisoirement toutes espèces confondues, sur un peuplement "gris", en considérant une "espèce grise". Quinze groupes d'espèces constituent autant de sous-modèles fournissant des données suffisantes pour la conception et le construction de Selva. La mise en oeuvre d'une régénération de ces groupes est à l'étude.

2.3.6. Discussion.    

Les avantages et limites sont considérés du point de vue du problème étudié. Il est bien entendu que certains aspects évoqués ici ne faisaient pas partie du cahier des charges de Selva.

Avantages de Selva :

- Interface très conviviale : on note en particulier la fenêtre Parcelle qui propose une cartographie très pratique sur laquelle il est possible d'opérer un zoom vers un placeau et d'obtenir des informations sur les individus représentés ;

- Le contrôle de la simulation est précis grâce aux histogrammes (effectifs par classes de diamètres (pour chaque type d'arbre), effectif par cycle (pour chaque type d'arbre), diamètre et nombre de voisins d'un individu par cycles ;

- Les possibilités d'éclaircies sont multiples : sélective ou systématique, pour exploitation (chablis avec ou non propagation) ou par empoisonnement, martelage possible individu par individu ;

- Logiciel très bien documenté par S. Gourlet-Fleury dans sa thèse ;

- Stable ;

- Conception, développement, maintenance et évolution facilités par l'emploi de la POO et de SmallTalk.

Inconvénients de Selva :

- Logiciel mono plate-forme (station HP sous UNIX) ;

- Un seul modèle pris en compte : pas de comparaisons possibles ;

- Pas de scénarios de sylviculture élaborés en parallèle : pas de comparaisons possibles ;

- Pas de liaisons vers d'autres logiciels (isolé) ;

- Performances limitées à cause de SmallTalk.

Selva correspond parfaitement aux besoins de S. Gourlet-Fleury. C'est un logiciel fait sur mesure pendant sa thèse pour son modèle. Il peut continuer d'évoluer sans problèmes, mais n'est pas ouvert à l'utilisation d'autres modèles comme l'est CAPSIS, c'est là son principal défaut.

3. Spécifications fonctionnelles.    

Cette liste répertorie les principales spécifications fonctionnelles requises pour la plate-forme de simulation générique. Elle a été établie à partir de l'étude des logiciels Selva, CAPSIS 2.x et CAPSIS 3.0 et de concertations avec des modélisateurs.

- Appliquer des modèles de croissance sur des peuplements d'arbres ;
- Permettre de dérouler des scénarios sylvicoles concernant un peuplement donné, altement donné, alternant des étapes de croissances et des interventions humaines ;
- Comparer des scénarios différents sur un même peuplement (réel ou virtuel) ou sur des peuplements différents (par la station, la composition spécifique, les structures spatiale et dimensionnelle), avec un modèle de croissance ad hoc ;
- Comparer les modèles entre eux (mêmes peuplements de départ, mêmes scénarios), quand ils concernent la même espèce ;
- Considérer des modèles dépendants (MADD) ou indépendants (MAID) des distances, avec possibilité de comparer l'un et l'autre sur le même peuplement ;
- Possibilité de disposer de « sous-modèles »différents pour des espèces ou groupe d'espèces d'un même peuplement, géré par un même module de modélisation (on ne prévoit pas d'utiliser plusieurs modules de modélisation sur des groupes d'arbres du même peuplement) ;
- Les modèles ont leur propre format de fichier inventaire, ils peuvent proposer de saisir des inventaires ou d'en générer à partirte;rer à partir de paramètres ;
- Les modèles peuvent demander la saisie de paramètres particuliers nécessaires à leur fonctionnement (par des boîtes de dialogues de saisie de paramètres ex : coefficients, fertilité...) ;
- A chaque modèle peuvent être associées des sorties graphiques (histogrammes, courbes ou tableaux) particulières, définies dans le module (on peut envisager des sorties par défaut ayant une signification pour les modèles MADD ou MAID en plus des sorties spécifiques). Ces sorties peuvent concerner une seule étape (ex : rapport d 'étape), deux étapes ou plus (ex : répartition par classes de diamètres avant et après l'intervention : étape n-1 et étape n) ou toutes les étapes d'un scénario (ex : évolution du nombre de vivants, évolution des caractéristiques dendrométriques et de la composition spécifique du peuplement, des dimensions des arbres, moyen ou individuels, empilement des cernes, branchaison) ;
- La simulation permet d'enchaîner dans des scénarios des étapes de croissance (plus régénération, mortalité...) et d'éclaircies ;
- Le pas de simulation est le cycle (durée paramétrable, ex : un an), une étape pouvant compter plusieurs cycles. On calcule des "Etats" (ou "stades") successifs du peuplement (et donc de chacun des arbres) à l'issue de chaque cycle ;
- La croissance se déroule jusqu'à atteindre une valeur limite préalablement saisie (ex : 15 ans, 3 cycles ou Hauteur dominante = 30 mètres) ;
- L'éclaircie peut se faire de plusieurs manières : systématique, manuelle, ... (martelage sur une cartographie si MADD) ;
- De manière générale et quand c'est possible, des procédures génériques sont proposées au modélisateur, qui peut les compléter ou les remplacer par des dispositifs spécifiques à son modèle ;
- Des liens sont prévus avec d'autres plates-formes logicielles, grâce à des fichiers d'interface générés par exportation (Excel, EpiFn, éventuellement LandMaker et SAS...) ;
- "Dé-croissance" : à partir d'un peuplement réel ou simulé à un âge à un âge donné (par exemple à 40 ans), il est nécessaire de reconstituer une croissance avant cet âge en faisant fonctionner le modèle de croissance à l'envers (cas de CAPSIS 2.4 pour certains modules), en considérant qu'il n'y a pas eu d'éclaircies jusque là. Cette reconstitution est indispensable pour tout ce qui est Qualité des Bois (cernes de la bille de pied).

4. Spécifications techniques.    

Le cahier des charges techniques se présente comme suit :

- Architecture de plate-forme logicielle générique : doit pouvoir faire fonctionner plusieurs modèles de croissances d'arbres en peuplement pour mise au point, comparaison et enseignement ;
- Simulation pour l'aide à la décision en gestion forestière ;
- Possibilité de rajouter des nouveaux modèles à l'application (si possible sans recompilation de l'application) ;
- L'application propose des interfaces ou outils génériques, remplaçables par d'autres plus spécifires plus spécifiques au modèle utilisé ;
- L'application doit être multi plates-formes pour offrir une utilisation par un plus large public, assurer une connexion plus aisée avec d'autres logiciels (mono plate-forme) et éviter de risquer un jour une réécriture (comme AMAPmod et AMAP commercial). Les plates-formes cibles sont Windows 95/98/NT/2000/etc..., Mac et Unix (Linux, Solaris, Irix et HP-UX principalement) ;
- L'interface graphique est conviviale (notamment pour l'enseignement) et paramétrable (préférences utilisateur). Des dialogues et graphiques particuliers peuvent être définis pour chaque modèle ;
- Les modélisateurs et utilisateurs bénéficient de support et d'assistance (documentations, manuels, aide en ligne, formations, outils de développement) ;
- L'application est développée « en réseau », autour d'un coordinateur, responsable de la conception, du développement, de la maintenance, de l'évolution et du support ; de modélisateurs, responsables du développement des modules de modélisation en liaison avec le coordinateur et les autres modélisateurs ; d'utilisateurs ; d'utilisateurs pour la gestion forestière, pour l'enseignement ou pour la recherche (chaînes logicielles). Les intervenants forment une communauté d'échange pour faire évoluer le logiciel. Ainsi, quand des fonctionnalités sont utilisées par plusieurs modèles, on peut envisager de modifier la plate-forme générique pour les proposer à tous ;
- Le volume de données calculées est a priori trop important pour tenir en mémoire vive. Les états intermédiaires de chaque arbre du peuplement font l'objet d'une gestion mémoire/disque si possible transparente pour les modélisateurs. A cet effet, il faut noter que les sorties (graphiques, courbes, fichiers...) peuvent concerner une, plusieurs ou toutes les étapes d'un scénario ou plusieurs scénarios, partant d'un ou plusieurs peuplements réels et/ou simulés ;
- L'application peut être invoquée en ligne (sans interface graphique) à partir d'un fichier paramètres spécifiant les fichiers paramètres spécifiques et inventaire à charger, ainsi que la description des scénarios à dérouler (préalablement mis au point avec l'application puis sauvés dauis sauvés dans des fichiers, ou directement écrits avec un langage de commandes). L'un des objectifs est de répéter de nombreuses fois des simulations faites à l'aide de modèles comportant des composantes aléatoires et/ou à partir de peuplements générés de manière partiellement aléatoire (par exemple, pour la répartition spatiale des arbres ou des semis).

5. Propositions de solutions.    

5.1. Reprise de CAPSIS 3.0.    

La plate-forme est disponible immédiatement dans une version prototype qui peut servir à la réalisation de modules de modélisation. Il faut cependant prévoir un certain temps pour la réapproriation et le "debuggage" systématique du logiciel (organisation des sources, commentaires), le complément des parties non terminées, les développements qui restent à faire, la mise en place du système d'aide, l'internationalisation (multi-langues)... Pendant ce laps de temps difficile à estimer, il est souhaitable de ralentir les développements de modules eximents de modules existants et de différer tout développement de nouveau module.

On peux d'ores et déjà prévoir beaucoup de temps passé sur les problèmes techniques, d'organisation, de "débuggage" et pour développer ce qui a été laissé inachevé (gestionnaire de scénario...) et les fonctionnalités manquantes (une visualisation standard MAID...). Il faut prévoir par la suite du temps pour développer des Tags, trouver un moyen de régler les problèmes de sauvegarde de structures de données complexes ou volumineuses (voisinages). Il faut développer tout ce qui est spécifique aux MAID.

Cette solution implique qu'il y ait un moteur de base de données non administré par poste de travail CAPSIS (avec les problèmes spécifiques liés : administration non supervisée des volumes, des index, des procédures de reprises...). Cette particularité réserve forcément des mauvaises surprises pour l'avenir.

L'architecture étant ce qu'elle est, les évolutions envisageables peuvent être problématiques, à moins de résider uniquement dans les modules de modélisation. Ainsi, remonter n. Ainsi, remonter des fonctionnalités dans l'application générique ne semble pas évident (gestion des voisinages, découpage du terrain en placeaux, découpage de l'espace en strates horizontales plus ou moins éclairées, introduction de "fonctionnel" (/ forestier)...).

Le démontage des fonctionnalités gênantes (messagerie, base de données, OWL pour la portabilité...) est très difficilement envisageable. Le logiciel est tellement appuyé sur les bibliothèques techniques visées que cela reviendrait à une modification profonde de son architecture. Le logiciel ne sera donc jamais portable.

On garde l'architecture "demi système multi-agent" sans en avoir les avantages (parallélisme, organisation en groupes et rôles, acheminement des messages pris en charge, traces et logs pour la mise au point...).

La terminaison et la reprise de CAPSIS 3.0 semble en définitive très difficile à envisager, tant sur le plan technique (point de vue du développeur) que sur le plan du développement partagé (complexité, manque de clarté) et de l'évolution future (étude au cas par cas). Les nombreux défauts du logiciel, impossibilit&iciel, impossibilité d'utiliser l'application "en ligne" (tâche de fond), le manque important de documentation technique et d'aide à l'utilisateur, l'architecture "fermée" du point de vue de la portabilité, hybride du point de vue de la technologie sous-jacente (mi objet mi SMA) et l'opacité du code source, sont autant d'arguments jouant en défaveur de sa reprise.

5.2. Architecture multi-agents.    

Le problème que l'on cherche à résoudre est un problème de génie logiciel pour lequel les points importants sont : pérennité (investissements dessus), facilité d'utilisation (développement partagé), souplesse (multi plate-formes, convivialité), capacité d'évolution, performance.

La conception d'un Système Multi-Agents (SMA) sous-entend l'utilisation d'une plate-forme de développement de SMA. La non utilisation d'un outil de ce genre revient à en développer un soi-même (complexe : multi-thread....). Cette utilisation crée une dépendance avec l'outil, nécessaire pour faire fonctionner le logiciel. Or, ces plate-formes sont pour le moment des produits issus t des produits issus de la recherche, qui fonctionnent bien, mais n'ont pas de caractère pérenne très marqué. La plupart ont été développés par des étudiants en thèse qui ne sont pas engagés dans la maintenance après coup (abandon, autre activité, version suivante...). En utilisant un de ces outils, on s'expose donc à devoir le maintenir soi-même au bout d'un certain temps, ce qui n'est pas insurmontable, mais n'est pas le but non plus.

D'autre part, Selva fait la preuve que le problème peut être résolu par un SMA, mais il peut être également résolu par une approche objet classique. En SMA, on apprend qu'il est souvent préférable de choisir l'approche classique quand elle peut répondre au problème.

La modélisation objets est quasi-immédiate, alors que la modélisation agents doit être approfondie. Elle nécessite une étude complémentaire qui a le désavantage de nécessiter du temps. Or, si il a réécriture, il faut qu'elle soit la plus rapide possible pour minimiser le temps de confiscation de l'outil aux chercheurs.

En conclusion, l'approche SMA est possible, intéressante pour le développeur, mais comme il n'y a pas d'argument particulier en faveur de cette solution, il est également possible de l'éviter pour préférer une approche classique plus sûre, en évitant des délais et problèmes spécifiques aux SMA et en se concentrant sur la rapidité, l'efficacité et la disponibilité pour les utilisateurs.

Toutefois, si des arguments probants venaient à être avancés, une étude se basant par exemple sur le modèle agent/groupe/rôle Aalaadin de Jacques Ferber (Université Montpellier II) pourrait être produite sous deux mois.

5.3. Architecture objet.    

5.3.1. Présentation.    

La programmation orientée objet semble présenter des avantages importants pour la réalisation de l'application envisagée. Les avantages généralement avancés sont la réutilisabilité des composants logiciels développés, la clarté de la conception (dépend aussi du concepteur), ou encore l'existence d'excellentes bibl d'excellentes bibliothèques de développement facilitant et accélérant la tâche du développeur (gestion de conteneurs de données classiques, hiérarchies de composants graphiques...).

Ce qui retient l'attention pour notre problème d'application générique, c'est en particulier la possibilité de redéfinir des traitements (i.e. : méthodes, procédures, fonctions...) spécifiques à des objets particuliers, qui ont été initialement définies pour des besoins généraux. Les mécanismes mis en jeux sont l'héritage, qui permet à un objet de posséder les caractéristiques de son père (grand-père...) et la redéfinition, qui lui donne la possibilité d'y substituer les siennes propres. Les caractéristiques en question sont des données (variables d'instance) ou des traitements (méthodes) qui sont encapsulées dans l'objet.

Ainsi, on peut concevoir une architecture d'application qui mette en oeuvre des objets génériques, constituant l'application de base, et concernant l'interface graphique, le noyau du logiciel (actions déclenchables), les interfaces de visualisation (cartogisualisation (cartographies, histogrammes...) ou les sorties graphiques prévues par défaut (courbes, rapports d'étape...). Les modèles de croissance sont vus comme des modules externes (classes chargées et instanciées à l'exécution) qui décrivent des objets qui héritent des objets génériques de l'application et en redéfinissent les comportements.

Par exemple, un module peut afficher des boîtes de dialogue spécifiques pour saisir des paramètres qui lui sont propres là où il était prévu une boîte de dialogue générique. Un module peut redéfinir ou compléter la cartographie standard pour y brancher des outils spécifiques, pour l'améliorer ou l'adapter à des besoins particuliers.

Cette section constitue une proposition de conception objet pour l'application générique de croissance des arbres en peuplement dont les spécifications sont décrites dans les chapitres précédents.

5.3.2. Notions de bases et structures de données.    

On prévoie deux modes de fonctionnx modes de fonctionnement pour l'application : interactif et autonome, à partir de fichiers de commandes préalablement constitués.

Dans le premier cas, le logiciel est piloté par une interface graphique classique, constituée d'une fenêtre d'application, de menus déroulants, de boîtes de dialogues, de visualisations graphiques, etc... Cette interface permet à l'utilisateur de déclencher des actions et d'en contrôler le résultat au fur et à mesure de l'avancée des simulations. C'est l'utilisation classique, pour la mise au point ou la comparaison des modèles, la constitution de scénarios de gestion forestière par des professionnels ou pour l'enseignement, etc...

Dans le deuxième cas, c'est un interpréteur qui pilote le logiciel et qui déclenche les actions comme spécifié dans un fichier de commandes. Les sorties sont de type fichier et ne sont disponibles qu'en fin de simulation. Ce mode autonome permet de traiter des volumes importants de données ou de répéter plusieurs fois des simulations s'appuyant sur un modèle comportant des composantes aléatoires. Le logiciel pouvant fonctionner en ligne, il est envisageable de le lancer à distance, apr&ege; distance, après téléchargement par réseau des fichiers de commandes à traiter sur le serveur qui l'abrite.

Le logiciel s'appuie sur plusieurs notions liées hiérarchiquement.

La session englobe toutes les autres. Le logiciel gère des sessions de simulation, interactives ou en tâche de fond, qu'il est possible d'enregistrer et de rejouer à loisir. Une session comporte un ou plusieurs scénarios.

Le scénario est le mode d'organisation des simulations. A chaque scénario, est lié un modèle de croissance (avec des paramètres spécifiques) et un peuplement (avec des paramètres stationnels). Un scénario est composé de une ou plusieurs étapes successives, chaînées entre elles. Un gestionnaire de scénarios très semblable à celui de CAPSIS 2.x permet de gérer les étapes du scénario. Il est notamment possible de construire des variantes d'un scénario en créant plusieurs étapes à la suite d'une même étape de base.

L'étape est l'élément de base du scénario. Elle marque un point clé dans la sylviculturedans la sylviculture mise en oeuvre. L'utilisateur peut créer une étape de croissance (jusqu'à une limite spécifiée) ou une étape d'éclaircie (sélective ou systématique). L'étape est liée à un état donné du peuplement à un moment donné (ex: à 50 ans...). Cet état correspond à un stade.

Le stade enregistre l'état du peuplement à un moment donné. Le premier stade est créé à partir du fichier peuplement chargé pour le scénario. Suivant les modèles mis en jeu, il est possible de créer les stades précédents en faisant fonctionner le modèle de croissance à l'envers pour remonter à l'origine de la vie de chaque arbre. Les stades sont chaînés entre eux comme les étapes. Certains stades correspondent à des étapes de scénario, mais d'autres peuvent être cachés. Ainsi, si le cycle de fonctionnement du modèle est de 2 ans et que l'on considère deux étapes de croissance successives à 100 et 106 ans, les stades correspondant aux âges 102 et 104 ans ne sont pas visibles dans le scénario, alors que les étapes 100 et 106 permettent de visualiser l'état du peupleacute;tat du peuplement (stade) aux âges correspondants. De même, si la deuxième étape a pour condition d'arrêt une hauteur dominante spécifiée pour le peuplement, l'étape correspondra au premier cycle de deux ans ayant permis de dépasser cette hauteur. Le stade est constitués d'arbres dans un état donné.

Le peuplement comprend tous les paramètres de la placette (i.e. milieu, biotrope, endroit -> paramètres stationnels), tel que l'indice de fertilité par exemple. Il contient l'ensemble des arbres concernés par le scénario (références vers les arbres).

L'arbre possède ses caractéristiques propres, nécessaires au fonctionnement du modèle considéré. Chaque modèle décrit son arbre. Le logiciel propose deux arbres génériques, caractérisés par certaines informations dendrométriques classiques, et dont l'un possède des coordonnées (en trois dimensions). Les outils génériques proposés s'appuient sur ce tronc commun de données que les modèles renseignent dans la mesure du possible. Le fait de se limiter à deux arbres génériques permet de n'avoir que deux classes d'outideux classes d'outils génériques (visualisateurs, sorties graphiques...). Le modélisateur peut bien sur ignorer certaines données de l'arbre générique, comme la coordonnée hauteur pour un modèle 2D, ou la hauteur du houppier pour un simple modèle en diamètre. Il s'agit alors de spécifier que le modèle ne produit pas les sorties graphiques liées aux informations qu'il ne gère pas (ex : courbe d'évolution de la hauteur de la base du houppier). L'arbre spécifique hérite de l'un des deux arbres génériques (au sens objet) et précise les données supplémentaires qui le caractérisent. Il est manipulé par des méthodes du modèle qui calculent ses grandeurs à chaque cycle d'évolution (croissance, mortalité, régénération ou éclaircie).

5.3.3. Architecture - partie générique.    

Le logiciel générique permet de gérer la session, les scénarios et leurs étapes. Il gère le paramétrage de l'application, la production des visualisations, sorties graphiques ou fichier, en s'appuyant le cas échéant sur des mét sur des méthodes particulières des modèles. Il est prévu une aide générale et une aide propre à chaque modèle.

La partie générique du logiciel propose un moteur d'actions (noyau), une interface graphique redéfinissable (comportant un gestionnaire de scénarios), un interpréteur de scénarios hors-ligne, des visualisations standards pour les MADD et les MAID, ainsi que des sorties graphiques génériques basées sur l'arbre standard.

Le moteur d'actions générique fournit des méthodes permettant de lancer les actions organisationnelles ou fonctionnelles du logiciel. Il peut s'agir de la création, l'ouverture, la sauvegarde d'une session ou d'un scénario, du déclenchement d'une étape de croissance ou d'éclaircie paramétrée, etc... Ses méthodes sont invoquées par l'interface graphiques ou par l'interpréteur de commandes. Certaines de ses méthodes sont redéfinissables dans chaque modèle et produiront des effets différents suivant le contexte d'utilisation (modèle du scénario de l'étape sélectionnée).

L'interface graphique générique comporte des menus, une fenêtre principale abritant un gestionnaire de scénarios, un visualisateur d'étape, et une fenêtre (à onglets) ou sont rangés les résultats graphiques au cours de leur production. Des boîtes de dialogues standards sont proposées lors des actions de l'utilisateur, remplaçables par d'autres spécifiques au modèle.

L'interpréteur invoque les méthodes du moteur d'actions d'après des ordres qui lui sont fournis dans un fichier de commande. Un langage particulier permet de créer des scénarios et de les jouer en tâche de fond sur des fichiers peuplements pour les modèles qui le prévoient (doivent fournir des méthodes de chargement de leurs paramètres spécifiques à partir de fichiers...). Il est envisageable de générer un fichier de commandes à partir d'un scénario créé interactivement.

Les visualisations standards permettent de mesurer visuellement l'état du peuplement pour une étape de scénario. Il peut s'agir par exemple d'une cartographie type Selva pour les MADD et d'un double histogramme de répartition par clae;partition par classes de diamètres en début (i.e. à l'étape précédente) et en fin d'étape, assorti de données dendrométriques du peuplement, type CAPSIS 2.x pour les MAID.

Les dialogues standards interviennent à tout moment opportun pour demander à l'utilisateur des précisions, paramètres, confirmations.

Le gestionnaire de scénario permet de créer plusieurs scénarios (chacun avec son modèle de croissance, son paramétrage et son peuplement particulier, incluant les paramètres stationnels). Il gère l'ajout, la suppression et la consultation d'étapes après la dernière étape ou après une précédente (branche de scénario parallèle). Son fonctionnement n'est pas redéfinissable.

A l'ajout d'une étape, un dialogue "modal" (qui doit être terminé normalement ou annulé en bloc avant toute autre action), redéfini spécifiquement par le modèle associé au scénario et pouvant comprendre plusieurs boîtes de dialogue, détermine les paramètres nécessaires concernant la croissance ou l'éclaircie. La validation en. La validation entraîne l'invocation de la méthode croissance ou éclaircie du modèle avec les paramètres saisis. Le modèle calcule le nombre de cycles correspondants, génère les stades s'y rapportant et la nouvelle étape est connectée au dernier d'entre eux. La visualisation est mise à jour pour correspondre au stade de l'étape et les sorties graphiques prévues par le modèle sont ajoutées à la fenêtre de résultats.

Des sorties standards sont proposées, utilisables par chaque modèle, sur la base des sorties proposées par Selva et CAPSIS 2.x. Ces sorties ne sont produites que si spécifiées pour le modèle.

5.3.4. Architecture - partie spécifique.    

Un modèle de croissance est constitué d'un ensemble de classes, héritant de classes génériques ("spécifiant" les classes génériques) du logiciel ou non. Les classes de chaque modèle doivent respecter une convention de nommage commune pour garantir l'unicité des noms de classes (ex: préfixe de trois lettres pour chaque classe).

Certaines méthodes peuvent être redéfinies dans des classes spécifiant les classes du modèle générique. A l'inverse, certaines méthodes ne sont explicitement pas redéfinissables. Ainsi, on interdit la modification de la gestion des sessions, scénarios, étapes et cycles qui forment le socle partagé du logiciel. De même, la gestion de la fenêtre résultats ne devrait pas faire l'objet de redéfinitions.

Les modèles peuvent redéfinir l'arbre de leur peuplement, les paramètres stationnels et les paramètres propres au modèle (coefficients...), ainsi que les comportements associés. Le logiciel donne la main explicitement au modèle pour la phase de mise en oeuvre de la croissance et de l'éclaircie. Les autres modifications interviennent comme des dérivations du fonctionnement normal. Le modélisateur, aidé du coordinateur, doit s'assurer de la cohérence de ses interventions pour fournir un comportement stable.

Une classe moteur spécifique portant le nom du modèle et spécifiant la classe moteur d'action générique doit fournir la redéfinition de plusieurs méthodes, concernant en particoncernant en particulier la croissance, l'éclaircie et leurs paramètres. Ainsi, par exemple, la méthode croissance générique étant vide (croissance ()), elle doit être redéfinie pour appliquer le modèle sur les arbres du peuplement dans l'état où ils sont, au stade correspondant à l'étape sélectionnée (ex : croissance (int ageCible) ou croissance (int hauteurDominanteCible))

Une interface spécifique permet de redéfinir les dialogues et certains menus (éventuellement). Ces dialogues permettent de saisir des paramètres particuliers. Le modélisateur étant maître du dialogue, il peut sauver les valeurs saisies où bon lui semble dans les variables d'instances des objets de son modèle.

Pour les visualisations spécifiques, plusieurs possibilités. Les visualisateurs étant des objets complexes (volumineux), le modèle générique en fournit un pour chaque type de modèle (MADD et MAID), utilisable en l'état. Ils représentent les données de l'arbre générique correspondant (histogrammes de répartition pour les MAID et cartographie pour les MADD). Le modélisateur peut intervenir de plusientervenir de plusieurs manières pour adapter le visualisateur.

Complément du visualisateur : ajout de zones de boutons ou de tableaux de valeurs renseignant sur l'évolution des données propres au modèle. Des boutons ajoutés peuvent déclencher l'apparition d'autres visualisations particulières, entièrement gérées par le modélisateur (histogrammes de type Selva par exemple).

Complément des graphiques du visualisateur : interception du graphique avant affichage dans le visualisateur standard pour complément : représentation de chablis, de houppiers, de déformation de troncs, etc...

Réécriture complète du visualisateur pour remplacer le standard, si le mode de visualisation choisi s'en éloigne trop.

Les sorties graphiques spécifiques sont des sorties standards et/ou des sorties particulières dont la liste à produire pour chaque étape créée est prévue par le modèle. Il est envisagé de fournir des outils génériques utilisables par les modélisateurs pour créer rapidement des histogrammes, courbes, tableaux... présentant un aspect et des foncun aspect et des fonctionnalités homogènes. On peut envisager de ranger automatiquement les sorties dans un nouvel onglet apparaissant dans une fenêtre résultat. Le choix d'un nouvel onglet a pour effet de sélectionner l'étape correspondante et de mettre à jour le visualisateur. Un mécanisme doit permettre d'exporter les résultats vers d'autres applications ou la génération directe de rapports imprimables.

5.3.5. Modèle Objet.    

Un modèle objet est proposé pour l'application (figure 1). Il représente dans sa partie haute le modèle du logiciel générique et dans sa partie basse, la structure d'un module de modélisation (ex : Cem pour Epicéa du Cemagref).

L'objet central est le moteur d'action générique (GenericKernel) qui décrit les actions connues du logiciel, classées en deux catégories : organisationnelles et fonctionnelles.

Les actions d'organisation concernent la gestion des sessions, scénarios, étapes, paramétrage du logiciel, sauvegardes, exportation... En général, elles ne docute;ral, elles ne donnent pas lieu à redéfinition dans les modules de modélisation.

Les actions fonctionnelles concernent la croissance, la mortalité, la régénération et l'éclaircie, soit toutes les actions touchant à l'arbre ou au peuplement étudié. Elles ne sont qu'ébauchées au niveau génériques (on peut proposer des actions standards) et sont destinées à être redéfinies spécifiquement pour chaque modèle.

Le modèle proprement dit est une classe (ex : CemModel) qui hérite du GenericKernel et redéfinit les actions fonctionnelles. Il possède ses propres paramètres spécifiques (coefficients ...).

L'interface graphique générique (GenericInterface) est spécifiée en CemInterface qui redéfinit les dialogues et autres éléments visuels spécifiques au modèle.

Le modèle Cemagref Epicéa peut utiliser le visualisateur MADD générique (GenericMaddVisu), le spécifier ou le modifier.

Les résultats produits à chaque étape peuvue étape peuvent être ceux prévus par le GenericMaddResults, éventuellement complétés ou avec certaines modifications.

La Session, les Scénarios, les étapes (Step) et stades successifs du peuplement (State) sont gérés par le GenericKernel. Ils sont construits en fonction des actions de l'utilisateur sur l'interface graphique (ou des actions générées par le GenericInterpreter à partir d'un fichier de commandes).

Le modèle gère un peuplement (CemStand) comportant des paramètres stationnels propres et des arbres (CemTree) ayant les caractéristiques particulières souhaitées en plus de celles de la classe dont il hérite : GenericMaddTree (qui comporte des positions et des grandeurs dendrométriques communément utilisées -> à définir). Il effectue des opérations de croissance ou d'éclaircie sur le dernier état du peuplement (il peut pour cela accéder aux n états précédents disponibles) et génère un ou plusieurs états nouveaux dont le dernier est connecté à la nouvelle étape créée.

5.3.6. Aspects techniques.    

5.3.6.1. Liaison dynamique des modèles.    

Les modèles de modélisations constituent des modules chargeables à l'exécution, plus précisément à la création (ou l'ouverture) d'un scénario.

Le modèle est choisi par son nom dans une liste déroulante et instancié dynamiquement. Une fois instancié, le moteur d'actions spécifique instancie son interface spécifique et les envois de messages (objets) sont envoyés aux objets spécifiques. Quand ceux-ci redéfinissent une méthode du modèle générique, c'est la méthode redéfinie qui est invoquée. Quand une méthode n'est pas redéfinie, c'est la méthode de même nom de la superclasse qui est invoquée, donc la méthode générique. Le même principe est utilisé pour le moteur d'actions et pour l'interface graphique.

Ainsi par exemple, quand on veut ouvrir une boîte de saisie de la valeur limite pour une étape de croissance, on invoquerassance, on invoquera la méthode de l'interface graphique du modèle spécifique. Si la méthode a été redéfinie, elle permettra de rentrer une hauteur dominante (sauvegardée dans une variable d'instance du modèle), sinon la méthode standard demandera un âge à atteindre.

5.3.6.2. Structure des données en mémoire et sur disque.    

Chaque cycle de simulation comporte un état (stade) du peuplement entier, arbre par arbre. Le grand nombre de données gérées incite à envisager une méthode de gestion des données en mémoire et sur disque transparente pour le programmeur (ex : figure 2. et figure 3.).

A la création d'un nouvel état du peuplement (stade) en mémoire, une référence est calculée à partir des références de session, scénario et d'un numéro de stade. Un fichier stade est sauvegardé sous cette référence sur disque (répertoire particulier pour la session et le scénario) et le stade est gardé en mémoute; en mémoire.

Quand la mémoire est pleine (à l'occasion de l'instanciation d'un objet quelconque), un ou plusieurs stades sont effacés de la mémoire pour faire de la place (jusqu'à ce qu'il y ait suffisamment de place pour l'instanciation). On efface de préférence des stades situés dans des scénarios qui ne contiennent pas l'étape courante.

Quand on a besoin des données d'un stade (à partir de sa référence calculée), un mécanisme transparent le recharge depuis le disque s'il n'est plus présent en mémoire.

Cette méthode permet de travailler en mémoire tant qu'on en a, puis de "swapper" sur le disque quand on en a plus. La stratégie de "swap" peut être modifiée sans modifier les traitements des modélisateurs.

Les écritures sur disque relatives au "swap" peuvent se faire au format binaire, puisqu'elles concernent des sauvegardes de travail d'états internes du logiciel. Les fichiers destinés à l'interfaçage avec d'autres logiciels sont générés à la demande, pour un arbre ou un scénario particulier. Ils sont au format texte (ASCII).
(ASCII).

5.3.6.3. Langage.    

Le développement de l'application suivant l'architecture objet décrite dans les paragraphes précédents nécessite un langage de développement orienté objets. SmalTtalk, Simula et Eiffel (etc...) ne sont pas des langages suffisamment "industriels" (rapides, largement diffusés, compilables sur suffisamment de plate-formes...) pour pouvoir prétendre être retenus. Les deux langages proposés sont donc C++ (Bjarne Stroutstrup, AT&T) et Java (Sun Microsystems).

C++ est le langage orienté objets le plus utilisé dans l'industrie pour différentes raisons. Il est une extension du langage C (Kernigan & Ritchie) qui est lui-même très largement employé. Ce dernier permet la programmation structurée (comme Pascal) et dispose d'une syntaxe très concise. C'est un langage compilé et performant qui est très apprécié des développeurs. C++ est une tentative de création d'un langage objet à partir de C. Il est de notoriété publique (du moins dans le milieu universitaire) que le résultat, s'il permet de rempt, s'il permet de remplir les conditions de la programmation orientée objets, n'est pas très heureux.

En effet, si C++ est apprécié des développeurs, c'est qu'il semble aisé de passer en douceur de C à C++ (même syntaxe), parce qu'il y a peu d'alternatives, parce qu'il est performant et... très utilisé. En réalité, le langage est complexe, le développeur doit être vigilant quand à la gestion des pointeurs (comme en C) et des références d'objets (nouveauté).

De C, il reprend le précompilateur, qui permet la compilation conditionnelle, l'interprétation et l'extension des macro-instructions dans les sources avant la compilation. L'utilisation abusive de ces "macros" nuit terriblement à la lisibilité du code (c'est l'un des problèmes de CAPSIS 3.0) et la maintenance en est (encore) complexifiée.

La confusion entre structure, union et classe, la possibilité de mélanger des portions de code en C et des classes de descriptions d'objets, la "permissivité" du compilateur qui laisse passer des erreurs potentielles en effectuant des transtypages discrets qui réservent des surprises à l'exécution, l'exécution, la multiplication des sources et la subtilité du langage (décrit intégralement dans un ouvrage de référence de 900 pages) génèrent des difficultés de "débuggage" d'évolution et de maintenance inhérentes au langage lui-même qui allongent d'autant toute intervention sur le projet.

C++ reste bien sûr utilisable en adoptant des règles de programmation strictes et en confiant le développement à des programmeurs expérimentés qui maîtriseront ses difficultés et profiteront de ses avantages (on peut tout faire en C++ et c'est performant).

Java est un langage orienté objets créé de toutes pièces par Sun Microsystems il y a quelques années (1995). Il s'agit techniquement d'un intermédiaire entre des langages "tout objets" comme Eiffel et SmallTalk et les langages moins "purs" et plus performants comme C++.

C'est un langage mi-compilé, mi-interprété. La phase de compilation produit la génération d'un pseudo-code qui est ensuite interprété par une machine virtuelle Java. L'intérêt de la chose est que la machinemachine virtuelle Java est portée par Sun ou d'autres sociétés sur la plupart des plate-formes du marché et qu'un programme Java utilisant toutes les possibilités du langage est directement portable sans recompilation sous Windows, Macintosh, Solaris, HP-UX, Irix, Linux, IBM-AIX, etc... Bien souvent, la machine virtuelle est écrite directement par le constructeur du matériel (qui a intérêt à vendre du matériel pouvant supporter les applications Java) ce qui est un gage de sérieux. Java intéresse beaucoup les constructeurs et éditeurs de logiciels parce qu'il permet de s'affranchir de la position de quasi monopole de Microsoft dans le domaine des systèmes d'exploitations pour micro. Cela explique le soutien qu'ils procurent à Sun dans la promotion de Java (pérennité).

Ce langage a été pensé de A à Z pour présenter le plus possible d'avantages. Citons (dans le désordre) l'allocation / libération de mémoire automatique (Un ramasse miettes se charge de la libération de la mémoire occupée par les objets qui ne sont plus référencés - sans qu'il soit nécessaire de définir des destructeurs), la disparition de la gestion manuelle d gestion manuelle des pointeurs et références, sources d'erreurs (pointeur null) dans les langages à pointeurs. Java passe les types fondamentaux par valeur (recopie) et les objets par référence sans qu'il existe de syntaxe ou d'arithmétique se rapportant aux pointeurs ou références. Java n'utilise pas de précompilateur, les macro-instructions de C et C++ n'existent donc plus (inutiles). Les fichiers entête ont été abandonnés, ainsi que la surcharge des opérateurs. La taille des types de données fondamentaux est spécifiée dans le langage (ex : int fait 32 bits sur toutes les plate-formes).

La syntaxe du langage est la même que celle du C. L'héritage multiple est impossible. C'est un choix qui interdit les conflits de noms ou de valeurs dans une hiérarchie de classes et simplifie la programmation. En contrepartie, il est possible de spécifier qu'une classe (qui hérite éventuellement d'une autre), implémente une Interface, c'est à dire qu'elle doit définir un ensemble de méthodes décrites par l'interface. Le compilateur est très strict, il va jusqu'à exiger l'initialisation des variables et le traitemes et le traitement des exceptions qui peuvent être levées par certaines portions de code. Une classe Thread permet de faciliter grandement la gestion des threads.

Un ensemble de librairies standardsportables couvre l'ensemble des besoins du développeur, interfaces graphiques, fonctions mathématiques, conteneurs, flux et fichiers, accès aux bases de données, invocation de méthodes distantes, utilisation de code natif (en C par exemple), internationalisation, dessin 2D, dessin 3D, etc... L'utilisation de ces librairies ne nécessite pas de recompilation sur la nouvelle plate-forme.

Les inconvénients de Java sont notamment : un manque de performances comparé aux langages compilés et optimisés, du à l'emploi d'un interpréteur et à la gestion automatisée de la mémoire ; l'impossibilité d'écrire certains programmes qui nécessitent les pointeurs ou bien qui doivent être particulièrement performants (drivers...) ; le manque de contrôle dans certains cas nécessitant une maîtrise parfaite de l'affichage (dithering pour la synthèse d'image).

Les problèmes de performances sont en partie résolupartie résolus par la récente machine virtuelle Java 1.2 qui est plus performante que celle de Java 1.1, l'utilisation de "Just In Time compilers" sur certaines plate-formes (compilation à l'exécution : la méthode est interprétée la première fois, puis c'est la version compilée qui est utilisée), la possibilité de compiler sur certaines plate-formes (Symantec permet de créer un exécutable sous Windows) et l'apparition récente de Hotspot, la nouvelle machine virtuelle de Sun qui repère les portions de code qui prennent le plus de ressources et qui les compile et les optimise dynamiquement. Les machines virtuelles Java récentes permettent de choisir des options pour la gestion de la mémoire, qui a été par ailleurs optimisée. Pour finir, les simulations volumineuses, nécessitant beaucoup de temps de calcul peuvent être effectuées en tâche de fond, comme l'architecture de l'application le prévoie, réduisant par là même la portée des problèmes de performance.

Le projet à l'étude prévoie la répartition du développement entre le coordinateur et les modélisateurs. Ces derniers ne sont pas forcément des programmeurst des programmeurs expérimentés. Le choix de Java comme langage de développement semble préférable, tant sur le plan de la simplicité (pour un langage objets) que de la portabilité, de la rapidité de développement et de la stabilité du code obtenu. Il est en effet beaucoup plus facile d'obtenir du code sans erreurs avec Java qu'avec C++.

haut de la page