MERISE 2 MCC, MCD Et MCTA

MODELISATION DES SYSTEMES D’I N F O R M A T I O N S : 2022/2023
APPROCHE SYSTEMIQUE AVEC MERISE
Objectif global
Ce cours a pour objectif principal d’initier les étudiants à la conception des
applications informatiques de façon systématique (méthodique) et reproductible
(rééditable) ; en les incitant à rechercher et établir les fonctionnalités d'une application,
et à les modéliser sous forme de modèles. Pour permettre à l’étudiant une immersion
immédiate, une étude de cas détaillée et guidée sera mise en exergue afin de faciliter
l’assimilation de cette méthode.
Objectifs Spécifiques
Dans la partie sur la méthode Merise, vous découvrirez comment :
 Participer à la conception et à l'évolution des systèmes d'information dans une
organisation ;
 Représenter schématiquement les flux d'information, les données et les
traitements d'un système d'informatisation avec les extensions Merise/2 ;
 Comparer certains modèles Merise à certains diagrammes UML.
Cours dispensé par Mme IPEM Arlette, IAI-Cameroun
1
METHODE D’ANALYSE ET DE
CONCEPTION DES SI : MERISE 2
Introduction
L'analyse est le moyen permettant de faire évoluer les systèmes d'information

(mise en évidence de nouveaux besoins en informations, amélioration des
procédures, des traitements...). L'analyse du SI repose sur la modélisation. Un
modèle est une représentation simplifiée de la réalité : on ne retient que les
éléments utiles et nécessaires au système d'information. Une maison conçue
sans plan risque de présenter, une fois finie, plus d’une erreur de conception. C'est
dire toute l'importance des méthodes de conception et de développement de
systèmes d'information mises en œuvre dans l'entreprise. MERISE est l’une des
méthodes que nous nous attèlerons à comprendre et à manipuler afin de nous
permettre de construire un système d’information automatisée qui soit efficace,
flexible et adapté à l’organisation.
I. Présentation générale de la méthode Merise
Au sens informatique, l’analyse consiste d’une part à comprendre et modéliser

le fonctionnement d’un domaine de gestion d’une organisation, et d’autre part à
concevoir la solution informatique adéquate.
Il existe plusieurs méthodes de modélisation. La plus connue est la méthode
MERISE.
1.1 Historique de la méthode Merise
MERISE est un acronyme signifiant Méthode d’Étude et de Réalisation
Informatique par les Sous-Ensembles ou pour les Systèmes d’Entreprise. La
méthode Merise a comme objectif d’aider et de guider les SSII (société de service et
d'ingénierie informatique) dans leurs phases d’analyse, de conception et de
développement de l’applicatif. Issue de l'analyse systémique, la méthode Merise est
le résultat des travaux menés par René Colletti, Arnold Rochfeld et Hubert Tardieu
dans les années 1970 et qui s'inséraient dans le cadre d'une réflexion internationale,

2
autour notamment du modèle relationnel d'Edgar Frank Codd.

La méthode Merise présente comme avantage indéniable de permettre une
définition claire et précise de l’ensemble du Système d’Information et d’en définir
correctement les spécifications des utilisateurs. Rigoureuse et surtout détaillée, elle
permet notamment de concevoir un système informatique d'une façon standardisée et
méthodique. Appliquée au système d'information comptable, l'approche MERISE
repose sur la séparation de l’étude des données et de celle des traitements et propose
de décrire le système en suivant des niveaux d'analyse distincts, allant du plus abstrait
au plus concret. On parle de niveaux d'abstraction.
1.2 Caractéristique de la méthode

La méthode Merise se caractérise par :
 Une approche systémique en ayant une vue de l’entreprise en termes de
systèmes (Le système de pilotage, le système d’information, et le système opérant) ;
 Une séparation des données (le côté statique) et des traitements (le côté
dynamique) ;
 Une approche par niveaux (le niveau conceptuel, le niveau

organisationnel, le niveau logique, le niveau physique).
À la vue des insuffisances relevés dans son utilisation, des extensions ont donc
été apportées à Merise I qui forment la méthode Merise 2. Les principales évolutions
par rapport à Merise sont :
 L’utilisation des MFC avec des techniques d'affinement (raffinement) ;
 La modification des modèles de traitement (MCT-> MCTA) ;
 L’extension du MCD ;
 L’introduction des CVO.
1.3 Les 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 :
 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).

3
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.
Figure 1: Les axes de modélisation
1.4 Les axes de modélisation et les 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. Les modèles physiques
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.

4
Figure 2: Les modèles de Merise 2
NB : Ces modèles ne sont pas tous obligatoires.
Suivant le type de projet et l'étape du cycle de vie, il convient de sélectionner une partie
de ces modèles. Voici quelques exemples de configurations possibles :
 Conception de système sans répartition et de logiciel "classique » (non orienté-
objets) MC, MFC, MCD, MCTA, CVO (facultatif), MLD, MLT, Maquettes (Dans
le cas d'un "petit projet")
 Conception de système sans répartition et de logiciel orienté-objets MC, MFC,
MCD, MCTA, CVO, MOTA Maquettes + Règles de passage vers des modèles
de structuration des classes, de communication des classes, de spécification
des classes (cas de gros projet d’entreprise)

5
II. Utilisation de la méthode MERISE 2

2.1 Les modèles conceptuel
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. 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. Autrement dit, Le premier niveau, dit « conceptuel »,
décrit le « QUOI ? », c'est-à-dire ce que fait le système d'information, sa raison d'être
(quoi faire ? avec quelles données ?). Les fonctions sont décrites sans tenir compte
des contraintes matérielles ni des aspects d'organisation du travail dans l'entreprise.
Les différents modèles proposés sont :
 Le Modèle de Contexte (MC) et le Modèle 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).
Figure 3: Les modèles du niveau conceptuel
A. Le modèle de contexte (MC) et le modèle de flux

conceptuels (MFC)
1) Définition
Au niveau conceptuel, la modélisation des flux permet la représentation des

mouvements de données à l'intérieur d'un système d'information et entre le système
et le monde extérieur. Le concept fondamental ici est le message : il contribue à
décrire un flux d’activités et symbolise les rapports entre les systèmes fonctionnels
(internes et externes) à l’entreprise.

