Professional Documents
Culture Documents
Université de Sousse
RAPPORT DE STAGE
POUR L’OBTENTION DE LA
NOM DU PROJET :
Tunisia Events
LIEU DU STAGE :
G-Dev
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.
2
Dédicace :
Du profond de mon cœur, je dédie ce travail à tous ceux qui me sont chers :
Ghada El May
3
Dédicace :
Je dédie ce projet à :
Mes parents : Ma mère, qui a œuvré pour ma réussite, de par son amour, son
soutien, tous les sacrifices consentis et ses précieux conseils, pour toute son
assistance et sa présence dans ma vie, reçois ç travers ce travail aussi modeste
soit-il, l'expression de mes sentiments et de mon éternelle gratitude.
Mon père, qui peut être fier et trouver ici le résultat de longues années de
sacrifices et privation pour m'aider à avancer dans la vie. Puisse Dieu faire en
sorte que ce travail parte son fruit, Merci pour les valeurs nobles, l'éducation et
le soutient permanent venu de toi.
Mes frères et sœurs qui n'ont cessé d'être pour mois des exemples de
persévérance, de courage et de générosité.
Magouri Yasser
4
5
Table des matières
Chapitre 1 : Contexte général du projet ............................................................................................... 16
I. Introduction : ................................................................................................................................. 16
II. Présentation de l’organisme d’acceuil .......................................................................................... 16
1. Historique : ................................................................................................................................ 16
2. Fiche technique : ....................................................................................................................... 17
3. Oraganigramme : ....................................................................................................................... 18
III. Etude préalable : ....................................................................................................................... 18
1. Présentation de Tunisia Events : ............................................................................................... 18
2. Les principaux éléments de Tunisia Events .............................................................................. 19
IV. Cahier de charge : ...................................................................................................................... 20
1. Etude de l’existant ..................................................................................................................... 20
2. Critique de l’existant : ............................................................................................................... 22
3. Spécification des besoins .......................................................................................................... 25
4. Architecture envisagée : ............................................................................................................ 26
V. Planning des tâches : ..................................................................................................................... 28
1. Diagramme de Gantt : ............................................................................................................... 28
VI. Conclusion : ............................................................................................................................... 28
Chapitre2 :Elaboration .......................................................................................................................... 31
I. Introduction : ................................................................................................................................. 31
II. Méthode et outils de modélisation choisis : ................................................................................. 31
1. Processus unifié : ....................................................................................................................... 31
2. Langage de modélisation choisi ................................................................................................ 35
3. Outil de modélisation ................................................................................................................ 36
a. L'équipe de développement ...................................................................................................... 37
b. Processus de développement ................................................................................................... 37
c. Modèle de gestion ..................................................................................................................... 37
d. Problèmes hérités ..................................................................................................................... 38
III. Modèle métier (Diagramme de Cas d’utilisation) : ................................................................... 38
1. Les diagrammes de cas d'utilisation : ........................................................................................ 38
2. Diagramme processus métier :.................................................................................................. 40
-Processus « Gérer événement» : ..................................................................................................... 44
6
IV. Modèle du domaine (Diagramme de Classe ............................................................................. 48
-Modèle de domaine de processus «Gestion événements» ............................................................. 48
-Processus « gestion des réservations » :.......................................................................................... 49
-Diagramme de séquence système : Gestion réservation ................................................................ 53
-Diagramme d’activité Gestion résérvation :réserver un événement .............................................. 54
-Diagramme d’activité Gestion résérvation :Consulter liste résérvations. ....................................... 56
-Modèle de domaine de cas d’utilisation «Gestion réservation» ..................................................... 57
V. Conclusion : ................................................................................................................................... 57
Chapitre3 : Analyse et conception ........................................................................................................ 59
I. Introduction : ................................................................................................................................. 59
II. -Analyse ......................................................................................................................................... 59
III. Analyse du cas d’utilisation « Gérer événement » : .................................................................. 60
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 .............................................................................................................................. 60
2. Diagramme de classe d’analyse de cas d’utilisation Gérer événement : Organisateur. ........... 61
3. Diagramme de classe d’analyse de cas d’utilisation Gérer événement :Client......................... 61
4. Diagramme de classe d’analyse Gérer événement : Administrateur........................................ 63
IV. Analyse du cas d’utilisation « Gérer réservation» :................................................................... 63
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. ............................................................................................................................. 63
2. Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Client........................ 63
3. Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Organisateur ............ 64
V. Conception .................................................................................................................................... 65
1. Diagrammes de séquences........................................................................................................ 65
A. Diagramme de séquences de processus <<gérer événement>> : .................................... 66
B. Diagramme de séquences de processus « Gérer réservation» ......................................... 73
2. Schéma de bases de données : ................................................................................................. 76
VI. Diagramme de déploiement :.................................................................................................... 77
VII. Conclusion ................................................................................................................................. 77
Chapitre 4 : Réalisation et mise en œuvre ............................................................................................ 79
I. Introduction : ................................................................................................................................. 79
1. Environnement de développement .......................................................................................... 79
a. Environnement matériel : ..................................................................................................... 79
b. Environnement logiciel .......................................................................................................... 79
II. Diagramme de composants :......................................................................................................... 82
7
III. Implémentation : ....................................................................................................................... 83
1. Implémentation de cas d’utilisation : Gérer réservation .......................................................... 83
a. Traçabilité MC/MI pour le CU «Gérer réservation» .......................................................... 83
b. Diagramme de composant de cas d’utilisation : Gérer événement.................................. 83
2. Implémentation de cas d’utilisation : Gérer événement .......................................................... 84
a. Traçabilité MC/MI pour le CU «Gérer événement» ........................................................... 84
b. Diagramme de composant cas d’utilisation : Gérer événement....................................... 85
IV. Présentation de l’application : .................................................................................................. 85
Présentation des interfaces :............................................................................................................. 86
1. Présentation des interfaces web : ............................................................................................. 86
2. Partie mobile : ........................................................................................................................... 89
V. Conclusion : ................................................................................................................................... 92
Conclusion générale & perspectives ..................................................................................................... 93
8
9
Liste des figures :
Figure 1:logo de la société G-Dev .......................................................................................................... 16
Figure 2:Organigramme de G-Dev......................................................................................................... 18
Figure 3:Logo de l’application Teskerti ................................................................................................. 21
Figure 4:Logo de l’apllication AlloCiné .................................................................................................. 21
Figure 5:Page d’accueil de l’application Teskerti .................................................................................. 23
Figure 6:Page d’acceuil de l’application Teskerti .................................................................................. 24
Figure 7:Présentation de l’application Teskerti .................................................................................... 24
Figure 8:Architecture matériel du modèle MVC ................................................................................... 27
Figure 9:Diagramme de Gantt ............................................................................................................... 28
Figure 10:Phase du Processus Unifié..................................................................................................... 32
Figure 11:Logo d’UML ........................................................................................................................... 35
Figure 12:Les diagrammes de UML ....................................................................................................... 36
Figure 13:Logo de Rationnal Rose ......................................................................................................... 37
Figure 14: Présentation générale d’un diagramme de cas d’utilisation ............................................... 39
Figure 15:Diagramme de cas d’utilisation Global ................................................................................. 41
Figure 16:Raffinement de cas d’utilisation : «S’authentifier»............................................................... 43
Figure 17:Raffinement de cas d’utilisation : Gérer évènement ............................................................ 44
Figure 18:Diagramme modèle de domaine de CU «Gestion événements» .......................................... 49
Figure 19:Raffinement de cas d’utilisation : Gérer réservation. ........................................................... 50
Figure 20:Diagramme se séquence système Gérer réservation : Réserver un événement .................. 53
Figure 21:Diagramme se séquence système Gérer réservation : Consulter réservation ..................... 54
Figure 22:Diagramme d’activité : Réserver un événement................................................................... 56
Figure 23:Diagramme de domaine de cas d’utilisation : Gestion réservation ...................................... 57
Figure 24:Traçabilité Diagramme de cas d’utilisation : Gérer événement. .......................................... 60
Figure 25:Diagramme de classe d’analyse de cas d’utilisation Gérer événement :Organisateur. ........ 61
Figure 26:Diagramme de classe d’analyse de cas d’utilisation Gérer événement :Organisateur. ........ 62
Figure 27:Diagramme de classe d’analyse Gérer événement : Administrateur. .................................. 63
Figure 28:Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation :
Gérer réservation. 63
Figure 29:Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Client. .................. 64
Figure 30:Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Client. .................. 64
Figure 31:Diagramme de séquences de cas d’utilisation : Consulter liste événement......................... 66
Figure 32:Diagramme de séquence afficher un événement ................................................................. 67
Figure 33:Diagramme de séquences de cas d’utilisation : Ajouter événement.................................... 68
Figure 34:Diagramme de séquences de cas d’utilisation : Modifier événement. ................................. 70
Figure 35:Diagramme de séquences de cas d’utilisation : Supprimer événement. .............................. 71
Figure 36:Diagramme de séquences de cas d’utilisation : Envoyer messages. .................................... 72
Figure 37:Diagramme de séquences de cas d’utilisation : Réserver événement ................................. 74
Figure 38: Diagramme de déploiement système .................................................................................. 77
Figure 39:Logo Microsoft word ............................................................................................................. 79
Figure 40:Logo Rationnal Rose .............................................................................................................. 79
Figure 41:Logo Notepad++: ................................................................................................................... 80
Figure 42:Logo Wamp Server ................................................................................................................ 80
10
Figure 43:Logo Paint .............................................................................................................................. 81
Figure 44:Logo de J2EE .......................................................................................................................... 81
Figure 45:Logo de Android Studio ......................................................................................................... 82
Figure 46:Implémentation de cas d’utilisation : Gérer réservation ...................................................... 83
Figure 47:Diagramme de composant de cas d’utilisation : Gérer événement ..................................... 83
Figure 48:Implémentation de cas d’utilisation : Gérer événement ...................................................... 84
Figure 49:Implémentation de cas d’utilisation : Gérer événement ...................................................... 85
Figure 50:Structure de l’application....................................................... 86
Figure 51:Interface d’accueil ................................................................................................................. 86
Figure 52:Interface comptes organisateur. ........................................................................................... 87
Figure 53:Interface validation événement ............................................................................................ 87
Figure 54:Interface ajouter événement ................................................................................................ 88
Figure 55:Interface de gestion des messages ....................................................................................... 88
Figure 56:Interface liste des réservations ............................................................................................. 89
Figure 57:Interface d’accueil ................................................................................................................. 89
Figure 58:Interface Se connecter : ........................................................................................................ 90
Figure 59:Interface Menu ...................................................................................................................... 90
Figure 60:Interface Liste événement .................................................................................................... 91
Figure 61:Interface rechercher événement .......................................................................................... 91
Figure 62:Interface liste réservations .................................................................................................... 92
Liste des tableaux :
Tableau 2:Tableaux des acteurs ............................................................................................................ 42
Tableau 3:Specification de cu : S’inscrire .............................................................................................. 42
Tableau 4:Scénario de cas «S’authentifier» .......................................................................................... 44
Tableau 5:Scénario de cas «Afficher liste événement» ........................................................................ 45
Tableau 6:Scénario de cas «Rechercher événement» .......................................................................... 45
Tableau 7:Scénario de cas «Ajouter aux favoris».................................................................................. 46
Tableau 8:Scénario de cas «Envoyer messages» .................................................................................. 46
Tableau 9:Scénario de cas « Ajouter événement» ................................................................................ 46
Tableau 10:Scénario de cas «Modifier événement.» ............................................................................ 47
Tableau 11:Scénario de cas «Supprimer événement» .......................................................................... 47
Tableau 12:Scénario de cas «Réserver événement»............................................................................. 50
Tableau 13:Scénario de cas «Consulter liste réservation».................................................................... 51
Tableau 14:Scénario de cas «Payer événement».................................................................................. 52
Tableau 15: Scénario de cas «Annuler réservation» ............................................................................. 52
Tableau 16:Description de diagramme de séquences de cas d’utilisation : Consulter liste événement.
............................................................................................................................................................... 66
Tableau 17:Description diagramme de séquences de cas d’utilisation : Ajouter événement ............. 69
Tableau 18:Description diagramme de séquences de cas d’utilisation : Modifier événement ........... 71
Tableau 19:Description diagramme de séquences de cas d’utilisation : Supprimer événement ........ 72
Tableau 20:Description diagramme de séquences de cas d’utilisation : Envoyer messages ............... 73
Tableau 21:Description diagramme de séquences de cas d’utilisation : Réserver événement ........... 75
Tableau 22:Tableau des caractéristiques matériel ............................................................................... 79
11
12
Chapitre 1 :
Cadre
générale du
projet
13
14
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 .
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.
15
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.
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.
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...
16
Nos collaborateurs sont pour la plupart des jeunes informaticiens
disciplinés en terme de relation client-service en éprouvant une énergie et
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.
2. Fiche technique :
Dénomination : GDev.
Nationalité : Tunisienne.
Siège social : Rue Docteur Moreau, Immeuble Averroès, 4éme étage, B21 –
4000 Sousse
Email : contact@gdev.tn
17
3. Oraganigramme :
Pour mieux assimiler notre sujet, il faut passer d’abord par les explications
suivantes :
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
18
ergonomiques, pour mieux faciliter la communication entre le client et
l’organisateur d’événement.
-Le client :
19
IV. Cahier de charge :
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 (les resto-lounge, les foires ,les maisons de théâtre etc…) utilisent
les réseaux sociaux pour publier leur événement comme : facebook,
Instagram ,
Teskerti est une application web qui permet la réservation et la vente des
tickets d’évènements.
20
Figure 3:Logo de l’application Teskerti
AlloCiné :
21
-Fonctionnalité d’application :
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.
22
b. Les méthodes numériques :
- Les événements publiés dans les pages ‘facebook’ ne sont pas garantie
à cent pour cent.
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.
‘Teskerti’ a lancé seulement une application mobile IOS pour les
organisateurs et non pas pour les clients.
23
Figure 6:Page d’acceuil de l’application Teskerti
-L’application AlloCiné est dédié seulement pour le cinéma aussi elle est utilisé seulement en France.
24
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.
-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.
4. Architecture envisagée :
26
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 :
27
V. Planning des tâches :
1. 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
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
28
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.
L’analyse et la conception des cas d’utilisation seront détaillées dans le
chapitre suivant.
29
Chapitre 2 :
Elaboration
30
Chapitre2 :Elaboration
I. 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.
31
Figure 10:Phase du Processus Unifié
o Elaboration :
32
- 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.
o Construction :
- 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.
33
o Analyse :
o Conception :
o Implémentation :
34
2. 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.
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.
35
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 13 diagrammes, chacun modélisant
sous un aspect particulier le système désiré.
3. Outil de modélisation
-Définitions :
36
Figure 13:Logo de Rationnal Rose
a. L'équipe de développement
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.
b. 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.
c. 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.
37
d. 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.
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.
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
38
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 :
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.
39
— 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 :
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) :
-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.
40
Figure 15:Diagramme de cas d’utilisation Global
41
Dans cette section, nous structurons les processus métier du système, permettant de donner
une vision globale du comportement fonctionnel du système.
-CU : S’inscrire
-CU : S’authentifier
42
Figure 16:Raffinement de cas d’utilisation : «S’authentifier».
43
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»
44
Scénario de bases 1-L’organisateur s’authentifie
2-cliue sur gestion événement puis liste événement
45
Tableau 6:Scénario de cas «Ajouter aux favoris»
46
Acteurs Organisateurs.
Post-Condition
Evénement modifié
Post-Condition
Evénement supprimé
47
IV. Modèle du domaine (Diagramme de Classe)
-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.
48
Figure 18:Diagramme modèle de domaine de CU «Gestion événements»
49
s
CU : Réserver événement.
50
Cu : Consulter liste réservation.
CU : Payer événement.
51
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
52
-Diagramme de séquence système : Gestion réservation
53
Figure 21:Diagramme se séquence système Gérer réservation : Consulter réservation
54
55
-Diagramme d’activité Gestion résérvation :Consulter liste
résérvations.
56
-Modèle de domaine de cas d’utilisation «Gestion réservation»
V. 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.
57
Chapitre3 :
Analyse et
conception
58
Chapitre3 : Analyse et conception
I. 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.
II. -Analyse
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
59
III. Analyse du cas d’utilisation « Gérer événement » :
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
60
2. Diagramme de classe d’analyse de cas d’utilisation Gérer
événement : Organisateur.
61
Figure 26:Diagramme de classe d’analyse de cas d’utilisation Gérer événement :Organisateur.
62
4. Diagramme de classe d’analyse Gérer événement : Administrateur.
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.
63
Figure 29:Diagramme de classe d’analyse de cas d’utilisation Gérer réservation : Client.
64
V. Conception
1. Diagrammes de séquences
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.
65
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.
Présentation des diagrammes de séquences :
Description :
66
b. Diagramme de séquence afficher un événement :
67
c. Diagramme de séquences de cas d’utilisation : Ajouter événement
Refus
9:Reponse requete
8:Execution de la requete
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.
68
4. Si l’événement est validé par
l’administrateur le système
enregistre l’événement au niveau de
la liste d’événement.
69
Figure 34:Diagramme de séquences de cas d’utilisation : Modifier événement.
Description :
Action de l’acteur Réaction du système
70
6. Redirection vers le profil du
client.
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.
71
Tableau 18:Description diagramme de séquences de cas d’utilisation : Supprimer événement
4:Données recupérées
10:Vericati on
12:Statue
13:Message envoyé
15:Satue
73
a. Diagramme de séquences de cas d’utilisation : Réserver événement.
1:Selectionner un événement
2:événement affiché
Alt
6:Demande envoyée
Echéc
9:Alerte d'échec
10:Msg'Stock epuisé'
Enchainement alternatif :
-Si le stock de ticket est épuisé le système affiche au client un message
‘Stock épuisé’.
75
c. Diagramme de séquence de cas d’utilisation annuler réservation :
76
VI. Diagramme de déploiement :
VII. Conclusion
A l’issu de ce chapitre, nous avons mis en place la partie d’analyse et de
conception de notre solution, en ayant recours aux différents diagrammes
d’UML.
Ainsi, nous pouvons passer à l’étape finale de notre projet, celle de la
réalisation, qui sera présentée dans le chapitre suivant avec la spécification
de notre choix technologique.
77
Chapitre 4 :
Réalisation et
mise en œuvre
78
Chapitre 4 : Réalisation et mise en œuvre
I. Introduction :
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.
1. 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.
a. Environnement matériel :
b. Environnement logiciel
79
Figure 42:Logo
Rationnal Rose
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.
80
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.
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
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 :
81
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
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 :
82
— Le processus de réutilisation soit facile.
III. Implémentation :
1. Implémentation de cas d’utilisation : Gérer réservation
83
2. Implémentation de cas d’utilisation : Gérer événement
84
b. Diagramme de composant cas d’utilisation : Gérer événement
85
Figure 52:Structure de l’application
Partie Administrateur :
Interface comptes organisateur.
86
L’administrateur consulte la liste des organisateurs.
Partie organisateur :
Interface ajouter événement :
87
1.
Figure 56:Interface ajouter événement
88
Figure 58:Interface liste des réservations
2. Partie mobile :
Partie clients :
Interface d’accueil :
Le client peut consulter, rechercher un événement sans être inscrit à
l’application.
Interface Se connecter :
89
A travers cette interface, chaque utilisateur doit saisir son email et son mot
de passe pour pouvoir accéder à l’application.
Interface Menu :
Cette interface permet d’accéder aux différentes fonctionnalités de
l’application
90
Figure 62:Interface Liste événement
91
Figure 64:Interface liste réservations
V. 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.
92
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.
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.
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.
93
Et Comme perspectives de ce travail.
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 .
94
Bibliographie :
Cours :
-Cours Méthodologies d’analyse et de conception - enseigné par Mr. Ahmed
Haddad, 2017.
Néographie :
- http://laurent-audibert.developpez.com/Cours-UML/?page=introduction-
modelisation-objet => Avril 2016
- https://simonhazout.wordpress.com/2010/12/31/logique-mvc-dans-le-
developpement-web/ => Avril 2016
- https://openclassrooms.com/courses/apprenez-a-programmer-en-
java/mieux-structurer-son-code-le-pattern-mvc => Avril 2016
-Méthodologies des systèmes d’informations-UML, cours du cycle
probatoire de
CNAM 2000-2001, de DI GALLO Frédéric
-www.gantt.com/fr/
-docs.phpmyadmin.net/fr/latest/intro.html
-openclassrooms.com/courses/creez-des-applications-pour-android
-https://openclassrooms.com/courses/creez-votre-application-web-avec-
java-ee
95