LO10 : Rapport de

conception
Semestre: Printemps 2023

Équipe projet
Audrey SOUPPAYA
Huu Khai NGUYEN
Majed HLAIHEL

1
Sommaire
Sommaire
Introduction
Présentation de l'application
Partie 1 : Maquettes
Partie 2 : Implémentation de l'application
Partie 3 : Présentation de l'application
Architecture de l’application répartie
Diagramme de composants
Détail des interfaces par services mobilisés
Motivation de l'architecture proposée
Patrons de conception
Cache
Service Controller
Service Descriptor
Ouverture de projet
État actuel de projet
Évolution de projet
Conclusion
Bibliographie
Annexes

2
Introduction
Dans le cadre de l’UE LO10 - Architectures orientées services, nous devons
développer une application. L’enjeu de celle-ci est une répartition sur la base
d’une analyse approfondie de l’architecture orientée services web qui supportera
l’application.
Les exigences du projet sont les suivantes :
- une application qui consomme au moins 5 services web tiers
- une architecture avec au moins 3 patrons de conception

Présentation de l'application
Dans le cadre de notre projet de développement logiciel, nous avons conçu une
application de planification de voyage pour faciliter l'organisation et la gestion
des voyages personnels ou en groupe. Cette application vise à offrir une
expérience utilisateur fluide, intuitive et personnalisée pour les voyageurs du
monde entier.

Le processus de planification de voyage peut souvent être complexe et fastidieux,

nécessitant de jongler avec de nombreuses informations telles que les
destinations, les dates, les réservations d'hébergement, les activités prévues et
bien plus encore. Notre application vise à simplifier ce processus en regroupant
toutes ces fonctionnalités essentielles au sein d'une interface unique et conviviale
comme montré ci-dessous avec notre vision board.

Figure 1: Vision Board

3
L'objectif principal de cette partie du rapport est de présenter les maquettes
initiales de l'application, qui ont servi de base à son développement ultérieur.
Nous mettrons en évidence les différentes interfaces utilisateur conçues pour
répondre aux besoins des voyageurs, en leur offrant une vue d'ensemble de
l'application et en leur permettant de se familiariser avec ses fonctionnalités clés.

Ensuite, nous passerons à la présentation de l'application implémentée, qui est le

résultat concret de notre travail. Nous montrerons comment les maquettes ont
été traduites en une application fonctionnelle, en mettant en avant son interface
utilisateur moderne, ses fonctionnalités clés et son intégration avec des services
tiers pertinents.

Partie 1 : Maquettes
Dans cette partie, nous allons explorer les maquettes de notre application de
planification de voyage. Nous avons défini en premier temps quelques maquettes
initiales en utilisant Figma pour représenter visuellement les différentes
interfaces utilisateur de l'application et se donner un aperçu de son apparence et
de son fonctionnement. Voici quelques interfaces utilisateur en maquettage qui
nous permettrait d’avoir une première vue sur ce que nous allions implémenter
dans le futur:

Page “Trip list”

Figure 2

4
Page “Trip Management”

Figure 3

Page “Trip Itinerary”

Figure 4

Page “Trip visualisation”

5
 Figure 5

Page “Trip map”

Figure 6

6
Partie 2 : Implémentation de l'application

L'implémentation de l’application s'appuie sur des technologies modernes du

Web suivant:

Côté client (front-end)

La bibliothèque ReactJS a été choisie pour construire l’interface utilisateur de
notre application. Ainsi, cela nous offre des fonctionnalités pour gérer les
évènements, les états de l'ensemble de composants de React grâce à des
fonctions de Hooks pour contrôler le cycle de vie d'un composant, le Context pour
le partage de données entre les composants dans l'arbre hiérarchique, la gestion
de Routeur du côté client, etc…

Côté serveur (back-end)

Le framework ExpressJS ainsi que son environnement d’exécution ont été choisis
pour l'implémentation du serveur de notre application. Cela nous permet de
traiter les requêtes HTTP du côté client (React), de construire l'ensemble d'API
RESTful pour interagir avec la base de données, de générer la session / cookies,
ainsi que d’intercepter et de modifier les informations de requêtes de client avant
de le laisser être envoyé au serveur, etc… ExpressJS nous rend le code plus lisible
et facile à comprendre de manière plus structurée.

