RAPPORT DE PROJET - Portfolio de Romain...

20
Hiver 2010 RAPPORT DE PROJET Mise en place d’une application de gestion d’articles du quotidien. Maître de Projet : M. ROY Patrice Etudiants : M. LOUVET Romain M. LEBLANC Louis Université de Sherbrooke Faculté des Sciences Département Informatique

Transcript of RAPPORT DE PROJET - Portfolio de Romain...

Hiver 2010

RAPPORT DE PROJET Mise en place d’une application de gestion d’articles du quotidien.

Maître de Projet : M. ROY Patrice Etudiants : M. LOUVET Romain

M. LEBLANC Louis

Université de Sherbrooke

Faculté des Sciences

Département Informatique

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

2

REMERCIEMENTS

Nous tenons à remercier Patrice ROY, pour nous avoir encadrés durant notre projet en répondant à nos diverses questions, ainsi que Bessam Abdulrazak pour ses idées apportées au sujet.

Nous tenons aussi à remercier Mario PAQUET qui nous a permis d’obtenir tout le matériel nécessaire au bon déroulement de notre projet (local, ordinateurs, serveurs, Pocket PC…).

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

3

Sommaire

INTRODUCTION ....................................................................................................................................... 4

1. Présentation .................................................................................................................................... 5

1.1. Le sujet .................................................................................................................................... 5

1.2. Les objectifs ............................................................................................................................. 5

2. Conception ...................................................................................................................................... 5

2.1. Pocket PC ................................................................................................................................. 7

2.2. Partie métier ............................................................................................................................ 8

2.3. Interface Cliente ...................................................................................................................... 9

2.3.1. Apparence ....................................................................................................................... 9

2.3.2. Patrons de Conception .................................................................................................. 10

2.3.3. Description des principales classes ............................................................................... 11

2.3.4. Composants supplémentaires ....................................................................................... 13

3. Répartition du travail..................................................................................................................... 14

4. Phases de la programmation ......................................................................................................... 14

4.1. Pocket PC et Windows Mobile .............................................................................................. 14

4.2. Interface Client ...................................................................................................................... 16

4.3. Application Web .................................................................................................................... 16

5. Problèmes rencontrés ................................................................................................................... 16

5.1. Lecture du code-barre ........................................................................................................... 16

5.2. L’interface Cliente ................................................................................................................. 17

5.3. Mise à jour des données ....................................................................................................... 17

6. Améliorations possibles................................................................................................................. 17

CONCLUSION ......................................................................................................................................... 18

ANNEXES ................................................................................................................................................ 19

Guide d’installation Java ................................................................................................................... 19

Guide d’installation Pocket PC .......................................................................................................... 20

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

4

INTRODUCTION

Actuellement en Baccalauréat Informatique, notre matière Projet d’informatique (IFT592) nous permet de réaliser un projet.

Notre souhait été de travailler avec un Pocket Pc et de lier différentes technologies web en correspondance avec du Java. Nous avons recherché un sujet dans lequel nous pourrions retrouver tous ces éléments.

Après diverses réflexions nous avons choisi un thème permettant d’apporter de l’aide à des personnes en difficulté. Pour trouver les détails du sujet sur lequel nous voulions travailler nous nous sommes inspirés du laboratoire DOMUS, sans toutefois avoir la prétention de faire l’équivalent.

La présentation d’une première ébauche à Bessam Abdulrazak a été très concluante puisque nous avons pu faire ressortir de nouvelles idées qui allaient compléter notre projet.

Notre présent rapport s’articulera autour de trois axes principaux qui sont l’explication en détails de notre projet ; les différentes phases de la programmation et enfin les différentes améliorations possibles suivit d’une conclusion.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

5

1. Présentation

1.1. Le sujet Le but de notre application est d’aider une personne en difficulté dans la réalisation de ses

tâches quotidiennes. Nous avons choisi d’aider une personne qui souhaiterait acheter des produits alimentaires. Pour réaliser sa tache cette personne aura besoin d’une liste de course. Cette liste de course doit être générée automatiquement ou rédigée par une personne de confiance.

