Cas « réservations hôtelières »

Présentation au sujet: "Cas « réservations hôtelières »"— Transcription de la présentation:

1 Cas « réservations hôtelières »
Partie 2 SYSTEMES D’INFORATION AUBE FLEURY Laetitia …. IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

2 Construction du schéma dynamique
Phase 1 : Identification des événements Phase 2 : comportement du système face à un événement Phase 3 : intégration des comportements Phase 4 : documenter le schéma conceptuel IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

3 Phase 1 : Identification des événements
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

4 Phase 2 : Comportement du système face à un événement
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

5 Le modèle entité / associations MCD (Modèle Conceptuel des Données)
Permet de structurer le modèle de données d’une future base de données 1,1 0,N HOTEL Appartient à REGION Entité Association Entité IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

6 Le modèle entité / associations MCD (Modèle Conceptuel des Données)
du cas étudié  IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

7 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
Formes normales Départ du schéma conceptuel IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

8 Modèles du réel à l’implémentation
Schéma Relationnel HOTEL IdHotel Nom Adresse IdRegion REGION Hotel (IdHotel, Nom, Adresse, IDRegion) Region (IdRegion, Nom) Monde réel Schéma Conceptuel (MCT) HOTEL REGION Appartient à 1,1 0,N Validation Normalité Implémentation dans SGBD IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

9 Le modèle relationnel présentation
HOTEL IdHotel Nom Adresse IdRegion REGION Hotel (IdHotel, Nom, Adresse, IDRegion) Region (IdRegion, Nom) Le modèle relationnel présentation But : exprimer le modèle conceptuel sous forme de « relations » On utilise pour cela des « tables » : ce sont des « moules » pour les futures données qui seront stockées Chaque table (= moule) est composée d’attributs (= rubriques) Chaque table contiendra des enregistrements (= données) IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

10 Le modèle relationnel tables et enregistrements
La table (= le moule) Hotel (IdHotel, Nom, Adresse) Une table est composée d’attributs, dont une ou plusieurs clés Les enregistrements (= les données) (001, ‘Au Bon Lit’, ‘24 rue Marcel LILLE’) (002, ‘Au Bon Dodo’, ‘32 rue Lulu LYON’) (003, ‘Au Bon Repos’, ‘7 rue René BREST’) HOTEL IdHotel Nom Adresse Le moule des Hôtels = la table « HOTEL » 1 Hôtel stocké = 1 enregistrement IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

11 Le modèle relationnel La notion de « clé » dans une table
Chaque table a besoin d’un identifiant qui définit chaque enregistrement de façon parfaite et unique : c’est la clé La ou les clés d’une table sont soulignées Une mauvaise clé peut nuire à la cohérence de la base de données Exemple : si la clé choisie est le nom de l’hôtel, cela peut poser problème si plusieurs hôtels portent le même nom On préfèrera alors un identifiant numérique (par exemple) pour que l’unicité soit certaine IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

12 Le modèle relationnel La notion de « clé » dans une table
Hotel (IdHotel, Nom, Adresse) Clé HOTEL IdHotel Nom Adresse Attributs Table IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

13 Passage du modèle conceptuel au modèle relationnel
CAS n°1 : au moins une des cardinalités est de type « 1,1 » ou « 0,1 » HOTEL REGION Appartient à 1,1 0,N  On construit une table par entité HOTEL IdHotel Nom Adresse IdRegion REGION Hotel (IdHotel, Nom, Adresse, IDRegion) IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004 Region (IdRegion, Nom)

14 Passage du modèle conceptuel au modèle relationnel
CAS n°2 : les deux cardinalités peuvent dépasser la valeur 1 HOTEL REGION Appartient à 1,2 0,N On construit une table par entité et une table par association HOTEL IdHotel Nom Adresse REGION IdRegion HOT_REG Hot_Reg (IdHotel, IdRegion) Hotel (IdHotel, Nom, Adresse) Region (IdRegion, Nom) IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

15 Validation du modèle relationnel : Les 3 formes normales
Vérifier la normalité d’un schéma conceptuel sert à vérifier la cohérence de la future base On évite ainsi les redondances d’information dans la base de données, qui nécessiteraient des traitements lourds de mise à jour en cas de modification d’informations dans les données IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

