Portage du modèle de simulation SISFRT

HAL Id: hal-02794838

https://hal.inrae.fr/hal-02794838

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Portage du modèle de simulation SISFRT

Pierre-Alexandre Guénolé, Ecrah Hoba Ulrich Eza

To cite this version:

Pierre-Alexandre Guénolé, Ecrah Hoba Ulrich Eza. Portage du modèle de simulation SISFRT. Envi-ronnement et Société. 2014. �hal-02794838�

Institut Supérieur d’Informatique de Modélisation et de leurs Applications Campus des Cézeaux 24, Avenue des Landais BP 10 125

63 173 AUBIERE cedex

INRA UREP Unité de Recherche sur l'Ecosystème Prairial 5 chemin de Beaulieu 63039 Clermont-Ferrand cedex 2

Rapport d’ingénieur Projet de 3ème année

Filière F2 - Génie Logiciel et Systèmes Informatiques

Portage du modèle de simulation SISFRT

Présenté par : Pierre-Alexandre GUÉNOLÉ Ecrah EZA

Responsables ISIMA : Loïc Yon, Claude Mazel Projet de 120 heures

REMERCIEMENTS

Nous tenons tout d'abord à remercier nos deux tuteurs INRA, Raphaël Martin et Julien Pottier, pour nous avoir permis d'acquérir de l'expérience à travers ce projet.

Nos remerciements s'adressent également à nos encadrants ISIMA, à savoir Loïc Yon et Claude Mazel, qui nous ont permis de réaliser notre projet dans les meilleures conditions possibles, et nous ont guidés dans les choix techniques au cours de nos réunions.

RÉSUMÉ

SisFRT est un modèle stochastique, individu centré, simulant le développement des brins d’herbe (talles) dans les prairies. Il s’intéresse à la dynamique démographique des talles des différentes espèces, à leurs déplacements dans l’espace ainsi qu'à la morphogenèse de leurs principaux organes (feuilles, racines et rhizomes). Simuler un tel système est complexe et nécessite beaucoup de puissance de calcul. Et comme la plupart des supercalculateurs fonctionnent sous un système d'exploitation Unix, il fallait porter SisFRT du C++/CLI vers un langage portable, le QT/C++.

Nous avons isolé le code au cœur de l'application existante et l'avons intégré dans une nouvelle interface utilisateur développée en QT/C++. Nous avons utilisé Qt Designer pour ajouter rapidement les widgets composant la nouvelle interface. La logique derrière les

widgets et le lien entre l'interface utilisateur et le modèle ont ensuite été ajoutés. L'application

peut être exécutée soit en mode graphique, soit en mode console. Ce dernier mode est important dans le cas d'une exécution sur un supercalculateur. Les tests unitaires nous ont permis de nous assurer que nous n'avions pas introduit de nouveau bug à la suite du portage.

Le but principal de notre projet a été atteint puisqu'il ne reste plus aucune dépendance au C++/CLI. L'application a par ailleurs été améliorée par l'ajout de nouvelles fonctionnalités, telles que l'internationalisation, la validation des données saisies, ou encore par la prévisualisation des résultats de simulation dans un nouvel onglet. Le format de fichier utilisé pour stocker ces résultats a également évolué du format Idrisi vers un format plus général et bien connu dans le monde scientifique : NetCDF.

ABSTRACT

SisFRT is a stochastic individual based model, simulating the development of grass in the pastures. It focuses on the demographic dynamic of different species, their movements in space and the morphogenesis of their main organs (leaves, roots and rhizomes). Simulating such a complex system requires a lot of power. Since most supercomputers run on Unix operating system, SisFRT had to be ported from C++/CLI to a portable language, QT/C++. We have taken the core code of the existing application and wrapped it in a new user interface developed in QT/C++. We have used Qt Designer to efficiently add the widgets composing the new user interface. Then the logic behind these widgets and the link between the user interface and the model have been added. The application can be run in either graphical mode or console mode. The later mode is important in order to run the application on a supercomputer. Many unit tests have also been carried out to make sure no new bug is introduced during the porting.

The main goal of our project has been successfully reached since no dependencies upon C++/CLI remains. The application has also been improved by adding new features, such as multi-language support, input data validation, or the preview of the simulation results in a new tab. The file format used for these results has also been upgraded from a basic Idrisi format to a much more general and well-known format in the scientific field: NetCDF.

T

Introduction ... 6

I-

Contexte d'étude ... 7

A- Présentation de l'entreprise à l'initiative du projet ... 7

B- Contexte de recherche ... 8 C- SisFRT ... 8 1- Historique ... 8 2- Présentation générale ... 8 D- Objectif du projet ... 9 E- Planning ... 9

II-

Portage du modèle ... 11

A- Mise en œuvre du portage ... 11

1- Documentation préliminaire ... 11

2- Restructuration du dépôt svn ... 11

B- Mode console & tests de non régression ... 12

1- Mise en place du mode console ... 12

2- Validation des tests unitaires ... 12

C- Améliorations apportées au modèle ... 13

1- Générateurs pseudo-aléatoires ... 13

2- Migration d'idrisi à netCDF ... 14

III-

La nouvelle interface graphique ... 16

A- Construction de la nouvelle interface ... 16

1- Constat et besoins utilisateur ... 16

2- Mise en œuvre ... 16

B- Amélioration de l'existant ... 18

1- Redimensionnement ... 18

2- Désactivation / Activation d'onglets ... 18

C- Nouvelles fonctionnalités ... 18

1- Vérification de la saisie ... 18

2- Internationalisation ... 21

3- Gestion de l'affichage des cartes netCDF ... 23

Conclusion ... 27

Annexe A – Guide pour la traduction de SisFRT avec Qt Linguist ... 29

T

Figure 1 - Organigramme de fonctionnement de l'UREP[1] --- 7

Figure 2 - La machine virtuelle CLR convertit le CIL en code machine --- 9

Figure 3 - Diagramme de Gantt --- 10

Figure 4 - Exemple fichier netCDF --- 15

Figure 5 - Modifications des fichiers de paramètres --- 15

Figure 6 – Structure globale de la fenêtre --- 16

Figure 7 : Aperçu de la barre d'outils de la nouvelle interface graphique --- 17

Figure 8 : Le fichier de ressources regroupe toutes les icônes de l'application --- 17

Figure 9: Infobulle dans le cas d'un nombre --- 19

Figure 10 : Cas d'une saisie de type texte --- 19

Figure 11 : 103 erreurs de saisie ont été détectées --- 20

