Table des matières

Introduction : ............................................................................................................................. 4
Objectifs : ................................................................................................................................... 4
Phase d’analyse : ....................................................................................................................... 5
• Étape 1: Capture des exigences fonctionnelles ............................................................................. 5
 Diagramme de cas d’utilisation : ........................................................................................................... 5
 Fiche descriptive des cas importants : ................................................................................................... 7
 Prototypes des interfaces ....................................................................................................................... 7
• Étape 2 : Étude du modèle statique : ............................................................................................. 7
 Diagramme de classe :........................................................................................................................... 7
 Dictionnaire de données : ...................................................................................................................... 8
• Étape 3 : Étude du modèle dynamique: ........................................................................................ 9
 Scénarios de Modélisation Dynamique ............................................................................................... 10
Phase de conception : .............................................................................................................. 13
• Étape 1: Conception générale : .................................................................................................... 13
 Répartition en Paquetages ................................................................................................................... 13
 Relation entre les paquetages : ............................................................................................................ 14
 Diagramme de composant du logiciel : ............................................................................................... 15
 Diagramme de Déploiement Intégrant les Composants : .................................................................... 16
• Étape 2 : Conception détaillée :.................................................................................................... 17
 Diagrammes de classes techniques des différents paquetages : .......................................................... 17
 Diagrammes de séquence technique et réalisation de l’approche MVC pour l’architecture de projet :
19
Phase d’implémentation :................................................................................................................ 20

Tableaux :
Tableau 1: Les acteurs du système ............................................................................................. 5
Tableau 2: Cas d'utilisation ........................................................................................................ 6
Tableau 3: Paquetages .............................................................................................................. 13

Table des figures

Figure 1: Diagramme de cas d'utilisation ................................................................................... 6
Figure 2: Prototype d'interface ................................................................................................... 7
Figure 3: Diagramme de classe .................................................................................................. 8
Figure 4: Diagramme du séquence -Prendre une réservation................................................... 10
Figure 5: Diagramme de séquence - Gérer l'arrivée d'un client ............................................... 11
Figure 6: Diagramme de séquence - Annuler une réservation ................................................. 11
Figure 7: Diagramme de Séquence - Modifier une Réservation .............................................. 12

2
Figure 1: Diagramme de cas d'utilisation ................................................................................... 6
Figure 2: Prototype d'interface ................................................................................................... 7
Figure 3: Diagramme de classe .................................................................................................. 8
Figure 4: Diagramme du séquence -Prendre une réservation................................................... 10
Figure 5: Diagramme de séquence - Gérer l'arrivée d'un client ............................................... 11
Figure 6: Diagramme de séquence - Annuler une réservation ................................................. 11
Figure 7: Diagramme de Séquence - Modifier une Réservation .............................................. 12
Figure 8: Diagramme de composant du logiciel ...................................................................... 16
Figure 9: Diagramme de dépoloiement .................................................................................... 16
Figure 10: Diagramme de classe de paquetage IHM ............................................................... 17
Figure 11: Diagramme de classe de paquetage Métier............................................................. 18
Figure 12: Diagramme de classe de paquetage Persistance ..................................................... 18
Figure 13: Diagramme de classe de paquetage Service ........................................................... 18
Figure 14: Diagramme de classe de paquetage Util ................................................................. 19
Figure 15: Diagramme de séquence technique......................................................................... 20
Figure 16: Capture d'écran de console après exécution ........................................................... 21
Figure 17: Erreur confronté ...................................................................................................... 21

3
Introduction :
Dans un contexte où l'efficacité et la rapidité sont essentielles, la modélisation UML s'impose
comme une approche structurée pour concevoir et visualiser des systèmes complexes. Notre
projet, centré sur la modernisation des opérations d'un restaurant, s'appuie sur cette
méthodologie, avec l'utilisation de l'outil Modelio.

