Cours MERISE AIAC 2P

Méthode de Conception des
Systèmes d’Information
MERISE
Filière GI – Semestre 3
Badr EL HATIMI
badr_elhatimi@yahoo.fr
Académie Internationale Mohammed VI de l'Aviation Civile
Plan du module
Les systèmes d’information
Notion de système d’information (SI) – Approche systémique – Cycle
de vie d’un SI.
La méthode MERISE
Généralités – Les cycles d’abstraction de conception d’un SI – Les flux
d’information – Les données – Les traitements - Les modèles statiques
et dynamiques.
Modélisation des flux
Définition de l’organisation – Diagramme de contexte – Diagramme de
flux.
Description statique du SI
Concepts de base – Concepts étendus – Règles de construction d’un
modèle conceptuel de données (MCD) – Modèle logique de données
(MLD) – Modèle physique de données (MPD).
Description dynamique du SI
Concepts de base : Acteur, événement, opération, règle d’émission,
synchronisation - Règles de construction d’un modèle conceptuel de
traitements (MCT) – Modèle organisationnel de traitement (MOT).
Etudes de cas et pratique d’un outil de conception graphique
2
(PowerAMC)
1
Chapitre 1
Les Systèmes d’Information
Au commencement était …
Méthode de Conception des Systèmes
d’Information d’organisation – La méthode
MERISE.
2
Un peu de vocabulaire ...
Contexte ? L’organisation :
On englobe sous ce terme l’ensemble des

structures socio-économiques qui existent :
les entreprises publiques, semi-publiques,
privées,
les administrations,
les établissements publics,
les associations...
Un peu de vocabulaire ...

Un Système est un ensemble d’éléments,
matériels ou humains, transformant des
éléments en entrée en éléments en sortie, et
dont la modification d’un composant entraîne
la modification d’une partie, ou de l’ensemble
du système.
Éléments Éléments
Système
en entrée en sortie
3
Les sous-systèmes d’une organisation
La définition du système d'information est
issue de la théorie des systèmes ou
systémique.
Ainsi, une organisation peut être modélisé
comme comportant trois sous systèmes :
le système de pilotage (ou de décision) (celui
qui réfléchit, décide, oriente),
le système opérant (celui qui produit,
transforme, agit),
and last but not least : le système
d'information.
7
Systèmes d’Information (SI)

Le système de pilotage (ou de décision) décide des
actions à conduire sur le système opérant en fonction
des objectifs et des politiques de l’entreprise.
Le système opérant englobe toutes les fonctions
liées à l’activité propre de l’entreprise : GRH, Gestion
commerciale, Gestion des stocks …
Le système d’information sélectionne les
informations pertinentes dans le système opérant,
les traite pour fournir des informations synthétiques
au système de pilotage qui peut alors renvoyer des
directives au système opérant.
4
Systèmes d’Information (SI)
Environnement:
Clients,
Fournisseurs,
Employés,
Actionnaires…
[ ZEMMARI 05]
9
Système d’information : une définition

Un Système d’Information (SI) est
l’ensemble des moyens techniques et
humains, et des méthodes, qui permettent le
traitement des informations au sein d’une
organisation et dans ses rapports à son
environnement.
Le SI a deux rôles principaux :
1. recueillir, mémoriser et diffuser les
informations,
2. assurer le traitement de ces informations.
10
5
Système d’information Vs Système
Informatique
On distinguera dans le SI :
• le système d'information organisationnel (SIO) la partie
visible, basée essentiellement sur des ressources
humaines, de l'activité organisée.
• le système d'information informatisé (SII) correspondant
au contenu informatisé du SI (logiciel, base de données)
SIO SI Automatisable SI Informatisé
11

Informatique : un exemple
Un SI comptable dont le rôle est de
transformer les pièces comptables en des
résultats comptables.
Pièces Résultats
SI Comptable
comptables comptables
12
6
Informatique : un exemple
La transformation des écritures comptables
en résultats comptables est informatisée, par
contre la transformation des pièces
comptables en écritures comptables
comporte des actions impliquant une décision
et donc une intervention de l'humain.
Pièces SI Comptable Écritures SI Comptable Résultats

comptables non informatisé comptables informatisé comptables
13
Processus d’informatisation du SI
Parmi les informations qui appartiennent au
système d’information, certaines doivent ou
peuvent faire l’objet d’un traitement
automatisé grâce aux outils informatiques.
Un projet d’informatisation du SI a pour
objectif de construire une application
informatique support d'un système
d'information informatisé, inclus dans un
système d'information organisationnel.
14
7
MERISE dans tout ceci ?
Pour assurer la cohérence du système
d’information, la méthode MERISE propose
une démarche d’informatisation ayant pour
principe de base que l'on ne peut pas
construire un SII sans comprendre au
préalable le SIO dans lequel on l'implante.
15
Encore du vocabulaire : La méthode

Une Méthode recouvre trois choses :
1. Une démarche : ensemble coordonné d'étapes, de
phases et de tâches indiquant le chemin à suivre
pour conduire un projet, ici, la conception d'un SI.
2. Une modélisation : des raisonnements et des
techniques nécessaires à la construction de l'objet
projeté.
3. Des moyens de mise en œuvre, en l'occurrence une
organisation de projet et des outils.
16
8
Pourquoi une méthode ?
Le développement de logiciels dans un

contexte professionnel suit souvent des
règles strictes encadrant la conception
et permettant le travail en groupe et la
maintenance du code. Ainsi, une
nouvelle discipline est née : le génie
logiciel.
17

L’importance d’une approche méthodologique s’est
imposée à la suite de la crise de l’industrie du
logiciel à la fin des années 1970. Cette crise était
principalement due à :
1. l’augmentation des coûts ;
2. les difficultés de maintenance et d’évolution ;
3. la non fiabilité ;
4. le non respect des spécifications ;
5. le non respect des délais.
Le génie logiciel 4 objectifs : encadrer la
conception / réduire les coûts et les délais /
permettre le travail en groupe / assurer la 18
maintenance du code.
9
Dans le domaine de l’ingénierie du logiciel, utiliser une
méthode (Exemple MERISE) permet de :
mieux répartir les tâches et d’automatiser certaines
d’entre elles;
réduire les coûts et les délais;
assurer un bon niveau de qualité et une maintenance
efficace. En effet, une fois mise en production,
l’application va devoir être maintenue, probablement
par une autre équipe et, qui plus est, pas
nécessairement de la même société que celle ayant
créée l’application.
19
Vocabulaire suite et fin : Conception
[F. TCHENAR2006]
10
Maintenant on comprend mieux
Méthode de Conception des Systèmes
d’Information d’organisation – La
méthode MERISE :
Méthode d’Étude et de Réalisation Informatique
pour les Systèmes d’Entreprise
21
Chapitre 2
La méthode MERISE
Généralités
11
MERISE : Les points forts
La méthode est apparue dans les années 70 et s’est
généralisée dans les années 80 et 90.
La méthode s'appuie sur une approche systémique :
C’est donc une approche globale.
Elle est fortement adaptée aux grands projets
d’informatisation de SI.
Les concepts sont peu nombreux et simples.
Elle est très indépendante vis à vis de la technologie.
Elle reste un standard de fait dans les pays
francophones dans les domaines de gestion.
Elle sert de référence aux enseignements sur les
méthodes de conception des SI. 23
MERISE : La critique
Les méthodes traditionnelles, dont MERISE,
composées d’étapes séquentielles depuis
l’analyse du besoin jusqu’à la recette,
présentent l’inconvénient d’être rigides et peu
réactives. Ainsi, le temps écoulé entre les
spécifications et la phase de livraison est
parfois tellement important que les besoins
ont entre-temps changé de nature.
24
12
MERISE : Les points faibles
Elle ne s'occupe pas de l'interface utilisateur.
Elle est très adaptée à un contexte de création
d'application mais pas forcément à un problème
de maintenance ou de ré-informatisation.
Elle ne permet pas une validation rapide de la
part des utilisateurs.
Il est très difficile de valider les traitements par
rapport aux données et cela au niveau
conceptuel ou organisationnel.
25
Cycles de vie d’un logiciel

Le génie logiciel s’intéresse particulièrement à
la manière dont le code source d’un logiciel est
spécifié puis produit. Ainsi, le génie logiciel
s’intéresse au cycle de vie des logiciels :
l’analyse du besoin,
l’élaboration des spécifications,
la conception,
le développement,
la phase de test,
la maintenance.
26
13
Modèles de cycle de vie
La séquence et la présence de chacune de
ces activités dans le cycle de vie dépend du
choix d’un modèle de cycle de vie entre le
client et l’équipe de développement.
Le cycle de vie permet de prendre en
compte, en plus des aspects techniques,
l’organisation et les aspects humains.
On parle de cycle de vie en cascade, en V,
en spirale, séquentiel, incrémental, itératif …
27
Modèle de cycle en cascade

Dans ce modèle le principe est simple : chaque
phase se termine à une date précise par la
production de certains documents ou logiciels.
Les résultats sont définis sur la base des
interactions entre étapes, ils sont soumis à une
revue approfondie et on ne passe à la phase
suivante que s’ils sont jugés satisfaisants.
L’inconvénient majeur du modèle de cycle de
vie en cascade est que la vérification du bon
fonctionnement du système est réalisée trop
tardivement : lors de la phase d’intégration ou
lors de la mise en production.
28
14
Modèle de cycle en cascade
La méthode
MERISE est basé
sur un cycle de
vie en cascade.
Ce modèle est
séquentiel. Il n’est
ni incrémental ni
itératif.
29
MERISE - Cycle de vie d’un système

d’information
PHASES DU CYCLE
OBJECTIFS PRINCIPAUX
DE VIE
Définition, de manière globale, la politique
1. Schéma directeur d’organisation et d’automatisation du SI
2. Étude préalable ou Élaboration globale des différentes solutions
Analyse Évaluation des diverses conséquences
Spécification complète du futur SI en deux phases:

