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

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

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

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

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

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

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

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

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

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 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

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

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

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)

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

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

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 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

Formes normales 1è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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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