Rapport de stage Wangle Mohamed El Mehdi Benabdellah .pdf



Nom original: Rapport de stage Wangle-Mohamed El Mehdi Benabdellah.pdf
Auteur: Mehdi Benabdellah

Ce document au format PDF 1.5 a été généré par Microsoft® Word 2013, et a été envoyé sur fichier-pdf.fr le 02/09/2015 à 17:07, depuis l'adresse IP 41.251.x.x. La présente page de téléchargement du fichier a été vue 444 fois.
Taille du document: 1.9 Mo (47 pages).
Confidentialité: fichier public




Télécharger le fichier (PDF)










Aperçu du document


Stage de fin d’année au sein de l’entreprise Bitdyne

CONCEPTION ET REALISATION D'UNE SOLUTION INFORMATIQUE
VISANT A L’ADMINISTRATION ET LA GESTION DES TACHES DES
EMPLOYES AU SEIN D’UNE ENTREPRISE

RÉALISÉ PAR : MOHAMED EL MEHDI
BENABDELLAH

Année universitaire : 2014/2015

Encadré par: M. Hatim Rih

Remerciements

Je tiens tout d’abord à remercier toutes les personnes qui m’ont aidé afin que
mon stage se déroule dans les meilleures conditions. Je m’adresse plus
particulièrement à:

- Monsieur Hatim Rih, directeur général de Bitdyne ainsi que mon parrain
de stage, qui m’a orienté pendant toute ma période de stage.

- Madame Mouna El Azmi, qui a eu l’amabilité de m’expliquer la finalité
du projet point par point, ce qui m’a aidé à mener à bien mon travail.
- M. Mehdi El Yacoubi et Mme. Najoua Mahi pour leurs
accompagnements et leurs conseils judicieux.

Enfin, je remercie vivement tous les employés de l’établissement pour la
sympathie qu’ils m’ont adressé tout au long de cette période du stage, et
surtout pour leur assistance et leur soutien.

MEHDI BENABDELLAH

2

Résumé
L’objectif de ce projet est la conception et la réalisation d’une application
Web nommée « Wangle ». Cette application permet à un administrateur de
saisir des informations et des données structurées dans des formulaires liées à
des tâches et/ou des actions précises ainsi que de paramétrer des formulaires
dynamiques et exposer les données voulues grâce à un Web Service qui servira
à alimenter l’application même et l’application mobile Android du même nom.
Ce projet a été composé de trois phases. La première phase étant la
collecte des données nécessaire à la spécification des besoins du client puis
l’analyse détaillée et la conception du projet en utilisant le langage UML.
La deuxième qui consiste à créer un Web Service API à l’aide du framework
asp.net qui servira à exposer les données sous format Json pour l’application
mobile et l’application d’administration Web.
Puis finalement la troisième phase qui s’est concrétisée par la réalisation de
l’application Web en utilisant le framework AngularJS. Les différentes parties
de ce projet ont été amplement détaillées dans ce rapport.

MEHDI BENABDELLAH

3

Table des matières
I- Chapitre1 : Contexte général du projet
I.1- Présentation du projet
I.2- Démarche de conduite du projet
I.2.a

Processus de développement

II- Chapitre 2 : Etude fonctionnelle et conception du projet
II.1-

Définition du cahier de charge

II.1.a

Besoins fonctionnels

II.1.b

Utilisateurs de la solution

II.2-

Spécifications fonctionnelle

II.2.a

Introduction

II.2.b

Les acteurs du système

II.2.c

Diagramme de cas d’utilisation

II.2.d

Diagramme de séquence

II.3-

Conception

II.3.a

Propriétés du formulaire dynamique

II.3.b

Diagramme de classe

II.3.c

Les services web

III- Chapitre 3 : Réalisation et mise en œuvre
III.1- Framework et outils utilisés
III.1.a

ASP.NET RESTful API

III.1.b

Entity Framework

III.1.c

AngularJS

III.2- Environnement de développement
III.3- Architecture de l’application
III.3.a

Ecran d’authentification

III.3.b

Tableau de bord

III.3.c

Editeur de formulaires

III.3.d

Tâches

III.3.e

Missions

IV-Conclusion générale
MEHDI BENABDELLAH

4

