Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université de Sousse

Institut Supérieur de Gestion de Sousse

RAPPORT DE STAGE

POUR L’OBTENTION DE LA

LICENCE EN INFORMATIQUE DE GESTION

PARCOURS : TECHNOLOGIES DES SYSTEMES D’INFORMATION

NOM DU PROJET :

Tunisia Events

LIEU DU STAGE :

G-Dev

ELABORE PAR : ENCADRE PAR :

Encadreur académique : Ahmed Haded

Ghada El May Encadreur professionnel : Rami Ghaouar

Yasser Magouri

Année Universitaire 2017/2018

1
 Remerciements
Au terme de ce travail, nous voudrons remercier tous ceux qui, sans leur aide inestimable,
ce projet n’aurait jamais été mené à son terme.

Nos remercîments s’adressent particulièrement à :

 Il nous est agréable, d’exprimer notre reconnaissance envers notre encadreur

académique M.Ahmed Haded qui nous a bien guidés pédagogiquement et
socialement, pour son encouragement, la gentillesse et la sympathie tout au long de
notre projet.
 Nous tenons à remercier notre encadreur professionnel M.Rami Ghaouar pour son
accueil et sa générosité en termes de partage d’expertise et du temps qu’il nous a
pleinement consacré.
 Tous les enseignants qui ont participé à ce projet de près ou de loin par ces
encouragements et ces idées.
 Notre dernier mot s’adresse à tous les membres du jury pour l’honneur qui nous font
de participer à l’examen de notre travail.

2
Liste des figures :

3
Figure 1:logo de la société G-Dev .......................................................................................................... 10
Figure 2:Organigramme de G-Dev......................................................................................................... 12
Figure 3:Logo de l’application Teskerti ................................................................................................. 15
Figure 4:Logo de l’apllication AlloCiné .................................................................................................. 15
Figure 5:Page d’accueil de l’application Teskerti .................................................................................. 17
Figure 6:Page d’acceuil de l’application Teskerti .................................................................................. 18
Figure 7:Présentation de l’application Teskerti .................................................................................... 18
Figure 8:Architecture matériel du modèle MVC ................................................................................... 21
Figure 9:Diagramme de Gantt ............................................................................................................... 22
Figure 10:Phase du Processus Unifié..................................................................................................... 25
Figure 11:Logo d’UML ........................................................................................................................... 28
Figure 12:Les diagrammes de UML ....................................................................................................... 30
Figure 13:Logo de Rationnal Rose ......................................................................................................... 30
Figure 14: Présentation générale d’un diagramme de cas d’utilisation ............................................... 33
Figure 15:Diagramme de cas d’utilisation Global ................................................................................. 35
Figure 16:Raffinement de cas d’utilisation : «S’authentifier»............................................................... 37
Figure 17:Raffinement de cas d’utilisation : Gérer évènement ............................................................ 38
Figure 18:Diagramme modèle de domaine de CU «Gestion événements» .......................................... 43
Figure 19:Raffinement de cas d’utilisation : Gérer réservation. ........................................................... 44
Figure 20:Diagramme se séquence système Gérer réservation : Réserver un événement .................. 47
Figure 21:Diagramme se séquence système Gérer réservation : Consulter réservation ..................... 48
Figure 22:Diagramme d’activité : Réserver un événement................................................................... 50
Figure 23:Diagramme de domaine de cas d’utilisation : Gestion réservation ...................................... 51
Figure 24:Traçabilité Diagramme de cas d’utilisation : Gérer événement. .......................................... 54
Figure 25:Diagramme de classe d’analyse de cas d’utilisation Gérer événement :Organisateur. ........ 55
Figure 26:Diagramme de classe d’analyse de cas d’utilisation Gérer événement :Organisateur......... 56
Figure 27:Diagramme de classe d’analyse Gérer événement : Administrateur. .................................. 57
Figure 28:1.1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation : Gérer réservation. ........................................................................................................... 57
Figure 29:Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Client. .................. 58
Figure 30:Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Client. .................. 58
Figure 31:Diagramme de séquences de cas d’utilisation : Consulter liste événement......................... 60
Figure 32:Diagramme de séquence afficher un événement ................................................................. 61
Figure 33:Diagramme de séquences de cas d’utilisation : Ajouter événement.................................... 62
Figure 34:Diagramme de séquences de cas d’utilisation : Modifier événement. ................................. 64
Figure 35:Diagramme de séquences de cas d’utilisation : Supprimer événement. .............................. 65
Figure 36:Diagramme de séquences de cas d’utilisation : Envoyer messages. .................................... 66
Figure 37:Diagramme de séquences de cas d’utilisation : Réserver événement ................................. 68
Figure 38: Diagramme de déploiement système .................................................................................. 69
Figure 39:Logo Microsoft word ............................................................................................................. 72
Figure 40:Logo Rationnal Rose .............................................................................................................. 72
Figure 41:Logo Notepad++: ................................................................................................................... 73
Figure 42:Logo Wamp Server ................................................................................................................ 73
Figure 43:Logo Paint .............................................................................................................................. 74
Figure 44:Logo de J2EE .......................................................................................................................... 74

4
Figure 45:Logo de Android Studio ......................................................................................................... 75
Figure 46:Implémentation de cas d’utilisation : Gérer réservation ...................................................... 76
Figure 47:Diagramme de composant de cas d’utilisation : Gérer événement ..................................... 76
Figure 48:Implémentation de cas d’utilisation : Gérer événement ...................................................... 77
Figure 49:Implémentation de cas d’utilisation : Gérer événement ...................................................... 78
Figure 50:Structure de l’application....................................................... 78
Figure 51:Interface d’accueil ................................................................................................................. 79
Figure 52:Interface comptes organisateur. ........................................................................................... 80
Figure 53:Interface validation événement ............................................................................................ 80
Figure 54:Interface ajouter événement ................................................................................................ 81
Figure 55:Interface de gestion des messages ....................................................................................... 81
Figure 56:Interface liste des réservations ............................................................................................. 82
Figure 57:Interface d’accueil ................................................................................................................. 82
Figure 58:Interface Se connecter : ........................................................................................................ 83
Figure 59:Interface Menu ...................................................................................................................... 83
Figure 60:Interface Liste événement .................................................................................................... 84
Figure 61:Interface rechercher événement .......................................................................................... 84
Figure 62:Interface liste réservations .................................................................................................... 85
Liste des tableaux :
Tableau 2:Tableaux des acteurs ............................................................................................................ 36
Tableau 3:Specification de cu : S’inscrire .............................................................................................. 36
Tableau 4:Scénario de cas «S’authentifier» .......................................................................................... 38
Tableau 5:Scénario de cas «Afficher liste événement» ........................................................................ 39
Tableau 6:Scénario de cas «Rechercher événement» .......................................................................... 39
Tableau 7:Scénario de cas «Ajouter aux favoris».................................................................................. 40
Tableau 8:Scénario de cas «Envoyer messages» .................................................................................. 40
Tableau 9:Scénario de cas « Ajouter événement» ................................................................................ 40
Tableau 10:Scénario de cas «Modifier événement.» ............................................................................ 41
Tableau 11:Scénario de cas «Supprimer événement» .......................................................................... 42
Tableau 12:Scénario de cas «Réserver événement»............................................................................. 44
Tableau 13:Scénario de cas «Consulter liste réservation».................................................................... 45
Tableau 14:Scénario de cas «Payer événement».................................................................................. 46
Tableau 15: Scénario de cas «Annuler réservation» ............................................................................. 46
Tableau 16:Description de diagramme de séquences de cas d’utilisation : Consulter liste événement.
............................................................................................................................................................... 60
Tableau 17:Description diagramme de séquences de cas d’utilisation : Ajouter événement ............. 63
Tableau 18:Description diagramme de séquences de cas d’utilisation : Modifier événement ........... 65
Tableau 19:Description diagramme de séquences de cas d’utilisation : Supprimer événement ........ 66
Tableau 20:Description diagramme de séquences de cas d’utilisation : Envoyer messages ............... 67
Tableau 21:Description diagramme de séquences de cas d’utilisation : Réserver événement ........... 69
Tableau 22:Tableau des caractéristiques matériel ............................................................................... 72

5
6
Chapitre 1 :
Cadre
générale du
projet

7
8
 Introduction générale
De nos jours, on ne peut pas nier ue les systèmes d’information se trouve
comme une nécessité fondamentale et cruciale qui facilitent la
communication entre différent domaines, surtout le domaine commercial .

En effet, les moyens de divertissement se voient très variés et dans

