REPUBLIQUE TUNISIENNE UNIVERSITE DE GABES

********** **********
MINISTERE DE L’ENSEIGNEMENT INSTITUT SUPERIEUR DE GESTION
SUPERIEUR DE LA RECHERCHE DE GABES
SCIENTIFIQUE **********

Rapport de projet de fin d’études

Pour obtenir le diplôme de master professionnel

En : Ingénierie de développement mobile

Sujet
Réalisation d’une application mobile de gestion des
compétitions de la fédération tunisienne de Yoseikan
Budo

Réalisé par : Ichrak jrad

Encadré par : Mr. Mohammed Ali Fall Seideh

Membre de jury :

Président :Mr.Zied Trifa

Rapporteur :Mm.Nahla Jlaiel

Année Universitaire : 2020-2021

 DEDICACE

Du profond de mon cœur, Je dédie ce travail à tous ceux qui me sentent

chers,
A ma chère mère,
Pour les sacrifices qu’elle fait pour mon bien être.
A la mémoire de mon père,
qui m’a toujours poussé et motivé dans toute les stades de ma vie.
A mes chères sœurs et mon frère pour leur grand amour et Leur soutien.
 Remerciement

Au terme de ce travail je tiens tout d’abord à remercier : Mon DIEU de m’avoir

donné le courage, la force et la volonté pour achever ce modeste travail.

Je tiens à adresser ma reconnaissance et mes remerciements à mon encadrant de

mémoire, Monsieur Mohammed Ali Fall Seideh pour son encadrement et sa
disponibilité, ainsi que pour la richesse et la qualité de son enseignement.

Enfin , je tiens à remercier également les membres du jury qui ont accepté
d’évaluer mon travail.
 Table des matières
Introduction générale .............................................................................................................1
Chapitre 1 : Cadre général du projet ......................................................................................2
Introduction ............................................................................................................................2
1. Cadre du projet ..................................................................................................................2
2. Domaine d’étude ...............................................................................................................2
2.1. Généralités sur les fédérations sportives ......................................................................2

2.2. Rôles de la fédération sportive .....................................................................................2

2.3. La fédération tunisienne de Yoseikan Budo ................................................................3

3. L’étude de l’existant ...........................................................................................................5

4. Problématique ....................................................................................................................5
4.1. Situation actuelle ..........................................................................................................5

4.2. Conséquence de la situation actuelle ............................................................................6

5. Solution proposée ..............................................................................................................6

Conclusion..............................................................................................................................7
Chapitre 2 : Spécification des besoins & conception .............................................................8
Introduction ............................................................................................................................8
1. Analyse et spécification des besoins .................................................................................8
1.1. Besoins fonctionnels ....................................................................................................8

1.2. Besoins non fonctionnels ...........................................................................................10

2. Conception UML .............................................................................................................10

2.1. Langage de modélisation ............................................................................................10

2.2. Diagramme de cas d’utilisation ..................................................................................10

2.2.1 Détail de cas d’utilisation de l’acteur « admin » .....................................................12

2.2.2. Détail de cas d’utilisation de l’acteur « responsable de club » ................................15

2.2.3. Détail de cas d’utilisation de l’acteur « joueur ».....................................................17

2.3. Diagramme de séquences ..............................................................................................18

2.3.1. Diagramme de séquence « s’authentifier » .............................................................18

2.3.2. Diagramme de séquence « demander licence» .......................................................19

2.4. Diagramme de classe....................................................................................................19

3. Le modèle relationnel ......................................................................................................20

Conclusion............................................................................................................................22
Chapitre 3 : Réalisation ........................................................................................................23
Introduction ..........................................................................................................................23
1. Environnements de travail ...............................................................................................23
1.1. Environnement matériel .............................................................................................23

1.2. Environnement logiciel ..............................................................................................23

1.2.1. Outils utilisés ..........................................................................................................23

1.2.2. Technologies utilisés .............................................................................................24

1.2.3. Système de gestion de base de données..................................................................27

2. Les interfaces de l’application .........................................................................................28

2.1. Partie administrative web ...........................................................................................28

2.2. Partie mobile ..............................................................................................................34

Conclusion............................................................................................................................43
Conclusion générale .............................................................................................................44
Webographie ........................................................................................................................45
 Table des figures

Figure 1:logo de FTYB ................................................................................................................................. 3

Figure 2:Diagramme de cas d’utilisation globale ......................................................................................... 11
Figure 3:Diagramme de cas d’utilisation « admin » ..................................................................................... 13
Figure 4:Diagramme de cas d’utilisation « responsable de club »................................................................ 15
Figure 5:Diagramme de cas d’utilisation « joueur »..................................................................................... 17
Figure 6:Diagramme de séquence « s’authentifier » .................................................................................... 18
Figure 7:Diagramme de séquence « demander licence » ............................................................................ 19
Figure 8:Diagramme de classe .................................................................................................................... 20
Figure 9 : logo de flutter ............................................................................................................................. 25
Figure 10: logo de codeigniter .................................................................................................................... 26
Figure 11: architecture de modèle-vue-Controller ...................................................................................... 27
Figure 12: interface "authentification" ........................................................................................................ 28
Figure 13: interface d’accueil ..................................................................................................................... 29
Figure 14 : interfaces « liste des club » ...................................................................................................... 30
Figure 15: interface « liste des demandes des licences » ............................................................................ 30
Figure 16: interface « traiter demande » ..................................................................................................... 31
Figure 17: interface « email envoyé » ......................................................................................................... 31
Figure 18: interface « programmer match » ................................................................................................ 32
Figure 19: interface « enregistrer résultats » ............................................................................................... 32
Figure 20: interface « examens des grades»................................................................................................ 33
Figure 21: interface mobile « accueil » ....................................................................................................... 34
Figure 22: interface « login» ....................................................................................................................... 35
Figure 23: interface « accueil » ................................................................................................................... 36
Figure 24: interface "notification" .............................................................................................................. 37
Figure 25:interface "demander licence" ...................................................................................................... 38
Figure 26: interface "consulter nos matchs" ............................................................................................... 39
Figure 27 : interface « liste des joueurs » .................................................................................................. 40
Figure 28: interface « profile joueur » ........................................................................................................ 41
Figure 29:interfaces "accueil" et « examens de grade » .............................................................................. 42
Figure 30: interfaces "contact" et "a propos de nous" ................................................................................. 43
 Liste des tables

