Introduction :

La phase d‘incubation est la première phase de processus unifié qui permet d‘étudier
le fonctionnement futur du système.
En effet, la modélisation est une représentation d‘un système réel quel que soit sa
forme. Cette représentation intelligible est indispensable pour assurer la
compréhension des systèmes complexe.
Par conséquent, l‘utilisateur d‘une approche de modélisation permet de fournir les
connaissances conceptuelles, méthodologiques et techniques nécessaire pour le
développement d‘un système donné.
Nous nous intéressons, au cours de ce chapitre, à la constitution technique globale
du système par l‘analyse fonctionnelle technique. Nous présentons, au premier lieu,
une modélisation objet permet de valider le besoin de notre client et de décrire le
comportement de chaque intervenant dans notre système.
En se basant sur ses besoins, nous modélisons toutes les étapes qui décrivent le
fonctionnement de notre solution.

1. Modélisation des besoins :

Afin de bien définir notre besoin et de valider, il est primordial de choisir la bonne
approche pour le modéliser.
1.1. Approches de modélisation utilisées :
L‘essor d‘UML (Unified Modeling Language) introduit plusieurs nouveaux concepts et
diagrammes utiles pour la modélisation d‘un processus. En particulier, le diagramme
de structure composite avec les concepts d‘une classe structurée permet maintenant
de décrire l‘interconnexion statique des parties d‘un système complexe. Les
avancées du diagramme de séquence permettent également de décrire des
scénarios d‘interaction d‘une façon descendants en ajoutant progressivement des
niveaux d‘architecture.
De plus, la modélisation UML permet de vulgariser les aspects liés à la conception et
à l‘architecture, propres au projet, à l‘utilisateur. Aussi, elle apporte une
compréhension rapide du programme à d‘autres développeurs externes en cas de
reprise du projet et facilite sa maintenance.
1.2. Identification des acteurs :
 Visiteur
 Client
  Administrateur
 Fournisseur
2. Modélisation des besoins énoncés par UML :
Chaque système UML permet de fournir une représentation abstraite des objets du système.
Ces derniers vont être modélisés par le diagramme cas d‘utilisation. Après, Il est
indispensable de décrire en général et en entier le comportement de notre système
respectivement par le diagramme de classes et le diagramme de séquence.
2.1. Diagramme de cas d’utilisation :
Le diagramme de cas d‘utilisation est un diagramme comportemental, appelé « Use
Case Diagram » dans le langage UML. L‘objectif de ce diagramme est de donner
une vision globale du comportement fonctionnel d'un système en identifiant les
services qu‘il rend. Il est utile pour des présentations auprès des acteurs d'un projet,
mais pour le développement, le cas d'utilisation est plus approprié.
Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur
(humain) et un système. Il contient un ou plusieurs scénarios qui définissent
comment le système devraient interagir avec les utilisateurs pour atteindre un but ou
une fonction spécifique d'un travail. Il est une unité significative de travail.
Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs (actors),
ils interagissent avec les cas d'utilisation (use cases) :
• L‘Acteur : il représente l'abstraction d'un rôle joué par des entités externes
(utilisateur, dispositif matériel ou autre système), il peut consulter ou modifier l'état du
système, ce dernier fournit un service qui correspond à son besoin.
• Use case : peut-être définit comme l‘ensemble des actions réalisées par le
système, en réponse à une action d'un acteur. L'ensemble des cas d‘utilisations
décrit les objectifs du système.
2.1.1. Diagramme de cas d’utilisation global :
Les rôles (acteurs) :
• Visiteur :
▪ C’est un utilisateur non inscrit ou non connecté.
▪ Il peut consulter les voitures disponibles à la vente ou choisir de
s’inscrire/se connecter pour accéder à plus de fonctionnalités.
• Client (hérite des droits du Visiteur) :
▪ C’est un utilisateur inscrit et connecté.
 ▪ Il peut consulter les voitures, acheter un véhicule, accéder à la section
des enchères et y participer.
• Fournisseur :
▪ Il représente un partenaire ou vendeur qui gère les véhicules mis en
vente sur la plateforme.
▪ Il a accès à la gestion du stock de voitures (ajout, modification ou
suppression), mais doit être authentifié.
• Administrateur :
▪ Il supervise l’ensemble du système.
▪ Il a la possibilité de réinitialiser les enchères et de consulter la salle des
enchères.
▪ Il n’a pas le droit de modifier les voitures ni d’en ajouter.
Scénario:

Le Visiteur doit accéder à MetroRide et consulter la liste des véhicules. Il va décider

de s'inscrire/se connecter pour interagir davantage.
Une fois qu’il est connecté, il devient Client et il peut :
o Acheter une voiture directement,
o Accéder à la salle des enchères pour voir les voitures en vente aux
enchères,
o Miser sur la voiture de son choix.
Le Fournisseur, après la connexion, peut gérer le stock des voitures.
L'Administrateur, lorsqu’ il est connecté, peut réinitialiser les enchères si nécessaire,
notamment après la fin d’une session.
 Figure 1 : Diagramme de cas d’utilisation global

Description textuelle du cas d’utilisation « Global » :

Tableau 1 : Description textuelle du cas d’utilisation « Global »

Cas d'utilisation Description

Consulter la Permet de parcourir les véhicules disponibles sans être
collection connecté.
S'inscrire / Se Requis pour accéder aux services personnalisés (achat,
connecter enchères, gestion).
Acheter une voiture Réservé aux clients connectés.
Accéder aux
Affiche les véhicules disponibles aux enchères.
enchères
Miser sur une voiture Permet à un client de placer une enchère sur un véhicule.
Fonctionnalité destinée aux fournisseurs pour gérer leur
Gérer les voitures
catalogue.
Réinitialiser les Permet à l’administrateur, si nécessaire, de remettre à zéro
enchères l’état des enchères.

2.1.2. Diagramme de cas d’utilisation pour Visiteur + Client :

Rôles des acteurs :

 Visiteur :
 Toute personne accédant au site MetroRide sans être connectée. Il peut
uniquement consulter la collection de voitures disponibles et s’inscrire ou se
connecter pour accéder à plus de fonctionnalités.
 Client (hérite du rôle de Visiteur):
Un utilisateur inscrit et connecté. Il dispose de droits supplémentaires : il peut
acheter une voiture, accéder à la salle des enchères et y placer une mise.
Scénario :

Exemple : Un nouveau visiteur veut acheter un véhicule.

Il accède au site MetroRide et consulte la collection de voitures. Pour passer à

l’achat, il doit s’inscrire ou se connecter. Une fois connecté, il devient "Client" et peut
accéder à plus de fonctionnalités.

Il peut désormais acheter une voiture, ou accéder à la salle des enchères. S’il choisit
de participer à une enchère, il accède aux voitures disponibles et peut miser sur celle
de son choix, en ajoutant une surenchère de 100€.

Figure 2 : Diagramme de cas d’utilisation pour Visiteur et Client

Description textuelle du cas d’utilisation pour «Visiteur + Client» :

Tableau 2 : Description textuelle du cas d’utilisation pour «Visiteur + Client »

Cas d’utilisation Description Conditions

Accessible à tous les visiteurs. Permet de
Consulter la
parcourir les voitures par catégorie, voir Aucune (disponible
collection de
leurs détails, et comparer les modèles même sans connexion)
voitures
disponibles.
S'inscrire / Se Action nécessaire pour transformer un Aucun (point d’entrée
Cas d’utilisation Description Conditions
visiteur en client. Permet d’accéder aux
connecter pour les visiteurs)
fonctionnalités liées à l’achat ou à l’enchère.
Cas d’utilisation réservé au client. Il inclut
Acheter une obligatoirement le processus <<include>> :
voiture d’authentification pour garantir la traçabilité S'inscrire / Se connecter
et la sécurité.
Donne au client la possibilité de consulter les
Accéder aux <<include>> :
voitures mises en enchère avec minuteurs et
enchères S'inscrire / Se connecter
prix de départ.
<<include>> :
Miser sur une S'inscrire / Se connecter
Permet de surenchérir sur un véhicule.
voiture <<include>> : Accéder
aux enchères

2.1.3. Diagramme de cas d'utilisation pour Fournisseur :

Rôle du Fournisseur :

Le Fournisseur représente un acteur externe du système MetroRide. Son rôle

