Ch5Merise - Copie PDF

Informatique de gestion :
MERISE
Konan Marcellin BROU

INP-HB/DFR-MI/DESCOGEF
konanmarcellin@yahoo.fr
kmbrou@inphb.edu.ci
2014-2015
Sommaire
 Introduction
 Principes généraux de Merise
 Modèle Conceptuel de Données
 Conception d’un MCD
 Modèle Conceptuel de Traitement
 Bibliographie
K. M. BROU Méthode d'analyse MERISE 2

I. Introduction
 1.1. Objectifs
 Apprendre les éléments de base de Merise ;
 Savoir créer un MCD;
 Savoir créer un MCT ;
 Savoir créer un MLD ;
 Savoir développer une application informatique.

I. Introduction
 1.2. Présentation
 Avant de réaliser un projet informatique, il faut pratiquer
une analyse informatique.
 Cette analyse consiste à comprendre et modéliser le
système d’information sur lequel on travaille.
 Système d’information (SI)
 Ensemble des informations qui circulent dans une entreprise
ainsi que l’ensemble des moyens mis en œuvre pour les gérer.
 Exemple : informations concernant la gestion des employés :
 Coordonnées, grade, département de l’employé

II. Notions de base
 2.1. Définitions
 Organisation
 Une « organisation » (entreprise, administration, collectivité,
tout groupe social organisé exerçant une activité) peut être
modélisé comme comportant trois sous systèmes :
 le système de pilotage (celui qui réfléchit, décide, oriente)
 le système opérant (celui qui produit, transforme, agit)
 le système d'information
 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.
 On s’intéresse en général qu’à un seul domaine d’activité de
l’organisation : RH, Vente, Comptabilité…
 On recense les besoins des utilisateurs.
 On définit le problème à résoudre.

II. Notions de base
 Conception
 Consiste à définir une solution informatique du problème :
 Structuration des données ;
 Organisation des traitements ;
 Définition des postes de travail;
 Choix techniques : matériels, langages de programmation, SGBD
 Méthode d’analyse
 L'efficacité et la validé de l’analyse reposent sur la qualité de la
communication entre les utilisateurs (maîtrise d’ouvrage) et
les informaticiens (maîtrise d’œuvre).
 Pour obtenir une bonne communication, les informaticiens
utilisent une méthode d’analyse.
 Constituée de trois éléments indispensables :
 la démarche ;
 les modèles ;
 les outils.

II. Notions de base
 Démarche :
 Ensemble coordonné d'étapes, de phases et de tâches
indiquant le chemin à suivre pour conduire un projet (la
conception d'un SI).
 processus opératoire qui permet d'effectuer le travail de
modélisation, de description et de réalisation du SI.
 Modèles :
 Représentation simplifiée d’une réalité sur laquelle on veut
être renseigné (plans, carte, schémas électroniques).
 S’exprime avec un ensemble de concepts, dotés de règles
d’utilisation et de représentation (souvent graphiques).
 Permet
 de communiquer : vérifier que l’analyste a bien compris les
besoins des utilisateurs (phase d’analyse) ;
 de préparer la réalisation grâce à un modèle de la solution (phase
de conception).

II. Notions de base
 Outils :
 Technique employée pour analyser et concevoir un système
d'information, ainsi que le support papier ou logiciel employé
pour conserver une trace du travail.
 Ateliers de Génie Logiciel (AGL)
 Permettent de concevoir des modèles, de créer des
documentations, de faire des simulations, des évaluations...
 Exemple : AMC Designor, Win’ Design, …
 Démarche générale d’informatisation :
Analyse du Conception Réalisation

problème de la solution du système

II. Notions de base
 2.2. Plusieurs méthodes d'analyse
 Les méthodes cartésiennes
 Premières méthodes apparues en 1960
 Basées sur les concepts et techniques de décomposition
hiérarchiques des flux de données ou flux d’information
 Préconisent d’analyser et de concevoir le SI en se centrant sur
ses fonctions.
 Perçoivent le SI comme un système de traitement de
l’information qui répond aux règles de procédures de gestion
pour produire des sorties.
 Utilise une démarche descendante qui met en œuvre le principe
de Descartes (Cartésien).
 La fonction initiale est décomposée en sous-fonctions, elles
mêmes décomposées en sous-fonctions…

II. Notions de base
 Exemple : SADT (Structured Analysis and Design Technic)
 Méthode utilisée pour décrire la fonction globale d’un système
Permet de réaliser la description d’un système (Ensemble d’éléments
en interaction) de façon structurée et hiérarchisée .
 Elle s’appuie sur une représentation graphique qui met en
évidence l’organisation fonctionnelle et structurelle du système en
allant du plus général au plus détaillé.
 Deux notions : Actigrammes (Actions) et Datagrammes (Données)
Actigramme Datagramme
II. Notions de base
 Exemples : Lave Linge
Choix de
Energie Paiement l’utilisateur
électrique Programme
Monnaie
W C R E
Poudres
Servir Boisson dans
Sirops
automatiquement un gobelet
Sucre
des boissons
Gobelets
chaudes ou froides
Eau
Déchets
Distributeur
 4 données de contrôle : énergétiques (W) ; exploitation (E) ; configuration
(C) ; réglage (R)
II. Notions de base
 Diagramme A-0

II. Notions de base
 Diagramme A 1

II. Notions de base
 Diagramme A 2

II. Notions de base
 Les méthodes systémiques
 Ont leur fondement dans la théorie des systèmes.
 Rendues célèbre par Merise
 Montre le SI en relation avec le système opérationnel de
l’organisation et son système de pilotage.
 Exemple : Merise qui découle de SADT

II. Notions de base
 Les méthodes Objets
 La conception par objets est la méthode qui conduit à des
architectures logicielles fondées sur les objets que tout
système manipule.
 plutôt que sur la fonction qu'il est censé réaliser (SADT).
 Objectif : réutiliser ce que l'on produit
 Programmer moins et mieux
 Basée sur la notion de classe ou d’objet
 Extension de la notion d’enregistrement (struct).
 Regroupe en une seule entité données et fonctions de traitement
de ces données.
 Données et traitement séparé en programmation classique

II. Notions de base
 Objet du monde réel : composé d'objets ayant tous deux
caractéristiques : un état et un comportement.
 Exemples 1 : Homme
 état = nom, couleur, race, poids....
 comportement = manger, crier, marcher...
 Exemples 2 : Voiture
 état = nombre de vitesses, modèle, couleur
 comportement = rouler, tourner, accélérer, changer de
vitesse
 Objet informatique :
 Maintient son état dans des variables appelées attributs ;
 Implémente son comportement à l'aide de méthodes.
 Un objet informatique est le regroupement logiciel d’attributs et
des méthodes associées.
 Exemple : Un rectangle
 Attributs : longueur, largeur
 Méthodes: calcul de son périmètre, calcul de sa surface
II. Notions de base
 Exemple de méthode objet : Processus unifié et UML (1990)
 Unified Modeling Language
 PU regroupe les activités à mener pour transformer les besoins
d’un utilisateur en système logiciel.
 Guichet Automatique billet de Banque
Scénario cas d’utilisation Retirer de l’argent

GAB
1. Le client s’identifie
Retirer de 2. Le client spécifie et le compte et le montant à
l'argent retirer
3. Le système déduit le montant du compte et
Déposer de
délivre l’argent
Client de l'argent
la banque
Effectuer
virement
Mettre de Employé de
l'argent la banque
Diagramme de cas d’utilisation
II. Notions de base
 Diagramme de collaboration pour la réalisation du cas
d’utilisation « Retirer de l’argent »

II. Notions de base
 Diagramme de séquence pour la réalisation d’un cas
d’utilisation

II. Notions de base
 2.3. Méthode d'analyse MERISE
 Méthode d’Etude et de Réalisation Informatique par Sous-
Ensemble.
 Méthode de conception et de développement de systèmes
d'information des organisations :
 les entreprises publiques ;
 les entreprises privées ;
 les administrations ;
 les associations...
 Créée en 1977 par la volonté du Ministère de l’Industrie
français, désireux de doter les administrations et les
entreprises publiques d'une méthodologie rigoureuse tout
en intégrant les aspects nouveaux d'informatique répartie
et de BD.
 Ses concepteurs sont :
 Hubert Tardieu, Georges Panet et Gérard Vahée.
II. Notions de base
 Les points forts de Merise :
S'appuie sur une approche systémique : C’est donc une

approche globale.
 Concepts peu nombreux et simples.
 Indépendante vis à vis de la technologie.
 Plus utilisée en France dans les domaines de gestion.
 Sert de référence aux enseignements sur les méthodes.

 Les critiques :
 Ne s'occupe pas de l'interface utilisateur ;
 Très adaptée à un contexte de création d'application mais pas
forcément à un problème de maintenance ou de seconde
informatisation.
 Ne permet pas réellement une validation rapide de la part des
utilisateurs.
 Davantage destinée à des sites centraux plus qu'à des
développements en temps réel, ou sur micro.
 Il est très difficile de valider les traitements par rapport aux
données et cela au niveau conceptuel ou organisationnel.

II. Notions de base
 Notion de système
 Ensemble d’éléments matériels ou immatériels (homme,
machine, méthode…) en interaction transformant par un
processus des éléments (les données d’entrées) en d’autres
éléments (les données de sortie).
 Un tel système est appelé système physique ou système
opérant (SO).
 Exemple 1 : une chaudière (SO)
 transforme par combustion du charbon (donnée d’entrée) en
chaleur (donnée de sortie).
charbon Chaudière Chaleur
 Exemple 2 : commande des clients
Bon de Rejet
Entreprise Ou
commande client
Livraison + facture
II. Notions de base
 Système de pilotage ou système de gestion et de contrôle.
 Décide du comportement du système en fonction des objectifs
fixés.
 Système opérant :
 Assure la production en vue de la réalisation de certaines tâches
(opérations).
 Ensemble du personnel exécutant
Système de pilotage
(réfléchit, décide, oriente)
Décision Information
Système opérant
(produit, transforme, agit)

II. Notions de base
 Notion de système d’information (SI)
 Le SI est constitué de moyens humains, matériels et des
méthodes permettant de collecter, mémoriser, traiter
distribuer, consulter les informations dont l’entreprise a besoin
pour ses différents domaines d’activité.
 Moyens humain : toutes les personnes touchées par le SI ;
 Moyen matériel : machines, ordinateurs, supports d’information
(disque, disquette, CD…) ;
 Méthode : algorithme, programme, modèle mathématique, plan
comptable…
 Interface entre le système de pilotage et le SO.
 Le SI reçoit 2 sortes d’informations qu’il doit traiter :
 Informations externe : commandes de clients, factures des
fournisseurs…
 Informations internes : documents comptables, chiffres de
production...

II. Notions de base
 4 fonctions principales d’un SI
1. Recueillir l’information : saisie ;
2. Mémoriser l’information : stockage dans des fichiers BD ;
3. Exploiter l’information : traitement
 Consulter ;
 Organiser ;
 Mettre à jour ;
 Produire de nouvelles informations par des calculs.
4. Diffuser l’information : édition

II. Notions de base
 Un SI comporte deux parties :
 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).
 Le SI possède deux aspects :
 Aspect statique (ou aspect données) :
 base d’information,
 modèle (ou structure) de données.
 Aspect dynamique (ou aspect traitement) :
 circulation de l’information entre les différents acteurs,
 évolution chronologique et causale des opérations provoquées
par des évènements.

II. Notions de base
 Schéma général d’un système d’entreprise
Système de pilotage
Management Décision Informations traitée
Système d’information
(mémorise, traite)
Entrée des Sortie des éléments

éléments externe à produits par
l’organisation Système opérant l’organisation
Evénement (produit, transforme, agit) Evénement
Matériaux Matériaux
Information Information

II. Notions de base
 Exemple Système de pilotage
Nouveaux Statistique
produits de vente
Système d’information
(mémorisation, traitement)
Bon de Bon de commande

livraison Pièce de règlement
commandes
Système opératoire Client

Client
(production, actions) Livraison de
règlements marchandise
Décision Information sur le SO Information-interaction

II. Notions de base
 Notion de domaine et de processus
 Un Domaine
 Découpage du SI de l'entreprise, défini dans un schéma directeur
en fonction de sa stratégie.
 Exemple : SI d’une banque
 domaines Gestion de clientèle, Gestion des participations
financières, Gestion de trésorerie, Gestion RH, Gestion
commerciale, etc.
 Le découpage en domaines correspond aux grandes fonctions de
