Débuter avec la Méthode de Conception des Systèmes d'Information Merise


Télécharger Débuter avec la Méthode de Conception des Systèmes d'Information Merise

★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Télécharger aussi :


SOMMAIRE

I.     INTRODUCTION . 2

A.   Le besoin de méthodes 2

B.   Présentation de la méthode MERISE . 2

C.   Cycle d'abstraction pour la conception des SI .. 2

II.   Le Modèle conceptuel de la communication (MCC) .. 4

A.   Définition de l'organisation 4

B.   Diagramme de contexte .. 5

C.   Diagramme conceptuel de flux 5

III.    Le Modèle conceptuel des données (MCD) 6

A.   Entités et classe d'entité . 6

B.   Relations et classes de relation 7

C.   La cardinalité . 8

D.   Les identifiants . 8

IV.    LE Modèle conceptuel des traitements (MCT) .. 9

E.    Le concept d'événement .. 10

F.    Opération . 10

G.   Processus .. 10

H.   La synchronisation 11

I.      Construction du MCT .. 11

V.   LE Modèle logique des données (MLD) .. 11

A.   Traduction d'une classe d'entité .. 12

B.   Traduction d'une classe de relation 12

VI.    Le modèle logique des traitements  (mlt) . 13 VII. LE Modèle physique des données . 14

VIII. Les différentes phases d'un projet Merise 14 IX. Avantages et inconvénients de la méthode . 15

    X.    quelques Logiciels de modélisation en méthode Merise .. 15

I.INTRODUCTION

A. 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 MERISE étant souvent celle à laquelle on pense en premier, surtout pour la conception de projets de refonte de SI. 

B. Présentation de la méthode MERISE

MERISE est une méthode d’analyse, de conception et de réalisation de SI informatisés. Elle est basée sur la séparation des données et des traitements à effectuer et préconise d'analyser séparément données et traitements, à chaque niveau. On aura pris soin de vérifier la cohérence entre ces deux analyses avant la validation et le passage au niveau suivant. Cette séparation 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. 

C. Cycle d'abstraction pour la conception des SI

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

1)    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. 

2)    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. 

3)    Le modèle logique représente un choix logiciel pour le système d'information. 

4)    Le modèle physique reflète un choix matériel pour le système d'information. 

Courbe du soleil

La littérature parle souvent de « courbe du soleil », établissant une analogie entre la démarche Merise et le lever puis le coucher du soleil : de même, le projet doit élaborer une analyse critique de l'existant (en partant du niveau physique et en s'élevant jusqu'au conceptuel : démarche bottom-up, phase ascendante de la courbe), puis décliner la solution retenue (en partant du niveau conceptuel et revenant au niveau physique : démarche top-down, phase descendante de la courbe).

II.LE MODELE CONCEPTUEL DE LA COMMUNICATION (MCC)

A. 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

B. 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

C. 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

III.       LE MODELE CONCEPTUEL DES DONNEES (MCD)

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. 

A. 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. 

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.

 Cotonou, Parakou sont deux instanciations de la classe ville béninoise avec par exemple les propriétés nombre d’habitants, superficie…

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é

B. 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. 

C. 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. 

D. 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'identifiantest une propriété particulière d'un objet telle qu'il n'existe pas deux occurrences decet 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é. 



