Ministère de l'Enseignement Supérieur et de la Recherche

Scientifique

Université de Tunis El Manar

Département des Technologies de l’Information et de la Communication

Projet de fin d'année

Présenté Par

Labiedh Kais & Hermessi Wafa

Intitulé

Conception et développement d’une application web/mobile de gestion de

tâches

Encadrant : M. Moez Ben Haj Hmida

Année universitaire : 2015/2016

2

Signature de l’encadrant

3

Liste des tableaux :

Université de Tunis El Manar .......................................................................................................... 1

Liste des tableaux : .................................................................................................................................. 3

Listes des figures ..................................................................................................................................... 5

Liste des tables ........................................................................................................................................ 6

Introduction générale ............................................................................................................................ 7

Chapitre I : Présentation du projet ..................................................................................................... 8

I.1 Introduction .................................................................................................................................. 8

I.2 Présentation générale du projet .................................................................................................. 8

I.2.1 Problématique ....................................................................................................................... 8

I.2.2 Etude de l’existant................................................................................................................. 8

I.3 Objectifs du projet ....................................................................................................................... 9

I.4 Solution proposée ......................................................................................................................... 9

Conclusion .......................................................................................................................................... 9

Chapitre II : Spécification des besoins............................................................................................... 10

II.1 Introduction .............................................................................................................................. 10

II.2 Besoins fonctionnels ................................................................................................................. 10

II.3 Besoins non-fonctionnels .......................................................................................................... 10

II.4 Traduction des besoins en diagrammes de cas d'utilisation ................................................. 11

II.4.1 Description des acteurs ................................................................................................ 11

II.4.2. Diagramme de cas d'utilisation global .................................................................... 11

II.3.2 Diagramme des cas d’utilisation raffiné .......................................................................... 13

Conclusion : ..................................................................................................................................... 14

Chapitre III : Architecture et conception ......................................................................................... 15

III.1Introduction.............................................................................................................................. 15

III.2 Conception générale ............................................................................................................... 15

III.3. Architecture logicielle ........................................................................................................ 16

III.3.1. Conception générale de l’application Web ................................................................... 16

III.3.2 Conception générale de l’application mobile ........................................................ 17

III.4. Conception détaillée ............................................................................................................... 19

III.4.1. Diagramme de classes ..................................................................................................... 19

III.4.2 Digramme de séquences .................................................................................................. 21

III.4.3 Digramme d’activité ........................................................................................................ 22

Conclusion ........................................................................................................................................ 23

4

Chapitre IV : Réalisation et tests ....................................................................................................... 24

Introduction ...................................................................................................................................... 24

IV.1 Réalisation ................................................................................................................................. 24

IV.1.2. Environnement logiciel ..................................................................................................... 24

IV.1.3. Environnement technique .............................................................................................. 24

IV.1.4. Travail réalisé :................................................................................................................ 27

VI.2.-Tests réalisés: ........................................................................................................................ 30

VI.2.1.Définition : ........................................................................................................................ 30

VI.2.2 Tests unitaires : ................................................................................................................ 30

VI.2.3 Test d'intégration ............................................................................................................. 34

Conclusion : ..................................................................................................................................... 38

Bibliographie ........................................................................................................................................ 40

5

Listes des figures

Figure 1Diagramme des cas d’utilisation global .................................................................................... 12

Figure 2:cas d’utilisation raffiné ............................................................................................................ 13

Figure 3 :Rest API .................................................................................................................................. 15

Figure 4:Graphe décrivant le design pattern MVVM [reference] ......................................................... 17

Figure 5:Architecture de l’application mobile : Patron MVC ................................................................ 18

Figure 6:Diagramme de classes ............................................................................................................. 20

Figure 7:diagramme de séquences : Affichage des tâches affectées à un technicien .......................... 21

Figure 8:Diagramme d’activité : Approuver une tâche ......................................................................... 22

Figure 9:Graphe de l’architecture de l’application web ........................................................................ 26

Figure 10:Rôle de Mongoose ................................................................................................................ 27

Figure 11:Interface d’accueil de l’application Web ............................................................................... 28

Figure 12:Interface d’accueil de l’application mobile ........................................................................... 29

Figure 13:Liste des tâches ..................................................................................................................... 29

Figure 14:Interface des paramètres ...................................................................................................... 30

Figure 15:Logo de mocha ...................................................................................................................... 31

Figure 16:Code source de la vérification du remplissage des champs d’une tâche.............................. 31

Figure 17:Résultat du test : vérification du remplissage des champs d’une tâche ............................... 32

Figure 18:Code source de la vérification du remplissage des champs d’un utilisateur ........................ 33

Figure 19:Résultat du test : vérification du remplissage des champs ................................................... 33

Figure 20:Logo Supertest....................................................................................................................... 34

Figure 21:Séparation des bases de données ......................................................................................... 35

Figure 22:Code source : insertion des champs par défaut .................................................................... 35

Figure 23:Insertion des champs avec succès ......................................................................................... 36

Figure 24:code source : Accès à la page d’accueil ................................................................................. 36

Figure 25:Résultat du test : Succès de l’accès à la page d’accueil ........................................................ 37

Figure 26:Code source de la vérification de l’existence des routes saisies ........................................... 37

Figure 27:Résultat du test : Erreur 404 ................................................................................................. 38

