Rapport de fin d’étude pour l’obtention

de la licence Sciences Mathématiques et

Informatique

Option : base de données

Conception et développement d’une application

de gestion de la phase finale d'un championnat
de football : Architecture applicative basée sur
les microservices et API Rest

Encadré par :
Pr Chemlal Yman

Réalisé par : Devant le jury :

BOUKDIR Soukaina Pr Chemlal Yman Examinateur

ZAKI Adnane Pr Taoufik Aziz Examinateur

Pr Nouh Said Examinateur
 Remerciement

Nous remercions dieu qui nous aide et qui nous donne la patience et le courage durant ces
longues années d’étude.

Ce travail est le fruit de la combinaison d’efforts de plusieurs personnes.

Nous espérons que toutes les personnes qui nous ont aidés durant l’élaboration de ce travail
trouvent dans ces lignes l’expression de nos reconnaissances et nos profondes gratitudes.

En commençant par remercier tout d’abord notre encadrante Mme Chemlal Yman pour avoir
accepté de diriger ce travail et pour son soutien, ses compétences et sa clairvoyance nous ont
été d’une aide inestimable. Il nous a toujours prodigué encouragements et conseils et nous a
réservé un temps précieux tout au long de notre projet.

Nous tenons aussi à exprimer notre gratitude reconnaissance à tous les membres de jury
d’avoir accepté d’évaluer notre travail.

Nous remercions sincèrement tous ceux qui nous ont assisté à développer nos compétences
dans diverses disciplines tout au long du cursus de la licence fondamental.

Nous portons toute nos gratitudes aux enseignants de La Faculté Des Science Ben M’Sik, pour
leur dévouement et leur assistance tout au long de nos études universitaires.
 Dédicaces
Nous tenons avec un grand plaisir que nous dédions ce modeste travail :

À nos parents pour tout le bien qu’ils n’ont cessé de nous prodiguer depuis notre naissance et
pour tous les sacrifices qu’ils ont consentis pour nous.

À nos chers frères et sœurs À tous nos amis et tous ceux qu’ont été là pour nous dans les bons
mais aussi dans les mauvais moments.

À tous mes collègues de La Faculté des sciences Ben M’Sik.

Et pour tous ceux qui nous aiment en témoignage de notre attachement.

 Table des matières

Table des matières

Chapitre 1 : Cahier des charges ............................................................. 2
I. Introduction .......................................................................................... 3
II. Contexte du projet : ........................................................................... 3
III. Objectif du projet : ............................................................................. 3
IV. Description technique du projet : .................................................4
V. Les besoins fonctionnels : ..............................................................4
VI. Les besoins non fonctionnels : .....................................................5
VII. Les contraintes du projet : .............................................................5
VIII. Les périmètres du projet : ..............................................................5
IX. Le service planification : .................................................................5
X. Le service référentiel :..................................................................... 6
XI. Les échanges entre les services : ............................................... 6
XII. Le plan prévisionnel : .........................................................................8
Chapitre 2 : Axes de solution .................................................................. 9
I. Design d’API et microservice : .................................................... 10
1. Les architectures existantes : ................................................................................................ 10

c. Les APIs : ............................................................................................. 11

a. Etude comparative : .............................................................................................................. 12
b. Les critères de choix des API Rest: ........................................................................................ 12
Conclusion : ................................................................................................................................... 14

Chapitre 3 : Analyse et Conception ..................................................... 15

Introduction : ............................................................................................... 16
I. Définition d’UML : ............................................................................. 16
II. Diagrammes de cas d’utilisation : .............................................. 16
Identification des acteurs : ............................................................................................................ 16
Diagramme de cas d’utilisation globale : ...................................................................................... 18
Diagramme de cas d’utilisation pour le service référentiel pour l’administrateur : ..................... 19
Diagramme de cas d’utilisation pour le service référentiel pour l’utilisateur : ............................ 20
Diagramme de cas d’utilisation pour le service planification : ..................................................... 21

III. Diagrammes de classe : ................................................................ 21

Diagramme de classe globale : ...................................................................................................... 22
Diagramme de classe du service référentiel : ............................................................................... 23
Diagramme de classe du service planification : ............................................................................ 23

IV. Diagrammes de séquence : ......................................................... 24

1. Définition ............................................................................................ 24
2. Partie qui contient l’inscription et l’authentification ........... 25
3. Partie qui contient les cas d’utilisation de
l’administrateur : .......................................................................................27
Pour le cas d’utilisation « ajouter objet » ............................................................................. 27
Pour le cas d’utilisation « supprimer objet » :....................................................................... 27
Pour le cas d’utilisation « modifier objet » : ......................................................................... 28
Pour le cas d’utilisation « consulter objet » : ........................................................................ 30
Partie qui contient les cas d’utilisation de l’utilisateur pour le service planification : .......... 31
Partie qui contient les cas d’utilisation de l’utilisateur pour le service référentiel :............. 32

L’api entre référentiel et planification .............................................. 32

L’api entre référentiel et match .......................................................... 32
L’api entre match et statistique .......................................................... 33
L’api entre match et planification ....................................................... 33
Conclusion : ................................................................................................ 34
L’api entre match et statistique .......................................................... 34
L’api entre planification et match ....................................................... 34
Chapitre 4 : Développement ................................................................. 36
Introduction : ................................................................................................................................. 37