Introduction générale
Mon projet consiste à réaliser une application web qui permet de paramétrer
les données à exposer via le Service Web et qui permet la saisie d’informations
pour le suivi des actions sur le terrain. Cette application est utilisable par les
commerciaux, les agents de recouvrement, les agents de distribution, les
auditeurs et bien d’autres métiers intéressés par tout ce qui est reporting.
Le présent rapport retrace les phases du déroulement du projet. Il comporte
Trois parties organisées de la façon suivante :
-

Contexte général du projet : Cette première partie décrit le projet et les
objectifs qui lui sont tracés.
- Étude fonctionnelle et technique : Cette partie introduit l’étude des
besoins fonctionnels ainsi que les exigences techniques et
l’établissement d’un cahier des charges, ainsi que l’établissement d’un
schéma de modélisation respectant le formalisme UML.
- Mise en oeuvre : La dernière partie est consacrée à la présentation de
l’architecture adoptée pour l’application, les outils de développement et
la description des interfaces. Enfin, une conclusion sur le travail réalisé
et présenté dans ce rapport.

MEHDI BENABDELLAH

5

Chapitre 1
Contexte général du
projet

MEHDI BENABDELLAH

6

I.

Présentation du projet

Le projet consiste à réaliser une application Web qui permet de paramétrer les
données à exposer via l’API Web.
Le rôle de l’utilisateur de cette application est principalement celui de
l’administrateur. Celui-ci gère en première partie la planification des tâches qui
contient chacune une ou plusieurs actions à réaliser, et affecte ces tâches-là
aux employés de l’entreprise concernée.
Et en deuxième lieu, l’administrateur paramètre des modèles de formulaires
qui vont servir de rapports à rendre après l’accomplissement de la dite-tâche
par l’employé affecté.
Le but principal du projet alors, est d’administrer et gérer correctement les
tâches à affecter aux utilisateurs de l’application mobile (les employés), et
avoir un suivi concret des actions et missions effectuées par chacun d’eux à
l’aide des formulaires paramétrés.

II. Démarche de conduite du projet :
1. Processus de développement :
Le processus de développement définit une séquence d’étapes, en
parties ordonnées, qui concoure à l’obtention d’un système logiciel de qualité
répondant aux besoins des utilisateurs dans un temps prévisible.
Le modèle en V demeure actuellement le cycle de vie le plus connu et
certainement le plus utilisé. Il s’agit d’un modèle en cascade dans lequel le
développement des tests et des logiciels sont effectués de manière synchrone.
Le principe de ce modèle est qu’avec toute décomposition doit être décrite la
recomposition et que toute description d’un composant est accompagnée de
tests qui permettront de s’assurer qu’il correspond à sa description.

MEHDI BENABDELLAH

7

Ceci rend explicite la préparation des dernières phases (validationvérification) par les premières (construction du logiciel), et permet ainsi
d’éviter un écueil bien connu de la spécification du logiciel : énoncer une
propriété qu’il est impossible de vérifier objectivement après la réalisation.
La représentation en V tient d'avantage compte de la réalité, le processus de
développement n'est pas réduit à un enchaînement de tâches séquentielles.
Elle montre que:
-

C'est en phase de spécification que l'on se préoccupe des procédures de
qualification,
- C'est en phase de conception globale que l'on se préoccupe des
procédures d'intégration,
- C'est en phase de conception détaillée que l'on prépare les tests
unitaires.
Le modèle de cycle de vie en V permet d'anticiper sur les phases ultérieures de
développement du produit. En particulier le modèle en V permet de
commencer plus tôt:
-

Plan de tests de qualification,
Plan d'évaluation des performances.

Le processus V est un cycle de développement et un modèle conceptuel de
gestion de projet. Il s'articule autour de 5 étapes :
1. Analyse des besoins.
2. Conception.
3. Réalisation et tests unitaires.
4. Test d’intégration.
5. Validation/Recette.
Illustré en figure ci-dessous,

MEHDI BENABDELLAH

8

Analyse des
besoins

Recette

Conception

Intégration

Développement
et tests unitaires
Figure 1: Cycle en V

Phases du cycle en V :
- Analyse des besoins : cette phase correspond à une étude approfondie
des besoins de l’organisme.
- Conception : Cette phase présente la structure générale du logiciel,
quelle fonctionnalité est traitée par quel module.
- Développement et tests unitaires : C’est la phase de réalisation pendant
laquelle sont développées des briques qui sont ensuite assemblées pour
créer le produit final.
- Intégration : Ce sont là les premiers tests grandeur nature du produit
final. On s’assure qu’il suit les indications des spécifications techniques.
- Recette : Le produit est vérifié une dernière fois en pré-production,
avant d’être mis en production. Le client procède à la recette, pour
vérifier que son expression de besoin est respectée.