l'entreprise, hiérarchisées par ses objectifs stratégiques (centres
d'intérêt).
Gestion Gestion
clientèle participations
financières
Domaines
Gestion Domaine
ressource Gestion
humaine commerciale

II. Notions de base
 Processus
 Ensemble d'opérations au sein d'un même domaine, généralement
déclenché par un événement externe (externe au domaine ou au
SI tout entier).
 Exemple : Domaine Gestion commerciale composé de trois
processus : Calculer devis ; Facturer ; Suivre règlement.
Réception Paiement,
Demande des travaux Date
de devis
Calculer Facturer Suivre Domaine

devis règlement Gestion
commerciale
Proposition de devis Facture Relance, Reçu

III. Conception
 Dans la réalisation d’un SI, une organisation peut être
observée selon plusieurs angles de vues appelés cycles.
 Suivant 3 cycles on définit les étapes de réalisation.
Cycle d’abstraction Démarche par étape
Niveau physique Mise en œuvre
Niveau logique Réalisation
Niveau organisationnel Etude détaillée

Etude préalable
Niveau conceptuel
Schéma directeur
Période de naissance
Cycle de décision
Période d’exploitation Décision sur Décision sur le
le contenu développement
Période de maintenance
Cycle de vie
III. Conception
 Description des données du SI suit un formalisme de
représentation précis, simple et rigoureux.
 Formalisme normalisé par l’ISO sous le nom de "ENTITE
RELATION".
 La représentation visuelle contribue à l’établissement d’un
dialogue constructif entre tous les partenaires qui collaborent
pour concevoir ensemble.

III. Conception
 3.2. Approche par étapes
 Schéma directeur
 Pont entre stratégies et besoins d’information.
 Etude globale du SI : Découpage en domaines.
 Définir les grandes orientations politiques et stratégiques de
l’entreprise.
 Définir les besoins en SI en fonction de la stratégie de
l’entreprise.
 Fixer les cadres budgétaires, la stratégie des besoins en
personnel et les contraintes diverses liées à l’environnement.
 Fixer les lignes directrices des développements informatiques
 Définir les projets nécessaires à l’élaboration ou l’évolution du
SI.
 Documents produits :
 Le schéma directeur, Le plan de développement informatique

III. Conception
 Etude préalable
 Etudie par domaine le projet à mettre en œuvre et son
interface.
 Analyse critique du système existant (conceptuel, organisation,
physique).
 Décrit les scénarios de solutions informatiques.
 Evalue les coûts et les moyens nécessaires.
 Fait un planning de réalisation.
 Documents produits :
 dossier d’étude préalable
 La direction doit faire un choix parmi les différentes solution

III. Conception
 Etude détaillée
 Description fonctionnelle de la solution à réaliser.
 Précise l’organisation détaillée de la solution retenue.
 Définit logiquement les données et les traitements
informatiques de la solution.
 Construit un planning de réalisation
 Documents produits : un cahier de charge de l’application
(contrat vis-à-vis des utilisateurs) ; un dossier d’étude
détaillée pour l’analyste programmeur ; un cahier de charge
matériel/logiciel pour un appel d’offres.

III. Conception
 Réalisation
 Production du logiciel, permet d’obtenir le logiciel testé sur un
jeu d’essai.
 Mise en œuvre
 Exécuter toutes les actions (formation, installation des
matériels, initialisation des données, réception, ...) qui
permettront d’aboutir au lancement du système auprès des
utilisateurs.
 Maintenance
 Mise à niveau éventuel des applications. Prolonger la durée de
vie.

III. Conception
 3.3. Cycles d’abstraction
 Succession d’étapes à suivre pour la conception d’une SI
automatisé.
 Met en évidence les règles qui régissent le SI.
 MERISE est basée sur la séparation des données et des
traitements.
 A chaque niveau correspondent à un modèle pour la
représentation des données et à un modèle pour la
représentation de traitements.
 Un formalisme de représentation est associé à chaque
modèle.
 4 niveaux d’abstraction :
 niveau conceptuel ;
 niveau organisationnel ;
 niveau logique ;
 niveau physique ou opérationnel.
III. Conception
 Enchaînement des niveaux d’abstraction
SI manuel
Expression des besoins
Modèle conceptuel MCD, MCT, MOD, MOT
Modèle logique MLD relationnel, réseau, objet…
Modèle physique Choix du matériel, des SGBD,…
SI automatisé

III. Conception
 Expression des besoins : on définit les fonctionnalités du
futur SI automatisé :
 Inventaire de tous les éléments nécessaires au SI
 Délimitation du SI en s’informant auprès des utilisateurs.
 Tout ceci permet de construire le MCC (Modèle Conceptuel de
Communication, le diagramme et le graphe des flux

III. Conception
 Description des niveaux d’abstraction
Niveau de description Concepts manipulés
Données Traitements
Modèle Conceptuel de Données Modèle Conceptuel des Traitement
(MCD) (MCT)
 Entité (ou objet)  Processus
Conceptuel
 Relation  Opération
 Propriétés  Evénement/Résultat
 Synchronisation
Modèle Organisationnel de Modèle Organisationnel des
Données (MOD) Traitement (MOT)
Organisationnel  Entité (ou objet)  Procédure
 Relation  Phase
 Propriétés  Tâche
Modèle Logique de Données Description Logique des Traitement
(MLD)  Procédure
Logique  Table  Phase
 Attribut  Tâche
 Fonction, Module
Description Physique de Modèle Opérationnel des
Données Traitements (MOPT)
Physique  Fichier  Application
 Rubrique  Unité de traitement (temps
réel ou batch)
III. Conception
 Les modèles de Merise2
 Aspect statique, Architectural (fonctionnelle) et dynamique
Interface Application
Statique Dynamique Architecture
Modèle Conceptuel de • Modèle Conceptuel Modèle de Flux
Modèle de Données (MCD) de traitement Conceptuels (MFC)
Quoi Contexte Analytique (MCTA)
(MC) • Cycle de Vide des
Objets (CVO)
Modèle Organisationnel • Modèle Modèle de Flux
D’où des Données (MOD) Organisationnel de Organisationnels
Qui MOT traitement (MFO)
Quand Analytique (MOTA)
• CVO
• Modèle Logique des • Modèle Logique des SALMI
Données (MLD) Traitements (MLT) SAL
Où Maquettes
• Modèle Logique des • Modèle Logique des SALr
Comment IHM
Données Réparties Traitements (MLTr)
(MLDr)
Schéma d’Architecture Logique des Moyens Informatique (SALMI)
Schéma d’Architecture Logique (SAL)
Schéma d’Architecture Logique répartie (SALr)
III. Conception
 3.4. Le cycle de vie du logiciel
 Pour obtenir un logiciel de qualité, il faut en maîtriser le
processus d’élaboration.
 Vie d’un logiciel
 Composée de différentes étapes.
 La succession de ces étapes forme le cycle de vie du logiciel.
 Il faut contrôler la succession de ces différentes étapes.
 C'est la description d'un processus couvrant les phases de :
 Création du produit logiciel ;
 Distribution sur un marché ;
 Disparition.
 Activités courantes :
 Etude de faisabilité ; Spécification ;
 Organisation du projet ; Conception ;
 Implémentation ; Tests ; Livraison ; Maintenance.

III. Conception
 Etude de faisabilité
 Déterminer si le développement proposé vaut la peine d’être
mis en œuvre, compte tenu des attentes et de la difficulté de
développement.
 Etude de marché : Déterminer s’il existe un marché potentiel
pour le produit.
 Spécification
 Déterminer les fonctionnalités que doit posséder le logiciel
 Qu’est-ce que le logiciel doit faire ?
 Comment s’assurer qu’il le fait ?
 Comment s’assurer qu’on développe le bon logiciel ?
 Décrire la solution, indépendamment de son implantation
 Identifier la frontière (les interfaces) du logiciel à développer
 Identifier les entités du logiciel et leurs interactions avec
l’environnement
 Spécifier le comportement attendu des entités, ainsi que leurs
interactions (internes).
III. Conception
 Organisation du projet
 Déterminer comment le logiciel va être développé
 Analyse des coûts : établir une estimation du prix du projet
 Planification : établir un calendrier de développement
 Assurance qualité du logiciel : déterminer les actions qui
permettront de s’assurer de la qualité du produit fini
 Répartition des tâches : hiérarchiser les tâches et sous-tâches
nécessaires au développement du logiciel
 Conception
 Déterminer la façon dont le logiciel fournit les différentes
fonctionnalités recherchées.
 Conception générale : Conception architecturale : déterminer la
structure du système ; Conception des interfaces : déterminer
la façon dont les différentes parties du système communiquent
entre elles
 Conception détaillée : Déterminer les algorithmes pour les
différentes parties du système.
III. Conception
 Implémentation
 Réalisation, à partir de la conception détaillée, d'un ensemble
de programme ou de composants de programmes.
 Tests
 Essayer le logiciel sur des données d’exemple pour s’assurer qu’il
fonctionne correctement.
 Devant l’impossibilité de réaliser des tests exhaustifs d'un
logiciel, les tests vont surtout se porter sur les interfaces :
 interaction entre les différents modules, entre les différentes
fonctionnalités,
 interactions entre le logiciel et le système d'exploitation, etc.
 Chaque test traite d'un élément précis de la conception ou de
l'utilisation.
 Le but d'un test est de découvrir un défaut, mais si une batterie
de tests ne montre pas de défaut cela n'implique pas que le
logiciel est quand même exempt de défaut...

III. Conception
 Livraison
 Fournir au client une solution logicielle qui fonctionne
correctement
 Installation : rendre le logiciel opérationnel sur le site du client
 Formation : enseigner aux utilisateurs à se servir du logiciel
 Assistance : répondre aux questions des utilisateurs
 Maintenance
 Mettre à jour et améliorer le logiciel pour assurer sa pérennité
 Pour limiter le temps et les coûts de maintenance, il faut porter
ses efforts sur les étapes antérieures.

III. Conception
 Deux catégories de modèle cycle de vie :
 Modelés linéaires
 cascade
 modele en V
 ...
 Modelés non linéaires
 prototypage
 modeles incrementaux
 modele en spirale
 ...

III. Conception
 Modèle de la cascade
 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 et activités, ils sont soumis à une revue approfondie.
 On ne passe à la phase suivante que s'ils sont jugés
satisfaisants.

III. Conception
Etude de
faisabilité
Spécification
Conception
générale
Conception
détaillée
Codage
Test
Maintenance
 Adapté pour des projets de petite taille, et dont le domaine est

bien maîtrisé.
III. Conception
 Modèle en V
 Variante du modèle en cascade qui met l’accent sur la
vérification et la validation.
 C’est un cycle de vie orienté test :
 A chaque activité créative (spécification, conception et codage)
correspond une activité de vérification (validation, intégration,
tests unitaires).
 La vérification est prise en compte au moment même de la
création.

III. Conception
Etude de Maintenance
faisabilité
Spécification Validation
Conception Tests
générale d’intégration
Conception Tests
détaillée unitaire
Codage
 Adapte pour des projets dont le domaine est bien maîtrisé

III. Conception
 On distingue deux sortes de dépendances :
 enchaînement et itération : se déroulent essentiellement de
gauche à droite.
 préparation des phases ultérieures.
 Par exemple à l'issue de la conception architecturale le
protocole et les jeux de test de l'intégration doivent être
complètement décrits.
 Conséquences :
 obligation de concevoir les jeux de test et leurs résultats ;
 réflexion et retour sur la description en cours ;
 meilleure préparation de la branche droite du V.

III. Conception
 Relations entre phases et activités selon le modèle en V
 Le tableau suivant montre la répartition des activités selon les
phases ainsi que les documents en entrées et en sortie de
chaque phase.
Activité Description Documents
Traduction des besoins en : Entrée : cahier des charges
• fonctionnalités ; Sortie :
• interfaces ; • Dossier de spécifications du logiciel
Spécification
• performances ; (DSL)
• contraintes ; • Manuels (installation/utilisation)
• exigence qualité ;
architecture globale : Entrée : Dossier de spécifications
• découpage en modules Sortie :
Conception
• communication inter-module • Dossier de conception générale (DCG)
générale ou
• échange de données • Dossier provisoire de tests/validation
architecturale
• contrôle (qui appelle qui)
• Conception de chaque Entrée : DCG
module Sortie :
Conception • Décomposition de chaque • Dossier de conception détaillée (DCD)
détaillée module en fonctions simples • Dossier provisoire de tests unitaires
facilement testables
III. Conception
Activité Description Documents
Traduction des traitements en Entrée : DCD
code Sortie :
Codage
Production • listage du code
• Dossier des tests unitaires (DTU)
Assemblage progressif des Entrée : DCG, DTI
composants Sortie :
Test
• DTI complet
d’intégration
• listage des composants testés
• Dossier des tests de validation (DTV)
• Test du logiciel complet en Entrée : DSL, DTV, cahier des recettes
fonctionnement opérationnel Sortie :
• Recette : tests faits par le • DTV complet
Validation commanditaire • Manuel d'utilisation et d'installation
• Vérification et gestion des • Dossier de livraison
modifications
• dossier définitif de livraison

III. Conception
 3.5. Cycle de décision
 Durant le cycle de vie, des décisions sont à prendre aux
différentes étapes.
Etape Décision
Schéma Approbation et mise en application du

directeur plan de développement (3 à 5 ans)
Etude préalable Choix d’une solution
Etude détaillée Accord des utilisateurs sur les

spécification techniques
Etude technique Accord du chef de projet sur les
spécification fonctionnelles
Codage Recette provisoire, conformité à la
solution
Mise en service Recette définitive, système en service
Maintenance Recette de maintenance

IV. MCD
 Le Modèle Conceptuel de Données (MCD) est une
représentation statique du SI.
 Permet de représenter les données fondamentale de
l’entreprise (les invariants décrits par des règles de gestion)
d’une manière compréhensible par les utilisateurs.
 Merise 2 parle de MCD étendu par ajout des notions telles
que l’héritage et les contraintes.

III. MCD
 3.2. Graphe des Dépendances Fonctionnelles (GDF)
 Définition
 Une Dépendance Fonctionnelle (DF), c'est le fait de relier de
manière unique une propriété à d'autre propriété ou un
ensemble de propriétés.
 Représentation
 La DF est représenté par une flèche : par exemple, A  B est
une DF de A vers B et se lit : à partir de A, on peut déterminer B.

III. MCD
 3.2. Modèle de données
 Ensemble de concepts et de règles de composition des ces
concepts permettant de décrire l’information structurée
d’un Système d’Information.
 Deux grandes classes de modèle de données :
 les modèles liés à un SGBD :
 modèles hiérarchique, réseau, relationnel…
 modèles non liés à un SGBD :
 modèles Zo, Entité/Association…).
 Remarque :
 Un SI est l’ensemble des moyens humains, matériels et des