Tableau 1:Scénario du cas d’utilisation « s’authentifier »........................................................................... 12

Tableau 2: Scénario du cas d’utilisation « gérer club »............................................................................... 14
Tableau 3: Scénario du cas d’utilisation « traiter demande » ...................................................................... 15
Tableau 4: Scénario du cas d’utilisation « consulter matchs » .................................................................... 16
Tableau 5: Scénario du cas d’utilisation « demander licences » ................................................................ 16
Tableau 6: Scénario du cas d’utilisation « consulter ses examens de grade » ............................................ 17
 Liste des abréviations

FTYB : fédération tunisienne de Yoseikan Budo

ISGG: Institut supérieur de gestion de Gabes
UML: Unified Modeling Language
PHP: Personal Home Pages
MVC: Model-View-Controller
IOS : Iphone operating system
SQL: Structured JQuery Language
 Projet de fin d’étude

Introduction générale
Ces dernières années, nous avons assisté à un changement dans le monde de la consommation.
L'émergence des réseaux sociaux et des applications web et mobiles a permis aux entreprises de
proposer de nouveaux services aux utilisateurs et de rechercher des solutions informatiques
capables de répondre aux différents besoins de leurs clients.

La bonne organisation de tout événement sportif est un facteur fondamental pour le processus
de développement, non seulement de la discipline sportive mais aussi chaque fédération
nationale.
En Tunisie, Chaque Fédération Sportive doit trouver des réponses spécifiques à sa situation et
cerner des zones de développement lui permettant d’élaborer des stratégies pour mener à bien des
plans d’organisation des compétitions. Elle doit tenir compte de l’ensemble de ressources
humaines disponibles sportives : entraîneurs, arbitres, joueurs et club qui constituent les éternels
piliers de la fédération.

Dans ce contexte, on se propose dans le cadre de notre projet de fin d’étude de développer une
application avec deux parties :

La première partie consiste de développer une application mobile pour les adhérents de la
fédération tunisienne de YOSEIKAN BUDO qui leur permet de suivre les résultats de ces
compétitions et demander des licences des joueurs et de coachs.

La deuxième partie consiste à développer un outil pour la fédération tunisienne de yoseikan

budo qui lui permet la gestion de ses adhérents et la gestion des compétitions.

Le présent rapport comporte trois chapitres. Dans le premier chapitre, nous nous intéressons
particulièrement a énoncer le cadre général de projet. Le deuxième chapitre est consacré à
l’analyse conceptuelle. Le troisième chapitre est dédié à la réalisation de notre travail. Nous
terminons le rapport par la conclusion et les perspectives.

2020/2021 Page 1
 Projet de fin d’étude

Chapitre 1 : Cadre général du projet

Introduction
Nous présentons dans ce premier chapitre le cadre principal du projet. Tout d’abord on décrit
le domaine d’étude de notre projet. Ensuite nous proposons une étude de l’existant et enfin, la
solution proposée.

1. Cadre du projet
Le projet entre dans le cadre de préparation de projet de fin d'études pour l'obtention de

diplôme de mastère professionnel en ingénierie de développement mobile (IDM) de l'institut

supérieur de gestion de Gabes. Notre projet consiste à concevoir et développer une application
multiplateforme pour la fédération nationale de yoseikanbudo.

2. Domaine d’étude
2.1. Généralités sur les fédérations sportives

Les fédérations sportives regroupent des associations sportives qui sont des organismes à but
non lucratif. Elles sont agréées par le ministère de la jeunesse et des sports. D’ailleurs, une
fédération sportive établit un contrat permanant avec l’état à fin de pouvoir organiser des
compétitions.

2.2. Rôles de la fédération sportive

Une fédération sportive a pour principale mission de promouvoir les activités sportives ainsi
que l’organisation de différentes manifestations. En effet, l’encadrement de la pratique sportive
est également la priorité d’une fédération sportive. Ainsi, elle est responsable de la mise en place
et de l’exécution des règlements fédéraux et a le pouvoir de délivrer des licences pour les
organismes ou les clubs sportifs. Elle participe également au développement des organismes.
Bref, une fédération sportive joue un rôle important dans l’existence des associations sportives.

2020/2021 Page 2
 Projet de fin d’étude

2.3. La fédération tunisienne de Yoseikan Budo

Dans le but de promouvoir les disciplines sportives et de développer le domaine du sport

