REPUBLIQUE DEMOCRATIQUE DU CONGO

ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

« Analyse métier et conception par la méthode up7 d’une application web de

réservation des billets de bus ».

MUPAPA ABOCK Rodine

Mémoire soumis pour l’obtention du diplôme de Licence en Sciences Informatiques à

l’Université Protestante de Lubumbashi

Promotion : BAC3 IG
Matricule : 2020022130

Octobre 2023
 REPUBLIQUE DEMOCRATIQUE DU CONGO
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

« Analyse métier et conception par la méthode up7 d’une application web de

réservation des billets de bus ».

MUPAPA ABOCK Rodine

Mémoire soumis pour l’obtention du diplôme de Licence en Sciences Informatiques à

l’Université Protestante de Lubumbashi

Directeur : Dr, msc, phd Jean-Marie KANDA

Co-directeur : Assistant José MALABA

Promotion : BAC3 IG
Matricule : 2020022130

Octobre 2023
 III
DEDICACE

A Mamy Nkulu, Myma ça y ai, on l’a fait.

A toute la communauté scientifique et adeptes des nouvelles technologies de
l’information et de la communication.

Je dédie ce travail.

RODINE MUPAPA ABOCK

 P a g e | IV
REMERCIEMENT

Ce travail est le résultat de multiples études et efforts scientifiques et donc des couts de
mains nous étaient vraiment indispensable. Cependant, nous exprimons notre gratitude et nos
remerciements à notre Dieu, le Maître du temps et des circonstances, pour sa grâce et sa
fidélité envers nous.

Nos remerciements s’adressent aussi au Doyen de la faculté des sciences

informatiques Daniel Katual ainsi qu’à Mon directeur Dr, Msc, phd, le professeur Jean- Marie
Kanda.

Merci à mon codirecteur l’assistant Jose Malaba qui a accepté de diriger ce travail
malgré ses multiples occupations.

Merci également au collège des assistants de la faculté des sciences

informatiques en particulier au chef des travaux Ruphin nyami, l’assistant Daniel
mbaya, pour leurs encadrements et leurs conseils.

A mes très chers parent Rodin Mupapa et Mamy Nkulu, aucune phrase ne pourrait bien
n’exprimer ma reconnaissance envers vous, merci pour vos sacrifices, matériels, spirituels,
morals et financiers durant tout mon cursus académique ainsi que pour la confiance faite en
ma faveur.

A tous mes frères et sœurs : Christelle Mupapa, Rommy Mupapa, Doee Mupapa et
Mirck Mupapa ; pour vos encouragements, votre disponibilité ainsi que votre amour.

A mes amis : Sylvain Kabyombwa, Chaty Ilunga, Philomène Kapend, Elicha Frecher,
Elijah Honour. Vous me remplissez toujours de joie

À vous ma seconde famille, Prince Kiwele, Claudine Kabuya, Dorcas Ngoy, Gregory
Kayembe ; merci mes amis pour tout

Et à tous ceux qui nous ont contribués de loin ou de près participer à la rédaction de ce
Travail.
 Page|V

TABLE DES MATIERES

INTRODUCTION GENERALE ..................................................................................................................... 1

1.1. Concept central de la recherche ........................................................................................... 1
1.1.1. Concept 1 : E- commerce .............................................................................................. 1
1.1.2. Concept 2 : réservation en ligne ................................................................................... 1
1.1.3. Concept 3 : Gestion numérique de programme de voyage ........................................ 2
1.2. Enoncée du problème et questions de la recherche ............................................................ 2
1.3. Etat de la question............................................................................................................... 3
1.4. Motivation de la recherche et objectifs ................................................................................ 3
1.4.1. Motivation de la recherche ........................................................................................... 3
1.4.2. Objectifs de la recherche............................................................................................... 4
1.5. Méthodologie de la recherche ............................................................................................... 4
CHAPITRE I. REVUE DE LA LITTERATURE ................................................................................................. 8
1.0. Introduction .............................................................................................................................. 8
1.1. Théorie sur les technologies web ............................................................................................... 8
1.1.1. Composants de l’architecture du web ................................................................................... 8
b) Les web dynamiques ............................................................................................................... 9
1.1.2. Types des architectures du web.............................................................................................. 9
I.1.5. Notion sur les développements web ..................................................................................... 12
I.2. Théorie sur les bases de données ............................................................................................. 12
II.2.3. Système de gestion des bases de données ................................... Erreur ! Signet non défini.
Conclusion partielle......................................................................................................................... 13
CHAPITRE II : ANALYSE METIER DU PROCESSUS DE RESERVATION DES BILLETS CHEZ MULYKAP ........ 14
2.1. Introduction .............................................................................................................................. 14
2.1.1. Présentation de l’entreprise ................................................................................................ 14
2.2. ANALYSE METIER DE VENTE TICKET DE TRANSPORT .......................................... 15
2.2.1. DESCRIPTION TEXTUELLE DU PROCESSUS ........................................................................... 15
2.2.2. Identification des acteurs .................................................................................................... 16
2.2.3. Diagramme de contexte ...................................................................................................... 16
2.2.4. DIAGRAMME DE CAS D'UTILISATION METIER ..................................................................... 17
2.2.5. DESCRIPTION DES CAS D’UTILISATION .......................................................................... 17
2.2.6. DIAGRAMME D'ACTIVITE METIER ................................................................................. 18
2.2.7. DIAGRAMME DES CLASSES DU DOMAINE ........................................................................... 20
2.3. DIAGNOSTIC DE L'EXISTANT ................................................................................................... 21
 P a g e | VI
2.3.1. POINTS POSITIFS .................................................................................................................. 21
2.3.2. POINTS NEGATIFS ................................................................................................................ 21
2.3.3. PROPOSITION ET CHOIX DE LA SOLUTION. ......................................................................... 21
Point de vue organisationnel......................................................................................................... 22
Solution informatique ................................................................................................................... 22
CHAPITRE III : CONCEPTION DE L’ARCHITECTURE LOGICIELLE DE MULYKAP TICKET............................ 23
3.1. INTRODUCTION ............................................................................................................... 23
3.2. EXIGENCES FONCTIONNELLES ................................................................................. 23
3.2.1. SPECIFICATION DES EXIGENCES FONCTIONNELLES ............................................................. 23
3.2.2. Les besoins non fonctionnels .............................................................................................. 23
3.3. ANALYSE DES CAS D’UTILISATION .......................................................................... 24
3.3.1. Identification des acteurs .................................................................................................... 24
3.3.2. Elaboration du diagramme des cas d’utilisation ........................................................... 24
3.3.3. Description des cases d’utilisation ................................................................................ 26
3.4. SYNTHESE D’ANALYSE ...................................................................................................... 43
3.4.1. ELABORATION DU DIAGRAMME DE CLASSE RECAPITULATIF.............................................. 43
3.4.2. Découpage en catégorie ...................................................................................................... 43
3.4.2. ÉLABORATION DE LA MATRICE DE VALIDATION ................................................................. 44
3.4.3 Digramme de navigation Globale ......................................................................................... 45
3.4. CONCEPTION DETAILLEE DE L’APPLICATION .................................................... 46
5.1 ÉLABORATION DES DIAGRAMMES DE SEQUENCE TECHNIQUE .............................................. 46
3.5.2. ÉLABORATION DES DIAGRAMMES DE CLASSE TECHNIQUE ................................................ 51
3.5.4. ÉLABORATION DU DIAGRAMME DE PAQUETAGE ......................................................... 54
3.5.5. Architecture de l’application .......................................................................................... 55
3.5.6. ÉLABORATION DU MODELE LOGIQUE ........................................................................... 56
3.5.5.3. Diagramme de déploiement............................................................................................. 59
CHAPITRE IV : RESULTAT DE LA RECHERCHE ......................................................................................... 61
4.1. Introduction ........................................................................................................................... 61
4.2. Choix des outils de développement .................................................................................... 61
4.2.1. Choix de Langages coté Client ....................................................................................... 61
4.2.2. Langages de programmation coté serveur .................................................................... 62
4.2.3. Le Serveur Web Apache ................................................................................................ 62
4.3. Discussion ............................................................................................................................. 63
CONCLUSION GENERALE ....................................................................................................................... 69
BIBLIOGRAPHIE ...................................................................................................................................... 70
P a g e | II
 I

LISTE DES TABLES

Tableau 1—Tableau des acteurs............................................................................................... 16

Tableau 2—Matrice de validation ............................................................................................ 45
 II

LISTE DES FIGURES

Fig.1 1—Le web statique ........................................................................................................................ 9

Fig.1 2—Le web dynamique ................................................................................................................... 9
Fig.1 3—L’’architecture 2-tier .............................................................................................................. 10
Fig.1 4—Architecteur à 3 niveaux ........................................................................................................ 10
Fig.1 5—Architecture à n- niveaux ....................................................................................................... 11

Fig.2. 1--–Localisation géographique de mulykap Sarl (source : Google maps) ................................. 15

Fig.2. 2--diagramme de contexte ........................................................................................................... 16
Fig.2. 3—Diagramme de cas d'utilisation Métier .................................................................................. 17
Fig.2. 4—Diagramme d'activité métier ................................................................................................. 19
Fig.2. 5—Diagramme des classes du domaine ..................................................................................... 20

Fig 3. 1—diagramme de cas d'utilisation internaute ............................................................................. 24

Fig 3. 2—diagramme de cas d'utilisation client .................................................................................... 25
Fig 3. 3—diagramme de cas d'utilisation administrateur ...................................................................... 25
Fig 3. 4—diagramme de cas d'utilisation final ...................................................................................... 26
Fig 3. 5—diagramme de séquence s'authentifier ................................................................................... 27
Fig 3. 6—Ecran de saisi d'authentification ............................................................................................ 28
Fig 3. 7—Diagramme de classes participantes d'authentification ......................................................... 28
Fig 3. 8—Diagramme de séquence du cas d'utilisation « Gérer utilisateur » ........................................ 29
Fig 3. 9—Ecran de gestion compte utilisateur ...................................................................................... 30
Fig 3. 10—Diagramme de classes participantes du cas d'utilisation Gérer utilisateur .......................... 30
Fig 3. 11--diagramme de séquence consulter programme ..................................................................... 31
Fig 3. 12—Interface utilisateur de consultation de programme de voyage ........................................... 32
Fig 3. 13—Diagramme de classes participantes du cas d'utilisation « consulter programme bus » ..... 32
Fig 3. 14—diagramme de séquence effectuer réservation .................................................................... 34
Fig 3. 15—Interface Utilisateur de saisie de réservation de place ........................................................ 35
Fig 3. 16—Diagramme de classes participantes du cas d’utilisation « Effectuer réservation » ............ 35
Fig 3. 17—diagramme de séquence confirmer réservation ................................................................... 37
Fig 3. 18—Interface utilisation de confirmation de réservation ............................................................ 38
Fig 3. 19—Diagramme de classes participantes du cas d'utilisation Confirmer réservation................. 38
Fig 3. 20—diagramme de séquence gérer programme .......................................................................... 41
Fig 3. 21—Interface utilisateur du cas d’utilisation « Gérer programme » ........................................... 42
Fig 3. 22—Diagramme de classes participantes Gérer programme ...................................................... 42
Fig 3. 23—diagramme de class récapitulatif ......................................................................................... 43
Fig 3. 24—Découpage en catégorie ...................................................................................................... 44
Fig 3. 25—Diagramme de navigation globale ...................................................................................... 45
Fig 3. 26—Diagramme d'interaction s'authentifier ............................................................................... 46
Fig 3. 27—Diagramme d'interaction effectuer paiement ...................................................................... 47
Fig 3. 28—Diagramme d'interaction créer compte ............................................................................... 48
Fig 3. 29—Diagramme d'interaction consulter programme .................................................................. 49
Fig 3. 30—Diagramme d'interaction gérer réservation ......................................................................... 50
Fig 3. 31—Diagramme d'interaction effectuer réservation ................................................................... 51
Fig 3. 32—Diagramme de classe de conception consulter programme ............................................... 51
Fig 3. 33—DCC créer compte ............................................................................................................... 52
 III