Figure 12 : Détail des erreurs de saisie. Certains champs ont une valeur erronée car inférieure au min, d'autres contiennent du texte au lieu d'un nombre et certains ont tout simplement été laissés vides. --- 21

Figure 13 : Dans cet exemple, l'utilisateur a cliqué sur l'erreur concernant le champ gr_leRepartUnifNQte. L'onglet Grille s'est alors ouvert laissant apparaître le champ en question avec un fond coloré. La valeur saisie est négative, l'erreur est légitime car une concentration ne peut pas être négative. --- 21

Figure 14 - Schéma de fonctionnement de la traduction avec Qt Linguist --- 22

Figure 15 : aperçu général de l'onglet NetCDF avant sélection d'un fichier source --- 24

Figure 16 : Le fichier source a été chargé, la heatmap affiche les données du fichier. --- 25

Figure 17 : Liste des variables contenues dans le fichier netCDF --- 25

Figure 18 : Pour générer le fichier netCDF utilisé ci-contre, nous avons lancé une simulation en cochant les options suivantes dans l'onglet Sorties --- 25

Figure 19 : Échelle en mode automatique/manuel --- 26

Figure 20 : Mode échelle logarithmique --- 26

Figure 21 : Message avertissant que des valeurs négatives ou nulles empêchent l'utilisation de l'échelle logarithmique.--- 26

Figure 22 : Hiérarchie du fichier XML contenant les traductions. Les widgets sont regroupés par onglet par faciliter leur identification. --- 37

Figure 23 : Extrait du fichier XML regroupant les traductions --- 38

L

6

I

NTRODUCTION

SisFRT (SImulateur Spatialisé des Feuilles, des Racines et des Talles) est un modèle stochastique simulant le développement des brins d’herbe (talles) ainsi que de leurs feuilles, racines et rhizomes, dans un espace virtuel représenté par une grille. L’environnement dans SisFRT est fortement paramétrable. Il est possible de définir les conditions météorologiques, la fertilité du sol, le régime de gestion (coupe des brins d’herbe et fertilisation notamment), etc.

SisFRT met en compétition, dans un même environnement, des talles d’espèces différentes afin d’identifier les propriétés conférant à certaines espèces une meilleure réponse aux stress environnementaux1. Il permet également d’analyser les dynamiques démographiques de chaque espèce ainsi que leur étalement dans l’espace, en fonction de diverses conditions environnementales.

Simuler un tel système est complexe et nécessite beaucoup de puissance de calcul. Cette puissance de calcul est bien souvent mise à disposition au travers de plusieurs supercalculateurs fonctionnant sous un système d'exploitation Unix.

Il serait donc intéressant de supprimer la dépendance forte qu'il existe entre SisFRT et le système d'exploitation sous lequel il a été développé : Windows.

C'est dans ce cadre que s'inscrit notre travail, dont le but sera de porter SisFRT du C++/CLI vers le QT/C++, qui présente l'avantage d'être multiplateforme.

Afin de présenter le travail réalisé, ce rapport sera constitué de trois parties. Dans la première, nous présenterons le contexte d'étude. La seconde partie sera consacrée au portage du modèle et dans la dernière, nous présenterons la nouvelle interface graphique mise en place.

7

I- Contexte d'étude

A- Présentation de l'entreprise à l'initiative du projet

L’Institut National de la Recherche Agronomique (INRA) est un organisme de recherche publique Français dont le domaine de recherche est l'agronomie. C'est le premier institut de recherche dans son domaine en Europe, et le deuxième au niveau mondial (en matière de de publications). L'INRA est présent sur l'ensemble du territoire français, à travers plusieurs centres eux-mêmes divisés en unités.

Notre projet a été créé par le centre de Clermont-Ferrand – Theix, au sein de l'Unité de Recherche sur l'Écosystème Prairial (UREP). « Cette unité possède une expertise

internationale dans le domaine de l'écologie prairiale et plus particulièrement sur l'impact du changement climatique, les bilans de gaz à effet de serre, la séquestration de carbone, les cycles carbone et azote, les interactions plantes-sol (microorganismes) et herbe-animal, ou encore les effets des pratiques de gestion sur la dynamique prairiale »2.

Figure 1 - Organigramme de fonctionnement de l'UREP[1]

2 _{D’après le document}

8

B- Contexte de recherche

Les prairies présentent une biodiversité garante de nombreux services écologiques rendus aux populations humaines et particulièrement au monde agricole. Or, cette biodiversité, principalement constituée des espèces végétales dont la majorité d’entre-elles appartiennent à la famille des graminées, présente une certaine vulnérabilité face aux évènements climatiques extrêmes comme les sécheresses. Cette vulnérabilité dépend de la biologie propre des différentes espèces de graminées et potentiellement de leur comportement (développement) en mélanges. Le projet Climagie (metaprogramme ACCAF) se propose d’identifier des mélanges d’espèces capables de résister au mieux à des évènements de sécheresse, ainsi que des pratiques agricoles (modalités de fauche ou pâturage, fertilisation) permettant d’optimiser la résistance des mélanges.

Les moyens à la disposition des chercheurs pour atteindre ces objectifs sont l'observation, l'expérimentation et la modélisation.

C- SisFRT

1- Historique

Le modèle SisFRT, objet du projet, permet de simuler la morphogénèse de brins d’herbes de différentes espèces au cours du temps et cela dans différents contextes climatiques. Il est pressenti pour faire émerger les paramètres d’espèces qui produisent les mélanges les plus résistants à la sécheresse par analyse de sensibilité.

Le projet SisFRT a débuté en 1997 sous le nom de SisTAL (SImulateur Spatialisé du TALlage). Le développement de SisTAL s’est prolongé pendant neuf ans grâce à des stages et projets et a conduit à deux publications (Mazel et al, 2005 et Lafarge et al, 2005).

Ce modèle ne suffisait toutefois pas à rendre compte de toutes les observations. En effet, il comportait de trop nombreux paramètres empiriques et ne se souciait pas de certaines contraintes telles que la concurrence entre talles. Aussi, en 2006, une refonte du modèle initial a été réalisée en vue d’introduire notamment la notion de concurrence entre individu faisant de SisTAL un simulateur multi-agents. Ce nouveau logiciel fut par la même occasion renommé en SisFRT (SImulateur Spatialisé des Feuilles, des Racines et des Talles). La mise en concurrence des talles a nécessité d’inclure la morphogénèse des feuilles (pour la concurrence portant sur les ressources lumineuses), et la morphogénèse des racines (pour la concurrence des ressources d’azote).

