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

SYSTÈME D’INFORMATION DE GESTION

Présentations similaires


Présentation au sujet: "SYSTÈME D’INFORMATION DE GESTION"— Transcription de la présentation:

1 SYSTÈME D’INFORMATION DE GESTION
Modélisation par Merise 02/10/2012 Yrelay - Système d’Information de Gestion Modélisation Merise

2 III-1 L’histoire de Merise
La naissance de Merise Années 60 : informatisation de l’administration française : contexte qui fait naître Merise Merise : c’est la fusion des bonnes idées du moment Le nom de Merise vient de « Merisier » qui est utilisé comme « porte-greffe ». Une progression sur trois cycles Cycle de vie = Démarche du projet : différentes phases de l’existence du système Cycle d’abstraction = raisonnement du projet : on passe du modèle à sa concrétisation Cycle de décision = maîtrise du projet : discussion des aspects connexes comme les coûts financiers 02/10/2012

3 III-2 Cycle de décision Les décisions stratégiques
Ce cycle concerne les choix connexes au projet : - choix budgétaires, - choix en termes d’organisation, - choix stratégiques. Les décisions stratégiques Préparer la mise en place du système et son évolution sur 2 à 5 ans Rédaction du Schéma Directeur Informatique La décisions organisationnelles Chaque domaine est découpé en projet et pour chaque projet on retient des solutions aux questions : Choix de l’organisation : qui fait quoi ? Définition et disposition des postes de travail Coûts des différentes solutions Rédaction du dossier de choix La décisions opérationnelles Pour chaque projet : une étude détaillée est réalisée. Rédaction de 2 documents : Dossier de spécification fonctionnelle générale pour les utilisateurs : cahier des charges Dossier de spécification fonctionnelle détaillée pour les programmateurs Synthèse Des décisions doivent être prises à différents moments, tout au long du cycle de vie. 02/10/2012

4 III-3 Cycle d’abstraction
Ce cycle correspond au passage de l’idée vers sa concrétisation. SIO : Système d’Information Organisationnel vue sous l’angle utilisateur Le niveau conceptuel : Quoi et Comment ? Quelles sont les fonctions réalisées par le système ? Comment fait le système ? Le niveau organisationnel : Qui, Quand et Ou ? On répond aux questions laissées en suspens dans le niveau précédent. On reste encore abstrait sans se préoccuper des questions purement informatiques. SII : Système d’Information Informatisé vue sous l’œil informaticien Le niveau logique : Avec quels moyens logiciels ? On détermine la forme de l’outil informatique : Quels écrans vont se succéder : aspect ergonomique, Quelles actions doivent être accomplies par les logiciels ? Quels messages doivent être échangés sur les réseaux ? Quelles tables doivent être construites pour stocker les informations ? Le niveau physique : Implantation proprement dite du système 02/10/2012

5 III-4 Cycle de vie Conception Réalisation Maintenance
Ce sont les différentes phases par lequel doit passer un projet informatique. Conception Analyse de l’existant et des besoins Etude des solutions d’organisation et techniques à mettre en place Etude détaillée pour obtenir le dossier de spécification fonctionnelle générale : cahier des charges Réalisation Etude technique : dossier de spécification fonctionnelle détaillée Production des éléments logiciels et mise en service : codage, tests, etc… Maintenance Maintenance préventive : modifier le programme pour éviter des problèmes de fonctionnement Maintenance corrective : correction des erreurs de programmation Maintenance préventive : adapter le logiciel aux évolutions de l’entreprise 02/10/2012

6 III-5 Les 3 aspects complémentaires du projet
La méthode Merise dans sa version 2 propose de voir le projet sous 3 aspects qui se complètent : Les communications Echanges d’informations entre les éléments du système : aspect dynamique inter-éléments Les données On se focalise sur les informations échangées ou stockées Les traitements Ce sont les opérations effectuées en réponse à des stimuli 02/10/2012

7 Modélisation Merise Le niveau Conceptuel 02/10/2012

8 III-6 Modèle Conceptuel des Communications MCC
Les intervenants (ellipses) Déterminer les « limites » du système Intervenants externes à l’entreprise appelés « partenaires » : ellipses trait pointillé avec un NOM Intervenants internes à l’entreprise appelés « domaines » : ellipses trait continu avec un VERBE Le domaine peut contenir des « sous-domaines » : ellipses avec un verbe plus détaillé Les « canaux » entre les intervenants Les messages (écrit à côté des flèches) Les flux d’information sont de différents types : ordres, description de matériaux, flux monétaires etc. Le message est représenté par « une flèche » depuis l’émetteur vers le récepteur Le nom du message est placé à côté de la flèche en majuscule La description du contenu du message est en minuscule Les messages et le support physique Un même support physique peut correspondre à différents messages conceptuels selon les destinataires Le document physique est indiqué en majuscule : BON DE COMMANDE Le message conceptuel associé est indiqué en minuscule entre parenthèses : BON DE COMMANDE (pièce comptable pour le journal des achats) BON DE COMMANDE (ordre d’achat pour le fournisseur) Deux types de message Message enclencheur : doit susciter une réaction et/ou une réponse de la part du récepteur Message informant : ne suscite pas obligatoirement une réaction et/ou une réponse 02/10/2012