De plus, NodeJS nous donne l'ensemble de modules pour faire la lecture /

l'écriture de fichier, de gérer le répertoire du projet, et les modules de chiffrement
et de hash pour générer des chaînes de caractères aléatoires, utilisés pour
générer l'identifiant du voyage et générer le code d'invitation.

Données
Pour récupérer les données nécessaires pour notre application de voyage comme
la prédiction de la météo du jour, les lieux à visiter (les restaurants, les hôtels, les
abstractions) à partir de ses coordonnées, et pour faciliter la recherche des places
et l’implémentation de la carte, nous avons pris 4 services d’API tierce suivant qui
sont des données qui viennent à l'extérieur:
● OpenWeatherMap API
● Travel Advisor RapidAPI
● Google Map API
● Google Autocomplete API
Cette intégration des API externes nous permet d’enrichir les fonctionnalités de
l'application avec des données actualisées et des services complémentaires.

7
D’un autre côté, pour simplifier le processus et diminuer le temps de
développement, nous avons décidé en premier temps, de stocker des données
internes de cette application, telles que les informations des utilisateurs et les
détails des voyages dans 2 fichiers du type JSON - users.json et trip.json (les
détails de ces fichiers sont en annexe). Ces fichiers nous permettent de maintenir
comme une base de données locale pour gérer les profils des utilisateurs, leurs
voyages enregistrés, ainsi que les préférences personnelles.

Partie 3 : Présentation de l'application

Notre application de voyage offre aux utilisateurs une plateforme complète pour
planifier, organiser et suivre leurs voyages de manière pratique et personnalisée.
L'application se distingue par ses fonctionnalités avancées, notamment une
authentification pour pouvoir accéder aux données de voyage.

Lors de la première utilisation, les utilisateurs sont invités à s'authentifier pour

accéder à l'application. Cela garantit que seuls les utilisateurs autorisés peuvent
profiter des fonctionnalités offertes par l'application.

Figure 7: L'authentification de testuser

Une fois connectés, les utilisateurs peuvent naviguer entre les différentes pages
grâce à une barre de navigation située en haut de l’interface.

8
 Figure 8: Page d'accueil

La barre de navigation propose trois principales sections de l’application: La

gestion de voyage (TRIP), la recherche des lieux (RESEARCH) et la déconnexion
(LOG OUT). Cette conception permet aux utilisateurs de passer facilement d’une
fonctionnalité à l'autre, selon leurs besoins spécifiques.

Par exemple, ils peuvent accéder à la gestion de voyage pour visualiser tous leurs
groupes de voyage en cliquant sur TRIP dans la barre de navigation.

9
 Figure 9: Page “TRIPS"

De plus, pour créer un nouveau groupe de voyage en cliquant sur le bouton en

bas à droite de l’interface et puis renseigner tous les champs nécessaires dans le
formulaire de création.

Figure 10: L'ajout d'un groupe de voyage

Une fois que les utilisateurs valident la création d'un nouveau groupe, l’interface
de la page est mise à jour avec ce nouveau groupe de voyage.

10
 Figure 11: La page TRIPS mise à jour avec un nouveau groupe

En cliquant sur ce nouveau groupe dans la liste de groupe (dans ce cas, c’est le
groupe “Road Trip to Denmark”), nous serons dirigés vers une autre page avec
les informations de base de ce voyage. Nous pouvons voir sur cette page une
sous-barre de navigation qui nous aide à gérer le voyage. La page qu’on voit
actuellement est le “Trip Management”.

11
 Figure 12: La page “Trip Management"