2- Présentation générale

Le programme SisFRT a initialement été développé sous Visual Studio en C++/CLI. Le C++/CLI (Common Langage Infrastructure) est une extension du C++ développée par Microsoft. La compilation du code C++/CLI produit un bytecode appelé CIL (Common

Intermediate Language) qui est ensuite exécuté sur la machine virtuelle CLR (Common Language Runtime). Il possède deux piles distinctes : la première est celle du C++ natif, la

9 Figure 2 - La machine virtuelle CLR convertit le CIL en code machine

Du point de vue technique, le programme SisFRT est orienté objet. Ces différents objets constituent des briques logicielles. La simulation fait interagir ces objets entre eux afin d’étudier notamment la dynamique démographique et l’étalement des talles dans l’espace. Toutefois, le C++/CLI est un langage propriétaire. Utiliser les ressources d'une grille de calcul afin d'exécuter SisFRT pourrait donc s'avérer (dans la plupart des cas) impossible. Il serait donc de pouvoir s'affranchir de cette dépendance forte qu'il y a entre SisFRT et Visual Studio.

D- Objectif du projet

L'objectif du projet est donc double. Il vise tout d'abord à porter le modèle SisFRT en C++ standard. Ensuite une nouvelle interface graphique devra être mise en place sous Qt.

Au démarrage du projet, la liste de fonctionnalités à laquelle devait répondre le modèle porté a été établie avec nos tuteurs de projets. Un niveau de priorité a été associé à cette liste. Il y avait donc des fonctionnalités impératives à rajouter et d'autres dont la mise en place serait appréciée. Cette liste de fonctionnalités est représentée dans le tableau 1.

Fonctionnalité Niveau de priorité

Supprimer toutes les références à C++/CLI 4 Réaliser la nouvelle interface graphique 4

Lancer le programme en mode console 3

Ajouter une vérification de saisie 3

Internationalisation 2

Migrer d'Idrisi à NetCDF 2

Afficher les cartes NetCDF dans l'interface 1

Tableau 1 - Cahier de charges du projet par niveau de priorité décroissant

Les droits à un dépôt SVN contenant le modèle initial nous ont également été accordés.

E- Planning

Le projet a été réalisé sur la période de novembre 2013 à fin février 2014 (16 semaines). Le diagramme la figure 3 représente le temps que nous avons passé sur chaque tâche du programme.

10 Figure 3 - Diagramme de Gantt

11

II- Portage du modèle

L'objectif initial du projet étant de porter le modèle vers du C++ standard, c'est par cette tâche que nous nous avons commencé.

A- Mise en œuvre du portage

1- Documentation préliminaire

Nous avons donc répertorié les différences qui existaient entre le C++/CLI et le C++ standard à l'aide de [2].

De ces recherches, nous avons constaté qu'hormis les nouveaux types de données introduits par Microsoft, la principale différence entre ces langages réside dans l'existence ou non d'un garbage collector. En effet, dans Visual C++ (ainsi que dans tous les autres langages du Framework .NET), il existe des variables dites managées. La mémoire utilisée par ces variables a la particularité d'être libérée automatiquement lorsque celles-ci ne sont plus utilisées (ou référencées). Le nom de ces variables est précédé par le caractère ^. L'existence de ces variables managées a entraîné une deuxième différence : celle de la syntaxe de déclaration des classes. En effet, une classe MaClasse contenant un attribut managé, ne peut plus être déclarée avec uniquement class MaClasse mais plutôt avec public ref class MaClasse.

Enfin, la dernière grande différence était l'existence des mixed assemblies (assemblement mixé) spécifiques aux langages du Framework .NET. En effet, ils constituent une fonctionnalité puissante de ce langage. Ils permettent de regrouper dans un même assemblement (assembly) du code C++ non managé (natif ; exécuté directement sur le processeur) et du code managé (exécuté sur la machine virtuelle).

2- Restructuration du dépôt svn

Un premier lancement du programme sans prise en compte du C++/CLI a montré une liste d'erreurs contenant 361 éléments. Il convient toutefois de préciser la répartition de ces erreurs. En effet, près de ¾ de celles-ci figuraient dans la partie graphique de SisFRT. Le modèle en lui-même était très peu dépendant du C++/CLI, ce qui a facilité d'autant plus la mise en place d'un mode console (voir partie suivante). Ainsi porter le modèle et réaliser une nouvelle interface graphique revenait (presque) à la même chose.

Au vu de cela, nous avons décidé qu'il valait mieux avancer simultanément sur ces deux objectifs (portage du modèle et nouvelle interface) et nous avons donc restructuré le dépôt SVN. Il a d’abord fallu créer une branche pour y placer le projet porté. Initialement le dépôt svn ne possédait pas la structure classique trunk/branches/tags. Nous l’avons donc créée. Le code du projet Sisfrt datant de fin août 2013 a naturellement été placé dans le trunk. Nous avons ensuite créé deux nouvelles branches :

- cli2std contenant le projet Visual Studio au sein duquel le C++/CLI a été converti

en C++ standard ;

12

B- Mode console & tests de non régression

Dans le code initial de SisFRT, une batterie de tests unitaires a été mise en place. Nous l'avons donc tout naturellement réutilisée pour nous assurer que le portage n'introduisait pas de nouveaux bugs.

Cependant, étant donné que la nouvelle interface graphique était en construction, nous avions deux options pour pouvoir les lancer :

- utiliser l'interface graphique développée en C++/CLI ;

- terminer le portage (modèle + interface) puis valider les tests.

Nous avons jugé que la première option était risquée car certains mécanismes mis en place par le CLR pourraient masquer des erreurs qui apparaîtraient en temps normal. Par exemple, une variable entière déclarée dans un environnement utilisant une machine virtuelle sera automatiquement initialisée à 0 (sauf initialisation explicite par le développeur). Dans un environnement sans machine virtuelle, cette variable aura une valeur arbitraire, ce qui pourrait provoquer l'obtention de résultats incompréhensibles.

La deuxième option, quand à elle, nous ferait découvrir (éventuellement) l'introduction de bugs trop tard.

C'est ainsi que la mise en place du mode console (figurant dans les objectifs du projet) en même temps que le portage de la partie modèle de SisFRT nous est apparue comme la solution idoine. Cela nous permettrait non seulement de résoudre notre problème de validation de tests, mais aussi d'identifier les points d'ancrage qui seront utilisés plus tard pour connecter notre nouvelle interface graphique à SisFRT.