9 III-7 Cas pratique MCC : Association sportive
I- Les composantes statiques du système Limites : limites juridiques de l’association sportive Partenaires : Futurs adhérents La Fédération Domaines : la Gestion des adhésions (éventuellement la Réalisation des séances d’entraînement) Canaux : 1- Futurs adhérents et Gestion des adhésions 2- Fédération et Gestion des adhésions 3- Eventuellement : Futurs adhérents et Réalisation des séances d’entraînement II- Les messages véhiculés à l’intérieur des canaux 1- Entre les Futurs adhérents (F) et Gestion des adhésions (G) : Message 1 : fiches adhésions vierges de G vers F Message 2 : fiches adhésions remplies, certificats médicaux, chèques de F vers G Message 3 : licences temporaires de G vers F Message 6 : licences définitives de G vers F 02/10/2012 9 9

10 III-7 Cas pratique MCC : Association sportive
2- Entre la Fédération (Fed) et Gestion des adhésions (G) : Message 4 : liste des adhérents à jour et chèques de G vers Fed Message 5 : licences définitives de Fed vers G 3- Entre les futurs adhérents (F) et la réalisation des séances (R) : Message 7 : séances d’entraînement de R vers F 02/10/2012 10 10

11 III-7 Cas pratique MCC Un atelier de menuiserie est composé de :
- un gérant : qui gère les achats, la facturation et la comptabilité en générale - un commercial qui démarche et livre Les produits finis - deux menuisiers qui réceptionnent les matières premières et produisent les éléments. Gérant-Fournisseur : « Appel d’offre » et « Bon de commande » Fournisseur-Gérant : « Proposition » et « Facture fournisseur » (en passant par le domaine achat) Commercial-Gérant : « Compte rendu de l’action commerciale » et « Contrat signé » Gérant-Commercial : « Ordre d’action commerciale » et « Ordre de livraison » et « Facture client » Gérant-Gérant : « Ordre d’achat » entre les sous-domaines Administration et Achat Menuisiers-Gérant : « Compte rendu du travail réalisé » Gérant-Menuisiers : « Ordre de production » Menuisiers-Commercial : « Produits à livrer » Fournisseurs-Menuisiers : « Matières premières » Commercial-Client : « Catalogue » et « Contrat vierge » et « Factures client » et « Produit livré » Client-Commercial : « Contrat signé » 02/10/2012

12 MCC 02/10/2012

13 III-8 Modèle Conceptuel des Traitements MCT
Les messages : évènements ou résultats (ellipses) Le message : « feuille d’achats » est le résultat d’une opération conceptuelle : « écrire le feuille d’achats » « feuille d’achats » est aussi l’évènement déclenchant une opération conceptuelle : « faire appel d’offres » L’opération conceptuelle (rectangle) Elle spécifie le travail effectué par l’intervenant pour traiter un évènement ou produire un résultat Seuls les traitements internes à l’entreprise sont étudiés Titre du rectangle : VERBE décrivant l’opération En dessous du rectangle : listes des actions Synchronisation des évènements (trapèze) Est-ce que les 2 évènements doivent arriver en même temps ? Ou un seul suffit à déclencher l’opération conceptuelle ? A ET B : A et B sont obligatoires A OU B : A ou B suffit A OUEX B : si A OK ; B ne doit pas être et inversement NON A : déclenchement si A ne survient pas ((A OU B) ET (C OU D)) OUEX E : R1 = A OU B R2 = C ou D R3 = R1 ET R2 Résultat final : R3 OUEX E 02/10/2012

14 III-8 Modèle Conceptuel des Traitements MCT
Production conditionnelle des résultats (sous-parties du rectangle) L’opération conceptuelle peut produire plusieurs résultats sous certaines conditions. Les conditions sont écrites en bas du rectangle 02/10/2012

15 III-9 Cas pratique MCT : Association sportive
On fait un zoom sur le domaine : gestion des adhésions. I- Les étapes de la gestion des adhésions pour fournir les licences Accueillir le futur adhérent Recueillir les documents : fiches adhésions remplies, certificats médicaux, chèques Envoyer la liste des adhérents à jour avec leur chèque à la fédération Distribuer les licences renvoyées par la fédération II- Les actions à accomplir pour chaque opération conceptuelle Accueil du futur adhérent : Remettre une fiche d’adhésion vierge Compter le nombre de séances d’essai effectuées Refuser les adhérents qui ont fait leurs séances d’essai Recueil des documents : Vérifier la validité des documents Remettre une licence temporaire Envoi à la fédération : Préparer la liste des adhérents à jour de leurs obligations Etablir le chèque de l’association dont le montant = somme du prix de chaque licence Préparer et envoyer la lettre Refuser les inscriptions des adhérents hors délai Distribution des licences : Recevoir le colis Distribuer les licences aux adhérents concernés 02/10/2012 15 15

