Cours et exercices d’application pour comprendre la methode Merise

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 :

• faire l'inventaire des éléments nécessaires au système d'information
• délimiter le système en s'informant auprès des futurs utilisateurs

...

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 :

• l'organisation est représentée par un rectangle
• les acteurs externes sont représentés par des ellipses en pointillés
• les flux d'information sont représentés par des flèches dont l'orientation désigne le sens du flux d'information

 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 :

• Les acteurs internes sont représentés par des ellipses
• les messages internes sont représentés par des flèches

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 :

• le champ du haut contient le libellé. Ce libellé est généralement une abréviation pour une raison de simplification de l'écriture. Il s'agit par contre de vérifier qu'à chaque classe d'entité correspond un et un seul libellé, et réciproquement
• le champ du bas contient la liste des propriétés de la classe d'entité

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 :

• une classe de relation récursive (ou réflexive) relie la même classe d'entité
• une classe de relation binaire relie deux classes d'entité
• une classe de relation ternaire relie trois classes d'entité
• une classe de relation n-aire relie n classes d'entité

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 :

• la borne minimale (généralement 0 ou 1) décrit le nombre minimum de fois qu'une entité peut participer à une relation
• la borne maximale (généralement 1 ou n) décrit le nombre maximum de fois qu'une entité peut participer à une relation

 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.

• la classe d'entité permettant d'identifier est appelée classe d'entité agrégeante
• la classe d'entité identifiée est appelée classe d'entité agrégée

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

1. a) avec des intervalles normalisés (ex : un trimestre d’une année scolaire). Ö réaliser une entité intervalle avec date début et date fin.

Exemple : La liste des coefficients des matières varient à chaque année scolaire. On peut donc avoir ces 2 types de modélisation.

1. b) Avec des intervalles non normalisés

Ö 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