tunisien, nous avons choisi de faire une recherche sur l’un des plus populaires fédérations
sportive en Tunisie, qui est la Fédération tunisienne de YOSEIKAN BUDO (FTYB).

Le Yoseikan Budo est un art martial moderne, complète et ludique, incluant tous les aspects
du combat : frappes, lutte, contrôles articulaires et même travail des armes, le tout debout comme
au sol !

Les différents services de la fédération tunisienne de YOSEIKANBUDO sont les suivants :

 Le service licence/ affiliation

 Le service compétition/ arbitrage
 Le service formation / examens
 Le service grades/ équivalences
 Le service communication

Figure 1:logo de FTYB

2020/2021 Page 3
 Projet de fin d’étude

 Organisation des compétitions :

Le système des compétitions peut varier d’une compétition à l’autre (pools, éliminations
directes,..).

Le but principal de la compétition est de réunir les pratiquants de YOSEIKAN BUDO des
différents clubs, régions, afin de créer un réseau d’amitié de plus en plus étendu. La compétition
veut :

 Susciter un état d’esprit de partage, et un comportement de respect mutuel.

 Former le sens de l’initiative et la capacité de décision rapide.
 Développer la concentration et le contrôle de soi.
 Former un esprit de patience.
 Forger une résistance mentale et physique.

A travers la compétition, les organisateurs souhaitent faire connaître le Yoseikan Budo et le

développer.

 Déroulement d’un match

Au début d’un match la couleur AKA (rouge) ou AO (bleu) est déterminée par l’ordre
d’inscription des compétiteurs. Le premier nommé est toujours AKA (rouge) il se place à droite.
Les juges arbitres signalent à l’aide de drapeau (AKA ou AO), les points marqués par l’un ou
l’autre des combattants. A la fin du match l’arbitre donne la décision finale à l’aide de drapeau
(AKA ou AO) .En cas d’égalité, un vote HANTEÏ décide quelle issue donner au combat.

2020/2021 Page 4
 Projet de fin d’étude

3. L’étude de l’existant
En raison de la popularité croissante du yoseikan budo dans le monde, et en particulier en
Tunisie, la Fédération tunisienne de Yōseikan Budō nécessite une solution pour la gestion de ses
adhérents et la gestion des compétitions nationales. En effet, le nombre des clubs et licenciés
affiliés à la fédération est en constante progression.

L'objectif de cette mémoire est l'évaluation des capacités des services de FTYB à fin
d'identifier les problèmes et de voir l’impact de ces services sur la performance des organisations
sportives tunisiennes.

Nous avons basé notre analyse qualitative sur le contenu d'une série d'entretiens avec les
adhérents de FTYB, ce qui nous a permis de vérifier la problématique.

4. Problématique
La FTYB souffre d'un manque d'organisation et d'une défaillance d'outils de gestion ce qui
fait que les activités sont souvent exécutées dans les limites des temps impartis (pour ne pas dire
tardivement) ce qui affecte la qualité des services offerts.

4.1. Situation actuelle

La Situation actuelle des services de FTYB a posé des différents problèmes pour tous les
adhérents de la fédération :

Coté fédération:

Les activités actuelles du responsable de la fédération :

 Communiquer avec les clubs et les joueurs en utilisant les courriels et les réseaux
sociaux
 Annoncer les résultats des combats à la fin de la compétition sur les réseaux sociaux.
 La gestion manuelle des licences des joueurs et des coachs.
 Programmer les compétitions et les matchs via un fichier Excel.

2020/2021 Page 5
 Projet de fin d’étude

Coté coachs, les joueurs et clubs :

Les activités actuelles des adhérents :

 Utiliser les e-mails et les réseaux sociaux pour suivre les résultats de la compétition.

4.2. Conséquence de la situation actuelle

La situation actuelle a engendré les conséquences suivantes :

 Livraison tardive des licences des joueurs et des coachs aux clubs.
 Erreurs et surcharges lors de remplissage des informations dans les licences des joueurs.
 Perte de temps lors de remplir les résultats des matchs.
 Erreurs et surcharges lors d’enregistrement des résultats des matchs

5. Solution proposée
Après une étude, la solution que nous proposons pour résoudre ces problèmes et faciliter les
services de la fédération est de développer un outil (application web) qui permet de gérer les
clubs, les joueurs et les arbitres, créer des compétitions, organiser le calendrier des matchs et
mettre à jour les résultats à la fin de chaque match.

Et une application mobile pour les adhérents (joueur, arbitre, coach) qui leur permet de suivre
les résultats de ces compétitions et les aide à s'intégrer facilement dans le sport.

 Les principaux objectifs d’amélioration :

Pour améliorer les services de FTYB, nous avons défini les objectifs suivants :
 Un gain de temps entre la fin d’un match et l’annonce des résultats.
 En cas de changement de dernière minute, les plannings peuvent être régénérés
rapidement.
 Accessibilités via une application mobile aux programmes et résultats des combats.
 Faciliter de demander des licences des joueurs et coachs pour les responsables des clubs.

2020/2021 Page 6
 Projet de fin d’étude

Conclusion
Dans ce chapitre nous avons présenté le contexte général de notre projet en déterminant la

Problématique et la solution proposée pour faire face à la situation courante. Le prochain chapitre
est consacré à la modélisation conceptuelle de notre projet

2020/2021 Page 7
 Projet de fin d’étude

Chapitre 2 : Spécification des besoins &

conception