Ce projet vise à migrer d'un système manuel de réservation à une solution informatisée plus
agile et précise. L'outil Modelio, reconnu pour sa robustesse dans la modélisation UML, est
notre choix pour donner vie à cette transition. À travers une série d'étapes, de la capture des
exigences fonctionnelles à la synthèse, nous explorons l'ensemble du processus de conception.
Des diagrammes de cas d'utilisation aux modèles de classe, Modelio sera notre allié pour
traduire les besoins du restaurant en une représentation visuelle claire et compréhensible.

Cette introduction jette les bases de notre démarche axée sur la modélisation UML et
l'utilisation de Modelio. Elle souligne l'importance de cette approche méthodique dans la
création d'un système informatisé adapté aux défis actuels du restaurant, tout en offrant une
flexibilité pour évoluer avec les besoins futurs.

Objectifs :
• Application des concepts UML pour modéliser les processus de réservation et
d'attribution de tables.
• Création des diagrammes UML clairs pour représenter les interactions, les cas
d'utilisation, et les modèles statiques et dynamiques.
• Élaboration des prototypes d'interface basés sur les exigences fonctionnelles.
• Réalisation d’un modèle statique robuste via un diagramme de classe UML.
• Développement des diagrammes de séquence et d'états UML pour illustrer le flux des
actions.

4
Phase d’analyse :
Avant de procéder à la conception, il est important d’analyser d’abord la situation pour définir
avec précision les besoins, les exigences et les fonctionnalités du système.
Cette phase s'articule autour de trois axes majeurs :

• Étape 1: Capture des exigences fonctionnelles

 Diagramme de cas d’utilisation :

Nous débuterons par élaborer un "Diagramme des cas d'utilisation", une représentation
visuelle des interactions entre le système et ses acteurs clés. Après une lecture approfondie
des consignes, nous avons réussi à extraire les composants principaux de ce diagramme :

Les acteurs : sont des entités externes qui interagissent avec le système.
Nous allons présenter dans le tableau ci-dessous les acteurs de notre système :

Les acteurs Fonctionnalités

Réceptionniste Gérer le planning en prenant une réservation, la modifier ou
l’annuler.
Maître d’hôtel Gérer le planning mais il ne peut pas annuler une réservation en
revanche il peut barrer une ligne quand une réservation est
achevée.
Client Demander une réservation.
Personnel Visualiser le planning.
Tableau 1: Les acteurs du système

Cas d’utilisation : représente une fonctionnalité ou un service spécifique que le système

offre à ses utilisateurs.
Le tableau ci-dessous détaille chaque cas d’utilisation :

Cas d’utilisation Type de relation Description

Ce cas regroupe les fonctionnalités
Relation de d'effectuer, modifier, et annuler une
Gérer le planning
communication réservation.

Relation Le réceptionniste annule une réservation

Annuler
d’utilisation existante.
Relation Le réceptionniste modifie une réservation
Modifier
d’utilisation existante.
Le réceptionniste prend une nouvelle
Relation de
Prendre une réservation réservation, en ajoutant les informations
communication
essentielles et complémentaires.
Le réceptionniste ajoute les informations
Ajouter les infos Relation
essentielles lors de la prise d'une nouvelle
essentielles d’utilisation
réservation.

5
 Le réceptionniste ajoute les informations
Ajouter les infos Relation
complémentaires lors de la prise d'une
complémentaires d’extension
nouvelle réservation.
Visualiser le planning Relation de Le personnel du restaurant déclenche ce
communication cas pour consulter les réservations pour
une date donnée.
Demander une Relation de Le client déclenche ce cas en contactant le
réservation communication et restaurant pour faire une demande de
de généralisation réservation, soit par téléphone soit en
direct.
Tableau 2: Cas d'utilisation

Après avoir identifié les acteurs et leurs cas d’utilisation, nous avons élaboré le diagramme de
cas d’utilisation sur Modelio :

Figure 1: Diagramme de cas d'utilisation

6
  Fiche descriptive des cas importants :