I. Outils et environnement de développement : ....................... 37

1. Les outils de conception : ............................................................ 37
Présentation de Lucidchart ................................................................................................... 37
b. Start UML :............................................................................................................................. 37

2. Les outils de réalisation du Backend : .................................... 37

a. Eclipse : .................................................................................................................................. 37
b. IntelliJ IDEA : .......................................................................................................................... 38
c. Spring MVC: ........................................................................................................................... 38
d. Spring boot : .......................................................................................................................... 38
e. Hibernate : ............................................................................................................................. 39
f. Spring data jpa : ..................................................................................................................... 39
g. Thymeleaf : ............................................................................................................................ 39

3. Les outils de réalisation du Frontend : ................................... 39

a. Html : ..................................................................................................................................... 39
b. CSS: ........................................................................................................................................ 40
c. Bootstrap: .............................................................................................................................. 40
d. Java script: ............................................................................................................................. 41

4. Les choix du SGBDR et outils du serveurs : ........................... 41

a. MySQL :.................................................................................................................................. 41
b. Xampp :.................................................................................................................................. 42

5. L’outil du planning : ........................................................................ 42

a. GanttProject : ........................................................................................................................ 42
1. L’environnement matériel : ................................................................................................... 42

II. Réalisation du Backend : .............................................................. 42

1. Le service référentiel : ........................................................................................................... 43
2. Le service planification : ........................................................................................................ 45

III. Réalisation des APIs :.................................................................... 46

IV. Interfaces graphiques : ................................................................. 49
 1. La page d’identification de l’utilisateur : ............................................................................... 50
2. La page d’authentification de l’utilisateur et l’administrateur : ........................................... 50
3. La page d’accueil pour l’utilisateur :...................................................................................... 51
4. L’affichage des équipes : ....................................................................................................... 51
5. L’affichage des joueurs des équipes : .................................................................................... 52
6. L’affichage des stades :.......................................................................................................... 52
7. L’affichage des arbitres : ....................................................................................................... 53
8. L’affichage des commentateurs : .......................................................................................... 53
9. L’affichage des matchs du tour courante : ............................................................................ 54
10. La page d’accueil pour l’administrateur : .......................................................................... 54
La page de la modification des équipes pour l’administrateur ......................................... 55
12. La page de la modification des joueurs de chaque équipe pour l’administrateur : .......... 56
13. La page de la modification des arbitres pour l’administrateur : ....................................... 56
14. La page de la modification des commentateurs pour l’administrateur : .......................... 57
15. La page de la modification des stades pour l’administrateur : ......................................... 57
Conclusion : ................................................................................................................................... 57

Conclusion générale ............................................................................... 59

Analyse des écarts : ....................................................................................................................... 60
Plan réel : ....................................................................................................................................... 60
 Introduction générale
Vu que l'avènement des architectures applicatives basées sur des microservices est considéré
comme une avancée remarquable dans le développement et le déploiement d’applications,
nombreuses organisations adoptent l'architecture microservices pour le développement de
leurs application métiers. Passer à une approche basée sur les microservices rend le
développement d'applications plus rapide et plus facile à gérer.

A cet effet, le travail primordial de ce projet est la mise en place d’une architecture orienté
micro service avec le développement et déploiement d’une application multiservices d’
organisation d’un championnat de Football, afin d’offrir aux utilisateurs la possibilité de suivre
le tournoi sous tous les angles et de faciliter l'accès aux informations des participants pour les
fans de ce jeu, en plus cette application permet de planifier les matchs des différents tours et
garder une trace de tous les matchs pour atteindre et mise en forme des statistiques du
tournoi.
Ce rapport présentera ce travail comme suit : le premier chapitre entamera le cahier des
charges, le deuxième présentera notre choix que nous avons adopté pour réaliser ce projet,
le troisième encadre tout ce qui concerne la partie analytique et conceptuel de l’application
et le dernier chapitre présentera la phase finale qui est celle de la réalisation.

1
Chapitre 1 : Cahier des charges

2
 I. Introduction :
Ce chapitre présentera le cahier des charges de ce projet de fin d’étude en mettant en
évidence ses exigences techniques. En plus de formaliser les besoins et les fonctionnalités
attendues. Et finir par présenter le planning prévisionnel de la réalisation de ce projet.

II. Contexte du projet :

Ce travail se déroule dans le cadre d’un projet de fin d’étude. L’objectif de ce projet est le
développement d’une application de gestion de la phase finale d’un championnat en utilisant
une architecture microservices et les API Rest. L’application
permettra de visualiser :

✓ Le calendrier des matchs et le stade où les matchs se joueront.

✓ Les différentes informations des matchs.
✓ Diverses informations pour les équipes participant au championnat.
✓ Des informations concernant les joueurs de chaque équipe et son évolution tout au
long du tournoi.

III. Objectif du projet :

On a comme objectif d’adopter une architecture microservices pour réaliser notre projet, et
la mise en place du suivi de l’évolution de la nouvelle génération des applications métiers et
des nouvelles architectures, afin de développer nos connaissances à propos dans ce domaine
de la gestion de l’architecture microservices qui fait référence à un style architectural pour le
développement d’applications et qui permet de séparer une grande application en parties
indépendantes et plus petites.

Pour définir les buts, on a opté de travailler avec la méthodologie SMART de gestion de projet
qui fonctionne par objectifs :