16 Formes normales 1ère forme normale
Une relation est en 1ère forme normale si : elle possède une clé, chaque attribut est atomique Exemple de table « ratée » Hotel (IdHotel, Nom, Adresse, {IdRegion}) serait impossible pour le cas des régions multiples Les enregistrements auraient des données de taille variable : (001, ‘Au Bon Lit’, ‘24 rue Marcel LILLE’, {01, 02}) (002, ‘Au Bon Dodo’, ‘32 rue Lulu LYON’ , {01, 02, 03}) HOTEL IdHotel Nom Adresse {IdRegion} REGION IdRegion Nom IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

17 Formes normales 1ère forme normale
Exemple (suite) On préfèrera Hotel (IdHotel, Nom, Adresse) (001, ‘Au Bon Lit’, ‘24 rue Marcel LILLE’) (002, ‘Au Bon Dodo’, ‘32 rue Lulu LYON’) Hot_Reg (IdHotel, IdRegion) (001, 01) (001, 02) (002, 01) (002, 02) (002, 03) HOTEL IdHotel Nom Adresse HOT_REG IdHotel IdRegion REGION IdRegion Nom IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

18 Formes normales 2ème forme normale
Une relation est en 2ème forme normale si : Elle est en 1ère forme normale Un attribut n’appartenant pas à la clé ne peut dépendre que d’une partie de la clé Cela nuirait au principe d’unicité formé par la clé toute entière IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

19 Formes normales 2ème forme normale
HOTEL IdHotel Nom Adresse HOT_REG IdRegion NomRegion Formes normales 2ème forme normale Exemple de table « ratée » Seul la variation de IdRegion ferait varier NomRegion HOT_REG IdHotel IdRegion NomRegion }Clé Cet Attribut ne dépend que de l’attribut IdRegion de la clé IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

20 Formes normales 3ème forme normale
Une relation est en 3ème forme normale si : Elle est en 2ème forme normale Il n’y a pas de dépendances fonctionnelles entre attributs n’appartenant pas à la clé  La variation d’un attribut hors-clé ne peut faire varier un autre attribut hors-clé, sinon il devrait appartenir à la clé IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

21 Formes normales 3ème forme normale
Exemple de table « ratée » Solution possible ARTICLE IdArticle PrixHT PrixTTC Ces deux Attributs sont interdépendants mais aucun n’appartient à la clé ARTICLE IdArticle PrixHT TauxTVA IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

22 Phase 3 : Intégration des comportements
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

23 Intégration des différentes descriptions du comportement
Intégration obtenue en faisant l´union des transitions dans un même graphe Chaque objet remora = une entité ou une relation du modèle Présent une seule fois, opération la concernant convergent vers l´objet Complétude : vérification que le cycle de vie de tout objet est couvert par une partie du schéma statiqe décrivant le comportement du système en dynamique et vice versa. IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

24 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
QUESTION 17 Concernant la synchronisation de l´évènement EV1 description annexe 9 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

25 Synchronisation de l´événement EV2
La transition de EV2 « un client annule sa réservation » déclanche sans condition : Ajout dans l´historique de la réservation (objet type HISTOETATRES) d´un état « annulée » OP10 modif des dispos de la chambre de l’objet type DISPOCHAMBRE OP11 Changement d’état de la RESERVATION : « annulée » OP12 pénalisation pour annulation trop tardive (DATEBEDDEM -8jours) NB attention à la différence HISTOETATRES RESERVATION IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

26 Synchronisation de l´événement EV3
La transition de EV3 « le système constate une nouvelle dispo » A comme EV1 l’issue : Si la demande peut être satisfaite alors L´historique de son état HISTOETATDEM est mis a « acceptée » OP3 Une reservation est crée RESERVATION OP6 Des chambres lui sont allouées CHAMBRERESERVEE OP8 L’état de la reservation est mis à « OK » HISTOETATDEM OP7 La dispo des chambres est mis à jour DISPOCHAMBRE OP9 NB : EV1 ne traite qu’une seule demande alors qu’EV3 doit passer toutes les demandes en attente IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

27 Synchronisation des événements EV4 et EV5
La transition EV4 « annulation d’une demande en attente par le système » déclanche sans condition l’opération de changement d’état de la demande sur l’objet type (HISTOETATDEM) qui est mis à « annulée » la transition EV5 « annulation du client de sa demande en attente » déclanche sans condition : L’opération de chgt d’état de la demande su l’objet type (HISTOETATDEM) qui est mis à « annulée » La demande annulée n´entraînent pas d´autre opération IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

