Rapport Final

REPUBLIQUE TUNISIENNE UNIVERSITE DE SFAX
***** *****
MINISTERE DE L’ENSEIGNEMENT INSTITUT SUPERIEUR
SUPERIEUR ET DE LA RECHERCHE D’INFORMATIQUE ET DU
SCIENTIFIQUE MULTIMEDIA SFAX
N° d’ordre: 2013 224
MEMOIRE DE PROJET DE FIN D’ETUDES
Pour l’obtention du :
DIPLOME D’INGENIEUR EN INFORMATIQUE,

TECHNOLOGIE WEB ET MULTIMEDIA
Sujet :
SYSTÈME MOBILE POUR LA GESTION DES

ACTIVITÉS SPORTIVES DANS UNE SALLE DE SPORT
Réalisé par :
Houssem BELGHITH
Rawia ZOUARI
Soutenu, le 06/06/2013, devant le jury d’examen :
M. Walid MAHDI Président

M. Tarek ZLITNI Rapporteur
M. Bassem BOUAZIZ Encadreur
Année universitaire : 2012-2013

Dédicaces
En témoignage de ma gratitude
et de ma reconnaissance, je dédie ce travail à:
Mes parents,
Mes frères,
Mes proches,
Mes amis,
ET tous ceux qui se reconnaitront.
Houssem
Dédicaces
En témoignage de ma gratitude
et de ma reconnaissance, je dédie ce travail :
A Mon Père,
En vous je vois un père dévoué à sa famille. Ta présence en toute
circonstance m’a maintes fois rappelé
le sens de la responsabilité
A Ma Mère,
En vous je vois la maman parfaite, toujours prête à se sacrifier pour le
Bonheur de des enfants.
Merci pour tous.
Rawia
Remerciements
C'est avec un grand plaisir que nous réservons cette page en signe de gratitude et de
reconnaissance à tous ceux qui ont assisté à ce travail.
Nous tenons à remercier infiniment Monsieur Bassem BOUAZIZ pour la confiance

qu’il nous a accordée en acceptant d’encadrer notre travail, aussi pour sa patience lors de la
préparation des différentes tâches du projet.
Nous adressons aussi nos remerciements les plus sincères aux membres de jury,
Monsieur Walid MAHDI et Monsieur Tarek ZLITNI pour avoir l’extrême gentillesse de bien
vouloir évaluer notre travail.
Nous adressons nos remerciements à tout le personnel de la société All Soft Multimédia,
en particulier Monsieur Salah WERDA pour son accueil chaleureux et pour ses conseils
enrichissants.
Nous exprimons toute notre gratitude à tous ceux qui nous ont aidés de prés ou de loin à
réaliser notre travail.
Nous tenons à remercier enfin tous nos enseignants du département informatique de

l’Institut Supérieur d’Informatiques et de Multimédia de Sfax et toutes les personnes qui nous
ont encouragés.
Avant Propos
Cette étude entre dans le cadre de la préparation du projet de fin d’études en vue de
l’obtention du diplôme d’Ingénieur en Informatique, Technologie Web et Multimédia au sein
de l’Institut Supérieur d’Informatique et de Multimédia de Sfax.
C’est ainsi que nous avons eu l’occasion de préparer notre projet de fin d’étude
intitulé «Gestion des activités sportives dans une salle de sport» proposé par la société All
Soft Multimédia.
TABLE DES MATIÈRES
INTRODUCTION.....................................................................................................................1
CHAPITRE I : MODELISATION DES BESOINS..............................................................2
I.1. Introduction..................................................................................................................3
I.2. Présentation de l’entreprise..........................................................................................3
I.3. Contexte du projet........................................................................................................3
I.3.1. Problématique.......................................................................................................3
I.3.2. Objectifs à atteindre..............................................................................................4
I.3.3. Public visé.............................................................................................................4
I.4. Besoins fonctionnels et non fonctionnels.....................................................................4
I.4.1. Besoins fonctionnels.............................................................................................4
I.4.2. Besoins non fonctionnels......................................................................................6
I.5. Choix de la méthodologie de développement..............................................................7
I.6. Modèle des cas d’utilisation.........................................................................................8
I.6.1. Identification des acteurs......................................................................................9
I.6.2. Diagrammes des cas d’utilisation.........................................................................9
I.6.3. Description textuelle des cas d’utilisation..........................................................15
I.7. Calendrier d’action.....................................................................................................20
I.8. Conclusion..................................................................................................................20
CHAPITRE II : MODÈLE D’ANALYSE ET DE CONCEPTION...................................21
II.1. Introduction................................................................................................................22
II.2. Analyse des cas d’utilisation......................................................................................22
II.2.1. Diagrammes d’état transition..............................................................................22
II.2.1.1. Diagramme d’état transition « Abonnement_Séance »...............................23
II.2.1.2. Diagramme d’état transition « Abonnement_Prépayé»...............................24
II.2.1.3. Diagramme d’état transition « Adhérent»...................................................25
II.2.1.4. Diagramme d’état transition « Séance »......................................................26
II.2.1.5. Diagramme d’état transition « Réservation »..............................................27
II.2.2. Diagrammes d’activité........................................................................................27
II.2.2.1. Diagramme d’activité « Ajouter et confirmer inscription »........................28
II.2.2.2. Diagramme d’activité « Réservation »........................................................29
II.2.3. Diagrammes de séquence....................................................................................30
II.2.3.1. Diagramme de séquence « Ajouter inscription ».........................................30
II.2.3.2. Diagramme de séquence « Confirmer inscription »....................................31
II.2.3.3. Diagramme de séquence « Ajouter réservation »........................................32
II.2.3.4. Diagramme de séquence « Annuler réservation ».......................................33
II.2.4. Traçabilité entre le modèle d’analyse et le modèle de conception.....................34
II.2.5. Diagramme de classe du modèle de conception.................................................36
II.3. Représentation des classes.........................................................................................38
II.3.1. Liste des classes..................................................................................................38
II.3.2. Liste des attributs................................................................................................44
II.3.3. Diagramme de classe..........................................................................................47
II.4. Diagramme de navigation..........................................................................................49
II.4.1. L’arborescence de l’application WEB................................................................49
II.4.2. L’arborescence de l’application mobile..............................................................50
II.5. Conclusion..................................................................................................................51
CHAPITRE III : MODELE D’IMPLÉMENTATION.......................................................52
III.1. Introduction............................................................................................................53
III.2. Architecture physique du système..........................................................................53
III.3. Justification du choix..............................................................................................54
III.3.1. Architecture de développement MVC................................................................54
III.3.2. Utilisation des web service.................................................................................55
III.3.3. Protocole des services web.................................................................................55
III.3.3.1. Comparaison................................................................................................56
III.3.3.2. Choix retenu................................................................................................61
III.4. Environnement de réalisation.................................................................................61
III.4.1. Environnement matériel......................................................................................61
III.4.2. Environnement logiciel.......................................................................................61
III.5. Diagramme de déploiement....................................................................................63
III.6. Mapping vers le modèle logique de données..........................................................64
III.6.1. Les règles de mapping........................................................................................64
III.6.2. Modélisation logique/physique des données......................................................65
III.7. Illustration du test des web service.........................................................................67
III.8. Test de l’application...............................................................................................70
III.8.1. Test de l’application mobile................................................................................70
III.8.2. Test de l’application web....................................................................................73
III.9. Apports et problèmes rencontrés............................................................................76
III.9.1. Difficultés rencontrées........................................................................................76
III.9.2. Apports................................................................................................................76
III.10. Conclusion..............................................................................................................77
CONCLUSION GENERALE................................................................................................78
BIBLIOGRAPHIE..................................................................................................................79
WEBOGRAPHIE...................................................................................................................80
LISTE DES FIGURES
Figure I- 1 : Les phases du processus RUP.................................................................................8
Figure I- 2 : Diagramme des cas d’utilisation « Gestion des inscriptions ».............................10
Figure I- 3 : Diagramme des cas d’utilisation « Gestion des abonnements »...........................10
Figure I- 4 : Diagramme des cas d’utilisation « Gestion des locaux ».....................................11
Figure I- 5 : Diagramme des cas d’utilisation « Gestion des activités sportives »...................11
Figure I- 6 : Diagramme des cas d’utilisation « Planification des séances »............................12
Figure I- 7 : Diagramme des cas d’utilisation « Gestion des réservations ».............................13
Figure I- 8 : Diagramme des cas d’utilisation « Suivi des fréquences des réservations »........14
Figure I- 9 : Diagramme des cas d’utilisation « Fonctionnalités mobile »...............................14
Figure II- 1 : Diagramme d’état transition « Abonnement_Séance ».......................................23

Figure II- 2 : Diagramme d’état transition « Abonnement_Prépayé ».....................................24
Figure II- 3 : Diagramme d’état transition « Adhérent »..........................................................25
Figure II- 4 : Diagramme d’état transition « Séance»...............................................................26
Figure II- 5 : Diagramme d’état transition « Réservation».......................................................27
Figure II- 6 : Diagramme d’activité « Ajouter et confirmer inscription».................................28
Figure II- 7 : Diagramme d’activité « Ajouter réservation».....................................................29
Figure II- 8 : Diagramme de séquence « Ajouter inscription».................................................30
Figure II- 9 : Diagramme de séquence « Confirmer inscription».............................................31
Figure II- 10 : Diagramme de séquence « Ajouter réservation»...............................................32
Figure II- 11 : Diagramme de séquence « Annuler réservation»..............................................33
Figure II- 12 : Traçabilité entre le modèle d'analyse et le modèle de conception....................34
Figure II- 16 : Diagramme de classe du modèle de conception « Ajouter inscription »..........36
Figure II- 17 : Diagramme de classe du modèle de conception « Confirmer inscription »......36
Figure II- 18 : Diagramme de classe du modèle de conception « Ajouter réservation »..........37
Figure II- 19 : Diagramme de classe du modèle de conception « Annuler inscription ».........37
Figure II- 20 : Diagramme de classe.........................................................................................48
Figure II- 21 : Diagramme de navigation « Application web »................................................49
Figure II- 22 : Diagramme de navigation «Application mobile »...........................................50
Figure III- 1 : Architecture physique du système.....................................................................53