Fig 3. 34—DCC réserver place ............................................................................................................. 52

Fig 3. 35—DCC effectuer payement ..................................................................................................... 53
Fig 3. 36—DCC global ......................................................................................................................... 53
Fig 3. 37—Diagramme de paquetage .................................................................................................... 55
Fig 3. 39—Modèle Physique de données .............................................................................................. 59
Fig 3. 40—Diagramme de déploiement ................................................................................................ 60

Fig.4 1—Accuel du système ................................................................................................................. 65

Fig.4 2—Interface d'authentification ..................................................................................................... 65
Fig.4 3—Interface utilisateur de gestion de programme ....................................................................... 66
Fig.4 4—Interface utilisateur de réservation de place ........................................................................... 67
Fig.4 5—Interface de confirmation Réservation ................................................................................... 67
Fig.4 6--Inteface Tocket voyage............................................................................................................ 68
 1

INTRODUCTION GENERALE

Avec l'apparition de l'outil informatique, nous avons constaté une grande révolution
de la technologie. Elle est omniprésente dans notre vie quotidienne, que ce soit dans les
ordinateurs, voitures, avions, bus etc…L’informatique a révolutionné la façon dont nous
communiquons, travaillons, apprenons et nous divertissons. Les systèmes informatiques sont
utilisés dans de nombreuse domaine tels que la finance, la sante, l’éducation, les transports etc.
cependant en République Démocratique du Congo « RDC en sigle » beaucoup d’entreprises
tant privées que publiques tentent d’optimiser leurs services dans le but de retrouver la mutation
mondiale qui tend à rejoindre les innovations au travers les nouvelles technologies de
l’information et de la communication « NTIC en sigle ».

Comme entre autres difficultés dans la distribution des services aux clients constitue de
plus en plus une préoccupation des dirigeants d’entreprise. Celles-ci sont astreintes à
l’élaboration des stratégies leurs, permettant d’atteindre leurs objectifs à travers une distribution
régulière et croissante de leurs produits et services.

Les entreprises doivent être de plus en plus réactives face aux nouveaux enjeux qui se
présentent à elles. Les orientations stratégiques et le Système d’Information doivent être pensés
de manière simultanée afin que celui-ci soutienne au mieux la prise de décision.

1.1.Concept central de la recherche

Dans cette section, nous présenterons le concept central de notre sujet qui est intitulé : «
Analyse métier et conception par la méthode up7 d’une application web de réservation des
billets de bus. »

1.1.1. Concept 1 : E- commerce

L’e-commerce, également connu sous le nom de commerce électronique, fait référence à
l'achat et à la vente de biens et de services en ligne, via Internet. Il permet aux entreprises et
aux consommateurs d'effectuer des transactions commerciales sans avoir à se déplacer
physiquement dans un magasin ou un lieu de vente.
1.1.2. Concept 2 : réservation en ligne
La réservation en ligne se réfère au processus de réservation de services ou de produits via
Internet. Cela peut inclure la réservation d'hôtels, de billets d'avion, de locations de voitures,
de billets de spectacle, etc. Les consommateurs peuvent accéder aux sites Web des
fournisseurs de services, sélectionner les options souhaitées, fournir les informations requises
et effectuer la réservation en ligne. Cela offre une commodité et une flexibilité aux
consommateurs, qui peuvent réserver leurs services à tout moment et de n'importe où.
 2

1.1.3. Concept 3 : Gestion numérique de programme de voyage

La gestion numérique de programme de voyage se réfère à l'utilisation de technologies
numériques pour organiser, suivre et gérer les détails d'un voyage. Cela peut inclure la
planification des itinéraires, la réservation de vols et d'hébergements, la gestion des horaires,
la consultation des informations sur les attractions touristiques, la gestion des dépenses, etc.
Les applications et les plateformes en ligne sont souvent utilisées pour faciliter cette gestion
numérique du programme de voyage, offrant aux voyageurs une meilleure organisation et une
expérience plus fluide lors de leurs déplacements.

1.2. Enoncée du problème et questions de la recherche

Nous avons pu constater quelques failles dans le système actuelles de MULYKAP :
Temps d'attente : La vente manuelle des tickets peut prendre plus de temps que les systèmes
automatisés, ce qui peut entraîner des files d'attente plus longues. Erreurs humaines : Les erreurs
de saisie ou de calcul peuvent se produire lors de la vente manuelle des tickets, ce qui peut
entraîner des problèmes de tarification incorrecte ou de mauvais itinéraires. Cela peut entraîner
des pertes financières pour l'entreprise de transport et une insatisfaction des clients.

Nous en tant que chercheur en sciences informatiques, nous avons pensé que la
Proposition d’un logiciel informatique serait la meilleure solution car celle-ci permettra de
retrouver dans le temps record de produire une bonne réservation et ainsi faire gagner en temps
et souplesse. Ainsi notre problématique porte autour des questions suivantes :
1. Quelle démarche méthodologique peut-on utiliser pour aboutir à la conception d’un
système d’e-business compatible aux besoins de l’entreprise ?
2. Quelle architecture logicielle pouvons-nous mettre en place pour la conception de
notre système ?
Voilà les interrogations qui constitueront la charpente de notre recherche. En guise des
solutions à la problématique soulevée ci-haut nous retenons les hypothèses suivantes :
Pour mener à bien faire notre étude nous allons utiliser la méthode UP7 (« Unified
process 7 » processus unifié 7 en français).
La méthode UP7 adoptée dans ce travail est une démarche d’analyse et de conception
des systèmes informatiques centrée sur la notation UML et développé par Pascal Roques dans
son ouvrage intitulé : “UML pour le web ».
 3

1.3. Etat de la question

Nous ne prétendons pas être les premiers à vouloir aborder les contours ou les aspects de
réservation des billets dans une entreprise de transport dans la mesure où beaucoup de nos
prédécesseurs s’y sont intéressé mais sous un aspect différent.

Il s’agit par exemple de :

1. MACHKOUK ABDELALIME. Dans son travail de fin de cycle de licence il a
eu a traité sur « la conception et réalisation d’un système de gestion des réservations des billets
dans une agence de voyage aérien » pour lui le but de ce projet était de créer un système qui
permettra la gestion des réservations des billets chez une agence de voyage aérien. Passant de
son but, sa solution était de mettre en place une application pour L’enregistrement des villes,
les horaires des vols, le prix de billet. Son programme devrait pouvoir afficher les vols
disponibles selon le désir des utilisateurs et permettre aux utilisateurs des réserver leurs places.
2. MUKUMBI BAHATI ANGEL dans son travail : « conception d'un logiciel de
réservation de billets de transport à bord d'un train » cas de la SNCC. Dont sa problématique
était basée sur l'inexactitude et le non précision de nombres de billets sans tenir compte de
nombre de places d'un train.
3. NGOSA MUTALE Malvine licencie.2021/ Université Protestante de
Lubumbashi/ faculté informatique et Gestion : Il a parlé sur la conception d’un logiciel de
réservation de billets de transport « cas de CLASSIC CHOSH », dont sa problématique était
basée sur le manque d’une base de données et la non précision de nombres de billets sans tenir
compte de la capacité du bus.
Après les investigations, nous marquons nettement la différence des auteurs cités ci- haut,
dans le sens que le présent travail traitera sur la conception d’une application web de
réservation des billets de bus, et notre étude se portera sur l’ entreprise de transport
MULUKAP se trouvant dans la ville de Lubumbashi précisément dans la province du haut-
Katanga, que nous tenterons d’apporter notre aide à une problématique de réservation des
billets en ligne avec une efficacité et une bonne sécurité pour la bonne réservation.
Toute la démarche de ce travail sera celle qui nous mènera à la méthodologie de
conception et au développement d’une application informatique qui pourra aider les clients
de MULYKAP à passer leurs réservations.
1.4.Motivation de la recherche et objectifs
1.4.1. Motivation de la recherche
 4

En effet, Le choix de ce sujet n’est pas le fruit du hasard ; c’est après un long moment
d’observation lors d’un voyage ou déplacement que cela a suscité notre curiosité et a nous
poussé à travailler dans ce domaine, afin d’apporter une connaissance et améliorer le système
leurs bureaux qui se situe à l’entrée de la ville.

1.4.2. Objectifs de la recherche

L’objectif de la recherche est de permettra aux clients de MULYKAP de pouvoir
effectuer de réservations en ligne, d’une part et à l’agence de transport MULYKAP de
pouvoir administrer numériquement le processus de vente de ticket ainsi de que la
programmation de bus et cela n’est possible qu’en mettant en place une application Web
de réservation de titre de voyage en ligne.

De manière spécifique, les objectifs à atteindre sont :

- Permettre la programmation de bus en ligne ;

- Le client doit arriver à faire une réservation en ligne et la confirmée en ligne
et avoir son ticket en ligne ;
- Le client peut faire recherche de programme en mode avancé ou direct
- L’administrateur peut désormais voir la situation de paiement de c’un
programme, annuler une réservation ou l’annulation carrément du
programme.
1.4.2.1.Objectif primaire
Collecter des informations pour le fonctionnement de vente des tickets afin de concevoir une
solution numérique efficace
1.4.2.2.Objectif secondaire
L’objectif de la recherche est de permettra aux clients de MULYKAP de pouvoir effectuer de
réservations en ligne, d’une part et à l’agence de transport de pouvoir administrer
numériquement le processus de vente de ticket ainsi de que la programmation de bus
1.5.Méthodologie de la recherche
Dans notre travail, nous utiliserons la méthode UP7 (Unifie Process 7) est une démarche
d’application d’UML qui prend appui sur UP (Unifie Process) mais qui se veut avant tout être
pragmatique. Cette démarche est fondée d’une part sur notre vision du processus de
développement et d’autre part sur notre propre expérience tirée de la réalisation en entreprise
de projets avec UML[1].
 5

Cette démarche s’articule suivant deux axes[2] : les quatre phases qui
correspondent à celles d’UP (lancement, élaboration, construction et transition) et sept
activités ou étapes ayant chacun un pourcentage de temps qu’elle occupe (Modélisation
métier, Exigence, Fonctionnelle, Analyse des cas d’utilisation, Synthèse d’analyse,
Conception, Implémentation et Test). Ainsi, nous pouvons présenter dès ce stade un
premier schéma d’ensemble de la démarche suivant ces deux axes.

Figure 1 tableau de la démarche up7

Les zones grises dans les différentes phases de la figure représentent la proportion
d'effort consacré à chaque activité dans chaque phase du projet.
Activité 1 : Modélisation métier
 Modèle de l’entreprise
- Diagramme de classe
 Modèle de processus de l’entreprise
- Diagramme d’activité
Activité 2 : Exigence fonctionnelles
 Identification et représentation des besoins
- Description des acteurs et des cas d’utilisation
- Diagramme de cas d’utilisation
Activité 3 : Analyse de cas d’utilisation
 6

 Analyse métier de l’existant

- Diagramme d’activité
- Diagramme de classe
- Modèle du domaine : classe métier
Activité 4 : synthèse de l’analyse
 Validation de l’analyse
- Diagramme de classe récapitulatif).
- Matrice de validation.

Activité 5 : Conception
 Diagramme d’interaction
- Diagramme de séquence
 Conception détaillée
- Diagramme de classe
Activité 6 : Implémentation
 Modèles issus de l’analyse et de la conception
- Technologies de programmation
- Produit logiciel sous forme des composants de bibliothèque
Activité 7 : Test
 Vérification implémentation (présentation du résultat)
- Présentation interfaces
- Présentation de l’application
Le schéma ci-dessous nous présente les différentes étapes qui caractérisent le cycle de
développement logiciel qu’exige la démarche UP7 d’une manière simplifiée.
Pour la conception de notre application nous allons nous servir de l’architecture
Logicielle 3 tiers. Et les techniques suivantes :
- La Technique de conception : elle nous permet d’analyser les systèmes pour
produire des modèles.
- La Technique de prototypage : est la démarche qui consiste à réaliser un prototype.
Ce prototype est un exemplaire incomplet et non définitif de ce que pourra être le
produit ou objet final.
 7