3. Étude détaillée ou - conception générale (extension du champ
Conception d'analyse du sous-ensemble du domaine)
- conception détaillée (traitement à effectuer)
Traduction informatique des spécifications issues

4. Étude technique de l'étude détaillée
Traduction dans des langages appropriés des

5. Codage spécifications et vérifications de leur conformité
30
15
MERISE - Cycle de vie d’un système
d’information
PHASES DU CYCLE
OBJECTIFS PRINCIPAUX
DE VIE
Installation des logiciels, mise en service
progressive du système d’information:
6. Mise en service - réception définitive du système
- fonctionnement de leur conformité
Prise en compte des évolutions ultérieures au
lancement opérationnel liées:
7. Maintenance - au progrès technique
- à la modification de l'environnement
- aux utilisateurs
Constat d'évolutions trop importantes pour
relever d'une simple maintenance ayant pour
origine:
8. Remise en cause - l'ancienneté de l'application
- l'obsolescence technologique
- un changement important dans l'activité ou
dans les principes de l'organisation 31
Données – Traitements – Flux

La méthode MERISE est basée sur la séparation des
données et des traitements à effectuer :
La séparation des données et des traitements assure
une longévité au modèle. En effet, l'agencement des
données n'a pas à être souvent remanié, tandis que
les traitements le sont plus fréquemment.
On dira statique en parlant des données et
dynamique pour les traitements.
La méthode MERISE traite aussi les flux
d’information entre acteurs au sein du SI.
32
16
Les 4 niveaux d’abstraction
MERISE définit 4 niveaux d’abstraction :
1. Le niveau conceptuel qui décrit la statique et la
dynamique du SI en se préoccupant uniquement du
point de vue du gestionnaire Quoi ?
2. Le niveau organisationnel décrit la nature des
ressources qui sont utilisées pour supporter la
description statique et dynamique du SI. Ces
ressources peuvent être humaines et/ou matérielles
et logicielles Qui ? Où ? Quand ?
3. Le niveau logique dans lequel on choisit les
techniques d’implantation du système d’information (
données et traitements) Comment ?
4. Le niveau physique concerne la réalisation (le
codage). 33
Les modèles MERISE

Données Traitements Flux
conceptuel
MCD : signification des MCT : activité du

Niveau
MCF : relations
Système d'information
informations sans domaine sans préciser les

entre le domainee et le
contraintes techniques ou ressources ou leur
reste du SI
économiques organisation
organisationnel
MOD : signification des MOT : fonctionnement

Niveau
informations avec du domaine avec les MOF : relations

contraintes techniques ou ressources utilisées et leur entre les acteurs
économiques organisation
MLT : fonctionnement du
Système d'information
MLD : description des

logique
Niveau
domaine avec les MLF : relations

données en tenant compte de
ressources utilisées et leur entre les systèmes
informatisé
leurs conditions et des

organisation informatiques
techniques de mémorisation
informatique
Physique
Niveau
MPD : description de la ou MPT : Architecture

MPF : supports
des BD dans la syntaxe du technique des
techniques des flux
SGF ou du SGBD programmes 34
17
Étude préalable
35
Étude détaillée
36
18
Étude détaillée : Conception
Deux phases s’enchaînent lors de la
conception :
1. La Conception Générale donnant une
description fonctionnelle complète du futur
SI Dossier de Conception Générale
2. La Conception Détaillée donnant une
description complète (et vérifiée) du futur SI
dans l’environnement cible Dossier de
Conception Détaillée
37
La phase de Conception Générale

1. Analyse de l’existant
2. Modélisation des flux (Diagramme de
contexte - MCC)
3. Modélisation des données (MCD)
4. Modélisation des traitements (MCT)
5. Validation & Revue
38
19
Niveau Conceptuel
L'objectif du niveau conceptuel est de représenter
l'activité de l'entreprise et de formaliser son SI
indépendamment de son organisation. Trois modèles :
1. Le MCC formalise les échanges d'informations entre
acteurs et domaines.
2. Le MCD est la référence de l'activité de l'entreprise, la
manière dont elle perçoit et mémorise son activité. Il
formalise toutes les informations.
3. Le MCT formalise les traitements effectués par un
système fonctionnel, comment l'entreprise réagit à une
réception d'informations, ou quand, spontanément, elle
décide d'émettre des informations.
39

contexte - MCC)
40
20
Analyse de l’existant
Définition de l’Organisation
De quelle entreprise s ’agit-il ? Quels sont :
Quels sont ses objectifs ? ses activités spécifiques ?
Déterminer la structure qui ses produits ?
prend les décisions ses matières premières
(fournisseurs) ?
ses clients ?
Critique du SI existant.
Techniques : Interviews – Colleecte et Analyse des
documents – Benchmarking. 41

contexte - MCC)
42
21
Chapitre 3
Modélisation des flux
Modèle Conceptuel de
Communication
Plusieurs noms : Modèle Conceptuel de
Communication (MCC), Modèle Conceptuel
de Flux (MCF) ou Diagramme de Flux.
Le diagramme de flux permet de :
Modéliser le système opérant de l'entreprise,
Identifier les unités actives qui échangent des
flux d'information dans le système,
Analyser les flux entre ces unités.
Délimiter les domaines du système.
Deux concepts : Les Acteurs et les Flux.
44
22
Communication : Acteur
Un Acteur représente une unité intervenant dans le
fonctionnement du système. Il est interne ou externe
au système. Il peut modéliser :
♦ Un partenaire extérieur à l'entreprise (client,
fournisseur),
♦ Un domaine d'activité de l'entreprise (comptabilité,
gestion du personnel),
♦ Un ensemble d'activités (liquidation, contrôles),
♦ Un élément structurel de l'entreprise (service,
département).
45
Communication : Flux
Un Flux représente un échange entre un
acteur émetteur et un acteur récepteur. On
peut distinguer trois types de flux:
♦ Flux physique (marchandises, matériaux),
♦ Flux financier (chèque, virement),
♦ Flux d'information ou flux logique qui peut être
verbal, documentaire ou informatique. C’est
ce dernier type de flux qui nous intéresse lors
d’une démarche d’informatisation.
46
23
Communication : Interne / Externe
Acteur externe : entité externe à
l’organisation ou au domaine étudié.
Acteur interne : appartient à l’organisation ou
au domaine étudié.
47
Communication : Interne / Externe
48
24
Formalisme graphique
49
Diagramme de contexte
Acteur 1
Info 1
ORGANISATION Info 2
Acteur 2
Info n
Acteur n
Le diagramme de contexte a pour but de représenter les

flux d'informations (avec leur sens) entre l'organisation et
les acteurs externes selon une représentation standard
dans laquelle chaque objet porte un nom.
Le diagramme de contexte permet de définir le SI dans 50
son environnement.
25
Communication (MCC)
Ce diagramme permet de compléter le
diagramme de contexte en décomposant
l'organisation en une série d'acteurs internes.
Acteur 3
Info 1
ORGANISATION
Acteur 1 Info 2
Acteur 4
Info 3
Acteur 2 Info 4
Acteur 5
51
Communication (MCC)
Exemple d’une agence commerciale :
AGENCE
3 Demande d’achat
6 Copie Bon de Commande
Agent Achat Agence Régional
4 Achat
1 Demande de devis
5 Bon de commande
2 Devis
Fournisseur
52
26
Exemple
53
Exemple
54
27
Matrice des Flux
55
Matrice des flux
56
28
contexte - MCC)
57
Modélisation des données :

Modèle entité-association
29
Modèle Entité - Association
Le MCD se base sur le modèle entité –
association ( ou entité – relation) a été
formalisé par l'américain Peter CHEN, à la suite
d'une publication intitulée "The Entity-
Relationship Model" en 1976.
Ce modèle est très proche du modèle
relationnel qui est à la base des principaux
SGBD du marché (SGBDR) comme , ORACLE,
SQL Server, MySQL, PostgreSQL…
59

La méthode MERISE constitue depuis le
milieu des années 80 un standard de fait
dans la conception des SI en France et dans
les pays francophones.
Le modèle entité-association est la norme
retenu par l’ISO (International Standard
Organization) pour décrire les aspects
conceptuels statiques dans la conception des
SI.
60
30
Le modèle entité-association est constitué de
trois éléments de base :
1. Les informations ou données.
2. Les entités, qui sont des regroupements
d'informations, et possèdent des attributs
(caractéristiques).
3. Les associations qui sont les liens logiques
entre les entités (et sont quantifiées par des
cardinalités).
61
MCD : Modèle Entité – Association

Les Entités
Définitions :
On désigne par entité tout objet (concret ou
abstrait) du domaine identifiable et pertinent
pour le Système d’Information.
Chaque entité représente un individu-type
auquel correspond une ou plusieurs
occurrences dans le domaine.
Une Entité Type (ET) est la représentation
d’un ensemble d’entités perçues comme
similaires et ayant les mêmes
caractéristiques.
62
31
Les Entités
Formalisme MERISE :
LIBELLE_ENTITE
63

Exemple
Exemple : Société InfoPower
Gestion des commandes
N°Commande : C112/05 Date : 14/09/05
Nom Client : Compagnie Industrielle du Gharb
Adresse : 20 Avenue Med V, KENITRA
Nom Représentant : ZITOUNI Hassan
N°Facture : 88/05 Date : 23/11/05
REF DESIGN N°Commande
QTE : C112/05
IN143 PC DELL PIV Nom Client
15 : Compagnie Industrielle du Gharb
IN213 IMP Laser HP A4 5: 20 Avenue Med V, KENITRA
Adresse
REF DESIGN QTE PU MONTANT

IN143 PC DELL PIV 15 8000 120000
IN213 IMP Laser HP A4 5 2000 10000
64
TOTAL : 130000
32
Les Entités
Occurrences
Entité Type
Compagnie Industrielle du Gharb
CLIENT 20 Avenue Med V, KENITRA
ZITOUNI Hassan
Grands Moulins Saïs

43 Bd. Hassan II, FES
BENNIS Amina
65

Les Entités
CLIENT ARTICLE COMMANDE FACTURE
66
33
Les Associations
Comment exprimer :
Un client passe une commande?
Une facture contient plusieurs produits?
Une facture est liée à une commande?
ASSOCIATION
67

Les Associations
Définition :
Une Association est un lien logique entre
plusieurs entités du même type.
Un Association Type (AT) est la
représentation d’un ensemble d’associations
ayant la même sémantique et décrites par
les mêmes caractéristiques.
68
34
Les Associations
Formalisme MERISE :
ENTITE 1 ENTITE n
libellé de
l’association
ENTITE 2
69

Les Associations
commande
facture
CLIENT COMMANDE ARTICLE FACTURE
passe commande facture