MEHDI BENABDELLAH

9

Les travaux réalisés dans le cadre de ce projet concernant les 5 phases sont
détaillés comme suit :

Tableau 1: Phase d’analyse des besoins

Objectifs

- Analyse et compréhension du métier,
- Validation de la compréhension de l’application.

Contraintes

- Choix des questions ciblées afin de tirer le maximum
d’informations.

Pré requis

-Compréhension du métier et des rôles de chaque acteur
dans l’élaboration.

Etape de la
phase

- Planning.

Livrables en
sortie

- Document explicatif des différents besoins fonctionnels et
non fonctionnels.

Critères de fin de phase :
 Compréhension fonctionnelle et technique de l’application par le
développeur.

MEHDI BENABDELLAH

10

Tableau 2: Phase de conception

Objectifs

- Formaliser les étapes préliminaires du développement
- Modéliser le fonctionnement futur du système

Contraintes

- Ambiguïté dans la description des besoins du client.
- Changement d’avis du client

Pré requis

- Maitrise du langage de modélisation

Etape de la
phase

- Diagrammes UML

Livrables en
sortie

- Document explicatif des différents besoins fonctionnels et
non fonctionnels.

Critères de fin de phase :
 Compréhension fonctionnelle et technique de l’application par le
développeur.

MEHDI BENABDELLAH

11

Tableau 3: Phase de développement et tests unitaires

Objectifs

- Développer les modules fonctionnels,
- Valider l’application sur le plan fonctionnel, technique et
ergonomique,
- S’assurer que la solution est cohérente avec les
spécifications et répond aux exigences des utilisateurs.

Contraintes

- Respect du référentiel d’exigence.

Pré requis

- Validation du dossier de spécifications fonctionnelles,
techniques détaillées.

Etape de la
phase

- Développement.

Livrables en
sortie

- Rapport de test (rapports d’exécution des scénarios
fonctionnels et liste des anomalies détectées et corrigées)

- Tests unitaires.

Critères de fin de phase :
 Aucune anomalie bloquante

MEHDI BENABDELLAH

12

Tableau 4: Phase d’intégration

Objectifs

Contraintes

- Test de l’application.

- Respect des exigences et des fonctionnalités.

Pré requis

- Tous les modules fonctionnels de l’application.

Etape de la
phase

- Bilan de projet.

Livrables en
sortie

- Document explicatif des différentes anomalies et
amélioration à apporter à l’application.

Critères de fin de phase :
 L’application répond aux exigences

MEHDI BENABDELLAH

13

Tableau 5: Phase de recette

Objectifs

Contraintes

- Assurer formellement que le produit est conforme aux
spécifications.
- Anomalie bloquante

Pré requis

- Une application complète

Etape de la
phase

- Tests système

Livrables en
sortie

- Le cahier de recette qui contient la liste exhaustive de
tous les tests effectués sur l’application.

- Tests d'acceptation utilisateur.

Critères de fin de phase :
 Validation des fonctionnalités exprimées dans le cahier des charges.

MEHDI BENABDELLAH

14

Chapitre 2
Étude Fonctionnelle et
conception du projet

MEHDI BENABDELLAH

15

I.

Définition du cahier des charges

1. Besoins fonctionnels
L’application offre les fonctionnalités suivantes à l’utilisateur :
 L’authentification de l’utilisateur via un login et un mot de passe.
 L'affichage d'un tableau de bord qui permet de consulter l’ensemble des
tâches planifiées, ainsi que l’historique des tâches accomplies.
 Planifier des tâches ainsi que les actions à effectuer.
 Affecter ces tâches à des employés.
 Créer des formulaires personnalisés qui seront liés à des tâches
spécifiques.

2. Les utilisateurs de la solution
Les utilisateurs visés par l’application, sont les commerciaux, les agents de
recouvrement, les agents de distribution, des auditeurs et tout autre métier
intéressé par les services de l’application.

MEHDI BENABDELLAH

16

II. Spécification fonctionnelle
1. Introduction
Dans cette partie je commence par une description de l’ensemble de

fonctionnalités relatives à chaque module du système globale. Le schéma
suivant présente les différentes relations et dépendances entres ces modules
fonctionnels :