La rigueur scientifique nous exige de Limiter notre champ d’investigation. C’est ainsi que
notre recherche est centrée sur MULYKAP. Nous ne nous baserons que sur la réservation des
billets et la production des rapports.

Hormis l’introduction et la conclusion ce travail est subdivisé en quatre chapitres ci-après:

Chapitre premier « revue de la littérature » : ce chapitre introduit principalement la

revue de la littérature sur la vente en ligne de ticket ainsi que la théorie de conception et
technologie Web.

- Chapitre Deuxième « Analyse métier du processus de réservation des places chez

Mulykap » : il s’agira de démontrer le mode fonctionnel du système actuel.
- Chapitre troisième « Conception de l’architecture MULYKAP Ticket » : ici il sera
question de modéliser avec le langage UML la façon dont sera constitué le système tout
en présentant les détails pratiques sur chaque point.
- Chapitre Quatrième « Résultats de l’étude » : il sera question de faire une discussion
sur la solution proposée.
 8

CHAPITRE I. REVUE DE LA LITTERATURE

1.0. Introduction
Ce chapitre introduit principalement la revue de la littérature sur la vente en ligne de
ticket ainsi que la théorie de conception et technologie Web.

1.1. Théorie sur les technologies web

Inventé par Tim Bernes-Lee et Robert Cailliaud à la fin des années 1980, le Web se
résume à cet outil qui permet la consultation, via un navigateur, de pages de sites Internet (ou
sites Web). Il ne représente qu'une partie de ce que comporte réellement Internet avec,
notamment, les applications de courrier électronique et le partage de fichiers en P2P, entre
autres [6].
A l’origine du web ou à la base de l’histoire du web se trouve Sir Tim Bernes-Lee qui est
considéré comme l’inventeur du World Wide Web. Sir Tim travaillait au CERN et voulait
trouver une solution pour faciliter le partage d’informations entre ingénieurs. A cette époque,
avec le développement d’internet, de nombreux ordinateurs étaient déjà connectés. Il a donc
trouvé la réponse pour le partage d’informations en combinant internet avec une autre
technologie émergente : HyperText [7].

1.1.1. Composants de l’architecture du web

Les trois technologies fondamentales du web proposées par SIR TIM sont les suivantes :
HTML : HyperText Markup Langage ; Le langage de balisage (formatage) du web. URI :
Uniform Resource Identifier, Une sorte d’adresse qui est unique et utilisée pour identifier
chaque ressource à travers le web. Communément aussi appelé un URL et HTTP : HyperText
Transfer Protocol. Permet la récupération de ressources liées à travers le Web.
a) Web statique
Dans le web statique nous voyons le client et le serveur c’est- à dire, Lorsqu’on connecte
les ordinateurs en réseau, il devient intéressant de concentrer certaines ressources (des
informations et des programmes) sur un seul ordinateur, et de permettre aux autres ordinateurs
de se servir de ces ressources uniquement lorsqu’ils en ont besoin. C’est l’architecture client-
serveur. Le serveur, c’est l’ordinateur qui a le droit d’accès a la ressource sur le serveur [8].
Le fonctionnement d’un site web statique se passe en deux temps :
1. Un client demande une page web au serveur.
2. Le serveur lui répond en lui envoyant la page demandée, sans la modifier.
 9

Fig.1 1—Le web statique

b) Les web dynamiques

Avec le web dynamique, nous allons avoir des pages qui pour une même adresse peuvent
prendre des formes différentes selon les actions de l’utilisateur. C’est à dire, pour
obtenir une page changeante, nous disposons de deux techniques :
 C’est le serveur qui construit une nouvelle page, qu’il envoie au client (scripts cote serveur)
 C’est le client qui reçoit une page fixe, et il modifie cette page (scripts cote client)
Fonctionnement des sites web dynamiques
Contrairement au site statique, le fonctionnement d’un site web dynamique se passe en
trois temps :
1. Le client demande une page web au serveur
2. Le serveur prépare la page spécialement pour le client
3. Le serveur lui envoie la page qu’il vient de générer.
La page web est générée à chaque fois qu’un client la réclame. C’est précisément ce qui
rend les sites dynamiques vivants, le contenu d’une même page peut changer d’un instant à
l’autre.

Fig.1 2—Le web dynamique

1.1.2. Types des architectures du web

Les différentes architectures du system sont : 2-tier, 3-tier et n -tier, En effet "n tier" est
un terme anglais qui ne doit pas être confondu avec le mot français "tiers". Dans toute la
présentation suivante tier signifie niveau logique [9].
a. Présentation de L’architecture 2-tier
 10

L'architecture à deux niveaux (aussi appelée architecture 2-tier, tier signifiant rangée en
anglais) caractérise les systèmes clients/serveurs pour lesquels le client demande une ressource
et le serveur la lui fournit directement, en utilisant ses propres ressources.

Fig.1 3—L’’architecture 2-tier

b. Présentation de L’architecture 3-tier

Dans l'architecture à 3 niveaux (appelée architecture 3-tier), il existe un niveau
intermédiaire, c'est-à-dire que l'on a généralement une architecture partagée entre :
Un client, c'est-à-dire l'ordinateur demandeur des ressources ,équipée d'une interface
utilisateur(généralement un navigateur web) chargée de la présentation;
Le serveur d'application (appelé également middleware), chargé de fournir la ressource mais
faisant appel à un autre serveur, Le serveur des données, fournissant au serveur d'application
les données dont il a besoin.

Fig.1 4—Architecteur à 3 niveaux

c. Présentation de L’architecture n-tiers
 11

L'architecture à N niveaux permet de spécialiser les serveurs dans une tache précise :
avantage de flexibilité, de sécurité et de performance. L'architecture peut être étendue sur un
nombre de niveaux plus important : on parle dans ce cas d'architecture à N- niveaux (ou multi-
tier).

Fig.1 5—Architecture à n- niveaux

1.1.3. Technique de base sur les applications web

Dans la technologie client-serveur, utilisée pour le World Wide Web, le navigateur Web
envoie au serveur des requêtes relatives à des pages Web. Le serveur répond aux demandes en
envoyant les pages au navigateur Web. Le navigateur affiche alors les pages à l'utilisateur.
Les applications Web utilisent cette technique pour mettre en œuvre leur interface
graphique. Celle-ci est composée de pages créées de toutes pièces par le logiciel lors de chaque
requête. Chaque hyperlien contenu dans la page provoque l'envoi d'une nouvelle requête, qui
donnera en résultat une nouvelle page. À la différence d'un site web statique où les pages sont
des fichiers préalablement enregistrés.
Les pages Web contiennent divers widgets tels que des boutons poussoirs, des icônes et
des zones de texte, permettant la manipulation de l'application. Chaque manipulation d'un
bouton poussoir provoque l'envoi d'une nouvelle requête. Les pages Web peuvent contenir des
applets [12].
1.1.4. Protocoles d’échange sur les applications web

Un protocole est un ensemble de règles qui définissent comment se produit une

communication dans un réseau. Le HTTP (Hyper Texta Transfert Protocol) est un protocole
simple, basé sur l'émission d'une requête vers un serveur HTTP, en vue de l'obtention d'une
ressource. Cette ressource est identifiée par un URL qui est une position "logique" dans le
réseau. L'objectif initial du HTTP est la requête sur des pages hypertexte (HTML), lesquelles
 12

servent de base à la construction d'un document composite, par combinaison de divers types de
ressources annexes :
 Des images
 Des feuilles de style
 Des scripts clients attachés
L’un des plus importants avantages du protocole http est de « découper » les documents
à transférer en blocs. Ces blocs peuvent être acheminés de manière indépendante du serveur
vers le client. Ils seront ensuite assemblés au niveau du récepteur.

I.1.5. Notion sur les développements web

La condition pré-requise à toute présence sur le Web est de disposer d’un espace de
stockage sur un serveur. Pour cela, les services d’un hébergeur de sites Web spécialisé sont
nécessaires. En règle générale, l’offre comprend des packs complets d’hébergement. Ces packs
incluent souvent des services comme la réservation d’un nom de domaine propre, de la mémoire
vive allouée par un serveur, des bases de données et tous les outils nécessaires pour le
développement Web. Généralement, les utilisateurs de ces packs d’hébergement ignorent
quelles machines physiques regroupent ces services. Ce n’est pas le cas pour les modèles
d’hébergement alternatifs (serveurs Web dédiés par exemple), dont les composants matériels
sont loués par un centre de données.
Il y a de nombreux avantages au développement d’application Web par rapport aux
applications mobiles. Ces raisons influencent la décision finale mais elles présentent également
des inconvénients.
I.2. Théorie sur les bases de données
Une base de données est un ensemble structuré de données organisées de manière à permettre
leur stockage, leur gestion et leur utilisation efficace. Elle est utilisée pour stocker des
informations dans un format structuré, ce qui facilite la recherche, la récupération et la
manipulation des données.
Les bases de données sont généralement composées de tables, qui contiennent des
enregistrements ou des lignes de données, et de colonnes, qui définissent les différents types
d'informations stockées. Les tables sont liées entre elles par des clés primaires et des clés
étrangères, ce qui permet d'établir des relations entre les données.
Les bases de données peuvent être gérées par des systèmes de gestion de bases de données
(SGBD), qui fournissent des fonctionnalités pour créer, modifier, interroger et gérer
 13

Les données. Les SGBD les plus couramment utilisés sont MySQL, Oracle, Microsoft SQL
Server et PostgreSQL.
Les bases de données sont largement utilisées dans de nombreux domaines, tels que les
applications web, les systèmes d'information, la gestion des stocks, les systèmes de réservation,
etc. Elles offrent une solution efficace pour stocker et gérer de grandes quantités de données de
manière sécurisée et fiable.
II.2.3. Types de SGBD
Il existe différents types de SGBD, tels que les SGBDR (Systèmes de Gestion de Bases de
Données Relationnelles), qui sont basés sur le modèle relationnel et utilisent le langage SQL
(Structured Query Language) pour interagir avec la base de données. Les SGBDR sont les plus
couramment utilisés et offrent des fonctionnalités avancées telles que les transactions ACID
(Atomicité, Cohérence, Isolation, Durabilité), les contraintes d'intégrité, les vues, etc.

Il existe également des SGBD orientés objet, qui permettent de stocker des objets complexes
avec leurs attributs et leurs méthodes, des SGBD NoSQL (Not only SQL), qui sont adaptés au
stockage et à la gestion de données non structurées ou semi-structurées, et des SGBD en
mémoire, qui stockent les données en mémoire vive pour des performances optimisées.
Les SGBD offrent également des fonctionnalités avancées telles que la réplication des données
pour assurer la disponibilité et la redondance, la sauvegarde et la restauration des données, la
gestion des droits d'accès pour garantir la sécurité des données, etc.
En résumé, un système de gestion des bases de données est un outil essentiel pour stocker,
organiser et gérer les données d'une entreprise de manière efficace. Il offre des fonctionnalités
avancées pour assurer la sécurité, l'intégrité et la disponibilité des données.

Conclusion partielle

Dans ce chapitre il a été question de présenter la méthode UP7 une méthode qui
s’appuie sur UP mais qui se veut être pragmatique, et décompose sa démarche en 7
étapes ou activités du cycle de développement logiciel.

Enfin nous avons conclu ce chapitre en parlant sur les applications web, les types
d’architecture ainsi que le fonctionnement d’une application web.
 14

CHAPITRE II : ANALYSE METIER DU PROCESSUS DE

RESERVATION DES BILLETS CHEZ MULYKAP
2.1. Introduction
Au cours de l'élaboration de notre projet, nous commençons par un aperçu des
recherches préliminaires. Cela comprend la liste de toutes les données et de tous les
traitements du système avant de recommander une solution pour le futur système. Il s'agit
d'une étape critique dans la mise en œuvre d'une application donnée. L'avenir de l'application
dépend fortement de cette étape qui évite le développement d'applications non conformes à
leurs spécifications. Pour ce faire, le client et le développeur doivent être en contact étroit.
Afin d'atteindre nos objectifs, nous devons être conscients de :