principal est de gérer les voitures proposées sur la plateforme, que ce soit en
ajoutant, en modifiant ou en suivant les interactions des clients potentiels. Il ne
participe pas aux enchères ou aux achats directs, mais agit comme gestionnaire du
stock de véhicules.
Scénario :

Le fournisseur accède à la plateforme et procède à son authentification.

Pour la Gestion du parc, il doit accéder à la section "Gérer les voitures" pour voir la
liste de ses voitures.
Il peut mettre à jour les informations d’un véhicule déjà existée (ex. : changement de
prix). Ou bien Il remplit un formulaire avec les détails d’un nouveau modèle de
voiture à ajouter. (Nom, prix, photo, etc.). La voiture est ensuite visible par tous les
visiteurs sur la page collection.
Pour le suivi commercial, Il contacte les clients intéressés par ses annonces pour
proposer une offre personnalisée ou répondre à des questions.
 Figure 3 : Diagramme de cas d’utilisation pour Fournisseur

Description textuelle du cas d’utilisation pour «Fournisseur» :

Tableau 3 : Description textuelle du cas d’utilisation pour «Visiteur + Client» :

Cas Description
d'utilisation
S'inscrire / Se Avant toute interaction avec la plateforme, le fournisseur doit
connecter s’authentifier. Cela garantit la sécurité et l’identification de ses
actions. Ce cas d’utilisation est requis (relation <<include>>) dans
toutes les autres actions.
Gérer les Permet au fournisseur d’accéder à l’ensemble des véhicules qu’il
voitures propose sur MetroRide. Il peut en ajouter de nouveaux, les supprimer
ou modifier leurs données.
Mettre à jour Permet de modifier les informations techniques ou commerciales
les détails (prix, description, disponibilité, etc.) d’un véhicule déjà ajouté. Cette
action suppose que le fournisseur soit connecté.
Contacter les Le fournisseur peut interagir avec les clients intéressés par ses
clients véhicules via un système de messagerie ou de notifications (suivi
d’intérêt, relances commerciales, etc.). L’authentification est
également requise ici.

2.1.4. Diagramme de cas d'utilisation pour Administrateur :

Rôle de l’administrateur :

L’administrateur joue un rôle clé dans le bon fonctionnement du système MetroRide.

Bien qu’il n’intervienne pas dans la vente directe ou dans les enchères en tant que
participant, il dispose d’actions de contrôle et de gestion essentielles. Son principal
objectif est d’assurer la régulation et la supervision des annonces et des activités
d’enchères.
Scénario :
L’administrateur se connecte à l’espace d’administration. Il accède à la salle des
enchères en cours pour s’assurer qu’elles se déroulent normalement. Il détecte
qu’une enchère est terminée, ou qu’une anomalie est survenue (bug, comportement
abusif). Il utilise alors la fonction « Réinitialiser les enchères » pour remettre à zéro le
processus. Il peut également passer à la gestion des annonces et désactiver celle
jugée inappropriée.

Figure 4 : Diagramme de cas d’utilisation pour Administrateur

Description textuelle du cas d’utilisation pour «Administrateur» :

Tableau 4 : Description textuelle du cas d’utilisation pour «Administrateur» :

Cas Description
d'utilisation
Accéder aux Permet à l'administrateur de consulter en temps réel la salle des
enchères enchères, suivre les enchères en cours, et surveiller le déroulement
des mises.
Gérer les L’administrateur peut examiner, approuver ou désactiver certaines
annonces annonces de vente ou d’enchères en cas de besoin (ex. : contenu
inapproprié, erreur sur le véhicule, etc.).
Réinitialiser Cas d’utilisation optionnel qui permet à l'administrateur de réinitialiser
les enchères une enchère (remise à zéro du prix ou du minuteur) en cas d'incident
(<<extend>>) technique, de comportement abusif ou lorsque la session d’enchères
est terminée. Ce cas est lié de manière conditionnelle au cas «
Accéder aux enchères », car il ne peut être activé qu’après
consultation des enchères.

2.2. Diagramme de séquence :