méthodes de traitement des différentes formes d’information
rencontrées dans une organisation (informations naturelles et
informations structurées).

III. MCD
 3.3. Modèle Entité/Association
 Crée en 1976 grâce aux travaux menés parallèlement aux
Etats Unis et en France.
 Sa paternité est attribuée à Peter Chen.
 Nommé aussi entité/relation, objet/relation,
 Modèle de données de type conceptuel.
 A donné naissance a la méthode MERISE.
 Raisons de son succès :
 Approche naturelle et facile à comprendre ;
 Obtention directe, sans manipulation de données, de résultats
de synthèse ;
 Représentation graphique et claire des résultats.

III. MCD
 Exemple de MCD
 Constitué d’entités reliées entre elle par des relations.
 Exemple le SI d’une école modélisé par le schéma suivant :
Classe Matiere
codeCl 1,n possède 1,n N°Mat
nomCl libellé
nomClEntier coeff
1,n
cycle
Semestre
lieu 1,n compose 1,2
Frequente N°Sem
note
1,n
1,1
Etudiant époux
1,1
N°Etudiant
marie
nom
prénom
1,1
dateNais
épouse
adresse
III. MCD
 3.4. Notion d’entité
 Définition
 Représentation d’un objet du monde réel (concept concret ou
abstrait), perçu par le concepteur comme ayant une existence.
 Une entité existe indépendamment du fait qu’elle puisse être
liée à d’autres entités de la base.
 Exemple :
 Fatou, Adjoua, Yao, Toto, BD, Math, INFO2, ECS2 sont des
entités du SI de l’école.
 Classe d’entités ou entités type
 C’est la classe dans laquelle on peut ranger un groupe d’entités
ayant des propriétés communes.
 Exemple :
 Etudiant est la classe des entités Fatou, Adjoua, Yao et Toto.
 Matière est la classe des entités BD et Math.
 Classe est la classe des entités INFO2 et ECS1
 Pour plus de commodité, la classe d’entité sera désignée par
K. M. BROU entité. Méthode d'analyse MERISE 62
III. MCD
 Classification
 C’est une relation (représentée par un verbe) qui existe entre
une entité et sa classe.
 Exemple :
Fatou est membre de Etudiant
Yao est membre de Etudiant
BD est membre de Matière
 Occurrence d’une entité

 L’entité étant considérée comme un ensemble, une occurrence
d’une entité est tout élément individualisé de cet ensemble.
 Exemple :
 Fatou et une occurrence de l’entité Etudiant
 Population
 On appelle population d’une classe d’entité, l’ensemble des
occurrences de la classe d’entité.

III. MCD
 Représentation
Nom de l’entité
 Exemple : entité Etudiant
Etudiant

III. MCD
 3.5. Notion d’attribut ou propriété
 Information élémentaire que l’on peut rattacher à une
entité ou à une association.
 Exemple :
 L’entité Employé a les attributs suivants : matricule, nom…
L’association ADroitIF a l »attribut suivant : montant
 Représentation
Exemple
Entité Employé Exemple : occurrences de l’entité Employé

attribut1 matricule
Attribut2 nom matricule Nom Prénom Datenais Adresse
prenom 1 Koné Fatou 26/04/85 BP 1090 Yakro
attributn dateNaiss
2 Koffi Yao 13/12/84 BP 15 Bouaké
adresse
 Remarque :
 Un attribut est également un ensemble de valeurs possibles ;
chaque occurrence de l’entité ou de l’association possède une
valeur distincte d’attribut.
III. MCD
 3.6. Clé d’une entité
 ou identifiant d’une entité
 Attribut ou ensemble d’attribut permettant d’identifier de
manière unique les occurrences d’une entité.
 Deux occurrences d’une entité, ne peuvent pas avoir la même
valeur de la clé.
 Exemple :
 L’attribut N°Etudiant est la clé de l’entité Etudiant
 Représentation
 La clé d’une entité est toujours soulignée.
Exemple
Etudiant
N°Etudiant Deux étudiants distincts ne peuvent pas
nom avoir le même numéro d’étudiant
prénom
dateNais
adresse

III. MCD
 3.7. Notion d’association
 Traduit dans le SI le fait qu’il existe une relation entre
plusieurs entités.
 Le nombre d’entité intervenant dans la relation caractérise
la dimension de l’association :
 Association binaire entre deux entités
 Association ternaire entre trois entités
 Association n-aire entre n entités
 Exemple :
Fatou compose en BD (a)
Toto compose en Math (b)
Yao compose en Matière (c)

III. MCD
 Association réflexive
 lie deux entités de même type.
 la spécification du rôle de chaque entité est indispensable pour
supprimer les ambiguïtés possibles.
 Exemple :
Toto est marié à Adjoua (d)
Yao Est marié à Fatou (e)
 Classe d’associations ou d’association type

 Classe dans laquelle on peut ranger un groupe d’associations
ayant des propriétés communes.
 La classe d’association lie plusieurs classes d’entités.
 Exemple :
 Compose est la classe des associations (a), (b) et (c).
 Marié est la classe des associations (d) et (e).
 Si nous raisonnons en terme de classes nous obtenons :
Etudiant compose Matiere
Etudiant marie Etudiant
III. MCD
 Remarque : on confond classe d’associations et association
 Représentation
Entité2
Entité1 Nom de l’association
Entité n
 Exemple
 Un étudiant peut composer dans une matière.
 Un étudiant peut se marier avec un autre étudiant.
Etudiant compose Matière
Etudiant marie

III. MCD
 Clé d’une association
 Obtenue par la réunion des identifiants des entités qui
participent à l’association.
 Un attribut d’association ne peut pas être déclarée comme clé
de l’association.
 Exemple
 (N°Etudiant, N°Mat, N°Sem) : clé de l’association Compose
 (N°Etudiant, CodeCl) : clé de l’association fréquente
 Occurrence d’une association
 a comme attributs, les attributs de l’association et les clés des
entités participant à l’association.
 Exemple : occurrences de l’association compose
N°Etudiant N°Mat N°Sem Note
007 01 1 15,50
007 02 1 19
007 01 2 14
059 01 1 16

III. MCD
 3.8. Type d’association
 Nombre d’occurrence mise en jeu de part et d’autre d’une
association.
 Trois types d’association :
 un à un, un à plusieurs et plusieurs à plusieurs.
 Soient E1 et E2 deux entités liées par l’association A.

III. MCD
 Association un à un
 A est une association un à un si à une occurrence de l’entité E 1
peut correspondre par l’association A au plus une occurrence de
l’entité E2. Réciproquement, à une occurrence de l’entité E2 ne
peut correspondre qu’au plus une occurrence de l’entité E1.
E1 A E2 Exemple
a1 a2
b2 Vehicule CarteGrise
b1 c2
numero possede numero
categorie nomProprietaire
c1 d2 marque
 Exemple :
 supposons que l’on considère l’association entre un véhicule et une
carte grise, nous avons les deux entités suivantes :
 Véhicule(numero, catégorie, marque)
 Carte grise(numero, nomPropriétaire)
 Entre ces deux entités il existe une association de type un à un.
 En effet, un véhicule possède une et une seule carte grise et
réciproquement à une carte grise n’est associé qu’un seul véhicule.
III. MCD
 Association un à plusieurs
 A est une association un à plusieurs si à une occurrence de
l’entité E1, l’association A peut faire correspondre plusieurs
occurrences de l’entité E2 mais qu’à une occurrence de E2
correspond au plus une occurrence de E1.
Exemple : considérons l’association fréquente entre l’entité
E1 A E2 Classe et l’entité Etudiant
a2 Il existe une association de type 1 à plusieurs entre l’entité

a Classe et l’entité Etudiant.
b2
1 b1 c2 En effet, dans une classe peuvent fréquenter plusieurs étudiants
e2 et un étudiant ne fréquente que dans une seule classe.
c1
d2 Yao et Toto fréquente dans la classe INFO2.

III. MCD
 Association plusieurs à plusieurs
 A est une association plusieurs à plusieurs si à une occurrence
de l’entité E1 peuvent être associées, par l’association A,
plusieurs occurrences de l’entité E2, et réciproquement, à une
occurrences de l’entité E2 peuvent être associées, par
l’association A plusieurs occurrences de l’entité E1.
E1 E2
Exemple : considérons l’association possède entre les entités
a2 Classe et Matière.
b2 Une classe peut posséder plusieurs matières et une matière peut
a1
être enseignée dans plusieurs classe, alors possède est une
b1 c2 association de type plusieurs à plusieurs.
c1 e2
d2

III. MCD
 Notation :
 association un à un  1 : 1
 association un à plusieurs  1 : n
 association plusieurs à plusieurs  n : m
Type d’association
Entité1 association Entité2
Exemple
1:n
Classe fréquente Etudiant

III. MCD
 3.11. Cardinalité
 Cardinalité d’un couple entité/association
 Donne des renseignements sur le minimum et le maximum
d’occurrences d’une association A liant deux entités E1 et E2.
 Caractérisée par une borne minimale et une borne maximale.
 Cardinalité minimale :
 Nombre minimum de fois qu’une occurrence d’une entité
participe aux occurrences de l’association.
 Cardinalité maximale :
 Nombre maximum de fois qu’une occurrence d’une entité
participe aux occurrences de l’association.
Dans la figure ci-contre, aucun trait ne lie l’occurrence a1 de E1 alors que plusieurs
E1 E2 traits lient les occurrences b1 et c1.
a2 Cela signifie que pour une occurrence donnée de E1 (ex a1) on peut n’avoir aucune
a1 association avec les occurrences de E2 i.e. au minimum zéro trait liant l’occurrence.
b2
b1 c2 Par contre il existe une autre occurrence de E1 (ex b1 ou c1) pour laquelle on peut
e2 avoir plusieurs occurrences de E2.
c1 On dit que la cardinalité de E1, muni de l’association A est (0, n) ; de même la
d2
cardinalité de E2, muni de l’association A est (0, n).
K. M. BROU Méthode d'analyse MERISE

76
III. MCD
 Notation :
 Les cardinalités les plus courantes sont :
 0, 1 : aucun ou un seul
 1, 1 : un et un seul
 0, n : aucun ou plusieurs
 1, n : au moins un ou plusieurs