Introduction
Dans ce chapitre, nous commençons en premier lieu par une spécification des besoins
auxquels doit répondre l'application, passant ensuite à l'analyse de ces besoins à travers
l'introduction des acteurs et les diagrammes de conception UML de l’application.

1. Analyse et spécification des besoins

L'analyse et la spécification des besoins représentent la première phase du cycle de
développement d'un logiciel. Elle sert à identifier les acteurs réactifs du système et leur associer
chacun l'ensemble d'actions avec lesquelles il intervient dans l'objectif de donner un résultat
optimal et satisfaisant au client.

1.1. Besoins fonctionnels

Cette phase est indispensable pour la conception de notre application. Elle nous permet de
déterminer les principales fonctionnalités de l’application.

 Les besoins fonctionnels liés à la fédération :

Le système à concevoir doit permettre à la fédération d’effectuer les opérations suivantes :

 La gestion des clubs, des joueurs, des arbitres et des coachs.

 La gestion des compétions nationales.
 La gestion des matchs (heure et lieu), affectation des arbitres et Enregistrement des
résultats.
 La gestion des examens de grade.
 Traitement des demandes des licences des coachs et joueurs.

2020/2021 Page 8
 Projet de fin d’étude

 Les besoins fonctionnels liés au responsable de club :

Notre application doit permettre au responsable de club d’effectuer les opérations suivantes :

 demander licence pour ses joueurs et ses coachs.

 Consulter ses matchs
 Consulter les listes de ses joueurs et ses coachs
 Communiquer avec ses joueurs et ses coachs
 Consulter les notifications

 Les besoins fonctionnels liés au Joueur :

Notre application doit permettre au joueur d’effectuer les opérations suivantes :

 Consulter ses matchs, son profile et ses examens de grade

 Consulter les notifications

 Les besoins fonctionnels liés à l’arbitre :

Notre application doit permettre à l’arbitre d’effectuer les opérations suivantes :

 Consulter ses matchs, son profile et ses examens de grade

 Consulter les notifications

 Les besoins fonctionnels liés au coach :

Notre application doit permettre au coach d’effectuer les opérations suivantes :

 Consulter les matchs de ses joueurs, son profile et ses examens de grade.
 Consulter les notifications.

2020/2021 Page 9
 Projet de fin d’étude

1.2. Besoins non fonctionnels

Les besoins non fonctionnels expliquent les aspects qualité du système à construire,
contrairement aux exigences fonctionnelles, sont implémentées de manière incrémentielle dans
n'importe quel système. Des contraintes doivent être prises en compte tout au long du
développement du projet :

Ergonomie : les interfaces de l'application doivent être conviviales et l'enchaînement entre les
pages doit être cohérant avec une navigation rapide.

Performance : L'application doit répondre aux exigences des usagers d’une manière optimale.

Sécurité : l'application doit être totalement sécurise car les données ne doivent pas être accessible
à tout le monde.

2. Conception UML
2.1. Langage de modélisation
Nous avons choisi UML comme un langage de modélisation pour bien modéliser notre projet.

UML est Le Langage de Modélisation Unifié, de l'anglais Unified Modeling Language (UML),
est un langage de modélisation graphique à base de pictogrammes conçu comme une méthode
normalisée de visualisation dans les domaines du développement logiciel et en conception
orientée objet[1].

2.2. Diagramme de cas d’utilisation

Les diagrammes de cas d’utilisation sont composés d’acteurs et de cas d’utilisation. Un

acteur est un utilisateur, humain ou non du système qui est doté d’un nom qui correspond à son
rôle. Un cas d’utilisation est une manière spécifique d’utiliser le système. Il permet de décrire ce
que le futur système devra faire, sans spécifier comment il le fera. Dans le cadre de notre
application nous distinguons 5 acteurs qui sont l’administrateur (responsable de la fédération)
responsable de club, joueur, coach et arbitre.

2020/2021 Page 10
 Projet de fin d’étude

La figure 2 représente le diagramme de cas d’utilisation globale.

Figure 2:Diagramme de cas d’utilisation globale

2020/2021 Page 11
 Projet de fin d’étude

Nous présentons dans la table 1 la description textuelle du cas d’utilisation « s’authentifier »

Cas d’utilisation S’authentifier

Acteur administrateur, joueur, responsable de club , arbitre , coach

Pré condition L’acteur possède un login et un mot de passe.

Post condition Authentification réussite.

1- L’acteur saisit son login et son mot de passe
2- Il clique sur le bouton « se connecter »
scénario principal
3- Le système vérifie les informations de saisie par l’acteur
et affiche l’interface d’accueil de l’utilisateur.

Un message d’erreur est affiché si le login ou mot de

Scénario d’exception
passe sont erroné.
Tableau 1:Scénario du cas d’utilisation « s’authentifier »

2.2.1 Détail de cas d’utilisation de l’acteur « admin »

Il s’agit d’un acteur administrateur qui est le responsable dans la fédération qui peut faire
différentes taches dans la partie web de l’application.

2020/2021 Page 12
 Projet de fin d’étude

Figure 3:Diagramme de cas d’utilisation « admin »

Dans la suite, nous proposons dans les tableaux suivants de présenter la description
textuelle des cas d’utilisation « gérer clubs » et « traiter demandes des licences ».

2020/2021 Page 13
 Projet de fin d’étude

Cas d’utilisation Gérer des clubs