16 III-9 Cas pratique MCT : Association sportive
III- Les messages entrant et sortant pour chaque opération conceptuelle Accueillir le futur adhérent Entrée : arrivée d’un futur adhérent avec / sans ses documents Sortie : adhérent qui a amené ses documents ou non Recueil des documents : Entrée : adhérent qui a amené ses documents Sortie : licence temporaire pour l’adhérent et nom d’un adhérent à ajouter à la liste Envoi à la fédération : Entrée : le fait que l’on soit le 1 er Novembre et au moins 1 nom d’adhérent à jour Sortie : lettre à envoyer à la fédération de tutelle Distribution des licences : Entrée : le colis envoyé par la fédération Sortie : les licences distribuées aux adhérents IV- Les opérations de synchronisation entre les événements Entrée 1 : arrivée d’un nouvel adhérent OU Entrée 2 : arrivée d’un futur adhérent qui vient faire une séance d’essai Entrée 1 : le fait que l’on soit le 1 er Novembre ET Entrée 2 : au moins un nom d’adhérent à jour de ses obligations 02/10/2012 16 16

17 III-9 Cas pratique MCT : Association sportive
V- Les conditions de génération des messages Accueillir le futur adhérent Sortie 1 : le futur adhérent a apporté ses documents Sortie 2 : le futur adhérent n’a pas apporté ses documents et le nombre d’essais effectués est inférieur ou égal à 3 Sortie 3 : le futur adhérent n’a pas apporté ses documents et le nombre d’essais effectués est strictement supérieur à 3 VI- La construction du MCT Sur le MCT : on fait une « coupure » entre : - les actions générées par la gestion des adhésions, - les actions générées par le fédération 02/10/2012 17 17

18 III-9 Cas pratique MCT : Association sportive
VI- La construction du MCT 02/10/2012 18 18

19 III-9 Cas pratique MCT On analyse le texte en mettant en évidence les opérations conceptuelles : On analyse le texte en mettant en évidence les messages : 02/10/2012

20 02/10/2012

21 III-9 Cas pratique MCT On détermine les conditions de génération des messages On peut imaginer la condition suivante : « présence ou non du client à son domicile » : Le client est présent : le commercial lui remet le catalogue, Le client n’est pas présent : le commercial note qu’il doit reporter la visite au lendemain. On détermine les opérations de synchronisation Soit le message A : Nom du client à visiter Soit le message B : Visite reportée 02/10/2012

22 MCT 02/10/2012

23 III-10 Le dictionnaire de données et les DF
→ On étudie le contenu des messages eux-mêmes : on énumère les informations : - on épure cette liste pour créer le dictionnaire des données, - on détermine les lien sémantiques qui existent entre ces éléments pour construire la couverture minimale → Une information peut prendre différentes valeurs appelées : occurrences. Les occurrences de l’information « prénom » sont : « Julie », « Serge » etc… → On élimine les ambigüités de vocabulaire : * polysèmes : congé au service RH <> congé en technique de soudure * synonymes : un trou oblong se dit « boutonnière » ou « lumière » → On prend en compte les informations composées : * la feuille achat contient l’information « 4 profilés en T 40*40 en A 48 M » → On ne prend pas les informations calculées : on prend l’information de départ et la règle de calcul Les dépendances fonctionnelles : X _ Y : connaître l’info X donne l’info Y Transitivité : X_Y et Y_Z : X_Z Décomposition : X_Y : X_Y1 et X_Y2 Union : X_Y et X_Z : X_YunionZ Augmentation : X_Y : XunionZ_YunionZ Composition : A_B et C_D : AunionC_BunionD DFElémentaire : NumSécu donne Patronyme DFTotale : NumSécu+Projet donne date affectation DFDirecte : il n’existe pas Z tel que : Si X_Y : X_Z et Z_Y 02/10/2012

24 III-11 Couverture minimale
1- On part du tableau du dictionnaire des données 2- Recherche des DF simples SOURCES : on les coche d’un V Ex : NumSécu ; NumSiret, NumProjet, NumFacture, NumPièce 3- Pour chaque élément source : on détermine les CIBLES correspondantes : on les coche d’une X Ex :  NumSécu _ patronyme, prénom, age, fonction  NumSiret _ raisonsoc, contact, tel, type  NumpProjet _ datedebut, nom  NumFacture _ date, montant  NumPiece _ desc, prixachat 4- On repère les données NON COCHEES : on coche un « carré » : elles ont pour source une concaténation:  NumProjet, NumSécu _ datedebut, datefin 5- On recherche les DF entre les données sources elles mêmes en précisant la nature de l’occurrence : NumProjet _ NumSiret (client), NumSécu (Chef) NumFacture _ NumProjet (attention dans l’autre sens cela ne fonctionne pas) NumPièce _ NumSiret (fournisseur), NumProjet 6- On reprend les 5 sources et la 6ème (concaténation) et on rajoute les DF entre sources : NumSécu _ patronyme, prénom, age, fonction NumSiret _ raisonsoc, contact, tel, type NumpProjet _ datedebut, nom, NumSiret (client), NumSécu (Chef) NumFacture _ date, montant, NumProjet NumPiece _ desc, prixachat, NumSiret (fournisseur), NumProjet NumProjet, NumSécu _ datedebut, datefin 02/10/2012