1. Analyse et définition des exigences : Une étape qui permet un consensus entre les experts
(développeurs) et les utilisateurs.

2. Etude de faisabilité : domaine d'application et état environnemental du futur système.

3. L'élaboration du cahier de charge : dans ce chapitre, nous présentons le système existant en

vue d'en dégager les faiblesses et proposer des solutions informatiques appropriées.

2.1.1. Présentation de l’entreprise

La belle aventure de MULYKAP, une société de transport en commun de voyageurs, a
commencé en 2008. spécialisée dans la vente des produits pétroliers et le transport des
personnes. Nous opérons dans le grand Katanga et relions la ville de Lubumbashi à la ville de
Kolwezi passant par Likasi et FUNGURUME et très bientôt KASUMBALESA avec une
centaine de bus neufs assurant sécurité et confort à nos passagers.
Nos différentes stations-service offrent à nos clients des produits de qualité
pour leurs besoins.

2.1.2. Situation géographique de l’entreprise

SITUATION GEOGRAPHIQUE. MULYKAP Sarl est une société de droit congolaise
opérant principalement dans la province de l'ex-Katanga, son siège social est établi au numéro
26 de l'Avenue USOKE, Commune KAMPEMBA, Quartier KIGOMA.
 15

Fig.2. 1--–Localisation géographique de mulykap Sarl (source : Google maps)

2.2. ANALYSE METIER DE VENTE TICKET DE TRANSPORT

2.2.1. DESCRIPTION TEXTUELLE DU PROCESSUS

Le processus commence lorsque le client désire réserver ou voyager, tel bus est
programmé d’avance par le manager, le client consulte le catalogue livre par le caissier
celui-ci muni de sa carte d’identité effectue sa réservation. Le caissier vérifie alors la
disponibilité. Si celle-ci est confirmée, le caissier établie un billet en sachant que le
formulaire est préalablement imprimé, le client le paie, le caissier quant à lui, encaisse le
billet et le remet au client tout en établissant un rapport a son manager qui le consultera à la
fin de la journée.
 16

2.2.2. Identification des acteurs

Tableau 1—Tableau des acteurs

Client Externe Toute personne voulant faire une reservation

ou voyager chez mulykap
Manager Interne Une personne chargé de gerer les programme
es voyage
Caissier Interne Toute personne qui est chargé d’encaisser
l’argent
Figure 2:tableau d'acteurs

2.2.3. Diagramme de contexte

Le Diagramme de contexte nous permet d'avoir une vue globale du système étudié,
des interactions entre ses activités et le rapport avec l'environnement extérieur.

Le diagramme de contexte statique délimite le domaine d'étude en précisant :

- Ce qui est à la charge du système et

- En identifiant l'environnement extérieur au système étudié avec lequel ce dernier

communique.

Dans cette perspective, notre diagramme de contexte se présente comme suit :

uc Diagramme de contexte

Reservation des billets

Client
Caissier

Manager

Fig.2. 2--diagramme de contexte

 17

2.2.4. DIAGRAMME DE CAS D'UTILISATION METIER

Le cas d’utilisation désigne les fonctionnalités visibles du système dont on désire

décrire le fonctionnement. Il répond au besoin en définissant une partie du comportement
attendu du système sans révéler sans structure interne.

En utilisant notre diagramme, un utilisateur ou acteur est représenté par un petit

Personnage, et le cas d’utilisation ou fonctionnalité du système par un ovale, les flèches issues
d’un personnage pointent vers les cas d’utilisation [3].

uc Diagramme de cas d'utilisation

Reservations Billets

consulterProgramme
etablierBillet

reserverPlace

Client EncaisserPaiement
«include» Caissier

payerBillet

etablirProgramme
etablirRapport

GererProgramme

Manager

consulterRapport

Fig.2. 3—Diagramme de cas d'utilisation Métier

2.2.5. DESCRIPTION DES CAS D’UTILISATION

Dans cette partie nous allons poursuivre notre analyse par la description des différents
cas d’utilisation. Pour le cadre de ce travail nous allons effectuer la description des cas
d’utilisation suivants :

• Cas 1 : Consulter programme ;

• Cas 2 : S’authentifier ;
 18

• Cas 3 : Gérer réservation place ;

• Cas 4 : Créer compte ;

Pour chaque cas d’utilisation, les sous-activités suivantes de l’activité « Analyse des
cas d’utilisation » sont réalisées :

• Description du cas d’utilisation

• Élaboration du diagramme de séquence
• Élaboration d’une maquette pouvant représenter la composition des différentes
IHM
• Élaboration du diagramme de classe

2.2.6. DIAGRAMME D'ACTIVITE METIER

Un diagramme d’activité est un diagramme UML qui modélise les aspects dynamiques
d’un système. C’est une simplification du diagramme d’état de transition permettant
d’améliorer les flux contrôle des processus informatiques et organisationnels.

Le diagramme d’activité se diffère de celui d’état transition par le fait que le diagramme
d’activité fournit une spécification complète d’un comportement et non, comme les
diagrammes d’interaction, un seul scénario possible. Alors que le diagramme d’état transition
se focalise sur la mise en œuvre des opérations dans lesquelles la plupart des événements
correspondent à la fin de l’activité précédente. Le diagramme d’activité ne fait pas de
distinction entre les activités, les actions et les événements [2].

Le diagramme d’activité expose juste les activités séquentielles et parallèles d’un

processus. Il est utilisé pour présenter :

- Le déroulement de processus métier ;

- Des enchainements d’activités regroupées séquentiellement ; - Les

8synchronisations d’activités.
Le diagramme d’activité se compose des éléments suivants :

- Une activité : représente une exécution d'un mécanisme, autrement dit, un

déroulement d'étapes séquentielles.
- Une transition : qui représente Le passage d'une activité vers une autre. Cette
transition peut être automatique, qui se déclenche par la fin d'une activité, provoquent
 19

le début immédiat d'une autre ou conditionnelle, qui ne se déclenche qu’après la

satisfaction de la condition qu’on appelle aussi garde.
- Les gardes : qui représentent la condition de passage d’une activité à une autre dans
les transitions conditionnelles ils sont symbolisés par des losanges comme dans la
figure suivante
- Les barres de synchronisation : sont des barres représentées par une ligne épaisse,
le rôle cette barre est de synchroniser le départ de plusieurs transitions qui arrivent de
déférentes activités, aboutissant toutes à une activité commune.

act Diagramme d'Activite

Client Caissier Manager

PublierProgamme
arriver: Client EtablirProgramme

DemanderReservation RemettreCatalogue

ConsulterCatalogue

VerifierDisponibilite
ReserverPlace

Disponible?

Oui Non

EtablirBillet MettreEnAttente
AcheterBillet

Fin
EncaisserPaiement

RecevoirBillet RemettreBillet

EtablirRapport ConsulterRapport

Fin

Fig.2. 4—Diagramme d'activité métier

 20

2.2.7. DIAGRAMME DES CLASSES DU DOMAINE

Le modèle de domaine est une représentation de concepts significatifs du monde réel et

qui concernent le domaine à modéliser dans le logiciel. Les concepts incluent les données
concernées par l’activité et les règles métier en rapport avec ces données.

class Class Model

Client Place
- idClient: int - IdBillet: int
- NomCleint: string 1 1..* - nomClient: string
- prenomClient: string - prenomClient: String
- Telephone: string
1
1

Paiement concerne

1..* Paiement

Programme - idBillet: int

concerne - NomClient: string 1
- Date: date - PrenomClient: string
- destination: string 1 1..* Concerne
- Prix: int 1 Billet
- Heure: date
1..* - Date: date
- idBillet: int
- NomClient: string
- prix: int

Catalogue

- destination: string
- JourVoyage: string

Fig.2. 5—Diagramme des classes du domaine

Signification de chaque concept :

Client : une personne qui réserve et voyage à bord du bus

Place : siège spécifique a bord du bus

Programme : c’est une prévision du trafic voyageurs, un programme est constitué de : le bus,
la date de départ, le vente, l’heure et la destination.
Catalogue : liste descriptive des horaires, destination

Billet : c’est un jeton de réservation que le guichetier fourni au client après sa réservation.

Paiement : montants fixé pour la réservation

 21

2.3. DIAGNOSTIC DE L'EXISTANT

Les critiques ne seront pas que négatives mais positives non plus du fait que dans chaque
chose y a toujours eu les points forts et faibles.

2.3.1. POINTS POSITIFS

Quelques temps de recherche au sein de MULYKAP nous sommes stupéfait de l’engagement

de personnel dans leurs taches ;

L’union et la collaboration du personnel pour l’accomplissement de leur mission ;

L’engagement du personnel pour l’accomplissement de la mission de MULYKAP quoique les
difficultés ;

2.3.2. POINTS NEGATIFS

Toute œuvre fait des mains des hommes ne manque pas des imperfections, si un défaut
S’avère utile de trouver une solution alors celui qui le découvre doit proposer une solution.

Voilà le dynamisme qui fonde le progrès scientifique. Nous allons relever les côtés
boiteux dans le système étudié et ce relèvement se fera en deux point : sur le point de vue
organisationnel et informationnel.

Point de vue organisationnel

- La structure du personnel n’est pas bien définie ;

- L’assistant manageur combine deux postes

Point de vue informationnel
- Redondance des informations dans plusieurs documents ;

- La recherche des informations lentes, soit difficile ;

- Insécurité dans la conservation de document ;

- Incertitude de produire le rapport en temps réel.

2.3.3. PROPOSITION ET CHOIX DE LA SOLUTION.

Après que nous ayons critiqué le système d’information existant nous allons maintenant
proposer nos solutions aux problèmes soulevés dans les précédentes lignes. Nous proposerons
deux types de solution, solution non informatique et informatique.
Proposition non informatique
 22

- Les propositions seront en deux volets.

Point de vue organisationnel

- La définition de la structure du personnel ;

- Détacher le poste de caissier à l’assistant manageur ;

- Point de vue informationnel

- Classer les documents dans les rayons pour faciliter la recherche des
informations

Solution informatique

Vu l’urgence et la prolifération des réservations qui ont besoin d’être géré et consulté
nous avons proposé ce qui suit :

La mise en place d’une structure autonome de gestion de réservation des billets. Cette
structure sera hiérarchiquement dépendante de l’envie d’être une structure de coordination de
la gestion de l’information.
Avoir un logiciel qui respecte les principes des Interfaces Homme/Machine (IHM) tels
que l'ergonomie et la fiabilité. Réduire les tâches manuelles qui nous permettraient de gagner
en spatiotemporel, Archiver les informations en toute confidentialité, Restituer rapidement les
données recherchées, Générer les rapports en temps réel Partager simultanément les
informations, Avoir un logiciel évolutif.

Conclusion partielle

La recherche préliminaire, techniquement connue sous le nom d'Ingénierie des

Exigences ou Analyse et Spécification des Exigences, est une phase critique qui doit être très
rigoureuse et mise en avant pour que le projet soit un grand succès si tout le reste du projet
en dépend. Après avoir fixé un objectif,
Afin d'atteindre notre objectif, nous devons suivre plusieurs étapes. Ceux-ci font partie
du cycle de vie de tout projet informatique. L'étape suivante est donc consacrée à l'analyse
des cas d'utilisation et à leur synthèse, puis passe à la conception de la plateforme.
 23

CHAPITRE III : CONCEPTION DE L’ARCHITECTURE

LOGICIELLE DE MULYKAP TICKET

3.1. INTRODUCTION
Dans ce chapitre, nous procéderons à la conception de nouveaux systèmes en analysant
la fonctionnalité du système et en identifiant les exigences fonctionnelles et non
fonctionnelles.

3.2. EXIGENCES FONCTIONNELLES

3.2.1. SPECIFICATION DES EXIGENCES FONCTIONNELLES

Avant de modéliser un système, il est important de saisir les besoins des utilisateurs
exprimés en termes de fonctionnalité du futur système. A cet effet, nous avons réparti ces
besoins en deux catégories, à savoir :

- Consulter catalogue : va permettre à l’internaute de consulter le catalogue