6
On distingue deux niveaux de représentation :
• le modèle (ou diagramme) de contexte ;
• le modèle (ou diagramme) de flux conceptuel qui affinent par étape le

modèle de contexte.
Cette décomposition permet, par affinements successifs, d'obtenir des sous-

systèmes formalisant les flux d'informations.
2) Les concepts utilisés
Plusieurs concepts sont liés à la modélisation conceptuelle et sont utiles à sa

compréhension et a sa matérialisation. Il s’agit : du domaine d’étude ou activité de
l’organisation ; de l’acteur et enfin du Flux d’information.
• Le domaine d’étude ou activité

Un domaine d’étude est un sous-ensemble de l’organisation dont on étudie
séparément le SI. Il représente une partie du système d'information regroupant un
ensemble d'activités réalisées par des acteurs internes. On étudie un seul domaine à
la fois de manière à mieux le cerner et dans un souci de clarté du modèle. Il est délimité
par les domaines connexes et les acteurs externes. Chaque domaine est considéré
comme « quasi-autonome » avec son propre SP, SI et SO.
Exemple : La gestion des ventes, la gestion des affaires financières, l’administration
des ressources humaines…
• Les domaines connexes

Ce ont les autres composantes du système d'information et interagissent avec le
domaine d'étude. Ils correspondent aux autres domaines d'activités de l'entreprise.
Ils ne sont représentés que s'ils échangent des informations avec le domaine d'étude.
Figure 4: Exemple Domaine d'étude’ ‘GESTION DES VENTES''

7
MODELISATION DES SYSTEMES D’I N F O R M A T I O N S :
• L’acteur
Un acteur est un émetteur ou un récepteur d’un flux d’information lié à une activité
au sein du système d’information d’une organisation. Autrement dit, Un acteur est une
entité, humaine ou matérielle, intervenant dans le système d’information.
Selon les cas, il pourrait s’agir d’une catégorie de personnes, d’un service, d’une
direction… ou du SI d’une autre organisation. Un acteur reçoit un flux d’information qui
lui permet d’agir en transformant l’information et en renvoyant un ou plusieurs autres
flux d’information à d’autres acteurs. Les acteurs sont représentés par leur rôle
(fonction, service ou direction.) dans l’activité ou domaine. Autrement dit, L’acteur
est une unité active : il fait quelque chose. Les acteurs peuvent être : • des personnes
: le client, le comptable, etc. • des services : le secrétariat, le service comptable, la
banque, etc. • des machines : un lecteur de badge qui fait office de contrôle d’entrée...
On distingue deux types d’acteurs

- Les acteurs internes qui font partie du domaine d’étude ; (Ex :
service vente, service comptable, Service de la scolarité...). Il est représenté par
une ellipse ou cercle au tracé fin et continue.
-
Nom de
l’acteur
Figure 5: Acteur interne

- Les acteurs externes ou partenaires qui ne font pas partie du domaine mais
qui effectuent des échanges avec les acteurs internes d’une organisation dans le
cadre de l’activité étudiée. (Ex : client, fournisseur, livreur ...). Un acteur externe
est représenté par un cercle ou ellipse au tracé en pointillé
Nom de
l’acteur
Figure 6: Acteur externe
Dans la notation que nous retiendrons, le nom de l’acteur est placé à l’intérieur du
cercle. Afin de faciliter la modélisation, nous pouvons utiliser un tableau appelé le
dictionnaire des acteurs qui est un tableau qui récence l’ensemble des acteurs du système
étudié ainsi que leur type et leurs caractéristiques. Tous les acteurs répertoriés ici devront
figurer dans la matrice (ou tableau) des flux
Exemple
Acteur Description Type Caractéristiques
Client Un client Externe Personne

8
Accueil L’accueil téléphonique du service Externe Service

commercial
Spécialiste Un commercial spécialiste Interne Personne
• Flux d’information
Un flux d’information désigne un transfert d’information entre deux acteurs du SI.
Il part d’un acteur source (émetteur) pour aboutir à un acteur but (ou récepteur), il
est représenté par une flèche dont l'orientation désigne le sens du flux d'information.
Ils représentent l'échange d'informations entre le domaine d'étude et une composante
extérieure ou entre deux activités du domaine (flux internes et externes).
Figure 7: Représentation d'un flux d'information
Les flux peuvent intervenir dans un ordre déterminé qu’on peut noter pour
faciliter la lecture. Cet ordre chronologique n’est pas nécessairement systématique et
n’exclut pas la simultanéité : certains flux peuvent être émis en même temps et porter
le même numéro d’ordre. Un flux peut être conditionnel dans le sens où il n’a lieu que
lorsqu’une condition est remplie. Dans ce cas on peut noter cette condition entre
guillemets « ».
Tout comme avec les acteurs, un dictionnaire de flux entre les acteurs peut
être schématisé pour une meilleure compréhension de l’activité.
Exemple
Repérer dans ce système les flux entre les acteurs en les ordonnant si c’est utile à
une meilleure compréhension de l’activité.
Le client pose sa question (1) auprès l’accueil. Cette dernière peut répondre à la
plupart des questions courantes (2), elle assure une assistance de premier niveau.
Dictionnaire des flux

Flux No Description : contenu, émetteur/récepteur
Question 1 Question du client posée l’assistante N1
Réponse 2 Réponse de niveau 1, de l’assistante au client
NB : Tous les flux répertoriés devront figurer dans la matrice des flux. Ce
dictionnaire et cette matrice des flux ne sont pas obligatoire
NB : Remarques et règles d’usages
- Un flux ne doit pas être bidirectionnel ;
- Le flux ne doit pas être réflexif ;
- Pas de flux entre des acteurs externes.

9
3) Étapes de construction du MCC
Pour sa construction, il serait judicieux de respecter les étapes suivantes :

1. La première étape de ce modèle est d'arriver à isoler le système en le
délimitant. Il s'agit donc de définir le système et les éléments externes (acteurs
externes) avec lesquels il échange des flux d'information ;
2. La seconde étape consiste à découper l'organisation en entités appelées
acteurs internes ;
3. La dernière étape est l'analyse des flux d'information, c'est-à-dire la
définition des processus.
Le respect scrupuleux de ces étapes est primordial à l’élaboration ou
schématisation de ce dernier.
4) Formalisme du MCC
Le formalisme de ce modèle repose sur la compréhension des deux modèles

