Vous êtes sur la page 1sur 60

Université cadi ayyad

Faculté des sciences et technique Marrakech

Département D’informatique

MEMOIRE DE PROJET DE FIN D’ETUDE


Pour L’Obtention du Titre :
Licence Science et Technique en Informatique
Filière : Systèmes Informatiques Réparties

Conception et Réalisation d’une plateforme de la FST


Orienté Micro-service
Gestion des commandes (côté Admin)

Soutenu par : Sous la direction de :


AIT ELAATTAR Mohcine Mr. ZOUANI Younes
BOULAANAIT Ismail

Année Universitaire : 2018-2019

1
DÉDICACE

A nos très chers parents


Nul mot ne saurait exprimer à sa juste valeur le
dévouement et le profond respect que nous portons
envers vous
Rien au monde ne pourrait compenser tout ce que
vous avez fait pour nous
Que ce travail soit le témoignage de notre gratitude
et de notre grand amour
Que dieu vous accorde, santé, bonheur et prospérité.
A tous les membres de notre grande et petite
famille
A tous nos amis

2
REMERCIEMENT
Il est agréable de nous acquitter d’une dette de reconnaissance auprès de
toutes les personnes, dont l’intervention au cours de ce projet, a favorisé son
aboutissement. Je profite cette occasion pour adresser notre sincère gratitude
à madame AMIR LAILA, notre responsable de filière à FST
Marrakech. Nos remerciements les plus sincères vont à Monsieur
ZOUANI YOUNESS, notre encadrant à la faculté des sciences et
techniques, pour les conseils qu’il nous a prodigué, Et pour nous avoir
encadré et encouragé tout au long de ce projet, et prodigué ses directives
Précieuses et ses conseils pertinents qui nous ont été d’un appui considérable
dans notre démarche. Son judicieux encadrement ainsi que son assistance
pour la rédaction du rapport. , pour nous avoir encadré et encouragé tout
au long de ce projet, et prodigué ses directives Précieuses et ses conseils
pertinents qui nous ont été d’un appui considérable dans notre démarche.
Que messieurs et dames les membres de jury trouvent ici l’expression de notre
reconnaissance pour avoir accepté de juger notre travail.
Nous tenons également à adresser nos plus sincères remerciements à
l’ensemble du corps enseignant de FSTG, pour avoir porté un vif Intérêt à
notre formation et celle de mes collègues, et pour nous avoir accordé le plus
clair de leur temps, leur attention et leur énergie et ce dans un cadre agréable
de complicité et de respect.

3
Enfin, que tous ceux et celles qui ont contribué de près ou de loin à
l’accomplissement de ce travail trouvent l’expression de nos remerciements et
de notre considération.

4
RESUME

Dans le cadre de notre stage interne dans la faculté des sciences et technique,
nous avons eu l’opportunité de collaborer avec une grande équipe afin de réaliser un
site web dynamique pour la Faculté des Sciences et Techniques de Marrakech.
Le projet proposé est un système qui gère le budget et le personnel de
l’établissement, ainsi que les opérations d’achat est de stockage, dans ce cadre notre
mission était le développement des micro-services permettant de gérer les besoins
exprimé par les entités administratifs de la FSTG et effectuer des commandes
concernant ces besoins.
Ce travail a été effectué en utilisant JEE avec le Framework SPRING,
l’utilisation de cette architecture et ce Framework nous a inspirer pour créer un
générateur de code qui génère des projets compatible avec la technologie utilisé,
ayant tout les fonctionnalités CRUD, ainsi que les interfaces graphiques.

5
ABSTRACT

As part of our internship in the Faculty of Science and Technology, we had the opportunity to work
with a large team to create a dynamic website for the Faculty of Science and Technology of
Marrakech.
The proposed project is a system that manages the budget and the staff of the establishment, as well as
the purchase operations is storage, in this framework our mission was the development of micro-
services to manage the needs expressed by the entities of the FSTG and make orders for these needs.
This work was done using JEE with the SPRING Framework, the use of this architecture and
framework inspired us to create a code generator that generates projects compatible with the
technology used, having all the features CRUD, as well as the graphical interfaces.

6
LISTE DES ABREVIATION
UML Unified Modeling Language
JPA Java Persistence API
JEE Java Enterprise Edition
XML eXtended Markup Language
HTML HyperText Markup Language
API Advanced Programming Interface
JDBC Java DataBase Connectivity
SQL Structured Query Language
CRUD Create,Read,Update,Delete
MS Micro Service
FSTG Faculté des Sciences et Techniques de
Marrakech
HTTP Hypertext Transfer Protocol
IDE Integrated Development Environment
JSON JavaScript Object Notation
REST Representational State Transfer
WS Web Service

7
TABLE DES MATIERES
CHAPITRE 1 13
1. CONTEXTE GENERAL DU PROJET 14
1.1. Organisme d’accueil 14
1.1.1 A propos de FSTG 14
1.1.2 Pédagogie 14
1.1.3 Equipe pédagogique 15
1.1.4 Architecture 15
1.1.5 Services 15
1.1.6 Fiche technique 16
1.2. Rappel du sujet de stage 17
1.3. Problématique et objectifs 17
1.4. Conduite de projet 17
1.4.1 Etapes de réalisation de projet 17
1.4.2 Conduite de projet 18
1.4.2.1. Cycle de développement 18
1.4.2.2. Processus de développement 18
1.4.2.2.1 Choix de la méthode SCRUM 18
1.4.2.2.2 Planification du SPRINT 19
1.4.3 Organisation 20

CHAPITRE 2 21
2. ETUDE PRELIMINAIRE 22
2.1. Introduction 22
2.2. Identification des acteurs 22
2.3. Les besoins fonctionnels 23
2.4. Les besoins non fonctionnels 23
2.5. Cahier de charge 23
2.5.1. Objectifs professionnels 23

8
2.5.2. Objectifs personnels 24
2.5.3. Apport de données sauvegardées 24
CHAPITRE 3 25
3. ANALYSE ET CONCEPTION 26
3.1. Architecture de l’application 26
3.1.1. L’architecture Micro Service 26
3.1.2. Communication entre les Micro Service 27
3.1.3. L’architecture générale de l’application 27
3.2. Le formalisme UML 28
3.2.1. Définition 28
3.2.2. Le choix d’UML 29
3.3. Diagrammes de classe 29
3.4. Diagrammes de cas d’utilisation 32
3.5. Diagrammes de séquence 35
CHAPITRE 4 39
4. OUTILS ET TECHNIQUE 40
4.1. Introduction 40
4.2. Framework utilisé 40
4.2.1. Côté client 40
4.2.2. Côté serveur 41
4.3. Langages utilisés 42
4.3.1. Côté client 42
4.3.2. Côté serveur 43
4.4. Outils 44
4.4.1. Outils de développement 44
4.4.2. Outils de persistance 47
4.5. APIs 48

