SlideShare une entreprise Scribd logo
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)

Contenu connexe

Tendances

Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
Ahmed rebai
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
FaissoilMkavavo
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
Hosni Mansour
 
Présentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobilePrésentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobile
Nader Somrani
 
Rapport du projet fin d'etudes
Rapport du projet fin d'etudesRapport du projet fin d'etudes
Rapport du projet fin d'etudes
Tahani RIAHI
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
Madjid Meddah
 
présentation soutenance PFE.ppt
présentation soutenance PFE.pptprésentation soutenance PFE.ppt
présentation soutenance PFE.ppt
Mohamed Ben Bouzid
 
Memoire licence informatique application gestion personnel par herma - zita...
Memoire licence  informatique application gestion personnel  par herma - zita...Memoire licence  informatique application gestion personnel  par herma - zita...
Memoire licence informatique application gestion personnel par herma - zita...
Soumia Elyakote HERMA
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Riadh K.
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique
MehdiOuqas
 
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Symphorien Niyonzima
 
Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application Mobile
Rim ENNOUR
 
rapport-finale-ZoubairWassim.pdf
rapport-finale-ZoubairWassim.pdfrapport-finale-ZoubairWassim.pdf
rapport-finale-ZoubairWassim.pdf
SyrinaGaddour
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
jihene Ab
 
Presentation (SOUTENANCE) : PFE
Presentation (SOUTENANCE) : PFE Presentation (SOUTENANCE) : PFE
Presentation (SOUTENANCE) : PFE
Mhand
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
Anouar Kacem
 
Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats
Ayed CHOKRI
 
Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site Web
Harrathi Mohamed
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Hajer Dahech
 
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed AmineRapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Mohamed Amine Mahmoudi
 

Tendances (20)

Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
Présentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobilePrésentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobile
 
Rapport du projet fin d'etudes
Rapport du projet fin d'etudesRapport du projet fin d'etudes
Rapport du projet fin d'etudes
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
 
présentation soutenance PFE.ppt
présentation soutenance PFE.pptprésentation soutenance PFE.ppt
présentation soutenance PFE.ppt
 
Memoire licence informatique application gestion personnel par herma - zita...
Memoire licence  informatique application gestion personnel  par herma - zita...Memoire licence  informatique application gestion personnel  par herma - zita...
Memoire licence informatique application gestion personnel par herma - zita...
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique
 
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
 
Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application Mobile
 
rapport-finale-ZoubairWassim.pdf
rapport-finale-ZoubairWassim.pdfrapport-finale-ZoubairWassim.pdf
rapport-finale-ZoubairWassim.pdf
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
 
Presentation (SOUTENANCE) : PFE
Presentation (SOUTENANCE) : PFE Presentation (SOUTENANCE) : PFE
Presentation (SOUTENANCE) : PFE
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats
 
Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site Web
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed AmineRapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
 

Similaire à Rapport de projet de fin d'année

Mémoire de Master 2
Mémoire de Master 2Mémoire de Master 2
Mémoire de Master 2
Montrésor Konan
 
Scénarisation d'un Mooc KAABI Intissar TARHOUNI Souhaieb BELWAFA Takwa WESL...
Scénarisation d'un Mooc KAABI Intissar  TARHOUNI Souhaieb BELWAFA Takwa  WESL...Scénarisation d'un Mooc KAABI Intissar  TARHOUNI Souhaieb BELWAFA Takwa  WESL...
Scénarisation d'un Mooc KAABI Intissar TARHOUNI Souhaieb BELWAFA Takwa WESL...
chaima Aridhi
 
STM32F4+Android Application
STM32F4+Android ApplicationSTM32F4+Android Application
STM32F4+Android Application
Hajer Dahech
 
dimensionnement et conception d'un convoyeur à bande
dimensionnement et conception d'un convoyeur à bandedimensionnement et conception d'un convoyeur à bande
dimensionnement et conception d'un convoyeur à bande
Hasni Zied
 
Rapport de Stage Licence 3
Rapport de Stage Licence 3Rapport de Stage Licence 3
Rapport de Stage Licence 3
Dylan Manceau
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
Ben Ahmed Zohra
 
Etude numérique de la diffusion thermique dans les solides: Quelques applicat...
Etude numérique de la diffusion thermique dans les solides: Quelques applicat...Etude numérique de la diffusion thermique dans les solides: Quelques applicat...
Etude numérique de la diffusion thermique dans les solides: Quelques applicat...
YoussefBenmoussa9
 