25 III-12 Matrice des dépendances fonctionnelles
On part du tableau du dictionnaire des données 1- 1ère colonne : numéro de ligne (= nombre de données) 2- 2ème colonne : description de la donnée 3- 3ème colonne : numéro de la 1ère donnée source : NumSécu 4- 4ème colonne : numéro de la 2ème donnée source : NumSiret Attention : s’il y a concaténation de sources : elle devient une source elle-même et on rajoute une ligne On met une (*) dans une colonne et ligne de même numéro On met un (1) s’il y a DF 02/10/2012

26 III-13 Modèle Conceptuel des Données MCD
Les messages deviennent des entités (carré) Une entité : c’est un objet matériel ou immatériel, un concept : pièce, bon de commande etc. Chaque entité a un identifiant du dictionnaire des données : pièce à NumPiece : on le souligne Chaque entité a des propriétés : DescPièce et PrixAchat L’association faisant le lien entre les occurrences des entités (ellipse) Une association est décrite par un verbe Une association peut posséder des propriétés : date début, date fin : indiquées dans l’ellipse Une association peut faire intervenir plusieurs entités : N entités : association d’arité N Association réflexive : 1 entité, 1 association : 1 aller-retour : on indique le rôle sur les flèche : Entité = employé ; association = encadrer ; aller : chef ; retour : subordonné Association multiple : 2 entités, 2 associations : Entité = employé ; Entité = pièce ; Association = commander ; Rôle = Resp Achat Entité = employé ; Entité = pièce ; Association = utiliser ; Rôle = Resp Achat Les cardinalités Cardinalité : nombre d’occurrences d’une association On se place d’un côté de l’association : cette association peut-elle ne pas exister ? Si oui : cardinalité minimale = 0 Si non : cardinalité minimale = 1 On se place du même côté de l’association : peut-il y avoir plusieurs occurrences? Si oui : cardinalité maximale = N Si non : cardinalité maximale = 1 02/10/2012

27 III-13 Modèle Conceptuel des Données MCD
Les contraintes sur les associations (petit cercle entre 2 ellipses d’association) OU inclusif : les occurrences de l’entité doivent participer à au moins une des deux associations : V OU exclusif : les occurrences de l’entité participent à au plus une association et certaines peuvent ne participer à aucune association : X Partition : l’ensemble des occurrences de l’entité est partagé entre celles qui sont impliquées dans l’association 1 et celles qui sont impliquées dans l’association 2 : + Inclusion : l’ensemble des occurrence de l’entité qui participent à l’association 2 participe aussi à l’association 1 mais la réciproque n’est pas vraie : I pointé sur l’association englobante Exemple : Si une pièce est inscrite dans une facture : elle a été au préalable Inscrite dans un bon de commande. dans un bon de commande : elle a été d’abord inscrite dans une feuille des achats. 02/10/2012

28 III-13 Modèle Conceptuel des Données MCD
La contrainte d’intégrité fonctionnelle CIF (flèches) La connaissance d’une occurrence d’une entité peut permettre de réduire l’occurrence d’une autre entité. Ce lien sémantique forme une « contrainte d’intégrité fonctionnelle » : CIF. Association binaire 1-N : il y a CIF car connaître l’occurrence de l’entité de cardinalité maximale 1 permet de déduire l’occurrence de l’autre entité. Association n-aire N-N : la connaissance des occurrences de certaines entités permet de déduire les occurrences des autres entités. Représentation : on remplace les traits par des flèches. 02/10/2012

29 III-13 Modèle Conceptuel des Données MCD
La contrainte d’intégrité multiple La connaissance des occurrences d’une ou plusieurs entités sources permet de déduire une ensemble d’occurrences d’une ou plusieurs entités cibles. C’est une généralisation de la CIF. Le lien d’héritage (triangle vers l’entité de base) A partir d’une entité de base : on fait dériver une entité plus spécialisée qui comporte ses propres attributs mais également les attributs de l’entité de base. Une entité dérivée utilise l’identifiant de l’entité de base. Exemple : L’entité TOLE(infos spécifiques à une tôle) et l’entité BARRE_FER(infos spécifiques à une barre de fer) héritent de l’entité PIECE(pièce métallique en général). Entité forte et entité faible Une entité faible ne peut être considérée qu’en association avec une entité forte. Une occurrence d’une entité faible n’est identifiée que par rapport à une occurrence d’une entité forte. Exemple : la « pièce » est considérée en association avec le projet dans lequel elle est utilisée car tout est centralisé autour de ce dernier. 02/10/2012

30 III-14 Construire un MCD à partir de la couverture minimale
Détermination des entités L’identifiant = information source de la DF Les propriétés = informations cibles La couverture minimale ne permet pas de déduire le nom de l’entité ; le choix est au concepteur du SI Exemple : la DF : NumSiret_Raissociale, contact, tel, typeEnt correspond à l’entité ENTREPRISE Détermination des associations On repart des étapes 4 et 5 de la couverture minimale : 4- On repère les données non cochées : on coche un « carré » : elles ont pour source une concaténation :  NumProjet, NumSécu _ datedebut, datefin 5- On recherche les DF entre les données sources elles mêmes en précisant la nature de l’occurrence : NumProjet _ NumSiret (client), NumSécu (Chef) NumFacture _ NumProjet (attention dans l’autre sens cela ne fonctionne pas) NumPièce _ NumSiret (fournisseur), NumProjet Plusieurs cas de figure se présentent. 02/10/2012