6

Liste des tables Tableau 1Description du diagramme des cas d’utilisation ................................................................... 12

Tableau 2:Description du diagramme des cas d’utilisation raffiné ....................................................... 14

7

Introduction générale

De nos jours, chaque entreprise cherche le meilleur moyen pour augmenter sa

production et de confronter les différents conflits qui peuvent être engendrés par le

manque de coordination et d’organisation au sein de ses différentes équipes. En

effet, vu la croissance des activités au sein des entreprises, la tâche de gérer

efficacement toutes ces actions s’avère de plus en plus complexe. En plus, le

pilotage des données, aujourd’hui, n’est plus une mince affaire. Pour surpasser ces

difficultés, une entreprise doit utiliser des outils optimisés et adaptés, facilitant les

tâches et offrant des fonctionnalités riches et utiles.

Pour cela, nous cherchons à créer une application de gestion des tâches des

employés qui aide à fixer les objectifs à atteindre pour chaque tâche et qui

synchronise le travail de chaque membre auprès de son employeur.

Cette application peut être intéressante surtout pour les entreprises fournissant un

service sur le champ ce qui nécessite le déplacement des employés et la validation

instantanée de leurs tâches. Ceci peut s’avérer intéressant aussi pour les entreprises

à activités critiques telles que la finance, le service technique…

Le présent rapport synthétise le travail que nous avons effectué. Il est organisé en

chapitres comme suit :

– Le premier chapitre donne une présentation générale du projet.

– Le deuxième chapitre intitulé « Spécification des besoins », présente les différents

besoins fonctionnels et non fonctionnels auxquels doit satisfaire l’application.

– La conception de notre solution sera présentée dans le chapitre trois.

– Le quatrième chapitre décrit les tâches accomplies et les tests réalisés.

– Et nous allons finir par une conclusion et des perspectives.

8

Chapitre I : Présentation du projet

I.1 Introduction Ce chapitre a pour objectif de situer le projet dans son contexte général, à

savoir la problématique qui a inspiré la création de notre application, la description du

projet et les objectifs à atteindre.

I.2 Présentation générale du projet

I.2.1 Problématique

Le souci principal de chaque moyenne ou grande entreprise se réduit

essentiellement à la gestion du personnel et à la coordination de leurs tâches afin de

maintenir une ambiance favorable à la productivité et l’évolution de l’entreprise.

Ceci nécessite alors la communication continue entre chaque employé et son patron.

Une telle communication peut s’avérer coûteuse en termes de ressources financières

de l’entreprise ainsi qu’en termes du temps mis pour exécuter une tâche.

Ce temps perdu est en fait expliqué soit par le déplacement des employés, d’où la

difficulté de réaliser des réunions pour discuter les tâches, soit par le manque de

contrôle des délais et de performance de chaque employé.

I.2.2 Etude de l’existant

Les entreprises à structure hiérarchique rencontrent souvent le problème de

communication entre patron et employés, surtout lorsque ces employés sont portés à

se déplacer au cours de leurs journées de travail.

La communication se fait dans ce cas par l’une ou la combinaison des méthodes

suivantes :

- Par téléphone, ce qui peut être coûteux pour une entreprise à grande activité

-Par e-mail que l’employé doit consulter constamment pour être au courant des

nouveaux messages de la part de son patron.

-Par certaines applications web qui présentent une plateforme de communication et

de partage de travail entre les membres d’une équipe dans une entreprise. On peut

Citer comme exemple «Orange Scrum » [1] qui est une application destinée à

faciliter la gestion des projets ainsi que la communication entre les membres.

Mais cette solution reste toujours limitée car elle n’a pas mis en considération le

déplacement des employés. En effet, dans la plupart des entreprises modernes les

employés se déplacent durant leur travail. Ce déplacement est un acteur crucial à la

flexibilité du travail et la décentralisation des services de l’entreprise.

9

I.3 Objectifs du projet

Les problèmes mentionnés précédemment peuvent être résolus par un moyen

qui garantit :

- L’affectation rapide de chaque tâche à l’employé concerné.

-La disponibilité de l’énoncé de chaque tâche ainsi que sa documentation auprès de

l’employé concerné.

-La communication instantanée avec les employés distants.

-Le contrôle du rendement de chaque employé par rapport à l’exécution des tâches

qui lui sont affectées.

I.4 Solution proposée

Ce projet consiste à concevoir et développer une application web/mobile

permettant de gérer les tâches effectuées au sein d’une entreprise. Elle doit aussi

offrir la possibilité d’organiser l’affectation des tâches aux employés ainsi que le suivi

de l’avancement de chaque tâche.

Cette application vise essentiellement à diminuer le temps que prend un rapport de

mission ou une validation verbale de l’accomplissement d’une tâche. Ceci va donc

améliorer considérablement le dynamisme du travail et va créer un espace

d’interaction entre les employés afin de garantir une meilleure productivité et clarté

du travail.

L’application présente aussi des statistiques concernant l’accomplissement des

tâches attribuées aux différents employés. Cette méthode permettra à l’entreprise de

documenter son travail et d’accorder à chaque employé la rémunération ou la prime

de rendement qu’il mérite.

Notre application est destinée essentiellement aux entreprises dans lesquelles les

employés se déplacent souvent, à savoir les techniciens quel que soit leur domaine

