Vous êtes sur la page 1sur 3

Étude de cas « Système de réservation de vols »

Ce Mini-Projet est extrait en partie du livre « UML2 par la pratique - Études de cas et exercices corrigés. »

Cette étude de cas concerne un système simplifié de réservation de vols pour une agence de
voyages. Les interviews des experts métier auxquelles on a procédé ont permis de résumer leur
connaissance du domaine sous la forme des phrases suivantes :

1. Des compagnies aériennes proposent différents vols.


2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie.
3. Un client peut réserver un ou plusieurs vols, pour des passagers différents.
4. Une réservation concerne un seul vol et un seul passager.
5. Une réservation peut être annulée ou confirmée.
6. Un vol a un aéroport de départ et un aéroport d’arrivée.
7. Un vol a un jour et une heure de départ, et un jour et une heure d’arrivée.
8. Un vol peut comporter des escales dans des aéroports.
9. Une escale a une heure de départ et une heure d’arrivée.
10. Chaque aéroport dessert une ou plusieurs villes.

L'objectif ici est de mettre au point un modèle d’analyse (aussi appelé modèle du domaine) à
partir de ces « connaissances », et d'aboutir à un diagramme de classes UML.
Une première partie de cette étude consiste à définir les classes, leurs attributs et les associations
de ce modèle.

1. Proposez un diagramme de classes de domaines approprié à ce contexte.

A partir de votre modélisation, on vous demande de développer cette application en appliquant


des design patterns.

Principes GRASP
L’objectif de cette partie, qui se focalisera sur le modèle d'analyse précédemment proposé, est
d'obtenir une modélisation aussi générique et réutilisable que possible.

1. Utiliser les principes d'affectation des responsabilités pour rajouter les opérations
correspondant aux connaissances 2 et 5.
2. En utilisation "normale" du système d'information (SI), quelles sont les classes dont on
créera régulièrement des instances ? Pour chacune de ces classes, quelles sont celles qui
seront chargées de les créer ? (Factory)
3. Distinguez dans votre diagramme de classes celles qui ont trop de responsabilités.
Comment faire pour améliorer cet élément de la modélisation ?
4. Réaliser une décomposition en packages en favorisant la réutilisabilité et l'indépendance
de ces packages

Design Patterns
Dans cette partie, on s'intéresse aux classes d'implémentation du SI de l'agence de voyage. On
cherchera à mettre en œuvre des bonnes pratiques de conception afin de favoriser la
réutilisabilité et la maintenabilité du code.
Patterns de création

1. Détailler le processus de création d'une réservation.


2. Détailler le processus de création d'un client (qui peut être soit une personne physique,
soit une personne morale).
3. Détailler le processus de création d'un vol.

Patterns de structure

1. Préciser le point d'entrée du SI de l'agence de voyage, spécifiquement dédié à la


réservation (pas de gestion des vols)
2. Comment faire pour faire en sorte de ne pas ré-entrer toutes les informations sur le
passager si celui-ci est également le client ?
3. Chaque vol ayant un nombre de sièges défini pour chaque compagnie affréteuse,
comment vérifier qu'il reste des places au moment de la création de la réservation sans
augmenter le couplage ?
4. L'agence de voyage souhaite proposer une assurance (en option) sur certains de ses
voyages. Comment implémenter cela ?

Implémentation

1. Implémentez cette solution en respectant toutes les exigences précédemment citées


2. Pusher votre code dans votre repository Git
3. Veillez à déposer un code personnalisé et de bonne qualité (Respect des bonnes
pratiques de développement)

Diagramme de classes par défaut :

Pour vous faire gagner du temps, une ébauche possible peut être une source d’inspiration (Il ne
faut pas l’adopter tel qu'elle l'est) vous est fournie ci-dessous

Vous aimerez peut-être aussi