plusieurs domaines (Soirées musicale Spectacles, concerts, projection film,
Marathon, événement etc...) Où la concurrence devient de plus en plus
accrue et les organisateurs d’événement se précipitent à présenter leur
meilleur et attirer le plus maximum de clients. Du coup ils reviennent à
plusieurs méthodes pour faire la publicité , tout en consacrant un budget
très important (Affiches, Spot publicitaires, flyers) , des stratégies ui
malgré l’effort y consacré ,demeurent obsolètes et primitives.

C’est dans ce contexte alors, que s’inscrit notre projet, réalisé dans le cadre
d’un stage de fin d’étude, effectué au sein de la société « G- Dev » dont la
mission consiste à développer une application de gestion d’événement web
et mobile intitulé « Tunisia Events»

Afin de répondre aux exigences posées par notre sujet nous articulons
notre rapport en quatre chapitres.

D’abord, le premier chapitre décrit le contexte général du projet, la

présentation de l’organisme d’accueil et la définition des grandes lignes du
travail demandé.

Ensuite le deuxième chapitre « la phase de création » illustre le lancement

du projet dans lequel nous citons les besoins fonctionnels et non
fonctionnels puis l’identification des acteurs et aussi les cas d’utilisation.

Le troisième chapitre « Phase d’élaboration » contient une conception

détaillé des cas d’utilisation de priorité 2 , les diagrammes de séquences,
les diagrammes de déploiement ainsi que le diagramme de classe .

9
Le quatrième chapitre « la phase de construction » porte sur la conception
des cas d’utilisation de priorité 3 tout en récupérant le résultat des deux
chapitres précédents pour compléter le diagramme de classe général.

Enfin la dernière partie ou « la phase de transition » comprend le dernier

cycle du processus unifié dédié à la confirmation et la mise en œuvre de
l’application réalisée.
Contexte général du projet

I. Introduction :
Au cours de ce premier chapitre, nous nous intéressons à décrire
l’organisme d’accueil,

Dans lequel s’est déroulé notre projet de fin d’études, Ensuite nous
décrivons le contexte général du projet qui comprend la problématique et
la solution envisagée ainsi la méthodologie de travail adoptée.

II. Présentation de l’organisme d’acceuil

Figure 1:logo de la société G-Dev

1. Historique :
GDev : est une société à responsabilité limitée (SARL) d’origine tunisienne
fondée en janvier 2015 spécialisée dans la conception et le développement
des applications spécifiques, sites WEB et d'applications mobiles
Androïde, multimédia. Elle met à la disposition des clients une équipe
d’experts pour désigner, réaliser, développer, héberger, maintenir et
promouvoir les sites web...

Nos collaborateurs sont pour la plupart des jeunes informaticiens

disciplinés en terme de relation client-service en éprouvant une énergie et

10
 ambition illimité, dotés d’une large expérience dans le domaine de
développement en Dot-Net, J2EE & ANDROID, d’une solide compétence,
que la société n’a pas manqué d’en certifier.

-Services offerts par GDev :

 Création des sites web.

 Développement des applications mobiles.
 Développements des applications spécifiques.
 Création graphique.
 Conseil & Accompagnement.
 Sous-traitance.
 Hébergement

2. Fiche technique :
Dénomination : GDev.

Nationalité : Tunisienne.

Premier responsable : Mr. Mongi Hammadi

Siège social : Rue Docteur Moreau, Immeuble Averroès, 4éme étage, B21 –
4000 Sousse

Téléphone : 73 228 626

Email : contact@gdev.tn

11
 3. Oraganigramme :

Figure 2:Organigramme de G-Dev

III. Etude préalable :

Dans ce cadre s’inscrit notre projet de fin d’études en informatique

appliqué à la gestion, qui consiste à proposer une solution dans le but de
mieux favoriser la publicité d’événement.

Notre choix a été fixé sur l’utilisation de nouvelles technologies de

l’information et de communication. D’où on a pensé à une application (Web
et Mobile) qui assure la publicité des événements et garantie que le client
soit à la page des actualités avec une la localisation facile des événements.

Pour mieux assimiler notre sujet, il faut passer d’abord par les explications
suivantes :

1. Présentation de Tunisia Events :

Les publicités des événements n’est pas une première, mais les méthodes
se diffères, d’où on a pensé dans notre application d’informatiser les
anciennes taches et les regrouper dans des interfaces simples et

12
ergonomiques, pour mieux faciliter la communication entre le client et
l’organisateur d’événement.

2. Les principaux éléments de Tunisia Events

-Le client :

Il s’agit de l’élément fondamental du (nom app) ,Il représente pour

l’entreprise, la seule source de son profit .En effet (Nom app) l’opportunité
d’attirer le plus maximum de clients.

-L’événement : Est l’élément intermédiaire qui met une relation entre le

client et l’organisateur de l’événement.

-L’organisateur : Est celui qui va lancer l’événement.

-Le management : la gestion d’événement permet l’organisation des

événements et donne une image claire au client et ça facilite pour lui le
choix .En effet, Tunisia Events permet d’attirer plus de clients en leur
donnant la possibilité de choisir le type, et la catégorie d’événement.

-La relation entre ces différents éléments : Assurer une bonne

communication et l’interaction entre le client et l’organisateur pour que
chacun atteigne son but.

Le client choisit son événement préféré, l’organisateur attire le public cible

et augmente enfin son profit.

IV. Cahier de charge :

13
 1. Etude de l’existant
Cette section a pour objectif d’étudier et faire le tour sur la solution
existante ce qui va nous permettre de dégager les points forts et faibles de
cette dernière. Dans ce qui suit, nous présentons une analyse de l’existant,
puis nous détaillons la critique de l’existant.

En Effet, la Publicité des événements se fait à travers plusieurs méthodes :

- Méthodes traditionnel : Affiches et panneaux publicitaires, Flyers,

Contacter client par téléphones etc…)

-Méthodes numérique : Annonces sur site web (réseaux sociaux).

On va faire une comparaison entre le traditionnel et le numérique

La Publicité traditionnel permet de rejoindre les clients mais ça reste

insuffisant .en revanche, la publicité numérique atteint de plus un public
spécifique et donne la possibilité de construire une relation plus étroite
avec les consommateurs.

La publicité numérique peut s’exercer à travers les médias sociaux et Les

listes courriels .Ces moyens sont moins couteuses avec un résultat plus
facilement mesurable.

En effet (les resto-lounge, les foires ,les maisons de théâtre etc…) utilisent
les réseaux sociaux pour publier leur événement comme : facebook,
Instagram ,

il existe une application web intitulé ‘Teskerti’ .

Teskerti est une application web qui permet la réservation et la vente des
tickets d’évènements.

14
 Figure 3:Logo de l’application Teskerti

Il existe encore des applications à l’étranger on cite :

AlloCiné :

Figure 4:Logo de l’apllication AlloCiné

Allociné est une société d'origine française fournissant des informations

cinématographiques en ligne.

Initialement, Allociné est un service d'informations téléphoniques sur les

programmes de cinéma, qui s'est imposé grâce à un numéro
mnémotechnique (40 30 20 10 puis 01 40 30 20 10) et l'absence de surtaxe
à l'appel, contrairement à ses concurrents. L'entreprise se diversifie ensuite
pour s'imposer comme le portail web de référence en France dans ce
domaine.

15
-Fonctionnalité d’application :

L'’application promet une expérience servicielle optimisée pour la

recherche d’un film ou série, et ce de trois façons : PROPOSER, EXPLORER,
PERSONNALISER.

Ainsi, de chez vous, confortablement installé dans votre canapé, choisissez,

en moins de trois minutes, le film ou la série qui fera votre soirée.

2. Critique de l’existant :
Dans cette partie, nous essayons de déceler les insuffisances de la situation
existante, nous présentons ses défaillances pour arriver enfin à proposer
une solution.

En effet, la stratégie existante dans le système d’organisation pose

beaucoup de problèmes, parmi lesquels nous pouvons citer :

a. Les méthodes traditionnel : sont très couteuses et demandent un

effort physique et technique, tout en prenant du temps pour les
réaliser.

 Risque que le spectateur ne soit pas informé de l’événement.

 Conflit de réservation (réservation par téléphone n’est pas très

pratique) :

Exemple : l’administration de théâtre municipale trouve des

problèmes lors de réservation des événements : les spectateurs
peuvent réserver leur tickets mais c’est pas garantie à cent pour cent

16
 car il y a une possibilité d’annulation d’où les responsables ne