- Gérer catalogue : va permettre à l’administrateur d’ajouter, supprimer, modifier les

articles sur le catalogue
- Effectuer réservation : va permettre au client de passer sa réservation.

- Générer rapport : va permettre à l’administrateur de générer un rapport d’activité.

- Effectuer paiement : va permettre au client de confirmer sa réservation

- Consulter réservation : va permettre à l’administrateur de consulter les commandes

- Créer compte : va permettre à l’internaute de créer le compte

- Gérer compte : va permettre à l’administrateur de gérer les comptes des utilisateurs

• Modifier un utilisateur

• Supprimer utilisateur

3.2.2. Les besoins non fonctionnels

Outre les besoins fondamentaux (fonctionnels), notre application doit répondre aux
Critères suivants :
- La rapidité du traitement : En effet, vu le nombre important des données que nous
pourrons analyser, il est impératif que la durée d'exécution des traitements s'approche
le plus possible du temps réel.
 24

- La performance : notre application doit être avant tout performante à travers ses
fonctionnalités, répondre à toutes les exigences des utilisateurs d'une manière
optimale.
- La sécurité : l'application doit être protégée avec une clé ou un mot de passe pour
l’authentification.

3.3. ANALYSE DES CAS D’UTILISATION

À partir du diagramme d’activité et de la connaissance des besoins des acteurs, nous

élaborons une vision générale des cas d’utilisation du futur système en produisant le un
diagramme de cas d’utilisation système.

3.3.1. Identification des acteurs

Nous avons recensé trois acteurs qui auront à interagir avec le nouveau système. Voici
ci-dessous ces différents acteurs :

- Client : rôles des personnes qui souhaitent effectuer une réservation.

- Internaute : rôle de la personne qui n’a pas encore créé de compte dans le système.

- Admin : rôle de l’employé qui est en charge du bon fonctionnement et de la

maintenance du système.
3.3.2. Elaboration du diagramme des cas d’utilisation

En rapport avec l’internaute, nous avons juste le cas d’utilisation suivant :

uc cas d'utilisation internaute

consulter programme

Internaute
Creer compte

Fig 3. 1—diagramme de cas d'utilisation internaute

 25

Les cas d’utilisation important liés au client sont :

uc cas d'utilisation Client

S'authentifier

EffectuerReservation
Client

Effectuer Payement
Systeme Paiement

Fig 3. 2—diagramme de cas d'utilisation client

- Le cas d’utilisation important liés à l’administrateur sont :

uc cas d'utilisation administrasteur

Creer compte

«include»

Internaute
gerer programme
«include» s'authentifier

«include»

gerer reservation

Fig 3. 3—diagramme de cas d'utilisation administrateur

Ayant donc identifié chacun des cas d’utilisation de chacun des acteurs du système, il y
a donc lieu de représenter le diagramme cas d’utilisation finale regroupant les trois acteurs du
système.
 26

uc Diagramme de cas d'utilisation2

Systeme
ConsulerCatalogue Consulter
Reservation

Créer Compte
Internaute Generer Rapport
«include»

Rechercher Admin
Destination «include»
Generer Rapport

«include»
S'authentifier

«include»
«include»
effectuer
Reservation Gerer Compte
«include»

Client Systeme Paiement

EffectuerPayement

Fig 3. 4—diagramme de cas d'utilisation final

3.3.3. Description des cases d’utilisation

1. Cas d’utilisation « Authentification »

• Objectif : Permettre de protéger l’accès au système
• Acteur concerné : user(internautes)
• Précondition : Avoir un compte
• Post condition : utilisateur authentifié
• Scenario nominal
1. L’utilisateur de demande l’interface
2. Le système affiche l’interface d’authentification
3. L’utilisateur fournies ses coordonnées d’identifications et lance une requête de
connexion
4. Le système vérifie les coordonnées fournies puis authentifie l’utilisateur si les
coordonnées fournies sont correctes
Scenarios alternatifs
3.a. Coordonnées incorrecte
1. le système affiche un message d’erreur et reprend à l’étape trois du scenario nominal
 27

sd S'authentifier

systeme

user

ref
créer Compte

Demander interface()

interfaceAffichée()

loop
Saisir coordonées()

verifier()

alt

[coordonnées]

break
User authentifier()

[sinon]
Login ou password incorrect()

Fig 3. 5—diagramme de séquence s'authentifier

 Interface graphique d’authentification est illustrée ci-après :

Pour consolider la description textuelle de notre système, nous présentons une interface
graphique illustrant l’authentification de l’utilisateur :
 28

Fig 3. 6—Ecran de saisi d'authentification

 Diagramme de classes participantes du cas d’utilisation s’authentifier :

Pour finir avec ce cas d’utilisation, nous illustrons les classes participantes mise en œuvre
lors de l’authentification de l’utilisateur.
class Use Case Model

utilisateur «dialog» Compte

EcranAuthentification GestionConnexion
id: int
- login: String + connecterUser(): void
login: String
- password: String + verifierConnexion(): void
password: String
+ valider(): void

Fig 3. 7—Diagramme de classes participantes d'authentification

2. Cas d’utilisation « créer compte »

Description textuelle du cas d’utilisation

- Objectif – Initialiser application avec les utilisateurs.

- Acteur concerné – Administrateur.
- Précondition – L’administrateur s’est authentifié correctement à l’application.
- Scénario nominal
1. L’administrateur crée un utilisateur avec ses caractéristiques : prénom, nom, mail,
profil.
2. L’application enregistre les informations renseignées et affiche un message de
confirmation.
3. Un mail est envoyé à l’utilisateur créé avec son identifiant/password.
 29

• Scénarios alternatifs

1a L’administrateur saisit un nom ou un prénom avec des chiffres.

- L’application affiche un message d’erreur précisant que le nom ou prénom sont des
chaînes de caractères uniquement. Le cas d’utilisation reprend au point 1.

1b L’administrateur saisit un nom ou prénom supérieur à 50 caractères.

- L’application affiche un message d’erreur précisant que le nom ou prénom sont des
chaînes de caractères inférieures à 50 caractères. Le cas d’utilisation reprend au point 1.

1c L’administrateur saisit un mail erroné (contrôle sur le @).

- L’application affiche un message d’erreur précisant que le mail n’est pas valide. Le cas
d’utilisation reprend au point 1.

Description des diagrammes d’analyse du cas d’utilisation

La suite de l’analyse du cas d’utilisation se poursuit par l’élaboration du diagramme de

séquence (fig. 3.7), l’élaboration de l’interface utilisateur (fig. 3.8) et l’élaboration du
diagramme de classe (fig. 3.9)

sd créer utilisateur

Admin
EcranUtilisateur GestionUtilisateur Utilisateur

ref
S'authentifier

utilisateur(nom, prenom, profil, email)

creerUser()

checkNomPrenom()

checkEMail()

genererIdentifiantMotDePasse()
creer()

envoiMail()

message()
Mail de confirmation envoyé à
utilisateur crée avec succès() l"utilisateur pour initialiser le mot de
passe du compte

Fig 3. 8—Diagramme de séquence du cas d'utilisation « Gérer utilisateur »

 30
ui Ecran saisie de consommation
Ecran de saisie des utilisateurs
Créer nouvel utilisateur

Infos utilisateur
Valider
Prénom

Modifier
Nom

Mail
Supprimer

Utilisateur
Profil

Fig 3. 9—Ecran de gestion compte utilisateur

Admin

<<dialog>>
EcranGestionUtilisateur <<control>> <<entity>>
GestionUtilisateur Utilisateur
-nom: String
-prenom: String -id: int
-email: String +creerUtilisateur() -nom: String
-profil: String +modifierUtilisateur() -email: String
+envoiMail() -prenom: String
+creerUtilisateur() +supprimerUtilisateur() -profil: String
+modifierUtilisateur() +afficherUtilisateur() -motDePasse: String
+supprimerUtilisateur()
+visualiserUtilisateur()

Fig 3. 10—Diagramme de classes participantes du cas d'utilisation Gérer utilisateur

4. Cas d’utilisation « Consulter Programme »

• Objectif : Permettre à l’internaute de consulter le programme des fournitures
• Acteur concerné : internaute
• Précondition : aucun
• Post condition : « programme consulter »
Scenario nominal :
1. L’internaute lance le système
2. Le système lui affiche le catalogue du programme
3. L’internaute choisi le programme souhaité et lance la requête de réservation
4. Le système lui redirige vers l’interface de paiement
• Scenario alternatif : aucun
 31

sd Consulter Programme

Systeme

Internaute

Demander Interface progamme()

Interface affichée()

loop
selectionner Progamme()

break

DetaileProgramme()

Fig 3. 11--diagramme de séquence consulter programme

Interface utilisateur de consultation de programme de voyage

 32

ui Consulter programme Bus

Interface utilisateur consultation programme

Programme de Voyage

Recherche par Date .../.../.... Recherche par Destination

KOLWEZI

Rechercher Réserver

Résultat de la recherche

1. Programme Heure voyage Ville départ Destination

Fig 3. 12—Interface utilisateur de consultation de programme de voyage

Pour terminer l’analyse du cas d’utilisation « Consulter programme » nous dressons un
diagramme de classes participantes :

Internaute
<<dialog>>
EcranConsultation <<entity>>
<<ctrl>> Programme
-numero: int GestionProgramme
-dateVoyage: date -numero: int
-heureVoyage: Time +rechercherProgramme() -dateVoyage: Date
-villeDepart: String +rechercherParDate() -heureVoyage: Time
-destination: String +rechercheParHeure() -villeDepart: String
-prixBillet: float +rechercheParDestination() -villeArrivee: String
+afficherPrixBillet() -prixBillet: float
+consulterParDate()
+reserverPlace()
+consulterParHeure()
+consulterParDestination()
+reserver()

Fig 3. 13—Diagramme de classes participantes du cas d'utilisation « consulter programme

bus »
5. Cas d’utilisation « Effectuer Réservation »
 33

• Objectif : Permettre au client de passer une réservation

• Acteur concerné : Client
• Précondition : S’authentifier •
• Post condition : Réservation effectuée
• Scenario nominal :
1. Le client lance l’espace de réservation
2. Le système affiche un formulaire
3. Le client saisit les informations nécessaires et valide sur ok
4. Le système affiche un récapitulatif des informations
5. Le système valide la réservation du client
6. Le système envoie la réservation à l’administrateur
7. Le système enregistre la commande
Scenario alternatif
1. Champs requis vides
1.a. Le système renvois un message d’erreur et reprend à l’étape 3 du scenario
nominal.
 34

sd Effectuer Reservation

Systeme

client

ref
S'authentifier

demander interface de reservation()

interface affichée()

Saisir coordonnée()

valider()

verifier()

alt

[info correct]

break
Reservation Effectuer()

[sinon]
Message erreur()

Fig 3. 14—diagramme de séquence effectuer réservation

Pour continuer avec l’analyse de cette fonctionnalité en présentant une interface utilisateur de
saisie de réservation dans la figure 3.15 suivante :
 35

ui Réservation place programme Bus

Interface utilisateur consultation programme

réservation Programme de Voyage

Recherche par Date .../.../.... Recherche par Destination

KOLWEZI

Nom client Téléphone +243

Nbre place réservés 1

Réserver Rechercher
Date réservation //***//****
Résultat de la recherche
1. Programme Heure voyage Ville départ Destination

Fig 3. 15—Interface Utilisateur de saisie de réservation de place

Pour terminer l’analyse de ce cas d’utilisation, nous donnons ci-dessous le digramme de
classes qui participent dans la réalisation de ce cas d’utilisation :

<<entity>>
Clients Programme
<<dialog>> -numero: int
EcranReservation -dateVoyage: Date
<<ctrl>>
-numero: int GestionReservation -heureVoyage: Time
-dateVoyage: date -villeDepart: String
-heureVoyage: Time +rechercherProgramme() -villeArrivee: String
-villeDepart: String +rechercherParDate() -prixBillet: float
-destination: String +rechercheParHeure()
-prixBillet: float +rechercheParDestination() 1
+afficherPrixBillet()
+consulterParDate()
+reserverPlace()
+consulterParHeure()
liée
+consulterParDestination()
+reserver()
1..*