qui le compose à savoir : Le modèle de contexte (MC) et modèle conceptuel de
flux (MCF).
a) Le modèle de contexte (MC)

Le modèle de contexte a pour but de représenter les flux d’informations entre
l’organisation étudiée et les acteurs externes. Il met en évidence, à un niveau très
général, les flux d'information échangés entre des acteurs externes, un domaine
d'étude et des domaines connexes. Autrement dit, c’est est le schéma qui présente
tous les flux échangés entre le système et ses partenaires. Il fait abstraction du détail
des différents acteurs internes
au domaine étudié à l’organisation pour n’en considérer qu’un seul : l’acteur interne «
Entreprise ». L’organisation ou domaine d’étude dans ce diagramme est représentée
par un rectangle.
ou nom de
l’Organisation
b)Le Modèle de flux conceptuel (MFC)
Ce modèle permet de compléter celui de contexte en décomposant

10
l’organisation en une série d’acteurs internes. C’est une représentation graphique des
acteurs et des flux échangés. Il permet de schématiser l’ensemble des acteurs
impliqués et l’ensemble des flux échangés entre eux. Il sert aussi bien à expliciter
le fonctionnement d’une entreprise qu’à permettre de l’améliorer. De plus, il est un
point d’appui pour affiner l’analyse et trouver d’autres acteurs et d’autres flux utiles au
bon déroulement de l’activité. Par conséquent, il peut permettre de détecter les
redondances ou des incohérences dans la circulation de l’information.
Flux externe (1)
Flux interne (2)
Étude de cas applicatif

Au supermarché ‘’CARREFOUR’’, quand un client s'adresse à un vendeur et
lui dit qu'il souhaite acheter un téléviseur (par exemple), celui-ci vérifie sur ordinateur
si l'article est disponible. Si ce n'est pas le cas, le vendeur informe le client de
l'indisponibilité du matériel souhaité ; sinon le vendeur remplit un bon avec les
références de l'article et le prix à payer. Le client doit alors se présenter à la caisse,
muni de ce bon. Une fois le montant à payer réglé, la caissière lui remet une facture
et un bon de sortie de stock. Un double de bon de sortie est envoyé à l'entrepôt afin
que soit apporté au magasin (au rayon "retrait des articles ») l’article acheté. Le client
se présente alors au rayon "retrait des articles", juste à côté de la caisse et présente
son bon de sortie de stock. Dès que l'article est arrivé, le magasinier tamponne le
bon de sortie : "article livré" et remet l'article acheté au client.

11
Questions
Pour assister la société CARREFOUR dans sa compréhension de l'outil à

développer, vous réaliserez un diagramme qui représente les flux liés au système
à mettre en place à travers :
a) Dressez la liste des acteurs internes et externes et des domaines connexes au

domaine d'étude ;
b) Élaborez le modèle de contexte ;
c) Élaborez le MFC correspondant.
5) Matrice des flux
Le DF peut être représenté par une matrice carrée appelée

matrice des flux. C’est une matrice qui présente en colonnes et en lignes
les acteurs intervenant dans le diagramme ; les flux sont représentés à
l’intersection des lignes et des colonnes. Elle peut être schématisée
comme suit :
Figure 8 : Matrice de flux
Exemple d’application
Reprenez l’étude de cas applicatif et schématisez sa matrice de flux.

12
B. Le Modèle Conceptuel de Données (MCD) ou Modèle

Entité- Association (MAE)
Le Modèle Conceptuel de Données (MCD) est une représentation statique du
système d’information de l’entreprise. Il a pour but de représenter de façon structurée
les données qui seront utilisées par le système d'information. Le MCD décrit la
sémantique c’est à dire le sens attaché à ces données et à leurs rapports. C’est aussi
un ensemble de concepts et de règles permettant de définir comment représenter des
informations dans un système informatique. Il est basé sur deux notions principales :
les entités et les associations, d'où sa seconde appellation de Modèle Entité-
Association (MEA). Nous commencerons par décrire le MCD originel, puis les
extensions proposées dans Merise 2.
1. Les concepts de bases utilisés
a) Les entités ou objets
Une entité est un élément concret ou abstrait qui peut être reconnu
distinctement (personne, produit, service, pays, facture…) et qui est caractérisé par sa
typicité c’est-à-dire un ensemble d’objets de même nature. Il s’agit en fait, d’un objet
identifiable et pertinent pour l’entreprise ou encore un ensemble d’objets ayant les
mêmes caractéristiques. Dotée d’une existence propre (autonome, libre.), elle est
décrite par un identifiant et une liste de caractéristiques qui lui sont spécifiques. Une
entité est représentée par un rectangle à cartouche. Le nom de l’entité est placé dans
la cartouche et est écris en MAJUSCULE : il est recommandé de choisir un nom
commun décrivant l’entité (exemple : ETUDIANT, ENSEIGNANT, MATIERE). Les
attributs prendront place dans la partie basse.
c) Attribut ou propriété
Un attribut (ou une propriété) est une information de base du SI. Elle
est une caractéristique associée à une entité ou à une association. Au niveau
de l’entité ou de l’association, chaque attribut possède un type qui définit
l'ensemble des valeurs possibles qui peuvent être choisies pour lui (entier,
alphanumérique, numerique, booléen, réel, Date…). Un attribut ne peut en

13
aucun cas être partagé par plusieurs entités ou association.
Notation
c) Identifiant ou clé primaire

Un identifiant d'une entité ou d'une association est constitué par un de ses
permet de connaître de façon sûre et unique l’ensemble des propriétés qui participent
à l’entité. Il est donc impossible que l’attribut constituant l'identifiant d'une entité ou
d’une association prenne la même valeur pour deux entités ou deux associations
distinctes. Néanmoins, certains cas particuliers peuvent exister notamment celui d’une
entité ne contenant qu’un seul attribut. Dans ce cas, cet attribut est donc forcément
l'identifiant.
NB : la notation graphique et manuelle d’un identifiant demande de le placer en