Par la suite, nous établirons une « Fiche descriptive des cas importants », disponible dans le
fichier Excel suivant : lien vers le fichier Excel.

 Prototypes des interfaces

Enfin, nous concrétiserons ces idées à travers des "Prototypes d'interfaces", offrant une vision
tangible de l'expérience utilisateur envisagée.

Figure 2: Prototype d'interface

• Étape 2 : Étude du modèle statique :

 Diagramme de classe :

Dans cette étape nous aborderons deux composantes essentielles : la réalisation d'une
première ébauche du "Diagramme de Classe" et la création d'un "Dictionnaire de Données"
détaillant chaque abstraction choisie.

7
Le "Diagramme de Classe" est une vue graphique de la structure statique d’un système. Nous
explorons les entités telles que les réservations, les tables…et d'autres éléments cruciaux du
contexte du restaurant.

Le choix des classes a été basé sur l'analyse des entités et des actions impliquées dans le
système :

Interface Planning : Cette classe représente l'interface visuelle du planning du restaurant.

Elle est responsable de la visualisation de la date consultée et offre une méthode pour
changer cette date, ce qui est essentiel pour la gestion des réservations.

Table : Les tables dans un restaurant sont des entités clés. Elles ont des caractéristiques
comme le numéro, la capacité, et un indicateur d'état pour savoir si elles sont réservées. Les
méthodes liées aux réservations et aux déplacements sont incluses pour gérer les opérations
sur les tables.

Reservation : Une réservation est une entité centrale dans le système de gestion des
opérations du restaurant. Elle a des informations principales, des informations secondaires,
et une date associée. Les méthodes permettent de changer ces informations, offrant une
flexibilité dans la gestion des réservations.

ReservationRapide : Cette classe est une spécialisation de la classe Reservation, adaptée

pour les réservations rapides.

Figure 3: Diagramme de classe

 Dictionnaire de données :

Chaque abstraction identifiée dans le diagramme de classe sera accompagnée d'un ensemble
de propriétés et d'attributs spécifiques. Le "Dictionnaire de Données" offre une vue succincte
mais détaillée de ces éléments, fournissant une compréhension claire des caractéristiques de
chaque classe.

8
Classe : Interface-planning :

• Attributs :
− dateRegardee (Type : string) : La date actuellement consultée dans l'interface du
planning.
• Méthodes :
− changeDate(in pDate: string) : Méthode permettant de changer la date consultée
dans l'interface du planning en utilisant la nouvelle date fournie en paramètre.
Classe : Table :

• Attributs :
− tableID (numéro) : Identifiant unique de la table.
− capacité (place total): Nombre maximum de personnes.
− disponibilité (est réservée): La disponibilité de la table.
• Méthodes :
− reserver(in preservation: Reservation) : Méthode pour réserver la table, prenant
en compte les détails de la réservation.
− dereserve(in pDate : string) : Méthode pour annuler une réservation à une date
spécifiée.
− deplacerReservation(in pReservation : string) : Méthode pour déplacer une
réservation existante vers une autre table.
• Relations : Associée à des réservations (Classe Réservation) et à l’interface planning.

Classe : Réservation :
• Attributs :
− infoPrincipale (Type : string) : Les informations principales de la réservation.
− infoSecondaires (Type : string) : Les informations secondaires de la réservation.
− date (Type : string) : La date de la réservation.
• Méthodes :
− changeInfoPrincipale(in pInfo: ...) : Méthode pour modifier les informations
principales de la réservation.
− changeInfoSecondaire(...) : Méthode pour modifier les informations secondaires
de la réservation.
− changeDate(in pDate: string) : Méthode pour modifier la date de la réservation.

• Relations : Associée à une table (Classe table).

Classe : Réservation-rapide :
• Attributs :
− infoPrincipale (Type : string) : Les informations principales de la réservation.

• Étape 3 : Étude du modèle dynamique:

Dans cette étape nous allons mettre l'accent sur la séquence des actions et les
changements d'état au fil du temps. Nous allons élaborer des diagrammes de
séquence ou de communication pour les cas d'utilisation clés, illustrant le flux des
interactions entre les acteurs et le système. En parallèle, nous allons construire des
diagrammes d'états pour certaines classes pertinentes, décrivant les différents états
et transitions possibles.

9
 Scénarios de Modélisation Dynamique

Prendre une Réservation (Réceptionniste - Clients) :

Le client initie une demande de réservation, déclenchant une série d'interactions

avec le réceptionniste et le système de réservation.
Les messages échangés, la vérification de la disponibilité et la mise à jour des
informations seront représentés de manière séquentielle dans un diagramme de
séquence.

Figure 4: Diagramme du séquence -Prendre une réservation

Gérer l'Arrivée des Clients (Maître d'Hôtel - Clients) :

Lors de l'arrivée des clients, le maître d'hôtel engage une interaction avec le système
de réservation pour confirmer ou attribuer une table.
Le flux d'actions, y compris la vérification des réservations et l'attribution de tables,
sera représenté dans un diagramme de séquence.

10
 Figure 5: Diagramme de séquence - Gérer l'arrivée d'un client

Annuler une Réservation (Client - Réceptionniste) :

Lorsqu'un client souhaite annuler une réservation, une interaction entre le client, le
réceptionniste, et le système de réservation se déclenche.
Les étapes de recherche, de confirmation, et de mise à jour seront détaillées dans un
diagramme de séquence.

Figure 6: Diagramme de séquence - Annuler une réservation

Modifier une Réservation (Clients - Réceptionniste) :

La demande de modification de réservation initie une séquence d'interactions

impliquant le client, le réceptionniste, et le système de réservation.
Les différentes options, la confirmation, et les mises à jour seront représentées dans
un diagramme de séquence.

11
Figure 7: Diagramme de Séquence - Modifier une Réservation

12
Phase de conception :
• Étape 1: Conception générale :
Dans la phase préliminaire de conception de notre système de gestion de restaurant,
nous avons établi une architecture logicielle modulaire, divisée en paquetages
distincts avec des responsabilités bien délimitées. Cette structuration vise à
promouvoir une séparation claire des préoccupations, facilitant ainsi la maintenance
et l'évolution du système.

 Répartition en Paquetages

Le tableau ci-dessous présente une répartition claire des paquetages, avec leurs descriptions
respectives et les fonctionnalités associées.

Paquetage Description Fonctionnalités

Responsable de l'interface utilisateur, -Interaction directe avec les
IHM (Interface encapsulant tous les aspects liés à utilisateurs.
Homme- l'IHM. Inclut des composants tels que -Utilisation de la bibliothèque Swing
machine) des fenêtres, des formulaires et des pour fournir une expérience utilisateur
widgets. riche et personnalisable
Cœur de l'application, gérant la - Orchestration des interactions entre
logique métier complexe. Orchestre les les classes centrales.
Métier(Logique
interactions entre les classes centrales - Intermédiaire entre l'IHM et la couche
métier)
telles que Restaurant, Table, de persistance, traitant les demandes et
Réservation, etc. préparant les données pour l'affichage.
Gère la sauvegarde fiable et la - Utilisation de JPA avec Hibernate
récupération des données. Utilise JPA pour faciliter les opérations CRUD.
Persistance avec Hibernate comme fournisseur
pour une abstraction solide au-dessus
de la base de données.
Centralise la gestion des exceptions et - Capturer et traiter les exceptions de
des erreurs. Propose des classes manière cohérente à travers
Erreur (Gestion
personnalisées pour capturer et traiter l'application. - Amélioration de la
des Erreurs)
les exceptions de manière cohérente à traçabilité et de la maintenance des
travers l'application. erreurs.
Prévu pour intégrer des fonctionnalités - Communication avec des systèmes
de services web et d'API. Interagit tiers tels que les systèmes de paiement
étroitement avec le paquetage Métier en ligne, les fournisseurs de services de
Services
pour réaliser le traitement des données. réservation, etc.
- Intégration de fonctionnalités de
services web et d'API.
Regroupe diverses classes utilitaires -Réutilisables et peuvent être invoqués
réutilisables telles que des outils de par n'importe quel autre paquetage
Util validation, des gestionnaires de pour accomplir des tâches communes.
configuration et des assistants de
formatage.
Tableau 3: Paquetages