<<entity>>
<<entity>> Reservation
Client
1 1..* -numero: int
-nom: String -date: Date
appartenir
-age: int -nbre: int
-telephone: int -numPlace: int

Fig 3. 16—Diagramme de classes participantes du cas d’utilisation « Effectuer réservation »

 36

Cas d’utilisation « Confirmer réservation »

• Objectif : Permettre au client de confirmer une réservation

• Acteur concerné : Client
• Précondition : Créer un compte, consulter programme, s’authentifier
 Post condition : Réservation confirmée
• Scenario nominal :
1. Le client saisi ces informations personnelles
2. Le système lui renvoi le formulaire récapitulatif à saisir
3. Le client saisi l’information et mode du paiement
4. Le système envoi les informations du client au système de paiement
5. Le système de paiement renvoi l’autorisation
6. Le système envoi le message d’une nouvelle confirmation a l’administrateur
7. Le système envoi un ticket de voyage au client
Scenario alternatif
1. aucun
 37

sd Confimer reservation

«Mulykap ticket» Systeme Paiement

Systeme
CLIENT Admin

alt

[visiteur]

ref
créer Compte

[Client]

ref
S'authentifier

ref
Consulter Programme

SaisirInfos(nom,telephone)

Recapitulatif saisie()

Infos Paiement(mode)

InfosPaiement(mode)

autorisation()

NouvelleReservationConfiremée()

resservation place()

Ticket de voyage ()

Fig 3. 17—diagramme de séquence confirmer réservation

Continuons l’analyse de ce cas d’utilisation en illustrant une interface utilisateur de la
confirmation de réservation en ligne de place ;
 38

ui Confirmer Réservation place

Interface utilisateur confirmer réservation

réservation Programme de Voyage

Recherche par Date .../.../.... Recherche par Destination

KOLWEZI

Nom client Téléphone +243

Nbre place réservés 1 Date réservation //***//****

Nom Passage Montant : 000

Mode paiement MpSA **** valider

Imprimer Ticket

Fig 3. 18—Interface utilisation de confirmation de réservation

Pour terminer l’analyse de cas d’utilisation de confirmation de réservation, nous illustrons
ci-après le diagramme de classes qui participent à sa réalisation :

<<entity>>
Programme
-numero: int
Clients -dateVoyage: Date
-heureVoyage: Time
<<dialog>> -villeDepart: String
EcranConfirmation -villeArrivee: String
<<ctrl>> -prixBillet: float
-numero: int GestionConfirmation
-dateVoyage: date
-heureVoyage: Time 1
+rechercherProgramme()
-villeDepart: String liée 1..*
+rechercherParDate()
-destination: String +rechercheParHeure()
-prixBillet: float <<entity>>
+rechercheParDestination()
-modePaiement: List Reservation
+afficherPrixBillet()
-telephoneClient: int +reserverPlace() -numero: int
-codeSecret: int +confirmerPaiement() -date: Date
+consulterParDate() +imprimerTicket() -nbre: int
+consulterParHeure() -numPlace: int
+consulterParDestination()
+reserver() 1..*
+confirmerReservation()
appartenir
+imprimerTicket() 1

<<ctrl>> <<entity>> <<entity>>

APIPaiement Client
Paiement
effectuerpar -nom: String
+post() -numero: int
-date: Date -age: int
+get()
-montant: float -telephone: int
-refpaiement: String
-mode: String

Fig 3. 19—Diagramme de classes participantes du cas d'utilisation Confirmer réservation

 39

6. Cas d’utilisation « Gérer programme »

• Objectif : Permettre à l’administrateur de gérer les programmes

• Acteur concerné : Administrateur
• Précondition : s’authentifier
Post condition : Catalogue gérer
Scenario nominal :
1. L’administrateur lance l’espace de gestion des programmes
2. Le système affiche l’interface
3. L’administrateur choisit les options suivantes :
a. Ajouter d’une destination au programme
a.1. L’administrateur sélectionne l’ajouter d’une destination au programme
a.2. Le système affiche un formulaire
a.3. L’administrateur remplit les informations et valide sur ok

Le s b. Cas d’utilisation « Gérer programme »

• Objectif : Permettre à l’administrateur de gérer les programmes des utilisateurs

• Acteur concerné : Administrateur
 Précondition : s’authentifier
 Post condition : compte géré
• Scenario nominal :
1. L’administrateur lance l’espace de gestion des programmes
2. Le système affiche l’interface
3. L’administrateur choisit les options suivantes :
a. « Modifier »

a.1. L’administrateur clique sur une destination

a.2. Le système affiche les détails de la destination
a.3. L’administrateur saisi les nouvelles informations et valide sur ok
a.4. Le système vérifie les informations saisies par l’administrateur
a.5. Le système affiche un message « mise à jour effectuée »
b. « Supprimer destination »
b.1. L’administrateur clique sur une destination
b.2. Le système affiche les détails de la destination
b.3. L’administrateur clique sur supprimer la destination
 40

b.4. Le système affiche un message « suppression réussie »

• Scenario alternatif :
1.a. l’administrateur ne fournit pas les informations de mise à jour
1. le système affiche un message d’erreur et le cas d’utilisation reprend à
l’étape a.3 du scenario nominal.
2.a. le système détecte un dysfonctionnement dans le processus de création d’un nouveau
rapport :
1. Le système signal le dysfonctionnement au décideur et prévient l’équipe informatique pour
engager des actions de maintenance. Le cas d’utilisation se termine en
échec
 41

sd Gerer programme Voyage

Admin
EcranProgrammeBus ControleurBus List<Programme>Programme

ref
S'authentifier

saisirProgramme(date, heure, destin, prix, bus)

creerProgramme(id, dat, heure, dest)

addProgramme()

afficher()

programme affiché avec succè()

opt editerProgramme(id, dt, h)

editerProgramme()

update()

afficher()

programme modifié avec succé()

opt
annulerProgramme(id)

annulerProgramme(id)

annuler()

afficher()

programme de voyage annulé()

Fig 3. 20—diagramme de séquence gérer programme

 42

Interface utilisateur du cas d’utilisation « Gérer programme »

ui Confirmer Gérer programme de voyage

Interface utilisateur Gérer programme de voyage

Gestion de Programme de Voyage

Recherche par Destination

Recherche par Date .../.../....
KOLWEZI
Heure départ .../...

Prix place Bus n°

Ville départ Lubumbashi

publier programme Annuler Supprimer

Fig 3. 21—Interface utilisateur du cas d’utilisation « Gérer programme »

Le diagramme de classes participantes du cas d’utilisation « Gérer programme » est donné ci-
après :

class DCP gerer Programme

Gerer Programme
«ctrl» «entité»
- date: date CtrlGererProgramme Programme
- password: int
- annuler: int + date(): void
+ ajouter(): void - valider: int + destination(): void
Admin + annuler(): void + heurDepart(): void
+ modifier(): void
1..*

conserne

1..*

«entité»
destination
- date: date
- description: string
- NomDestination: string

Fig 3. 22—Diagramme de classes participantes Gérer programme

 43

3.4. SYNTHESE D’ANALYSE

3.4.1. ELABORATION DU DIAGRAMME DE CLASSE RECAPITULATIF

class diagramme de classe recapitulatif

1..* gerer
gerer
Programme user 1..*
1 1
- bus: string - id: int
- dateDepart: string - mail: string Administrateur
- Destination: string - nom: string
- id: int - password: string - matricule: string
- prenom: string
+ ajouter(): void
+ modifier(): void
+ rechercher(): void
+ supprimer(): void

1..*
LigneProgramme consulter Client

- DateDepart: date - id: string

- destination: string - sexe: string
- heureDepart: string - telephone: string
1..*
+ reserver(): void 1..*

Reservation
Place
- dateReserv: date
- id: string demander
- destination: string
- type: string concerner - id: int 1
+ ajouter(): void 1..* 1 - type: string
+ modifier(): void + annuler(): void
+ rechercher(): void + demander(): void
+ supprimer(): void + modifier(): void

Fig 3. 23—diagramme de class récapitulatif

3.4.2. Découpage en catégorie

Le découpage en catégories constitue la première étape de cette phase qui contient d'un
coup le découpage choisi ainsi que les informations concernant le modèle statique (classes,
attributs, méthodes) et qui va s'affiner de manière itérative au cours du développement du
projet[9].
 44
class Use Case Model

progVoyage

AgenceVoyage
InfoArret
- nom
- /duree
- numImpot
- heureArrivee
- siege
- heureDepart
+reference 1
proposer
1..*
depart
VoyageEnBus
Ville 1 0..*
- dateArrivee
- nom - dateDepart
arrivee - /duree
1 0..* - heureArrivee
0..* - heureDepart
0..*
{ordered} + fermerReservation(): void
+ ouvrirReservation(): void

{frozen} 1

concerner

«import»
1..*
ReservationVoyage {frozen}

Reservation effectuer Client

1..* 1
- date - adresse
- numero - nom
- numTel
+ annuler(): void
- prenom
+ confirmer(): void
0..*
concerne
1

Passager
- nom
- prenom

Fig 3. 24—Découpage en catégorie

3.4.2. ÉLABORATION DE LA MATRICE DE VALIDATION

La matrice de validation permet de vérifier que l’analyse du cas est complète, c’est-
à-dire que tous les cas d’utilisation métier ont été intégrés. Elle permet aussi d’établir une
correspondance entre les cas d’utilisation métier et les cas d’utilisation d’analyse.
 45

Tableau 2—Matrice de validation

3.4.3 Digramme de navigation Globale

act Diagramme de navigation general

Client
visiteur
Consulter Programme

visiteur
Créer compte

gerer
Acceuil reservation
Artifact3
user
S'authebtifier
payer billet

Fig 3. 25—Diagramme de navigation globale

 46

3.4. CONCEPTION DETAILLEE DE L’APPLICATION

Il s’agit d’un affinement de ce que nous avons réalisé de façon générique dans la section
précédente. Cela revient à dire que nous allons maintenant incorporer dans nos diagrammes le
choix d’architecture et les choix technologiques qui vont modifier les classes de conception
préliminaire, les préciser, ajouter de nouvelles classes plus techniques, etc. Nous allons détailler
en particulier comment se traduisent les trois types de classes d’analyse avec les différentes
solutions technologiques.

5.1 ÉLABORATION DES DIAGRAMMES DE SEQUENCE TECHNIQUE

1. opération système « s’authentifier »

sd S'authentifier

client
accueil form d'authentification ctrl user user

demander authentification()

interface afficher()

loop saisir()

valider()

demande connexion()

verifier()
select *from()

alt

[info correct]

break donnees recuperer()

ouvrir session()

[info incorrect]
donnees non trouvées()

msg erreur *données incorrect*()

[champ vide]
champ non renseigner()

Fig 3. 26—Diagramme d'interaction s'authentifier

 47

c) Opération système : Effectuer payement

sd Effectuer Payement

Systeme Payement

internaute
interface d'accueil formulaire ctrlCompte user

ref
Consulter Programme

demander formulaire()

Demander formulaire()

Afficher formulaire()

loop
saisir formulaire()

verifier()

effectuer payement()

verifier donnees()

verifier()

changer donnees()

alt

[Montant suffisant]

break inserer info()

Msg succes()

msg payement effectué()

[montant insuffisant] données non charchés()

Msg erreur* solde insuffisant*()

Fig 3. 27—Diagramme d'interaction effectuer paiement

d) Opération système : Créer Compte
 48

sd Diag Interact Creer compte

Internaute
Interface Accueil Formulaire CtrlCompte Client

Demander Formulaire()

formulaire compte()

InterfaceAffichée()

loop
Remplir Formulaire()

Valider()

CreerCompte()

Verifier()

alt

[Info Correct]

loop Insert Info()

User enregistré()

Msg succes()

Msg erreur()
[info incorrect]

[Champ vide]
Msg()

Fig 3. 28—Diagramme d'interaction créer compte

e) Opération système : Consulter programme
 49