d’expertise. Ces employés sont appelés à être présents sur le champ et l’entreprise à

laquelle ils appartiennent doit contrôler les tâches individuelles dont ils sont

responsables.

Conclusion

Tout au long de ce chapitre, nous avons mis notre projet dans son cadre général, à

savoir la présentation du projet et ses objectifs, et nous allons spécifier dans le

prochain chapitre les différents besoins auxquels doit répondre notre application.

10

Chapitre II : Spécification des besoins

II.1 Introduction

La réussite de tout projet dépend de la qualité de son départ. De ce fait,

l’étape de spécification des besoins constitue la base de départ de notre

travail, elle doit décrire sans ambiguïté le logiciel à développer.

Pour assurer les objectifs attendus, il est essentiel que nous parvenions

à une vue claire des différents besoins escomptés de notre projet. Au cours de

ce chapitre, nous allons dégager les fonctionnalités attendues du module "

Gestion des tâches" en définissant les différents cas d’utilisation et quelques

scénarios qui expliquent ces cas.

II.2 Besoins fonctionnels

Le module gestion des tâches doit permettre aux utilisateurs de

consulter les tableaux de bords des tâches et des missions. Ce module doit

mettre à la disposition des acteurs les fonctionnalités suivantes :

-Un administrateur peut créer, modifier ou supprimer un technicien.

-Un administrateur peut créer, modifier ou supprimer des tâches.

-Un administrateur affecte les tâches créées aux techniciens.

-Un administrateur peut envoyer des fiches techniques (pdf, xls..) aux

techniciens.

-Un administrateur peut visualiser les statistiques relatives :

-aux tâches achevées.

-au rendement des employés.

-Un technicien peut accéder à la liste de ses tâches affectées par

l'administrateur.

-Un technicien peut créer et modifier son profil.

-Un technicien peut visualiser les statistiques relatives à ses propres tâches.

-Un technicien peut communiquer avec l'administrateur ou avec ses collègues

à travers un service de messagerie.

-Un technicien peut envoyer un compte-rendu décrivant la réalisation de ses tâches

(tâche effectuée, les problèmes rencontrés dans le cas contraire…).

II.3 Besoins non-fonctionnels -L’application doit être facile à utiliser.

11

-Le temps de réponse de l’application doit être le plus rapide possible.

-L’application doit être portable.

-Possibilité d’optimiser l’application plus tard.

-L’application doit sécuriser les informations de ses utilisateurs.

II.4 Traduction des besoins en diagrammes de cas d'utilisation

Le diagramme des cas d’utilisation est un modèle simplifié du

fonctionnement de l’application qui spécifie les acteurs qui l’utilisent et les

services qu’il leur offre.

II.4.1 Description des acteurs

Un acteur représente une abstraction d'un rôle joué par des entités

externes au système qui interagissent directement avec lui.

Dans cette application, nous identifions deux types d’acteurs : le technicien et

l’administrateur

Technicien: Il s’agit d’un employé de l’entreprise qui est chargé d’accomplir

les tâches qui lui sont assignées.

L’application lui offre plusieurs fonctionnalités telles que consulter ses propres

tâches, envoyer des messages et rédiger un rapport concernant chaque

tâche.

Administrateur: C’est l’acteur qui gère les tâches ainsi que les employés. Il

se charge aussi de contrôler l’avancement du travail au sein de l’entreprise.

La fonctionnalité la plus importante qu’il a est d’affecter les tâches aux employés et

de recevoir les rapports d’exécution de chaque tâche.

II.4.2. Diagramme de cas d'utilisation global

Le diagramme de la figure 1 illustre le rôle de chaque acteur ainsi que

l’étendue de ses responsabilités.

12

Figure 1Diagramme des cas d’utilisation global

Ce diagramme est développé davantage par le tableau 1 :

Titre Accéder aux services de l’application

Description Ce cas d’utilisation permet aux utilisateurs ayant le rôle technicien ainsi que le rôle administrateur d’accéder à leurs comptes sur l’application.

Acteurs Technicien, administrateur

Pré-conditions -L’utilisateur doit être authentifié. -L’utilisateur doit avoir le rôle « Administrateur » pour gérer les tâches de tous les utilisateurs.

Scénario nominal 1. L’utilisateur s’authentifie. 2. L’utilisateur choisit le module « Tâches » dans le menu de la page d’accueil. 3. L’utilisateur est conduit à la page principale du module où il peut visualiser ses différentes tâches ainsi que des statistiques sur leur progrès.

Tableau 1Description du diagramme des cas d’utilisation

13

II.3.2 Diagramme des cas d’utilisation raffiné

Nous avons choisi d’étudier le cas d’utilisation qui définit le rôle de l’administrateur à

savoir la gestion des utilisateurs.

Le diagramme de la figure 2 en décrit les détails :

Figure 2:cas d’utilisation raffiné

14

Le tableau 2 traduit et explique la figure 2 :

Cas d’utilisation : Gérer les utilisateurs

Objectifs : Permettre à l’administrateur de gérer les utilisateurs de la plateforme (ajout, suppression, modification).

Acteur Administrateur

Pré-condition : L’utilisateur est authentifié en tant que administrateur

Post-condition Mise à jour de la base de données

Scénarios nominaux :