JOB NETWORK - Réseau social collaboratif d’emploi
JOB NETWORK - Réseau social collaboratif d’emploiJOB NETWORK - Réseau social collaboratif d’emploi
JOB NETWORK - Réseau social collaboratif d’emploi
Youssef NIDABRAHIM
 
Etude critique et amélioration de la gestion de la performance du service mai...
Etude critique et amélioration de la gestion de la performance du service mai...Etude critique et amélioration de la gestion de la performance du service mai...
Etude critique et amélioration de la gestion de la performance du service mai...
darckdaxter
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Yasmine Lachheb
 
application mobile de gestion de panne de BTS
application mobile de gestion de panne de BTSapplication mobile de gestion de panne de BTS
application mobile de gestion de panne de BTS
anis chamkhi
 
Rapport Stage Alstom Otmane Douieb
Rapport Stage Alstom Otmane DouiebRapport Stage Alstom Otmane Douieb
Rapport Stage Alstom Otmane Douieb
OtmaneDouieb
 
Rapportpfe
RapportpfeRapportpfe
Rapportpfe
BILEL TLILI
 
Guide de mise en conformité
Guide de mise en conformitéGuide de mise en conformité
Guide de mise en conformité
smemanager
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
Oussama Ben Sghaier
 
Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010
CLES-FACIL
 
Projet Fin d'année version finale
Projet Fin d'année version finaleProjet Fin d'année version finale
Projet Fin d'année version finale
Houssem AZZOUZ
 
Atelier tapisserie-entreprise
Atelier tapisserie-entrepriseAtelier tapisserie-entreprise
Atelier tapisserie-entreprise
Ahmed BEN DAHMEN
 

Similaire à Rapport de projet de fin d'année (20)

Mémoire de Master 2
Mémoire de Master 2Mémoire de Master 2
Mémoire de Master 2
 
Scénarisation d'un Mooc KAABI Intissar TARHOUNI Souhaieb BELWAFA Takwa WESL...
Scénarisation d'un Mooc KAABI Intissar  TARHOUNI Souhaieb BELWAFA Takwa  WESL...Scénarisation d'un Mooc KAABI Intissar  TARHOUNI Souhaieb BELWAFA Takwa  WESL...
Scénarisation d'un Mooc KAABI Intissar TARHOUNI Souhaieb BELWAFA Takwa WESL...
 
STM32F4+Android Application
STM32F4+Android ApplicationSTM32F4+Android Application
STM32F4+Android Application
 
dimensionnement et conception d'un convoyeur à bande
dimensionnement et conception d'un convoyeur à bandedimensionnement et conception d'un convoyeur à bande
dimensionnement et conception d'un convoyeur à bande
 
Rapport de Stage Licence 3
Rapport de Stage Licence 3Rapport de Stage Licence 3
Rapport de Stage Licence 3
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
Etude numérique de la diffusion thermique dans les solides: Quelques applicat...
Etude numérique de la diffusion thermique dans les solides: Quelques applicat...Etude numérique de la diffusion thermique dans les solides: Quelques applicat...
Etude numérique de la diffusion thermique dans les solides: Quelques applicat...
 
JOB NETWORK - Réseau social collaboratif d’emploi
JOB NETWORK - Réseau social collaboratif d’emploiJOB NETWORK - Réseau social collaboratif d’emploi
JOB NETWORK - Réseau social collaboratif d’emploi
 
Etude critique et amélioration de la gestion de la performance du service mai...
Etude critique et amélioration de la gestion de la performance du service mai...Etude critique et amélioration de la gestion de la performance du service mai...
Etude critique et amélioration de la gestion de la performance du service mai...
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
application mobile de gestion de panne de BTS
application mobile de gestion de panne de BTSapplication mobile de gestion de panne de BTS
application mobile de gestion de panne de BTS
 
Pfe 2015
Pfe 2015Pfe 2015
Pfe 2015
 
Rapport Stage Alstom Otmane Douieb
Rapport Stage Alstom Otmane DouiebRapport Stage Alstom Otmane Douieb
Rapport Stage Alstom Otmane Douieb
 
Rapportpfe
RapportpfeRapportpfe
Rapportpfe
 
Guide de mise en conformité
Guide de mise en conformitéGuide de mise en conformité
Guide de mise en conformité
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
 
Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010
 
Projet Fin d'année version finale
Projet Fin d'année version finaleProjet Fin d'année version finale
Projet Fin d'année version finale
 
Atelier tapisserie-entreprise
Atelier tapisserie-entrepriseAtelier tapisserie-entreprise
Atelier tapisserie-entreprise
 
siem.pdf
siem.pdfsiem.pdf
siem.pdf
 

Rapport de projet de fin d'année

  • 1. 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
  • 3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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)