Le diagramme de séquence est un diagramme comportemental appelé « Sequence
Diagram » dans le langage UML. Il est rattaché à un cas d‘utilisation et décrit ce
dernier en entier ou en partie. En effet, il est une solution de modélisation dynamique
très appréciée. Ce type de modélisation s'intéresse aux interactions se produisant à
l'intérieur de notre système selon un ordre chronologique.
D‘après les figures suivantes, plusieurs scénarios peuvent se dérouler via notre site.
Parmi ses scénarios, quatre seront détaillés par la suite, en faisant une description
textuelle avec des diagrammes de séquences successivement comme illustré dans
les figures ci-dessous.
2.2.1. Diagramme de séquence pour l'achat direct :

Figure 5 : Diagramme de séquence pour l'achat direct

2.2.2. Diagramme de séquence pour les enchères :

Figure 6 : Diagramme de séquence pour les enchères

 2.2.3. Diagramme de séquence pour la réinitialisation des enchères par
l'administrateur :

Figure 7 : Diagramme de séquence pour la réinitialisation des enchères par l'administrateur

2.2.4. Diagramme de séquence d'inscription d'un utilisateur pour

participer à une enchère :

Figure 8 : Diagramme de séquence d'inscription d'un utilisateur pour participer à une enchère

2.3. Diagramme de classe :

Le diagramme de classes est essentiel en modélisation orientée objet, c’est le seul
diagramme obligatoire. Contrairement au diagramme de cas d’utilisation qui montre
le système vu par les acteurs, le diagramme de classes montre sa structure interne.
Il représente les objets qui interagissent pour réaliser les cas d’utilisation, et un
même objet peut participer à plusieurs cas. Ce diagramme est statique, il ne montre
pas le déroulement dans le temps ni les détails d’un cas d’utilisation. Il modélise les
classes du système et leurs relations (association, généralisation, dépendances)
sans dépendre d’un langage de programmation.
La figure suivante représente le diagramme de classes décrivant le fonctionnement
du notre système.

Figure 9 : Diagramme de classe

Rôles des classes :

Tableau 5 : Description textuelle des rôles des classes

Classe Rôle
Utilisateur Classe mère générique représentant toute personne interagissant
avec le site. Elle contient les attributs de base (id, nom, email, mot de
passe) ainsi que les méthodes de connexion et d'accès aux enchères.
Client Sous-classe d’Utilisateur représentant un acheteur potentiel. Il peut
acheter des voitures et les consulter.
Fournisseu Sous-classe de Utilisateur représentant une personne qui ajoute ou
r gère les voitures en vente. Il peut contacter les clients et gérer son
stock.
Voiture Représente une voiture mise en vente ou en enchère. Elle possède
des informations comme le modèle, l’image, le prix et les méthodes de
mise à jour.
 Enchère Représente une vente aux enchères contenant plusieurs voitures,
avec des méthodes pour démarrer, fermer l'enchère et afficher les
offres.
Admin Représente l’administrateur qui peut réinitialiser les enchères et les
gérer, mais sans modifier directement les voitures.

Scénario d’utilisation du système :

Un utilisateur visite MetroRide et peut s’inscrire/se connecter via la classe Utilisateur.
Le client connecté peut :
o Parcourir la collection via consulterVoitures ()
o Acheter une voiture via acheterVoiture ()
o Participer à des enchères via voirEncheres () et placerMise ()
Le fournisseur, après authentification :
o Ajoute une voiture via ajouterVoiture ()
o Modifie ou supprime ses offres via modifierVoiture () et
supprimerVoiture().
o Peut contacter les clients pour les offres ou promotions via
contacterClients ().
L’admin supervise les enchères, les démarre ou les réinitialise via la méthode
reinitialiserEnchere () de la classe Admin, et collabore avec la classe Enchère, qui
contient les méthodes demarrerEnchere () et fermerEnchere () pour gérer le cycle de
vie des enchères.
La classe Enchère est directement liée à la classe Voiture car elle inclut une liste de
voitures mises aux enchères (voitures: List<Voiture>), ce qui permet de gérer
l’affichage, les mises et les délais restants pour chaque véhicule.

Conclusion :
Ce chapitre a été consacré à la modélisation UML. Nous avons exposé les différents
diagrammes élaborés lors d‘une étude conceptuelle du projet tels que les
diagrammes de cas d‘utilisation, les diagrammes de séquences et le diagramme de
classes. Cette conception adoptée est essentielle pour la phase de Réalisation qui
constitue l‘objet du chapitre dernier.