Entité1 card min, card max association Exemple de schéma E/A

sup
1:n
Employé 1, 1
nom chef
Exemple
salaire 1, n
Fournisseur
Classe 1, n fréquente 1, 1 Etudiant 0, 1 inf
nomF
n:m 0, n adresse
travaille 1:n livre
0, n quantité 0, n
1, n
 Représentation 1:n
Rayon Article
E1 y1 : y2 E2 nomR 0, n vend 1, 1 nomA
a1e1 x1, y1 x2, y2 a1e2 étage type
A
a2e1 a2e2
a3e1 a1a

III. MCD
 3.12. Généralisation/spécialisation
 Lien orienté, d’une entité spécialisé (ou spécifique ou fille)
vers une autre entité générique (ou père).
 Elle permet d’exprimer les caractéristiques communes à
plusieurs entités formant une même famille.
 Elle traduit la relation "est-un", (IS-A).
 Sémantique du lien :
 à toute occurrence de l’entité spécifique correspond une
occurrence de l’entité générique qui décrit le même objet du
monde réel ;
 inversement, à toute occurrence de l’entité générique
correspond zéro ou une occurrence de l’entité spécifique.
E L’entité E est plus générale que les entités E1 et E2.
Exemple :
un étudiant est une personne, un enseignant est une personne.
E1 E2 L’entité Personne est la généralisation des entités Etudiant et
Enseignant.
III. MCD
 Héritage :
 Principale propriété de la généralisation.
 toute entité E’ (sous-type) ayant avec une autre entité E (sur-type)
une relation de généralisation dans le sens E’ est un E hérite des
attributs de E.
 Les attributs adjoints à l’entité E’ sont appelés attributs propres et
ne peuvent être hérités par l’entité E.
 Exemple :
 Personne(N°Matricule, nom, prénom, dateNais)
 Etudiant(N°Etudiant, discipline, diplômePréparé, annéeEtude)
 Les entités Etudiant et Enseignant vont hériter des attributs
N°Matricule, nom, prénom, dateNais.
 Par contre l’entité Personne ne peut hériter de l’attribut N°Etudiant car
toutes les personnes ne sont pas des étudiants.

III. MCD
 Généralisation multiple
 Une entité hérite de plusieurs autres entités.
 Exemple : L’entité Assistant-Doctorant, regroupe la
Personne population des personnes qui sont à la fois
Employé Assistant et Doctorant.
Etudiant Enseignant Technicien Administratif
Doctorant Assistant Professeur

professeu
r
Assistant-Doctorant
 Problème de la généralisation multiple

 pose des problèmes liés à l’héritage.
 Eviter d’hériter deux fois d’un ancêtre commun.
 L’entité Assistant-Doctorant doit hériter une seule fois de
l’entité Personne :
 soit via Doctorant et Etudiant,
 soit via Assistant-Enseignant-Employé.
III. MCD
 Les contraintes
 Contrainte de couverture : toute occurrence sur-type doit
appartenir à un sous-type.
 Contrainte disjonction : les instances d’un sous-type ne peuvent

être incluses dans un autre sous-type du même sur-type (pas
d’intersection entre les sous-types).

III. MCD
 Contraintes sur les types
 Contrainte de partition = disjonction + couverture
Employé
Un employé est soit salarié, soit
horaire, soit vacataire
+
Employé Employé Employé

salarié horaire vacataire
 Contrainte de Totalité= non disjonction + couverture

Personne
Une étudiant peut être un employé

T et vice versa
Etudiant Employé

III. MCD
 Contrainte d’exclusion = disjonction + non couverture
Contrat
Un contrat ne peut être à la fois un

x contrat crédit et un contrat d’épargne,
il existe d’autres types de contrats
Contrat Contra
crédit épargne

III. MCD
 Contraintes sur les associations
 Contrainte de partition = disjonction + couverture
Résider en France 1, n Ville
codeV L’entité Pivot est reliée à la
0, n contrainte
Personne
codeP +
Une personne réside forcément
en France ou à l'étranger, mais
0, n Résider à l’étranger 1, n Pays pas dans les deux.
Entité Pivot codeP
 Contrainte de Totalité= non disjonction + couverture

Etre salarié 1, n Entreprise
codeE Pour une personne, elle est
0, n soit étudiante, soit salarié,
Personne soit les deux.
codeP T Toute occurrence du pivot
participe forcément à une des
0, n Etre étudiant 1, n Université deux associations, voire aux
codeU deux.

III. MCD
 Exercice 1 : Bibliothèque
Une bibliothèque universitaire souhaite automatiser sa gestion. Cette
bibliothèque est gérée par un gestionnaire chargé des inscriptions et des
relances des lecteurs quand ceux-ci n’ont pas rendu leurs ouvrages au-delà du
délai autorisé Les bibliothécaires sont chargés de gérer les emprunts et la
restitution des ouvrages ainsi que l’acquisition de nouveaux ouvrages. Il existe
trois catégories d’abonné. Tout d’abord les étudiants qui doivent seulement
s’acquitter d’une somme forfaitaire pour une année afin d’avoir droit à tous les
services de la bibliothèque. L’accès à la bibliothèque est libre pour tous les
enseignants. Enfin, il est possible d’autoriser des étudiants d’une autre
université à s’inscrire exceptionnellement comme abonné moyennant le
versement d’une cotisation. Le nombre d’abonnés externes est limité chaque
année à environ 10% des inscrits. Un nouveau consultation du catalogue
général des ouvrages doit être mis en place. Les ouvrages, souvent acquis en
plusieurs exemplaires, sont rangés dans des rayons de la
bibliothèque. Chaque exemplaire est repéré par une référence gérée dans le
catalogue et le code du rayon où il est rangé. Chaque abonné ne peut
emprunté plus de trois ouvrages. Le délai d’emprunt d’un ouvrage est de trois
semaines, il peut cependant être prolongé exceptionnellement à cinq
semaines.
Questions : Faire le MCD

Méthode d'analyse MERISE 85
K. M. BROU
III. MCD
 Exercice 2 : Gestion des formations
Il s'agit d'établir le schéma conceptuel d'une base de données pour la gestion
des formations d'un institut privé. Un cours est caractérisé par un numéro de
cours (NOCOURS), un libellé (LIBELLE), une durée en heures (DUREE) et un
type (TYPE). Un cours peut faire l'objet dans l'année de plusieurs sessions
identiques. Une session est caractérisée par un numéro (NOSES), une date de
début (DATE) et un prix (PRIX). Une session est le plus souvent assurée par
plusieurs animateurs et est placée sous la responsabilité d'un animateur
principal. Un animateur peut intervenir dans plusieurs sessions au cours de
l'année. On désire mémoriser le nombre d'heures (NBH) effectué par un
animateur pour chaque session. Un animateur est caractérisé par un numéro
(NOANI), un nom (NOMA) et une adresse (ADRA). Chaque session est suivie
par un certain nombre de participants. Un participant est une personne
indépendante ou un employé d'une entreprise cliente. Un participant est
caractérisé par un numéro (NOPAR), un nom (NOMP) et une adresse (ADRP).
Dans le cas d’un employé, on enregistre le nom (NOMEN) et l’adresse de
l’entreprise (ADREN). On désire pouvoir gérer d’une manière séparée (pour la
facturation notamment) les personnes indépendantes d’une part, et les
employés d’autre part. Si nécessaire, on fera les hypothèses sémantiques
complémentaires qui pourraient s'imposer.
Question : Établir le MCD.

III. MCD
 Exercice 3 : Hypermarché
sup
1:n
Employé 1, 1
nom chef
1, n
salaire
inf Fournisseur
0, 1 nomF
n:m 0, n adresse
travaille
1:n livre
0, n quantité 0, n
1, n
1:n
Rayon Article
nomR 0, n vend 1, 1 nomA
étage type
On veut séparer les articles (d’attributs n°Code, nomA, marque, qté en stock)
en plusieurs classes : article alimentation (d’attribut date limite de vente),
article habillement (d’attributs taille et couleur), HI-FI (d’attribut puissance),
hygiène… On introduit également une entité Service après vente pour la
réparation des articles HI-FI.
Compléter le schéma E/A de l’hypermarché avec cette nouvelle réalité.

III. MCD
 Correction Exercice 1 :
Ouvrage Gestionnaire
codeOuv 1, 1 achète Bibliothécaire codeGe
1, n
intitulé codeBi nomGe
1, n nomBi
1, n 0, n
possède 0, n inscrit relance
1, 1
emprunte 1, 1
0, n
Exemplaire 0, n dateEmprunt
numéro Abonné
dateRetour
codeAb
1, 1 1, 3 nomA
range tel
email
1, n
Rayon
Etudiant Enseignant Etudiant
nomR
matricule spécialité externe
étage
département université

III. MCD
 Correction : Exercice 3
sup
Employé 1, 1
nom chef
salaire 1, n
Fournisseur
0, 1 inf
nomA Service
0, n après vente
emploie
livre type adresse
quantité
quantité Article 1, n
0, n 0, n n°Code
1, n
nomA répare
Rayon type date entée
nomR 0, n vend 1, 1 marque date sortie
étage qtéStock montant
quantité
1, 1
Article Article Article
alimentaire habillement HI-FI
date limite date limite puissance
Remarque couleur
Il n’est pas nécessaire que les entités spécifiques représentent, dans leur ensemble, tous les
objets représentés par l’entité générique. Ainsi, les article d’hygiène, de bricolage… ne
constituent pas d’autres classes spécifiques et sont donc représentés par l’entité générique
Article.
III. MCD
 3.13. L’agrégation
 Associations ou liens particulier ayant la sémantique
"composé-composant".
 Consiste à créer un découpage de l’entité E en sous-
ensembles E1, E2, …, En, différenciés par des attributs
propres, ou par des valeurs spéciales pour un attribut.
 L’entité E est appelée entité mère et les entités Ei sont
appelées entités filles. E Ei est partie de E ou E est
composée de E1, E2…
 Remarque E1 E2
 La suppression d'un "composé" peut ou non entraîner celle des
"composants"
 "pièces détachées" irrécupérables ou récupérables!.
 Réciproquement la suppression d'un "composant" peut ou non
entraîner la suppression du "composé"
 (une voiture sans roue ne change pas d'identité, une voiture avec un
nouveau châssis est une autre voiture...).
III. MCD
 Exemple
 On veut connaître les étudiants mariés et les différents types de
véhicule. Voiture
Châssis Moteur Roues

III. MCD
 3.14. La personnalisation d’association
 Permet de créer des entités plus complexes lorsqu’une
entité est liée à un groupe d’entités.
 Exemple :
 les problèmes de police d’assurance sur le campus ne
concernent que les voitures des étudiants.
 On peut exprimer ce fait à l’aide d’une personnalisation
d’association qui créera une entité composée VoitureEtudiant.
VoitureEtudiant La pseudo-entité VoitureEtudiant n’a de réalité

pour l’association est assurée que parce que c’est
Etudiant possède Voiture le couple d’entité (Etudiant, Voiture) qui est
concerné par l’assurance.
1, 1
En effet une police est nominale, elle ne concerne
est assurée un véhicule et un propriétaire, en l’occurrence
l’étudiant.
Police

III. MCD
 3.15. Détermination des clés
 Un identifiant où clé d’une entité (ou association) est un
ensemble minimum d’attribut tel qu’il n’existe pas deux
occurrences de l’entité (ou association) qui ont la même
valeur pour ces attributs.
 Une entité (ou association) peut avoir plusieurs identifiants
ou n’avoir aucun.
 Exemple :
 n°employé et nom + prénoms sont deux identifiants de l’entité
Employé :
 si dans cette entreprise il n’y a jamais deux employés ayant le
même numéro et les mêmes nom et prénoms.

III. MCD
 Identifiant d’une association
 Exemple 1 :
 soit le schéma E/A suivant représentant les mariages
actuels.
époux
Personne
nom 1, 1
marie
sexe
1, 1 date
État_civil
épouse
Une occurrence de l’association marie est un triplet (époux, épouse, date).
Si on suppose que l’attribut nom est l’identifiant de l’entité Personne, l’association

marie possède un identifiant constitué de époux.nom et épouse.nom.
Cette définition n’est valable que si la population de l’association marie ne contient

que les mariages en cours (on ne garde pas l’historique).
Si on garde l’historique (i.e. les mariages passés), les cardinalités sont 0, n et

l’identifiant devient : époux.nom et épouse.nom + date.