1- Mise en place du mode console

Elle s'est réalisée aisément en se basant sur l'architecture existante.

Etant donné que certains traitements dépendaient du mode de lancement de l'application, une variable globale GRAPHICAL_MODE_ENABLED a été introduite. Elle vaut true quand le mode d'exécution est graphique et false sinon.

On peut également spécifier le fichier de paramètres directement en ligne de commande. Pour cela, on doit faire usage du flag -p. Le fichier de paramètres doit obligatoirement suivre ce flag. Si ce fichier n'est pas spécifié, l'utilisateur devra le rentrer explicitement au clavier. De plus, lors de l'exécution de SisFRT, certaines sorties consoles sont réalisées. Il est désormais possible de contrôler leur flux via l'option –v qui, lorsqu'elle est absente, indique que ces sorties ne doivent plus s'effectuer.

Il est à noter que l'option –p est également présente en mode graphique.

2- Validation des tests unitaires

Les tests unitaires précédemment mentionnés ont été exécutés avec succès à l'issue du portage du modèle. Cela permet de s'assurer que la traduction du C++/CLI en C++ standard n'a pas entraîné de nouveaux bugs.

13 De plus, nous avons aussi voulu nous assurer que les sorties du programme en mode console étaient identiques à celle du mode graphique (du projet SisFRT initial). Pour ce faire, il a fallu comparer les hash des fichiers générés par les deux types de simulation. Cette comparaison a pu se faire directement à l'intérieur du répertoire SVN contenant les fichiers de résultats. En effet, les CVS utilisent les hash des fichiers pour s'assurer que les fichiers n'ont pas subi de modification après le dernier commit. Ainsi, une icône verte devant les fichiers de résultats après l'exécution de la simulation avec le fichier de paramètres précédemment utilisé, permettrait de s'assurer que les nouveaux résultats sont identiques aux précédents.

Cependant, des erreurs ont été rencontrées. En effet, en comparant les fichiers de sorties, on s'est rendu compte que certaines valeurs n'étaient pas égales (la comparaison a été faite avec la commande UNIX diff) sans être non plus extrêmement éloignées. Ainsi on peut trouver par exemple dans le fichier de résultats de l’exécution en mode graphique la valeur

1.49752 tandis que dans le fichier de résultats en mode console on trouve (à la même ligne)

la valeur 1.49745.

Il faut cependant noter que le fichier des statistiques (situé dans Resultats/stats/ ) reste pour sa part identique avec les deux modes d’exécution. Seul le fichier journal (se trouvant dans Resultats/journal/) présente les anomalies énumérées plus haut.

N’arrivant pas à comprendre la nature du problème, nous avons comparé des fichiers de sorties entre deux exécutions avec le même mode et le même fichier de paramètre. Et même dans ce cas, l’issue restait la même : les fichiers résultats étaient différents.

Puis, nous nous sommes rendu compte que les germes des fichiers de simulations n’étaient pas les seuls présents dans le programme. Il y avait une autre fonction std::rand()3 dans le fichier ModeleSisfrt.cpp. En initialisant donc le germe utilisé par cette fonction avec une même valeur, on constate maintenant que les fichiers de résultats sont identiques.

C- Améliorations apportées au modèle

1- Générateurs pseudo-aléatoires

Lors de la validation des tests unitaires, nous nous sommes rendus compte de l'utilisation de la fonction std::rand() pour la génération de certains nombres pseudo-aléatoires. Deux considérations nous ont cependant poussés à remplacer cette dernière.

La première est que ce générateur était initialisé avec srand(time(0)). Cela pose des problèmes de reproductibilité de la simulation. En effet, la fonction time(0) renvoie le temps écoulé depuis le 1er Janvier 1970. Ainsi d'une exécution à l'autre, ce générateur était initialisé avec un germe, différent certes, mais impossible à reproduire.

La deuxième considération était l'utilisation d'un deuxième générateur pseudo-aléatoire dans SisFRT : le Mersenne Twister. En effet, il est courant et recommandé de n'avoir qu'une seule instance de générateur pseudo-aléatoire dans une simulation.

3

14 Etant donné qu'il était possible de paramétrer le germe (appelé plutôt, pour ce type de générateur, le statut) du Mersenne Twister, nous avons donc décidé d'utiliser ce dernier comme générateur de la simulation et avons substitué toutes les fonctions std::rand() par genrand_int32(). Cela nous a permis de résoudre les deux problèmes mentionnés plus haut. De plus, ce générateur présente de meilleures propriétés statistiques que le rand [3].

2- Migration d'idrisi à netCDF

Dans la version initiale de SisFRT, des cartes de sorties étaient produites au format idrisi afin d'avoir un état des principales variables de la simulation.

Cependant, l'utilisation de ce format présente certains inconvénients :  Il nécessite l'usage d'un logiciel spécifique (payant) pour le lire ;  Il est peu utilisé dans le domaine scientifique.

Etant donné que le format netCDF comble tous les inconvénients susmentionnés, c'est vers lui que nous avons naturellement migré.

a. Présentation de netCDF

NetCDF permet de stocker des données scientifiques comme des ensembles de tableaux connexes [4]. Il est basé sur trois concepts principaux :

 Les variables qui sont des tableaux à N-dimension contenant les quantités physiques mesurées (azote, matière organique, etc.) ;

 Les dimensions qui représentent les axes des variables (x, y, temps) ;

 Les attributs qui représentent les informations supplémentaires associées aux variables (unité).

La combinaison de ces concepts permet de créer un fichier netCDF auto-descriptif.

Le contenu d'un fichier netCDF est encodé en binaire, ce qui rend plus rapide sa lecture. Il est cependant possible d'exporter ce contenu au format texte en utilisant les utilitaires ncdump ou ncgen fournis avec la bibliothèque. Sur la figure 2 est illustré un extrait du contenu, au format texte, d'un fichier netCDF.

b. Modifications apportées à SisFRT

En dehors des détails d'implémentation, qui ne seront pas présentés ici, il était nécessaire de modifier la structure des fichiers de paramètres car ceux-ci étaient adaptés pour idrisi. La figure 3 présente ces modifications. Seules les balises sont représentées.

Dans cette figure, on peut voir que la balise idrisi se transforme en netcdf. Ensuite, vu que la simulation ne produit désormais qu'un seul fichier de sortie, configurer un répertoire devient superflu ; d'où la substitution de la balise rep par fichier.

15 Figure 4 - Exemple fichier netCDF

Figure 5 - Modifications des fichiers de paramètres