CHAPITRE 5 53
5. IMPLEMENTATION 54
5.1. Les Difficultés rencontrés 54
5.2. Les captures d’écran les plus pertinent 54

9
TABLE DES FIGURES
Figure 1 Architecture de la FSTG ......................................................................................................... 15
Figure 2 Services de la FSTG ................................................................................................................. 16
Figure 3 fiche technique de la FSTG ..................................................................................................... 16
Figure 4 SCRUM .................................................................................................................................... 19
Figure 5 trello ....................................................................................................................................... 20
Figure 6 L’architecture Micro Service .................................................................................................. 26
Figure 7 Architecture générale de l’application .............................................................................. 27
Figure 8 Diagramme de classe MS 1 .................................................................................................... 30
Figure 9 Diagramme de classe MS 2 ................................................................................................... 31
Figure 10 Diagramme de cas d'utilisation MS 1 .................................................................................. 33
Figure 11 Diagramme de cas d'utilisation MS 2 ................................................................................. 34
Figure 12 Diagramme de séquence MS 1 (création) ........................................................................... 35
Figure 13 Diagramme de séquence MS 1 (accordation) .................................................................... 36
Figure 14 Diagramme de séquence MS 2 (création) .......................................................................... 37
Figure 15 Diagramme de séquence MS 2 (affectation) ...................................................................... 38
Figure 17 Architecture d'angular ......................................................................................................... 40
Figure 16 Angular................................................................................................................................. 40
Figure 18 Spring boot ......................................................................................................................... 41
Figure 19 Spring data ........................................................................................................................... 41
Figure 20 CSS ........................................................................................................................................ 42
Figure 21 html..................................................................................................................................... 42
Figure 22 Bootstrap ............................................................................................................................. 42
Figure 23 TypeScript ........................................................................................................................... 43
Figure 24 JEE ........................................................................................................................................ 43
Figure 25 Architecture JEE .................................................................................................................. 44
Figure 26 NetBeans............................................................................................................................. 44
Figure 27 git ......................................................................................................................................... 45
Figure 28 WebStorm ........................................................................................................................... 46
Figure 29 MySQL ................................................................................................................................. 47
Figure 30 jpa ....................................................................................................................................... 47
Figure 31 tomcat................................................................................................................................. 47

10
Figure 32 micro service edge .............................................................................................................. 50
Figure 33 zipkin .................................................................................................................................... 50
Figure 34 spring sleuth ........................................................................................................................ 51
Figure 35 jasper ................................................................................................................................... 51
Figure 36 création expression de besoin ............................................................................................. 55
Figure 37 modification expression de besoin .................................................................................... 55
Figure 38 création commande ............................................................................................................ 56
Figure 39 liste des commandes ........................................................................................................... 56
Figure 40 paiement ............................................................................................................................. 57
Figure 41 affectation ........................................................................................................................... 57

11
INTRODUCTION GENERALE
Dans le cadre de notre apprentissage en licence Sciences et Techniques Système
Informatique Répartis, et pour ce dernier semestre, nous sommes amenées à passer un stage
de fin d’étude qui a pour objectifs de nous donner un aperçu du travail en entreprise et qui
nous permet de concrétiser ce que nous avons appris tout au long des semestres de la licence.

Nous avons effectué notre stage au sien de la Faculté des Sciences et Techniques de
Marrakech, et notre mission a été de concevoir un site web pour FSTG .Il s’agit de créer un
site web offrant aux utilisateurs (doyen, comptable, chef de département) géré les commande
et les expressions de besoin concernant tout les départements de la FST avec la gestion du
stock et de livraison.

Le présent rapport comporte quatre chapitres. Le premier chapitre définit le contexte général
du projet. Il débute par la présentation de la Faculté FSTG, la présentation et la conduite de
notre projet.

Dans le deuxième chapitre, nous exposons l’étude préliminaire du projet, La première partie
est consacrée à présenter les besoins fonctionnels et les besoins non fonctionnels et la
réalisation du cahier des charges.

Le troisième chapitre présente la partie conception du projet en utilisant le standard UML.

Le quatrième chapitre présente les outils techniques

Au dernier chapitre, il aborde l’étape de la mise œuvre du projet tout en présentant la mise
en place de chaque couche de l’architecture technique du système.

12
CHAPITRE 1
CONTEXTE GENERALE DU PROJET

 Organisme d’accueil
 Rappel du sujet de stage
 Problématique et Objectifs
 Conduite de Projet

Ce premier chapitre décrit le


contexte général du projet. Nous allons
présenter en première section de ce
chapitre l’organisme d’accueil, FSTG
Marrakech, puis nous présenterons le
cadre dans lequel s’inscrit notre projet,
les objectifs à atteindre durant le stage
ainsi que la démarche suivie pour mener
à bien notre travail

13
Chapitre 1 _______ CONTEXTE GENERALE DU PROJET

Contexte général du projet

1. Contexte général du projet

1.1. Organisme d’accueil

1.1.1. A propos de FSTG

La Faculté des Sciences et Techniques de Marrakech (FST Marrakech), est un


établissement d’enseignement supérieur à caractère scientifique et technique.
Elle a été créée en vue de renforcer le potentiel universitaire et technologique de
la région de Marrakech, développer et diversifier les formations offertes en vue
d'une meilleure intégration de l'Université dans son environnement socio-
économique.

1.1.2. Pédagogie

Elle a pour mission :

 La formation dans les domaines scientifiques et techniques


adaptés aux besoins de la région.
 La formation continue des cadres techniques des industries
environnantes.
 La recherche appliquée à des thèmes prioritaires en vue du
développement de l'économie régionale et nationale.

L’enseignement à la FST Marrakech est caractérisé par :

 Un accès limité et sélectif


 Une Formation scientifique technique.

Un système pédagogique innovateur basé sur :

 Les Modules et les semestres


 Les Passerelles entre les filières
 Le suivi et l’orientation
 Le contrôle continu des connaissances, des aptitudes et des
compétences

L’admission des bacheliers scientifiques se fait sur la base d'une sélection


effectuée à partir d’un classement réalisé par le ministère de tutelle et basé
sur les notes obtenues au Baccalauréat.

14
Chapitre 1 _______ CONTEXTE GENERALE DU PROJET

1.1.3. Equipe pédagogique