III. MCD
 Exemple 2 :
 les résultats à ce jour des étudiants lors de contrôles.
Etudiant Matière
n°carte contrôle numMat
0, n 0, n
nom note libellé
moyenne coef
Une association dont toutes les cardinalités maximums sont supérieures à 1, a en

général un identifiant qui est constitué de l’ensemble des identifiants des entités
liées. L’identifiant de l’association contrôle est : Etudiant.n°Carte +
Matière.numMat.
 Exercice : dans cette représentation un étudiant a au plus une
note par matière. Comment modifier le schéma EA pour qu’il
puisse en avoir plusieurs.
 Réponse : ajouter un attribut date à l’association contrôle. Dans

ce cas sa clé devient Etudiant.n°Carte + Matière.numMat +
contrôle.date Etudiant Matière
n°carte contrôle numMat
0, n note 0, n
nom libellé
moyenne
coef
date
III. MCD
 Exemple 3 :
 association ou une entité a une cardinalité maximum égale à 1.
Personne
Voiture
numP assure
0, n 1, 1 numV
nom
sexe
1, n
âge
Cie Assurance
nomA
L’identifiant de l’association assure n’est pas Personne.numP + Voiture.numV +

assure.nomA car ce triplet ne constitue pas un ensemble minimal.
En effet l’attribut numV de l’entité Voiture suffit, à lui seul, pour identifier une occurrence
de l’association assure.
Ceci est dû à la cardinalité 1, 1 qui garantit que pour une valeur de numV il n’y aura
qu’une seule occurrence de assure avec cette valeur de numV. D’où la règle suivante :
Si une association a une cardinalité maximum égale à 1 pour une des entités,
alors tout identifiant de cette entité est identifiant de cette association.

III. MCD
 Identifiant d’une entité faible
 Une entité E est dite faible si aucun sous-ensemble de ses
attributs ne constitue un identifiant (il n’a pas d’identifiant qui
lui soit interne), et qu’un identifiant peut être défini en
intégrant un identifiant d’une autre entité E’ qui lui est lié par
une association binaire de cardinalité 1, 1 pour E.
 on dit que E dépend de E’.
 Exemple : exemplaire d’un livre.
Livre
est un Exemplaire
ISBN 1, n 1, 1
numEx
titre
état
ISBN = International Standard Book Number
L’entité Exemplaire est une entité faible (numEx n’est pas un identifiant) dépend de
l’entité Livre. On dit que Exemplaire dépend de Livre car, du fait des cardinalité, il n’est
pas possible de créer une occurrence de Exemplaire sans la rattacher à une occurrence
existante de Livre. Ce type dépendance est appelé dépendance d’existence.
L’identifiant d’une entité faible (qui est le même que celui de l’association) est constitué
de l’identifiant de l’entité dont il dépend et d’un (ou plusieurs) attributs du l’entité faible.
L’identifiant de Exemplaire (et de l’association est un) est : Livre.ISBN + numEx
III. MCD
 Identifiant d’une sous-classe
 Soit E une entité sous-classe de l’entité E’, alors tout identifiant
de E’ est aussi identifiant de E.
 E n’a pas nécessairement d’identifiant qui lui soit propre.
 Dans l’exemple de hypermarché, Article, Article alimentaire,
Article habillement et Article HI-FI ont tous les trois pour
identifiant celui de Article (n°Code).
Article
n°Code
nomA
type
marque
qtéStock
Article Article Article

alimentaire habillement HI-FI
date limite date limite puissance
couleur

IV. Conception d'un MCD
 Deux méthodes de conception d’un schéma entité-
association :
 Méthode descendante : qui part des entrées et permet de définir
un modèle conceptuel de données.
 Cette méthode convient particulièrement aux bases de données.
 Méthode ascendante : qui part des sorties pour obtenir les
entrées.
 Cette méthode est surtout adaptée à une analyse classique en
terme de fichiers
 On appelle sortie tout document imprimé ou toute image d’écrans
permettant de visualiser des informations.

 4.2. La méthode descendante
 Dans cette méthode, on passe directement de l’univers du
discours (ou monde réel) au modèle conceptuel.
 Exemple : Supposons que l’univers du discours est traduit
par le texte suivant :
 «Le gestionnaire d’une entreprise désire enregistrer
l’affectation des divers bureaux aux divers employés et
connaître la surface du plancher dont chacun dispose».
 A partir de ce texte imprécis, on peut définir deux schéma
contenant les mêmes attributs mais traduisant deux réalités
différentes.
Employé Employé
occupe Bureau
n° emp n° emp
1, n 0, n n° bureau
nom nom surface
n° bureau
surface
Schéma 2
Schéma 1
Dans le schéma 2, un employé peut occuper plusieurs bureaux.
 Il y a donc plusieurs solutions possibles.
 Pour n’en retenir qu’une, le concepteur recherchera le SI le
mieux adapté à la réalité en discutant avec le gestionnaire.
 Est-ce que la notion de bureau est accessoire ou au contraire assez
importante pour nécessiter la création d’une entité ?
 si cette dernière option est retenue, il est probable que d’autres attributs
(nombre de fenêtres, exposition, type d’ameublement…) seront ajouter pour
décrire un bureau.
 Par ailleurs, il apparaît plus judicieux d’attribuer une surface à un bureau
qu’à une personne
 Principaux problèmes de cette méthode :
1. reconnaissance des entités et des associations
2. reconnaissance des attributs pertinents
3. placement des attributs
4. détermination des types d’association
5. choix des cardinalités pour les couples entité/association
 La reconnaissance des entités et des associations ainsi que les
attributs pertinents sont obtenues par un travail d’analyse de
K. M. BROU
l’univers du discours.
Méthode d'analyse MERISE
101
 Placement des attributs sous les associations
 Un attribut peut être placé sous une association lorsqu’il est
déterminé par toutes les entités liées par l’association.
 Un attribut appartient à une association lorsqu’il dépend de toutes les entités
liées dans cette association.
 Pour chaque ensemble formé par chaque occurrence de toutes les entités
concernées, il existe une seule valeur possible pour cet attribut.
 Exemple : prenons le cas d’un étudiant qui assure sa voiture.
 Le montant de l’assurance dépend à la fois des caractéristiques de l’étudiant
(âge, date de permis, etc.) et des caractéristiques de la voiture (nombre de
chevaux).
Etudiant Voiture
N°Etud N°immat
assure
nomEtud chevaux
prénomEtud montant marque
dateNais catégorie
datePermis

 Le problème de la représentation du temps
 Deux points de vue principaux concernant la représentation du
temps : point de vue synchronique et point de vue diachronique.
 Point de vue est synchronique
 Un point de vue est synchronique lorsque le temps n’intervient pas
comme élément discriminant. Il correspond à une vision instantanée
de la réalité modélisée.
 Exemple : prise en compte de la date d’assurance de la voiture d’un étudiant
; on suppose qu'un étudiant ne peut assurer sa voiture plusieurs fois.
On placera la date comme attribut de l’association assure.
Etudiant
N°Etud Voiture
nomEtud assure N°immat
prénomEtud 1, n 1, 1 chevaux
montant
dateNais marque
date
datePermis catégorie
contrat
Le problème se complique lorsqu’il faut représenter les divers états

d’une entité dans le temps

 Point de vue est diachronique
 Une représentation est diachronique lorsqu’il faut prendre en
compte des éléments temporels comme attribut ou entité
discriminants.
 Elle correspond à une vision historique de la réalité modélisée.
 Deux méthodes de représentation du temps :
 la création d’une entité temporelle (Date, Jour, Semaine, Année, …) ;
 l’introduction d’entités représentant des événements datés.
 Exemple 1 : création d’une entité temporelle
 On crée une entité temporelle pour traduire le fait qu’un étudiant peut
assurer plusieurs fois la même voiture auprès de la même compagnie
d'assurance ou non (le point de vue synchronique ne va plus).
 Règle 1 :
 pour passer d’une vision synchronique à une vision diachronique par la
méthode d’introduction d’une entité temporelle, on rajoute une entité
représentant le temps et on transforme l’association n-aire en une
association n+1-aire.

Etudiant Voiture
N°Etud assure N°immat
nomEtud montant chevaux
prénomEtud 1, n 1, n marque
dateNais 1, n catégorie
datePermis
Date
date contrat
Les occurrences de l’entité Date sont les dates de signature de contrats entre
l’étudiant et les sociétés d’assurance.
Remarques :
Une entité temporelle possède souvent un seul attribut et elle fait intervenir une
association n-aire (sauf les attributs de mesure du temps jour, heure, minute…).

 Exemple 2 : introduction d’événements datés
 On va créer une entité Police pour représenter l’événement contrat
d’assurance qui est un événement daté.
Etudiant Voiture
N°Etud 1, n assure 1, 1 N°immat
nomEtud chevaux
prénomEtud marque
dateNais 1, 1 catégorie
datePermis
Police
numéro_police
date_contrat
montant
 Si une voiture devait être assurée à un moment donné plusieurs fois, le
schéma ci-dessus ne marche pas, d’où le schéma suivant.
 Règle 2 :
 l’introduction d’événements datés en tant qu’entités reporte sur ces entités
tous les attributs associables à ces événements.

 Dans le cas où plusieurs occurrences d’une entité participent
simultanément à un événement, il est préférable de lier ces
événements aux autres entités par des association.
Etudiant Voiture
N°Etud N°immat
nomEtud 1, n 1, 1 chevaux
prénomEtud possède marque
dateNais catégorie
datePermis
1, n
1, n
souscrit concerne
1, 1
1, 1
Police
N°Police
dateContrat
montant

 Détermination des types d’association et des cardinalités
 Détermination des types d’association
 Elle se fait en se posant les question suivante : une occurrence donnée de
l’entité Ei est-elle reliable à une ou plusieurs occurrence de l’entité Ej par
l’association A ?
 La détermination du type d’une association binaire se fait en terme de
possibilité.
 Exemple : Un étudiant peut posséder plusieurs voitures et une voiture peut
être possédée par plusieurs étudiants. Si on admet la propriété multiple, le
type de l’association possède est n : m (plusieurs à plusieurs), sinon c’est 1 :
n (plusieurs voiture pour un étudiant)
 Détermination des cardinalités
 Le choix des cardinalités d’un couple (Ei, A) est plus discriminant ; il suppose
la détermination de deux paramètres : le minimum et le maximum.
 détermination du minimum : en se posant la question suivante : Ei est-elle
forcement lié par A ? Si la réponse est oui, le minimum est 1, sinon c’est 0.
 détermination du maximum : en se posant la question suivante : combien de
liens au maximum sont associés à une occurrence donnée de l’entité Ei ? Si
ce maximum est connu sous forme d’une valeur x, alors la cardinalité max de
(Ei, A) est x, sinon c’est n.
 La détermination d’une cardinalité d’un couple
entité/association se fait en terme de contraintes, ou
d’hypothèse forte.
 Exemple :
 Un étudiant ne possède pas forcément une voiture, le minimum de (Etudiant,
possède) est 0.
 Un étudiant peut avoir plusieurs voitures en nombre indéterminé, le max de
(Etudiant, possède) est n.
 Une voiture est forcément la propriété d’un étudiant, le minimum de
(Voiture, possède) est 1.
 Une voiture ne doit être la propriété que d’un seul étudiant, le maximum de
(Voiture, possède) est 1.
 Cardinalité de (Etudiant, possède) : (0, n)

 Cardinalité de (Voiture, possède) : (1, 1)
Etudiant Voiture
N°tud 0, n possède 1, 1 N°Immat
nomEtud chevaux
prénomEtud marque
dateNais catégorie
datePermis
 Relation entre cardinalité et type d’association
 Soit une association binaire liant deux entité E1 et E2.
 Soient (x1, y1) la cardinalité du couple (E1, A) et (x2, y2) la
cardinalité du couple (E2, A).
 Si y1 = y2 = 1 alors A est de type 1 : 1
 Si y1 > 1 et y2 = 1 ou y1 = 1 et y2 > 1 alors A est de type 1 : n
 Si y1 > 1 et y2 > 1 alors A est de type n : m.
 Si le type A est 1 : 1 alors y1 = y2 = 1

 Si le type de A est 1 : n alors y1 = 1 et y2 > 1 ou y1 > 1 et y2 = 1
 Si le type de A est n : m alors y1 > 1 et y2 > 1

 4.3. La méthode ascendante
 Dépendance fonctionnelle : DF
 Soit une relation R(A, B, C) où A, B et C représentent des