commande article article
70
35
Propriétés
Définition :
La propriété (ou attribut ou rubrique) est
une information élémentaire, c’est-à-dire
non déductible d’autres informations, qui
présente un intérêt pour le domaine étudié.
Une propriété caractérise une entité ou une
association.
Exemple : Un CLIENT est caractérisé par
Nom Client, Adresse et Nom Représentant.
71

Propriétés
Formalisme MERISE :
ENTITE 1 ENTITE n
P1 Libellé_association P1
P2 P2
… LibellePropriete
…
ENTITE 2
P1
P2
… 72
36
Propriétés
com_fact
NomClient NCommande Ref NFacture

Adresse DateCommande Design DateFacture
Representant PU
passe_com com_article fact_article
QuantCommandee QuantFacturee
73

Propriétés
Remarque :
Une propriété est atomique Simple et
Monovaluée
Propriété Simple non composée d’autres
propriétés
Propriété Monovaluée ne peut prendre
qu’une seule valeur par occurrence
(cardinalité max = 1)
74
37
Propriétés
Remarque :
Une propriété est atomique Simple et Monovaluée
Propriété Simple non composée d’autres propriétés
Propriété Monovaluée ne peut prendre qu’une seule valeur
par occurrence (cardinalité max = 1)
CLIENT CL232
SOMID
CodeClient Casablanca
NomClient 022546712, 022546742, 022546783
AdresseClient
TelClient
75

Propriétés
Remarque :
Une propriété est atomique Simple et Monovaluée
Propriété Simple non composée d’autres propriétés
Propriété Monovaluée ne peut prendre qu’une seule valeur
par occurrence (cardinalité max = 1)
CLIENT TELEPHONE
CodeClient telephone_client Telephone
NomClient
AdresseClient
76
38
Identifiants d’une Entité
Règle de distinguabilité :
Chaque occurrence d’entité représente un
individu clairement différencié des autres
dans le S.I.
Définition :
L'identifiant est une propriété particulière
d'une entité telle qu'il n'existe pas deux
occurrences pour lesquelles cette propriété
prenne une même valeur.
Exemple : Une facture est identifiée par le
77
N°Facture.

Formalisme MERISE :
LIBELLE_ENTITE
Libelle_Id1
Libelle_Id2
Libelle_P1
Libelle_P2
…
78
39
Généralisation :
L’identifiant d’une entité est un ensemble
minimum de propriétés tel qu’il n’existe pas
deux occurrences qui ont les mêmes valeurs
pour ces attributs.
EMPLOYE
# Nom
# Prenom
DateNaissance
SituationFam
DateRecrutement
79

EMPLOYE EMPLOYE
# Nom # CodeEmploye
# Prenom Nom
DateNaissance Prenom
SituationFam DateNaissance
DateRecrutement SituationFam
DateRecrutement
Identifiant naturel Vs Identifiant abstrait

80
40
Remarques :
Une entité peut avoir plusieurs identifiants.
Identifiant primaire / secondaire
Chaque entité doit avoir au moins un identifiant.
OUVRAGE
Cote est l’identifiant
Cote
primaire et ISBN un
ISBN
Titre
identifiant secondaire.
Auteur
Editeur
81

Identifiant d’une Entité
com_fact

Representant PU
82
41
Cardinalité d’un Association
La cardinalité d'une relation est composé
d'un couple comportant une borne maximale
et une borne minimale, intervalle dans
lequel la cardinalité d'une entité peut prendre
sa valeur:
la borne minimale (0 ou 1) décrit le nombre
minimum de fois qu'une entité peut participer
à une relation.
la borne maximale (1 ou n) décrit le nombre
maximum de fois qu'une entité peut participer
à une relation.
83

84
[ CNAM - DI GALLO 01]
42
CLIENT COMMANDE
NomClient passe_com NCommande

Adresse DateCommande
Representant 0,n 1,1
• Un client peut ne pas passer • Une commande est toujours

de commande (client potentiel) passée par un client
• Un client peut passer au plus • Une même commande est
n commande passée au plus par un seul client
85

com_fact
1,1 1,1

Representant PU
1,n 0,n 0,n 1,n

0,n 1,1
86
43
Les cardinalités n’expriment pas une vérité absolue,
mais des choix de conception. Elles doivent
correspondre aux règles de gestion du SI.
Exemple : État Civil
Mariage monogame (e.g. Europe occidentale) :
HOMME FEMME
marier
0,1 0,1
87

Mariage polygame polygyne (e.g. Islam) :
HOMME FEMME
marier
0,4 0,1
88
44
Mariage polygame polyandre (e.g. Esquimaux) :
HOMME FEMME
marier
0,1 0,n
89

Dimension d’une Association
Une association reliant la même entité type
est dite réflexive (ou récursive ou cyclique).
Une association reliant deux entités types est
dite binaire.
Une association reliant trois entités types est
dite ternaire.
Une association reliant n entités types est dite
n-aire.
90
45
Association Réflexive
Dans le cas des associations réflexives, il faut
indiquer les rôles pour lever d’éventuelles
ambiguïtés.
0,1 (compose)
PIECE
NPiece compose
Libelle
0,n (se compose)
91

Association n-aire
ASSUREUR
CodeAssur
0,n
police
CLIENT VEHICULE
0,n Prime 1,1
CodeClient CodeVehic
92
46
Notions étendues MERISE 2
Généralisation / Spécialisation
Exemple :
Employé : N°Employé – Nom – Prénom –
Adresse
Employé mensuel : Date d’Entrée – Salaire
Mensuel
Employé vacataire : Date début vacation –
Durée vacation – Coût horaire
93

Solution 1 :
PERSONNEL • Respecte le formalisme de
base
NEmploye
Nom • Propriété supplémentaire :
Prenom
Catégorie
Adresse
Categorie
• Toutes les propriétés ne sont
DateEntree
SalaireMensuel pas pertinentes pour toutes les
DateDebutVacation occurrences
DureeVacation
CoutHoraire Solution pas complètement
satisfaisante 94
47
Solution 2 :
PERSONNEL_MENS PERSONNEL_VACAT
UEL AIRE
NEmploye NEmploye
Nom Nom
Prenom Prenom
Adresse Adresse
DateEntree DateDebutVacation
SalaireMensuel DureeVacation
CoutHoraire
• Respecte le formalisme de base

• Redondance des propriétés 95

Solution 3 : PERSONNEL
NEmploye
Nom
Prenom
Adresse
MENSUEL VACATAIRE
CoutHoraire
96
48
Entité
Mécanisme d’héritage Générique
Héritage simple Liste des
propriétés
communes
Entité Entité
Spécialisé A Spécialisé B
Liste des Liste des
propriétés propriétés
spécifiques spécifiques
97

Entité Entité
Générique A Générique B
Entité
spécialisé
Mécanisme d’héritage
Héritage multiple
98
49
Les contraintes ensemblistes
Dans l’exemple précédent comment
exprimer:
Un employé doit être soit vacataire ou
mensuel.
Un employé ne peut pas être vacataire et
mensuel à la fois.
Concept de contraintes ensemblistes
99
Notions étendus MERISE 2

La contrainte d’Inclusion (notée I) entre deux
ensembles A et B impose que l’ensemble A soit inclus
dans l’ensemble B.
La contrainte de Totalité (notée T) porte sur trois
ensembles A, B et C et impose que l’union de A et de B
soit égale à C.
La contrainte d’exclusion (notée X) entre deux
ensembles A et B impose que l’intersection entre A et B
soit vide.
La contrainte d’Égalité (notée =) entre deux ensemble A
et B impose que l’ensemble A soit égal à l’ensemble B.
La contrainte du Ou exclusif (notée +) porte sur trois
ensembles et est la combinaison d’une exclusion et d’une
100
totalité.
50
Exemple : Contrainte de Totalité entre deux
sous-types [DI GALLO – 01]
101

Exemple : Contrainte du Ou exclusif entre
deux sous-types [DI GALLO – 01]
102
51
Les contraintes ensemblistes portent
sur les entités mais aussi sur les
associations.
103

Exemple : Contrainte d’Exclusion entre deux
associations [DI GALLO – 01]
Règle de gestion exprimée : Un auditeur ne
peut être inscrit à un module qu’il possède
déjà.
104
52
Exercice
On veut représenter le personnel d'une entreprise et son
affectation. L'entreprise est organisée en services auxquels est
affecté le personnel. Chaque service est décrit par son nom, son
chef (qui est nécessairement un cadre de l'entreprise) et la liste de
ses locaux. Le personnel est réparti en trois catégories, les
administratifs, les techniciens et les cadres. Tous possèdent un
numéro d'employé, un nom, un prénom, une adresse, une
identification bancaire (nom banque, nom agence, numéro de
compte), un salaire et sont rattachés à un service. Chaque
catégorie possède en outre des renseignements qui lui sont
propres:
pour un administratif ou un technicien, le prix de l'heure
supplémentaire;
pour un technicien, les machines dont il est responsable;
pour un administratif, le(s) cadre(s) pour le(s)quel(s) il travaille;
pour un cadre, son bureau, son numéro de poste téléphonique105et
l'(les) administratif(s) (s'il en existe) qui lui est (sont) attaché(s).
Construction du Modèle Conceptuel

de Données
53
Étape 0 : Recueil des informations
Interviews des différents postes de travail du
S.I.
Rassembler des exemplaires de tous les
documents utilisés.
Collecter les descriptions de tous les fichiers
en usage dans le domaine.
107
Étape 0 : Recueil des documents et

interviews
Société InfoPower
Domaine étudié : Gestion des commandes
Document 1 : Exemplaire de commande
N°Commande : C112/05 Date : 14/09/05

REF DESIGN QTE

IN143 PC DELL PIV 15
IN213 IMP Laser HP A4 5
108
54
Étape 0 : Recueil des documents et
interviews
Document 2 : Exemplaire de facture
N°Facture : 88/05 Date : 23/11/05

N°Commande : C112/05
REF DESIGN QTE PU MONTANT

IN143 PC DELL PIV 15 8000 120000
IN213 IMP Laser HP A4 5 2000 10000
TOTAL : 130000
109
Étape 1 : Expliciter les Règles de