peuvent pas fixer le nombre des ventes des tickets.

b. Les méthodes numériques :

- Les événements publiés dans les pages ‘facebook’ ne sont pas garantie
à cent pour cent.

-Risque de piratage des pages officielles des événements (sur les

réseaux sociaux) d’où perte de confiance entre le client et l’organisateur.

-Difficultés de choisir la destination et le type d’événement.

L’application Teskerti :

La publication des événements se fait aléatoirement (pas d’organisation

selon les catégories, type , ville)

Figure 5:Page d’accueil de l’application Teskerti

L’inexistence d’une application mobile qui réalise ces taches car l’utilisation
des applications mobile est plus rapide et aussi très pratique, le client sera
notifié de toutes mise à jours ou nouveauté sur son téléphone.

17
‘Teskerti’ a lancé seulement une application mobile IOS pour les
organisateurs et non pas pour les clients.

Figure 6:Page d’acceuil de l’application Teskerti

L’application ne favorise pas aux client de faire le bon choix selon ses
intérêts, gouts, type, catégorie.

Figure 7:Présentation de l’application Teskerti

18
-L’application AlloCiné est dédié seulement pour le cinéma aussi elle est utilisé seulement en France.

3. Spécification des besoins

L’analyse fonctionnelle est un élément indispensable à la bonne réalisation
d’un projet. Elle vise donc à améliorer la qualité du produit en s’intéressant
d’abord à ses fonctions, c’est-à-dire sur quoi le produit est conçu. Les
besoins fonctionnels expriment une action que doit effectuer le système en
réponse à une demande : sorties qui sont produites pour un ensemble
donné d’entrées.

a. Identification des besoins fonctionnels :

-Avoir accès à une plateforme des événements : Le client aura sous les
mains une interface dans lequel il trouve une variété d’événements selon
ses intérêts, gout et domaine.

-Avoir la possibilité de réserver l’événement : Le client peut choisir son

événement et le réserver en une simple clique ainsi il peut l’ajouter aux
favoris et le retourner une autre fois.

-Avoir la possibilité de communiquer avec l’équipe d’organisation : Le

client peut envoyer des messages à l’organisateur d’événement, exprimer
son avis, donner des réclamations et des recommandations et aussi se
renseigner à-propos l’événement.

-Avoir l’accès à une plateforme pour publier les événements :

l’organisateur d’événement a sous les mains une interfaces pour publier son
événement, faire une description, mentionner la date et l’emplacement
aussi publier une photo.

-Avoir les possibilités de consulter les messages : L’organisateur peut

consulter les messages de clients et répondre à toutes questions.

19
-Avoir la possibilité de connaitre l’emplacement exacte de
l’événement : le client peut savoir la localisation de l’évènement.

-Avoir la possibilité de réserver un évènement : le client après la

consultation de l’événement, il peut le réserver et effectuer le payement.

-Avoir la possibilité de payer un événement :le client peut payer en ligne

à travers le Paypal.

a. Identification des besoins non fonctionnels :

— Interface graphique et ergonomie : Interface simple, moderne, bien

structurée et Conviviale pour favoriser une prise en main rapide des
fonctionnalités de l’application.
— Responsive : Une application responsive est devenue une approche de
conception Web incontournable dans tous les projets de développement,
qui vise l’élaboration de sites orant une expérience de lecture et de
navigation optimales pour l’utilisateur quelle que soit sa gamme d’appareil
(téléphones mobiles, tablettes, liseuses, moniteurs d’ordinateur de bureau,
etc.).
— Sécurité : Les utilisateurs inscrits ont tous un identifiant unique qui
permet de les identifier dans le middle office et le back office. Les données
d’authentification doivent être cryptées dans la base de données.
— Performance et disponibilité : L’application doit être hautement
disponible et fluide afin de garantir une meilleure qualité de service. Le
code de l’application doit être bien lisible, compréhensible et bien
documenté pour pouvoir la maintenir rapidement.
L’application doit être évolutive pour répondre aux changements des
besoins.
— Compatibilité : Certaines fonctionnalités dans les pages de l’application
middle office ne sont pas compatibles avec certaines versions de
navigateurs antérieurs.
Utiliser une version récente de navigateur et mettre à jour la version de
votre navigateur pour assurer la compatibilité.
— Maintenabilité et Extensibilité : afin d’encourager la réutilisabilité du
code en tout ou parties dans d’autres applications, et la facilité de sa
maintenance, il est requis que le code source soit lisible et compréhensible ;
pour ceci il faut tenir compte de sa documentation détaillée.
— Portabilité : L’application doit pouvoir s’exécuter sous différents
environnements.
20
 4. Architecture envisagée :

La figure ci-dessus représente l’architecture générale des composants

matériels de notre projet inclus les solutions déjà présentées :

Figure 8:Architecture matériel du modèle MVC

V. Planning des tâches :

21
 1. Diagramme de Gantt :

Figure 9:Diagramme de Gantt

-Définitions :
Le diagramme de Gantt, couramment utilisé en gestion de projet, est l'un
des outils les plus efficaces pour représenter visuellement l'état
d'avancement des différentes activités (tâches) qui constituent un projet. La
colonne de gauche du diagramme énumère toutes les tâches à effectuer,
tandis que la ligne d'en-tête représente les unités de temps les plus
adaptées au projet (jours, semaines, mois etc.). Chaque tâche est
matérialisée par une barre horizontale, dont la position et la longueur
représentent la date de début, la durée et la date de fin. Ce diagramme
permet donc de visualiser d'un seul coup d'oeil :
 Les différentes tâches à envisager
 La date de début et la date de fin de chaque tâche
 La durée escomptée de chaque tâche
 Le chevauchement éventuel des tâches, et la durée de ce
chevauchement
 La date de début et la date de fin du projet dans son ensemble

En résumé, un diagramme de Gantt répertorie toutes les tâches à accomplir

pour mener le projet à bien, et indique la date à laquelle ces tâches doivent
être effectuées.

VI. Conclusion :

Ce premier chapitre a été consacré en premier lieu, à la présentation

générale du cadre de notre travail, En deuxième lieu, nous avons procédé à
l’étude préalable qui nous a permis de comprendre les principes de base
d’un système de gestion de la relation client en général, de présenter une
vue global sur notre sujet « Tunisia Events » où nous avons détaillé notre
cahier de charge ainsi que les principaux besoins fonctionnels et non
fonctionnels des utilisateurs et de tracer les grandes lignes de notre
système en définissant ses fonctionnalités et le matériel nécessaire.

22
L’analyse et la conception des cas d’utilisation seront détaillées dans le
chapitre suivant.

23
Chapitre 2 :
Elaboration

24
Chapitre2 :Elaboration
Introduction :
Dans ce chapitre nous commençons par une présentation concernant les
différents outils logiciels et les langages de modélisations utilisés. Puis nous
allons détailler le diagramme des processus métier avec une traçabilité
entre le diagramme de processus métier et de cas d’utilisation ainsi nous
allons raffiner les cas d’utilisations de deux processus. Notre but est de
permettre à l’utilisateur de l’application de comprendre notre projet et la
manière de son utilisation.

Le Processus Unifié répète un certain nombre de fois une série de cycles de

développement. Chaque cycle est géré comme un projet, se conclu par la
livraison d’une version du produit au client et s’articule autour 4 phases à
savoir :

Figure 10:Phase du Processus Unifié

25
 o Création (Lancement, Incubation, Initialisation) :

- L’objectif de cette phase étant de décider de continuer ou non le

projet.

- Il s’agit d’identifier les principaux besoins fonctionnels et non

fonctionnels. On fait apparaître et on étudie les principaux cas
d’utilisation.

- Il s’agit aussi de déterminer au moins une architecture candidate.

- Il s’agit encore d’identifier et d’évaluer les risques les plus critiques

susceptibles de faire obstacles matériels.

o Elaboration :

- L’objectif de cette phase est de stabiliser l’architecture du système et

d’aboutis ainsi à une architecture de référence, celle qui prend en
compte les cas utilisation les plus significatifs.

- Il s’agit de raffiner le modèle de cas d’utilisation, voire capturer de

nouveaux besoins fonctionnels et compléter la liste des besoins non
fonctionnels.

- Il s’agit aussi de raffiner le modèle d’analyse, de conception et de

dépoilement de sorte à aboutir à une architecture de base robuste et
stable.

o Construction :

- À l’issue de cette phase, l’architecture de référence se métamorphose

en produit exécutable complet prêt à être livré à ses futurs
utilisateurs lors de la prochaine phase (Transition).