Les balises masque et format ont quand à elles été supprimées. En effet, la première n'était en réalité pas utilisée dans le modèle initial. La deuxième, quand à elle, permettait de configurer le type de fichier produit (texte ou binaire). Dans le cas de NetCDF, le fichier produit est obligatoirement au format binaire. Il n'y avait donc aucune nécessité de garder cette balise.

c. Problème rencontré

Lors de la migration, nous avons été confrontés à un problème de bibliothèque netCDF. En effet, nous nous sommes initialement tournés vers les bibliothèques pour le langage C++. Cependant, nous ne sommes pas parvenus à en faire fonctionner une pour l'environnement Windows.

C'est alors que nous avons regardé du côté des bibliothèques pour le langage C. Après plusieurs essais, nous avons finalement identifié la version 3.5.1 qui était fonctionnelle sous Windows. C'est donc elle que nous avons utilisée pour l'implémentation.

16

III- La nouvelle interface graphique

A- Construction de la nouvelle interface

1- Constat et besoins utilisateur

Avant de concevoir la nouvelle interface graphique, nous avons voulu savoir si une réorganisation des champs au sein des onglets serait pertinente. Après réflexion, nous en avons conclu que le regroupement thématique des champs dans les onglets était suffisant. Par conséquent nous avons décidé de conserver la même répartition des champs de saisie dans les onglets. Et comme ces onglets étaient déjà présents dans l'ancienne interface graphique, nous ne ferons que parler des nouveaux onglets/fonctionnalités que nous avons apportés.

2- Mise en œuvre

a. Qt Designer

Écrire le code d'une interface graphique est un travail long et répétitif. L'outil Qt Designer a été conçu pour rendre la tache plus simple et surtout plus rapide. Il permet de concevoir une interface graphique en plaçant des widgets prédéfinis (QPushButton ...) selon la technique du WYSIWYG (what-you-see-is-what-you-get). C'est cet outil que nous avons utilisé pour concevoir la nouvelle interface graphique.

b. Structure globale de la fenêtre

La fenêtre est désormais composée d'une barre d'outils (QToolBar) et d'un conteneur d'onglets (QTabWidget) :

17

c. La barre d'outils

De nouvelles fonctionnalités ont été introduites dans la barre d'outils de la nouvelle interface graphique :

Figure 7 : Aperçu de la barre d'outils de la nouvelle interface graphique

Cette barre est désormais composée de 8 éléments permettant, de gauche à droite, d'effectuer les actions suivantes :

- ouvrir un fichier de simulation ; - enregistrer un fichier de simulation ;

- "enregistrer sous" un fichier de simulation ; - effacer tous les champs ;

- lancer la simulation ; - ouvrir une bulle d'aide ;

- liste déroulante affichant la liste des erreurs de saisies éventuelles ; - changer la langue.

L'avantage de la barre d'outils est qu'elle est accessible depuis n'importe quel onglet. On peut donc par exemple enregistrer le fichier de simulation de n'importe quel onglet.

d. Le fichier de ressources

Toutes les icônes et images utilisées dans la nouvelle interface graphique ont été regroupées dans un même fichier de ressources dénommé SisfrtRessourceQt.qrc, dont voici le contenu :

18

B- Amélioration de l'existant

1- Redimensionnement

Dans l'ancienne interface graphique le redimensionnement de la fenêtre n'était pas pris en compte car les widgets avaient un positionnement absolu. Le contenu de la fenêtre restait donc à la même position quelle que soit la taille de celle-ci.

Dans la nouvelle interface graphique nous avons au contraire opté pour un positionnement relatif utilisant le système de layouts. Ainsi l'affichage est plus souple et la position des

widgets s'adapte à la taille de la fenêtre.

2- Désactivation / Activation d'onglets

L'ancienne interface graphique ne désactivait pas les onglets lorsque la simulation était en cours d'exécution.

Ceci a été corrigé dans la nouvelle interface graphique.

C- Nouvelles fonctionnalités

1- Vérification de la saisie

a. Vérification faible : les infobulles des champs de saisie

i.

Constat

L'idée d'introduire une vérification des données saisies est rapidement apparue comme un besoin majeur de l'utilisateur tant le nombre de paramètres est grand.

La première réponse apportée à ce problème a été l'ajout d'infobulles affichant des informations complémentaires destinées à guider la saisie de l'utilisateur. Elles renseignent d'abord sur le type de la valeur à saisir (texte ou nombre) et dans le cas où il faut saisir un nombre, les valeurs min/max sont affichées ainsi que les éventuelles unités/valeurs par défaut de la variable.

ii.

Mise en œuvre

Les informations sur les valeurs acceptées par un champ sont regroupées dans un fichier XML. Ce fichier est nommé intervallesChamps.xml et doit se placer dans le working directory (répertoire de travail). Au sein du fichier la syntaxe est la suivante :

Cette ligne indique que le champ nommé gr_leRepartUnifNQte accepte une valeur numérique (pas de texte donc), que sa valeur minimale est 0 (une concentration est

19 obligatoirement positive ou nulle), qu'il n'y a pas de valeur maximale et que l'unité est le mg/cm².

Ces lignes sont insérées entre des balises <onglets> afin de regrouper entre eux les champs présents dans un même onglet :

iii.

Résultats

Les deux figures suivantes donnent un aperçu des infobulles :

Figure 9: Infobulle dans le cas d'un nombre

Figure 10 : Cas d'une saisie de type texte

Cette aide apportée à l'utilisateur n'est cependant pas suffisante car rien ne l'empêche de lancer la simulation alors même qu'il n'a pas respecté les valeurs min/max spécifiées dans l'infobulle. Un autre système devait être mis en place pour accompagner celui-ci.

b. Vérification forte : le contrôle automatique de saisie

i.

Constat

Un système de vérification forte vient compléter les infobulles des champs de saisie. En effet le simple fait d'afficher les valeurs min/max dans une infobulle n'était pas jugé suffisant car rien n'empêchait l'utilisateur de démarrer la simulation tout en ayant commis des erreurs de saisie.

20 Une vérification automatique des valeurs saisies par l'utilisateur était donc nécessaire. C'est la raison pour laquelle nous avons ajouté une liste déroulante dans la barre d'outils. Celle-ci a pour rôle de lister toutes les erreurs de saisie qui ont été détectées. Cette vérification se fait lorsque l'utilisateur clique sur le bouton de lancement de la simulation.

Les erreurs détectées doivent être de trois types : - champ laissé vide ;