1. Consulter la liste des utilisateurs : L’administrateur demande la liste des utilisateurs. Le système retourne la liste de tous les utilisateurs ainsi que les informations relatives. 2. Ajouter un utilisateur : L’administrateur demande d’ajouter un nouvel utilisateur, il choisit le type d’utilisateur à ajouter et remplit le formulaire d’ajout retourné par le système. Le système valide les informations saisies et confirme l’ajout de l’utilisateur en cas de réussite. 3. Modifier un utilisateur : L’administrateur choisit un compte à éditer, modifie les informations désirées et enregistre la modification. Le système valide les informations modifiées et confirme la modification en cas de réussite. 4. Supprimer un utilisateur L’administrateur choisit un compte à effacer. Le système confirme la suppression en cas de réussite.

Tableau 2:Description du diagramme des cas d’utilisation raffiné

Conclusion :

Ce chapitre nous a permis de couvrir les différents besoins fonctionnels et non fonctionnels

auxquels doit satisfaire notre application. Nous avons aussi détaillé ces besoins à travers des

diagrammes de cas d’utilisation pour passer par la suite à la conception de notre application

qui sera présentée dans le chapitre suivant.

15

Chapitre III : Architecture et conception

III.1Introduction

Dans le présent chapitre, nous allons entamer une partie importante du

développement de l’application qui constitue un pont entre la spécification et la

réalisation. Nous allons présenter dans un premier temps la conception générale de

notre application, puis la conception détaillée comprenant les vues statiques via les

diagrammes de classes.

III.2 Conception générale

Notre application consiste en un module web et un autre mobile qui sont en

interaction à travers des services web.

Le mode d’interaction ainsi que la modélisation de l’application peuvent être décrits

par ce graphe :

Figure 3 :Rest API

16

III.3. Architecture logicielle

Nous avons opté pour l’architecture REST pour le développement de notre

application.

L’architecture REST (REpresentational State Transfer) est un style d’architecture

pour les systèmes distribués que nous avons choisi pour ces avantages qui

concernent notre application:

L'application est plus simple à entretenir, parce qu’elle sépare la partie client de

la partie serveur.

Elle permet aussi de ne pas avoir à maintenir une connexion permanente entre le

client et le serveur. Le serveur peut ainsi répondre à d'autres requêtes venant

d'autres clients sans saturer l'ensemble de ses ports de communication.

Une meilleure évolutivité et tolérance aux pannes (un serveur peut être ajouté

facilement pour augmenter la capacité de traitement, ou pour en remplacer un

autre).

Dans un contexte Web :

l'utilisation du protocole HTTP permet de tirer parti de son enveloppe et ses

en-têtes.

l'utilisation d'URI comme représentant d'une ressource permet d'avoir un

système universel d'identification des éléments de l'application [1].

III.3.1. Conception générale de l’application Web

III.3.1.1.Choix de patron de conception

Un patron de conception ou un design pattern est un concept destiné à

résoudre les problèmes récurrents du génie logiciel suivant le paradigme objet. Les

patrons de conception décrivent des solutions standards pour répondre à des

problèmes d’architecture et de conception des logiciels par une formalisation de

bonnes pratiques, ce qui signifie que l’on privilégie les solutions éprouvées (un

patron de conception n’est considéré comme « prouvé » qu’une fois qu’il a été utilisé

avec succès au moins dans trois cas)[4].

Pour l’application web, nous avons choisi le patron MVVM.

MVVM(MODEL VIEW VIEWMODEL) :

17

Ce patron de conception permet, comme le modèle MVC (Modèle-Vue-Contrôleur),

de séparer la vue de la logique et de l’accès aux données en accentuant les

principes de binding et d’événements.

La différence entre MVVM et MVC est le fait que le MVVM se repose sur le

DataBinding et l’évènementiel. Pour plus de clarté, nous détaillant les composants de

ce modèle dans ce qui suit :

MODEL : correspond aux données. Il s’agit en général de plusieurs classes

qui permettent d’accéder aux données.

VIEW : Couche PRÉSENTATION. C’est la présentation graphique de

l’application (l’interface utilisateur)

VIEWMODEL : Peut être simulé à la colle entre le modèle et la vue. Il s’agit

d’une classe qui fournit une abstraction de la vue, il s’appuie sur la puissance

du binding pour mettre à disposition de la vue les données du modèle.

Nous présenterons plus de détail sur le patron de conception MVC dans

l’architecture de l’application mobile.

Figure 4:Graphe décrivant le design pattern MVVM [reference]

III.3.2 Conception générale de l’application mobile

L’architecture de l’application mobile peut être illustrée par le graphique de la

figure 5

18

Figure 5:Architecture de l’application mobile : Patron MVC

Pour l’application mobile, nous avons choisi de travailler avec le patron de

Conception MVC.

Le Modèle-Vue-Contrôleur (en abrégé MVC, de l’anglais Model-View-Controller) est

une architecture et une méthode de conception qui organise l’interface homme-

machine (IHM) d’une application logicielle. Ce paradigme divise l’IHM en

un modèle (modèle de données), une vue (présentation, interface utilisateur) et un

contrôleur (logique de contrôle, gestion des événements, synchronisation), chacun

ayant un rôle précis dans l’interface. Cette méthode a été mise au point

en 1979 par Trygve Reenskaug [12].

Nous l’avons choisi vu ses avantages nombreux :