attributs ou groupes d’attributs. B est dit fonctionnellement
dépendant de A si étant donné deux tuples <a1, b1, c1> et <a2,
b2, c2> de R, a1 = a2  b1 = b2.
 Plus simplement, B dépend fonctionnellement de A, si étant
donné une valeur de A il lui correspond une valeur unique de B.
 La DF est notée : A  B et se lit : A détermine B ou B est
fonctionnellement dépendant de A.
 Exemple
 CommandeProduit(N°Prod, désign, qtéCom, prixU, N°Com,
 dateCom, N°Client, nom, adresse)
 F = {N°Prod  désign, N°Prod  prixU, N°client  nom,
 N°Client  adresse, N°Com  dateCom, N°Com  N°Client,
N°Com, N°Prod  qtéCom}
 Contre exemple :
 N°Client  N°Prod

 Propriétés des DF
 Réflexivité : Y  X  X  Y (dépendance triviale)
 Augmentation : X  Y  X, Z  Y, Z
 Transitivité : X  Y et Y  Z  X  Z
 Union ou Additivité : X  Y et X  Z  X  Y, Z
 Pseudo-transitivité : X  Y et Y, W  Z  X, W  Z
 Décomposition : X  Y et Z  Y  X  Z
 Dépendance Fonctionnelle Elémentaire (DFE)
 Une DF X  Y est élémentaire s’il n’existe pas de X’  X tel que X’
Y
 Exemple :
 N°Client  nom ; N°Com, N°Prod  qtéCom
 Contre exemple :
 N°Client, N°Com  nom car N°Client  nom

 Dépendance Fonctionnelle Directe (DFD)
 Une DF X  Y, dans une relation R est directe s’il n’existe pas
d’attribut Z de R tel que X  Z et Z  Y
 La DF X  Y n’est pas obtenue par transitivité
 Exemple :
 N°Client  nom ; N°Com, N°Prod  qtéCom
 Contre exemple :
 N°Com  nom car N°Com  N°Client et N°Client  nom
 Fermeture transitive d’un ensemble F de DFE
 Ensemble F+ obtenu en ajoutant à F toutes les DF élémentaires
déduites par transitivité.
 F+ = F  {DF transitives}
 Couverture minimale
 Ensemble MIN(F) de DF élémentaires associé à un ensemble
d’attributs vérifiant les propriétés suivantes :
 aucune dépendance de F n’est redondante ; c’est-à-dire, pour
toute DF F’ de F, F-{F’} n’est pas équivalent à F
 toute DF élémentaire des attributs est dans F+ de F.
 En d’autres termes, il n’existe pas F’  MIN(F) / (F’)+ = F+

 Dictionnaire de données
 Résultat de la phase de collecte des données.
 Cette phase est également appelée recueil d'information.
 Rechercher les informations dans :
 Les documents ;
 Les règlements ;
 Les normes, les procédures ;
 Les bases de données, les fichiers.
 Les techniques de recueil
 L’étude de documents ;
 Les entrevues ;
 Les questionnaires ;


 Classification des données
 Données élémentaires : l’information se confond avec la valeur
prise par la donnée. Par exemple, un nom, une date….
 Données calculées ou déduites : elles sont obtenues par
l’application règles de gestion.
 Données composées : données regroupées en une même entité
sémantique (par exemple une adresse).
 Les principaux types de données :
 Alphanumérique (AN) : déterminer la taille maximale
 Numérique : entier, réel, monétaire…
 Date : Date/Heure, Date, Heure ;
 Logique ou booléen (L ou B).

 Formalisme

 Exploitation
 L’ensemble des données recueillies constitue le dictionnaire des
données brut. Toutes les données ne seront pas utilisées de la
même manière. Pour la phase de modélisation des données, il
convient d’épurer ce dictionnaire brut :
 des synonymes (données ayant le même sens) car ils constituent
des redondances ambiguës,
 des polysèmes (mots ayant plusieurs sens) car ils peuvent
provoquer des malentendus.
 On supprimera les synonymes et les polysèmes de façon à
établir une bijection entre l'ensemble des signifiants et celui des
signifiés.

 Phase 1 : liste des rubriques figurant sur les sorties
 On dresse la liste des rubriques figurant sur l’ensemble des
sorties.
 Les rubriques communes à plusieurs sorties ne sont notées
qu’une seule fois.
Exemple : Factures éditées par la
coopérative La Nature
COOPERATIVE DE LA NATURE
FACTURE N° FACTURE : ………
On peut recenser les rubriques suivante :
DATE : …/…/… le numéro de la facture, la date d’édition de la
N° ADHERENT : ………….
facture, le n° de l’adhérent, ainsi que ses nom,
Nom - prénom : ………………………… … prénom et adresse, pour chaque produit
Adresse : ………………………...…………. commandé le numéro,
la désignation, la quantité commandée, le prix
N° produit Désignation Qté PrixU TVA Montant unitaire, le taux de TVA, le montant et pour
l’ensemble de produits commandés, le total
hors taxe et le total TTC.
Par contre on ne recensera pas les rubriques

Total HT ……... préimprimées ou fixes telles que le nom de la
Total TTC : …….. coopérative (COOPERATIVE LA NATURE),
FACTURE, N° ADHERENT…

 L’image écran ci-dessous permet des saisir les informations sur
les produits livrés par les fournisseurs.
COOPERATIVE DE LA NATURE De cette image écran, on peut recenser :

le : ../../…. la date du jour, pour chaque produit un numéro
et une désignation, ainsi que l’ensemble des
N° produit Désignation Prix unitaire.N° Four. Nom Four.
fournisseurs pouvant procurer ce produit, avec
pour chacun d’eux : son numéro, son nom et le
prix auquel il vend le produit.
Ici également, on ne recense pas les rubriques

fixes de l’écran.
Taper Entrée pour voir la suite

 Phase 2 : recherche de rubriques figurant dans le graphe de DF
 On recherche les rubriques qui seront dans le graphe de DF.
 On classe les rubriques en quatre catégories :
 Rubriques Non Calculées (NC) : ce sont des rubriques dont les valeurs
doivent être lues pour pouvoir figurer sur une sortie, telles le nom et le
prénom d’un client. Elles ne sont pas fixes et on n’a pas les moyens de les
calculer.
 Rubriques Calculées (C) : ce sont des rubriques dont les valeurs sont
calculées à partir d’autre rubriques, telles la rubrique montant (calculée à
partir de la quantité et le prix unitaire).
 Paramètres (P) : ce sont des rubriques dont la valeur est toujours la même
pour un traitement ; par exemple la date d’émission d’une facture est la
même pendant toute une journée.
 Rubriques Incrémentées (I) : ce sont des rubriques également calculées
mais à partir de valeurs initiales pouvant être considérées comme
paramètres ; par exemple le numéro d’une facture est obtenue à partir du
numéro précédent augmenté de 1.
 Remarque
 une rubrique ne se place pas toujours dans la même catégorie ; la catégorie
doit être précisée en fonction du contexte. Par exemple le numéro de facture
figurant sur la facture est une rubrique incrémentée alors que celle du relevé
K. M. BROU de facture (voire exercice ci-dessous)
Méthode d'analyse MERISEest une rubrique non calculée. 120
 Modèle de grille d’analyse des rubriques :
Rubriques I NC C P S1 S2
n° facture X X S1 = sortie 1 = document facture
date S1 X X S2 = image écran
n° adhérent X X
nom adhérent X X Remarque
prénom adhérent X X Dans le cas d’une rubrique apparaissant sur
adresse adhérent X X plusieurs sorties, si elle apparaît au moins une
n° produit X X X fois comme une rubrique non calculée, alors
désignation X X X on retiendra ce type pour la caractériser.
qté commandée X X
prix vente X X Si une rubrique est calculée et que les
tva X X
rubriques nécessaires pour effectuer le calcul
montant X X
ne figurent pas dans la grille, alors il faut les
total HT X X
total TTC X X ajouter et les analyser.
date S2 X X
n° fournisseur X X
nom fournisseur X X
prix achat X X

 Phase 3 : graphe de DF
N° Rubriques 1 2 3 4 5 6 7 8 9 10 11 12 13 Matrice des DF :
1 n° facture X X X X X
2 n° adhérent X X X X On établit le graphe des DF,
3 nom adhérent X
4 prénom adhérent X
on ne retiendra pour ce
5 adresse adhérent X
6 n° produit X X X X
faire que les rubriques non
7 désignation X calculées ou incrémentées.
8 qté commandée X
9 prix vente X
10 tva X
11 n° fournisseur X X
12 nom fournisseur X
13 prix achat X
Si la rubrique de la ligne i est en DF avec la rubrique de la colonne j (i  j) alors on met une croix
dans la case ayant i et j pour coordonnées.
Si pour une rubrique, aucune croix n’apparaît dans une ligne ou dans une colonne, cela signifie que
cette rubrique ne dépend d’aucune autre et que la connaissance de cette rubrique ne nous permet
pas d’en déterminer une autre. Il va falloir chercher des dépendances composées faisant intervenir
les rubriques indépendantes. Dans notre cas il s’agit des rubrique 8 ( qté commandée) et 13 (prix
achat).
n° facture, n° produit  qté commandée
n° produit, n° fournisseur  prix achat
 Phase 4 : Rechercher une couverture minimale.
 Une couverture minimale est un ensemble minimum de DF à
partir du quel on peut retrouver toute les autres.
 On supprime des DF qui peuvent être obtenues par les règles d’Amstrong.
 n° facture  n° adhérent
 n° adhérent  nom adhérent, prénom adhérent, adresse adhérent
 n° produit  désignation, prix vente, tva
 n° fournisseur  nom fournisseur
 n° facture, n° produit  qté commandée
 n° produit, n° fournisseur  prix achat

 Phase 5 : établir le modèle entité-association
qté commandée prix achat
n° adhérent n° facture n° produit n° fournisseur
nom adhérent, prénom adhérent, adresse adhérent

désignation, prix vente, tva nom fournisseur
 On distingue en général trois sortes de liens :

 Liens entre un attribut, clé d’une entité et les autres attributs de l’entité
(trait plein) ;
 Liens entre un attribut clé d’une entité et un attribut clé d’une autre entité
(n° facture  n° adhérent) ; cette catégorie de lien est appelée Contrainte
d’Intégrité Fonctionnelle (CIF). Par exemple n° facture détermine n° adhérent
(trait en pointillé).
 Liens entre des attributs clés et des attributs non clé (n° facture, n° Produit
 qté commandée).

 Le schéma obtenu est appelé SAT (Structure d’Accès Théorique)
Facture Contient Produit
n° facture 1, n Qté commandée 0, n n° produit
désignation
1, 1 prix vente
tva
Envoyée a
1, n
1, n
fournit
Adhérent
n° adhérent prix achat
nom adhérent
1, n
prénom adhérent
adresse adhérent Fournisseur
n° fournisseur
nom fournisseur

 Exercice :
 On ajoute la sortie suivante (relevé de facture) aux autres
sorties de la Coopérative De la Nature. Déterminer le schéma
entité/association en tenant compte de cette nouvelle réalité.
COOPERATIVE DE LA NATURE
RELEVE DE FACTURE
N° ADHERENT : …………. DATE : …/…/…
Nom - prénom : ………………………… …

Adresse : ………………………...………….
Cher client,
Nous vous informons que vous êtes redevables pour le mois de……… des factures
dont la liste suit :
N° facture date Montant
………… ../../.. ………..
………… ../../.. ………..
………… ../../.. ………..
Montant à régler : ………..
126
 Correction
 Le numéro de facture n’est plus dans ce document une rubrique
incrémentée mais une rubrique non calculée. On retiendra ce
dernier type.
 De même la date de la facture qui était un paramètre doit être
traitée maintenant comme une rubrique non calculée. On
retiendra ce dernier type
 En ce qui concerne les montants partiels, si les éléments de
calcul (le détail des factures) ont été conservés, alors il faut le
traiter comme une rubrique calculée. Si seuls les montants des
factures on été conservés, alors on peut les considérer comme
des rubriques non calculées.
 Le montant à régler est une rubrique calculée.

 La grille d’analyse des rubriques
Rubriques I NC C P S1 S2 S3 Il n’est pas nécessaire de reprendre toutes les