sd Consulter Programme

Client
Accueil InterfaceProgramme CtrlProgamme Programme

Demander catalogue programme()

Interface Programme()

Select* from()

Recuperer Donnees()

Afficher Interface()

Fig 3. 29—Diagramme d'interaction consulter programme

f) Opération Système : Gérer réservation
 50

sd Diag interact gerer Reservation place

Client
Interface Formulaire CtrlReservation Reservavtion
Programme reservation
ref
Consulter Programme ou catalogue

Demander formulaire de Reservation()

Formulaire reservation()

ref
S'authentifier

opt
Afficher formulaire()
[Reverver place]

loop
ref
Effectuer reservation

alt
[donnees correct]
break inserer info()

new reservation()

afficher resultat de la reservation()

[donnees incorrect]msg erreur * données incorrect*()

[champ vide] msg erreur*champs non renseignés*()

[Annuler Reservation]
annuler reservation()

annuler reservation()

Demander confirmation()

alt
confirmer annulation()
[confirmer]
annuler reservation()

delete*from()

reservation supprimer()
reservation annuler()

[sinon]
annuler confirmation()

annuler()

Msg annulation()

Fig 3. 30—Diagramme d'interaction gérer réservation

g) Opération système : Effectuer réservation
 51

sd Effectuer reservation

client
interface reservation ctrlReservation

Saisir()

valider()

Reserver()

verifier()

Fig 3. 31—Diagramme d'interaction effectuer réservation

3.5.2. ÉLABORATION DES DIAGRAMMES DE CLASSE TECHNIQUE

1. Cas d’utilisation 1 : « Consulter programme »

class Class DCC consulter programme

«dialogue» programme
CatalogueProgramme «ctrl» - bus: string
ctrlProgramme - dateDepart: date
- programme: int - destination: string
+ annuler(): void
- vente: date
+ annuler(): void + reserver(): void
+ reserver(): void + delete(): void
internaute
+ insert(): void
+ select(): void
+ update(): void

Fig 3. 32—Diagramme de classe de conception consulter programme

Cas d’utilisation 2 : «créer compte»
 52

class DCC créer compte

«interface» «ctrl» «entité»

creer Compte creerCompte user

+ valider(): void + valider(): void - iduser: int

- nom: string
internaute
- password: int

«entité»
Client

- adresse: string
- idClient: int
- nom: string
- password: int
- prenom: string
- telephone: int

Fig 3. 33—DCC créer compte

Cas d’utilisation 3 : « réservation place »

class DCC reserver place

«dialogue»
formReserv

- destination: string
- nom: string
- prenom: string

+ annuler(): void «entité»

+ reserver(): void Reservation
«ctrl»
- dateReservation: date
ctrlReserv
- destination: string
Client + annuler(): void - id: int
+ reserver(): void - type: string
+ valider(): void
+ delete(): void
+ insert(): void
+ select(): void
«dialogue» + update(): void
Resultat Reserv

- resultat reserv: int

+ annuler(): void
+ valider(): void

Fig 3. 34—DCC réserver place

Cas d’utilisation 4: «effectuer payement »
 53

class Class DCC effectuer payement

«entité»
payement

- code: int
- num: int
«interface»
payement + ajouter(): void
«ctrl» + modifier(): void
- code: int
payement + selectionner(): void
- num: int
- annuler: int
Client + annuler(): void
- valider: int
+ valider(): void

«entité»
Client

- adresse: string
- idClient: int
- nom: string
- password: int
- prenom: string
- telephone: int

Fig 3. 35—DCC effectuer payement

Cas d’utilisation 5 : Diagramme de conception globale
class Use Case Model

AgenceVoyage
- nom Client
- numImpot - adresse
- siege - nom
+reference 1 - numTel
- prenom
proposer {frozen} 1

1..* effectuer
depart 1..*
VoyageEnBus
Ville 1 0..*
- dateArrivee Reservation
- nom - dateDepart {frozen}
arrivee concerner - date
- /duree - numero
1 0..* - heureArrivee 1 1..*
0..* - heureDepart + annuler(): void
0..* + confirmer(): void
{ordered} + fermerReservation(): void
+ ouvrirReservation(): void 0..*
concerne
InfoArret 1
- /duree Passager
- heureArrivee
- heureDepart - nom
- prenom

Fig 3. 36—DCC global

 54

3.5.4. ÉLABORATION DU DIAGRAMME DE PAQUETAGE

Il existe différentes sortes d’architecture, elles sont associées à différents niveaux du

système. En termes d’architectures techniques, les plus connues sont : l’architecture à trois tiers
(3 niveaux) et l’architecture client-serveur. Ce type d’architecture se base sur le fonctionnement
logiciel de l’application.

L’architecture à 3-tier dispose de trois grands niveaux : le navigateur web, le serveur

HTTP et enfin le second serveur qui sollicite une base de données. Le point fort de ce modèle
est qu’on peut envisager la bonne gestion des données des utilisateurs. En plus du premier
serveur HTTP, dans ce système, on ajoute un serveur secondaire qui est le serveur de base de
données.

Tous les paquetages de l’application sont représentés sur la figure 45:

 Dialogue – Paquetage regroupant l’ensemble des classes permettant la gestion des

dialogues de l’application :
- Dialogue VueCatalogue.
- Dialogue Recherche Programme.
- Dialogue saisir Réservation.
- Dialogue Confirmation Réservation.
- Dialogue s’authentifier.
- Dialogue Créer Compte.
- Saisie programme de voyage
 Contrôleur – Paquetage regroupant l’ensemble des classes permettant la gestion des
contrôleurs de l’application :
- CTRL Catalogue.
- CTRL Réservation.
- CTRL Authentification.
- CTRL Confirmation.
- CTRL Créer Compte.
 Entité – Paquetage regroupant l’ensemble des classes métiers de l’application. À l’intérieur
de ce paquetage, une division en trois sous-paquetages est présente qui correspond à un
découpage fonctionnel. Ces trois sous-paquetages sont les suivants.
- Gestion des clients – Paquetage regroupant l’ensemble des classes permettant la
gestion des données de clients :
 55

 Client.
 Compte.
 Passager
- Gestion Catalogue– Paquetage regroupant l’ensemble des classes permettant la
gestion des données relatives aux activités de saisie de programmation :
 Catalogue.
 Programme
 Ville Départ
 destination

- Gestion Réservation – Paquetage regroupant l’ensemble des classes relatives à la

réservation, confirmation de réservation :
 Réservation.
 Paiement

pkg Gestion Réservation

Entity

Gestion Catalogue
Gestion Clients
Dialogue
«import»
Controleur
+ EcranAuthentification
+ EcranCatalogue + CTRLAUthentifications
+ EcranConfirmation «import» + CTRLCatalogue
«import»
+ EcranGestionCompte + CTRLProgramme «import» «import»
+ EcranReservation + CTRReservation
Gestion Réservation

Fig 3. 37—Diagramme de paquetage

3.5.5. Architecture de l’application

Un système de réservation de place en ligne nécessite une architecture client-serveur dont
la responsabilité du client se limitera à afficher les pages et faire quelques traitements locaux.
Ainsi une architecture Web légère composée des éléments suivants a été choisie :

- Les éléments de présentations : pour mettre l’interaction avec l’utilisateur final

- Une application Navigateur qui a pour rôle d’interpréter les balises html et tous les
langages client (HTML, CSS, JavaScript)
 56

- Un serveur Web Apache pour la gestion de pages Web et l’interaction de la partie

dynamique avec le module de PHP
- Un composant PHP Data Object (PDO) pour la connexion avec les sources de données
MySQL
- Une source de données MySQL permettant l’interfaçage avec le serveur de base de
données MySQL
- Un serveur de base de données ou Système de Gestion de Base de Données MySQL
(SGBD) pour l’administration de la base de données
- Les différents composants applicatifs conçus de notre système (classes métiers). La
Figure 46 suivante illustre la structure logicielle de notre système.

Figure 3 . 38 Architecture technique de la solution

3.5.6. ÉLABORATION DU MODELE LOGIQUE

3.5.6.1. Règles de passage en modèle logique de données (MLD)
A partir du diagramme des classes récapitulatifs nous pouvons déduire un
modeler logique qui est un modèle plus proche de l’implémentation. Le passage du
diagramme de classes (entités) en modèle logique se fait sur base de certains réglés,
appelées règles de transformations. Voici donc ces différentes règles :
 57

1. Règles des classes

• Toutes les classes deviennent des tables en MLD.

• Les attributs de la classe deviennent des champs de la table.

• L’identifiant de la classe devient la clé primaire de la table.

2. Règles des relations

a. Relation 1 à 1
Il existe deux règles pour transformer la relation 1 à 1 :

• La fusion des deux classes qui participent à la relation si et

seulement si les deux classes sont issues d’une même
fonctionnaliste. Et le nom de la nouvelle classe sera la concaténation
de deux classes en relation. Avantage : diminution des accès à base
des données
• La clé primaire issue de la classe de la première fonctionnalité migre
vers la classe issue de la deuxième fonctionnalité, elle devient ainsi
la clé étrangère dans la nouvelle table.
b. Relation 1 a plusieurs
Dans ce type de relation la transformation se fait en migrant la clé primaire
issu de la classe parent (à multiplicité maximal de 1) vers la classe enfant
(à multiplicité maximal de *), l’attribut ainsi ajout joue le rôle de la clé
étrangère
c. Relation plusieurs à plusieurs

Il existe deux type de relation plusieurs à plusieurs, une relation 2-tiers et

une relation N-tiers. Dans les deux cas l’association déduit une classe-
association qui aura comme clé primaire la concaténation des clés
primaires des classes qu’elle relie. La clé primaire de la nouvelle table
issue de la classe-association dérive de la concaténation de deux clés
primaire des classes en association.
d. Règle de la relation réflexive

On crée un nouvel attribut dans la table de transformation pour gérer les deux
relations.
 58

e. Règle des agrégations

Elle est transformée comme une classe association. La relation devient la
table et la clé primaire est la concaténation des deux clés primaires des
classes associations.
f. Règle de la composition
Pour la relation de composition on ajoute la clé primaire de la table
déduite de la classe composite ou de l’agrégat à la clé primaire déduite de
la classe composante. L’attribut ainsi ajouté joue le rôle de la clé primaire
et étrangère.
g. Règles d’héritage

• Transformation par distinction : on fait appel à l’héritage exclusif

dont la classe abstraite n’existe pas.
• Transformation descendante : elle fait appel à la contrainte de
partition. C’est-à-dire l’héritage non complet. On parle de la
spécialisation (la surclasse est une classe abstraite. Ses instances
migrent dans la sousclasse).
• La transformation ascendante : elle fait appel à la contrainte de
totalité.

C’est-à-dire l’héritage complet. On parle de la généralisation.

 59

3.5.5.2. Transformation en modèle logique

Fig 3. 38—Modèle Physique de données

3.5.5.3. Diagramme de déploiement

C’est un diagramme appartenant à la catégorie des diagrammes structurels, dont le but

est de montrer le déploiement physique des artéfacts (éléments concrets tels que fichiers,
exécutables, etc.) sur les ressources matérielles.
 60

deployment Deployment Model

Poste-Internaute

«Compo...
Navigateur.exe

http80
Serveur Web

Poste-client «compone...
Web Apache «compone...
API Systeme
«compone... http80 tcp/ip
Paiement
Navigateur

«compone...
PHP

htttp80

poste-Admin tcp/ip

«compone...
Navigateur

Serveur Base de
Données
«compone...
Mysql

BD.SQL

Fig 3. 39—Diagramme de déploiemen

tConclusion partielle
Ce chapitre avait pour objectif de concevoir l’architecture détaillée de l’application
MULYKAP TIKCET. Sur ce, nous avons analysé et réalisé les cas d’utilisation au moyen des
outils suivants : la description textuelle, diagramme de classes participantes, les diagrammes de
séquence ; pour spécifier d’avantage les détails d’implémentation, nous avons construit de
diagramme de séquences détaillées pour les opérations de système MULYKAPTICKET
identifié précédemment, le diagramme de classes de conception ainsi qu’un modèle de base de
données. Le prochain chapitre se consacre à l’implémentation et à la présentation de résultats.
 61