-Il permet de formaliser l’application et de faciliter la compréhension de son mode de

fonctionnement.

-Il permet de délimiter les différents modules de l’application et de simplifier leur

création.

-La séparation des modules nous permet d’effectuer des changements sur l’un d’eux

sans affecter le reste du code ou le fonctionnement global de l’application.

19

Les composant du modèle MVC sont :

Model : La base de l’application. Il décrit les données et contrôle leur intégrité.

Il comporte la base de données.

Vue : L’interface avec laquelle interagit l’utilisateur. Elle est en interaction avec

le modèle ainsi que le contrôleur.

Contrôleur : Responsable de la synchronisation entre le modèle et la vue. Il

gère les événements reçus par la vue et demande les changements

nécessaires au modèle.

III.4. Conception détaillée

III.4.1. Diagramme de classes

La figure 6 représente le diagramme de classes des entités utilisées dans

notre système :

20

Figure 6:Diagramme de classes

-Utilisateur : c’est la classe qui représente un utilisateur de l’application qui est soit

un technicien soit un administrateur.

-Tâche : c’est l’entité qui représente les tâches gérées par l’administrateur et

affectées au technicien.

-Document : certaines tâches peuvent être accompagnées de documents qui

servent soit à clarifier certains détails ou qui sont à remplir par le technicien

responsable de ces tâches (fiche technique, cahier des charges, contrat…).

-Message : c’est la classe qui définit les messages échangés entre les utilisateurs à

travers un service de messagerie dans l’application.

21

-Rapport : la classe Rapport désigne le compte-rendu retourné par le technicien à

l’administrateur qui décrit le déroulement de sa mission et son résultat : soit la tâche

est accomplie soit elle a présenté certains problèmes que le technicien doit

mentionner.

III.4.2 Digramme de séquences

Le diagramme des séquences suivant décrit le scénario de consultation de la

fiche d’un technicien par l’administrateur:

Figure 7:diagramme de séquences : Affichage des tâches affectées à un technicien

Ce diagramme décrit le déroulement de la recherche d’un technicien et l’affichage de

ses données ainsi que ses tâches.

Il est à noter que l’administrateur peut aussi visualiser les statistiques de progrès de

chaque technicien ce qui permet le calcul juste et efficace des primes de rendement

des employés.

22

III.4.3 Digramme d’activité

Le digramme de la figure 8 illustre le scénario d’approbation d’une tâche qui

met en jeu l’administrateur, le technicien ainsi que le système qui gère l’application.

Figure 8:Diagramme d’activité : Approuver une tâche

23

Après avoir créé une tâche, l’administrateur choisit le technicien à l’effectuer.

Lorsque le technicien concerné reçoit la notification de la nouvelle tâche, il peut

confirmer ou nier sa disponibilité.

Cas idéal :

Le technicien confirme sa disponibilité pour effectuer la tâche.

Le technicien achève la tâche et confirme son exécution.

Si l’entreprise ne reçoit pas de réclamations de la part du client concerné après 24

heures, la tâche est validée et enregistrée dans la fiche du technicien.

Cas alternatifs :

1. Le technicien n’a pas confirmé sa disponibilité : Une notification est envoyée à

l’administrateur qui choisira par la suite un autre technicien pour effectuer la

tâche.

2. Le technicien n’a pas confirmé l’exécution de la tâche : dans le cas où certains

problèmes peuvent surgir lors de l’exécution de la tâche, le technicien rédige

un rapport décrivant ce problème et l’envoie à l’administrateur pour y

remédier.

3. L’entreprise reçoit une réclamation de la part du client dans les 24 heures qui

suivent l’exécution de la tâche : la tâche sera alors marquée comme

inachevée et sera affectée de nouveau à l’un des techniciens disponibles (y

compris celui qui l’a exécutée la première fois).

Notons que chaque tâche, achevée ou non, sera enregistrée dans la fiche de

chaque technicien pour bien suivre son progrès et calculer son rendement.

Conclusion

Dans ce chapitre, nous avons modélisé le fonctionnement de l’application afin

d’avoir une vue globale et simplifiée du système. Nous avons aussi détaillé les

différents modules de l’application ce qui nous a permis d’organiser le travail et

d’avoir une idée claire sur le travail à réaliser. Ce travail est décrit plus précisément

dans le chapitre qui suit.

24

Chapitre IV : Réalisation et tests

Introduction

Après l’étape de conception de l’application, nous allons, dans ce chapitre, décrire la phase de réalisation. Nous allons présenter, en premier lieu, l’environnement du travail utilisé pour le développement de l’application, ensuite, nous allons donner un aperçu sur le travail accompli à travers des captures d’écran.

IV.1 Réalisation

IV.1.2. Environnement logiciel

Dans ce paragraphe nous décrivons les différents outils et logiciels utilisés pour la mise en œuvre de l’application.

-Enterprise Architect [13] :

Pour les besoins de notre projet, nous avons utilisé l’outil de modélisation "Enterprise Architect" qui nous a permis de concevoir l’architecture de notre plateforme ainsi que les différents diagrammes contenus dans ce rapport.

-Adobe Photoshop CS6 [14] :

Adobe Photoshop est un logiciel de traitement d'image. Cette application permet de créer et de modifier des images. Elle nous a été utile lors de la création du logo de l’application ainsi que pour ajuster certaines icones et photos utilisées dans l’application.

