Etude et développement d'une interface graphique de conception ...

Institut Supérieur Institut de recherche d’Informatique de en sciences et Modélisation et de technologies pour

leurs Applications l'environnement Complexe des Cézeaux 24 Avenue des Landais BP 10125 BP 50085 63173 Aubière Cedex 63172 Aubière Cedex

Rapport de stage de 2ème année ISIMA Génie Logiciel et Systèmes Informatiques

Etude et développement d’une interface graphique de conception logicielle appliquée aux Réseaux de

Capteurs Sans Fil Présenté par : Sylvain Rebeyrol Responsable ISIMA : Jian Jin Li Responsables entreprise : Gil De Sousa et Aurélien Jacquot

Du 4 avril au 2 septembre 2011

Remerciements Je remercie le personnel du Cemagref, pour l'accueil qu'ils m’ont réservé tout au long de mon stage. L'ambiance était chaleureuse et conviviale. J’ai été très bien intégré au sein de cette équipe. Je tiens à remercier particulièrement Aurélien JACQUOT et Gil DE SOUSA pour m'avoir aidé dans de nombreuses circonstances. Ils m'ont permis d'avancer sur mon travail lorsque j'ai rencontré des difficultés. Ils m'ont soutenu et leur aide et leur expérience m’ont été précieuses.

Glossaire ARM : Société britannique spécialisée dans le développement de processeur. AWT : Abstract Window Toolkit est une bibliothèque graphique pour JAVA, et

sert de fondement à Swing. Eclipse : Environnement de développement libre codé principalement en JAVA

par la Fondation Eclipse. Framework : Ensemble de composants logiciels structurels, permettant de créer la

base ainsi que les grandes lignes d’un logiciel. I²C : Inter Integrated Circuit Bus, développé par Philips. Ce bus de

communication nécessite deux fils. ISIMA : Institut Supérieur de l'Informatique de Modélisation et de leurs

Applications. JFace : JFace est une bibliothèque graphique pour JAVA, s’appuyant sur SWT

pour fournir des interfaces plus structurées. Langage C : Langage de programmation impératif, de bas niveau inventé en 1970. Langage JAVA : Langage de programmation orienté objet, inventé en 1995. LIMOS : Laboratoire d'Informatique, de Modélisation et d'Optimisation des

Systèmes est une unité mixte de recherche. Il est rattaché aux deux universités clermontoises.

Package : Paquetage. Désigne un ensemble de classe. PIC : Famille de microcontrôleurs de la société Microchip. RCP : Rich Client Platfom est une application riche conçue à l’aide d’un

noyau exécutif et de briques logicielles, ainsi que d’un framework et un modèle d’interface utilisateur.

RSCF : Réseau de Capteur Sans Fil Swing : Bibliothèque graphique pour JAVA, basé sur AWT. Elle utilise des

composants en pur Java. SWT : Standard Widget Toolkit est une bibliothèque graphique libre pour

JAVA, initiée par IBM. Elle fait appel aux composants natifs du système d’exploitation.

Template : Permet à une classe ou une fonction de pouvoir s’adapter à plusieurs

types sans avoir besoin d'être redéfinie.

TSCF : Technologies et Systèmes d'information pour les agrosystèmes de Clermont Ferrand.

UML : Unified Modeling Language est un langage de modélisation graphique à base de pictogrammes.

Wi-Fi : IEEE 802.11, protocole de communication sans fil. Il permet de relier

plusieurs appareils informatiques, les informations étant transmises par des ondes.

XML : Extensible Markup Language est un langage informatique de balisage

générique. ZigBee : IEEE 802.15.4, protocole de communication à consommation d'énergie

réduite.

Résumé Les évolutions technologiques des dernières années ont permis de mettre en évidence un nouveau domaine de recherche : les réseaux de capteurs sans fil (RCSF). Ils sont utilisés par le Cemagref pour répondre à différents types d’applications dans le domaine agricole et environnemental. Mon travail a consisté à développer une interface graphique de programmation permettant de faciliter la création de nouvelles applications pour les nœuds de ces réseaux. Cette interface doit permettre de générer le code de l’application à partir des paramètres fournis par l’utilisateur et des briques logicielles. J’ai développé cette interface sous Eclipse à l’aide du langage JAVA et du framework d’Eclipse, permettant de réaliser un RCP. Aujourd’hui, l’interface est fonctionnelle et permet de générer du code. Il est également possible de sauvegarder et de réutiliser certaines parties du code d'applications déjà existantes. Des corrections et améliorations pourront être apportées pour une meilleure utilisation de l’interface. Des fonctions pourront également être ajoutées pour que l’interface soit plus complète. Mots clés : réseau de capteurs sans fil, agriculture, environnement, interface graphique, génération de code, langage JAVA, RCP.

Abstract Technological developments in recent years have highlighted a new research area: wireless sensors networks (WSN). WSN are used by Cemagref to respond to different kinds of challenges in agriculture and the environment field. . The objective of my work was to develop a programming graphical user interface (GUI) to make easier the design of new applications for the WSN nodes. This interface allows the application code generation from user-supplied parameters and software components. I developed this interface in JAVA language and with the Eclipse framework, to achieve an RCP application. Today, the interface is functional and can generate code. It's also possible to save and reuse parts of existing application code. Corrections and upgrades can be made for a better use of the interface. Functions can also be added for completed the interface. Key words: wireless sensors network, agriculture, environment, graphical user interface, code generation, JAVA language, RCP.

Tables des matières Introduction ................................................................................................................................ 1 I. Présentation du stage............................................................................................................... 2

I.1. Présentation du Cemagref ................................................................................................ 2 I.1.1. Présentation de l’unité de recherche TSCF ........................................................ 2 I.1.2. Présentation de l’équipe COPAIN...................................................................... 3

I.2. Contexte de l’étude .......................................................................................................... 3 I.3. Objectifs du stage et planning.......................................................................................... 5 I.4. Planning du stage ............................................................................................................. 5

II. Etude et recherche d’outils .................................................................................................... 6

II.1. Etude............................................................................................................................... 6 II.1.1. Architecture d’une plateforme de RCSF ............................................................ 6 II.1.2. Fonctionnalités attendus de l'interface................................................................ 7 II.1.3. Etude le l’existant ............................................................................................... 7

II.2. Outils informatiques utilisés......................................................................................... 10 II.2.1. Choix du langage de programmation................................................................ 10 II.2.2. Choix d’un outil de modélisation ..................................................................... 10 II.2.3. Choix de la bibliothèque graphique.................................................................. 12 II.2.4. Utilisation d’un RCP......................................................................................... 14

III. Modélisation de l’interface................................................................................................. 17

III.1. Déroulement de son utilisation.................................................................................... 17 III.2. Diagrammes de classes de l’application...................................................................... 18 III.3. Découpage en vues...................................................................................................... 21

IV. Développement de l’application ........................................................................................ 23

IV.1. Cœur de l’application.................................................................................................. 23 IV.1.1. Données et ressources....................................................................................... 23 IV.1.2. Génération de code ........................................................................................... 25

IV.2. Interface....................................................................................................................... 26 IV.2.1. Création d’une interface avec Eclipse RCP...................................................... 26 IV.2.2. Principales parties de l’interface....................................................................... 28

IV.2.2.a. Explorateur .............................................................................................. 29 IV.2.2.b. Listes des ressources ............................................................................... 29 IV.2.2.c. Vue pour le paramétrage ......................................................................... 29 IV.2.2.d. Editeur graphique .................................................................................... 30

IV.2.3. Exporter le RCP................................................................................................ 31 V. Première utilisation de l’application.................................................................................... 32

V.1. Test de l’interface......................................................................................................... 32 V.2. Réalisation d’un nœud.................................................................................................. 32 V.3. Compilation et test du code généré .............................................................................. 35

Conclusion................................................................................................................................ 36

Table des figures Figure 1. Présentation des centres du Cemagref en France........................................................ 2 Figure 2. Schéma d'un RCSF ..................................................................................................... 4 Figure 3. Schéma d'une plateforme de RCSF ............................................................................ 6 Figure 4. Photo d’une carte mère avec une carte fille Watermark ............................................. 7 Figure 5. Diagrammes des différentes étapes du prototype ....................................................... 8 Figure 6. Fenêtre de configuration de capteur du prototype ...................................................... 9 Figure 7. Vue généraliste d’ArgoUML.................................................................................... 10 Figure 8. Vue généraliste d’ArgoUML.................................................................................... 12 Figure 9. Exemple d’interface développé avec Eclipse RCP................................................... 15 Figure 10. Diagramme de cas d'utilisation de l'application...................................................... 17 Figure 11. Diagramme d’activité de l'application .................................................................... 18 Figure 12. Version simplifiée du diagramme de classes du package « data »......................... 19 Figure 13. Version simplifiée du diagramme de classes du package « io »............................. 19 Figure 14. Version simplifiée du diagramme de classes du package « ui »............................. 20 Figure 15. Vue externe du nœud .............................................................................................. 21 Figure 16. Vue interne du nœud............................................................................................... 22 Figure 17. Vue interne de la carte fille..................................................................................... 22 Figure 18. Exemple du code générer........................................................................................ 25 Figure 19. Onglet d'extension du plugin .................................................................................. 27 Figure 20. Vision globale de l'interface ................................................................................... 28 Figure 21. Création du projet Test ........................................................................................... 33 Figure 22. Création du profil Carte Watermark ....................................................................... 34 Figure 23. Configuration de la carte fille ................................................................................. 34

Table des tableaux Tableau 1. Comparatif entre Papyrus et ArgoUML................................................................. 11 Tableau 2. Comparatif entre Swing et JFace............................................................................ 13 Tableau 3. Formatage d'un fichier de carte fille....................................................................... 23 Tableau 4. Exemple de formatage d'un fichier de projet.......................................................... 24

Etude et développement d’une interface graphique de conception logicielle appliquée aux Réseaux de Capteurs Sans Fil

Rebeyrol Sylvain 22 août 2011 1