S pour spécifique o A l’aide d’une architecture microservices,

l’application doit être réalisée et développée en
(Précis et clair) constituant un groupe des services sépares qui ont
ses propres domaines de responsabilité.
o En revanche, ces mini-services doivent se
communiquer entre eux à l’aide des API Rest qui
respectent les contraintes du style architectural
Rest et qui permettent l’interaction avec les
services Web RestFull d’une façon plus facile.

M pour mesurable o A la fin de la durée du projet, 80% des services

doivent être fonctionnels et devraient pouvoir
(Quantifié ou qualifié) partager les données entre eux.

3
 A pour atteignable o Les membres de notre groupe ont un fort désir de
réussir et de donner le meilleur de nous-mêmes
(Réaliste) pour améliorer nos compétences et profiter des
diverses technologies qu’on va utiliser lors de la
réalisation de l’architecture microservices.

R pour relevant o Ce projet permettra d'approfondir les

connaissances du groupe et de découvrir les
(Pertinent) différents angles de l'architecture microservices.

T pour temporel o Comme délai de réalisation, nous avons 3 mois.

(Avec délai)

Partie Fonctionnelle :

IV. Description technique du projet :

Techniquement parlant, ce projet sera mis en œuvre grâce à l'adoption d'une architecture micro-
services. Sur ce, le logiciel va être décomposé en 2 services :

o Le service planification.
o Le service référentiel.

Et pour élargir notre gestion du tournoi de foot, nos services vont communiquer avec 2 autres services
(service3 « service match » et le service4 « service statistiques ») qui seront pris en charge par un autre
groupe concerné.
Pour la communication entre les différents 4 services, elle sera assurée par utiliser les API Rest pour
obtenir une application de meilleure qualité.

V. Les besoins fonctionnels :

Notre projet doit permettre de :
➢ Gérer les joueurs selon le besoin « ajouter, supprimer, modifier les informations
des joueurs » par consulter la liste de ces derniers et leurs informations et
appliquer les modifications.
➢ Gérer les équipes en modifiant leur liste par l’ajout ou la suppression d’une
équipe, en plus d’offrir la possibilité de modifier leurs informations.
➢ Gérer la liste des arbitres disponibles.
➢ Gérer la liste commentateurs disponibles.
➢ Gérer la liste des stades prêts à accueillir le tournoi pour chaque équipe.
➢ Gérer les matchs s’il existe une modification les concernant.
➢ Afficher la liste des matchs de la semaine courante.

4
 VI. Les besoins non fonctionnels :
Il s’agit des besoins qui caractérisent le système et les besoins en matière de performance,
de type de matériel ou le type de conception. Ces besoins peuvent concerner les
contraintes d’implémentation :

✓ Connecter au réseau : Le système de l’application doit être connecté de façon

permanente à l’internet pour subvenir aux besoins de tous les acteurs et éviter le retard
ou des mauvais fonctionnements.

✓ Être compatible avec n’importe quel système d’exploitation : L’application doit être
supportée par tous les systèmes d’exploitation et peut être exécuter par tous les
périphériques soit PC, Portable, tablette.

✓ L’application doit garantir la sécurité à travers la gestion des droits d’accès : L’accès
aux informations n’est possible qu’après vérification des privilèges et des droits d’accès.
Ainsi tout utilisateur passera par une phase d’authentification pour pouvoir consulter
les services offerts par l’application.
VII. Les contraintes du projet :
Pour les contraintes, on peut les résumer en :

➢ Chaque équipe joue chaque tour soit chez lui soit à l’extérieur.
➢ Chaque équipe joue séquentiellement un match à la maison et un match à l’extérieur.
➢ Les équipes qui n’ont pas un terrain prêt à domicile pour le championnat, leurs matchs
doivent se programmer à l’extérieur.
➢ Si deux équipes de la même ville jouent à domicile, nous devons programmer leurs
matchs à des horaires différents.
➢ Si une équipe a joué 2 matchs à domicile, son 3eme match doit être joué à l’extérieur.
➢ L’équipe perdante doit être éliminé du tournoi.
➢ Apres chaque semaine, la planification doit être renouvelée.
➢ L’équipe gagnante va poursuivre son chemin dans le tournoi.

VIII. Les périmètres du projet :

Le travail sur l’architecture microservices à mettre en place est mené en parallèle avec le
travail de développement et déploiement d’une application multimodales de la gestion de la
phase finale d'un championnat de football. Et les étapes de validation de l’architecture dans
l’environnement de développement et de déploiement et réaliser ce projet a l’aide de
l’adoption de l’architecture microservices sont le pivot central de ce travail.
IX. Le service planification :
On va planifier les matchs du championnat en trouvant un calendrier optimal pour les équipes,
en prenant en considération les différentes contraintes et conditions.

Et on va utiliser un algorithme qui va programmer les matchs de chaque semaine pendant la

période du championnat, en forme de l’équipe de réception et l’équipe adverse, en revanche,
l’algorithme va nous donner pour chaqu'un des équipes « s’il va jouer le match chez lui ou à
l’extérieur ».

5
X. Le service référentiel :
D’abord notre service va se baser sur la construction de base de données et on va le deviser
aux deux parties.

Première partie ça va être la partie des équipes qui va contenir les joueurs et les entraineurs
avec ses informations.