-Android Studio (version 1.5.1) [15] :

Comme environnement de développement mobile, nous avons opté pour Android

Studio vu qu’il facilite la correction du code et qu’il fournit un aperçu instantané après

chaque changement sur l’application.

Il nous a aidés aussi à travers son émulateur intégré qui simule un appareil mobile

avec toutes ses fonctionnalités ce qui nous a permis de mieux tester notre travail.

-Web Storm (version 10.0.4)[16] :

WebStorm est un IDE pour les langages Web (HTML, CSS et JavaScript), développé

par l'entreprise JetBrains et basé sur la plateforme IntelliJ IDEA.

IV.1.3. Environnement technique

25

-HTML5/CSS3 [17] :

Ce sont les deux langages utilisés pour créer et mettre en forme (respectivement) les

pages de l’application web.

-Java [18] :

C’est un langage de programmation orienté objet caractérisé essentiellement par sa

portabilité. Nous l’avons utilisé pour coder notre application mobile.

-Node Js [18] :

Node.js est une technologie qui permet d’écrire du javascript coté serveur pour

réaliser des applications webs.Node.js est particulièrement adapté aux projets ayant

besoin de temps réel. Il supporte nativement des technologies comme les

websockets, ce qui permet de créer facilement des applications réactives [5].

-Express Js [19] :

C'est un micro framework pour construire des applications web en Node.js,

-Angular Js [20] :

AngularJS est un framework Javascript très populaire actuellement, visant à

structurer et simplifier le développement d’applications mono-pages (Single Page

Application – SPA).

Il est développé par Google sous licence open-source, il offre les outils nécessaires

pour développer du code bien organisé, modulaire, basé sur l’injection de

dépendances et prêt pour les tests unitaires. [7]

Nous avons utilisé les trois derniers outils mentionnés ci-dessus dans partie web qui

peut être mieux simplifiée à travers ce schéma :

26

Figure 9:Graphe de l’architecture de l’application web

-MongoDB [21] :

C'est un système de gestion de base de données orientée documents, répartissable

sur un nombre quelconque d'ordinateurs et ne nécessitant pas de schéma prédéfini

des données (schemaless).

Il est écrit en C++. Le serveur et les outils sont distribués sous licence AGPL, les

pilotes sous licence Apache et la documentation sous licence Creative Commons2. Il

fait partie de la mouvance NoSQL [8].

Nous l’avons choisi parce qu’il offre plus de souplesse dans le contenu de la base de

données vu qu’il ne se base pas sur un schéma prédéterminé. Il contient aussi des

mécanismes d’agrégation qui facilitent efficacement le code et diminuent le temps de

traitement.

-Mongoose [24] :

Mongoose, est un progiciel open-source de Node.js qui fournit une structure et un

modèle aux données de l’application enregistrées par MongoDB.

Mongoose traduit les données dans la base de données en objets

JavaScript pour être utilisés dans l’application .

27

Figure 10:Rôle de Mongoose

-Xml [22] :

C’est un métalangage en balises qui permet de faciliter l’échange de données entre

de différents systèmes informatiques hétérogènes.

-JSON [23] :

C’est un format de données qui est léger, facile à lire et écrire pour les humains et il

est aisément analysable par les machines. Il est basé sur le langage JavaScript. [1]

Nous l’avons utilisé vu qu’il est la base du langage MongoDB que nous avons choisi

pour traiter la base de données, ainsi que pour manipuler le transfert de données

dans la coté mobile de l’application.

-SQLite [25] :

C’est une bibliothèque écrite en C qui propose un moteur de base de données

rationnelle accessible par le langage SQL [2].

Elle nous a été utile dans l’application mobile vu qu’elle diminue considérablement le

nombre de requêtes vers la base de données en stockant certaines données d’où, la

diminution le temps de traitement et de réponse du système.

-Materialize :

Materialize est un framework créé par Google basé sur le material design qui a servi

comme outil de design du coté web de l’application. Nous l’avons choisi parce qu’il

est riche en composantes simples, modernes et diverses.

IV.1.4. Travail réalisé :

28

Introduction :

Cette partie est consacrée à présenter quelques interfaces de l’application réalisée.

IV.1.4.1. Interfaces Web :

Les différentes interfaces de l’application web ont été créées à l’aide du framework

Materialize dans lequel nous avons choisi des éléments clairs et visuellement

simples.

Les couleurs choisies pour le coté web ainsi que mobile sont principalement:

