Merise (informatique)

Un article de Wikivisual, l'encyclopédie libre.

(Redirigé depuis MERISE)

Pour les articles homonymes, voir Merise. Image:Disambig.svg

Merise est une méthode d'analyse, de conception et de gestion de projet complètement intégrée, ce qui en constitue le principal atout. Elle a fourni un cadre méthodologique et un langage commun et rigoureux à une génération d'informaticiens français.

Sommaire

1 Historique de Merise
2 Méthode d'analyse et de conception
3 Méthode de conduite de projet
4 Méta-modèle de Merise pour les données
- 4.1 Types de "modèles" (méta-modèles) dits "Entity-Relationship"
5 Bibliographie
6 Voir aussi
7 Lien externe

[modifier] Historique de Merise

Historique de Merise sur developpez.com

Issue de l'analyse systémique, la méthode MERISE est née dans les années 1970 et a surtout été utilisée en France, par les SSII de ses membres fondateurs (Sema Metra, ainsi que par la CGI Informatique) et principalement pour les projets importants. Elle a d'emblée connu la concurrence de méthodes anglo-saxonnes telle que SDM/S ou Axial. Elle a ensuite cherché à s'adapter aux évolutions rapides des technologies de l'informatique avec MERISE/objet, puis MERISE/2 destinée à s'adapter au client-serveur. Depuis les années 90 environ, la seule méthode qui peut prétendre à la remplacer est UML, mieux adaptée à la conception de projet sur micro-ordinateurs puis avec internet, mais sans en avoir la même portée.

[modifier] Méthode d'analyse et de conception

De l'aveu même d'un de ses fondateurs, le nom MERISE vient de l'analogie faite entre le Merisier "qui ne peut porter de beaux fruits que si on lui greffe une branche de cerisier : ainsi en va-t-il des méthodes informatiques bien conçues, qui ne produisent de bons résultats que si la greffe sur l'organisation réussit", même si initialement, beaucoup de gens ont voulu y voir un acronyme signifiant Méthode d'Étude et de Réalisation Informatique par les Sous-Ensembles ou pour les Systèmes d'Entreprises.

La méthode Merise d'analyse et de conception propose une démarche articulée sur 3 niveaux de préoccupation.

Cet étagement en 3 niveaux a pour objectif de hiérarchiser les préoccupations et les questions auxquelles répondre lors de la conduite d'un projet. L'objectif est de ne pas biaiser les réponses apportées au niveau conceptuel par des choix de technique ou d'organisation (ou de ré-organisation) : le niveau conceptuel vise ainsi à s'abstraire de questions d'ordre organisationnel ou technique, c'est le cycle d'abstraction.

[modifier] Niveau conceptuel

Les travaux menés à ce niveau visent à décrire le modèle (le système) de l'entreprise ou de l'organisme :