Pluralité des statuts et pluridisciplinarité des enseignants (enseignants,


enseignants-chercheurs, intervenants de la profession, …) garantissant aux
formations la prise en compte de toutes les composantes de la
professionnalisation : techniques, généralistes et transversales.

1.1.4. Architecture

Figure 1 Architecture de la FSTG

1.1.5. Services

15
Chapitre 1 _______ CONTEXTE GENERALE DU PROJET

•Amphithéâtres
locaux •Salles de TD
d'enseignemet •Salles de TP
•Salles Informatique

•Bibliothèque centrale
bibliothèque •Bibliothèque de département
•Salles de lecture

•Buvette des étudiants


Autres •Service de scolarité
•Service de photocopie

Figure 2 Services de la FSTG

1.1.6. Fiche technique

Raison local
• La faculté des sciences et techniques

Domicile
• B.P 549, Av.Abdelkarim Alkhattabi, Guéliz - Marrakech 40000, Marrakech.

Doyen
• Pr. TAOURIRTE MOHA

Téléphone fixe et fax


• +212 24 43 34 04
• +212 24 43 31 70

Adresse Postale
• BP N°549

E-mail
• doyen@fstg-marraech.ac.ma

Site web
• www.fstg-marrakech.ac.ma

Figure 3 fiche technique de la FSTG

16
Chapitre 1 _______ CONTEXTE GENERALE DU PROJET

1.2. Rappel du sujet de stage

Dans le cadre de notre stage interne dans la faculté des sciences et technique, nous
avons eu l’opportunité de collaborer avec une grande équipe afin de réaliser un site
web dynamique pour la Faculté des Sciences et Techniques de Marrakech.
Le projet proposé est un système qui gère le budget et le personnel de l’établissement,
ainsi que les opérations d’achat est de stockage, dans ce cadre notre mission était le
développement des micro-services permettant de gérer les besoins exprimé par les
entités administratifs de la FSTG et effectuer des commandes concernant ces besoins.
Ce travail a été effectué en utilisant JEE avec le Framework SPRING, l’utilisation de
cette architecture et ce Framework nous a inspirer pour créer un générateur de code
qui génère des projets compatible avec la technologie utilisé, ayant tout les
fonctionnalités CRUD, ainsi que les interfaces graphiques.

1.3. Problématique et objectifs

les opération de la gestion des ressources de la faculté se fait manuellement, alors la


problématique à laquelle notre application répond est d’automatiser ces opérations.
Pour bien détailler les taches attendues de notre application, nous avons arrêté la liste
des objectifs suivante :
 Offrir un moyen qui permet aux entités administratives de la faculté
l’expression de leurs besoins.
 L’affichage des expressions de besoins afin d’être supervisé par
l’administration pour accorder ou refuser une expression de besoin.
 Faciliter la création des commandes à partir des expressions de besoins
validés.

1.4. Conduite de projet

Dans un premier temps, nous avons pris la connaissance du site dynamique que nous
devons réaliser, l’ensemble des interfaces que doivent êtres présentent et le
fonctionnement de chacune d’elles afin de pouvoir le reproduire. Avant de se
pencher sur l’étude détaillée du sujet, une phase de planification est primordiale afin
d’assurer la bonne conduite du projet puisqu’elle participe d’emblée au succès de la
démarche.

1.4.1. Etapes de réalisation de projet


Les différentes phases par lesquelles notre projet a passé sont les suivantes :

17
Chapitre 1 _______ CONTEXTE GENERALE DU PROJET

 Observation et compréhension des besoins : est une phase


primordiale qui assure la bonne conduite du projet puisqu’elle participe
d’emblée de la démarche. De ce fait la nécessité impérieuse de maîtriser
le projet implique la mise en place d’une organisation adaptée en ce qui
concerne l’ordonnancement des tâches.
 Spécification et analyse des besoins : qui consiste à livrer une
spécification complète des besoins et définir l’architecture et la
technologie de base de la conception de notre système.
 La conception : elle vise à modéliser le système selon une vue bien
claire.
 Réalisation: elle s’occupe du développement des codes des différentes
fonctionnalités du système.
 Rédaction du rapport : elle collecte toutes les informations nécessaires
et autorisées à republiées.

Ces phases sont subdivisées en plusieurs tâches à effectuer sur la durée du projet.
Ces tâches sont décrites dans le tableau et la figure qui présente le diagramme de Gantt
adopté dans la réalisation du projet.

1.4.2. Conduite du projet

1.4.2.1. Cycle de développement

Dans un projet informatique, il est très impératif de se baser sur un cycle de vie
de développement sur lequel s’articule l’ensemble des solutions.

1.4.2.2. Processus de développement

1.4.2.2.1. Le choix de la méthode SCRUM

Le choix d’une méthode de travail, qui soit adéquat aux particularités


et exigences d’un projet, doit être élaborée au préalable afin d’obtenir
un produit de qualité qui répond aux besoins et attentes des
utilisateurs. En se retrouvant dans telles conditions de
développement et de travail il s’est avéré nécessaire d’opter pour une
méthode qui à la fois met en œuvre des pratiques de programmation
qui permettent de rendre le logiciel extrêmement flexible, et où les
changements sont acceptés et intégrés. Cette méthode est la méthode
SCRUM. SCRUM est un cadre « Framework » de développement
logiciel itératif et incrémental pour la gestion des projets logiciels, où
une équipe de développement travaille en tant qu'unité pour atteindre
un but commun. Cette méthode permet de concevoir des logiciels en
se concentrant au maximum sur le client, et de répondre activement à
ses demandes, il définit trois rôles : Le propriétaire du produit

18
Chapitre 1 _______ CONTEXTE GENERALE DU PROJET

(Product Owener) : est le « propriétaire » du produit, en tant que


représentant du client. Dans notre projet c’est l’administration de notre
faculté qui est considéré comme un propriétaire du produit. Le
SCRUM Master : c’est le manager du projet, chargé d’assister l’équipe
pour appliquer la philosophie et les pratiques de la méthode agile, il est
celui qui facilite la résolution des problèmes. L’Équipe des
développeurs : elle est composée de tous les corps de métier
nécessaires à l’implémentation d’une fonctionnalité. Elle est
responsable de ses décisions et s’autogère dans notre cas c’est le group
réalisateur du projet.

Figure 4 SCRUM

1.4.2.2.2. Planification du Sprint


Phase 1 : Le « Quoi »

Une fois que le Product Backlog est suffisamment complet et