Figure III- 2 : Architecture du modèle MVC............................................................................54
Figure III- 3 : Diagramme de déploiement...............................................................................63
Figure III- 4 : Invocation du service web SOAP « GetAll_Reservation»................................67
Figure III- 5 : Résultat du service web SOAP « GetAll_Reservation»....................................68
Figure III- 6 : Test du service web REST « Authentification »................................................68
Figure III- 7 : Test du service web REST « GetActivites_ByMode »......................................69
Figure III- 8 : Test du service web REST « GetAll_Salle»......................................................69
Figure III- 9 : Ecran d’authentification.....................................................................................70
Figure III- 10 : Ecran de menu..................................................................................................70
Figure III- 11 : Ecran de paramètres.........................................................................................70
Figure III- 12 : Ecran choix du type d’abonnement..................................................................70
Figure III- 13 : Ecran liste d’abonnements prépayé..................................................................70
Figure III- 15 : Ecran de liste d’abonnement séance...............................................................71
Figure III- 16 : Ecran de choix du type de ressource à réserver...............................................71
Figure III- 17 : Ecran de la liste des leçons..............................................................................71
Figure III- 19 : Ecran de la liste des terrains.............................................................................71
Figure III- 20 : Ecran du choix de la date et le nombre de personnes......................................71
Figure III- 21 : Ecran des créneaux des terrains da la date choisie...........................................72
Figure III- 22 : Ecran des créneaux des terrains.......................................................................72
Figure III- 23 : Ecran de réservation.........................................................................................72
Figure III- 24 : Ecran d’ajout de réservation............................................................................72
Figure III- 25 : Ecran d’accueil.................................................................................................73
Figure III- 26 : Ecran de menu du responsable.........................................................................73
Figure III- 27 : Ecran de choix critères de statistique...............................................................74
Figure III- 28 : Ecran de graphe de la statistique......................................................................74
Figure III- 29 : Ecran de la liste des terrains.............................................................................75
Figure III- 30 : Ecran de description d’un terrain.....................................................................75
Figure III- 31 : Ecran de choix des informations......................................................................76
LISTE DES TABLEAUX
Tableau I- 1 : Description textuelle du cas d'utilisation « Ajouter inscription »......................15
Tableau I- 2 : Description textuelle du cas d'utilisation « Confirmer inscription »..................16
Tableau I- 5 : Calendrier d’action.............................................................................................20
Tableau II- 1 : Représentation de la classe « Salle »................................................................38

Tableau II- 2 : Représentation de la classe « Reservation ».....................................................38
Tableau II- 3 : Représentation de la classe « Membre»............................................................39
Tableau II- 4 : Représentation de la classe « Adherent»..........................................................39
Tableau II- 5 : Représentation de la classe « Seance ».............................................................40
Tableau II- 6 : Représentation de la classe « Entraineur ».......................................................40
Tableau II- 7 : Représentation de la classe « Planning »..........................................................41
Tableau II- 8 : Représentation de la classe « Creneau »...........................................................41
Tableau II- 9 : Représentation de la classe « JourSemaine »....................................................41
Tableau II- 10 : Représentation de la classe « TypeLocal ».....................................................42
Tableau II- 11 : Représentation de la classe « Local ».............................................................42
Tableau II- 12 : Représentation de la classe « Activite ».........................................................42
Tableau II- 13 : Représentation de la classe « Abonnement_Seance »....................................43
Tableau II- 14 : Représentation de la classe « Abonnement_Prepaye »...................................43
Tableau II- 15 : Représentation de la classe « Modele_Abonnement »...................................43
Tableau II- 16 : Représentation de la classe « Galerie »...........................................................44
Tableau II- 17 : Généralisation/Spécialisation..........................................................................44
Tableau II- 18 : Dictionnaire des données................................................................................44
Tableau III- 1 : Serveur PHP avec SOAP.................................................................................57

Tableau III- 2 : Client PHP avec SOAP....................................................................................57
Tableau III- 3 : Client Android avec SOAP..............................................................................57
Tableau III- 4 : Serveur PHP avec REST.................................................................................59
Tableau III- 5 : Client PHP avec REST....................................................................................59
Tableau III- 6 : Client Android avec REST..............................................................................59
Tableau III- 7 : Comparaison entre XML et JSON...................................................................60
Tableau III- 8 : Comparaison entre SOAP et REST.................................................................60
Tableau III- 9 : Technologies utilisées......................................................................................62
INTRODUCTION
INTRODUCTION
La fréquentation des salles de sport est généralement couplée à la disponibilité des
adhérents et leur proximité. Devant le nombre important de salles, certains cherchent des
moyens attractifs leurs permettant d’attirer le maximum d’adhérents tout en optimisant leur
rentabilité et leur taux d’occupation.
Par ailleurs, pour éviter les encombrements, les dirigeants de salle optent pour la
réservation au préalable mais cette solution reste statique et insatisfaisante pour certains
adhérents.
En ce qui concerne les adhérents, ils cherchent toujours des services qui correspondent
mieux à leurs besoins, qui s’adaptent à leur disponibilité et qui offre une accessibilité
permanente surtout lorsqu’il s’agit d’une salle de sport multi-sites.
Suite aux grandes mutations dans le marché du Smartphone, permettant une connexion
mobile à Internet par le réseau 3G ou wifi, ainsi, le web mobile constitue un excellent moyen
d'accroître les revenus d’une entreprise ce qui l’incite à s’adapter et exploiter ces opportunités
pour être compétitive.
L’objectif du présent travail est de concevoir et développer un système mobile

permettant non seulement d’automatiser l’ensemble des tâches de gestion d’une salle de sport
mais aussi d’offrir l’accessibilité.
Le présent mémoire s’articule autour de trois chapitres. Le premier chapitre,

modélisation des besoins, a pour objectif de présenter le contexte du projet et décrit les
besoins utilisateurs ainsi que les cas d’utilisation de l’application. Le deuxième traite l’analyse
des cas d’utilisation et la modélisation conceptuelle. Le troisième chapitre présente
l’environnement, l es détails et les résultats de la réalisation technique de l’application.
1
Chapitre I : MODELISATION
DES BESOINS
Chapitre. I.
Chapitre I : Modélisation des besoins
I.1. Introduction
Dans ce chapitre nous présentons le contexte du projet, la problématique et les objectifs
à atteindre. En ce qui suit, nous décrivons les besoins fonctionnels et non fonctionnels ainsi
que la méthodologie de développement à utiliser.
I.2. Présentation de l’entreprise

ASM (All Soft Multimédia) est une société de Conseil, dÍngénierie Informatique située
à Sfax en Tunisie. Elle propose des solutions de gestion et des solutions web & Multimédia
performantes.
Elle accompagne ses clients dans la réalisation de tous leurs projets Internet : (Création
de site vitrine, site e-commerce, site catalogue, Référencement, création graphique, Conseil
& Audit), et de tous leurs Projets de Gestion: (Gestion de Paie, Gestion de Parc, Gestion d
Áchat, etc.…)
 Contact :
o Adresse : Av.de la liberté Im. El Itkan 3ème étage Bureau. 11 - Sfax 3027.
o Téléphone : (+216) 74 415 055.
o Fax : (+216) 74 415 044.
o E-mail : contact@asm.com.tn
I.3. Contexte du projet

Dans cette section, nous expliquons le sujet de notre projet, sa problématique et son but.
I.3.1. Problématique
Le sport est devenu une nécessité dans notre vie quotidienne. En fait, pour le pratiquer
régulièrement, les séances sont fixées à l’avance ce qui provoque un engagement envers soi.
A cause des préoccupations humaines, les adhérents de salles de sport ne peuvent pas profiter
des séances qui leurs sont allouées vu que les planifications sont fixées au préalable. Il est
3
difficile donc d’adapter les délais de disponibilités aux séances planifiées surtout lorsqu’il
s’agit d’une leçon ou d’un déplacement de l’adhérent.
I.3.2. Objectifs à atteindre

Notre objectif est de concevoir et développer un système mobile pour la gestion des
activités dans une salle de sport afin faciliter l’accessibilité à toutes les informations
concernant une salle de sport quelque soit le dispositif de connexion.
I.3.3. Public visé

Notre projet s’adresse en particulier aux adhérents et aux particuliers qui désirent suivre
des cours dans une salle de sport.
I.4. Besoins fonctionnels et non fonctionnels

Nous présentons dans ce qui suit tous les besoins non fonctionnels de l’application ainsi
que les besoins fonctionnels classés par acteur.
I.4.1. Besoins fonctionnels

Les acteurs de notre système se répartissent en deux catégories, soit un administrateur
soit un adhérent.
 Adhérent
Cette application doit permettre aux adhérents de :
o Créer un compte.
o Modifier son adresse, code postale, numéro de téléphone, ville et mot de

passe en cas de besoin.
o S’identifier.
o Consulter les plannings et la disponibilité des terrains et/ou des leçons pour
une salle choisie.
o Réserver en ligne un terrain et/ou dans une séance planifiée pour une leçon
spécifique.
4
o Consulter et/ou annuler leurs réservations tout en respectant les délais

d’annulation spécifiques à la salle de la réservation.
o Visualiser leurs abonnements actifs et expirés selon leur type (prépayé, par
séance).
o Consulter les informations (description, images et vidéos) de tous les terrains

et les leçons de toutes les salles.
 Administrateur
Cette application permet à l’administrateur de :
o Confirmer les demandes d'inscription des adhérents suite à la génération des

abonnements.
o Ajouter et annuler les réservations des adhérents.
o Consulter les réservations des adhérents et/ou d’un terrain et/ou d’une leçon à
un moment donné.
o Consulter les abonnements des adhérents selon un type (prépayé, par séance)
et/ou un modèle.
o Planifier les séances d’une leçon spécifique dans un local donné sous la
supervision d’un entraineur.
o Ajouter les informations (description, images et vidéos) des terrains et des