28 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
Evénement EV6 EV6 « modification des ressources» permet la prise en compte par le système de l´ensemble des modifications modifs d’infrastructure EV6 va être ensuite divisée en 3 évènements distincts soit : EV7 : création d’une ressource (station, hôtel, chambre) EV8 : suppression d’une ressource (hôtel, chambre) EV9 : modification d’une ressource (station, hôtel, chambre) Attention EV6 ne prend pas en charge l’arrivée de nouvelles ressources EV3 prend le relais pour transformer ces ressources en reservations IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

29 Synchronisation de l´événement EV7
Conceptualisation EV7 « création ressource » Un seul événement EV7 pour tous les cas de création si on a une station à créer, on pourra créer grâce au même EV7 les hôtels et leurs chambres de cette nouvelle station. IDEM pour les hôtels… EV7 déclenche en fonction de son prédicat les opérations suivantes : La création d’une station (OP14) La création d’un hôtel (OP16) La mise à jour des tarifs d’une chambre PHS, PBS Objet Type PRIXCHAMBRE (OP18) La m à j des périodes de disponibilité d’une chambre sur l’Objet Type DISPOCHAMBRE (OP17) La m à j des saisons d’une station Objet Type TYPESAISON (OP15) Rq : Les mises à jour sont parfois des créations IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

30 Synchronisation de l´événement EV7
Condition de déclenchement : OP14 : création stations OP15 : création saison d’une station =>Condition C6, la ressource à créer est une station. OP16 : créer hôtel => condition C7, il existe au moins un hôtel à créer. OP17 : période de dispo chambre et OP18 tarif d’1 chambre => Déclenchement inconditionnel car sinon liste vide. Facteurs de déclenchement : Permettra de créer de manière itérative des nouvelles ressources par exemple une liste d’hôtels. OP15 : déclare type saison d’une station => toutes les saisons OP16 : Ouvrir hôtel => ens. hôtels OP17 : dispo des chambres => ens. périodes de dispo OP18 : prix par type saison => ens IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

31 Question 18 : compléter le modèle dynamique
Le cycle de vie des réservations : Création Modification Annulation Une reservation peut être interrompue cad que la personne nóccupe pas l´hôtel jusqu´au terme de sa reservation => disponibilité D´autre part dáutre événement ont été rajouté : Consultation par une personne des informations e concernant Demande par une personne de sa suppresion du fichier client Modification des informations sur une personne IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

32 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
EV11 EV13 EV12 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

33 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
UML Unified Modeling Language Etape importante dans la convergence des notations utilisées dans le domaine de l´analyse et de la conception objet Synthèse 3 méthodes OMT, BOOCH, OOSE Grands éditeurs du marché informatique Règles générale : Bon niveau de cohérence et d´homogénéité sur l´ensemble des modèles, Des règles d´écriture et de représentation formalisées les principaux éléments généraux IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

34 Principaux éléments généraux (1)
Stéréotype = 1 Moyen de de classer les éléments de la modélisation Facilite l´élaboration de métamodèles évolution générale d´UML prise en compte de situation particulières à l´entreprise S´applique principalement aux classes identification d´une typologie de classe Paquetage Découpage logique du système correspondant à des espaces de nommage homogènes Relation de dépendance en trait pointillé Client „acteur“ IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

35 Principaux éléments généraux (2)
Note : Commentaire explicatif d´un element UML Contrainte : Note ayant une valeur sémantique particulière pour un élément de la modélisation S´écrit entre accolade { } { ceci est une contrainte } À l´intérieur d´une note Language OCL Object Contraint Language disponible en UML Spécifique à l´expression de contraintes Commentaire IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

36 Principaux éléments généraux (3)
Principales règles d´écriture des noms et des expressions Nom : Simple : chaîne de caractères Composé : nom simple . Complément de dénomination Nomchambre.Nomhôtel Etiquette : Dénomination textuelle d´une symbole ou d´une propriété du modèle Valeur : Une valeur initiale peut être donnée à un élément IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

37 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
Les 9 Diagrammes UML description d´une partie du système ou description du système d´un point de vue particulier Diagramme des cas d´utilisation DCU Diagramme de classes description statique du système Diagramme d´objets DOB Diagramme état transition DET Diagramme d´activité DAC Diagramme de séquence DSE Diagramme de collaboration DCO Diagramme de composants DCP Diagramme de déploiement DDP UML décrit concept et formalisme des diagrammes mais ne propose pas de démarche de conception IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

38 Positionnement des 9 diagrammes
DCU DSE DAC DCO DOB DET DCL DCP DDP Description statique et dynamique du système Description de l´architecture du système IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