ordonnancé, on peut planifier un sprint. Le Product Owner revoit alors
avec nous la vision du produit, la roadmap, le plan de livraison (jalons
et deadline), l’objectif du sprint et le Product Backlog. On vérifie les
estimations, confirme qu’elles sont exactes et sélectionne en haut du
Product Backlog les exigences qu’on se sent capable de convertir en
fonctionnalités utilisables d’ici la fin du sprint (il s’agit d’une
prévision et non pas d’un engagement « contractuel »).

19
Chapitre 1 _______ CONTEXTE GENERALE DU PROJET

Phase 2 : Le « Comment »

Ensuite on fait l’inventaire des tâches qui permettront de convertir


les exigences sélectionnées en fonctionnalités utilisables d’ici la fin du
sprint. Toutes les exigences n’ont pas nécessairement besoin d’être
découpées en tâches. En cas de manque de temps on peut se contenter
de découper celles qui seront réalisées au cours des premiers jours du
sprint (elle découpera en cours de sprint les autres exigences). Elle doit
cependant aller suffisamment loin dans l’effort de conception pour
pouvoir vérifier sa prévision.

1.4.3. Organisation
Afin de bien planifier et organiser dans notre travail , nous avons utilisé les
applications suivantes :
 Trello

Figure 5 trello

Trello est un outil de gestion de projet en ligne, basé sur une organisation des projets en
planches listant des cartes, chacune représentant des tâches. Les cartes sont assignables à des
utilisateurs et sont mobiles d'une planche à l'autre, traduisant leur avancement.

Conclusion :

Durant ce premier chapitre qui vise à situer le contexte général du projet nous avons
commencé par une présentation de la faculté et du projet .Ensuit nous avons situé les
objectifs du projet, conduit du projet. Enfin pour clôturer ce chapitre on a annoncé le plan de
notre projet.

Le chapitre suivant sera réservé à l’analyse fonctionnelle et technique du projet

20
Chapitre 1 _______ CONTEXTE GENERALE DU PROJET

CHAPITRE 2
ETUDE PRELIMINAIRE
 Identification des auteurs
 Capture des Besoins fonctionnels
 Les Besoins non fonctionnels
 Le Cahier des Charges

Ce chapitre présente l’étude préliminaire du


projet, qui consiste à effectuer un premier
repérage des besoins fonctionnels et techniques
du projet

21
Chapitre 2 ETUDE PRELIMINAIRE

2. Etude préliminaire

2.1. Introduction

Le présent chapitre nous permet d’identifier toutes les fonctionnalités de notre futur système
pour chaque type d’utilisateur, et ceci en recensant les besoins fonctionnels et d’appréhender
la liste des exigences traduites par les besoins non fonctionnels. Ceci se fera par
l’identification des acteurs et la définition de tous les besoins fonctionnels et non fonctionnels.

2.2. Identification des acteurs

 chef d’entité administrative :

Il s’occupe d’opération concernant le besoin (création, paiement …) .

 Doyen :

Le contrôle et la supervision de tout les operations (besoin et commande).

 Comptable :

Il s’occupe d’opération concernons la commande (création, paiement …).

22
Chapitre 2 ETUDE PRELIMINAIRE

2.3. Les besoin fonctionnels

Les besoins fonctionnels auxquels doit répondre notre système :

 La création des commandes et besoin.


 Indiquer les besoins satisfaits par chaque élément de commande.
 Consulter la liste des commandes et la liste des paiements.
 Modifier ou bien supprimer l’affectation des éléments de commande
aux expressions de besoin.

2.4. Les besoins non fonctionnels

Les besoins non fonctionnels auxquels doit répondre le système :

 Imprimer les informations concernant les commandes et les


besoins.
 Temps de réponse minimum.
 Utilise les micro-service edge.

2.5. Cahier de charge


2.5.1. Objectifs professionnels

Afin de simplifier l’exercice de ses missions, la faculté des sciences et


techniques a adopté le choix de mettre son site dynamique.

Pour bien détailler les taches attendues de notre application, nous avons arrêté
la liste des objectifs suivante :
 Offrir un moyen qui permet aux entités administratives de la faculté
l’expression de leurs besoins.
 L’affichage des expressions de besoins afin d’être supervisé par
l’administration pour accorder ou refuser une expression de besoin.
 Faciliter la création des commandes à partir des expressions de besoins
validés.

2.5.2. Objectifs personnels

 La maitrise des langages de programmation utilisée.

23
Chapitre 2 ETUDE PRELIMINAIRE

 Savoir gérer un projet de manière professionnel et structuré.


 Finaliser notre formation informatique et technique par la mise en pratique
des compétences acquises.
 Développer nos connaissances informatiques.
 Confronter à des situations professionnelles.
 Etre créatif (es) et avoir de nouvelles idées.
 Le travail en groupe sur un projet comme celui-là, nous aide à faire un
échange d’idées et d’information avec une répartition de tâches.
 Développer le sens du travail en équipe, le sens de relationnel et des
responsabilités

2.5.3. Apport de données sauvegardées

La base de données va permettre une amélioration dans les travaux effectués par les
utilisateurs, en l’occurrence elle offrira :
 Meilleure gestion de l’information.
 Disponibilité et accès rapide à l’information.
 Diminution de l’utilisation du support papier pour la manipulation de
l’information.
 Réduction des délais de manipulation de l’information.
 Stockage et archivage surs des données.

Conclusion :

Au cours de ce chapitre, nous avons détaillé l’analyse de notre projet .la première partie
consiste à capturer les besoins fonctionnels et non fonctionnels, ensuite la présentation du
cahier des charges.

Dans ce chapitre qui suit, nous présentons l’étape de conception du système.

24
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

CHAPITRE 3
ANALYSE ET CONCEPTION

 Architecture de l’application
 Démarche de conception
 Diagrammes de cas d’utilisation
 Diagrammes de séquence
 Diagramme de classes

Ce chapitre définit l’architecture et la


technologie de base de la conception de
notre système.

25
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

3. Analyse et conception

3.1. Architecture de l’application

3.1.1. L’architecture Micro Service

Figure 6 L’architecture Micro Service

L’architecture Micro-services répond à des problèmes rencontrés par les


entreprises, parmi ces problèmes :

 comment faire en sorte que les applications proposées en ligne soient


toujours disponibles et ne souffrent jamais de coupure ou de ralentissement,
quelle que soit l'affluence des utilisateurs sur celles-ci ?

26
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

 les entreprises se livrent à une "guerre de la mise à jour". Il faut que


l'entreprise soit capable de faire évoluer son application de façon très
fréquente et de répondre rapidement aux nouvelles fonctionnalités que
propose la concurrence.
 Les technologies utilisées pour développer ces applications évoluent très vite