leçons
o Consulter les statistiques des réservations des leçons et/ou des terrains depuis
les adhérents, et lui offre des graphes statistiques.
5
I.4.2. Besoins non fonctionnels

Les besoins non fonctionnels représentent les exigences implicites auquel le système
doit répondre. Parmi ces besoins on cite :
 Ergonomie et souplesse
o L’adhérent doit être guidé lors de la réservation par la numérotation des

étapes dans chaque fenêtre.
o Les dates doivent être introduites à travers un calendrier.
o les informations numériques comme le numéro de téléphone doit avoir des

widgets spécifiques.
o L’application doit être simple à utiliser à traves la mise en place des

widgets simple comme les listes et les menus déroulant.
 Rapidité
o L'application doit optimiser les traitements pour avoir un temps de

rechargement des informations après l’ajout d’une réservation.
 La performance
o L’application doit garantir la sécurité à travers la gestion des droits d’accès.
o l’application doit être avant tout performante c'est-à- dire à travers ses
fonctionnalités, répond à toutes les exigences des usagers d’une manière
optimale.
 Maintenabilité et sociabilité
o Le code de l'application doit être lisible et compréhensible afin d'assurer son

évolutivité et extensibilité par rapport aux besoins du marché.
6
I.5. Choix de la méthodologie de développement

Il existe deux approches de conceptions. L'approche fonctionnelle qui voit le système
comme un ensemble de fonctions à réaliser et l'approche objet qui voit le système comme un
ensemble d'objets. [1]
Vue l’ampleur de notre projet nous avons choisi l'approche objet. En effet, la
modélisation objet consiste à créer une représentation informatique des éléments du monde
réel. Elle définit un cadre générique de développement objet facile à réutiliser avec
l’utilisation UML (Unified Modeling Language) comme un langage de modélisation et la
méthodologie RUP (Rational Unified Process) comme processus de développement.
 UML
UML (Unified Modeling Language) est un langage de modélisation graphique apparu

dans le monde du génie logiciel dans le cadre de la conception orientée objet. C’est
l’accomplissement de la fusion de précédents langages de modélisation objet: Booch, OMT,
OOSE. UML est à présent un standard défini par l’OMG (Object Management Group). [2]
 RUP
RUP est un processus basé sur une approche disciplinée afin de bien maîtriser
l’assignation des tâches et la responsabilisation des différents acteurs participant au cycle de
développement du logiciel
RUP est adopté lors des projets complexes. Il a pour objectif principal de faire appliquer
les bonnes pratiques de développement aux entreprises, ce qui confère au produit final une
meilleure qualité. [3]
Il se déroule selon quatre phases (Figure I-1) qui sont l’inception, l’élaboration, la
construction et la transition. [4]
7
Figure I- 1 : Les phases du processus RUP
o Inception : Définir la portée du projet.
o Elaboration : Planifier le projet, spécifier les fonctionnalités, construire

l’architecture.
o Construction : Construire le produit.
o Transition : Transition du produit vers les utilisateurs.
I.6. Modèle des cas d’utilisation

Le modèle des cas d’utilisation comprend les acteurs, le système et les cas d’utilisation.
L’ensemble des fonctionnalités du système est déterminé en examinant les besoins de chaque
acteur, exprimés sous forme de famille d’interactions dans les cas d’utilisation.
8
I.6.1. Identification des acteurs

Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système dans
le but de réaliser une valeur ajoutée.
Les acteurs qui participent à cette application sont:
 L’adhérent
Il représente un client disposant d’un abonnement dans une salle de sport.
 L’administrateur
Il représente un agent administratif possédant tous les droits d'accès pour interagir avec le
système.
 L’agent d’accueil
Il représente un agent d’accueil d’une salle de sport possédant les droits d’accès nécessaire
pour effectuer des réservations aux membres.
 L’entraineur
Il représente le superviseur d’une ou de plusieurs leçons.
 Le membre
Il représente un client dans une salle de sport.
I.6.2. Diagrammes des cas d’utilisation

Afin de simplifier la lecture et la compréhension des diagrammes, nous proposons de
regrouper les cas d’utilisation en fonctionnalité.
9
Figure I- 2 : Diagramme des cas d’utilisation « Gestion des inscriptions »
Figure I- 3 : Diagramme des cas d’utilisation « Gestion des abonnements »
10
Figure I- 4 : Diagramme des cas d’utilisation « Gestion des locaux »
Figure I- 5 : Diagramme des cas d’utilisation « Gestion des activités sportives »
11
Figure I- 6 : Diagramme des cas d’utilisation « Planification des séances »
12
Figure I- 7 : Diagramme des cas d’utilisation « Gestion des réservations »
13
Figure I- 8 : Diagramme des cas d’utilisation « Suivi des fréquences des réservations »
Figure I- 9 : Diagramme des cas d’utilisation « Fonctionnalités mobile »
14
I.6.3. Description textuelle des cas d’utilisation

Nous allons détailler par la suite les cas d’utilisation en élaborant les scénarios
nominaux et alternatifs.
Tableau I- 1 : Description textuelle du cas d'utilisation « Ajouter inscription »
Sommaire d’identification
Titre Ajouter inscription
Acteur Membre
Objectif Permettre au membre d’effectuer une inscription.
Description des enchainements

Pré condition Post condition
 Inscription effectuée avec sucées.
Scénario nominal
1. Le membre demande la rubrique inscription.
2. Le système affiche le formulaire d’inscription.
3. Le membre remplit le formulaire.
4. Le système vérifie les informations d’inscription.
5. Le membre valide l’inscription.
6. Le système enregistre l’inscription.
Scénario échecs
5.a. Erreur de saisie d’informations :
 Le système affiche (« Vérifiez vos coordonnées »).
 Le cas d’utilisation reprend à l’action 2 du scénario nominal.
5.b. Login existant :
 Le système affiche (« Adhérent existant »).
15
Tableau I- 2 : Description textuelle du cas d'utilisation « Confirmer inscription »
Titre Confirmer inscription
Acteur Administrateur
Permettre à l’administrateur de confirmer une inscription à travers la
Objectif
génération d’un abonnement.

 L’administrateur doit être  Abonnement généré avec sucées.
authentifié.
 Inscription confirmée
 L’inscription à confirmer doit
être crée.
Scénario nominal
1. L’administrateur demande la liste des inscriptions non encore confirmées.
2. Le système affiche la liste d’inscriptions non encore confirmées.
3. L’administrateur choisit l’inscription à confirmer.
4. Le système affiche les informations de l’inscription choisie (adhérent).
5. L’administrateur demande l’ajout d’un abonnement.
6. Le système demande le type d’abonnement (Prépayé ou par séance).
7. L’administrateur choisit l’abonnement prépayé.
8. Le système demande la date début et la durée de l’abonnement prépayé.
9. L’administrateur saisit la date début et la durée de l’abonnement prépayé.
10. Le système demande le modèle d’abonnement.
11. L’administrateur choisit un modèle d’abonnement défini.
12. Le système génère l’abonnement lié à cette inscription.
13. Le système affiche « abonnement ajouté ».
16
Scénarios alternatifs
7.a. L’administrateur choisit l’abonnement par séance :
 Le système demande le nombre de séances à accorder.
 L’administrateur saisit le nombre de séances pour l’abonnement séance.
Titre Ajouter réservation
Acteur Adhérent
Permettre à l’adhérent d’effectuer une réservation d’une ressource
Objectif
(terrain, leçon).

 La date et l’heure de réservation  Réservation ajoutée.
doivent être supérieures à la date
Système.
 La capacité de la séance à
réserver doit être suffisante.
 L’abonnement de l’adhérent doit
être valide.
 L’adhérent doit être authentifié
Scénario nominal
1. L’adhérent demande la rubrique réservation.
2. Le système affiche la liste des abonnements actifs de l’adhérent.
3. L’adhérent choisit un abonnement.
4. Le système affiche la liste des types de ressources (terrain, leçon).
5. L’adhérent choisit le type de ressource à réserver.
6. Le système affiche la liste des ressources du type sélectionné liées à

l’abonnement déjà choisi.
17
7. L’adhérent choisit une ressource.
8. Le système demande la date et le nombre de personne.
9. L’adhérent saisit la date et le nombre de personne.
10. Le système vérifie la capacité et la disponibilité de la ressource.
11. Le système affiche la liste des séances pour la ressource et la date choisie.
12. L’adhérent choisit la séance à réserver.
13. Le système vérifie la disponibilité de la séance choisie.
14. Le système affiche la réservation à enregistrer.
15. L’adhérent confirme la réservation.
16. Le système vérifie de nouveau la disponibilité de la séance.
17. Le système enregistre la réservation et met à jour la séance.
Scénarios alternatifs
7.a. L’adhérent demande le changement de la salle
 Le système vérifie le type d’abonnement (critère de multi-salle).
Scénarios d’échecs
11.a. Capacité indisponible :
 Le système affiche (« Capacité indisponible »).
14.a. Mode de réservation de la séance est hors ligne :
 Le système affiche (« Vous ne pouvez pas réserver cette séance en ligne »).
14.b. Séance déjà réservée :
 Le système affiche (« Séance réservée veuillez choisir une autre »).
17.a. Séance non disponible :
 Le système affiche (« Réservation non ajoutée veuillez choisir une autre »).
18
Titre Annuler réservation
Acteur Adhérent
Objectif Permettre à l’adhérent d’annuler une réservation.

 Le délai et la date système doit  Réservation annulée avec sucées.
être inférieur à la date de la
séance.  Séance mise à jour.
 L’adhérent doit être authentifié  Abonnement mis à jour.
Scénario nominal
1. L’adhérent demande la rubrique mes réservations.
2. Le système affiche la liste des réservations non encore achevées.
3. L’adhérent sélectionne la réservation à annuler.
4. Le système affiche la réservation et demande la confirmation d’annulation.
5. L’adhérent confirme l’annulation.
6. Le système vérifie le délai d’annulation.
7. Le système annule la réservation et met à jour la séance et l’abonnement.
Scénarios d’échecs
7.a. Délai dépassé :
 Le système affiche (« Vous ne pouvez plus annuler cette réservation »).