Deuxième partie c’est la partie qui contient tout ce qui concerne le stade. Le nom, le lieu, les
arbitres, les commentateurs et l’horaires possible.

Ensuit que le service génère toutes les données qui se précède on va la traiter pour afficher à
chaque utilisateur de l’application.

Finalement les autres services que ça soit service planification, match ou service de statistique
il doit faire une demande d’API au service référentiel pour récupérer des données spécifiées.

XI. Les échanges entre les services :

Puisque notre va se baser sur l’architecture micro-services, les services de notre groupe et
ceux de l’autre groupe partenaire qui va nous associer à réaliser notre projet.

Le service émetteur Le service récepteur Description

Service référentiel Service planification Le service de référentiel doit

transférer les informations
des équipes, les stades, les
commentateurs et les
arbitres par la méthode Post
au service planification.

Service référentiel Service match Le service référentiel doit

transférer les informations
supplémentaires des matchs
aux service match par POST.

6
Service référentiel Service statistique Le service référentiel doit
transférer les noms des
joueurs et des équipes au
service statistique par POST.

Service planification Service statistique Pour le service planification

et le service statistique y a
pas d'échange entre les deux.

Service planification Service match Le service planification doit

transférer les dates, le stade,
l'horaire, les équipes, les
commentateurs et les
arbitres du match aux service
match par POST

Service match Service statistique Le service statistique va

recevoir les résultats sur le
match, les buteurs, les
cartes … par GET.

7
 Service match Service planification Le service planification va
recevoir l'équipe gagnante
depuis le service match par la
méthode GET.

XII. Le plan prévisionnel :

La planification de projet vise à établir des prévisions raisonnables et à prévoir
l’ordonnancement des phases sur le plan des délais pour la mise en œuvre des travaux
d’ingénierie et la gestion du projet. Ces prévisions sont indispensables à une gestion de projet
efficace. Parmi les outils de planification de projet, il y a le diagramme de GANTT, un outil qui
permet de planifier un projet et rendre plus simple le suivi de son avancement. Le diagramme
de GANTT est une technique et représentation graphique permettant de renseigner et situer
dans le temps les phases, activités, tâches et ressources du projet.

Conclusion :

Dans ce chapitre nous avons étudié le projet sous différents angles, commençant par définir
le contexte et l’objectif du projet, et en passant par décrire les différents services et les
échanges entre eux, les besoins de notre application et les contraintes.

8
Chapitre 2 : Axes de solution

9
 Introduction :
Ce chapitre représente une vue générale sur le choix pour réaliser ce projet. Cela par présenter
les avantages et les inconvénients de de toutes les solutions disponibles, afin de définir le
choix que nous avons effectué.

I. Design d’API et microservice :

1. Les architectures existantes :
Généralement il existe deux solutions disponibles pour l’architecture du projet, soit travailler
avec une architecture microservices qui désigne une approche de développement qui a été
inventée pour résoudre certaines difficultés causées par les gros projets car avec le temps les
projets informatiques ont tendance à grossir et petit à petit on étend les fonctionnalités
existantes, avec de nombreux rajouts et peu de suppressions.

Soit adopter une architecture monolithique qui représente un modèle traditionnel unifié de
conception d’un programme informatique et qui est composé d’un seul tenant, et conçu
comme une unité unifiée autonome et indépendante d'autres apps
a. Etude comparative :
Types d’architecture Avantages Inconvénients

Architecture 1. Représente un déploiement facile 3. Pour apporter un changement

monolithique car un seul fichier exécutable ou à ce type d'application, il faut
répertoire facilite le déploiement. mettre à jour l'ensemble du
2. Lorsqu’une app est conçue avec stack en accédant à la base de
une seule base de code, elle est code, puis en créant et en
plus facile à développer déployant une version mise à
jour de l'interface côté
service.

Architecture  Elle est une méthode de  Chaque microservice utilise

microservices développement d’applications qui une API pour échanger des
aide à décomposer données, et cependant, les
l’applications en éléments les plus modifications de l'API peuvent
simples et indépendants qui être source d'erreurs.
s’appellent des microservices.
 Chacun des Microservices se
concentre sur l’achèvement d’une
fonctionnalité ou bien d’un module
bien déterminé.

10
  Mise à jour plus facile comme on
va travailler avec des services
indépendants.
 L'application plus facile à créer.

b. Les critères de choix de l’architecture microservice :

A cet effet, nous avons choisi d’utiliser l’architecture microservices, et ce choix vient du fait
que les applications de microservices permettent aux développeurs de décomposer plus
facilement leur travail en petites équipes indépendantes et d’intégrer ce travail au fur et à
mesure. En plus qu’elle permet de rendre les applications plus faciles à maintenir.

i. Les avantages :
L’architecture microservices offre :
• Un développement des services indépendamment.
• Avoir une base de données indépendante pour chaque microservice.
• Les microservices peuvent être testé et déployé indépendamment.
• La rapidité de notre application.

Par ce cela la maintenance revient plus facile car quand la quantité de code augmente, sa
maintenance devient de plus en plus complexe et par utiliser cette architecture on peut
mettre à jour juste des composants précis de l’application sans préjudice des autres parties,
la chose qui facilite l’identification et l’isolation des problèmes rencontrés par notre
application.