Introduction Au cours de ma deuxième année d'étude à l'Institut Supérieur d'Informatique, de Modélisation et de leurs Applications (ISIMA), j'ai effectué un stage au sein de l'institut de recherche en sciences et technologies pour l'environnement, nommé Cemagref. Ce stage a duré cinq mois entre avril et septembre 2011. Dans le cadre des applications de collecte de données environnementales à distance, l'équipe Copain s'appuie sur la technologie des Réseaux de Capteurs Sans Fil (RCSF). Celle-ci déploie une multitude de systèmes électroniques (nœuds), embarquant une intelligence, une mémoire, ainsi qu'un moyen de communication sans fil sur des zones vastes (parcelles agricoles, vignes...). Différentes versions d'une plateforme de RCSF, nommée LiveNode, ont été développées, en collaboration avec le laboratoire d'informatique LIMOS. Actuellement, le capteur sans fil LiveNode est basé sur une architecture matérielle modulaire. Cependant, il est difficile de se servir des différentes briques logicielles de ces plateformes. De plus, on constate que, dans la majorité des cas, des codes communs peuvent être réutilisés d’une application à l’autre. Il est donc important de centraliser les différentes briques logicielles, pour faciliter leur développement. Pour le moment, un utilisateur novice aura de grandes difficultés pour reprendre et concevoir une application, car il devra comprendre et modifier lui-même l’intérieur du code. Il est donc nécessaire de développer un outil graphique permettant de l’aider dans son travail. Je présenterai dans une première partie le contexte du stage. Une seconde partie détaillera l’étude d’un prototype d’interface effectuée, ainsi que le choix des outils qui seront utilisés durant le stage. Ensuite, dans une troisième partie, je propose une modélisation de l’application à travers différents diagrammes UML, ainsi que la schématisation d’un nœud. La quatrième partie expliquera le développement de l’application. Enfin, la cinquième et dernière partie présentera le fonctionnement de l’application et les tests effectués.



I. PRESENTATION DU STAGE

I.1. Présentation du Cemagref

J'ai effectué mon stage au sein du Cemagref, qui est un établissement public à caractère scientifique et technologique (EPST). Le Cemagref possède 9 centres sur la France et 2 antennes, une en Martinique et une à Strasbourg illustré dans la Figure 1.

Figure 1. Présentation des centres du Cemagref en France.

Le Cemagref possède 20 unités de recherche et 5 unités mixtes de recherche, autour de 3 départements de recherche que sont les eaux, les écotechnologies et les territoires. Il y a 1600 personnes qui travaillent au Cemagref réparties dans tous ces centres, dont environ 500 chercheurs et 200 doctorants. J'ai rejoint à l'unité de recherche Technologies et Système d'information pour les agrosystèmes de Clermont-Ferrand. (UR TSCF)

I.1.1. Présentation de l’unité de recherche TSCF L'unité de recherche TSCF appartient au centre de Clermont-Ferrand (63), qui a la particularité d’être sur deux sites :

- Site d’Aubière, département du Puy-de-Dôme. - Site de Montoldre, département de l’Allier

Ce dernier site dispose d'une ferme expérimentale. Régulièrement, les agents sont amenés à effectuer des essais ou des relevés sur ce site, afin de mieux tester leurs solutions et appareils en milieu agricole. L'unité de recherche TSCF est composée de trois équipes de recherche, qui sont réparties sur les deux sites :

- L'équipe TEAM, Technologie Epandage Agroéquipements Mobilité, a pour but d'améliorer les techniques d'épandage pour un meilleur résultat sans détériorer



l'environnement, et d'apporter des solutions pour améliorer les travaux des exploitants par l'intermédiaire de robots mobiles autonomes coopératifs.

- L'équipe CARAC'TERRE s'occupe de la caractérisation des matériaux et des différents milieux dans le domaine agricole.

- La troisième équipe, que j'ai rejointe, est l'équipe COPAIN, présentée plus en détails ci-dessous

I.1.2. Présentation de l’équipe COPAIN

L'équipe travaille sur les Systèmes d'Information Agro-environnementaux et Communicants, et est chargée de concevoir et réaliser des systèmes d'information dédiés à la gestion de données agro-environnementales. Ces systèmes sont alimentés par des données environnementales collectées, et permettent de qualifier et d'avoir une meilleure compréhension de l'environnement et des pratiques agricoles. De plus, les échanges de données entre différents systèmes d’information sont également étudiés afin d’exploiter au mieux les informations recueillies. La démarche de la réalisation commence par l'analyse des besoins de l'utilisateur, la spécification des systèmes d'information, la modélisation et la conception d'une solution et enfin la gestion des sources de données. L'équipe est composée de 12 personnes permanentes au sein du Cemagref, une personne post-doctorante et deux personnes doctorantes. L'équipe développe trois thématiques de recherche :

- Les réseaux de capteurs sans fil (RSCFs). - Les entrepôts de données - Les systèmes d'information géographique (SIGs).

Mon stage s'intègre dans la thématique des RCSFs. Mon maître de stage, Gil DE SOUSA, travaillent au sein de cette équipe ainsi que mon encadrant Aurélien JACQUOT.

I.2. Contexte de l’étude

Un RCSF est composé de deux grands types de nœuds : les capteurs sans fil et le point (ou station) de collecte. Les capteurs sans fil relèvent des données grâce à des capteurs de grandeur physique (thermomètre, pluviomètre...), et envoient ces informations vers le point de collecte, également appelé puits. Le puits récupère les informations remontées par les différents capteurs sans fil et les transmet au centre de traitement. Il n'est pas rare qu'un capteur sans fil soit hors de portée du puits, les informations vont alors transiter de nœud en nœud jusqu'à atteindre un point de collecte (Figure 2). Les nœuds d’un RCSF sont des systèmes embarqués à fortes contraintes de ressources, notamment en termes d’énergie, de puissance de calcul et de mémoire. Les nœuds peuvent être dans des endroits difficiles d'accès, et on considère qu'ils sont autonomes une fois qu'ils sont déployés. L'autonomie de leur batterie est donc primordiale et c’est pour cela qu’ils doivent consommer le moins possible, tout en ayant une puissance de calcul et une mémoire suffisante. Le protocole de communication sans fil utilisé est également très important. Par exemple, le Wi-Fi (IEEE 802.11) offre un débit élevé au détriment d'une consommation d'énergie importante. D'autres protocoles comme le ZigBee (IEEE 802.15.4) ont, à l'inverse, un débit limité pour une consommation assez faible. Le choix du protocole de communication dépend des contraintes de l'application supportée.



Les domaines d’applications des RCSF sont vastes, allant notamment de la collecte de données environnementales à la surveillance d’infrastructures en passant par l’aide à la personne.

Figure 2. Schéma d'un RCSF

Il existe trois manières de collecter les informations d'un RCSF : soit à la demande, soit sur événement, soit automatiquement. Dans le premier cas, lorsque l'on souhaite avoir l'état de la zone de couverture à un instant T, le puits va émettre un signal vers toute la zone de couverture pour que les capteurs remontent leurs informations. Dans le deuxième cas, lorsqu'un événement se produit en un point, les capteurs sans fil situés à proximité vont alors remonter les informations vers le puits. Cela permet de repérer quand le niveau d'eau monte trop ou encore quand le sol est trop sec et qu'il y a un risque d'incendie. Dans le cas d'une collecte automatique, les nœuds vont remonter automatiquement et périodiquement leur dernier relevé vers le puits. Cela permet d'étudier l'évolution de la zone de couverture dans le temps, en constituant une base de données. Les RCSFs peuvent, par exemple, permettre de contrôler à distance l'irrigation d'une vigne. Les différents nœuds sont disséminés dans toute la vigne pour avoir un relevé détaillé de l’état hydrique du sol. En complément, différentes données météorologiques peuvent être mesurées, puis traiter, afin d'indiquer la nécessité d'irriguer en fonction de l'humidité du sol. Le RCSF peut aussi permettre de comparer les relevés des différentes périodes de l'année sur plusieurs années, puisqu'une base de données stocke les informations utiles de ces relevés. Avec ceux-ci, l'utilisateur peut analyser la qualité du sol de son exploitation grâce à un outil d'aide à la décision. L'outil fournit des conseils à l'utilisateur à partir des données recueillies et des modèles de culture et de traitements. Le sol n'absorbant pas l'eau uniformément sur toute une exploitation, cette dernière est alors découpée en parcelles modélisées dans l'outil afin de fournir un rapport sur l'état du sol. Ainsi, l'utilisateur peut irriguer uniquement les parcelles qui en ont besoin et économiser de l'eau sur les autres. Pour fonctionner, les nœuds disposent de batteries qui doivent leur permettre



d'avoir une autonomie de plusieurs mois sans intervention. Les énergies renouvelables comme le solaire peuvent aider à améliorer la durée de vie de chaque nœud du réseau.

I.3. Objectifs du stage et planning

L’objectif du stage consiste à proposer une interface graphique de programmation, permettant de faciliter la création de nouvelles applications sur les microcontrôleurs ARM et PIC des plateformes de RCSF. Je dois, dans un premier temps, me familiariser avec la programmation sur ces architectures et prendre connaissance des applications existantes. Dans un deuxième temps, j’étudierai le prototype existant et réaliserai une modélisation UML de l’interface. Dans un troisième temps je devrai développer l’interface. L’interface devra permettre une conception visuelle de l’application ainsi que son paramétrage, à l’aide de briques graphiques représentant les différents périphériques et fonctionnalités. Il faudra également à tout instant pouvoir ajouter ou corriger des fonctionnalités à des briques nouvelles ou existantes. Elle utilisera des bibliothèques de codes réutilisables d’applications embarquées, écrites en langage C. A partir de la représentation visuelle et de ces bibliothèques, le logiciel pourra générer un code source paramétré pour une application embarquée donnée. Ensuite, ces codes seront compilés par un logiciel tiers. A terme, il est envisagé d'intégrer des outils de compilation libres à l'interface de programmation, pour en faire un outil complet de développement et d'envoi sur cible. Enfin, les applications générées devront être validées sur la plateforme matérielle développée.

I.4. Planning du stage