Acteurs administrateur
Pré-condition Authentification obligatoire
Post-condition Gérer les club
Scénario nominale Consulter la liste des clubs:
1- l'administrateur demande l’affichage de la liste des clubs.
2- le système affiche la liste des clubs
...Ajouter club :
1- l’administrateur demande le formulaire d’ajouter un club. 2-
Le système affiche l’interface d’ajout un club.
3- L’administrateur remplit les champs nécessaires et valide.
4- Le système vérifie les données saisies.
5- Le système enregistre un nouveau club et affiche un message de
Succès.
Modifier club:
1- l’administrateur choisit le club à modifier
2- le système affiche le formulaire de modification
3- l’administrateur modifie les informations et valide
4- le système vérifie les données saisies
5- le système enregistre les données modifiées
Supprimer club:
1- l’administrateur choisit le club à supprimer
2- le système affiche un message de confirmation
3- l’administrateur valide son choix
4- le système affiche un message de succès
5- le système supprime le club
Chercher club :
1- l’administrateur saisie le nom du club a cherché
6- le système affiche les information nécessaire
Exceptions Si l’un des champs est vide, le système affiche un message d’erreur
pour remplir tous les champs .
Tableau 2: Scénario du cas d’utilisation « gérer club »

2020/2021 Page 14
 Projet de fin d’étude

Cas d’utilisation Traiter demande

Acteurs administrateur
Pré-condition Authentification obligatoire
Post-condition Demande traitée
Scénario nominale Consulter la liste des demandes des licences (joueurs ou coachs):
1-l'administrateur demande l’affichage de la liste des demandes
2- le système affiche la liste.
3- l’administrateur demande le formulaire pour traiter la demande
Si l’administrateur Accepte la demande :
1- il doit ajouter le mot d’utilisateur , le mot de passe et le numéro de
licence.
2- il doit cliquer sur le boutton “confirmer demande”
3- le systéme envoi un mail au joueur contenant le mot d’utilisateur , le
mot de passe et le numéro de licence.
Si l’administrateur Refuse la demande:
1- il doit cliquer sur le boutton “refuser
demande”
2- le système affiche un message de succès
3- le système supprime la demande

Exceptions Si l’un des champs est vide, le système affiche un message d’erreur
pour remplir tous les champs .
Tableau 3: Scénario du cas d’utilisation « traiter demande »

2.2.2. Détail de cas d’utilisation de l’acteur « responsable de club »

Figure 4:Diagramme de cas d’utilisation « responsable de club »

2020/2021 Page 15
 Projet de fin d’étude

Nous proposons dans les tableaux suivants de décrire la description textuelle du cas d’utilisation
« consulter ses matchs » et « demander licences»

Cas d’utilisation Consulter ses matchs

Acteur joueur, responsable de club, arbitre, coach

Pré condition Authentification obligatoire

Post condition Matchs affichés

1- L’acteur choisit « mes matchs »

scénario principal 2- Le système affiche la page de matchs (terminés et a

venir)

Scénario d’Exception Pas d’exception

Tableau 4: Scénario du cas d’utilisation « consulter matchs »

Cas d’utilisation Demander licences

Acteur responsable de club

Pré condition Authentification obligatoire

Post condition Demande envoyée

1-L’acteur clique sur le boutton « demander licence »
2-Le système affiche l’interface de demander licence.
3-L’acteur remplit les champs nécessaires et valide.
scénario principal 4- Le système vérifie les données saisies.
5- Le système enregistre une nouvelle demande et
affiche un message de succès.

Si l’un des champs est vide, le système affiche un message

Scénario d’Exception
d’erreur pour remplir tous les champs .
Tableau 5: Scénario du cas d’utilisation « demander licences »

2020/2021 Page 16
 Projet de fin d’étude

2.2.3. Détail de cas d’utilisation de l’acteur « joueur »

Figure 5:Diagramme de cas d’utilisation « joueur »

Le tableau suivant est la description textuelle du cas d’utilisation « consulter ses examens de
grade ».

Cas d’utilisation consulter ses examens de grade

Acteur joueur, arbitre, coach

Pré condition Examens de grade affichés

Post condition Authentification réussite.

1- L’acteur choisit « mes examens de grade»

scénario principal
2- Le système affiche la page des examens de grade

Scénario d’Exception Pas d’exception

Tableau 6: Scénario du cas d’utilisation « consulter ses examens de grade »

2020/2021 Page 17
 Projet de fin d’étude

 Signalons que les autres cas d’utilisation des autres acteurs sont réalisés de la même
manière que l’acteur joueur, à un cas d’utilisation prés.

2.3. Diagramme de séquences

Un diagramme de séquence permet de décrire les interactions entre différentes entités et/ou
acteurs : par exemple des objets dans un modèle d'un logiciel, des sous-systèmes dans un modèle
d'un système complet [2].

2.3.1. Diagramme de séquence « s’authentifier »

La figure 6 décrit les détails du diagramme de séquence de cas d’utilisation « S’authentifier »

Figure 6:Diagramme de séquence « s’authentifier »

2020/2021 Page 18
 Projet de fin d’étude

2.3.2. Diagramme de séquence « demander licence»

La figure 7 décrit les détails du diagramme de séquence de cas d’utilisation « demander

licence ».

Figure 7:Diagramme de séquence « demander licence »

2.4. Diagramme de classe

Un diagramme de classes est une collection d'éléments de modélisation statiques (classes,