19
I.7. Calendrier d’action

Un bon planning est la clé principale de la réussite d’un projet. En effet, le
planning aide à bien subdiviser le travail et séparer les taches à réaliser.
Dans notre projet, nous avons estimé de réaliser notre application dans une durée
approximative de quatre mois. Le tableau ci-dessous montre le planning que nous
avons adapté pour la réalisation des différentes parties du projet.
Tableau I- 5 : Calendrier d’action

Semaine Février Mars Avril Mai
Etape
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Modélisation des besoins
Conception
Réalisation
Rédaction du rapport
I.8. Conclusion
Ce chapitre nous a permis de couvrir les différents besoins fonctionnels et non
fonctionnels des acteurs de notre application. Nous avons fourni une représentation
détaillée de ces besoins grâce à un diagramme de cas d'utilisation relatif aux acteurs
réagissant avec l’application. Le chapitre qui suit, portera sur la partie analyse et
conception.
20
CHAPITRE II : MODÈLE
D’ANALYSE ET DE
CONCEPTION
Chapitre. II.
Chapitre II : Modèle d’analyse et de conception
II.1. Introduction
Après avoir identifié les besoins de notre application exprimés par les cas d’utilisation,
nous procédons dans ce qui suit à l’analyse des besoins afin d’avoir une représentation
raffinée permettant de couvrir tous les aspects de l’application.
II.2. Analyse des cas d’utilisation

Dans cette partie nous allons analyser les différentes fonctionnalités présentées déjà
dans les diagrammes des cas d’utilisation.
II.2.1. Diagrammes d’état transition

Les objets d’une classe ne sont pas figés, ils peuvent évoluer et changer d’états au cours
de leur cycle de vie (intervalle de temps entre la création et la suppression de l’objet). [5]
Un diagramme d'état montre les états potentiels d'un objet, et les transitions d'un état à
un autre. Une transition est déclenchée par un événement, il peut y avoir une condition de
garde, et une action associée à la transition. [6]
Un diagramme d’état de transition d’une classe est une description des évolutions
possibles de ses objets.
Il donne :
o La liste des états que peut prendre l’objet durant son cycle de vie ;
o les événements déclenchant les changements d’états ;
o les éventuelles conditions qu’il doit vérifier avant de changer d’état ;
o les opérations qui le font passer d’un état à autre.
Pour présenter les états des objets interactifs dans notre application nous présentons les
diagrammes d’état de transition pour les occurrences d’objets suivants :
 Abonnement_Séance
 Abonnement_Prépayé
22
 Adhérent
 Séance
 Réservation
II.2.1.1. Diagramme d’état transition « Abonnement_Séance »
L’abonnement séance dans notre cas débute par l’état "actif". Si le nombre de séance
atteint la valeur zéro, l’état à ce moment devient "expiré" sinon il reste à l’état "actif". S’il ya
eu un renouvellement l’état passe de "expiré" à "actif" comme le montre la Figure II-1.
Figure II- 1 : Diagramme d’état transition « Abonnement_Séance »
23
II.2.1.2. Diagramme d’état transition « Abonnement_Prépayé»
L’abonnement prépayé dans notre cas débute par l’état "actif". Si la date de début et la
durée de l’abonnement sont supérieures à la date du système l’état à ce moment devient
"expiré" sinon il reste à l’état "actif". S’il ya eu un renouvellement l’état passe de "expiré" à
"actif" comme le montre la Figure II-2.
Figure II- 2 : Diagramme d’état transition « Abonnement_Prépayé »
24
II.2.1.3. Diagramme d’état transition « Adhérent»
L’adhérent dans notre cas débute par l’état "utilisateur". Lors d’une inscription l’état
devient "Membre". Suite à la génération d’un abonnement l’état devient "Adhérent actif". Une
fois l’abonnement de ce dernier est expiré l’état passe à "Adhérent Inactif". S’il ya eu un
renouvellement d’abonnement l’état passe de "Adhérent Inactif" à "Adhérent actif" comme le
montre la Figure II-3.
Figure II- 3 : Diagramme d’état transition « Adhérent »
25
II.2.1.4. Diagramme d’état transition « Séance »
Toute nouvelle séance passe automatiquement par l’état "Planifiée". Lors d’une
réservation l’état à ce moment devient "Réservée" si la capacité disponible atteint zéro sinon
elle ne change pas d’état. Dans le cas ou la date système est la même que la date de la séance
et l’heure système supérieur à l’heure de la séance l’état passe à "Effectuée". Une fois
l’adhérent annule la réservation avant que le délai est atteint elle revient "Planifiée" comme le
montre la Figure II-4.
Figure II- 4 : Diagramme d’état transition « Séance»
26
II.2.1.5. Diagramme d’état transition « Réservation »
A la création d’une réservation l’état est "Valide". Lors d’une annulation l’état devient
"Annulée" si la date d’annulation est inférieure au délai fixé. Une fois la date système
devienne supérieure à la date de réservation l’état devient "Archivée" comme le montre la
Figure II-5.
Figure II- 5 : Diagramme d’état transition « Réservation»
II.2.2. Diagrammes d’activité

Le diagramme d’activité présente un certain nombre de points communs avec le
diagramme d’état-transition puisqu’il concerne le comportement interne des opérations ou des
cas d’utilisation. Cependant le comportement visé ici s’applique aux flots de contrôle et aux
flots de données propres à un ensemble d’activités et non plus relativement à une seule classe.
[3]
Le passage d'une activité vers une autre est matérialisé par une transition. Les
transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une
autre (elles sont automatiques). [7]
27
II.2.2.1. Diagramme d’activité « Ajouter et confirmer inscription »
L’inscription se fait par le membre, une fois les informations sont valides, un objet
adhérent est crée. "Adhérent" ainsi créé reste en attente jusqu’à la génération d’un
abonnement auprès de l’administrateur. Finalement une notification de confirmation est
envoyée à l’adhérent.
Figure II- 6 : Diagramme d’activité « Ajouter et confirmer inscription»
28
II.2.2.2. Diagramme d’activité « Réservation »
Une fois les informations d’authentification sont valides, un menu s’affiche à l’écran.
Pour réserver une certaine ressource, l’adhérent suivre les étapes suivantes: le choix de
l’abonnement à réserver, le choix de la ressource elle-même (dans le cas ou l’abonnement
choisi est multi-salle, l’adhérent peut migrer vers une autre salle) alors une liste de séances est
affichée selon la date, la salle et l’activité choisie. L’adhérent doit choisir une séance et
valider sa réservation.
Figure II- 7 : Diagramme d’activité « Ajouter réservation»
29
II.2.3. Diagrammes de séquence

Les diagrammes de séquences permettent de représenter des collaborations entre objets
selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages.
L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du
diagramme; le temps s'écoule "de haut en bas" de cet axe. La disposition des objets sur l'axe
horizontal n'a pas de conséquences pour la sémantique du diagramme. [8]
II.2.3.1. Diagramme de séquence « Ajouter inscription »
Figure II- 8 : Diagramme de séquence « Ajouter inscription»
II.2.3.2. Diagramme de séquence « Confirmer inscription »

30
Figure II- 9 : Diagramme de séquence « Confirmer inscription»
II.2.3.3. Diagramme de séquence « Ajouter réservation »
31
Figure II- 10 : Diagramme de séquence « Ajouter réservation»
II.2.3.4. Diagramme de séquence « Annuler réservation »
32
Figure II- 11 : Diagramme de séquence « Annuler réservation»
II.2.4. Traçabilité entre le modèle d’analyse et le modèle de conception

Les diagrammes de traçabilité entre le modèle d’analyse et le modèle de conception
permettent d’élaborer les classes correspondantes pour chaque objet du modèle d’analyse.
33
 Ajouter inscription
La figure II-12, ci-dessous montre la traçabilité entre le modèle d’analyse et le modèle

de conception pour le cas d’utilisation « Ajouter inscription ».
Figure II- 12 : Traçabilité entre le modèle d'analyse et le modèle de conception

« Ajouter inscription »
 Confirmer inscription

de conception pour le cas d’utilisation « Confirmer inscription ».

« Confirmer inscription »
 Ajouter réservation

de conception pour le cas d’utilisation « Ajouter réservation ».
34

« Ajouter réservation »
 Annuler réservation

de conception pour le cas d’utilisation « Annuler réservation ».

« Annuler inscription »
II.2.5. Diagramme de classe du modèle de conception

Nous allons dégager par la suite, les diagrammes de classes du modèle de conception
des cas d’utilisation suivantes : Ajouter inscription, Confirmer inscription, Ajouter réservation
et Annuler réservation.
35
 Ajouter inscription
La figure II-16 présente le digramme de classe du modèle de conception pour le cas

d’utilisation ajouter inscription.
Figure II- 16 : Diagramme de classe du modèle de conception « Ajouter inscription »
 Confirmer inscription

d’utilisation confirmer inscription.
Figure II- 17 : Diagramme de classe du modèle de conception « Confirmer inscription »
36
 Ajouter réservation

d’utilisation ajouter réservation.
Figure II- 18 : Diagramme de classe du modèle de conception « Ajouter réservation »
 Annuler réservation
La figure présente le digramme de classe du modèle de conception pour le cas

d’utilisation annuler réservation.
Figure II- 19 : Diagramme de classe du modèle de conception « Annuler inscription »
37
II.3. Représentation des classes

Dans ce qui suit nous allons définir les classes et la liste des attributs pour élaborer le
diagramme de classe de notre système.
II.3.1. Liste des classes
 C01 : Classe Salle

Tableau II- 1 : Représentation de la classe « Salle »
Attribut Méthodes
N° Code
1 id_salle
2 nom_salle getAll()
3 ville_salle AddSalle(Salle)
4 adresse_salle getSalle_ById(id_salle)
5 numero_tel_salle
6 logo_salle
 C02 : Classe Reservation