- valeur trop petite (<min) ; - valeur trop grande (>max).

ii.

Mise en œuvre

Lors de la vérification de la saisie, tous les champs de saisie sont passés en revue afin de tester s'ils présentent l'une de ces trois erreurs. Quand une anomalie est identifiée, le message d'erreur est ajouté à la liste déroulante.

Pour faciliter le travail de l'utilisateur, un clic sur une entrée de la liste ouvre immédiatement l'onglet contenant le champ erroné. Le fond du champ est d'ailleurs coloré afin de le trouver rapidement dans l'onglet.

Le fichier de données utilisé pour connaître les valeurs min/max et le type des champs, est le même que celui utilisé pour la vérification faible (infobulles).

iii.

Résultats

Cliquer sur le bouton Lancer la simulation alors que des champs sont restés vides entraîne la levée d'erreurs de saisie. Celles-ci s'affichent dans la liste déroulante de la barre d'outils :

Figure 11 : 103 erreurs de saisie ont été détectées

Les trois types d'erreurs détectés par la vérification de saisie sont : - un champ laissé vide ;

- un champ contenant du texte au lieu d'un nombre ;

21 Figure 12 : Détail des erreurs de saisie. Certains champs ont une valeur erronée car inférieure au min,

d'autres contiennent du texte au lieu d'un nombre et certains ont tout simplement été laissés vides.

Afin de simplifier la correction l'utilisateur n'a qu'à cliquer sur un élément de la liste pour que le focus soit donné au champ concerné par l'erreur. Le champ est d'ailleurs coloré pour l'identifier plus rapidement :

Figure 13 : Dans cet exemple, l'utilisateur a cliqué sur l'erreur concernant le champ gr_leRepartUnifNQte. L'onglet Grille s'est alors ouvert laissant apparaître le champ en question avec un fond coloré. La valeur

saisie est négative, l'erreur est légitime car une concentration ne peut pas être négative.

2- Internationalisation

a. Enjeux

Dans la mesure où SisFRT fait partie d'un projet de recherche scientifique, il a vocation à être partagé avec la communauté scientifique. Il faut donc qu'il soit compréhensible par des utilisateurs ne partageant pas la même langue. L'internationalisation du programme était donc nécessaire.

b. Choix techniques

Qt fournit un outil d'internationalisation dénommé Qt Linguist. Il fait généralement intervenir deux acteurs : i) un développeur, ii) un traducteur. Le développeur écrit son code normalement, il doit simplement englober les chaînes de caractère à traduire avec la fonction tr(). Qt Linguist permet ensuite de parcourir le code source du programme afin d'extraire toutes les chaînes à traduire. Le traducteur n'a plus qu'à renseigner la traduction de chaque texte dans les langues voulues, générant ainsi un fichier .ts par langue. Ces fichiers sont alors compilés en .qm puis ils sont lus à l'exécution et les traductions remplacent les chaînes de caractères écrites par le développeur.

22 Cette solution est puissante. Toutefois dans notre réalité, le traducteur sera l'utilisateur final du logiciel. Or celui-ci n'a pas été formé à l'utilisation de l'outil Qt Linguist. Nous avons donc écrit un guide en annexe détaillant pas à pas les étapes de la traduction.

À noter que nous avions initialement développé une solution de traduction basée sur un fichier XML (voir en annexe B). Pour plus de cohérence, la structure de ce fichier était calquée sur la structure de l'interface : les champs étaient regroupés dans des balises <onglet> correspondant aux onglets de l'interface, et chaque champ avait une traduction en français et en anglais.

Cette solution était adaptée à la traduction des étiquettes des champs de l'interface. Mais finalement nous avons voulu traduire l'intégralité de l'interface (en incluant les messages d'erreur, les textes des infobulles etc). Il nous était possible d'ajouter leurs traductions dans le fichier XML précédent, mais nous ne l'avons pas fait car ce fichier serait devenu plus complexe à parcourir et à maintenir.

Par conséquent il semblait plus approprié de proposer une solution plus cohérente et plus puissante : Qt Linguist.

c.

Mise en œuvre

L'outil Qt Linguist permet de traduire les chaînes de caractère d'un programme. Comme cela a été expliqué précédemment, les chaînes à traduire doivent être encadrées par la fonction tr(). Cela permet à l'analyseur de savoir quelles chaînes il doit extraire :

Figure 14 - Schéma de fonctionnement de la traduction avec Qt Linguist4

4