Gestion
Règles de Gestion (RG) : règles régissant les
activités de l’entreprise (domaine) :
disposition légale, règle de travail, règlement
interne, exigence formulée par le client …
Les règles de gestion permettent de
renseigner le MCD (e.g: Un employé
n’appartient qu’à un seul service à la fois) ou
de le compléter (e.g.: formules de calcul).
110
55
Gestion
RG 1 : Un client peut passer une, plusieurs
ou aucune commande.
RG 2 : Une commande peut concerner un ou
plusieurs produits.
RG 3 : Une commande est passée à un
représentant qui est le même pour un client
donné.
RG 4 : Une facture correspond à une seule
commande.
111

Gestion
Une règle de gestion n’exprime pas une
réalité absolue, aussi un même processus
peut donner lieu à des règles différentes
selon les organisations. Exemple : génération
des factures à partir des commandes :
RG 5 : A une commande ne correspond
qu’une seule facture.
RG 5’: Une commande peut être éclatée en
plusieurs factures.
112
56
Étape 2 : Constitution du dictionnaire
de données
N°Bon ………………. Date ………...…………..
Nom Client ………………………….............................…
Adresse …………………………………..............………..
………………………………………………………………..
Nom Représentant ……………………….……..…………
Réf Design. Qte PU Montant
Total
113
Information
L'information ou la donnée est un
"renseignement" ou une "connaissance"
élémentaire désignée à l'aide d'un mot ou
d'un groupe de mots et prenant des valeurs.
L’information doit être pertinente c’est-à-dire
qu’elle présente un intérêt pour le domaine
étudié.
Pour une informatisation réussie, l’information
devra être cernée et classifiée de manière
très précise dans le dictionnaire de données.
114
57
Les catégories d’informations
les informations élémentaires : on ne peut pas
déduire sa valeur. Pour pouvoir s’en servir, on doit
connaître sa valeur ( exemple : le nom d’un employé
).
les informations paramètres : un paramètre est une
rubrique dont la valeur est constante et prévisible.
On peut estimer que sa valeur est connue et la
même pour tout et pour tous ( exemple : un taux de
TVA connu et identique pour tous les articles ).
les informations calculées ou résultantes : elles
sont obtenues par un traitement arithmétique ou
logique.
les informations composées : informations
obtenues par composition d’informations
élémentaires.
115
Autres classifications
On retrouve aussi les classifications
suivantes :
interne ou externe,
quantitative ou qualitative,
permanente ou temporaire.
116
58
Le mode de représentation des
données
Il s’agit ici de déterminer de quel type seront
les données utilisées par le programme
alphabétique pur
alphanumérique
numérique
date
logique Booléen …
On détermine par la même occasion la taille
de l’information.
117
Le recensement des données

Le recensement des informations est le préalable
absolu à toute démarche d’automatisation. Il existe
2 méthodes :
1. la méthode ascendante : très pratique pour une
nouvelle informatisation ; elle consiste à étudier
toutes les sorties à obtenir et à remonter vers les
données nécessaires à l’obtention des résultats
figurant sur ces sorties.
2. La méthode descendante : à utiliser sur un
système existant ; elle consiste à recenser toutes les
informations du système rencontrées sur les divers
documents en service et à y ajouter les nouvelles
données nécessaires aux nouveaux traitements.
118
59
Étape 2 : Constitution du dictionnaire de
données
Le recensement des informations et de leurs
catégories permet de constituer le
Dictionnaire des Données (ou Lexique des
Données).
Il s’agit d’un tableau recensant l’ensemble
des informations rencontrées lors de
l’analyse préalable ou permettant de
répondre aux objectifs du système
d’information et mentionnant parfois la
classification de l’information, son mode de
représentation ainsi que sa longueur.
119

données
On attribue un nom (normalisé de préférence) pour
chacune des informations identifiées.
On précisera si l’information est obligatoire ou
facultative.
On y inscrira également :
les contraintes d’intégrité ( par exemple les limites
minimales et maximales d’une donnée, les relations
entre dates …),
les règles de calcul pour les informations calculées et
la description des informations composées.
le format d’affichage (par exemple pour les dates) …
120
60
données
N°Bon ………………. Date ………...…………..
Nom Client ………………………….............................…
Adresse …………………………………..............………..
………………………………………………………………..
Nom Représentant ……………………….……..…………
Réf Design. Qte PU Montant
Total
121
Contraintes d’intégrité
Nom Signification Type* Obligatoire Nature ** / Règles de calcul /
Format
NBon N° bon de commande N Oui E
Date Date de commande D Oui E jj/mm/aa
NomClient Nom du client A Oui E
Adresse Adresse du client A Oui CO N° + Rue + Ville
NomRepr Nom du représentant A Oui E
Ref Référence du produit A Oui E 2 Lettres + 3 Chiffres
Design Libellé du produit A Oui E
Qte Quantité commandée N Oui E Entier > 0
PU Prix unitaire N Oui E 9999,99
Montant Montant ligne N Oui CA PU * Qte
Total Total commande N Oui CA Somme des montants
* N : Numérique / A : Alphanumérique / D : Date

** E : Élémentaire / CO : Composée / CA : Calculée
122
61
Étape 2 : Constitution du dictionnaire
de données
A la fin de cette étape nous avons obtenu un
dictionnaire de données brut, recensant
toutes les informations du SI.
Ces informations seront les futures propriétés
des entités et des associations du MCD.
123
Étape 3 : Épuration du dictionnaire de

données
Phase 1 : Éliminer les synonymes et les polysémes.
Dans le dictionnaire de données brut, on trouvera
des synonymes et des polysémes.
Un synonyme : deux signifiants pour un même signifié.
Exemple : TVA et Taxe, Code Client et NClient On
ne gardera qu’un seul nom et on éliminera les autres.
Un polyséme : un signifiant pour deux signifiés.
Exemple : Nom pour Nom de client et Nom de
fournisseurs On changera les noms.
Après cette étape, on obtiendra un dictionnaire des
données épuré des polysémes et des synonymes
pour que tout le monde parle le même langage.
124
62
Étape 3 : Épuration du dictionnaire de
données
Phase 2 : On supprimera les rubriques
composées comme ADRESSE qui est
composée de NUMERO, RUE, VILLE. La
suppression des informations composées se
fait par éclatement ou par concaténation.
On supprimera également les rubriques
calculées.
On ne conservera que les rubriques
élémentaires. On obtiendra ainsi un
dictionnaires des données élémentaires.
125
Contraintes d’intégrité
Nom Signification Type Obligatoire Nature / Règles de calcul /
Format
Adresse Adresse du client A Oui CO N° + Rue + Ville
Montant Montant ligne N Oui CA PU * Qte
Total Total commande N Oui CA Somme des montants
126
63
Contraintes d’intégrité /
Nom Signification Type Obligatoire Nature Règles de calcul /
Format
Adresse Adresse du client A Oui E Obtenue par concaténation
On obtient ainsi le dictionnaire de données élémentaires épuré.
127
Étape 4 : Recherche des entités

Définitions :
On désigne par entité tout objet (concret ou
abstrait) du domaine identifiable et pertinent
pour le Système d’Information.
Chaque entité représente un individu-type
auquel correspond une ou plusieurs
occurrences dans le domaine.
Une Entité Type (ET) est la représentation
d’un ensemble d’entités perçues comme
similaires et ayant les mêmes propriétés.
128
64
Définition :
La propriété (ou attribut ou rubrique) est une
information élémentaire issue du dictionnaire de
données élémentaires.
Exemple : Un CLIENT est caractérisé par Nom
Client, Adresse et Nom Représentant.
Les propriétés d’une entité doivent être atomiques
Simple : non composée d’autres propriétés
Monovaluée : ne peut prendre qu’une seule valeur par
occurrence.
129

Formalisme MERISE :
LIBELLE_ENTITE
Propriété 1
Propriété 2
…
Propriété n
130
65
Société InfoPower
Occurrences
Entité Type
Compagnie Industrielle du Gharb
CLIENT 20 Avenue Med V, KENITRA
ZITOUNI Hassan
NomClient
Adresse Grands Moulins Saïs
Representant 43 Bd. Hassan II, FES
BENNIS Amina
131

Representant PU
132
66
Étape 5 : Recherche des identifiants
des entités
Règle de distinguabilité :
Chaque occurrence d’une entité représente un
individu clairement différencié des autres dans le S.I.
Chaque entité doit posséder au moins un identifiant.
Définition 1 :
L'identifiant d’une entité est un ensemble de
propriétés tel qu'il n'existe pas deux occurrences
différentes de l’entité pour lesquelles cet ensemble
prenne la même valeur.
Exemple : Une facture est identifiée par le N°Facture.
133

des entités
Formalisme MERISE :
LIBELLE_ENTITE
Libelle_Id1
Libelle_Id2
Libelle_P1
Libelle_P2
…
134
67
des entités
Définition 2 :
L’identifiant d’une entité est un ensemble
minimum de propriétés tel qu’il n’existe pas
deux occurrences qui ont les mêmes valeurs
pour ces propriètés.
EMPLOYE
# Nom
# Prenom
DateNaissance
SituationFam
DateRecrutement
135

des entités
EMPLOYE EMPLOYE
# Nom # CodeEmploye
# Prenom Nom
DateNaissance Prenom
SituationFam DateNaissance
DateRecrutement SituationFam
DateRecrutement
(Nom, Prenom) est dit identifiant naturel s’il existe

dans le SI avant informatisation.
CodeEmploye est dit identifiant abstrait s’il est créé
pour les besoins de l’informatisation du SI.
136
68
des entités
Remarques :
Une entité peut avoir plusieurs identifiants
Dans ce cas il faut distinguer l’identifiant
primaire ou principal et des identifiants
secondaires.
OUVRAGE
Cote
Cote est l’identifiant
ISBN
primaire et ISBN un
Titre
Auteur
identifiant secondaire.
Editeur 137
Étape 6 : Recherche des associations

Comment exprimer :
Un client passe une commande?
Une facture contient plusieurs produits?
Une facture est liée à une commande?
ASSOCIATION
138
69
Définition :
Une Association est un lien logique entre
plusieurs entités du même type.
Un Association Type (AT) est la
représentation d’un ensemble d’associations
ayant la même sémantique et décrites par
les mêmes caractéristiques.
Comme pour les entités, les associations sont
caractérisées par des propriétés.
139

Formalisme MERISE :
ENTITE 1 ENTITE n
P1 Libellé_association P1
P2 P2
… LibellePropriete
…
ENTITE 2
P1
P2
… 140
70
com_fact