et les nouveautés offrent parfois des avantages énormes. Comment les
entreprises peuvent-elle s'adapter rapidement pour tirer profit de ces
évolutions ?

Pour remédier à ces problèmes l'architecture Micro-services propose une solution


en principe simple : découper une application en petits applications fine, appelés
Micro services et se concentre sur un ensemble limité de traitements, chaque
application est indépendante au niveau de :
o Base de donnés
o Serveur
o Environnement d’exécution

3.1.2. Communication entre les MS

La communication entre les MS se fait via un style d’architecture « REST »,


c’est web service qui permet la communication entre deux application dans un
monde hétérogène a travers l’envoi des liens sous forme de requête JSON et la
réception d’une réponse JSON.

3.1.3. Architecture générale de l’application

Les MS constituant l’application ont l’architecture suivante :

Figure 7 Architecture générale de l’application

27
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

Cette architecture est respecté par l’ensemble des MS , elle se compose de :

 Présentation : interface usager et présentation basé sur HTML et JavaScript.


 Logique du logiciel : c’est la logique de l’application, elle est basé principalement sur
IOC (Inversion of control), le principe de ce concept est d’éviter la modification d’un
code qui est déjà testé et validé, pour cela on introduit une class mère qui contient des
méthodes abstraite et qui seront redéfinit par des classes filles.
 Logique des données : Base de données.

3.2. Le formalisme UML

3.2.1. Définition

UML, (Unified Modeling Language), que l'on peut traduire par "langage de
modélisation unifié" est une notation permettant la modélisation d'un problème.
Ce langage est né de la fusion de plusieurs méthodes existantes auparavant, et est
devenu la référence en termes de modélisation objet. Entre 1910 et 1990, de
nombreux analystes ont mis au point des approches orientées objets, ainsi en
1994 il existait plus de 50 méthodes objet. Toutefois seules 3 méthodes ont
véritablement émergé :

 La méthode OMT de Rumbaugh


 La méthode BOOCH’93 de Booch.
 La méthode OOSE de Jacobson (Object Oriented Software Engineering)

A partir de 1994. Rumbaugh et Booch (rejoints en 1995 par Jacobson) ont uni
leurs efforts pour mettre au point la méthode unifiée incorporant les avantages de
chacune des méthodes précédentes. La méthode unifiée à partir de la version 1.0
devient UML (Unified Modeling Language), une notation universelle pour la
modélisation objet. UML 1.0 est soumise à l’OMG1 en janvier 1997 mais elle ne
sera acceptée qu'en novembre 199 7dans sa version 1.1, date à partir de laquelle
UML devient un standard international cette méthode représente un moyen de
spécifier, représenter et construire les composantes d'un système informatique.
En effet, la notation unifiée définit 9 diagrammes pour représenter les différents
points de vue de modélisation. Ces diagrammes permettent de visualiser et de
manipuler les éléments de modélisation. Les diagrammes définis par UML, sont
les suivants :

 Les diagrammes de cas d'utilisation : représentation des fonctions du


système du point de vue de l'utilisateur

28
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

 Les diagrammes de séquence : représentation temporelle des objets et de


leurs Les diagrammes d'activités représentation du comportement d'une
opération en termes d’actions.
 Les diagrammes de composants : représentation du code en termes de
modules, de composants et sur tous des concepts du langage ou de
l'environnement d’implémentation.
 Les diagrammes de classes : représentation de la structure statique en
termes de classes et de relations.

3.2.2. Le choix de UML

 Vu que l’application doit être robuste, extensible et modulaire, une


modélisation objet apparait la plus adaptée. En effet, l’objet a fait ses
preuves dans la réalisation d'applications temps réel. C'est pourquoi nous
avons opté pour UML comme langage de modélisation.
 Ce choix peut être justifié également par plusieurs raisons La notation
UML facilite la compréhension et la communication d'une modélisation
objet.
 La notation UML, par définition, n'est pas spécifique à un langage de
programmation objet, elle peut donc être utilisée avec n'importe quel
langage tel que C#, J#, JAVA ou C++ UML est aujourd'hui un standard,
adopté par les grands constructeurs de logiciel du marché. Durant notre
étude du système, nous avons utilisé trois diagrammes d'UML, il s'agit du
diagramme des cas d'utilisation, les diagrammes de séquences, et le
diagramme de classes.

3.3. Diagramme de classe :

Le diagramme de classes permet de représenter l’aspect statique du système en termes


de classes et des relations entre ces classes, en identifiant les différents attributs et
méthodes qui reflètent respectivement les propriétés et les services offerts par notre
système.

3.3.1. Le premier MS : gestion des expressions des besoins

29
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

Figure 8 Diagramme de classe MS 1

La classe ExpressionBesoin contient une liste des éléments ExpressionBesoinItem

30
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

3.3.2. le deuxième MS : gestion des commandes

Figure 9 Diagramme de classe MS 2

La classe Commande qui correspond à un fournisseur dispose des listes suivantes :

 La liste des éléments de la commande (CommandeItem)


 La liste des paiements effectués pour cette commande (Paiement)

La classe CommandeItem a la liste des CommandeItemExpressionBesoin : c'est-à-dire à


quelle expression des besoins correspondent cet élément de commande.

31
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

3.4. Diagramme de cas d’utilisation

Un cas d'utilisation représente un ensemble de séquences d'actions réalisées par le


système et produisant un résultat observable intéressant pour un acteur particulier.
Pour constituer les cas d'utilisation, il faut considérer l'intention fonctionnelle de
l'acteur par rapport au système dans le cadre de l'émission ou de la réception de
chaque message. En regroupant les intentions fonctionnelles en unités cohérentes,
nous obtenons les cas d'utilisation.

Comme représenté sur le diagramme ci-dessous, les cas d'utilisations majeurs offerts
par le système sont :

32
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

3.4.1. Le premier MS : gestion des expressions des besoins

Figure 10 Diagramme de cas d'utilisation MS 1

Ce diagramme décrit les cas d’utilisation pour les acteurs : chef d’entité
administrative , doyen de la faculté en ce qui concerne la manipulation des
expression de besoin

33
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

3.4.2. le deuxième MS : gestion des commandes

Figure 11 Diagramme de cas d'utilisation MS 2

Ce diagramme décrit les cas d’utilisation pour les acteurs : Comptable en


ce qui concerne la manipulation des commande

34
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

3.5. Diagramme de séquence

3.5.1. Le premier MS : gestion des expressions des besoins

 Création d’expression de besoins

Figure 12 Diagramme de séquence MS 1 (création)

 