tête de liste, de le souligner et de le faire précéder d'un #. Celle avec l’applicatif se
note comme ci-dessous.
Notation
d) Cardinalités
Les cardinalités sont des couples de valeurs que l'on trouve entre chaque entité
et ses associations liées et expriment le nombre de fois ou l’occurrence(possibilité)
qu’une entité participe aux occurrences de la relation. Donc, pour une association de
2 entités, il y a 4 cardinalités à indiquer (2 de chaque côté). Les cardinalités traduisent
des règles de gestion. Ce sont des règles propres à l'organisation étudiée, qui sont
décidées par les gestionnaires et décideurs. Ces règles expriment des contraintes sur
le modèle.

14
 Cardinalité minimale
Elle est exprimée presque toujours par l’une des deux valeurs 0 ou 1. Elle traduit
combien de fois au minimum une occurrence de l’entité participe à l’association.
 Cardinalité maximale
La cardinalité maximale exprime le nombre maximum de fois qu'une occurrence
d'une entité participe à une relation.
En fait, dans la grande majorité des cas, on n’utilise que 4 combinaisons de valeurs
pour les cardinalités à savoir :
Cardinalité Symbole Description
Un(e) et un(e) 1,1 Une occurrence de la première entité peut

seul(e) correspondre à une et une seule occurrence de la
seconde entité
Un(e) ou 1, n Une occurrence de la première entité peut

plusieurs correspondre à une ou plusieurs occurrences de la
seconde entité
Au plus un(e) 0,1 Au plus une occurrence de la première entité peut

correspondre à la même occurrence de la seconde
entité
Zéro ou 0, n Une occurrence de la première entité peut être reliée a

plusieurs aucune ou plusieurs occurrences de la seconde entité.

15
e) Association ou relation
Une association (ou une relation) est une attache entre une ou plusieurs
entités. Une association est représentée graphiquement par une ellipse à cartouche
dans laquelle figure son nom, souvent un verbe à l’infinitif, à la forme passive ou bien
accompagné d’un adverbe qui caractérise le type de relation entre les entités. Notez
que l’initiale du nom de l’association est en MAJUSCULE. Une association possède
parfois des propriétés. Une association est dite binaire si elle lie 2 entités et n-aire si
elle lie n entités.
Notation
 Dimension d’une association

La dimension d'une relation est le nombre d'objets participant à l’association. Elle est
dite : récursive (ou réflexive) lorsqu’elle relie la même entité ; binaire relie deux entités,
ternaire relie trois entités, relation n aires relie n entités.

16
Association réflexive Association ternaire
Association
binaire
 Types d’association
On différencie deux types d’associations : hiérarchiques et non hiérarchiques.
- Associations hiérarchiques : associations ou d'un côté la cardinalité
maximale est à 1 et de l'autre côté la cardinalité maximale est à N.
Associations non hiérarchiques : Elles se caractérisent par les cardinalités

maximales de chaque entité égales à N. Cela veut dire qu'il n'existe pas de
dépendance entre les entités.
En résumé :

17
f) La notion d’héritage dans un MCD

L'héritage permet de définir une entité spécialisée par rapport à une entité
générale. Dans un héritage, les entités ont beaucoup de caractéristiques communes
mais sont toutefois différentes. L'entité générale est appelée entité surtype ou père,
elle est dotée de toutes les caractéristiques communes aux entités spécialisées qui
elles, sont appelées sous-type, fils ou enfant. Les entités sous-types ne disposent
que des caractéristiques qui leur sont propres.
Vous pouvez établir un lien d'héritage entre une entité générale et des entités
spécialisées. Dans un lien d'héritage, une ou plusieurs entités enfant héritent, au
niveau physique, de tout ou partie des attributs d'une entité père.
Exemple : Soit le cas d'une entreprise gérant sa comptabilité où tous les partenaires
avec lesquels elle commerce sont considérés comme des tiers. Parmi ces tiers, on
souhaite distinguer deux sous-types : les clients et les fournisseurs. En tant que tiers,
clients et fournisseurs ont des caractéristiques communes, mais ils ont aussi des
caractéristiques spécifiques telles que les conditions de règlement ou les taux de
remises. Dans un héritage, les entités Clients et Fournisseurs constituent des types
spécialisés de l'entité père Compte.
Graphiquement, vous obtiendrez le résultat suivant :
2. La réalisation d’un MCD

Principe : Réaliser un MCD demande de passer par un ensemble d’étapes
bien définies. A partir d'un cahier des charges, concevoir de manière visuelle les
différents liens qui existent entre les différentes données. Ces dernières peuvent
en deux catégories : la modélisation directe et la modélisation par analyse
(Ou indirecte)
a) La modélisation directe
Elle consiste à identifier, à partir d’une description exprimée en langage naturel, les

18
entités et les associations en appliquant les règles suivantes :

- Les noms deviennent des entités
- Les verbes deviennent des associations Exemple :
Un client reçoit une facture contenant des produits Ce qui donne la modélisation
suivante :
Le modèle obtenu par cette méthode comme le montre l’exemple ci-dessus,

est très loin de la représentation optimale et il sera nécessaire d’appliquer une
phase de validation et de normalisation (élimination des situations qui induisent des
redondances) pour aboutir à une solution satisfaisante.
b) La modélisation par analyse ou indirecte
Ici, certaines étapes doivent être respectées, mais pour un souci de

compréhension, nous les résumerons en cinq (05) étapes fondamentales. Il s’agit
de :
Étape 1 : L’identification en premier lieu de toutes les propriétés du système

d’information à analyser.
L’identification des propriétés du SI à étudier passe par l’établissement du
dictionnaire de données et de son épuration. Le dictionnaire de données est
un document essentiel à la construction du MCD car il a pour but de recenser et
collecter l’ensemble des données élémentaires (ou attributs) manipulées par le
système et se rapportant strictement au domaine étudié.
 Établissement du dictionnaire de données
C'est une étape intermédiaire qui peut avoir son importance, surtout si vous êtes
plusieurs à travailler sur une même base de données, d'un volume conséquent.
Concevoir le dictionnaire de données revient à extraire des documents en notre
possession et des entretiens effectues, l′ensemble des informations strictement
indispensables à la gestion du domaine d′activité à informatiser. Il faut faire la liste
exhaustive de toutes les données qui sont utilisées dans le cadre d’un système
d’information et leur attribuer un nom différent pour chaque champ. Toutes les
données sont recensées dans un tableau en sachant que l'on distingue 3 types de
données :