31 III-14 Construire un MCD à partir de la couverture minimale
1er cas : 2 sources forment une DF : source_cible ; asso 1-N entre deux entités Exemple : NumPiece _ DescPiece, PrixAchatPiece NumProjet _ DateDebutProjet, NomProjet NumPiece _ NumProjet Si on connaît la valeur de NumPiece : on en déduit la valeur de NumProjet. La pièce est liée à un seul projet. La cardinalité maximale 1 est du côté de Piece, et la cardinalité maximale N est du côté Projet. La DF ne permet pas de trouver le nom de l’association : choix du concepteur. La DF ne permet pas de déduire les cardinalités minimales : choix du concepteur. Dans notre exemple : la cardinalité minimale de PIECE est « 0 » : la DF est faible. 02/10/2012

32 III-14 Construire un MCD à partir de la couverture minimale
2ème cas : les cibles ne sont pas des sources, asso N-N entre deux entités Exemple : NumProjet _ DateDebutProjet, NomProjet NumSecuEmp _ PatronymeEmp, PrenomEmp, AgeEmp, FonctionEmp NumSecuEmp, NumProjet _ DatedebutAffect, DateFinAffect 02/10/2012

33 III-14 Construire un MCD à partir de la couverture minimale
3ème cas : des cibles peuvent être des sources, asso N-N qui comporte une CIF Exemple : NumProjet _ DateDebutProjet, NomProjet NumSecuEmp _ PatronymeEmp, PrenomEmp, AgeEmp, FonctionEmp NumFeuilleAchats _ DateFeuilleAchats NumProjet(préparateur), NumSecuEmp _ NumFeuilleAchats Les 3 premières DF déterminent les entités PROJET, EMPLOYE, FEUILLE_ACHATS Comme NumFeuilleAchats est cible : cette entité est la cible de la CIF 02/10/2012

34 III-14 Construire un MCD à partir de la couverture minimale
4ème cas : certaines sources ne sont pas sources dans d’autres DF, asso N-N qui comporte une CIF Exemple : On reprend l’exemple précédent : on considère maintenant que DateFeuilleAchats comporte uniquement le jour et le mois ; l’année doit être stockée dans une autre information. NumProjet _ DateDebutProjet, NomProjet NumSecuEmp _ PatronymeEmp, PrenomEmp, AgeEmp, FonctionEmp NumFeuilleAchats _ DateFeuilleAchats NumProjet(préparateur), NumSecuEmp, année _ NumFeuilleAchats 02/10/2012

35 III-15 Cas pratique MCD On détermine les informations concernant :
- les constituants - les partenaires - les messages du MCC et MCT Pour chaque élément : choisir une mnémonique Construire la couverture minimale en 4 étapes : 1- Déterminer les éléments sources : leur connaissance permet de déterminer les autres éléments. 2- Ecrire les éléments cibles des dépendances fonctionnelles 3- Ecrire les DF ayant comme source des combinaisons d’éléments 4- Ecrire les DF entre les éléments sources On détermine les associations à partir des DF entre les éléments sources (cf n° 4) : La source de la DF correspond à l’entité qui porte la cardinalité maximale 1 La cible de la DF correspond à l’entité qui porte la cardinalité maximale N On rassemble toutes les entités sur un même schéma On complète : cardinalités minimales et noms des associations à partir des annexes 02/10/2012

36 III-15 Cas pratique MCD : Association sportive
I- Les éléments d’information manipulés au sein du SI II- La détermination des éléments sources * nom > prenom, dateNaiss, adresse, CodePost, ville, , telPort, telFixe, licence * nomGrade > themeGrade * poids > catPoids * nomMed > adresseMed, codePostMed, villeMed, telMed * ageFed > catAge 02/10/2012 36 36

37 III-15 Cas pratique MCD : Association sportive
III- Les associations existant entre les entités * ADHERENT « EST SUIVI PAR » MEDECIN : Côté adhérent : Cardinalités 1 ; 1 (médecin obligatoire et un seul) Côté médecin : Cardinalités 1 ; N (s’il est inscrit dans le fichier : il a au moins un patient à plusieurs) * ADHERENT « POSSEDE » GRADE : Côté adhérent : Cardinalités 0 ; 1 (l’adhérent peut ne jamais avoir été licencié dans un club) Côté grade : Cardinalités 0 ; N (un grade donné peut n’avoir aucun représentant) * ADHERENT « PESE » POIDS : Côté adhérent : Cardinalités 1 ; 1 Côté poids : Cardinalités 0 ; N * ADHERENT « EST AGE DE » AGE : Côté âge : Cardinalités 0 ; N 02/10/2012 37 37

38 III-15 Cas pratique MCD : Association sportive
02/10/2012 38 38

39 MCD 02/10/2012 39 39

40 Le niveau Organisationnel
Modélisation Merise Le niveau Organisationnel 02/10/2012