13
  Relation entre les paquetages :

IHM ↔ Métier : L'IHM fait appel au paquetage Métier pour l'exécution des opérations
métier et l'obtention des données à présenter à l'utilisateur.

Métier ↔ Persistance : Le Métier, en retour, interagit avec le paquetage Persistance pour

la persistance des données

Interactions avec le Paquetage Erreur : Tous les paquetages peuvent invoquer le

paquetage Erreur pour gérer les exceptions.

Interactions avec le Paquetage Service : Le paquetage Services peut nécessiter

des informations métier pour traiter les requêtes et les réponses lors d'interactions
externes.

Utilisation de paquetage Util : Les fonctionnalités communes sont accessibles via

le paquetage Util, utilisé universellement par tous les autres paquetages.

Conception et architecture de l’application : Pour soutenir une application

multithread capable de gérer de multiples interactions utilisateur simultanément, une
attention particulière a été portée à la conception thread-safe des composants. En
outre, la nature répartie de l'application a été envisagée pour une accessibilité à
distance ou via Internet, s'appuyant sur l'architecture robuste fournie par Spring Boot,
facilitant le déploiement et la gestion des microservices. Le modèle MVC est
employé pour séparer les responsabilités au sein de l'IHM, garantissant une couche
de présentation bien organisée et facile à tester.

 Choix technologiques :

Afin d’assurer l’efficacité, la fiabilité et l'évolutivité du logiciel, il est important de

choisir des technologies convenables.
Ci-dessous sont détaillées les justifications de ces choix, incluant la persistance, le
multithreading, l'architecture distribuée, les design patterns, ainsi que les frameworks
sélectionnés.

IHM avec Swing : Nous avons opté pour Swing en raison de sa maturité et de sa
stabilité dans le domaine des interfaces graphiques Java. Cette bibliothèque offre
une flexibilité significative pour personnaliser les composants de l'interface utilisateur,
avec une large communauté assurant un support continu et des ressources
abondantes pour les développeurs.

Persistance avec JPA/Hibernate : L'utilisation de JPA avec Hibernate comme

implémentation nous permet de bénéficier d'une couche d'abstraction efficace pour
la gestion des données. Cette approche simplifie les interactions avec la base de
données, améliore la portabilité entre différents SGBD et facilite l'intégration de la
logique métier avec la couche de persistance.

Multithreading : Le multithreading est crucial pour assurer une haute réactivité et

gérer efficacement les multiples requêtes utilisateur simultanées. Java offre un

14
modèle de concurrence robuste et des fonctionnalités de synchronisation intégrées
qui nous permettent de construire une application capable de traiter les opérations
concurrentes de manière sûre et efficace.

Architecture Répartie avec Spring Boot : Notre choix d'une architecture répartie
est motivé par la nécessité d'accéder au système via Internet et de gérer les
opérations à distance. Spring Boot est notre outil de prédilection en raison de sa
facilité de mise en place, sa configuration minimale et son support intégré pour la
création de microservices. Cette approche offre une grande modularité et simplifie le
déploiement des composants de l'application.

Design Patterns et MVC : Les design patterns sont au cœur de notre approche de
conception pour garantir un code propre, réutilisable et facilement testable. Nous
utilisons le modèle MVC (Modèle-Vue-Contrôleur) pour séparer clairement la logique
métier de l'IHM, facilitant ainsi les tests et la maintenance. De plus, nous intégrons
des patterns comme Singleton pour la gestion des instances uniques, telles que les
connexions à la base de données, et Factory pour la création d'objets complexes au
sein de la logique métier.

 Diagramme de composant du logiciel :

