Logiciel Libre et Palm

Transcription

1 École Polytechnique de l Université de Nantes PROJET SILR 2 ANNÉE UNIVERSITAIRE 2003/2004 RÉALISÉ AVEC LA COLLABORATION DE : ALSTOM Logiciel Libre et Palm Rapport de Réalisation Présenté par Bao LA DUONG et Quang Khai PHAM le : 4 juin 2004 Jury : Coordinateur : Henri Briand Tuteur Enseignant : Philippe Peter Tuteur Entreprise : Hervé Guérin

2 Contents Introduction 2 1 La plateforme de développement Les IDE Les Emulateurs Les JVM La Base de Données L implémentation Mise en place de la base Optimisation de la base L architecture du Palm Os Les problèmes liées à l architecture Les solutions Limites de la bibliographie L Interface Homme Machine L API interface utilisateur MIDP Le contrôle d affichage MIDP L API haut niveau L API bas niveau Les difficultés et les solutions mises en place Choix de l API Cascade de MIDlets Le package org.ascentphase.suit Limites de la bibliographie Intégration et tests 27 1

3 5 La gestion du projet Le rapport de Pré-Réalisation La plannification de la phase de réalisation Plannification initiale Ré-évaluation du planning Limites du cycle de développement Outils et qualité du développement Relation avec le client Conclusion 44 Annexes 45 Fiches de suivi et copies de mail 45 2

4 Introduction Ce rapport conclut la dernière étape du projet SILR de deuxième année : Logiciel Libre et BD Palm. Rappel : il s agit pour nous de concevoir une application de gestion d idées pour Palm, c est-à-dire un outil permettant de créer graphiquement des objets, de les relier entre eux et d y naviguer. Notre projet en open source sera une interface à une base de données existante, développée par un projet antérieur. L étape de bibliographie nous a permis de cerner et d approfondir les domaines impliqués dans notre projet. La modélisation a été la phase d analyse du problème et l élaboration d une solution. Ces deux étapes ayant été validées, nous nous sommes concentrés sur la dernière phase du cycle de développement du projet : la réalisation. Cette étape permet à partir des deux premières d entrer au coeur même de la partie technique et d implémenter l application. Nous allons tout d abord présenter les outils qui nous ont servi à constituer notre plateforme de développement. Puis nous étudierons en détail d une part l implémentation de la base de données et d autre part celle de l interface homme machine constituant notre application. Nous verrons ensuite les parties intégration et tests du projet et enfin nous terminerons par la gestion mise en oeuvre pour ce projet tout au long des différentes phases. 3