le Modèle Conceptuel des Données (ou MCD), schéma représentant la structure du système d'information, du point de vue des données, c'est-à-dire les dépendances ou relations entre les différentes données du système d'information (par exemple : la ligne de commande, le numéro de client, etc.),
et le Modèle Conceptuel des Traitements (ou MCT), schéma représentant les traitements, en réponse aux événements à traiter (par exemple : la prise en compte de la commande d'un client).

L'étude conceptuelle Merise s'attache aux invariants de l'entreprise ou de l'organisme du point de vue du métier : quels sont les objets métier gérés par l'entreprise, quels sont les processus traités, ... indépendamment des choix techniques (comment fait-on ?) ou organisationnels (qui fait quoi ?) qui ne seront abordés que dans les niveaux suivants.

Dans l'idéal, le MCD et le MCT d'une entreprise sont stables, à périmètre fonctionnel constant, et tant que le métier de l'entreprise ne varie pas. La modélisation ne dépend pas du choix d'un progiciel ou d'un autre, d'une automatisation ou non des tâches à effectuer, d'une organisation ou d'une autre, etc.

[modifier] Le MCD modèle conceptuel des données

Le MCD repose sur les notions d'entité et d'association (entity/relationship en anglais).

L'entité ou objet

L'entité est définie comme un objet de gestion considéré d'intérêt pour représenter l'activité à modéliser (exemple : entité pays) et chaque entité est porteuse d'une ou plusieurs propriétés simples, dites atomiques (exemples : code, nom, capitale, population, superficie) dont l'une, unique et discriminante, est désignée comme identifiant (exemple : code).

L'entité se décline en occurrences.

Exemples :

(fr, france, paris, 60,4 millions hab., 550 000 km²),
(de, allemagne, berlin, 82 537 000 hab., 357 027 km²),

sont des occurences de l'entité "pays", constituées de n-uplets de propriétés, et que le code FR ou DE, suffit à identifier sans risque de doublon.

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 taxes comprises 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.

L'association ou relation

L'association est un lien sémantique entre une ou plusieurs entités : l'association peut être réflexive, de préférence binaire (ex : une usine 'est implantée' dans un pays), parfois ternaire, voire de dimension supérieure. Elle peut également être porteuse d'une ou plusieurs propriétés (ex : 'date d'implantation' d'une usine dans un pays)

Cette description sémantique est enrichie par la notion de cardinalité, celle-ci indique le nombre minimum (0 ou 1) et maximum (1 ou n) de fois où une occurrence quelconque d'une entité peut participer à une association (ex: une usine est implantée dans un (card. min=1) et un seul (card. max=1) pays; et réciproquement un pays peut faire l'objet soit d'aucune (card. min=0) implantation d'usine soit de plusieurs (card. max=n).

[modifier] Le MCT modèle conceptuel des traitements

Le MCT repose sur les notions d'événement et d'opération, celle de processus en découle.

L'événement

Un événement est assimilable à un message porteur d'informations donc potentiellement de données mémorisables (par exemple : l'événement 'commande client à prendre en compte' contient au minimum l'identification du client, les références et les quantités de chacun des produits commandés).

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.

L'opération

Une opération se déclenche uniquement par le stimulus d'un ou de plusieurs évènements synchronisés

Elle est constituée d'un ensemble d'actions correspondant à des règles de gestion de niveau conceptuel, stables pour la durée de vie de la future application (ex: pour la prise en compte d'une commande : vérifier le code client (présence, validité), vérifier la disponibilité des articles commandés, ...).

Le déroulement d'une opération est ininterruptible : les actions à réaliser en cas d'exceptions, les évènements résultats correspondants doivent être formellement décrits (ex : en reprenant l'exemple précédent, si le code client indiqué sur la commande est incorrect prévoir sa recherche à partir du nom ou de l'adresse indiqués sur la commande, s'il s'agit d'un nouveau client prévoir sa création et les informations à mémoriser, ...)

Le processus

Un processus est une vue du MCT correspondant à un enchaînement pertinent d'opérations du point de vue de l'analyse (ex : l'ensemble des évènements et opérations qui se déroulent entre la prise en compte d'une nouvelle commande et la livraison des articles au client)

[modifier] Niveau organisationnel

A ce niveau de préoccupation, les modèles conceptuels sont précisés et font l'objet de choix organisationnels. On construit :

un Modèle Logique des Données (ou MLD), qui reprend le contenu du MCD précédent, mais précise la volumétrie, la structure et l'organisation des données telle 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
un Modèle Logique des Traitements (ou MLT), qui précise les acteurs et les moyens qui seront mis en œuvre. C'est ici que les traitements sont découpés en procédures fonctionnelles (ou PF).

Comme son nom l'indique, l'étude organisationnelle s'attache à préciser comment on organise les données de l'entreprise (MLD) et les tâches ou procédures (MLT). Pour autant, les choix techniques d'implémentation, tant pour les données (choix d'un SGBD) que pour les traitements (logiciel, progiciel), ne seront effectués qu'au niveau suivant.

[modifier] Le MLD modèle logique des données

Le MLD est une transcription ( également appelée dérivation ) du MCD dans un formalisme adapté à une implémentation ultérieure, au niveau physique, sous forme de base de données relationnelle ou réseau, ou autres (ex: simples fichiers ).

La transcription d'un MCD en modèle relationnel s'effectue selon quelques règles simples qui consistent d'abord à transformer toute entité en table, avec l'identifiant comme clé primaire, puis à observer les valeurs prises par les cardinalités maximum de chaque association pour représenter celle-ci soit (ex:card. max 1-n ou 0-n) par l'ajout d'une clé étrangère dans une table existante, soit (ex:card. max n-n) par la création d'une nouvelle table dont la clé primaire est obtenue par concaténation de clés étrangères correspondant aux entités liées, exemple :

MLD / Modèle relationnel

PAYS(code_pays)

USINE(id_usine,@code_pays,date_implantation)

EXPORT(@id_usine,@code_pays)

Les opérateurs de l'algèbre relationnelle ( projection, selection, jointure, opérateurs ensemblistes ) Langage d'interrogation de données peuvent ensuite directement s'appliquer sur le modèle relationnel ainsi obtenu et normalisé Formes normales.

Cette démarche algorithmique ne fournit pas à ce niveau d'élément sur l'optimisation de la durée ou des ressources nécessaires pour exécuter les traitements dans l'environnement de production cible.

La transcription du MCD en MLD doit également être précédée d'une étape de synchronisation et de validation des modèles de données ( MCD ) et de traitement (MCT et MLT ), au moyen de vues . Cela afin d'y introduire les informations d'organisation définies au MLT, d'éliminer les propriétés conceptuelles non utilisées dans les traitements ou redondantes et enfin de vérifier que les données utilisées pour un traitement sont bien atteignables par 'navigation' entre les entités/relations du MCD

[modifier] Le MLT modèle logique des traitements

Le MLT appelé aussi MOT (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 : c’est à dire qui fait quoi, où, quand, comment. A un MCT correspond donc généralement plusieurs MLT.

Les notions introduites à ce niveau sont le poste de travail, la phase, la tache 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’utilisateurs du système ( ex : client-web, responsable commercial, responsable des stocks, etc. ).

La phase

La phase est un ensemble d’actions (CF MCT/Opération ) réalisées sur un même poste de travail.

La phase peut être soit manuelle ( ex : confectionner des colis ), soit automatisée et intéractive ( ex : saisie d’un formulaire client ) ou automatisée batch ( ex : production et envoi de tableaux de bord quotidiens dans les boîtes aux lettres électroniques).

La tâche

La tâche est une description détaillée d’une phase automatisée intéractive : spécification de l’interface et du dialogue homme-machine, localisation et nature des contrôles à effectuer, etc.

La procédure

La procédure est un regroupement de phases, équivalent organisationnel des notions d’opération et d’actions conceptuelles, mais se déroulant sur une période de temps homogène.

Des procédures d’origines non conceptuelles peuvent être rajoutées du fait des choix d’organisation retenus ( ex : procédures d’échanges d’informations liées à l’externalisation de certaines activités, prise en compte des questions de sécurité en cas de choix de solution Web, ... )

[modifier] Niveau physique

Les réponses apportées à ce dernier niveau permettent d'établir la manière concrète dont le système sera mis en place.

le Modèle Physique des Données (ou MPD ou MPhD) permet de préciser les systèmes de stockage employés (implémentation du MLD dans le SGBD retenu)
le Modèle Opérationnel des Traitements (ou MOT ou MOpT) permet de spécifier les fonctions telles qu'elles seront ensuite réalisées par le programmeur.

[modifier] Méthode de conduite de projet

Merise édicte également des principes et règles pour la conduite et la gestion de projet.

[modifier] Méta-modèle de Merise pour les données

[modifier] Types de "modèles" (méta-modèles) dits "Entity-Relationship"

P.P.Chen présente la classification suivante des différents modèles "entité-association".

N-aires :
- 1-Avec attributs pour entités et associations
- 2-Avec attributs pour entités seulement
- 3-Sans d'attribut

Binaires :
- 4-Avec attributs pour entités et associations
- 5-Avec attributs pour entitités seulement
  - 51-Avec associations "plusieurs-à-plusieurs"
  - 52-"Sans" association "plusieurs-à-plusieurs"
    - 521-Associations non orientées
    - 522-Associations orientées (avec seulement un "parent", avec un "parent physique" et un "parent logique", avec des parents multiples, par exemple CODASYL)
- 6-Sans attribut: "modèle binaire [ABR74], Entity Set Model, Modèle fonctionnel

Références :

Chen P.P., (editor) "Methodology and tools for database design", North-Holland,1983
Chen P.P."A prelimary framework for E-R models" in CHEN83,pp.19-2
Abrial J.R. "Data semantics", in KLK74
KLI74 Klimbie,K. (editors) "Database management", North-Holland,1974

Merise utilise un "modèle" avec entités, attributs (ou propriétés) et relations (ou associations)

En termes formels, on dira qu'un MCD est un invariant.

On y spécifie des ensembles, des relations dont on donne les propriétés (fonction (totale ou partielle), fonction injective, surjective,relation quelconque). On utilise pour cela des "cardinalités" (appelées en UML, des multiplicités). Il y a 16 cas de relations.

En termes de mathématiques ensemblistes, un attribut est une fonction. Par exemple date_de_naissance est une fonction de l'ensemble Personnes vers l'ensemble Dates, date_de_décès est une fonction partielle de l'ensemble Personnes vers l'ensemble Dates.

Les fonctions (au sens mathématique) sont exprimées par ce qui est appelé "clé" (même sens que celui du "modèle relationnel n-aire" de Codd) et aussi par les "cardinalités" (0-1 pour les fonctions partielles) et (1-1 pour les fonctions totales). Quand la fonction a comme partie gauche un produit cartésien entre entités de types différents (entre plusieurs rectangles), on parle de CIF (Contrainte d'Intégrité Fonctionnelle).

Voir également l'article sur les formes normales.

[modifier] Bibliographie

On ne peut pas parler de MERISE sans au moins citer les trois livres "historiques" (le "vert", le "bleu" et le "rouge") qui décrivent précisément la méthode:

Hubert Tardieu, Arnold Rochfeld, René Colletti (1983). La méthode Merise - Tome 1 Principes et outils. Editions d'organisation (Paris) : 328 p. ISBN 2-7081-1106-X.
Hubert Tardieu, Arnold Rochfeld, René Colletti, Georges Panet, Gérard Vahéee (1985). La méthode Merise - Tome 2 Démarches et pratiques. Editions d'organisation (Paris) : 460 p. ISBN 2-7081-0703-8.
Arnold Rochfeld, José Morejon (1989). La méthode Merise - Tome 3 Gamme opératoire. Editions d'organisation (Paris) : 264 p. ISBN 2-7081-1057-8.

Il est juste aussi d'associer à cette bibliographie minimale, le livre trés accessible d'un des créateurs de la méthode, qui historiquement, a suivi son chemin de son côté