Cette personne fait ses commissions et scanne les codes barres des produits qu’elle achète à l’aide de l’appareil photo du Pocket PC. Sa liste de course est alors mise à jour en fonction de ses scannes, ce qui lui permet de savoir les articles restant à acheter. Quand elle rentre chez elle, la personne voit sur son écran les produits qu’elle a achetés et sait ou les ranger puisque l’application lui dit ou les placer.

Cette personne ayant des difficultés dans ses tâches quotidiennes, il est important qu’un responsable surveille ses activités. Une interface est alors disponible depuis le web via un site internet pour gérer les différentes applications.

1.2. Les objectifs Construire un système d'aide et de suivi de gestion de produits à travers la saisie d'article

incluant la reconnaissance de code barre. Proposer de l'information via une intelligence de rangement d'article. Prendre en charge la saisie de ces articles via un appareil mobile et en traiter les informations avec un serveur. Développer une application logicielle capable de reprendre le tout grâce à une interface utilisateur. Développer une application web pouvant gérer le système à distance.

Un des objectifs principal a été de réaliser une application la plus « maniable » possible, en séparant les principales fonctions. Pour satisfaire ce besoin, nous avons utilisé plusieurs langages ainsi que plusieurs types de serveurs. L’utilisateur doit avoir accès aux principales fonctions de base. Toutes les données de l’application doivent être traitables, traitées et préservées. L’application doit être réactive, et les modifications doivent s’afficher dans tous les modules des différentes applications.

Les objectifs de ce projet sont de réaliser une interface permettant de saisir les produits achetés à l’aide d’un Pocket PC et d’avoir une interface cliente dans laquelle nous retrouverions toutes les informations de l’application.

2. Conception Dans le but d’avoir une meilleure vision des différentes entités du projet, nous avons réalisé un

diagramme regroupant les différentes applications utilisées. Un client est relié à une base de données. Les bases de données peuvent être de types différents (MySQL, PgSql, ObjectStore, …). Elles sont reliées à un serveur de service web ainsi qu’à un serveur de backup. Chaque base de données du côté client est reliée au serveur de l’administrateur qui de ce fait, peut surveiller tous les clients.

Les clients saisissent leurs produits à l’aide de Pocket PC reliés à leurs serveurs.

Figure 01 – Schéma explicatif des différentes applications

2.1. Pocket PC Il existe deux modes possibles pour la partie Pocket PC : Mode Connecté et non Connecté. Nous

avons considéré ces deux modes car à l’heure actuelle, tous les centres d’achats ne proposent pas d’accès à internet via des bornes Wifi. Le type de mode se met directement à jour avec un test de connexion sur le Pocket PC.

Dans le mode Connecté, dès que l’on va prendre en photo le code barre d’un produit, celui-ci va directement être envoyé par FTP sur notre serveur distant. Après cet envoi, nous allons faire appel à un serveur ASP.NET qui va analyser notre image et retourner le code correspondant s’il a réussi à décrypter le code-barre de l’image. Ensuite, nous allons envoyer au Service Web Tomcat les différentes informations du produit (code-barre, nom, date de péremption, …) qui seront ensuite inscrites dans la base de données.

Figure 02- Schéma Mode Connecté

Dans le mode non connecté, toutes nos informations vont être stockées via des fichiers XML. Notre serveur FTP va être remplacé par notre dossier d’images qui se situe directement sur le Pocket PC. Dès que l’on aura accès à internet, il suffira d’appuyer sur le bouton « synchroniser » de l’application pour envoyer toutes nos informations sur les serveurs.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

8

Figure 03- Schéma Mode Non Connecté

2.2. Partie métier La partie métier représente la librairie utilisée par le service web Axis, permettant de traiter les

données du Pocket PC et d’attribuer à chaque produit, un rangement particulier. Elle permet également de traiter les données XML échangées du Pocket PC au service Web et vice versa. Elle notifie le « serveur » du client pour ajouter d’un nouveau produit. Le diagramme suivant reprend de façon très simplifié cette explication.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

9

Figure 04 - Diagramme Métier

