Cas « réservations hôtelières »

IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

1

Cas « réservations hôtelières »

Partie 2SYSTEMES D’INFORATION

AUBE FLEURY Laetitia….


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


3

Phase 1 : Identification des événements


4

Phase 2 : Comportement du système

face à un événement


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

HOTEL REGIONAppartient à1,1 0,N

Entité Association Entité


6

Le modèle entité / associations

MCD (Modèle Conceptuel des Données)

Le modèle entité / association du cas étudié


7

Formes normalesDépart du schéma conceptuel


8

Modèles du réel à l’implémentation

Validation Normalité

Implémentation dans SGBD

Monde réelSchéma

Conceptuel(MCT)

HOTEL REGIONAppartient à

1,1 0,N

SchémaRelationnel

HOTELIdHotelNom

AdresseIdRegion

REGION

IdRegionNom

Hotel (IdHotel, Nom, Adresse, IDRegion)Region (IdRegion, Nom)


9

Le modèle relationnelpré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)

HOTELIdHotelNom

AdresseIdRegion

REGION

IdRegionNom

Hotel (IdHotel, Nom, Adresse, IDRegion)Region (IdRegion, Nom)


10

Le modèle relationneltables 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 59000 LILLE’)(002, ‘Au Bon Dodo’, ‘32 rue Lulu 69000 LYON’)(003, ‘Au Bon Repos’, ‘7 rue René 29000 BREST’)

HOTELIdHotelNom

Adresse

Le moule des Hôtels = la table « HOTEL »1 Hôtel stocké = 1 enregistrement


11

Le modèle relationnelLa notion de « clé » dans une

tableChaque 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éesUne 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 nomOn préfèrera alors un identifiant numérique (par exemple) pour que l’unicité soit certaine


12

Le modèle relationnelLa notion de « clé » dans une

table

Hotel (IdHotel, Nom, Adresse)

HOTELIdHotelNom

Adresse

Table

Attributs

Clé


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 »


HOTELIdHotelNom

AdresseIdRegion

REGIONIdRegion

Nom

On construit une table par entité

Hotel (IdHotel, Nom, Adresse, IDRegion) 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

HOTELIdHotelNom

Adresse

REGIONIdRegion

Nom

HOT_REGIdHotel

IdRegion


On construit une table par entité et une table par association

Hot_Reg (IdHotel, IdRegion)Hotel (IdHotel, Nom, Adresse) Region (IdRegion, Nom)


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


16

Formes normales1è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 multiplesLes enregistrements auraient des données de taille variable :

(001, ‘Au Bon Lit’, ‘24 rue Marcel 59000 LILLE’, {01, 02})(002, ‘Au Bon Dodo’, ‘32 rue Lulu 69000 LYON’ , {01, 02, 03})

HOTELIdHotelNom

Adresse{IdRegion}

REGIONIdRegion

Nom


17

Formes normales1ère forme normale

Exemple (suite)On préfèrera

Hotel (IdHotel, Nom, Adresse)(001, ‘Au Bon Lit’, ‘24 rue Marcel 59000 LILLE’)(002, ‘Au Bon Dodo’, ‘32 rue Lulu 69000 LYON’)Hot_Reg (IdHotel, IdRegion)(001, 01)(001, 02)(002, 01)(002, 02)(002, 03)

HOTELIdHotelNom

Adresse

REGIONIdRegion

Nom

HOT_REGIdHotel

IdRegion


18

Formes normales2ème forme normale

Une relation est en 2ème forme normale si :

Elle est en 1ère forme normaleUn 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


19


Exemple de table « ratée »

HOT_REGIdHotel

IdRegionNomRegion Cet Attribut

ne dépend que de l’attribut IdRegion

de la clé

}Clé

Seul la variation de IdRegion

ferait varier NomRegion

HOTELIdHotelNom

Adresse

HOT_REGIdHotel

IdRegionNomRegion


20


Une relation est en 3ème forme normale si :

Elle est en 2ème forme normaleIl 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é


21


Exemple de table « ratée »

Solution possible

ARTICLEIdArticlePrixHTPrixTTC

Ces deux Attributssont interdépendants

mais aucun n’appartient à la clé

ARTICLEIdArticlePrixHT

TauxTVA


22

Phase 3 : Intégration des comportements


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èlePrésent une seule fois, opération la concernant convergent vers l´objetComplé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.


24

QUESTION 17Concernant la synchronisation de l´évènement EV1 description annexe 9


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 » OP10modif des dispos de la chambre de l’objet type DISPOCHAMBRE OP11Changement d’état de la RESERVATION : « annulée » OP12 pénalisation pour annulation trop tardive (DATEBEDDEM -8jours)

