Cours et exercices d’application pour comprendre la méthode Merise Pdf
Rappel :
MERISE est une méthode de conception, de développement et de réalisation de projets informatiques. Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode MERISE est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques.
La séparation des données et des traitements assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent remanié, tandis que les traitements le sont plus fréquemment.
La méthode MERISE date de 1978-1979, et fait suite à une consultation nationale lancée en 1977 par le ministère de l'Industrie dans le but de choisir des sociétés de conseil en informatique afin de définir une méthode de conception de systèmes d'information. Les deux principales sociétés ayant mis au point cette méthode sont le CTI (Centre Technique d'Informatique) chargé de gérer le projet, et le CETE (Centre d'Etudes Techniques de l'Equipement) implanté à Aix-en-Provence.
Cycle d'abstraction de conception des systèmes d'information
La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.
Cette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :
L'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :
...
MERISE - Modèle conceptuel de la communication
Définition de l'organisation
La première étape de ce modèle est d'arriver à isoler le système en le délimitant. Il s'agit donc de définir le système et les éléments externes avec lesquels il échange des flux d'information. Ces éléments extérieurs sont appelés acteurs externes (ou partenaires).
La seconde étape consiste à découper l'organisation en entités appelées acteurs internes (ou domaines). Lorsque les domaines d'une organisation sont trop importants, ils peuvent être décomposés eux-mêmes en sous-domaines.
La dernière étape est l'analyse des flux d'information, c'est-à-dire la définition des processus.
Diagramme de contexte
Le diagramme de contexte a pour but de représenter les flux d'informations entre l'organisation et les acteurs externes selon une représentation standard dans laquelle chaque objet porte un nom :
Diagramme conceptuel de flux
Ce diagramme (appelé aussi modèle conceptuel de la communication) permet de compléter le diagramme de contexte en décomposant l'organisation en une série d'acteurs internes. Dans ce diagramme la représentation standard est la suivante :
MERISE - Modèle conceptuel des données
Modèle conceptuel des données
Le modèle conceptuel des données (MCD) a pour but d'écrire de façon formelle les données qui seront utilisées par le système d'information. Il s'agit donc d'une représentation des données, facilement compréhensible, permettant de décrire le système d'information à l'aide d'entités.
Entités et classe d'entité
Une entité est la représentation d'un élément matériel ou immatériel ayant un rôle dans le système que l'on désire décrire.
On appelle classe d'entité un ensemble composé d'entités de même type, c'est-à-dire dont la définition est la même. Le classement des entités au sein d'une classe s'appelle classification (ou abstraction). Une entité est une instanciation de la classe. Chaque entité est composée de propriétés, données élémentaires permettant de la décrire.
Prenons par exemple une Ford Fiesta, une Renault Laguna et une Peugeot 306. Il s'agit de 3 entités faisant partie d'une classe d'entité que l'on pourrait appeler voiture. La Ford Fiesta est donc une instanciation de la classe voiture. Chaque entité peut posséder les propriétés couleur, année et modèle.
Les classes d'entités sont représentées par un rectangle. Ce rectangle est séparé en deux champs :
Relations et classes de relation
Une relation (appelée aussi parfois association) représente les liens sémantiques qui peuvent exister entre plusieurs entités. Une classe de relation contient donc toutes les relations de même type (qui relient donc des entités appartenant à des mêmes classes d'entité). Une classe de relation peut lier plus de deux classes d'entité. Voici les dénominations des classes de relation selon le nombre d'intervenants :
Les classes de relations sont représentées par des hexagones (parfois des ellipses) dont l'intitulé décrit le type de relation qui relie les classes d'entité (généralement un verbe). On définit pour chaque classe de relation un identificateur de la forme Ri permettant de désigner de façon unique la classe de relation à laquelle il est associé.
On peut éventuellement ajouter des propriétés aux classes de relation.
…
La cardinalité
Les cardinalités permettent de caractériser le lien qui existe entre une entité et la relation à laquelle elle est reliée. La cardinalité d'une relation est composée d'un couple comportant une borne maximale et une borne minimale, intervalle dans lequel la cardinalité d'une entité peut prendre sa valeur :
Une cardinalité 1.N signifie que chaque entité appartenant à une classe d'entité participe au moins une fois à la relation.
Une cardinalité 0.N signifie que chaque entité appartenant à une classe d'entité ne participe pas forcément à la relation.
Les identifiants
Un identifiant est un ensemble de propriétés (une ou plusieurs) permettant de désigner une et une seule entité. La définition originale est la suivante :
L'identifiant est une propriété particulière d'un objet telle qu'il n'existe pas deux occurrences de cet objet pour lesquelles cette propriété pourrait prendre une même valeur.
Les attributs d'une classe d'entité permettant de désigner de façon unique chaque instance de cette entité sont appelés identifiants absolus.
Le modèle conceptuel des données propose de faire précéder d'un # les identifiants (parfois de les souligner).
Ainsi, chaque classe d'entité doit posséder au moins un attribut identifiant, et l'ensemble de ses attributs identifiants doivent être renseignés à la création de l'entité.
Agrégation (ou identification relative)
Lorsqu'un identifiant est constitué uniquement d'attributs intrinsèques à une entité, c'est-à-dire ne faisant référence à aucune autre entité, on le nomme identifiant absolu. Les entités comportant des identifiants absolus peuvent être définies indépendamment des autres occurrences d'entités, on dit que ces entités sont indépendantes.
Certaines entités ne peuvent toutefois être identifiées que par l'intermédiaire d'autres entités, c'est la raison pour laquelle on parle d'identification relative.
On parlera par exemple de la 4ème porte au 2ème étage du bâtiment B au lieu de dire la porte n°3451...
Ainsi, l'agrégation (appelée aussi identification relative) permet de spécifier qu'une entité est nécessaire pour en identifier une autre.
Contraintes de totalité sur rôles
La contrainte de totalité sur rôles exprime le fait qu'une entité participe au moins à une des classes de relation qu'elle met en oeuvre.
Elle est représentée par un "T" reliant deux classes d'entités.
Contraintes d'exclusion sur rôles
La contrainte d'exclusion sur rôles exprime le fait qu'une entité ne peut pas participer aux deux classes de relation simultanément.
Elle est représentée par un "X" reliant deux classes d'entités.
Lorsque cette contrainte fait intervenir plusieurs relations, l'entité ne peut pas participer à toutes les relations simultanément, tout au plus à n-1 relations
Contraintes de sous-ensemble sur rôles
La contrainte de sous ensemble sur rôles exprime le fait qu'une entité participant à une classe de relation, participe obligatoirement à l'autre relation.
Elle est représentée par une flèche reliant deux classes d'entités et montrant la direction de l'implication.
…
GESTION DES NOMBRES / MONTANTS.
Soit le nombre ou le montant décrivent une entité naturelle et dans ce cas, ils constituent une propriété de l’entité comme une autre (on vérifiera alors le respect des 3 formes normales). Soit on ne peut pas placer le nombre dans une entité naturelle car il fait la liaison entre 2 entités (exemple : le nombre de poissons tirés par chasse et par espèce).
Dans ce cas, on a 2 modélisations possibles :
1°) On crée une entité qui contiendra la propriété nombre ainsi que les propriétés supplémentaires. Cette entité sera reliée par 2 associations avec des cardinalités 1,1 aux 2 autres entités.
Exemples :
2°) On crée une association avec des cardinalités maxi n et n entre les 2 entités. Le nombre sera alors une propriété de l’association (ainsi que les éventuelles autres propriétés).
Attention : dans ce type de modélisation, il faut vérifier que cela n’engendre pas un problème au niveau de la clé.
Exemple :
Le modèle logique donnerait :
Ainsi, le même agent ne pourrait pas effectuer de prélèvements sur la même parcelle à 2 dates différentes (on aurait un problème de doublons).
Conclusion : en cas de doute, choisir plutôt le premier mode de modélisation qui s’applique à tous les cas.
INTERPRETATION DE DOCUMENTS :
1°) Codes et numéros
Dans un document, tout code ou numéro correspondent souvent à la représentation d’un identifiant. Il y a donc une forte présomption quand on rencontre un code qu’il faille créer l’entité correspondante.
2°) Identification des liaisons 1,1 1,n
Lorsqu’on a un bloc homogène d’informations qui contient un code ou un numéro qui décrit un autre concept, il y a de fortes chances qu’on soit en présence d’une association de type 1,1 ---- 1,n.
Exemple :
Code exploitation Nom de l’exploitation
SAU
Code du comptable
Ici, il y a une association entre « exploitation » et « comptable ». Pour une exploitation, je ne peux trouver qu’un seul code comptable (=> cardinalités 1,1).
3°) Lecture des tableaux
Tout tableau se présente toujours de la manière suivante :
En-tête du tableau
Détail des lignes
Dans tous les cas, on aura la modélisation suivante :
Une entité pour l’en-tête du tableau
Une entité pour chaque ligne du tableau
Une association entre ces 2 entités avec les cardinalités 1,n de l’en-tête vers la ligne et des cardinalités 1,1 de la ligne vers l’en-tête.
L’entité qui modélisera chaque ligne du tableau devra bien évidemment respecter les formes normales et on trouvera ainsi souvent ce type de modélisation :
Exploitation
Code exploitation SI
Nom exploitation A50
La ligne du tableau peut également être reliée à plusieurs entités qui se trouvent dans les colonnes du tableau.
Exemple :
Code entreprise
Nom entreprise
Détail des employés
Service
Type de salarié Nombre
Commercial Salariés 75
Commercial Cadres 10
Administratif Salariés 10
Administratif Cadres 5
TYPE SALARIE
Code type salarié
Libellée type
SERVICE
Code service Libellé service
GESTION DE L’HISTORIQUE OU DU PREVISIONNEL
Il est nécessaire dans l’élaboration de tout modèle de se demander si la gestion de l’historique doit être intégrée.
Celle-ci permet en effet une gestion plus fine des informations mais génère en contrepartie un temps supplémentaire de programmation. Un modèle qui intègre l’historique génère en effet plus de tables, donc plus d’écrans de saisie ...
Il existe 2 principales façons d’intégrer la gestion de l’historique dans un modèle :
1°) on gère l’historique avec une seule date.
Exemples : gestion des visites d’un inspecteur académique à des classes, gestion des piqûres réalisées sur un patient ...
Dans ce cas, il faut créer une entité qui contient la propriété « Date » avec éventuellement d’autres propriétés qui sont spécifiques de l’intervention, visite ... effectuée à cette date.
2°) gestion de l’historique par période
Exemple : La liste des coefficients des matières varient à chaque année scolaire. On peut donc avoir ces 2 types de modélisation.
Ö Réaliser une entité période avec date début et date fin en y incluant éventuellement d’autres propriétés spécifiques à la période.
En général, on a 2 associations avec des cardinalités 1,1 qui partent de l’entité période vers 2 autres entités.
Exemple : on veut gérer la liste des postes occupés par un salarié (en gardant l’historique) en gérant à chaque fois le salaire correspondant.
SALARIE
Code salarie Nom salarie
PERIODE OCCUPATION
Id occupation Date début
Date fin Salaire
POSTE
Code poste Libellé poste