Remarques :

 Par construction, le MCD impose que toutes les propriétés d'une entité ont vocation à être renseignées (il n'y a pas de propriété « facultative »).

 Le MCD doit, de préférence, ne contenir que le cœur des informations strictement nécessaires pour réaliser les traitements conceptuels (cf. MCT) ; les informations calculées (ex: montant TTC d'une facture), déductibles (ex: densité démographique = population / superficie) et a fortiori celles liées aux choix d'organisation conçus pour effectuer les traitements (cf. MOT) ne doivent pas y figurer.

IV.       LE MODELE CONCEPTUEL DES TRAITEMENTS (MCT)

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ù  

E. 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

Un événement peut :

•    déclencher une opération (ex : 'commande client à prendre en compte' déclenche l'opération 'prise en compte commande'),

•    être le résultat d'une opération (ex : 'colis à expédier' suite à l'opération de 'préparation colis'), et à ce titre être, éventuellement, un événement déclencheur d'une autre opération.

On représente un événement par une ellipse en trait plein pour les événements internes à l'organisation, en trait pointillé pour les événements externes. 

F. 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. 

G. 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 correspondant aux opérations

H. 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

I. Construction du MCT

Le modèle conceptuel des traitements permet de représenter schématiquement la gestion des événements : 

       V.    LE MODELE LOGIQUE DES DONNEES (MLD)

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 reprend le contenu du MCD, mais précise la volumétrie, la structure et l'organisation des données telles qu'elles pourront être implémentées. Par exemple, à ce stade, il est possible de connaître la liste exhaustive des tables qui seront à créer dans une base de données relationnelle. 

Ainsi, le modèle logique est dépendant du type de base de données utilisé. 

A. 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. 

B. 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

VI.       LE MODELE LOGIQUE DES TRAITEMENTS  (MLT)

Le MLT, appelé aussi MOT pour « modèle organisationnel des traitements », décrit avec précision l’organisation à mettre en place pour réaliser une ou, le cas échéant, plusieurs opérations figurant dans le MCT. Il répond aux questions suivantes : qui ? quoi ? où ? quand ? À un MCT correspondent donc généralement plusieurs MLT.

Les notions introduites à ce niveau sont : le poste de travail, la phase, la tâche et la procédure.

Le poste de travail

Le poste de travail décrit la localisation, les responsabilités, et les ressources nécessaires pour chaque profil d’utilisateur du système.

Par exemple, on peut identifier les profils suivants : client-web, responsable commercial, responsable des stocks, etc.



La phase

La phase est un ensemble d’actions (cf. la notion d’opération pour le MCT) réalisées sur un même poste de travail.

La phase peut être : 

 soit manuelle : par exemple, la confection d'un colis ;

 soit automatisée et interactive : par exemple, la saisie d’un formulaire client ;  soit automatisée et planifiée (on parle aussi de batch) : par exemple, la production et l'envoi quotidiens de tableaux de bord dans les boites aux lettres électroniques.

La tâche

La tâche est une description détaillée d’une phase automatisée interactive.

Par exemple, elle correspond à la spécification de l’interface et du dialogue humainmachine, à la localisation et la nature des contrôles à effectuer, etc.

La procédure

La procédure est un regroupement de phases. Elle équivaut sur le plan organisationnel aux notions d’opérations et d’actions conceptuelles. La différence est que l'on considère ici ces dernières comme se déroulant sur une période de temps homogène.

Des procédures d’origines non conceptuelles peuvent être ajoutées du fait des choix d’organisation effectués.

Par exemple, on peut citer les procédures d’échanges d’informations liées à l’externalisation de certaines activités, la prise en compte des questions de sécurité en cas de choix de solution Web, etc.

VII.      LE MODELE PHYSIQUE DES DONNEES

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.

VIII.    LES DIFFERENTES PHASES D'UN PROJET MERISE

Un projet élaboré selon la méthode Merise est composé de différentes phases :

•    Les acteurs : il s'agit ici d'identifier les acteurs du projet, les personnes intervenant dans une quelconque phase de celui-ci. Ces acteurs apparaitront logiquement dans la modélisation des flux de données.

•    Le schéma directeur : le schéma directeur définit le cadre organisationnel et informatique des futurs projets, et donc doit définir le projet relativement aux objectifs de l'entreprise, sa stratégie. Il ne s'agira pas ici de donner les détails du projet, mais plutôt de fournir le cadre, les objectifs, et moyens du projet.

•    L'étude préalable : elle décrit les besoins et les attentes des utilisateurs, les traitements (processus métier) pour la procédure représentative (modèle conceptuel des traitements, modèle logique des traitements, ébauche de modèle physique des données), et les principales données (modèle conceptuel des données, modèle logique des données, ébauche de modèle physique externe des traitements),

•    L'étude détaillée : elle décrit les besoins, traitements, et données de façon plus détaillée pour chaque procédure fonctionnelle. L'étude détaillée se décompose elle-même en :  o Spécifications fonctionnelles générales (Tableau des opérations par processus, ToP), écrites par la maîtrise d'ouvrage, o Spécifications fonctionnelles détaillées, écrites par la maîtrise d'œuvre,

•    L'étude technique : elle décrit les moyens techniques nécessaires à la réalisation de l'application (environnement technique, SGBD, langages informatiques, consignes de développement, ).

•    La production : elle décrit la mise en production.

•    La maintenance : elle décrit la maintenance du système, et fournira donc au moins les éléments suivants :  o les acteurs o les documentations o les formations

IX.       AVANTAGES ET INCONVENIENTS DE LA METHODE

 Sa mise en œuvre peut paraître lourde 

On consacre en effet beaucoup de temps à concevoir et à pré-documenter avant de commencer à coder, ce qui pouvait sembler nécessaire à une époque où les moyens informatiques n'étaient pas aussi diffusés qu'aujourd'hui. Cela dit, elle évite l'écueil inverse du développement micro, qui souffre du manque de documentation, et où les erreurs sont finalement très coûteuses à réparer a posteriori.

 Formalisme jugé trop complexe

Même si les échanges et la consultation entre concepteurs et utilisateurs sont formellement organisés, on a aussi reproché à Merise d'utiliser un formalisme jugé complexe (surtout pour les modèles de données), qu'il faut d'abord apprendre à manier, mais qui constitue ensuite un véritable langage commun, puissant et rigoureux pour qui le maîtrise.

 Analyse de l’existant jugée trop couteuse car cette phase augmente considérablement la durée du projet.

       X.       QUELQUES LOGICIELS DE MODELISATION EN METHODE MERISE

 MySQL Workbench

 DBDesigner

 AnalyseSI

 WinDesign

 Open ModelSphere (GPL)

 MPD Designer



176