Ainsi, L’architecture microservices s’agit clairement d’une idée puissante qui offre de sérieux
avantages pour la conception et la mise en œuvre d’applications d’entreprise.
c. Les APIs :
Comme nous avons adopté l’architecture microservices comme solution, alors que nous
devons spécifier une méthode pour la communication entre les différents services. Et
concernant cette partie nous avons assez de solutions et de choix pour la réaliser, mais il faut
choisir la solution la plus efficace et la plus utilisée sur le marché du travail.

La notion d’API, présente un médiateur entre les utilisateurs et les ressources ou services web
auxquels ils souhaitent accéder.

11
Et nous avons la possibilité de choisir entre l’utilisation des API Rest ou l l’utilisation des Soap.
a. Etude comparative :
REST SOAP

C’est un style architectural C’est un protocole.

REST peut utiliser SOAP comme protocole SOAP ne peut pas utiliser REST puisque SOAP
sous-jacent pour les services Web, car il ne est un protocole et REST est un modèle
s'agit finalement que d'un modèle architectural.
architectural.

REST utilise des localisateurs de service SOAP utilise des interfaces de service pour
uniforme pour accéder aux composants sur exposer ses fonctionnalités aux applications
le périphérique matériel clientes

b. Les critères de choix des API Rest:

On a choisi l’API Rest pour l’objectif de nous aider à réaliser une application de bonne qualité
et d’haut niveau à cause de ses multiples avantages.

i. Les avantages :
Parmi les avantages on peut citer :

 La séparation du client qui est celui qui va utiliser l’API et du serveur.

 Le serveur ne sauvegarde aucune des requêtes ou réponses précédentes.
 La possibilité de mettre les données en cache pour éviter la recherche des informations
une deuxième fois par le serveur si l’utilisateur a choisi d’exécuter la même requête au
futur.

3. La Solution proposée :

12
• Dans cette partie nous allons simplifier notre application : nous avons créé deux services (le service
référentiel et le service planification) et on a fait des communications avec les services via Rest Api.
Premièrement on a créé une base de données du service référentiel qui contient (les joueurs, les
commentateurs, les stades, les équipes et les arbitres). Deuxième on a transféré ces données au service
planification par POST pour faire un traitement qui va planifier les matches. Après on va stocker ces
matches dans la base de données de ce service et au même temps on va ajouter au service match de
l’autre groupe L’api Rest par POST contenant les matchs planifiés. Après les matches, ce dernier va
ajouter à service planification les équipes gagnantes par GET pour faire la deuxième planification et on va
le répéter ce traitement entre le service planification et match jusqu’à la fin de championnat. Au même
temps le service référentiel va ajouter par POST au service match des données et le service match aussi
va ajouter au dernier service (service statistique) par POST.

• Concernant l’API GATEWAY ou bien l’intergiciels API c’est une réponse à un résultat découlant
des architectures microservices, à savoir la prolifération des services et de leurs interfaces. L'objectif
principal d'une passerelle API est de simplifier et de stabiliser les interfaces.

• Pour la dernière partie on va faire une communication à l’application par L’API Gateway se doit d'être
indépendante et se place entre le client et le backend. En tant que couche d'abstraction
des microservices, elle agit comme un proxy inversé en redistribuant les requêtes vers les
différents microservices correspondants. Elle devient donc un point d'entrée à l'application.

13
Conclusion :
Comme résumé, nous avons fait dans ce chapitre une étude des différents aspects du solution
pour choisir le meilleur moyen et la bonne solution pour développer l’application
parfaitement.

14
Chapitre 3 : Analyse et Conception

15
Introduction :
Dans ce chapitre nous mettons en évidence le coté conceptuel et analytique de notre
application qui constitue une étape fondamentale qui précède l’implémentation, et il permet
de détailler les différents diagrammes et scénarios à implémenter dans la phase suivante. Ceci
permettra de mieux comprendre nos applications. Dans cette démarche, les diagrammes UML
utilisés sont les suivants : Diagramme de cas d’utilisation, diagramme de classe et les
diagrammes de séquences

I. Définition d’UML :
Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du

modèle ; c'est une perspective du modèle. Chaque type de diagramme UML possède une
structure (les types des éléments de modélisation qui le composent sont prédéfinis) et
véhicule une sémantique précise (il offre toujours la même vue d'un système). Combinés, les
différents types de diagrammes UML offrent une vue complète des aspects statiques et
dynamiques d'un système. Les diagrammes permettent donc d'inspecter un modèle selon
différentes perspectives et guident l'utilisation des éléments de modélisation (les concepts
objet), car ils possèdent une structure

II. Diagrammes de cas d’utilisation :

Les diagrammes de cas d’utilisation (DCU) sont des diagrammes UML utilisé pour donner une
vision globale du comportement fonctionnel d’un système logiciel. Ce type de diagramme
permet de décrire l’objectif et distraire l’ensemble des besoins attendus par notre système en
se basant sur le cahier de charge.

Il comporte trois concepts :

• Les besoins (cas d’utilisation). C’est une manière spécifique d’utiliser le système.
• Les acteurs (les utilisateurs).
• Les relations entre les acteurs et les cas d’utilisation (relation d’extension, inclusion
ou de généralisation).
Identification des acteurs :
Un acteur représente un rôle joué par une personne ou une chose qui interagit avec le système, et il
doit avoir au moins un cas d’utilisation.

