conception et développement d'une application client/serveur android/tomcat pour la gestion...

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

Signatures des encadrants

M. Aymen ELLOUZE

Signature

Mme Malek BEN YOUSSEF

Signature

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


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


workitemDao.getWorkitems

ByProject(project)

Récupéer la liste des projets

projectDao.getAllProjects()

projectService.listProjects()

Lancer

ProjectListActivity

getProjectList()


S'authentifier

Développeur

:Application_Android :Base_de_données:Couche_DAO:Web_Service :Couche_Service

[Non Valide]

[Valide]

alt


workitemDao.getWorkitems

ByProject(project)

Récupéer la liste des projets

projectDao.getAllProjects()

projectService.listProjects()

Lancer

ProjectListActivity

getProjectList()


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

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

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

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

L

on

g i

nte

ge

r

Lo

ng

va

ria

ble

ch

ara

cte

rs (

30

)

Ide

nti

fia

nt_

11



Wo

rkit

em

Se

ve

rity

idW

Se

ve

rity

na

me

L

on

g i

nte

ge

r

Lo

ng

va

ria

ble

ch

ara

cte

rs (

30

)

Ide

nti

fia

nt_

10



Wo

rkit

em

Sta

tus

idW

Sta

tus

na

me

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

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

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

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

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

L

on

g i

nte

ge

r

Lo

ng

va

ria

ble

ch

ara

cte

rs (

30

)

Ide

nti

fia

nt_

12



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

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

L

on

g i

nte

ge

r

Lo

ng

va

ria

ble

ch

ara

cte

rs (

30

)

Ide

nti

fia

nt_

13



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


[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


[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


[N21] http://www.sybase.fr/products/modelingdevelopment/poweramc consulté

le 14/03/2014.

53

conception et développement d'une application client/serveur android/tomcat pour la gestion...

Documents