Mon stage a commencé le 4 avril 2011. Durant le mois d'avril, j’ai étudié le fonctionnement des RCSFs ainsi que l'architecture des nœuds utilisés par le Cemagref. J’ai également étudié le prototype d'interface qui a été réalisé en amont de mon stage. Lors du mois de mai, j'ai cherché des outils pour la modélisation et la conception de l'application que j'utiliserai pendant le stage. Pour la fin du mois de mai, j'ai préparé une présentation faisant le point sur mon stage. Pendant le mois de juin, j'ai modélisé l'application. Pour cela, différents diagrammes UML ont été réalisés. Un diagramme de cas d'utilisation et un diagramme d’activité ont été établis pour voir les différentes étapes qu'un utilisateur ferait, s'il voulait créer un nœud, ainsi que leur ordre. Des diagrammes de classes de l'application ont également été réalisés. La base du code de l'application a ensuite été générée à partir de ces diagrammes. Lors des mois de juillet et d'août, j'ai développé l'application, en concevant l'interface et la génération du code. Enfin au mois d'août, j'ai rédigé mon rapport. J'ai également effectué des tests et débogué l'application. Malheureusement, je n'ai pas eu le temps de tester le code sur la plateforme physique.



II. ETUDE ET RECHERCHE D’OUTILS

II.1. Etude

II.1.1. Architecture d’une plateforme de RCSF Différentes versions de la plateforme de RCSF, nommée LiveNode, ont été développées en collaboration avec le laboratoire d'informatique LIMOS. Actuellement, le capteur sans fil LiveNode est basé sur une architecture matérielle modulaire : une carte mère et des cartes filles. Ces cartes sont empilables, c’est-à-dire que l’on peut brancher une carte fille sur une carte mère, sur laquelle on pourra brancher une nouvelle carte fille (Figure 3 et Figure 4).

Figure 3. Schéma d'une plateforme de RCSF

Cette structure offre une réutilisabilité des éléments d’une plateforme à une autre, et permet également de ne pas être limité physiquement en nombre de cartes filles. Les cartes mères sont conçues autour du processeur ARM7 et dispose de mémoires internes Flash de 256ko et RAM de 64ko. Les cartes filles embarquent un processeur PIC24F avec 32ko de mémoire Flash et 8ko de RAM. La carte mère s’occupe de gérer la communication entre les différents nœuds du RCSF, de transférer des mesures vers la station de collecte de données, ainsi que de piloter le réveil des différentes cartes filles. Les cartes filles sont conçues pour répondre à une application et traiter les informations provenant de différents capteurs.



Figure 4. Photo d’une carte mère avec une carte fille Watermark

A noter qu’il existe deux types de cartes filles : actives et passives. Les cartes filles actives possèdent un processeur et traitent elles-mêmes les données collectés par les capteurs. Les cartes filles passives ne possèdent pas de processeur. Par conséquent, elles ne peuvent que faire passer à la carte mère les données brutes collectées par les capteurs. La carte mère devra traiter les données brutes avant de les envoyer.

II.1.2. Fonctionnalités attendus de l'interface Un utilisateur de cette application attend diverses fonctionnalités. Il doit tout d'abord pouvoir l'utiliser sans être un expert. Cela signifie qu'il peut créer un nœud sans avoir à écrire du code, mais uniquement à l'aide de représentations graphiques et de paramètres. Il doit pouvoir paramétrer les différentes parties du nœud, que ce soit la carte mère, les cartes filles ou les capteurs. L'une des principales fonctionnalités attendue est de pouvoir générer du code à partir d'éléments connus, possédant des bibliothèques de codes, mais également à partir d'éléments inconnus. Dans ce cas, un squelette de code sera généré. Il doit également être possible d'ajouter de nouvelles cartes filles et capteurs au fil du temps. L'utilisateur doit également avoir une certaine liberté dans l'ordre des étapes de création d'un nœud, comme paramétrer une carte fille juste après l'avoir ajouté ou seulement après avoir ajouté toutes les cartes filles. Enfin, l'interface doit être facilement modulable pour ajouter, par exemple, de nouveaux paramètres ou de nouvelles fonctionnalités.

II.1.3. Etude le l’existant Un premier projet ISIMA, auquel je n'ai pas participé, a été réalisé en amont de mon stage. Le but de celui-ci était de concevoir un prototype d’interface et de tester les possibilités au



niveau de la génération de code. Le prototype devait permettre de générer du code paramétré d’une application pour une carte fille de type Watermark. L’interface a été réalisée en Java sous Eclipse avec la bibliothèque graphique Swing. Elle est découpée en différentes fenêtres, chaque fenêtre correspondant à une étape (Figure 5). En passant d’une étape à une autre, une nouvelle fenêtre s’ouvre et la précédente se ferme.

Figure 5. Diagrammes des différentes étapes du prototype

Le code est généré au fur et à mesure que l’on avance. Un dossier va être créé pour chaque carte fille dans lequel on trouvera la base du codage des cartes Watermark ainsi que les fichiers correspondant aux différents périphériques de la carte. La configuration des capteurs est écrite dans le fichier gpio.c . Ce prototype permet bien de générer du code pour les cartes Watermark, cependant il y a quelques défauts au niveau de l'ergonomie et de son fonctionnement. Par exemple, le fait de changer de fenêtre à chaque étape est perturbant. On place la fenêtre à un endroit et quand on passe à l’étape suivante, la nouvelle fenêtre se trouve aux coordonnées par défaut. On ne déplace alors plus la fenêtre car elles changent assez rapidement, ce qui nous fait travailler dans le coin supérieur gauche de notre écran. De plus, les éléments d’une fenêtre (bouton, case à cocher, zone de texte, etc.) ont des coordonnés absolues et non relatives. Ceci pose des problèmes d’alignement et de redimensionnement, mais également de modularité. Il y a également un problème lors de la configuration des capteurs (Figure 6), il faut faire attention à bien appuyer sur le bouton « Validate » pour chaque capteur avant de faire « Next step ». Il n’y a pas de contrôle sur ce dernier, et on peut passer à l’étape suivante sans avoir validé de configuration pour tous les capteurs. Il faut donc faire bien attention à valider



chaque configuration de capteur, pour éviter de générer du code avec des parties manquantes. Il est d’autant plus facile d’oublier de valider lorsque la carte fille n’a qu’un capteur.

Figure 6. Fenêtre de configuration de capteur du prototype

Le prototype possède également quelques limitations. Par exemple les cartes filles d’une carte mère sont obligatoirement du même type, alors qu'en règle générale, si un nœud possède plusieurs cartes filles ces dernières sont de types différents. On peut également remarquer sur la Figure 5 que les étapes pour une carte connue sont quasi similaires à celles pour les autres cartes. Il aurait peut-être été préférable de trouver une solution pour fusionner ses étapes et éviter une redondance en utilisant des classes quasi similaires. Après avoir étudié ce projet, divers problèmes sont apparus pour utiliser ce prototype comme base pour l'interface. Tout d'abord, son déroulement est trop séquentiel. Les différentes étapes doivent être faites dans un ordre précis. De plus, il n’est pas possible de revenir en arrière. Ceci implique que, si l’on a fait une erreur lors d’une étape, il faut recommencer de zéro. Il n’est pas non plus possible de sauvegarder le projet que l’on réalise. Il faut donc savoir précisément ce que l’on veut avant de lancer l’application. Un autre problème est la trop grande rigidité de ce prototype. Il n’est pas évident de rajouter des éléments, comme un autre type de carte fille ou de nouveaux paramètres pour des capteurs. Cela est en partie du à une gestion des éléments graphiques en coordonnées absolues, obligeant à réadapter ces éléments à chaque ajout d’un nouvel élément. Enfin, il est possible de paramétrer les cartes, mais le prototype ne possède pas de représentation graphique, permettant de mieux visualiser le nœud que l'on est en train de créer et d'ajouter ou retirer des éléments. Au vu des différents problèmes, j’ai donc suivi l’avis initial de mes encadrants et décidé de ne pas reprendre le prototype. Bien que je ne l'ai pas repris, je me suis tout de même inspiré du prototype pour développer l'interface.



II.2. Outils informatiques utilisés

II.2.1. Choix du langage de programmation Il m'a fallu choisir avant tout un langage de programmation qui allait être utilisés pour développer l'interface. J'ai focalisé mon choix sur des langages orientés objet et entre deux en particulier : C++ et Java. J'ai toutefois préféré Java à C++, notamment à cause de la portabilité de Java, permettant d'utiliser une application sur de multiples systèmes d'exploitation sans avoir à la recompiler. J'ai également choisi ce langage car il possède une bibliothèque graphique en standard et qu'il existe des outils facilitant le développement d'interfaces.

II.2.2. Choix d’un outil de modélisation Avant de commencer la modélisation de l’interface, j’ai recherché un logiciel permettant de réaliser des diagrammes UML. Ce logiciel devait : - pouvoir réaliser les principaux diagrammes UML - être libre - pouvoir générer du code Java à partir de diagrammes de classe Après quelques recherches j’ai sélectionné, dans un premier temps deux logiciels : Papyrus (voir Figure 7) et ArgoUML (voir Figure 8).

Figure 7. Vue généraliste d’ArgoUML



Papyrus a été développé en Java, et est basée sur Eclipse et sur le plugin UML2 d'Eclipse. Il a été développé à l'origine par le Commissariat à l'Energie Atomique, et est actuellement développé par Papyrus UML-Team. Il permet de générer du C++ ou du Java. ArgoUML est un logiciel conçu en Java et développé à l'origine par Jason E. Robbins. Il est maintenant un projet open source hébergé sur Tigris.org. Il permet de générer du C++, du C#, du Java, du PHP ou encore du SQL. Les points forts et faibles sont résumés dans le Tableau 1.

Tableau 1. Comparatif entre Papyrus et ArgoUML

UML 2 Support des classes Java Génération de diagrammes

Papyrus oui non non

ArgoUML non oui java