35
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

 Accorder d’un expression de besoin

Figure 13 Diagramme de séquence MS 1 (accordation)

2.5.2. Le deuxième MS : gestion des commandes

 Création d’une commande

36
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

Figure 14 Diagramme de séquence MS 2 (création)

 Affecter une commande aux expressions de besoins

37
Chapitre 3 ____ ___ ANALYSE ET CONCEPTION

Figure 15 Diagramme de séquence MS 2 (affectation)

38
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

CHAPITRE 4
OUTILS ET TECHNIQUES

 Introduction
 Les Framework utilisés
 Les langages utilisés
 Les outils et API’s

Ce chapitre traite
l’architecture technique
adoptée, une présentation
des différents Framework
utilisés.

39
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

4. Outils et techniques.
1.1 Introduction.

Lors de la discussion à propos du choix des technologies et Framework à


utiliser, nous avons été amenés à respecter certains critères et exigences,
dont je cite :
• L’application doit respecter la notion de portabilité, d’où le choix
du JAVA et plus précisément JAVA EE.
• Avoir les caractéristiques et la puissance d’une application desktop.
• Etre adaptable à l’évolution (implémentation et intégration progressive).
Afin de réaliser ces objectifs, nous avons opté pour les Framework et
technologies suivants :

1.2 Frameworks utilisés.


1.2.1 Cote client.
Angular :

Angular est un framework Javascript côté client qui permet de


réaliser des applications de type "Single Page Application". Il
est basé sur le concept de l'architecture MVC (Model View
Controller) qui permet de séparer les données, les vues et les
différentes actions que l'on peut effectuer.
Figure 16 Angular
Architecture :
Angular est aujourd'hui basé sur une architecture de composants
complètement indépendants les uns des autres. Une fois le
composant principal chargé, il analyse ensuite la vue html
correspondant à celui-ci et détecte si il comporte des composants
imbriqués. Si c'est le cas, Angular va trouver toutes les
correspondances et exécuter le code lié a celles-ci. On peut
imbriquer autant de composants que l'on souhaite

Figure 17 Architecture d'angular

40
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

1.2.2 Cote serveur.


Spring boot.

Spring Boot est un projet ou un micro framework qui a


notamment pour but de faciliter la configuration d’un projet
Spring et de réduire le temps alloué au démarrage d’un projet.
Pour arriver à remplir cet objectif, Spring Boot se base sur
Figure 18 Spring boot plusieurs éléments :

Un site web qui vous permet de générer rapidement la


structure de votre projet en y incluant toutes les dépendances
Maven nécessaires à votre application.

L’utilisation de « Starters » pour gérer les dépendances.


Spring a regroupé les dépendances Maven de Spring dans des
« méga dépendances » afin de faciliter la gestion de celles-ci.
Par exemple si vous voulez ajouter toutes les dépendances pour
gérer la sécurité il suffit d’ajouter le starter « spring-boot-starter-
security ».

Spring data.

Spring Data JPA fournit une implémentation de la


couche d’accès aux données (DAO)pour une application
Spring. C’est une brique très pratique car elle permet de
ne pas réinventer la roue de l’accès aux données à

Figure 19 Spring data chaque nouvelle application et donc de se concentrer sur


la partie métier. Il y a quelques bonnes pratiques à
respecter lors de l’utilisation de Spring Data JPA : par
exemple, limiter le chargement des objets inutiles pour
optimiser les performances.

41
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

1.3 Les langages utilisés.


1.3.1 Cote client.

HTML :
Html est le format de données conçu pour représenter
les pages web. C’est un langage de balisage permettant d’écrire
de l’hypertexte, d’où son nom. HTML permet également de
structurer sémantiquement et logiquement et de mettre en
Figure 21 html forme le contenu des pages, d’inclure des ressources
multimédias dont des images, des formulaires de saisie, et des
programmes informatiques.

CSS :

CSS est un langage informatique utilisé sur l'internet pour


mettre en forme les fichiers HTML ou XML. Ainsi, les
feuilles de style, aussi appelé les fichiers CSS, comprennent
du code qui permet de gérer le design d'une page en HTML.
Figure 20 CSS

Bootstrap :

Bootstrap est une collection d'outils utile à la création


du design (graph me, animation et interactions avec la page
dans le navigateur ... etc ) de sites et d'applications web. C'est
Figure 22 Bootstrap
un ensemble qui contient des codes HT ML et CSS, des
formulaires, boutons, outils de navigation et autres éléments
interactifs, ainsi que des extensions JavaScript en option.

42
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

TypeScript :

TypeScript est un langage de programmation libre et open source


Figure 23 TypeScript développé par Microsoft qui a pour but d'améliorer et de sécuriser la
production de code JavaScript. C'est un sur-ensemble de JavaScript
(c'est-à-dire que tout code JavaScript correct peut être utilisé avec
TypeScript).

TypeScript permet un typage statique optionnel des variables et


des fonctions, la création de classes et d'interfaces, l'import de modules,
tout en conservant l'approche non-contraignante de JavaScript.

1.3.2 Cote serveur.

Plateforme JEE
a. Pourquoi la technologie JEE ?
Figure 24 JEE

J2EE est une plate-forme fortement orientée serveur pour le développement et


l'exécution d'applications distribuées. Elle est composée de deux parties essentielles :

 un ensemble de spécifications pour une infrastructure dans laquelle s'exécutent les


composants écrits en Java : un tel environnement se nomme serveur
d'applications.
 un ensemble d'API qui peuvent être obtenues et utilisées séparément. Pour être
utilisées, certaines nécessitent une implémentation de la part d'un fournisseur
tiers.

Sun propose une implémentation minimale des spécifications de J2EE : le J2EE


SDK. Cette implémentation permet de développer des applications respectant les
spécifications mais n'est pas prévue pour être utilisée dans un environnement de
production. Ces spécifications doivent être respectées par les outils développés par
des éditeurs tiers.

43
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

L'utilisation de J2EE pour développer et exécuter une application offre plusieurs


avantages :

 une architecture d'applications basée sur les composants qui permet un découpage
de l'application et donc une séparation des rôles lors du développement
 la possibilité de s'interfacer avec le système d'information existant grâce à de
nombreuses API : JDBC, JNDI, JMS, JCA ...
 la possibilité de choisir les outils de développement et le ou les serveurs
d'applications utilisés qu'ils soient commerciaux ou libres

J2EE permet une grande flexibilité dans le choix de l'architecture de l'application