2.3. Interface Cliente

2.3.1. Apparence L’IHM est composée de 3 grandes parties :

Fil d’Ariane + choix de la langue Navigation dans l’application Panel d’information permettant la saisie des différents champs

La navigation se fait « par colonne » (inspirée notamment de l’explorateur MAC OS X). Cette façon de concevoir l’IHM permet à l’utilisateur d’avoir une meilleure « vision » de ses différentes saisies. Cela lui permet de passer d’un rangement à un autre très rapidement. Le « retour en arrière » est lui aussi très simple et très réactif. L’application ne devant pas être une « plaie » à utiliser, nous avons souhaité quelque chose d’efficient.

L’interface permet entre autres à l’utilisateur de cliquer sur un compartiment et d’afficher toute la liste des produits. Il peut rechercher un article rapidement en saisissant au clavier le nom de l’article. Et les articles s’affichent au fur et à mesure que l’utilisateur tape sa recherche illustrée par le cadre rouge de la figure 05.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

10

L’utilisation d’un fil d’Ariane permet à l’utilisateur de savoir où il se situe dans la navigation de l’interface. Ceci est illustré dans la figure 05 à l’aide du cadre bleu.

Un module d’information lui permet également d’apporter des modifications aux différentes entités de l’application. Ceci est illustré dans la figure 05 à l’aide du cadre vert.

Figure 05- Fonction recherche de l’interface cliente

2.3.2. Patrons de Conception Dans l'implémentation de l’interface, nous avons utilisé les patrons de conception Singleton,

Observer (avec le Modele Vue Controleur), ainsi que le décorateur (réutilisation des composants) pour RechercheListModel qui décore un ListModel et qui offre les fonctionnalités pour la recherche. -Le singleton utile uniquement pour avoir une instanciation de classe particulière.

Nous avons également utilisé le patron de conception Builder qui nous permet de faire abstraction de l'étape de construction d'objet de manière à construire différentes représentations de ces objets. Nous créons nos objets complexes à partir d'un objet source cela nous permet d’obtenir un ensemble d'objet grâce à un ensemble d'appels à l'interface commune de la classe abstraite Builder.

Pour créer nos frigos et étagères nous avons utilisé un patron de conception largement utilisé dans le MVC, le Factory Method. On a une interface qui définit des classes et on laisse les autres sous classes décidées lesquelles instanciées. Permet de créer des objets dynamiquement en fonction des paramètres passés. De ce fait on les manipule de manière transparente.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

11

2.3.3. Description des principales classes Tout d'abord, nous avons le contrôleur primaire qui va gérer tous les contrôleurs

secondaires. Ce contrôleur primaire agit sur les vues principales comme le fil d'Ariane, la navigation en colonne, etc...

Le contrôleur secondaire agit sur son model propre comme par exemple un article. La classe vue colonne model est un observateur du model ce qui lui permet de mettre à jour toutes ses informations lorsqu'on sélectionne un modèle dans une colonne.

Le contrôleur primaire s'occupe également de charger les panels pour les modifications d’information. Les classes dans le package modele.liste permettent de manipuler tous les modèles sous forme de collection et il y a aussi des classes comme ListeModeleListModel qui permettent de faire « le pont » entre notre représentation et celle de swing.

Voici un diagramme permettant de synthétiser les classes.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

12

Figure 06 - Conception de l’interface cliente

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

13

2.3.4. Composants supplémentaires

Utilisation de la librairie JCalendar

Nous avons utilisé cette librairie pour permettre à l’utilisateur de choisir une date graphiquement, et ainsi lui permettre un meilleur confort d’utilisation de l’application en se rappelant le jour de telle ou telle date. L’utilisation de cette API va aussi permettre de prendre une date dans un format donné. Cela va donc limiter les erreurs de format de date dans notre application. Cette API dispose d’une JavaDoc bien documentée située sur : http://www.toedter.com/en/jcalendar/api/com/toedter/calendar/package-summary.html

Figure 07 - Utilisation JCalendar

Internationalisation