Editeur de formulaires

Planification des tâches

Affectation des missions

Administration du système

Figure1 : Modules du système

MEHDI BENABDELLAH

17

2. Les acteurs du système
Acteur
Employé

Description
Reçoit la liste de l’ensemble des tâches qui lui sont affectées à travers son
application mobile, ainsi que les formulaires à remplir lors de
l’accomplissement d’une tâche.

Administrateur système

Peut consulter/ajouter/modifier/supprimer n’importe quelle entité du
système, et configure les paramètres des modules.

Web Service (API)

Expose les données saisies par l’administrateur sous format JSON pour
alimenter l’application mobile.

MEHDI BENABDELLAH

18

3. Diagramme de cas d’utilisations
Puisque l’application est centrée sur l’administrateur, seul les cas d’utilisations
de celui-ci seront détaillés.
Consulter les tâches
planifiées
Définir des actions
Modifier les tâches
existantes
<<include>>

Suppprimer des
tâches
existantes

Planification de tâches

<<include>>

Authentification

Administrateur
<<include>>

Personnaliser des
formulaires
Modifier des
modèles
existants

Supprimer des
modèles
existants
<<inclure>>

Ajouter des modèles
de rapport
Ajouter une mission

Programmer des missions

Modifier une mission
existante

<<inclure>>

Affecter des missions
à des employés

Supprimer une mission
existante

Figure 2: Digramme de cas d’utilisation de l’administrateur

MEHDI BENABDELLAH

19

4. Diagramme de séquence
4.1.

Authentification

L’authentification sur l’application « Wangle » est basée sur le protocole
OAuth2 qui permet à l’application d’obtenir un accès limité au service
disponible via HTTP par le biais d’une autorisation préalable du détenteur des
ressources.
L’accès est demandé par ce qu’on appelle « un client », et qui peut être un site
internet ou une application web par exemple. Si les ressources
n’appartiennent pas au client, alors ce dernier doit obtenir l’autorisation de
l’utilisateur final, sinon il peut directement obtenir l’accès en s’authentifiant
avec ses propres identifiants.
Pour renforcer la sécurité de l’application, toute les requête dirigées vers le
web service (API) doivent comporter un access-token obtenu lors de
l’authentification de l’utilisateur, cet access-token est passé dans le header
HTTP des requêtes sous la forme suivante : « Bearer + access_token »

MEHDI BENABDELLAH

20

Figure 3: Digramme de séquence de l’authentification

MEHDI BENABDELLAH

21

Au lancement de l’application trois cas se présentent:
1 - Il s’agit d’un premier lancement, l’utilisateur sera redirigé directement vers
l'écran de Login.
2 - L’utilisateur a été déjà authentifié et son Refresh Token est toujours valide
un appel à la méthode token avec les paramètres grant_type = refresh_token
et refresh_token est le refresh token de l’utilisateur, cet appel permet
d’actualiser l’Access Token de l’application.
En cas de succès la méthode Token retourne un objet User qui doit être stocké
dans le cache du serveur pour une utilisation ultérieure, et ensuite l’utilisateur
sera redirigé vers l'écran d’accueil.
Dans le cas contraire ce dernier restera sur la page de Login et sera notifié par
un message d’erreur.
3 - L'utilisateur a déjà été authentifié mais son refresh token a expiré
l’utilisateur sera redirigé vers l'écran de Login.
La vérification de la validation du Refresh Token se fait comme suit:
La date actuelle ne doit pas dépasser le champ issued de l’objet User plus le
REFRESH_TOKEN_TTL qui est de 30 jours.
- L’utilisateur saisit son adresse mail et son mot de passe.
- L’application appel la méthode Token avec le paramètre
grant_type=password.
- Si l’utilisateur est bien authentifié, le serveur renvoi un objet User avec
l’Access Token et le Refresh Token, cet objet doit être stocké sur
l’application pour une éventuelle utilisation et l’utilisateur aura accès à
l’application.
- Si l’utilisateur n’est pas authentifié il sera notifié par un message
d’erreur.

MEHDI BENABDELLAH

22

III. Conception
1. Propriétés du formulaire dynamique
L’une des principales fonctionnalités de l’application est le paramétrage des
formulaires qui permet de construire un formulaire totalement générique, et
ceci grâce à la création dynamique de champs qui sont définis selon un certain
type au niveau du back-office. Le formulaire est alors reconstruit en respectant
les conditions selon lesquelles chaque champ a été enregistré.
Propriété