Papyrus possède l'avantage de gérer l'UML 2 alors qu’ArgoUML n'est qu'à UML 1.4. De nombreuses fonctionnalités d'Argo UML ne sont pas finies de développer, ce qui est également un bon désavantage face à Papyrus. Par exemple, certains diagrammes ne sont pas complètement implémentés et il n’est pas non plus possible d’annuler ou de répéter les actions. Cependant, ArgoUML possède deux bons avantages sur Papyrus. Tout d'abord, il possède, en plus des classes de base d’UML, toutes les classes de base de Java. Il offre également la possibilité de faire des constructeurs facilement. L'autre point fort d'ArgoUML est qu'il permet de générer des diagrammes de classes à partir d’un code Java, ce qui est intéressant pour réaliser le diagramme de classes final de l'application. Les deux logiciels possèdent néanmoins quelques défauts. Par exemple, dans Papyrus, il arrive fréquemment qu'il y ait des problèmes lorsque l'on sauvegarde des diagrammes. Dans ArgoUML, il arrive parfois que lorsque l'on veut supprimer un élément, il disparaisse seulement du diagramme mais ne soit pas réellement supprimé. J'ai choisi ArgoUML plutôt que Papyrus car, bien qu'il ne gère pas UML 2, le code généré est plus correct que celui de Papyrus, notamment grâce à l'intégration des classes de base de Java. Le fait qu'il puisse également générer un diagramme à partir du code est une bonne plus-value.



Figure 8. Vue généraliste d’ArgoUML

Comme on peut le voir dans la Figure 8, la zone de gauche permet de voir les différents éléments des projets. Ici, on peut voir les différents diagrammes UML qui seront affichés dans la zone centrale. Au centre, on a le diagramme sélectionné. Il est construit à l'aide de la barre d'outils se trouvant juste au dessus. Enfin, en bas se trouve les détails de l'élément sélectionné dans le diagramme. La partie la plus intéressante est la partie propriétés. C'est dans cet onglet que l'on indiquera les informations sur les attributs et méthodes des classes. Pour les attributs, il est, par exemple, possible de choisir le nom, le type, le niveau de visibilité, la valeur par défaut ou encore si l'attribut est de classe ou d'instance. Pour les méthodes, il est possibles d'indiquer les différents paramètres ainsi que de coder l'intérieur des méthodes. Il est rare que l'on code le contenu des méthodes dans ArgoUML car cette fonctionnalité n'est pas très pratique d'utilisation. La génération du code, notamment des interfaces et des héritages, fonctionne assez bien. Le seul point gênant dans le code généré est la mauvaise gestion des template. Il n'est pas possible de les utiliser avec les classes de base de Java telle que List, et il est également difficile de créer une classe avec un template.

II.2.3. Choix de la bibliothèque graphique Ne reprenant pas le prototype d’interface du projet, j’ai comparé les deux principales bibliothèques graphiques de Java pour déterminer laquelle utiliser. Ces deux bibliothèques sont Swing et JFace. Chacune de ces bibliothèques se reposent sur une autre bibliothèque, AWT pour Swing et SWT pour JFace. La grande différence entre Swing et JFace se trouve au niveau de Swing et SWT. Leur gestion des éléments graphiques, comme les fenêtres, les boutons, les zones de texte, ou la barre de menu est aussi différente.



Swing crée ses propres éléments en Java, ce qui le rend donc indépendant de l'OS (Operating System, système d’exploitation). SWT, de son côté, demande au système d’exploitation de lui créer des éléments externes à Java et qu’il gérera par la suite. De cette différence découle différents avantages et inconvénients (voir Tableau 2).

Tableau 2. Comparatif entre Swing et JFace

Performances Portabilité Apparence

Swing Assez lourd Gestion automatique des ressources

Indépendant de l'OS Indépendante de l'OS

JFace Rapide et fluide Gestion manuelle des ressources

Installation de bibliothèques en fonction de l'OS

Apparence similaire à celle de l'OS

Au niveau des performances, JFace est plus rapide que Swing car il fait appel a des composants natifs alors que Swing fait appel à des composants en Java. Cependant, dans le cas particulier de l'affichage d'un très grand nombre de données, JFace est plus lent. En effet, les données à afficher doivent systématiquement être copiées dans les composants natifs, alors qu'avec Swing, elles sont utilisées directement, sans recopie. Toutefois, le nombre d'éléments à afficher dans un composant graphique est le plus souvent modéré. Contrairement à Swing, JFace demande de gérer soit même la libération des ressources car ces dernières sont alloués par l'OS et non le Java. Au niveau de la portabilité, Swing est totalement indépendant de l'OS sur lequel il tourne et il fait également partie des bibliothèques de base de Java, ce qui le rend facilement utilisable et exploitable. Du côté de JFace, certaines bibliothèques sont dépendantes de l'OS. Bien que les programmes utilisant JFace soient indépendants de l'OS, il faudra donc installer ces librairies en fonctions de ce dernier. De plus, JFace ne fait pas partie des bibliothèques de base de Java. Enfin au niveau de l'apparence, elle ne change pas d'un OS à l'autre pour Swing tandis que pour JFace, l'apparence des programmes est similaire au système sur lequel il fonctionne. Swing permet donc d'avoir une apparence unique et personnalisable, et JFace permet de faire des applications s'intégrant mieux avec l'OS. J’ai commencé par développer quelques petits programmes avec JFace, car je ne connaissais pas cette bibliothèque. Après un petit temps d’adaptation, JFace étant un peu déroutant au début, je l’ai trouvé plus facile d'utilisation que Swing. Il m’a fallu un temps d’adaptation car j’étais habitué à Swing et que les deux bibliothèques se ressemblent. Certaines classes portent le même nom, mais d’autres non. On passe donc du temps à chercher les noms de ces classes. Il faut aussi penser à bien libérer les éléments. Enfin, chose qui m’a le plus dérouté par rapport à Swing, c’est que les éléments d’interface sont liés à un autre dès leur création. Si l’on veut par exemple ajouter un bouton dans une fenêtre, avec Swing on crée la fenêtre et le bouton, puis on ajoute le bouton à la fenêtre, ce qui est le schéma naturelle. Dans JFace, on crée la fenêtre, puis lorsqu’on crée le bouton, on indique qu’il se trouve dans la fenêtre, ce qui est donc le schéma inverse. Finalement, je me suis plutôt tourné vers JFace que Swing, car je l'ai trouvé plus pratique que Swing pour développer l'interface. Le nombre de données à afficher étant modéré, JFace sera



également plus performant que Swing. De plus, cela me permet de découvrir une nouvelle bibliothèque graphique et de ne pas me limiter à Swing. J'ai toutefois préférer étudier les RCP (Rich Client Platform) avant de faire un choix définitif sur la bibliothèque graphique.

II.2.4. Utilisation d’un RCP Un RCP, ou plateforme client riche en français, fournit des briques logicielles de base pour la construction d’une application ainsi qu’un noyau exécutif pour le faire fonctionner. Cela permet de faciliter la conception d’une interface en partant d’une base connue, fonctionnelle et fiable. Les RCP se basent en général sur un framework. Les principaux framework en Java sont Eclipse, NetBeans et Spring Framework, qui sont open source (code source libre). Eclipse et NetBeans sont deux environnements de développement qui ont été codé en Java pour produire des programmes en Java. Les deux mettent à disposition leur framework pour développer un RCP. Le framework de NetBeans utilise Swing pour la partie graphique tandis que celui d’Eclipse utilise JFace. Devant développer mon interface sous Eclipse, j’ai étudié principalement le fonctionnement de son framework pour le développement d’un RCP. Développer un RCP avec le framework d’Eclipe revient à faire un ou plusieurs plugins pour Eclipse. L’application pourra donc fonctionner directement sous Eclipse. Mais, il est également possible de rendre l’application autonome. Pour cela, Eclipse va générer une base, un noyau, auquel il va rajouter les plugins de l’application. On peut voir sur la Figure 9 un exemple d’interface, ici un afficheur de données géographiques, réalisé avec Eclipse RCP.



Figure 9. Exemple d’interface développé avec Eclipse RCP

Pour les applications reprenant le fonctionnement d’Eclipse, l’interface est basée sur des vues, éditeurs et perspectives. Les éditeurs sont regroupés dans une zone, souvent la zone central. Un éditeur correspond à un élément sur lequel on travaille. Il peut s’agir de codes sources ou encore de diagrammes UML par exemple. Autour de cette zone peuvent se trouver des vues. Elles peuvent être regroupées sous forme d’onglets ou séparées. Les vue contiennent des informations annexes aux éditeurs, comme un explorateur de fichier, des informations sur un fichier ou encore les valeurs des variables lors d’un débogage. Enfin, les perspectives correspondent à un ensemble de vues et à leurs organisations. Une perspective correspond généralement à un type d’utilisation. Dans Eclipse, les deux principales perspectives sont celles de développement et celle de débogage. La perspective de débogage va contenir des vues pour connaître des informations sur le déroulement de l’exécution que n’aura pas la perspective de développement Ce framework utilisant JFace et donc SWT. Il est donc dépendant du système d’exploitation sur lequel il fonctionne. Cela ne concerne pas tout le framework mais seulement la portion de SWT qui est spécifique à un système. Le code de notre application est donc indépendant du système mais il se repose sur un framework qui ne l’est pas. Pour faciliter la diffusion de l’application, Eclipse permet d’exporter l’application vers n’importe lequel des systèmes d’exploitation où Eclipse est compatible. Eclipse créera un dossier comprenant les plugins de notre application ainsi que les plugins du framework qu’on utilise, comprenant la version adaptée au système d’exploitation de SWT, le noyau du framework et un fichier permettant de démarrer l’application, qui est généré en fonction du système d’exploitation cible.



J’ai finalement choisi de faire un RCP à l’aide du framework d’Eclipse, car cela me permettrait de développer plus rapidement l’interface, notamment grâce aux concepts d'éditeurs et de vues. Il serait alors possible d'afficher facilement une représentation graphique ainsi que les paramètres dans la même fenêtre. J’ai également choisi celui d’Eclipse à cause de sa notion de plugin, permettant de rajouter facilement des modules à une application, mais également d'utiliser l'application directement au sein d'Eclipse. Au niveau de la bibliothèque graphique, cela concordé de plus avec mon choix initial.



III. MODELISATION DE L’INTERFACE

III.1. Déroulement de son utilisation

J’ai tout d'abord repéré les différentes actions qu’un utilisateur voudra faire. Cela m’a permis de construire un diagramme de cas d’utilisation (Figure 10).