- un bleu sombre (code hex. #050229)

-un bleu turquoise (code hex. #199a95)

-un rose magenta (code hex. #941152)

Figure 11:Interface d’accueil de l’application Web

IV.1.4.2. Interfaces Mobile :

Les interfaces mobiles ont été créées directement à l’aide du logiciel Android Studio

En respectant les mêmes conventions d’apparence de l’application Web.

29

La figure 12 représente la première interface de l’application mobile, c’est celle qui

permet à l’utilisateur de s’identifier et d’accéder à son espace personnel qui contient

ses tâches, son profil, ses messages ainsi que d’autres services :

Figure 12:Interface d’accueil de l’application mobile

La figure 13 montre la première interface affichée après la connexion de l’utilisateur.

Il s’agit de la liste des tâches affectées à l’utilisateur qu’elles soient effectuées ou

pas, triées par date.Chaque élément de cette liste redirige l’utilisateurs au détails de

la tâche sélectionnée.

Figure 13:Liste des tâches

30

La figure suivante décrit l’interface des paramètres que l’utilisateur peut configurer,

allant de l’affichage des tâches jusqu’à la modification de ses données personnelles

et les informations sur l’application.

Figure 14:Interface des paramètres

VI.2.-Tests réalisés:

Nous allons commencer cette partie par une définition des tests et voir leur

importance dans le cycle de développement d'une application.

VI.2.1.Définition :

« Tester, c'est exécuter le programme dans l'intention d'y trouver des

anomalies ou des défauts ». [9]

Le plan de test définit les étapes à valider par le testeur pour vérifier le bon

fonctionnement de l'application et pour détecter ainsi les erreurs qui pourraient

survenir lors d'une utilisation « normale »de l'application.

Il existe plusieurs types de tests, pour notre application nous avons réalisé des tests

unitaires et des tests d'intégration.

VI.2.2 Tests unitaires :

Le test unitaire est une procédure permettant de vérifier le bon fonctionnement

d'une partie précise d'un logiciel ou d'une portion d'un programme.

V.2.2.1. Outils de test :

Dans notre application nous avons effectué nos tests unitaires en utilisant le

fameux framework de test JavaScript mocha .

31

Figure 15:Logo de mocha

VI.2.2.2. Cas de test :

Test du « TaskController » :

Objectif : Ce test nous permet de vérifier si on peut créer une tâche sans donner sa description Scénario: On va créer une tâche avec la méthode « post » du « Task controller » avec tous ses attributs sauf sa description. La figure suivante illustre le code source du processus de test:

Figure 16:Code source de la vérification du remplissage des champs d’une tâche

32

En utilisant Mocha pour tester ce code, nous avons obtenu le résultat représenté dans la figure 17 :

Figure 17:Résultat du test : vérification du remplissage des champs d’une tâche

Ce résultat montre bien qu’on ne peut pas passer une nouvelle tâche par la méthode

« post » savoir fournir sa description, ce qui est clair dans le message fourni par le

testeur.

Test du « UserController »

Objectif : Ce test nous permet de vérifier si on peut créer un utilisateur sans donner son nom. Scénario: On va ajouter un utilisateur avec la méthode « post » du « User controller » avec tous ses attributs sauf son nom. Le code source est donné par la figure 18 :

33

Figure 18:Code source de la vérification du remplissage des champs d’un utilisateur

Après le lancement du test avec Mocha nous avons obtenu le résultat représenté dans la figure 19 :

Figure 19:Résultat du test : vérification du remplissage des champs

34

Comme le montre la figure précédente, le test a abouti à une erreur : « Bad Status

201 ».Cette type d’erreurs signifie une erreur dans les données envoyées à la base

de données. Dans notre cas, elle a été bien accompagnée avec un message qui

explique qu’on ne peut pas envoyer une requête « post » sans le champ « nom »

rempli.

VI.2.3 Test d'intégration

Dans le monde du développement informatique, le test d'intégration est une

phase dans les tests, qui est précédée des tests unitaires et est généralement

suivie par les tests de validation.

Dans le test unitaire, on vérifie le bon fonctionnement d'une partie précise d'un

logiciel ou d'une portion d'un programme (appelée « unité » ou « module »), dans le

test d’intégration chacun des modules indépendants du logiciel sont assemblés et

testés dans l’ensemble.

VI.2.3.1. Outils de test :

Pour les tests d'intégrations, nous avons choisi d’utiliser Supertest, un package

Node.js qui permet de simplifier l’écriture des requêtes HTTP (une surcouche au

package http disponible dans Node.js).

Figure 20:Logo Supertest

1.3.2 Cas des tests :

Test d’intégration de la base de données :

Objectif : Tester lors de l'ajout d'un utilisateur qu’au niveau de la base de données: - l'ajout de l’attribut « _id » est automatique. - l'ajout de l'attribut « isactif » avec la valeur « false » est automatique. Pour cela nous allons séparer l'environnement de développement de l'environnement de production en créant une copie de test de notre base de données. La figure 20 montre qu’on a choisi de se connecter à la base appelée « pfaAPI_test » si on est dans un environnement de développement et à la

35

base d’origine, appelée « pfaApi » si on est dans un environnement de production.

Figure 21:Séparation des bases de données

La figure suivante montre le code mis en œuvre pour réaliser les conditions à vérifier

qui sont : l’ajout du champ « _id » et « isactif » avec une valeur « false » par défaut.

Figure 22:Code source : insertion des champs par défaut

L’exécution de ce code donne un résultat affirmant la création de l’utilisateur avec les

champs mentionnés avec succès.

36

Ceci est illustré dans la figure 23 :

Figure 23:Insertion des champs avec succès

Test de la route de la page d’accueil Objectif : On va utiliser la route « '/' » avec la méthode « http Get » pour accéder à la page d’accueil. Le code source décrit par la figure 24 consiste à créer cette route pour pouvoir accéder à la page d’accueil.

Figure 24:code source : Accès à la page d’accueil

37

Après l’exécution de ce code avec l’outil Supertest, nous avons confirmé qu’on peut

maintenant accéder à la page d’accueil avec la route « ‘/ ‘» comme montré dans la

figure 25 :

Figure 25:Résultat du test : Succès de l’accès à la page d’accueil

404 Error :

Objectif : Vérifier si on peut passer dans l’adresse URL une route qui n'est définie dans nos routes. Si la route n’existe pas, il faut que l’utilisateur reçoive une erreur « 404 error » qui signifie que l’adresse qu’il cherche est introuvable.

Scénario : Nous allons choisir une route « /random » qui n'est pas définie dans nos routes et on va la tester. La figure 26 décrit le code source de cette vérification.

Figure 26:Code source de la vérification de l’existence des routes saisies

38

Le résultat de ce test est donné par la figure 27.

Figure 27:Résultat du test : Erreur 404

Comme le montre la figure précédente, la route que nous avons choisie n’existe pas,

d’où le système a retourné une erreur 404.

Conclusion :

Dans ce chapitre, nous avons présenté quelques interfaces de du coté web et

mobile de l'application et nous avons démontré quelques scénarios de tests que

nous avons appliqué pour vérifier que l'application fonctionne correctement.

39

Conclusion et perspectives

Dans ce rapport, nous avons exposé les étapes de conception et de développement

de notre application qui consiste à créer une application mobile/web pour la gestion

des tâches dans une entreprise. C'est un exemple concret du rôle des TIC dans le

domaine du développement utile dans la vie courante.

Notre travail s'est déroulé sur trois étapes. Nous avons commencé par une étude de

l'existant, suivie de la proposition d'une solution adéquate.

Dans la deuxième phase, nous avons spécifié les besoins fonctionnels et non

fonctionnels que doit respecter l’application suivis par des diagrammes des cas

d’utilisation mettant en jeu les acteurs qui interagissent avec le système.

La troisième étape concernait la conception de notre application en utilisant des

diagrammes de cas d'utilisation, de classes et de séquences.

Dans la dernière phase, nous avons évoqué les différentes technologies utilisées

ainsi que l'implémentation de notre système.

Ce projet se situe en effet, dans le cadre du projet de fin de la deuxième année du

cycle ingénieur en informatique. Ce projet était une véritable expérience de travail en

collaboration, qui nous a permis de bien gérer la répartition des tâches et de

renforcer l'esprit de partage de connaissances ainsi que la synchronisation de notre

travail.

Cependant, nous pouvons encore améliorer cette application en ajoutant un système

automatique de détection de l’emplacement de chaque employé afin d’optimaliser

l’affectation des tâches en fonction de l’emplacement le plus proche par rapport à

celui de l’employé.

Une autre amélioration concernerait les statistiques du progrès de chaque employé.

On peut certainement améliorer l’algorithme de calcul de ce progrès en ajoutant de

nouvelles variables ou bien par l’ajustement des paramètres utilisés dans le calcul

40

Bibliographie

[1] http://www.orangescrum.com/ (consulté le 15/4/2016 à 12 :26)

[1] https://fr.wikipedia.org/wiki/Representational_State_Transfer (consulté le 2/4/2016

à 19:26)

[1] http://www.json.org/json-fr.html (consulté le 2/4/2016 à 20:00)

[2] https://fr.wikipedia.org/wiki/SQLite (consulté le 2/4/2016 à 20:06)

[4] https://fr.wikipedia.org/wiki/Patron_de_conception (consulté le 7/4/2016 à 19:45)

[5] http://www.toam.fr/06-04-2014-bien-demarer-avec-nodejs/ (consulté le 7/4/2016 à

20 :10)

[7] http://www.opentuto.com/apprenez-a-developper-des-applications-angularjs/ (consulté

le 7/4/2016 à 20:12)

