MERISE - Initiation à la conception de systèmes d'information
Le besoin de méthodes
La conception d'un système d'information
n'est pas évidente car il
faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en
place.
La phase de conception nécessite des méthodes permettant de mettre
en place un modèle sur lequel on va s'appuyer.
La modélisation consiste à créer une représentation virtuelle d'une
réalité de telle façon à faire ressortir les points auxquels on
s'intéresse.
Ce type de méthode est appelé analyse. Il existe plusieurs
méthodes d'analyse, la méthode la plus utilisée en France étant la méthode MERISE.
Présentation de la méthode MERISE
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 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
Cela va permettre de créer le MCC (Modèle conceptuel de la communication) qui
définit les flux d'informations à prendre en compte.
L'étape suivante consiste à mettre au point le MCD (Modèle
conceptuel des données) et le MCT (Modèle conceptuel des traitements)
décrivant les règles et les contraintes à prendre en compte.
Le modèle organisationnel consiste à définir le MOT (Modèle
organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).
Le modèle logique représente un choix logiciel pour le système d'information.
Le modèle physique reflète un choix matériel pour le système d'information.
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :MERISE - Modèle conceptuel de la communication
Juin 2015
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.
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
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :
Merise-modele-conceptuel-de-la-communication .pdf
MERISE - Modèle conceptuel de la communication
Juin 2015
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.
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
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :
Merise-modele-conceptuel-de-la-communication .pdf
MERISE - Modèle conceptuel des données
Juin 2015
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é.
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.
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...
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
La représentation de ce type de relation est la suivante :
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :
Merise-modele-conceptuel-des-donnees .pdf
MERISE - Contraintes sur rôles
Juin 2015
La cardinalité d'une relation permet de définir les conditions de participation
d'une entité à une relation. Toutefois, une entité peut participer
à plusieurs relations, c'est ce que l'on nomme les contraintes sur rôles.
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.
Contraintes d'égalité sur rôles
La contrainte d'égalité sur rôles exprime le fait qu'une entité
participant à une classe de relation, participe obligatoirement à l'autre relation,
et réciproquement. Il s'agit donc d'une contrainte de sous-ensemble bidirectionnelle.
Elle est représentée par un signe "=" reliant deux classes d'entités.
Cette contrainte peut faire intervenir plusieurs relations, auquel cas une entité participant
à une relation doit participer aux n relations.
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :
Merise-contraintes-sur-roles .pdf
MERISE - Contraintes sur relations
Juin 2015
Alors que les contraintes sur rôles
permettent de définir les conditions de participation d'une entité à une relation,
les contraintes sur relations permettent d'exprimer des restrictions sur les classes
de relation.
Contraintes d'exclusion sur relations
La contrainte d'exclusion sur relation exprime le fait que deux occurrences de classes d'entité
ne peuvent pas participer simultanément à une même classe de relation.
Elle est représenté par un "X" reliant deux classes de relation.
Contraintes de sous-ensemble sur relations
La contrainte de sous ensemble sur relation exprime le fait que une occurrence de classe d'entité
participant à une classe de relation, participe obligatoirement à l'autre classe de relation.
Elle est représenté par une flèche reliant deux classes de relation
et montrant la direction de l'implication.
Contraintes d'égalité sur relations
La contrainte d'égalité sur relation exprime le fait qu'une occurrence de classe d'entité
participant à une classe de relation, participe obligatoirement à l'autre classe de relation,
et réciproquement. Il s'agit donc d'une contrainte de sous-ensemble bidirectionnelle.
Elle est représenté par un signe "=" reliant deux classes de relation.
Cette contrainte peut faire intervenir plusieurs
occurrences de classes d'entité, auquel cas une occurrence de classe
d'entité participant
à une classe de relation doit participer aux n classes de relation.
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :
Merise-contraintes-sur-relations .pdf
MERISE - Modèle conceptuel des traitements
Juin 2015
Le modèle conceptuel des traitements
Le modèle conceptuel des traitements permet de traiter la dynamique du système
d'information, c'est-à-dire les opérations qui sont réalisées en
fonction d'événements.
Ce modèle permet donc de représenter de façon schématique l'activité
d'un système d'information sans faire référence à des choix organisationnels
ou des moyens d'exécution, c'est-à-dire qu'il permet de définir simplement
ce qui doit être fait, mais il ne dit pas quand, comment ni où...
Le concept d'événement
Un événement représente un changement dans l'univers extérieur
au système d'information, ou dans le système d'information lui-même.
- un événement externe est un changement de l'univers extérieur
- un événement interne est un changement interne au système d'information
Définition d'un processus
Un processus est un sous-ensemble de l'activité de l'entreprise, cela signifie
que l'activité de l'entreprise est constituée d'un ensemble de processus.
Un processus est lui-même composé de traitements regroupés en ensembles
appelés opérations.
Opération
Une opération est un ensemble d'actions exécutées par le système
suite à un événement, ou à une conjonction d'événements.
Cet ensemble d'actions est ininterruptible, c'est-à-dire que les événements ne sont pas pris en compte (ils ne sont pas forcéments ignorés pour autant) tant que l'opération n'a pas été accomplie.
Cet ensemble d'actions est ininterruptible, c'est-à-dire que les événements ne sont pas pris en compte (ils ne sont pas forcéments ignorés pour autant) tant que l'opération n'a pas été accomplie.
La synchronisation
La synchronisation d'une opération définit une condition booléenne
sur les événements contributifs devant déclencher une opération.
Il s'agit donc de conditions au niveau des événements régies par une
condition logique réalisée grâce aux opérateurs :
- OU
- ET
- NON
Construction du MCT
Le modèle conceptuel des traitements permet de représenter
schématiquement la gestion des événements :
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :
Merise-modele-conceptuel-des-traitements .pdf
MERISE - Modèle organisationnel des traitements
Juin 2015
Le modèle organisationnel des traitements
Le modèle organisationnel des traitements s'attache à décrire les propriétés
des traitements non traitées par le modèle conceptuel des données, c'est-à-dire :
- le temps
- les ressources
- le lieu
Le tableau des procédures fonctionnelles
La première étape du modèle organisationnel des traitements
consiste à découper les opérations en procédures
fonctionnelles, une succession de traitements déclenchée par un
événement.
Il s'agit donc d'associer dans un tableau :
- les procédures fonctionnelles
- l'heure de début et de fin
- le lieu du poste de travail
- le responsable du poste de travail
- les ressources du poste de travail
| Procédure | temps | poste de travail | |||
| début | durée | lieu | responsable | ressources | |
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :
Merise-modele-organisationnel-des-traitements .pdf
MERISE - Modèle logique des données
Juin 2015
Le modèle logique des données
Le modèle logique des données consiste à décrire la structure
de données utilisée sans faire référence à un
langage de programmation. Il s'agit donc de préciser le type de données
utilisées lors des traitements.
Ainsi, le modèle logique est dépendant du type de base
de données utilisé.
Le modèle relationnel
Traduction d'une classe d'entité
Chaque classe d'entité du modèle conceptuel devient une table
dans le modèle logique. Les identifiants de la classe d'entité
sont appelé clés de la table, tandis que les attributs
standards deviennent des attributs de la table, c'est-à-dire des colonnes.
Traduction d'une classe de relation
Le passage du modèle conceptuel au modèle logique au niveau des classes
de relation se fait selon les cardinalités des classes d'entité participant
à la relation :
- si une des classes d'entités possède une cardinalité faible :
la table aura comme attributs, les attributs de la classe ayant une cardinalité faible, puis le (ou les) attribut(s) de relation et enfin les attributs de la seconde classe précédé du nom de la classe - si les deux classes d'entités possèdent une cardinalité forte :
la table aura comme attributs, les attributs des deux classes de relation précédés des noms des classes respectives, puis le (ou les) attribut(s) de relation
Traduction d'une classe d'agrégation
Dans le cas de la présence d'une classe d'agrégation, la classe
d'entité agrégée a comme attributs supplémentaires
les attributs de la classe d'entité agrégeante
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :
Merise-modele-logique-des-donnees .pdf
MERISE - Modèle physique des données
Juin 2015
Le modèle physique
Cette étape consiste à implémenter le modèle dans le SGBD,
c'est-à-dire le traduire dans un langage de définition de données.
Le langage généralement utilisé pour ce type d'opération
est le SQL, et plus spécialement le langage de
définition de données du SQL.
Pour une lecture illimitée hors ligne, vous avez la possibilité de télécharger gratuitement cet article au format PDF :
Merise-modele-physique-des-donnees .pdf
Aucun commentaire:
Enregistrer un commentaire