Representant PU
Qte
141
Étape 7 : Ajout des cardinalités aux

associations
La cardinalité d'une association est
composée d'un couple comportant une borne
maximale et une borne minimale.
la borne minimale (prend la valeur 0 ou 1)
décrit le nombre minimum de fois qu'une
occurrence d’entité peut participer à
l’association.
la borne maximale (prend la valeur 1 ou n)
décrit le nombre maximum de fois qu'une
occurrence d’entité peut participer à
l’association. n indiquant plusieurs fois.
142
71
associations
143
[ CNAM - DI GALLO 01]

associations
CLIENT COMMANDE
NomClient passe_com NCommande

Adresse DateCommande
Representant 0,n 1,1
• Un client peut ne pas passer • Une commande est toujours

de commande (client potentiel) passée par un client
• Un client peut passer au plus • Une même commande est
n commande passée au plus par un seul client
Les cardinalités sont spécifiées grâce aux règles

de gestion. 144
72
associations
com_fact
1,1 1,1

Representant PU
1,n 0,n 0,n 1,n

0,n 1,1
Qte
145

associations
Mariage monogame (e.g. Europe occidentale) :
HOMME FEMME
marier
0,1 0,1
146
73
associations
Mariage polygame polygyne (e.g. Islam) :
HOMME FEMME
marier
0,4*** 0,1
147

associations
Mariage polygame polyandre (e.g. Esquimaux) :
HOMME FEMME
marier
0,1 0,n
148
74
associations
On parle d’association un-à-un dans le cas
où toutes les cardinalités de l’association sont
de type (0,1) ou (1,1).
On parle d’association plusieurs-à-plusieurs
dans le cas où toutes les cardinalités de
l’association sont de type (0,n) ou (1,n).
Dans les autres cas on parle d’association
un-à-plusieurs.
149
Compléments : Dimension d’une

Association
Une association reliant la même entité type
est dite réflexive (ou récursive ou cyclique).
Une association reliant deux entités types est
dite binaire.
Une association reliant trois entités types est
dite ternaire.
Une association reliant n entités types est dite
n-aire.
150
75
Association
Dans le cas des associations réflexives, il faut
indiquer les rôles pour lever d’éventuelles
ambiguïtés.
0,1 (compose)
PIECE
NPiece compose
Libelle
0,n (se compose)
151

Association
ASSUREUR
CodeAssur
0,n
police
CLIENT VEHICULE
0,n Prime 1,1
CodeClient CodeVehic
152
76
Compléments : Traitement des
propriétés multivaluées
Propriété est dite multivaluée si elle peut prendre
plusieurs valeurs par occurrence d’entité.
Exemple : TelClient de l’entité CLIENT.
CLIENT CL232
SOMID
CodeClient Casablanca
NomClient 022546712, 022546742, 022546783
AdresseClient
TelClient
153
Compléments : Traitement des propriétés

multivaluées
On crée une nouvelle entité qui aura comme propriété la
propriété multivaluée (dans l’exemple TelClient) et
éventuellement un identifiant artificiel (dans l’exemple Id).
Puis on crée une association de type un-à-plusieurs entre les
deux entités.
CLIENT TELEPHONE
CodeClient telephone_client Id
NomClient TelClient
AdresseClient
(- , n) (- , 1)
154
77
Extension du Modèle Entité-

Association :
Généralisation-Spécialisation

Exemple :
Employé : N°Employé – Nom – Prénom –
Adresse
Employé mensuel : Date d’Entrée – Salaire
Mensuel
Employé vacataire : Date début vacation –
Durée vacation – Coût horaire
156
78
Solution 1 :
PERSONNEL • Respecte le formalisme de
base
NEmploye
Nom • Propriété supplémentaire :
Prenom
Catégorie
Adresse
Categorie
• Toutes les propriétés ne sont
DateEntree
SalaireMensuel pas pertinentes pour toutes les
DateDebutVacation occurrences
DureeVacation
CoutHoraire Solution pas complètement
satisfaisante 157

Solution 2 :
PERSONNEL_MENS PERSONNEL_VACAT
UEL AIRE
NEmploye NEmploye
Nom Nom
Prenom Prenom
Adresse Adresse
CoutHoraire
• Respecte le formalisme de base

• Redondance des propriétés 158
79
Solution 3 : PERSONNEL
NEmploye
Nom
Prenom
Adresse
MENSUEL VACATAIRE
CoutHoraire
159

Entité
Mécanisme d’héritage Générique
Héritage simple Liste des
propriétés
communes
Entité Entité
Spécialisé A Spécialisé B
Liste des Liste des
propriétés propriétés
spécifiques spécifiques
160
80
Entité Entité
Générique A Générique B
Entité
spécialisé
Mécanisme d’héritage
Héritage multiple
161

Dans l’exemple précédent comment
exprimer:
Un employé doit être soit vacataire ou
mensuel.
Un employé ne peut pas être vacataire et
mensuel à la fois.
Concept de contraintes ensemblistes
162
81
La contrainte d’Inclusion (notée I) entre deux
ensembles A et B impose que l’ensemble A soit inclus
dans l’ensemble B.
La contrainte de Totalité (notée T) porte sur trois
ensembles A, B et C et impose que l’union de A et de B
soit égale à C.
La contrainte d’exclusion (notée X) entre deux
ensembles A et B impose que l’intersection entre A et B
soit vide.
La contrainte d’Égalité (notée =) entre deux ensemble A
et B impose que l’ensemble A soit égal à l’ensemble B.
La contrainte du Ou exclusif (notée +) porte sur trois
ensembles et est la combinaison d’une exclusion et d’une
163
totalité.

Exemple : Contrainte de Totalité entre deux
sous-types [DI GALLO – 01]
164
82
Exemple : Contrainte du Ou exclusif entre
deux sous-types [DI GALLO – 01]
165

Les contraintes ensemblistes portent
sur les entités mais aussi sur les
associations.
166
83
Exemple : Contrainte d’Exclusion entre deux
associations [DI GALLO – 01]
Règle de gestion exprimée : Un auditeur ne
peut être inscrit à un module qu’il possède
déjà.
167

contexte - MCC)
168
84
Modèles de Traitements
Traitements
Modèle Conceptuel de Traitements

Les traitements constituent la partie
dynamique d’un SI. Ils décrivent les actions
à exécuter sur les données pour arriver aux
résultats attendus par l’organisme.
Les traitements ne sont en fait que la
traduction en actions des règles de gestion
qui composent l’activité de l’organisme.
170
85
Exemple : Règle de Gestion « Une
commande ne sera satisfaite que si la
quantité commandée est inférieure à la
quantité en stock ».
Cette règle se traduit par les traitements :
1. Lire la quantité commandée,
2. Comparer la quantité commandée avec la
quantité en stock,
3. Si la quantité commandée est supérieure à
la quantité en stock alors rejeter la
171
commande sinon continuer.

Définition : Le MCT est une représentation
schématique de l’activité ou d’un sous-
ensemble de l’activité d’une entreprise
indépendamment des choix d’organisation
et des moyens d’exécution.
Le Quoi sans le Qui ni le Comment.
172
86
Concepts MCT : Processus
Le processus constitue un sous-ensemble de
l’activité de l’entreprise dont les points d’entrée et
de sortie sont stables et indépendants des choix
d’organisation.
Exemple :
Commande Gestion Facture

acceptée des Factures établie
173
Concepts MCT : Processus

Un processus est constitué d’un ensemble
d’opérations au sein du même domaine.
Exemple : Si on considère le domaine gestion

des stocks on trouvera les opérations :
Approvisionnement / Déstockage / Inventaire …
174
87
Concepts MCT : Opération
•Un processus comporte un nombre important de
traitements qu’il convient de regrouper en
ensembles plus élémentaires appelés opérations.
•Une opération représente l'ensemble des actions
que le domaine peut effectuer à partir des
informations fournies par un ou plusieurs
événements et de celles déjà connues dans la
mémoire du système d'information.
•Une opération est constituée d’actions qui sont
exécutables sans interruption.
175
MCT : Formalisme d’une opération

Événements déclenchants
Conditions Synchronisation
d’exécution
Désignation de l’Opération
Actions de l’Opération
Conditions d’émissions des résultats
176
Résultats
88
MCT : Exemple
Commande Ouvrage
(ext 1)
ext1
Traitement de la commande
Stock Stock
Insuffisant Suffisant
Demande Facture 177

réapprovisionnement (int1) (int 2)

Lors de son exécution une opération ne peut pas être
interrompue par l’attente d’un événement externe.
L’exécution d’une opération se ramène à l’exécution
d’actions élémentaires effectuées sur la base
d’informations à partir des données portées par le ou les
événement(s) déclencheur(s).
Ces actions élémentaires portent sur des occurrences
d’entités ou d’associations du MCD et peuvent appartenir à
l’un des quatre types suivants :
- Création
- Modification
- Suppression
- Consultation 178
89
1. Rq 1 : La logique d’enchaînement des actions
élémentaires n’est pas toujours séquentielle et peut faire
intervenir des structures alternatives (Si .. Alors … Sinon)
ou itératives (Tant que …, Répéter …, Pour …).
2. Rq 2 : Il est possible d’associer à une opération une
durée qui représente le temps maximal qui lui est alloué
pour qu’elle s’exécute.
179
Concepts MCT : Événement

Un événement est un flux de nature quelconque
ou un fait qui contribue au déclenchement d'une
opération ou qui est provoqué par cette opération.
L'événement indique que quelque chose s'est
passé et que le système d'information doit réagir.
180
90
On distingue trois types d’événements :
1. Événement (déclencheur) externe : sont des
événements émis par un acteur externe (en dehors du
domaine / processus) et qui déclenche une opération.
2. Événement (ou résultat) interne : événement produit
en sortie d’une opération et déclencheur d’une autre
opération à l’intérieur du processus. Un événement
interne n’a lieu d’être que si le compte rendu de la fin
d’une opération doit être suivi d’une nouvelle réaction du
système d’information
3. Résultat externe : évènement résultat destiné à sortir du
processus et ne peut être déclencheur d’une autre
opération. 181

L’événement est soit intra-processus (
résultat et déclencheur d’une opération dans
un même processus) ou extra-processus (
résultat d’une opération dans un processus et
déclencheur d ’une opération d’un autre
processus).
182
91
Processus : Ouverture compte bancaire
183
MCT : Formalisme d’une opération