n° facture X X X étapes. Une seule rubrique supplémentaire date
date S1 X X X S1 correspondant à la date de la facture est
n° adhérent X X X prendre en compte et sera ajouter dans la
nom adhérent X X X matrice des DF. On mettra en évidence par une
prénom adhérent X X X croix l’existence de la DF : n° facture  date S1
adresse adhérent X X X
n° produit X X X
Dans la représentation graphique de la
désignation X X X
couverture minimale la seule modification porte
qté commandée X X
sur :
prix vente X X
tva X X Dans le MCD l’entité
montant X X Facture devient :
total HT X X n° facture
total TTC X X X Facture
date S2 X X n° facture
n° fournisseur X X date si n° adhérent date s1
nom fournisseur X X
prix achat X X
date s3 X X
mois X X
montant à régler X X

 4.3. Les limites du modèle entité/association
 Le modèle entité/association est un modèle de données et
non de traitement.
 Il ne peut donc pas contenir les opérations de mise à jour
(création, suppression…) ou de consultation d’entités.
 Absence de contrainte de mise à jour
 Ces contraintes peuvent être générales ou dépendant du temps.
 Exemples de contraintes générales :
 Un achat est enregistré dans le SI par la comptabilité parce que le
chef comptable donne la dernière autorisation
 Tout achat décidé doit être enregistré le jour même.
 Exemples de contraintes dépendant du temps :
 Par contrat, les prix ne sont modifiés que le 1 er novembre de chaque année.
 Lors du premier achat à un fournisseur, la quantité commandée doit être la
plus petite possible.
129
 Absence de contrôle de validation
 Lors d’une mise à jour, on effectue des contrôles indépendants
des valeurs enregistrées (validation statique) ou au contraire
dépendant des valeurs enregistrées (validation dynamique).
 Exemple de validation statique :
 Le prix d’un produit doit être inférieur à 10 000 F.
 Exemple de validation dynamique
 Pour un produit, on doit choisir le fournisseur le moins cher.
 Conclusion
 Malgré ces quelques limites, le modèle entité/association
rencontre un vif succès ;
 C’est un élément de la méthode Merise.
 Ce succès est dû en particulier à la représentation graphique
claire et synthétique de la description conceptuelle des données.
 Cette représentation facilite le dialogue entre l’utilisateur et
l’analyste.
130
V. MCT
 Le traitement constitue la partie dynamique du SI.
 Ils décrivent les actions à exécuter sur les données afin
d’obtenir les résultats attendus par l’entreprise.
 Les traitements sont la traduction en actions des Règles de
Gestion qui composent l’activité de l’entreprise.
 Exemple : soit la règle de gestion suivante :
 "Une commande ne sera satisfaite que si la quantité en stock
est supérieure à la quantité demandée"
 Cette RG se traduit par les traitements suivants :
 Lire la quantité commandée
 Comparer la quantité commandée avec la quantité en stock
 Si la quantité commandée est inférieure à la quantité en stock, alors
la commande est acceptée, sinon la commande est rejetée.

V. MCT
 Le MCT permet de formaliser les traitements en fonction des
événements extérieurs sans s'intéresser à l'organisation qui
régira ces traitements.
 Il exprime ce qu’il faut faire, mais il n’indique pas qui doit le
faire ni quand il faut le faire ni où il faut le faire (concepts
organisationnels) ni comment il faut le faire (concepts
opérationnels).
 Il exprime donc le quoi, mais ni le qui, ni le quand, ni le où,
ni le comment.

V. MCT
 5.2. Les modèles de flux
 Un modèle de flux est une représentation des mouvement
de données à l’intérieur d’un SI et entre ce SI et son
environnement extérieur.
Flux
Traitement
Données
 Il permet de :
 décomposer le SI en sous-système ;
 formaliser les flux d’information entre ses sous-systèmes
 2 sortes de modèles de flux au niveau conceptuel :
 Le modèle de contexte (MC) ;
 Le modèle de flux conceptuel (MFC).
V. MCT
 Le modèle de contexte
 Le MC détermine le domaine d’étude et ses échanges avec son
environnement extérieur (acteurs externes).
 Domaine d’étude
 Sous-ensemble cohérent de l’entreprise bien délimité et formant le
contenu d’étude.
 Il peut être assimilé au modèle de flux de niveau 0.
 Acteur : entité organisationnelle identifiable par la mission qu’il
remplit dans le cadre du champ d’étude défini.
 Acteur interne : acteur dont le missions se situent à l’intérieur du
champ d’étude. Par raccourci, on l’appelle aussi acteur.
 Acteur Externe (ou Partenaire) : acteur dont les missions se
situe en dehors du champ d’étude mais qui échange des
informations avec un acteur interne.
 Exemples : activité, service, personne, profil (secrétaire, ingénieur,
directeur…), matériel.

V. MCT
 Formalisme
Acteur 1
Domaine
d’étude
Acteur 2
Domaine
connexe 1
 Domaine connexe
 Autre domaine du SI interagissant avec le domaine d’étude.

V. MCT
 Exemple
demande d’achat
proposition
commande
Client facture Service
produit Vente
règlement
Facture acquittée
Demande de réappro Stock mis à jours
Service
Achat
 Utilité du MC
 Démarrage de l’étude : permet de déterminer le domaine d’étude
(correspond la plus part du temps à un domaine fonctionnel).
 Fin d’analyse du SI actuel : permet de déterminer les activités
existantes.
 Début d’analyse du système futur : permet de préciser les
contours du domaine d’étude.
V. MCT
 Modèle de flux conceptuel (MFC)
 Il décrit par raffinement successif les activités du domaine
d’étude sans décrire leurs comportements.
 C’est une structure hiérarchique de diagramme de flux (DF).
DF1
Modèle de
Contexte (MC)
DF12 DF13 …. DF1n
DF131 DF132
Modèle de Flux Conceptuel

 DF ou MOF (Modèle Organisationnel de Flux) ou DFD
(Diagramme de Flux de Données)
 Représente les flux échangés entre :
 Les acteurs du domaine d’étude ;
 Les acteurs du domaine d’étude et les partenaires extérieurs ou
domaine extérieur au domaine d’étude.
V. MCT
 Le MFC et le DF complètent le MC par la description des activités
et gérant les flux externes.
 On s’arrête généralement au Niveau 2.
 On poursuit la décomposition jusqu’à l’obtention d’activité qui
correspondent à un processus ou à une opération conceptuelle (cf.
MCT, MCTA).
 Activités
 Ensemble de traitements homogènes qui manipulent les données.
 Concept sur lequel se concentre la décomposition du modèle de
flux.

V. MCT
 Exemple
demande d’achat
proposition
commande
Client facture Service
produit Vente
règlement
Facture acquittée
Demande de réappro Stock mis à jours
Service
Achat
Modèle de contexte : niveau 0
 Le domaine d’étude Service Vente sera décomposé en activités

V. MCT
 Décomposition du domaine « Service Vente » en 2 activité :
« Produire » et « Vendre »
demande d’achat
Produire
proposition
double proposition
Client commande
facture
produit Vendre
règlement
Facture acquittée
DF de niveau 1

V. MCT
 Décomposition de l’activité « Vendre » en 2 activité : « Gestion des
commandes » et « Gestion des règlements ».
commande
facture Gestion des
produit commandes
Client double facture
règlement Gestion des

Facture acquittée règlements
DF de niveau 2

V. MCT
 5.2. Modèle organisationnel des flux
 MOF ou DFD (Diagramme de Flux de Données) ou
diagramme des flux
 Représente les flux échangés entre :
 Les acteurs du domaine d’étude ;
 Les acteurs du domaine d’étude et les partenaires extérieurs ou
domaine extérieur au domaine d’étude.
 Acteur : entité organisationnelle identifiable par la mission
qu’il remplit dans le cadre du champ d’étude défini.
 Acteur interne : acteur dont le missions se situent à l’intérieur
du champ d’étude. Par raccourci, on l’appelle aussi acteur.
 Acteur Externe (ou Partenaire) : acteur dont les missions se
situe en dehors du champ d’étude mais qui échange des
informations avec un acteur interne.
 Exemples : activité, service, personne, profil (secrétaire,
ingénieur, directeur…), matériel .

V. MCT
 Exemples :
 L’activité « gestion des commandes » s’occupe de passer des
commandes à ses fournisseurs.
 L’activité « gestion des clients » s’occupe de la réaliser des ventes
aux clients.
 L’activité « gestion des clients » envoie un avis de non paiement
au service contentieux.
 Le service contentieux envoie des rappels de non paiement au
client.
 Formalisme
Nom du flux 1 Nom de
Nom de
l’acteur 2
l’acteur 1
Nom de
Nom de Nom du flux 2
l’acteur
l’acteur 3
externe 1

V. MCT
 Exemple : Vente de livres par correspondance
facture
Client Service
bon de commande vente
Demande de réapprovisionnement
Service
Stock mis à jours
achat

V. MCT
 Graphe d’ordonnancement des flux
 Objectif : obtenir un MCT fiable et ne comportant pas de traitements
redondants.
Commande
Demande Réception
Facture
de réappro. produits
Stock mis à
jours

V. MCT
 5.3. Concepts de base
 Processus
 Ensemble d'opérations au sein d'un même domaine d’activité,
généralement déclenché par un événement externe (externe au
domaine ou au SI tout entier).
 Exemple : Processus de l’activité Gestion commerciale :
 Gestion des commandes
 Gestion des factures
 Gestion de la comptabilité des clients

V. MCT
 Opération
 Si un processus comporte un nombre important de traitements
on les regroupe en des ensembles plus élémentaires appelés
opérations.
 Une opération est une liste d’actions à exécuter par le SI en
réaction à un événement ou à une conjonction d’événements.
 Elle est productive d’événements.
 L'ensemble des actions de l'opération se déroule de façon
autonome (ne nécessitant pas d’autre événement que le
déclencheur initial) et sans interruption.
 Une opération constitue donc un bloc de traitement, une
succession de tâches plus élémentaires, qui ne doit pas souffrir
d’interruption dans son exécution, et dont l’exécution aboutit à
l’émission d’événements internes (poursuite de l’exécution du
processus) ou résultats (signaux pour l’extérieur).

V. MCT
 Exemple : L’ouverture d’un compte bancaire suite à la demande
d’un client.
 Evénement déclencheur : demande du client
 Opération : ouverture du compte
 Résultat : ouverture du compte
 Formalisme Exemple
A B Demande
Evénements entrants
d’ouverture
Conditions Synchronisation
d’exécution
Désignation de l’opération Ouverture d’un compte
Opération
Conditions d’émission de
résultats acceptée refusée
C D E Evénements sortants Compte Ouverture

ouvert refusée
148
V. MCT
 Evénement
 Fait réel qui sollicite le SI, déclenche une ou plusieurs
opérations.
 Evénement externe : événement que le SI perçoit en
provenance de l’extérieur et sur lesquels il n’a aucune maîtrise
et qui déclenche une opération.
 Evénement interne, ou événement intermédiaire : événement
qui se produit à la fin d’une opération.
 A ce niveau, il est appelé résultat de l’opération.
 Ce résultat pourra lui-même déclencher d’autres opérations.
 Evénement résultat : événement émis par le SI vers l’extérieur.
 Un événement peut être porteur d’information
 par exemple l’événement commande porte les informations suivantes :
numéro de la commande et date de la commande.

V. MCT
 Synchronisation d’événements
 L’exécution d’une opération est toujours conditionnée par un ou
plusieurs événements.
 Une synchronisation est une condition booléenne (ET / OU)
traduisant les règles de gestion que doivent respecter les
événements pour déclencher une opération.
 Dans le cas ET, elle marque qu'un événement déjà là doit en
attendre un ou plusieurs autres.
 Règle d’émission
 C’est une expression logique indiquant selon le résultat de
l'opération quels événements internes au SI sont créés
 Rôle des règles de gestion
 Recensées lors de l'étude de l'existant ou définies pour le futur
SI, elles décrivent les enchaînements d'opérations.
 Elles rendent possible le regroupement des actions au sein
d'une seule opération non interruptible.

V. MCT
 Exemple complet
Commande
Evénement externe
Commande
(déclencheur)
Facture Demande
de réappro.
Traitement de la commande Opération
Stock Stock Règles d’émission Réception
Evénement interne insuffisant suffisant produits
Facture Stock mis à

Demande de
réapprovisionnement jours
à centrale d'achat (b)
Réception Evénement résultat L’événement "Réception produit" à
produits (c) provoquer l’interruption de l’opération
"Traitement commande".
Synchronisation
b ET c
(marquant une attente) Cette interruption est due à une attente
Mise à jour du stock conceptuelle provoquée par un
événement représentant une nécessité
toujours du fonctionnement, et non par des
contraintes de l’organisation.
On a ici une attente conceptuelle due à

