View
23
Download
0
Category
Preview:
DESCRIPTION
Cas « réservations hôtelières ». Partie 2 SYSTEMES D’INFORATION. AUBE FLEURY Laetitia …. 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 - PowerPoint PPT Presentation
Citation preview
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….
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
HOTEL REGIONAppartient à1,1 0,N
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)
Le modèle entité / association du cas étudié
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
7
Formes normalesDé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
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)
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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)
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
12
Le modèle relationnelLa notion de « clé » dans une
table
Hotel (IdHotel, Nom, Adresse)
HOTELIdHotelNom
Adresse
Table
Attributs
Clé
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 REGIONAppartient à1,1 0,N
HOTELIdHotelNom
AdresseIdRegion
REGIONIdRegion
Nom
On construit une table par entité
Hotel (IdHotel, Nom, Adresse, IDRegion) Region (IdRegion, Nom)
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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
HOTEL REGIONAppartient à1,2 0,N
On construit une table par entité et une table par association
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 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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
19
Formes normales2ème forme normale
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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
20
Formes normales3ème forme normale
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é
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
21
Formes normales3ème forme normale
Exemple de table « ratée »
Solution possible
ARTICLEIdArticlePrixHTPrixTTC
Ces deux Attributssont interdépendants
mais aucun n’appartient à la clé
ARTICLEIdArticlePrixHT
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è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.
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
24
QUESTION 17Concernant 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 » 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
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
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 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
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é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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
32
EV11
EV12EV13
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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
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élisationFacilite l´élaboration de métamodèles
évolution générale d´UMLprise en compte de situation particulières à l´entreprise
S´applique principalement aux classesidentification d´une typologie de classe
PaquetageDécoupage logique du système correspondant à des espaces de nommage homogènesRelation de dépendance en trait pointillé
Client„acteur“
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
35
Note : Commentaire explicatif d´un 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´intérieur d´une note
Language OCL Object Contraint Language disponible en UML
Spécifique à l´expression de contraintes
Principaux éléments généraux (2)
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è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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
37
Les 9 Diagrammes UMLdescription d´une partie du système ou description du système d´un point de vue particulier
Diagramme des cas d´utilisation DCUDiagramme de classes description statique du systèmeDiagramme d´objets DOBDiagramme état transition DETDiagramme d´activité 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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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
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èmeMoyen de recueillir et décrire les besoins des acteursChaque cas décrit sous forme textuelleTravail d´identification des cas
Acteurs connusUtilisateur typeAppartiennent à une ou plusieurs classe suivant les rôles qu´ils tiennent prp système
ReprésentationActeurCas d´utilisationInté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´utilisationRelation d´inclusion :
1 instance de A contient le comportement décrit dans B
Relation d´extension1 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
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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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
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
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
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
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
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
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
Décision 2 - historiser les demandes
IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004
49
EtatDem:« satisfait » = 1« en attente » = 2« refusé » = 3
Décision 2 - historiser les demandes
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
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
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
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
AttributsObjet
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)
Recommended