paquetages...), qui montre la structure d'un modèle. Il fait abstraction des aspects dynamiques et
temporels. Le diagramme de classe est un graphe qui présente la structure statique d’un système.
Il contient principalement des classes et leurs relations. .Le diagramme de classe est le point
central dans un développement orienté objet.

2020/2021 Page 19
 Projet de fin d’étude

Une classe est composée :

D’attribut : il s’agit des données dont les valeurs représentent l’état de l’objet. Des
méthodes : il s’agit des opérations applicables aux objets.

Figure 8:Diagramme de classe

3. Le modèle relationnel
Le modèle relationnel est une manière de modéliser les relations existantes entre plusieurs
informations, et de les ordonner entre elles.

2020/2021 Page 20
 Projet de fin d’étude

Les règles de passages vers un schéma relationnel de la base de données sont :

 Chaque classe devient une table.

 Chaque attribut donnera une colonne dans la table.
 La colonne de clé primaire sera l’identificateur unique de l’instance.
 Chaque instance de la classe sera représentée par une ligne dans cette table.
 Chaque association « un à plusieurs » est représente par une clé étrangère dans la table
fille.
 Chaque association « plusieurs à plusieurs » entre deux classes est représente par une
nouvelle table qui prend pour une clé primaire de concaténation des clés primaire de deux
classes.

 Schéma relationnel de la base de donnés

Le modèle relationnel des données de l’application est représenté comme suit :

Club (Id-club, nom_club, reponsable_club,login , motdepasse)