19
• Données élémentaires : Elles ne sont pas obtenues par calcul à partir d'autres
données.
Exemple : On donne la quantité, le prix de l'article, calculer le coût total… La
quantité et le prix sont des données élémentaires
• Données calculées : Elles résultent d'un calcul effectué à partir d'autres
données.
Exemple : Le coût total est une donnée calculée (= quantité * prix unitaire).
• Les données concaténées :
Elles résultent de plusieurs propriétés
Exemple : Étudiant est une donnée concaténée Étudiant (= nom, prénom, âge…)
Le dictionnaire correspond à une liste de données qui est présentée sous forme de
tableau avec les éléments suivants :
Le dictionnaire des données est un document/tableau qui regroupe toutes les
données que vous aurez à conserver dans votre base (et qui figureront donc dans
le MCD). Pour chaque donnée, il indique :
• Le nom de la donnée/propriété indiquant son nom integral

 Le code mnémonique : il s'agit d'un libellé ou une abréviation désignant une
donnée (par exemple «titre_l» pour le titre d'un livre)
 La désignation : il s'agit d'une mention décrivant ce à quoi la donnée
correspond (par exemple «titre du livre»)
 Le type de donnée :
o A ou Alphabétique : lorsque la donnée est uniquement composée de
caractères alphabétiques (de 'A' à 'Z' et de 'a' à 'z') ;
o N ou Numérique : lorsque la donnée est composée uniquement de
nombres (entiers ou réels) ;
o AN ou Alphanumérique : lorsque la donnée peut être composée à la
fois de caractères alphabétiques et numériques ;
o Date : lorsque la donnée est une date (au format AAAA-MM-JJ) ;
o Booléen : Vrai ou Faux’
o Paramètre : la valeur de la donnée est invariable
 La taille : elle s'exprime en nombre de caractères ou de chiffres. Dans le cas
d'une date au format AAAA-JJ-MM, on compte également le nombre de
caractères, soit 10 caractères. Pour ce qui est du type booléen, nul besoin de
préciser la taille (ceci dépend de l'implémentation du SGBDR).
 Et parfois des remarques ou observations complémentaires (par exemple
si une donnée est strictement supérieure à 0, etc.).
Commentaires/
Code ou
Nom de la Longueur Remarques ou
Mnémonique
N° donnée(Propriété) Nature Type observations

20
01 Identifiant du Id_Pers Elémentaire(E) AN 20

personnel
02 Total facture Tot_Fact Calculée (Ca) N 15
NB
Les données qui figurent dans le MCD (et donc dans le dictionnaire des données)
doivent être, dans la plupart des cas, élémentaires :
 Elles ne doivent pas être calculées : les données calculées doivent être
obtenues, par le calcul, à partir de données élémentaires qui, elles, sont
conservées en base. Cependant, il existe quelques cas où il s'avère pertinent
de conserver, pour des raisons d'optimisation, une donnée calculée. Par
exemple le montant d'une commande par exemple. On ne conservera
cependant pas les données calculées intermédiaires sauf en cas d'obligation
légale (c'est le cas pour un montant HT par exemple, où les composantes
peuvent d'ailleurs avoir un prix variable dans le temps). En effet, cela évite
de refaire les calculs plusieurs fois pour un résultat qui restera fixe.
 Elles ne doivent pas être composées : les données composées doivent être
obtenues par la concaténation de données élémentaires conservées en
base. Par exemple une adresse est obtenue à partir d'une rue, d'une ville et
d'un code postal : ce sont ces trois dernières données qui sont conservées et
donc qui figureront dans le MCD (et dans le dictionnaire des données).
 Épuration du dictionnaire de données

Le but de l’épuration est de nettoyer l’ensemble des attributs obtenus à l’étape
précédente, en vérifiant que chaque donnée correspond à un “fragment”
d’informations, indivisible et indépendant des autres données.
NB : IL NE FAUT AUCUNE REDONDANCE (DIRECTE OU INDIRECTE) DANS
UN DDD ÉPURÉ.
Pour ce faire il faut passer en revue, l’un après l’autre et sans ordre préétabli,
chacun des attributs du DDD et vérifier les points suivants :
• Vérifier les synonymes : la même donnée utilisée sous deux termes
différents par deux acteurs différents ;
• Vérifier les homonymes : deux données différentes utilisées sous le
même terme par deux acteurs différents ;
• Vérifier les dépendances directes : une donnée qui peut être obtenue à
partir d’autres données (exemple : prix unitaire HT, TVA, prix unitaire TTC
: une de ces données doit être épurée), ;
• Vérifier les dépendances indirectes et les données calculées : une
donnée obtenue comme totalisation ou comptage d’autres données
(exemple : nombre de factures, ou chiffre d’affaires d’un client).

21
Étape 2 : Détermination des dépendances fonctionnelles
Une dépendance fonctionnelle est une interrelation, un lien, une association,

entre deux données ou deux groupes de données. Soit A et B des attributs, une
information B dépend fonctionnellement d’une information A si et seulement si à
une seule valeur de A, il n’est possible d’associer qu’une et qu’une seule
valeur de B. On parle de Dépendances fonctionnelles directes ou
élémentaires. Autrement dit, si on connaît la valeur de A, on peut en déduire une
seule valeur de B. Mais la réciproque n’est pas vraie (si on connaît b, on ne peut
pas en déduire a). La première donnée est dite source (en ligne), et le second
but (en colonne). On note Source But soit
A B.
Une DF doit être :
 Élémentaire : C'est l'intégralité de la source (partie gauche) qui doit
déterminer le but (partie droite) d'une DF. Exemple : Si A→ C alors A, B →
C n'est pas élémentaire.
 Directe : La DF ne doit pas être obtenue par transitivité. Par exemple, si A→
B et B → C alors A → C a été obtenue par transitivité et n'est donc pas directe.
NB : En général, Toutes les propriétés d’une entité « dépendent
fonctionnellement » de l’identifiant
Exemple
La connaissance d’un numéro de sécurité sociale détermine un seul nom de
famille, celui du titulaire de ce numéro. Par contre, un prénom ne détermine rien,
car plusieurs personnes peuvent avoir le même prénom. On peut représenter cette
DF de la façon suivante :
numSecu → nomPers
Lorsqu’une information dépend fonctionnellement de plusieurs autres
informations, la dépendance fonctionnelle est dite composée. On note par un +
cette concaténation.
Exemple : Si l’on souhaite connaître la note obtenue par un étudiant à un
examen, il est nécessaire de connaître le numéro de l’étudiant, le numéro du
module, et la session qu’il passait.
Ce qui se représente : numEtudiant +numModule + numSession →
valeurNote
Dans le cas où l’information ne possède pas de dépendance, alors l’information
dépend fonctionnellement d’elle-même.
La détermination des dépendances fonctionnelles dans un MCD, se fait par la

réalisation d’une part de la matrice des dépendances fonctionnelles et d’autre
part, par celui du graphe des dépendances fonctionnelles.
a) La matrice des dépendances fonctionnelles
Une matrice des DF est un tableau faisant apparaitre horizontalement et

verticalement toutes les données recensées dans le DDD.

22
Soit l’exemple ci-dessous représentant une des factures établies par une entreprise
du nom de ‘’Au Bon Beurre’’.
La sélection des données a permis de ressortir le DDD suivant :
Commentaires/
Code ou
Nom de la donnée Longueur Remarques ou
Mnémonique
N° (Propriété) Nature Type observations
1 Nom entreprise Nom_ent A P 21
2 Adresse entreprise Adr_ent AN P 50
3 Code postal CP_ent AN P 15

entreprise
4 Ville entreprise Vil_ent AN P 30
5 Numero Client Num_Clt N E 20
6 Nom Client Nom_Clt
7 Adresse Client Adr_Clt AN E 30
8 Code postal client CP_Clt AN E 25

23
8 Ville client Vil_Clt AN E 32
10 Numero facture Num_Fact N E 10
11 Date facture Dat_Fact D E 8
12 Reference Ref AN E 25
13 Designation Des AN E 15
14 Prix unitaire P_Unit N E 50
15 Quantite Qte N E 32
16 Montant brut Mont_Brut N C 45
17 Total HT Tot_HT N C
18 Montant TVA Mont_TVA N C
19 TTC TTC N C
Taux TVA Tx_TVA N P
Explication sur le choix des données du DDD
1. La donnée ‘’Nom entreprise’’ ne prendra pour seule valeur que la valeur ‘’Au
Bon Beurre’’, raison pour laquelle elle est de type paramètre. Il en est de
même pour les données adresse entreprise, code postal entreprise et ville
entreprise ;
2. Numéro client et Numéro facture sont des données élémentaires car elles
sont calculées sur elles-mêmes. En effet, le nouveau numéro client ou d’une
facture sera égal à l’ancien numéro client ou facture + 1. C’est donc des
données élémentaires ;
3. Date Facture, Reference, Prix unitaire, sont des données élémentaires car
ne peuvent être obtenu à partir d’un calcul ;
4. Montant brut est une donnée calculée car résulte de la ‘’règle de calcul’’
entre la quantité et le prix unitaire (Prix unitaire x Quantité) ;
5. Montant TVA est une donnée calculée, qui ajoute une autre celle de taux
TVA ;
6. TTC est une donnée calculée sans problème particulier ;
7. Taux TVA est un paramètre car nous considérons que tous les produits
vendus dans cette entreprise sont vendus à un taux fixe.

24
Après épuration, il en ressort le dictionnaire final ci-dessous :

Nom de la Commentaires/
Code ou
donnée Longueur Remarques ou
Mnémonique
N° (Propriété) Nature Type observations
1 Numéro Client Num_Clt N E 20
2 Nom Client Nom_Clt A E 30
3 Adresse Client Adr_Clt AN E 30
4 Code postal client CP_Clt AN E 25
5 Ville client Vil_Clt AN E 32
6 Numéro facture Num_Fact N E 10
7 Date facture Dat_Fact D E 8
8 Reference Ref AN E 25
9 Désignation Des AN E 15
10 Prix unitaire P_Unit N E 50
Quantité Qte N E 32
Pour trouver les dépendances fonctionnelles, l’astuce est de trouver les

identifiants (clés) des entités à partir de la matrice des dépendances fonctionnelles.
Création
Pour créer cette matrice, nous nous occuperons uniquement des données
élémentaires. Il s'agit d'un tableau à 2 entrées : En ligne et en colonnes, on
inscrit les données issues du dictionnaire de données (données élémentaires
uniquement).
Méthode
Pour remplir ce tableau, on considère chaque colonne de données. On pose une
question pour chaque colonne de donnée : Pour une valeur de cette donnée, existe-
t-il une seule et unique valeur de la donnée située en ligne ? Dans l’affirmative, on

25
inscrit le chiffre 1 à l'intersection et dans la négative, on n’inscrit rien du tout.
La matrice des dépendances fonctionnelles de notre précédent exemple est le

suivant :
La règle de remplissage de cette matrice est la suivante :
Première colonne
Question : pour un n° de client existe-t-il un seul nom de client ?
Réponse : oui Chaque client possède un numéro diffèrent ; Idem pour ses
coordonnées (ville, prénom etc. …)
Seconde colonne
Question : Pour un nom de client, existe-t-il un seul n° de client :
Réponse : non Pour un nom de client, je peux avoir plusieurs n° de client
Exemple : Atangana Etienne possède le n° 1000, Atangana Annie en possède un
également : 1005. Les 2 personnes ont le même nom (Atangana). On réalise cette
opération pour toutes les données situées en colonnes.

26
Après le remplissage de toutes intersections de ladite matrice, il faut maintenant la

simplifier pour une meilleure manipulation des données.
b) Simplification de la matrice des dépendances fonctionnelles

On ne conserve pas dans le tableau les colonnes vides (suppression des colonnes
qui ne contiennent pas de 1)
S’agissant de notre exemple, le tableau deviendra après simplification :

27
Dans l'exemple, la donnée Quantité n'est pas reliée aux données têtes de colonnes ;
il s'agit donc d'une donnée qui va dépendre de plusieurs données têtes de colonnes
(dépendance fonctionnelle composée).
 Une dépendance fonctionnelle composée est de la forme : A, B à C, elle se
lit : Pour une valeur de A et une valeur de B, on a une seule valeur de C.
La donnée Quantité : Pour un N° de facture et une référence, il y a une seule quantité.
Elle se note : N° facture, référence Quantité.
 Les contraintes d'intégrité fonctionnelles (CIF)
Dans la matrice des dépendances fonctionnelles, la présence de 1 dans la ligne d'une
donnée en tête de colonne traduit la présence d'une contrainte d'intégrité fonctionnelle
entre ces deux données. Autrement dit, Une CIF est un type d'association entre 2
entités. Elle se caractérise par un 1 en cardinalité supérieure (0,1 ou 1,1) sur une
des pattes de la relation. On dit alors que la relation est porteuse d'une dépendance
fonctionnelle. Une CIF indique donc une dépendance.

28
Exemple : L'entité qui correspond à la branche du côté du 1 est parfois appelée entité
fils et l'entité correspondant à la branche du côté n est parfois appelée entité père.
Cette appellation découle de l'analogie : un fils n'a qu'un seul père, et un père peut
avoir plusieurs fils.
NB : Ce type d'association n'a jamais de propriété portée. Si vous êtes tentés de mettre
une propriété à l'intérieur de l'association, c'est soit que vos cardinalités sont fausses,
soit que la propriété devrait être dans une des entités.
La cardinalité 1,1 sur la gauche de la relation fait de la relation une CIF
c) Le graphe de dépendance fonctionnelle (GDF)

