html5-img
1 / 54

Cas « réservations hôtelières »

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

alexandria-anagnos
Download Presentation

Cas « réservations hôtelières »

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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é / associationsMCD (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é / associationsMCD (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 normales • Départ du schéma conceptuel IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

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

  9. HOTEL IdHotel Nom Adresse IdRegion REGION IdRegion Nom Hotel (IdHotel, Nom, Adresse, IDRegion) Region (IdRegion, Nom) 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) 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’) 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 relationnelLa 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 relationnelLa 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. 1,1 0,N HOTEL Appartient à REGION HOTEL IdHotel Nom Adresse IdRegion REGION IdRegion Nom 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 »  On construit une table par entité Region (IdRegion, Nom) IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004 Hotel (IdHotel, Nom, Adresse, IDRegion)

  14. 1,2 0,N HOTEL Appartient à REGION HOTEL IdHotel Nom Adresse HOT_REG IdHotel IdRegion REGION IdRegion Nom Region (IdRegion, Nom) Hotel (IdHotel, Nom, Adresse) Hot_Reg (IdHotel, IdRegion) Passage du modèle conceptuel au modèle relationnel • CAS n°2 : les deux cardinalités peuvent dépasser la valeur 1 • On construit une table par entité et une table par association 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’informationdans 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 multiples • Les 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}) HOTEL IdHotel Nom Adresse {IdRegion} REGION IdRegion 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) HOTEL IdHotel Nom Adresse HOT_REG IdHotel IdRegion REGION IdRegion Nom 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 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. HOTEL IdHotel Nom Adresse HOT_REG IdHotel IdRegion NomRegion HOT_REG IdHotel IdRegion NomRegion Cet Attribut ne dépend que de l’attribut IdRegion de la clé Formes normales2ème forme normale • Exemple de table « ratée » Seul la variation de IdRegion ferait varier NomRegion }Clé 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 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 normales3è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. 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. 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. EV11 EV13 EV12 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

  33. 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. Commentaire 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 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. 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. Description statique et dynamique du système Description de l´architecture du système DCU DCP DAC DSE DCO DOB DDP DCL DET Positionnement des 9 diagrammes 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. Consulter planning de R Faire D de R Consulter historiqueD Annuler R Consulter historiqueR Modifier R GESTIONNAIRE Annuler une D en attente Modifier infos le concernant Interrompre R Consulter infos le concernant PERSONNE Demander création nouvelle ressource Demander à être supprimer Modifier ressource HÔTELIER Supprimer ressource IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 2004

  42. Faire D de R Annuler R Ctrl paiement R Modifier R Annuler une D en attente Examen D en attente Surtaxer paiement R Interrompre R PERSONNE Demander création nouvelle ressource Modifier ressource HÔTELIER Supprimer ressource 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 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

More Related