Joueur (Id-joueur,login , motdepasse , nomprenom , email ,datenaissance , categorie , poid ,

genre , #id_club , #id_coach)

Coach (Id-joueur,login , motdepasse , nomprenom , email ,datenaissance , genre , grade

#id_club ,)

Arbitre (Id-joueur, nomprenom,login , motdepasse , grade , datenaissance)

Licence (numero_licence, , date_licence , #id_joueur XOR #id_coach)

competition (id_competition, , nom_competition , date_competiton ,lieu_competition)

Match (id_match, , #id_joueur , #id_competiton ,#id_arbitre , tour , date , lieu)

Match_joué (id_match, , #id_joueur , #id_competiton ,#id_arbitre , tour , date , lieu ,

score_joueur1 , score_joueur2)

Examen_grade (id_examen, , grade , date , resultat)

2020/2021 Page 21
 Projet de fin d’étude

Conclusion
Présenter la solution conceptuelle d’un projet est un volet primordial dans la réussite de ce
dernier. En effet, en présentant le modèle conceptuel, nous avons pu définir les différentes entités
de système et déterminer le rôle de chacune d’elles. Dans le prochain chapitre, nous allons
entamer la dernière étape qui est la réalisation du projet.

2020/2021 Page 22
 Projet de fin d’étude

Chapitre 3 : Réalisation

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

1. Environnements de travail
1.1. Environnement matériel

Notre application a été développée sur une plateforme matérielle et testé sur un

Smartphone androïde.

Les caractéristiques de la plateforme :

- Processeur : Intel Core i5

- Mémoire RAM : 8 GB
- Espace disque : 240 Go SSD
- Système d„exploitation : Windows 10

Les caractéristiques du Smartphone utilisé pour le teste :

- Mémoire RAM : 4G
- Mémoire interne : 64 GB

1.2. Environnement logiciel

1.2.1. Outils utilisés

 STAR 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 (qui visiblement continue…) sous une licence

2020/2021 Page 23
 Projet de fin d’étude

modifiée de GNU GPL. StarUML gère la plupart des diagrammes spécifiés dans la norme UML
2.0[3].

 Figma :

Est un éditeur de graphiques vectoriels qui permet aux UX/UI designers de prototyper les interfaces
graphiques. Il aide notamment à concevoir sites web, applications et autres interfaces utilisateur [4].

 Visual studio code :

Visual Studio Code est un éditeur de code source léger mais puissant qui est disponible pour
Windows, macOS et Linux. Il est livré avec une prise en charge intégrée de JavaScript,
TypeScript et Node.js et dispose d'un riche écosystème d'extensions pour d'autres langages (tels
que C++, C#, Java, Python, PHP, Go) et des environnements d'exécution (tels que .NET et Unity)
[5].

 Postman :

Postman est une application permettant de tester des API, créée en 2012 par Abhinav Asthana,
Ankit Sobti et Abhijit Kane2 à Bangalore pour répondre à une problématique de test d'API
partageable. D'abord module complémentaire de Google Chrome, puis client lourd, et client
léger, elle est utilisée par plus de 500 000 entreprises dans le monde et a son siège à San
Francisco[6].

 XAMPP :

XAMPP est un ensemble de logiciels permettant de mettre en place un serveur Web local,
un serveur FTP et un serveur de messagerie électronique.Il s'agit d'une distribution de logiciels
libres (X (cross) Apache MariaDB Perl PHP) offrant une bonne souplesse d'utilisation, réputée
pour son installation simple et rapide[7].

1.2.2. Technologies utilisés

Partie mobile :

2020/2021 Page 24
 Projet de fin d’étude

 FLUTTER :

un framework open source créé par Google pour la réalisation d’applications multiplateformes.
Il permet donc de construire en une seule fois des applications qui pourront être déployées pour
différentes plateformes (Android/iOS), et même plus avec l’arrivée de Flutter pour web et
desktop. En soit Flutter pourrait fonctionner sur n’importe quel device possédant un écran plus ou
moins intelligent. La première version a été release en Décembre 2018 ce qui en fait un
framework encore jeune.Flutter s’appuie sur le langage de programmation DART (à l’origine
appelé Dash), créé également par Google et présenté au public en 2011[8].

Figure 9 : logo de flutter

Flutter présente 2 spécificités principales :

Les widgets : ils permettent de décrire simplement le rendu final. Chaque objet est défini
indépendamment des contraintes parentes. C’est son emplacement dans le code qui permettra de
définir ses contraintes extérieures. Cela permet de construire facilement son interface ; le code est
alors plus facilement lisible et maintenable.

Les composants : ils ont été créés par Google. Les développeurs disposent d’une galerie de
composants s’adaptant à IOS comme Android, et aux différentes versions d’OS.

Avantage de flutter :

Multiplateformes :on peut développer une seule application et unique qui fonctionne à la fois
sur les plateformes Ios et Androïde..

La conception design considérablement simplifiée : Grâce à Flutter il est beaucoup plus facile
d’intégrer des animations dans les applications mobiles.

2020/2021 Page 25
 Projet de fin d’étude

Une maintenance accélérée et optimisée : Les corrections de bugs sont rapides et régulières.

Performance : flutter est plus rapide que les autres Framework multiplateforme (ionic , react-
native…) grâce a la communication directe avec les composant natifs.

Partie Web :

 Codeigniter :

Un framework web écrit en PHP , qui vante une conception logicielle compacte rendant le
développement d'applications Web plus rapide et plus efficace. Codeigniter a été créé par la
société américaine de logiciels EllisLab, qui a publié sa première version en février 2006[9].

Figure 10: logo de codeigniter

Construction et structure du Framework :

La conception orientée performance de CodeIgniter se reflète dans la construction allégée du

framework PHP. Elle est basée sur le modèle d'architecture logicielle appelé Modèle-Vue-
Contrôleur (MVC). Le principe fondamental du MVC est la séparation stricte du code du
programme et de la présentation. Elle est réalisée par une structure logicielle modulaire et
l'externalisation du code PHP. On différencie alors trois composants centraux : le modèle de
données (modèle), la présentation (vue) et le contrôleur[10].

Modèle : représente la structure de données d'une application Web développée sur la base de
CodeIgniter. Pour cela, des classes de modèles sont définies dans le code source. Il s'agit

2020/2021 Page 26
 Projet de fin d’étude

notamment de fonctions spéciales qui permettent d'extraire des informations d'une base de
données, de les stocker ou de les mettre à jour.

Vue : est la partie de l’application qui est présentée à l'utilisateur final. Elle retourne une
présentation des données venant du model. Il s'agit en principe d'un document HTML dans lequel
le contenu est intégré dynamiquement via PHP.

Controller: gère les requêtes des utilisateurs. Elle est responsable deretourner une réponse avec
l’aide mutuelle des couches Model et Vue. LesControllers peuvent être imaginés comme des
managers qui ont pour mission que toutes les ressources souhaitées pour accomplir une tâche
soient déléguées aux travailleurs corrects.

Figure 11: architecture de modèle-vue-Controller

1.2.3. Système de gestion de base de données

 PhpMyAdmin :

Est une application Web de gestion pour les systèmes de gestion de base de données MySQL
et Maria DB, réalisée principalement en PHP et distribuée sous licence GNU GPL .Il existe
plusieurs façons d’accéder à sa base de données et d’y faire des modifications. On peut utiliser une
ligne de commande (console), exécuter les requêtes en PHP ou faire appel à un programme

2020/2021 Page 27
 Projet de fin d’étude

qui nous permet d’avoir rapidement une vue d’ensemble. PhpMyAdmin est livré avec MAMP et
XAMPP [11].

2. Les interfaces de l’application

2.1. Partie administrative web

La partie administrative de notre application est accessible par un responsable de la fédération.

Dans ce qui suit on présente quelques interfaces de la partie administrative.

 Interface d’authentification

Cette interface permet l’administrateur de s’authentifier sur l’application pour permettre

d’accéder aux différentes fonctionnalités comme (modifier, ajouter et supprimer des adhérents,
traiter les demandes des licences, programmer des matchs…).

Figure 12: interface "authentification"

2020/2021 Page 28
 Projet de fin d’étude

 Interface d’accueil

Cette interface permet l’administrateur de consulter les nombres des adhérents et les nombres
des demandes des licences arrivés.

Figure 13: interface d’accueil

 Interface liste des clubs

A partir de cette interface, l’administrateur peut consulter la liste de tous les clubs qui existent
dans la base de données, comme il peut ajouter un nouveau club ou encore modifier un club
existant.

2020/2021 Page 29
 Projet de fin d’étude

Figure 14 : interfaces « liste des club »

.

 Interface liste des demandes des licences

Les interfaces suivantes permettent l’administrateur le traitement des demandes des licences
des coachs et joueurs. Elles se succèdent pour montrer le déroulement des opérations de ce cas.

Figure 15: interface « liste des demandes des licences »

2020/2021 Page 30
 Projet de fin d’étude

L’administrateur peut confirmer ou refuser la demande.

Figure 16: interface « traiter demande »

Une fois la demande est confirmé, un email est envoyé au joueur ou coach, contenant le numéro
de licence, le mot d’utilisateur et le mot de passe pour lui permet d’accéder a l’application
mobile.

Figure 17: interface « email envoyé »

 Interface listes des matchs

2020/2021 Page 31
 Projet de fin d’étude

Les interfaces suivantes permettent l’administrateur de programmer un match, affecter des

arbitres et les joueurs et enregistrer les résultats.

Figure 18: interface « programmer match »

Figure 19: interface « enregistrer résultats »

 Interface liste des examens de grade

2020/2021 Page 32
 Projet de fin d’étude

L’interface suivante permet l’administrateur de programmer un examen de grade pour les

joueurs, arbitres et coachs, et enregistrer les résultats.

Figure 20: interface « examens des grades»

2020/2021 Page 33
 Projet de fin d’étude

2.2. Partie mobile

la partie mobile de l'application est accessible par le responsable de club, le joueur , l'arbitre et le
coach et leur permet de faire différents taches .

Au premier lancement de l’application, une interface principale apparait et permet à l’utilisateur de

choisir son profil.

Figure 21: interface mobile « accueil »

2020/2021 Page 34
 Projet de fin d’étude

 Interface d’authentification

Cette interface permet à l„utilisateur de s„authentifier à travers son mot d’utilisateur et son mot
de passe pour accéder aux fonctionnalités de l„application.

Figure 22: interface « login»

2020/2021 Page 35
 Projet de fin d’étude

 Les interfaces de l’acteur responsable de club

L’interface accueil est un espace privé par le responsable de club dans laquelle il peut consulter
ses matchs, ses joueurs, ses coachs et demander des licences, il peut aussi consulter les
notifications et son profil.

Figure 23: interface « accueil »

2020/2021 Page 36
 Projet de fin d’étude

Quand la fédération programme un nouveau match, une notification est envoyé au responsable
de club pour qu'il connaitre qu'il a un match.

Figure 24: interface "notification"

2020/2021 Page 37
 Projet de fin d’étude

Les interfaces suivantes permettent au club de demander des licences pour ses joueurs et ses
coachs

Figure 25:interface "demander licence"

2020/2021 Page 38
 Projet de fin d’étude

Ces interfaces permettent au responsable de club de consulter ses matchs programmés et terminés
ainsi que les détails des résultats des matchs terminés.

Figure 26: interface "consulter nos matchs"

2020/2021 Page 39
 Projet de fin d’étude

D’après ces interfaces, le responsable de club peut consulter la liste de ses joueurs et ses coachs
(licenciés ou en attente).il peut aussi accéder a leur profile et les contacter par appel téléphonique
ou en envoyant un mail.

Figure 27 : interface « liste des joueurs »

2020/2021 Page 40
 Projet de fin d’étude

Figure 28: interface « profile joueur »

 Les interfaces de l’acteur « joueur »

L’interface accueil permet au joueur de consulter ses notifications, ses matchs et ses examens de
grades programmés et terminés.

2020/2021 Page 41
 Projet de fin d’étude

Figure 29:interfaces "accueil" et « examens de grade »

Signalons que les autres interfaces des autres acteurs (arbitre, coach) sont réalisés de la même
manière que l’acteur joueur.

2020/2021 Page 42
 Projet de fin d’étude

 Les interfaces « contact » et « a propos de nous »

Ces interfaces permettent au acteurs (responsable de club, joueur, arbitre et coach) de contacter
la fédération.

Figure 30: interfaces "contact" et "a propos de nous"

Conclusion
Dans ce chapitre nous avons présenté en détail la réalisation de notre projet en commençant
par la présentation des outils matériels et logiciels utilisés. Ensuite la seconde partie, nous avons
illustré le résultat de notre travail par des imprimes écran les plus importantes interfaces de note
application.

2020/2021 Page 43
 Projet de fin d’étude

Conclusion générale

Dans le cadre de notre projet de fin d’étude nous avons développé une application mobile
multiplateforme pour la gestion des compétitions pour la fédération tunisienne de yoseiken
budo. Dans ce contexte, nous avons cherché à développer une application facile à exploiter
cette application a permet d’améliorer les services de FTYB.

Ce projet m’a donné la faveur de mettre en pratique mes connaissances académiques acquises
tout au long de ma formation universitaire. En effet, j’ai eu l’opportunité de me familiariser avec
des technologies récentes telle que : Flutter, Codeigniter et la base de données PHPMYADMIN

Finalement, comme perspectives il sera intéressant :

 D’ajouter des statistiques pour les performances des joueurs et des clubs.
 D’ajouter des compétitions de championnat par système des points avec classement
pour chaque journée.

2020/2021 Page 44
 Projet de fin d’étude

Webographie

[1] https://fr.wikipedia.org/wiki/UML_(informatique)#Les_diagrammes

[2] https://cian.developpez.com/uml2/tutoriel/sequence/

[3] https://fr.wikipedia.org/wiki/StarUML

[4] https://www.journaldunet.fr/web-tech/guide-de-l-entreprise-digitale/1499171-figma-tout-
savoir-sur-l-outil-phare-de-design-collaboratif/

[5] https://code.visualstudio.com/docs

[6] https://fr.wikipedia.org/wiki/Postman_(logiciel)

[7] https://fr.wikipedia.org/wiki/XAMPP

[8] https://www.technologies-ebusiness.com/solutions/pourquoi-flutter

[9]https://www.ionos.fr/digitalguide/sites-internet/developpement-web/codeigniter-le-
framework-php-leger/

[10] https://www.ionos.fr/digitalguide/sites-internet/developpement-web/codeigniter-le-
framework-php-leger/

[11] https://fr.wikipedia.org/wiki/PhpMyAdmin

2020/2021 Page 45