23 Dans un premier temps toutes les chaînes à traduire ont donc été encadrées par la fonction tr() (messages d'erreurs etc).

Un fichier uiQt_en.ts a ensuite été généré avec la commande lupdate. Les chaînes de caractère de ce fichier ont ensuite été traduites avec l'outil Qt Linguist, puis ce fichier a été compilé pour obtenir un fichier .qm.

L'annexe A détail ce fonctionnement.

3- Gestion de l'affichage des cartes netCDF

a. Intérêt

Lorsqu'on conçoit une interface homme machine, l'objectif est d'offrir à l'utilisateur le plus grand confort d'utilisation possible. C'est la raison pour laquelle une fonctionnalité permettant l'affichage des résultats de la simulation a été ajoutée au sein même de l'interface graphique. Ainsi l'utilisateur n'est plus contraint d'utiliser un logiciel tiers à côté de SisFRT pour la visualisation des résultats, ce qui constitue un gain de temps substantiel et améliore au passage la convivialité du logiciel.

b. Solution retenue

Comme indiqué au paragraphe I-C-2 les cartes des résultats sont stockées au format netCDF. L'affichage de ces résultats nécessite donc de parcourir ces fichiers netCDF afin de récupérer les valeurs.

Les valeurs stockées dans ces cartes sont des concentrations d'azote, le nombre de talles par case etc. À un instant t fixé, les données occupent trois dimensions (2 dimensions spatiales, et une dimension supplémentaire pour la variable suivie). La représentation graphique la plus adaptée pour ce type de données est donc la heatmap, ou carte thermique.

Qt ne dispose d'aucun widget natif permettant d'afficher une heatmap. En revanche la bibliothèque Qwt (Qt Widgets for Technical Applications) propose un composant

QwtPlotSpectrogram permettant comme son nom l'indique d'afficher un spectrogramme.

Comme un spectrogramme permet d'afficher des données à trois dimensions, ce type de diagramme convient parfaitement pour afficher une heatmap.

c. Résultats

i.

Aperçu général de l'onglet NetCDF

Au démarrage du logiciel les fonctionnalités de l'onglet NetCDF sont désactivées tant que l'utilisateur n'a pas sélectionné un fichier netCDF. L'utilisateur peut sélectionner le fichier grâce au bouton "Ouvrir fichier NetCDF". Une fenêtre de sélection de fichier s'ouvre alors.

24 Figure 15 : aperçu général de l'onglet NetCDF avant sélection d'un fichier source

25 Figure 16 : Le fichier source a été chargé, la heatmap affiche les données du fichier.

ii.

Aperçu plus détaillé des fonctionnalités

Sous le bouton de sélection du fichier netCDF se trouve la liste des variables présentes dans le fichier en chargé. À titre de remarque, ces variables sont celles que l'on sélectionne dans l'onglet Sorties :

Figure 17 : Liste des variables contenues dans le fichier netCDF

Figure 18 : Pour générer le fichier netCDF utilisé ci-contre, nous avons lancé une simulation en cochant les options

suivantes dans l'onglet Sorties

26 Le choix a été laissé à l'utilisateur de choisir entre une échelle automatique ou manuelle. L'échelle peut aussi passer en mode logarithmique à condition que les valeurs à afficher soient toutes strictement positives. Dans le cas contraire, un message d'avertissement apparaît.

Figure 19 : Échelle en mode automatique/manuel

Figure 20 : Mode échelle logarithmique

Figure 21 : Message avertissant que des valeurs négatives ou nulles empêchent l'utilisation de l'échelle logarithmique.

27

C

ONCLUSION

SisFRT est un modèle stochastique, individu centré, simulant le développement des brins d’herbe (talles) dans les prairies. Il s’intéresse à la dynamique démographique des talles des différentes espèces, à leurs déplacements dans l’espace ainsi qu'à la morphogenèse de leurs principaux organes (feuilles, racines et rhizomes). Simuler un tel système est complexe et nécessite beaucoup de puissance de calcul. Et comme la plupart des supercalculateurs fonctionnent sous un système d'exploitation Unix, il fallait porter SisFRT du C++/CLI vers un langage portable, le QT/C++.

Au vu du cahier de charges établi au début du projet, on peut dire que l'objectif a été atteint. L'application est intégralement portable et il est maintenant possible de l'exécuter sous Windows, comme sur Unix. La nouvelle interface utilisateur est plus conviviale grâce aux nouvelles fonctionnalités. Il sera désormais plus facile pour les scientifiques d'exécuter leur application et d'avoir un retour rapide sur les résultats. L'application peut également être distribuée dans le monde entier dans la mesure où elle supporte plusieurs langues.

Ce projet à été l'occasion pour nous de découvrir de nouvelles fonctionnalités de Qt telles que Qt Linguist et la bibliothèque Qwt. Nous nous sommes également familiarisés avec le format de fichier NetCDF.

28 REFERENCES

[1] P.-A. Guénolé, Rétroingénierie et améliorations d'un modèle, Clermont-Ferrand, 2013. [2] «MSDN,» [En ligne]. Available: http://msdn.microsoft.com/fr-fr/library/b23b94s7.aspx.

[Accès le 21 Février 2014].

[3] H. David, Analyse par Objets et Modélisation par Simulation, France: Addison-Wesley, 1993.

[4] «Documentation NetCDF,» [En ligne]. Available:

http://www.unidata.ucar.edu/software/netcdf/docs/classic_model.html. [Accès le 21 Février 2014].

29

Annexe A – Guide pour la traduction de SisFRT avec Qt Linguist

Avant de poursuivre vers l'une des sections de ce guide, assurez-vous d'avoir Qt Linguist sur votre ordinateur.

Par défaut, celui-ci s'installe automatiquement avec Qt Creator et peut être trouvé dans les dossiers d'installation de ce dernier.

Si ce n'est pas le cas, il peut être téléchargé en stand-alone ici : http://qt-apps.org/content/show.php/Qt+Linguist+Download?content=89360.

1- Traduction d'un fichier existant

30 Cliquer sur File > Open pour choisir le fichier de traduction (*ts) contenant les chaînes de caractères traduisibles du programme. Ce fichier de traduction se trouve dans le dossier traductions du répertoire racine de SisFRT (celui contenant uiQt.pro).

En cliquant sur Ouvrir, la fenêtre suivante s'affiche :

Dans l'onglet Strings, vous pouvez spécifier la traduction (anglaise ici, car le fichier

uiQt_en.ts de traduction se termine par _en) d'une chaîne de caractères.

A noter la possibilité, via le menu Edit de rechercher une chaîne (Find), ou même de la traduire directement (Search and Translate).

31 Il faut veiller à valider les chaînes dont la traduction est terminée. Sans cela, leur traduction ne seront pas prise en compte par Qt. En effet, une icône de statut, modifiable par un clic, est présente devant toutes les chaînes. La liste complète de ces icônes ainsi que leur signification est détaillée ici : http://qt-project.org/doc/qt-5.0/qtlinguist/linguist-translators.html#strings-window. La figure ci-dessous en présente néanmoins les plus basiques:

Chaîne non traduite

Chaîne traduite non validée

Chaîne traduite et ne passant pas toutes les vérifications de

Qt Linguist (problème de ponctuation ici)

Chaîne validée

Dans le troisième cas mentionné dans le tableau ci-dessus (erreur de traduction), la fenêtre Warnings de Qt Linguist affiche l'erreur correspondante :

Le problème mentionné est que la chaîne traduite ne se termine pas par le même signe de ponctuation que la chaîne d'origine ('Type' au lieu de 'Type :').

Une fois les validations effectuées et les modifications sauvegardées, il faut exporter le fichier de traduction au format binaire afin que celui-ci puisse être utilisé par Qt.

Pour cela faire File > Release ou File > Release As.

Une attention particulière doit être portée sur le nom du fichier binaire crée ainsi qu'à l'endroit où il est enregistré, cela afin de pouvoir automatiser son chargement par SisFRT. Tout d'abord, son nom doit respecter la convention de nommage suivante :

32 Ensuite, il doit être enregistré dans le sous dossier traductions du répertoire de compilation de SisFRT (celui contenant le dossier debug), qui doit être créé au besoin. La contrainte de nom est automatiquement satisfaite avec File > Release si le nom du fichier de traduction chargé respecte déjà la convention susmentionnée. Cependant, le fichier binaire crée via cette commande est enregistré dans le même répertoire que celui du fichier de traduction, c’est-à-dire dans le sous dossier traductions du répertoire racine de SisFRT. Ainsi, si votre répertoire de compilation est le même que le répertoire racine de SisFRT, la commande File > Release suffit à satisfaire les deux contraintes. Dans le cas contraire, il faudra veiller à déplacer le fichier binaire dans le bon dossier.