Le diagramme de composants illustre l'organisation et les dépendances entre les

différents composants logiciels de votre système. Pour le système de gestion de
restaurant, voici les principaux composants à inclure :

• Composant IHM : Interface utilisateur permettant aux utilisateurs (personnel

du restaurant et clients) d'interagir avec le système.
• Composant Métier : Contient la logique métier, traitant des opérations telles
que la gestion des réservations, des tables, et des commandes.
• Composant Persistance : Gère la persistance des données, interagissant
avec la base de données pour sauvegarder et récupérer les informations.
• Composant Services : Inclut les services externes, comme les API de
paiement ou d'autres intégrations tierces.
• Composant Util : Fournit des fonctionnalités communes utilisées par d'autres
composants, telles que la validation des entrées ou la gestion des erreurs.

Les relations entre les composants peuvent être représentées par des flèches
indiquant les dépendances. Par exemple, le Composant IHM dépend du Composant
Métier pour afficher les données, et le Composant Métier dépend du Composant
Persistance pour accéder aux données stockées.

15
 Figure 8: Diagramme de composant du logiciel

 Diagramme de Déploiement Intégrant les Composants :

Le diagramme de déploiement montre comment les composants logiciels sont

déployés sur l'infrastructure matérielle.
Serveur d'Application : Héberge les composants Métier, Persistance et Services.
Ce serveur peut être une machine virtuelle ou un conteneur dans un environnement
cloud.
Base de Données : Stocke les données de l'application, accessibles par le
Composant Persistance.
Clients : Ordinateurs ou appareils mobiles sur lesquels l'IHM est exécutée,
permettant aux utilisateurs d'accéder au système.

Les composants sont représentés comme des artefacts déployés sur ces nœuds.
Les connexions réseau entre les clients, le serveur d'application, et la base de
données illustrent comment les données sont échangées entre les composants.

Figure 9: Diagramme de dépoloiement

16
• Étape 2 : Conception détaillée :
 Diagrammes de classes techniques des différents paquetages :
Les diagrammes de classes techniques offrent une vue détaillée de la structure interne des
paquetages logiciels, montrant les relations entre les différents composants.

Paquetage IHM (Interface Homme-Machine)

• Classes de Vue :
− ReservationView : Affiche le formulaire de réservation et la liste des
réservations.
− TableView : Affiche l'état actuel des tables dans le restaurant.
− MenuView : Permet aux utilisateurs de consulter et de sélectionner des
items du menu.
− OrderView : Affiche le détail des commandes et permet leur gestion.
• Classes de Contrôleur :
− ReservationController : Traite les actions liées aux réservations
(ajout, modification, annulation).
− TableController : Gère les interactions liées à l'état des tables.
− MenuController : Gère la sélection des items de menu et les
interactions avec le modèle de menu.
− OrderController : Traite les commandes, les mises à jour et les
interactions avec le modèle de commande.

Figure 10: Diagramme de classe de paquetage IHM

Paquetage Métier
• Classes Métier :
− Reservation : Contient les détails d'une réservation.
− Table : Représente une table dans le restaurant avec son état et sa
capacité.
− MenuItem : Représente un item du menu avec ses propriétés comme le
prix, la description.
− Order : Représente une commande avec une liste d'items commandés.

17
 Figure 11: Diagramme de classe de paquetage Métier

Paquetage Persistance
• Classes DAO (Data Access Object) :
− ReservationDAO : Gère la persistance des réservations.
− TableDAO : Gère la persistance de l'état des tables.
− MenuDAO : Gère la persistance des items de menu.
− OrderDAO : Gère la persistance des commandes.

Figure 12: Diagramme de classe de paquetage Persistance

Paquetage Services
• Classes de Service :
− PaymentService : Intègre un service de paiement externe.
− NotificationService : Envoie des notifications par e-mail ou SMS.

Figure 13: Diagramme de classe de paquetage Service