NB attention à la différence HISTOETATRES RESERVATION


26


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


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


28

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


29


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


30


Condition de déclenchement :OP14 : création stationsOP15 : 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 saisonsOP16 : Ouvrir hôtel => ens. hôtelsOP17 : dispo des chambres => ens. périodes de dispoOP18 : prix par type saison => ens


31

Question 18 : compléter le modèle dynamique

Le cycle de vie des réservations :CréationModificationAnnulation

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 concernantDemande par une personne de sa suppresion du fichier clientModification des informations sur une personne


32

EV11

EV12EV13


33

UMLUnified Modeling LanguageEtape 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, OOSEGrands é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éesles principaux éléments généraux


34

Principaux éléments généraux (1)

Stéréotype= 1 Moyen de de classer les éléments de la modélisationFacilite l´élaboration de métamodèles

évolution générale dÚMLprise en compte de situation particulières à léntreprise

Sápplique principalement aux classesidentification dúne typologie de classe

PaquetageDécoupage logique du système correspondant à des espaces de nommage homogènesRelation de dépendance en trait pointillé

Client„acteur“


35

Note : Commentaire explicatif dún element UML

Contrainte :Note ayant une valeur sémantique particulière pour un élément de la modélisationS´écrit entre accolade { }

{ ceci est une contrainte }À líntérieur dúne note

Language OCL Object Contraint Language disponible en UML

Spécifique à léxpression de contraintes


Commentaire


36


Principales règles d´écriture des noms et des expressions

Nom :Simple : chaîne de caractèresComposé : 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


37

Les 9 Diagrammes UMLdescription dúne partie du système ou description du système dún point de vue particulier

Diagramme des cas dútilisation DCUDiagramme de classes description statique du systèmeDiagramme dóbjets DOBDiagramme état transition DETDiagramme dáctivité DACDiagramme de séquence DSEDiagramme de collaboration DCODiagramme de composants DCPDiagramme de déploiement DDP

UML décrit concept et formalisme des diagrammes mais ne propose pas de démarche de conception


38

Positionnement des 9 diagrammes

DCU

DSEDAC DCO

DOB

DETDCL

DCP

DDP

Description statique et dynamique du système

Description de l´architecture du système


39

Diagramme des cas dútilisation

Description des intéractions entre les acteurs et le systèmeMoyen de recueillir et décrire les besoins des acteursChaque cas décrit sous forme textuelleTravail dídentification des cas

Acteurs connusUtilisateur typeAppartiennent à une ou plusieurs classe suivant les rôles quíls tiennent prp système

ReprésentationActeurCas dútilisationIntéraction entre acteur et cas dútilisation

Nom du cas dútilisation


40

Diagramme des cas dútilisation

Relation entre cas dútilisationRelation dínclusion :

1 instance de A contient le comportement décrit dans B

Relation déxtension1 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útilisation du système de gestion des réservations


41

PERSONNE

Consulter infos le concernant

Demander à être supprimer

Modifier infos le concernant

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 ressource

GESTIONNAIRE

Consulter planning de R

Consulter historiqueD

Consulter historiqueR


42

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 ressource

Examen D en attente

Ctrl paiement R

Surtaxerpaiement R

Examiner R effectuées


43

Phase 4 : Documenter le

schéma conceptuel


44

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


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


46

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


47

Décision 2 - historiser les demandes

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 »

AttributsObjet


48

… … …… … …… … …025 18082003 1026 18082003 1027 19082003 2027 20082003 3028 20082003 2028 20082003 1029 21082003 2029 22082003 3… … …… … …

Table : HistoEtatDem

Instances del’objet

HistoEtatDem

NumDem

DateEtatDem

EtatDem

EtatDem:« satisfait » = 1« en attente » = 2« refusé » = 3



49

EtatDem:« satisfait » = 1« en attente » = 2« refusé » = 3


027 19082003 2027 20082003 3028 20082003 2028 20082003 1029 21082003 2029 22082003 3

Table : HistoEtatDem

• Demandes 027 et 029 annulées le lendemain de leur mise en attente

• Demande 028 satisfaite dans la journée


50


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


51

Décision 3 - historiser les réservations

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 »

AttributsObjet


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


53

Décision 4 : allouer les chambres aux réservations

Lorsqu’une réservation est effectuée, une chambre est réservée

AttributsObjet

Reservation (NumRes, NumHot, NumPers, NumDem)

ChambreReservee (NumRes, NumCha)

PrixChambre (NumCha, NumHot, TypeSai, Prix)

DispoChambre (NumCha, NumHot, DateDebDispo, DateFinDispo)


54


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)

Cas « réservations hôtelières »

Documents

Transcript of Cas « réservations hôtelières »