Tableau 4 : Tableau descriptif des attributs d’un formulaire
Description

fieldId

L’identifiant du champ.

fieldType

Les types prédéfinis sont :
String : Un champ texte
Text : Un champ texte avec des lignes multiples
Boolean : Bouton radio avec 2 options (oui/non)
Int => Un champ qui contient un nombre entier
Decimal => Un champ qui contient un nombre décimal
Select => Une liste de valeurs à choix unique.
Select multiple => Une liste de valeurs à choix multiple.

fieldName
Required

Le label du champ.
Permet de déterminer s’il s’agit d’un champ obligatoire ou facultatif.

MinValue

La longueur minimale du champ de type entier/décimal/text/string

MaxValue

La longueur maximale du champ de type entier/décimal/text/string.

DefaultValue

La valeur par défaut du champ

SelectValues
Placeholder

La liste des valeurs à afficher pour les champs de types Select et select
multiple.
Le placeholder à afficher dans le champ.

Description

Une description du champ.

MEHDI BENABDELLAH

23

2. Diagramme de classe

-UserId
-FirstName
-LastName
-email
-PasswordHash

0..*

1,1

User

UserTask

0..*

: Int
: String
: String
: String
: String

TaskTemplate

0..*

-TaskTemplateId
-TaskTemplateName
-Spontaneous
-DateCreated
-LastModified
-Deleted
-Importance
-Description
-LongDescription

: Int
: String
: Boolean
:Date
:Date
:Boolean
:Int
:String
:String

1,1

-UserTaskId
-TaskName
-Completed
-DueDate
-AlertDate
-DateCreated
-LastModified
-Deleted
-Urgent

:Int
:String
:Boolean
:Date
:Date
:Date
:Date
:Boolean
:Boolean

1,1

TaskAction
0..*

-TaskActionId
-TaskActionName

:Int
:String
1,1

ReportTemplate

ReportField
-ReportFieldId
-FieldName
-IsRequired
-MinValue
-MaxValue
-DefaultValue
-SelectValues
-Placeholder
-Description

:Int
:String
:Boolean
:String
:String
:String
:String
:String
:String

0..*
1,1

-ReportTemplateId
-ReportName
-DateCreated
-LastModified
-Deleted

:Int
:String
:Date
:Date
:Boolean

0..*

Figure 4: Digramme de classes

Description

Classes

La classe des utilisateurs de l’application

User

La classe des tâches. Regroupe les tâches spécifiques à chaque employé et
les tâches spontanées, qui peuvent être faites par n’importe quel employé

TaskTemplate
UserTask
TaskAction

La classe des tâches affectées aux employés
La classe des actions liées à une tâche

ReportTemplate

La classe des formulaires liés à une action

ReportFields

La classe des différents champs composant un formulaire

. Tableau 5 : Tableau descriptif des différentes classes

MEHDI BENABDELLAH

24

3. Les services Web
Un service web est un programme ou, partie d’un programme informatique
permettant la communication et l'échange de données entre les applications et systèmes
hétérogènes dans des environnements distribués. Il s'agit donc d'un ensemble de
fonctionnalités exposées sur internet ou sur un intranet.
Intérêt :
• Décomposition d'une application en briques fonctionnelles ou unités logiques
applicatives.
• Composant réutilisable fournissant des données et des services à d’autres
applications.
• Facilite l'interopérabilité des différents modèles de composants en interne
comme en externe.
• Utilisation et intégration très facilitées de composants métiers de partenaires
• Agrégation de plusieurs services de métiers différents sur un même site.
Invocation :
L’invocation des services web se fait via des appels des contrôleurs de type POST ou
GET, le format utilisé pour l’envoi et le traitement des messages est soit XML ou bien
JSON.
Ce tableau résume une comparaison entre les deux formats de données :
Format
XML

Avantages
+Création de nouveaux types à
l’aide des XSDs.
+XSLT pour la transformation vers
plusieurs formats de sortie.
+XPath/XQuery pour l’extraction
des données.

JSON

+Syntaxe simple, moins de balisage.
+Facilité d’utilisation avec
JavaScript du fait qu’ils ont les
mêmes types de données.