(A noter le champs “Invitation Link" pour la démonstration de la partie collaboration de
l'application)

En cliquant sur “Trip Tasks" dans la sous-barre de navigation, une interface de

distribution des tâches pour le membre du groupe de voyage sera affichée.

12
 Figure 13: La page “Trip Tasks"

Sur cette page, nous pouvons créer une nouvelle tâche et la distribuer à un
membre dans le groupe de voyage. Pour l'instant, il n'y a que le membre
“testuser"

Figure 14: Le formulaire d’ajout d'une tâche

Nous validons la création de tâche et l'interface de “Trip Tasks" viendra mettre à

jour

13
 Figure 15: La page “Trip Tasks" mise à jour avec une nouvelle tâche

Maintenant, nous allons faire quelques recherches sur les lieux (les restaurants, les
hôtels, etc…) pour le voyage en cliquant sur RESEARCH dans la barre de
navigation. Grâce à Google Autocomplete API, nous pouvons facilement avoir une
liste de suggestions en temps réel quand nous saisissons dans la barre de
recherche

Figure 16: La page RESEARCH avec l’autocomplétion

14
En validant une valeur dans la liste de suggestions, les informations par rapport à
la localisation choisie vont afficher sous la forme d'une carte avec l'ensemble des
lieux proposés sur le côté gauche de la carte. De plus nous pouvons faire un
filtrage du type de lieux ainsi que par rapport au rating de lieux comme ci-
dessous:

Figure 17: La page de recherche avec les données de lieux / de la météo

L'objectif de cette fonctionnalité est de permettre aux utilisateurs de faire la

recherche de lieux préférés pour le voyage et de les enregistrer pour le voyage.
Pour le faire, on choisit le lieux que l'on veut noter pour le voyage, un formulaire
sera affiché pour choisir le groupe que l'on souhaite ajouter un lieu pour le
voyage. Par exemple on voulait ajouter un restaurant à visiter pour le voyage du
groupe “Road trip to Denmark":

15
 Figure 18: L'ajout d’un lieu dans la page “Trip Itinerary"

Nous pouvons retrouver dont le restaurant enregistré pour le voyage “Road Trip
to Denmark" en revenant de la page la liste de groupes de voyage dans TRIP, et
puis choisir le groupe “Road Trip to Denmark" et finalement en cliquant sur
“Trip Itinerary" dans la sous-barre de navigation:

16
 Figure 19: La page “Trip Itinerary" mise à jour avec un lieu enregistré

Sur la page d’itinéraire du voyage, nous avons donc le restaurant enregistré

depuis la page de RESEARCH qui est localisée sur la carte.

Maintenant, nous allons montrer la partie de collaboration de cette application,

une fonctionnalité qui nous permet d'inviter les autres à rejoindre un groupe de
voyage via le lien d'invitation. Ce lien d'invitation peut être retrouvé sur la page de
“Trip Management", qui décrit les informations générales d'un groupe de voyage
(voir figure 12). Tout d'abord, nous avons besoin de faire l'authentification avec un
autre utilisateur (ce n'est pas utilisateur “testuser”). En ouvrant une nouvelle
fenêtre privée et finissant l'authentification avec l'utilisateur “Kaykay”:

17
 Figure 20: L'authentification de Kaykay

Actuellement sur la page de la gestion de voyage, il n'y a que le groupe

“Lisbonne" dans la liste de voyage. Pour inviter l'utilisateur Kaykay à rejoindre le
groupe “Road Trip to Denmark”, nous avons besoin de faire copier-coller le lien
d'invitation http://localhost:3000/invite?co2de=5yjPMKai sur la page de “Trip
Management" de l'utilisateur “testuser", puis l’envoyer à Kaykay. Kaykay devrait
lancer l'application avec ce lien d'invitation. Et voilà, il a réussit à rejoindre à ce
groupe de voyage avec un message de succès:

Figure 21: Kaykay rejoint un groupe via un lien d’invitation

Sur la page de “Trip Management", et également sur la page de “Trip Itinerary”,

l'utilisateur Kaykay peut voir toutes les informations du groupe “Road trip to
Denmark" qui sont ajoutées par l'utilisateur testuser

18
Figure 22: Page “Trip Management" de Kaykay

Figure 23: Page “Trip Itinerary" de Kaykay

19
De plus, grâce à cela, depuis la page “Trip Tasks", soit de testuser, soit de
Kaykay, nous pouvons distribuer les tâches à ces 2 utilisateurs:

Figure 24: Distribution de tâches pour Kaykay

20
 Figure 25: La tâche de “Kaykay” est ajoutée sur la fenêtre de “Kaykay” et “testuser”
Nous avons donc décrit les principales fonctionnalités de l'application ainsi que la
façon d'utiliser chaque fonctionnalité. En somme, notre application de
planification de voyage offre une interface conviviale et complète pour simplifier
l'organisation des voyages, facilitant ainsi la création d'itinéraires personnalisés et
la gestion des tâches associées.

Nous passerons par la suite en termes de l'architecture de l’application.

21
Architecture de l’application répartie

Diagramme de composants

Figure 26: Diagramme de composants

22
Détail des interfaces par services mobilisés
● OpenWeatherMap

Le service OpenWeatherMap est un service Web Rest-like qui fournit des

données de météo en Json et XML grâce à une clé unique, pour n’importe quelle
localisation du monde.

Figure 26
L’interface qu’on utilise dans notre app:

Cette interface fournit plusieurs méthode dont celle qu’on utilise qui permet de
requêter le service à partir de cet endpoint:
https://api.openweathermap.org/data/2.5/weather?
lat={lat}&lon={lon}&appid={API key}
en ajoutant les coordonnées géographique de la localisation et la clé d’api en
paramètre.
La localisation par défaut est celle de l’utilisateur, mais l’utilisateur peut très bien
chercher pour n’importe quelle ville dans le monde, et la localisation envoyée est
celle retrouvée par le service de Google Maps.
Nous utiliserons ensuite les données retrouvés pour afficher certaines
informations concernant la météo sur la carte dynamique.

● Travel Advisor Rapid API

Ce service REST, grâce à une clé rapidapi, permet de reproduire les données et
fonctionnalités publiques de TripAdvisor - tripadvisor.com.
Elle permet d'interroger en temps réel les prix des vols, la réservation d'hôtels, les
restaurants, les lieux d'attraction, etc.

23
L’interface utilisée:

Figure 27

Cette interface permet de faire des requêtes sur 3 endpoints différent:

https://travel-advisor.p.rapidapi.com/${type}/list-in-boundary
en précisant le type dans l’uri on peut retrouver une liste (de n nombre égale au
limite précisé dans les params) des hôtels ou restaurant ou place d’attractions
dans un rectangle précisé, on précise ces deux points du zone rectangulaire:
bl=bottom left et tr=top right.
endpoint restaurants:
https://travel-advisor.p.rapidapi.com/restaurants/list-in-boundary

endpoint hotels:
https://travel-advisor.p.rapidapi.com/hotels/list-in-boundary

endpoint attractions:
https://travel-advisor.p.rapidapi.com/attractions/list-in-boundary

● google-map-react

C’est une librairie tierce pour React qui simplifie le processus d’intégration de
Google Maps dans les applications React. Il agit comme un wrapper de l’api

24
JavaScript de Google Maps, ce qui permet de réduire les complexités du travail
direct avec Google Maps et offrir un moyen plus intuitif.
Cette librairie, grâce à une clé de l’API Google Maps, nous offre les composants
suivants:

GoogleMapReact: La Carte interactive configurable qui affiche les places (hôtels,

restaurants ou attractions) dans la ville ou emplacement recherché.

AutoComplete: Ce Composant fournit des suggestions sur les emplacements au

fur et à mesure que l’utilisateur saisie dans le champ, permettant de faciliter la
recherche et la sélection aux utilisateurs.

● Service de l’application

Pour faire persister et manipuler les données, nous avons créé notre service dédié
à l’application.
L’interface crée:

Figure 28

Cette interface offre plusieurs méthodes:

● getTrips: permet de retrouver tous les trips d’un utilisateur
● getTrip(tripId:string): permet de retrouver un trip spécifique par son id.
● addTrip(trip:Trip): permet d’ajouter un trip à la DB local
● updateTrip(tripId:string): permet de modifier les données d’un trip.

25
 Figure 28

Plan: représente la place (hotel,attraction,restaurent) qu’il vont visité, avec la date,

la localisation et d'autres infos.
Task: la tâche qui sera attribuée à un membre du groupe, dans l’idée de
contribuer à la planification du voyage.

Le format des données trips et des utilisateurs est en annexe.

26
Motivation de l'architecture proposée
Au début de projet, lors d’une réunion hebdomadaire, nous avons choisi de suivre
le modèle client-serveur, une architecture classique de l'application du Web avec
ReactJS utilisé pour la partie client, et ExpressJS comme framework côté serveur
ainsi que son environnement d'exécution NodeJS.

L'architecture côté client utilise ReactJS, une bibliothèque JavaScript populaire

pour la construction d'interfaces utilisateur les plus interactives. ReactJS adopte
une approche basée sur des composants, permettant à l'application d'être
structurée en composants réutilisables et modulaires. Cela favorise la réutilisation
du code, la maintenabilité et une séparation claire des responsabilités.

Côté serveur, Express est utilisé comme framework d'application web. Il fournit
un ensemble robuste d'outils et de middleware pour gérer les requêtes HTTP, le
routage, la gestion des sessions et l'authentification. Express permet la mise en
œuvre d'API RESTful, permettant au côté client de communiquer avec le serveur
et de récupérer les données selon les besoins.

27
L'architecture proposée, utilisant ReactJS et ExpressJS, a été choisie pour
répondre à plusieurs critères importants en termes de performance, coûts, sûreté
de fonctionnement, maintenabilité et extensibilité.

La motivation de l'architecture proposée repose sur les critères de performance,

de coûts, de sûreté de fonctionnement, de maintenabilité et d'extensibilité. Voici
une explication de la motivation derrière chaque critère :

1. Performance :
● ReactJS offre des performances élevées grâce à son approche de rendu
virtuel et à sa gestion optimisée des mises à jour de l'interface utilisateur.
Cela permet d'obtenir des temps de réponse rapides et une expérience
utilisateur fluide.
● ExpressJS, basé sur Node.js, est réputé pour sa rapidité d'exécution et son
évolutivité, ce qui garantit une gestion efficace des requêtes et une
capacité de traitement élevée.

2. Coûts :
● L'utilisation de ReactJS et ExpressJS, deux technologies open source,
permet de réduire les coûts liés aux licences logicielles.
● Ces frameworks sont également populaires et bénéficient d'une large
communauté de développeurs, ce qui facilite l'accès à des ressources
gratuites, des tutoriels et des conseils, réduisant ainsi les coûts de
formation et de support.

3. Sûreté de fonctionnement :
● L'architecture adopte des mécanismes de gestion de session pour
l'authentification et la sécurisation des ressources. Cela permet de garantir
que seules les personnes autorisées ont accès aux données et aux
fonctionnalités appropriées.
● Les frameworks tels que ExpressJS sont bien établis et bénéficient d'une
réputation solide en termes de sécurité, ce qui renforce la sûreté de
fonctionnement de l'application.

4. Maintenabilité :

28
 ● L'approche basée sur des composants de ReactJS permet de développer
l'application de manière modulaire et réutilisable. Cela facilite la
maintenance du code, car les composants peuvent être développés, testés
et mis à jour indépendamment les uns des autres.
● ExpressJS, avec son architecture basée sur des middlewares, facilite
également la maintenance en permettant d'ajouter, de modifier ou de
supprimer des fonctionnalités de manière modulaire, sans impacter le
reste du système.

5. Extensibilité :
● L'architecture modulaire de ReactJS et ExpressJS permet d'ajouter
facilement de nouvelles fonctionnalités à l'application. Les composants
React peuvent être étendus ou réutilisés pour répondre à de nouveaux
besoins, tandis que les middlewares d'Express permettent de gérer de
manière flexible les requêtes et les fonctionnalités supplémentaires.

En résumé, l'architecture utilisant ReactJS et ExpressJS a été motivée par la

recherche de performances élevées, de coûts réduits, de sûreté de
fonctionnement, de maintenabilité facile et d'extensibilité pour l'application. Ces
choix d'architecture permettent de développer une application robuste, évolutive
et efficace, tout en minimisant les coûts et en garantissant une expérience
utilisateur sécurisée et fluide.

29
Patrons de conception

Cache

Le premier patron de conception qu’on a implémenté dans notre projet est le

cache pattern.
L’idée est de stocker temporairement les réponses des requêtes API afin de
réduire les temps de réponse, de minimiser la charge sur les serveurs et
d’économiser des requêtes coûteuses.

Dans le cadre de notre projet, ce pattern est très intéressant puisque les API

Ainsi, d’après le schéma ci-dessous, on remarque bien qu’avant d’effectuer une

requête à l’API Google Maps, on vérifie d’abord si les données demandées ne sont
pas stockées dans le cache.

Cas 1 : Si les données ne sont pas présentes dans le cache, on effectue une
requête à l'API Google Maps pour obtenir les données nécessaires qui seront
stockées dans le cache pour une utilisation ultérieure.

Cas 2 : Si elles le sont, on récupère directement à partir du cache les données au

lieu de faire une nouvelle requête à l'API.

30
Service Controller

Le patron de conception Service Controller est une approche de conception

courante pour les applications Web qui impliquent des opérations CRUD (Create,
Read, Update, Delete) sur des ressources. Il permet de séparer la logique métier
de la logique de présentation en utilisant des classes de contrôleur de service
pour gérer les opérations sur les données.

Pour montrer l’implémentation de ce patron de conception dans notre projet,

nous allons prendre un morceau de code du serveur que nous avons examiné.

Le patron de conception Service Controller est implémenté à l'aide des classes de

contrôleur de service telles que UserController et TripController. Ces classes
encapsulent la logique métier pour les opérations associées aux utilisateurs et
aux voyages, respectivement. Ces classes de contrôleur sont aussi responsables
de la manipulation des requêtes HTTP entrantes et des réponses sortantes, ainsi
de l'interaction avec les modèles de données pour effectuer des opérations
CRUD.

31
Par exemple, le UserController gère les opérations d'authentification des
utilisateurs, telles que la connexion et la déconnexion. Il utilise des méthodes
login et logout pour effectuer ces opérations.

Figure : Contrôleur ‘UserController’

La méthode login lit les données d’utilisateur, vérifie les informations

d'identification fournies par l'utilisateur et crée une session pour l'utilisateur. La
méthode logout détruit la session de l'utilisateur et supprime les cookies
associés.

Voici un petit schéma pour décrire le fonctionnement de UserController:

Figure : Schéma simple de UserController

Ce contrôleur nous permet de définir la gestion des requêtes pour chaque
endpoint de manière plus lisible.

Figure : Endpoints de l’authentification

32
Service Descriptor

Dans notre projet, nous utilisons le Service Descriptor pour fournir une
description standardisée et lisible par machine de l'interface de service pour
faciliter la découverte et l'interopérabilité des services au sein de notre
application.

Pour implémenter Service Descriptor, nous avons utilisé OpenAPI (Swagger), qui
fournit un format lisible par machine pour décrire les API RESTful, y compris des
informations sur les points de terminaison, les paramètres, les formats de requête
et de réponse, et les mécanismes d'authentification. Nous avons créé un fichier
du format YAML pour décrire notre API, y compris les endpoints, les paramètres,
les réponses et les schémas. Nous avons ensuite utilisé les packages yamljs et
swagger-ui-express pour charger la spécification OpenAPI et afficher la
documentation dans une interface utilisateur conviviale.

Figure : Les endpoints implémentés dans notre application

33
 Figure : Les réponses de GET /api/trips

Ouverture de projet

État actuel de projet

L'état actuel de l'application est fonctionnel et propose des fonctionnalités de
base telles que l'authentification des utilisateurs, la création de voyages, la mise à
jour des voyages existants, la gestion de voyage comme la distribution des tâches
pour chaque membre dans un groupe de voyage, le partage de location préférée
pour le voyage depuis la page de recherche, et la récupération des voyages
spécifiques à un utilisateur. De plus, on peut inviter les autres à rejoindre un
groupe de voyage via un lien d’invitation généré par le système de l'application.
Cependant, il convient de noter que l'application peut encore être améliorée et
étendue pour répondre à des besoins futurs.

34
Évolution de projet
En termes de potentiel d'évolution, voici quelques points à considérer :

1. Ajout de fonctionnalités supplémentaires :

L'application peut être enrichie avec de nouvelles fonctionnalités en fonction des
besoins des utilisateurs. Par exemple, nous pourrions envisager de:
● ajouter la fonctionnalité de l'inscription,
● ajouter la possibilité de modifier ou de supprimer des voyages
● ajouter des commentaires ou des images aux voyages
● intégrer des services tiers pour gérer des opérations ou des analyses
complexes et pour gérer le budget de voyage.

2. Renforcement de la sécurité :
Pour assurer la sécurité des utilisateurs et de leurs données, nous pouvons
implémenter des mesures supplémentaires telles que le hash de mots de passe,
le chiffrement des données sensibles comme les informations d’utilisateurs, la
gestion des autorisations d'accès, la protection contre les attaques courantes
telles que les attaques par injection SQL ou les attaques de contournement
d'authentification.

3. Mise en place d’une base de données complète :

Pour l'instant, aucune base de données est intégrée à notre application. Nous
utilisons 2 fichiers du type JSON pour stocker les informations d’utilisateurs et les
données de voyage. La mise en place d'une base de données complète pour
notre application comme MongoDB, DynamoDB ou MySQL est indispensable
pour pouvoir fluidifier le flux de données et normaliser le stockage de données
pour l'application. Cela facilitera également la gestion de données de manière
plus claire et plus compréhensible ainsi que pour la maintenabilité de notre
application.

4. Tests et maintenance :
Il est essentiel d'effectuer des tests approfondis pour identifier et résoudre les
éventuels problèmes ou bugs. Nous devrions donc mettre en place des tests
unitaires, des tests d'intégration et des tests de performance pour garantir le bon
fonctionnement de l'application. En outre, la maintenance continue est

35
nécessaire pour appliquer des correctifs de sécurité, gérer les mises à jour des
dépendances et prendre en compte les commentaires des utilisateurs.

5. Extension à une architecture à microservices :

Si l'application devient plus complexe et nécessite une évolutivité accrue, nous
pourrions envisager de passer à une architecture à microservices. Cela implique
de découper l'application en services distincts, chacun responsable d'une
fonctionnalité spécifique. Cela permet une meilleure isolation, une évolutivité
indépendante des composants et une gestion simplifiée.

6. Amélioration de l'expérience utilisateur :

Nous pouvons améliorer l'interface utilisateur pour la rendre plus conviviale,
réactive et esthétiquement attrayante. Cela peut inclure des améliorations de la
mise en page, des animations, des icônes intuitives, une navigation simplifiée et
des interactions plus fluides.

7. Optimisation des performances :

Nous pouvons analyser et optimiser les performances de l'application en
identifiant les goulots d'étranglement, en améliorant les requêtes de base de
données, en mettant en cache les données fréquemment utilisées, en utilisant la
compression des ressources, ou en utilisant des techniques de chargement
progressif pour améliorer le temps de réponse et l'expérience utilisateur globale.

En résumé, l'application actuelle possède un potentiel d'évolution significatif. En

ajoutant de nouvelles fonctionnalités, en améliorant l'expérience utilisateur, en
renforçant la sécurité, en optimisant les performances et en envisageant une
architecture à microservices, nous pouvons faire évoluer le produit pour répondre
aux besoins changeants des utilisateurs. Une approche de tests et de
maintenance rigoureuse permettra de maintenir l'application en bon état de
fonctionnement et de garantir sa qualité à long terme. Avec ces améliorations et
évolutions, l'application pourra fournir une expérience utilisateur exceptionnelle
tout en offrant une flexibilité et une évolutivité accrues.

36
Conclusion
En conclusion, notre projet de développement logiciel dans le cadre de LO10 a
abouti à la création d'une application de planification de voyage complète et
conviviale. Grâce à une architecture orientée services Web soigneusement
analysée, nous avons réussi à répondre aux exigences du projet, notamment en
intégrant 4 services d'API et en utilisant 3 patrons de conception.

L'architecture orientée services adoptée dans notre application a permis une

séparation claire des responsabilités, favorisant la réutilisabilité du code et la
maintenabilité de l'application. Les trois patrons de conception utilisés ont
contribué à la structuration efficace de notre code et à l'amélioration de la
flexibilité de l'application.

En développant cette application, nous avons relevé le défi de combiner les

différentes technologies et services externes tout en offrant une interface
utilisateur intuitive et conviviale. Nous nous sommes convaincus que notre

37
application de planification de voyage répond aux besoins des utilisateurs en
offrant une solution complète et pratique pour organiser leurs voyages.

Ce projet nous a permis de mettre en pratique nos connaissances en architecture

orientée services, en intégration de services Web et en conception logicielle. Nous
avons acquis une expérience précieuse dans le développement d'applications
fonctionnelles et évolutives, tout en répondant aux exigences spécifiques du
projet.

En somme, notre application de planification de voyage représente une étape

importante dans notre parcours de développement logiciel. Nous sommes fiers
du résultat obtenu et confiants dans sa capacité à offrir une expérience
enrichissante aux voyageurs du monde entier, inclus nous-même.

Bibliographie
OpenWeatherMap API
Travel Advisor RapidAPI
Google Map API (voir documentation pour générer une clé API)
Google Autocomplete API
Service Design Pattern

38
Annexes
Annexe 1: Fichier users.json

39
Annexe 2: Fichier trip.json (un petit morceau pour démontrer la structure de
données)

40
41