La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 20041 Cas « réservations hôtelières » Partie 2 SYSTEMES DINFORATION AUBE FLEURY Laetitia …."— Transcription de la présentation:

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

2 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Phase 1 : Identification des événements

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

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

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

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

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

9 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 dattributs (= rubriques) Chaque table contiendra des enregistrements (= données) HOTEL IdHotel Nom Adresse IdRegion REGION IdRegion Nom Hotel (IdHotel, Nom, Adresse, IDRegion) Region (IdRegion, Nom)

10 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Le modèle relationnel tables et enregistrements La table (= le moule) Hotel (IdHotel, Nom, Adresse) Une table est composée dattributs, 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

11 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Le modèle relationnel La notion de « clé » dans une table Chaque table a besoin dun identifiant qui définit chaque enregistrement de façon parfaite et unique : cest la clé La ou les clés dune 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 lhô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 lunicité soit certaine

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

13 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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,10,N HOTEL IdHotel Nom Adresse IdRegion REGION IdRegion Nom On construit une table par entité Hotel (IdHotel, Nom, Adresse, IDRegion) Region (IdRegion, Nom)

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

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

16 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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

17 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 REGION IdRegion Nom HOT_REG IdHotel IdRegion

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

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

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

21 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 nappartient à la clé ARTICLE IdArticle PrixHT TauxTVA

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

23 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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.

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

25 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 lobjet 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

26 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Synchronisation de l´événement EV3 La transition de EV3 « le système constate une nouvelle dispo » A comme EV1 lissue : 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 quune seule demande alors quEV3 doit passer toutes les demandes en attente

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

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

29 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 dune station (OP14) La création dun hôtel (OP16) La mise à jour des tarifs dune chambre PHS, PBS Objet Type PRIXCHAMBRE (OP18) La m à j des périodes de disponibilité dune chambre sur lObjet Type DISPOCHAMBRE (OP17) La m à j des saisons dune station Objet Type TYPESAISON (OP15) Rq : Les mises à jour sont parfois des créations

30 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Synchronisation de l´événement EV7 Condition de déclenchement : OP14 : création stations OP15 : création saison dune 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 d1 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 dhôtels. OP15 : déclare type saison dune 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

31 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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

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

33 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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

34 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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

35 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 Principaux éléments généraux (2) Commentaire

36 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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

37 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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

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

39 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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

40 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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

41 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 Surtaxer paiement R Examiner R effectuées

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

44 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Type de documentation Afin daider 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 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 ladéquation des ressources existantes aux demandes Choix alternatifs : ne stocker que les demandes « en attente » ne stocker que les réservations

47 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 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 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Table : HistoEtatDem Instances de lobjet HistoEtatDem NumDem DateEtatDem EtatDem EtatDem: « satisfait » = 1 « en attente » = 2 « refusé » = 3 Décision 2 - historiser les demandes

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

50 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Documentation du processus Décision 2 : historiser les demandes Justification : permet danalyser 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 lobjet DEMANDE

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

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

53 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Décision 4 : allouer les chambres aux réservations Lorsquune 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 IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier Documentation du processus Décision 4 : allouer les chambres aux réservations Justification : permet dallouer 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 lhôtel, létat (réservé ou non)


Télécharger ppt "IAE PARIS - DESS CAAE MBA Systèmes d'information -Janvier 20041 Cas « réservations hôtelières » Partie 2 SYSTEMES DINFORATION AUBE FLEURY Laetitia …."

Présentations similaires


Annonces Google