41 III-16 Modèle Organisationnel des Traitements MOT
Le MOT est établi à partir du MCT en répartissant les opérations conceptuelles entre les différents postes de travail. Le découpage en postes de travail Il s’agit de découper l’entreprise en unités d’organisation Ces postes de travail sont : les moyens humains et matériels, Le travail à effectuer Concernant les moyens humains : Une personne peut être affectée à un poste, Une personne occupe plusieurs postes, Un poste est occupé par plusieurs personnes. Concernant le travail à effectuer : Une opération est prise en charge par un seul poste de travail, Une opération est prise en charge par plusieurs postes de travail La notion d’opération organisée Les opérations conceptuelles du MCT sont réparties sur les postes et deviennent : « organisées ». Il n’existe pas nécessairement une correspondance entre une opération conceptuelle et un poste de travail d’où différents cas de figure : Une opération conceptuelle correspond à une opération organisée, Une opération conceptuelle peut être découpée en plusieurs opérations organisées, Plusieurs opérations conceptuelles peuvent être regroupées en une opération organisée 02/10/2012

42 III-16 Modèle Organisationnel des Traitements MOT
La représentation graphique La représentation graphique est telle que le temps s’écoule de haut vers le bas Le modèle est découpé en colonnes qui correspondent chacune à un poste de travail ou un partenaire Ensuite on place les différentes opérations organisées dans les bonnes colonnes Les opérations organisées sont représentées selon le même formalisme que celui utilisé pour les opérations conceptuelles Les opérations organisées peuvent être découpées en tâches de deux types : Les tâches hommes Les tâches machine S’il n’y a pas de message interne à un poste : les tâches organisées doivent être regroupées La modélisation d’une période de déclenchement Si une opération organisée se déclenche de façon périodique : on modélise par le « trapèze » avec le nom de la période indiqué à l’intérieur 02/10/2012

43 III-17 Modèle Organisationnel des Données MOD
Objectif du MOD Il s’agit de maîtriser les redondances d’informations entre les différents postes de travail, Dimensionner les moyens informatiques à mettre en place au niveau des différents postes Il s’agit de construire les « vues » du MCD Exemple : le responsable des stocks a juste besoin de voir la liste des éléments dans le stock sans se soucier des informations concernant la paie des employés qui elle, doit être accessible au gérant. Le choix de cette vue a des conséquences sur d’autres décisions : Aspect sécurité et restriction des accés, Choix des données qui sont laissées sur un serveur central de stockage et celles qui sont copiées vers un serveur local Choix des éléments informatiques à acheter en fonction de la quantité de données à gérer sur un poste 02/10/2012

44 III-18 Modèle Organisationnel des Communications MOC
Objectif du MOC Il existe des échanges d’informations entre les sites, ou sont stockées les données, et des sites où sont manipulées des données. Il est nécessaire de représenter ces différents sites et les communications qui peuvent exister entre ces sites afin de dimensionner des éléments comme les réseaux ou les systèmes de stockage. C’est l’objectif du MOC. La notion de site Pour une grande entreprise, un site peut être distant de plusieurs centaines de Km. Les communications entre sites doivent passer par un réseau d’un opérateur. Si l’entreprise dispose de différents bâtiments : la notion de site peut désigner ses bâtiments. Les communications s’appuient sur le réseau d’entreprise. S’il n’y a qu’un seul bâtiment : un site est un bureau. Les communications s’appuient sur un réseau local. Dans le cas de petites entreprises avec une seule pièce (ex Start Up) : les sites sont les ordinateurs. Enfin, les sites peuvent désigner différents programmes fonctionnant sur une même machine. Le stockage centralisé : un seul site pour stocker des données Les autres sites sont des sites de traitement qui accèdent, de façon concurrente, à ce site central pour : Lire des données (entrées des traitements), Ecrire des données (sorties des traitements) Avantage : gestion simplifiée car toutes les informations sont concentrées au même endroit Inconvénients : Nécessité d’un mécanisme d’exclusion mutuelle pour gérer les accès concurrents, Grand dimensionnement pour éviter le goulot d’étranglement (fermes de machine des moteurs de recherche), Si le site central tombe : tout est bloqué (on fait une copie automatique sur un site secondaire). 02/10/2012

45 III-18 Modèle Organisationnel des Communications MOC
La gestion de stockage centralisée avec des caches On copie des vues sur des sites locaux de stockage des données qui peuvent être confondus avec des sites de traitement afin d’alléger la charge du site central. Deux façons de fonctionner : Le site de traitement consulte d’abord le site de stockage local (appelé « cache »). S’il ne trouve pas l’information : il accède au site central en dernier recours. S’il ne trouve pas l’information : c’est le site de stockage local qui consulte le site de stockage central et qui redonne l’information au site de traitement. Le site de stockage local joue le rôle d’intermédiaire. Avantages : l’utilisation des caches évite le goulot d’étranglement. Inconvénients : nécessité d’un mécanisme de cohérence des copies et d’un mécanisme d’exclusion mutuelle. Il est possible de mettre plusieurs sites locaux de stockage en cascade : plusieurs niveaux de cache. La gestion décentralisée Le site central de stockage est remplacé par plusieurs sites de stockage répartis sur le réseau. Les sites sont à la fois « utilisateurs d’informations » et « dépositaires d’informations » : « Peer to Peer ». Nécessité d’un annuaire qui conserve les lieux de stockage. Mise ne place d’un mécanisme de cohérence des copies. 02/10/2012