On peut également représenter une dépendance fonctionnelle à l'aide d'un
Graphe de Dépendances Fonctionnelles (GDF). Ce graphe est une représentation
graphique de l’ensemble des DF unissant les propriétés dans un domaine d’activité du
système d’information. Ces propriétés sont obtenues à partir du dictionnaire de
données du domaine.
D’après notre exemple ci-dessus, nous aurons le graphe suivant :

29
2022/2023
Étape 3 : Détermination des entités (mise en évidence des objets ou

regroupements des attributs en entités)
Pour déterminer les entités, il faut tenir comptes du graphe des dépendances
fonctionnelles. En effet, il s’agira ici, de mettre en évidence les objets ou de regrouper
les différents attributs en famille. Dans un sens général, les identifiants ou clés
retrouvés dans le GDF permettent de déduire les entités.
Dans notre exemple, chaque colonne induit la création d'une entité dont la clé primaire
est la tête de colonne.
Ce qui nous donne 3 entités : CLIENT, PRODUIT, FACTURE
Les clés primaires :
Entité client : N° client (un numéro est unique )
Entité produit : référence
Entité facture : N° facture
CLIENT PRODUIT FACTURE
# Num _Clt # Ref # Num _Fact
Étape 4 : Détermination des associations
Elles sont déduites suivant les objets qu’elles lient ou sont construites à partir des
dépendances fonctionnelles composées. Toute dépendance fonctionnelle composée
induit la création d'une association dont les branches sont reliées aux entités contenant
les différentes données clés primaires de l'association

