Introduction générale

L'écotourisme est l'un des secteurs qui connaît le plus fort taux de popularité dans le monde, à l'inverse
du tourisme de masse qui dégrade les milieux naturels, en intégrant une dimension éthique et éco-citoyenne.
Des guides de bonnes pratiques apparaissent, dont pour la prise en compte de la biodiversité dans les hôtels.
L'écotourisme, que l'on associe au tourisme vert, est l’une des formes du tourisme durable, plus centrée sur
la découverte de la nature (écosystèmes, mais aussi agro-systèmes et tourisme rural), voire d'écologie
urbaine (jardins écologiques, espaces verts écologiques, réserves naturelles urbaines et autres aspects de
l'écologie urbaine...)
Né il y a une trentaine d’années, le terme d’écotourisme est un néologisme composé de
l'abréviation eco- (écologie) et tourisme. Le mot serait apparu en 1983 avec l'architecte mexicain Héctor
Ceballos-Lascuráin.
La Société Internationale de l’Écotourisme (TIES) donne une définition en 1991 : « L’écotourisme est un
voyage responsable dans des environnements naturels où les ressources et le bien-être des populations sont
préservés ».
Ce mode de tourisme s'adapte aussi bien aux pays développés comme la France, où il est d'ailleurs défendu
par l'Association française d'écotourisme depuis 2005, ainsi que par d'autres associations nationales de
l'écotourisme en Europe et en Australie.
En Tunisie, l’écotourisme commence à se faire une place graduellement à côté du tourisme balnéaire qui
détient la palme en matière d’attractivité touristique mais qui a commencé à perdre de sa séduction ces
derniers temps. Il faut bien proposer un produit touristique alternatif dans un contexte mondial où tout le
monde parle, désormais, écolo.
En effet, la Tunisie avec ses parcs et réserves naturels constitue un terrain idoine pour le développement de
l’écotourisme. D’ailleurs, les régions du nord- ouest, du nord-est et du Cap Bon en l’occurrence disposent
d’un patrimoine écologique riche.
C’est dans ce cadre que se définit notre projet qui vise dans un premier temps à présenter les régions et
l’existence d’importantes potentialités et paysages naturels dans notre pays à travers un contenu multimédia
(photos, vidéos) , puis dans une seconde phase permettra également aux organisateurs de publier des
évènements (randonné, camping, festival) et aux participant d’y en participer.

Ce rapport comprend quatre parties et des annexes.

Le premier chapitre est une présentation générale du projet. Il comprendra une partie qui sera consacré à
l’analyse et le bilan de l’existant. La dernière partie de ce chapitre est entièrement consacré à la
méthodologie de conception, et montrera comment juger une bonne méthodologie de conception. Un
planning de travail, mettant en œuvre les différentes tâches en orges chronologiques, clôturera ce premier
chapitre.

Le deuxième chapitre sera consacré à l’analyse et la spécification des besoins, qui fournit une
compréhension des exigences, des concepts et du comportement de l’application.

Le troisième chapitre sera consacré à la conception objet. On présentera les diagrammes de séquences
détaillés ainsi que le diagramme de classe métier. On conclura cette partie par l’architecture logique
déployée.
Le dernier chapitre sera entièrement réservé à l’implémentation du projet, les interfaces homme/machine
seront un témoin de réalisation de l’application.

Un ensemble d’annexes donnant en ordre l’ensemble des procédures d’installation des différents outils de
réalisation de l’application.
 CHAPITRE
1 Étude préliminaire

Introduction
Ce chapitre introductif sera la pierre angulaire pour la compréhension de notre projet.
Après avoir présenté l’organisme d’accueil, nous passons à cerner quelques solutions Web
existantes, dont le but de fixer nos objectifs.
Nous dévoilons le processus de conception que nous préconisons pour la modélisation de
l’application.
Ce chapitre sera achevé par la planification de projet, mettant en œuvre l’ordre chronologique
de la réalisation des différentes étapes de ce projet.

Présentation de l’organisme d’accueil

La startup Tripylight est crée en 2020.

Adresse : Avenue Mohamed V, cité de la Culture 1001 Tunis, Tunisie

Nombre de Salarié : 10

Contact : Housssem Eddin Ben Smida - Directeur Générale

Contexte du projet

L'écotourisme est l'un des secteurs qui connaît le plus fort taux de popularité dans le monde, à
l'inverse du tourisme de masse qui dégrade les milieux naturels, en intégrant une
dimension éthique et éco-citoyenne. Des guides de bonnes pratiques apparaissent, dont pour la prise en
compte de la biodiversité dans les hôtels.
 Il rassemble toutes les formes de tourisme axées sur la nature et les cultures traditionnelles
qui règnent dans les zones naturelles. Il comporte une part d’éducation et d’interprétation de
l’environnement. L’écotourisme repose sur quatre principes :
— La valorisation de la préservation et de la protection de l’environnement et de la
biodiversité en minimisant les impacts
— La contribution équitable au développement économique local en améliorant les
opportunités d’emploi local,
— La prise en compte des besoins des communautés hôtes en recherchant une meilleure
compréhension de la nature, de la société et de la culture locale
— La promotion d’une expression touristique authentique et responsable. L’écotourisme (ou
agritourisme, tourisme vert, tourisme sportif…) est une forme de tourisme en expansion,
qui vise à réduire ou annuler les dégâts écologiques lors du voyage.
L’écotourisme se pratique dans la nature, en petits groupes au sein de petites structures, alors
que le tourisme durable est une notion plus large qui veut dire « développement durable du
tourisme», et qui concerne également les hôtels dans les villes ou les compagnies de transport par
exemple.

Dans ce contexte, notre mission consiste à concevoir et réaliser une plateforme d’écotourisme.

Analyse de la concurrence

L’analyse de la concurrence ou analyse concurrentielle consiste à identifier et comparer les

données relatives aux concurrents d’une entreprise, telles que leur position sur le marché, les
actions de communication déployées, afin d’en dégager les points forts et les points faibles.
Dans cette optique, nous décrivons trois sites web concurrents à notre application.

Solutions concurrentes

— Babel Voyages:

Babel Voyages, c’est une SAS depuis janvier 2016, qui a vu le jour sous la forme d’une
association en octobre 2011 avec pour objectif de sensibiliser le plus grand nombre au
voyage engagé et aux valeurs qui en découlent : altruisme, ouverture d’esprit, respect des
cultures, égards envers notre planète et ses écosystèmes… [2].
 Figure 1.1 – Site officielle de Babel Voyages

— Bookingdifferent.com
Bookdifferent.com a été fondé en 2012 aux Pays-Bas, probablement l'un des pays les plus
verts du monde! Après tout le temps que nous passons à vélo, nous pensons qu'être vert
nous tient à cœur et nous voulons que cela se reflète également dans les voyages.

Nous croyons que voyager est une chose merveilleuse et nous permet vraiment d'apprécier
la belle planète que nous avons, mais nous pensons aussi que l'impact du tourisme
aujourd'hui est un peu effrayant. Nous ne voulons pas voir davantage d’îles fermées en
raison de la pollution et de la surpopulation, mais nous voulons plutôt aider les gens à
choisir une meilleure façon de voyager. Pour nous, cela commence par choisir des
hébergements qui font leur part pour prendre soin de l'environnement, de leurs habitants et
des communautés dans lesquelles ils se trouvent [3].
 FIGURE 1.2 – Site officiel de bookdifferent.com

— Tunisie.co

TUNISIE.co Tunisie.co est le portail touristique tunisien fournissant un guide pratique et

interactif pour renseigner à portée de click les touristes et les Tunisiens sur la Tunisie

TUNISIE.co se propose d’apporter du contenu à forte valeur ajoutée dans quatre thèmes à
savoir : Le tourisme, l’Artisanat, la Culture et la Cuisine.

TUNISIE.co est édité par la société TUNISIE COMPAGNIE [4].

 FIGURE 1.2 – Site officiel de tunisie.co
Bilan et synthèse

Suite à l’analyse concurrentielle entre les trois solutions décrites ci-dessus, nous dressons le
tableau suivant mettant en œuvre une comparaison entre leurs différentes fonctionnalités.

TABLE 1.1 – Synthèse au tour des solutions existantes

fonctionnalit
Babel Bookdiffere Tunisie-co
é
nt
solution
Inscription des Formulaire Formulaire Formulaire
utilisateurs
Nombre de réservation limité limité illimité
Mode de paiement Paiement de main en Carte Carte
main bancaire bancaire
galerie images moyenne moyenne moyenne
galerie vidéos faible absent absent

Résultats attendus

Notre sujet consiste à concevoir et développer une plateforme, qui rassemble tous les acteurs de
l’écotourisme ( Les organisateurs des évènements, les participants, les vendeurs de matériels, …) et qui
vise à promouvoir le tourisme interne dans les régions internes de la Tunisie, en proposant un
écosystème numérique, mutualisé et ouvert, permettant de présenter ces zones à travers un contenu
multimédia divers (photos, vidéos,...etc.).
 Ce portail permettra également aux organisateurs de publier des évènements (randonnés, camping,
festivals,...etc.) et aux participant d’y en participer. Tous les utilisateurs peuvent aussi ajouter des
publications (image, vidéos,...etc.) à leurs profils et publier des annonces de vente ou location de
matériel et des équipements de camping.

Méthodologie de gestion de projet

Choix de la méthodologie

Le choix entre une méthode et une autre dépend de la nature du projet et de sa taille, afin de
minimiser le risque lié au choix du processus de développement. Pour cette raison, nous avons
choisi de dresser un tableau comparatif entre le modèle en cascade, en V et Méthode agile (MA).
Le tableau (voir Tableau 1.1) regroupe l’ensemble des points positifs et négatifs assiégé suite à
l’analyse des trois solutions concurrentes.
 TABLE 1.2 – Tableau comparatif entre les différents cycles de vie d’un logiciel

Cycle de vie Avantages Inconvénients

—Tous les besoins doivent être
—Facile à comprendre et à bien spécifiés au départ.
utiliser.
—Donne une fausse impression
—Adapté pour une équipe de l’avancée des travaux.
Cycle en inexpé- rimentée.
cascade —Pas d’interaction entre
—Les limites de chaque étape les phases de
sont visibles. développement. ’inté- gration
—La définition des besoins est n’a lieu qu’à la fin du cycle.
non-évolutive.

—Facile à utiliser.
—Les tests sont effectués à —Le processus n’est pas itératif.
chaque étape. —Une mauvaise prise en
Cycle en V —Le contrôle se fait progressive- compte des changements de
ment à chaque étape. la spécifi- cation des
besoins.
—Les phases de validation sont
prises en main très tôt dans le —Ne contient pas les activités
processus de développement. d’analyses de risques.

—Repose sur des cycles itératifs

rapides de développement.
—Recommande un déroulement —Ne couvre pas les phase en
par itérations courtes. amont et en aval de
Cycle Agile développe- ment.
—Facile à mettre en oeuvre.
—garanti une large place aux as- —Elude 1 la phase d’analyse.
pects techniques : prototypes,
régles de développement, tests
etc .

Lorsqu’il s’agit d’un projet où les données ne sont pas ajustées au début, ou les besoins ne
sont pas complets dès le départ ou qu’ils peuvent se développer en cours de travail comme dans
notre cas, il est indispensable d’orienter vers une méthode itérative et orientées prototypes.
Parmi les méthodes itératives, nous pouvons distinguer les MA qu’ils sont largement utiliser à
l’époque actuelle.
Une MA vise à réduire le cycle de vie du logiciel (donc accélérer son développement) en
1. Éviter.
développant une version minimale, puis en intégrant les fonctionnalités par un processus itératif
basé sur une écoute client et des tests tout au long du cycle de développement [5]
En fait, il ne s’agit pas de choisir la meilleure méthode parmi les différentes MA existantes,
mais, il s’agit plutôt de sélectionner la méthode la plus convenable.
D’où, la nature de notre projet est évolutive et les besoins n’ont pas encore été totalement
identifiés. Dans ce but, nous a orientés vers une méthode de type AGILE et plus particulièrement
l’Unified Process (UP).

Présentation de la méthodologie UP

◆ Définition UP est un processus de développement logiciel « itératif et incrémental, centré

sur l’architecture, conduit par les cas d’utilisation et piloté par les risques » :
* Itératif et incrémental : Le projet est découpé en itérations de courte durée qui aident
à mieux suivre l’avancement.
À la fin de chaque itération, une partie exécutable du système final est produite.
* Centré sur l’architecture : tout système complexe doit être décomposé en parties
modulaires afin de garantir une maintenance et une évolution facilitées. Cette
architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et
pas seulement documentée en texte.
* Piloté par les risques : Les risques majeurs du projet doivent être identifiés au plus
tôt, mais surtout le plus rapidement possible. Les mesures à prendre dans ce cadre
déterminent l’ordre des itérations.
* Conduit par les cas d’utilisation : Le projet est mené en tenant compte des besoins et
des exigences des utilisateurs. Les cas d’utilisation du futur système sont identifiés,
décrits avec précision et priorités. Référence : [5]
◆ La structure logique du Processus : Contrairement au processus en cascade, le UP ne
considère pas que les disciplines soient purement séquentielles. En fait, une itération
comporte une certaine quantité de travail dans la plupart des disciplines.
La figure illustrée (voir Figure 1-5) montre la structure logique du ce processus.
 FIGURE 1.4 – La structure logique du Processus Unifié

Démarche à suivre

Le processus que nous avons l’intention de suivre pour le développement de notre l’application
est basé sur UP, mais dans un cadre plus général.
Notamment, ce processus est présenté et appliqué tout au long de ce rapport est :
 Conduit par les cas d’utilisation,

 Relativement léger et restreint, mais sans négliger les activités de modélisation en analyse et
conception,
 fondé sur l’utilisation d’un sous-ensemble nécessaire et suffisant des diagrammes UML
Unified Modeling Language (UML).

Planification de projet
Le planning suivant reconstitue le déroulement des tâches effectuées depuis le lancement du
projet.

FIGURE 1.5 – Planning prévisionnel

Conclusion
Ce chapitre a été consacré essentiellement à la compréhension du contexte du projet.
Nous passons maintenant à poser la question : Qui Fait Quoi dans le système ? , objet du deuxième
chapitre Analyse et spécification des besoins.
CHAPITRE
2 Analyse et spécification des besoins

Introduction
Ce chapitre sera organisé en trois volets importants.
Tout d’abord, nous détaillons dans un premier temps les exigences fonctionnelles de
l’application, à savoir les fonctionnalités requises par l’utilisateur. Nous ajoutons ensuite des
exigences non fonctionnelles.
Par la suite, nous détaillons les différentes étapes de la démarche que nous allons adopter afin
d’aboutir au modèle des cas d’utilisation.
Finalement, nous allons décrire de façon détaillée les cas d’utilisation par : des fiche-type
pour chacun et des représentations graphiques UML très utile : le diagramme de séquence.

L’application coté utilisateur

L’objectif est de collecter, analyser et définir les besoins de haut niveau et les caractéristiques
du futur site Web. On se focalise sur les fonctionnalités requises par les utilisateurs, et sur la
raison d’être de ces exigences. Nous rajoutons les besoins non fonctionnelles nécessaires au bon
fonctionnement du système.
Le détail de la description de ces besoins se trouve dans la partie Spécification détaillée des
cas d’utilisation

Exigence fonctionnelles

La solution devra regrouper toutes les fonctionnalités nécessaires de recherche, de découverte

détaillée, de sélection et de réservation d’évènement.
 Recherche : La première étape pour l’utilisateur consiste à trouver le plus rapidement possible
un évènement ou un produit recherché dans l’ensemble du catalogue. Les références de cet
évènement (ou produit) pouvant être plus ou moins précises, il faut lui fournir plusieurs méthodes
de recherche différentes.
L’utilisateur pourra ainsi sélectionner un critère (destination, organisateur, type, etc.). Les
résultats de la recherche seront disponibles sur une page particulière, et devront pouvoir être
facilement parcourus et reclassés.
Découverte : Chaque évènement publié sur le site sera présenté en détail sur sa propre page.
On y trouvera en particulier :
* une image (pour la majorité des évènements),

* son prix et sa disponibilité,

De plus, on trouvera les fiches détailles de chaque participants inscris dans un tel évènement.
Réservation et paiement : Le participant peut accéder au formulaire de réservation, dans
lequel il saisit ses coordonnées et les informations nécessaires au paiement.
Pour garantir la sécurisation et la confidentialité des échanges, il est impératif que l’envoi des
données se fasse de manière cryptée.

Exigence non fonctionnelles

Exigences de qualité

Pour attirer un utilisateur sur notre site et ensuite le fidéliser, il est important de répondre aux
exigences de qualité suivantes :
Ergonomie sobre et efficace : Réserver un évènement sur le Web ne doit pas prendre
beaucoup de temps ou demander une maîtrise de mathématiques ! La mise en page du
site facilitera au maximum la démarche à l’aide d’une présentation claire et intuitive. Les
sites trop riches et trop complexes n’incitent pas aux réservations, car ils demandent un
effort intellectuel important et non souhaité.
 — Formulaire de réservation simple : Très souvent, l’utilisateur cale au moment de
réservation, car la conception et la présentation du formulaire est assez complexe.
Donc il faut adopter des styles particulièrement soignées pour ne pas rebuter les utilisateurs
de notre site.
— Sécurité : Se doter d’un système sécurisé est une chose primordiale dans la réalisation de
notre site.
En effet, vu la pertinence des informations (numéro carte bancaire et mot de passe)
circulant, il s’avère judicieux de garantir la sécurité de notre site.

Exigences de performance

—Le système doit pouvoir gérer les comptes de plus de 10 000 clients,
—Le site web doit supporter plus de 1000 connexions simultanées,
—Le catalogue d’évènement doit pouvoir comprendre plus de 10 000 titres,
—Aucune recherche ne doit prendre plus de 5 secondes.

Spécification des exigences d’après les cas d’utilisation

L’expression préliminaire des besoins donne lieu à une modélisation par les cas d’utilisation
qui va aboutir à la construction d’un modèle des as d’utilisation qui :
—Comprend une collection des cas d’utilisation,

—Caractérise le comportement de l’ensemble du système et ses acteurs (dans leur interaction).

Ainsi, la démarche que nous allons adopter afin d’aboutir ce modèle est schématisé par la

figure
2-1
FIGURE 2.1 – Synoptique de la démarche de construction du modèle de cas d’utilisation
 Identification des acteurs

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. [6]
Durant notre analyse, nous avons identifié les acteurs suivants :
—Administrateur : Rôle des acteurs qui sont en charge du bon fonctionnement et de la
maintenance du site,
—Organisateur : Rôle des acteurs qui sont responsables du contenu rédactionnel du site
(évènements, annonces et publications),
—Internaute : La personne qui demande des prestations auprès du site et qui est responsables
de contenu rédactionnel aussi (publications, et annonces).
Nous allons également prendre en compte le système informatique, à savoir le système
Paiement-Sécurisé qui assure le paiement de toutes les réservations effectuées.

Identification des cas d’utilisation

Lors de notre analyse des besoins, nous avons pu identifier pour chaque acteur les cas
d’utilisation importants que nous montrerons ci-dessous et nous les modélisons par la suite grâce
au modèle des cas d’utilisation.
Débutant par l’acteur le plus important dans notre application : l’administrateur, ces cas
d’utilisation principaux ont été bien mis en évidence par l’expression de besoins préliminaire, à
savoir :
—Maintenir le portail,
—Mise à jour des comptes utilisateurs.
—Mise à jour des évènements : Recherche, consultation, suppression, publication.
—Mise à jour des articles.
—Mise à jour des annonces (vente et location de matériels).

On obtient un diagramme préliminaire (voir figure 2-2) en représentant les cas d’utilisation reliés
par des associations à leur acteur.
 FIGURE 2.2 – Cas d’utilisation principaux de l’administrateur

Ensuite, l’intention métier selon lequel l’organisateur utilise le système est identifiée comme suit :
—Mise à jour des évènements : Création, modification, Recherche, consultation et suppression,
—Mise à jour des annonces: Création, modification, Recherche, consultation et suppression,
—Mise à jour de profil: Ajouter des publications, Ajouter et modifier ces cordonnés
, Ces cas d’utilisation sont illustrés par un diagramme préliminaire (voir figure 2-3)

FIGURE 2.3 – Cas d’utilisation principaux de l’organisateur

 Finalement, les cas d’utilisation de l’internaute seront comme suit :
—Chercher un évènement,
—Consulter les évènements,
—Réserver un évènement, qui fait intervenir le système « PaimentSécurisé »
—Évaluer et commenter un évènement.
—Mise à jour des annonces: Création, modification, Recherche, consultation et suppression,
—Mise à jour de profil: Ajouter des publications, Ajouter et modifier ces cordonnés
Ces cas d’utilisation sont illustrés par un diagramme préliminaire (voir figure 2-4)

FIGURE 2.4 – Cas d’utilisation principaux de l’internaute

Structuration en packages

Dans le but de l’organisation générale et la décomposition du système en des parties plus

facilement observables, nous allons regrouper les cas d’utilisation en des ensembles fonctionnels
cohérents.
Pour achever ce travail, nous utilisons le concept général d’UML, le package.
Les acteurs ont été regroupés dans trois packages séparés. L’organisation générale du modèle
des cas d’utilisation sera schématisée par la figure suivante (voir figure 2-5).
 FIGURE 2.5 – Organisation des cas d’utilisation et des acteurs en packages

Affinement du modèle de cas d’utilisation

À tout moment, le visiteur peut choisir de créer un compte, afin de devenir participant.
Le participant a la possibilité de mettre à jour son profil :
- Les informations le concernant (nom, prénom, adresse électronique, etc.) stockées par le
site web.
-Les publications
Aussi l’authentification de l’internaute lui donne la possibilité de publier et consulter les
annonces de vente et location et la possibilité de faire une recherche d’un évènement qui
peut donner lieu à sa consultation et sa réservation.
Enfin, l’authentification du participant est nécessaire pour la recherche, la consultation et la
réservation d’un évènement, l’ajout et la consultation des annonces, ainsi pour la gestion de
son propre profil.
Nous mentionnons également l’importance du système externe de Paiement sécurisé,
nécessaire au moment de la réservation en ligne.
Le diagramme devient alors celui de la figure 2.6.

FIGURE 2.6 – Relations entre cas d’utilisation des internautes

—Relations entre cas d’utilisation des organisateurs
Les différentes possibilités de Mise à jour des évènements seront modélisées plus finement
par une relation de généralisation telle que l’ajout, la suppression et la modification d’un
événement (CRUD).

FIGURE 2.7 – Relations entre cas d’utilisation des organisateurs

—Relations entre cas d’utilisation du l’administrateur

Pour ce diagramme, nous pouvons relier les cas d’utilisation de l’administrateur par des
relations d’inclusion : la mise à jour d’un évènement nécessite absolument une recherche
de celui-ci.
 FIGURE 2.8 – Relations entre cas d’utilisation du l’administrateur

Spécification détaillée des exigences

Nous allons maintenant décrire de façon détaillée les cas d’utilisation que nous trouvons
importants grâce à une fiche-type pour chaque cas d’utilisation. Nous compléterons cette
description textuelle par une représentation graphique UML très utile : le diagramme de séquence
« système ».
Description textuelle des cas d’utilisation

—S’authentifier

TABLE 2.1 – Description textuelle de S’authentifier

Nom S’authentifier
Acteur Principal Administrateur, Organisateur et internaute
Objectif Accéder au fonctionnalités du site.
Pré-conditions L’acteur existe dans la base de données
1.L’acteur demande le formulaire de connexion
2.Le système affiche le formulaire d’identification
Scénario 3.L’acteur remplit le formulaire avec l’ensemble des
nominal informa- tions nécessaires à son identification
4.Le système vérifie les informations saisies et le redirige
vers son espace approprié.

Scénario 1.L’acteur saisit des informations incohérentes.

alternatif 2.Le système renvoie un message d’erreur.

—Créer un évènement

TABLE 2.2 – Description textuelle de Créer un évènement

Nom Créer un évènement

Acteur Principal Organisateur
Objectif Créer un nouveau évènement
Pré-conditions Organisateur authentifié
1.l’organisateur demande le formulaire d’ajout d’un
nouveau évènement
2.le système affiche le formulaire demandé
Scénario
nominal 3.l’organisateur saisit les informations relatives à chaque
évè- nement
4.le système vérifie les données et affiche le résultat de la
tache.

Scénario 1.L’organisateur saisit des informations. incohérentes

alternatif 2.Le système renvoie un message d’erreur.
 —Chercher un évènement

TABLE 2.3 – Description textuelle de Chercher un évènement

Nom Chercher un évènement

Acteur Principal Participant
Objectif Recherche d’un événement
Pré-conditions Liste des évènements disponible
1.l’acteur affiche l’onglet de recherche et selectionne un
critère.
Scénario
2.le système renvoie une fiche détaillée de l’évènement
nominal choi- sie.
3.l’acteur consulte la page affiché

Scénario Néant
alternatif

—Réserver un évènement

TABLE 2.4 – Description textuelle de Réserver un évènement

Nom Réserver un évènement

Acteur Principal Participant
Objectif Participer à un évènement
Pré-conditions participant authentifié
1.le participant cherche un évènement
2.le système affiche l’évènement sélectionné.
Scénario 3.le participant demande la participation
nominal 4.le système renvoie la page du panier.
5.le parcicipant choisie le nombre de places à réserver

Scénario 1. le nombre de places disponibles est égale à 0

alternatif

Diagrammes de séquence système

Dans cette section, nous décrivons le comportement du système par des Diagrammes de
séquence système (DSS) où ce dernier est vu comme une boîte noire.
Le système est donc vu de l’extérieur par les acteurs sans préjuger de comment il sera réalisé.
La boîte noire décrite seulement en phase de conception.
 Le fonctionnement d’un cas d’utilisation est notamment décrit sous la forme d’une séquence
de messages échangés entre les acteurs et le système Dans ce qui suit, nous présentons les DSS
des cas d’utilisation importants en tenant compte des règles suivantes :
—La notation avec la flèche pleine représente des messages synchrones, c’est-à-dire des appels
où l’émetteur se bloque en attente de la réponse. Dans le cas contraire, on parle de message
asynchrone, et on le représente par une flèche évidée.
—la flèche pointillée partant du système à l’étude représente un retour au sens UML. Cela
signifie que le message en question est le résultat direct du message précédent par une
relation forte de cause à effet. En général, on ne fait figurer que les retours intéressants et
non triviaux.
—la notation des bandes blanches le long des lignes verticales (appelées lignes de vie)
représente l’activation de l’élément en question. Le système informatique n’est actif que
lorsqu’il est sollicité par un acteur, alors que les acteurs sont a priori toujours actifs. Cette
notation est optionnelle, mais aide à mieux comprendre la flèche pointillée du message de
retour. Toutefois, dans un souci de simplicité, nous ne l’utiliserons pas pour les autres DSS.
—La flèche qui reboucle sur le système (enregistrement Commande) permet de représenter
graphiquement un comportement interne majeur sur lequel on veut mettre l’accent. Il ne
faut cependant pas en abuser car ce n’est pas l’objectif premier de ce type de diagramme dit
d’interaction.

— S’authentifier : Rappelons que pour passer à une authentification, le membre doit demander
la page de connexion. Ce dernier saisie ses paramètres d’identification et par la suite il sera
dirigé vers son espace approprié.
La pré-condition du cas d’utilisation peut également être matérialisée graphiquement grâce
au symbole d’état sur la ligne de vie.
Il est même possible de représenter également le cas d’erreur où le système ne trouve pas
des membres correspondant à la requête. Il suffit d’ajouter un cadre alt, (pour indiquer que
les messages de succès ou d’erreur). Le diagramme devient alors comme sur la figure 2.9.
 FIGURE 2.9 – DSS de s’authentifier

—Créer un évènement

FIGURE 2.10 – DSS de Créer un évènement

—Chercher un évènement

FIGURE 2.11 – DSS de chercher un évènement

—Réserver un évènement
FIGURE 2.12 – DSS de réserver un évènement
 Classement des cas d’utilisation

Après tout ce travail d’identification des cas d’utilisation, nous pouvons maintenant les
classifier en tenant compte des deux facteurs suivants :
La priorité fonctionnelle,
Le risque technique, estimé par le chef de projet.
Le tableau suivant illustre cette démarche.
TABLE 2.5 – Classement des cas d’utilisation

Cas d’utilisation Priorit Risq Itération

é ue #
S’authentifier Haute Haut 1
Créer un compte Haute Haut 5
Créer un évènement Haut moye 2
n
Gérer son compte Moyen Moy 7
ne en
Consulter un Moyen Moy 6
évènement ne en
Chercher un Haute Haut 3
évènement
Évaluer et commenter Bas Bas 8
Réserver un Haute Haut 4
événement

Au niveau des risques techniques, le chef de projet a classé au plus haut la création des
évènements, à cause des problèmes liés à leur disponibilité régulière dans la base de données. De
même, le processus d’authentification est noté avec un risque haut à cause des problèmes de
confidentialité de données.

Conclusion
Comment recueillir tous les besoins des acteurs du système d’information, et rien que leurs
besoins réels ? Comment se mettre d’accord sur la spécification des exigences ? Comment
aboutir à un modèle de cas d’utilisation ?, toutes ses questions ont été annoncé dans ce chapitre.
La question qui se pose maintenant Comment le système fonctionne t-il ?, objet du troisième
chapitre Conception détaillé
CHAPITRE
3
Conception détaillée

Introduction
Tous les besoins sont établis, nous consacrons ce chapitre à la conception objet en entamant
les diagrammes de séquence détaillés et les diagrammes de classe métier.
Ce chapitre sera clôturé par l’architecture logique déployée.

La conception objet préliminaire

Nous présentons dans cette partie les diagrammes de séquence détaillés ainsi que le
diagramme de classe métier.

Diagrammes de séquence détaillés

Par rapport aux diagrammes de séquences système de la section précédente, nous remplaçons
ici le système, vu comme une boîte noire, par un ensemble d’objets en collaboration (figure 3-1).
Ces objets sont des instances des trois types de classes d’analyse, à savoir des dialogues, des
contrôles et des entités.

FIGURE 3.1 – Migration d’un DSS vers un diagramme de séquence détaillé

—Séquence détaillé de S’authentifier

FIGURE 3.2 – Séquence détaillé de S’authentifier

—Séquence détaillé de Créer un évènement

FIGURE 3.3 – Séquence détaillé de Créer un évènement

—Séquence détaillé de Chercher un évènement

FIGURE 3.4 – Séquence détaillé de Chercher un évènement

—Séquence détaillé de Réserver un évènement

FIGURE 3.5 – Séquence détaillé de Réserver un évènement
 Diagramme de classes métier
Le diagramme de classe constitue l'un des pivots essentiels de la modélisation avec UML. En effet, ce
diagramme permet de donner la représentation statique du système à développer. Cette représentation est
centrée sur les concepts de classe et d'association. Chaque classe se décrit par les données et les traitements
dont elle est responsable pour elle-même et vis-à-vis des autres classes. Les traitements sont matérialisés par
des opérations. Le détail des traitements n'est pas représenté directement dans le diagramme de classe.

FIGURE 3.6 – Diagramme de classes métier

Conception objet détaillée

Dans cette partie, nous présentons l’architecture de l’application qui consiste à diviser une
application en différents modules constituent autant de couches.

 Le cœur de l’application (modèle métier) : modèle objet et traitements propres au

domaine de l’application.
 Les données persistantes (couche d’accès aux données) : Couche basse faisant le lien entre le
modèle métier et stockage physique des données (système de fichier, SGBD, etc.).
 L’interface utilisateur (couche de présentation) : Interface permettant à l’utilisateur
d’agir sur le modèle métier (interface graphique, interface web, etc.).
Cette architecture est composée de :
 Express Web Framework comme servlet container.
 Le serveur de base de données MongoDB.
 Le client comme navigateur web.
Comme l’indique la figure 3.7, le client envoie une requête au serveur « Express web
Framework », qui va la transférer au serveur de base de données (MongoDB) qui à son tour
renvoi le résultat de la requête container. Le serveur interrogé va récupérer et modifier les
données et enfin afficher le résultat de l’opération au client.

FIGURE 3.7 – Architecture logique

Conclusion
À travers ce chapitre, nous avons mis en œuvre la faisabilité de notre application. En premier
lieu, nous avons présenté la conception préliminaire de notre application à travers la présentation
du diagramme de séquence et classe métier. Ensuite, nous avons présenté une vue sur
l’architecture logique, notamment le patron MVC adopté.
Après avoir entamé notre étude conceptuelle, nous allons voir en détail, dans le prochain
chapitre phase de développement, une description des étapes et des outils nécessaires à la
réalisation du projet.
CHAPITRE
4 Phase de développement

Introduction
L’objectif de ce chapitre est de présenter le travail d’architecture et de mise en place de
différentes phases de notre projet.
Nous détaillons aussi l’environnement de travail matériel et logiciel utilisé pour la réalisation
des solutions proposés et nous présentons les configurations de notre solutions adaptée avec
quelques aperçus d’écran montrant les différentes étapes de mise en place de notre solution.

Environnement de travail
Dans cette partie, nous présentons brièvement les technologies et les logiciels employés
pendant notre projet.

Environnement matériel

Pour le développement de notre application, nous avons utilisé un ordinateur Dell avec les
caractéristiques suivantes :
Processeur : Intel(R) Core(TM) i5-8250U CPU @1.60GHz 1.80 GHz
RAM : 8Go

Environnement logiciel

Concernant l’environnement logiciel, nous allons utiliser :

Système d’exploitation : Windows 10
Outils de développement : Visual Studio Code

La rédaction du rapport : Microsoft Word

Conception UML : PaceStar UML Diagrammer
Outils de travail

Visual Studio Code : est un éditeur de code extensible développé par Microsoft .

Les fonctionnalités incluent la prise en charge du débogage, la mise en évidence de la

syntaxe, la complétion intelligente du code, les snippets, la refactorisation du code
et Git intégré. Les utilisateurs peuvent modifier le thème, les raccourcis clavier, les
préférences et installer des extensions qui ajoutent des fonctionnalités supplémentaires.

Le code source de Visual Studio Code provient du projet logiciel libre et open
source VSCode de Microsoft publié sous la licence MIT permissive, mais les binaires
compilés sont des logiciels gratuits pour toute utilisation.

Dans le Stack Overflow 2019 Developer Survey, Visual Studio Code a été classé comme
l'outil d'environnement de développement le plus populaire, avec 50,7% des 87317
répondants déclarant l'utiliser.

React JS : est une bibliothèque JavaScript libre développée par Facebook depuis 2013. Le but

principal de cette bibliothèque est de faciliter la création d'application web monopage, via
la création de composants dépendant d'un état et générant une page (ou portion) HTML à
chaque changement d'état.

React est une bibliothèque qui ne gère que l'interface de l'application, considéré comme la
vue dans le modèle MVC. Elle peut ainsi être utilisée avec une autre bibliothèque ou
un framework MVC comme AngularJS. La bibliothèque se démarque de ses concurrents
par sa flexibilité et ses performances, en travaillant avec un DOM virtuel et en ne mettant à
jour le rendu dans le navigateur qu'en cas de nécessité

Node.js : est une plateforme logicielle libre en JavaScript orientée vers les

applications réseau événementielles hautement concurrentes qui doivent pouvoir monter en
charge.

Elle utilise la machine virtuelle V8, la librairie libuv pour sa boucle d'évènements, et

implémente sous licence MIT les spécifications CommonJS.

Parmi les modules natifs de Node.js, on retrouve http qui permet le développement
de serveur HTTP. Il est donc possible de se passer de serveurs web tels
que Nginx ou Apache lors du déploiement de sites et d'applications web développés avec
Node.js.
 Concrètement, Node.js est un environnement bas niveau permettant l’exécution
de JavaScript côté serveur.

Express.js : est un framework pour construire des applications web basées sur Node.js2. C'est

de fait le framework standard pour le développement de serveur en Node.js3. L'auteur
original, TJ Holowaychuck, le décrit comme un serveur inspiré de Sinatra4 dans le sens
qu'il est relativement minimaliste tout en permettant d'étendre ses fonctionnalités via des
plugins.

MongoDB : (de l'anglais humongous qui peut être traduit par « énorme ») est un système

de gestion de base de données orienté documents, répartissable sur un nombre quelconque
d'ordinateurs et ne nécessitant pas de schéma prédéfini des données. Il est écrit en C++. Le
serveur et les outils sont distribués sous licence SSPL, les pilotes sous licence Apache et la
documentation sous licence Creative Commons5. Il fait partie de la mouvance NoSQL.
 Implémentation

Étapes de réalisation

Cette partie sera réalisée dans la partie annexe Prise en main de

l’environnement de développement

Interface homme machine