Tableau II- 2 : Représentation de la classe « Reservation »
Attribut Méthodes
N° Code getAll()
1 id_res AddReservation(Reservation)
2 date_res getReservation_ById(id_salle)
3 heure_res getListReservation_ByAdhérent(Adherent)
4 etat_res getListReservation_BySeance(Seance)
5 nombre_personne DeleteReservation(Reservation)
38
 C03 : Classe Membre

Tableau II- 3 : Représentation de la classe « Membre»
Attribut Méthodes
N
Code
°
getAll()
1 Id
AddMembre(Membre)
2 Nom
UpdateMembre(Membre)
3 Prenom
getMembre_ById(id)
4 numero_tel
5 date_nais
 C04 : Classe Adherent

Tableau II- 4 : Représentation de la classe « Adherent»
Attribut Méthodes
N° Code
1 id_adh
2 nom_adh
3 prenom_adh getAll()
4 numero_tel_adh AddAdhérent(Adhérent)
5 date_nais_adh UpdateAdherent(Adhérent)
6 Login getAdherent_ById(id_adh)
7 Mdp getAdherent_ByLogin(Adhérent)
8 Sexe Authentification(login,mdp)
9 Adresse
10 code_postal
11 Ville
39
 C05 : Classe Seance

Tableau II- 5 : Représentation de la classe « Seance »
Attribut Méthodes
N° Code getAll()
1 id_seance AddSeance(Seance)
2 capacite_disp_seance getSeance_ById(id_seance)
getListSeance_ByLocal(Local)
3 description_seance
getListSeance_ByDate()
getListSeance_ByActivite()
4 date_seance deleteSeance(Seance)
incrementerCapacite(Seance)
decrementerCapacite(Seance)
 C06 : Classe Entraineur

Tableau II- 6 : Représentation de la classe « Entraineur »
Attribut Méthodes
N
Code
°
1 id_entraineur
getAll()
2 nom_entraineur
AddEntraineur(Entraineur)
3 prenom_entraineur
UpdateEntraineur(Entraineur)
4 login_entraineur
getEntraineur_ById(id_entraineur)
5 mdp_entraineur
6 numero_tel_entraineur
7 date_nais_entraineur
40
 C07 : Classe Planning

Tableau II- 7 : Représentation de la classe « Planning »
Attribut Méthodes
N° Code
getAll()
1 id_planning
AddPlanning(Planning)
2 Periode
getPlanning_ById(id_planning)
3 Annee
getPlanning_ByDate()
4 description_planning
 C08 : Classe Creneau

Tableau II- 8 : Représentation de la classe « Creneau »
Attribut Méthodes
N° Code
getAll()
1 id_creneau
getCreneau_ByAll(TypeLocal,JourSemaine,Planning)
2 heure_debut
AddCreneau(Creneau)
3 Duree
getCreneau_ById(id_creneau)
4 mode_res_creneau
 C09 : Classe JourSemaine