46 Modélisation Merise Le niveau Logique 02/10/2012

47 III-19 Modèle Logique des Données MLD
La notion de relation Une relation est le lien entre des informations pour former une information plus complexe. Ex : PIECE (numPiece, descPiece, prixAchatPiece) La notion de table La relation PIECE est un ensemble d’occurrences que l’on met dans une table : Chaque colonne correspond à un attribut de la relation, Chaque ligne correspond à une occurrence de la relation, Chaque case correspond à une valeur de l’attribut pour une occurrence donnée de la relation. Une table est un ensemble d’enregistrements ou « tuples ». Les attributs sont aussi appelés « champs ». La notion de clés Pour distinguer les enregistrements, on utilise des clés : c’est-à-dire des attributs qui ont une valeur unique pour chaque tuple et qui permettent de les distinguer les uns des autres. Clé candidate : attributs pouvant être utilisés comme clés Clé primaire : attribut choisi comme clé : il est souligné. Clé étrangère : une clé étrangère dans la relation R1 ne sert pas à identifier les enregistrements R1 mais est utilisée comme clé principale dans une relation R2. On met un # devant l’attribut. Ex : PIECE (numPiece, descPiece, prixAchatPiece, # numProjet) PROJET(numProjet, dateDebutProjet, nomProjet) 02/10/2012

48 III-19 Modèle Logique des Données MLD
Les règles de passage du MCD vers MLD Une entité se transforme en relation : La transformation d’une association 1 _ 1 Soient deux entités : ENTITE1 et ENTITE2, liées par une association ASSOCIE type 1_1. Ces trois éléments sont fusionnés : seul l’attribut6 a été choisi comme clé principale. 02/10/2012

49 III-19 Modèle Logique des Données MLD
La transformation d’une association 1 _ N Soient deux entités : ENTITE1 et ENTITE2, liées par une association ASSOCIE type 1, N. Pour transformer cette association : il faut utiliser 2 relations : 1ère relation : ENTITE1 regroupe ENTITE1 et ASSOCIE + clé étrangère = clé primaire ENTITE2 2ème relation : ENTITE2 02/10/2012 49 49

50 III-19 Modèle Logique des Données MLD
La transformation d’une association N _ N Construction de 2 relations correspondant aux 2 entités de départ Construction d’une 3ème relation comportant : 2 clés étrangères pointant sur les occurrences issues des 2 entités, Les éventuels attributs de l’association On peut ajouter un nouvel attribut de type numérique composé des 2 clés étrangères 02/10/2012 50 50

51 III-19 Modèle Logique des Données MLD
La transformation d’une association N _ N avec une CIF Même principe que précédemment mais la clé étrangère de l’entité CIF n’est pas soulignée. 02/10/2012 51 51

52 III-19 Modèle Logique des Données MLD
La transformation d’une association réflexive On ne s’occupe pas de l’association : on ne prend que l’entité On écrit une clé étrangère = clé primaire avec le nom du rôle de cardinalité N 02/10/2012 52 52

53 III-19 Modèle Logique des Données MLD
La transformation d’associations multiples Même principe que précédemment. 02/10/2012 53 53