26
 - Dans cette phase, il faut essayer de capturer tous les besoins restants,
car il n’est pratiquement plus possible de la faire dans la prochaine
phase.

- Finaliser l’analyse et la conception.

Chaque phase se termine par un jalon (point de contrôle) permettant de

prendre des décisions cruciales avant de passer à la suivante et permettant
de surveiller la progression du travail. Chaque phase se subdivise en une ou
plusieurs itérations. Chaque itération couvre généralement 5 activités et
constitue un mini projet.

Les 5 activités du Processus Unifié sont :

o Expression des Besoins (Capture des Besoins) :

- Identifier et décrire les besoins fonctionnels qui conduisent à

l’élaboration du modèle de cas d’utilisation.

- Définir les besoins non fonctionnels.

o Analyse :

- Définir les réalisations des CU et les structurer en termes de

paquetages et de classes d’analyse.

- Le modèle d’analyse est la première vue interne du système et peut-

être considéré comme une première ébauche du modèle de
conception.

o Conception :

- Détailler et approfondir le modèle d’analyse afin d’aboutir à un

modèle de conception décrivant l’architecture du système en termes

27
 de paquetages, classes de conceptions, objets de conception
interagissant entre eux pour réaliser les CU.

- Aboutis aussi à un modèle de déploiement décrivant l’architecture du

système en termes de nœuds matériels et leurs connexions.

- Tenir compte des choix technologiques.

- Constitue un point de départ à l’implémentation.

o Implémentation :

- Implémenter sous forme de composants les sous-systèmes et les

classes conçus.

- Les composants peuvent être de différents types exemples : code

source, code exécutable, bibliothèque, table de BD. Les composants
sont liés entre eux par des liens de dépendances.

Langage de modélisation choisi

Nous avons besoins, d’un langage de modélisation unifiée pour la
modélisation et la conception de notre système.

Figure 11:Logo d’UML

28
Nous avons adopté une approche orientée objet pour la conception de notre
application qui représente un standard incontestable dans le cadre du
développement logiciel.
Pour modéliser notre système, nous allons utiliser le langage de
modélisation UML (de l’anglais Unified Modeling Language) que l’on peut
traduire par "langage de modélisation unifié" qui est un langage de
modélisation graphique conçu pour fournir une méthode normalisée pour
la conception d’un système. le langage UML se repose sur l’approche objet
et définit un ensemble de notations graphiques des représentations
conceptuelles d’un système.
Brièvement, ce langage est né de la fusion des méthodes OOSE d’Ivar
Jacobson,
BOOCH de Grady Booch et OMT de James Rambaugh, et est à présent un
standard
défini par l’OMG(Objet Management Group) : il est utilisé surtout pour
spécifier, visualiser, modifier et construire les documents nécessaires au
bon développement d’un logiciel orienté objet, ce qui offre un standard de
modélisation pour représenter son architecture logicielle.
UML est un langage visuel qui fournit une multitude de représentations
graphiques appelés diagrammes qui sont des représentations graphiques
d’un ou plusieurs éléments du système et ce selon un aspect particulier du
système ; il s’agit de vue. En effet, une vue est une collection de diagrammes
décrivant les aspects similaires d’un projet.
UML aperçoit un système logiciel à développer selon trois vues à savoir : la
vue fonctionnelle, la vue statique et la vue dynamique.
En utilisant UML, nous nous servons donc d’une modélisation de très haut
niveau indépendamment des langages et des environnements, et
garantirons la réalisation d’objectifs réputés que visent assurée l’approche
objet, à savoir :
— La décomposition du processus de développement.
— La prise en compte de l’évolution de l’analyse et du développement.
— La compréhension de représentations abstraites complexes.
— La factorisation du code, son organisation et sa réutilisabilité dans
d’autres applications.
— La création d’un formalisme pour la conception d’un système logiciel.
— L’expression visuelle de solutions proposées.
— Limiter les ambiguïtés et les incompréhensions.
— Un gain de précision et de stabilité.
Dans sa version 2.3, UML s’appuie sur 14 diagrammes, chacun modélisant
sous un aspect particulier le système désiré.

29
 Figure 12:Les diagrammes de UML

1. Outil de modélisation
Définitions :

Figure 13:Logo de Rationnal Rose

Rational Rose est un outil de conception de logiciels commerciaux de cas-

outil. Il comporte deux éléments principaux de l'ingénierie de logiciels
moderne : développement par composant et contrôlé de développement
itératif. Il facilite l'analyse orientée objet et la conception en permettant aux
utilisateurs (analystes, ingénieurs, écrivains et chefs de projet) de créer,
d'afficher, de manipuler et de modifier des éléments dans un langage UML
(Unified Modeling) tout au long de l'ensemble des activités, à l'aide d'un
outil et la langue. Avec ses nombreux avantages, il est rapidement devenu
un des meilleurs outils dans l'industrie.

L'équipe de développement

30
L'un des principaux avantages de Rational Rose est qu'il facilite le
développement de l'équipe en apportant un soutien de l'équipe complète. Il
permet facilement aux utilisateurs de travailler avec leur propre version
unique du modèle dans leur propre milieu de travail, sans se déplacer d'un
endroit à l'autre.

Processus de développement

Le logiciel peut facilement servir pendant tout le processus de

développement logiciel entier, contrairement à d'autres logiciels. Rose peut
être utilisée à tout moment pendant le processus de développement, mais
aussi l'utiliser pour aider à découvrir et à prévenir de potentiels graves
erreurs à l'avenir.

Modèle de gestion

Modifications apportées au modèle de gestion est également faite simple

par Rational Rose. Les modifications apportées à un modèle peuvent être
mises à la disposition aux autres en utilisant une gestion de la configuration
et le système de contrôle (CMVC) version. Cela permet d'intégrer facilement
des modifications dans le modèle sans interférer avec n'importe quel stade
de développement.

Problèmes hérités

Rational Rose aborde des problèmes hérités mauvais ; il vous permet de

revenir en arrière et corriger les erreurs et les lacunes dans l'application
héritée. Ceci est utile face à un logiciel qui ne rentre pas les besoins des
utilisateurs.

II. Modèle métier (Diagramme de Cas d’utilisation) :

Les diagrammes de cas d'utilisation :
Définitions :

Sont des diagrammes UML utilisés pour donner une vision globale du
comportement fonctionnel d'un système logiciel. Ils sont utiles pour des
présentations auprès de la direction ou des acteurs d'un projet, mais pour le
développement, les cas d'utilisation sont plus appropriés.
Un cas d'utilisation représente une unité discrète d'interaction entre un
utilisateur (humain ou machine) et un système. Il est une unité significative
de travail.

31
Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs
ils interagissent avec les cas d’utilisation.
UML définit une notation graphique pour représenter les cas d'utilisation,
cette notation est appelée diagramme de cas d'utilisation. UML ne définit
pas de standard pour la forme écrite de ces cas d'utilisation, et en
conséquence il est aisé de croire que cette notation graphique suffit à elle
seule pour décrire la nature d'un cas d'utilisation. Dans les faits, une
notation graphique peut seulement donner une vue générale simplifiée d'un
cas ou d'un ensemble de cas d'utilisation.
Les diagrammes de cas d'utilisation sont souvent confondus avec les cas
d'utilisation. Bien que ces deux concepts soient reliés, les cas d'utilisation
sont bien plus détaillés que les diagrammes de cas d'utilisation.
Un cas d’utilisation :
Définitions :
Un cas d’utilisation met en évidence une fonctionnalité, c’est à dire une
interaction entre acteur et système. Les cas d’utilisation délimitent le
système, ses fonctions et ses relations avec son environnement. Ils
représentent donc un moyen pour déterminer les besoins fonctionnels et
servent de guide tout au long du processus du développement.
Le diagramme de cas d’utilisation représente le point de vue fonctionnel du
système

Logiciel à développer, c’est-à-dire l’ensemble des fonctionnalités à satisfaire

pour les utilisateurs du système à travers des concepts de cas d’utilisation,
d’acteurs et leurs relations (association, dépendance et généralisation)
Les éléments de bases d’un diagramme de cas d’utilisations :

32
 Figure 14: Présentation générale d’un diagramme de cas d’utilisation