Inconvénients
+Plus de syntaxe pour la
même quantité de données
(comparaison avec JSON)
+Des fois le fichier de retour
dépasse les 2Kb (latence de
chargement).
+Syntaxe simple, nombre de
types pris en charge très
restreint.

Tableau 6 : Tableau comparatif de XML et JSON

Cette comparaison justifie l’utilisation du format JSON dans toute l’application.

MEHDI BENABDELLAH

25

Chapitre 3
Réalisation et mise en
œuvre

MEHDI BENABDELLAH

26

I.

Framework et outils utilisés :

1. .NET RESTful Web API :
REST (Representational State Transfer) est un style d’architecture qui repose
sur le protocole HTTP : On accède à une ressource (par son URI unique) pour
procéder à diverses opérations (GET lecture / POST écriture / PUT modification
/ DELETE suppression), opérations supportées nativement par HTTP.
REST est un style d'architecture, pas un standard. Il n'existe donc pas de
spécifications de REST. Il faut comprendre le style REST et ensuite concevoir
des applications ou des services Web selon ce style.
Bien que REST ne soit pas un standard, il utilise des standards. En particulier :
- URI comme syntaxe universelle pour adresser les ressources,
- HTTP un protocole sans état (stateless) avec un nombre très limité
d'opérations,
-

Des liens hypermedia dans des documents (X)HTML et XML pour
représenter à la fois le contenu des informations et la transition entre
états de l'application,

-

Les types MIME comme text/xml, text/html, image/jpeg,
application/pdf, video/mpeg pour la représentation des ressources.

-

REST concerne l'architecture globale d'un système. Il ne définit pas la
manière de réaliser dans les détails. En particulier, des services REST
peuvent être réalisés en .NET, JAVA, CGI ou COBOL.

MEHDI BENABDELLAH

27

2. Entity Framework (ORM)
Entity Framework est la solution de mapping objet-relationnel proposée
par Microsoft. Son but est de fournir la couche d'abstraction nécessaire aux
développeurs pour qu'ils n'accèdent plus directement à la base de données,
mais par l'intermédiaire d'entités définies par un modèle appelé EDM
(Entity Data Model).
Ce modèle est divisé en 3 parties :
 Le schéma conceptuel : Il regroupe la définition des entités, des
ensembles d'entités et des fonctions utilisées. Ces éléments sont définis
dans un fichier XML appelé CSDL (Conceptual Schema Definition
Language).
 Le schéma logique : Celui-ci correspond à la définition des tables, vues et
procédures stockées déclarées dans la base de données. Toutes ces
informations sont regroupées dans un fichier XML appelé SSDL (Store
Schema Definition Language).
 Schéma de liaison : Il définit les liaisons entre le schéma conceptuel et le
schéma logique. Il associe entre autres les entités déclarées dans le
fichier CSDL aux tables définies dans le fichier SSDL. Ce mapping est
inscrit dans le fichier XML MSL (Mapping Specification Language).

Cette architecture particulière permet une totale indépendance entre les
objets utilisés dans la couche d'accès aux données et les éléments (tables,
vues, procédures stockées) de la base de données. Il est ainsi possible de
modifier le schéma logique sans que cela n'ait d'impact sur la définition des
objets et inversement. Il est juste nécessaire de mettre à jour le schéma de
liaison MSL.

MEHDI BENABDELLAH

28

Lors du traitement d'opérations CRUD (création, lecture, mise à jour et
suppression), le framework utilise le modèle EDM pour construire les
requêtes SQL. A partir d'une entité définie dans le fichier CSDL, il est
possible de retrouver la ou les tables associées décrites dans le schéma
logique grâce au schéma de liaison qui associe les entités aux tables.

3. AngularJS :

AngularJS est un framework Javascript qui permet de déplacer la logique de
présentation du côté client et ainsi la séparer de la logique de l'application qui
reste sur le serveur. Les données sont récupérées auprès de celui-ci via des
requêtes HTTP. Enfin, celles-ci sont interprétées et affichées au visiteur
indépendamment du serveur.
Ce déplacement permet de rendre la navigation sur le site internet beaucoup
plus fluide pour le visiteur.
Cette approche permet donc de séparer complètement le back-end et le frontend, contrairement à l'architecture classique d'un site web. Elle est très utilisée
pour les sites mono-pages.
Parmi les grands atouts de ce framework :
1- Repose en grande partie sur le patron de conception Modèle-VueContrôleur. Ce design pattern qui se base sur la
subdivision conceptuelle de chaque page en un Modèle, une Vue et un
Contrôleur.
2- Lien bilatéral des données entre le modèle et la vue qui permet lors du
chargement de la page de créer le modèle et initialiser les variables des
scopes selon ce qui est déclaré dans le contrôleur et le template.
Ces concepts qui sont au centre du framework, simplifient grandement la
tâche du développement et justifient l’utilisation d’AngularJS dans ce projet.

