Analyse (méthode Merise)

Transcription

1 Analyse (méthode Merise) Roland Mahiquès Introduction Origine 1977 : commande du Ministère de l Industrie à l Université d Aix-Marseille 1981 : diffusion et utilisation Caractéristiques générales Cohérence interne et avec l industrie Séparation des données et des traitements Description de l existant pour aller vers le futur Prise en compte du SI 1 Montpellier Analyse Page 2 Objectif Contenu du chapitre Conceptualiser le problème Construire les modèles Proposer une solution globale Donner aux développeurs les éléments de la mise en œuvre Description et mise en pratique d une démarche de conception d une application informatique répondant aux questions : Quoi faire? Pour qui et par qui? Comment et où? En combien de temps? À quel prix? Montpellier Analyse Page 3 Montpellier Analyse Page 4 Démarche Démarche Comprendre l'environnement Lister les données Déterminer les règles de gestion Construire les modèles de données Lister les traitements Construire les modèles de traitements Vérifier la cohérence de l'ensemble Général Informatique Communication Données Traitement Conception MCC MCD MCT Organisation MOC MOD MOT Logique MLC MLD MLT Physique MPC MPD MPT Montpellier Analyse Page 5 Montpellier Analyse Page 6 Analyse - Page 1 -

2 Chronologie 1 GDF MCC + DD 2' MOC 2 4' MCD 3 Validation MCC/MCD MCT 4 5 MOD Validation MCT 6 MOT Déterminer l'interaction avec l'environnement pour le problème à résoudre Concevoir les MCC et MOC Déterminer les domaines Spécifier les acteurs externes Lister les messages échangés entre eux Montpellier Analyse Page 7 Montpellier Analyse Page 8 Formalisme Les domaines Les acteurs externes Les messages Domaine Acteur message Acteur Demande de consommation Paiement Récupération de la monnaie Domaine Client Édition du Messages Commande servie Ticket fourni Monnaie rendue Montpellier Analyse Page 9 Montpellier Analyse Page 10 Détecter les flux internes entre les différents domaines ou sous-domaines Matrice des flux internes Déterminer les sous-domaines Lister les messages échangés entre eux Service Sous-domaine Demande de plateau Domaine Édition du Plateau servi Ticket fourni Messages Préparation du plateau Sous-domaine Montpellier Analyse Page 11 Montpellier Analyse Page 12 Analyse - Page 2 -

3 Le Modèle Organisationnel de Communication (MOC) Sites et lieux des postes de travail Chronologie des échanges Précision sur le personnel agissant Exemple : Qui vérifie le avant qu'il parte vers le client? Qui prépare la commande? Le dictionnaire des données (DD) Lister les données Tableau en 5 colonnes : 1 code : attribué par nous-même 2 désignation : signification du code 3 type : nature de la donnée 4 obtenu : saisi ou calculé 5 exemple : ou mode de calcul Éviter les synonymes et homonymes Éviter les polysémes Montpellier Analyse Page 13 Montpellier Analyse Page Les données et leurs dépendances Code Désignation Type Obtenu Exemple N table Numéro de la table Numérique Saisie 12 Qté Dictionnaire des données Quantité consommée d'une boisson N S 2 Conso Nom de la consomation Texte S Café PU Prix unitaire N (M) S 1,50 Montant Montant par conso N (M) C PU x Qté TVA Taux de TVA N (P) S 19,6% Montant TVA Montant de la TVA N (M) C TTC-(TTC/1,196) TTC Total TTC du N (M) C Somme des Montants Date Date d'emission du Date S (Automatisée) lundi 5 mai 2002 Heure Heure d'émission du Heure S (A) 11:05:38 N Numéro unique du N S (A) 45 Nom Nom du serveur T S Marcel Montpellier Numéro du serveur N Analyse S (A) 7 Page 15 Le dictionnaire des données (DD) Trouver les identifiants Les mettre en évidence Données = attributs ou rubriques Montpellier Analyse Page Les données et leurs dépendances Code Désignation Type Obtenu Exemple N table Numéro de la table Numérique Saisie 12 Qté Dictionnaire des données Quantité consommée d'une boisson N S 2 Conso Nom de la consomation Texte S Café PU Prix unitaire N (M) S 1,50 Montant Montant par conso N (M) C PU x Qté TVA Taux de TVA N (P) S 19,6% Montant TVA Montant de la TVA N (M) C TTC-(TTC/1,196) TTC Total TTC du N (M) C Somme des Montants Date Date d'emission du Date S (Automatisée) lundi 5 mai 2002 Heure Heure d'émission du Heure S (A) 11:05:38 N Numéro unique du N S (A) 45 Nom Nom du serveur T S Marcel Montpellier Numéro du serveur N Analyse S (A) 7 Page 17 Les règles de gestion Recenser les règles De gestion : Quoi? D'organisation : Où? Qui? Quand? Techniques : Comment? Montpellier Analyse Page 18 Analyse - Page 3 -