Figure 10. Diagramme de cas d'utilisation de l'application Ce diagramme est assez simple et ne comporte qu'un acteur. Au niveau des cas d'utilisation, l'utilisateur peut créer, configurer ou supprimer un nœud, ajouter un élément, que ça soit une carte mère, une carte fille, ou un protocole ou un capteur. Il peut également créer un profil de carte fille. Enfin, l'utilisateur peut générer le code du nœud qu'il a créé. A partir de ce diagramme, j'ai défini les différentes étapes pour créer un nœud, et j’ai établi un diagramme d’activité (Figure 11), indiquant le déroulement logique des différentes étapes.



Figure 11. Diagramme d’activité de l'application

Dans un premier temps, l’utilisateur crée et configure un nœud puis carte mère. Ensuite pour les cartes filles, il peut soit décider d’utiliser une carte fille existante, soit créer un nouveau profil, où il indiquera les capteurs qu’elle possède ainsi que certains paramètres. Il configurera ensuite la carte fille pour le nœud qu’il réalise. Enfin, une fois que toutes les cartes filles sont ajoutées et configurées, il générera le code. Bien entendu, le diagramme d'activité montre le déroulement théorique du programme. En réalité, l'utilisateur pourra configurer les éléments quand il le souhaite ou encore pourra créer un profil sans l'utiliser dans le nœud.

III.2. Diagrammes de classes de l’application

A partir du diagramme d’activité et de l'étude du prototype, j'ai tout d'abord réalisé les différents packages de l'application. Un diagramme de classes a été réalisé pour chaque package. Le tout premier package est le package « data » (Figure 12 et Annexe I), qui regroupent les différentes données d'un projet ainsi qu'une interface, IData, que les différentes classes de ce package vont implémenter. Ces classes sont Project, Node, MotherBoard, ChildBoard, Link et Sensor, correspondantes respectivement à un projet, un nœud, une carte mère, une carte fille, un protocole de communication et un capteur. Il y a également un autre package dans data, intitulé « profile », et contenant les classe ChildBoardP, LinkP et SensorP. Les classes de ce package correspondent à un profil (ou modèle) d'élément. Par exemple, une carte fille seule correspond à un ChildBoardP, tandis que cette même carte intégrée dans un nœud correspondra à un ChildBoard et contiendra des informations supplémentaires. Ces éléments ne sont donc pas dépendants du nœud et peuvent être réutilisés d'un projet à l'autre. Un projet contient donc un nœud, qui contient une carte mère. Cette carte mère dialogue avec les cartes filles via des protocoles de communication et chacune d’elles est définit à partir d’un modèle de carte fille, et contient des capteurs et les librairies de traitement. Les modèles de carte filles contiennent des modèles de capteurs.



Prenons l’exemple d’un nœud possédant des cartes filles Watermark. La carte mère dialoguera avec les cartes filles via le protocole de communication I²C, et chacune d’elles est définit à partir du modèle de carte Watermark. Ce modèle comporte trois capteurs de type Watermark et possèdent des librairies de traitement permettant de gérer la carte fille et ses capteurs.

Figure 12. Version simplifiée du diagramme de classes du package « data »

Un deuxième package important est « io » (Figure 13 et Annexe II), comprenant les classes permettant de gérer les entrées/sorties. Il contient les classes ProjectFile, ChildBoardFile, LinkFile et SensorFile qui permettent respectivement de charger et de sauvegarder un projet, un modèle de carte fille, un modèle de protocole de communication ou un modèle de capteur dans un fichier texte. Il y a également la classe Generator, permettant de générer le code source du nœud.

Figure 13. Version simplifiée du diagramme de classes du package « io »



Un troisième package, nommé « ui » (Figure 14), regroupe toutes les classes permettant de réaliser l'interface graphique de l'application. Il y a dedans six packages : « perspectives », « views » (Annexe III), « viewers », « editors » (Annexe IV), « input » et « actions » qui contiennent respectivement les perspectives, les vues, les visionneuses, les éditeurs, les types d’entrées des éditeurs et les actions. Les classes de ces packages sont les différentes classes permettant de faire un RCP à l'aide du framework d'Eclipse. Le package « ui » contient également un autre package, « forms ». Ce dernier contient différentes classes implémentant l'interface Iform, se trouvant dans ce même package. Ces classes servent à représenter graphiquement les instances des classes du package « data ». Il y a les classes NodeForm, MotherBoardForm, ChildBoardForm, LinkForm, ProfileForm et SensorForm, permettant de représenter un nœud, une carte mère une carte fille, un protocole de communication ou un capteur. Le package contient, pour finir, l’interface DrawableData qui est implémentée par les classes du package « data » possédant une représentation graphique comme les nœuds, les capteurs, etc.

Figure 14. Version simplifiée du diagramme de classes du package « ui »

Enfin, il y a trois autres packages mineurs : - « historic », regroupant les différentes classes servant à créer un historique, pour pouvoir

annuler ou répéter des actions. Il contient la classe Historic permettant de constituer un historique d'actions, ainsi que des classes d'actions implémentant l'interface IHistoricAction. Ces classes sont CreateAction, DeleteAction et MoveAction.

- « models », contenant une classe générique Model, et trois autres classes héritant de

ChildBoardModel, LinkModel et SensorModel. Ces classes permettent de lister tous les



types de cartes filles, protocoles et capteurs existants, correspondant à des instances des classes ChildBoardP, LinkP et SensorP.

- « util », regroupant les classes IOFunction, LineReader et LineWriter. IOFunction et

contenant les fonctions utiles pour la gestion des fichiers, comme la création d’un dossier, la copie d’un fichier ou encore la copie d’un dossier. LineReader et LineWriter servent à lire et écrire ligne par ligne dans un fichier texte.

Cinq classes se trouvent également à la racine de l'application. Ces classes sont celles de base, générées par Eclipse, pour faire un RCP. Ce sont les premières classes de l'application à être utilisées et permettent de créer la fenêtre, ainsi que la barre de menu et les raccourcis.

III.3. Découpage en vues

Pour pouvoir représenter le nœud et le paramétrer, des vues, correspondant à différents niveaux de zoom sur le nœud, ont été définies. Elles permettent de mieux visualiser la partie du nœud sur laquelle on travaille. La première vue correspond au nœud vu de l’extérieur (Figure 15). Celle-ci permet de paramétrer le nœud au niveau de son intégration au réseau, comme par exemple l'activation d'un DHCP (Dynamic Host Configuration Protocol) ou l’adresse IP (Internet Protocol) du nœud, la passerelle de communication et l'identifiant du réseau auquel il appartient.

Figure 15. Vue externe du nœud

La deuxième vue est interne au nœud (Figure 16). Elle représente donc la carte mère, les cartes fille ainsi que le ou les protocole(s) de communication entre la carte mère et chaque carte fille. Ici, on pourra paramétrer les fréquences d'envoi, la calibration des capteurs ainsi que tous les paramètres spécifiques relatifs à la carte mère et aux cartes filles.



Figure 16. Vue interne du nœud

La dernière vue représente l'intérieur d'une carte fille (Figure 17). Cette vue schématise la carte fille et ses capteurs. Dans cette vue, on représente graphiquement un profil de carte fille avec l'ensemble des éléments la constituant. On retrouve les capteurs avec leurs librairies respectives ainsi que la définition du protocole de communication avec la carte mère. Les paramètres que l'on trouve ici, sont indépendants de la carte mère, et du nœud.

Figure 17. Vue interne de la carte fille



IV. DEVELOPPEMENT DE L’APPLICATION

Deux grandes parties se distinguent dans l’application. D’un côté le cœur de l’application, gérant les différents éléments et paramètres d’un nœud ainsi que la génération du code, et de l’autre nous avons l’interface vue par l’utilisateur permettant de communiquer avec le cœur.

IV.1. Cœur de l’application

IV.1.1. Données et ressources Comme nous l'avons vu dans le diagramme de classe classes (voir paragraphe III.2, Figure 12), il y a neuf types de données qui sont associées à neuf classes : Project, Node, MotherBoard, ChildBoard, Link, Sensor, ChildBoardP, LinkP et SensorP. Ces données sont : un projet, un nœud, une carte mère, une carte fille, un capteur, un protocole de communication, un modèle de carte fille, un modèle de capteur et un modèle de protocole de communication. Ces données sont identifiées par des noms uniques. Comme nous l'avons vu, les trois dernières classes, correspondant à des profils, peuvent être réutilisées. Il faut donc pouvoir les enregistrer et les charger. Cela sera réalisé à l'aide des classes ChildBoardFile, SensorFile et LinkFile. Les données sont sauvegardées sous forme de fichier texte où chaque ligne correspond à une valeur d’une variable. Elles seront chargées au démarrage de l’application. Les profils possèdent tous un nom ainsi que le chemin d'accès à la bibliothèque associée à la carte fille, capteur ou protocole. Les capteurs et protocoles possèdent également le nom du fichier à inclure dans le code de la carte fille. Par exemple pour un capteur Watermark, le chemin d'accès sera « /bibliotheques/capteurs/watermark/ », contenant les fichiers watermark.c et watermark.h. Le fichier à inclure sera watermark.h, et on écrira donc #include « watermark.h » dans le code de la carte fille. Pour la carte fille, elle contient le chemin des différents fichiers correspondant aux modèles de capteurs qui la compose (Tableau 3).

Tableau 3. Formatage d'un fichier de carte fille Nom de la carte Carte Watermark

Chemin de la bibliothèque de la carte /bibliotheque s/cartes filles/watermark/

Chemin du fichier du capteur 1 /ressources/capteur s/watermark.sen

Chemin du fichier du capteur 2 /ressources/capteurs /watermark.sen

Les six autres classes représentent les éléments d’un projet. La classe ProjectFile permet d’enregistrer ou charger un projet, en faisant étape par étape, pour chaque élément (Annexe V). Les projets sont également sauvegardés sous forme de fichiers texte formatés de la même manière que les précédents (Tableau 4). Les fichiers du projet pourront être chargés à n'importe quel moment de l’exécution du programme.



Les objets ChildBoard, Sensor et Link sont rattachés à un modèle. Au niveau du fichier de projet, cela ce traduit par le nom du profil.

Tableau 4. Exemple de formatage d'un fichier de projet Identifiant du projet Test

