Conception et développement d'une application Client/Serveur Android/Tomcat pour la gestion des...
description
Transcript of Conception et développement d'une application Client/Serveur Android/Tomcat pour la gestion des...
Cycle de formation des ingénieurs en Télécommunications
Option :
Wireless Networks and Communications (WINCOM)
Rapport de Projet de fin d’études
Thème :
Conception et développement d'une application Client/Serveur Android/Tomcat
pour la gestion des projets
Réalisé par :
Wafa KHROUF
Encadrants :
Mme Malek BEN YOUSSEF M. Aymen ELLOUZE
Travail proposé et réalisé en collaboration avec
Année universitaire : 2013/2014
Dédicaces
A mon très cher père Habib,
A ma très chère mère Nabila,
Nulle Expression ne peut témoigner mes sentiments d’amour, de respects et de
gratitudes.
Je vous dois tout mon succès et mon bonheur.
Merci pour votre amour, vos efforts, vos sacrifices et vos prières.
J’espère du fond du cœur être digne de vous et sujet de fierté à vos yeux en espérant ne
jamais vous décevoir et être toujours à la hauteur de vos espérances.
Que ce travail soit le fruit de vos efforts, l’expression de mon amour et de ma gratitude.
Je vous suis éternellement reconnaissante.
Que Dieu vous protège et vous procure du bonheur et de la santé.
A mon très cher frère Mohamed Ridha & sa femme Basma,
A ma très chère sœur Raafa & son mari Moez,
A ma très chère soeur Mouna & son mari Ayman,
Qu’ils trouvent ici le témoignage de mon respect et de mon amour.
Que Dieu vous protège et vous donne la plus belle vie.
A toutes mes chères amies,
Merci pour votre aide et votre gentillesse.
A tous ceux que j’ai omis de citer, l’oubli du nom n’est pas celui du cœur,
Je dédie ce travail.
i
Résumé
Ce travail, effectué au sein de Telnet, s’inscrit dans le cadre du projet de fin d’études
en vue de l’obtention du diplôme d’ingénieur en télécommunications. Il consiste à mettre
en place une solution mobile Android pour la gestion des projets.
En effet, Telnet propose une solution Web appelée ALM (Application Lifecycle Mana-
gement) qui a pour but de gérer les cycles de vie des projets élaborés au sein de l’entreprise.
Cette solution Web, malgré son importance et son efficacité, n’est pas suffisante pour sa-
tisfaire les besoins de ces utilisateurs du fait qu’on ne peut y accéder qu’à travers un
ordinateur.
Dans ce cadre, notre projet a pour but de créer une solution mobile Android qui va
servir pour client de la solution Web utilisé à Telnet, et ceci afin de faciliter l’accès aux
fonctionnalités usuelles d’ALM.
Mots clés : Solution mobile, Android, Gestion des projets et ALM.
ii
Remerciements
Je tiens à exprimer mon respect et mes remerciements à mon encadrant à Telnet
Monsieur Aymen ELLOUZE pour son accueil, son assistance et ses conseils pertinents
tout au long de la période de mon projet.
Je tiens aussi à remercier mon encadrante de Sup’Com Madame Malek BEN
YOUSSEF pour ses conseils, son support et la grande patience qu’elle m’a accordée
durant la réalisation de mon travail.
Ma gratitude et mes remerciements les plus sincères sont adressés à mes parents pour
leur patience et leur soutien continus.
Je remercie par ailleurs toute personne qui, de près ou de loin, m’a aidée pour bien
accomplir ce travail et le mener à ses fins.
iii
Table des matières
Résumé ii
Introduction générale 1
1 Étude Préalable 2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Présentation du cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . 2
1.1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2.2 Critiques de l’existant et solution proposée . . . . . . . . . 3
1.1.2.3 Méthodologie adaptée . . . . . . . . . . . . . . . . . . . . 4
1.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Gestion du Cycle de vie des Applications (ALM) . . . . . . . . . . 5
1.2.2 Plateforme Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2.1 Présentation de la plateforme . . . . . . . . . . . . . . . . 6
1.2.2.2 Architecture d’Android . . . . . . . . . . . . . . . . . . . 7
1.2.2.3 Avantages de la plateforme Android . . . . . . . . . . . . . 8
1.2.3 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.3.1 Web service de type SOAP . . . . . . . . . . . . . . . . . 9
1.2.3.2 Web service de type REST . . . . . . . . . . . . . . . . . 9
1.2.3.3 Solution retenue . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.4 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.4.1 Couche DAO . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.4.2 Couche Service . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.5 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
iv
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Spécification des besoins et Conception 13
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . 14
2.1.1.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . 15
2.1.2 Spécifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2.1 Présentation des acteurs . . . . . . . . . . . . . . . . . . . 16
2.1.2.2 Diagrammes des cas d’utilisation . . . . . . . . . . . . . . 16
2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . 20
2.2.2.2 Diagramme d’activités . . . . . . . . . . . . . . . . . . . . 24
2.2.2.3 Diagrammes de séquences . . . . . . . . . . . . . . . . . . 26
2.2.3 Conception de la base de données . . . . . . . . . . . . . . . . . . . 28
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Réalisation 32
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Présentation de l’environnement de travail . . . . . . . . . . . . . . . . . . 32
3.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2.2 SDK Android . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2.3 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2.4 pgAdmin III . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2.5 Photoshop CC . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2.6 PowerAMC . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Interfaces Homme Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . 36
v
3.2.2 Interface de la liste des projets . . . . . . . . . . . . . . . . . . . . . 37
3.2.3 Interface présentant le contenu du projet sélectionné . . . . . . . . . 39
3.2.4 Interface d’ajout de projet . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.5 Interface d’ajout d’élément de travail . . . . . . . . . . . . . . . . . 45
3.2.6 Interface d’ajout de commentaire à un élément de travail . . . . . . 48
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Conclusion générale et Perspectives 50
Bibliographie 51
Nétographie 52
vi
Table des figures
1.1 Architecture 3 tiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Architecture du système d’exploitation Android[N3]. . . . . . . . . . . . . 8
2.1 Diagramme des cas d’utilisation global. . . . . . . . . . . . . . . . . . . . . 17
2.2 Diagramme du cas d’utilisation « Gérer les éléments de travail ». . . . . . . 19
2.3 Le modèles MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Diagramme des classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Diagramme d’activités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Diagrammes de séquences du scénario « S’authentifier ». . . . . . . . . . . 27
2.7 Diagrammes de séquences du scénario « Afficher la liste des projets ». . . . 28
2.8 Modèle conceptuel de données. . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Lancement du serveur Tomcat. . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 ProgressDialog de l’interface d’authentification. . . . . . . . . . . . . . . . 36
3.3 Interface d’authentification. . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 ProgressDialog de l’interface de la liste des projets. . . . . . . . . . . . . . 38
3.5 Interface de la liste des projets. . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Interface des détails du projet. . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Interface de la liste des Work Items. . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Détails de l’élément de travail "ALM-1". . . . . . . . . . . . . . . . . . . . 41
3.9 Interface d’ajout de projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.10 Menu déroulant correspondant à "Customer". . . . . . . . . . . . . . . . . . 42
3.11 Date Picker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.12 Enregistrement du nouveau projet. . . . . . . . . . . . . . . . . . . . . . . 44
3.13 Liste des projets contenant le nouveau projet. . . . . . . . . . . . . . . . . 44
3.14 Détails du nouveau projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
vii
3.15 Interface d’ajout d’élément de travail (1). . . . . . . . . . . . . . . . . . . . 46
3.16 Interface d’ajout d’élément de travail (2). . . . . . . . . . . . . . . . . . . . 46
3.17 Listes des éléments de travail contenant l’élément ajouté. . . . . . . . . . . 47
3.18 Détails du nouveau élément de travail. . . . . . . . . . . . . . . . . . . . . 47
3.19 Interface d’ajout de commentaire à un élément de travail. . . . . . . . . . . 48
3.20 Vérification de l’ajout du nouveau commentaire. . . . . . . . . . . . . . . . 49
viii
Liste des tableaux
2.1 Présentation des acteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Tableau descriptif du cas d’utilisation « S’authentifier ». . . . . . . . . . . 18
3.1 Logiciels utilisés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ix
Liste des abréviations
ADT : Android Development Tools
ALM : Application Lifecycle Management
API : Application Programming Interface
DAO : Data Access Object
HQL : Hibernate Query Language
HTTP : HyperText Transfer Protocol
IDE : Integrated Development Environment
IHM : Interface homme machine
JDBC : Java DataBase Connectivity
JSON : JavaScript Object Notation
MCD : Modèle Conceptuel de Données
ODBC : Open DataBase Connectivity
ORM : Object Relational Mapping
REST : Representational State Transfer
SDK : Software Development Toolkit
SGBD : Système de Gestion de Base de Données
SGBDR : Système de Gestion de Base de Données Relationnelles
SOAP : Simple Object Acces
SQL : Structured Query Language
UML : Unified Modeling Language
URI : Uniform Ressources Identifier
W3C : World Wide Web Consortium
XML : Extensible Markup Language
x
Introduction générale
Le nombre de solutions logicielles en gestion de projet augmente considérablement ces
dernières années vu leurs utilités indéniables. Dans ce cadre, Telnet adopte un solution
Web ALM qui répond à ce besoin. Toutefois, cette solution, malgré son importance et
son efficacité, manque d’ergonomie car elle n’est accessible qu’à travers un ordinateur. De
plus, vu le développement spectaculaire des applications de technologies de l’information
et des communications, on a cerné la nécessité d’une application mobile rendant possible
l’accès aux fonctionnalités usuelles d’ALM (tels que la consultation des projets et des
tâches correspondantes à effectuer) via un appareil mobile.
C’est au sein de ce contexte que se situe le sujet de notre projet de fin d’études effectué
à Telnet Sfax. Il consiste en fait à concevoir et à développer cette solution mobile.
Pour décrire ce travail, notre rapport est organisé en trois chapitres qui reflètent la
démarche utilisée dans notre projet.
Dans le premier chapitre, on va mettre le projet dans son cadre, puis, on va présenter
l’état de l’art afin de définir les concepts liés à ce projet sur le plan théorique.
Dans le deuxième chapitre, on va analyser et spécifier, dans sa première partie, les
besoins fonctionnels et non fonctionnels et on va présenter les différents cas d’utilisation
qui y sont associés. On va ensuite consacrer sa deuxième partie à la phase de la conception.
En effet, on va présenter l’architecture de l’application ainsi qu’une description détaillée
des diagrammes de classes, d’activités et de séquences.
Finalement, on va aborder dans le dernier chapitre l’environnement technique de ce
travail, ainsi que les outils utilisés. Par la suite, on va présenter les principales interfaces
graphiques réalisées et on va analyser les différents résultats obtenus.
1
Chapitre 1
Étude Préalable
Introduction
Dans ce chapitre, on va mettre le projet dans son cadre général. Au début, on va
présenter l’entreprise d’accueil et l’objectif de notre projet. Ensuite, on va faire une étude
sur les technologies et les concepts sur lesquels se base notre projet.
1.1 Présentation du cadre du projet
1.1.1 Présentation de l’organisme d’accueil
Telnet est un groupe tunisien de sociétés de services, d’ingénierie et de conseil dans
l’innovation et les hautes technologies.
Crée en 1994, Telnet est rapidement devenu leader dans son cœur de métier à l’échelle
national. Telnet a cherché depuis sa création à élargir ses champs de compétences afin
de proposer à ses clients des prestations de qualité diversifiées selon les spécifications
demandées. Dans un souci de proximité de ses clients, Telnet opère selon un modèle Front
office / Back office, elle propose essentiellement des prestations d’ingénierie en Offshore
et en Nearshore pour le compte des plus grands groupes internationaux.
Telnet est considérée comme un acteur majeur dans le domaine des hautes technolo-
gies et occupe un positionnement de plus en plus important à l’échelle régional.
Telnet développe une expertise métier notamment dans le développement de Sys-
tèmes Intégrés, le design Électronique et Micro-électronique ainsi que dans l’ingénierie
Mécanique.
2
Le groupe Telnet propose un éventail de compétences considérable. Il œuvre dans les
secteurs d’activité suivants :
• Télécommunications & Multimédia ;
• Transport & Automotive ;
• Défense & Avionique ;
• Sécurité & Carte à puce ;
• Industrie ;
• Systèmes d’information.
Telnet dispose d’un centre de développement qui a été certifié CMMi niveau 5 en
2006 et ISO 9001 version 2008, ce qui lui permet de garantir la sécurité, la confidentialité
et la propriété intellectuelle de ses prestations.
1.1.2 Présentation du sujet
1.1.2.1 Étude de l’existant
ALM est une application utilisée par Telnet. Elle assure la gestion des projets, l’affec-
tation des ressources et l’élaboration des plannings et le suivi des projets.
L’application ALM existante à Telnet est une solution Web. Donc, il n’est possible d’y
accéder qu’à partir du navigateur d’un ordinateur puissant.
1.1.2.2 Critiques de l’existant et solution proposée
La solution Web d’ALM n’est pas suffisante pour satisfaire aux besoins de ces utilisa-
teurs. En fait, elle n’est pas très pratique, surtout qu’on a parfois besoin d’y accéder pour
faire des tâches simples ou même pour donner des commentaires.
C’est pour cela qu’on a pensé à développer une application mobile conviviale qui assure
l’accès et la manipulation de différentes fonctionnalités fournis par l’application ALM.
Citons l’exemple d’un développeur qui accède à son compte sur cette application et
passe pour voir les nouvelles tâches qui lui sont affectées. En les lisant, il découvre qu’il a
besoin d’une simple clarification de l’une de ces tâches. Il écrit donc sa question comme
un "work item" (élément de travail). Mais, il s’avère que le chef du projet est en congés,
donc il devra travailler à l’aveuglette jusqu’au retour de celui-là. Par contre, si le chef de
projet possède cette application sur son téléphone mobile, il va tout simplement répondre
3
à la question de cet employé sans perdre beaucoup de temps (pour ne pas être dérangé
pendant son congés).
On peut remarquer de cet exemple que cette application mobile peut encourager les
employés et surtout les chefs des projets de se rassurer du bon déroulement de leurs projets
même pendant leurs vacances, ce qui est important pour le bien de l’entreprise.
1.1.2.3 Méthodologie adaptée
Pour réaliser notre projet, on a adopté l’architecture 3 tiers pour ses différents avan-
tages. D’abord, elle permet aux données d’être gérées d’une façon centralisée. Elle permet
aussi de séparer les 3 couches habituelles d’une application : IHM, traitements et don-
nées[N1].
Notre application sera donc composée de 3 couches indépendantes :
. Couche présentation qui correspond à l’application Android.
. Couche traitements qui est composée de la couche service et la couche web service.
. Couche d’accès aux données qui est composée de la couche DAO et la base de
données.
La figure 1.1 présente l’architecture de l’application ainsi que les relations entre les
différentes couches qu’on a citées et qu’on va détaillées dans la partie suivante.
La séparation entre les couches a pour but de rendre indépendante chacune des couches
afin de simplifier la maintenance et les évolutions futures de l’application (par exemple,
changement de système de base de données, portage d’un environnement graphique à un
autre, ...). Elle assure une sécurité plus importante car l’accès à la base de données n’est
autorisé que par la couche traitements.
4
Hibernate
Application Android
Web Service
Service
DAO
Base de données
Figure 1.1 – Architecture 3 tiers.
1.2 État de l’art
Dans cette partie, on va commencer par définir d’une façon détaillée la solution ALM
utilisée par Telnet pour la gestion des projets. Ensuite on va étudier la plateforme Android
tout en justifiant le choix de celle-ci dans le développement de notre application mobile.
Puis, on fera une comparaison entre les technologies de services web pour en choisir la
meilleure. Enfin, on va définir Hibernate (voir figure 1.1).
1.2.1 Gestion du Cycle de vie des Applications (ALM)
La Gestion du cycle de vie des Applications (ou ALM pour Application Lifecycle
Management) est la gestion coordonnée du cycle de développement d’une application
5
logicielle de son idée initiale à sa livraison et sa maintenance impliquant tous les acteurs
participant au projet, tout en appliquant les processus propres à l’entreprise[N2].
ALM fournit des outils pour l’équipe d’ingénieurs pour la gestion du développement
logiciel (Software Development Lifecycle) et des outils adaptés pour les autres personnes
impliquées dans le projet.
ALM concerne toutes les entreprises de tous les secteurs car en réalité leurs besoins sont
similaires. En effet, l’innovation logicielle est devenue un facteur clef de compétitivité pour
les entreprises. La bonne gestion de leur portefeuille de projets prend une place capitale
pour ces entreprises dites « High-Tech ».
L’objectif général de l’ALM est d’améliorer la gestion des projets logiciels et de leurs
développements. De plus, ALM permet de :
. Industrialiser les développements ;
. Améliorer la qualité des livrables ;
. Obtenir la traçabilité des changements ;
. Suivre en temps réel l’avancement des projets ;
. Réduire les coûts et respecter les délais ;
. Améliorer la productivité ;
. Gérer les risques ;
. Faciliter la collaboration et la communication entre les membres.
1.2.2 Plateforme Android
On a choisi Android comme plateforme d’implémentation de l’application mobile.
Donc, on donnera dans cette partie un aperçu sur cette plateforme, puis, on présentera
ses atouts.
1.2.2.1 Présentation de la plateforme
Android est un système d’exploitation Open Source destiné à tourner sur des termi-
naux mobiles, promu par Google et l’Open Handset Alliance qui comprend plus de 35
constructeurs, fournisseurs de logiciel, et opérateurs. Il concurrence des plateformes telles
que l’iOS d’Apple, Windows Mobile de Microsoft, RIM OS intégré dans les BlackBerry
de Research In Motion, WebOS d’HP Bada de Samsung, ou encore Symbian et MeeGo
de Nokia.
6
Exploiter une nouvelle plateforme n’est pas toujours aussi évident. C’est pourquoi
Google fournit, en plus du système d’exploitation, un kit de développement (Software
Development Toolkit ou SDK). Ce dernier est un ensemble d’outils qui permet aux dé-
veloppeurs et aux entreprises de créer des applications Android[1]. Le SDK Android est
composé de plusieurs éléments pour aider les développeurs à créer et à maintenir leurs
applications (des API (interfaces de programmation), des exemples de code, de la do-
cumentation, des outils (parmi lesquels un émulateur)) permettant de concevoir et de
développer des applications assez complexes, basées sur le langage Java et destinées à
tourner sur des terminaux équipés de l’OS Android.
1.2.2.2 Architecture d’Android
Pour bien comprendre la plateforme Android, on va expliquer l’architecture du système
Android.
Les composants majeurs de la plateforme Android sont résumés dans la figure 1.2.
En tant que système d’exploitation, Android est composé de cinq couches :
• Le noyau : C’est une couche de bas niveau, basée sur un noyau Linux, qui assure la
communication entre la couche logicielle et le matériel.
• Des bibliothèques : Il s’agit d’un ensemble de bibliothèques, en C/C++, qui offrent
des fonctionnalités de base qui peuvent être utilisées par les différents composants
du système d’exploitation Android, ainsi que par les programmes développés avec
le kit offert et déployés sur ce système.
• L’environnement d’exécution des applications Android dont la machine virtuelle
Dalvik est le composant principal. Cette machine virtuelle a été conçue spécialement
pour des environnements qui ont des contraintes liées aux ressources assez limitées
(Mémoire, CPU, Batterie, ...). Pour chaque nouveau programme qui doit s’exécuter
sur Android une nouvelle instance de la machine virtuelle Dalvik sera créée.
• Un framework qui regroupe un ensemble d’applications et d’APIs écrites en Java,
qui représente toujours la couche qui est en dessous de toute application développée
et déployée sur la plateforme Android.
• Un ensemble d’applications très utiles pour l’utilisateur final du système, parmi
lesquelles on trouvera un calendrier, un programme qui permet la gestion de la liste
des contacts avec toutes leurs informations, un navigateur web, etc.
7
Applications
Bureau Contacts Téléphone Navigateur …
Framework Applicatif
Bibliothèques
Noyau Linux
Moteur d’exécution
Android
Gestionnaire
d’activités
Gestionnaire de
fenêtres Fournisseur de
contenu Mécanisme des
vues
Gestionnaire
de paquetages Gestionnaire de
la téléphonie
Gestionnaire
des ressources Gestionnaire de
localisation Gestionnaire de
notifications
Gestionnaire
des surfaces Plateforme
Média SQLite
OpenGL|ES FreeType WebKit
SGL SSL libc
Pilote de
l’appareil photo Pilote de la
mémoire Flash Pilote IPC
Pilote
du clavier Pilote du wifi Pilotes Audio Gestion de
l’alimentation
Bibliothèques
internes
Machine virtuelle
Dalvik
Pilote
de l’écran
Figure 1.2 – Architecture du système d’exploitation Android[N3].
1.2.2.3 Avantages de la plateforme Android
Les avantages d’Android en tant que plateforme[1] :
• Elle est innovante car toutes les dernières technologies de téléphonie y sont intégrées :
écran tactile, accéléromètre, appareil photo numérique, etc.
• Elle est accessible car en tant que développeur on ne doit pas acheter du matériel
spécifique, ni à connaître un langage spécifique. En effet, le développement sur la
plateforme Android se fait par le langage Java, un des langages de programmation
les plus répandus.
• Elle est ouverte car la plateforme Android est fournie sous licence open source,
8
permettant à tous les développeurs (et constructeurs) de consulter les sources et
d’effectuer les modifications qu’ils souhaitent.
1.2.3 Web Service
Les web services sont des composants distribués qui offrent des fonctionnalités aux
applications au travers du réseau en utilisant des standards ouverts. Ils peuvent donc être
utilisés par des applications écrites dans différents langages et exécutées dans différentes
plateformes sur différents systèmes.
Les web services utilisent une architecture distribuée composée de plusieurs ordina-
teurs et/ou systèmes différents qui communiquent sur le réseau. Ils mettent en œuvre un
ensemble de normes et standards ouverts qui permettent aux développeurs d’implémenter
des applications distribuées internes ou externes en utilisant des outils différents fournis
par les fournisseurs[N4].
Un web service permet généralement de proposer une ou plusieurs fonctionnalités
métiers qui seront invoquées par un ou plusieurs consommateurs. Il existe deux grandes
familles de web services :
• Les web services de type SOAP
• Les web services de type REST.
1.2.3.1 Web service de type SOAP
SOAP (acronyme de Simple Object Acces Protocol) est un standard du W3C qui
permet l’échange formaté d’informations entre un client et un serveur. SOAP peut être
utilisé pour la requête et la réponse de cet échange.
Son grand intérêt est d’utiliser XML ce qui le rend ouvert contrairement aux autres
protocoles qui sont propriétaires : cela permet la communication entre un client et un
serveur utilisant des technologies différentes. Mais, il faut mentionner que l’utilisation du
protocole SOAP pose des problèmes qui concernent principalement l’alourdissement des
échanges à cause du nombre important d’informations qu’impose le format XML.
1.2.3.2 Web service de type REST
REST (acronyme de Representational State Transfer) est un style d’architecture réseau
pour les web services qui met l’accent sur la définition de ressources identifiées par des URI,
9
et utilise les messages du protocole HTTP pour définir la sémantique de la communication
client/serveur :
- GET pour la récupération de la représentation d’une ressource ou d’une liste de
ressources ;
- POST pour la création d’une sous ressource ou l’ajout d’information à une ressource
existante ;
- PUT pour la mise à jour d’une ressource existante ou la création d’une ressource
en spécifiant son URI ;
- DELETE pour un effacement.
Pour les web services REST, les encodages les plus utilisés sont XML et JSON :
. XML est un standard incontesté mais qui souffre de quelques inconvénients :
- Il est difficilement lisible.
- Il y a une dualité entre les attributs et les éléments.
. JSON (acronyme de JavaScript Object Notation) est un format texte qui permet
de représenter des données et de les échanger facilement comme le XML.
Ce sous ensemble de JavaScript permet de décrire le modèle objet de JavaScript.
Contrairement à XML, le format JSON ne fait pas de différence entre attribut et
élément. Il est donc globalement plus simple et plus lisible.
REST présente plusieurs avantages. En effet, REST est léger car il est basé uniquement
sur le protocole HTTP. De plus, REST permet une consommation de mémoire inférieure,
une plus grande simplicité et donc il a une capacité plus grande pour répondre à un grand
nombre de requêtes simultanées[2].
1.2.3.3 Solution retenue
On a choisi de travailler avec le web service de type REST vu les inconvénients du
type SOAP et étant donné que les avantages du type REST répondent bien aux besoins
de notre application (simplicité, rapidité et moins de consommation mémoire).
En effet, SOAP est un protocole très verbeux et parfois assez gourmand en ressources.
Beaucoup le déconseillent sur une plateforme telle qu’Android qui propose un environ-
nement contraint sur des appareils mobiles, surtout parce que le web service sera appelé
plusieurs fois avec un échange de données assez élevé[1].
10
1.2.4 Hibernate
Hibernate est une solution open source de type ORM (Object Relational Mapping)
qui permet de faciliter le développement de la couche persistance d’une application. Elle
permet donc de représenter une base de données en objets Java et vice versa[N5].
Hibernate facilite la persistance et la recherche de données dans une base de données
en réalisant lui-même la création des objets et les traitements de remplissage de ceux-ci
en accédant à la base de données.
Hibernate est très populaire notamment à cause de ses bonnes performances et de son
ouverture à de nombreuses bases de données.
Les bases de données supportées sont les principales du marché : PostgreSQL, DB2,
Oracle, MySQL, Sybase, SQL Server, Sap DB, Interbase, ...
Hibernate a besoin de plusieurs éléments pour fonctionner :
. Un fichier de configuration qui assure la correspondance entre la classe et la table :
il s’agit du mapping ou mappage de données qui est le mécanisme visant à faire cor-
respondre les attributs d’une fiche du système de stockage (BDD) avec les attributs
d’une entité (entité Java dans notre cas).
. Des propriétés de configuration notamment des informations concernant la connexion
à la base de données.
Une fois ces éléments sont correctement définis, on peut passer à l’implémentation de
la couche DAO puis la couche service qui va être utilisé par le web service.
1.2.4.1 Couche DAO
Le modèle DAO (Data Access Object) permet de faire le lien entre la couche métier
(qui correspond à nos entités Java mappées sur notre base) et la couche persistante (qui
correspond à la base de données), ceci afin de centraliser les mécanismes de mapping entre
les deux couches[N6].
Le modèle DAO consiste à ajouter un ensemble d’objets dont le rôle sera de lire, écrire,
modifier et supprimer les données stockées dans la base de données. Cet ensemble d’objet
s’appelle la couche DAO.
11
1.2.4.2 Couche Service
La couche service fait le lien entre la couche DAO et les couches supérieures. Elle va
donc être chargée, par exemple lors de la connexion d’un utilisateur, de vérifier que le
login et le mot de passe saisis correspondent bien à un utilisateur existant dans la base de
données. Elle sera également chargée de demander à la couche DAO de renvoyer la liste
de tous les projets enregistrés lorsqu’on veut les afficher une fois l’utilisateur est connecté
à l’application.
L’utilisation de la couche service permet d’apporter une modularité et un meilleur
découplage à l’application.
1.2.5 Base de données
Une base de données est un ensemble structuré et organisé permettant le stockage
de grandes quantités d’informations afin d’en faciliter l’exploitation (ajout, mise à jour,
recherche de données, etc)[N7].
Dans notre projet, on a choisi de travailler avec une base de données PostgreSQL car
c’est le SGBD (Système de Gestion de Base de Données) utilisé par l’entreprise et vu les
avantages qu’il présente.
L’une des principales qualités de PostgreSQL est d’être un logiciel libre et dont les
sources sont disponibles. De plus, PostgreSQL possède de nombreuses caractéristiques
faisant de lui un SGBDR (SGBD Relationnelles) puissant et robuste[N8] :
• Des interfaces graphiques pour gérer les tables.
• Des bibliothèques pour de nombreux langages afin d’accéder aux enregistrements à
partir de programmes écrits en : Java (JDBC), C/C++ et Perl.
• Une API ODBC permettant à n’importe quelle application supportant ce type d’in-
terface d’accéder à des bases de données de type PostgreSQL.
Conclusion
Dans ce chapitre, on a mis le projet dans son cadre et on a expliqué son sujet. On a
aussi présenté l’état de l’art des différents concepts liés à ce projet sur le plan théorique.
Le chapitre suivant portera sur les fonctionnalités qu’offrira notre solution et présentera
ses différents diagrammes de cas d’utilisation et sa conception.
12
Chapitre 2
Spécification des besoins et
Conception
Introduction
Dans ce chapitre, on va commencer tout d’abord par l’analyse et la spécification des
besoins de notre application. Ensuite, on va passer à la phase de conception.
2.1 Spécification des besoins
La spécification des besoins consiste à recenser les besoins potentiels et fournir une liste
des fonctionnalités attendues par la nouvelle application. Ces fonctionnalités et exigences
sont décrites sous forme textuelle au début de cette partie.
Ensuite, on va modéliser selon le langage UML afin de décrire les fonctionnalités d’une
façon formelle. Plus précisément, on va commencer par l’identification des acteurs qui vont
interagir avec le système. Puis, on va élaborer les diagrammes des cas d’utilisation.
2.1.1 Analyse des besoins
On spécifiera dans cette partie les besoins de notre application en termes de fonc-
tionnalités à atteindre. Ces besoins sont répartis en deux types : fonctionnels et non
fonctionnels.
13
2.1.1.1 Besoins fonctionnels
L’application doit permettre aux utilisateurs d’assurer un bon suivi de leurs projets.
Pour ce faire, on présente dans cette partie toutes les fonctionnalités que doit offrir notre
application.
1. Authentification
L’accès au menu de l’application nécessite un nom d’utilisateur et un mot de passe
correcte.
Une fois l’authentification est réussite, des interfaces spécifiques à chaque utilisateur
(selon son rôle) s’affichent.
2. Gestion des membres de l’équipe
Le but de la gestion des membres de l’équipe est d’associer aux projets l’ensemble
des ressources humaines qui y sont reliés.
3. Gestion de la liste des projets
• Créer un nouveau projet : L’administrateur de l’application et le chef de projet
peuvent créer un nouveau projet. Ils doivent donc fournir les données suivantes :
nom du projet, abréviation, client, description, statut, groupe, date de début et
date de fin.
• Afficher les listes des projets relatifs à l’utilisateur qui s’est authentifié. S’il s’agit
de l’administrateur de l’application, alors il pourra voir tous les projets existants.
• Afficher les détails du projet sélectionné.
4. Gestion des éléments de travail (work item)
• Créer un nouveau élément de travail : Lors de l’ajout, l’utilisateur doit fournir les
données suivantes : titre, type, business key (qui doit être unique), description,
priorité, sévérité, statut et à qui sera affecté l’élément de travail.
Il est à noter qu’un élément de travail peut être de type Task, Risk, Defect, Ques-
tion, Requirement, Notification, Change Request, Acceptance, Improvement, New
Feature, Test Case, Regression, Business Case ou User Story.
• Afficher les listes d’éléments de travail relatifs au projet choisi.
• Afficher des détails d’un élément de travail.
• Ajouter un commentaire à un élément de travail en cas de besoin.
14
2.1.1.2 Besoins non fonctionnels
Les besoins non fonctionnels décrivent toutes les contraintes auxquelles est soumise
l’application pour sa réalisation et son bon fonctionnement :
1. Les contraintes ergonomiques Les contraintes ergonomiques sont les contraintes
liées à l’adaptation entre les fonctionnalités de l’application, leurs interfaces et leurs
utilisations. Pour notre application, on doit obéir aux contraintes ergonomiques
suivantes :
• Ergonomie et souplesse : L’application doit offrir une interface conviviale et ergo-
nomique compréhensible par l’utilisateur.
• Présenter les informations d’une façon simple et claire.
• Rapidité : L’application doit optimiser les traitements pour avoir un temps de
réponse raisonnable.
2. Les contraintes techniques
• Compatibilité : les fonctions de l’application doivent être compatibles avec celles
existantes.
• Homogénéité des interfaces de l’application : les différentes pages doivent suivre
le même modèle de représentation (couleurs, images, etc.).
• Efficacité : L’application doit être fonctionnelle si le smartphone est connecté à
l’internet indépendamment de toute autre circonstance pouvant entourer l’utili-
sateur.
• Le code doit être extensible et maintenable pour faciliter toute opération d’amé-
lioration ou d’optimisation.
2.1.2 Spécifications
Après une description textuelle des besoins, on présentera dans cette partie les fonc-
tionnalités de notre application d’une façon formelle en utilisant le langage de modélisation
UML qui se définit comme un langage de modélisation graphique.
Pour ce faire, on commencera par identifier et présenter les acteurs en premier lieu
pour arriver enfin aux diagrammes des cas d’utilisation.
15
2.1.2.1 Présentation des acteurs
Les acteurs représentent les entités externes qui interagissent avec le système. Notre
application comporte essentiellement trois acteurs présentés dans le tableau 2.1.
Table 2.1 – Présentation des acteurs.
Développeur
C’est un utilisateur de l’application qui peut gérer ses éléments de
travail.
Chef de projet
Il peut gérer l’ensemble des projets dont il est responsable et créer
de nouveaux projets.
Admin
C’est l’administrateur de l’application. Il possède tous les privilèges.
Il peut gérer tous les projets de l’application.
2.1.2.2 Diagrammes des cas d’utilisation
Un diagramme de cas d’utilisation est utilisé pour donner une vision globale du com-
portement fonctionnel d’un système logiciel, car il représente une unité discrète d’inter-
action acteur/système.
1. Diagramme de cas d’utilisation global Le diagramme de cas d’utilisation glo-
bale représente les fonctionnalités principales qu’offre notre application. Il est repré-
senté par la figure 2.1.
16
Développeur
Admin Chef de projet
Gérer les travaux des membres du projet
S'authentifier
Afficher la liste des projets
<<include>>
<<include>>
Sélectionner un projet
<<include>>
<<include>>
Ajouter un projet<<include>>
Gérer les éléments de travail
Figure 2.1 – Diagramme des cas d’utilisation global.
Dans ce qui suit, on va détailler davantage les cas d’utilisation « S’authentifier »,
«Gérer les éléments de travail » et « Gérer les travaux des membres du projet ».
2. Description détaillée des cas d’utilisation
a. Cas d’utilisation « S’authentifier »
L’authentification est une étape primordiale afin que chaque utilisateur puisse
accéder à son espace de travail.
Le tableau 2.2 présente une description textuelle du cas d’utilisation «S’au-
thentifier» :
17
Table 2.2 – Tableau descriptif du cas d’utilisation « S’authentifier ».
Titre Authentification.
Acteurs Utilisateur (Admin, Chef de projet et Développeur)
Pré-conditionsServeur disponible.
Utilisateur inscrit.
Définition des
enchainements
Enchainement nominal :
1. L’utilisateur demande l’accès au système.
2. Le système affiche le formulaire d’authentification.
3. L’utilisateur saisit son nom d’utilisateur et son mot
de passe et clique sur le bouton « Connexion ».
4. Le système vérifie les informations.
5. Le système autorise l’accès.
Enchainement d’exception :
Nom d’utilisateur ou mot de passe non valides et/ou
vides :
1. Le système affiche un message d’erreur.
2. Le scénario reprend de 3.
Post-
conditionsL’utilisateur peut accéder à l’interface principale.
b. Cas d’utilisation « Gérer les éléments de travail »
La figure 2.2 représente le diagramme du cas d’utilisation « Gérer les éléments
de travail » qui présente les opérations qui peuvent être effectuées par les
utilisateurs de notre application pour la gestion des éléments de travail.
18
Afficher la liste des éléments de travail
Afficher les détails d'un élément de travail
Ajouter un élément de travail
Afficher les commentaires
Commenter un élément de travail
<<extend>>
<<include>>
<<extend>>
<<extend>>
Développeur
AdminChef de projet
Figure 2.2 – Diagramme du cas d’utilisation « Gérer les éléments de travail ».
c. Cas d’utilisation « Gérer les travaux des membres du projet »
Le chef de projet et l’admin sont les seuls acteurs qui ont le droit de gérer les
travaux des membres. Il s’agit en fait de désigner les utilisateurs qui pourront
accéder au projet.
2.2 Conception
La conception consiste à décrire la manière avec laquelle le système réalise les exigences
et les besoins de notre application.
Cette étape est primordiale dans le déroulement du projet et a pour but de détailler
les tâches à entreprendre pour préparer le terrain à l’étape de réalisation.
On va présenter d’abord la conception globale du système. Ensuite, on va détailler à
travers les diagrammes de classes, d’activités et de séquences, la conception de l’applica-
tion développée au sein de notre projet. Puis, on va présenter la conception de la base de
données en s’appuyant sur le modèle conceptuel de données.
2.2.1 Conception globale
On a utilisé dans notre projet le modèle MVC (Modèle-Vue-Contrôleur) pour déve-
lopper notre application mobile (figure 2.3).
Le modèle MVC est une méthode de conception qui organise l’interface homme ma-
chine (IHM) d’une application logicielle. Ce paradigme divise l’IHM en un modèle, une
vue et un contrôleur, chacun ayant un rôle précis dans l’interface[N9] :
19
• Le modèle : Il représente les données de l’application. Il définit aussi l’interaction
avec la base de données et le traitement de ces données.
• La vue : Elle représente l’interface utilisateur. Elle n’effectue aucun traitement et
elle se contente simplement d’afficher les données que lui fournit le modèle.
• Le contrôleur : Il interprète la requête du client pour lui envoyer la vue corres-
pondante. Il effectue la synchronisation entre le modèle et les vues.
Figure 2.3 – Le modèles MVC.
Les avantages du modèle MVC sont nombreux. D’une part, il permet de formaliser
l’application pour faciliter la compréhension de sa structure. Il permet aussi de créer des
limites très claires et bien définies entre les différents morceaux de code ce qui rend la
réutilisation beaucoup plus simple. D’autre part, il assure l’indépendance des données, de
l’affichage et des actions ce qui donne plus de souplesse pour la maintenance et l’évolution
de l’application.
2.2.2 Conception détaillée
Dans cette partie, on va présenter les diagrammes d’activités, de séquences et de classes
de notre application.
2.2.2.1 Diagramme de classes
Le diagramme de classes représente les classes intervenantes dans le système. Il s’agit
d’une représentation statique des éléments qui composent le système et de leurs rela-
20
tions[N13].
La figure 2.4 présente les classes les plus importantes de notre projet des deux parties :
client et serveur.
D’une façon générale, les activités Android font appel aux classes de la couche Web
Service. Ceux-ci exécutent les classes de la couche service qui leurs sont reliées. De même,
ces dernières font appel aux classes de la couche DAO qui exécutent des requêtes HQL
pour extraire les données demandées de la base de données.
On va présenter maintenant ces classes selon la couche à laquelle elles appartiennent.
1. Couche DAO Dans cette couche, on a 4 classes :
• GenericDao : C’est une classe abstraite qui implémente l’interface IGeneric-
Dao dans laquelle on trouve la méthode create(Entity entity) qui va servir à
la création de nouvelle entity.
Il est à noter que dans ce diagramme on utilise les entités Project (Projet),Wor-
kitem (Élément de travail) et User (Utilisateur) dont on va expliquer davantage
leurs relations dans le modèle de conception de données (dans la partie 2.2.3).
• UserDao : Cette classe implémente l’interface IUserDao qui contient la mé-
thode getUsersList() qui va extraire la liste des utilisateurs et les données qui
leurs sont relatives (comme le rôle de l’utilisateur dans l’application (UserRole)).
• WorkitemDao : Cette classe implémente l’interface IWorkitemDao qui contient
la méthode getWorkitemsByProject(Project project) qui va extraire la liste
des éléments de travail relatifs au projet entré en paramètre. Ceux-ci seront ac-
compagnés par les données qui leurs sont relatives.
• ProjectDao : Cette classe implémente l’interface IProjectDao qui contient la
méthode getAllProjects() qui va extraire la liste des projets et les données qui
leurs sont relatives.
Ces 3 dernières classes de cette couche héritent de la classe GenericDao et les
interfaces qu’elles implémentent héritent de l’interface IGenericDao.
21
1..
*
1
1..
*1
Pro
jectW
S
-p
roje
ctS
erv
ice
: IP
roje
ctS
erv
ice
+ +
ge
tPro
jectL
ist
()
po
stP
roje
ct
(Mu
ltiv
alu
ed
Ma
p<
Str
ing
, S
trin
g>
pro
jectL
istP
ara
ms)
: L
ist<
Pro
ject>
: P
roje
ct
IPro
jectS
erv
ice
+ +
list
Pro
jects
()
cre
ate
(P
roje
ct
pro
ject)
: L
ist<
Pro
ject>
: P
roje
ct
Pro
jectS
erv
ice
-p
roje
ctD
ao
: IP
roje
ctD
ao
+ +
list
Pro
jects
()
cre
ate
(P
roje
ct
pro
ject)
: L
ist<
Pro
ject>
: P
roje
ct
Pro
jectD
ao
-w
ork
ite
mD
ao
: IW
ork
ite
mD
ao
+g
etA
llP
roje
cts
()
: L
ist<
Pro
ject>
IPro
jectD
ao
+g
etA
llP
roje
cts
()
: L
ist<
Pro
ject>
Ge
ne
ricD
ao
+cre
ate
(E
nti
ty e
nti
ty)
: E
nti
ty
IGe
ne
ricD
ao
+cre
ate
(E
nti
ty n
ew
Inst
an
ce
):
En
tity
Wo
rkit
em
Da
o
+g
etW
ork
ite
msB
yP
roje
ct
(Pro
ject
pro
ject)
: L
ist<
Wo
rkit
em
>
IWo
rkit
em
Da
o
+g
etW
ork
ite
msB
yP
roje
ct
(Pro
ject
pro
ject)
: L
ist<
Wo
rkit
em
>
Use
rWS
-u
serS
erv
ice
: IU
serS
erv
ice
+g
etU
sers
Lis
t ()
: L
ist<
Use
r>
IUse
rSe
rvic
e
+li
stU
sers
()
: L
ist<
Use
r>
Use
rSe
rvic
e
-u
sers
Da
o:
IUse
rDa
o
+li
stU
sers
()
: L
ist<
Use
r>
Use
rDa
o
+g
etA
llU
sers
()
: L
ist<
Use
r>
IUse
rDa
o
+g
etA
llU
sers
()
: L
ist<
Use
r>
Au
the
nti
fica
tio
nA
cti
vit
y
- - - - - -
use
rna
me
pa
ssw
ord
btn
Co
nn
exio
n
url
msg
Err
eu
r
jso
n
: E
dit
Te
xt
: E
dit
Te
xt
: B
utt
on
: S
trin
g
: S
trin
g
: S
trin
g
#o
nC
rea
te (
Bu
nd
le s
ave
dIn
sta
nce
Sta
te)
: vo
id
Pro
jectL
istA
cti
vit
y
- - - - - - - - - -
filt
erE
dit
Te
xt
list
Vie
wP
roje
ct
btn
Ad
dP
roje
ct
acti
on
Ba
r
oth
erA
cti
on
pro
jectL
ist
ad
ap
ter
jso
n
use
rRo
le
url
: E
dit
Te
xt
: L
istV
iew
: B
utt
on
: A
cti
on
Ba
r
: A
cti
on
: L
ist<
Str
ing
>
: A
rra
yA
da
pte
r<S
trin
g>
: S
trin
g
: S
trin
g
: S
trin
g
#o
nC
rea
te (
Bu
nd
le s
ave
dIn
sta
nce
Sta
te)
: vo
id
Ad
dP
roje
ctA
cti
vit
y
- - - - - - - - - - - - - - - - - - - -
ed
itN
am
e
ed
itA
bre
via
tio
n
ed
itD
esc
rip
tio
n
spin
ne
rCu
sto
me
r
spin
ne
rPro
jectS
tatu
s
spin
ne
rPro
jectG
rou
p
btn
Pla
nn
ed
Sta
rtD
ate
btn
Pla
nn
ed
En
dD
ate
btn
Ad
dP
roje
ct
da
teP
icke
r
sta
rtD
ate
Pic
kerL
iste
ne
r
en
dD
ate
Pic
kerL
iste
ne
r
list
Cu
sto
me
r
list
Pro
jectS
tatu
s
list
Pro
jectG
rou
p
acti
on
Ba
r
oth
erA
cti
on
jso
n
jso
nP
ost
url
: E
dit
Te
xt
: E
dit
Te
xt
: E
dit
Te
xt
: S
pin
ne
r
: S
pin
ne
r
: S
pin
ne
r
: B
utt
on
: B
utt
on
: B
utt
on
: D
ate
Pic
kert
: D
ate
Pic
kerD
ialo
g.O
nD
ate
Se
tLis
ten
er
: D
ate
Pic
kerD
ialo
g.O
nD
ate
Se
tLis
ten
er
: L
ist<
Str
ing
>
: L
ist<
Str
ing
>
: L
ist<
Str
ing
>
: A
cti
on
Ba
r
: A
cti
on
: S
trin
g
: S
trin
g
: S
trin
g
# #
on
Cre
ate
(B
un
dle
sa
ve
dIn
sta
nce
Sta
te)
on
Cre
ate
Dia
log
(in
t id
)
: vo
id
: D
ialo
g
Wo
rkit
em
Se
rvic
e
-w
ork
ite
mD
ao
: IW
ork
ite
mD
ao
+cre
ate
(W
ork
ite
m w
ork
ite
m)
: W
ork
ite
m
IWo
rkit
em
Se
rvic
e
+cre
ate
(W
ork
ite
m w
ork
ite
m)
: W
ork
ite
m
Ad
dW
ork
ite
mA
cti
vit
y
- - - - - - - - - - - - - - - - - - - - - -
ed
itT
itle
ed
itB
usi
ne
ssK
ey
ed
itW
ork
ite
mS
tatu
s
ed
itA
ssig
ne
dT
o
ed
itW
ork
ite
mD
esc
rip
tio
n
spin
ne
rPro
jectN
am
e
spin
ne
rWo
rkit
em
Typ
e
spin
ne
rWo
rkit
em
Se
ve
rity
spin
ne
rWo
rkit
em
Pri
ori
ty
btn
Ad
dW
ork
ite
m
list
Pro
jectN
am
e
list
Wo
rkit
em
Typ
e
list
Wo
rkit
em
Se
ve
rity
list
Wo
rkit
em
Pri
ori
ty
acti
on
Ba
r
oth
erA
cti
on
jso
nA
rra
y
ele
me
nt
da
ta
jso
n
jso
nP
ost
url
: E
dit
Te
xt
: E
dit
Te
xt
: E
dit
Te
xt
: E
dit
Te
xt
: E
dit
Te
xt
: S
pin
ne
r
: S
pin
ne
r
: S
pin
ne
r
: S
pin
ne
r
: B
utt
on
: L
ist<
Str
ing
>
: L
ist<
Str
ing
>
: L
ist<
Str
ing
>
: L
ist<
Str
ing
>
: A
cti
on
Ba
r
: A
cti
on
: JS
ON
Arr
ay
: JS
ON
Ob
ject
: JS
ON
Ob
ject
: S
trin
g
: S
trin
g
: S
trin
g
#o
nC
rea
te (
Bu
nd
le s
ave
dIn
sta
nce
Sta
te)
: vo
id
Wo
rkit
em
WS
-w
ork
ite
mS
erv
ice
: IW
ork
ite
mS
erv
ice
+p
ost
Wo
rkit
em
(M
ult
iva
lue
dM
ap
<S
trin
g,
Str
ing
> w
ork
ite
mL
istP
ara
ms)
: W
ork
ite
m
Se
lecte
dP
roje
ctA
cti
vit
y
- - - - - - - - - - - -
tab
s
pa
ge
r
mP
ag
erA
da
pte
r
acti
on
Ba
r
oth
erA
cti
on
jso
n
na
me
wo
rkit
em
s
id jso
nA
rra
y
da
ta
ele
me
nt
: P
ag
erS
lid
ing
Ta
bS
trip
: V
iew
Pa
ge
r
: P
ag
erA
da
pte
r
: A
cti
on
Ba
r
: A
cti
on
: S
trin
g
: S
trin
g
: S
trin
g
: in
t
: JS
ON
Arr
ay
: JS
ON
Ob
ject
: JS
ON
Ob
ject
#o
nC
rea
te (
Bu
nd
le s
ave
dIn
sta
nce
Sta
te)
: vo
id
Wo
rkit
em
sActi
vit
y
- - - - - - - - -
exp
an
da
ble
Lis
tVie
wW
ork
ite
ms
btn
Ad
dW
ork
ite
m
ho
lde
r_ch
ild
ho
lde
r_p
are
nt
jso
n
wo
rkit
em
s
wo
rkit
em
sJso
nA
rra
y
ele
me
nt
da
ta
: E
xp
an
da
ble
Lis
tVie
w
: B
utt
on
: V
iew
Ho
lde
r_C
hil
d
: V
iew
Ho
lde
r_P
are
nt
: S
trin
g
: S
trin
g
: JS
ON
Arr
ay
: JS
ON
Ob
ject
: JS
ON
Ob
ject
+ + - +
on
Cre
ate
(B
un
dle
sa
ve
dIn
sta
nce
Sta
te)
on
Cre
ate
Vie
w (
La
yo
utI
nfl
ate
r in
fla
ter,
Vie
wG
rou
p c
on
tain
er,
Bu
nd
le s
ave
dIn
sta
nce
Sta
te)
ge
tAll
Ids
(Vie
w v
iew
)
on
Acti
vit
yC
rea
ted
(B
un
dle
sa
ve
dIn
sta
nce
Sta
te)
: vo
id
: V
iew
: vo
id
: vo
id
Pro
jectD
eta
ilA
cti
vit
y
- - - - - - -
txtD
eta
ilP
roje
ct
na
me
jso
n
id jso
nA
rra
y
ele
me
nt
da
ta
: T
extV
iew
: S
trin
g
: S
trin
g
: in
t
: JS
ON
Arr
ay
: JS
ON
Ob
ject
: JS
ON
Ob
ject
+ + +
on
Cre
ate
(B
un
dle
sa
ve
dIn
sta
nce
Sta
te)
on
Cre
ate
Vie
w (
La
yo
utI
nfl
ate
r in
fla
ter,
Vie
wG
rou
p c
on
tain
er,
Bu
nd
le s
ave
dIn
sta
nce
Sta
te)
on
Acti
vit
yC
rea
ted
(B
un
dle
sa
ve
dIn
sta
nce
Sta
te)
: vo
id
: V
iew
: vo
id
Figure 2.4 – Diagramme des classes.
22
2. Couche Service
• UserService : Cette classe implémente l’interface IUserService qui contient
la méthode listUsers() qui va faire appel à la méthode getAllUsers() de la
classe UserDao.
• WorkitemService : Cette classe implémente l’interface IWorkitemService
qui contient la méthode create(Workitem workitem) qui va faire appel à la
méthode create(Entity entity) de la classe GenericDao à travers la classe
WorkitemDao.
• ProjectService : Cette classe implémente l’interface IProjectService qui contient
la méthode listProjects() qui va faire appel à la méthode getAllProjects() de
la classe ProjectDao.
La classe ProjectService contient aussi la méthode create(Project project)
qui va faire appel à la méthode create(Entity entity) de la classeGenericDao
à travers la classe ProjectDao.
3. Couche Web Service
• UserWS : Cette classe contient la méthode getUserslist() qui va faire appel
à la méthode listUsers() de la classe UserService.
• WorkitemWS : Cette classe contient la méthode postWorkitem qui va faire
appel à la méthode create(Workitem workitem) de la classe WorkitemSer-
vice pour créer un nouveau élément de travail.
• ProjectWS : Cette classe contient la méthode getProjectlist() qui va faire
appel à la méthode listProjects() de la classe ProjectService.
La classe ProjectWS contient aussi la méthode postProject qui va faire appel
à la méthode create(Project project) de la classe ProjectService pour créer
un nouveau projet.
4. Activités Android
• AuthentificationActivity : C’est la première activité Android qui se lance en
ouvrant l’application. Elle permet, tout d’abord, de lancer une requête GET pour
récupérer la liste des utilisateurs à partir de la BDD. Pour ce faire, elle fait appel
à la méthode getUsersList() de la classe UserWS. Ensuite, elle vérifie les
données saisies par l’utilisateur pour lui permettre d’accéder à l’activité suivante
(au cas où il saisit des données valides).
23
• ProjectListActivity : C’est l’activité qui va se lancer après authentification.
Elle lance dès son ouverture une requête GET qui va faire appel à la méthode
getProjectList() de la classe ProjectWS dans le but de récupérer et afficher
la liste des projets relatifs à l’utilisateur connecté.
Cette activité contient aussi un bouton qui permet d’ouvrir l’activité AddPro-
jectActivity.
• AddProjectActivity : Cette activité sert pour l’ajout d’un nouveau projet. Ceci
se fait en lançant une requête POST qui va faire appel à la méthode postProject
de la classe ProjectWS.
• SelectedProjectActivity : L’utilisateur peut accéder à cette activité en sélec-
tionnant un projet de la liste fourni par l’activité ProjectListActivity.
Cette activité contient un ViewPager qui est composé de deux fragments : Pro-
jectDetailActivity et WorkitemsActivity sachant que le ViewPager[N14] est un
gestionnaire de layout qui permet à l’utilisateur de glisser à gauche et à droite des
pages de données et les fragments représentent des portions d’activité qui vont
être les composants de l’activité SelectedProjectActivity.
. ProjectDetailActivity : C’est un fragment qui va présenter les détails du projet
choisi.
. WorkitemsActivity : C’est un fragment qui va présenter les éléments de travail
relatifs au projet sélectionné. Ce fragment contient aussi un bouton qui va
permettre d’accéder à l’activité AddWorkitemActivity.
• AddWorkitemActivity : Cette activité sert à ajouter un nouveau élément de
travail. Ceci se fait en lançant une requête POST qui va faire appel à la méthode
postWorkitem de la classe WorkitemWS.
2.2.2.2 Diagramme d’activités
Le diagramme d’activités représente la dynamique du système. Il montre l’enchaîne-
ment des activités d’un système ou même d’une opération[N10].
Le diagramme d’activités est utilisé pour illustrer les flux de travail dans un système,
du niveau métier jusqu’au niveau opérationnel[N11].
24
Figure 2.5 – Diagramme d’activités.
La figure 2.5 présente le diagramme d’activités qui traduit les différentes tâches réali-
sées par le chef de projet ou l’administrateur de l’application :
1. Après avoir lancer l’application, une interface d’authentification s’affiche dans la-
quelle l’utilisateur (le chef de projet ou l’administrateur de l’application) saisit son
nom d’utilisateur et son mot de passe.
2. Si le nom d’utilisateur ou le mot de passe n’est pas valide, un message d’erreur sera
affiché sinon l’utilisateur accède à l’interface qui contient liste des projets.
3. En accédant à cette interface, l’utilisateur peut ajouter un nouveau projet (en cli-
quant sur le bouton « Add Project »). Dans ce cas, une nouvelle interface s’ouvre.
Celle-ci contient des champs spécifiques pour ajouter les informations relatives au
nouveau projet. Après les avoir enregistrées, la liste de projets s’affiche de nouveau
tout en contenant le nom du projet ajouté.
L’utilisateur peut aussi (après avoir accéder à l’interface qui contient liste des pro-
25
jets) sélectionner un projet en cliquant sur son nom dans la liste. Dans ce cas, il peut
afficher les détails du projet sélectionné ou afficher la liste des éléments de travail
relatifs à celui-ci.
Au cas où l’utilisateur choisit d’afficher la liste des éléments de travail, une nouvelle
interface s’ouvre dans laquelle il va pouvoir ajouter ou commenter un élément de
travail ou encore afficher les détails d’un élément de travail existant en le sélection-
nant.
Ce diagramme d’activités reste valable même pour le développeur sauf que ce dernier
n’a pas la permission d’ajouter un nouveau projet.
2.2.2.3 Diagrammes de séquences
Le diagramme de séquences est un diagramme d’interaction dont les principales in-
formations sont les messages échangés entre les lignes de vie, présentés dans un ordre
chronologique. Il peut servir à illustrer un cas d’utilisation[N12]. On va présenter, dans
ce qui suit, des exemples de scénarios décrivant quelques cas d’utilisation présentés pré-
cédemment.
1. Diagramme de séquences du scénario « S’authentifier » Pour accéder aux
différentes fonctionnalités de l’application, l’utilisateur (développeur, chef de projet
ou admin) doit s’authentifier.
Les étapes d’authentification sont décrites dans la figure 2.6.
En ouvrant l’application, une requête GET se lance pour récupérer la liste des
utilisateurs existants dans la base de données. L’exécution de cette requête entraîne
l’exécution successive des méthodes : getUsersList() du Web Service, listUsers()
de la couche service et getAllUsers() de la couche DAO. Cette dernière exécute
une requête HQL qui va servir à la récupération de la liste des utilisateurs à partir
de la base de données PostgreSQL.
Après l’exécution de ces méthodes, l’application laisse la main à l’utilisateur pour
entrer son nom d’utilisateur et son mot de passe. Puis, elle vérifie ces données. Si ces
derniers sont valides, alors l’utilisateur pourra accéder à l’interface suivante, sinon,
un message d’erreur sera affiché.
26
DS Authentification
Vérifier nom d'util isateur
et mot de passe dans la
liste des util isateurs
Autoriser l 'accèes
Afficher message d'erreur
Saisir nom d'util isateur
et mot de passe
Ouvrir l 'interface
d'authentification
Retourner la liste
des util isateurs
Retourner la liste
des util isateurs
Retourner la liste
des util isateurs
Retourner la liste
des util isateurs
Récupéer la liste
des util isateurs
usersDao.getAllUsers()
userService.listUsers()getUsersList()
Ouvrir l 'application
Util isateur
:Application_Android :Web_Service :Couche_Service :Couche_DAO :Base_de_données
[Valide]
[Non valide]
alt
Vérifier nom d'util isateur
et mot de passe dans la
liste des util isateurs
Autoriser l 'accèes
Afficher message d'erreur
Saisir nom d'util isateur
et mot de passe
Ouvrir l 'interface
d'authentification
Retourner la liste
des util isateurs
Retourner la liste
des util isateurs
Retourner la liste
des util isateurs
Retourner la liste
des util isateurs
Récupéer la liste
des util isateurs
usersDao.getAllUsers()
userService.listUsers()getUsersList()
Ouvrir l 'application
Figure 2.6 – Diagrammes de séquences du scénario « S’authentifier ».
2. Diagramme de séquences du scénario « Afficher la liste des projets »
Les étapes d’affichage la liste des projets sont décrites dans la figure 2.6.
Pour afficher la liste des projets, l’utilisateur doit tout d’abord s’authentifier. Après
avoir entré un nom d’utilisateur et un mot de passe valides, l’application ouvre
l’activité ProjectListActivity. Celle-ci lance une requête GET pour récupérer
l’ensemble des projets stockés dans la base de données. Ce qui entraine l’exécu-
tion de la méthode getProjectList() du Web Service qui fait appel à la méthode
listProjects() de la couche service. Celle-ci, à son tour, fait appel à la méthode
getAllProjects() de la couche DAO. Pour récupérer les listes d’éléments de travail
relatives à chaque projet, cette dernière méthode fait appel à la méthode getWor-
kitemsByProject(project) de la couche DAO.
Après avoir récupéré tous les données relatifs à tous les projets, la liste des noms
27
des projets apparaît dans l’interface de l’activité courante.
DS Afficher la liste des projets
Afficher la liste des projets
workitemDao.getWorkitems
ByProject(project)
Récupéer la liste des projets
projectDao.getAllProjects()
projectService.listProjects()
Lancer
ProjectListActivity
getProjectList()
Afficher message d'erreur
S'authentifier
Développeur
:Application_Android :Base_de_données:Couche_DAO:Web_Service :Couche_Service
[Non Valide]
[Valide]
alt
Afficher la liste des projets
workitemDao.getWorkitems
ByProject(project)
Récupéer la liste des projets
projectDao.getAllProjects()
projectService.listProjects()
Lancer
ProjectListActivity
getProjectList()
Afficher message d'erreur
S'authentifier
Figure 2.7 – Diagrammes de séquences du scénario « Afficher la liste des projets ».
2.2.3 Conception de la base de données
Le modèle conceptuel de données (MCD ou Modèle entité-association) a pour but
d’écrire de façon formelle les données qui seront utilisées par le système d’information. Il
s’agit donc d’une représentation des données, facilement compréhensible, permettant de
décrire le système d’information à l’aide d’entités[N15].
28
1,1
0,n
1,1
0,n
1,1
0,n
1,1
0,n
1,1
0,n
1,1
0,n
1,1
0,n
1,1
0,n
0,n
1,n
0,n
0,n
0,n
1,1
1,1
0,n
Pro
ject
idP
roje
ct
na
me
ab
revia
tio
n
pla
nn
ed
_st
art
_d
ate
pla
nn
ed
_e
nd
_d
ate
de
scri
pti
on
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Lo
ng
va
ria
ble
ch
ara
cte
rs (
10
)
Da
te
Da
te
Te
xt
Ide
nti
fia
nt_
1<
pi>
Wo
rkit
em
idW
ork
ite
m
bu
sin
ess
_ke
y
titl
e
asi
gn
ed
_to
de
scri
pti
on
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Lo
ng
ch
ara
cte
rs (
25
5)
Lo
ng
va
ria
ble
ch
ara
cte
rs (
60
)
Te
xt
Ide
nti
fia
nt_
2<
pi>
Use
r
idU
ser
use
rna
me
pa
ssw
ord
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
60
)
Lo
ng
va
ria
ble
ch
ara
cte
rs (
10
0)
Ide
nti
fia
nt_
3<
pi>
Wo
rkit
em
Pri
ori
ty
idW
Pri
ori
ty
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
11
<p
i>
Wo
rkit
em
Se
ve
rity
idW
Se
ve
rity
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
10
<p
i>
Wo
rkit
em
Sta
tus
idW
Sta
tus
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
9<
pi>
Wo
rkit
em
Typ
e
idW
Typ
e
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
8<
pi>
Pro
jectS
tatu
s
idP
Sta
tus
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
6<
pi> P
roje
ctG
rou
p
idG
rou
p
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
7<
pi>Cu
sto
me
r
idC
ust
om
er
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
5<
pi>P
roje
ctR
ole
idP
roje
ctR
ole
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
12
<p
i>
co
nti
en
t
est
ca
racté
risé
pa
rp
oss
èd
e3
po
ssè
de
4p
oss
èd
e5
co
rre
spo
nd
po
ssè
de
2
ap
pa
rtie
nt
avo
ir
po
ssè
de
Use
rRo
le
idU
serR
ole
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
4<
pi>
po
ssè
de
1
Wo
rkit
em
Co
mm
en
t
idW
Co
mm
en
t
na
me
<p
i>L
on
g i
nte
ge
r
Lo
ng
va
ria
ble
ch
ara
cte
rs (
30
)
Ide
nti
fia
nt_
13
<p
i>
co
nti
en
t2
Figure 2.8 – Modèle conceptuel de données.
29
La figure 2.8 présente le modèle conceptuel de données de notre projet qui contient les
entités suivantes :
• Project : Cette entité contient l’identifiant du projet, son nom, son abréviation, sa
description et ses dates de début et de fin.
• Customer : C’est le client du projet.
• ProjectStatus : C’est le statut du projet qui peut prendre l’une des valeurs sui-
vantes : "In progress", "Closed", "Cancelled", "New" ou "Planned".
• ProjectGroup : C’est le groupe du projet.
• User : Cette entité contient l’identifiant de l’utilisateur, son nom et son mot de
passe.
• UserRole : C’est le rôle de l’utilisateur dans l’application. Celui-ci peut être l’ad-
min ou un simple utilisateur dans l’application.
• ProjectRole : C’est le rôle de l’utilisateur dans un projet donné. Celui-là peut être
un chef de projet ou un développeur.
• Workitem : Cette entité présente l’élément de travail. Elle contient son identifiant,
son titre, son business key, sa description et à qui il est affecté.
• WorkitemType : C’est le type de l’élément de travail. Ceui-ci peut être de type :
"Requirement", "Defect", "Change Request", "Test Case", "Risk", "Task", "Accep-
tance", "Improvement", "New feature", "Regression", "Business Case", "Notification",
"Question" ou "User Story".
• WorkitemStatus : C’est le statut de l’élément de travail. Celui-ci peut être
"Draft", "Accepted", "Active", "New", "Assigned", "In Progress", "Implemented", "Re-
solved", "Done", "Verified" ou "Closed".
• WorkitemSeverity : C’est le degré de sévérité de l’élément de travail. Il peut
être : "Must Have", "Normal", "Blocker", "Critical", "Major", "Minor", "Trivial" ou
"Moderate".
• WorkitemPriority : C’est le degré de priorité de l’élément de travail. Il peut
être : "Highest", "High", "Medium", "Low" ou "Lowest".
• WorkitemComment : Cette entité présente les commentaires relatifs à un élé-
ment de travail.
30
Conclusion
Dans ce chapitre, on a présenté en premier lieu les besoins fonctionnels et non fonc-
tionnels de notre application. On a ensuite représenté ces besoins en détaillant les fonc-
tionnalités attendues à travers les diagrammes des cas d’utilisation.
Puis, on a présenté la conception globale de notre solution. Après, on a détaillé la
conception de notre application à travers une description des diagrammes de classes,
d’activités et de séquences. Enfin, on a représenté la conception de notre base de données.
Dans le chapitre suivant, on va exposer la réalisation de notre projet en présentant
l’environnement de travail ainsi que les résultats obtenus.
31
Chapitre 3
Réalisation
Introduction
L’implémentation du projet est une étape aussi importante que la conception. Cette
étape constitue la phase d’achèvement et d’aboutissement du projet.
Pour accomplir cette tâche avec succès, il faut bien choisir les outils nécessaires au
développement. Ce choix peut influencer sur la qualité du produit obtenu et donc nécessite
une attention particulière et doit se baser sur les besoins du projet et le résultat escompté.
Dans ce chapitre, on va présenter alors l’environnement de travail et les différentes
technologies utilisées pour notre application. Par la suite, on va présenter les interfaces
de notre solution.
3.1 Présentation de l’environnement de travail
3.1.1 Environnement matériel
L’environnement matériel avec lequel on a développé notre application est le suivant :
. PC portable HP Pavillon dv6 ;
. Processeur Intel R© Pentium Dual Core T4500, 2.3 Ghz ;
. RAM : 4 Go ;
. Système d’exploitation : Windows 7.
32
3.1.2 Environnement logiciel
Les logiciels utilisés lors du développement et de la conception sont les suivants :
Table 3.1 – Logiciels utilisés.
Type Nom Version
Environnement de développement Eclipse Juno 4.2
Kit de développement SDK Android 22.0.1
Serveur d’application Apache Tomcat 7.0.37
SGBD PostgreSQL 8.4
Outil de gestion de base de données pgAdmin III 1.14
Logiciel de retouche d’images Adobe Photoshop CC 14.0
Navigateur Web Google Chrome 35
Environnement de conception UML PowerAMC 16.5
On va présenter maintenant les logiciels les plus importants parmi ceux situés dans le
tableau 3.1.
3.1.2.1 Eclipse
Eclipse est un environnement de développement intégré (IDE) dont le but est de fournir
une plateforme modulaire pour permettre de réaliser des développements informatiques.
Le choix d’Eclipse se justifie par la multitude des points forts qu’il possède dont les
principaux sont[N16] :
. Une plateforme ouverte pour le développement d’applications et extensible grâce à
un mécanisme de plugins.
. Malgré son écriture en Java, Eclipse est très rapide à l’exécution grâce à l’utilisation
de la bibliothèque SWT.
. Une ergonomie entièrement configurable qui propose selon les activités à réaliser
différentes « perspectives »
. Le gestionnaire de mise à jour permet de télécharger de nouveaux plugins ou nou-
velles versions d’un plugin déjà installées à partir de sites web dédiés.
Pour le développement de notre projet, on a ajouté les deux plugins suivants :
– Android Development Tools (ADT) : C’est un plugin pour l’IDE Eclipse qui est
33
conçu pour offrir un environnement puissant et intégré pour créer des applications
Android[N17].
– Hibernate Tools : C’est un ensemble d’outils pour Hibernate implémenté en tant
qu’une suite intégrée de plugins Eclipse. Il contribue à la génération des fichiers
de mapping.
3.1.2.2 SDK Android
Le SDK Android fournie les librairies et les outils de développement nécessaire pour
compiler, tester, et déboguer les applications Android.
3.1.2.3 Apache Tomcat
Tomcat[N18] est un serveur d’applications Java, c’est à dire qu’il est intégralement écrit
en Java et que les applications web qu’il est capable d’exécuter doivent être développées
en Java. Pour traiter les requêtes entrantes, il existe des connecteurs capables de véhiculer
les requêtes du serveur web frontal au serveur d’applications.
Tomcat est un projet open source, réalisé par la communauté Jakarta, au sein du
groupe Apache.
3.1.2.4 pgAdmin III
pgAdmin[N19] est la plateforme d’administration et de développement libre la plus
populaire et la plus riche pour PostgreSQL.
Cette plateforme est conçu pour répondre aux besoins de tous les utilisateurs, de
l’écriture de requêtes SQL simples aux développements de bases de données complexes.
L’interface graphique supporte toutes les fonctionnalités de PostgreSQL et simplifie l’ad-
ministration.
pgAdmin est développé par une communauté d’experts de PostgreSQL répartis tout
autour du monde et est disponible dans plus d’une douzaine de langues. De plus, c’est un
logiciel libre proposé sous la licence PostgreSQL.
3.1.2.5 Photoshop CC
Photoshop CC est l’application de retouche d’images la plus performante au monde qui
permet d’améliorer, de retoucher et de manipuler les images. C’est un logiciel de la société
34
Adobe qui est mondialement utilisé pour ses capacités hors du commun[N20]. Photoshop
est l’outil le plus utilisé actuellement pour la retouche d’images de qualité professionnelle.
Ses nombreux outils lui permettent d’effectuer quasiment tout ce qui est possible de faire
sur une image.
Ses principales fonctionnalités sont :
. La conception de sélections dans différents modes qui permet de choisir avec une
grande précision les parties de l’image devant subir des modifications.
. Les nombreux outils permettant de détourer tout ou partie d’une image afin d’ef-
fectuer des montages.
. De nombreux filtres permettant des effets spéciaux.
On a utilisé Photoshop dans le design de l’application mobile essentiellement pour
supprimer l’arrière plan des images et parfois leurs ombres.
3.1.2.6 PowerAMC
PowerAMC[N21] est une solution de modélisation et de gestion de métadonnées à la
pointe de l’innovation, destinée aux architectures de données, d’informations et d’entre-
prise.
On a choisi d’utiliser ce logiciel pour créer les diagrammes UML de notre projet.
3.2 Interfaces Homme Machine
Après avoir choisi l’environnement de développement, on va présenter dans cette sec-
tion les différentes interfaces de notre application.
Il faut signaler que lors de la phase d’implémentation, on n’a pas pris compte des rôles
de l’utilisateur dans les projets, mais plutôt, son rôle dans l’application (administrateur
ou utilisateur).
Avant de lancer l’application, on doit démarrer le serveur Tomcat (figure 3.1).
Figure 3.1 – Lancement du serveur Tomcat.
35
3.2.1 Interface d’authentification
En lançant l’application, une requête GET s’exécute pour récupérer la liste des utilisa-
teurs à partir de la base de données. Durant son exécution, un ProgressDialog apparaît sur
l’interface de l’application pour signaler à l’utilisateur que celle-ci est entrain de récupérer
des données (voir figure 3.2).
Figure 3.2 – ProgressDialog de l’interface d’authentification.
Les données demandées sont reçues de la couche Web Service sous forme de fichier
JSON après avoir passé par toutes les autres couches (service et DAO) venant de la base
de données.
Dès la récupération des données, le ProgressDialog disparait afin de donner la main à
l’utilisateur pour entrer son nom d’utilisateur (username) et son mot de passe (password)
comme le montre la figure 3.3.
36
Figure 3.3 – Interface d’authentification.
Dans cette figure, on a utilisé le compte administrateur pour voir les différentes fonc-
tionnalités offertes par l’application.
En cliquant sur le bouton connexion, l’application vérifie les données saisies. Si l’utili-
sateur ne saisit pas son username ou son password, ou qu’il utilise des données non valides,
un message d’erreur spécifique apparaît pour lui signaler l’erreur commise.
Au cas où l’utilisateur saisie des données valides, il pourra accéder à l’interface suivante.
3.2.2 Interface de la liste des projets
En lançant cette interface, une requête GET s’exécute pour récupérer la liste des pro-
jets à partir de la base de données. Durant son exécution, de même que dans l’interface
d’authentification, un ProgressDialog apparaît pour indiquer à l’utilisateur que l’applica-
tion est entrain de récupérer des données (voir figure 3.4).
Dès l’arrivée de ces données, le ProgressDialog disparait et la liste des noms des projets
s’affiche comme le montre la figure 3.5.
37
Figure 3.4 – ProgressDialog de l’interface de la liste des projets.
Figure 3.5 – Interface de la liste des projets.
38
L’interface présentée par la figure 3.5 contient un EditText (qui sert comme un filtre
pour les noms des projets), la liste des projets et un bouton : "Add Project" qui permet
d’accéder à l’interface d’ajout de projet.
3.2.3 Interface présentant le contenu du projet sélectionné
En choisissant l’un des projets de la liste (ALM - PFE par exemple), une nouvelle
interface s’ouvre. Celle-ci contient un menu qui glisse horizontalement.
Dans ce menu, on peut choisir d’afficher les détails du projet sélectionné comme le
montre la figure 3.6, ou bien, on peut choisir d’afficher la liste des Work Items (éléments
de travail) (voir figure 3.7).
Figure 3.6 – Interface des détails du projet.
39
Figure 3.7 – Interface de la liste des Work Items.
En cliquant sur un élément de travail, on peut afficher ses détails.
Dans la figure 3.8, on a choisi d’afficher les détails de l’élément de travail dont le
business key est "ALM-1".
Il est à noter que le type de l’élément de travail apparaît sous forme d’icône qui le
décrit. Par exemple, pour l’élément de travail "ALM-1", il s’agit d’une tâche (Task).
40
Figure 3.8 – Détails de l’élément de travail "ALM-1".
L’utilisateur a aussi la possibilité de cliquer sur l’un des boutons : "Comment Work
Item" (pour commenter un élément de travail) ou "Add Work Item" (pour ajouter un
nouveau élément de travail).
3.2.4 Interface d’ajout de projet
Pour ajouter un nouveau projet, l’utilisateur clique sur le bouton "Add Project" pré-
senté dans la figure 4.5. Alors, une nouvelle interface s’ouvre pour permette à l’utilisateur
de saisir les données relatifs à son projet. La figure 3.9 montre cette interface.
En cliquant sur le menu déroulant (spinner) relatif à "Customer", la liste des clients ap-
paraît (voir figure 3.10). On peut faire de même pour les menus déroulants correspondants
à "Project Status" et "Project Group".
41
Figure 3.9 – Interface d’ajout de projet.
Figure 3.10 – Menu déroulant correspondant à "Customer".
42
En cliquant sur le bouton correspondant à la date de début (Planned Start Date), un
Date Picker (figure 3.11) apparaît pour permettre à l’utilisateur d’entrer la date. De la
même manière, on peut ajouter la date de fin.
On termine la saisie des autres données du nouveau projet, puis on clique sur le
bouton "Save". Alors, une requête POST s’exécute pour enregistrer ce nouveau projet.
Cependant, un ProgressDialog apparaît pour signaler à l’utilisateur que l’application et
entrain de sauvegarder son projet dans la base de données (figure 3.12).
Après l’enregistrement du nouveau projet, l’interface de la liste des projets s’ouvre et
charge de nouveau la liste actuelle des projets (figure 3.13).
Pour vérifier le bon déroulement de l’opération d’ajout de projet, on sélectionne le
nouveau projet. Ainsi, l’interface des détails du projet s’ouvre. D’après la figure 3.13, on
vérifie que les données existantes dans cette interface correspondent bien aux données
ajoutées.
Figure 3.11 – Date Picker.
43
Figure 3.12 – Enregistrement du nouveau projet.
Figure 3.13 – Liste des projets contenant le nouveau projet.
44
Figure 3.14 – Détails du nouveau projet.
3.2.5 Interface d’ajout d’élément de travail
Pour ajouter un nouveau élément de travail, l’utilisateur clique sur le bouton "Add
Work Item" présenté dans la figure 3.7. Alors, une nouvelle interface s’ouvre pour permette
à l’utilisateur de saisir les données relatifs à son nouveau élément de travail. Les figures
3.15 et 3.16 montrent cette interface.
En cliquant sur le bouton "Save", une requête POST s’exécute pour enregistrer ce
nouveau élément de travail dans la base de données.
Après l’enregistrement du nouveau élément de travail, l’interface de la liste des projets
s’ouvre et charge de nouveau la liste actuelle des projets avec leurs éléments de travail.
Pour vérifier le bon déroulement de l’opération d’ajout d’élément de travail, on sé-
lectionne le projet "ALM - PFE" et on choisit d’afficher la liste des éléments de travail.
D’après les figures 3.17 et 3.18, on vérifie que les données existantes dans cette interface
correspondent bien aux données ajoutées.
45
Figure 3.15 – Interface d’ajout d’élément de travail (1).
Figure 3.16 – Interface d’ajout d’élément de travail (2).
46
Figure 3.17 – Listes des éléments de travail contenant l’élément ajouté.
Figure 3.18 – Détails du nouveau élément de travail.
47
3.2.6 Interface d’ajout de commentaire à un élément de travail
Pour commenter un élément de travail, l’utilisateur clique sur le bouton "Comment
Work Item" présenté dans la figure 3.7. Alors, une nouvelle interface s’ouvre pour permette
à l’utilisateur de saisir son commentaire et de choisir l’élément de travail auquel il va
ajouter celui-là. La figure 3.19 montre cette interface.
En cliquant sur le bouton "Save", une requête POST s’exécute pour enregistrer ce
nouveau élément de travail dans la base de données.
Après l’enregistrement du nouveau élément de travail, l’interface de la liste des projets
s’ouvre et charge de nouveau la liste actuelle des projets avec leurs éléments de travail.
Pour vérifier le bon déroulement de l’opération d’ajout de commentaire à l’élément de
travail "ALM-1", on sélectionne le projet "ALM - PFE" et on choisit d’afficher la liste des
éléments de travail. D’après la figure 3.20, on peut s’assurer que le commentaire a été bien
ajouté.
Figure 3.19 – Interface d’ajout de commentaire à un élément de travail.
48
Figure 3.20 – Vérification de l’ajout du nouveau commentaire.
Conclusion
Dans ce chapitre, on a présenté la réalisation du projet ainsi que les différents outils
de développement utilisés pour accomplir cette tâche.
49
Conclusion générale et Perspectives
A travers ce rapport, on a procuré le bilan complet de notre travail qui se situe dans
le cadre de notre projet de fin d’études. Ce travail consiste à concevoir et à réaliser une
solution mobile Android qui a pour objectif la simplification d’accès aux fonctionnalités
usuelles de la solution Web ALM déjà existante à Telnet.
On a entamé ce rapport par une étude du contexte général du sujet, ce qui nous a
permis de dégager la problématique ayant engendré le besoin d’une telle application. Puis,
on a effectué une étude théorique des concepts liés à notre projet et on a choisi parmi ces
derniers, ceux qui sont les plus adaptées à nos besoins. Ensuite, on a identifié les besoins
fonctionnels et non fonctionnels auxquels devra répondre notre application. Par la suite, on
a présenté une conception générale et une conception détaillée de l’application développée
au sein de notre projet. Enfin, on a montré les choix techniques de l’environnement de
travail et on a exposé le travail effectué à travers des captures d’écran.
Pour simplifier la réalisation de notre projet et par contrainte de temps, on n’a pas fait
la relation entre l’utilisateur de l’application et l’ensemble des projets qu’il peut y accéder
ainsi que son rôle dans ces projets. Donc, on peut considérer cette tâche comme perspective
du projet élaboré. Pour enrichir les fonctionnalités de notre application, on peut ajouter
un fil d’actualité qui montre aux utilisateurs les dernières modifications effectuées dans
ALM, c’est-à-dire, par exemple quand un chef de projet ajoute ou commente un élément
de travail, les développeurs de ce projet s’aperçoivent (en consultant leurs fils d’actualités)
de cet ajout sans avoir besoin de consulter la liste des éléments de travail relatifs à ce
projet.
50
Bibliographie
[1] D. Guignard, J. Chable et E. Robles : "Programmation Android : De la conception au
déploiement avec le SDK Google Android 2", EYROLLES, 2010.
[2] P. Gambarotto, "Technologies pour Web Services faciles : REST, JSON", INPT DSI,
ENSEEIHT Département Informatique, Toulouse, France, 2009.
51
Nétographie
[N1] http://doc.pcsoft.fr/?3013072&name=gestion_3tiers consulté le 18/02/2014.
[N2] http://www.journaldunet.com/solutions/expert/51364/comprendre-la-gestion-
du-cycle-de-vie-des-applications--alm--en-2-min.shtml consulté le 05/02/2014.
[N3] http://www.alcyonix.com/articles/google-android-premieres-impressions/
consulté le 06/02/2014.
[N4] http://www.jmdoudoux.fr/java/dej/chap-service-web.htm#service-web-1
consulté le 10/02/2014.
[N5] http://www.jmdoudoux.fr/java/dej/chap-hibernate.htm consulté le 07/05/2014.
[N6] http://cyrille-herby.developpez.com/tutoriels/java/mapper-sa-base-donnees-
avec-pattern-dao/ consulté le 07/05/2014.
[N7] http://www.adproxima.fr/glossaire-208-base-donnees.html consulté le 07/05/2014.
[N8] http://www.commentcamarche.net/contents/814-postgresql-introduction
consulté le 07/05/2014.
[N9] http://notes.mazenod.fr/le-design-pattern-mvc1.html consulté le 18/02/2014.
[N10] http://saoudyihab.voila.net/cours_uml/Diagramme_d_activite.pdf consulté
le 21/02/2014.
[N11] http://support.objecteering.com/objecteering6.1/help/fr/objecteering_
uml_modeler/diagrams/activity_diagrams.htm consulté le 21/02/2014.
[N12] http://dico.developpez.com/html/991-Conception-diagramme-de-sequence.
php consulté le 23/02/2014.
[N13] http://www.uml-sysml.org/diagrammes-uml-et-sysml/diagramme-uml/diagramme-
de-classe consulté le 24/02/2014.
[N14] http://developer.android.com/reference/android/support/v4/view/ViewPager.
html consulté le 01/04/2014.
[N15] http://www.commentcamarche.net/contents/659-merise-modele-conceptuel-
52
des-donnees consulté le 19/02/2014.
[N16] http://jmdoudoux.developpez.com/cours/developpons/eclipse/chap-eclipse-
intro.php#eclipse-intro-1 consulté le 04/02/2014.
[N17] http://developer.android.com/tools/sdk/eclipse-adt.html consulté le 04/02/2014.
[N18] http://www-igm.univ-mlv.fr/~dr/XPOSE2003/tomcat/tomcat.php?rub=3 consulté
le 06/02/2014.
[N19] http://www.pgadmin.org/?lang=fr_FR consulté le 07/05/2014.
[N20] http://www.dicodunet.com/definitions/internet/logiciel-photoshop.htm
consulté le 22/03/2014.
[N21] http://www.sybase.fr/products/modelingdevelopment/poweramc consulté
le 14/03/2014.
53