en combinant les différents composants. Ce choix dépend des besoins auxquels doit
répondre l'application mais aussi des compétences dans les différentes API de J2EE.
L'architecture d'une application se découpe idéalement en au moins trois tiers :

 la partie cliente : c'est la partie qui permet le dialogue avec l'utilisateur. Elle peut
être composée d'une application standalone, d'une application web ou d'applets
 la partie métier : c'est la partie qui encapsule les traitements (dans des EJB ou des
JavaBeans)
 la partie données : c'est la partie qui stocke les données

Pour des raisons diverses, ces services sont conçus à base d’applications
distribuées reposant sur plusieurs niveaux à savoir la couche client, la
couche donnée et une ou plusieurs couches intermédiaires.

Figure 25 Architecture JEE

1.4 Les outils.


1.4.1 Les outils de développement.

IDE Netbeans :

NetBeans est un environnement de


Figure 26 NetBeans

44
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

développement intégré (EDI), placé en open source par


Sun en juin 2000 sous licence CDDL (Common
Développent and Distribution License) et GPLv2.
En plus de Java, NetBeans permet la prise en
charge native de divers langages tels le C, le C++, le
JavaScript, le XML, le Groovy, le PHP et le HTML, ou
d'autres (dont Python et Ruby) par l'ajout de greffons. Il
offre toutes les facilités d'un IDE moderne (éditeur en
couleurs, projets multi- langage, refactoring, éditeur
graphique d'interfaces et de pages Web).
NetBeans constitue par ailleurs une plateforme qui
permet le développement d'applications spécifiques
(bibliothèque Swing (Java)). L'IDE NetBeans s'appuie
sur cette plateforme.

GIT :

Git est un logiciel de gestion de versions décentralisé.


Son rôle principal est d'assurer le suivi des modifications
dans un ensemble de fichiers. Il repose sur un système
d'archivage de fichiers adressable par le contenu via
l'utilisation de fonctions de hachage cryptographiques
Figure 27 git (SHA-1) pour indexer les fichiers. Git est principalement
utile avec des fichiers au format texte (code source, fichiers
de configuration,..) mais il peut aussi gérer des documents
binaires de manière efficace

45
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

IDE WebStorm :

Figure 28 WebStorm

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. Il améliore la productivité et offre une expérience de
développement agréable grâce un éditeur intelligent avec l'autocomplétion,
la détection d'erreur à la volée, les refactorisations et le formatage de code,
etc. Il offre un support avancé pour Node.js et les frameworks populaires
comme Angular, React, Vue.js, Ionic, Cordova, React Native, Meteor et
Electron.

Que vous travailliez sur une application JavaScript côté client ou


Node.js, WebStorm fournit de puissants outils intégrés pour déboguer,
tester et tracer facilement votre code dans l'IDE. Pour le débogage, vous
pourrez entre autres insérer des points de rupture directement dans le
code source, explorer la pile d'appels et les variables, définir des
observateurs et utiliser la console interactive. WebStorm intègre aussi des
frameworks JavaScript de tests populaires comme Karma, Mocha,
Protractor et Jest. Vous disposez également de spy-js, un outil intégré qui
vous aide à tracer votre code et à identifier efficacement les éventuels
goulots d'étranglement. Il fonctionne à la fois pour JavaScript (côté client)
et Node.js, et supporte même les langages compilés vers JavaScript.

46
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

1.4.2 Les outils de persistances :

MySQL :

MySQL est un serveur de bases de


données relationnelles SQL développé dans un
Figure 29 MySQL souci de performances élevées en lecture, ce qui
signifie qu'il est davantage orienté vers le service
de données déjà en place que vers celui de mises à
jour fréquentes et fortement sécurisées. Il est
multithread et multi-utilisateur.

JAVA Persistance API :

Définir facilement des objets métier, qui


pourront servir d'interface entre la base de
données et l'application, dans le cadre d'un
Figure 30 jpa mapping objet- relationnel.

TomCat Serveur :

Figure 31 tomcat Tomcat est un serveur Web. Il est souvent utilisé


comme serveur d'applications pour des applications
strictement Web, mais n'inclut pas l'ensemble des fonctionnalités qu'un serveur
d'applications Java EE fournirait.

47
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

1.5 Api’s
1.5.1 Générateur de code

Durant notre stage nous avons remarqué qu’il y a toujours un ensemble des fonctionnalités
qui se répètent.

Pour remédier à ce problème nous avons pris la décision de créer un générateur de code
permettant de générer automatiquement du code source. Son but est d'automatiser la
production de code source répétitif afin de minimiser les risques d'erreurs et de permettre au
programmeur de se concentrer sur l'écriture de code à plus grande valeur ajoutée.

Pour ce faire, nous avons basé sur un ancien générateur en améliorant les points suivant :

 Rendre le générateur plus dynamique pour qu’il soit adaptable avec plusieurs langages
et Framework.
 Adapter le générateur avec l’architecture utilisé (architecture MS et le Framework
SPRING).
 Ajouter une fonctionnalité au générateur qui permet de générer les interface graphique
en se basant sur ANGULAR 7 ( il peut supporter d’autre frameworks).

Principe

Génération de code source est basé sur les classe entités. Il récupère tout les champs de
chaque classe et leur type, ces derniers sont utilisés pour générer l’ensemble des couches
du projet.

Implémentation

Une grande a participé dans ce travail chaque collaborateur s’occupe d’une partie. Notre
mission c’était :

Au niveau de côté serveur :

Notre travail était centralisé sur la couche DAO qui permet la connexion avec la base
de donne, nous avons crée les interfaces de touts les classes entités qui contient les
CRUD simple en se basent sur l’ensemble des attributs et leur type.

48
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

 Au niveau de côté client :

Dans cette partie nous avons ciblé l’interface graphique qui permet d’effectuer
des recherches sur un ensemble des données et afficher leurs détails

Pour se faire nous avons pointé sur les classes entités pour récupérer
l’ensemble des champs, en se basant sur leurs type on génère les composant
graphique correspondent (par exemple pour les champs de type nombre on
prépare des inputs min et max dans la barre de recherche)

Point faible

 Le générateur de code support un nombre limité de langages et Framework


 Il a une durée de vie courte vu l’évolution qui impose toujours des nouveautés

1.5.2 Eureka

Eureka est une application permettant la localisation d’instances de services. Elle


se caractérise par une partie serveur et une partie cliente. La communication entre
les parties se fait via les API Web exposées par le composant serveur.

1.5.3 Zuul

Zuul est un service qualifiable de “point d’entrée” permettant de faire du proxy


inverse au sein d’une application. Il se place donc en entrée de l’architecture et
permet de réaliser des opérations avant de transmettre la requête aux services et
sur leur retour. Zuul fait partie de la stack Netflix OSS et utilise en interne
certaines autres applications de la stack, comme Ribbon et Hystrix, par exemple.