Pour les utilisateurs exécutant l'application avec Qt Creator, le répertoire de compilation est configurable dans l'onglet Projets de ce dernier :

2- Ajout d'une nouvelle langue

En réalité, l'ajout d'une nouvelle langue ne doit pas se faire par un utilisateur (traducteur). C'est au rôle du développeur de générer des fichiers de langue pour l'application. Cependant, un utilisateur ayant quelques notions en informatique et sur Qt pourrait y arriver en suivant quelques instructions simples, d'où ce guide.

Pour rendre ce guide aussi simple que possible, on se basera sur un exemple concret. Il s'agira de traduire SisFRT en allemand.

1ère étape : Editez le fichier uiQt.pro pour rajouter le nom du fichier de traduction à générer. Comme on veut traduire en allemand, son nom devra être : uiQt_de.

Le nom du fichier a été préfixé par traductions/ pour que celui soit généré dans le dossier traductions du répertoire racine de SisFRT. Vous êtes libre de modifier cette valeur (à condition que le répertoire de destination existe) et d'enregistrer le fichier de traduction où bon vous semble.

2e étape: Générer le fichier de traduction .Pour cela, ouvrez l'invite de commande de Qt et rendez vous dans le répertoire racine de SisFRT (commande cd).

33 Tapez ensuite la commande lupdate uiQt.pro.

Si tout se passe bien, le fichier uiQt_de.ts se créé dans le répertoire spécifié dans uiQt.pro.

3e étape : Traduire le fichier avec Qt Linguist (voir première section du guide). Pour notre exemple, nous n'allons traduire que le titre de l'onglet Général.

34 Après avoir validé les traductions, exporté et enregistré le fichier binaire au bon endroit, un lancement de SisFRT (sans recompiler) donne l'affichage suivant :

On voit bien que German a été rajouté à la liste des langues disponibles (même s'il manque encore l'icône). Cela a été possible via le suffixe _de donné au nom du fichier binaire de traduction.

En cliquant donc sur German dans la liste déroulante, le nom de l'onglet Général se traduit comme souhaité :

On voit bien qu'en suivant les conventions établies et sans même recompiler SisFRT, il est possible de faire en sorte qu'il prenne en compte une nouvelle langue.

4e étape (question de présentation) : Ajoutez une icône pour la langue allemande. Pour cela, téléchargez une icône de drapeau allemand au format .gif, renommez la en drapeauDe (suffixe De car allemand) et enregistrez la dans le dossier uiQt/vue/img.

35 Pour conserver une homogénéité de taille avec les drapeaux déjà présents, l'image ajoutée doit avoir des dimensions de 17x11.

Il est cette fois-ci nécessaire de compiler SisFRT pour que la nouvelle image s'intègre à l'exécutable. Une fois cela fait, l'exécution de SisFRT montre l'ajout du drapeau :

36

Annexe B – Premier système de traduction (remplacé par Qt

Linguist)

Voici ci-dessous la partie que nous avions initialement rédigée concernant le premier système de traduction que nous avions mis en place (basé sur un fichier XML), mais que nous avons aujourd'hui remplacé par un système basé sur l'outil Qt Linguist.

Internationalisation

a. Enjeux

Dans la mesure où SisFRT fait partie d'un projet de recherche scientifique, il a vocation à être partagé avec la communauté scientifique. Il faut donc qu'il soit compréhensible par des utilisateurs ne partageant pas la même langue. L'internationalisation du programme était donc nécessaire.

b. Choix techniques

Qt fournit un outil d'internationalisation dénommé Qt Linguist. Il fait généralement intervenir deux acteurs : i) un développeur, ii) un traducteur. Le développeur écrit son code normalement, il doit simplement englober les chaînes de caractère à traduire avec la fonction tr(). Qt Linguist permet ensuite de parcourir le code source du programme afin d'extraire toutes les chaînes à traduire. Le traducteur n'a plus qu'à renseigner la traduction de chaque texte dans les langues voulues, générant ainsi un fichier .ts par langue. Ces fichiers sont alors compilés en .qm puis ils sont lus à l'exécution et les traductions remplacent les chaînes de caractères écrites par le développeur.

Cette solution est puissante. Toutefois dans notre réalité, le traducteur sera l'utilisateur final du logiciel. Or celui-ci n'a pas été formé à l'utilisation de l'outil Qt Linguist. Par conséquent il semblait plus approprié de proposer une solution plus simple : les fichiers XML.

Au lieu d'utiliser l'outil Qt Linguist ce sont donc des fichiers XML, regroupant les traductions en différentes langues, qui ont été retenus. En effet il devient très simple de modifier les traductions car il suffit d'éditer le fichier XML avec un éditeur de texte (type bloc-note).

c.

Mise en œuvre

Les traductions des différents textes de l'interface graphique sont donc regroupées dans un fichier XML. Il faut alors un moyen de faire la liaison entre le nom d'un widget devant afficher un texte traduisible, et la traduction de ce texte dans le fichier XML.

Pour ce faire les widgets ont tous été nommés par un identifiant unique. Cet identifiant unique suit la convention de nommage suivante :

37

NO_TCNomDuChamp[_label]

NO = un condensé en deux lettres du nom de l'onglet où se trouve le texte à traduire exemple : gn pour l'onglet général, gr pour l'onglet grille etc.

TC = un condensé en deux lettres du type du widget exemple : le pour QLineEdit, gb pour QGroupBox etc.

NomDuChamp = nom explicite décrivant précisément ce que contient le champ

exemple : mt_pbAjouterFichierTemperatures est particulièrement explicite.

On comprend rapidement qu'il s'agit d'un QPushButton de l'onglet météo et qu'il sert à ajouter un fichier de températures.

_label = suffixe facultatif apposé à un widget servant de label (une étiquette) décrivant un champ de saisie.

Cette convention de nommage se veut explicite afin de permettre d'identifier un chaque

widget facilement et sans ambigüité. Le simple fait de faire figurer le nom de l'onglet dans le

nom du widget réduit grandement les confusions possibles car un onglet contient relativement peu de widgets.

La structure du fichier XML est la suivante :

Figure 22 : Hiérarchie du fichier XML contenant les traductions. Les widgets sont regroupés par onglet par faciliter leur identification.

38 Figure 23 : Extrait du fichier XML regroupant les traductions