SAE 501 – 502 Livrable 1 spécifications et

conception

ElClassico

FARINA Timothé
BUVRY Paul
THIBONNET Julian

Année universitaire 2023/2024 NYZAM Valen n

SOULET Arnaud
INTRODUCTION
L’objec f de ce projet vise à développer et à déployer une applica on web dédiée à la
comparaison d'en tés basée sur les données de l'encyclopédie Wikipedia.

Pour y parvenir, plusieurs besoins clés ont été iden fiés, englobant des domaines variés tels
que la ges on de projet, la collabora on en équipe, la concep on et la réalisa on technique,
ainsi que la sécurisa on des informa ons.

Les besoins spécifiques du projet incluent la mise en place d'un environnement de travail
collabora f, le découpage et l'a ribu on des tâches, la produc on de documenta on, la
sécurisa on de l'applica on, et la ges on de l'ensemble des étapes du développement.

Ce document permet de présenter l’ordre dans lequel nous allons réaliser ce projet et les
moyens que nous souhaitons me re en place pour y parvenir. Il nous servira de guide tout au
long de notre projet mais pourra être modifié à tout moment en fonc on des problèmes
rencontrés et de l’évolu on du projet.

2
SOMMAIRE

INTRODUCTION ................................................................................................................ 2
SOMMAIRE ...................................................................................................................... 3
SPÉCIFICATIONS DU PROJET .............................................................................................. 4
DIAGRAMME D’EXIGENCES ...................................................................................................... 5
ORDRE D’IMPLÉMENTATION ..................................................................................................... 6
PAGES MAQUETTES FRONT END ............................................................................................... 7
CONCEPTION .................................................................................................................... 9
ARCHITECTURE BACKEND ......................................................................................................... 9
API REST ................................................................................................................................ 10
Overload................................................................................................................................ 11
AVANCEMENT DU PROJET ............................................................................................... 11
CONCLUSION .................................................................................................................. 16

3
SPÉCIFICATIONS DU PROJET
Pour la ges on de projet et la collabora on en équipe, nous u liserons l’ou l Git, qui
assure le suivi des versions et facilite la collabora on entre les développeurs. En complément
de Git, un Diagramme de Gan sera mis en œuvre pour organiser et planifier le travail,
perme ant ainsi de visualiser clairement le calendrier des tâches, les dépendances entre elles
et l'avancement global du projet. En ce qui concerne l'a ribu on et le suivi des tâches, une
approche structurée sera adoptée. Les tâches, également appelées "issues", seront a ribuées
et répertoriées sur Git, et numérotées par ordre d'importance. Ce e méthode perme ra de
prioriser les ac vités et de s’assurer que les éléments cruciaux du projet soient traités en
priorité, garan ssant ainsi une progression ordonnée et efficace du projet.

Concernant la concep on proprement dite de l'applica on, celle-ci sera dotée d'une
page de connexion et d'une page dédiée à la comparaison des en tés Wiki. Les u lisateurs
enregistrés bénéficieront de fonc onnalités supplémentaires telles que la sauvegarde de
favoris et l'accès à un historique de comparaisons Wiki, tandis que les u lisateurs non
connectés auront la possibilité d'effectuer des comparaisons en tant qu'invités.

4
DIAGRAMME D’EXIGENCES

Figure 1: Diagramme des exigences v1

5
ORDRE D’IMPLÉMENTATION

1. Mise en place des conteneurs et de la virtualisa on

2. Créa on d’une page d’accueil
3. Créa on du visuel global du site web
4. Créa on de la page de comparaison
5. Transforma on de la page en page responsive
6. Implémenta on de la fonc on de connexion
7. Implémenta on de la fonc on de l’historique

6
PAGES MAQUETTES FRONT END

Le design du site sera élaboré en u lisant le Framework Bulma qui perme ra de styliser
l'interface u lisateur de manière moderne. Le visuel global sera cohérent sur toutes les pages.

Figure 2: Page des comparaisons

7
Figure 3: Page de connexion

Figure 4: Page des u lisateurs

8
CONCEPTION
ARCHITECTURE BACKEND

L'architecture globale de notre applica on web repose sur une approche basée sur des
conteneurs, gérée par Podman. Ce e technologie permet de déployer et de configurer
plusieurs conteneurs chacun ayant une fonc on spécifique, et de les faire communiquer entre
eux pour le bon fonc onnement de l'applica on sur une machine virtuelle CentOS 9
garan ssant ainsi l’isola on, sécurité et flexibilité.

 Un conteneur Nginx agit en tant que serveur web, gérant les requêtes HTTP et servant
les ressources sta ques de l'applica on.
 Un autre conteneur est dédié au traitement PHP côté serveur, interagissant avec la
base de données et exécutant les scripts nécessaires pour répondre aux requêtes des
clients.
 Le troisième conteneur est dédié à MySQL et héberge la base de données de
l'applica on, gérant toutes les données persistantes nécessaires.

En complément de ce e architecture conteneurisée nous u liserons des technologies et

Framework spécifiques pour développer l'interface et les fonc onnalités de l'applica on.

 Les Framework Bulma et Slim PHP seront ainsi adoptés pour, respec vement, styliser
l'interface u lisateur et structurer l'applica on.

9
  De plus MySQLi sera employé pour faciliter l'interac on avec la base de données
MySQL assurant ainsi une communica on fluide et efficace entre les différentes
composantes de l'applica on.

Ce e combinaison de technologies et d'architectures perme ra de construire une applica on

web robuste, modulaire et efficace, capable de répondre aux besoins spécifiques du projet.

API REST