39 Diagramme des cas d´utilisation
Description des intéractions entre les acteurs et le système Moyen de recueillir et décrire les besoins des acteurs Chaque cas décrit sous forme textuelle Travail d´identification des cas Acteurs connus Utilisateur type Appartiennent à une ou plusieurs classe suivant les rôles qu´ils tiennent prp système Représentation Acteur Cas d´utilisation Intéraction entre acteur et cas d´utilisation Nom du cas d´utilisation IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

40 Diagramme des cas d´utilisation
Relation entre cas d´utilisation Relation d´inclusion : 1 instance de A contient le comportement décrit dans B Relation d´extension 1 instance de A peut être étendue par le comportement décrit dans B Relation de généralisation Question 19 : construction du diagramme des cas d´utilisation du système de gestion des réservations IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

41 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
PERSONNE Consulter infos le concernant Demander à être supprimer Modifier infos Faire D de R Annuler R Modifier R Annuler une D en attente Interrompre R HÔTELIER Demander création nouvelle ressource Modifier ressource Supprimer GESTIONNAIRE Consulter planning de R historiqueD historiqueR IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

42 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
Examen D en attente Ctrl paiement R Surtaxer PERSONNE Faire D de R Annuler R Modifier R Annuler une D en attente Interrompre R HÔTELIER Demander création nouvelle ressource Modifier ressource Supprimer Examiner R effectuées IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

43 Phase 4 : Documenter le schéma conceptuel
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

44 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
Type de documentation Afin d’aider les équipes de développement, 2 types de documentation complémentaires : Le schéma conceptuel : description des élément du produit la documentation du processus : justification des choix de conception IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

45 Documentation du processus
Pour la documentation concernant la partie statique et la partie dynamique, la forme retenue est la suivante : La décision de conception La justification les choix alternatifs considérés IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

46 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
Exemple : Décision 1 Décision 1 : stocker toutes les demandes Justification : permet de garder une trace du flux des demandes dans le temps dans le but de vérifier l’adéquation des ressources existantes aux demandes Choix alternatifs : ne stocker que les demandes « en attente » ne stocker que les réservations IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

47 Décision 2 - historiser les demandes
Objet Attributs HistoEtatDem (NumDem, DateEtatDem, EtatDem) A chaque nouvelle demande, une instance de HistoEtatDem est créée, avec les états suivants possibles: EtatDem = « Satisfait », « en attente », « refusée » IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

48 Décision 2 - historiser les demandes
Table : HistoEtatDem Instances de l’objet HistoEtatDem EtatDem DateEtatDem EtatDem: « satisfait » = 1 « en attente » = 2 « refusé » = 3 NumDem IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

49 Décision 2 - historiser les demandes
Demandes 027 et 029 annulées le lendemain de leur mise en attente Demande 028 satisfaite dans la journée EtatDem: « satisfait » = 1 « en attente » = 2 « refusé » = 3 Table : HistoEtatDem IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

50 Documentation du processus
Décision 2 : historiser les demandes Justification : permet d’analyser le comportement des clients en fonction de l’état de leur demande (satisfaite ou non) Choix alternatifs : ne stocker que les demandes non satisfaites gérer un historique dans l’objet DEMANDE IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

51 Décision 3 - historiser les réservations
Objet Attributs HistoEtatRes (NumRes, DateEtatRes, EtatRes) Lorsqu’une demande peut être satisfaite ou lorsqu’une chambre se libère, une réservation est crée. Elle peut ensuite être annulée. EtatRes = « OK », « annulée » IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

52 Documentation du processus :
Décision 3 : historiser les réservations Justification : permet d’analyser le comportement des clients (annulations) et l’adéquation des ressources (nouvelles disponibilités) Choix alternatifs : ne stocker que les annulations gérer un historique dans l’objet RESERVATION IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

53 Décision 4 : allouer les chambres aux réservations
Lorsqu’une réservation est effectuée, une chambre est réservée Objet Attributs Reservation (NumRes, NumHot, NumPers, NumDem) ChambreReservee (NumRes, NumCha) PrixChambre (NumCha, NumHot, TypeSai, Prix) DispoChambre (NumCha, NumHot, DateDebDispo, DateFinDispo) IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

54 Documentation du processus
Décision 4 : allouer les chambres aux réservations Justification : permet d’allouer simplement un nombre illimité de chambres pour une réservation, dans des hôtels différents Choix alternatifs : avoir un objet CHAMBRE qui contient le numéro de l’hôtel, l’état (réservé ou non) IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004