La figure ci-dessus représente les éléments que nous pouvons avoir dans un
diagramme de cas d’utilisation, à savoir :
— Acteur : Un acteur est un rôle joué par une personne externe, un
processus ou une chose qui interagit avec un système.
— Cas d’utilisation : un cas d’utilisation représente une fonctionnalité
offerte par le
Système, sans imposer son mode de réalisation.
— Relation : une relation d’association représente un canal de
communication reliant un acteur à un cas d’utilisation.
— Inclusion : La relation d’inclusion entre un cas d’utilisation A et un autre
B, signifie que le cas A ne peut avoir lieu qu’après exécution de B.
la réalisation de A exigé la réalisation B.
— Extension : La relation d’extension entre deux cas d’utilisation indique
que le cas étendue peut faire appel à l’autre. Supposons qu’un cas
d’utilisation A étend B, ceci signifie que l’exécution de B peut entrainer
l’exécution de A; on parle alors d’une dépendance facultative.
— Généralisation : La généralisation est un type de relation entre acteurs et
même des cas d’utilisation. Il s’agit d’une migration de comportements
entre acteurs(ou cas d’utilisation).
Par exemple, un acteur A est une généralisation d’un autre B, désigne que B
est un aspect particulier ; qu’en plus des comportements de A, l’acteur
B possède d’autres qui s’y ajoutent.
2. Identification des acteurs du système :
Les types d’acteurs qui participent à notre système sont les suivants :
33
Un acteur est l’idéalisation d’un rôle joué par une personne externe, un
processus ou une chose qui interagit avec un système. Dans le cas de notre
projet nous présentons les acteurs suivants :
L’administrateur : l’administrateur contrôle directement l’application. Il est
le responsable de la gestion des organisateurs, aussi celui qui donne
l’autorisation à un organisateur pour publier un événement
Le Client(le Spectateur) :

Est celui qui va consulter, réserver l’événement.

L’organisateur d’événement :

Est le responsable de la publication des événements, gérer les réservations et gérer les
messages du client.

Diagramme processus métier :

Dans cette section, nous structurons les processus métier du système,
permettant de donner une vision globale du comportement fonctionnel du
système.

34
Figure 15:Diagramme de cas d’utilisation Global

35
Dans cette section, nous structurons les processus métier du système, permettant de donner
une vision globale du comportement fonctionnel du système.

Les acteurs Administrateur Organisateur Client : participant

Les Cas d’utilisations

Gérer back office × ×

Gérer événement × × ×
Gérer réservations × ×
Tableau 1:Tableaux des acteurs

CU : S’inscrire

Nom de cas d’utilisation Remplir formulaire.

Description brèves L’organisateur a la possibilité d’envoyer une réponse

aux clients.
Pré-Condition - L’organisateur s’est authentifié.
- Opération Afficher liste messages choisie.
-Opération répondre aux messages choisie.
Scénario de bases 1-L’organisateur s’authentifie
2-il Choisit Afficher liste organisateurs.
3-il choisit l’option répondre

Post-Condition Envoyer messages aux clients

Tableau 2:Specification de cu : S’inscrire

CU : S’authentifier

36
 Figure 16:Raffinement de cas d’utilisation : «S’authentifier».

Spécification des cas d’utilisation précis «S’authentifier»

Nom de cas d’utilisation S’authentifier.

Acteurs Administrateur, Organisateur, Client.
Description brèves L’acteur s’authentifie en utilisant son login et son mot
de passe.
Pré-Condition - Opération d’authentification demandée par l’acteur
Scénario de bases
1. L’acteur saisit son e-mail et son mot de passe.
2. Le système vérifie les données de l’acteur.
3. Le système affiche un message de succès
d’authentification.
4. Le système affiche l’interface d’accueil propre à
l’acteur
Post-Condition Acteur authentifié.

37
Scénario d’exception 2. login ou mot de passe non valide :
- Le système affiche un message d’erreur.
- Retour à l’étape 1 du scénario de base.
Tableau 3:Scénario de cas «S’authentifier»

Processus « Gérer événement» :

Figure 17:Raffinement de cas d’utilisation : Gérer évènement

Cu : Afficher liste évènement.

Nom de cas Afficher liste événement.

d’utilisation
Acteurs Client

Description brèves Le client à la possibilité de consulter la liste

d’événement.

38
Pré-Condition - le client s’est authentifié.

Scénario de bases 1-L’organisateur s’authentifie

2-cliue sur gestion événement puis liste événement

Post-Condition Liste événement affiché

Tableau 4:Scénario de cas «Afficher liste événement»

Cu : Rechercher événement :
Nom de cas Rechercher événement
d’utilisation
Acteurs Client

Description brèves Le client a la possibilité de faire une recherche des

événements selon la catégorie, la ville, intérêt.
Pré-Condition - le client s’est authentifié.
- Opération de Rechercher événement choisie.
Scénario de bases 1-L’organisateur s’authentifie.
2-Choisie Rechercher événement.
3-Entrer les critères désirées.

Post-Condition Liste des événements désirés afficher.

Tableau 5:Scénario de cas «Rechercher événement»

CU : Ajouter aux favoris.

Nom de cas Ajouter aux favoris.
d’utilisation
Acteurs Client.

Description brèves Le client a la possibilité d’ajouter des événements au

panier.

39
Pré-Condition 1-le client s’est authentifié.
2-Consulter évènement
3- Opération de ajouter aux favoris choisie.
Post-Condition Liste des événements désirés afficher.
Tableau 6:Scénario de cas «Ajouter aux favoris»

Cu : Envoyer messages.
Nom de cas Envoyer messages.
d’utilisation
Acteurs Client

Description brèves Le client a la possibilité d’envoyer un message

(Réclamation, Suggestion, question etc…)
Pré-Condition 1-le client s’est authentifié.
2-Choisir l’opération Contacter
3-Envoyer messages.
Post-Condition Messages envoyée.
Scénario de bases 1-L’organisateur s’authentifie.
2-choisir contacter
3-ecrire et envoyer messages.

Tableau 7:Scénario de cas «Envoyer messages»

Cu : Ajouter événement

Nom de cas Ajouter événement.

d’utilisation
Acteurs Organisateurs.

Description brèves L’organisateur a la possibilité d’ajouter un ou plusieurs

événements.
Pré-Condition 1-l’organisateur S’inscrit.
2-le client s’est authentifié.
3-choisir gestion événement
4-remplir les caractéristiques et ajouter événement
Post-Condition Evénement ajouté
Scénario de bases 1-L’organisateur s’authentifie.
2-Choisir Gestion événement
3-Ajouter événement

Tableau 8:Scénario de cas « Ajouter événement»

40
Cu : Modifier événement.

Nom de cas Modifier événement.

d’utilisation
Acteurs Organisateurs.

Description brèves L’organisateur a la possibilité de modifier un événement.

Pré-Condition 1-le client s’est authentifié.

Scénario de bases
2-choisir gestion événement
3-afficher liste événement
4-choisir l’événement à modifier.
5-appliuer les modifications et valider.
1-L’organisateur s’authentifie.
2-Choisir Gestion événement

Post-Condition
Evénement modifié

Tableau 9:Scénario de cas «Modifier événement.»

Cu : Supprimer événement.

Nom de cas Supprimer événement.

d’utilisation
Acteurs Organisateurs.

Description brèves L’organisateur a la possibilité de supprimer un

événement.
Pré-Condition 1-organisateur authentifié.
2-choisir gestion événement
3-afficher liste événement
4-choisir l’événement à supprimer.
.
Scénario de bases 1-L’organisateur s’authentifie.
2-Choisir Gestion événement

Post-Condition
Evénement supprimé

41
 Tableau 10:Scénario de cas «Supprimer événement»

2. Modèle du domaine (Diagramme de Classe)

2.1 Définition
Le diagramme de classes [10] est considéré comme le plus important de la
modélisation orientée objet, il est le seul obligatoire lors d'une telle
modélisation.
Alors que le diagramme de cas d'utilisation montre un système du point de
vue des acteurs, le diagramme de classes en montre la structure interne. Il
permet de fournir une représentation abstraite des objets du système qui
vont interagir pour réaliser les cas d'utilisation. Il est important de noter
qu'un même objet peut très bien intervenir dans la réalisation de plusieurs
cas d'utilisation. Les cas d'utilisation ne réalisent donc pas une partition des
classes du diagramme de classes. Un diagramme de classes n'est donc pas
adapté (sauf cas particulier) pour détailler, décomposer, ou illustrer la
réalisation d'un cas d'utilisation particulier.
Il s'agit d'une vue statique, car on ne tient pas compte du facteur temporel
dans le comportement du système. Le diagramme de classes modélise les
concepts du domaine d'application ainsi que les concepts internes créés de
toutes pièces dans le cadre de l'implémentation d'une application. Chaque
langage de Programmation orienté objet donne un moyen spécifique
d'implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou
pas, etc.), mais le diagramme de classes permet de modéliser les classes du
système et leurs relations indépendamment d'un langage de
programmation particulier.
Les principaux éléments de cette vue statique sont les classes et leurs
relations : association, généralisation et plusieurs types de dépendances,
telles que la réalisation et l'utilisation.

