OdefiX - Objectifs - Interface graphique - API - GUI

Cette partie présente l'architecture générale du développement. Elle détaille notamment les classes créées pour concevoir l'interface graphique générique présentée à la section précédente.

L'architecture de l'application, présentée dans la figure 5.1, est définie par le regroupement de classes dans des paquetages. Les relations entre paquetages définissent les dépendances dans l'application et déterminent la stabilité de l'architecture.

Figure 5.1. - Architecture générale

• Le paquetage java regroupe tous les paquetages du kit de développement fourni par Sun Microsystems. Nous utilisons le JDK 1.4 (Java Development Kit).

• Le paquetage data contient des classes nécessaires à la construction et à l'évolution des modèles.

• Le paquetage gui : Graphical User Interface regroupe les classes écrites pour l'interface graphique de l'application. Ce package est fortement lié au package data puisqu'il sert à les figurer, ainsi qu'à les manipuler et les visualiser.

• Le paquetage applicatif_métier applicatif_métier correspond aux classes propres à un modèle spécifique. Ce dernier est basé sur le package data, les données d'un modèle dérivant des données génériques. Le package gui sert quant à lui à représenter ces données

L'intérêt de l'architecture réside dans la souplesse de modification pour ajouter de nouvelles caractéristiques. La génération d'applicatifs dédiés est facilitée par la structuration proposée, qui permet ainsi une extension aisée des types de composants à étudier.

Les classes de base

La présentation de l'interface graphique générique a montré l'intérêt de spécifier la notion générale de définition. Tout objet manipulé peut être traité comme une définition plus ou moins complexe. Il peut se ramener dans tous les cas à la définition d'une donnée de type simple comme une chaine de caractères, un réel, un entier, un booléen. Ces données peuvent elles mêmes être traitées comme des définitions.

Dans OdefiX, les données manipulées par le modèle seront toutes décrites par une Definition. Tout objet du monde réel nécessaire au modèle, qu'il soit concret (réservoirs, bassin versant, etc.) ou abstrait (chroniques des pluies ; variation dans le temps de certaines données, etc. ), pourra et devra être représenté par une Definition. Ces définitions sont plus ou moins complexes selon le type d'élément qu'elles vont figurer.

Figure 5.2. - les classes de base

L'abstraction Definition

Pour un objet, être une Definition assure de la spécification de :

• un label, qui constitue la dénomination de l'objet ;
• un identifiant le définissant de manière unique ;
• un type, qui permet de qualifier l'objet par une brève description (méthode getType()) ;
• la représentation et l'affectation possible des données sous forme d'une chaine de caractères (méthodes toString() et set(String s)) ;
• la validité de l'objet (renvoi des incohérences);
• la représentation de l'objet, sous forme d'un modèle de tableau (TableModel), suivant différents points de vue : description, définition, validité, résultats, etc.

Toute Definition possède également un formalisme en XML et pourra donc être stockée dans un fichier au format XML puis restaurée depuis ce fichier. Cet enregistrement/restauration des données en tant que fichier ne se fait que pour les Definition qui sont également des Documents. Toute Definition possèdera forcement un Document comme parent dans un des niveaux supérieurs de sa hiérarchie. Un document est une définition complexe, extensible, qui peut être chargée et sauvée au format XML. C'est un composant de base de l'environnement de travail.

L'avantage des Definitions est l'homogénéité. En effet, si chaque modèle et ses données sont représentés sous forme de Definition, il sera d'autant plus simple de faire cohabiter les modèles, ce qui est la finalité d'OdefiX.

-A VOIR-
- explications sur persistance en XML
- explications sur gestion de l'indexation
- explications sur la gestion des modifications sep-2004

OdefiX offre un ensemble de Definitions qui seront communes à de nombreux modèles. Il fournit pour cela des Definitions correspondant aux données primitives des langages de programmation (les chaînes de caractères, les nombres entiers, les nombres à virgule flottant, les booléens ), ainsi que l'équivalent des tableaux à une et deux dimensions de ces données primitives.