5 1 La plateforme de développement Dans cette partie, nous allons lister et décrire succinctement les outils qui ont permis de mettre en place notre plateforme de développement. 1.1 Les IDE Deux IDE (Integrated Development Environment) ont été utilisés pour ce projet. Ils ont pour particularité de reposer sur la même base. L interface graphique a été développée en utilisant Eclipse. Eclipse est un environnement de développement intégré (IDE) dont le but est de fournir une plate-forme modulaire pour permettre de réaliser des développements informatiques. I.B.M. est à l origine du développement d Eclipse qui est d ailleurs toujours le coeur de son outil Websphere Studio Workbench (WSW) lui même à la base de la famille des derniers outils de développement en java d I.B.M. Tout le code d Eclipse a été donné à la communauté Opensource par I.B.M. Nous avons utilisé la version officielle d Eclipse stable (disponible sur le site officiel : Pour pouvoir développer des applications Java 2 Micro Edition (J2ME), il faut associer à l IDE Eclipse la boîte à outil Wireless Tool Kit (WTK) de Sun qui regroupe un certain nombre d outils. La version mise en place est la La version 2.1 est actuellement disponible mais elle ne permet pas la conception de projets Palm. Pour faciliter le développement, nous avons utilisé le plugin SIPtech qui est un outil d intégration pour Eclipse et pour le WTK. Il permet la création facilitée de projets J2ME ( La base de données a aussi été développée à l aide d Eclipse mais intégrée dans une solution logicielle plus complète, Websphere Studio Device Developer(WSDD) de IBM. En effet, WSDD se base sur l environnement de développement Eclipse mais intègre directement l ensemble des outils nécessaires 4

6 pour pouvoir concevoir, tester et déployer des applications J2ME fonctionnant sur des appareils sans fil tels que les téléphones cellulaires, les assistants personnels et les ordinateurs de poche. 1.2 Les Emulateurs Afin d intégrer et de tester notre application, nous avons utilisé d une part, les émulateurs fournis avec le WTK qui n émulent que des téléphones cellulaires. Un émulateur de téléphone générique est intégré à WSSD et n est adapté qu aux spécifications MIDP. D autre part, nous nous sommes servis de l émulateur gratuit pour Palm, POSE. Ce dernier émule le matériel de différents modèles d assistants personnels de type Palm. Dans la version du WTK, un lien est possible vers cet émulateur. 1.3 Les JVM Les Java Virtual Machine (JVM) pour Palm sont très nombreuses. On pourrait les classer dans trois catégories distinctes. Il y a celles qui ont été développées indépendemment de Sun et qui ne sont pas compatibles avec les spécifications de Sun mais supportent leurs propres packages. Parmi ces JVM, on retrouve waba et superwaba ( Il y a aussi la Kada VM ( mais elle reste introuvable sur internet même si elle est référencée partout ( Ensuite, la catégorie suivante de JVM est destinée à des machines ayant plus de ressources. Ce sont des JVM qui supportent non pas le J2ME mais les versions plus anciennes du J2SE (1.1 à 1.2 voire 1.3). Parmi ces JVM, on retrouve Kaffe et SavaJe XE Operating System. Kaffe que l on retrouve sur est une implémentation incomplète encore du J2SE. SavaJe XE Operating System ( est en fait bien plus qu une JVM. C est un mini-os qui inclut dans son noyau une JVM supportant parfaite- 5

7 ment le J2SE. Il n est pas disponible pour le grand public. Enfin, dans la dernière catégorie, il y a les JVM qui respectent parfaitement la spécification du J2ME de Sun. Parmi celles-ci, nous retrouvons bien sûr KVM qui est la JVM officielle de Sun disponible sur java.sun.com. On retrouve aussi JBed Micro Edition ( Color KVM ( et J9 de IBM intégré dans Websphere Studio Device Developper disponible sur Toutes ces JVM ont leurs spécificités et supportent toutes des sousensembles plus ou moins importants du J2ME ou du J2SE. Donc, pour pouvoir implémenter notre application, nous avons dû faire un choix. Au final, notre attention d est tourné vers deux JVM : KVM de Sun et J9 d IBM. Notre choix s est fait en fonction de la portabilité et des possibilités de déploiement qu offraient ces deux JVM. Le choix du J9 s explique en plus par le fait qu il supporte la Java Native Interface (JNI) que ne fait pas KVM. 6

8 2 La Base de Données 2.1 L implémentation Mise en place de la base Pour pouvoir exploiter un base de données, l idéal est de trouver et d utiliser un SGBDR. Cela permet ainsi de pourvoir faire les requêtes sur la base de données en SQL sans se préoccuper de son implémentation physique. Cependant, sur Palm il n y a pas de SGBDR libre. Les seules SGBDR qui existent d après les recherches menées sont celles de Oracle et de IBM. Cependant, ces dernières sont soit payantes soit limitées dans leur fonctionnalités et leur durée d utilisation. De plus, étant donné que nous utilisons Java pour exploiter la base, le problème est de trouver une base qui soit exploitable avec le jeu d instructions réduit J2ME du J2SE. Au vu de toutes ces contraintes, il nous a fallu mettre en place notre propre système de gestion de base de donnèes. Il nous a aussi fallu implémenter les fonctions de recherche dont nous avions besoin pour générer les écrans d affichage nécessaires. Dans la phase de bibliographie, nous avions fait le choix des outils permettant de générer la base de données pour le Palm. Nous avions choisi d utiliser JPilotDB qui est un projet opensource proposant une interface utilisateur graphique simple d utilisation. Via cette interface il est possible de créer sa base de données puis de l exporter dans différents formats, notamment au format.pdb qui est le standard des données sur Palm. Ainsi, nous avons généré les différents fichiers correspondant à notre base de données. Étant donné que nous n avions pas de SGBDR pour analyser le fichier.pdb sur Palm et d en extraire les données dont nous avions besoin, nous avons étudié à travers de la documentation et à travers des exemples le format exact des fichiers.pdb. Nous avons ensuite écrit un certain nombre de classes Java permettant d extraire octet par octet les informations dont nous avions besoin. Une fois cette phase d analyse opérationnelle, nous avons commencé 7

9 à mettre en place l ensemble des requêtes qui allaient être faites sur la base de données. Cependant, cette étape a été précédée d une autre opération, fondamentale, l optimisation de l accès aux données Optimisation de la base Pour implémenter une requête, le réflexe premier est de traduire directement la requête SQL en succession de méthodes. Ce faisant, nous faisons complètement abstraction de la manière dont la base de données a été implémentée. Dans un SGBDR traditionel comme Oracle, l ensemble des clefs primaires des tables sont indexées par un index en arbre-b+. Cette optimisation est faite directement par le SGBDR et est complètement transparente pour l utilisateur lambda. Dans le cas de notre application nous ne pouvons nous lancer dans la traduction directe d une requête sur la base. Il nous faut d abord étudier les contraintes qui nous sont imposées. En effet, le PDA sensé acceuillir et faire tourner notre application est un Palm Vx avec 8Mo de ram et un processeur fonctionnant à 33MHz. C est une configuration aux possibilités de traitement extrêmement faibles; surtout lorsque l on voit la taille de base en entrée, c est-à-dire une base d environ un millier d entrées avec à peu près autant de notes associées. Lorsque l on fait une recherche, on ne peut se permettre de faire un recherche purement séquentielle. Le contenu de la base est actuellement exactement de 968 entrées. Avec une recherche séquentielle, cela voudrait dire qu en moyenne le système devra parcourir et tester 484 entrées pour trouver celle qui nous intéresse. Sachant que lorsque l utilisateur clique à l écran sur une idée, l ensemble des recherches faites ne se résume pas à un seul élément. Loin de là, la requête faite est souvent composée de recherches simples de ce type mais elle s accompagne aussi de jointures. La jointure étant décomposable en un produit cartésien suivi d une sélection, on voit de suite la lourdeur d une telle opération. L idée a donc été de se dire qu il fallait connaître a priori l emplacement exact de l élement 8

10 cherché et d y accéder directement. Mais là c est une chose quasi-irréalisable. Une autre idée a été de se dire que l on pourrait réduire la taille des éléments sur laquelle la recherche doit être faite. Sans information à priori cela semble aussi peu réalisable. L idée a donc finalement été de se dire qu en combinant le meilleur de ces deux méthodes, il était possible de réduire considérablement l ensemble sur lequel une recherche devait être faite. Avant de présenter la méthode utilisée, il semble intéressant de rappeler comment fait un SGBDR comme Oracle pour optimiser l accès aux données. Ainsi, deux techniques fortement utilisées sous Oracle sont les indexes et les tables de hachage. Un index sur une clé primaire est plaçant, de ce fait l accès à une donnée est extrêmement rapide. À partir d une clef le système va descendre dans la hiérarchie de l arbre- B+ pour atteindre les pages feuilles qui vont pointer sur la page de données correspondant à la clef. L avantage des indexes est indéniablement la vitesse à laquelle la recherche d un élément se fait. L inconvénient est par contre le fait de devoir précalculer l index. Cela peut être très coûteux en temps de calcul sur des tables de grande dimension. En ce qui conçerne les tables de hachage, elles sont toujours associées à une fonction de hachage H. Leur principe d utilisation est très simple. On définit un domaine D dans lequel la fonction H va prendre ses valeurs. On peut prendre par exemple [0..9]. La table de hachage est une table de pointeurs de structures ou de liste de structures. On entend par structure tout type de données construit ou pas. Les indices de la table de hachage vont prendre leurs valeurs dans le domaine D. Pour ajouter une structure à la table, il suffit de lui appliquer la fonction de hachage qui va renvoyer une valeur. Cette valeur indique l indice dans le tableau auquel il faudra ajouter la structure. Maintenant, pour en revenir à la manière dont la base de données sur Palm a été optimisée, nous nous sommes dits que faire en moyenne 484 tests 9

11 pour trouver un entrée était bien trop important. Si seulement, on pouvait diminuer cette valeur à environ 25, cela voudrait dire qu il que l on aura divisé la recherche d environ 40 fois. Or, les clefs de la base de données issue de la synchronisation entre le pc et le palm sont quasiment uniformément réparties entre 0 et le nombre d éléments de la base. En partitionant cet ensemble de clefs en 4 tables de hachages de 10 pointeurs chacunes, on arrive à diviser le temps de recherche moyen d environ 40 fois. On a atteint l objectif que l on s est donné. On pourrait bien sûr dire que ce que l on peut faire avec quatre tables de hachages, on pourrait très bien le faire avec 5 ou 6 et donc diviser encore plus le temps de recherche. Il faut rappeler que nous apportons ici une solution adaptée au problème qui se pose. Notre objectif n est pas de faire quelque chose de joli sur le plan théorique mais de répondre à un besoin précis de l utilisateur. De plus, cette optimisation est faite à la main. Il faut donc coder en dur la gestion de toutes ces tables, même si cela est relativement facile à faire, cela reste une technique limitée. Cependant, si en cours de simulation cela n était pas suffisant nous ajouterions bien sûr d autres tables ou utiliserions d autres techniques pour améliorer les performances. La mise en place d un tel stratagème n est bien sûr pas sans défauts. En effet, nous partons d une table et dispatchons les tuples à travers les différentes tables, dans différentes listes. Du coup, nous perdons l information de la disposition des tuples dans la table. Certes, cette information n est pas très utile en soit dans le cadre d opérations algébriques. Elle ne l est que dans le cas où on s intéresse aux tuples suivants et/ou précédants un autre tuple. Dans ce cas, il a fallu trouver un stratagème pour retrouver cette information ou une partie de l information pour la reconstituer. Nous avons alors mis en place un pseudo-index sur le numéro du tuple. C est en fait un tableau de clefs dont l indice est la position du tuple dans la table d origine et dont la clef vaut : clef = valeurdeclef * 10 + tableaud Appartenance. En utilisant ce stratagème, on peut retrouver très facilement le tuple situé à une position 10

12 i donnée. En effectuant (clef mod 10), on retrouve la table dans laquelle se trouve le tuple, puis en appliquant la fonction de hachage sur (clef div 10) on retrouve la liste de tuple à laquelle il appartient. Il faut certes effectuer une recherche, mais avec l optimisation introduite précédemment, elle reste courte. Nous avons donc commencé par optimiser l accès aux données. Cela n est cependant pas suffisant pour optimiser complètement les traitements sur la base de données. Nous avons bien sûr aussi optimisé le plan d exécution des requêtes faites sur la base de données, notamment celles effectuant des jointures, pour réduire au minimum les ensembles sur lequels les opérations les plus lourdes sont faites, c est-à-dire les produits cartésiens. Maintenant que nous avons présenté les optimisations faites sur la base de données, nous allons pouvoir présenter les difficultés rencontrées lors de sa mise en place. 2.2 L architecture du Palm Os Les problèmes liées à l architecture Avant de pouvoir faire une quelconque opération sur la base de données, la première chose à faire est de la charger en mémoire centrale. Pour cela, la démarche est de charger le ou les fichiers contenant la base de données avec le SGBDR, le format d une base de données étant complètement lié au SGBDR qui l a générée. Dans le cadre du développement sur le Palm, comme nous l avons mentionné plus tôt, il n existe pas de SGBDR. Cela est le premier obstacle que l on rencontre. En effet, en l absence d un SGBDR, il nous faut faire le travail d analyse du fichier en entrée à sa place. Les fichiers représentant les bases de données pour Palm ont heureusement une spécification standardisée. Nous avons donc dû mettre en place un certain nombre de fonctionnalités permettant de traiter les fichiers des différentes tables de notre base suivant la 11

13 nature de ces dernières. La deuxième difficulté que l on a rencontré est le fait de devoir charger le ou les fichiers de la base de données en mémoire. Il n existe pas sous Palm OS de système de fichiers à proprement parlé. Le seul moyen de stocker des données est de les synchroniser avec le Palm; les fichiers sont alors stockés sur le Palm, dans la mémoire ram/rom/flash sous la forme d un simple tableau d octets. Ces tableaux sont communément appelés databases et sont gérés par un Database Manager. Ils n ont, à s y tromper, aucun lien avec les bases de données au sens relationnel du terme. Ce sont plutôt des bases d octets. Lorsque dans l application nous essayons d accéder à nos fichiers via leur nom logique, le Palm OS nous renvoit des erreurs. Il existe cependant une autre méthode pour stocker les données de manière persistante sur le Palm via une application écrite en Java. Cela est permis par l utilisation de la classe RMS offerte par MIDP. C est une classe qui map en partie le fonctionnement et l accès aux données résiduelles dans la mémoire ram/rom/flash du Palm. Cependant, dans le cadre de notre développement, nous ne pouvons utiliser cette technique. En effet, la différence de notre application avec une autre qui utiliserait les RMS est le fait que ce n est pas notre application qui, lors de son fonctionnement, créerait et remplirait la base de données. Dans le cadre de notre utilisation, nous devons accéder à une base qui aura été synchronisée auparavant par l utilisateur. Nous ne faisons que demander un point d accès dessus. Le problème conçernant l analyse des fichiers contenant la base étant rapidement réglé grâce à la spécification complète de ces derniers, nos efforts se sont alors concentrés sur la résolution de la problématique du chargement de ces derniers. 12

14 2.2.2 Les solutions L idée pour trouver la solution d un problème est de comprendre quels sont les facteurs qui l ont engendré. Dans notre cas, c est le format de stockage des données qui fait obstacle. Cependant, il existe sur Palm moultes applications utilisant une base de données et/ou stockant les données de manière permanente. Il doit donc forcément exister un moyen d accéder à ces données, cela est indéniable. Nous nous sommes donc replongés dans toutes les documentations que nous avons pu trouver jusqu alors sur le système Palm OS pour savoir ce qui était mis en oeuvre. Nous avons alors trouvé que l ensemble des applications présentes sur le Palm étaient codées en C voire C++. En fait, le système d exploitation est complètement codé en C et propose aux développeur tout un ensemble d API permettant de faire appel aux fonctionnalités les plus bas niveau. Il existe en Java une méthode pour intégrer du code provenant d un autre langage dans les classes Java. C est l utilisation de la Java Native Interface. C est une interface permettant d utiliser des fonctionnalités bas niveau proposées par un système d exploitation. En général, l utilisation des JNI est complètement liée à la Machine Virtuelle. Comme nous l avons rappelé au début du rapport, il existe de très nombreuses machines virtuelles différentes disponibles pour Palm. Cependant, très peu d entre elles supportent le JNI. En fait, les seules JVM supportant le JNI sont KJava de Sun et J9 développé par IBM. Il en existe une autre mais ne pouvons envisager de l utiliser; il s agit de SavaJe Xe de Mochaworks. En effet, cette dernière JVM est bien plus qu une JVM. Elle est à elle seule un mini-système offrant bien plus de fonctionnalités qu une simple JVM. La solution à envisager est donc d utiliser soit KJava, soit J9. Là encore le choix est rapidement fait. En effet, KJava est une machine virtuelle que Sun a mis au point en Depuis, Sun ne supporte plus KJava mais préconise plutôt l utilisation de KVM qu il intègre au package contenant la librairie 13

15 MIDP. De plus, KJava était dans une version beta voir même alpha dont l utilisation n était absolument pas assurée. Ainsi, nous avons fait le choix d utiliser la machine virtuelle d IBM, J9 qui est intégré dans l environnement de développement (IDE) Websphere Studio Device Developper 5.6. Cependant, là aussi il y a des contraintes sur l utilisation de cette JVM. En effet, J9 ne supporte que les systèmes d exploitation Palm OS supérieurs à la version 3.5. Par expérience, nous avons pu montrer qu en fait J9 ne supporte Palm OS qu à partir de la version 5.0. L important a donc été d informer correctement notre client et de lui expliquer les contraintes d ordre matériel et architecturales du système d exploitation. Fort heureusement, il a très bien compris notre situation et a la possibilité de changer son Palm pour une version plus récente. Au travers des difficultés rencontrées et des solutions que nous avons envisagées jusqu à présent, nous avons pu mettre en évidence les limites de notre étude bibliographique effectuée en début de projet. 2.3 Limites de la bibliographie Lors de la phase de bibliographie, nous avons orienté notre recherche vers l existant et les outils dont nous allions nous servir pour la réalisation. Ainsi nous avions présenté Palm OS, JPilotDB et J2ME. Nous avions présenté leurs spécifications générales et les fonctionnalités offertes qui allaient nous être utiles. Nous mettons ici en évidence certaines limites de notre étude bibliographique. En effet, dans la phase de bibliographie, nous ne nous sommes pas plongés dans la spécification détaillée de Palm OS. Nous n avions alors pas vu qu il ne supportait pas de système de fichiers. Nous avions plutôt présenté les possibilités graphiques de J2ME et plus précisément du MIDP. Étant donné que nous savions que J2ME supportait Palm Os et étant donné aussi qu il y avait une JVM pour J2ME, nous ne nous sommes pas posé la question de savoir quelles fonctionnalités supportaient cette JVM. 14

16 Nous avions fait là une grosse erreur d appréciation. Certes, J2ME supporte l utilisation des fichiers lorsqu il est utilisé sur certaines plateformes (téléphones mobiles, certains PDA,...) mais porté sur Palm cela n est plus vrai. L erreur commise a donc été de ne pas avoir poussé la recherche et l étude des spécifications détaillées de Palm OS et des limites d utilisation du MIDP porté sur Palm. Ceci a donc complètement altéré notre évaluation de la complexité et de la faisabilité du projet, au vu des moyens disponibles à ce moment là. Cependant, il nous semble, avec plus de recul, qu il n était pas réellement possible non plus de prévoir le moindre de ces détails d implémentation, même si l idéal est de tendre dans cette direction. Certains de ces détails ne sont visibles qu au moment où le besoin s en fait sentir c est-à-dire en pleine implémentation. 15

17 3 L Interface Homme Machine Notre application fournit à l utilisateur un certain nombre d informations provenant de la base de données. Ces données doivent apparaître de manière claire et précise afin de répondre aux mieux aux attentes de l utilisateur. L interface homme machine joue donc un rôle essentiel dans la restitution des informations et doit permettre une navigation intuitive et ergonomique dans les différentes fenêtres composant l application. Nous allons dans cette partie étudier l implémentation de la couche supérieure de notre logiciel, les difficultés rencontrées et les différences par rapport à ce qui avait été annoncé lors de la phase de bibliographie. 3.1 L API interface utilisateur MIDP Comme nous l avions décrit dans la première étape de notre projet, nous avons choisi un développement basé sur l API du MIDP. Pour rappel, ce profil a été créé pour permettre le développement d applications sur des machines aux ressources et à l interface limitée tels que les téléphones portables ou bien les assistants personnels de type Palm. L API GUI MIDP est entièrement contenu dans le package javax.microedition.lcdui. De plus, l interface utilisateur est décomposée en deux niveaux d API : haute et basse. Nous allons dans un premier temps présenter le système d affichage MIDP puis nous étudierons les API haut niveau et bas niveau Le contrôle d affichage MIDP Avant l affichage de composants graphiques (Widgets), nous avons besoin d accéder à l affichage de l écran. En MIDP, le système d affichage est accessible via un gestionnaire appelé objet Display. Cet objet gère l écran du système ou l affichage. Il prend aussi en compte les périphériques d entrée système. Il n y a qu un seul objet Display pour chaque MIDlet. Il fournit des méthodes pour dessiner et afficher les éléments de l interface graphique 16

18 utilisateur sur l écran, en fonction de l API utilisée (haut ou bas niveau). L instance Display offre aussi des méthodes permettant de récupérer les propriétés de l affichage de l appareil pour savoir s il supporte la couleur ou bien quel objet est actuellement affiché sur le système. Objets Displayable Il n est pas possible d ajouter des éléments graphiques directement à l affichage. De ce fait, tous les objets de l interface graphique devant être affichés à l écran doivent être contenus dans un objet de type Displayable. Displayable est une classe abstraite à partir de laquelle toutes les classes de l interface graphique héritent. Screen ainsi que toutes ses sous-classes, sont des classes d affichage de l API haut-niveau. Alternativement, Canvas est utilisée en tant que classe Displayable pour l API bas-niveau. Seulement un objet Displayable peut être affiché à la fois. L objet Displayable qui est affiché est appelé le Displayable courant. L objet Displayable permet les accès à l objet Displayable courant via deux méthodes complémentaires qui sont : getcurrent() et setcurrent(displayable nextdisplayable). Nous allons maintenant présenter les APIs haut niveau et bas niveau L API haut niveau Cette API possède un haut niveau d abstraction et fournit toute une série d éléments graphiques (Widgets) prédéfinis qui peuvent être ajoutés ou bien utilisés pour l affichage. Avec cette API de haut niveau, le système, et non l application, gère la mise en place des composants, le défilement, la navigation et les caractéristiques visuelles telles que couleur, forme, police et l affichage des éléments sur l écran. Ainsi, elle offre peu de contrôle sur l apparence visuelle. De plus, l application n est pas informée des interac- 17

19 tions entre les composants. L implémentation fournit l adaptation nécessaire au terminal. L avantage de cette API est d assurer un haut niveau de portabilité. Screen est la super classe pour tous les objets GUI Displayable de l interface haut niveau. Elle fournit des sous-classes avec un titre optionnel qui peut être affiché tout en haut de la zone d affichage. L interface graphique utilisateur haut-niveau MIDP possède deux types de sous-classes Screen qui peuvent être utilisés pour afficher les composants graphiques. Le premier type encapsule complètement les composants de l interface utilisateur et a une structure prédéfinie pour afficher l information à l utilisateur. La plupart des composants Screen ne permettent pas à l application d ajouter ou d enlever d autres composants de l interface utilisateur. List, TextBox et Alert sont des sous-classes de Screen qui entrent dans cette catégorie. Le deuxième type de Screen permet aux applications d ajouter ou de supprimer d autres éléments graphiques de l affichage. Ce second type est représenté par la sous-classe Form de Screen. Une Form permet aux développeurs de créer des affichages arbitraires d éléments graphiques spécifiques appelés des items. Ainsi, les Forms n encapsulent pas complètement leurs éléments comme les autres sous-classes de Screen L API bas niveau Alternativement, dans l API bas niveau, l application a beaucoup plus de contrôle sur l affichage. Cette API a été développée pour des applications telles que les jeux où le contrôle précis et le placement des éléments graphique est requis. Cette API renferme une série de méthodes de dessin permettant d élaborer l affichage, forme par forme, si nécessaire, et de les afficher à l écran. À cette API est aussi associé un mécanisme de gestion d évènements bas 18

20 niveau. Les applications utilisant cette API à faible niveau d abstraction ne seront pas facilement portables sur une autre plateforme étant donné que l application peut avoir accès à des ressources systèmes pouvant ne pas être disponibles sur tous les autres appareils. Par exemple, une application écrite pour afficher des pixels dans une résolution précise pourra ne pas être adaptée pour d autres applications ayant des affichages différents. Cependant, pour garder un minimum de portabilité, l API bas niveau fournit un certain nombre de méthodes très pratiques pour vérifier la disponibilité des ressources non portables. Par exemple, l application pourra vérifier la taille disponible de l écran avant d afficher des pixels en dehors de l affichage disponible. Les classes Canvas et Graphics implémentent cette API. Canvas Contrairement à l API bas-niveau, il n y a qu une seule sous-classe Displayable à utiliser lors de la création d interfaces graphiques utilisateurs bas-niveau. Il s agit de la classe Canvas. Cependant, la classe Canvas est abstraite et requiert des objets qui vont l implémenter. les formes géométriques en deux dimensions et/ou le texte sont affichés dans un objet Canvas à travers un mécanisme de dessin appelé un objet Graphics. Une instance d une sousclasse Canvas est passée à un objet Graphics via l appel par le système de la méthode paint(graphics g) d un canvas. Chaque sous-classe Canvas doit implémenter cette méthode abstraite, et c est seulement pendant l execution de la méthode paint(graphics g) que les applications peuvent dessiner des graphiques bas-niveau sur l affichage. Cependant, l application n invoquera jamais la méthode paint(graphics g) directement. Ce travail est laissé au système. Le rafraîchissement de l affichage est fait automatiquement pour tous les objets Screen dans l API haut-niveau alors que les instances des sousclasses Canvas sont chargées de leur propre rafraîchissement. La demande de rafraîchissement est faite en appelant la méthode Canvas repaint(), qui 19

21 éventuellement appellera la méthode paint (Graphics g) fournie par la super-classe Canvas. Le rafraîchissement d un canvas est un évènement asynchrone, donc plusieurs appels à la méthode repaint() peuvent être effectués avant que la méthode paint(graphics g) ne soit déclenchée. Cela permet de rafraîchir de manière optimale l affichage, ce qui est très important pour les applications telles que les jeux. Pour plus d optimisation, l application peut ne demander que le rafraîchissement d une partie de l affichage en utilisant la méthode repaint(int x, int y, int width, int height) qui cible le rafraîchissement sur une zone spécifique de l affichage. Graphics Une instance de la classe Graphics se charge de toute la partie dessin de l API GUI bas-niveau. Elle offre un certain nombre de méthodes de dessin pour l affichage de caractères ou de chaînes de caractères, d images, de rectangles droits, de rectangles aux bords arrondis et d arcs. Les rectangles, aux bords arrondis et les arcs peuvent être remplis ou non. L objet Graphics ne doit pas être déclarée, mais une nouvelle instance de cet objet est créée et passée à un objet Canvas via la méthode paint(graphics g). Cela permet aux graphiques d être affichés directement lorsque la méthode paint(graphics g) est invoquée par le système. Toute opération de dessin effectue du remplacement de pixel. En d autres termes, toute opération de dessin spécifiée dans l objet Graphics qui définit une valeur de pixel, remplace la précédente. Il n est pas possible de combiner ou de mélanger les valeurs de pixel comme c est le cas dans des systèmes plus sophistiqués de dessin. L objet Graphics supporte la couleur 24 bits. Les composantes de couleur rouge, verte et bleue sont chacunes codées sur 8 bits. Cependant, tous les appareils ne supportent pas le 24 bits. Dans ce cas, le système va tenter 20

22 de faire correspondre au mieux les couleurs disponibles aux couleurs requises par l application. La classe Display fournit des méthodes pour obtenir les caractéristiques de l appareil telles que le support de la couleur qui peuvent être utilisées par l application pour offrir des affichages plus agréables qui ne seront pas gâchés par la correspondance automatique des couleurs. Cela permet aussi à l application de rester portable et de ne pas dépendre des caractéristiques d une architecture spécifique. Toutes les méthodes de dessin de l objet Graphics utilisent un système de coordonnées. Le système par défaut définit le coin supérieur gauche comme étant la coordonnée (0,0) de l affichage de l appareil. Le système de coordonnées représente en fait la position entre chaque pixel. Par exemple, les coordonnées suivantes bornent le pixel situé en haut à gauche de l affichage: (0,0), (1,0), (0,1), (1,1). Chaque incrémentation des coordonnées X et Y représente un déplacement du pixel sur l affichage. La coordonnée X effectue un déplacement positif vers la gauche et la coordonnée Y permet un déplacement positif vers le bas de l affichage. Les applications ne sont pas autorisées à définir les pixels en tant que carrés. En d autres termes, les distances horizontales et verticales dans le système de coordonnées sont égales. Les opérations de dessin déclenchées par les objets Graphics sont faites par un stylo d un pixel de large qui remplit le pixel immédiatement en dessous et à droite de la coordonnée spécifiée, incluant les deux points de fin. Le dessin de texte utilise un point d ancre pour minimiser le calcul requis pour placer du texte sur l affichage. Lorsque l on dessine une chaîne ou un caractère, l application doit spécifier à la fois les coordonnées du point d ancre (x,y) et une constante horizontale et verticale pour positionner la chaîne sur l écran. Une constante horizontale (LEFT, HCENTER, RIGHT) est combinée avec une verticale constante (TOP, BASELINE, BOTTOM) en une opération logique OR. Ces constantes fournissent la direction vers laquelle la chaîne de caractère doit être affichée, à partir du point d ancre 21

23 (x,y). Il faut noter que seule la méthode paint(graphics g) doit être implémentée. A l intérieur de cette méthode, des commandes graphiques spécifiques sont susceptibles d afficher du texte ou des formes. Cependant, c est l appareil qui contrôlera quand cette méthode sera appelée. A l intérieur de la MIDlet, tout ce que l on aura à faire sera de créer l objet Canvas et de l associer à l objet courant Displayable. Fonts Un Font est utilisé par l API bas-niveau pour définir la police de n importe quel texte affiché à l écran. L application n a pas le contrôle de la police lorsque l API haut-niveau est utilisée. Contrairement à des systèmes plus élaborés, les polices ne peuvent pas être créées par l application. L application ne peut seulement utiliser que des polices basées sur un ensemble d attributs prédéfinis. Les polices ont des attributs gérant le style, la taille, la forme à l aide de constantes statiques symboliques qui représentent les possibilités de chaque attribut. Le système va tenter de fournir une police qui correspond au mieux aux attributs demandés mais ce n est pas garanti. Le système peut n avoir qu un petit sous-ensemble de polices disponibles. Une instance Font est obtenue en appelant la méthode static getfont(int face, int style, int size) de la classe Font. Un objet Graphics utilise alors l objet Font pour associer la police courante à toutes les chaînes de caractères ou caractères individuels. La méthode setfont(font font) est utilisée sur une instance de Graphics pour définir la police courante. 22

24 3.2 Les difficultés et les solutions mises en place Choix de l API La première difficulté que nous avons rencontrée en commençant le développement de l interface a été le choix de l API GUI. En effet, l un de nos objectifs principaux est une portabilité maximale de l application quelque soit la plateforme ou bien le système d exploitation (d où le choix du langage java). Nous nous sommes donc logiquement tournés dans un premier temps vers l API haut niveau. Nous avons donc commencé l implémentation dans l optique de laisser le système gérer la mise en place des composants graphiques de l interface ainsi que les événements. Mais nous nous sommes rapidement retrouvés coincés car cette API est très limitée et n offre que très peu de possibilités au niveau des Widgets. Par exemple, dans le cadre du projet, si on veut respecter le storyboard, il faut que les objets matérialisant les idées soient cliquables et se comportent comme des boutons c est-à-dire qu en cliquant dessus, un événement est envoyé (rafraîchissement de la fenêtre avec l idée sélectionnée centrée au milieu de l écran). Or, l API haut niveau ne permet pas de définir des objets et leur comportement, seul un certain nombre de composants prédéfinis peuvent être insérer dans une fenêtre (des champs de texte, des listes de label, des fenêtres d alerte, etc.). Il a donc fallu reconsidérer notre choix et nous orienter vers l API bas niveau qui nous a permis plus de liberté et répondait davantage à nos besoins. La principale difficulté de cette API est qu il faut avoir dans un premier temps une approche graphique de l interface. En effet, il n existe aucun élément prédéfini, de ce fait, il faut complètement dessiner l interface et tous les composants en utilisant les méthodes de dessins de la classe Graphics. L exemple le plus parlant est celui de l implémentation d un simple bouton. Il faut tout d abord dessiner le bouton en traçant un cadre à l aide de la méthode drawline() puis on insère le texte du bouton grâce à la méthode 23

25 drawstring(). Il est ensuite intéressant de définir les différents états du bouton, lorsqu il est déselectionné, lorsque l on clique dessus et lorsque l on relâche le clic. On a donc besoin de dessiner chacun de ces états séparément et d associer un comportement lié au clic de l utilisateur qui déclenchera l affichage approprié. Cet exemple illustre l un des nombreux cas rencontrés au cours de la phase de réalisation où nous avons été obligés de concevoir (graphisme et comportement) chacun des éléments de l interface en fonction de nos besoins Cascade de MIDlets Un autre problème auquel nous avons été confronté, a été la communication entre des fenêtres de type assez spécifique au fonctionnement élaboré. Prenons l exemple de la fenêtre principale : elle affiche des idées de la base à l utilisateur. L utilisateur navigue dans la liste d idées en cliquant dessus pour les recentrer mais pour le moment, il ne reste que dans la même fenêtre donc la classe qui va implémenter la fenêtre principale va s appeler elle-même. Elle a un état particulier à un instant t. A présent, l utilisateur désire effectuer une recherche. Il clique sur le bouton de recherche qui va appeler la fenêtre de recherche, effectue un certain nombre d opérations puis lorsqu il a fini, veut retourner à la page principale à l état où il l avait laissé à l instant t. Etant donné que le nombre d appels à différentes fenêtres est plutôt important, on ne peut pas se permettre pour des raisons de performances de passer en paramètres toutes les variables et les différents états des fenêtres. C est pourquoi, pour résoudre ce problème, nous avons mis en place des cascades de MIDlets. Ainsi pour les fenêtres devant être réutilisées, nous avons décidé de les implémenter en tant que MIDlets et de ce fait de déclarer des instances de ces classes dans les classes appelantes. Le principal avantage de cette implémentation est de pouvoir mettre en pause une MIDlet, d en appeler une autre et de reprendre la précédente ultérieurement. 24

26 Pour rappel, une MIDlet doit implémenter trois méthodes abstraites et protégées spécifiées par MIDlet. Ainsi, les applications doivent réécrire destroyapp(boolean unconditionnal), startapp() et pauseapp(). Les MIDlets peuvent exister sous trois états : active, en pause et détruite. Ces trois méthodes abstraites permettent à l application de travailler sur les transitions entre ces états. Quand une MIDlet est démarrée en appelant startapp(), la MIDlet entre dans l état actif. Dans cet état, une MIDlet peut utiliser toutes les ressources disponibles. Lorsqu elle est en pause, une MI- Dlet doit libérer toutes les ressources et devenir inactive. Une MIDlet se met en pause grâce à l appel à la méthode pauseapp(). Une application MIDlet peut aller et revenir de l état actif à l état de pause. A partir de l état actif ou en pause, la MIDlet peut entrer dans l état détruit en invoquant la méthode destroyapp(boolean unconditional). Une fois dans l état détruit, une MIDlet ne peut revenir ni à l état actif ni à l état de pause. Toutes les ressources doivent être libérées et les données persistantes sauvegardées. Les classes implémentant la fenêtre principale, la fenêtre d idées zoomées, la fenêtre restreinte et la fenêtre de postit ont été définies en tant que MIDlet. 3.3 Le package org.ascentphase.suit Comme nous l avons vu précédemment, l API bas-niveau est assez difficile à appréhender et il faut avoir une vue graphique de l application. C est pourquoi, en effectuant quelques recherches sur la communauté Open Source ( nous sommes tombés sur une librairie fournissant des classes d objets graphiques prédéfinis utilisant l API bas-niveau. Ainsi, ce package fournit des composants de base telles que des boutons, des entêtes de fenêtre, des labels, etc. Toutes ces classes héritent de la classe abstraite Widget qui définit la zone graphique du composant et intègre la gestion des évènements utilisateurs (un clic de l utilisateur sur la zone d affichage 25

27 par exemple). Pour implémenter une fenêtre, il faut créer une classe qui hérite de la classe Panel. Cette classe hérite de la super-classe Widget citée précédemment. Un objet Panel définit un objet Displayable qui pourra être associé à l affichage. Pour ajouter les composants dans le Panel, il suffira d utiliser la méthode add(widget w, int x, int y) qui insère un objet de type widget aux coordonnées x et y de l écran. Nous avons donc réécrits certaines classes de cette librairie pour les adapter à nos besoins afin de rester le plus fidèle possible au storyboard. Les classes suivantes ont été utilisées : Widget : classe abstraite pour tous les composants graphiques Panel : un conteneur permettant d afficher un ou plusieurs composants Widgets Button : un composant bouton qui déclenche un évènement lorsque l utilisateur clique dessus Field : un champ qui affiche du texte sur un nombre de ligne Label : une simple chaîne de caractères TitleBar : un widget qui dessine un titre à la fenêtre 3.4 Limites de la bibliographie Nous avons cité dans la partie 2.3, les faiblesses de notre étude bibliographique liées aux spécifications de l architecture du système. Dans cette partie, nous allons voir les manques que nous avons eu vis à vis de l interface homme machine. Comme nous l avons vu précédemment dans l étude des API disponibles pour l implémentation de l interface graphique, au premier abord, lors de la phase de bibliographie, il nous a paru naturel de nous orienter vers l API haut-niveau puisque celle-ci offre des classes qui vont laisser le système se 26

28 charger de la mise en forme graphique, ce qui permet une forte portabilité. Or, ce n est qu en nous plongeant dans le développement de l application que nous nous sommes rendu compte des limites de l API haut-niveau. C est en faisant des recherches supplémentaires et en analysant nos besoins que nous nous sommes rendus compte que l API bas-niveau était celle qui nous correspondait le mieux. Il convient de citer un autre problème que nous avons eu mais cette fois-ci plus en rapport avec la plate-forme de développement et des outils utilisés. Il concerne l usage du Wireless Tool Kit. En effet, dans la phase de bibliographie, nous avions retenu le WTK 2.1 en tant qu ensemble d outils J2ME permettant de développer pour du matériel portable tel que téléphones ou bien PDA. Il nous a donc paru logique d utiliser cette dernière version en date sans trop nous poser de questions. Or, c est en attaquant la phase de réalisation que nous nous sommes rendu compte que cette version n était pas adaptée car elle ne prenait pas en charge le développement pour Palm. C est en effectuant des recherches plus approfondies que nous avons découvert qu il fallait repasser à une version plus ancienne, la WTK 1.0 afin de pouvoir créer des applications pour Palm et profiter de son émulateur. Nous avons donc allié un peu de bibliographie à la réalisation afin de nous réorienter. Maintenant que nous avons vu comment nous avons développé en parallèle la partie BD et l IHM, nous allons présenter la manière dont nous avons effectué nos tests et la manière dont nous avons fusionné ces deux parties. 27

29 4 Intégration et tests Étant donné que nous avons développé en parallèle les parties BD et IHM, les tests se sont faits en deux parties. En effet, nous avons tout d abord effectué des tests unitaires tout au long de l implémentation indépendante de ces deux parties. L idée était de tester et de s assurer du bon fonctionnement de l ensemble des fonctions écrites. Nous avons essayé de ramener les risques de bugs, de malfonctionnement et de cas d utilisation pouvant produire des résultats non souhaités le plus proche de zéro possible. Donc, une fois le code écrit, nous avons passé beaucoup de temps à faire des tests sur des jeux d essais les plus vastes possibles. Pour la base de données, nous avons généré des bases de test cohérentes et avons essayé de faire toutes les requêtes susceptibles d être faites par l application. Cependant, ces bases ne nous ont pas semblé suffisamment représentatives du cas réel d utilisation. Les bases de test que nous avons générées ne contenaient qu une dizaine de tuples. Cela ne nous donnait pas assez de renseignements sur la vitesse d execution des requêtes. En règle général, lorsque l on multiple par 10 le volume de traitements à faire, on multiple par 100 le temps d exécution. Ainsi, nous nous sommes demandés quel pouvait être le temps que mettrait une requête sur une base d un millier d entrées. De ce fait, nous avons demandé au groupe de projet s occupant de la sychronisation de nous fournir les bases réelles de M. GUÉRIN. Ce faisant, nous avons pu voir où et quand il était nécessaire de faire des optimisations. Pour l interface graphique utilisateur, étant donné que nous n avions pas encore fait les liens avec la base données, nous en avons fait abstraction et avons fait des liens directs entre les différentes fenêtres. Cela était suffisant pour identifier d éventuels problèmes et de voir si nous arrivions à faire défiler les fenêtres comme nous le voulions, en pointant sur les bons bouttons. Une fois ces tests individuels et indépendants validés, nous avons com- 28

30 mencé à faire les liens entre la base de données et les différents contrôleurs de l interface graphique. Nous avons continué l ensemble des tests sur les différents émulateurs dont nous disposions pour nous assurer d une portabilité optimale de l application. Une fois que nous avions pu produire des parties de l application qui marchaient correctement sur nos émulateurs, pour finaliser les tests de ces modules, nous les avons essayés directement sur un Palm. Maintenant que nous avons exposé la manière dont nous avons codé notre application, nous allons prendre un peu de recul. Nous allons voir comment cette phase de réalisation a été menée d un point de vue plus global. 29

31 5 La gestion du projet 5.1 Le rapport de Pré-Réalisation À la fin de la soutenance de la phase de modélisation, notre client nous avait demandé de modifier et d ajouter un certain nombre de fonctionnalités notamment de recherche et d affichage. Nous lui avons donc demandé un temps de réflexion, pour pouvoir étudier la faisabilité et évaluer le poids des changements à faire sur notre modélisation. Nous avons ainsi élaboré un nouveau storyboard représentant les fenêtres à afficher en plus de celles déjà définies. 30