Modèle de domaine de processus «Gestion

événements»

42
 Figure 18:Diagramme modèle de domaine de CU «Gestion événements»

Processus « gestion des réservations » :

43
 s

Figure 19:Raffinement de cas d’utilisation : Gérer réservation.

Spécification de cas d’utilisation : Gérer réservations.

CU : Réserver événement.

Nom de cas Réserver événement

d’utilisation
Acteurs Client.

Description brèves Le client a la possibilité de réserver un événement.

Pré-Condition 1-le client s’est authentifié.

2-choisir Consulter liste événement.
3-afficher liste événement
4-choisir un événement.
5-Afficher détails événement.
6-Reserver événement.
Post-Condition Evénement réservé.
Scénario de bases 1-Le client s’est authentifie.
2-Choisir liste événement.
3-Choisir détails événement.
4-Reserver événement

Tableau 11:Scénario de cas «Réserver événement»

44
Cu : Consulter liste réservation.

Nom de cas Consulter liste réservations.

d’utilisation
Acteurs Organisateurs.

Description brèves L’organisateur a la possibilité de consulter la liste de

réservation.
Pré-Condition 1-l’organisateur s’est authentifié.
2-choisir gestion réservation
3-afficher liste réservation.

Post-Condition Liste réservation affiché

Scénario de bases 1-L’organisateur s’authentifie.
2-Choisir Gestion Réservations.

Tableau 12:Scénario de cas «Consulter liste réservation»

CU : Payer événement.

Nom de cas Payer événement.

d’utilisation
Acteurs Client.

Description brèves Le client a la possibilité de payer un événement.

Pré-Condition 1-le client s’est authentifié.

2-choisir Consulter liste événement.
3-afficher liste événement
4-choisir un événement.
5-Afficher détails événement.
6-Reserver événement.
Post-Condition Cliquer sur payer
Payement effectuées.
Scénario de bases 1-choisir Consulter liste événement.
2-afficher liste événement
3-choisir un événement.

45
 4-Afficher détails événement.
5-Reserver événement.
6effectuer payement sur le site de paypal
Tableau 13:Scénario de cas «Payer événement»

CU : Annuler réservation

Nom de cas Annuler réservation.

d’utilisation
Acteurs Client.

Description brèves Le client a la possibilité d’annuler une réservation.

Pré-Condition 1-le client s’est authentifié.

2-choisir Consulter liste réservation.
3-choisir un événement.
4- Cliquer sur annuler.
.
Post-Condition Annulation effectuées.
Scénario de bases 1-choisir Consulter liste réservation.
2-choisir un événement.
3- Cliquer sur annuler.

Tableau 14: Scénario de cas «Annuler réservation»

Diagramme de séquence système : Gestion réservation

46
Figure 20:Diagramme se séquence système Gérer réservation : Réserver un événement

47
Figure 21:Diagramme se séquence système Gérer réservation : Consulter réservation

Diagramme d’activité Gestion résérvation :réserver un événement

48
49
Figure 22:Diagramme d’activité : Réserver un événement

Modèle de domaine de cas d’utilisation «Gestion

réservation»

50
Figure 23:Diagramme de domaine de cas d’utilisation : Gestion réservation

Conclusion :

Ce deuxième chapitre, a été consacré, en premier lieu, à la méthode et outils de

modélisation choisis d’où on a présenté les choix conceptuels en termes de
méthode de conception, d’outils techniques et de cycle de vie logiciel. En
second lieu, nous avons procédé au modèle métier qui concerne le diagramme
des processus métier. Puis, grâce au modèle de cas d’utilisation, nous avons
essayé de lever les ambiguïtés sur les besoins et les exigences. L’analyse et la
conception des cas d’utilisation seront détaillées dans le chapitre suivant.

51
Chapitre3 :
Analyse et
conception

52
Chapitre3 : Analyse et conception
Introduction :
Ce chapitre se consacre, en premier lieu, à l'analyse des besoins décrits dans
le chapitre précédent, en les raffinant et en les structurant. L'objectif est
d'accéder à une compréhension plus aiguë des besoins et des exigences et
d'en livrer une description facile à entretenir, favorisant la structuration de
l'ensemble du système, y compris de son architecture.
Il s’agit, donc, d’analyser les cas d’utilisation qui ont été identifiés et raffinés
pendant la phase d’élaboration. En deuxième lieu, ce chapitre procède à
l’enchaînement de conception, ayant pour but de produire les spécifications
d’implémentation du système en se basant sur le modèle MVC.

1. Modèle d’analyse (Diagramme de traçabilité et diagramme de classe d’analyse) :

L’enchaînement d’analyse présente une analyse détaillée de chaque
d’utilisation à travers les diagrammes d’analyse et de classe qui se compose
de 3 types de classes :
Classes « entité » : Classes données du système (durée de vie plus
longue que celle des UC)
Classes « frontière » : Interfaces entre acteur et système
Classes « contrôle » : Encapsulent le comportement d'un Use Case

1.1 Analyse du cas d’utilisation « Gérer événement » :

1.1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle
d’analyse du cas d’utilisation : Gérer évènement

53
 Figure 24:Traçabilité Diagramme de cas d’utilisation : Gérer événement.

Diagramme de classe d’analyse de cas d’utilisation Gérer

événement : Organisateur.

54
 Figure 25:Diagramme de classe d’analyse de cas d’utilisation Gérer événement :Organisateur.

Diagramme de classe d’analyse de cas d’utilisation Gérer

événement :Client.

55
 Figure 26:Diagramme de classe d’analyse de cas d’utilisation Gérer événement :Organisateur.

Diagramme de classe d’analyse Gérer événement : Administrateur.

56
 Figure 27:Diagramme de classe d’analyse Gérer événement : Administrateur.

Analyse du cas d’utilisation « Gérer réservation» :

1.1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation : Gérer réservation.

Figure 28:1.1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation : Gérer réservation.

Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Client.

57
 Figure 29:Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Client.

Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Organisateur

Figure 30:Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Client.

58
II. Conception
1. Diagrammes de séquences
1.1. Définition
Les diagrammes de séquences permettent d’établir un lien entre les
diagrammes de classes et les diagrammes de cas d’utilisation car ils
montrent comment les objets communiquent entre eux pour réaliser les
fonctionnalités attendues. En effet, ils montrent les interactions entre les
objets selon un point de vue temporel.
Les éléments associés pour la modélisation d’un diagramme de séquences
sont :
-Les objets.
-Les messages entre les objets.
En effet, un diagramme de séquence présente plusieurs avantages :
Vous pouvez facilement voire comment les tâches sont distribuées entre les
différents composants.
Vous pouvez identifier les modèles d'interaction qui rendent plus difficile la
mise à jour du logiciel.

1.2. Le modèle utilisé MVC : Modèle Vue Contrôleur

Le patron modèle-vue-contrôleur (en abrégé MVC, de l'anglais model-View-

Controller), est un modèle destiné à répondre aux besoins des applications
interactives en séparant les problématiques liées aux différents composants
au sein de leur architecture respective.
Ce paradigme regroupe les fonctions nécessaires en trois catégories :
Model : C'est la partie qui définit la fonctionnalité de base de
l'application derrière des abstractions. L'accès aux données et le logique
métier sont définis dans cette couche.

59
View : La vue définit exactement ce qui sera présenté à l'utilisateur.
Normalement les contrôleurs passent des données à chaque vue à rendre
dans un format précis. Les vues collectent les données de l'utilisateur aussi.
1.3. Présentation des diagrammes de séquences :
1.4. Diagramme de séquences de processus gérer événement :
Diagramme de séquences de cas d’utilisation : Consulter liste événement.

Figure 31:Diagramme de séquences de cas d’utilisation : Consulter liste événement.

Description :

Action de l’acteur Réaction du système

1-L’organisateur demande d’afficher 2-le système affiche la liste
la liste d’événement. d’événement.
Tableau 15:Description de diagramme de séquences de cas d’utilisation : Consulter liste événement.

Diagramme de séquence afficher un événement :

60
Figure 32:Diagramme de séquence afficher un événement

Diagramme de séquences de cas d’utilisation : Ajouter événement