Événements déclenchants
Conditions Synchronisation
d’exécution
Désignation de l’Opération
Actions de l’Opération
Conditions d’émissions des résultats
184
Résultats
92
Concepts MCT : Règles d’émission
Une condition d’émission ou règle d’émission

est la condition sous laquelle des événements sont
produits par une opération. Une opération peut
avoir une ou plusieurs règles d'émission, chacune
émettant un ou plusieurs événements.
Une règle d'émission appartient à une seule
opération à la fois mais il n'est pas obligatoire
qu'une opération soit dotée d'une règle d'émission.
Dans ce cas, la production d'un événement est
inconditionnelle.
185
MCT : Exemple
Commande Ouvrage
(ext 1)
ext1
Traitement de la commande
Stock Stock
Insuffisant Suffisant
Demande Facture 186

réapprovisionnement (int1) (int 2)
93
Concepts MCT : Synchronisation
La synchronisation d’une opération (ou
conditions d’exécution) est composée de deux
éléments :
- d’une part la liste des événement (internes ou
externes) qui doivent être arrivés avant de
déclencher l’opération.
- et d’autre part la règle sous forme d’une
proposition logique qui précise de quelle manière
les événements participent au déclenchement de
l’opération.
187

Synchronisation d’une opération : Exemple :
Par exemple, pour modéliser le déclenchement de la mise
à jour d’un dossier incomplet suite à la réception des pièces
manquantes, on introduira une synchronisation admettant
en entrée les deux événements suivants :
Événement int2 : « Dossier D Mis en attente le
JJ/MM/AAAA »
Événement ext2: « Réception des pièces manquantes du
dossier D »
Proposition logique : int2 ET ext2
188
94
Un client non
satisfait peut
retourner un article.
On lui fait un
"avoir". Il peut alors
le présenter en
caisse pour être
remboursé de son
achat. Il peut
encore remplacer
l'article défectueux
par un autre,
auquel cas on
189
annule l'avoir.
Cas particulier : Cycle

Cycles : pour une même opération, un événement
déclencheur et un événement résultat sont identiques.
190
95
Formalisme PowerAMC
191
Construction d’un MCT : Biblio

Dans une bibliothèque, l’opération d’emprunt
ne peut se déclencher que si l’exemplaire est
disponible. L’employé de la bibliothèque fait
remplir à l’adhérent une fiche d’emprunt. Dés
que le livre est disponible, il inscrit une ligne
d’emprunt sur la fiche du livre. L’exemplaire
est alors envoyé à l’adhérent. Lorsque le livre
est de retour, l’employé raye la ligne
d’emprunt correspondante sur la fiche du livre
et stocke celui-ci, il redevient disponible.
192
96
Fonctionnement du modèle dynamique
193
Fonctionnement du modèle dynamique

L’arrivée d’un événement externe dans le système
d’information provoque l’apparition d’une occurrence
nouvelle pour cet événement. On appelle jeton cette
occurrence d’événement. Une synchronisation, lorsqu’elle
est en attente, devient activable, lorsque la proposition
logique associée et les conditions locales deviennent
vraies par l’arrivée d’un nouveau jeton. Lorsque la
synchronisation est activée, il y a consommation d’un ou
de plusieurs jetons par événement qui a contribué à rendre
vrai le prédicat et les conditions locales de synchronisation.
La synchronisation déclenche le démarrage de l’opération
qui s’exécute et qui provoque l’apparition d’un ou de
plusieurs jetons supplémentaires dans tous les
événements en sortie de l’opération pour lesquels la règle
d’émission est vérifiée.
194
97
Fonctionnement du modèle dynamique :
Erreur de modélisation
Une telle conception
entraînerait
la consommation de
l’événement « Ecriture
définitive » lors de la
première « Demande
de consultation ». Ceci
implique qu’une
écriture ne sera
consultée qu’une seule
fois.
195
Fonctionnement du modèle dynamique :

Erreur de modélisation
Pour corriger ceci on

devra supprimer de la
synchronisation
l’événement
« Ecriture définitive ».
196
98
Evénement consommable
197
L’utilisation d’un événement consommable
permet d’exprimer qu’un événement interne
peut être candidat au déclenchement de
plusieurs opérations.
Dans l’exemple « Proposition » est candidat
au déclenchement de « Ouvrir police » ou
« Annuler proposition » mais jamais des deux
à la fois.
Ceci est possible à la condition que les
événements « Accord client » et « Fin
validité » n’arrivent pas simultanément. 198
99
Démarche classique de
construction du MCT
On construit le MCF (Acteurs / Flux).
On identifie les processus à partir du MCF.
Les flux identifiées seront les événements
déclencheurs et résultats des traitements des
processus.
On établit le graphe d’enchaînement (par
processus).
On construit le MCT du processus.
199
Démarche classique de construction du MCT

Etape 1 : MCF
200
100
Etape 2 : Découpage en processus
Trois processus identifiables :
Facturation
Vente
Livraison
On choisit par la suite de construire le MCT du

processus « Vente »
201

Etape 4 : Graphe d’enchaînement
Demande d’achat
Commande Proposition
Double de la Vente Bon de livraison

commande
202
101
Etape 5 : Construire le MCT
A partir du graphe d’enchaînement on établit
une première version du MCT.
Comment ?
1. Les flux sont transformés en événements
(déclencheurs ou résultats).
2. Les arcs sont remplacés par des opérations.
Le MCT ainsi construit est ensuite enrichi en
tenant compte des règles de gestion.
203
204
102
MCT : Résumé
205
Modèle Logique de
Données : MLD
103
Modèle Logique de Données
Le MCD a permis de représenter le plus
fidèlement possible les réalités du SI à
informatiser. Mais cette représentation ne
peut pas être directement manipulée et
acceptée par un système informatique. Il est
donc nécessaire de passer du niveau
conceptuel à second un niveau plus proche
des capacités des systèmes informatiques et
plus précisément des Systèmes de Gestion
de Bases de Données (SGBD).
207

Tout SGBD est construit sur un modèle
logique de données
208
104
Il existe différents modèles :
1. Modèle Réseau
2. Modèle Hiérarchique
3. Modèle Relationnel (Oracle, SQL Server,
MySQL…) Standard de fait - 90% du marché des
SGBD
4. Modèle Objet Futur ?
Le modèle logique associé à la méthode MERISE
est le modèle relationnel. Aussi par abus de
langage parle t-on de Modèle Relationnel de
Données (MRD) au lieu de Modèle Logique de
Données (MLD).
209
Modèle Relationnel
Concepts de Base
Le domaine de valeurs : Ensemble
d’instances d’un type élémentaire caractérisé
par un nom : Les domaines sont les
ensembles dans lesquels les données
prennent leurs valeurs.
Les domaines de valeurs peuvent être défini
en intention (Entier, Réel, Alphanumérique
…) ou en extension (Couleur {Rouge, Blanc,
Bleu, Jaune}).
210
105
Modèle Relationnel
Concepts de Base
La Relation ou Table : Sous-ensemble fini
du produit cartésien d’une liste de domaines
caractérisé par un nom.
CODD a représenté les relations sous forme
de tables à deux dimensions.
211
Modèle Relationnel
Concepts de Base
CLIENT
C342 ELECTRA S.A. Casablanca

C235 Comptoirs du SOUSS Agadir
C145 Africaine de câbles Tanger
C98 Electronia Casablanca
C114 SMEC Casablanca
212
106
Modèle Relationnel
Concepts de Base
Un attribut : Colonne d’une relation
caractérisée par un nom. Un attribut est
toujours associé à un domaine.
213
Modèle Relationnel
Concepts de Base
CLIENT
Code LibelleClient Adresse
C342 ELECTRA S.A. Casablanca

C235 Comptoirs du SOUSS Agadir
C145 Africaine de câbles Tanger
C98 Electronia Casablanca
C114 SMEC Casablanca
214
107
Modèle Relationnel
Concepts de Base
Schéma de la relation : Nom de la relation
suivi par la liste des noms de ses attributs
avec leur domaine associé.
CLIENT ( Code : alphanumérique,
LibelleClient : alphanumérique, Adresse :
alphanumérique)
Tupple ou Enregistrement : n-uplet
(v1,…,vn) correspondant à une ligne de la
table représentant la relation.
(‘C342’,’ELECTRA S.A’, ‘Casablanca’)
215
Modèle Relationnel
Concepts de Base
Clé ou Identifiant : Plus petit ensemble des
attributs dont la connaissance des valeurs
permet d’identifier un tuple de la relation de
manière unique.
CLIENT ( Code : alphanumérique,
LibelleClient : alphanumérique, Adresse :
alphanumérique)
216
108
Règles de passage du MCD au MRD
Modèle Conceptuel de Données (MCD) est un
modèle à deux structures : Entité –
Association
Comment passer
du MCD au MRD ?
Modèle Logique de Données (MLD) ou Modèle

Relationnel de Données (MRD)
Modèle à une seule structure : Relation 217

Règle de passage pour les entités :
On crée une relation du même nom.
Chaque propriété devient un attribut.
Les attributs de l’identifiant constituent la clé
de la relation.
218
109
com_fact
1,1 1,1

Representant PU
1,n 0,n 0,n 1,n

0,n 1,1
219

Règle de passage pour les entités :
CLIENT (IdClient, NomClient, Representant,
Adresse)
COMMANDE (NCommande,
DateCommande)
FACTURE (NFacture, DateFacture)
ARTICLE (Ref, Design, PU)
220
110
Règles de passage du MCD au
MRD
IdClient NCommande Ref NFacture

NomClient DateCommande Design DateFacture
Adresse PU
Representant
221

Règle pour une association un-à-plusieurs
SERVICE EMPLOYE
IdService Matricule
0,N 1,1 Nom
NomService travaille
Fonction
222
111
Règle pour une association un-à-
plusieurs:
Soit une association un-à-plusieurs entre A et
B ( plusieurs B pour un A, un seul A pour
chaque B).
On crée les relations RA et RB
correspondantes aux entités A et B.
L’identifiant de A est ajouté comme clé
étrangère à RB Contrainte Référentielle
223

Règle pour une association un-à-plusieurs
EMPLOYE
SERVICE
Matricule
IdService
Nom
NomService
Fonction
Service
Réf : Service
Remarque : La clé étrangère n’a pas obligatoirement le