L'implémenta on d'une API REST est un élément clé de notre projet perme ant une
communica on fluide et efficace entre les différents services et composants de l'applica on.

Ce e API offre une interface standardisée pour l'accès et la manipula on des ressources,
assurant ainsi l'interopérabilité entre les différentes par es de l'applica on.

L'API REST u lise les méthodes HTTP standard (GET, POST, PUT, DELETE) pour perme re la
créa on la lecture la mise à jour et la suppression des ressources. Elle est construite selon les
principes de l'architecture REST, ce qui implique un état sans état et une représenta on des
ressources sous forme de JSON ou XML. Ce e approche permet une maintenabilité op male
facilitant ainsi l'évolu on et l'adapta on de l'applica on a des besoins changeants.

10
Overload

En ce qui concerne la ges on de la surcharge (overload) de l'applica on, plusieurs stratégies

seront mises en œuvre pour assurer la stabilité et la performance du système, même en cas
de trafic élevé. L'applica on sera conçue pour capable de gérer une augmenta on de la charge
en augmentant les ressources. Des mécanismes de mise en cache seront également u lisés
pour réduire le temps de réponse et la charge sur le serveur, en stockant les résultats des
requêtes fréquentes.

AVANCEMENT DU PROJET
Tout d'abord, pour bien commencer le projet, nous avons réalisé en groupe un diagramme
de Gan . Cet ou l nous permet de visualiser l'ensemble des tâches à accomplir et ainsi de
définir les délais et afin d’iden fier des dépendances entre les différentes taches.

Figure 5: Digramme de Gant temporaire

Celui-ci est directement modifiable et consultable sur Git.

Par la suite nous avons Créer un fichier docker-compose.yml qui perme ra de gérer les
conteneurs PHP, MySQL et Nginx de manière automa que à chaque lancement de
l’applica on web sur l’hôte du client.

11
 Figure 6: docker-compose.yml

Dans notre fichier docker-compose.yml la configura on des dépendances, des volumes et

des paramètres est très importante pour assurer le bon lancement de l’applica on.

12
Après avoir configuré notre fichier.yml nous avons ensuite procédé à la réalisa on d'un
prototype de Modèle Logique de Données (MLD) afin de préparer la bonne
configura on/installa on de la base de données MySQL. Le MLD nous permet de définir la
structure de la base de données, en iden fiant les tables nécessaires, les rela ons entre elles,
ainsi que les a ributs de chaque table.

Figure 7: MLD temporaire de BDD

Dans notre modèle logique de données (MLD), les rela ons entre les en tés sont définies
comme suit :

 Rela on entre UTILISATEUR et COMPTE :

Un UTILISATEUR peut posséder plusieurs COMPTES, mais chaque COMPTE est lié à un seul
et unique UTILISATEUR. Ce e rela on est de type 1: N

13
  Rela on entre COMPTE et COMPARAISON :

Un COMPTE peut générer plusieurs COMPARAISONS, cependant, chaque COMPARAISON est

créée par un seul COMPTE, établissant ainsi une rela on 1:N

 Rela on entre COMPARAISON et ARTICLE:

Une COMPARAISON implique l'étude de plusieurs ARTICLES, mais un ARTICLE donné peut
être analysé dans le cadre de différentes COMPARAISONS. Ce e rela on est de nature M:N,
mais est représentée ici comme 1:N à l'aide des clés étrangères dans l'en té COMPARAISON.

 Rela on entre HISTORIQUE et COMPARAISON :

Un HISTORIQUE documente plusieurs COMPARAISONS, mais chaque COMPARAISON figure

dans un seul HISTORIQUE. Il s'agit d'une rela on 1:N.

 Rela on entre HISTORIQUE et UTILISATEUR:

Un HISTORIQUE est associé à un seul UTILISATEUR, tandis qu'un UTILISATEUR peut avoir
plusieurs HISTORIQUES. Ce e rela on est également de type 1:N.

Les a ributs id présents dans chaque en té sont les clés primaires. Les autres a ributs
comme u lisateurId, ar cleId1, ar cleId2, compteId et comparaisonId sont u lisés comme
clés étrangères.

Il est important de noter que ce MLD est temporaire et sera suscep ble d'évoluer au fur et à
mesure du développement du projet. Par exemple il nous manque encore certaines tables
poten ellement comme la table des favoris.

14
Une fois les conteneurs correctement installés, nous avons procédé à l'installa on du
framework Slim et créé nos premières routes de test. Slim est framework PHP perme ant de
développer des applica ons web de manière rapide et efficace. Les premières routes nous
ont permis de vérifier l'intégra on réussie de Slim.

Figure 8: localhost:8080/hello/paul - aperçu de l'applica on web et de sa première route

15
CONCLUSION
Pour conclure, au fil de notre projet, nous avons posé les bases essen elles à la bonne
réalisa on de celui-ci en u lisant des ou ls tels que Git et un Diagramme de Gan , et en
élaborant une architecture intégrant des conteneurs, des frameworks, et prochainement une
API REST. La mise en œuvre du fichier docker-compose.yml et la créa on d'un prototype de
MLD ont été cruciales pour structurer notre applica on.

L'installa on du framework Slim et la mise en place des premières routes vont nous perme re
de poursuivre le développement de notre applica on. Bien que notre MLD soit encore en
cours d'évolu on, il servira de guide pour définir la structure de notre base de données.

La concep on de notre projet visant à créer une applica on web de comparaison d'en tés
Wikipedia n'en est qu'à ses débuts, mais nous sommes sur la bonne voie pour mener à bien
ce projet dans les meilleures condi ons et en respectant les délais du clients (le prof).

16