A chaque définition Data est associé un DataType, qui spécifie le type des données représentées (un nombre représentant un débit est différent d'un nombre représentant une coordonnée). Un type Datae données possède donc différents attributs (des bornes de validité minimale et maximale, une valeur par défaut, une unité, un format, une précision, etc.) Ces types de données sont répertoriés dans des catégories et principalement défini dans des fichiers XML. Les types de données communs à tous les modèles sont stockés dans la catégorie OdefiX, tandis que chaque modèle spécifique possède sa propre catégorie, et éventuellement son propre fichier XML.

Figure 5.3. - les définitions de type de base

Exemple de types simples sous leur forme XML :
Le type de la catégorie OdefiX décrivant un nombre à virgule flottant quelconque :
<type id="real" label="Real" base="real" minValue="0" maxValue="1000000000000" precision="0.01" format="0.0#"/>
Le type de la catégorie ZonAgri décrivant un prix se basant sur le type simple de base décrit ci-dessus:
<type id="price" label="Prix total" base="real" desc="Prix des produits total" minValue="0" maxValue="100000" precision="0.01" unit="euro" cumul="true" format="0.00" holeValue="-1"/>

-A VOIR-
- explications sur le formatage
- explications sur la gestion des unités

Une Definition possède un contenu qui peut être simple ou complexe, extensible ou prédéfini. Une Definition complexe pourra donc contenir d'autres Definition, elles-mêmes pouvant être complexes. Il apparaît alors la notion de hiérarchie, chaque Definition possédant une Definition parent et des Definitions enfants, en ce qui concerne les complexes. Les Definitions extensibles peuvent recevoir un certain nombre de Definition d'un certain type, défini par le programmeur et correspondant à la nature spécifique de l'objet contenant.

Figure 5.4. - les définitions "complexes"

Par exemple, un réservoir peut être défini pour une contenance maximum et un débit constant, qui seront tous deux des définitions simples. Une zone géographique peut alors être décrite comme un ensemble de réservoirs. Ce sera alors une définition complexe et extensible, qui possèdera une liste de réservoirs, c'est-à-dire une liste de Definitions complexes.

- soit créer une Definition qui n'est en fait qu'un raccourci, une référence à une Definition déjà définie ailleurs dans l'arborescence de l'environnement de modélisation. Ainsi, toute Definition de type Document sera manipulée à travers des associations ;

- soit définir une liste de Definition, à partir de laquelle on pourra choisir le type de Definition de l'objet. Par exemple, une valeur peut être définie par un nombre ou bien par un calcul (une formule). Ce sera à l'utilisateur de choisir le mode de définition.

Figure 5.5. - les associations

La figure 5.5 présente l'arbre d'héritage des classes pour la gestion du temps : pas de temps, variations saisonnières, chroniques, etc.

Figure 5.5. - Les classes de gestion du temps

Le pas de temps est introduit par la classe abstraite TimePeriod qui hérite de AbstractIntDefinition. La classe TimePeriod assure en plus la spécification :

• d'un calendrier de référence, on utilise le calendrier grégorien disponible dans le paquetage java.utilgetCalendar()) ; (méthode
• d'un format de date (méthode getFormat()) ;
• du passage au pas de temps suivant (méthode toNext()) ;
• du nombre de jour du pas de temps (méthode getDays()) ;
• de diverses méthodes intéressant les dates (méthode isLeapYear(int _year), etc).

Les classes YearStep, MonthStep, D10Step et DayStep assurent l'implémentation de la spécification d'un pas de temps respectivement annuel, mensuel, décadaire (au sens météorologique c'est à dire période du 1 au 10, du 11 au 20, et du 21 à dernier jour du mois) et journalier.

La variation saisonnière d'une caractéristique numérique est introduite par la classe YearlyVariation qui hérite de TimeVariation donc de AbstractDefinition. La classe YearlyVariation assure, à partir de la définition des valeurs mensuelles interannuelles, la spécification :

• de la valeur de la variable pour une décade ou un jour particulier, actuellement traitée par interpolation linéaire (méthodes getValue(D10Step _step) et getValue(DayStep _step)) ;
• de chroniques de valeurs interpolées en décadaire et journalier (méthodes getD10Chronicle() et getDayChronicle).

La classe Chronicle permet de définir la variation d'une caractéristique numérique à pas de temps fixe sur une grande période. La chronique peut être affectée à partir d'un fichier (méthode set(java.io.File file)). Le pas de temps début (méthode getFirstStep()) spécifie le type de variation : annuelle, mensuelle, décadaire ou journalière.

-A VOIR-
- explications sur le package data.time

Cette extension est basée sur une structuration générique des données (gestion de cartes, plans, schémas, graphes, etc) par un typage des informations et propose une formalisation de la gestion du temps autorisant les animations graphiques.

Figure 5.6. - Les classes de représentation en 2D

Le document cartographique est une Definition composée d'objets Couche. Un document peut contenir une ou plusieurs couches. Chaque couche correspond à une agrégation d'objets permettant une représentation en deux dimensions et possédant des informations associées.

Ces objets, que nous dénommons Série, sont donc décrits par une série de valeurs x et de valeurs y, les types de valeurs correspondants et une liste d'informations associées.

-A VOIR-
- explications sur le package data.map
- explications sur les parsers ASCII dont le parser Mif/Mid