même nom que dans la relation parent. 224
112
Règle pour une association un-à-un :
PROVINCE VILLE
NomProv NomVille
Superficie Pop
1,1 0,1
Pop Chef-lieu X
Statut Y
225

Soit une association R un-à-un entre A et B.
On crée les relations RA et RB
correspondantes aux entités A et B.
On ajoute à l’une des deux relations
l’identifiant de l’autre comme clé étrangère.
On ajoutera le nouvel attribut à la relation où
R est obligatoire. Sinon le choix est facultatif.
226
113
PROVINCE
VILLE
CodeProv
NomProv CodeVille
Superficie NomVille
Pop Pop
Statut X
ChefLieu Y
Réf : ChefLieu
227

Règle pour une association plusieurs-à-
plusieurs :
FOURNISSEUR
ARTICLE
NFournisseur 0,n fournit 1,n Ref
NomFournis
PrixUnitaire Design
Adresse
228
114
plusieurs :
Une association Plusieurs-à-Plusieurs est
transformée en relation (dite associative)
contenant les clés étrangères référençant les
entités en association.
Les propriétés de l’association deviennent
des attributs de la nouvelle relation.
229

plusieurs :
FOURNIT
FOURNISSEUR
Fournisseur ARTICLE
NFournisseur Article
Ref
NomFournis PrixUnitaire
Design
Adresse Réf : Fournisseur
Réf : Article
230
115
Règle pour les association cycliques:

Les associations cycliques sont
transformées selon leur cardinalité
comme les cas déjà traités.
231
Association cyclique Un-à-Plusieurs :
EMPLOYE Responsable 0,N

Matricule
Nom supervise
Fonction
Subordonné 0,1
232
116
Association cyclique Un-à-Plusieurs :
EMPLOYE
Matricule
Nom
Fonction
Responsable
Réf : Responsable
233
Association cyclique Un-à-Un :
PERSONNE Epoux 0 : 1
CIN
Nom mariage
DateNaiss
Epouse 0 : 1
234
117
Association cyclique Un-à-Un :
PERSONNE
CIN
Nom
DateNaiss
Conjoint
Réf : Conjoint
235
Association cyclique Plusieurs-à-Plusieurs :
PRODUIT
IdProd
Composé 0 : N
Libellé
PrixUnitaire se compose
PoidsUnitaire
Composant 0 : N
236
118
Association cyclique Plusieurs-à-Plusieurs :
PRODUIT COMPOSITION
IdProd Composant
Libellé Composé
PrixUnitaire
PoidsUnitaire Réf : Composant
Réf : Composé
237
com_fact
1,1 1,1

Representant PU
1,n 0,n 0,n 1,n

0,n 1,1
Qte
238
119
CLIENT ARTICLE
FACTURE
IdClient Ref
NomClient Design NFacture
Adresse PU DateFacture
Representant
COMMANDE
NCommande COM_ARTICLE FACT_ARTICLE

DateCommande
Client Commande Facture
Facture Article Article
Qte
Réf : Commande Réf : Facture
Réf : Client
Réf : Article Réf : Article 239
Réf : Facture
Cas de l’héritage :
Solution A : Table sur-type et
disparition des sous-types. Avec un tel
principe les propriétés spécifiques à
chacun des sous-types ne seront pas
valorisées pour certaines occurrences
de la relation sur-type.
240
120
Solution B : Tables sous-types et
disparition du sur-type. Cette solution
entraîne une redondance importante
des données du sur-type si il n’y a pas
exclusion entre les sous-types.
241
Solution C : Tables sur-type et sous-types.
Dans chacune des relations sous-types,
l’identifiant de l’entité sur-type est intégré. Il
est à la fois clé primaire de la relation et clé
étrangère par rapport à l’entité sur-type.
Remarque : Il est important de noter que
quelque soit la solution adoptée, toute la
puissance portée par le concept d’héritage
est perdue dans le modèle relationnel.
242
121
Contraintes ensemblistes :
Il n’existe pas de concept dans le
modèle relationnel pour exprimer les
contraintes ensemblistes, à la place on
définira des contraintes d’intégrité que
le SGBDR devra gérer.
243
Règles de passage MCD MRD