Et concernant notre projet, il possède les acteurs suivants :

16
1. L’administrateur : c’est l’acteur qui se charge de la gestion de notre projet, et il a pour
fonctionnalités :
o La gestion des équipes
o La gestion des joueurs
o La gestion des matchs
o La gestion des arbitres
o La gestion des stades
o La gestion des commentateurs
2. Le client : c’est la personne qui va utiliser nos services. Il a les fonctionnalités suivantes :
o La création d’un compte
o La consultation des matchs
o La consultation des équipes
o La consultation des joueurs
o La consultation des arbitres
o La consultation des stades
o La consultation des commentateurs

17
Diagramme de cas d’utilisation globale :

18
Diagramme de cas d’utilisation pour le service référentiel pour l’administrateur :

19
Diagramme de cas d’utilisation pour le service référentiel pour l’utilisateur :

20
Diagramme de cas d’utilisation pour le service planification :

III. Diagrammes de classe :

Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et
les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce diagramme
fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et
dynamiques.

Les relations de ce diagramme peuvent se résument en :

✓ L’association
✓ L’agrégation
✓ La composition
✓ La généralisation
✓ La relation de dépendance

21
Diagramme de classe globale :

22
Diagramme de classe du service référentiel :

Diagramme de classe du service planification :

23
 IV. Diagrammes de séquence :
1. Définition
Les diagrammes de séquences sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique dans la formulation UML (Unified
Modeling System).

Il permet certainement de faire apparaître :

▪ Les intervenants dans les interactions (les objets du système ou acteurs).

▪ Les interactions entre les intervenants.
▪ La description de l’interaction (messages).

Pour ce diagramme, on adapte la notion de ligne de vie qui désigne les moments où l’objet
peut être actif durant son existence.

Concernant les types des messages, on cite :

a. Messages synchrones
b. Messages asynchrones
c. Messages réflexifs
d. Messages de retour

Pour les types des fragments, on peut définir :

➢ Fragment (alt). Equivalent à si-alors-sinon.

➢ Fragment (opt). Equivalent à si-alors.
➢ Fragment (loop). Pour décrire un ensemble d’interaction qui s’exécute en
boucle.
➢ Fragment (par). Pour représenter des interactions qui se réalisent n parallèle.
➢ Fragment (ref). Pour indiquer une référence vers un autre diagramme de
séquence existant.

24
2. Partie qui contient l’inscription et l’authentification
a) Pour le cas d’utilisation « s’inscrire » :x

b) Pour le cas d’utilisation « s’authentifier » :

25
26
3. Partie qui contient les cas d’utilisation de l’administrateur :
Pour le cas d’utilisation « ajouter objet » :

Pour le cas d’utilisation « supprimer objet » :

27
Pour le cas d’utilisation « modifier objet » :

28
29
Pour le cas d’utilisation « consulter objet » :

30
Partie qui contient les cas d’utilisation de l’utilisateur pour le service planification :

31
 Partie qui contient les cas d’utilisation de l’utilisateur pour le service référentiel :

I. Conception des Api Rest :

L’api entre référentiel et planification

De Service référentiel

Vers Service planification

Verbe api POST

Objet {Équipe, stade, commentateur, arbitre}

L’api entre référentiel et match

De Service référentiel

Vers Service match

32
Verbe api POST

Objet {équipe, stade, commentateur, arbitre}

L’api entre match et statistique

De Service Match

Vers Service statistique

Verbe api POST

Objet {équipe, joueur}

L’api entre match et planification

De Service Match

Vers Service planification

Verbe api GET

Objet {équipes gagnantes}

33
 L’api entre planification et match

De Service planification

Vers Service match

Verbe api POST

Objet {Planification, stage, équipe, commentateur, arbitre}

L’api entre match et statistique

De Service Match

Vers Service statistique

Verbe api GET

Objet {/**/}

34
Conclusion :
Par cela, ce chapitre a présenté la partie de la conception en définissant les diagrammes de
cas d’utilisation, les diagrammes de classes et les diagrammes de séquence de notre
application, ce qui va nous aider à la bien développer.

35
Chapitre 4 : Développement

36
Introduction :
Ce chapitre, permet de découvrir l’environnement de travail par présenter les différents outils
qui nous ont aidé à réaliser ce projet de fin d’étude.

I. Outils et environnement de développement :

1. Les outils de conception :
Présentation de Lucidchart

Lucidchart est une application de création de diagrammes basée sur le Web qui permet aux
utilisateurs l’élaboration intelligente de diagrammes, la révision et le partage de graphiques
et de diagrammes par offrir la possibilité de créer des multiples types de diagrammes de
bonne qualité.
b. Start UML :

StarUML est un logiciel de modélisation UML, qui a été « cédé comme open source » par son
éditeur, à la fin de son exploitation commerciale, sous une licence modifiée de GNU GPL.
Aujourd'hui la version StarUML V3 n'existe qu'en licence propriétaire.

2. Les outils de réalisation du Backend :

a. Eclipse :

37
Eclipse IDE est un environnement de développement intégré libre, extensible, universel et
polyvalent, permettant potentiellement de créer des projets de développement mettant en
œuvre n'importe quel langage de programmation.
b. IntelliJ IDEA :
IntelliJ IDEA également appelé « IntelliJ », « IDEA » ou « IDJ » est un environnement de