MEHDI BENABDELLAH

29

II. Environnement de développement
Visual Studio Express 2013 pour le Web et SQL Server

Visual studio permet une gestion aisée des packages et favorise le
développement en javascript grâce à son outil d’auto complétion (intellisense).
La construction du service web API, a aussi été faite grâce au framework
ASP.NET, et visual studio dispose de templates prédisposés qui facilitent
énormément la tâche.
Pour des raisons de compatibilités, SQL Server a été choisi comme SGBD pour
créer et gérer la base de données.

MEHDI BENABDELLAH

30

III. Architecture de l’application
1. Ecran d’authentification:

Au lancement du site, si l’utilisateur n’est pas préalablement authentifié, il est
directement dirigé vers la page d’authentification où il est invité à saisir ses
identifiants. Si ceux-ci sont corrects l’utilisateur est redirigé vers la page
d’accueil, dans le cas échéant un message d’erreur s’affiche à l’écran, et
l’utilisateur devra alors ressaisir ses identifiants.

MEHDI BENABDELLAH

31

2. Tableau de bord

Après une authentification réussie, la page d’accueil s’affiche alors.
Celle-ci se compose de trois panneaux principaux :

MEHDI BENABDELLAH

32

2.1.

Panneaux communs:

2.1.1.

Header :

Qui indique précisément la page courante et le nom de l’utilisateur connecté
ainsi qu’un menu déroulant pour l’aide et la déconnexion.
Grâce au header, l’utilisateur navigue aisément sur toutes les pages du site car
il est constamment notifié du chemin de la page courante de navigation, et
peut basculer à n’importe quel moment entre la hiérarchie de ces pages.

2.1.2.

Menu de navigation :

L’utilisateur a le choix entre afficher un menu détaillé ou le Toggle Menu qui
est plus adapté aux petits écrans.

MEHDI BENABDELLAH

33

2.2.

Panneaux principal:

Pour avoir un meilleur suivi des missions planifiées, et garder toujours un
historique bref et concis sur l’avancement de celles-ci, ce panneau comporte
deux fonctions principales :

2.2.1.

Calendrier des missions :

Ce calendrier montre en bref l’intitulé de toutes les missions programmées,
ainsi que l’employé affecté à chacune d’elles.

MEHDI BENABDELLAH

34

2.2.2.

Liste des missions complétées:

Cette file classée selon les dates d’accomplissement, montre le nom de
l’employé affecté et l’intitulé de la mission complétée.

3. Editeur de formulaires
L’une des fonctionnalités fondamentale de l’application est la création
de formulaires dynamiques selon le besoin de la mission.
L’interface propose alors trois onglets lors de la création ou modification du
formulaire :

MEHDI BENABDELLAH

35

3.1.

Informations générales sur le formulaire :

L’enregistrement d’un formulaire se fait obligatoirement en spécifiant son
nom, puis si désiré une description et le layout de la disposition des champs :

MEHDI BENABDELLAH

36

3.2.

La palette :

La palette offre une multitude de champs classés par type :

MEHDI BENABDELLAH

37

L’utilisateur peut alors choisir le champ désiré et le glisser dans le canevas ou
simplement cliquer sur le bouton
du champ associé

MEHDI BENABDELLAH

38

Chaque champ possède des propriétés paramétrables en cliquant sur le
bouton
associé au champ, et qui permet de définir :
-

Le label du champ
La valeur initiale
Le placeholder
La description du champ sous forme d’un tooltip
La valeur maximale/minimale du champ
Le pattern pour les champs de texte
Déterminer si le champ est obligatoire ou non
Les options pour les checkbox, boutons radio et les listes de sélection

L’utilisateur peut supprimer un champ non voulu à l’aide du bouton

MEHDI BENABDELLAH

39

3.3.

L’aperçu du formulaire :

Lorsque l’utilisateur a fini de créer les champs du formulaire, il peut avoir
un aperçu global du formulaire et a par conséquent la possibilité de pouvoir
basculer sur la palette dans le cas où des modifications sont souhaitées, et ceci
avant d’enregistrer le modèle.