En résumé : Passage d’un modèle à deux
structures (entité – association) à un modèle
à une structure (relation).
4 règles de passage :
1. Entité Relation
2. Association un-à-plusieurs Clé étrangère
3. Association un-à-un Clé étrangère
4. Association plusieurs-à-plusieurs
Relation
244
122
Normalisation du MRD
Le MRD obtenu à partir du MCD n’est en
principe pas normalisé.
Avant de passer au Modèle Physique de
Données (MCD) il convient de normaliser le
MRD.
Le degré de normalisation dépend du besoin,
mais en général la normalisation se fait au
minimum à la 3FN.
245
Modèle Physique de
Données : MPD
123
MPD : Modèles Physiques de données
Choix du SGBD (Système de Gestion de
Bases de Données) Modèle Relationnel
SGBDR (SGBD Relationnels Oracle –
SQL Server – DB2 …
Génération de la Base de Données à partir
du MRD Traduction du MLD en LDD
(Langage de Description de Données)
LDD associé aux SGBDR : SQL
247
MPD : Modèles Physiques de données

Exemple :
Script SQL syntaxe Oracle
Create table CLIENT

CLIENT
( IdClient number (6) not null,
IdClient
NomClient NomClient char (40) not null,
Adresse Adresse char(100) not null,
Representant
Representant char(40) not
null,
Primary key (IdClient));
248
124
Niveau organisationnel
Modèle Organisationnel
de Traitement (MOT)
Les postes de travail de l'entreprise : le

niveau organisationnel
Pourquoi une organisation ? Pour réaliser les fonctions
de l'entreprise décrites dans le niveau conceptuel. Cela
répond à la question QUI FAIT QUOI ? Et éventuellement
QUAND ?
Préalablement à ces modèles, l'organisation des postes
de travail, QUI, est donc définie.
Dans le cas de développement sur monoposte ou dans le
cas où l'application ne concerne qu'une seule personne,
le niveau organisationnel se ramène à sa plus simple
expression, un seul poste de travail.
L'ordre des trois modèles du niveau organisationnel
(MOT, MOD et MOF) est différent de celui du niveau
conceptuel.
250
125
Passage MCT MOT
Le passage des modèles conceptuels de traitement
(opérations effectuées par des intervenants) aux
modèles organisationnels de traitement (opérations
effectuées par une structure organisée) n'est pas
automatique. La construction de la structure des
postes de travail apporte une dimension nouvelle
qu'il faut assimiler. Les fonctions de l'entreprise sont
"projetées" sur les postes de travail.
Toute opération conceptuelle devra être exécutée de
manière organisée par un poste de travail.
251
Postes de travail
Le découpage organisationnel de l'entreprise
définit les postes de travail ou les unités
d'organisation. "QUI", poste de travail est
défini avant de déterminer QUI FAIT QUOI ?
Un poste de travail est défini par les moyens
mis à disposition (personnes, ressources
matérielles et logicielles) et le travail à
effectuer (les opérations organisées).
La définition des postes de travail reflète les
intervenants (acteurs) définis au niveau
conceptuel.
252
126
Postes de travail
Un poste de travail est une responsabilité au sein de
l'entreprise : P. D. G., directeur commercial,
secrétaire... Il est aussi "casquette" : acheteur,
vendeur...
Une même personne peut avoir plusieurs casquettes.
Tout dépend de ses capacités et de sa charge de
travail.
Les raisons de s'organiser de telle ou telle manière
sont des raisons de bon sens telles qu'un partenaire
(le client par exemple) doit toujours avoir un même
poste de travail (interlocuteur client) comme
correspondant pour le fidéliser ou des raisons de
pouvoir ou d'historique non formalisable. L'utilisateur
exerce son choix.
253
MOT : Pourquoi ?
Objectif : décrire les traitements au moyen des règles
d'organisation :
QUI fait : les RESSOURCES (manuelles et/ou automatisées)
OU ce sera fait : les POSTES de TRAVAIL
QUAND ce doit être fait : la CHRONOLOGIE
Tout en restant indépendant de :
COMMENT on pourrait bien le faire : il n'est toujours pas
question ni d'algorithmes ni de programmes.
Le MOT doit au final répondre aux questions suivantes :
1. Quel poste de travail assure le traitement ?
2. Traitement manuel ou automatisé ?
3. Contraintes de temps dues à l’organisation ?
254
127
MOT – Pourquoi ?
Exemple : règles d'organisation associées à l'enregistrement d'un
retrait sur compte bancaire.
QUI : - Tous les guichetiers (ils sont polyvalents)
- certains guichetiers (sur un poste de travail spécialisé dans
cette fonction).
- automatiquement par Guichets Automatiques Bancaires
(GAB).
- ...etc.
OU : - Dans l'Agence qui tient le compte.
- dans toutes les agences de la Banque.
- au Centre de Traitement des chèques.
- ...etc.
QUAND : - à tout moment aux heures d'ouverture de la Banque.
- en fin de journée, lors d'un traitement de mise à jour par
lots.
- n'importe quand par connexion directe sur les comptes.
-...etc.
255
MOT – Contexte d’utilisation

Un MOT peut être utilisé dans le contexte d'une
étude préalable, c'est-à-dire pour décrire l'existant.
Le MOT de l'existant fournit les bases pour décider
du "périmètre" de l'informatisation. Cette décision doit
prendre en compte une analyse coûts / avantages.
Ce peut encore être l'occasion de réorganiser
certaines procédures.
ou dans le contexte de la future application qui peut
éventuellement prévoir une réorganisation des
procédures et des postes de travail.
256
128
MOT : Concepts clés
Poste de travail ou acteur
Il correspond à une unité d’actions élémentaires dotée
de moyens de traitements
Phase de traitement ou Opération
organisationnelle
Sous-ensemble d’une opération conceptuelle exécuté
par un même poste de travail. Une phase de
traitement peut être manuelle ou automatisée.
Tâche
Sous-ensemble d’une phase exécuté soit par l’homme
soit par la machine et regroupant une ou plusieurs
règles de gestion
257
MOT : Poste de travail - Définition

Le poste de travail est caractérisé par :
Une fonction à assurer (gestion des stocks…),
Une implantation géographique (site central,
national, régional, local …)
Un ensemble de moyens/ressources
(personnel, matériel).
UN PT est équivalent à l’acteur du
diagramme de flux.
258
129
MOT : La phase - Définition
Une phase est un ensemble de tâches dont
l’enchaînement est non interruptible compte tenu de
l’organisation mise en place. Toutes les tâches d’une
phases se déroulent :
Sur un même poste de travail (unité de lieu)
A un moment déterminé (unité de temps)
Avec des moyens homogènes – manuel ou
automatique (unité d’action)
Exemple : Chaque jour à 16 H le secrétariat exécute
la phase « saisie du dossier » sur micro; Liste des
tâches : saisie des données, mise à jour du fichier
informatique, classement du dossier papier.
259
MOT : Phase - Formalisme
Événement
Événement Événement Événement
déclencheur déclencheur déclencheur
•objet 1 Données intervenant

Synchronisation Conditions •objet 2
d'exécution dans la phase
N° de la phase N°
Nom de la phase
dans la procédure Phase
Type de traitement x Condition Condition

d'émission d'émission Règle
MA : manuel
d'émission
TR : temps réel
TD : temps différé Événement Événement
résultat résultat
260
130
MOT : Phase – Type de traitement
Manuel,
Interactif,
Conversationnel (traitement unitaire
immédiat, ou temps réel),
Par lots (traitement différé d’un lot ou
traitement batch ou temps différé).
261
MOT : Phase – Événements

En plus des événements conceptuels déjà
étudiés on ajoute les événements
organisationnelles qui sont des :
1. Événements de déclenchement de phase.
Exemple : date d’exécution d’une tâche.
2. Événements internes traduisant des liens
entre phases (événements intermédiaires,
états d’attente). Exemple : dossier saisi.
262
131
MOT : Périodicité
Des contraintes de temps dues à
l’organisation sont introduites.
Exemple : chaque jour à 17H00 édition des
factures.
NB : Il ne faut pas confondre ce concept avec
la notion de temps au niveau conceptuel.
Exemple : chaque année le gestionnaire
envoie à ses clients une évaluation de leur
portefeuille.
263
MOT - Exemple
Période Client Caissière Comptable Type
Article Caisse
donné mise à
jour
Règlement
donné et
Encaissement
Heures d'ouverture Contrôler le règlement
Interactif
Quelques minutes Encaisser
Etablir le ticket de caisse
Montants différents Montants identiques
Règlement
redonné
Décision de
Article vérifier la
remis Caisse
et
Fin de journée Vérification de la Caisse
Manuel
15 à 30 minutes Caisse
remise
264
132
Passage MCT MOT
Cas général :
Une opération regroupant plusieurs règles de gestion
peut être découpée en plusieurs phases de
traitement ; ainsi une phase est un sous-ensemble
d’une opération.
Cas particuliers:
1 - Une opération se transforme en une seule phase.
les règles de gestion de l’opération du MCT sont
affectées à un seul poste de travail et les traitements
correspondants sont effectués au même moment et
en un seul lieu.
2 - Ajout de phases : Celles-ci correspondent à des
traitements qui ne figurent pas au niveau conceptuel.
265
266
133
Démarche d’élaboration du MOT
1. Définir un scénario global d’organisation.
2. Définir succinctement les ressources pour
chaque poste de travail.
3. Définir les fonctions associées à chaque
poste (automatisées, manuelles,
interactives).
4. Décomposer chaque opération en phases
de traitement.
267
MOT – Procédure fonctionnelle

Les phases sont regroupées en groupes
homogènes appelés procédures
fonctionnelles (PF). Une procédure
correspond à un seul processus. Un
processus peut donner lieu à plusieurs
procédures.
268
134
Fiche descriptive de procédure
269
Fiche descriptive de phase
270
135
MOT – Étude de cas : Domaine
Une entreprise de plomberie, chauffage et électricité ne prend une
affaire que si un devis a été signé par le client. Lorsqu'elle est
conclue, l'affaire est enregistrée, mise dans le planning des chantiers
et il faut rechercher les articles et fournitures à commander aux
fournisseurs.
En matière d'approvisionnements deux cas peuvent se présenter.
Les articles courants (tuyaux de cuivre, colliers, etc.) sont stockés en
magasin. Les articles spécifiques à une affaire sont commandés dès
que le devis a été fait. Dans les deux cas, les commandes ont lieu
auprès de distributeurs grossistes lors du passage de leurs
représentants. Les livraisons sont faites au siège de l'entreprise et
les articles rangés en magasin.
On prépare un chantier avant son ouverture pour s'assurer que les
articles nécessaires sont disponibles. Lorsque ce n'est pas le cas, on
fait une relance urgente auprès du fournisseur. A cette occasion on
affecte aussi un ou plusieurs ouvriers sur le chantier qui va s'ouvrir.
Nous avons au préalable identifié les postes de travail suivants :
Secrétariat – Chef d’entreprise – Chef de chantier.
271
MOT – Étude de cas : MCT
272
136
273
274
137
MOT – Étude de cas : Régles
RO1 Calcul des devis pourra être automatisée. Il existe d'ailleurs des
progiciels spécialisés dans ce domaine.
RO2 Acceptation/refus de l'affaire devra rester manuelle (décision
personnelle du chef d'entreprise). Il existe cependant des logiciels d'aide à la
décision qui permettraient à partir du devis et des données analytiques de
gestion de l'entreprise de fournir une estimation du taux de marge sur
l'affaire envisagée.
RO3 Enregistrer commande sera automatisée : saisie des prestations et
fournitures demandées.
RO4 Mise à jour du planning de chantier pourra être décomposée en 2 sous
procédures :
Mise à jour du planning (date début, date fin), en manuel.
Calcul des besoins en fournitures spéciales : automatisée par différence
entre ce qui est nécessaire (RO3) et ce qui est connu en stock courant.
RO5 Affecter ouvriers au chantier restera manuelle.
RO6 Contrôler besoins pourra être automatique si les entrées en stock ont
été enregistrées au fur et à mesure des livraisons des fournisseurs.
RO7 Relance en urgent restera manuelle. L'application informatique pourra
cependant fournir la liste des fournisseurs à contacter ainsi que leur
téléphone par exemple. 275
Validation Données -
Traitements
138
Validation Données - Traitements
La Validation consiste lors de l’étude du système
d’information futur, à vérifier qu’il y a cohérence
entre le MOT (vision dynamique) et le MCD (vision
statique).
Cette procédure permet de vérifier que les données
manipulées par les équipes chargées de la
modélisation des données et des traitements sont
interprétées de la même façon, que leur syntaxe est
identique et qu’elles sont toutes présentes.
Le principe de la validation : Le concepteur
vérifiera que les données permanentes nécessaires
pour chaque phase de traitement sont définies au
niveau du MCD global.
277

Pour chaque phase le concepteur construira autant
de petits modèles de données qu’il y a de phases,
sans aucune vision globale de l’ensemble. Cette
approche constitue le “Modèle externe” ou “Vue
externe ”. Ce qualificatif vient du fait qu’il s’agit de
construire une “vue” propre à chacun des
traitements.
Les vues externes du système d’information
expriment les visions particulières des différents
acteurs à travers les documents qu’ils manipulent.
278
139
Exemple : GESTION DES
STOCKS D'UNE SOCIETE
Soit la phase d'édition
permettant la sortie à une
date déterminée de l'état des
stocks de chaque usine.
279

L’état de sortie correspondant demandé par
l’utilisateur :
280
140
Vue externe associée à cette phase :
281

Le MCD établi initialement :
Les divergences
éventuelles
constatées devront
être analysées et
faire l’objet de
corrections.
282
141
Au cours de cette étape de validation, tous
les attributs seront analysés, de façon à ne
garder que celles qui sont nécessaires pour
les phases automatisées.
Au terme de cette opération, on procédera à
la mise à jour du dictionnaire des données.
La validation concerne chaque attribut de
chaque entité et de chaque association.
283
142

Cours MERISE AIAC 2P

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

Cours MERISE AIAC 2P

Transféré par

Droits d'auteur :

Formats disponibles

Méthode de Conception des

Académie Internationale Mohammed VI de l'Aviation Civile

Les Systèmes d’Information

On englobe sous ce terme l’ensemble des

Un peu de vocabulaire ...

Systèmes d’Information (SI)

Système d’information : une définition

SIO SI Automatisable SI Informatisé

Système d’information Vs Système

Pièces SI Comptable Écritures SI Comptable Résultats

Encore du vocabulaire : La méthode

Le développement de logiciels dans un

Pourquoi une méthode ?

Vocabulaire suite et fin : Conception

Cycles de vie d’un logiciel

Modèle de cycle en cascade

MERISE - Cycle de vie d’un système

Spécification complète du futur SI en deux phases:

Traduction informatique des spécifications issues

Traduction dans des langages appropriés des

Données – Traitements – Flux

Les modèles MERISE

MCD : signification des MCT : activité du

informations sans domaine sans préciser les

MOD : signification des MOT : fonctionnement

informations avec du domaine avec les MOF : relations

MLD : description des

domaine avec les MLF : relations

leurs conditions et des

MPD : description de la ou MPT : Architecture

La phase de Conception Générale

La phase de Conception Générale

La phase de Conception Générale

Modélisation des flux

Le diagramme de contexte a pour but de représenter les

Matrice des flux

Modélisation des données :

Modèle Entité - Association

MCD : Modèle Entité – Association

MCD : Modèle Entité – Association

REF DESIGN QTE PU MONTANT

Grands Moulins Saïs

MCD : Modèle Entité – Association

CLIENT ARTICLE COMMANDE FACTURE

MCD : Modèle Entité – Association

MCD : Modèle Entité – Association

CLIENT COMMANDE ARTICLE FACTURE

passe commande facture

MCD : Modèle Entité – Association

CLIENT COMMANDE ARTICLE FACTURE

NomClient NCommande Ref NFacture

passe_com com_article fact_article

MCD : Modèle Entité – Association

MCD : Modèle Entité – Association

MCD : Modèle Entité – Association

MCD : Modèle Entité – Association

Identifiant naturel Vs Identifiant abstrait

MCD : Modèle Entité – Association

CLIENT COMMANDE ARTICLE FACTURE

NomClient NCommande Ref NFacture

passe_com com_article fact_article

MCD : Modèle Entité – Association

NomClient passe_com NCommande