4 Pourquoi modéliser les données? Minimiser la saisie Maximiser les contrôles Assurer la cohérence du SI Obtenir des résultats corrects Vérifier que le SI correspond à la réalité observée Définition Représentation du SI en terme d'entités (concepts qui ont du sens dans l'entreprise) manipulés par l'utilisateur et d'associations qui les lient Complément de définition Ensemble des données mémorisables du domaine Montpellier Analyse Page 19 Montpellier Analyse Page 20 Détecter les objets à utiliser et leurs attributs Les Entités Détecter les liens entre ces entités Les Associations Placer les attributs restants Dans les associations Dans des entités artificielles 2 types de construction construction déductive : on part des données du DD et on les structure. construction inductive : on met rapidement en évidence les objets (entités) auxquels on rattache les informations (attributs). Montpellier Analyse Page 21 Montpellier Analyse Page 22 Indiquer la "taille" des éléments Les occurrences Déterminer Les cardinalités Nombre mini et maxi qu'une occurrence d'une entité intervient dans une association Mini = {0, 1, n}, Maxi = {1,n} Type 1 à 1 (1,1) ou 0 à 1 (0,1) Type 1 à plusieurs (1,n) ou (0,n) Type plusieurs à plusieurs (n,n) Formalisme Les entités avec leurs occurrences Les associations avec leurs occurrences Les liens entre entités et associations 12 N, Nom 1,n Apporter Montpellier Analyse Page 23 Montpellier Analyse Page 24 Analyse - Page 4 -