61
 :Organisateur : : ui Ajout événement :Control événement : : Evénement
NewClass16 Control événement

Ref: Sequence Diagram: Consulter liste événement

1:Demande le formulaire d'ajout

2:Fournir le formulaire d'ajout

3:Saisir les données

4:Verification des champs

5:Soumettre les données

Alt
6:Envoie de la requete Ajout événement(Données saisie)
Succée
10:Evénement en attente

12:Evénement validé par l'admin

11:Evénement ajouté avec succées

7:Verification des données

Refus
9:Reponse requete

13:Evénement refusé par l'admin

8:Execution de la requete

14:Evénement n'est pas publié

Figure 33:Diagramme de séquences de cas d’utilisation : Ajouter événement

Description :
Action de l’acteur Réaction du système
1-L’organisateur demande d’ajouter 2. Vérifie la validité des champs
un événement saisis.
3. Enregistre les données du
nouveau de la BD.
4. Si l’événement est validé par

62
 l’administrateur le système
enregistre l’événement au niveau de
la liste d’événement.

Tableau 16:Description diagramme de séquences de cas d’utilisation : Ajouter événement

Diagramme de séquences de cas d’utilisation : Modifier événement.

63
 Figure 34:Diagramme de séquences de cas d’utilisation : Modifier événement.

Description :
Action de l’acteur Réaction du système

1. L’organisateur Choisit 2. Affiche les informations

l’événement à modifier. concernant le client à modifier.

3. L’organisateur saisie les nouvelles 4. Vérifie les données modifiées

données. 5. Enregistre les données a
modifiées dans la table de la base de
données.

64
 6. Redirection vers le profil du
client.

Tableau 17:Description diagramme de séquences de cas d’utilisation : Modifier événement

Diagramme de séquences de cas d’utilisation : Supprimer événement.

Figure 35:Diagramme de séquences de cas d’utilisation : Supprimer événement.

Description :
Action de l’acteur Réaction du système

1. L’organisateur Choisit
l’événement à supprimer. 2. Affiche les informations
concernant l’événement..
3. L’expert choisie le client à
supprimer. 4. Enregistre la demande de
suppression dans la table de la base
de données.
5. Redirection vers la liste des
clients avec un message.

65
Tableau 18:Description diagramme de séquences de cas d’utilisation : Supprimer événement

Diagramme de séquences de cas d’utilisation : Envoyer messages.

Client : NewClass16 : UI liste événement : UI Envoyer message : Control messages : Message

1:Afficher i nterface événement

2:charger demande d'interface

4:Données recupérées

5:Interface événement affiché

6:Click sur btn 'Envoyer messge'

3:Traitement de la requete

7:Interface message affiché

8:Saisir les données d'envoie d'un msg

9:Envoyer les données

10:Vericati on

Loop 11:Ajout des données

12:Statue

13:Message envoyé

14:Msg'Envoyé avec succés

15:Satue

16:Message est vide

17:Msg'Veuillez saisir votre messages'

Figure 36:Diagramme de séquences de cas d’utilisation : Envoyer messages.

Action de l’acteur Réaction du système

1. Le client Choisit l’événement pour 2. Le système affiche l’événement.

envoyer un message. 4. Le système affiche l’interface de
messages.
3. Le client clique sur le bouton 6. Enregistre la demande d’envoi de
envoyer messages. messages dans la table de la base de
5. Le client remplie les champs données.

66
 pour envoyer un message. 6. Redirection vers la liste de
messages de clients et la liste de
messages d’organisateurs

Tableau 19:Description diagramme de séquences de cas d’utilisation : Envoyer messages

Diagramme de séquences de processus « Gérer réservation»

Diagramme de séquences de cas d’utilisation : Réserver événement.

67
 Client : NewClass16 : UI détails événement : Control reservation : Evénement

1:Selectionner un événement

2:événement affiché

3:Click sur btn 'plus details'

4:Interface details événement affichée

Click sur btn'Reserver'

Alt

5:Add reservation(:num reservation)

Succée
6:Enregistrer reservation

7:Afficher alérte de succées

8:Msg'Reservation effectuée avec succées

6:Demande envoyée
Echéc

9:Alerte d'échec

10:Msg'Stock epuisé'

Figure 37:Diagramme de séquences de cas d’utilisation : Réserver événement

Action de l’acteur Réaction du système

1. Le client Choisit l’événement à 2. Le système affiche l’événement.

réserver. 4. Le système affiche deux bouton
soit réserver seulement soit payer
3. Le client clique sur le bouton l’événement.
réserver.
5. Enregistre la demande de
réservation dans la table de la base
de données.
6. Redirection vers la liste de la
réservation de clients avec un
message.

68
Enchainement alternatif :
-Si le stock de ticket est épuisé le système affiche au client un message
‘Stock épuisé’.

Tableau 20:Description diagramme de séquences de cas d’utilisation : Réserver événement

Schéma de bases de données :

Evenement(idEvent,adrEvent,dateEvent,descEvent,etat,heureEvent,imageE
vent,latitude,longitude,nbrPlaces,note,prixEvent,TitreEvent,villeEvent,categ
orie_id,organisateur_id).
Organisateur(id_organisateur,etat,mail,tel).
Personne (id,login,nom,password,prenom,role_user).
Utilisateur (mail,tel,ville,id_user).
Reservation(NumReservation,dateRes,Eveneme_id),utilisateur_id).
Favoris (idfav,Evenement_id,Utilisateur_id).
Admin(idAdmin).

Diagramme de déploiement :

Figure 38: Diagramme de déploiement système

69
70
 Chapitre 4 :
Réalisation et
mise en œuvre

71
Chapitre 4 : Réalisation et mise en œuvre
4.1Introduction :
Après avoir achevé la phase d’élaboration ainsi que l’analyse et la
conception du système d’information, nous complétons la phase terminale
de notre travail qui se compose de trois grandes parties :
Dans une deuxième partie, nous allons présenter les langages, bibliothèques
et outils de développements.
Dans la troisième partie, nous passons à la présentation de l’application
‘Tunisia Events’ à travers des captures d’écrans produites lors de la
réalisation.

4.2 Environnement de développement

Dans cette partie nous allons décrire l’environnement matériel, logiciel et
technique qu’on a opté au cours de la réalisation de notre application.
4.2.1 Environnement matériel
Le développement de l’application est réalisé par le biais de deux
ordinateurs portables ayant les caractéristiques suivantes :

Caractéristique Machine A Machine B

Marque ACER SAMSUNG
Processeur Intel core i3 Intel core i5
Disque dur 500 GB 500 GB
Ram 4GB 4GB
Système d’exploitation Windows 8.1 Windows 7
Tableau 21:Tableau des caractéristiques matériel

4.2.2 Environnement logiciel

En effet, les logiciels et les langages utilisés pour le développement de notre
application ainsi que pour la rédaction du rapport sont :
Outils de rédaction de rapport : Microsoft Word

Figure 39:Logo Microsoft word

Outils de conception : Rational Rose

Figure 40:Logo
Rationnal Rose
72
Rational Rose est un logiciel édité par l'entreprise Rational Machines (plus
tard renommée Rational Software) pour créer et éditer les différents
diagrammes du modèle UML (Unified Modeling Language) d'un logiciel.

Editeur de texte : Notepad++ .

Figure 41:Logo Notepad++:

Notepad++: est un éditeur de texte libre générique, fonctionnant sous

Windows, codé en C++.
qui intègre la coloration syntaxique de code source pour les langages et
fichiers C, C++, Java, C#.

Serveur de gestion des bases de données : Wamp Server

Figure 42:Logo Wamp Server

(anciennement WAMP5) est une plateforme de développement Web de

type WAMP, permettant de faire fonctionner localement (sans avoir à se
connecter à un serveur externe) des scripts PHP. WampServer n'est pas en
soi un logiciel, mais un environnement comprenant trois serveurs
(Apache, MySQL et MariaDB), un interpréteur de script (PHP), ainsi
que phpMyAdmin pour l'administration Web des bases MySQL.

Logiciel : PHP MyAdmin (version …)

L’une des plus célèbres interfaces pour la gestion des bases de données
MySQL sur un serveur PHP son utilisation est possible sans devoir
l’installer. Cette interface permet d’exécuter, des requêtes comme les
créations de table de données, insertions, mises à jour, suppressions et
modifications de structure de la base de données, ainsi que l’attribution et
la révocation de droits et l’import/export.

