Initiation à la méthode Merise : Outils conceptuels et organisationnels
Participez au vote ☆☆☆☆☆★★★★★
les modèles conceptuels
MERISE 2
concepts de base
démarche et modèles
Equipe d’analyse
département Informatique
IUT 2 Grenoble
Université Pierre Mendès-France
Merise 2
1
2000/2001
Merise 2
2
2000/2001
Sommaire
Les notes de ce cours sont entièrement issues de différents livres sur Merise cités en
Bibliographie.
1. MERISE/MERISE2 .5
1.1. QUELQUES CHIFFRES .5
1.2. OBJECTIFS MERISE 2 .5
2. NOTIONS DE BASE ..7
2.1. LES SYSTÈMES ..7
2.2. LE SYSTÈME D'INFORMATION ..8
2.3. CONCEPTION D'UN SI 9
Cycle de vie ..9
Différences principales entre Merise et Merise 2 10
Les niveaux d'abstraction ..12
Parcours au sein des niveaux d'abstraction ..13
Un parcours "standard" .14
3. LES MODÈLES 17
3.1. MODÈLE .17
3.2. LES TROIS AXES DE MODÉLISATION DE MERISE 2 ..17
3.3. AXES DE MODÉLISATION ET NIVEAUX D'ABSTRACTION .18
4. MODÈLES CONCEPTUELS 20
5. LES MODÈLES DE FLUX .22
5.1. MODÈLE DE CONTEXTE (MC) ..22
Définition .22
Représentation graphique .22
Concepts associés ..23
Utilisation du modèle ..23
5.2. MODÈLE DE FLUX CONCEPTUELS (MFC) 23
Définition .23
Exemple 24
Concepts associés ..25
5.3. LES CONCEPTS ASSOCIÉS .25
Domaine d'étude .25
Activité ..26
Flux de données ..26
Acteur externe ..26
Domaine connexe 26
5.4. GAMMES OPÉRATOIRES .26
Mécanisme de décomposition .26
Merise 2
1
2000/2001
Mécanisme de composition ..27
Au niveau organisationnel ? 27
6. MODÈLE CONCEPTUEL DE DONNÉES "ÉTENDU" ..29
6.1. VOCABULAIRE 29
Propriété ..29
Objet type (ou individu) ..29
Relation type .29
Cardinalités 29
6.2. LA PROPRIÉTÉ 30
6.3. OBJET, OCCURRENCE D'OBJET ..30
6.4. RELATION .32
6.5. CARDINALITÉS ..33
6.6. CONTRAINTE D'INTÉGRITÉ FONCTIONNELLE 35
6.7. LE PROBLÈME DE LA REPRÉSENTATION DU TEMPS 36
6.8. VÉRIFICATION DU MODÈLE .39
6.9. LA DÉMARCHE 39
Ecole pragmatique .39
Ecole "formelle" (ou plutôt exhaustive) 39
6.10. SOUS-TYPE D'OBJET ET SOUS-TYPE DE RELATION 40
Sous-type d'objet .40
Sous-type de relation 42
6.11. CONTRAINTES D'INTÉGRITÉ STATIQUE ..42
6.11.1. Contraintes de base : couverture et disjonction ..42
6.11.2. Contraintes d'intégrité entre les sous-types d'objets .43
6.11.3. Contraintes d'intégrité sur les relations ..45
7. LES MODÈLES DYNAMIQUES 49
8. MODÈLE CONCEPTUEL DES TRAITEMENTS (MCT) 49
8.1. VOCABULAIRE DE BASE 49
Evénement ..49
Opération 50
Résultat .50
Synchronisation ..50
8.2. EVÉNEMENT 50
8.3. SYNCHRONISATION .51
8.4. OPÉRATION ..51
8.5. LE PROCESSUS 53
8.6. LA CONSOMMATION 56
9. MODÈLE CONCEPTUEL DES TRAITEMENTS ANALYTIQUE (MCTA) .58
9.1. OPÉRATION CONCEPTUELLE ..58
9.2. ETAT D'OBJET .59
9.3. ACTION ..61
9.4. CONDITION SUR LES ACTIONS 64
Condition de Déclenchement ..64
Condition Itérative .65
9.5. EVÉNEMENT INTERNE 65
9.7. PASSAGE DES MODÈLES DE FLUX AU MCTA 67
10. LES CYCLES DE VIE DES OBJETS ..68
10.1. INTRODUCTION 68
Merise 2
2
2000/2001
Evénement et Transition .68
Représentation graphique et exemple partiel 68
Objectifs 68
Commentaires MCTA / CVO 69
10.2. LES PRINCIPALES TRANSITIONS .69
Séquence ..69
Alternative ..69
Itération 69
10.3. ETAT D'OBJET ..70
Le CVO d'un objet comporte : 70
Les états d'un objets sont identifiés à partir : 71
Etats d'objets et sous-types 73
10.4. SPÉCIALISATION DE CVO .73
10.5. VARIABLES D'ÉTAT ET STRUCTURES PARALLÈLES .73
Variables d'état et structures parallèles 73
Les différents cas de structures parallèle .74
10.6. VÉRIFICATION ET ELABORATION DES CVO 77
Règles de vérification ..77
Enchaînement des modèles (cf. page suivante) .77
Démarche pratique 77
11. BIBLIOGRAPHIE ..81
Merise 2
3
2000/2001
Merise 2
4
2000/2001
Merise 2
1. Merise/Merise2
1.1. Quelques chiffres
- premier contrat de recherche en 1974
- premier ouvrage en 1983
- aujourd'hui 50 000 praticiens et plus de 40 ouvrages
- démarrage du projet Merise 2 en 1989 (Sema Group)
1.2. Objectifs Merise 2
- fournir un ensemble complet de démarches, modèles et méthodes pour la conception et le
développement de SI
- conserver une compatibilité totale avec Merise
- amélioration de certains points clés :
technique de raffinement
intégration des diagrammes de flux de données
enrichissement de la sémantique du modèle de données
représentation du cycle de vie du système et des objets
meilleure distinction entre les niveaux organisationnel et logique
- extension vers des aspects techniques
prise en compte des nouvelles architectures d'applications
prise en compte des nouvelles interfaces
- adaptation aux standards en cours de définition
démarche et modèles choisis en fonction des types de projets
- outillage par des logiciels d'aide à la conception et au développement
Merise 2
5
2000/2001
Merise 2
6
2000/2001
2. Notions de base
2.1. Les systèmes
Système : "un tout constitué d'éléments unis par des relations, ces éléments et ces relations
étant munis de propriétés"
Exemple : le système "d'entreprise" est composé d'éléments tels que des employés, des
services, des articles, des emplacements de stockage Les propriétés décrivant ces éléments sont
le matricule de l'employé, son nom, la référence de l'article.. Entre ces éléments on trouve des
relations telles que "est rattaché" entre un employé et un service, "est stocké" entre un article et
un emplacement de stockage Les propriétés de ces relations sont la date d'entrée dans le
service, la quantité stockée
Etat d'un système : l'ensemble des valeurs, à un moment donné, des propriétés des éléments
et des relations du système.
Un système vit dans un environnement. Il subit de cet environnement des stimuli qui
viennent le perturber et l'obligent à réagir c.a.d à déclencher des activités qui vont le faire
évoluer vers un nouvel état.
Système : "un tout constitué d'éléments unis par des relations, doté d'une activité et répondant
à des stimuli".
entreprise
état 1
rejet
commande
réaction
ou
client
livraison
entreprise
état 2
Figure 1 : réactivité du système
L'environnement n'est pas toujours "l'extérieur". Par exemple le processus "expédition" subit
une perturbation sous la forme d'un bordereau d'expédition en provenance du processus
"traitement de commandes".
Le Moigne propose en 1977 de définir un système comme :
- quelque chose (n'importe quoi, identifiable)
- qui fait quelque chose (activité, fonction),
- qui est doté d'une structure,
- qui évolue dans le temps,
- dans quelque chose (environnement),
- pour quelque chose (finalité).
Merise 2
7
2000/2001
2.2. Le système d'information
Le concept de SI d'une organisation recouvre deux notions:
• l'organisation réelle se transformant, agissant, communiquant et mémorisant des informations,
notion qui apparente le SI à un objet naturel
• le système construit par l'homme pour représenter les actions, la communication et la
mémorisation de l'information, notion qui apparente le SI à objet artificiel.
conception
système
système
d'information
d'information
naturel
artificiel
intégration
Figure 2 : le SI réel le SI artificiel
système d'information / système informatisé / système informatique
Une partie du S. d'information peut être (doit être) informatisé (le S. informatisé). Le système
informatisé s'appuie sur un S. informatique (matériel, logiciel, réseau..)
S. d'Information
S. Informatisé
S. Informatique
Figure 3 : S. Informatique/S. Informatisé/S.
d’Information
Le schéma systémique de l'entreprise :
Le SI est avant tout un véhicule de communication dans l'entreprise et entre l'entreprise et son
environnement. Au sein de l'entreprise on distingue:
• le système opérant chargé de la production (chaîne de fabrication, atelier d'assemblage, etc.),
• le système de pilotage dirigeant l'entreprise et maintenant les objectifs (directeur, chef de
service, etc.),
Merise 2
8
2000/2001
• le système d'information assurant le lien entre les deux précédents. Il informe le système de
pilotage des performances du système opérant. Inversement il transmet au système opérant les
instructions du système de pilotage.
S. de Pilotage
coordination, objectifs
décisions
informations
info. vers
informations
traitées
l'extérieur
externes
S. d'Information
mémorisation
informations
col ectées
flux sortant
flux entrants
S. Opérant
production
Figure 4 : S. Opérant / S. d’Information / S. de
Pilotage
Les principes de la méthode Merise sont essentiellement applicables à la partie opérante : ils
permettent une bonne appréhension de la gestion courante (gestion de la production, des stocks,
facturation ), plutôt que la gestion de “ pilotage ” (états statistique, historiques, plans long
terme ).
2.3. Conception d'un SI
Cycle de vie
Tout projet est mené dans le cadre d'une démarche par étapes, appelée cycle de
développement ou cycle de vie. Ce cycle se situe sur une échelle de temps qui part de l'étude de
l'objet naturel à l'intégration du système artificiel dans l'objet naturel.
La partie cycle de vie prise en compte par Merise est découpée en quatre périodes : la
conception (descriptions détaillées des spécifications fonctionnelles), la réalisation (description
logique et physique des données, production des programmes et des consignes d'utilisation ), la
mise en oeuvre (mise en place effective du système dans son environnement réel) et la
maintenance du système (adaptation du système aux évolutions de l'entreprise).
maintenance
SI
mise en oeuvre
objet naturel
conception
SI
objet artificiel
réalisation
Figure 5 : cycle de vie du SI
Merise 2
9
2000/2001
Plus finement (Figure 6) on distingue :
• le Schéma Directeur : définition des domaines d'étude, planification du développement de
chaque domaine. Il fixe les moyens en personne, machine S'il n'y a pas de schéma directeur
récent une Etude d'Opportunité est nécessaire.
• l'Etude Préalable : elle permet de déterminer le domaine sur lequel porte le projet, les
structures concernées et l'organisation des postes de travail. Elle décrit les circuits de
l'information et les procédures, en précisant pour chacune d'elle sa nature et son degré
d'automatisation. Elle définit également les moyens informatiques à mettre en oeuvre, les
coûts, les délais des différentes étapes de l'étude détaillée. Elle porte sur un sous-ensemble
représentatif du système de manière à permettre aux dirigeants de prendre des décisions sur la
globalité du projet. L'objectif est ici de définir la mission, d'établir un diagnostic de l'existant et
de proposer de nouvelles orientations de gestion, d'organisation et technique. L'étude préalable
peut être décomposée en trois étapes : un recueil se soldant par un bilan de l'existant, une
conception permettant de préciser les nouvelle orientations de gestion, d'organisation et
technique et une appréciation permettant en particulier de planifier la suite du projet.
• l'étude détaillée : elle détermine les spécifications fonctionnelles en respectant les solutions
retenues à l'issue de l'étude préalable. Elle se scinde en deux étapes : la conception globale ou
Conception d'Ensemble (Merise 2) et la conception détaillée ou Conception Fonctionnelle
Détaillée (Merise 2).
• la réalisation. Elle se scinde en deux étapes : Conception Technique Détaillée (Merise 2)qui
détermine les descriptions logique et physique des données, l'architecture des programmes,
etc., la Réalisation proprement dite qui aboutit à production des programmes et comporte les
tests unitaires et les tests d'intégration.
• Préparation de la Mise en Oeuvre et Mise en Oeuvre : concerne la préparation de la
nouvelle organisation en particulier la conduite du changement et les supports de formation. La
mise en oeuvre proprement dite concerne davantage le basculement des données et les
changements de logiciels.
• Maintenance : adaptation du système aux évolutions de l'entreprise
Les trois premières étapes correspondent à la conception du système, les suivantes concernent
sa réalisation et son lancement.
Différences principales entre Merise et Merise 2
Le cycle de référence de Merise 2 propose un découpage légèrement plus fin que le découpage
initial de Merise.
• Il sépare en deux étapes distinctes le Conception d'Ensemble et la Conception Fonctionnelle
détaillée. Dans Merise ces deux étapes étaient appelées Etude Détaillée.
• Il propose une nouvelle phase la Conception Technique Générale, définie lors de la Conception
d'Ensemble. En effet, la plupart des choix techniques sont généralement faits à l'issus de cette
étape.
• Il sépare la Préparation de la Mise en Oeuvre de la Mise en Oeuvre proprement dite.
Merise 2
10
2000/2001
ETAPES
DECISIONS PRINCIPALES
lancement d'un schéma directeur ?
Schéma
Etude
directeur
d'Opportunité
Dossier de SD
Dossier d'EO
accord sur
accord
l'inscription
sur la cible et
du projet
Etude Préalable
plans annuels
Dossier d'EP
choix d'une solution conceptuelle,
organisationnelle et technique
Préparation
Conception
justification du projet
Mise
d'Ensemble
en
Oeuvre
accord sur les règles de gestion,
Dossier de CE
les procédures, l'architecture globale
Conception
Fonctionnelle
Détaillée
Dossier de CFD
accord sur les fonctions et
interfaces utilisateurs
Conception
Technique
Détaillée
Dossier de CTD
accord sur l'architecture
technique détaillée
Réalisation
organisation
réception du logiciel
logistique
logiciel
réception de la logistique
Mise en Oeuvre
et de l'organisation
Système
réception du système
Maintenance
Figure 6 : cycle de vie détaillé
Le cycle de référence (Figure 6) est un cycle générique, à adapter aux types de projets et aux
standards de l'entreprise. Il est par exemple possible de regrouper des étapes pour retrouver le
cycle Merise. Certaines étapes sont parfois inutiles. Par exemple dans le cadre d'un "petit projet"
la distinction entre Conception d'Ensemble et Conception Fonctionnelle Détaillée est inutile.
Merise 2
11
2000/2001
Les niveaux d'abstraction
La conception d'un SI se fait en utilisant des modèles permettant de représenter les données
(aspects statiques) et les traitements (aspects dynamiques) du futur système.
Les niveaux d'abstraction ont pour but de permettre une modélisation progressive, par niveaux
de préoccupation. Ces niveaux sont au nombre de 4.
• Niveau conceptuel
La description conceptuelle du système permet de représenter sa raison d'être et sa finalité en
s'appuyant sur ses objectifs et les réalités qui le contraignent. Il s'agit dans un premier temps de
décrire les règles de gestion qui permettront l'élaboration des modèles conceptuels de données et
de traitements. Une règle de gestion traduit un objectif prioritaire sans se soucier de la
manière de le mettre en œuvre.
Exemple intuitif : considérons les carrefours d'un système routier
Règles de gestion : - le système assure une circulation fluide des véhicules
- il s'agit d'éviter au mieux les collisions
Ces règles traduisent les deux objectifs primordiaux (fluidité de la circulation et limitation des
collisions).
• Niveau organisationnel
La description organisationnelle du système représente l’organisation permettant d’atteindre
les objectifs définis au niveau conceptuel. Il s'agit donc de décrire le fonctionnement du SI dans
le cadre d'une organisation cible. Les descriptions du niveau organisationnel pour les traitements
et les données ne préfigurent pas des moyens à mettre en oeuvre pour y parvenir.
La description organisationnelle permet de décrire les vues partielles du système pour chaque
type d'acteur par site de l'organisation. Il s'agit de décrire D'OU sont visibles les données et les
traitements, QUI fait quoi en matière de données et de traitement, QUAND réalise-t-on les
traitements et manipule-t-on les données.
Exemple intuitif :
Règles d'organisation : le système alterne les flots de circulation, en autorisant un passage en
séquence dans une durée limitée des véhicules des différents axes.
• Niveau logique
Le niveau logique concerne la conception du logiciel correspondant aux parties à automatiser
du système. Il prend en compte l'état de l'art technique général plutôt que les aspects physiques
dans un contexte particulier. Il inclue une description logique des données c'est à dire une
description dans un formalisme compatible avec l'état de l'art (modèle relationnel, modèle objet,
fichiers, etc.) mais encore portable par rapport à des choix techniques précis. Il inclue également
des modèles logiques de traitements décrivant le guidage fonctionnel, les boites de dialogue,
l'arborescence des fenêtres
Exemple intuitif : L'alternance sera assurée à l'aide de signaux lumineux, placés sur chaque
axe de circulation
Merise 2
12
2000/2001
• Niveau physique
le niveau physique tient compte des préoccupations et des choix techniques nécessaires à
l'implantation physique des données et à la mise en place des traitements : langage de
programmation, choix du SGBD, taille mémoire, etc.
Le passage de l'état ancien du système à l'état futur lors d'étapes de conception (en
particulier lors de l' étape de conception de l'étude préalable) doit obligatoirement se faire par le
niveau conceptuel, qui décrit l'invariant de l'entreprise. Toute étude qui proposerait des
évolutions techniques non justifiées aux niveaux conceptuel et organisationnel est à proscrire.
état ancien
état futur
conceptuel
organisationnel
logique
physique
Figure 7 : évolution du SI / niveaux
d’abstraction
Chaque niveau d'abstraction offrent une panoplie de modèles.
Chaque étape du cycle de vie d'un projet nécessite de s'intéresser :
• à un ou plusieurs niveaux d'abstraction,
• en utilisant un ou plusieurs modèles offerts par chaque niveau d'abstraction.
Parcours au sein des niveaux d'abstraction
Pour un projet donné il s'agit de fixer :
• La démarche. Par exemple, certaines étape du cycle de vie peuvent être "fusionnées" dans le
cas de "petits projet".
• Le choix des modèles de différents niveaux d'abstraction qui seront utilisés lors de chaque
étape.
Le parcours au sein de ces niveaux d'abstraction lors des différentes étapes d'un projet
d'informatisation est appelé cycle d'abstraction et est schématisé par une courbe dite "courbe
du soleil".
Merise 2
13
2000/2001
Le processus est itératif, de plus suivant l'étape de la démarche dans laquelle on se trouve, la
description d'un niveau d'abstraction peut être :
• plus ou moins détaillée (technique d'affinement)
• sur une couverture plus ou moins large du domaine (Sous Ensemble Représentatif : SER)
Le niveau de détail augmente au fur et à mesure que l'on progresse dans les étapes.
COUVERTURE
PREOCCUPATION
DETAIL
Figure 8 : courbe du soleil
Un parcours "standard"
A titre purement indicatif les indications suivantes peuvent permettre de suivre une démarche
cohérente:
• Etude Préalable.
Si l'on part d'un existant, il s'agira de décrire le fonctionnement actuel (niveau
organisationnel) de manière à en déduire une représentation conceptuelle (en tirer l'essentiel et
l'incontournable). La conception du futur système partira du niveau conceptuel approuvé et
validé par le client. Une étude préalable devant être courte mais complète, il s'agira alors de
concevoir les niveaux organisationnel, logique et même éventuellement physique ( prototype)
d'un Sous Ensemble Représentatif (couverture limitée) du domaine à automatiser à un niveau de
détail qui peut rester sommaire.
• Etude Détaillée.
Il s'agit de décrire les niveaux conceptuel et organisationnel (spécifications fonctionnelles) sur
l'ensemble du projet. Au niveau de la conception d'ensemble le niveau de détail n'est pas encore
très fin. Par exemple les données nécessaires à chaque procédure sont encore globalisées dans un
modèle de données général. Les caractéristiques de moyens humains et matériels à mettre en
oeuvre ne sont pas forcément abordées. Au niveau de la conception fonctionnelle détaillée les
niveaux conceptuel et organisationnel doivent être entièrement décrits (niveau de détail le plus
fin sur toute la couverture du projet).
Merise 2
14
2000/2001
• Réalisation
Il s'agit de se focaliser sur les parties à automatiser. On commencera (conception technique
détaillée) par établir une description logique des données et des traitements. Puis une description
physique des données. A l'issue de la conception technique détaillée la réalisation proprement dit
aboutit à la production de programmes.
ETAPES
niveau d'abstraction
Schéma
Etude
directeur
d'Opportunité
Dossier de SD
Dossier d'EO
Etude Préalable
Dossier d'EP
tous les niveaux
couverture limité
Prépar.
niveau de détail faible
Conception
Mise
d'Ensemble
en
Oeuvre
Dossier de CE
niveaux conceptuel et organisationnel
couverture : tout le projet
Conception
niveau de détail moyen
Fonctionnelle
Détaillée
niveaux conceptuel et organisationnel
Dossier de CFD
couverture : tout le projet
niveau de détail fin
Conception
Technique
Détaillée
niveau logique et physique
Dossier de CTD
couverture : tout
niveau de détail fin
Réalisation
organisation
logistique
logiciel
Mise en Oeuvre
Système
Maintenance
Figure 9 : parcours standard
Merise 2
15
2000/2001
Merise 2
16
2000/2001
3. Les modèles
3.1. Modèle
Un modèle est une représentation abstraite de la réalité. Par exemple une carte routière est une
représentation abstraite de routes, un plan d'architecture est une représentation abstraite d'un
bâtiment, etc. Les définitions du concept de modèle sont nombreuses :
• Weinberg
"Le modèle, c'est l'expression de quelque chose que nous cherchons à appréhender, représentée en
des termes que nous pensons comprendre"
• Douglas Ross
" M modélise A si M répond à des questions concernant A"
• Minsky
" Pour un opérateur O, un objet M est un modèle d'un objet A dans la mesure où O peut utiliser M
pour répondre aux questions qui l'intéressent au sujet de A"
Donc un modèle doit :
- correctement représenter la pensée du modéliseur,
- permettre de communiquer sans ambiguïté.
Pour ce faire il s'agit d'offrir des formalismes précis et normalisés pour modéliser les
différents éléments (données et traitements) des systèmes d'information et ceci aux différents
niveaux d'abstraction.
Par abus de langage nous utiliserons le mot "modèle" pour parler aussi bien des formalismes
que de leur utilisation. C'est le contexte qui précise le sens. Lorsque nous parlerons par exemple,
de modèles de données il s'agit du formalisme utilisé pour modéliser des données. Quand nous
parlerons du modèle de donnée du domaine vente. Il s'agit de son utilisation pour modéliser les
données concernées par le domaine "vente".
3.2. Les trois axes de modélisation de Merise 2
Merise 2 propose une démarche globale de modélisation basée sur 3 axes de modélisation
(Figure 10 : Trois axes de modélisation) :
• l'axe d'architecture ou fonctionnel qui permet de décrire ce que fait le système (les activités) ;
• l'axe statique qui permet de décrire ce qu'est le système (les données) ;
• l'axe dynamique ou comportemental qui permet de décrire comment se comporte le système
(les processus et la succession de transformations effectuées sur les données).
Merise 2
17
2000/2001
Exemple : On s'intéresse au traitement des commandes.
Dans ce cadre on distinguera plusieurs activités telles que le traitement de la commande, la
facturation et la livraison. Ces activités décrivent les aspects fonctionnels du système (sous-
système). Les aspects statiques correspondent à la représentation des données mises en jeu :
informations sur les clients, les articles, les commandes, etc. Enfin les aspects comportementaux
correspondent à la représentation du comportement du système lors de l'arrivée d'événement et
l'impact sur les données. Par exemple l'arrivée d'une commande va déclencher la création d'une
nouvelle commande.
Architecture
faire
Statique
Dynamique
Etre
se comporter
Figure 10 : Trois axes de modélisation
3.3. Axes de modélisation et niveaux d'abstraction
Merise 2 offrent différents modèles permettant de représenter les aspects statique,
fonctionnel (architecture) et dynamique d'un système et ceci à différents niveaux d'abstraction :
conceptuel,organisationnel et logique (Figure 11 : les modèles de Merise 2). Les modèles
physique ne font pas partie de la méthode (et pour cause). Par rapport à Merise, Merise 2
propose de nouveaux modèles (modèle de flux par exemple) et établit une distinction beaucoup
plus claire entre les modèles organisationnels et les modèles logiques.
INTERFACE APPLICATION
STATIQUE
DYNAMIQUE
ARCHITECTURE
MCD
MCTA
quoi
MC
MFC
CVO
d'où
qui
MOTA
MO T MOD
MFO
quand
CVO
MLT
SALMI, SAL
où
Maquettes
MLD
comment
IHM
MLDr
MLTr
SALR
est
se comporte
fait
Figure 11 : les modèles de Merise 2
Merise 2
18
2000/2001
• Modèle de Contexte (MC)
• Modèle Conceptuel des Données (MCD)
• Modèle Conceptuel des Traitements Analytique (MCTA)
• Cycle de Vie des Objets (CVO)
• Modèle de Flux Conceptuel (MFC)
+ Règles de Gestion
• Modèle Organisationnel des Traitements (MOT)
• Modèle Organisationnel des Données (MOD)
• Modèle Organisationnel des Traitements Analytique (MOTA)
• Modèle de Flux Organisationnel (MFO)
+ Règles d'Organisation
• Modèle Logique des Données (MLD)
• Modèle Logique des Données Réparties (MLDr)
• Modèle Logique des Traitements (MLT)
• Modèle Logique des Traitements Répartis (MLTR)
+ Primitives
Ces modèles sont complétés pour les études d'architectures techniques complexes par les
modèles suivants :
• Schéma d'Architecture Logique des Moyens Informatiques (SALMI)
• Schéma d'Architecture Logique (SAL)
• Schéma d'Architecture Logique Répartie (SALr)
Suivant le type de projet et l'étape du cycle de vie, il convient de sélectionner une partie de ces
modèles.
Exemple : Dans le cas d'un "petit projet" (quelques hommes/mois, pas de répartition, logiciel
classique) on ne développera que les MC, MFC, MCD, MCTA, CVO, MLD, MLT, maquettes.
Rappel : Ces modèles peuvent être élaborés à différents niveaux de détail, sur une couverture
partielle ou totale du domaine d'étude et s'inscrivent dans une démarche itérative ("courbe du
soleil").
Merise 2
19
2000/2001
4. Modèles Conceptuels
La description conceptuelle permet de représenter la finalité du système et sa raison d'être, en
s'appuyant sur ses objectifs et les réalités externes qui le contraignent. Elle s'appuie sur un
ensemble de Règles de Gestion qui décrivent le "quoi" de l'entreprise. Une Règle de Gestion est
une traduction conceptuelle des objectifs choisis et des contraintes acceptées par l'entreprise. La
plupart du temps il s'agit de règles d'actions liées aux traitements ou de règles de calcul liées aux
données.
Exemples : "un inventaire doit être dressé périodiquement"
" tout produit livré sera entré en stock"
"la centrale d'achat sera libre d'imposer des jours de commandes"
"le salaire de base est égal à l'indice multiplié par la valeur du point"
Attention : l'analyste n'a aucune initiative sur les règles de gestion, son unique rôle est
de les trouver (interview), les faire valider puis les utiliser pour élaborer les différents
modèles conceptuels.
Le niveau conceptuel traite des événements et fournit des résultats sans se soucier de la
manière dont sont acquises et restituées les informations portées par ces événements et résultats.
NIVEAU CONCEPTUEL
ACQUISITION
MEMOIRE
TRAITEMENTS
MEMOIRE
TRANSITOIRE
PERMANENTE
RESTITUTION
EVENEMENTS
OPERATIONS
ENTITES
RESULTATS
Figure 12 : niveau conceptuel
Les différents modèles proposés sont :
• le Modèle de Contexte (MC) et les Modèles de Flux Conceptuels (MFC)
• le Modèle Conceptuel des Données (MCD)
• le Modèle Conceptuel de Traitements (MCT), le Modèle Conceptuel des Traitements
Analytique (MCTA) et les Cycles de Vie des Objets (CVO)
Merise 2
20
2000/2001
MC, MFC
Faire
ACTIVITES
architecture
MCT
Se comporter
Etre
MCD
MCTA
STRUCTURE
COMPORTEMENT
CVO
statique
dynamique
Figure 13 : Les 3 axes de modélisation / les
modèles
Ces modèles peuvent être élaborés à différents niveaux de détail, sur une couverture plus ou
moins grande et s'inscrivent dans une démarche itérative (tranche de la courbe du soleil).
MFC
MCD
MCTA
CVO
Figure 14 : démarche itérative
Les principales évolutions par rapport à Merise sont :
• l'utilisation des MFCavec des techniques d'affinement (refinement),
• la modification des modèles de traitement (MCT-> MCTA),
• l'extension du MCD,
• l'introduction des CVO.
Merise 2
21
2000/2001
5. Les Modèles de Flux
Un modèle de flux est une représentation des mouvements de données à l'intérieur d'un
système d'information et entre ce système et son environnement. Il permet de décomposer le
système en sous-systèmes et de formaliser les flux d'informations entre les sous-systèmes.
L'utilisation du modèle de flux permet de décrire la cartographie du système sans en étudier
son comportement. Il permet de choisir les activités qui pourront au mieux résoudre un problème
sans se soucier du comportement du système (ordonnancement, synchronisation ).
Les modèles de flux sont hérités des méthodes d'origine anglo-saxonne, ils ont été intégrés
dans Merise 2.
Au niveau conceptuel, on distingue deux types de modèles de flux :
• le Modèle de Contexte (MC),
• le Modèle de Flux Conceptuel (MFC).
5.1. Modèle de Contexte (MC)
Définition
Le MC détermine le domaine d'étude et ses échanges avec l'environnement. Il peut être
assimilé au Modèle de Flux de niveau 0.
Représentation graphique
Acteur
externe 1
DOMAINE DE
flux
L'ETUDE
Acteur
externe 2
Domaine
connexe 1
Figure 15 : Modèle de Contexte
Exemple
Merise 2
22
2000/2001
demande d'achat
proposition
DOMAINE
client
commande
VENTE
facture
produit
règlement
facture acquittée
Figure 16 : Modèle de Contexte du domaine Vente
Concepts associés
domaine d'étude, acteur externe, domaine connexe, flux (agrégat de flux) de données
Utilisation du modèle
• au démarrage de l'étude : pour déterminer le domaine d'étude (correspondant la plupart du
temps à un domaine fonctionnel) ;
• en fin d'analyse du système actuel : pour déterminer les activités existantes ;
• au début de l'analyse du système futur : pour préciser les contours du domaine d'étude.
5.2. Modèle de flux Conceptuels (MFC)
Définition
Un MFC détermine, par affinages successifs les activités du domaine d'étude sans décrire leur
comportement.
Il correspond à une structure hiérarchique de diagrammes de flux, à partir du niveau 1.
On appelle diagramme de flux 1 (DFD1), le diagramme de 1er niveau décrivant les macros
activités du domaine d'étude et les flux échangés.
On appelle diagramme de flux (DFDi), tout diagramme qui affine une activité.
Merise 2
23
2000/2001
MODELE DE CONTEXTE
MODELE DE FLUX
DF1
DF2 DF2
DF3 DF3
Figure 17 : Le Modèle de Flux Conceptuel
Exemple
demande d'achat
proposition
proposer
double proposition
client
commande
facture
vendre
produit
règlement
facture acquittée
Figure 18 : diagramme de flux de niveau 1
Merise 2
24
2000/2001
vendre
commande
produit
gestion des
commandes
facture
client
double facture
règlement
facture acquittée
gestion des
règlements
Figure 19 : diagramme de flux de niveau 2
Le MFC et les DFD complètent donc le MC par la description des activités du domaine
recevant et générant les flux externes. Généralement établis sur deux niveaux, ils peuvent en
comporter plus : la décomposition s'arrêtant lorsque les activités décrites correspondent aux
processus ou aux opérations conceptuelles (cf. MCT et MCTA). En effet lors de la construction
du Modèle Conceptuel de Traitement (Analytique) nous verrons que les événements remplacent
les flux et que les opérations ou les processus remplacent les activités.
Concepts associés
les activités, les flux de données, les acteurs externes, les domaines connexes
5.3. Les concepts associés
Domaine d'étude
Un Domaine d'étude est un sous-ensemble cohérent de l'entreprise ou de l'organisme, bien
délimité et formant le contenu à étudier. Il regroupe toutes les activités concernées par l'étude.
Il est:
• déterminé plus ou moins arbitrairement au démarrage de l'étude,
• précisé en fin d'analyse du système actuel,
• modifié éventuellement au début de l'analyse du système futur par la suppression ou l'ajout
d'activités.
Il doit:
• correspondre à un projet de taille réaliste,
Merise 2
25
2000/2001
• être informatiquement opérationnel indépendamment du développement sur les autres
domaines,
• minimiser les perturbations dans l'organisation lors de sa mise en place,
• minimiser les conséquences des choix organisationnels et techniques sur les autres domaines.
Activité
L'activité est un ensemble de traitements homogènes qui transforment ou manipulent des
données.
L'activité est le concept sur lequel se concentre la décomposition du Modèle de Flux. Une
activité du diagramme que l'on veut affiner devient le limite du diagramme de Flux de niveau
inférieur. La décomposition d'une activité doit être indépendante des autres, mais peut par contre
entraîner la décomposition des flux entrants et sortants.
Flux de données
Un flux de données est la représentation d'un échange d'informations entre deux composants
du système ou entre un composant du système et un système extérieur. Un flux de données peut
mettre en jeu des échanges de données informatisées, vocales, écrites, etc. mais aussi des flux
physique de matières.
flux
acteur externe
activité
domaine connexe
acteur externe
non
oui
non
activité
oui
oui
oui
domaine connexe
non
oui
non
Figure 20 : flux de données
Acteur externe
L'acteur externe est une source ou une destination des données située dans l'environnement du
système étudié. Il peut s'agir d'un service, d'une personne, d'un profil, etc.
Domaine connexe
Un domaine connexe est un composant du SI opérationnel ou de pilotage, interagissant avec
le domaine étudié.
5.4. Gammes opératoires
Mécanisme de décomposition
Le niveau d'arrêt de la décomposition correspond au moment où l'activité représente une
opération (au sens Merise) et donc vérifie la règle d'ininterruption (cf. MCT et MCTA). Une
Merise 2
26
2000/2001
activité est ininterruptible si son exécution ne peut être suspendue par l'attente d'un flux
d'information.
Dans la Figure 19 par exemple l'activité Gestion des commandes est exécutée sans
interruption dès l'arrivée d'une commande et se termine par l'émission des flux résultats (produit
et facture). A partir de ce moment, il devient nécessaire de passer à la modélisation dynamique
du système (cf. MCT) où nous verrons qu'une activité pourra être décomposée en plusieurs
opérations conceptuelles si des interruptions temporelles le nécessitent.
On peut également s’arrêter un “ cran ” avant c’est à dire au moment où les activités
représentent des processus.
Mécanisme de composition
Ce mécanisme peut être utilisé suite à une analyse de l'existant, dans le but d'architecturer le
domaine d'étude de manière homogène.
Deux approches :
- par les objectifs en regroupant des activités qui participent à la même finalité opératoire,
- par les données en utilisant des matrices activités/objets par exemple.
Au niveau organisationnel ?
Au niveau organisationnel les MFO préciseront l'organisation des échanges d'informations
(les sites, les postes, les supports d'échanges par exemple un courrier, un transfert informatique,
un coup de téléphone ).
Merise 2
27
2000/2001
Merise 2
28
2000/2001
6. Modèle Conceptuel de Données "étendu"
Le Modèle Conceptuel de Données est une représentation statique du système d'information
de l'entreprise. Au niveau conceptuel il s'agit de modéliser les données fondamentales de
l'entreprise (les invariants décrits par des règles de gestion). Il ne doit être fait aucune hypothèse
sur l'utilisation ultérieure de ces données.
Le Modèle Conceptuel de Données "étendu" (Merise 2) apporte des extensions au formalisme
individuel adopté par Merise.
Ces extensions ont pour objectifs :
• de préciser et d’enrichir la description des objets en mettant en évidence des propriétés, des
contraintes d'intégrité supplémentaires et des objets historiques,
• d’aider la validation du modèle de traitement (MCTA),
• de permettre à différents utilisateurs de partager le même modèle (accès à différents niveaux de
décomposition ou de spécialisation),
• de permettre une relative stabilité par rapport aux évolutions de l'entreprise ou de l'application
(une modification de détail laissant les niveaux supérieurs inchangés).
Nous commencerons par décrire le MCD originel, puis les extensions proposées dans Merise 2.
Le formalisme Merise est conforme au modèle individuel (Entity-Relationship Approach).
6.1. Vocabulaire
Propriété
information élémentaire, conforme au choix de gestion de l'entreprise (adresse d'un client,
référence d'un article, prix d'achat..).
Objet type (ou individu)
regroupement de propriétés, reflet d'une entité présentant un intérêt pour le système étudié,
doté d'une existence propre et identifiable (par exemple Article doté des propriétés libellé, prix
unitaire, nature et identifié par sa référence).
Relation type
représente une association entre plusieurs objets; son existence est conditionnée par celles de
objets mis en relation (par exemple la relation "commander" entre client et commande).
Cardinalités
indiquent pour chaque couple objet-relation les nombres minimum et maximum de valeurs de
la relation pouvant exister pour chaque valeur d'objet.
Par exemple, dans la relation "commander" entre client et commande les cardinalités du
couple client-commander sont (0,n) si un client peut exister comme prospect, il peut ne pas avoir
Merise 2
29
2000/2001
passer de commandes, d'autre part un client peut avoir n commandes, les cardinalités du couple
commande-commander sont (1,1) une commande intervient dans une et une seule relation car
elle concerne un et un seul client.
objet ou individu
nom de
COMMANDE
CLIENT
l'objet
Numcommande
Numclient
liste de
Nomclient
propriétes
Datecommande
Adresseclient
(identifiant
en tête et
1,1
souligné)
1,n
0,n
nom de la
relation
COMMANDER
CONCERNE
relation
quantitécommandée
ARTICLE
0,n
Numarticle
Libellearticle
propriété
Prixunitaire
cardinalités
Statutarticle
Figure 21 : notions de base du MCD
6.2. La Propriété
La propriété correspond à la plus petite partie logique d'information manipulée dans
l'entreprise, il peut s'agir d'une propriété simple comme une référence ou un nom, mais aussi
d'une propriété composée comme une date ou une adresse. Le degré d'atomisation est fonction
de l'application. Si l'on s'intéresse à la gestion courante d'un fichier d'adresse il faudra éclater
l'adresse en plusieurs propriétés (num, rue, code postal, ville).
Il faut autant que possible :
• éviter les propriétés calculables et redondantes,
• faire la chasse aux synonymies (référence article et num de produit) et aux polysèmes (préciser
s’il s’agit de l’adresse du client ou celle du fournisseur).
6.3. Objet, Occurrence d'objet
L'objet est un regroupement de propriétés (ou attributs). Il est le reflet d'une entité de
l'organisme dotée d'une existence propre. Il est identifiable et ne doit représenter qu'un seul
concept sémantique.
Merise 2
30
2000/2001
Chaque propriété d'un objet peut être assimilée à une variable. Les valeurs qui lui seront
affectées représentent les occurrences de cette propriété. Si l'on affecte une valeur à chacune des
propriétés composant un objet, on obtient une occurrence de celui-ci.
ARTICLE
rtf006
Référence
rtf005
Libellé
robeindienne
Prixunitaire
230
Quantitéen stock
25
Objet
occurrences d'objet
Figure 22 : objet / occurrences d’Objet
Identifiant (ou clé) : L'identifiant d'un objet est une propriété ou un ensemble de propriété qui
permet de connaître sans ambiguïté chacune de ses occurrences. Dans l'exemple ci-dessus il
s'agit de la propriété Référence.
Dépendance fonctionnelle monovaluée : Un ensemble B dépend fonctionnellement d'un
ensemble A si la connaissance d'un élément a de A détermine au plus un élément b de B (si b
existe). On dit que A détermine B. Les dépendances fonctionnelles monovaluées sont
applicables aux objets : A et B sont alors des propriétés ; a et b sont des valeurs affectées à ces
propriétés.
Dans un objet toute propriété dépend fonctionnellement de l'identifiant. Une propriété
non identifiant ne dépend pas d'une autre propriété non identifiant. Une propriété non
identifiant ne dépend pas que d'une partie de l'identifiant.
ARTICLE
détermine
Référence
A
B
Libellé
Prixunitaire
détermine
Référence
Libellé
Quantitéenstock
détermine
Référence
Prixunitaire
détermine
Prixunitaire
Quantitéenstock
Figure 23 : dépendance fonctionnelle
monovaluée
Merise 2
31
2000/2001
Construction des objets : c'est l'existence de cette propriété identifiant qui rapprochée à la
règle de la dépendance fonctionnelle monovaluée, nous permet de construire les objets du
modèle conceptuel. L'inventaire de la liste des données manipulées par l'entreprise nous conduit
à dresser une liste de propriétés parmi lesquelles certaines sont reconnues comme identifiants
nous révélant l'existence des objets. Les autres propriétés décrivant l'objet doivent être en
dépendance fonctionnelle de son identifiant. Les propriétés de la liste qui ne dépendent pas d'un
identifiant ou qui en apparence dépendent de plusieurs identifiants seront pour l'instant laissées
de coté.
extrait de la liste des propriétés du SI d'un
cabinet d'assurances:
N° de police
Date d'effet de la police
Libellé du bien assuré
Adresse du bien assuré
N° du bien assuré
N° du sinistre
Date d'échéance de la police
Code de garantie
Montant du sinistre
valeur du bien assuré
recherche des objets par les
identifiants
POLICE
BIEN
SINISTRE
GARANTIE
N°depolice
N°debien
N°desinistre
codegarantie
propriétés en dépendance
fonctionnelle
POLICE
BIEN
SINISTRE
GARANTIE
N°depolice
N°debien
N°desinistre codegarantie
Dated'effet
Libellédubien
montant
Dateéchéance Adressedubien
Valeurdubien
Figure 24 : construction des objets
6.4. Relation
La relation peut être vue comme une association entre divers objets du modèle. Elle est la
traduction des verbes du langage de l'entreprise. La relation COMMANDER entre
COMMANDE et CLIENT est la traduction de la phrase : "un client peut passer une ou des
commandes". Cette association permet en particulier de savoir à qui livrer ou facturer une
commande.
Merise 2
32
2000/2001
Contrairement aux objets, une association n'a pas d'existence propre. Son existence est
conditionnée à celle des objets qui la composent.
L'ensemble des objets entrant dans la composition d'une relation est appelé collection de la
relation, celle-ci comportant au moins deux objets. La dimension de la relation est égale au
nombre d'objets de sa collection. Elle est dit n-aire (binaire, ternaire..) ou de dimension n (2, 3..).
Une relation peut ou non être porteuse de propriétés. Nous avons vu précédemment que lors
de la construction des objets, certaines propriétés de la liste peuvent être restées en attente (car
en dépendance fonctionnelle de plusieurs identifiants). La plupart du temps il s'agit de propriétés
de relations. C'est pas exemple le cas de "quantité commandée" qui est propriété de la relation
CONCERNE entre COMMANDE et ARTICLE.
Identifiant : La relation possède un identifiant qui est la combinaison (concaténation,
enchaînement) des identifiants des objets mis en relation. L'identifiant d'une relation n'est pas
mentionné sur les schémas.
COMMANDE
ARTICLE
CONCERNE
Numcommande
Numarticle
Numcommande-Numarticle
Libellearticle
Datecommande
Quantitécommandée
Prixunitaire
Statutarticle
Figure 25 : Identifiant des Relations
Dépendance fonctionnelle monovaluée : Comme dans le cas des objets, toute propriété
dépend fonctionnellement de l'identifiant. Une propriété non identifiant ne doit pas dépendre
d'une autre propriété non identifiant. Une propriété non identifiant ne doit pas dépendre que
d'une partie de l'identifiant.
Diagramme des occurrences: Construire un diagramme d'occurrences c'est attribuer à
chacun des objets et relations du modèle étudié, un ensemble de valeurs plausibles pour en
vérifier la validité (Figure 28).
Relation réflexive : Elle relie un objet à lui même. Une occurrence de la relation associe une
occurrence de l'objet à une autre occurrence de ce même objet (exemple PARENTE).
PERSONNE
0,n
parent de
PARENTE
Nom
Prénom
2,2
enfant de
Figure 26 : relation réflexive
6.5. Cardinalités
Merise 2
33
2000/2001
Les cardinalités représentent pour chaque couple objet-relation les nombres minimum et
maximum d'occurrences de la relation pouvant exister pour une occurrence d'objet. Elles
mesurent donc la participation des occurrences d'objets aux relations.
• (0, 1) : une occurrence d'objet peut exister sans pour autant participer à la relation (0) et ne
participe jamais plus d'une fois.
• (0,n) : c'est la cardinalité la plus ouverte; une occurrence d'objet peut exister sans pour autant
participer à la relation (0) et peut participer sans limitation.
• (1,1) : une occurrence d'objet participe une et une seule fois à la relation.
• (1,n) : une occurrence d'objet participe au moins une fois à la relation et peut participer sans
limitation.
Pour être complet, un modèle conceptuel doit comporter les cardinalités correspondantes à
chaque couple objet-relation. Les diagrammes d'occurrences mais surtout les règles de gestion
aident à déterminer les cardinalités. Elles sont des traductions de règles de gestion.
DEPOT
ARTICLE
N°dépot
?
STOCKER
?
N°article
Adressedépot
quantitéstockée
Libel éarticle
Figure 27 : cardinalités ?
N°dépot
Adressedépot
N°article
Libelléarticle
D01
Meylan
20
tOO1
t002
DO2
Grenoble
30
c001
D03
Fontaine
c002
10
c003
Figure 28 : diagramme d’occurrences
Du diagramme d'occurrences ci-dessus il ressort qu'un article peut être en stock dans plusieurs
dépôts, qu'un article peut ne pas être en stock et qu'à un moment donné un dépôt peut être vide.
Règles de gestion :
Merise 2
34
2000/2001
• Un article peut exister sans être stocké.
• Il peut être stocké dans plusieurs dépôts.
• Un dépôt peut exister même s'il ne stocke rien.
DEPOT
ARTICLE
N°dépot
0,n
STOCKER
0,n N°article
Adressedépot
quantitéstockée
Libelléarticle
Figure 29 : cardinalités
6.6. Contrainte d'Intégrité Fonctionnelle
Une Contrainte d'Intégrité Fonctionnelle (CIF) définie sur une relation représente le fait que
l'un des objets de sa collection est identifié sans aucun doute par la connaissance d'un ou
plusieurs autres.
Une relation binaire ayant des cardinalités (0,1) ou (1,1) exprime une CIF.
Une CIF exprime une règle de gestion et est représentée par une flèche pointant sur l'objet
déterminé.
DEPOT
ARTICLE
N°dépot
0 , n
STOCKER
1 , 1 N°article
Adressedépot
quantitéstockée
Libelléarticle
CIF
Figure 30 : Contrainte d’Intégrité Fonctionnelle
Le schéma ci-dessus (Figure 30) exprime les règles de gestion :
• Un article ne peut exister sans être stocké.
• Il ne peut être stocké qu'à un seul endroit.
Les CIF sont utilisées pour décomposer les relations. Elles permettent donc de simplifier des
relations de dimensions supérieure à 2.
Exemple : dans une entreprise industrielle, les ordres de fabrication sont établis par le siège en
direction de divers sites de production. On suppose la règle de gestion suivante:
• un ordre de fabrication ne concerne qu'un seul site.
Merise 2
35
2000/2001
La connaissance de l'ordre de fabrication permet donc de déterminer le site correspondant
(existence d'une CIF de "ordre de fabrication" vers "site"). Cette contrainte d'intégrité permet de
décomposer la relation ternaire (Figure 31) en deux relations binaires ( Figure 32).
SITE
ARTICLE
SITE
ARTICLE
N°site
N°article
N°site
N°article
Adressesite
1,n
Libelléarticle
Adressesite
Libelléarticle
1,n
1,n
1,n
FABRIQUER
FABRIQUER
quantitéàfabriquer
DESTINER
quantitéàfabriquer
1,n
CIF
1,n
ORDRE DE
1,1
FABRICATION
ORDRE DE
N°OF
FABRICATION
DateOF
N°OF
DateOF
Figure 32 : décomposition de
relation
Figure 31 : relation ternaire et CIF
6.7. Le problème de la représentation du temps
Il existe deux points de vue concernant la représentation du temps.
Représentation synchronique : Le temps n'intervient pas comme élément discriminant. Elle
correspond à une vision instantanée de la réalité modélisée.
Représentation diachronique (ou historique) : Le temps intervient comme élément
discriminant. Elle correspond à une vision historique de la réalité modélisée.
cas 1 (Figure 33 ) :
• Un étudiant assure une voiture pour un certain montant.
• Toute voiture est assurée par un et un seul étudiant.
ETUDIANT
VOITURE
1,n
ASSURE
1,1
N°étudiant
N°immat
montant
Figure 33 : le temps n’intervient pas
Merise 2
36
2000/2001
cas 2 (Figure 34): représentation synchronique
• Un étudiant assure à une certaine date, une voiture pour un certain montant.
• Toute voiture est assurée par un et un seul étudiant.
ETUDIANT
VOITURE
1,n
ASSURE
1,1
N°étudiant
N°immat
montant
date_contrat
Figure 34 : représentation synchronique
L'identifiant de l'association est toujours N°étudiant, N°immat
cas 3 (Figure 35): représentation diachronique
• Un étudiant assure à une certaine date, une voiture pour un certain montant.
• Il peut avoir assuré plusieurs fois sa voiture.
ETUDIANT
VOITURE
N°étudiant
N°immat
1,n
1,n
ASSURE
montant
DATE
date
Figure 35 : représentation diachronique
La prise en compte du temps peut se faire:
• soit en introduisant une entité temporelle (date, jour ) ( Figure 35),
• soit en introduisant des entités représentant des événements datés (Figure 36).
Merise 2
37
2000/2001
cas 4 (Figure 36): introduction d’événements datés
• Un étudiant peut pour une même voiture passer successivement plusieurs contrats
ETUDIANT
VOITURE
N°étudiant
N°immat
1,n
1,n
ASSURE
1,1
CONTRAT
N°contrat
montant
date_contrat
Figure 36 : entités correspondant à des
événements datés
Merise 2
38
2000/2001
6.8. Vérification du modèle
• Toutes les propriétés doivent être élémentaires (non décomposables).
• Chaque objet doit posséder un identifiant et un seul.
• Les propriétés d'un objet, autres que l'identifiant, doivent être en dépendance fonctionnelle
monovaluée de cet identifiant.
• Une propriété ne peut qualifiée qu'un seul objet ou qu'une seule relation (éviter les redondances
et les polysèmes).
• les dépendances fonctionnelles transitives doivent être éliminées. Autrement dit une propriété
non identifiant ne doit pas être en dépendance fonctionnelle d'une autre propriété non
identifiant.
• Pour chaque occurrence d'une relation, il doit exister une et une seule occurrence de chacun
des objets de la collection (la participation d'un objet à une relation ne peut pas être
optionnelle).
• les propriétés d'une relation doivent dépendre de la totalité de l'identifiant de cette relation.
Autrement dit une propriété non identifiant ne doit pas dépendre que d'une partie de
l'identifiant.
6.9. La démarche
Ecole pragmatique
• recherche des objets par "intuition",
• objet = reflet d'une entité d'intérêt pour l'organisation étudiée,
• inconvénients :
• se laisser envahir par l'existant pour construire un modèle qui doit représenter l'invariant (c'est
à dire se placer hors du temps) ;
• trop proche de la "vue" de l'utilisateur et non de la globalité des objets de l'organisation.
Ecole "formelle" (ou plutôt exhaustive)
• établir la liste des propriétés à partir des documents de l'entreprise (ou de tout autre support),
• classer ces données par ordre alphabétique,
• épuration des polysèmes, des synonymes et des redondances,
• repérer les identifiants existants pour dégager les objets naturels,
• rattacher à ces objets les propriétés en dépendance fonctionnelle de leur identifiant,
• placer les relations et leur rattacher, si besoin est, les propriétés en dépendance fonctionnelle de
plusieurs identifiants,
Merise 2
39
2000/2001
• considérer les propriétés restantes afin de les grouper en objets pour lesquels on définira des
identifiants,
• étudier les cardinalités de chaque couple objet-relation,
• simplifier le modèle à l'aide des contraintes d'intégrité fonctionnelle,
• procéder à la vérification des règles.
Cohérence par rapport aux Modèles de Flux
Quel que soit le mode d'obtention du MCD, les propriétés des objets et des relations doivent être
cohérentes avec celles drainées par les flux d'information des Modèles de flux.
C'est ainsi que l'arrivée d'une commande (un flux d'information du modèle de contexte) est
porteuse de nombreuses informations (code client, nom client, code produit, quantité
commandée .) qui correspondent à des propriétés des objets et des relations du MCD. Inversement,
une facture émise par le domaine étudié est également porteuse d'informations (prix total à payer,
etc.) qui correspondent soit à des propriétés des objets ou des relations soient à des informations
calculables à partir de celles ci.
Les paragraphes suivants présentent les extensions proposées dans Merise 2. Il s'agit d'une part
de la définition des sous-types d'objets et de relations, d'autre part de l'introduction des contraintes
d'intégrité statiques.
6.10. Sous-type d'objet et sous-type de relation
Sous-type d'objet
Un sous-type d'objet correspond à un sous-ensemble d'occurrences d'objet dotées de
caractéristiques propres (propriétés spécifiques et/ou relations spécifiques). On pourra aussi
employé les termes d'objet générique (sur-type) et objet spécialisé (sous-type).
• L'objet générique ou sur-type porte les caractéristiques communes aux objets spécialisés.
EMPLOYE
N°employé
nom
EMPLOYE HOMME
EMPOYE FEMME
service militaire
congés maternités
Figure 37 : sur-type/sous-type
Merise 2
40
2000/2001
• Chaque sous-type hérite des propriétés et des relations du sur-type.
relations
génériques
propriétés génériques
propriétés spécifiques
relations spécifiques
Figure 38 : héritage et spécialisation
• Le mécanisme de spécialisation permet d'avoir plusieurs niveaux de description d'un même
objet : de la description la plus générale à la description la plus spécifique.
PERSONNEL
DOMICILIATION
BANCAIRE
Numpers
possède
Nom
RIB
Prenom
Adresse
Age
PERSONNEL
PERSONNEL
ADMINISTRATIF
NAVIGANT
nbe heures vol
appartient
HOTESSE
PILOTE
SERVICE
code
possède
Figure 39 : BREVET
hiérarchie d’héritage
• Cas particulier de spécialisation : la spécialisation par états
Un sous-type correspond dans ce cas à un état de l'objet. Il peut y avoir transfert d'une
occurrence de l'objet d'un sous-type à un autre sous-type, contrairement au cas précédent (Figure
39) qui correspond à une spécialisation par "catégorie". Nous verrons que les CVO constitue une
alternative à la modélisation des états.
PERSONNE
CELIBATAIRE
MARIE
DIVORCE
Figure 40 : spécialisation par états
Merise 2
41
2000/2001
Sous-type de relation
Un sous-type de relation correspond à un sous-ensemble d'occurrences d'une relation dotées
de propriétés et/ou de cardinalités spécifiques.
OUVRAGE
LIVRE
REVUE
N° ISBN
N° ISSN
1,n
1,1
1,n
editer_livre
editer_revue
éditer
EDITEUR
Figure 41 : sous-type de relation
6.11. Contraintes d'intégrité statique
Les contraintes d'intégrité statiques peuvent porter sur :
• Une ou plusieurs propriétés :
? plage de valeurs
? liste de valeurs
? contrainte de format
• Des sous-type d'objets :
? contrainte de partition (notée +)
? contrainte d'exclusion (notée x)
? contrainte de totalité (notée T)
• Des relations ou des pattes de relations :
? contrainte de partition (+)
? contrainte d'exclusion (x)
? contrainte de totalité (T)
? contrainte d'inclusion (I)
? contrainte d'égalité (=)
? contrainte d'unicité (1)
• Des propriétés et/ou des relations :
? contraintes d'identification
6.11.1. Contraintes de base : couverture et disjonction
Merise 2
42
2000/2001
contrainte de couverture : toute occurrence de l'objet générique doit appartenir à au moins un
des sous-types.
A
A
C ••
•
•
•
B
B
C
Figure 42 : couverture
contrainte de disjonction : toute occurrence de l'objet générique doit appartenir à un seul sous-
type (les sous-types sont mutuellement exclusifs).
A
A
C •
•
•
•
•
B
C
•
•
B
Figure 43 : disjonction
6.11.2. Contraintes d'intégrité entre les sous-types d'objets
disjonction + couverture
partition (+)
disjonction + couverture
totalité (T)
disjonction + couverture
exclusion (x)
Figure 44 : contraintes d’intégrité entre les sous-
types
Merise 2
43
2000/2001
Contrainte de partition
Un auteur est soit invité, soit accepté, soit refusé.
AUTEUR
+
AUTEUR INVITE
AUTEUR ACCEPTE
AUTEUR REFUSE
Figure 45 : partition = disjonction + couverture
Contrainte de totalité
Une personne physique peut être à la fois Particulier et Entrepreneur individuel, elle est l'un
ou l'autre.
PERSONNE
PHYSIQUE
T
PARTICULIER
ENTREPRENEUR
Figure 46 : totalité = couverture et non
disjonction
Contrainte d'exclusion
Un contrat ne peut être à la fois un contrat de crédit et un contrat d'épargne, il existe d'autres
types de contrats.
CONTRAT
X
CONTRAT
CONTRAT EPARGNE
CREDIT
Figure 47 : exclusion = disjonction et non
couverture
Merise 2
44
2000/2001
6.11.3. Contraintes d'intégrité sur les relations
Ici aussi il s'agit de contraintes ensemblistes.
Contrainte de partition (couverture et disjonction)
Une contrainte de partition permet d'exprimer que toutes les occurrences d'un objet (dit objet
pivot) impliqué dans deux (ou plus) relations sont présentes dans une et une seule d'entre elles
(ou exclusif).
Toute personne est soit résidente en France soit résidente à l'étranger, mais ne peut être les
deux.
VILLE
résident 0,n
0,1 France
PERSONNE
+
0,1
0,n
PAYS
résident
étranger
Figure 48 : partition
Contrainte d'exclusion (non couverture et disjonction)
Une contrainte d'exclusion interdit qu'une occurrence d'un objet (dit objet pivot) impliqué
dans deux (ou plus) relations soit présente dans deux d'entre elles.
On ne peut être salarié et étudiant, certaines personnes ne sont ni l'un ni l'autre.
ETABLISSEMENT
étudiant
PERSONNE
0,1
x
0,1
ENTREPRISE
salarie
Figure 49 : exclusion
Contrainte de totalité (couverture et non disjonction)
Une contrainte de totalité permet d'exprimer que toutes les occurrences d'un objet (dit objet
pivot) impliqué dans deux (ou plus) relations sont présentes dans au moins l'une d'entre elles (ou
inclusif).
Toute personne est étudiant dans un établissement, ou salarié dans une entreprise ou les deux
à la fois.
Merise 2
45
2000/2001
ETABLISSEMENT
étudiant
PERSONNE
T
ENTREPRISE
salarie
Figure 50 : totalité
Note : Pour les contraintes de partition, d’exclusion et de totalité, si aucun
objet pivot n’est mentionné la contrainte porte sur la collection de la
relation.
On ne peut être salarié et étudiant du même établissement.
étudiant
PERSONNE
0,1
ETABLISSEMENT
x
0,1
salarie
Figure 51 : plusieurs objets pivots
Contrainte d'inclusion
cas 1 : pas d'objet pivot explicitement désigné
Une contrainte d'inclusion permet d'exprimer que l'ensemble des occurrences d'une relation
est inclus dans l'ensemble des occurrences d'une autre relation.
Le président du comité d'organisation d'une conférence est choisi parmi les membres du
comité d'organisation (de cette même conférence).
membre
du CO
PERSONNE
CONFERENCE
I
président
du CO
Figure 52 : inclusion sans objet pivot explicite
Merise 2
46
2000/2001
La relation président du CO est appelée "portée" de la contrainte d'inclusion,
La relation membre du CO est la "cible" de la contrainte d'inclusion.
cas 2 : un objet pivot
Dans ce cas la contrainte d'inclusion porte sur l'ensemble des occurrences d'un objet (dit objet
pivot). L'ensemble des occurrences de l'objet pivot présentes dans une des relations est inclus
dans l'ensemble des occurrences de l'objet pivot présentes dans l'autre relation.
Si un employé est rattaché à un service il doit dépendre d'un site de l'entreprise (par contre il
peut dépendre d'un site sans être rattaché à un service).
SERVICE
rattaché
EMPLOYE
I
SITE
dépend
Figure 53 : inclusion avec objet pivot
portée de la CI : "rattaché", cible de la CI : "dépend", objet pivot : EMPLOYE
Note : dans le cas 1 le pivot est constitué des deux objets Personne et Conférence.
Contrainte d'égalité
Une contrainte d'égalité est une combinaison de deux inclusions symétriques.
Tout employé rattaché à un service dépend de l'un des sites de l'entreprise. Inversement tout
employé dépendant d'un site doit être rattaché à un service.
SERVICE
rattaché
EMPLOYE
=
SITE
dépend
Figure 54 : égalité
Contrainte d'unicité
Merise 2
47
2000/2001
Une personne à une date donnée ne peut occuper qu'une et une seule fonction.
PERSONNE
DATE
0,n
0,n
nommer
1
0,n
FONCTION
Figure 55 : unicité
Contrainte d'identification
Jusqu'à présent un objet était défini comme ayant une existence et donc une identification
propre. Cependant il arrive que certain objet n'ont d'existence que par rapport à un ou plusieurs
autres objets. Ses relations avec ces objets peuvent être utilisées pour l'identifier.
appartenir
CHAMBRE
HOTEL
N°hotel
N°chambre =
N°hotel +
N°chambredanshotel
Figure 56 : identification
Merise 2
48
2000/2001
7. Les Modèles dynamiques
Les modèles précédents ont permis de décrire au niveau conceptuel :
• les aspects structurels par le MCD,
• les aspects fonctionnels par le MFC.
Il s'agit à présent de décrire les aspects comportementaux (dynamiques) du système. Dans
Merise la représentation dynamique du système est décrite par le Modèle Conceptuel de
Traitement. Merise 2 offre deux modèles complémentaires : le Modèle Conceptuel de
Traitements Analytique (MCTA) et les cycles de vie des objets (CVO).
Quel que soit le modèle, il s'agit au niveau conceptuel de décrire l'activité de l'entreprise en
éliminant les considérations d'organisation telles que la répartition du travail, le déroulement
dans le temps, la nature des tâches et bien sûr les contraintes techniques.
Le formalisme introduit dans Merise 2 (MCTA) se distingue du formalisme classique de
Merise (MCT) par les points suivants :
• il met en évidence l'interaction entre les données et les traitements (grâce au CVO),
• il s'appuie sur une définition rigoureuse des événements déclencheurs,
• il permet de représenter le parallélisme de certains traitements,
• il prend en compte le cas où à l'arrivée d'un événement le système ne se trouve pas dans l'état
qui permettrait à une opération de se déclencher,
• il distingue les événements déclencheurs des opérations et les ressources (données consultées)
nécessaires à l'exécution de ces opérations.
Le paragraphe suivant décrit le MCT originel introduit dans Merise. Nous présenterons
ensuite les extensions apportées par le MCTA et enfin nous introduirons les CVO.
8. Modèle Conceptuel des Traitements (MCT)
8.1. Vocabulaire de base
La modélisation des aspects dynamiques repose sur le concept d’événements vus comme des
stimulateurs de l'activité. Il s’agit d’obtenir une représentation de l’enchaînement des opérations
du système et des conditions de déclenchement de son activité par des stimulations extérieures.
La dynamique du fonctionnement obéit à des règles issues d'un enrichissement des concepts
des réseaux de Pétri.
Evénement
C'est la représentation d'un fait nouveau pour le système étudié ; ce fait est porteur
d'information. C'est par exemple l'arrivée d'une déclaration de sinistre dans une compagnie
d'assurance. Cet événement est porteur d'informations concernant l'assuré, le bien assuré et le
sinistre affectant celui-ci.
Merise 2
49
2000/2001
Opération
C'est la réaction du système, sous forme de traitements, face à l'arrivée d'un événement ou
d'un ensemble événements. L'arrivée de l’événement "Déclaration de sinistre" déclenche
l'opération "vérifier la garantie".
Résultat
C'est la représentation de la réponse du système, générée par une opération. L'opération
"vérifier la garantie" produit les résultats "sinistre pris en compte" ou "sinistre rejeté".
Synchronisation
C'est la représentation d'une pré-condition au déclenchement d'une opération. Elle peut faire
intervenir plusieurs événements. Le déclenchement de l'opération "rembourser assuré" est
conditionné par la présence des événements "rapport d'expertise" ET "facture de réparation".
rapport
facture de
d'expertise
réparation
évènements
synchronisation
ET
Rembourser l'assuré
opération
chèque
dossier clos
résultats
Figure 57 : concepts de base du MCT
8.2. Evénement
Un événement est une circonstance portée à la connaissance du système et à laquelle il doit
réagir. Pour qu'il y ait événement il faut que certaines conditions soient vérifiées :
• il doit se produire quelque chose (à l'extérieur ou à l'intérieur de l'organisation),
• ce fait doit être perçu par le système (qui devra donc se doter des moyens appropriés de le
percevoir)
• ce fait n'intéresse le système que dans la mesure où il est identifié comme un déclencheur
possible de son activité.
Merise 2
50
2000/2001
On distingue plusieurs types d’événements :
• les événements que le système perçoit en provenance de l'extérieur et sur lesquels il n'a aucune
maîtrise : les événements externes ;
• le résultat d'une opération peut participer en tant qu’événement au déclenchement de
l'opération suivante. On parle d’événement interne. Ce type d’événement ne peut déclencher
l'opération suivante que s'il est combiné avec au moins un autre événement. Si ce n'est pas le
cas, l’événement ne doit pas apparaître dans le modèle conceptuel, il s'agit la plupart du temps
d'un résultat intermédiaire de l'opération.
• un résultat ne participant pas à la poursuite de l'activité du système et destiné à être émis vers
l'extérieur : on parle alors d’événements résultats ou simplement de résultats.
8.3. Synchronisation
Il est fréquent de rencontrer des opérations dont le déclenchement est conditionné par plusieurs
événements. Il faut alors représenter les conditions d'entrée, c'est à dire préciser quelles sont les
associations d’événements dont la présence est indispensable au déclenchement de l'opération.
Cette représentation se fait par la synchronisation.
La synchronisation est à la fois une association d’événements "candidats" et une expression
booléenne formée à partir des opérateurs ET et OU.
Pour faciliter la lecture il est recommandé d'attacher à chacun des événements concernés un label
plus facile à manipuler que le nom de l’événement et qui représente une occurrence de l’événement.
rapport
facture de
dossier
d'expertise
réparation
ouvert
b
a
c
a ET b ET c
Rembourser l'assuré
chèque
dossier clos
Figure 58 : synchronisation
8.4. Opération
Merise 2
51
2000/2001
L’arrivée d'un événement déclenche un ensemble de traitements appelé opération.
Une opération ne peut être déclenchée que par l'arrivée de l’événement ou de l'ensemble
d’événements qui lui est rattaché. Cet ensemble d’événements peut être considéré comme les
ressources nécessaires au bon déroulement de l'opération.
Une opération est une séquence continue d'actions et qui doit s'exécuter sans interruption
(principe de non interruptibilité) dès qu'elle est déclenchée. Une opération constitue donc un
bloc de traitement, qui ne doit pas souffrir d'aucune interruption durant son exécution (pas
d'attente d’événement externe). L'exécution d'une opération produit l'émission d’événements
internes (poursuite de l'activité) et/ou de résultats (signaux vers l'extérieur).
Une même opération peut produire plusieurs résultats. Nous avons vu qu'il est possible de
représenter les conditions de déclenchement d'une opération. De la même manière, la production
de résultats peut être soumise à des conditions de sortie de l'opération appelées règles
d'émission.
Une opération est donc décrite par :
• sa désignation (un libellé + éventuellement un code),
• les actions élémentaires descriptives des travaux à accomplir; ces actions sont essentiellement
des actions sur les données (consultation, mise à jour).
• les événements émis (événement internes ou résultats) et les conditions de ces émissions.
L'opération "vérifier garantie" déclenchée à l'arrivée de l’événement "déclaration de sinistre"
génère les résultats : "sinistre rejetée" et "lettre de rejet" ou "sinistre accepté" et "dossier ouvert".
déclaration
de sinistre
vérifier la garantie
risque couvert
risque non couvert
sinistre
sinistre
accepté
rejeté
dossier ouvert
lettre de rejet
Figure 59 : opération
différents graphismes :
Merise 2
52
2000/2001
vérifier la garantie
opération
vérifier la garantie
opération avec
règles
risque couvert
risque non couvert
d'émission
OPC1 VERIFIER GARANTIE
code + libellé
- vérifier existence du client
- vérifier que le bien est assuré
actions
- vérifier la garantie du bien
risque couvert risque non couvert
règles d'émission
Figure 60 : formalismes graphiques des
opérations
8.5. Le processus
Le processus est un enchaînement synchronisé d'opérations qui représente une unité de
préoccupation de l'entreprise. Il est propre à un domaine d'activité.
E2
E1
Syn.1
OPERATION1
E3
R1
Syn.2
O
O P
P E
E R
R A
A T
TI IO
O N
N22
R2
R3
Figure 61 : processus
Exemple de processus
Merise 2
53
2000/2001
billet demandé
OPC1 ATTRIBUTION BILLET
- contrôle recevabilité de la demande
- recherche des places disponibles
- attribution de la place
- édition du billet
- calcul du prix
non OK
OK
autre recherche
demande non
demandée
satisfaite
billets émis
paiement
ET
OPC2 REFORMULATION
ET
- proposition de reformulation
de la demande
OPC3 VENTE BILLET
OK
- encaissement du montant
non OK
- remise du billet
OK
non OK
billet remis
Figure 62 : exemple de processus
Pour décrire un domaine on peut être amené à définir plusieurs processus. Si le domaine est
vaste, on le découpe en plusieurs sous-domaines chacun décrit par un processus.
Exemple : commercialisation des produits d'une entreprise.
La gestion des ventes reçoit des commandes puis transmet le double des bons de commandes
à la facturation et les bons de livraisons à la gestion des livraison. La facturation établit des
factures, reçoit les règlements et expédie des reçus. La gestion des livraisons livrent les articles
aux clients. Nous pouvons établir le diagramme de flux de niveau 1 suivant. Les sous-domaines
à distinguer sont les activités vente, facturation et livraison. Chacun de ces sous-domaines est
couvert par un processus distinct. Les opérations conceptuelles sont définies à chaque point
d'arrivée des événements externes au processus décrit : "commande", "commande validée",
"règlement", "bon de livraison".
Merise 2
54
2000/2001
facture
règlement
facturation
processus 1
reçu
client
commande validée
commande
vente
processus 2
bon livraison
produit
livraison
processus 3
L'ensemble des événements, opérations et résultats décrivant un processus constitue le modèle
conceptuel de traitements de ce processus.
commande
validée
facturé
règlement
facture
ET
encaissé
reçu
Figure 63 : MCT du processus facturation
On rappelle qu'une opération est interruptible. En particulier, elle ne peut pas s'interrompre
dans l'attente d'un événement externe (ou d'une combinaison d’événements interne). Si tel est le
cas il convient de décrire une seconde opération s'appuyant sur cet événement en attente.
Considérons par exemple le processus de facturation. Les résultats attendus sont d'une part
une facture, d'autre part un reçu après règlement du client. La facturation ne nécessite pas le
Merise 2
55
2000/2001
paiement, mais l'émission du reçu ne peut s'effectuer qu'après celui-ci. Il y a donc présence de
deux opérations : l'une générant la facture, l'autre le reçu.
Remarque : facture est à la fois un événement résultat (transmis à l'extérieur) et un événement
interne participant au déclenchement de l'opération suivant. Cette double flèche traduit la règle
de gestion imposant la facturation préalable à l'encaissement.
8.6. La consommation
Un événement peut être candidat au déclenchement de plusieurs opérations sachant qu'une
occurrence de cet événement ne peut prendre part qu'à une seule de ces opérations.
demande contrat
étudier la demande
évènement
consommable
proposition
accord
fin de validité
client
ET
ET
ouvrir police
annuler la proposition
police ouverte
proposition annulée
Figure 64 : événement consommable
Exemple : lorsqu'un client désire assurer un bien, il demande à la compagnie de lui faire une
proposition. Une fois élaborée, cette proposition est soumise au client et reste valable durant un
certain temps au bout duquel faute de réponse du client elle est annulée.
Cette représentation n'est acceptable que si les deux situations ne peuvent avoir lieu
simultanément. Dans l’exemple précédent le client ne peut pas simultanément donner son accord
et ne pas donner suite à la proposition.
8.61. Démarche d'élaboration du MCT
Merise 2
56
2000/2001
Le plus simple est de partir des modèles de flux. Le point d'arrêt de la décomposition avec le
formalisme du MFC correspond au moment où l'activité peut être assimilée à une opération et
est donc ininterrupible, mais le dernier niveau utile pour passer au MCT est plutôt le niveau
précédent, celui où l'activité peut être assimilée à un processus. Il est donc souvent nécessaire
d'aller un niveau trop loin dans le processus de décomposition des MFC pour être capable de
déterminer le niveau où il est nécessaire de changer de formalisme.
Le modèle de flux ne permet pas d'exprimer la notion de temps et de séquence. On doit alors
passer à un raisonnement événementiel et faire intervenir le temps, les règles de synchronisation
et les règles d'émission.
Nous avons vu que tous les flux d'information des Modèles Conceptuels de Flux sont
transformés en événements dans le MCT. En l'absence d'événements temporels, un flux
correspond donc à un événement et une activité correspond à une opération. Par contre, si des
événements temporels doivent être pris en compte une activité peut être décomposée en
plusieurs opérations conceptuelles : l'activité ininterruptible en terme de flux d'information
devient interruptible par le temps.
Reprenons par exemple la figure 19. L'activité "gestion des règlements" est ininterruptible en
terme de flux d'information : aucun flux d'information autre que le règlement n'est nécessaire au
bon déroulement de cette activité. Supposons à présent l'existence de règles de gestion imposant
que :
- les règlements soient immédiatement vérifiés dès leurs arrivées
- les factures acquittées soient envoyées aux clients tous les soirs.
L'événement temporel "tous les soirs" provoque une interruption temporelle durant l'activité
"gestion des règlements" qui sera décomposée dans le MCT en deux opérations conceptuelles :
la prise en compte des règlements et la facturation.
règlement
Prise en compte règlement
règlement accepté
le soir
ET
facturer
facture acquitée
Merise 2
57
2000/2001
9. Modèle Conceptuel des Traitements Analytique (MCTA)
La tendance actuelle consiste à développer le couplage traitements-objets, notamment par
l'introduction des Cycles de Vie des Objets. Les CVO permettent en effet de rendre compte des
changements d'états des principaux objets des modèles de données, au cours de la vie des
processus. Ces modifications d'états portées sur le MCTA complètent les opérations
conceptuelles.
Nous commencerons par compléter la définition des opérations conceptuelles puis
introduirons la notion d'état d'objet, notion qui sera reprise et approfondie lorsque nous
présenterons les CVO.
9.1. Opération conceptuelle
L'opération conceptuelle est :
- déclenchée par un ou plusieurs événements,
- met en oeuvre un ensemble de règles conceptuelles formalisées,
- consulte et met à jour des entités de la mémoire permanente par l’intermédiaire d'actions,
- laisse les données du SI dans un état cohérent par rapport aux contraintes d'intégrité de la
mémoire permanente,
- ne peut être interrompue par l'attente d'un événement externe ou temporel.
Représentation graphique:
Evènement externe
Evènement
ou temporel
interne
OBJ1
état4
règle Synchro
OBJ2
OPC1
état1
règles d'émission
OBJ3
état1
Résultat
Evènement
externe
interne
OBJ4
état5
etat4
état6
Figure 65 : représentation graphique des
opérations dans le MCTA
Merise 2
58
2000/2001
Exemple intuitif : Nous sommes dans le cadre d’une formation permanente. Une demande
d'inscription à un stage déclenche l’opération “ enregistrer candidature ”. Cette opération :
• s'assure que le stage existe,
• crée une occurrence de l'entité stagiaire dans l'état candidat.
Demande
d'inscription
consultation
STAGE
créé
enregistrer candidature
STAGIAIRE
stage non existant stage existant
candidat
candidature
candidature
enregistrée
création
rejetée
Figure 66 : Opération “ enregistrer candidature ”
9.2. Etat d'objet
Un état d'objet est un stade transitoire par lequel passe un objet (une entité de la mémoire
permanente) au cours de son cycle de vie.
Exemple :
• "à livrer", "en attente", "livrée", "facturée" : états de COMMANDE
• "créé", "complet", "ouvert", "en cours" : états de STAGE
• "candidat", "recalé", "reçu", "inscrit", "en attente", "en formation" : états de STAGIAIRE
Les états des objets sont représentés dans le MCTA pour montrer l'évolution des objets durant
l'exécution des opérations conceptuelles.
Représentation graphique dans le MCTA
OBJ
état
état1
état2
état
avant
après
Figure 67 : états des objets avant et après
exécution de l'opération
Merise 2
59
2000/2001
Merise 2
60
2000/2001
Les différents cas possibles :
création d'une occurrence
OBJ1
STAGIAIRE
de l'obj1 dans un état1.
état1
candidat
consultation d'une occurrence
OBJ2
STAGE
de l'obj2 dans un état1
état1
créé
suppression d'une occurrence
OBJ3
STAGE
de l'obj3 qui se trouve dans
état1
un état1
créé
modification d'une occurrence
OBJ4
STAGIAIRE
de l'obj4. Elle passe de l'état4
état5
à l'état5 ou l'état6.
etat4
candidat
recalé
état6
reçu
Figure 68 : Evolution des états d’objets
Dans le cas d'une consultation on peut :
• soit ne pas représenter l'état de l'objet, si l'état n'a pas d'importance ;
• soit représenter l'état de l'objet, c'est le cas d'une consultation qui s'assure qu'un objet est bien
dans un état donné.
9.3. Action
Une action est une manipulation des données d'un objet ou d'une relation du SI. Elle peut
créer / consulter / modifier / supprimer une et une seule occurrence d'entité (objet ou relation)
de la mémoire permanente. Dans les MCT les actions s'expriment en langue naturelle à
l'intérieur des opérations. Dans le MCTA les actions agissant sur les états d'objets sont
représentées graphiquement.
Merise 2
61
2000/2001
OBJ1
SUPPRESSION
OPERATION
état4
CONSULTATION
OBJ2
OPERATION
état1
OBJ3
CREATION
OPERATION
état1
OBJ4
MODIFICATION
OPERATION
état5
etat4
état6
Figure 69 : actions des opérations dans le MCTA
L'ordre des actions d'une opération conceptuelle sera, dans la mesure du possible, présenté de
haut en bas. L'opération conceptuelle ENREGISTRER CANDIDATURE est composée de deux
actions : une consultation permettant de vérifier que le stage est crée, une création d'un stagiaire
dans un état candidat.
Demande
d'inscription
enregistrer candidature
- vérifier stage créé
MCT
- création du stagiaire candidat
stage non créé
stage créé
candidature
candidature
enregistrée
rejetée
Demande
d'inscription
consultation
MCTA
STAGE
créé
enregistrer candidature
STAGIAIRE
stage non créé
stage créé
candidat
candidature
candidature
création
enregistrée
rejetée
Figure 70 : actions du MCT au MCTA
Une action de consultation peut exprimer une condition de déclenchement sur une mise à jour.
C'est le cas ici où l'on souhaiterait exprimer que le stagiaire est créé (état candidat) si le stage
existe (état créé). Dans ce cas il s'agit d'exprimer explicitement une condition de déclenchement
sur une opération de mise à jour (Figure 71).
Merise 2
62
2000/2001
Une action peut donc être accompagnée d'une condition de déclenchement qui peut ou non
être itérative.
Merise 2
63
2000/2001
9.4. Condition sur les actions
Condition de Déclenchement
Le déclenchement d'une action peut être soumis à une condition, c'est à dire à une règle qui
porte sur l'état de la structure de données au moment où l’événement est constaté.
Demande
d'inscription
consultation
STAGE
créé
enregistrer candidature
STAGIAIRE
non C
C
candidat C
candidature
candidature
enregistrée
création
rejetée
C : stage créé
Figure 71 : condition de déclenchement
La condition de déclenchement C permet le respect des contraintes d'intégrité statiques
exprimées dans le modèle de données.
Dans l'exemple ci-dessous un exemplaire est soit prêté, soit réservé (il ne peut être les deux).
S'il n'est ni l'un ni l'autre il est disponible. Un abonné peut emprunter un livre (il devient actif) ou
établir une réservation (il est en attente). Un abonné inactif n'a ni prêt, ni réservation en cours.
PRET
0,1
0,1
EXEMPLAIRE
ABONNE
X
X
RESERVE 0,1
0,1
Merise 2
64
2000/2001
Demande
ABONNE
de prêt
inactif
actif
C1
en at ente
non C1
EXEMPLAIRE
disponible
prété
C
TRAITEMENT DEMANDE DE PRET
C et C1
EXEMPLAIRE
prété
réservé
C
exemplaire
donné
C : abonné inactif
C1 : exemplaire disponible
Figure 72 : condition de déclenchement et
respects des CI
Condition Itérative
Le déclenchement itératif d'une action peut être contrôlé par une règle qui définit les
paramètres de l'itération. Dans le schéma ci-dessous le N signifie que l'opération intervient sur
toutes les occurrences de l'objet concerné respectant la condition de déclenchement. On parle
d'action collective.
moment retenu
pour la résiliation
POLICE
N
proposée résiliée C1
RESILIER LES POLICES
D'ASSURANCE
C1 : délai de signature dépassé
Figure 73 : condition itérative
9.5. Evénement interne
Merise 2
65
2000/2001
Un événement interne correspond à un changement d'état particulier d'objet. Provoqué par une
opération, il participe à son tour au déclenchement de l'exécution d'une opération.
• L’événement interne mis en évidence au niveau du MCTA se situe entre deux états
cohérents du système. Par exemple dans le MCTA ci-dessous on exprime qu'une commande peut
être créée sans être facturée.
arrivée d'un bon de commande
PRODUIT
en stock
PRENDRE EN COMPTE UNE COMMANDE
COMMANDE
C
C
créée
bon de
personnel
commande
disponible
accepté
COMMANDE
créée
facturée
N
FACTURER
FACTURE
envoi facture
C : produit en stock
Figure 74 : événement interne déclencheur
• Les ressources informationnelles nécessaires à l'exécution d'une opération, mais non
déclenchantes, sont représentées par des actions de consultation et non plus par des événements
internes comme dans le MCT (Figure 75).
Merise 2
66
2000/2001
arrivée d'une
arrivée d'une
commande
commande
FACTURE
FACTURER
créée
FACTURER
arrivée
facture
arrivée
règlement
créée
règlement
FACTURE
ET
créée
archivée
ENCAISSER
ENCAISSER
REGLEMENT
MCT
MCTA
Figure 75 : événement interne non déclencheur
Remarquons que dans l'exemple précédent (Figure 74) l’événement interne "bon de
commande accepté" n'est pas remplacé par une opération de consultation. En effet, l'opération
Facturer est déclenchée si un membre du personnel est disponible ET au moins un bon de
commande a été accepté.
9.7. Passage des modèles de flux au MCTA
La technique présentée dans le chapitre précédent (élaboration du MCT) reste la même. Il
s'agit donc de décomposer les activités des modèles de flux jusqu'à ce que l'activité corresponde
à une opération conceptuelle ou à un processus.
On peut également passer d'abord par un MCT, puis se focaliser sur les CVO (cf. paragraphe
suivant) pour finalement transformer le MCT en MCTA. Ne pas oublier alors de supprimer les
événements internes du MCT correspondant à des consultations.
Merise 2
67
2000/2001
10. Les Cycles de Vie des Objets
10.1. Introduction
Une entité décrite dans le modèle de données n'est pas figée à tout jamais. Elle passe durant sa
vie par différents états qui peuvent être constatés à partir des diverses valeurs prises par :
• ses propriétés,
• ou celles des objets qui lui sont liés,
• ou encore par sa participation (ou sa non participation) dans les relations où elle intervient.
Cette succession d'états est représentée par un graphe orienté dont les sommets sont de deux
types :
•les divers états de l'objet,
•les événements provoquant le passage d'un état à un autre.
Evénement et Transition
La définition de l’événement reste identique. Un événement peut être externe, interne,
temporel. Dans le CVO les événements déclenchent la transition d'un état à l'autre.
Un événement peut déclencher plusieurs transitions.
Un événement interne est généré par au moins une transition d'états d'objet.
Une transition correspond au passage d'un objet d'un état dans un autre. Elle est représentée
par un double arc orienté, reliant deux états par l'intermédiaire d'un événement.
Représentation graphique et exemple partiel
ARTICLE
ARTICLE
contrôle
livré
contrôlé
OBJET 0
OBJET O
Ev.1
état1
état2
Figure 76 : état, événement et transition dans les
CVO
Objectifs
• donner une vision synthétique du cycle de vie des principaux objets,
Merise 2
68
2000/2001
• compléter le MCD en mettant en évidence des contraintes d'intégrité statiques entre les états
d'objet et les propriétés spécifiques aux états,
• mettre en évidence des contraintes d'intégrité dynamiques sur les enchaînement d’états,
• faciliter la construction du MCTA.
Commentaires MCTA / CVO
Les deux modèles représentent les aspects dynamique du SI, cependant :
• les CVO modélisent le cycle de vie de chaque objet du système alors que le MCTA modélise le
cycle de vie du système.
• le CVO est construit autour de l'objet et décrit l'ensemble des événements affectant l'objet au
cours de son cycle de vie. Le MCTA est construit autour des opérations et donne une vision
globale des conséquences d'un même événement
• le MCTA donne une vision synthétique de la coordination des événements, le CVO donne une
vision synthétique de la coordination entre états.
10.2. Les principales transitions
Les trois schémas de base qui peuvent être représentés sur un CVO sont la séquence,
l'alternative et l'itération.
Séquence
ARTICLE
ARTICLE
rupture
livraison
en stock
Alternative
ABONNE
ABONNE
C1
demande
inactif
actif
prêt
non C1 ABONNE
en attente
C1: exemplaire disponible
Itération
Merise 2
69
2000/2001
non C2
STAGE
STAGE
C2
créé
complet
sélection
C2: si inscriptions = nombre places
En général les cycles de vie des objets sont interconnectés. Lors de la représentation du CVO
d'un objet (dit objet principal) on pourra représenter par une flèche pointillée les transitions
d'états sur les objets qui lui sont liés.
non C2
STAGE
STAGE
C2
créé
sélection
complet
C2
STAGIAIRE
C2: si inscriptions = nombre places
liste at ente
Figure 77 : CVO interconnectés
10.3. Etat d'objet
Nous reprenons la définition introduite précédemment :
Un état d'objet est un stade transitoire par lequel passe un objet (une entité de la
mémoire permanente) au cours de son cycle de vie.
Le CVO d'un objet comporte :
• un ou plusieurs états initiaux,
Merise 2
70
2000/2001
• un ou plusieurs états intermédiaires,
• un ou plusieurs états finaux.
Les états d'un objets sont identifiés à partir :
• de la valeur de propriétés de l'objet
Un article est mis dans l'état "stocké" si la propriété "quantité en stock" est supérieure à 0.
ARTICLE
N°article
quté stock
= 0
> 0
ARTICLE
ARTICLE
rupture
livraison
s t o c k é
• de la valeur des propriétés des objets qui lui sont liés
Une commande est dans l'état "bloquée" si la quantité en stock d'un article commandé est
inférieure à la quantité commandée.
COMMANDE
ARTICLE
1,n
COMPOSER
0,n
N°article
N°commande
quté commandée
quté stock
COMMANDE
COMMANDE
C 1
consult.
c r é é e
bloquée
stock
non
COMMANDE
C1
disponible
C1: quté stock < quté commandée
• de la valeur des états des objets qui lui sont reliés
Un stagiaire est dans l'état "liste d'attente" si le stage auquel il est candidat est dans l'état
"complet".
Merise 2
71
2000/2001
STAGIAIRE
STAGE
0,n
CANDIDAT
0,n
codestage
N°stagiaire
non C2
STAGE
STAGE
C2
créé
sélection
complet
C2
STAGIAIRE
C2: si inscriptions = nombre places
liste attente
• de ses relations ou absence de relations avec d'autres objets
Une commande est dite "en attente" si elle n’intervient pas dans la relation "livrer".
COMMANDE
LIVRAISON
0,1
LIVRER
1,1
COMMANDE
COMMANDE
livraison
en attente
livrée
faite
LIVRAISON
créée
• de la valeur des propriétés de ses relations avec d'autres objets
Un produit est dit "en rupture de stock" dans un dépôt si sa quantité en stock est inférieure à
un seuil critique.
PRODUIT
DEPOT
0,n
STOCKER
1,n
quté stock
seuil critique
non C3
PRODUIT
PRODUIT
C3
en stock
déstocké
rupture
de stock
C3 : quté stock < seuil critique
Merise 2
72
2000/2001
A chaque état d'objet ou configuration d'états il est donc important d'associer des contraintes
d'intégrités qui correspondent à des états cohérents de la structure de données. Ces contraintes
d'intégrités seront exprimées avec le CVO des objets.
Etats d'objets et sous-types
C'est généralement le caractère transitoire de l'état d'objet qui le différencie d'un sous-type.
Exemple : HOMME et FEMME sont des sous-types de PERSONNE
"célibataire", "veuf", "divorcé" sont des états de l'objet PERSONNE.
Dans un MCD il est préférable d'utiliser la spécialisation par "catégorie" c'est à dire qu'il n'y a
pas de transfert d'une occurrence d'un sous-type à un autre.
Il n'est cependant pas interdit de faire de la spécialisation par "état" c'est à dire de permettre
des transferts d'occurrence.
10.4. Spécialisation de CVO
On peut représenter le CVO d'un objet à différents niveaux de détail. C'est ainsi que dans un
premier temps nous identifierons l'état "en vente" d'un article ce qui correspond à un état
"standard" pendant un processus de vente. Cet état peut ensuite être décomposé pour mettre en
évidence des états particuliers par lequel passe cet objet durant le même processus. C'est ainsi
que nous pourrons identifier l'état "en vente normale" et "en vente soldée".
ARTICLE
date fin
date début
en vente
collection
collection
ARTICLE
date
ARTICLE
date début
date fin
en vente
début
en vente
collection
collection
normale
solde
soldée
Figure 78 : Spécialisation d’états
10.5. Variables d'état et Structures parallèles
• Variables d'état et structures parallèles
Un objet peut, à un certain moment de sa vie, être dans plusieurs états. Un logement peut être
"libre" ou "occupé" tout en étant par ailleurs "en vente", "vendu", "en location" ou "loué". Il peut
donc être intéressant de gérer plusieurs variables d'état pour un objet. L'objet admet différents
états caractérisés par la valeur de ses différentes variables.
La vie d'une variable d'état peut dépendre partiellement ou totalement de la vie d'une ou
plusieurs autres variables d'état de ce même objet. On a alors des structures parallèles dans le
CVO.
Exemple : Pour l'objet PERSONNE on s'intéresse à deux variables d'états
• V1 correspond à l'état matrimonial,
Merise 2
73
2000/2001
• V2 correspond à l'état civil.
L’événement "naissance" met la personne dans l'état "célibataire" (/V1) et "mineur (/V2). Nous
sommes dans le cas où un même événement fait passer l'objet dans deux états.
PERSONNE
naissance
célibataire
V1
PERSONNE
naissance
V2
mineur
Il est possible au niveau du MCTA de faire apparaître le fait qu'une même opération
déclenchée par le même événement modifie plusieurs variables d'état d'un objet.
Naissance
PERSONNE
célibataire V1
Prendre en compte une naissance
mineur
V2
• Les différents cas de structures parallèle
Merise 2
74
2000/2001
1er cas : un événement commun aux deux variables
C'est le cas vu précédemment ; à l'arrivée d'un événement E2 (naissance) l'objet (personne)
passe dans l'état 2 et 3 (célibataire et mineur).
PERSONNE
nais ance
Objet
Objet
célibataire
V1 Ev. E2
V1
état1
état2
PERSONNE
Objet
nais ance
V2
mineur Ev. E2
V2
état3
2ème cas : dans le CVO d'une variable, consultation de l'état d'une autre variable.
A l'arrivée de E3 (mariage), l'objet (personne) ne passe dans l'état 5 (marié) que si C1 est
vérifiée (si personne est "majeur").
C0
non
PERSONNE
PERSONNE
anniversaire
V 2
Objet
Objet
mineur
majeur
C0
Ev. E2
V 2
état3
état4
PERSONNE
C1
PERSONNE
mariage
célibataire
V 1
marié
Objet
C1
C1 : l'objet est
Ev. E3
V 1
C1 : Personne est dans
état5
dans l'état 4
l'état "majeur"
Merise 2
75
2000/2001
3ème cas : Une transition dans le cycle de vie d'une variable constitue un événement interne
qui déclenche une transition sur le cycle de vie d'une autre variable.
Autrement dit la transition état1-état2 constitue un événement interne qui fait passer l'objet A
dans un état 3. Intuitivement, le passage de l'état "mineur" à "majeur" vis à vis de la variable
"état civil", provoque le passage à l'état "électeur" de la variable "état administratif".
Merise 2
76
2000/2001
10.6. Vérification et Elaboration des CVO
Règles de vérification
Les règles suivantes sont destinées à vérifier qu'aucun événement ou état n'a été oublié dans
un CVO. Elle contribuent également à valider le MCTA en vérifiant sa complétude.
• Pour chaque objet on doit avoir :
- un événement déclenchant sa création dans un état initial,
- un événement pour chaque transition possible d'état,
- un événement qui déclenche sa transition vers un état final ou sa suppression.
Note : la création pourra être représentée par une transition sans état initial, la suppression par
une transition sans état final
• Chaque événement doit affecter au moins un objet.
• Chaque objet doit être affecté par au moins un événement.
Enchaînement des modèles (cf. page suivante)
La construction des CVO s'appuient sur le MCTA et sur le MCD. Ce processus est itératif et
les CVO permettent à leur tour d'enrichir et de valider le MCTA et le MCD.
Si le système à modéliser comporte de nombreuses règles dynamiques, il est conseillé de
commencer par les CVO.
Démarche pratique
1. Choisir un objet au cycle de vie complexe,
2. Commencer par décrire le cycle de vie "standard" de l'objet,
3. Compléter le CVO par les événements et états facultatifs qui ne font pas partie du cycle de vie
standard,
4. Définir précisément chaque état en indiquant les contraintes d'intégrité qui le caractérisent,
5. Connecter le graphe aux autres CVO,
6. Construire éventuellement des CVO spécialisés.
Merise 2
77
2000/2001
Une planche d'illustration : MCD,MCTA,CVO
PRET
0,1
0,1
EXEMPLAIRE
ABONNE
X
X
RESERVE 0,1
0,1
Demande
ABONNE
de prêt
inactif
actif
C1
en attente non C1
EXEMPLAIRE
disponible
prété
C
TRAITEMENT DEMANDE DE PRET
C et C2
C et C1
EXEMPLAIRE
prété
réservé
C
exemplaire
indisponible et
exemplaire
déjà réservé
donné
C : abonné inactif
C1 : exemplaire disponible C2 : exemple réservé
CVO partiels des objets (ne tient compte que de l’événement demande de prêt)
Merise 2
78
2000/2001
ABONNE
ABONNE EXEMPLAIRE
EXEMPLAIRE
demande C1
demande C
inactif
prêt
actif
disponible
prêt
prété
non C1
ABONNE
en
EXEMPLAIRE
C
demande
attente
réservé
prêt
Abonné inactif = pas de prêt ni de réservation, Exemplaire prêté = existe prêt
Abonné actif = existe prêt,
Exemplaire réservé = existe réservation
Abonné en attente = existe réservation,
Exemplaire disponible = pas de prêt ni de
réservation
Merise 2
79
2000/2001
Merise 2
80
2000/2001
11. Bibliographie
Les notes de ce cours sont entièrement issues de :
MERISE/2 : Modèles et Techniques MERISE avancés
Georges Panet, Raymond Letouche
Les éditions d'organisation 1994
De l'autre côté de MERISE, Système d'information et modèles d'entreprise
Yves Tabourier
Les éditions d'organisation 1986
La méthode MERISE- tome 1 : Principes et outils et tome 2 : Démarche et Pratiques
Tardieu, A. Rochfeld, E. Colleti
Les éditions d'organisation 1983
MERISE exercices
Mathelot, H. Annonay, H. Briand, M. Fruchard
Les éditions d'organisation 1990
L'essentiel sur MERISE
Dominique Dionisi
Eyrolles 1994
Parlez-vous MERISE ?
Diviné
Eyrolles
Merise 2
81
2000/2001