5 Exemple 12 N, Nom apporter 1000 TICKETS N, date heure Passage du GDF au MCD Les objets deviennent des entités; Les DF entre objets deviennent des associations avec la cardinalité maxi 1 du côté du départ de la flèche; Les rubriques non en DF directe se placent dans une ou plusieurs associations de cardinalité maxi n de chaque côté. Montpellier Analyse Page 25 Montpellier Analyse Page 26 Règles de vérification du MCD Tous les attributs du DD sont dans le MCD Un attribut n'apparaît qu'une fois Toutes les entités ont un seul identifiant Toute association relie au moins 2 entités (sauf celles réflexives : d'une entité sur elle-même) Il existe au moins un chemin entre tous les attributs Normalisation du MCD différents stades de qualité. éviter les pertes de données, les incohérences, l'effondrement des performances. remplacer une entité par plusieurs. hiérarchie dans la normalisation : une relation en 5 ème FN est forcément en 4 ème FN, et ainsi de suite. Montpellier Analyse Page 27 Montpellier Analyse Page 28 Normalisation du MCD 1FN = Pas d'attribut multivalué EMPLOYÉS matricule nom prénom EMPLOYÉS matricule nom, prénom prénoms-enfants Avoir ENFANTS N nom prénom Montpellier Analyse Page 29 Normalisation du MCD 2FN = 1FN + tout attribut dépend de l'identifiant LIVRES code titre LIVRES code, titre nom-éditeur adresse Avoir ÉDITEURS N éditeur nom-éditeur adresse Montpellier Analyse Page 30 Analyse - Page 5 -

6 Normalisation du MCD 3FN = 2FN + tout attribut dépend directement de l'identifiant EMPLOYÉS matricule nom prénom EMPLOYÉS matricule nom, prénom nom_projet début, fin w PROJETS N projet nom_projet début, fin Montpellier Analyse Page 31 Passer de l'abstrait au concret Dans la théorie générale des Bases de Données, présenté en algèbre relationnelle et appelé MRD : Modèle Relationnel des Données MOD = MRD C'est la même chose, seul le formalisme change : graphique (MOD) ou algébrique (MRD) Montpellier Analyse Page 32 Le MOD est une transformation du MCD Entité Table Association Table Attribut Champ Cardinalité Type de relation On ne s'intéresse qu'aux Maxi a,1 de chaque côté CIF a,1 d'un côté et a,n de l'autre "1 à plusieurs" a,n d'un côté et a,n de l'autre "plusieurs à plusieurs" Montpellier Analyse Page 33 Fondé sur les théories relationnelles La liaison s'exprime à travers les champs des tables Clés externes (ou étrangères) Doit permettre d'interroger les données Requêtes (SQL) Montpellier Analyse Page 34 Transformation du MCD en MOD 1 - Une entité devient une table avec comme champ les attributs de l'entité (y compris l'identifiant) 20 nom => nom Transformation du MCD en MOD TICKETS Une association de type "plusieurs à N plusieurs" 1,ndevient Porter une table avec 0,n comme Conso date, champ heure les attributs Qté, montant qu'elle comportait PU Montant TVA, TTC éventuellement ET les identifiants des entités que l'association relie, appelés clés externes => CONSOMMATIONS TICKETS PORTER CONSOMMATIONS N Qté, montant Conso date, heure N PU Montant TVA, TTC Conso Montpellier Analyse Page 35 Montpellier Analyse Page 36 Analyse - Page 6 -

7 20 Transformation du MCD en MOD 3 nom - Une association de type "1 à nom plusieurs" se transforme 1,n en une (ou des) clé(s) externe(s) dans l'entité du côté "1" Apporter => correspondant à (aux) identifiant(s) du 1, côté "n", ET avec comme champs TICKETS supplémentaires les attributs propres TICKETS à l'association si elle en comportait. N date, heure Montant TVA, TTC N date, heure Montant TVA, TTC Montpellier Analyse Page 37 Transformation du MCD en MOD 4 Simplification : les entités ayant l identifiant comme seul attribut peuvent être ignorées Montpellier Analyse Page 38 Formalisme graphique (MOD) N, Nom TICKETS N, date heure n serveur Formalisme algébrique (MRD) (N, nom) TICKETS(N, date, heure, n serveur) Montpellier Analyse Page 39 Objectif Mettre en évidence l'activité de l'entreprise en utilisant un langage formel et identifier : Des acteurs Des évènements Des états Des synchronisations Des processus Des opérations Des résultats Montpellier Analyse Page 40 Traitement = description d'un processus Déclenché dans le domaine En réponse à l'environnement (par qui ou quoi) Décrit les actions sur le SI avec leur déclenchement faisant vivre les données C'est une description dynamique On répond à la question "Quoi?" (quelles actions fait l'entreprise) On ne répond pas aux questions "Où", "Quand", Comment" Montpellier Analyse Page 41 Montpellier Analyse Page 42 Analyse - Page 7 -

8 Eléments utilisés L'acteur les acteurs externes et internes au domaine L'événement Flux reçus (message) Flux émis (résultat) Acteur Ticket de caisse L'état Dépend d'une situation préalable du SI exemple : un dossier doit être ouvert avant d'instruire un sinistre Le traitement peut produire des changements d'état après le règlement du sinistre le dossier est clos ARTICLE Disponible Montpellier Analyse Page 43 Montpellier Analyse Page 44 La synchronisation Condition préalable au démarrage de l'opération. opération logique : ET; OU; NON, >, < =,... Le processus Ensemble structuré d'opérations et résultats consécutifs qui concourent à un même but ET Nom du processus Opération 1 Opération 2 Condition 1 Condition 2 L'opération Action s'enchaînant au cours d'un processus avec les seules informations du MCD amenées par l'événement déclenchant et VENTE DIRECTE AU COMPTANT Enregistrer la commande Facturer Enregistrer le règlement Remettre les articles Articles en stock Dernier article vendu Montpellier Analyse Page 45 Montpellier Analyse Page 46 CLIENT Etablissement ouvert ET COMMANDE Enregistrer la commande Etablir le Préparer les consommations Servir Ticket CLIENT Commande servie Commande encaissée Montpellier Analyse Page 47 Validation du MCT Par présentation aux partenaires Par vérification par simulation En Respectant les règles suivantes : 1 acteur émet au moins 1 événement ou reçoit au moins un résultat (il sert à quelque chose!) 1 événement externe provient d'au moins 1 acteur un résultat provient d'au moins 1 opération Montpellier Analyse Page 48 Analyse - Page 8 -

9 Validation du MCT En respectant les règles suivantes : Tout résultat a au moins une destination Une opération est déclenchée par un événement, un état ou une synchronisation unique Une synchronisation lie au moins 2 événements ou états par une expression logique Une expression logique associée à une synchronisation a au moins un résultat vrai Validation du MCT En respectant les règles suivantes : Un fonctionnement cyclique doit pouvoir être contrôlé Tout résultat ou état du MCT doit pouvoir être produit Les situations de conflit doivent être analysées Montpellier Analyse Page 49 Montpellier Analyse Page 50 Remarques : Le MCT ne vit que par ces échanges avec l'environnement Les événements externe ne naissent pas spontanément Les résultats produits sont utilisés...ou inutiles! des traitements (MOT) Il permet de préciser : La chronologie des traitements Les postes de travail concernés Le personnel concerné Le temps correspondant Montpellier Analyse Page 51 Montpellier Analyse Page 52 Analyse (méthode Merise) Fin du chapitre 53 Analyse - Page 9 -