73
Ce système permet de sauvegarder commodément une base de données
sous forme de fichier d’extension SqL et d’y transférer ses données.
Outils de traitement d’image :Paint

Figure 43:Logo Paint

Langages de programmation
Le HTML5 est la dernière révision majeure d’HTML qui est un langage
informatique de présentation apparu aux années 1991 lors du lancement
du Web. Son rôle est de gérer et d’organiser le contenu. Le code HTML
est exécuter côté client et c’est les navigateurs web qui seront chargés de
leurs traductions et affichage sur l’écran. Cette dernière version qui de
plus en plus répandue, fait beaucoup parler d’elle car elle apporte de
nombreuses améliorations comme la possibilité d’inclure facilement des
vidéos, un meilleur agencement du contenu, et plein de nouvelles
fonctionnalités pour les formulaires. CSS3
Le CSS, Feuilles de style en cascade, de l’anglais Cascading Style Sheets, est
un langage informatique qui décrit la présentation et la mise
en forme des documents HTML, on dit alors qu’il vient pour compléter
le HTML afin de magnifier l’apparence des pages web (agencement,
positionnement, décoration, couleurs, taille du texte,etc.).
Le CSS fut un standard couramment utilisé dans la conception des sites web
et pris en charge par la majorité des navigateurs dans les années 2000.
J2EE :

Figure 44:Logo de J2EE

La plateforme J2EE (Java™ 2 Platform Enterprise Edition) met à disposition

une norme pour le développement d'applications d'entreprise multi niveau.
L'économie et la technologie d'aujourd'hui ont intensifié la nécessité de
disposer de solutions de gestion des informations plus rapides, plus
efficaces et à plus grande échelle. La spécification J2EE répond à ces défis en
offrant un modèle de programmation qui améliore la productivité de
74
développement, qui standardise la plateforme d'hébergement des
applications d'entreprise et qui garantit la portabilité des applications
développées grâce à une vaste suite de tests.
Android Studio :

Figure 45:Logo de Android Studio

Android Studio est un environnement de développement pour développer

des applications Android. Il est basé sur IntelliJ IDEA.
Android Studio permet principalement d'éditer les fichiers Java/Kotlin et
les fichiers de configuration XML d'une application Android.
Il propose entre autres des outils pour gérer le développement
d'applications multilingues et permet de visualiser la mise en page des
écrans sur des écrans de résolutions variées simultanément.
Diagramme de composants :
Dans UML, les diagrammes de composants représentent la structure du
système logiciel, qui décrit les composants du logiciel, leurs interfaces et
leurs dépendances.
Ce type de diagramme prend en charge le développement à base de
composants, dans lequel un système logiciel est divisé en composants et
interfaces qui sont réutilisables et remplaçables.
Les fichiers sources, les fichiers exécutables, les librairies, et les documents
sont considérés comme des composants.
Ainsi, nous modélisons les composants et les relations qui permettent de les
lier pour que :
— Les clients peuvent visualiser la structure et les fonctionnalités du
système finalisé.
— Les développeurs admettent une structure sur laquelle, ils peuvent
travailler.
— Les rédacteurs techniques peuvent fournir une documentation et des
fichiers d’aide expliquant parfaitement le système implémenté.
— Le processus de réutilisation soit facile.
Implémentation de cas d’utilisation : Gérer réservation
Traçabilité MC/MI pour le CU «Gérer réservation»

75
Figure 46:Implémentation de cas d’utilisation : Gérer réservation

Diagramme de composant de cas d’utilisation : Gérer événement

Figure 47:Diagramme de composant de cas d’utilisation : Gérer événement

Implémentation de cas d’utilisation : Gérer événement

Traçabilité MC/MI pour le CU «Gérer événement»

76
Figure 48:Implémentation de cas d’utilisation : Gérer événement

77
Diagramme de composant cas d’utilisation : Gérer événement

Figure 49:Implémentation de cas d’utilisation : Gérer événement

Dans ce qui suit nous présentons la structure selon laquelle seront

disposées les différentes fonctionnalités de l’application :

Figure 50:Structure de l’application

78
 Présentation des interfaces :
Ci-dessous nous exposons des captures d’écran de certaines interfaces de
l’application développée :
Présentation des interfaces web :
Interface d’accueil : Se connecter
A travers cette interface, chaque utilisateur doit saisir son email et son mot de passe
pour pouvoir accéder à l’application.

Figure 51:Interface d’accueil

Partie Administrateur :
Interface comptes organisateur.
L’administrateur consulte la liste des organisateurs.

79
 Figure 52:Interface comptes organisateur.

Interface validation événement :

L’administrateur consulte la liste des événements pour les valider

Figure 53:Interface validation événement

Partie organisateur :
Interface ajouter événement :

80
 Figure 54:Interface ajouter événement

Interface de gestion des messages :

Figure 55:Interface de gestion des messages

Interface liste des réservations :

Le client consulte la liste des réservations.

81
 Figure 56:Interface liste des réservations

Partie web :
Partie clients :
Interface d’accueil :
Le client peut consulter, rechercher un événement sans être inscrit à
l’application.

Figure 57:Interface d’accueil

Interface Se connecter :

82
A travers cette interface, chaque utilisateur doit saisir son email et son mot
de passe pour pouvoir accéder à l’application.

Figure 58:Interface Se connecter :

Interface Menu :
Cette interface permet d’accéder aux différentes fonctionnalités de
l’application

Figure 59:Interface Menu

Interface Liste événement :

Cette interface permet d’accéder à la liste d’événements.

83
 Figure 60:Interface Liste événement

Interface rechercher événement :

Cette interface permet chercher un événement selon la ville et catégorie.

Figure 61:Interface rechercher événement

Interface liste réservations :

Cette interface permet au client de consulter sa liste de réservation et
d’annuler une réservation.

84
 Figure 62:Interface liste réservations

Interface détails événement : le client peut consulter, localiser, ajouter aux

favoris un événement aussi envoyer un message aux organisateurs.

Conclusion :
Au cours de ce chapitre, nous avons décrit les plateformes utilisées dans le
développement de notre application. Nous avons ensuite présenté
l’application proprement dite à travers une sélection des interfaces les plus
significatives que nous avons développées.

85
A présent nous passerons dans la partie suivante à la conclusion générale
de notre projet et aux perspectives que nous souhaitons achever dans un
futur proche.
Conclusion générale & perspectives
Dans l’environnement concurrentiel d’aujourd’hui, il est primordial pour
toute organisation de maîtriser les outils de marketing et publicité.

En effet projet a été réalisé dans le cadre de projet de fin d’étude pendant
trois mois de stage au sein de la société de développement « G-Dev ».
Le présent travail se résume dans la conception et la réalisation d’une
application web et mobile pour la gestion et la publicité d’événement .Il
s’agit d’informatiser certaines fonctionnalités essentielles.
Ainsi, dans ce projet on a appliqué quelques enchaînements du cycle de vie
du processus unifié et on s’est basé sur le paradigme MVC comme schéma
de programmation qui propose de séparer l’application en trois parties
(Modèle, Vue, Contrôleur).
De plus, on s’est servi de l’Android et J2EE pour la réalisation et le
déploiement de notre projet.
Par ailleurs, ce stage nous a donné la chance de manipuler des techniques
innovantes et évolutives et nous a permis aussi de tester et d’appliquer nos
connaissances acquises au sein de l’ISG et de les améliorer.

De même, il nous a fourni l’occasion d’être intégré dans la vie

professionnelle et nous a donné une vision globale sur notre avenir comme
concepteur et développeur.

Cependant, comme tout projet de fin d’étude nous avons rencontré des
problèmes de divers types. L’implémentation de notre système fut l’une des
majeures difficultés que nous avons rencontrées vu le nouvel
environnement de travail et sa complexité.

Nous avons pu dépasser ces défis par notre volonté à présenter un bon
travail, à apprendre et à utiliser les nouvelles technologies de
programmation et en appliquant nos connaissances.

Il est vrai d’après les différents scénarios des tests d’exécution effectués
précédemment que nous sommes arrivés à réaliser le but de notre projet.

Mais ceci ne nous empêche pas à penser à des améliorations à apporter à

notre application.
Et Comme perspectives de ce travail.

86
Nous pouvons faire évoluer notre application en développant un module de
notification qui permet au client d’être notifié par localisation d’événement
le plus proche et même d’utiliser d’autres modes de paiement .

L’application pourra aussi donner l’opportunité d’intégrer la notion de

sponsoring et faire une publicité des autres organisations d’où ‘Tunisia
Events’ deviendra beaucoup plus rentable.

87