Identifiant du nœud Nœud

Adresse IP si on n’utilise pas de DHCP, sinon null

null

Caractéristiques de la représentation graphique du nœud

89;60;100;60

Identifiant de la carte mère Carte mère

Fréquence de la carte mère 10

Caractéristiques de la représentation graphique de la carte mère

30;109;100;60

Identifiant de la carte fille 1 Carte Watermark

Etat de la carte fille 1 0

Adresse de la carte fille 1 0x67

Caractéristiques de la représentation graphique de la carte fille 1

211;72;77;51

Identifiant du profil de la carte fille 1 Carte Wat ermark

Identifiant du protocole 1 de la carte fille 1

I2C

Caractéristiques de sa représentation graphique

211;99;132;138

Identifiant du capteur 1 de la carte fille 1

Watermark

Identifiant du profil du capteur 1 de la carte fille 1

Watermark

Etat du capteur 1 de la carte fille 1 1

Fréquence du capteur 1 de la carte fille 1 2

Statut du capteur 1 de la carte fille 1 3

Pin d'alimentation du capteur 1 de la carte fille 1

22

Pin de transmission du capteur 1 de la carte fille 1

23

Canal du capteur 1 de la carte fille 1 10

Type de canal du capteur 1 de la carte fille 1

0



IV.1.2. Génération de code Une fois que le nœud a été paramétré, on passe à l'étape de génération du code associé. Cette étape consiste à insérer les paramètres dans un squelette de code plus ou moins complet. On ne traite ici que de la génération des cartes filles, pas celle de la carte mère et du nœu. Pour générer entièrement le nœud, il faudrait générer les cartes filles et la carte mère. Lors de la génération, un dossier sera créé et portera le nom du nœud. A l’intérieur, se trouveront les dossiers des cartes filles, dans lesquels il y aura d’autres dossiers séparant les différentes parties du code, comme le squelette, les protocoles de communication ou encore les capteurs. En fonction des éléments qui composent la carte fille, différents fichiers seront copiés dans les dossiers. Enfin, au niveau du squelette du code, les paramètres de la carte fille seront écrits. Les principaux paramètres de la carte fille se feront dans la fonction Init_cfg_global du fichier config.c, tandis que les paramètres des capteurs (Annexe VI) qui la composent se feront dans la fonction Init_cfg_sensors du même fichier (Figure 18). Il faut également inclure les fichiers dont la carte fille a besoin dans le fichier include_lib.h. Ces fichiers sont ceux des protocoles de communication et des bibliothèques associées aux capteurs. Pour écrire le code au niveau du squelette, le fichier config.c est copié dans un fichier temporaire puis il va être recopié au fur et à mesure. On écrit les paramètres lorsque l’on arrive au niveau où l’on doit les insérer, puis on continue de recopier le fichier temporaire. Une fois que l’on a fini, il ne reste plus qu’à fermer le fichier temporaire, qui sera alors supprimer, et à fermer config.c qui contiendra alors les paramètres de la carte fille.

Figure 18. Exemple du code générer

void Init_cfg_global() { cfg_global.state = 0; cfg_global.address = 0x67; cfg_global.nb_sensors = 3; } void Init_cfg_sensors() { cfg[0].state = UNKNOWN_STATE; cfg[0].alim = 11; cfg[0].pin = 22; cfg[0].channel = 10; cfg[0].channel_type = IO_TYPE; cfg[0].sensor_cfg.id = 0; cfg[0].sensor_cfg.type = WATERMARK_SENSOR_TYPE; cfg[0].sensor_cfg.status = NORMAL_SENSOR_STATE; cfg[0].sensor_cfg.freq = 300; cfg[1].state = UNKNOWN_STATE; cfg[1].alim = 13; cfg[1].pin = 24; cfg[1].channel = 12; cfg[1].channel_type = IO_TYPE; cfg[1].sensor_cfg.id = 1; cfg[1].sensor_cfg.type = WATERMARK_SENSOR_TYPE; cfg[1].sensor_cfg.status = NORMAL_SENSOR_STATE; cfg[1].sensor_cfg.freq = 300; }



IV.2. Interface

IV.2.1. Création d’une interface avec Eclipse RCP Un plugin d’Eclipse permet d’utiliser facilement le framework d’Eclipse, mais il n’est pas dans tous les packs d’Eclipse. Il sert en réalité à faire des plugins qui pourront être ou non des RCPs. Avant de créer l’interface, il faut d’abord créer un projet de plugin dans notre cas. On peut préciser la cible sur laquelle est destinée le plugin, comme par exemple une certaine version d’Eclipse. Le nom d’un plugin Java est en général construit de la même manière que les packages. Dans le cas présent, le plugin a été nommé « com.cemagref.interface ». Il faut ensuite donner quelques informations supplémentaires sur le plugin comme son identifiant, la version que l’on réalise ou encore la version de Java qu’il utilise. Ces paramètres seront modifiables par la suite. On nous demande également si l’on veut créer un RCP ce qui est notre cas. Enfin avant de finir la création du projet, on peut choisir un modèle de RCP. Cinq classes ainsi que des fichiers sur le plugin sont alors générés. Ces cinq classes sont : - Activator , qui sert à activer le plugin, - Application , qui sera appelée lorsque la classe s’activera ou se désactivera, - ApplicationActionBarAdvisor , regroupant toutes les actions, qui sont généralement

utilisées par un raccourci ou dans la barre de menu, et permettant de construire une barre de menu,

- ApplicationWorkbenchAdvisor , qui créera l’espace de travail - ApplicationWorkbenchWindowAdvisor , qui créera et remplira la fenêtre Seules les classes ApplicationActionBarAdvisor et ApplicationWorkbenchWindow

Advisor peuvent avoir besoin d’être complétées. En essayant d’ouvrir le fichier XML ou le manifeste du plugin, un onglet s’ouvre et regroupe les principales informations et caractéristiques du plugin. On peut voir et modifier les dépendances de notre plugin, mais aussi indiquer quels packages seront visibles, les éléments et ressources du projet qui doivent être incluses. La partie la plus intéressante est celle traitant des extensions du plugin (Figure 19). Depuis cet onglet, il est possible de concevoir le squelette de l’interface sans effort de programmation. Bien entendu il est toujours possible de réécrire ces éléments. Chaque extension permet d’ajouter un type d’élément dans l’application. Par exemple l’extension org.eclipse.ui.views permet de créer des vues, tandis que l’extension org.eclipse.ui.bindings permet de définir des raccourcis clavier. Dans la partie de droite, on indiquera les détails de l’élément sélectionné. Par exemple pour une vue, différents paramètres tels que l’identifiant de la vue, le nom de la vue et la classe associée à la vue pourront être renseignés.



Figure 19. Onglet d'extension du plugin

L’interface de l’application utilise les extensions suivantes : - org.eclipse.core.runtime.products , regroupant les informations utilisées si on rend

le plugin autonome ; - org.eclipse.core.runtime.application , servant à indiquer la classe principale de

l’application ; - org.eclipse.ui.perspectives , permettant de créer des perspectives; - org.eclipse.ui.perspectiveExtensions , indiquant les vues que contiennent les

perspectives; - org.eclipse.ui.views , gérant les vues; - org.eclipse.ui.editors , permettant de créer des éditeurs; - org.eclipse.ui.commands , regroupant des commandes; - org.eclipse.ui.bindings , permettant de créer des raccourcis clavier, chaque raccourci

étant associé à une commande. Une fois les extensions créées il faut remplir les classes associées. La plupart de ces classes possèdent un identifiant unique pour que le noyau d'Eclipse puisse aller chercher leurs différents éléments. Une vue, par exemple, ne peut apparaître qu’une fois dans une perspective, ce qui fait que la classe associée à la vue ne sera jamais instanciée plus d’une fois simultanément. Dans le cas des éditeurs, il y a un double identifiant. L’identifiant du type d’éditeur et l’identifiant des données en entrée de l’éditeur. Il est donc possible d'instancier plusieurs fois un éditeur, du moment que les données en entrée sont différentes. Par exemple, si on a un diagramme UML codé en XML, on pourra l'ouvrir avec un éditeur XML et UML en même temps, l'un affichant le XML et l'autre le diagramme, mais il n'est pas possible d'ouvrir deux fois le fichier avec l'éditeur XML.



IV.2.2. Principales parties de l’interface Comme nous le montre la Figure 20, l’interface est découpée en quatre parties : l’explorateur à gauche, les listes des ressources à droite, une zone pour le paramétrage en bas et l’éditeur graphique, au centre. Les trois premières parties contiennent des vues, tandis que la dernière contient les éditeurs.

Figure 20. Vision globale de l'interface

Les vues se reposent sur des viewers, c’est-à-dire sur une classe qui va permettre de visualiser les données passées en entrée à la vue. Par exemple, un TreeViewer va permettre d'afficher les données sous la forme d'une arborescence. La vue va également avoir besoin de savoir comment nommer les objets fournis par le viewer. Les éditeurs permettent de modifier un type de donnée. Un éditeur XML permettra de modifier des fichiers XML, tandis qu'un éditeur de carte fille permettra de modifier une carte fille. Les éditeurs sont donc fortement liés aux données passées en entrée. Eclipse a intégré une gestion de sauvegarde au niveau des éditeurs pour sauvegarder les modifications effectués. Il n’y a que quatre méthodes à remplir pour gérer la sauvegarde des fichiers d’un éditeur : - isSaveAsAllowed , qui permet d’indiquer si l’éditeur est autorisé à sauvegarder ; - isDirty , qui permet de savoir si le fichier a été modifié depuis la dernière sauvegarde ; - doSave et doSaveAs , qui sont appelées lorsque l’on veut sauvegarder.



IV.2.2.a. Explorateur L’explorateur permet de voir les différents projets ouverts ainsi que les éléments d’un projet, comme le nœud et les cartes filles. Une structure en arborescence a donc été choisie comme dans la plupart des explorateurs de fichiers. Le viewer utilisé a donc été un objet de type TreeViewer , permettant de visualiser les données sous forme d’arbre. Il a besoin d’une autre classe, implémentant l’interface ITreeContentProvider , lui indiquant comment construire l’arbre à partir des données en entrée, à l’aide de quatre méthodes : - getElements , permettant de récupérer les éléments de l’arborescence à partir d’une