l’attente de réception de produits.
Stock mis à jours Evénement résultat
V. MCT
 5.4. MCTA
 MCT Analytique
 Permet la mise en relation données/traitement par
l’introduction des cycle de vie des objets ou données (CVO).
 Sa construction s’appuie sur le MFC.
 CVO
 Permettent de rendre compte des changements d’état des
objets.
 Changements d’état et formalisme

V. MCT
 Objet
 Entité de la mémoire permanente
 Exemples : Client, Commande, Facture, Détail commande…
 Etat d’un objet
 Stade transitoire par lequel passe un objet au cours de son
cycle de vie.
 Exemple : états de l’objet Commande
 à livrer, en attente, livrée, facturée, payée
 Représentation d’un objet
Objet Etat 1 : état avant l’exécution de l’opération
Etat 1 Etat 2 Etat 2 : état après l’exécution de l’opération
 Exemple
Commande
Une commande passe de l’état créée à l’état payée
Créée Payée

V. MCT
 Plusieurs sortes de représentation des états :
 Pas d’état avant : création de l’objet
Abonné
actif
 Un ou plusieurs états avant : modification de l’objet

Livre Livre
disponible emprunté emprunté réservé
 Un ou plusieurs états après : modification de l’objet

Candidat
admis
Créé
refusé
 Même états avant et après : modification de la valeur d’un
attribut, dans ce cas on met la MAJ à coté de l’objet
Produit
MAJ de la quantité en stock
créé créé

V. MCT
 Pas d’état après : suppression de l’objet
Abonné
actif
 Un état ou une ou plusieurs propriétés de l’objet : consultation

d’un objet
Contrat
date de contrat

V. MCT
 Opération conceptuel
 Déclenchée par un ou plusieurs événements
 Met en œuvre un ensembles de règles conceptuelles
 Consulte et met à jour les objets permanents
 Laisse les objets dans un état cohérent par rapport au
contraintes d’intégrités.
 Ne peut être interrompue par l’attente d’un événement externe
ou temporelle.
 Représentation

V. MCT
 Représentation

V. MCT
 Exemple
Commande
Gestion des commandes

Commande
Stock Stock Créée
insuffisant suffisant
Demande
Facture
de réappro
Règlement
reçu
b ET c
Gestion des règlement
Commande
toujours Créée Payée

V. MCT
 Exercices
 Créer le MCTA à partir du MCT et MCD ci-dessous.

V. MCT
 Solution

VI. MLD
 MLD : Modèle Logique de Données
 Représentation des données issues du MCD traduite dans
les concepts du modèle logique de données utilisé par le
SGBD choisi.
 Le MCD décrit la future base, indépendamment des choix
techniques d’implantation.
 Plusieurs types de MLD :
 Modèle hérarchique ;
 Modèle navigationel ;
 Modèle relationnel ;
 Modèle objet-relationnel.
 A chaque modèle est associé un SGBD
 SGBD navigationnel ;
 SGBD relationnel ;
 SGBD objet
K. M. BROU SGBD relationnel –objet.
Méthode d'analyse MERISE 161
VI. MLD
 6.2. Règle de passage du modèle E/A au modèle
relationnel
 Tableau de conversion
Entité Relation
Propriété de l’entité attribut de la relation
Identifiant de l’entité Clé primaire de la relation
 Règle1 :
 Chaque entité devient une relation.
 L’identifiant de l’entité est la clé de la relation
Entité
E1 Relation
a1e1 E(a1e1, a2e1)

a2e1

VI. MLD
 Règle2 :
 Association de type 1-n (ou relation de type père-fils)
 Le père est du côté de la cardinalité max n et le fils du côté de la
cardinalité max 1. L’identifiant du père et les propriétés de
l’association migrent chez le fils.
Entité1 : père Entité2 : fils

Relations
E1 E2
0, n A 0, 1 E1(a1e1, a2e1)
a1e1 a1e2
a2e1 ou a1a ou a2e2 E2(a1e2, a2e2, #a1e1, a1a)
1, n 1, 1

VI. MLD
 Règle 3 : Association de type m-n
 L’association devient une relation. Ses propriétés sont les
propriétés de l’association et les identifiants des entités qui
participent à l’association. Sa clé est la concaténation des
identifiants des entités qui participent à l’association.
Entité1 Entité2
Relations
E1 E2
0, n A 0, n E1(a1e1, a2e1)
a1e1 a1e2
a2e1 ou a1a ou a2e2 E2(a1e2, a2e2)
1, n 1, n
A(a1e1, a1e2, a1a)

VI. MLD
 Règle 4 : association réflexive
 On applique les règles 2 et 3 selon les cardinalités.
Entité
0, 1 ou 1, 1 Relatio
E1 Règle 2 n
A E1(a1e1, a2e1, a1e1Père, a1a)
a1e1
a1a
a2e1
0, n ou
1, n
Entité
0, n ou 1, n Relations
E1 Règle 3
A E1(a1e1, a2e1)
a1e1
a1a A(a1e1Père, a1e1Fils, a1a)
a2e1
0, n ou
1, n

VI. MLD
 Règle 5 : Association de type 1-1
Entité1 Entité2
Relations
E1 E2
a1e1 1, 1 A 1, 1 a1e2 E1(a1e1, a2e1, a1e2, a2e2, a1a)
a2e1 a1a a2e2
Entité1 Entité2
Relations
E1 E2
a1e1 1, 1 A 0, 1 a1e2 E1(a1e1, a2e1, a1e2, a1a)
a2e1 a1a a2e2 E2(a1e2, a2e2)
Entité1 Entité2
Relations
E1 E2
a1e1 0, 1 A 0, 1 a1e2 E1(a1e1, a2e1)
a2e1 a1a a2e2 E2(a1e2, a1e2)
ou
E1(a1e1, a2e1, a1e2, a1a)
E2(a1e2, a2e2)

VI. MLD
 Règle 6 : héritage d’entité
 L’identifiant de l’entité générique devient la clé des entités
spécialisées.
Entité générique
E1 Relations
a1e1 E1(a1e1, a2e1)
a2e1
E2(a1e1, a1e2)
E3(a1e1, a1e3)
E2 E3 E4(a1e1, a1e4)
a1e2 a1e3
Entités
spécialisées
E4
a1e4

VI. MLD
 Exemple récapitulatif
Client Commande Produit

0, n 1, 1 1, n ligneDeCom 0, n
codeCl passe numCom refPr
nomCl date qté Libellé
adresse PU
1, 1
traite
Représentant Sup.
0, n 0, n chef
codeRep
nomRep 0, 1
Inf.
 Par application des règles ci-dessus on obtient le schéma

relationnel suivant :
 Client(codeCl, nomCl, adresse)
 Commande(numCom, date, #codecl, #codeRep)
 Produit(refPr, libellé, PU)
 Représentant(coderep, nomRep, #codeRepChef)
 LigneDeCom(#numCom, #refPr, qté)
Bibliographie
 Livres
 "Modélisation dans la conception des systèmes
d’information", Edition Masson.
 "Les fichiers et organisation des données", C. JOUFFROY,
C.LEITANG, Bordas Informatique.
 "Base de données et systèmes relationnels", C. DELOBEL,
M. ADIBA, Dunod Informatique.
 "Les bases de données relationnelles", Serge MIRANDA,
José Maria BUSTA.
 "Base de données, les systèmes et leurs langages", G.
GARDARIN, Edition Eyrolles.
 "Système d’information et base de données", GALACSI,
Bordas Informatique.
 « Comprendre Merise, Outils conceptuel et organisation »,
Jean-Patrice Matheron, Edition Eyrolles.
 « Merise et UML pour la modélisation des systèmes
d’informations », Joseph Gabay, 4e édition, Dunod.
 « Ingénierie des systèmes d’information : Merise
deuxième génération », Dominique Nanci, Bernard
Espinasse, Edition Sybex, 3e édition.
Bibliographie
 « Ingénierie des systèmes d’information : Merise deuxième
génération », Dominique Nanci, Bernard Espinasse, Edition
Sybex, 4e édition.
 « Génie logiciel, Conception des systèmes d’information :
panorama des méthodes et des techniques », Pascal
ANDRE, Alain VAILLY, Edition Ellipses.
170
Bibliographie
 Webogaphie
 http://selsek.free.fr/eloker/miage/cours%20M1/msi/Pol
y-Merise2%20IUT-Info-Grenoble.pdf
 http://www.infres.enst.fr/~dombd/polyv7/
 http://lbdwww.epfl.ch/f/teaching/courses/poly2/11/11.h
tm
 Cours de Yolaine.Bourda@supelec.fr
 Cours de Mme Silber cours@www-aius.u-strasbg.fr
 http://www.proplus-
donbosco.net/courses/INITIATIONAUXSCIENCESDELINGE
NIEUR/document/Module_1/cours_analyse_fonctionnelle/
fiche_SADT.pdf?cidReq=INITIATIONAUXSCIENCESDELING
ENIEUR
 www.labo-sgbd.fr.st
 http://www.iutc3.unicaen.fr/~moranb/cours/acsi/valid/t
able.htm
 http://www.iutc3.unicaen.fr/~moranb/cours/acsi/activite
s/activ19.htm
171

Ch5Merise - Copie PDF

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

Ch5Merise - Copie PDF

Transféré par

Droits d'auteur :

Formats disponibles

Informatique de gestion :

Konan Marcellin BROU

K. M. BROU Méthode d'analyse MERISE 2

K. M. BROU Méthode d'analyse MERISE 3

K. M. BROU Méthode d'analyse MERISE 4

K. M. BROU Méthode d'analyse MERISE 5

K. M. BROU Méthode d'analyse MERISE 6

K. M. BROU Méthode d'analyse MERISE 7

Analyse du Conception Réalisation

K. M. BROU Méthode d'analyse MERISE 8

K. M. BROU Méthode d'analyse MERISE 9

K. M. BROU Méthode d'analyse MERISE 12

K. M. BROU Méthode d'analyse MERISE 13

K. M. BROU Méthode d'analyse MERISE 14

K. M. BROU Méthode d'analyse MERISE 15

K. M. BROU Méthode d'analyse MERISE 16

Scénario cas d’utilisation Retirer de l’argent

K. M. BROU Méthode d'analyse MERISE 19

K. M. BROU Méthode d'analyse MERISE 20

 Indépendante vis à vis de la technologie.

 Plus utilisée en France dans les domaines de gestion.

 Sert de référence aux enseignements sur les méthodes.

K. M. BROU Méthode d'analyse MERISE 22

charbon Chaudière Chaleur

 Exemple 2 : commande des clients

K. M. BROU Méthode d'analyse MERISE 24

K. M. BROU Méthode d'analyse MERISE 25

K. M. BROU Méthode d'analyse MERISE 26

K. M. BROU Méthode d'analyse MERISE 27

Management Décision Informations traitée

Entrée des Sortie des éléments

K. M. BROU Méthode d'analyse MERISE 28

Bon de Bon de commande

Système opératoire Client

Décision Information sur le SO Information-interaction

K. M. BROU Méthode d'analyse MERISE 29

K. M. BROU Méthode d'analyse MERISE 30

Calculer Facturer Suivre Domaine

Proposition de devis Facture Relance, Reçu

K. M. BROU Méthode d'analyse MERISE 31

Niveau physique Mise en œuvre

Niveau logique Réalisation

Niveau organisationnel Etude détaillée

K. M. BROU Méthode d'analyse MERISE 33

K. M. BROU Méthode d'analyse MERISE 34

K. M. BROU Méthode d'analyse MERISE 35

K. M. BROU Méthode d'analyse MERISE 36

K. M. BROU Méthode d'analyse MERISE 37

Expression des besoins

Modèle conceptuel MCD, MCT, MOD, MOT

Modèle logique MLD relationnel, réseau, objet…

Modèle physique Choix du matériel, des SGBD,…

K. M. BROU Méthode d'analyse MERISE 39

K. M. BROU Méthode d'analyse MERISE 40

K. M. BROU Méthode d'analyse MERISE 43

K. M. BROU Méthode d'analyse MERISE 46

K. M. BROU Méthode d'analyse MERISE 47

K. M. BROU Méthode d'analyse MERISE 48

K. M. BROU Méthode d'analyse MERISE 49

 Adapté pour des projets de petite taille, et dont le domaine est

K. M. BROU Méthode d'analyse MERISE 51

 Adapte pour des projets dont le domaine est bien maîtrisé

K. M. BROU Méthode d'analyse MERISE 52