MEHDI BENABDELLAH

40

 Après l’enregistrement du formulaire, les modèles enregistrés sont listés
sous forme de tableau ou il est possible de les modifier ou les supprimer

MEHDI BENABDELLAH

41

4. Tâches:
La création d’un formulaire de rapport se fait dans le but de pouvoir
l’attacher à une ou plusieurs actions spécifiques.
Ces actions sont définies sous le cadre d’une tâche qui sera plus tard
affecté à un employé.
Il existe deux types de tâche :

- Spontanée : qui peut être accomplie par n’importe quel employé
- Standard : qui sera affecté à un employé bien déterminé
La tâche peut comporter une ou plusieurs actions chacune liée à un formulaire.
Cette propriété est gérée dynamiquement à l’aide des boutons

-

: Pour ajouter une nouvelle action

-

: Pour retirer la dernière action ajoutée

-

: Pour réinitialiser les actions entrées

MEHDI BENABDELLAH

42

Le bouton « Enregistrer »
ne s’active que lorsque le
formulaire est
correctement complété

L’utilisateur est notifié si
les champs obligatoires
ne sont pas saisis

Liste déroulante des
modèles de
formulaire déjà
enregistrés

MEHDI BENABDELLAH

43

 Après l’enregistrement de la tâche, les tâches enregistrées sont listés
sous forme de tableau ou il est possible de les modifier ou les supprimer.

MEHDI BENABDELLAH

44

5. Missions :
Cette partie représente le bourgeon final de l’application. En effet, après
avoir créé un modèle de rapport, lié ce modèle à une action et définit cette
action dans une tâche, l’utilisateur peut enfin planifier une mission en
affectant cette tâche-là à un employé donné.
La définition d’une mission se fait à travers de trois éléments principaux :
- Le modèle de la tâche
- Le lieu de la mission
- Les dates d’alerte/limite de la mission

MEHDI BENABDELLAH

45

 Après l’enregistrement de la mission, les missions programmées sont
listés sous forme de tableau, classés par date de dernière modification
où il est possible de les modifier ou les supprimer.
 Les missions programmées apparaissent dans le calendrier du tableau de
bord.

MEHDI BENABDELLAH

46

Conclusion générale
La réalisation de ce projet de fin d’année chez Bitdyne a passé par plusieurs étapes.
Tout d’abord j’ai commencé par une étude préliminaire du contexte générale où j’ai pu bien
identifier le besoin de la société, ensuite l’étude fonctionnelle de ces besoins à partir de
laquelle j’ai établi le cahier des charges, accompagnée d’une étude technique qui m’a
permis de préparer et construire l’environnement technique et technologique dans lequel le
projet sera mis en œuvre. Le travail qui a abouti à la projection de ces deux études pour
pouvoir créer le système et le mettre en marche, tout en passant par les différentes étapes
d’étude comparatives et rédaction du rapport.
Le système résultant est un système performant, solide, et plus précisément correct
gérant les différents modules et workflows avec une vitesse adéquate tout en offrant une
interface ergonomique et moderne.
Cette expérience m’a été bénéfique dans plusieurs sens. En effet, les différentes
réunions avec les responsables et les employés concernés par le projet m’ont permises
d’apprendre énormément en terme de communication, de travail d’équipe ainsi que le sens
de la responsabilité. De plus j’ai pu mettre en pratique les différentes connaissances
théoriques acquises durant mon cursus universitaire concernant la gestion de projets
informatique et la programmation. Sans oublier l’opportunité que j’avais eu de travailler
avec des technologies les plus récentes et les plus performantes sur le marché, et plus
particulièrement le développement avec le framework AngularJS.
Ce stage a donc était une immense opportunité pour confronter le milieu
professionnel. C’était une occasion pour améliorer mon savoir-faire et mon savoir être, de
concrétiser toutes les compétences managériales et en informatique acquises au cours des
années de formation au sein de l’Ecole Nationale des Sciences Appliquées de Tétouan.

MEHDI BENABDELLAH

47



Documents similaires


rapport wangle mehdi benabdellah
rapport de stage wangle mohamed el mehdi benabdellah
sutton guide aide tableau de bord fr
nfp121 final 2013 corrige
prototype des fonctionnalites
petrole


Sur le même sujet..