30
Ex : dans notre exemple, N° facture, référence Quantité est une association dont
les branches sont reliées aux entités Facture et Produit, dont les clés primaires sont
N° facture et référence.
Transformation du GDF en MCD Règles de transformation
R1 : les données sources d'au moins une DF (celles qui sont soulignées sur le GDF)
représentent les identifiants des entités dont les attributs sont les cibles de ces DF.
R2 : Les flèches restantes deviennent des associations. Les données déterminées par
une DF conjointe deviennent des attributs portés par l’association.
R3 : Les règles de gestion doivent permettre de trouver les cardinalités.
FACTURE
Correspondre PRODUIT
# Num _Fact Quantité
# Reference
Date_Fact
Désignation
Prix_Unit
Dans l’exemple, la ligne N° client (qui est également une donnée en tête de colonne),
contient un 1 dans la colonne N° facture. Ceci se traduit par l'existence d'une CIF entre
N° Facture et N° Client Cette CIF se lit de la façon suivante : POUR UNE FACTURE,
IL Y A UN CLIENT.
Représentation de la CIF :
(1,1) (1, n)
FACTURE CLIENT
Recevoir
# Num _Fact # Num _Clt
CIF
Étape 5 : Détermination des cardinalités à partir des règles de gestion établies
Le modèle conceptuel finale est le suivant :
FACTURE (1, n) (0, n)

Contenir PRODUIT
# Num _Fact
# Reference
Date_Fact
Désignation
Prix_Unit
(1,1) (1, n) CLIENT

Correspondre
Quantité
# Num _Clt
Nom_Clt
Adr_Clt
CP_Clt
Vill_Clt

31
Exercice : Étude de cas applicatif
TAF : Représentez le MCD correspondant de notre étude applicative de ce cours

en suivant les étapes de sa construction.
C. Le Modèle Conceptuel de Traitement Analytique (MCTA)

Dans le modèle Merise, le M.C.T. est appelé « Modèle Évènement-Résultat »
: L’arrivée d’un ou plusieurs évènements va déclencher une opération qui va produire
un résultat. Il met en évidence la logique et la dynamique des traitements opérés sur
les données. Ici, on répond à la question « Quoi ? »
Dans l’extension avec Merise 2, le MCTA permet de faire le lien entre les données
(provenant du MCD) et les traitements.
1. Concepts de base et représentation schématique

Le MCTA se déduit du MFC dans la mesure où il représente un zoom sur ce
dernier. Son principe consiste à "ouvrir" chaque domaine ou sous domaine identifié
par le MCC de façon à définir les opérations faites dans ce domaine. Autrement dit,
ici, on représente comment un acteur de l’organisation réagit quand il reçoit un
message et quelle(s) opération(s) il effectue. Le vocabulaire de ce modèle de
traitements est le suivant :
Événement : c’est une sollicitation du système Un évènement est représenté par une ellipse. On y
d’information qui génère une réaction de la part de inscrit le nom de l’événement.
celui-ci. Un événement peut être externe au
domaine étudié (ex : commande client) ou interne
au SI, souvent le résultat d’un processus antérieur Nom del’évènement
(ex : ordre de préparation). Un événement peut-
être aussi temporel, c'est-à-dire lié à des dates qui
rythment l’exécution de certains traitements (délai
de maintenance, relances…).
Opération : c’est un ensemble d’actions Une opération est représentée par une boîte. On
accomplies par le système d’information en inscrit le nom de l’opération en en-tête, au besoin les
réaction à un événement ou à une conjonction tâches réalisées au cours de l’opération et le ou les
d’événements et non interruptibles par un états possibles de l’opération au sortir de celle-ci (au
événement externe. Remarque : Une opération moins 1 état).
déclenche au moins un résultat. Une opération est
représentée par un verbe ou mieux un substantif Numéro
(ex : Préparer la commande ou préparation de la opération Opération
commande).
Une opération est représentée par un verbe ou mieux Tâches
un substantif (ex : Préparer la commande ou
préparation de la commande)