18
Paquetage Util
• Classes Utilitaires :
− Logger : Offre des fonctionnalités de journalisation.
− Validator : Fournit des méthodes de validation pour les entrées
utilisateur.

Figure 14: Diagramme de classe de paquetage Util

 Diagrammes de séquence technique et réalisation de l’approche MVC

pour l’architecture de projet :

Les diagrammes de séquence technique et l'approche MVC sont des éléments clés dans la
conception et le développement logiciel. Ils permettent de visualiser les interactions entre les
composants et de structurer efficacement l'architecture d'un projet.
Pour élaborer le diagramme de séquence technique pour une nouvelle réservation et décrire en
détail l'approche MVC, voici les étapes que nous allons suivre :
Identification des acteurs : Utilisateur (Client ou Personnel du restaurant).
Description du scénario : L'utilisateur souhaite créer une nouvelle réservation.
Détail des étapes du scénario : en indiquant les interactions entre les composants MVC.
• L'utilisateur déclenche l'action de création de réservation via l'interface utilisateur
(Vue).
• L'interface utilisateur envoie la demande au contrôleur de réservation (Contrôleur).
• Le contrôleur de réservation valide les données de l'utilisateur, potentiellement à l'aide
d'un service de validation du paquetage Util (Modèle ou Utilitaire).
• Si les données sont valides, le contrôleur de réservation demande au modèle de
réservation de créer une nouvelle réservation (Modèle).
• Le modèle de réservation crée un objet de réservation et le transmet au DAO de
réservation pour la persistance (Modèle).
• Le DAO de réservation interagit avec la base de données pour enregistrer la nouvelle
réservation (Persistance).
• Une fois la réservation enregistrée, une réponse est renvoyée au modèle de réservation,
puis au contrôleur de réservation (Modèle).
• Le contrôleur de réservation informe l'interface utilisateur de la réussite de l'opération
(Contrôleur).
• L'interface utilisateur affiche un message de confirmation à l'utilisateur (Vue).

Cela montre comment le modèle-vue-contrôleur (MVC) est implémenté dans le processus de

création d'une nouvelle réservation. Chaque composant MVC a des responsabilités
spécifiques et communique avec les autres composants de manière structurée et modulaire.

19
 Figure 15: Diagramme de séquence technique

Phase d’implémentation :

 Développement deux cas d’utilisation :

Nous avons développé notre application avec Spring Boot organisée selon une architecture
basée sur le modèle MVC.
Vue d'ensemble des Composants :

− Modèles : Représentent la structure des données, notamment les réservations, avec

toutes les informations nécessaires. ( class Reservation).
− Contrôleurs :Gèrent les interactions utilisateur, en traitant les requêtes et en retournant
les réponses appropriées. (class PlanningController).
− Services : Contiennent la logique métier de l'application, gérant les opérations liées
aux réservations. (class PlanningService et PlanningServiceImpl).
− Dépôts :Facilitent l'accès et la manipulation des données persistantes, en utilisant
Spring Data. (interface ReservationRepository).
− Configuration :Configure l'application, incluant la connexion à la base de données et
la mise en place de divers beans..

20
 − Utilitaires : Offrent des fonctions auxiliaires, comme la manipulation des dates,
utilisées à travers l'application.

 les listings et les copies d’écran :

Après avoir exécuté notre application , la console n’affiche aucun erreur :

Figure 16: Capture d'écran de console après exécution

Le journal indique que l'application a démarré avec succès sur une machine de développement
locale et que le serveur Tomcat démarre avec succès sur le port 8080.
Mais malheureusement quand on essaye d’accéder à notre ‘http://localhost:8080/’ , on
constate l’erreur suivant :

Figure 17: Erreur confronté

Nous avons essayé pendant 5 jours de résoudre ce problème ( en regardant plusieurs vidéos
YouTube et en lisant des articles et en appliquant leurs conseils) mais sans succès.
Sachant que tous est bien configuré.

21