entrée sous forme de tableau ; - hasChildren ( Annexe VII) , permettant de savoir si un élément possède un fils ; - getChildren ( Annexe VIII) , indiquant la manière de récupérer les fils d’un élément ; - getParent , indiquant la manière de récupérer le père d’un l’élément. Si hasChildren retourne vrai, le symbole « + » apparaitra à côté de l’élément. Lorsque l’on clique dessus, la méthode getChildren sera alors appelée. Il n’est pas obligatoire de remplir la méthode getParent pour pouvoir créer l’arborescence. En double cliquant sur un élément, il est possible de déclencher un événement. Ici, un double clic sur un élément permet d’ouvrir l’éditeur associé à cet élément. Il n’est possible d’ouvrir un éditeur qu’en double cliquant sur un projet, un nœud ou une carte fille.

IV.2.2.b. Listes des ressources Cette zone permet de lister les éléments qui peuvent être rajoutés au projet, c’est-à-dire les cartes filles, les protocoles de communication et les capteurs. Pour cela, on utilise trois vues similaires regroupées en onglets, chaque vue correspondant à un type de ressource. Vu que l’on a besoin de lister des éléments, le viewer utilisé ici est un ListViewer . Pour ajouter un élément d’une des listes dans le projet, il faut sélectionner l’élément puis le dessiner dans l’éditeur. Bien entendu, il n’est pas possible de créer n‘importe quel élément n’importe où. Les cartes filles et les protocoles de communication ne pourront être insérées seulement lorsque l’on concevra l’intérieur d’un nœud, et les capteurs ne pourront être ajoutés que lors de la conception de l’intérieur d’une carte fille.

Il est possible d’ajouter des éléments dans les listes. En réalité, à chaque fois que l’on enregistre l’un de ces éléments, une nouvelle entrée est créée. Par exemple, si j’ajoute une carte fille existante dans un projet et que je modifie sa composition puis la sauvegarde, le profil d’origine ne sera pas modifié mais, par contre, un nouveau sera créé et listé.

IV.2.2.c. Vue pour le paramétrage Cette vue permet de voir les paramètres du ou des éléments sélectionnés dans l’éditeur actif. Le mieux pour afficher ces paramètres est de les organiser sous forme de tableau où chaque ligne correspond à un paramètre de l’élément sélectionné. La première colonne contenant l’intitulé du paramètre et la deuxième contenant le paramètre. Eclipse offre bien la possibilité de faire des tableaux mais leur gestion n’est pas prévue pour cette forme d’affichage. Les tableaux sont prévus pour avoir une entrée par ligne et non par colonne comme on l’aurait souhaité. La première ligne contient donc l’intitulé des paramètres et la seconde ligne contient les paramètres. Le viewer utilisé pour faire un tableau est un ParameterViewer , que j’ai écrit et qui hérite de la classe TableViewer . C’est le viewer qui va créer le tableau et déterminer le nombre de



colonnes. Chacune de ces colonnes sera associée à un TableViewerColumn qui permettra de visualiser les cases d’une colonne en fonction de l’entrée. Ils s’appuient sur une instance de la classe DataEditingSupport , héritée de l’objet EditingSupport servant à remplir une cellule. Dans cette classe, j’implémente quatre méthodes principales : - getCellEditor , déterminant le type d’éditeur de cellule ; - canEdit , vérifiant si une cellule est modifiable ; - getValue , permettant de récupérer la valeur utilisée par l’éditeur de cellule ; - setValue , permettant de modifier la valeur utilisée par l’éditeur de cellule. Ces méthodes ont toutes comme paramètre l’élément qui est en entrée de la ligne actuelle. Il existe différents types d’éditeurs de cellule. Cela peut être une zone de texte ou une liste déroulante par exemple. La valeur récupérée par getValue peut-être différente de celle affichée. Par exemple si l’éditeur de cellule est une liste déroulante, la valeur attendue est le numéro de l’élément dans la liste et non l’intitulé. Les éléments sélectionnés étant différent, la barre de titre du tableau n'est pas utilisable. Si une carte mère et une carte fille sont sélectionnées, les intitulés ne peuvent être utilisés comme barre de titre car il ne correspondrait pas à tous les éléments sélectionnés. Les intitulés sont donc insérés dans le tableau à chaque type d’élément sélectionné, les éléments étant triés par type.

IV.2.2.d. Editeur graphique Les éditeurs de l’interface sont basés sur les « vues » évoquées dans la partie III.3. Il y en a donc trois : nœud, carte mère/cartes filles et carte fille/capteurs. Ces éditeurs sont ouverts à partir de l’explorateur de projet. En double cliquant sur un projet, on ouvre l’éditeur représentant le nœud. En le faisant sur un nœud, on ouvrira l’éditeur représentant l’intérieur d’un nœud avec sa carte mère et ses cartes filles. Et enfin, en le faisant sur une carte fille, on ouvrira l’éditeur représentant l’intérieur d’une carte fille, c’est-à-dire celle-ci ainsi que ses capteurs. L’élément passé en entrée de ces éditeurs est l’objet sur lequel on a double cliqué. Ces éditeurs sont constitués d’un canevas sur lequel sera dessiné le schéma. Un écouteur d’événements est associé à ce canevas. Ces éditeurs ont deux modes de fonctionnement. Ils peuvent être soit en mode « dessin », soit en mode « déplacement ». Dans le mode « dessin », il est possible d’ajouter des éléments. Pour cela, il faut avoir au préalable sélectionné l’élément à insérer puis le dessiner en cliquant puis en tirant tout en maintenant enfoncé le bouton de la souris. L’élément sera créé en relâchant le bouton. Dans le mode « déplacement », il est possible de sélectionner un ou plusieurs éléments. Seuls les éléments qui sont inclus dans la zone de sélections seront sélectionnés. Il est ensuite possible de déplacer les éléments sélectionnés ou de les supprimer. Lorsque l’on modifie le nom d’un élément sans les paramètres, le nom est mis à jour dans l’éditeur et dans l’explorateur de projet. Lorsqu’un élément est ajouté ou supprimé, l’explorateur de projet est également mis à jour. A chaque éditeur est également associé un historique. Cet historique permet d’annuler ou répéter les actions que l’on a faites dans l’éditeur, c’est-à-dire créer, déplacer ou supprimer un élément. Il permet également de déterminer si la sauvegarde est à jour ou non.



IV.2.3. Exporter le RCP Un fois l’application terminée, il reste encore à récupérer le plugin ou la version autonome. Pour exporter le plugin, il suffit de cliquer sur exporter dans la partie Overview de la fenêtre contenant les extensions du plugin, que nous avions vue précédemment. Mais si l’on veut réaliser une application autonome, cela demande plus de temps. Il faut tout d’abord créer un nouveau fichier de configuration de produit. Ce fichier correspond donc à une application autonome. Il faudra indiquer tout d’abord le nom du produit ainsi que sa version. Il faudra ensuite indiquer la classe « application » qui sera la première classe appelée. Ici, cette classe est la classe Application de mon plugin com.cemagref.interface . Il faut ensuite préciser les plugins à inclure. Il suffit ici de sélectionner mon plugin, puis d’appuyer sur « Ajouter les plugins requis » pour ajouter automatiquement les plugins dont dépend le mien. Il est ensuite possible de déterminer les autres plugins à démarrer en plus du principal, ce qui n’est pas le cas ici. Il y a enfin quelques autres options, comme la possibilité d’associer une icône à l’application ou encore de remplir la fenêtre « A propos de » que propose Eclipse. Après avoir fini le paramétrage de l’application, il est enfin possible d’exporter l’application.



V. PREMIERE UTILISATION DE L’APPLICATION

V.1. Test de l’interface

Une fois le développement de l’interface terminé, j’ai effectué des tests pour vérifier son bon fonctionnement et corriger des bogues. Il y a eu des tests mineurs, tel que la vérification des raccourcis ou le bon affichage des schémas. Des tests plus importants ont été réalisés sur les fichiers de projet. Il a fallu vérifier que la sauvegarde s’effectue correctement. Pour le chargement, il fallait supporter un fichier tronqué, et traité le cas où un projet fait référence à un profil de carte fille inexistant dans l’interface. Il a fallu ensuite tester l’arborescence, qui est assez fragile. Il faut bien sécuriser les fonctions déterminant si un élément possède un fils et permettant de récupérer ses fils. Si un problème survient dans ces fonctions, l’arborescence peut afficher des fils invisibles, être tronquée ou aboutir à une boucle infinie, avec un élément qui est son propre fils. Pour le cas particulier d’une référence à un profil inexistant, la carte fille apparait bien dans l’arborescence, mais il faut vérifier qu’on ne puisse pas l’ouvrir, car sinon le programme bogue. Les fichiers de profil ont des tests similaires, il faut vérifier que les fichiers sont correctement sauvegardés, et pouvoir charger des fichiers tronqués. Il faut également gérer le cas où deux profils portent le même nom. Pour la génération de code, j’ai testé que le code puisse être générer même si des informations manquent, comme l’état d’un capteur ou encore les bibliothèques associées à ce dernier. Enfin j’ai effectué beaucoup de tests au niveau des entrées de l’utilisateur pour les paramètres. Par exemple, vérifier que la fréquence du capteur est bien un entier ou que l’adresse du nœud est bien en hexadécimale.

V.2. Réalisation d’un nœud

Voici un exemple d’utilisation de l’application pour réaliser un nœud. Au lancement de l'application, les profils sont chargés. Dans notre exemple, on charge le protocole I²C et le capteur Watermark, ce qui va créer un LinkP et un SensorP. Ces profils sont ajoutés dans les listes de la partie droite de la fenêtre. Un fois ceci fait, il nous faut créer un nouveau projet, que l’on nomme Test. Le fichier « Test.pjt » sera créer, et contiendra toutes les données du projet. Un nœud et une carte mère sont ajoutés automatiquement dans le projet (Figure 21). De là, on ouvrira le schéma du projet et du nœud pour paramétrer le nœud et la carte mère, en indiquant par exemple que le nœud utilise un DHCP. Notre projet contient à cet instant un Project, un Node et un MotherBoard.



