Merise (informatique)
22424
30917846
2008-06-23T13:47:00Z
81.20.209.195
/* Le MCD modèle conceptuel des données */
{{voir homonyme|Merise}}
'''Merise''' (prononcer "Meurise" et non "Mérise") est une méthode d'analyse, de [[Conception de logiciel|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.
== Historique ==
Issue de l'[[analyse systémique]], la méthode Merise est issue des travaux menés par [[Hubert Tardieu]] dans les [[années 1970]] et qui s'inséraient dans le cadre d'une réflexion internationale, autour notamment du [[modèle relationnel]] de [[Edgar Frank Codd]]. Elle est devenue un projet opérationnel au début des [[années 1980]] à la demande du ministère de l'industrie, et a surtout été utilisée en France, par les [[Société de services en ingénierie informatique|SSII]] de ses membres fondateurs ([[Atos Origin|Sema-Metra]], ainsi que par la [[International Business Machines Corporation|CGI Informatique]]) et principalement pour les projets d'envergure, notamment des grandes administrations publiques ou privées.
'''Merise''', méthode spécifiquement française, a d'emblée connu la concurrence internationale de méthodes anglo-saxonnes telles que SDM/S ou Axial. Elle a ensuite cherché à s'adapter aux évolutions rapides des technologies de l'informatique avec MERISE/[[Objet (informatique)|objet]], puis MERISE/2 destinée à s'adapter au [[client-serveur]]. Merise était un courant majeur des réflexions sur une « Euro Méthode » qui n'a pas réussi à percer.
On pourra aussi consulter un [http://uml.developpez.com/faq/merise/?page=GENE#INTRO_Historique historique de Merise sur le site Web Developpez.com].
== Positionnement de la méthode==
La méthode MERISE est une méthode d'analyse, de conception et de réalisation de système d'information informatisé.
En amont, elle se situait dans le prolongement naturel d'un [[Schéma directeur (informatique)|schéma directeur]], souvent conduit suivant la [[méthode RACINES]], très présente notamment dans le secteur public.
Les projets MERISE étaient généralement des projets de grande ampleur de refonte d'un existant complexe, dans un environnement grand système. La méthode a aussi connu des tentatives d'adaptation avec les [[SGBD]] relationnels, les différents interfaces homme-machine [[IHM]], l'[[Orienté objet]], le développement micro, les outils [[CASE]], le [[reverse engineering]]... mais qui n'ont pas connu le même succès.
La méthode est essentiellement franco-française et n'a pas eu beaucoup de succès à l'étranger où les méthodes anglo-saxonnes sont plus présentes.
Elle a un côté très administratif. On passe beaucoup de temps à réfléchir et à pré-documenter avant de commencer à coder la moindre ligne, ce qui pouvait sembler naturel à une époque où les moyens informatiques n'étaient pas aussi diffusés qu'aujourd'hui. Ceci dit elle évite l'écueil inverse du développement micro, qui souffre par le manque de documentation, et où les erreurs sont finalement très coûteuses à réparer a posteriori.
Même si l'aller-retour et la consultation entre concepteurs et utilisateurs est formellement organisée, 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.
L'articulation très codifiée et bien balisée des différentes étapes, avec un descriptif très précis des résultats attendus est ce qui reste aujourd'hui de mieux connu et de plus utilisé.
== Méthode d'analyse et de conception ==
[[Image:MERISE.jpg|thumb|400px|La méthode MERISE 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.<ref>{{cite journal |last = Waldner |first = Jean-Baptiste |authorlink = Jean-Baptiste Waldner |title = CIM, les nouvelles perspectives de la production, Dunod Bordas, 1990 [http://en.wikipedia.org/w/index.php?title=Special:Booksources&isbn=9782040198206] |publisher = [[DUNOD]] |place = Paris |date = 1990| pages = p111 |isbn = 9782040198206}}</ref>]]
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 beaucoup de gens ont voulu y voir un [[Acronymie|acronyme]] comme par exemple ''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 simultanément selon 3 axes pour ''hiérarchiser'' les préoccupations et les questions auxquelles répondre lors de la conduite d'un projet:
* '''Cycle de vie''' : phases de conception, de réalisation, de maintenance puis nouveau cycle de projet.
* '''Cycle de décision''' : des grands choix (GO-NO GO : Étude préalable), la définition du projet (étude détaillée) jusqu'aux petites décisions des détails de la réalisation et de la mise en œuvre du système d'information. Chaque étape est documentée et marquée par une prise de décision.
* '''Cycle d'abstraction''' : niveaux conceptuels, logique/organisationnel et physique/opérationnel (du plus abstrait au plus concret) L'objectif du ''cycle d'abstraction'' est de prendre d'abord les grandes décisions métier, pour les principales activités (Conceptuel) sans rentrer dans le détail de questions d'ordre organisationnel ou technique.
La méthode Merise, très analytique (attention méthode systémique), distingue nettement les données et les traitements, même si les interactions entre les deux sont profondes et s'enrichissent mutuellement (validation des données par les traitements et réciproquement). Certains auteurs (Merise/méga, puis Merise/2) ont également apporté la notion complémentaire de communications, vues au sens des messages échangés. Aujourd'hui, avec les SGBD-R, l'objet, les notions de données et de traitements sont de plus en plus imbriquées.
=== "'''La courbe du soleil'''" ===
La littérature parle 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 [[Technologie bottom-up|bottom-up]]), puis décliner la solution retenue (en partant du niveau conceptuel et revenant au niveau physique : démarche [[Technologie top-down|top-down]]).
À noter que le recensement de l'existant, est aujourd'hui très décrié, car prolonge la durée du projet. Sur ce point, la démarche Merise est à l'opposé des méthodes itératives de type [[Rapid Application Development|RAD]], ou de l'adoption systématique des ''best practices'' observées dans d'autres entreprises du secteur, qui constituent une démarche typique dans l'implémentation de progiciels.
=== Niveau conceptuel ===
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 activités, les métiers gérés par l'entreprise, quels sont les grands [[Processus (gestion de la qualité)|processus traités]], de quoi parle-t-on en matière de données, quelles notions manipule-t-on ?... est-ce indépendamment des choix techniques (comment fait-on ?) ou organisationnels (qui fait quoi ?) qui ne seront abordés que dans les niveaux suivants.
Au niveau conceptuel on veut décrire, après ''abstraction'', 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ée]]s, c'est-à-dire les dépendances ou relations entre les différentes données du [[système d'information]] (par exemple : le client, la commande, la ligne de commande, 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).
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.
==== Le MCD [[modèle conceptuel des données]] ====
Le MCD repose sur les notions d'entité et d'association et sur les notions de relations.
(''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é représente le concept qui se décline, dans le concret en occurrences d'individus.
Exemples :
* (fr, France, Paris, 60,4 millions hab., 550 000 km²), et
* (de, Allemagne, Berlin, 82 537 000 hab., 357 027 km²),
sont deux occurrences de l'entité "pays" et sont constituées de n-uplets de propriétés, 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).
==== 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)
=== Niveau Organisationnel ===
=== Niveau Logique ===
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édure fonctionnelle|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.
==== Le MLD modèle logique des données ====
(é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 :
* MCD
* MLD / Modèle relationnel
PAYS(<u>code_pays</u>)
USINE(<u>id_usine</u>,@code_pays,date_implantation)
EXPORT(<u>@id_usine,@code_pays</u>)
De plus en plus, nous voyons arriver une nouvelle façon d'écrire le modèle relationnel :
PAYS(code_pays)
code_pays : clé primaire de la relation PAYS
USINE(id_usine,code_pays,date_implantation)
id_usine : clé primaire de la relation USINE
EXPORT(id_usine,code_pays)
id_usine + code_pays : clé primaire de la relation EXPORT [concaténation de id_usine et de code_pays]
id_usine : clé étrangère de la relation EXPORT en référence à id_usine de la relation USINE
code_pays : clé étrangère de la relation EXPORT en référence à code_pays de la relation PAYS
Les opérateurs de l'algèbre relationnelle (projection, sélection, jointure, opérateurs ensemblistes) peuvent ensuite directement s'appliquer sur le modèle relationnel ainsi obtenu et normalisé. (Voir [[Langage d'interrogation de données]] et [[Forme normale (bases de données relationnelles)|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.
==== Le MLT modèle logique des traitements ====
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 ? comment ? À un MCT correspond 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 humain-machine, à 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.
=== 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. <br />
*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écification|spécifier]] les fonctions telles qu'elles seront ensuite réalisées par le programmeur.
== Méta-modèle de Merise pour les données==
=== Types de "modèles" (méta-modèles) dits "Entity-Relationship"===
[[Peter 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 entité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 [[Edgar Frank Codd|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).
{{Article connexe|Forme normale (bases de données relationnelles)}}
== 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é
* Yves Tabourier (1986). ''De l'autre côté de Merise''. Editions d'organisation (Paris)
Sur Merise/2, on consultera également :
* Georges Panet, Raymond Letouche (1994). ''Merise/2 - Modèles et techniques avancées''. Editions d'organisation (Paris) : 366 p. ISBN 2-7081-1653-3.
==Références==
{{Références}}
== Voir aussi ==
'''Sur les méthodes d'urbanisation ou de modélisation'''
* [[Urbanisation (informatique)]]
* [[Méta-modèle d’urbanisme]] et ses relations avec les [[objets métiers]]
* [[Unified Modeling Language|UML]]
* [[Formes normales]]
'''Sur la [[gestion de projet]]'''
* [[Gestion de programme]]
* [[Cycle en V]]
== Lien externe ==
* [http://www.commentcamarche.net/merise/concintro.php3 commentcamarche.net] Principe de fonctionnement de la méthode MERISE - initiation à la conception de système d'information.
* [http://merise.developpez.com/ developpez.com] Tutoriels Merise.
{{Portail informatique}}
[[Catégorie:Urbanisation du SI]]
[[Catégorie:Gestion de projet]]
[[Catégorie:Modélisation des données]]
[[Catégorie:Méthode d'analyse et de conception]]
[[es:MERISE]]
[[eu:MERISE]]
[[nl:Merise]]