développement intégré destiné au développement de logiciels informatiques reposant sur la

technologie Java.
c. Spring MVC:

Spring MVC permet de construire des applications Web en Java. Comme son nom le suggère,
il utilise le principe du Modèle/Vue/Contrôleur (MVC) en association avec le modèle Ioc
(Inversion of Control) du Spring Framework.
d. Spring boot :
Pour une réalisation plus efficace pour les microsrvices et les API Rest on a choisi de travailler

avec le Spring Boot est un nouveau Framework conçu pour simplifier le démarrage et le
développement de nouvelles applications Spring. Le Framework propose une approche
dogmatique de la configuration, qui permet d'éviter aux développeurs de redéfinir la même
configuration à plusieurs endroits du code. Dans ce sens, Boot se veut d'être un acteur majeur
dans le secteur croissant du développement d'applications rapide.

38
 e. Hibernate :
Hibernate est un Framework open source gérant la persistance des objets en base de données

relationnelle.

f. Spring data jpa :

Permet de simplifie le codage de la couche d'accès aux données. Plus de code passe-partout

des classes DAO.

g. Thymeleaf :
Thymeleaf est un moteur de Template, sous licence Apache 2.0, écrit en Java pouvant générer

du XML/XHTML/HTML5. Thymeleaf peut être utilisé dans un environnement web ou non web.
Son but principal est d'être utilisé dans un environnement web pour la génération de vue pour
les applications web basées sur le modèle MVC.

3. Les outils de réalisation du Frontend :

a. Html :

Le HyperText Markup Langage, généralement abrégé HTML ou dans sa dernière version

HTML5, est le langage de balisage conçu pour représenter les pages web. C’est un langage
permettant d’écrire de l’hypertexte, d’où son nom. HTML permet également de structurer
sémantiquement et logiquement et de mettre en forme le contenu des pages, d’inclure des

39
ressources multimédias dont des images, des formulaires de saisie et des programmes
informatiques. Il permet de créer des documents interopérables avec des équipements très
variés de manière conforme aux exigences de l’accessibilité du web. Il est souvent utilisé
conjointement avec le langage de programmation JavaScript et des feuilles de style en cascade
(CSS)
b. CSS:

Le terme CSS est l'acronyme anglais de Cascading Style Sheets qui peut se traduire par "feuilles
de style en cascade". Le 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.

c. Bootstrap:

Bootstrap est une collection d'outils utiles à la création du design (graphisme, animation et
interactions avec la page dans le navigateur, etc.) de sites et d'applications web. C'est un
ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de navigation
et autres éléments interactifs, ainsi que des extensions JavaScript en option.

40
 d. Java script:

Un langage de programmation qui permet de créer du contenu mis à jour de façon dynamique,
de contrôler le contenu multimédia, d’animer des images, et tout ce à quoi on peut penser.

4. Les choix du SGBDR et outils du serveurs :

a. MySQL :
Nous sommes en train de réaliser une application web qui se connecte à un serveur de bases
de données afin de récupérer les données.
D’où l’architecture de notre application est à trois niveaux (architecture 3-tiers), elle est
partagée entre :
• L’utilisateur : Conteneur d’application et demandeur de ressources.
• Le serveur : Vu que les données seront communiquées entre deux environnements
hétérogènes, le rôle principal du serveur est de gérer la communication entre l’utilisateur et
la base de données.
• La base de données : fournis les données au serveur.

Et pour manipuler et accéder aux données dans la base de données, on a opté d'utiliser le
SGBDR MySQL qui est la base de données la plus populaire en hébergement web. Il s’agit
d’une option puissante, tout en étant gratuite, très en vague. MySQL est fréquemment utilisé
avec une interface de gestion appelée phpMyAdmin qui permet à un non-initié de générer des
requêtes SQL sur une base de données dans un espace ergonomique et intuitif.

41
 b. Xampp :

XAMPP est un package de pile de solutions de serveur Web multiplateforme gratuit et open
source développée par Apache Friends, composé principalement du serveur HTTP Apache, de
la base de données MariaDB et d'interpréteurs pour les scripts. Etant donné que la plupart
des déploiements de serveurs Web réels utilisent les mêmes composants que XAMPP, cela
rend possible la transition d'un serveur de test local vers un serveur en direct.
5. L’outil du planning :
a. GanttProject :

GanttProject est un logiciel libre de gestion de projet écrit en Java, ce qui permet de l'utiliser
sur divers systèmes d'exploitation. L'outil GanttProject permet de planifier un projet à travers
la réalisation de diagrammes de Gantt.
1. L’environnement matériel :

La marque : HP
Le processeur : Intel Core i5-6300U¹
Stockage : 256 GB SSD
Graphic : Intel HD Graphics 520 intégré
Système d’exploitation : Windows 10 Professionnel 64-bits.

La marque : DELL
Le processeur : Intel Core i5-1145G7
Stockage: 512 GB SSD
Système d’exploitation : Windows 10 Professionnel 64-bits.
II. Réalisation du Backend :
Concernant cette partie, nous avons compté sur les diagrammes de classes pour la réaliser en
créant les entités et spécifiant les relations entre eux. Et comme on a utilisé le Framework
SpringBoot, alors pour chaque entité nous avons défini son interface repository qui indique