54 III-19 Modèle Logique des Données MLD
La transformation d’un lien d’héritage On suppose 2 entités A et B qui héritent d’une entité C 1ère méthode : 3 relations A et B comportent une clé étrangère pointant sur C A(#attribut1, #attribut2, attribut4, attribut5) B(#attribut1, #attribut2, attribut6) C(attribut1, attribut2, attribut3) 2ème méthode : 2 relations A et B comportent chacune les attributs de C A(attribut1, attribut2, attribut3, attribut4, attribut5) B(attribut1, attribut2, attribut3, attribut6) 3ème méthode : 1 relation Une seule relation correspondant à l’entité C dans laquelle on ajoute les attributs de A et B C(attribut1, attribut2, attribut3, attribut4, attribut5, attribut6) 02/10/2012 54 54

55 III-20 La normalisation des relations
Intérêt de la normalisation Il s’agit d’appliquer de nouvelles règles de transformations pour diminuer les redondances. Il existe trois types d’anomalies de stockage : Insertion : si l’on souhaite stocker l’info : salaire d’un chaudronnier avec 3 ans d’ancienneté : il est nécessaire d’avoir cet employé ! Modification : si nous oublions de modifier le salaire d’un chaudronnier de 1 an d’ancienneté : La table devient incohérente ! Suppression : si nous supprimons l’unique enregistrement du chaudronnier de 2 ans d’ancienneté : nous perdons l’info sur le salaire à ce poste La hiérarchie des formes normales Les modifications nécessaires des relations ont été regroupées par niveau appelées : « formes normales ». Le respect d’une forme normale de niveau N implique le respect de la forme normale de niveau inférieur. 02/10/2012 55 55

56 III-20 La normalisation des relations
La première forme normale 1NF Une relation qui est de première forme normale doit posséder les propriétés suivantes : Les attributs de la relation sont mono-valués : exemple le prénom, Les valeurs sont atomiques : elles ne peuvent être décomposées en plusieurs sous-valeurs, Les valeurs sont constantes dans le temps La normalisation par stockage horizontal : La normalisation par stockage vertical : 02/10/2012 56 56

57 III-20 La normalisation des relations
La deuxième forme normale 2NF Une relation qui est de deuxième forme normale doit posséder les propriétés suivantes : La relation est de première forme normale, Il y a une dépendance fonctionnelle totale entre la clé composée et les attributs qui n’appartiennent pas à cette clé Soit la relation : COMMANDE (CodeFournisseur, refArticle, DescArticle, Qté) Il existe une dépendance fonctionnelle où la source est constituée par une partie de la clé : RefArticle _ article On obtient deux relations : COMMANDE (CodeFournisseur, #refArticle, Qté) ARTICLE (refArticle, DescArticle) 02/10/2012 57 57

58 III-20 La normalisation des relations
La troisième forme normale 3NF Une relation qui est de troisième forme normale doit posséder les propriétés suivantes : La relation est de deuxième forme normale, Il n’y a pas de DF entre des attributs qui n’appartiennent pas à la clé Soit la relation : COMMANDE (NumCommande, Codefournisseur, refArticle, DescArticle, Qté) Il existe une dépendance fonctionnelle entre RefArticle et DescArticle et ces deux attributs n’appartiennent pas à la clé On obtient deux relations : COMMANDE (NumCommande, Codefournisseur, #refArticle, Qté) ARTICLE (refArticle, DescArticle) 02/10/2012 58 58

59 III-20 La normalisation des relations
La forme normale de BOYCE CODD (BCNF) Une relation qui est de forme normale BCNF doit posséder les propriétés suivantes : La relation est de troisième forme normale, Les attributs, qui appartiennent à la clé, ne sont pas la cible d’une dépendance fonctionnelle d’attributs n’appartenant pas à la clé Soit la relation : LISTE_PIECE (piece, descPiece, qté, fournisseur) Si chaque fournisseur se spécialise dans un type de pièce, cela se traduit par une dépendance fonctionnelle de fournisseur vers pièce. On obtient deux relations : LISTE_PIECE (piece, descPiece, qté) FOURNISSEUR (fournisseur, #piece) 02/10/2012 59 59

60 III-20 La normalisation des relations
La quatrième forme normale 4NF Une relation qui est de quatrième forme normale doit posséder les propriétés suivantes : La relation est de forme normale BCNF, Il n’y a pas de dépendances multi-valuées Exemple : A partir d’un numéro de projet : on peut en déduire plusieurs salariés : On dit que numProjet multi détermine salarié : c’est une dépendance multi-valuées. Soit la relation : HABILITATION (nomSalarié, typeTravail, lieu) Il faut scinder en deux relations : HABILITATION_TYPE_TRAVAIL (nomSalarie, typeTravail) HABILITATION_LIEU (nomSalarie, lieu) 02/10/2012 60 60

61 III-21 Cas pratique MLD I- Partir du MCD (diapo 39) : écrire la relation correspondante pour chaque entité Exemple : EMPLOYE(numEmp, nomEmp, prenomEmp, adrEmp, cpEmp, villeEmp, telFixeEmp, telPortEmp, Emp, fctEmp) II- Pour chaque association cardinalités max 1-1 : fusionner les relations Il n’y a pas d’association 1_1 dans notre exemple. III- Transformer les associations de type cardinalités max 1-N On change la relation de cardinalité max 1 : on ajoute une clé étrangère = clé prim. de l’autre relation. IV- Transformer les associations de type cardinalités max N-N Ne concerne pas notre exemple. V- Modèle relationnel final 02/10/2012 61 61

62 III-21 Cas pratique MLD 02/10/2012 62 62

63 III-22 Modèle Logique des Traitements MLT
L’outil informatique Le MLT spécifie pour chaque opération organisée : Le ou les outils informatiques utilisés, La logique d’enchaînement des différents écrans Les outils transactionnels : interagissent avec l’utilisateur par le clavier, la souris, l’écran, l’imprimante Les outils en traitement différé : outils de traitement pas « batch » L’ergonomie des outils informatiques La mise au point d’une IHM : Interface Homme Machine joue un rôle important dans l’acceptation d’un outil Les masques : La sémantique utilisée, Les widgets : zones de saisies, étiquettes, boutons, listes La matrice « Etats-Transitions » Lorsqu’une fenêtre est affichée à l’écran : c’est un état du logiciel Les changements d’état constituent la dynamique du logiciel : on parle de transitions. La matrice « Etats- Transitions » représente la dynamique du logiciel sous forme de tableau : Etat de départ, Evènement déclenchant la transition Conditions à respecter pour effectuer cette transition Etat d’arrivée La représentation du MLT Les « nœuds » correspondent à des états Les flèches (arcs) correspondent à des transitions 02/10/2012 63 63

64 III-23 Modèle Logique des Communications MLC
Le MLC n’existe que s’il y a plusieurs sites. 02/10/2012 64 64


Télécharger ppt "SYSTÈME D’INFORMATION DE GESTION"

Présentations similaires


Annonces Google