[8] https://fr.wikipedia.org/wiki/MongoDB (consulté le 7/4/2016 à 20:19)

[9] http://perso.ens-lyon.fr/christophe.alias/verif/bardin.pdf (consulté le 7/4/2016 à 20:38)

[12] https://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur (consulté le

16/4/2016 à 19 :55)

[13] http://www.sparxsystems.com.au/products/ea/ (consulté le 17/4/2016 à 11:22)

[14] http://www.adobe.com/fr/products/photoshop.html (consulté le 17/4/2016 à 11:26)

[15] http://developer.android.com/sdk/index.html (consulté le 17/4/2016 à 11:30)

[16] https://www.jetbrains.com/webstorm/whatsnew/ (consulté le 17/4/2016 à 11:31)

[17] https://fr.wikipedia.org/wiki/HTML5 (consulté le 17/4/2016 à 11:26)

[18] https://www.java.com/fr/ (consulté le 17/4/2016 à 11:33)

[19] http://expressjs.com/ (consulté le 17/4/2016 à 11:34)

[20] https://angularjs.org/ (consulté le 17/4/2016 à 11:26)

[21] https://www.mongodb.org/ (consulté le 17/4/2016 à 11:35)

[22] https://fr.wikipedia.org/wiki/Extensible_Markup_Language (consulté le 17/4/2016

à 11:35)

[23] https://fr.wikipedia.org/wiki/JavaScript_Object_Notation (consulté le 17/4/2016 à

11:37)

[24] http://mongoosejs.com/ (consulté le 17/4/2016 à 11:37)

[25] https://www.sqlite.org/ (consulté le 17/4/2016 à 11:37)