42
que la classe ou l’entité a pour rôle de communiquer avec une source de données (en
l'occurrence la base de données) et son service afin de définir son contrôleur qui va être
considéré comme regroupement des APIs Rest de l’entité.
1. Le service référentiel :

43
44
2. Le service planification :

45
III. Réalisation des APIs :

✓ API qui affiche la liste des objets de l’entité en utilisant la méthode GET.

46
✓ API qui affiche un seul objet par recevoir son id et donner en retour les
informations de cet objet en utilisant la méthode GET.

✓ API qui permet d’ajouter un objet d’une entité en utilisant la méthode POST.

47
✓ API qui permet de supprimer un objet en acceptant son id comme paramètre en
utilisant la méthode DELETE.

✓ API qui permet de supprimer un ensemble d’objets en utilisant la méthode DELETE.

48
 ✓ API qui permet de modifier un objet dune entité en donnant son id et les nouvelles
données qu’on souhaite ajouter à ce dernier, tout ça en utilisant la méthode PUT.

En plus nous avons utilisé les APIs qui se chargent de la consultation des listes des objet pour
établir la communication entre les différents services par l’envoie et la réception des données.
IV. Interfaces graphiques :

49
 1. La page d’identification de l’utilisateur :

• Cette partie représente la manière d’inscription des nouveaux utilisateurs avec

(Nom, Prénom, pseudo et mot de passe)

2. La page d’authentification de l’utilisateur et l’administrateur :

• Cette interface représente la connexion des personnes inscrit déjà à notre

Application

50
3. La page d’accueil pour l’utilisateur :

• La page d'accueil qu'on va fusionner pour les utilisateurs directement après

l'authentification

4. L’affichage des équipes :

• L’interface des listes des équipes qu’on a travaillées avec dans notre championnat

51
5. L’affichage des joueurs des équipes :

• La liste des joueurs pour une parmi les équipes qui on a sur la base de données

6. L’affichage des stades :

• L’interface des listes des stades ou les matches va programmés

52
7. L’affichage des arbitres :

• Cette interface représente la liste des arbitres qui va planifier pour les matches

8. L’affichage des commentateurs :

• Cette interface représente la liste des Commentateurs des matches dans le service
référentiel

53
9. L’affichage des matchs du tour courante :

• Cette interface représente la sortie de service planification et a affiché la liste des

matches programmés

10. La page d’accueil pour l’administrateur :

• Cette interface après la détection d’authentification d’administrateur qui on les

même champs que les utilisateurs plus le champs (EDIT) pour faire (l’ajout, la
modification et la suppression des objets) pour les deux services.

54
• Ici où il y a les objets qu’on peut de l’administrateur à faire des mises à jour dans le
service référentiel

La page de la modification des équipes pour l’administrateur

• Ici où il y a la liste des équipes qu’on peut de l’administrateur à faire les mises à jour
dans le service référentiel

55
12. La page de la modification des joueurs de chaque équipe pour l’administrateur :

• Ici où il y a un exemple d’une liste des équipes qu’on peut de l’administrateur à faire
les mises
13. La page à jour pour ledes
de la modification service référentiel.
arbitres pour l’administrateur :

• Cette interface permet de mettre à jour la liste des arbitres pour l'administrateur au
service référentiel.

56
 14. La page de la modification des commentateurs pour l’administrateur :

• L’interface des mises à jour des commentateurs pour l’administrateur dans le

service référentiel
15. La page de la modification des stades pour l’administrateur :

• L’interface qui permet de l’administrateur à modifier dans les stades du service

référentiel.

Conclusion :
Dans ce chapitre, nous avons présenté le travail réalisé et nous avons détaillé les outils
utilisés pour amener le projet la réalité.

57
58
 Conclusion générale
Ce projet a regroupé les différentes étapes de l’analyse, la conception et la réalisation de notre
application afin de réaliser un système de gestion de la phase finale d'un championnat de
football en se basant sur l’architecture Microservices et les APIs Rest.

En premier lieu, on a effectué la conception par le cahier de charge, le formalisme UML et la

mise en œuvre des bases de données avec le gestionnaire MySQL. Ensuite l'implémentation
des apis pour la manipulation des données et enfin l’exécution de l'application sur le web sous
l'environnement de programmation que nous avons travaillé avec. Cette dernier nous a fourni
tous les outils nécessaires pour développer, tester et déployer des applications.

Par ailleurs, ce projet a fait l’objet d’une expérience intéressante, qui nous a permis
d’améliorer les connaissances et les compétences dans le domaine de la conception et la
programmation des systèmes d’informations.

Cependant, La réalisation de ce projet a nécessité la mise en œuvre de plusieurs technologies

afin d’assurer la performance et la fiabilité de l’application, dont la réalisation a nécessité une
méthode de conception.

En guise de perspective, notre solution a l’avantage d’être ouverte et extensible. Nous

pouvons envisager d’ajouter plusieurs fonctionnalités comme nouvelles exclusives de football
avec des vidéos afin de satisfaire tous les besoins des clients.

59
Analyse des écarts :
A la fin de ce projet nous avons constaté qu’il y’a petit décalage entre le planning
prévisionnel et le planning réel et ceci c’est parce que la réalisation et la conception de
projet nécessite assez de temps mais la préparation aux examens nous a pris beaucoup de
temps.

Plan réel :

60