Tableau II- 9 : Représentation de la classe « JourSemaine »
Attribut Méthodes
N° Code getAll()
1 id_jour getJour_ById(id_jour)
2 nom_jour getJour_ByDate(JourSemaine
41
 C10 : Classe TypeLocal

Tableau II- 10 : Représentation de la classe « TypeLocal »
Attribut Méthodes
N° Code
getAll()
1 id_type_local
getTypeLocal_ById(id_type_local)
2 nom_type_local
 C11 : Classe Local

Tableau II- 11 : Représentation de la classe « Local »
Attribut Méthodes
N° Code
getAll()
1 id_local
getLocal_ById(id_local)
2 nom_local
getLocal_ByActivite(Activite)
3 capacite_local
getListLocal_ByTypeLocal(TypeLocal)
4 description_local
getListLocal_ByMode_Salle(Salle,mode)
5 mode_res_local
 C12 : Classe Actvite

Tableau II- 12 : Représentation de la classe « Activite »
Attribut Méthodes
N° Code getAll()
1 id_activite getActivite_ById(id_activite)
2 nom_actvite getActivite_ByLocal(Local)
3 description_activite getActivite_ByEntraineur(Entraineur)
4 mode_res_activite getActivite_ByMode(mode)
42
 C13 : Classe Abonnement_Seance

Tableau II- 13 : Représentation de la classe « Abonnement_Seance »
Attribut Méthodes
N° Code getAll()
1 id_abo getAbonnement_ById(id_abo)
2 code_carte getListAbonnementSeance_ByAdhérent(Adhérent)
getAbonnement_ByEtat(etat)
3 etat_abo
hasAbonnementSeance_MultiSalle(Adhérent)
4 nombre_seance incrementer_nbreSeance(Abonnement_seance)
deccrementer_nbreSeance(Abonnement_seance)
 C14 : Classe Abonnement_Prepaye

Tableau II- 14 : Représentation de la classe « Abonnement_Prepaye »
Attribut Méthodes
N° Code
getAll()
1 id_abo
getAbonnement_ById(id_abo)
2 code_carte
getListAbonnementPrépayé_ByAdhérent(Adhérent)
3 etat_abo
getAbonnement_ByEtat(etat)
4 date_debut_abo
hasAbonnementPrépayé_MultiSalle(Adhérent)
5 duree_abo
 C15 : Classe Modele_Abonnement

Tableau II- 15 : Représentation de la classe « Modele_Abonnement »
Attribut Méthodes
N° Code
1 id_modele getAll()
2 nom_modele getModele_ById(id_activite)
3 description_modele
4 multi_salle
43
 C16: Classe Galerie

Tableau II- 16 : Représentation de la classe « Galerie »
Attribut Méthodes
N° Code
1 id_galerie
getById()
2 Type
getByType()
3 Nom
AddMedia()
4 Description
5 Chemin
 Généralisation/Spécialisation
Tableau II- 17 : Généralisation/Spécialisation
Super-Classe Sous-Classes
Abonnement_Seance
Abonnement
Abonnement_Prepaye
Membre Adherent
II.3.2. Liste des attributs

Tableau II- 18 : Dictionnaire des données
N° Attribut Libelle Type Taille
1 id_salle Identifiant d’une salle Entier -
2 nom_salle Nom d’une salle Chaine de caractère 45
3 ville_salle Ville d’une salle Chaine de caractère 45
4 adresse_salle Adresse d’une salle Chaine de caractère 200
5 numero_tel_salle Numéro téléphone d’une salle Entier long
6 logo_salle Logo d’une salle Chaine de caractère 100
Le délai d’annulation d’une
7 delai_annulation Entier -
réservation pour une salle
8 id_res Identifiant d’une réservation Entier -
9 date_res Date d’une réservation Date -
10 heure_res Heure d’une réservation Date -
11 etat_res Etat d’une réservation Chaine de caractère 45
44
Nombre de personne pour une

12 nombre_personne Entier -
réservation
13 id Identifiant d’un membre Entier -
14 nom Nom d’un membre Chaine de caractère 45
15 prenom Prénom d’un membre Chaine de caractère 45
Numéro téléphone d’un
16 numero_tel Entier Long -
membre
La date de naissance d’un
17 date_nais Date -
membre
18 id_seance Identifiant d’une séance Entier -
Capacité disponible d’une
19 capacite_disp_seance Entier -
séance
20 description_seance Description d’une séance Chaine de caractère 200
21 date_seance Date d’une séance Date -
22 id_entraineur Identifiant d’un entraineur Entier -
23 nom_entraineur Nom d’un entraineur Chaine de caractère 45
24 prenom_entraineur Prénom d’un entraineur Chaine de caractère 45
25 login_entraineur Login d’un entraineur Chaine de caractère 45
26 mdp_entraineur Mot de passe d’un entraineur Chaine de caractère 45
Numéro téléphone d’un
27 numero_tel_entraineur Entier long -
entraineur
28 date_nais_entraineur Date naissance d’un entraineur Date -
29 id_planning Identifiant d’un planning Entier -
30 periode Période d’un planning Chaine de caractère 45
31 annee L’année d’un planning Date -
32 description_planning Description d’un planning Chaine de caractère 200
33 id_creneau Identifiant d’un créneau Entier -
34 heure_debut L’heure début d’un créneau Date -
35 duree La durée d’un créneau Entier -
36 mode_res_creneau Mode réservation d’un créneau Chaine de caractère 45
37 id_jour Identifiant d’un jour Entier -
38 nom_jour Nom du jour Chaine de caractère 45
39 id_type_local Identifiant d’un type local Entier -
40 nom_type_local Nom d’un type local Chaine de caractère 45
45
41 id_local Identifiant d’un local Entier -

42 nom_local Nom d’un local Chaine de caractère 45
43 capacite_local Capacité d’un local Entier -
44 description_local Description d’un local Chaine de caractère 200
45 mode_res_local Mode réservation d’un local Chaine de caractère 45

Identifiant d’une activité Entier -
46 id_activite
sportive
47 nom_actvite Nom d’une activité sportive Chaine de caractère 45
Description d’une activité Chaine de caractère 200
48 description_activite
sportive
Mode réservation d’une Chaine de caractère 45
49 mode_res_activite
activité sportive
50 login Login d’un adhérent Chaine de caractère 45
51 mdp Mot de passe d’un adhérent Chaine de caractère 45
52 sexe Sexe d’un adhérent Chaine de caractère 45
53 adresse Adresse d’un adhérent Chaine de caractère 200
54 code_postal code postal d’un adhérent Entier -
55 ville ville d’un adhérent Chaine de caractère 45
56 id_abo id d’un abonnement Entier -
57 code_carte Code d’un abonnement Entier -
58 etat_abo Etat d’un abonnement Chaine de caractère 45

Nombre de séance pour un Entier -
59 nombre_seance
abonnement séance
Date début d’un abonnement Date -
60 date_debut_abo
prépayé
La durée d’un abonnement Date -
61 duree_abo
prépayé
Identifiant d’un modèle Entier -
62 id_modele
d’abonnement
Nom d’un modèle Chaine de caractère 45
63 nom_modele
d’abonnement
Description d’un modèle Chaine de caractère 200
64 description_modele
d’abonnement
Modèle d’abonnement multi- Booléen -
65 multi_salle
salle ou non
66 id_galerie Identifiant d’une galerie Entier -
67 type Type d’une galerie Chaine de caractère 45
68 nom Nom d’une galerie Chaine de caractère 200
69 description Description d’une galerie Chaine de caractère 200
46
70 chemin Chemin d’accès d’une galerie Chaine de caractère 200
II.3.3. Diagramme de classe

Le diagramme des classes est une représentation statique des classes d'un système, y
compris les propriétés, les méthodes de chaque classe et les diverses relations. [9]
 Les règles de gestion
o Un adhérent ne peut pas disposer de plus d’un abonnement actif pour la

même activité à un moment donné.
o Un adhérent ne peut pas réserver un terrain (local) pour une seule personne.
47
 Représentation du diagramme de classe
Figure II- 20 : Diagramme de classe
48
II.4. Diagramme de navigation

Nous allons présenter une illustration de navigation pour l’application web et mobile.
II.4.1. L’arborescence de l’application WEB

Le diagramme de navigation ci-dessous présente l’arborescence de l’application web.
Figure II- 21 : Diagramme de navigation « Application web »
49
II.4.2. L’arborescence de l’application mobile

Le diagramme de navigation ci-dessous présente l’arborescence de l’application mobile.
Figure II- 22 : Diagramme de navigation «Application mobile »
50
II.5. Conclusion
Dans cette phase, nous avons pu capturer les besoins des utilisateurs, analysé tous les
cas d’utilisation et conçu la plupart d’entre eux. Dans ce qui suit nous détaillons des aspects
d’implémentation.
51
Chapitre III : MODELE
D’IMPLÉMENTATION
Chapitre. III.
Chapitre III : Modèle d’implémentation
III.1. Introduction
Suite à l’analyse et la conception des fonctionnalités des cas d’utilisation, nous
présentons dans ce qui suit des aspects d’implémentation portant sur l’architecture de
l’application, la mise en œuvre, le test global et le test des services web.
III.2. Architecture physique du système

Dans cette partie, nous allons décrire l’architecture globale de notre système suivie par
la présentation des technologies utilisées pour l’implémentation de l’application web,
l’application mobile et les services web.
Figure III- 1 : Architecture physique du système
o Le client peut être un client Android ou un client web développé avec jQuery
Mobile afin d’être utilisé sur plusieurs dispositifs. Il correspond à la partie de
l'application visible aux utilisateurs.
o Le service web est la logique métier des services web pour la réutilisabilité
entre les différentes interfaces de l’application.
o Le serveur de base de données fournit les données au serveur web.
53
III.3. Justification du choix

Dans cette section, nous détaillons l’architecture de développement adoptée, ainsi que le
protocole du service web et le format d’échange de données retenus.
III.3.1. Architecture de développement MVC

Dans notre projet, nous avons utilisé l’architecture MVC (Modèle-Vue-Contrôleur).
Cette dernière, constitue une architecture de développent qui cherche à séparer nettement les
couches de présentation, métier et d'accès aux données comme l'explique la figureIII-2.
Figure III- 2 : Architecture du modèle MVC
 Modèle
Cette partie gère les données. Son rôle est d'aller récupérer les informations « brutes »
dans la base de données, de les organiser et de les assembler pour qu'elles puissent ensuite
être traitées par le contrôleur. On y trouve donc les requêtes SQL.
 Vue
Cette partie se concentre sur l'affichage. Elle ne fait presque aucun calcul et se contente
de récupérer des variables pour savoir ce qu'elle doit afficher.
 Contrôleur
54
Cette partie gère la logique du code. C'est en quelque sorte l'intermédiaire entre le
modèle et la vue : le contrôleur va demander au modèle les données, les analyser, prendre des
décisions et renvoyer le texte à afficher à la vue. Le contrôleur contient exclusivement du
PHP.
Les avantages apportés par l'architecture MVC sont :
o La séparation des données de la vue et du contrôleur (ce qui permet une

conception claire et efficace de l'application).
o Une indépendance des données, de l'affichage et des actions (ce qui donne
plus de souplesse pour la maintenabilité et l'évolutivité du système).
o Un gain de temps de maintenance et d'évolution de l'application.
III.3.2. Utilisation des web service

Un Service WEB est un ensemble de protocoles permettant à des applications de
communiquer entre elles, indépendamment de la structure et du langage employés.
En d'autres termes, un service Web est tout simplement un programme accessible au

moyen d'Internet, qui utilise un système de messagerie standard XML, et n'est lié à aucun
système d'exploitation ou langage de programmation.
Grâce aux services web, les applications peuvent être vues comme un ensemble de
services métiers structurés et correctement décrits.
Le premier bénéfice des services web est la facilité de maintenance de l'application,

ainsi que l'interopérabilité permettant de modifier facilement un service pour le remplacer par
un autre. De plus, les services web permettent de réduire la complexité d'une application car
on peut se focaliser sur un service, indépendamment du reste de l'application.
III.3.3. Protocole des services web

Les méthodes de communication utilisées pour établir et/ou consommer un Service
WEB, nous noterons :
o RPC (Remote Procedure Call).
o REST (Representational State Transfert).
55
o SOAP (Simple Object Access Protocol).
III.3.3.1. Comparaison
Pour choisir les technologies de développement de cette application, nous avons

précédé le travail par une étude comparative dont on a élaboré deux prototypes.
Parmi les méthodes déjà citées ci-dessus, nous retiendrons uniquement le protocole
SOAP et l’architecture REST.
Notre but dans ces prototypes est d’effectuer des services web qui traitent des sélections
et des insertions dans une base de données afin d'être utilisés par une tierce partie. Cela
signifie que nous devons être capables de recevoir des requêtes et de retourner une réponse
compréhensible, indépendamment de la plate-forme et de l'architecture distante.
 SOAP
SOAP est un protocole de transmission de messages créé dans le but de partager des
données et d'invoquer des méthodes distantes, indépendamment de la plate-forme ou du
serveur sur lequel elles fonctionnent, tant qu'il existe un protocole de communication
permettant d'y accéder, comme par exemple HTTP. [11]
Afin de savoir comment utiliser un service web SOAP, ce dernier est décrit dans un
langage de description de service web basé sur XML : le WSDL (Web Services Description
Language).
o WSDL
WSDL est une grammaire XML utilisée pour donner une définition abstraite des
services, le détail des types de données échangées, les opérations possibles, le protocole
à utiliser ainsi que l'adresse (URL) du service. [12]
Le fichier WSDL de chaque web service peut être publié dans un annuaire. Le fichier
WSDL associé à un web service représente en quelque sorte sa notice d’utilisation.
Nous expliquerons en ce qui suit comment on a utilisé SOAP, WSDL, PHP et Android
en pratique.
56
1. Création du document WSDL à la main.
2. Création du serveur en PHP.
3. Création du client en PHP et en Android.
o Serveur PHP
Tableau III- 1 : Serveur PHP avec SOAP

Instruction Description
Création du serveur. On passe en argument
$s = new SoapServer("http://…/fichier.wsdl");
l'url de WSDL.
$s->addFunction("nomFonction") ; Ajout d'une fonction.
function nomFonction($paramètres) {…}

Traitement à effectuer.
$s->handle() ; Lancer le serveur
o Client PHP
Tableau III- 2 : Client PHP avec SOAP

$c=new SoapClient("http://…/service.php? Création du client. On passe en argument
wsdl"); l’url du descripteur du service.
$res=$c->nomFonction([paramètres]) ; Consommation du service.
o Client Android
Tableau III- 3 : Client Android avec SOAP

Création d’un objet SoapObject. On passe
obj= new SoapObject(); en paramètre le namespace et le nom de la
méthode
obj.addProperty(…) ; Ajouter les paramètres à l’objet SoapObject
Déclaration de la version du SOAP request.

envelope=new SoapSerializationEnvelope();
On passe en argument la version à utiliser
57
envelope.setOutputSoapObject (request); Encapsulation des paramètres
Création de l’objet HttpTransportSE. On

ObjtHttp = new HttpTransportSE();
passe en paramètre l’url du WSDL
Appeler le web service. On passe en
androidHttpTransport.call();
paramètre l’action et l’enveloppe
result = envelope.bodyIn; Récupération de résultat
Parmi les avantages du SOAP :
o Extensible.
o Utilisation du standard XML pour l'échange des messages.
o Un contrat personnalisé entre le client et le serveur.
o L'utilisation du protocole HTTP pour le transport qui permet de s'affranchir

les problématiques de firewalls.
 REST
REST n'est pas un protocole au même titre que SOAP, mais une architecture définie par
des règles « simples » facilitant l'accès à ces services et basé sur HTTP. [13]
REST est un moyen d'accéder aux documents et aux ressources distantes selon une
architecture logicielle simple, représentée par une API.
Les principaux avantages de REST : [14]
o facile à mettre en œuvre que les alternatives classiques ;
o moins de consommation mémoire ;
o mise en cache des ressources, donc accélération des opérations ;
o on peut échanger des requêtes entre diverses applications ou média car elles
sont représentées par des URI.
Nous expliquerons en ce qui suit comment on a utilisé REST, PHP et Android en

pratique.
58
1. Création du serveur en PHP,
2. Création du client en PHP et en Android.
o Serveur PHP
Tableau III- 4 : Serveur PHP avec REST

$json= new Services_JSON(); Instanciation d’un Service_Json
$json->encode (); Encodage du résultat
o Client PHP
Tableau III- 5 : Client PHP avec REST

$json= new Services_JSON(); Instanciation d’un Service_Json
Création du contexte (la méthode utilisée

$context = stream_context_create($opts);
Get ou Post, les paramètres à envoyer)
$res=file_get_contents(url, context) ; Récupération du résultat en format Json
$json->decode (); décodage du résultat
o Client Android
Tableau III- 6 : Client Android avec REST

Création d’un objet RestClient. On passe en
RestClient client = new RestClient(url) ;
paramètre l’url du service web
client.AddParam(name, parm) ; Ajouter les paramètres à l’objet RestClient
Invocation du web service a partir de l’objet

client.Execute(RequestMethod.POST);
RestClient.
repserv = client.getResponse(); Récupération du résultat sous format Json
listres = new Gson().fromJson ; Décodage du résultat
59
 Comparaison entre XML et JSON

Tableau III- 7 : Comparaison entre XML et JSON
Critères XML JSON
Validation Xsd Aucune validation
Espace de nommage Inclue Aucun
Lisibilité du résultat N’est pas lisible simple et lisible
Communication XML http
Transmission Lourd Léger
 Comparaison entre SOAP et REST

Tableau III- 8 : Comparaison entre SOAP et REST
Critère SOAP REST
Nature Protocole Architecture
Type des Projets projet simple Tout type de projet
Format d’échange de données WSDL JSON ou XML
Invocation RPC méthode via l’url
Lisibilité du résultat n’est pas lisible simple et lisible
Utilisation JavaScript Compliqué Simple
Performance Moins performant Performant
60
III.3.3.2. Choix retenu
On compte tenu des critères de performance, de simplicité et de lisibilité déjà cités nous

allons choisir le format d’échange de données JSON avec l'architecture REST puisqu’il est
simple, auto descriptif et plus performant.
III.4. Environnement de réalisation

Dans cette partie nous allons présenter l’environnement matériel et logiciel ainsi que les
technologies utilisées pour la réalisation de ce travail.
III.4.1. Environnement matériel

Pour la réalisation du projet, nous avons utilisé :
o Un ordinateur portable « DELL » utilise Windows 7 comme système

d’exploitation.
o Un ordinateur portable « ACER » utilise Windows 7 comme système

d’exploitation.
o Un appareil téléphonique « Samsung Galaxy Ace» dont le système

d’exploitation est Android 2.3.6.
o Un serveur distant.
III.4.2. Environnement logiciel
o Netbeans 7.2.1 pour le développement de l’application web et le serveur.
o Eclipse JUNO 4.2.1 pour la réalisation de l’application mobile.
o Rational Rose Enterprise Edition 8.2 pour la modélisation des diagrammes

UML.
o Microsoft Office Word 2007 pour la rédaction des rapports.
o MySQL 5.1 utilisé comme un serveur de base de données.
o SOA Client (Extension pour Mozilla Firefox) pour tester les services web
SOAP.
61
o Postman (Extension pour Google Chrome) pour tester les services web
REST.
Ci-dessous un tableau représentant les différentes technologies utilisées dans notre

application :
Tableau III- 9 : Technologies utilisées
Android
Système d’exploitation open source pour Smartphones, PDA et terminaux
mobile.
PHP
Langage de scripts libre principalement utilisé pour produire des pages web
dynamiques.
MySQL
Système de gestion de base des données (SGBD).
JSON
Format de données textuel, générique, dérivé de la notation des objets du
langage ECMAScript.
jQuery Mobile
Framework jQuery Mobile. Un Framework UI optimisé pour les appareils
tactiles et construit avec jQuery et HTML5.
62
III.5. Diagramme de déploiement

Le diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de
l'infrastructure physique par le système et la manière dont les composants du système sont
répartis ainsi que leurs relations entre eux.
Figure III- 3 : Diagramme de déploiement
63
III.6. Mapping vers le modèle logique de données

Pour la gestion de la persistance des données nous avons utilisé une base de données
relationnelle dont la création est issue de l’application des règles de mapping du modèle
objets vers le modèle relationnel.
III.6.1. Les règles de mapping

Dans cette partie, nous présenterons les règles permettant de décrire un schéma logique
dans les modèles relationnels à partir d’un diagramme de classe UML.
Selon [15], il existe cinq règles opérationnelles pour traduire un schéma conceptuel
UML en un schéma relationnel équivalent.
 R1 : Transformation des entités/classes
Chaque classe du diagramme UML devient une relation. Il faut choisir un attribut de la
classe pouvant jouer le rôle d’identifiant.
Si aucun attribut ne convient en tant qu’identifiant, il faut en ajouter un de telle sortie

que la relation dispose d’une clé primaire.
 R2 : Transformation des associations un-à-plusieurs
Il faut ajouter un attribut de type clé étrangère dans la relation fils (0..*) de
l’association. L’attribut porte le nom de la clé primaire de la relation père (1) de l’association.
 R3 : Transformation des associations plusieurs-à-plusieurs et n-aires
L’association (classe-association) devient une relation dont la clé primaire est composée
par la concaténation des identifiants des classes connectées à l’association. Chaque attribut
devient clé étrangère si la classe connectée dont il provient devient une relation en vertu de la
règle 1. Les attributs de l’association (classe-association) doivent être ajoutés à la nouvelle
relation. Ces attributs ne sont ni clé primaire, ni clé étrangère.
64
 R4 : Transformation des associations un-à-un
Il faut ajouter un attribut clé étrangère dans la relation dérivée de l’entité ayant la
multiplicité minimale égale à un. L’attribut porte le nom de la clé primaire de la relation
dérivée de la classe connectée à l’association.
Si les deux cardinalités minimales sont à un, il est sans doute préférable de fusionner les
deux classes en une seule.
 R5 : Transformation de l’héritage
Trois décompositions sont possibles pour traduire une association d’héritage en fonction
des contraintes existantes :
o Décomposition par distinction :
Il faut transformer chaque sous-classe en une relation. La clé primaire de la sur-classe

migre dans les relations issues de la sous-classe et devient à la fois clé primaire et clé
étrangère.
o Décomposition descendante (push-down) :
Il faut migrer tous les attributs de la relation issue de la sur-classe dans les relations
issues des sous-classes.
o Décomposition ascendante (push-up) :
Il faut supprimer les relations issues des sous-classes et faire migrer les attributs dans la
relation issue de la sur-classe.
III.6.2. Modélisation logique/physique des données

L’utilisation d’un SGBDR impose un changement entre la structure des classes et la
structure des tables relationnelles. Les deux structures ont des analogies dont on peut établir
des équivalences (directement ou indirectement) entre elles.
Nous pouvons alors déduire le modèle logique des données optimisées permettant le
passage du diagramme de classes au modèle relationnel.
65
o Salle (id, nom,ville, adresse, numero_tel, logo, delai_annulation)
o Activite (id, nom, description, mode_reseservation, description)
o Jour_semaine (id, nom)
o Planning (id, periode, annee, description, date_debut, date_fin)
o Type_Local (id, nom_type)
o Entraineur (id, nom, prenom, numero_tel, date_naissance, login,

mot_de_passe)
o Local (id, nom, capacite, description, mode_reservation, #id_salle,

#id_type_local)
o Membre (id, nom, prenom, numero_tel, date_naissance)
o Adherent (id, nom, prenom, numero_tel, date_naissance, login,

mot_de_passe, sexe, adresse, code_postal, ville, #id_salle)
o Creneau (id, heure_debut, duree, mode_reservation, #id_planning,

#id_type_local, #id_jour)
o Abonnement_prepaye (id, code_carte, etat, date_debut, duree, #id_adhérent,

#id_modele_abonnement)
o Abonnement_seance (id, code_carte, etat, nombre_de_seance #id_adhérent,

#id_modele_abonnement)
o Modele_abonnement (id, nom, description, multi_salle)
o Reservation (id, date, heure, etat, nombre_personne, #id_adherent,

#id_membre, #id_seance)
o Seance (id, capacite_disponible, description, date, #id_creneau, #id_local,

#id_activite, #id_entraineur)
o Entraineur_Activite (id, #id_entraineur, #id_activite)
o Local_Actvite (id, #id_local, #id_activite)
o Modele_Activite (id, #id_modele_abonnement, # id_activite)
66
o Galerie (id, type, nom, chemin, #id_salle, #id_local, #id_activite)
III.7. Illustration du test des web service

Nous présentons dans cette partie des captures relatives aux tests des services web
effectués.
 SOAP
Pour tester nos services web avec le protocole SOAP, nous avons utilisé l’outil SOA
Client (Extension pour Mozilla Firefox).
Figure III- 4 : Invocation du service web SOAP « GetAll_Reservation»

1 : L’adresse du service web.
2 : Choix de la méthode à invoquer.
3 : Les paramètres du service web.
4 : Envoi des paramètres au service web pour l’exécution.
67
Figure III- 5 : Résultat du service web SOAP « GetAll_Reservation»
 REST
Pour tester nos services web, nous avons utilisé l’outil Postman (Extension pour Google
Chrome).
Figure III- 6 : Test du service web REST « Authentification »
68
1 : L’adresse du service web.
2 : Les paramètres du service web.
3 : Envoi des paramètres au service web pour l’exécution.
4 : Données au format JSON.
Figure III- 7 : Test du service web REST « GetActivites_ByMode »
Figure III- 8 : Test du service web REST « GetAll_Salle»
III.8. Test de l’application

69
Dans cette partie, nous allons présenter le test global.
III.8.1. Test de l’application mobile

Nous allons présenter dans cette section, les captures d’écrans reliées à l’exploitation de
l’application mobile pour un scénario de réservation.
Figure III- 9 : Ecran Figure III- 10 : Ecran de Figure III- 11 : Ecran de
d’authentification menu paramètres
Figure III- 12 : Ecran choix Figure III- 13 : Ecran liste Figure III- 14 : Ecran de
du type d’abonnement d’abonnements prépayé menu
70
Figure III- 15 : Ecran de Figure III- 16 : Ecran de Figure III- 17 : Ecran de la
liste d’abonnement séance choix du type de ressource à liste des leçons
réserver
Figure III- 18 : Ecran de Figure III- 19 : Ecran de la Figure III- 20 : Ecran du
menu liste des terrains choix de la date et le
nombre de personnes
71
Figure III- 21 : Ecran des Figure III- 22 : Ecran des Figure III- 23 : Ecran de
créneaux des terrains da la créneaux des terrains réservation
date choisie
Figure III- 24 : Ecran

d’ajout de réservation
72
III.8.2. Test de l’application web

Nous allons présenter dans cette section, les captures d’écrans reliées à l’exploitation de
l’application web.
Figure III- 25 : Ecran d’accueil
Figure III- 26 : Ecran de menu du responsable
73
Figure III- 27 : Ecran de choix critères de statistique
Figure III- 28 : Ecran de graphe de la statistique
74
Figure III- 29 : Ecran de la liste des terrains
Figure III- 30 : Ecran de description d’un terrain
75
Figure III- 31 : Ecran de choix des informations
III.9. Apports et problèmes rencontrés

Cette étude est une occasion pour développer et exercer nos capacités d'observation,
d'analyse, de conception, d'organisation, de développement et de rédaction. On présente dans
ce qui suit les difficultés rencontrées ainsi que les apports.
III.9.1. Difficultés rencontrées

Tout au long de la réalisation de ce projet, nous avons rencontré des difficultés au
niveau de l’architecture de l’application, vu qu’on a respecté le modèle MVC sans l’utilisation
d’un Framework de mapping, de même au niveau du protocole d’invocation des services web
le choix était délicat comme il existe divers protocoles, ce qui a été résolu par l’élaboration
des prototypes. Au niveau d’encodage des données telles que les caractères spéciaux, on a
résolu cette difficulté à travers l’exploration du codage UTF-8. Pour l’application web, on a
eu des difficultés au niveau d’intégration et de la manipulation du Framework jQuery Mobile.
III.9.2. Apports
Au cours de l’élaboration de notre projet nous avons enrichi nos connaissances
théoriques à travers la conception et le développement d’un cas réel de gestion des activités
sportives pour une salle de sport ; Ce qui nous a permis de découvrir le système
d’information des salles de sport et de nous familiarisée au Framework jQuery Mobile et
Android Suite à la réalisation d’une application web et mobile. Par ailleurs, on a maitrisé les
protocoles d’invocation des services web.
76
III.10. Conclusion
Nous avons présenté dans ce chapitre l’architecture physique de notre système ainsi
que nos choix techniques pour la réalisation de l’application en expliquant leurs atouts et
utilités, par la suite nous avons élaboré le diagramme de déploiement. Dans la deuxième
partie, on a présenté une simulation des interactions entre utilisateurs et l’application à travers
un scénario de réservation.
77
Conclusion générale
CONCLUSION
GENERALE
Dans ce travail nous avons conçu et implémenté un système de gestion des activités
sportives accessible à partir d’un dispositif mobile.
Pour aboutir à l’implémentation de l’application, nous avons appliqué la méthodologie

RUP qui couvre tout le cycle de développement. Nous avons aussi respecté l’architecture
MVC, le protocole REST pour rendre accessible un service WEB à partir de la plateforme
Mobile. Nous avons aussi intégré et exploité le Framework jQuery Mobile pour l’application
web.
Principalement, l’application mobile permet à l’adhérent de se rattacher à la salle de

sport, de faciliter la gestion de son calendrier à travers l’accessibilité des informations des
séances planifiées et de les exploiter au mieux à traves la flexibilité de réservation en mode
mono-site et multi-sites.
Par ailleurs, nous avons étendu l’accès à l’application à travers une interface web avec
l’enrichissement des fonctionnalités puisque le responsable pourra effectuer des planifications
des activités et de les contrôler à travers les statistiques de réservations.
Comme perspectives, nous suggérons d’intégrer tout le système web en mobile et de

développer une version avec Xcode pour les produits Apple.
78
BIBLIOGRAPHIE
BIBLIOGRAPHIE
[3] : [Joseph GABAY, David GABAY, UML 2 Analyse et Conception, Dunod, Paris, 2008].
[4] : [Michel WINTER, cour de Management de projet ,2011-2012].
[5] : [Cours Conception Orientée Objet des Systèmes d’information, Rafik BOUAZIZ, Faiez
GARGOURI, 2009].
[6] : [Céline DECOSSE & Henri TUDOR, Comment Lire Les Diagrammes UML, 2002].
[8] : [Introduction à la programmation orientée objets, Eivd, 2002].
[14] : [Thèse de Roy-FIELDING chapitre 5].
[15] : [Christian SOUTOU, UML2 pour les bases de données, Eyrolles/2007].
79
WEBOGRAPHIE
WEBOGRAPHIE
[1] : [http://tecfa.unige.ch/staf/staf-i/gorga/staf2x/classPHP/introobjet.php].
[2] : [http://fr.wikipedia.org/wiki/Unified_Modeling_Language].
[7] : [http://uml.free.fr/cours/i-p21.html].
[9] : [http://grimaldi.univ-tln.fr/LPAI/UML/Diagrammes%20UML.pdf].
[10] : [http://www.9lessons.info/2012/05/create-restful-services-api-in-php.html].
[11] : [http://fr.wikipedia.org/wiki/SOAP].
[12] : [http://fr.wikipedia.org/wiki/Web_Services_Description_Language].
[13] : [http://www.scriptol.fr/programmation/rest.php].
80
: ‫الخالصة‬
‫يتمثل هذا المشروع في تصميم و انشاء برنامج إلدارة قاعة رياضة من خالل جهاز محمول مجهز‬
‫بالبرمجة أندرويد أو عن طريق المتصفح باسثعمال االطار جكويري• موبايل‬
(REST) ‫والبروتوكول‬ (RUP) ‫هذا و قد تم تنفيذ هذا العمل باالعتماد علي منهجية‬
.‫لتوفير• خدمة ويب‬
RUP‫ و‬REST، ‫المفاتيح‬: ‫ الواب خدمات‬،‫ أندرويد‬، ‫جكويري موبايل‬
Résumé :
Ce projet de fin d’étude consiste à concevoir et à développer un système mobile

pour la gestion des activités dans une salle de sport quelque soit le dispositif de
connexion sous la plateforme Android et le Framework jQuery Mobile.
La réalisation de ce système a été effectuée avec la méthodologie RUP et le

protocole REST pour l’invocation des services WEB.
Mots clés : Service Web, Android, jQuery Mobile, REST et RUP
Abstract:
This project is designed to run on mobile system. It offers the management of

activities at a sport's center. Our system need Android OS device and can be
accessible from a browser.
The development of this system was performed according to RUP methodology

Web services based on REST protocol.
Keywords: Service Web, Android, jQuery Mobile, REST, and RUP
Pôle technologique route tunis Km 10 ; B.P. : 242 SFAX 3021 ‫؛ صفاقس‬242 :.‫ب‬.‫؛ ص‬10 ‫القطب التكنولوجي طريق تونس كلم‬
8122 33 ; Fax : 216 74 86 24 32
Tél. : 216 74 86 86 24 32 :‫؛ فاكس‬33 216 22 86 74 :‫ هاتف‬3021
www.isimsf.rnu.tn 74 216

Rapport Final

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Final

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE TUNISIENNE UNIVERSITE DE SFAX

MEMOIRE DE PROJET DE FIN D’ETUDES

Pour l’obtention du :

DIPLOME D’INGENIEUR EN INFORMATIQUE,

SYSTÈME MOBILE POUR LA GESTION DES

M. Walid MAHDI Président

Année universitaire : 2012-2013

et de ma reconnaissance, je dédie ce travail à:

ET tous ceux qui se reconnaitront.

et de ma reconnaissance, je dédie ce travail :

circonstance m’a maintes fois rappelé

Bonheur de des enfants.

Merci pour tous.

Nous tenons à remercier infiniment Monsieur Bassem BOUAZIZ pour la confiance

Nous tenons à remercier enfin tous nos enseignants du département informatique de

Figure II- 1 : Diagramme d’état transition « Abonnement_Séance ».......................................23

Figure III- 1 : Architecture physique du système.....................................................................53

Tableau II- 1 : Représentation de la classe « Salle »................................................................38

Tableau III- 1 : Serveur PHP avec SOAP.................................................................................57

L’objectif du présent travail est de concevoir et développer un système mobile

Le présent mémoire s’articule autour de trois chapitres. Le premier chapitre,

I.2. Présentation de l’entreprise

o Téléphone : (+216) 74 415 055.

o Fax : (+216) 74 415 044.

I.3. Contexte du projet

I.3.2. Objectifs à atteindre

I.3.3. Public visé

I.4. Besoins fonctionnels et non fonctionnels

I.4.1. Besoins fonctionnels

Cette application doit permettre aux adhérents de :

o Modifier son adresse, code postale, numéro de téléphone, ville et mot de

o Consulter et/ou annuler leurs réservations tout en respectant les délais

o Consulter les informations (description, images et vidéos) de tous les terrains

Cette application permet à l’administrateur de :

o Confirmer les demandes d'inscription des adhérents suite à la génération des

o Ajouter et annuler les réservations des adhérents.

o Ajouter les informations (description, images et vidéos) des terrains et des

I.4.2. Besoins non fonctionnels

o L’adhérent doit être guidé lors de la réservation par la numérotation des

o Les dates doivent être introduites à travers un calendrier.

o les informations numériques comme le numéro de téléphone doit avoir des

o L’application doit être simple à utiliser à traves la mise en place des

o L'application doit optimiser les traitements pour avoir un temps de

o L’application doit garantir la sécurité à travers la gestion des droits d’accès.

o Le code de l'application doit être lisible et compréhensible afin d'assurer son

I.5. Choix de la méthodologie de développement

UML (Uniﬁed Modeling Language) est un langage de modélisation graphique apparu

Figure I- 1 : Les phases du processus RUP

o Inception : Définir la portée du projet.

o Elaboration : Planifier le projet, spécifier les fonctionnalités, construire

o Construction : Construire le produit.

o Transition : Transition du produit vers les utilisateurs.

I.6. Modèle des cas d’utilisation

I.6.1. Identification des acteurs

Les acteurs qui participent à cette application sont:

Il représente un client disposant d’un abonnement dans une salle de sport.

Il représente le superviseur d’une ou de plusieurs leçons.

Il représente un client dans une salle de sport.

I.6.2. Diagrammes des cas d’utilisation

Figure I- 2 : Diagramme des cas d’utilisation « Gestion des inscriptions »

Figure I- 3 : Diagramme des cas d’utilisation « Gestion des abonnements »

Figure I- 4 : Diagramme des cas d’utilisation « Gestion des locaux »

Figure I- 5 : Diagramme des cas d’utilisation « Gestion des activités sportives »