1.5.4 Architecture de Zuul + Eureka

49
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

Figure 32 micro service edge

1.5.5 Spring sleuth

Spring Cloud Sleuth implémente une solution


de traçage distribué pour Spring Cloud, empruntant
énormément à Dapper, Zipkin et HTrace. Pour la plupart
des utilisateurs, Sleuth doit être invisible et toutes vos
Figure 33 zipkin interactions avec des systèmes externes doivent être
instrumentées automatiquement. Vous pouvez capturer des
données simplement dans des journaux ou en les envoyant
à un service de collecte à distance.

1.5.6 Zipkine

Zipkin est un système de traçage distribué. Il


aide à rassembler les données de synchronisation
nécessaires pour résoudre les problèmes de latence dans les
architectures de microservices. Il gère à la fois la collecte et
la recherche de ces données. Le design de Zipkin est basé
sur le papier Google Dapper.

50
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

1.5.7 Spring Actuator.

Spring Boot Actuator comprend un certain


nombre de fonctionnalités supplémentaires pour vous aider à
surveiller et à gérer votre application lorsqu'elle est mise en
production. Vous pouvez choisir de gérer et de surveiller votre
Figure 34 spring sleuth application à l'aide de points de terminaison HTTP ou JMX.
Spring Boot Actuator n'est pas un Edge Microservice en soi,
mais simplement une dépendance que vous ajoutez à votre
Microservice

1.5.8 Spring Admin.

Spring Boot Admin est un micro-service edge utilisée pour gérer et surveiller
les applications Spring Boot. Chaque application est considérée comme un client
et s’enregistre auprès du serveur d’administration.

1.5.9 Jasper report

Figure 35 jasper
JasperReports se base sur des fichiers XML (dont
l'extension est en général .jrxml) pour la présentation des états. Il
peut être couplé à iReport ou JasperStudio (plugin Eclipse
équivalent) pour faciliter sa mise en œuvre dans une application
Java, classique ou orientée web.

La version complète de l'application se nomme


JasperReports Server (JRS) depuis la V4 (anciennement
JasperServer) et propose un serveur d'application et la création de
rapports web.

51
Chapitre 4 ____ ___ OUTILS ET TECHNIQUES

Conclusion :

Ce chapitre représente les différents les outils techniques pour développement de notre projet.

52
Chapitre 5 ____ ___ IMPLEMENTATION

CHAPITRE 5
IMPLEMENTATION

 Les difficultés rencontrées


 Les captures d’écran les plus pertinent

Ce chapitre décrit les difficultés


rencontrées durant la phase de la
réalisation ainsi que les écrans les plus
pertinents de l’application

53
Chapitre 5 ____ ___ IMPLEMENTATION

5. IMPLEMENTATION
5.1. Les difficultés rencontrées
5.1.1. Les difficultés au niveau de la conception

Parmi les difficultés que nous avons rencontrées est celle de


l'analyse conceptuelle, durant cette phase, il fallait tout d'abord
comprendre le besoin de la commune pour établir une conception
optimale, mais la difficulté s'est manifestée lors de la phase de la réalisation
suite à l'expression du besoin qui n'est été pas assez clair et qui nous pousse
parfois à effectuer des changements au niveau du diagramme de classes.

5.1.2. Les difficultés au niveau technique

 Les difficultés techniques majeures que nous avons rencontrées


durant ce projet résident essentiellement dans la nouveauté des
technologies à savoir Spring/Angular.
 Nous avons utilisé Jasper Report pour créer nos rapports (fichier
JRXML et .Jasper).mais le grand problème que nous avons
rencontrer c’est le subreport (liste des éléments et chaque élément
constituer de plusieurs éléments) .
 Le deuxième problème rencontré au niveau de jasper est
l’adaptation avec le web service REST et la communication avec
le côté client ANGULAR

5.2. Ecrans de l’application

En ce qui concerne les écrans de l’application nous nous


restreindrons à présenter les écrans les plus pertinents.

54
Chapitre 5 ____ ___ IMPLEMENTATION

5.2.1. Pour l’expression de besoin

Figure 36 création expression de besoin

Cette page permet le chef de l’entité administrative de créer une expression de besoin qui
contiens un ensemble des éléments selon le besoin.

Le modale qui permet au doyen


d’accorder une expression de
besoin ou le refusé

Figure 37 modification expression de besoin

55
Chapitre 5 ____ ___ IMPLEMENTATION

5.2.2.Pour la commande

Figure 38 création commande

Cette interface permet à l’utilisateur de créer un commande avec ses items, de plus il permet
de recevoir des appelle d’offre pour les transférer vers un commande.

Figure 39 liste des commandes

56
Chapitre 5 ____ ___ IMPLEMENTATION

Une fois l’utilisateur veut effectuer une recherche sur des commande, un
panneau de recherche lui aide a faire des recherche selon la référence, la date min et la date
max.

De plus cette interface permet de modifier les éléments de la commande ou bien le supprimer,
imprimer la commande avec l’ensemble de ses éléments.

Figure 40 paiement

L’utilisateur ici peut payer une commande ou bien une somme de la commande et
aussi il a le droit d’imprimer la commande avec l’ensemble de ses payements.

Figure 41 affectation

Après avoir faire un recherche sur un commande tout les éléments de cette commande
apparaitre.

Le deuxième Botton permet de trouver tout l’expression de besoin qui sont accorder et
ils ont le même produit que l’élément de la commande sélectionner.

57
Chapitre 5 ____ ___ IMPLEMENTATION

L’utilisateur peut donc affecter une quantité a une entité administrative.

58
Chapitre 5 ____ ___ IMPLEMENTATION

CONCLUSION
Conclusion : La période de stage que nous avons passés au département d'informatique a la
faculté reste un événement important pour nous. Non seulement elle constitue la transition
d'une vie académique vers une vie professionnelle, Mais aussi un moment de développement
de nos savoir-faire et nos savoir être. Il est certain que ce stage a été une bonne occasion
d’apprendre, de concrétiser les acquis théoriques et d'avoir un important échange
d'informations et d’options. On a également bénéficié de bonnes conditions de travail
(assistance, sympathie...) qui ont rendu le stage agréable

BIBLIOGRAPHIE
http://stackoverflow.com

http://www.w3schools.com

http://commentcamarche.net

http://getbootstrap.com/components/

https://spring.io/docs

59
Chapitre 5 ____ ___ IMPLEMENTATION

60

Vous aimerez peut-être aussi