CHAPITRE IV : RESULTAT DE LA RECHERCHE

4.1. Introduction

Ce chapitre, a pour objectif d’implémenter les classes de conception obtenue dans le

chapitre précédant dans langage de programmation afin de faire de tests de la solution de
passation de commandes en ligne. Pour cela, certains choix techniques sont inévitables.

4.2. Choix des outils de développement

Pour développer notre application, nous avons besoin de 4 outils indispensables

d'un développeur Web suivants :

1 – L'éditeur de texte. Tel le marteau d'un ouvrier, l'éditeur de texte est l'outil principal et
indispensable d'un développeur. ...
2 – un serveur Web qui va se charger de la gestion du contenu de notre site Web
3 – Un module PHP pour interpréter les codes dynamiques de notre application
4 – Un serveur de base de données
D’autres outils sont nécessaires à différents niveaux pour la réalisation de certaines
tâches.

4.2.1. Choix de Langages coté Client

De nos jours, il existe plusieurs langages de programmation qui ont vu le jour pour
permettre au programmeur de structuré les codes des applications Web en fin de mettre, mais
pour notre cas nous avons choisi le langage de programmation PHP couplé au langage balisé
HTML pour nous faciliter la conception de notre application.

 Le HTML (HyperText Mark up Langage) qui est un langage de description de données,

et non un langage de programmation, Le langage HTML se décrit comme un ensemble
de balises ouvrantes et fermantes qui contiennent le contenu (texte, image, animation)
et qui sont interprétées par le navigateur client (Internet Explorer, Netscape, Mozilla,
Firefox, …). L’interprétation de certaines balises peut varier d’un navigateur à l’autre5.
(Ex : taille des textes). C.à.d. HTML c’est un langage de balisage.
 Le JavaScript : est un excellent langage, qui des années s’imposer comme une
technologie vraiment incontournable dans le web. Le nombre de sites qui utilisent
désormais JavaScript est tout simplement gigantesque. L’avènement du web 2.0, un web
communautaire où les Web masters cherchent à faire interagir toujours plus l’utilisateur
 62

avec le site. JavaScript est un langage tout indiqué pour répondre à ce besoin, expliquant
ainsi en partie son succès. Un beau paysage pour JavaScript.
 Le CSS : CSS (Cascading Style Sheets) : Son rôle est en quelque sorte de « décorer »
votre site web, lui donner de l’allure. On utilise le CSS en particulier pour réaliser la
mise en page du site, pour définir la police, la taille du texte, la couleur du texte et du
fond.

4.2.2. Langages de programmation coté serveur

Pour que la base de données puisse être mise à jour, modifiée, ou que des éléments (nouvel
utilisateur, par exemple) puissent s’intégrer à la base préexistante, le développeur back-end va
utiliser des langages dynamiques, lesquels vont connecter la base de données avec l’application.

Pour cela, le développeur back-end va avoir tendance à utiliser les langages :

 PHP

 Ruby

 Python

Pour nous, le choix traditionnel de PHP sous semble justifié et motivé par la simplicité et
la disponibilité de la documentation et d’aides en lignes.

 Le PHP : Le sigle PHP signifiait à l’origine Personal Home Page. Pour Ras mus Elsdorf,
l’auteur de ce qui allait devenir le langage de script côté serveur incorporable dans tout
document XHTML que nous connaissons, il s’agissait alors d’ajouter quelques
fonctionnalités à ses pages personnelles. PHP signifie aujourd’hui Hypertexte
Préprocesseur car il renvoie à un navigateur un document XHTML construit par le
moteur de script Zend Engine 2 de PHP, dont nous allons voir le fonctionnement. Il
permet de créer des pages Web dynamiques et interactives.

4.2.3. Le Serveur Web Apache

Apache est un logiciel de serveur web gratuit et open-source qui gère de ressources de
sites à travers le Web. Son nom officiel est Serveur Apache HTTP et il est maintenu et
développé par Apache Software Foundation.

Il permet aux propriétaires de sites web de servir du contenu sur le web – d’où le nom
« serveur web » -. C’est l’un des serveurs web les plus anciens et les plus fiables avec une
première version sortie il y a plus de 20 ans, en 1995
 63

Fig.4. 1—apache http server

4.2.4. Serveur de base de données

Dans le back-end, il est également question de construire la base de données de sorte à

conserver dans des informations structurées dans de tables spécifiques constituant ainsi les
données nécessaires au fonctionnement de l’application.

Cette base de données est généralement placée sous la responsabilité d’un logiciel
spécialisé pour la gestion appelé Système de Gestion de Base de Données (SGBD). Et pour cela
nous avons jeté notre dévolu sur le logiciel MySQL.

Fig.4. 2—logo MySQL

MySQL fait partie des Systèmes de Gestion de Bases de Données Relationnelles les plus
populaires. Connu au monde de SGBDR depuis 1994 sous la responsabilité de MySQL, le
logiciel est désormais géré par Oracle Corporation. Le logiciel est distribué sous deux licence
entreprise ou payant et GPL (General Public Licence) gratuit. Une autre version existe
spécialement pour la gestion de bases de données distribuées (MariaDB).

4.3. Discussion

Le processus de développement logiciel informatique suit une séquence d’étapes appelées

« cycle de vie logiciel » lequel oblige à chaque module développé de subir de transformation
 64

avant d’arriver à l’utilisation réelle. Ainsi par rapport à notre projet, l’implémentation est faite
de manière itérative et incrémentale.

Nous allons donc présenté le travail successif réalisé dans chaque cas d’utilisation.

Eu égard aux objectifs de cette étude, nous confirmons que les hypothèses ont été
confirmées. Le prototype réalisé n’est qu’une première itération de l’application
MULYKAPAPP, et dispose les options suivantes : un module de recherche en ligne de
programme de voyage, une option de sélection de programme pour effectuer sa réservation de
partout où on se trouve ; un module de confirmation de la réservation en ligne incluant une
possibilité de payer par Mobil Money, ou en espèce afin d’entrer en possession de son ticket de
voyage en bonne et due forme dans un bref délai ; un module pour suivre en temps réel
l’évolution de la réservation en cas non confirmation pour une mise à jour automatique selon le
délai; et un module de gestion de programme. Désormais les clients de MULYKAP ne peuvent
plus se soucier de la distance, de la perte du ticket avant le voyage car désormais un espace
client est disponible en ligne pour effectuer ses réservations, imprimer ses tickets.

Signalons aussi que les objectifs fixés se heurtent une résidence technique due à l’accès
refusé à l’API de paiement par les porteurs Mobiles. Néanmoins, une simulation est faite avec
de données d’essai.

a) Page d’accueil

La page d’accueil suivante permet de visualiser le programme de voyage avec possibilité

de réserver une place et la confirmée en ligne. L’utilisateur a la possibilité de se connecter en
tant que client ou Internaute pour finaliser sa commande.

Le programme de voyage est affiché avec les détails comme la date, l’heure, la
destination, le nombre d’escale, le prix, la photo du bus aligné.
 65

Fig.4 1—Accuel du système

b) Présentation de l’authentification

L’authentification permet de sécuriser les sessions utilisateurs et leurs informations lors

de la passation de commande.

Fig.4 2—Interface d'authentification

c) Mise en jour du programme de voyage

 66

L’IHM suivante permet à l’admin d’ajouter, de modifier ou de supprimer un programme

de voyage.

Fig.4 3—Interface utilisateur de gestion de programme

d) Ecran Réservation place

La réservation permet à un client après avoir sélectionné un programme, de fournir les
informations ainsi que les coordonnés de paiement.
 67

Fig.4 4—Interface utilisateur de réservation de place

Après remplissage de données du client, le système lui oblige de fournir les données de
paiement :

Fig.4 5—Interface de confirmation Réservation

e) Impression Ticket en ligne
 68

Fig.4 6--Inteface Tocket voyage

 69

CONCLUSION GENERALE

Après ces tournures de langages, nous voici à l’apogée de notre mémoire qui a consisté
sur « la conception par la méthode UP7 d’une application web de réservation des billets de
bus» qui constitue de nos jours un domaine convoité de l’ère du numérique. L’objectif de cette
étude été de solutionner la problématique de réservation de place en ligne en mettant en place
une application web capable de rendre ce genre de service à la population lushoise d’une part
et aux agents de l’agence de rationaliser le processus métier.

Pour y arriver, la méthodologie UP7 (Unified Process en sept étapes) avec le langage
UML (Unified Modelong Language) ont été la cible de cette recherche pour la conception de
note application Web MULYKAPAPP dont la subdivision est la suivante : le premier chapitre
nous avions abordé la revue de la littérature sur la conception Web ; le second chapitre nous a
permis de faire l’analyse métier afin de comprendre l’existant en termes des activités, acteurs,
informations et règles de gestion sur la réservation de place, le mode de paiement, la prise de la
place à bord d’un Bus MULYKAP au moyen de diagrammes UML de cas d’utilisation,
d’activité et de classes du domaines ; le troisième chapitre été pour nous l’application de la
méthode UP7 pour concevoir l’architecture de l’application de réservation de ticket en ligne;
enfin le quatrième chapitre nous avons présenté les résultats de l’étude après l’implémentation
l’architecture logicielle de MULYKAPAPP afin d’avoir une application Web permettant aux
clients de s’en passer de limite géographique pour avoir une place à bord d’un bus.

Ainsi nous confirmons nos hypothèses dans la perspective d’autorisation d’accès aux
APIs de paiement de banques Mobile. Notre étude a suivi une démarche rigoureuse intégrant
les principes du génie logiciel comme la modularité, le faible couplage et une forte cohésion
interne.

Signalons que le domaine d’e-commerce restent complexe pour nous, sur ce, nous
ouvrons une perspective de recherches à venir sur la réservation par QR-Code.
 70

BIBLIOGRAPHIE

[1] L. Debrauwer et F. Van Der Heyde, « UML 2.5 », Barcelona: Editions ENI. Obtenido de
https://books. google. com. ec/books, 2016.
[2] D. O. LUKENDO, N. C. AUGUSTIN, et C. Z. KALUMUNA, « Démarche UP7 pour la
conception d’un système de suivi de près du processus de retrait des diplômes et relevés
de notes aux seins des institutions supérieures et universitaires, cas de l’ISP/Bukavu. »,
Revue Internationale du Chercheur, vol. 1, no 4, 2020.
[3] P. G. OPRESCU, « GENERAL E-BUSINESS METHODS IN AGILE CONTEXT ».
[4] I. F. Schlömer, « Agility as a Driver of Digital Transformation-a Literature Review »,
dans Conference on e-Business, e-Services and e-Society, Springer, 2022, p. 238‑253.
[5] M.-R. Yan, N. Tran-Danh, et L.-Y. Hong, « Knowledge-based decision support system
for improving e-business innovations and dynamic capability of IT project management »,
Knowledge Management Research & Practice, vol. 17, no 2, p. 125‑136, avr. 2019, doi:
10.1080/14778238.2019.1601507.
[6] S. Legras, « L’agilité, nouvelle transformation pour l’entreprise », Documentaliste-
Sciences de l’Information, vol. Vol. 51, no 4, p. 4‑6, 2014, doi: 10.3917/docsi.514.0004.
[7] B. Gâteau, D. Khadraoui, et E. Dubois, « Architecture e-business sécurisée pour la gestion
des contrats », dans 3eme Conférence sur la Sécurité et Architectures Réseaux (SAR). La
Londe-France, 2004.
[8] R. N. NYATE et al., « L’AGILITE AU SERVICE DE E-BUSINESS: CONCEPTION
D’UN SYSTEME D’E-COMMERCE DE VENTE EN LIGNE DE TICKETS DE TRAIN
A LA SOCIETE NATIONALE DE CHEMIN DE FER DU CONGO (RDC) », Revue
Internationale du Chercheur, vol. 4, no 1, 2023.
[9] A. da S. Lima, UML 2.5-do Requisito a Solução. Saraiva Educação SA, 2005.