Pour gérer le multi langage nous avons rédigé un fichier properties dans lequel nous avons référencé tous les String de notre application avec leur traduction en anglais. Pour appeler les données enregistrées dans ce fichier, nous avons programmé une classe I18n. Cette classe permet d’initialiser la traduction en chargeant le bon fichier properties. Pour rendre l’utilisation de cette classe plus évidente, nous en avons fait un singleton. Pour appeler tous les String de notre application, il suffit alors d’appeler une méthode que nous avons nommée _. Cette méthode prend en paramètre la clé du String à afficher et en fonction de la langue chargée la méthode renvoie le String correspondant.

Figure 08 - Barre de langue

Popup

Quand un utilisateur ajoute des produits via le Pocket PC, ils les retrouvent lorsqu’ il rentre chez lui à l’aide d’un popup qui s’affiche à chaque ajout d’un article.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

14

Figure 09 – Affichage d’un popup

3. Répartition du travail Notre projet étant composé en 2 parties très distinctes, cela correspondait parfaitement à notre

équipe. Nous nous sommes réparti le travail en vertu des connaissances et des envies de chacun. L’un de nous 2 a travaillé sur la partie Java (Service Web et interface client) et l’autre s’est focalisé sur le Pocket PC et Service Web ASP.NET. Comme nos taches étaient dépendantes les unes des autres, il était important que chacun réalise son travail dans un temps imparti pour ne pas pénaliser l’autre qui attendait les résultats de sa réalisation.

4. Phases de la programmation

4.1. Pocket PC et Windows Mobile Toute la partie du Pocket PC a été codée en C#.NET. Pour ce type d’appareil, c’est le Compact

Framework qui est utilisé. C’est un sous ensemble du .NET Framework. Il y a aussi des librairies en plus dans le compact Framework que l’on a utilisé comme la gestion de l’appareil photo ainsi que la gestion de la téléphonie. Notre application a été développée pour les Pocket PC avec l’OS Windows Mobile 6.0 d’installé.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

15

Figure 10- Page d’accueil

Figure 11 – Ecran 2 avec liste de course

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

16

Figure 12- Page de saisie d’informations sur le produit

4.2. Interface Client Toute la partie cliente a été réalisée en Java après avoir implémenté le service web nécessaire à

la récupération des données du Pocket PC. Nous avons ensuite développé la partie interface en tant que telle sans se soucier des données que nous allions récupérer. La dernière phase a été de créer un service web entre la partie métier s’occupant de récupérer les articles et l’interface devant être notifiée. Il a donc fallut faire de l’interface cliente, un serveur proposant un service web.

4.3. Application Web La dernière phase du projet a été de développer l’application de l’administrateur en Servlet/JSP

utilisant les librairies que nous avions développé pour la partie métier et pour l’interface cliente. Cette application permet à l’administrateur d’avoir un suivi détaillé des opérations effectuées par l’interface cliente produisant des logs. L’application permet de se connecter à plusieurs bases de données en chargeant le driver correspondant lors de la connexion au client.

5. Problèmes rencontrés

5.1. Lecture du code-barre Notre premier problème rencontré fut la reconnaissance de code barre. Ce problème est survenu

avec l’appareil photo du Pocket PC qui dispose d’un focus qui n’est pas assez élevé. Dès que l’on prend une photo d’un code barre trop petit avec le Pocket PC, l’image est floue et notre service web est incapable de décrypter cette image. Pour résoudre ce problème, nous avons testé plusieurs algorithmes pour essayer de déflouter cette image pour la rendre plus exploitable par notre service

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

17

web. Toutes ces techniques n’ont pas fonctionné, ceci dit, notre application est capable de reconnaitre un code barre sur une feuille blanche de 8x4cm (comme le jour de notre présentation).

5.2. L’interface Cliente Comme nous voulions réaliser une interface se basant sur le Finder de Mac OS, il a été difficile de

faire un équivalent puisque nous avions que de petites expériences en programmation d’interface Java. Mais nos différentes recherches et lecture de documents ont permis de résoudre ce problème.

5.3. Mise à jour des données Nous avons du réfléchir longuement à la façon dont nous allions mettre à jour les données des