Figure 21. Création du projet Test

Il n'y a pas le profil de carte fille que l'on souhaite et on doit donc crée un nouveau profil de carte fille. Pour cela, on sélectionne « Nouvelle Carte Fille » dans la partie de droite, ce qui ouvrira un nouveau schéma contenant une carte fille, et créera une nouvelle instance de ChilBoardP. On ajoute à ce schéma deux capteurs « Watermark ». En comparant la Figure 22 et la Figure 17, on remarque bien que le schéma du profil correspond bien à la vue interne de la carte fille. Après avoir indiqué où sont localisées les bibliothèques de la carte fille, on nomme ce profil « Carte Watermark » et on sauvegarde dans le fichier « Carte Watermark.chb ». Cela va valider le profil de carte fille et il va alors être intégré dans la liste des profils disponibles.



Figure 22. Création du profil Carte Watermark

Dans le schéma du nœud, on va ajouter une carte fille en sélectionnant le profil que l’on vient de créer. Cela va ajouter un ChildBoard et deux Sensor au projet. On lie ensuite la carte mère et la carte fille ajoutant une communication I²C, ajoutant un Link à la carte fille. Enfin, on sélectionne la carte fille pour la paramétrer. On remarque également ici en comparant la Figure 23 et la Figure 16 que le schéma ressemble bien à la vue interne du nœud.

Figure 23. Configuration de la carte fille



Le nœud est maintenant près à être générer. On enregistre au préalable le projet, puis on utilise le bouton « Générer ». Cela va créer un dossier principal pour le projet contenant les différentes parties du code du nœud dans différents sous-dossiers, tel que les capteurs et les cartes filles. Maintenant que le code est générer il nous faudra passer à la compilation du code.

V.3. Compilation et test du code généré

La compilation et le test du code généré des cartes filles vont être effectués à l’aide de MPLAB, le logiciel de développement de Microchip. On créera un projet, en indiquant le bon microcontrôleur. On pourra ensuite insérer le code source qui a été généré précédemment. De là, on pourra tester le code avec le mode débogage de MPLAB. Cela permettra de vérifier que le code est bien fonctionnel et que les paramètres fournis sont correctes. Malheureusement, je n’ai pas eu le temps de tester le code généré jusqu'à présent. D'ici, la fin de mon stage, un premier test sera effectué pour valider complètement le concept d'interface d'aide à la programmation. Comme on peut le constater, l’interface ne permet pour le moment que de générer le code, et on doit faire appel à un autre programme pour compiler et envoyer le code sur cible. Il serait donc intéressant de pouvoir intégrer ces outils dans l’interface, pour évoluer vers un outil d'aide à la programmation plus complet.



Conclusion L'objectif de mon stage était de réaliser une interface graphique de conception logicielle appliqué aux RCSFs pour faciliter le développement d'applications basées sur les capteurs sans fil LiveNode. L’utilisation d’un framework pour développer un RCP a permis de faciliter le développement de l’interface, bien que j’aie dû faire face à quelques difficultés car je ne connaissais pas le framework. Cela a également permis une certaine flexibilité. Le programme que j’ai réalisé est en fait un plugin. Pour ajouter de nouvelles fonctionnalités, il sera possible de concevoir un nouveau plugin utilisant le mien. L’interface est fonctionnelle, de la création de projet à la génération de code. Il est possible de sauvegarder et de reprendre un projet. Il est également possible de créer des modèles de cartes filles, de capteurs ou de protocoles de communication qui pourront être réutilisés dans d’autres projets. Cependant, seul le code des cartes filles est généré. La génération du code de la carte mère n’a pas pu, faute de temps, être faite. Au niveau des cartes filles, seules les cartes filles actives sont bien gérées, mais il est tout de même possible d’indiquer plusieurs protocoles à une carte fille, en prévision d’un futur support des cartes passives. Je n’ai également pas eu le temps de tester le code généré par l’application sur cible. Au delà du cadre de mon stage, l’interface pourra être améliorée, que ce soit visuellement ou au niveau des fonctionnalités. Comme je l’ai dit plus haut un support des cartes filles passives peut être envisagé. Une quatrième vue, représentant l’intérieur d’une carte mère pourra également être ajoutée afin de pouvoir créer des profils de cartes mères. Une fonctionnalité qui serait également très utile serait la possibilité de compiler et d’envoyer sur les systèmes embarqués le code générer. Cela permettrait à l’interface d’être complète et de ne plus nécessiter un autre logiciel.

Webographie [Vogel Lars] Tutoriels de programmation de Java et Eclipse http://www.vogella.de/ [Eclipse] Tutoriel sur l’utilisation d’Eclipse RCP http://eclipse.org/articles/Article-RCP-1/tutorial1.html [Doudoux JM] Développons en Java, Le développement d’interfaces graphiques avec SWT http://www.jmdoudoux.fr/java/dej/chap-swt.htm [Doudoux JM] Développons en Java, JFace http://www.jmdoudoux.fr/java/dej/chap-jface.htm [Institut d'électronique et d'informatique Gaspard-Monge] Les réseaux de capteurs sans fil http://igm.univ-mlv.fr/~dr/XPOSE2006/Bunel/ [WIKIPEDIA] Encyclopédie libre, http://fr.wikipedia.org/wiki/

Annexes Table des matières Annexe I. Diagramme de classes du package « data » Annexe II. Diagramme de classes du package « io » Annexe III. Diagramme de classes du package « views » Annexe IV. Diagramme de classes du package « editors » Annexe V. Fonction de sauvegarde d’une carte fille dans un fichier de projet Annexe VI. Fonction de génération de la configuration d’un capteur Annexe VII. Fonction déterminant si un élément de l’arborescence a des fils Annexe VIII. Fonction de récupération des fils d’un élément de l’arborescence

Annexe I. Diagramme de classes du package « data »

Annexe II. Diagramme de classes du package « io »

Annexe III. Diagramme de classes du package « views »

Annexe IV. Diagramme de classes du package « editors »

Annexe V. Fonction de sauvegarde d’une carte fille dans un fichier de projet

private void saveChildBoard(ChildBoard childBoard, LineWriter w riter) throws IOException

{ Iterator<Link> itL; Link link; if(childBoard != null) { writer.writeLine(childBoard.getName());

writer.writeLine(Integer. toString(childBoard.getStateValue())); writer.writeLine(Integer. toString(childBoard.getAddress()));

if(childBoard.getForm() != null) writer.writeLine(childBoard.getForm().toString() ); if(childBoard.getProfile() != null) writer.writeLine(childBoard.getProfile().getName ()); itL = childBoard.getLinksIterator(); while(itL.hasNext()) { link = itL.next(); writer.writeLine(link.getName()); writer.writeLine(link.getForm().toString()); } writer.writeLine( "null" ); for(Sensor sensor : childBoard.getSensorList()) { writer.writeLine(sensor.getName()); writer.writeLine(sensor.getProfile().getName()); writer.writeLine(Integer. toString(sensor.getStateValue())); writer.writeLine(Integer. toString(sensor.getFrequency())); writer.writeLine(Integer. toString(sensor.getStatusValue())); writer.writeLine(Integer. toString(sensor.getPowerSupplyPin())); writer.writeLine(Integer. toString(sensor.getTransmissionPin())); writer.writeLine(Integer. toString(sensor.getChannel())); writer.writeLine(Integer. toString(sensor.getChannelTypeValue())); } } }

Annexe VI. Fonction de génération de la configuration d’un capteur

private boolean writeSensorConfig(LineWriter writer, Sensor sensor , int sensorNumber)

{ boolean success = true; if(sensor != null) { try {

writer.writeLine( " cfg[" + sensorNumber + "].state = " + sensor.getState() + ";" );

writer.writeLine( " cfg[" + sensorNumber + "].alim = " + sensor.getPowerSupplyPin() + ";" );

writer.writeLine( " cfg[" + sensorNumber + "].pin = " + sensor.getTransmissionPin() + ";" );

writer.writeLine( " cfg[" + sensorNumber + "].channel = " + sensor.getChannel() + ";" );

writer.writeLine( " cfg[" + sensorNumber + "].channel_type = " + sensor.getChannelType() + ";" );

writer.writeLine( " cfg[" + sensorNumber + "].sensor_cfg.id = " + sensorNumber + ";" );

writer.writeLine( " cfg[" + sensorNumber + "].sensor_cfg.type = " + sensor.getType() + ";" );

writer.writeLine( " cfg[" + sensorNumber + "].sensor_cfg.status = " + sensor.getStatus() + ";" );

writer.writeLine( " cfg[" + sensorNumber + "].sensor_cfg.freq = " + sensor.getFrequency() + ";" );

} catch (IOException e) { success = false; e.printStackTrace(); } } return success; }

Annexe VII. Fonction déterminant si un élément de l’arborescence a des fils

Annexe VIII. Fonction de récupération des fils d’un élément de l’arborescence

public boolean hasChildren(Object element) { boolean hasChildren = false; ChildBoard childBoard; ChildBoardP profile; if(element instanceof Project) { hasChildren = (((Project)element).getNode()!= null); } else if(element instanceof Node) { hasChildren = (((Node)element).getMotherBoard()!= null); } else if(element instanceof MotherBoard) { hasChildren = (((MotherBoard)element).getChildBoa rds(). length > 0); } else if(element instanceof ChildBoard) { childBoard = ((ChildBoard)element);

hasChildren = (childBoard.getProfile()!= null && childBoard.NumberOfLinks() > 0);

} return hasChildren; }

public Object[] getChildren(Object parentElement) { Object[] children = null; if(parentElement instanceof Project) { children = new Object[]{((Project)parentElement).getNode()}; } else if(parentElement instanceof Node) { children = new Object[]{((Node)parentElement).getMotherBoard()}; } else if(parentElement instanceof MotherBoard) { children = ((MotherBoard)parentElement).getChildB oards(); } else if(parentElement instanceof ChildBoard) { children = ((ChildBoard)parentElement).getChildre n(); } return children; }

Etude et développement d'une interface graphique de conception ...

Documents

Transcript of Etude et développement d'une interface graphique de conception ...