Cours Merise

Modelisation avec Merise support de formation de base


Télécharger Modelisation avec Merise support de formation de base

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

Télécharger aussi :


Modélisation avec Merise support de formation de base

Merise est une méthode d'analyse pour les projets informatiques

Merise est une méthode de conception de systèmes d'information de gestion.

Merise ne se limite pas à l'aspect informatique. Cette méthode a eu comme objectif premier de jeter un pont entre les besoins des utilisateurs et les solutions des informaticiens. Certes sa finalité est quand même de faciliter la conception des projets informatiques en permettant d'analyser et de formaliser très tôt les « besoins » des utilisateurs.

Qu'est qu'un système d'information La définition du système d'information est issue de la théorie des systèmes ou systémique. Bien que fortement « théorisante », elle fournit un éclairage assez solide sur le terrain (lorsqu'on ne voit plus de quoi on parle…)

Une « organisation » (entreprise, administration, collectivité, tout groupe social organisé exerçant une activité) peut être modélisé comme comportant trois sous systèmes :

  • le système de pilotage (celui qui réfléchit, décide, oriente)
  • le système opérant (celui qui produit, transforme, agit)
  • le système d'information

Le système d'information est la représentation de l'activité du système opérant ,construite par et pour le système de pilotage pour en faciliter le fonctionnement. Le système d'information a deux grandes fonctions :

  • recueillir, mémoriser et diffuser les informations
  • assurer le traitement de ces informations

On reconnaît ici la fameuse dichotomie Données / Traitements.

Le système d'information, dans son principe, n'est pas né avec l'informatique ! Les pharaons disposaient de systèmes d'informations ; seuls les moyens différaient. C'est la capacité de l'outil informatique à amplifier la gestion des données et des traitements qui a conduit à distinguer deux niveaux de système d'information :

Une « organisation » (entreprise, administration, collectivité, tout groupe social organisé exerçant une activité) peut être modélisé comme comportant trois sous systèmes :

  • le système d'information organisationnel (SIO), la partie visible, basée essentiellement sur des ressources humaines, de l'activité organisée
  • le système d'information informatisé (SII) correspondant au contenu informatisé du SI (logiciel, base de données)

Ainsi, un projet informatique a pour objectif de construire une application informatique (logiciel et base de données), support d'un système d'information informatisé, inclus dans un système d'information organisationnel. Merise ne fait que rappeler que l'on ne peut pas construire un SII sans comprendre au préalable le SIO dans lequel on l'implante ! J'utilise parfois la métaphore de la « prothèse » que l'on greffe au sein de l'organisation pour amplifier ses fonctions, qui doit être adaptée à son contexte, ne pas « blesser » le récepteur sous peine de rejet…

Qu'est ce qu'une méthode Une méthode comporte trois axes indispensables pour obtenir ce label « méthode » :

  • une démarche, ensemble coordonné d'étapes, de phases et de tâches indiquant le chemin à suivre [Hodos, le chemin en grec, serait une des étymologies de méthode] pour conduire un projet, ici, la conception d'un SI,
  • des raisonnements et des techniques nécessaires à la construction de l'objet projeté, traduits ici par des modélisations,
  • des moyens de mise en œuvre, en l'occurrence une organisation de projet et des outils.

Seule la réunion de ces trois dimensions permet une utilisation opérationnelle. Dès le début, Merise s'est voulu une méthode. Avec un effet induit : dès que l'un des axes est remis en cause, l'ensemble en pâti…C'est en effet la lourdeur de la démarche, dénoncée dans les années 90, qui a « plombé » Merise.

  1. Les 3 composantes de la méthode Merise

3.1. la démarche ou cycle de vie

Elle traduit le caractère "vivant" du système d'information qui naît, croît, évolue et meurt puis renaît...

En informatique, on peut distinguer 3 grandes périodes: la conception, la réalisation, la maintenance.

La conception se découpe en 3 étapes:

  • le schéma directeur :définition des orientations générales du développement en termes d'objectifs et de contraintes (options sociopersonnelles, politique matérielle et logicielle, cagres budgétaires...)
  • l'étude préalable : avant de se lancer complètement dans un projet, on élabore globalement différentes solutions et on en évalue les conséquences.
  • l'étude détaillée : permet d'obtenir, pour l'utilisateur, une description complète du futur système d'information organisationnel (+ réajustement des évaluations des moyens, des coûts et délais déjà estimés dans l'étude préalable).

La réalisation se découpe également en 3 étapes:

  • l'étude technique : traduction informatique des spécifications issues de l'étude détaillée. Elle permet de déterminer la structure informatique de la BD, l'architecture des programmes et des accès aux données.
  • la production de logiciel : traduire les programmes dans les langages appropriés , générer les fichiers ou BD, tester
  • la mise en service : installer les logiciels réalisés et mettre progressivement l'ensemble du système d'information au service des utilisateurs.

La maintenance finalement consiste à prendre en compte les évolutions apparaissant ultérieurement, la rectification des anomalies et diverses améliorations. Cette étape est à priori la plus importante de la vie d'un projet!

3.2. Les raisonnements ou cycle d'abstraction

Lors de la conception d'un système d'information, des problèmes très variés peuvent se poser (définition des règles de gestion, définition des informations, répartition des traitements entre l'homme et la machine, organisation physique des fichiers, choix du matériel,...). Ces problèmes conduisent à faire des choix de natures différentes (gestion, organisation, techniques, matériels,etc..).

Merise considère 4 niveaux d'abstraction, les 2 1ers au sein du système d'informatisation organisationnel (SIO), les 2 suivants au sein du système d'informatisation  informatisé (SII):

  • niveau conceptuel : exprime les choix fondamentaux de gestion (recherche des éléments stables, indépendammment des moyens à mettre en oeuvre, de leurs contraintes et de leur organisation
  • niveau organisationnel : exprime les choix d'organisation de ressources humaines et matérielles (définition de sites, de postes de travail...)
  • niveau logique : exprime les choix de moyens et ressources informatiques en faisant abstraction de leurs caractéristiques techniques précises
  • niveau physique : traduit les choix techniques et la prise en compte de leurs spécificités.

Merise propose un modèle différent pour chaque niveau d'abstraction et ceci pour chaque volet (données, traitements). Chaque modèle est exprimé dans un formalisme utilisant des concepts adaptés.

  • Le modèle conceptuel de données (MCD) formalise la signification des informations sans contraintes techniques ni économiques.
  • Le modèle conceptuel de traitements (MCT) formalise l'activité du domaine abordé sans préciser les ressources ni leur organisation.
  • Le modèle organisationnel des données (MOD) précise quelles sont parmi les données définies dans le MCD celles qui sont prises en compte par le futur système informatisé, où ces données sont localisées, leur confidentialité pour chaque intervenant de l'entreprise.
  • Le modèle organisationnel de traitements (MOT) décrit le fonctionnement du domaine en précisant les ressources humaines et matérielles mobilisées ainsi que l'organisatiopn de ces ressources dans le temps et l'espace.
  • Le modèle logique de données (MLD) fournit une desription des données tenant compte des moyens informatiques de mémorisation et leurs conditions d'utilisation par les traitements.
  • Le modèle logique de traitements (MLT) décrit comment les tâches informatisées définies dans les MOT sont conçues en termes de logiciel.
  • Le modèle physique de données (MPD) est une description de la ou des bases de données ou de l'ensemble des fichiers, exprimée dans la syntaxe du SGBD ou système de gestion de fichiers adoptés.
  • Le modèle physique de traitements (MPT) précise, pour la réalisation, les spécifications techniques des différents modules définis au niveau du MLT. Ces modules pourront être réalisés soit en langage de 4ème génération, soit de façon plus traditionnelle en langage de 3ème génération (Cobol, C...).

Ce parcours de cycle d'abstraction mettra en jeu des compétences diverses (gestionnaires, utilisateurs, informaticiens,...)



3.3. La maîtrise du projet ou cycle de décision

Elle est pricipalement constituée par la répartition des rôles entre les différents partenaires, les diverses décisions à prendre au fur et à mesure de l'avancement du projet, la hiérarchisation des choix et les résultats à produire. Un ensemble de décisions d'arbitrage relatives au coût, délai et niveau de gamme est toujours associé au projet.

  1. Les raisonnements de la méthode Merise : Conception du système d'information organisationnel.

4.1. Découpage en domaines et analyse des flux

C'est l'analyse systémique qui nous fourni une modélisation de l'entreprise échangeant et transformant des flux. Cette vision unitaire d'un système d'information général est difficilement exploitable. Pour tenter de réduire la complexité de modélisation d'une entreprise et pour obtenir des tailles de projet maîtrisables, on cherche à découper l'entreprise en domaines d'activités (ex vendre, stocker, acheter, gérer du personnel ...). Chaque domaine est considéré comme quasi autonome. Cependant, les systèmes d'information résultant du découpage en domaines ne sont pas disjoints. Ils entretiennent entre eux des flux.

L'analyse des flux permet d'appréhender le fonctionnement global de l'entreprise, en se focalisant éventuellement sur un ensemble d'activités concernées par l'étude.

Elle s'exprime avec 2 concepts : l'acteur et le flux.

Dans la pratique, un acteur peut modéliser un partenaire extérieur à l'entreprise = acteur externe (client, fournisseur,...), un domaine d'activité de l'entreprise = acteur interne (comptabilité, gestion du personnel,...), ..

Le flux représente un échange entre 2 acteurs.

Les diagrammes de flux sont des représentations graphiques des acteurs et des flux échangés.

L'aspect visuel et la simplicité du symbolisme font du diagramme des flux un support efficace pour le dialogue avec l'utilisateur, en particulier lors des 1ers entretiens.

Le diagramme de flux peut parfois, dans la phase d'analyse de l'existant, se substituer au MOT dans le cas où les aspects organisationnels sont simples ou limités.

ex:

4.2. Modélisation conceptuelle des traitements

Elle a donc pour objectif de représenter formellement les activités exercées par le domaine, activités dont la connaissance est la base du système d'information.

Merise s'exprime dans un formalisme spécifique élaboré pour permettre de représenter le fonctionnement d'activités aux différents niveaux de préoccupation. Il s'inspire du formalisme des réseaux de Pétri et comporte les concepts suivants: l'acteur, l'événement / résultat-message, l'état, l'opération.

  • l'acteur: les acteurs pris en compte dans un MCT sont uniquement les acteurs externes au domaine. Les acteurs internes au domaine mis en évidence dans l'analyse des flux traduisent un découpage organisationnel dont on doit faire abstraction au niveau conceptuel.
  • l'événement/résultat-message: les flux reçus (stimuli) et émis (réaction) par le domaine sont respectivement modélisés en événements et résultats. Un événement est émis par un acteur à destination du domaine. Un résultat est la formalisation d'une réaction du domaine et de son système d'information. Il est émis par une activité du domaine à destination d'un acteur.
  • l'état (concept nouvellemnt introduit dans la méthode Merise): modélise une situation du système d'information. L'exécution de certaines activités dépendra de l'état du système (ex dossier d'assurance doit être ouvert avant d'instruire un sinistre...)
  • l'opération: est la description du comportement du domaine et de son système d'information par rapport aux événements types. Elle est déclenchée par la survenance d'un événement... Elle comprend l'ensemble des activités que le domaine peut effectuer à partir des informations fournies par l'événement.

Comme tout modèle, un MCT doit représenter fidèlement le système étudié. Afin de le vérifier,  le MCT doit respecter quelques règles simples de syntaxe:

  • un acteur émet au moins un événement, ou reçoit au moins un résultat
  • un événement externe provient au moins d'un acteur
  • un résultat provient d'au moins une opération
  • une opération est déclenchée soit directement par un événement ou un état, soit par une synchronisation unique
  • ...
  • un fonctionnement cyclique doit pouvoir être contrôlé (il y a un cycle dans un MCT lorqu'un état contribue à un opération qui produit directement ou à travers plusieurs opérations à ce même état
  • tout résultat ou état du MCT doit pouvoir être produit
  • les situations de conflit doivent être analysées (il y a conflit sur un événement/résultat s'il est destiné à plusieurs acteurs

4.3. Modélisation conceptuelle des données

Le MCD est donc la représentation de l'ensemble des données du domaine, sans tenir compte des aspects techniques et économiques de mémorisation et d'accès, sans se référer aux conditions d'utilisation par tel ou tel traitement.

Dans la plupart des systèmes d'information en fonctionnement, les données et les traitements apparaissent intimement liés du point de vue de l'utilisateur. L'ensemble des informations utilisées constitue l'univers du discours du domaine. On y fait généralement référence à des objets concrets ou abstraits (la facture, le client,...) et à des relations entre ces objets. L'objectif du MCD sera d'identifier ces objets et ces relations afin de les modéliser.

On adopte souvent pour ce faire une démarche inductive qui s'appuie sur l'existence préalable d'une liste d'informations à structurer fournie par l'utilisateur ou le gestionnaire. On essaye ainsi de la décortiquer en informations élémentaires constituant le "dictionnaire des données".

4.3.1. Constitution du dictionnaire de données

Il s'agit de rassembler au cours d'entretiens ou sur des documents écrits les informations présentes. A chaque information que le concepteur receuille dans son environnement, il s'agit, avant de la rajouter au dictionnaire de données, de vérifier que la nouvelle information n'a pas déjà été repertoriée (ex. les n° de facture ou de police d'assurance apparaissent dans de nombreux documents) sous le même nom ou sous un synonyme. Attention la situation inverse peut également se rencontrer : 2 informations portant le même nom dans 2 documents différents peuvent être réellement différentes (2 "dates" sur 2 formulaires différents, une date de facturation, une de livraison). Dans ce cas, il faut faire apparaître les 2 dans le dictionnaire de données et lever l'ambiguité sur les noms.

4.3.2. Formalisme de description des données = Diagrammes Entités/Associations

4 concepts types de base:

Entités / Associations / Propriétés / Cardinalités

La propriété type

est la modélisation d'une information élémentaire présente dans le dictionnaire de données. Il y a ici une notion de type, la propriété type pourra prendre des valeurs.

ex: nom de patient : Antoine, Fabien, Henri

 date de naissance : 28/03/59, 06/05/99

Attention, toutes les informations ne sont pas systématiquement traduites par une propriété.



La propriété est une donnée élémentaire obligatoirement liée à une entité type ou à une association type.

Règles:

  • A tout instant, une propriété n'a qu'une seule valeur (valeur unique)
  • Elle ne peut se rattacher qu'à un seul concept, entité ou association (pas de redondance)
  • Elle est atomique (pas de sous propriétés)

Remarque: Merise "moderne" permet la modélisation de propriétés "composées". Elle permet, en étude préalable, de "nommer" un ensemble d'informations sans systématiquement en exprimer le détail. Chaque fraction de valeur d'une propriété composée peut être exprimée par la valeur de chaque propriété composante.

L'entité type permet de modéliser un ensemble d'objets concrets ou abstraits présentant une existence propre et un intérêt dans le discours.

On parlera d'"occurrences" d'entité type.

Remarque: Très souvent par abus de langage on se passera du mot type suivant le mot entité.

Représentation graphique :

La reconnaissance des différentes entités d'un modèle obéit à des règles de pertinence. Plusieurs modélisations sont possibles sur la base d'un même discours, certaines plus "pertinentes" que d'autres.

Règle d'identification

L'on doit pouvoir faire référence distinctement à chaque occurrence de l'entité. Pour cela l'entité type doit être dotée d'un identifiant.

Cet identifiant est une propriété (ou un groupe de propriétés, on parle alors d'identifiant composé) telle qu'à chacune de ses valeurs correspond une seule occurrence de l'entité.

Représentation graphique: la propriété identifiant est soulignée au sein de l'entité.

Dans certains formalismes, elle apparaît également répétée en bas de l'entité, précédée de "id".

Règles: Un identifiant d'une entité type doit être

  • univalué: : à une occurrence de l'entité doit correspondre une seule valeur pour un identifiant donné
  • discriminant : à une valeur correspond une seule occurrence de l'entité
  • stable : pour une occurrence d'entité donnée, une fois affectée une valeur à son identifiant, cette valeur doit être conservée jusqu'à la destruction de l'occurrence
  • minimal : lorsqu'il s'agit d'un identifiant composé d'un groupe de propriétés, toutes celles-ci doivent être indispensables. Ainsi la suppression de n'importe laquelle lui ferait perdre son caractère discriminant.

Le choix d'un identifiant est parfois un problème délicat. On peut choisir une propriété "naturelle" ou, au contraire, une nouvelle propriété "artificielle", inventée par le concepteur (numéros, codes).

Règle d'énumération:

  • A toute occurrence de l'entité (càd à toute valeur de l'identifiant) , il ne peut y avoir qu'une valeur de chaque propriété.

Si une propriété viole cette règle, c'est qu'elle ne peut pas se situer au sein de cette entité.

ex: Un acteur pouvant avoir joué dans plusieurs films, la propriété nom de film ne peut faire partie de l'entité Acteurs mais donnera naissance à une nouvelle entité Films

...

Types et sous-types d'entités : spécialisations/généralisations

Spécialisation simple

Lorsqu'une entreprise effectue sa comptabilité, ses clients et ses fournisseurs apparaissent comme des tiers. En dehors d'informations tout à fait spécifiques voire opposées, ceux-ci ont néanmoins des caractéristiques communes (ils ont tous une adresse, une raison sociale...)

La spécialisation consiste à modéliser d'abord une entité TIERS (entité surtype) décrivant uniquement les caractéristiques communes aux clients et aux fournisseurs. Ensuite, on considère les entités CLIENTS et FOURNISSEURS (entités sous-types) avec leurs caractéristiques spécifiques.

En fait, les occurrences d'un sous-type sont également occurrences d'un surtype. Elles héritent des propriétés définies au niveau du surtype. Les entités sous-types ne possèdent pas d'identifiant propre mais héritent de l'identifiant du surtype. Elles se comportent néanmoins comme de vraies entités et peuvent faire partie d'autres associations.

Ces spécialisations aussi appelées relations is-a sont représentées avec un triangle:

Une spécialisation peut comporter un nombre quelconque de sous-types, eux-mêmes pouvant être surtypes d'une autre spécialisation. On a alors une arborescence de spécialisations.

De même un même surtype peut l'être pour plusieurs spécialisations selon des critères différents. On parle alors de spécialisations multiples.

Contraintes sur spécialisations

On peut imaginer, dans certaines situations, que le découpage en sous-populations comporte des contraintes de participation aux différents sous-types.

On peut visualiser sur l'exemple tiers, clients, fournisseurs les différentes situations grâce à la théorie des ensembles:

  1. a) les tiers peuvent être clients ou fournisseurs ou autres (ou inclusif)
  2. b) les tiers peuvent être clients et fournisseurs en même temps mais rien d'autre.

On placera la lettre T (total) au milieu du triangle de la spécialisation

  1. c) les tiers ne peuvent pas être clients et en même temps fournisseurs mais ils peuvent être autres . On placera la lettre X (exclusion) au milieu du triangle de la spécialisation

) les tiers ne peuvent être que soit clients, soit fournisseurs, pas les 2 et rien d'autre. En termes mathématiques, C et F forment une partition de T

On placera les lettres XT au milieu du triangle de la spécialisation

Spécialisations à surtypes multiples

Lorsque 2 populations ont une intersection, on peut modéliser la population intersection comme un sous-type respectivement des 2 populations.

ex: une population d'étudiants et une population de salariés. Certains étudiants sont salariés. Une entité étudiant salarié peut être modélisée, sous-type aussi bien de l'entité étudiant que de l'entité salarié. Elle ne possède pas d'identifiant propre mais bien un identifiant alternatif, soit celui de l'entité étudiant, soit celui de l'entité salarié.

Généralisations

Contrairement aux spécialisations, ici les sous-types préexistent. Ils sont donc identifiés par un identifiant propre. C'est la seule différence avec les spécialisations.  

4.3.3. Modéliser les contraintes en Merise

  • Dépendances fonctionnelles intraentités

En mathématiques, la notion de dépendance fonctionnelle (ou de fonction) entre 2 ensembles A et B exprime qu'à un élément a de A correspond au plus un élément b de B. On note A  B



On parle de l'ensemble source et de l'ensemble cible.

Par extension, au sein d'une entité (ou même d'une association), on pourra constater d'éventuelles dépendances fonctionnelles entre 2 propriétés S et C (source et cible) .

...

  • Contraintes interassociations

 Contraintes sur la participation d'une entité à plusieurs associations

Elles concernent la coexistence d'occurrences de différentes associations au départ d'une entité commune.

On représentera un cercle dans lequel on spécifiera le type de contrainte. On le liera aux associations concernées par un trait plein (et éventuellement à l'entité concernée par un trait pointillé).

Contraintes d'exclusion

Si une occurrence d'une entité E1 participe à l'association Ass 1, alors elle ne peut nécessairement pas participer à l'association Ass 2 et réciproquement.

Seule une des occurrences des associations liées à une même occurrence d'entité peut exister.

On placera la lettre X au sein du petit cercle.

Contraintes d'inclusion

Si une occurrence d'une entité E1 participe à l'association Ass 1, alors elle participe nécessairement à l'autre (mais pas réciproquement).

On placera la lettre I au sein du petit cercle et on dirigera une flèche vers l'association cible.

Contraintes de simultanéité (ET logique)

Toute occurrence de l'entité E1 participant à l'association Ass 1 participe simultanément à l'association Ass 2.

On placera la lettre S au sein du petit cercle.

Contraintes de totalité (OU inclusif)

Toute occurrence de l'entité E1 participe au moins à l'une des 2 associations Ass 1 ou Ass 2.

On placera la lettre T au sein du petit cercle.

Contraintes d'exclusion et totalité(OU exclusif)

Toute occurrence de l'entité E1 participe au moins à l'une des 2 associations Ass 1 ou Ass 2 mais jamais aux 2 à la fois.

On placera les lettres XT au sein du petit cercle.

Quelques exemples:

Contrainte d'exclusion

Soit un responsable dans un centre de vacances. Soit il travaille comme éducateur et "surveille" des adolescents, soit il est spécialisé dans une activité sportive

Contrainte de simultanéité

Toute personne qui possède un véhicule contracte nécessairement une assurance RC et inversément si une personne a un contrat d'assurance auto RC c'est qu'elle possède un véhicule.

 Contraintes sur la participation de plusieurs entités à plusieurs associations

L'ensemble de référence n'est plus limité à une entité mais à des n-uples d'entités.

Soient 2 associations A1 et A2 liant chacune l'entité E1 à l'entité E2

A1 est en "DF exclusive" avec A2

ssi

 (e1,e2)  A1, (e1,e2)  A2 (avec e1 occurrence de E1 et e2 occurrence de E2)

4.3.4. Modélisation du temps

Le MCD est par nature statique. Néanmoins, on désire parfois mémoriser des données liées au temps.

Propriété à valeur calendaire

(ex date de livraison, mois d'échéance, année d'exercice, ...)

La première question qui souvent se pose est celle de Temps, Date: Entités ou Propriétés ?

o Si un événement est modélisé sous forme d'une entité (ex : commande, facture,...), cela signifie qu'il est identifié par un identifiant (n°commande, ...). Si l'on désire connaître la date de cet événement, celle-ci sera tout naturelllement une nouvelle propriété de l'entité concernée.

o Si un événement est modélisé sous forme d'une association, la situation n'est pas aussi évidente.

L'association ne possède pas d'identifiant propre.

La question à se poser est alors: Le temps participe t'il à l'identification de l'association? En d'autres termes, peut-on avoir 2 occurrences de l'association ne différant que par l'information temps?

Si la réponse est oui, le temps devra être modélisé comme une nouvelle entité et l'association s'enrichira d'une nouvelle patte vers celle-ci,

si la réponse est non, le temps sera simplement une propriété de l'association.


298