différents modules. Les différents tests et la mise en place finale de la structure ont été longues à mettre en place.

6. Améliorations possibles En fonction du temps qui nous était imparti, il semble évident que nous n’avons pas pu

réaliser tous les objectifs que nous nous étions fixés. Nous avons fait le choix de développer certains modules de façon rapide et non évolutive. Par exemple, nous aurions aimé réaliser une base de données propre au Pocket PC sans être obligé de passer par des fichiers XML. Tout d’abord, nous aurions aimé ajouter un module qui permettrait au client de générer des recettes en fonction des produits présents dans ces différents rangements.

Nous aurions également apprécié de développer un module pour le Pocket PC qui permettrait au client d’afficher la liste des produits à acheter en fonction des rayons du magasin. De cette manière, le client se serait rendu d’un point à un autre du magasin sans faire d’aller retour.

Pour que l’application soit plus évolutive, nous aurions aimé développer des fichiers properties reprenant l’ensemble de nos constantes, ce qui aurait été plus « refactorisable » comme nous l’avons fait dans l’internationalisation dans l’interface.

L’utilisation de mots de passe cryptés et non en « clair » pour l’ajout de produit dans notre web service.

Nous aurions souhaité faire une interface encore plus précise avec plus d’options accessibles.

La saisie de code barre aurait été plus judicieuse avec un lecteur de code barre en option du Pocket PC. Ce qui est encore tout a fait possible car seule l’application du Pocket PC aurait besoin d’être modifiée.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

18

CONCLUSION

Ce projet est à notre gout une réussite, nous sommes fière de nos 9431 lignes de code. Nos principaux objectifs ont été atteints. Nous avons réussi à utiliser de manière efficace l’interopérabilité de plusieurs langages ainsi que l’utilisation de plusieurs serveurs et périphériques.

Nous avons fait preuve d’une patience et d’une camaraderie qui ont été des atouts dans l’élaboration de notre projet. La répartition du travail et la présence de chacun à toutes les réunions ont permis un développement dans de très bonnes conditions.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

19

ANNEXES

Guide d’installation Java

Vérifier que JAVA est bien installé avec la version JAVA 1.6

1. Service Web JAVA (Serveur)

- Installer Apache Tomcat : Version 6.0.26 Server

- Copier le dossier XX dans « C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps »

- Installer Apache Axis : Version 1.4

- Déployer le service web

1. Copier le jar XX dans « C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\axis\WEB-INF\lib »

2. Ouvrir un terminal et se placer dans « C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\axis »

3. Exécuter ensuite la commande : java org.apache.axis.client.AdminClient deploy.wsdd pour déployer vos services

2. IHM (Client)

- Lancer le fichier .jar.

RAPPORT DE PROJET

Hiver 2010

Mise en place d’une application de gestion d’articles

20

Guide d’installation Pocket PC

1. Service Web .NET (Serveur)

- Installer Serveur FTP : ici TypSoft FTP Server Version 1.11

- Créer un dossier partagé nommé « Image_upload » (dossier qui va contenir toutes les images envoyées par le PocketPC)

- Créer un utilisateur FTP : user : projet / pass : France

- Installer IIS : Version 6.0

- Installer ASP.NET : Verison 2.0.50727

- Copier les dossiers Source .NET\WebServiceCodeBarre dans « C:\Inetpub\wwwroot » pour déployer le Service Web de reconnaissance de code barre

2. Pocket PC

- Lancer Source .NET\PocketPC\Projet_IFT592.sln dans Visual Studio (Projet avec Windows Mobile 6)

- Changer l’adresse IP du serveur FTP dans la classe FTPClient.cs à la ligne 38.

- Créer un dossier dans le PocketPC (à la racine de celui-ci) nommé « bdd_projet_ift592 »

- Mettre à jour les adresses des WebReferences (WebServiceAchat et WabServiceCodeBarre) dans Visual Studio

- Si toutes ces étapes ont été réalisées alors, vous pouvez déployer l’application sur le PocketPC avec Visual Studio.