32
Résultat : un résultat est un événement au sortir

d’une opération. Ce peut être un document, un
message externe, un nouvel état du SI (nouvelle
situation, nouvelles données), créé par une Résultat
opération. Un résultat externe représente une
information envoyée à l’extérieur du SI (ex. :
facture) Un résultat interne est un nouvel état du
système d’information (ex. : ordre de préparation).
Synchronisation : c’est une condition, portant sur

les événements, nécessaire au déclenchement
d’une opération. Une synchronisation n’est requise
qu’en présence de plusieurs événements
déclencheurs, ce sans quoi le symbole de
synchronisation est laissé blanc. Au besoin, on
numérote les événements (a, b, c …) constitutifs
de l’expression booléenne (ex : (a ET b) OU c).
Règle d’émission : condition traduisant les Prise en compte

règles de gestion, qui permet d'exprimer une d'une commande
condition de sortie de résultat ou une condition
requise pour qu’une action ait lieu. OK Produit conditions d'émission
non disponible des messages
Les conditions d’émissions peuvent être
nombreuses. Une condition d’émission peut
donner lieu à plusieurs résultats. Parmi ces
conditions, nous pouvons avoir : cde absence
à livrer produit
- Toujours (Tjrs) : L'opération est à
chaque fois réalisée ;
- OK : Si le résultat de l’opération est bon
- Non OK : Si le résultat de l’opération
n’est pas bon.
Objet : Un objet correspond à une entité ou une Un objet est représenté par une boîte comportant en
association du MCD correspondant au champ en-tête le nom de l’objet (i.e. de l’entité ou de
d’étude du SI. l’association), et son état avant et après action.
Objet
État avant État après

33
Action : une action est une manipulation

(création, consultation, modification ou
suppression) d’un objet du système d’information.
Elle est symbolisée par un trait entre l’opération
et l’objet manipulé.
Représentation schématique du MCTA
Pour élaborer un M.C.T. il faut :
 Éliminer
tous les évènements organisationnels (qui, quand, quoi, où,
comment) ;
 Repérer les évènements déclencheurs et les résultats ;
 Ordonner les opérations (ordre chronologique) ;

34
 Repérer les règles de synchronisation et d'émission.
En général, les flux d'informations se trouvant dans le modèle de flux sont les
évènements déclencheurs ou résultants des différentes activités.
Exemple simplifié d'un diagramme événement-résultat
Exemple d’application
Reprenez l’étude de cas applicatif et schématisez le MCTA correspondant.

35

MERISE 2 MCC, MCD Et MCTA

Transféré par

Informations du documentcliquez pour développer les informations du document

Droits d'auteur :

Formats disponibles

MERISE 2 MCC, MCD Et MCTA

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MERISE 2 MCC, MCD Et MCTA

Transféré par

Droits d'auteur :

Formats disponibles

MODELISATION DES SYSTEMES D’I N F O R M A T I O N S : 2022/2023

APPROCHE SYSTEMIQUE AVEC MERISE

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

L'analyse est le moyen permettant de faire évoluer les systèmes d'information

I. Présentation générale de la méthode Merise

Au sens informatique, l’analyse consiste d’une part à comprendre et modéliser

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

autour notamment du modèle relationnel d'Edgar Frank Codd.

1.2 Caractéristique de la méthode

 Une approche par niveaux (le niveau conceptuel, le niveau

1.3 Les axes de modélisation de merise 2

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

Exemple : On s'intéresse au traitement des commandes. Dans ce cadre on

Figure 1: Les axes de modélisation

1.4 Les axes de modélisation et les niveaux d’abstraction

Merise 2 offrent différents modèles permettant de représenter les aspects

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

Figure 2: Les modèles de Merise 2

NB : Ces modèles ne sont pas tous obligatoires.

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

II. Utilisation de la méthode MERISE 2

Figure 3: Les modèles du niveau conceptuel

A. Le modèle de contexte (MC) et le modèle de flux

Au niveau conceptuel, la modélisation des flux permet la représentation des

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

On distingue deux niveaux de représentation :

• le modèle (ou diagramme) de contexte ;

• le modèle (ou diagramme) de flux conceptuel qui affinent par étape le

Cette décomposition permet, par affinements successifs, d'obtenir des sous-

2) Les concepts utilisés

Plusieurs concepts sont liés à la modélisation conceptuelle et sont utiles à sa

• Le domaine d’étude ou activité

• Les domaines connexes

Figure 4: Exemple Domaine d'étude’ ‘GESTION DES VENTES''

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

On distingue deux types d’acteurs

Figure 5: Acteur interne

Figure 6: Acteur externe

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

Accueil L’accueil téléphonique du service Externe Service

Figure 7: Représentation d'un flux d'information

Dictionnaire des flux

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

3) Étapes de construction du MCC

Pour sa construction, il serait judicieux de respecter les étapes suivantes :

Le formalisme de ce modèle repose sur la compréhension des deux modèles

a) Le modèle de contexte (MC)

b)Le Modèle de flux conceptuel (MFC)

Ce modèle permet de compléter celui de contexte en décomposant

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

Flux externe (1)

Flux interne (2)

Étude de cas applicatif

Cours dispensé par Mme IPEM Arlette, IAI-Cameroun

Pour assister la société CARREFOUR dans sa compréhension de l'outil à

a) Dressez la liste des acteurs internes et externes et des domaines connexes au

b) Élaborez le modèle de contexte ;

c) Élaborez le MFC correspondant.