MAMPUYA KINKANI

Pescie Honoré, PhD.

Modelisation
Merise

EDUPC, Novembre 2023

Editions de l’Université Protestante au Congo

 1

MAMPUYA KINKANI Pescie Honoré, PhD.

MUKENDI Fabrice
ESAKI Christian

Modéliser avec MERISE

EDUPC, Janvier 2023

Editions de l’Université Protestante au Congo

Copyright © Université Protestante au Congo – Mampuya Kinkani Pescie Honoré
Croisement du Boulevard Triomphal et Av. de Libération
Kinshassa/lingwala (BP. 4745 Kinshasa 2) RDC.

Toute reproduction d’un extrait de ce livre, par quelque procédé que ce soit, no-
tamment par photocopie ou microfilm est strictement interdite.
Imprimé à Kinshassa, janvier 2023
 3

TABLE DES MATIERES

PREFACE .................................................................................................................................................................... 6

AVANT-PROPOS ....................................................................................................................................................... 7

CHAPITRE 1 : INTRODUCTION AUX METHODES D’ANALYSE ET DE CONCEPTION DES SYSTEMES D’INFORMATION . 9

1. GENERALITE SUR LA METHODE ......................................................................................................... 9

2. DEFINITION DE CONCEPTS ............................................................................................................................... 10

2.1. LA SYSTEMIQUE................................................................................................................................................. 10

2.2. L’INFORMATION ................................................................................................................................................ 11

2.3. LE SYSTEME D’INFORMATION ............................................................................................................................... 12

2.3.1. LA REPRESENTATION SCHEMATIQUE DES SYTEMES DE L’ENTREPRISE .......................................................................... 14

2.3.2. LE SYSTEME DE PILOTAGE ................................................................................................................................. 15

2.3.3. LE SYSTEME D’INFORMATION ............................................................................................................................ 16

2.3.4. LE SYSTEME OPERANT ...................................................................................................................................... 16

2.4. LES DONNEES (OU INFORMATIONS) ....................................................................................................................... 16

2.4.1. L’INTERVIEW OU L’ENTRETIEN ........................................................................................................................... 17

2.4.2. L’OBERSEVATION ............................................................................................................................................ 17

2.4.3. L’ETUDE DES DOCUMENTS INTERNES ET EXTERNES ................................................................................................. 17

2.4.4. LA TECHNIQUE DE QUESTIONNAIRES ................................................................................................................... 18

2.5. LES DIFFERENTS TYPES D’INFORMATIONS ............................................................................................................... 18

2.5.1. LES INFORMATIONS ELEMENTAIRES ET MEMORISABLES ........................................................................................... 18

2.5.2. LES INFORMATIONS CALCULEES ......................................................................................................................... 18

2.5.3. LES TRAITEMENTS ........................................................................................................................................... 19

2. ANALYSE DES SYSTEMES D’INFORMATION ................................................................................................ 19

3. LA PROCEDURE D’INFORMATISATION ....................................................................................................... 24

CHAPITRE II : PRESENTATION DE LA METHODE MERISE ................................................................................. 26

2.1. HISTORIQUE DE LA METHODE MERISE.................................................................................................................... 26

2.3. PRESENTATION GENERALE ................................................................................................................................... 27

2.4. LES TROIS COMPOSANTES DE LA METHODE MERISE ................................................................................................. 27

2.4.1. La démarche ou cycle de vie ................................................................................................................. 27

.2.4.2. Les raisonnements ou cycle d’abstraction ........................................................................................... 31

2.4.3. La maîtrise du projet ou cycle de décision ............................................................................................ 33

2.5. ETUDES PREALABLES ET ANALYSE DE L’EXISTANT ....................................................................................................... 34

 4

2.5.1. ETUDES PREALABLES ....................................................................................................................................... 35

2.5.1.1. FORMATION DE GROUPE D’ETUDE ............................................................................................................ 36

2.5.1.2. PLANIFICATION DES ACTIVITES D’UN PROJET................................................................................................ 36

2.5.1.3. TECHNIQUES DE RECOLTE DE DONNES........................................................................................................ 37

2.5.2. ANALYSE DE L’EXISTANT .............................................................................................................................. 37

1) ANALYSE DE LA STRUCTURE ............................................................................................................................... 38

2) ANALYSE DE POSTE DE TRAVAIL .......................................................................................................................... 39

3) ANALYSE DE DOCUMENTS UTILISES ..................................................................................................................... 41

LE DICTIONNAIRE DES DONNEES .................................................................................................................................. 42

4) ANALYSE DES MOYENS DE TRAITEMENT ............................................................................................................... 44

A. LES MOYENS MATERIELS ................................................................................................................................... 44

B. LES MOYENS HUMAINS .................................................................................................................................... 45

5) ANALYSE DE FLUX D’INFORMATIONS ................................................................................................................... 46

5.1 APPLICATION DE SCHEMA DE CIRCULATION DES INFORMATIONS ................................................................................... 47

6) DIAGNOSTIC DE L’EXISTANT .............................................................................................................................. 54

CHAPITRE III : CONCEPTION DU SYSTEME D’INFORMATION ORGANISE (ETUDE DETAILLEE) .................................. 57

2.6. LE MODELE CONCEPTUEL ............................................................................................................................. 57

2.6.1. LE MODELE CONCEPTUEL DES DONNEES (MCD) ............................................................................................... 57

a) Les propriétés ............................................................................................................................................. 58

b) Les entités ou objets ................................................................................................................................... 58

L’identifiant .................................................................................................................................................... 58

c) Les relations ou associations ...................................................................................................................... 59

Les cardinalités ............................................................................................................................................... 60

Les relations porteuses ................................................................................................................................... 62

d) Régles d’usages .......................................................................................................................................... 64

Notions d’entité forte et d’entité faible ......................................................................................................... 66

3.1.2. DICTIONNAIRE DES DONNEES ............................................................................................................................ 67

3.1.3. LES DEPENDANCES FONCTIONNELLES .............................................................................................................. 70

3.1.3.1. DES DONNEES AUX DEPENDANCES FONCTIONNELLES .................................................................................... 70

3.1.3.2. DEPENDANCES FONCTIONNELLES ELEMENTAIRES ................................................................................................ 71

3.1.3.3. DEPENDANCES FONCTIONNELLES ELEMENTAIRES DIRECTES ............................................................................ 72

3.1.3.4. DEPENDANCES FONCTIONNELLES COMPOSEES ............................................................................................. 72

 5

METHODOLOGIE D’ELABORATION DES DEPENDANCES FONCTIONNELLES .............................................................................. 73

ETUDE DES CAS PRATIQUES......................................................................................................................................... 73

DICTIONNAIRE DES DONNEES ...................................................................................................................................... 74

DETERMINATION DES DEPENDANCES FONCTIONNELLES OU DF .......................................................................................... 75

GRAPHE DES DEPENDANCES FONCTIONNELLES ................................................................................................................ 77

MATRICE DES DEPENDANCES FONCTIONNELLES .............................................................................................................. 77

3.1.4. NOTIONS D'INTEGRITE FONCTIONNELLE .......................................................................................................... 78

3.1.5. NOTIONS D'IDENTIFIANT RELATIF................................................................................................................... 79

2.6.2. LE MODELE CONCEPTUEL DES TRAITEMENTS (MCT) .......................................................................................... 91

2.7. LE MODELE ORGANISATIONEL ....................................................................................................................... 95

2.7.1. LE MODELE ORGANISATIONEL DES DONNEES .................................................................................................... 96

2.7.1.1. CHOIX DES DONNEES A MEMORISER INFORMATIQUEMENT ............................................................................. 97

Identification des types de sites et des types d'acteurs : ................................................................................ 97

Détermination des données à retenir au niveau organisationnel .................................................................. 97

Détermination des droits d'accès ................................................................................................................... 98

La visibilité des données par site organisationnel .......................................................................................... 98

Exemple de construction d’un MOD : Cas d’une applicatiion de suivi de temps de vol : ................................ 99

2.7.2. LE MODELE ORGANISATIONEL DES TRAITEMENTS ............................................................................................ 104

CHAPITRE IV : CONCEPTION DU SYSTEME D’INFORMATION INFORMATISE (ETUDES TECHNIQUES).....................108

4.1. MODELE LOGIQUE.................................................................................................................................... 108

4.1.1. MODELE LOGIQUE DES DONNEES (MLD) ...................................................................................................... 108

4.1.1.2. LES FORMES NORMALES .............................................................................................................................. 119

Introduction aux formes normales ............................................................................................................... 119

Schéma relationnel associé .......................................................................................................................... 125

4.1.2. MODELE LOGIQUE DES TRAITEMENTS (MLT) ................................................................................................. 126

Vocabulaire spécifique utilisé ....................................................................................................................... 126

Règles de passage du MOT au MLT .............................................................................................................. 126

4.2. MODELE PHYSIQUE .................................................................................................................................. 133

4.2.1. MODELE PHYSIQUE DES DONNEES (MPD) .................................................................................................... 133

Transcription SQL du modèle physique ........................................................................................................ 135

4.2.2. MODELE PHYSIQUE DES TRAITEMENTS (MPT) ............................................................................................... 136

CHAPITRE V : ETUDE DES CAS AVEC POWERAMC ...................................................................................................138

 6

5.1. OBJECTIFS ET PREREQUIS................................................................................................................................... 138

5.2. LES MODELES MERISE ET LES MODELES POWERAMC............................................................................................ 139

5.3. L’INTERFACE GRAPHIQUE DE POWERAMC ........................................................................................................... 140

5.3.1. DEMARRAGE DE POWERAMC ........................................................................................................................ 140

I5.3.2. CREATION D'UN NOUVEAU MCD.................................................................................................................... 141

5.3.3. UTILISATION DES OUTILS DE LA PALETTE ............................................................................................................ 142

5.3.4. DEFINITION DES PREFERENCES ET DES OPTIONS DE MCD ...................................................................................... 146

5.3.5. DEFINITION DES PROPRIETES DE MCD .............................................................................................................. 148

5.3.6. CREATION D'UNE REGLE DE GESTION ................................................................................................................ 148

5.3.7. CREATION D'UN DOMAINE.............................................................................................................................. 151

5.3.8. CREATION D'UNE ENTITE ................................................................................................................................ 155

5.3.9. CREATION D'UNE ENTITE ASSOCIATIVE .............................................................................................................. 157

5.3.10. DEFINITION D'ATTRIBUTS D'ENTITE ................................................................................................................. 158

5.3.11. DEFINITION D'UN IDENTIFIANT ...................................................................................................................... 161

5.3.12. CREATION D'UNE RELATION .......................................................................................................................... 164

BIBLIOGRAPHIE ................................................................................................................................................. 168

PREFACE
La mise en place de n’importe quelle application informatique passe préalablement par
une activité d’analyse qui du reste est indispensable pour toute informatisation. Ce sujet
demeure passionnant pour es informaticiens qui sont appelés à apprendre continuelle-
ment de nouvelles approches et techniques pour développer le logiciel de manière effi-
ciente et efficace.
L’Analyse Informatique est très complexe suite à son caractère abstrait d’où la nécessité
pour le maitre d’œuvre de se résoudre à adopter une démarche plus cohérente, métho-
dique, reproductible et flexible.
 7

Ce livre sur la méthode Merise s’adresse tout particulièrement aux étudiants en premier
cycle d’informatique et à toute personne souhaitant une information simple, directe et
pratique sur la méthode Merise.
Au travers des chapitres sur la méthode Merise, vous découvrirez comment :
 Faire l’étude préalable et l’analyse de l’existant ;
 Réaliser les différents modèles (modèles conceptuels, modèles logiques,
modèles physiques) mais aussi les modèles spécifiques aux traitements (modèles con-
ceptuels des traitements, modèles organisationnels des traitements…) ;
 Modéliser avec les extensions Merise/2 (Comparer certains modèles Merise à cer-
tains diagrammes UML).

Avec PowerAMC15, pour la pratique, ce livre sera votre précieux compagnon.

Professeur MUSANGU LUKA Marcel

In Memoriam

AVANT-PROPOS
Notre monde, je voulais dire le monde informatique se trouve à un tournant très impor-
tant qui correspond à un changement total de culture et de comportement.
Cette génération est appelée « génération utilisateur) qui trouve son sens de nos jours
dans les langages de quatrième génération : l’intelligence artificielle, le génie logiciel, la
programmation orientée objet, la logique floue, les concepts d’intégrations, les multimé-
dias, etc.
Il devient donc plus que jamais nécéssaire de maîtriser, de bien asseoir ou mieux de con-
naitre les systèmes informations dans lesquels vient s’integrer cette informatique nou-
velle.
 8

Le système d’iinformation (SI), peut être vu comme un ensemble des taches complexes
regroupées en modules specialisées qui composent l’applicatif informatique : le logiciel.
Ces taches sont considérées comme un assemblage des taches plus simples. Ces der-
nières sont les briques de base de l’applicatif c’est-à-dire comme les briques qu’un ma-
con assemble pour eriger une maison. Le logiciel, tout comme une maison, a besoin
d’un plan de conception réalisé par un architecte. Une maison conçue sans plan risque
de presenter des erreurs de conception une fois fini. Il en est de meme pour le logiciel.
Sans étude préalables, construit sans méthodologie (Merise), risque de surprendre son
utilisateur.
 9

CHAPITRE 1 : INTRODUCTION AUX METHODES D’ANALYSE ET DE

CONCEPTION DES SYSTEMES D’INFORMATION

1. GENERALITE SUR LA METHODE

La méthode d'analyse informatique décrit comment modéliser et construire des systèmes logiciels
de manière fiable et reproductible.

De manière générale, les méthodes permettent de construire des modèles à partir d'éléments de
modélisation qui constituent des concepts fondamentaux pour la représentation de systèmes ou
de phénomènes.

Les méthodes définissent également une représentation, souvent graphique, qui permet d'une part
de manipuler aisément les modèles, et d'autre part de communiquer et d'échanger l'information
entre les différents intervenants. Une bonne représentation recherche l'équilibre entre la densité
d'information et la lisibilité.

En plus des éléments de modélisation et de leurs représentations graphiques, une méthode définit
des règles de mise en œuvre qui décrivent l'articulation des différents points de vue, l'enchaîne-
ment des actions, l'ordonnancement des tâches et la répartition des responsabilités. Ces règles
définissent un processus qui assure l'harmonie au sein d'un ensemble d'éléments coopératifs et
qui explique comment il convient de se servir de la méthode.

Une méthodologie d'analyse propose au concepteur des modèles, des méthodes et des outils.

 Un modèle, au sens d'une théorie de la modélisation, est un ensemble de concepts et de

lois (de complétude, de cohérence, de transformation ...) unissant ces concepts. Concepts
et lois qui per- mettent de décrire "intelligemment" une réalité. A titre subsidiaire, un
modèle comporte des formalismes, qu'il ne faut pas croire limités aux seuls schémas gra-
phiques ou diagrammes dont, à l'instar de tout concepteur.
 Une méthode propose des démarches et des règles de bon usage. Idéalement, elle se
fonde sur des modèles éprouvés et vise à en exploiter les potentialités en vue de fabri-
quer des objets répondant à certains critères de qualité.

Une méthode est nécessaire :

 Pour maîtriser la complexité du problème informationnel à résoudre ;

 Pour sortir la construction des systèmes d'information de l'empirisme individuel et la
fonder sur une coopération efficace entre informaticiens et gestionnaires;
 Pour permettre la communication entre individus de l'équipe de conception;
 Pour construire des systèmes pertinents, fiables, flexibles et adaptatifs;
 10

 Pour permettre d'évaluer le système à tout moment de son cycle, tant sur le plan de
son efficacité technique que sur celui de sa pertinence par rapport aux besoins des
gestionnaires ;
 Pour améliorer les coûts, les délais et la productivité des activités de développement.

.
Les équipes de développement ont besoin d’une méthode de travail contrôlée, d’un processus
intégrant les diverses facettes du développement et d’une approche commune, c’est-à-dire d’un
processus capable :
Introduction A l’Analyse Informatique

De dicter l’organisation des activités de l’équipe ;

De diriger les tâches de chaque individu et de l’ensemble de l’équipe ;
De spécifier les artefacts à produire ;
De proposer des critères pour le contrôle et l’évaluation des produits et des activités
du projet.

2. DEFINITION DE CONCEPTS
Dans cette section, il sera question de définir les principaux concepts utilisés dans la méthode
d’analyse informatique.

2.1. La systémique

Il existe de nombreuses définitions du mot système, chaque auteur apportant sa propre

contribution, en fonction de ce qu’il cherche à dire et du degré d’exhaustivité nécessaire
de son exposé.

En anatomie, un système designe un ensemble de parties similaires qui participent à une

activité commune (système cardiaque, système digestif, système respiratoire, etc.). En
science, le système peut servir pour definir des unités par exemple le système metrique.

Selon le Robert, un système est un dispositif formé par la réunion d’éléments analogues.
La définition du Larousse semble plus explicite : « combinaison de parties qui se coor-
donnent pour concourir à un résultat, de manière à former un ensemble ». Tout système
fonctionne en transformant des flux d’entrée en flux de sortie selon le processus plus au
moins complexe.

Domique Dionisi dans son ouvrage, l’essentiel sur Merise, retient la définition sui-
vante : « un système est un tout constitué d’éléments unis par des relations, ces éléments
et ces relations étant munis des propriètés ». Décrire un tel système consiste à déterminer
ses éléments et ses relations, leurs propriètés et les valeurs que peuvent prendre ces der-
nieres, ainsi que son activité et l’organisation qui en decoule.
 11

En latin et en grec, le mot « système » veut dire combiner, établir, rassembler. Le concept
système a été défini de plusieurs manières par différents auteurs :
Un système est un assemblage d'éléments reliés entre eux compris dans un ensemble
plus grand. Selon Joel de Rosnay, un système est un ensemble d’éléments en interaction
dynamique poursuivant un but commun.
Jean LOUIS LEMOINE définit le système comme :
 Quelque chose (n’importe quoi identifiable) ;
 Qui fait quelque chose (activité ou fonction) ;
 Qui est doté d’une structure ;
 Qui évolue dans le temps ;
 Pour quelque chose ;
Partant de ces définitions, nous pouvons dire que l’entreprise peut être considérée
comme un système constitué d’éléments en interaction. Ces éléments ne sont pas sta-
tiques, mais dynamiques poursuivant un but ou des objectifs commun.
Un système peut être composé des sous-systèmes. Généralement, un système est cons-
titué de composants (ou d'éléments) organisés ensemble dans le but de faciliter le flux
d'informations, de matières ou d'énergie.

2.2. L’information

Une information est un message, un renseignement ou un événement susceptible d’être

communiqué entre les hommes et suffisamment explicite pour pouvoir déclencher une
action ou une réaction auprès du destinataire.
Pour être exploitée par l’homme a qui, il est destiné, le message, le renseignement ou
l’événement doit être correct, c'est‐à‐dire avoir un sens. A cet effet, il doit renseigner
aussi bien sur le contexte que sur toutes les valeurs particulières se rapportant au con-
texte.
L'information est représentée par des données, c'est-à-dire des formes écrites (textes,
nombres ...), picturales (graphiques, dessins, photos, vidéos ...) et sonores. Ces données
sont matérialisées sur des supports (papier, écrans, bandes magnétiques, disquettes, CD
...). A ces représentations, un être humain, une organisation ou une machine (ordina-
teur, robot ...) attache une signification susceptible d'entraîner une modification, immé-
diate ou différée, de son comportement.
 12

Exemple : un automobiliste voyant les lettres STOP sur un panneau rouge octogonal
[données] arrête sa voiture [comportement]
Exemple : un client ayant reçu une facture [données] prend son téléphone [comporte-
ment] pour donner un ordre de virement à sa banque [données] ; l'agent de la banque
recevant de la ligne téléphonique les chiffres composant le virement [données] effectue
diverses opérations [comportement]
Exemple : après avoir accumulé des données statistiques relatives à ses ventes, à la con-
currence, etc., la direction d'une entreprise commerciale décide de changer sa politique
et de modifier son catalogue : elle en retire certains produits et en introduit d'autres.
On peut définir une information comme étant l'accroissement de connaissance décou-
lant de l'interprétation d'un ensemble de données. Cette interprétation est le fait d'un
acteur humain ou mécanique.

2.3. Le système d’information

Un système d’information est un ensemble de personnes, de procédures et de res-

sources qui recueillent de l’information, la transforment et la distribuent au sein d’une
organisation.
Le système d'information est le véhicule de la communication dans l'organisation. Sa
structure est constituée de l'ensemble des ressources (les hommes, le matériel, les logi-
ciels) organisées pour : collecter, stocker, traiter et communiquer les informations. Le
système d'information coordonne grâce les activités de l'organisation et lui permet ainsi
d'atteindre ses objectifs.
Né dans les domaines de l'informatique et des télécommunications, le concept de SI
s'applique maintenant à l'ensemble des organisations, privées ou publiques. Le concept
de système d'information (SI) a été défini de différentes manières suivantes :
Un ensemble organisé de ressources (personnel, données, procédures, matériel, logiciel,
…) permettant d'acquérir, de stocker, de structurer et de communiquer des informations
sous forme de textes, images, sons, ou de données codées dans des organisations. Selon
leur finalité principale, on distingue des systèmes d'information supports d'opérations
(traitement de transaction, contrôle de processus industriels, supports d'opérations de
bureau et de communication) et des systèmes d'information supports de gestion (aide à
la production de rapports, aide à la décision…).
 13

Un système ou sous-système d'équipements, d'informatique ou de télécommunication,

interconnectés dans le but de l'acquisition, du stockage, de la structuration, de la ges-
tion, du déplacement, du contrôle, de l'affichage, de l'échange (transmission ou récep-
tion) de données sous forme de textes, d'images, de sons, et/ou, faisant intervenir, du
matériel et des logiciels.
Un SI est un réseau complexe de relations structurées où interviennent hommes, ma-
chines et procédures qui a pour but d’engendrer des flux ordonnés d’informations per-
tinentes provenant de différentes sources et destinées à servir de base aux décisions.
Un SI est un ensemble d'éléments matériels ou immatériels (hommes, machines, mé-
thodes, règles) en interaction transformant en processus des éléments (les entrées) en
d'autres éléments (les sorties).
La confusion est fréquente entre systèmes d’information et systèmes informatisés. Cela
provient en grande partie de ce que la réflexion sur l’existence du SI, indissociable de
toute organisation, est devenue indispensable face à l’apparition des problèmes générés
par l’informatisation croissante de l’entreprise. Une partie du SI peut être informatisée.
Nous parlerons alors du système informatisé. Ce système informatisé prend appui sur un
système informatique composé de materiel et de logiciel de base.

Système informatisé

Système d’information

Système Informatique

Figure 1.1 : représentation du système d’information-système informatisé- système informatique

Le système informatisé se doit d’être au service du système d’information mis en place

par les dirigeants de l’entreprise, et non l’inverse comme on le voit souvent. C’est un
leurre que de laisser croire que le système informatique peut apporter de l’organisa-
tion.on informatise bien que ce qui marche bien. Le concept de SI revouvre en fait deux
réalités :

- L’organisation elle-même qui agit et evolue à travers l’information, cette notion

apparentant le SI à un objet naturel ;
 14

- Le système construit par l’homme pour représenter la communication et mémo-

riser l’information ; on parle alors d’objet artificiel(ou artefact).

La conception du SI se situe en permanence dans une reflexivité entre l’organisation,

objet naturel, et sa représentation, objet artificiel. Une fois réalisé, le SI est integré à l’or-
ganisation et devient un objet naturel.

Conception

Système d’information naturel Système d’information artificiel

Intégration

Figure 1.2 : représentation du système d’information : conception- intégration

2.3.1. La représentation schematique des sytèmes de l’entreprise

Si nous reprenons l’analogie anatomique, et si nous comparonsl’entreprise à un corps

humain, nous pouvons reduire l’entreprise à un cerveau qui pilote, un muscle qui opère
et des nerfs qui font transiter les informations.

Le bon fonctionnement d’une entreprise dépend de la manière dont l’information est

perçue, stockée, traitée et diffusée. Dès lors que l’entreprise en tant que système com-
plexe ne répond pas à cette règle, elle ne pourra jamais atteindre ses objectifs. Ainsi, une
entreprise en tant que système complexe est un ensemble avec des sous-ensembles dont
le but est d’atteindre les objectifs qu’elle s’est assignées.
Voici un schéma simplifié qui en decoule :
 15

Environnement
Système de pilotage

Information Information à
mémorisée mémoriser

Système d’information

Information à Information
mémoriser mémorisée

Système opérant
Flux de données

Sortantes

Flux de données

Entrantes

Figure 1.3 : représentation schématique des systèmes de l’entreprise

2.3.2. Le système de pilotage

Le système de pilotage (S.P) a pour objectif d’arrêter des stratégies pour le bon fonction-
nement de l’entreprise. Il est appelé autrement système décisionnel, car il décide du sort
de l’entreprise à court et moyen terme.
Il a pour activité :
 Réfléchir : adaptation à l’environnement, conception ;
 Décider : prévision, allocation, planification ;
 Contrôler.
 16

2.3.3. Le système d’information

Le système d’information (S.I) joue le rôle de la courroie de transmission entre le système

de pilotage et le système opérant. Il est un ensemble d’information et de moyens utilisés
pour exploiter ses informations. Il s’agit des moyens : matériels, humains, logiciels, finan-
ciers, …
Il a pour activité :
 Générer (produire) les informations ;
 Mémoriser ;
 Diffuser ;
 Traiter.

2.3.4. Le système operant

Le système opérant (S.O) ou d’exécution a pour objectif d’exécuter les ordres provenant
du système décisionnel via le système d’information et d’en faire un rapport après exé-
cution.
Il a pour activité : transformer les informations, produire et rapporter les résultats.

2.4. Les données (ou informations)

L’information est l’émission ou la réception de signaux oraux ou écrits, sonores, visuels

ou multimédias dont le but est de déclencher les processus alimentant l’échange, base
naturelle et indispensable de l’alimentation de l’organisation.

Les informations se recuiellent à l’intérieur du domaine à étudier. Les techniques utilisées

lors de l’analyse de l’existant pour recueillir les données sont multiples, cependant en
informatique les techniques comme :
 L’interview ;
 L’observation ;
 Documentaire ;
 Questionnaires (Enquête) sont les plus utilisées.
 17

2.4.1. L’interview ou l’entretien

C’est la technique la plus utilisée pour étudier le système existant.

Les entretiens : sont les interviews à travers lesquels on peut poser les questions pour
connaitre en détail ce qui ne fonctionne pas et ce qu’on peut améliorer.
La technique d’interview nécessite une préparation, ainsi l’analyste doit établir avant l’in-
terview, les différentes questions à poser aux interlocuteurs ces questions sont souvent
conçu à l’aide des outils informatiques. Cependant l’expérience de l’analyste compte
beaucoup au cours de l’interview et à la fin de l’interview.
 Ne pas utiliser les termes trop techniques ;
 Etre bien habillé ;
 Préparer les questions ;
 Rappeler toujours le but de votre visite ;
 Ne pas interrompre celui qui parle ;
 Promettre toujours de passer une fois le travail terminer ;
 Maitriser la langue du travail.

2.4.2. L’obersevation

L’observation nécessite la présence de l’analyste dans les différents postes de travail con-
cernés par l’application. On recommande toujours au niveau de chaque poste de travail,
un délai d’au moins deux semaines pour observer (voir) la façon de travailler de l’agent
ainsi que les documents traités.

2.4.3. L’etude des documents internes et externes

Cette technique consiste à consulter les documents existants afin de se faire une idée
sur la pertinence des informations contenues dans ce document. Dans le cas où l’entre-
prise garde des archives, ainsi on peut toujours se référer à ces archives, pour récolter
les données désirées.

L’etude des documents externes et internes (factures, bon de livraison, ordre de fabrica-
tion, etc.) recèlent des informations qui sont souvent omises lors des entretiens et de
decouvrir aussi quelques regles de gestion.

Avant d’ajouter une information, il est imperatif de s’assurer qu’elle n’est pas déjà
preésente. Par exemple, un numéro client peut apparaître sur un bon de livraison et sur
une facture. Ce n’est pas la peine de le répertorier deux fois.
 18

2.4.4. La technique de questionnaires

Cette technique nécessite des moyens financiers énormes, liés aux problèmes des res-
sources humaines et autres.
En outre, cette technique nécessite la présence des spécialistes dans l’élaboration des
questions qui peuvent être de types fermés ou ouverts.
NB :
 Les étapes évoquées ci-dessus sont appelées étapes préliminaires ou travaux orga-
nisationnels.
 Après avoir défini les objectifs, formés des groupes d’études, planifier les travaux
choisi les techniques de récoltes de données, on peut alors passer à l’analyse du
système existant.

2.5. Les differents types d’informations

2.5.1. Les informations élémentaires et mémorisables

Les informations élémentaires sont des informations dont les valeurs ne peuvent pas être
inventées, elles ne sont pas déductibles d’autres informations.

Par exemple, un nom de client ou sa raison sociale ne peuvent pas être inventés. Une
quantité commandée ne peut pas non plus être inventée.

Une information doit être atomique, c’est à dire non décomposable. Par exemple si l’in-
formation ADRESSE doit contenir « 36, rue des bananiers, commune de ngaliema,
Kinshasa » celle –ci peut être decomposée en plusieurs informations :

 Adresse
 Commune
 Ville

Chaque valeur prise par une information est appelée une occurrence. Par exemple, l’in-
formation Nom peut avoir les occurrences suivantes :

 Mampuya
 Pescie

2.5.2. Les informations calculées

Les informations calculées sont déductibles des informations élémentaires. Par exemple,
le total d’une ligne de commande est les résultats de la multiplication du prix de vente
hors taxe et de la quantité commandée.
 19

2.5.3. Les traitements

Ils sont collectés comme les informations via un processus d’interview et d’études des
documents. Ils peuvent être de deux sortes : automatique et manuels. Ils sont déclenchés
par l’arrivée d’évènements.

La gestion des traitements sert à identifier les fonctionalités selon une approche qui va
du général au particulier et qui définit leur découpage et leur enchaînement

2. ANALYSE DES SYSTEMES D’INFORMATION

Comme tout phénomène humain, un système d'information évolue et est périodiquement atteint
d'obsolescence. Il est alors nécessaire d'en développer un nouveau ou, du moins, une nouvelle
version. Cette idée de développer ou fabriquer est évidemment particulièrement pertinente pour
la partie "programmée" du système, c'est-à-dire pour les applications informatiques.

Dans le développement d'un projet informatique, on donne le nom général d'analyse à l'ensemble
des démarches accomplies avant de rédiger et mettre au point les programmes.

L'analyse se déroule en plusieurs étapes et elle procède à différents niveaux ou de différents

points de vue.

2.1. Etapes de l’analyse

La tradition américaine, foncièrement pragmatique, distingue deux étapes : l’analyse ("analysis")
des besoins puis la conception ("design") de la solution technique. Aux premiers temps de l'infor-
matique (19651975), ces deux étapes étaient, dans nos contrées, désignées sous les noms d'ana-
lyse fonctionnelle (= étude des fonctionnalités, c'est-à-dire de l'utilité, du système à mettre en
place) et analyse organique (= description des organes composant la solution).

Habituellement, une étude préalable part d’un diagnostic du système d'information existant,
qu'elle décrit plus ou moins exhaustivement, avec plus ou moins de détail. Elle justifie une nou-
velle solution, qu'elle recommande et à laquelle elle assigne des objectifs. L'étude préalable dit
le "pourquoi" ; elle motive la décision de mettre un projet en chantier.
L'analyse fonctionnelle détaille le "quoi" de la solution, pas encore le comment : « abstraction
précise du but de l'application et non de la façon dont elle sera bâtie ». Elle décrit complètement
le contenu sémantique et logique du nouveau système à mettre en place, sans prendre en consi-
dération les moyens à mettre en œuvre pour le faire fonctionner.
"Comment ?" L'étape de conception définit la réalisation de ce système sous la forme de cons-
tructions — programmes et procédures — utilisant au mieux les ressources techniques et orga-
nisationnelles : logiciels, équipements, personnel, locaux, horaires, etc.

De manière générale, le développement d'une application répond à quatre questions :

 20

Application = Quoi faire + Dans quel domaine + Comment + Avec quelles compétences

Ces questions correspondent à différents points de vue et concernent différents intervenants.

Elles peuvent être étudiées selon des techniques variées, mais doivent dans tous les cas être con-
sidérées pour développer une application :

Quoi faire ? La réponse est exprimée par l'utilisateur qui décrit ce qu'il attend du système, com-
ment il entend interagir avec lui et quels sont les différents intervenants. Il s'agit d'une description
fonctionnelle qui ne rentre pas dans les détails de la réalisation : le quoi faire est purement des-
criptif.
Dans quel domaine ? La réponse doit décrire le domaine (l'environnement) dans lequel l'appli-
cation va exister et préciser quels sont les éléments pertinents dans ce domaine pour l'application.
L'étude du domaine est le fruit d'une analyse, totalement déconnectée de toute considération de
réalisation. Le domaine est analysé par un analyste et doit pouvoir être compris par un utilisateur.
Comment ? Il faut le déterminer lors de la conception. Le comment est le fruit de l'expérience
et du savoir-faire du concepteur. La conception est l'art de rendre possible les désirs de l'utilisa-
teur — exprimés dans le quoi faire — en considérant le domaine de l'application et en tenant
compte des contraintes de réalisation.
Avec quelles compétences ? Il faut déterminer tout ce qui est nécessaire à la fabrication de l'ap-
plication. Ce point repose sur des compétences techniques pour le développement, sur des com-
pétences d'animation pour l'encadrement des équipes et sur des compétences d'organisation pour
assurer la logistique générale.

2.2. Niveaux de modélisation

Le texte reproduit ci-dessus souligne la multiplicité des points de vue développés lors de l'analyse
(au sens large) d'une application informatique.

Et, en effet, l'analyse d'un système d'information consiste pour l'essentiel à en établir différents
modèles, c'est-à-dire différentes représentations abstraites et réductrices, selon divers points de
vue qui se complètent progressivement.

Les modèles mathématiques mis au point par les astronomes leur permettent de prévoir des an-
nées à l'avance les phénomènes célestes tels que les éclipses ; leurs abstractions mathématiques
s'avèrent d'une efficacité infaillible. Pour établir leurs prévisions, plus aléatoires, les météoro-
logues se fondent sur des modèles probabilistes.
Nous l'avons déjà évoqué : dans les applications industrielles, l'ordinateur qui "pilote" un proces-
sus manipule en réalité un modèle mathématique de ce processus.
 21

Le système comptable d'une entreprise est un modèle de celle-ci, fortement réducteur puisqu'il
ramène tous les événements de la vie de cette entreprise à de pures quantifications monétaires ;
il est néanmoins très efficace pour la gestion et la conduite de l'entreprise.

Mais on ne recourt pas à des modèles que pour prévoir ou piloter, on en utilise aussi beaucoup
dans les démarches de création. C'est dans ce but que les informaticiens élaborent des modèles
avant de programmer.

Un modèle est une abstraction de quelque chose de réel qui permet de comprendre avant de cons-
truire. Parce qu'il ne tient pas compte des éléments qui ne sont pas essentiels, le modèle est plus
facile à manipuler que l'entité originale.

L'abstraction est une capacité fondamentalement humaine qui nous permet de gérer la com-
plexité. Depuis des milliers d'années, les ingénieurs, artistes et artisans construisent des modèles
pour tester leurs concepts avant de les exécuter. Le développement du matériel informatique et
du logiciel ne fait pas exception. Pour construire des systèmes complexes, le développeur doit
abstraire différentes vues du système, construire des modèles en utilisant une notation précise,
vérifier que les modèles satisfont aux spécifications du système, et progressivement ajouter des
détails pour transformer les modèles en une implémentation.
 22

2.3. Articulation de la démarche d’analyse

L'étude du texte ci-dessous montrera que les deux démarches, l'américaine et la française, ne sont
pas incompatibles mais permet d’enrichir la vision de l'analyste concepteur.

2.3.1. L'analyse
L'analyse [au sens américain] remonte de la conséquence vers le principe : elle essaie de com-
prendre, d'expliquer et de représenter la nature profonde du système qu'elle observe. L'analyse
ne se préoccupe pas de solutions mais de questions ; elle identifie le quoi faire et l'environnement
d'un système, sans décrire le comment, qui est le propre de la conception.

L'analyse commence par la détermination du quoi faire, c'est-à-dire des besoins de l'utilisateur.
Bien souvent, l'utilisateur n'est pas capable d'exprimer clairement ses attentes, de sorte que le
cahier des charges n'est qu'une représentation approximative de ses besoins réels. La présence
d'un imposant cahier des charges n'est pas toujours de bon augure. Trop souvent, les cahiers de
charges sont confus, contiennent des points contradictoires et ne reflètent pas les vrais besoins
des utilisateurs.

L'analyse se poursuit par la modélisation du domaine de l'application, c'est-à-dire par l'identifi-

cation des objets qui appartiennent fondamentalement à l'environnement de l'application, et par
la représentation des interactions entre ces objets.

L'assise sur les éléments du monde réel facilite le départ de la démarche car elle concentre la
pensée sur des éléments concrets. Elle doit impérativement être poursuivie par une démarche
d'abstraction qui vise à faire oublier les contingences du monde réel et à déterminer les concepts
fondateurs qui sont à leurs origines. Si la réflexion se focalise trop sur l'existant, les risques sont
grands de reproduire une solution au lieu d'identifier le problème posé.

L'analyse est l'antithèse de la conformité. L'analyse est souvent surprenante car elle demande de
changer de point de vue, d'oublier ce qui est connu, ce qui s'impose de prime abord, afin de
retrouver l'essentiel, la nature cachée des choses. Le propre de l'analyse est de trouver une des-
cription à laquelle personne n'avait jamais pensé jusqu'alors, mais qui une fois déterminée s'im-
pose au point d'être évidente.

La conséquence immédiate d'une analyse bien menée est toujours une grande économie dans la
réalisation qui s'ensuit.
Parallèlement à l'analyse de l'environnement, se déroule parfois une analyse de l'existant et des
contraintes de réalisation. L'objet de cette analyse est de comprendre parfaitement les caracté-
ristiques et les contraintes de l'environnement de réalisation afin de pouvoir prendre lors de la
conception des décisions motivées et réfléchies.
 23

2.3.2. La conception
Comme l'analyse et la conception, la conception et la réalisation se chevauchent en partie. Il est
rare de savoir comment tout faire pour cette raison, il faut essayer des techniques alternatives,
comparer les résultats puis choisir en faisant des compromis. La conception et la réalisation se
complètent. La conception a besoin d'expérimenter, la réalisation a besoin de principes directeurs.

Afin de maintenir le plus longtemps possible les bénéfices de l'abstraction, la conception est gé-
néralement subdivisée en deux étapes : une étape logique indépendante de l'environnement de
réalisation et une étape physique qui se préoccupe de l'ordonnancement des ressources et des
particularités des langages de programmation ou de l'environnement d'exécution.

La conception est souvent considérée, à tort, comme un simple enrichissement des résultats ob-
tenus durant l'analyse. Il s'agit là d'une vision fortement réductrice qui ignore tout simplement
que la conception est le temps de la mise en œuvre du savoir-faire. Ce savoir-faire peut être
interne au projet ou acquis à l'extérieur sous la forme d'outils, de composants réutilisables ou plus
largement de cadres de développement.

La conception débute par la détermination de l'architecture du logiciel, c'est-à-dire par l'élabora-

tion des structures statiques et dynamiques qui serviront de charpente pour l'ensemble du déve-
loppement. L'architecture définit la forme générale de l'application ; de sa qualité dépendent le
développement et l'évolution du logiciel. L'architecture est la conséquence de décisions straté-
giques arrêtées lors de la conception et de décisions tactiques prises en cours de réalisation.
Se donner une stratégie informatique, c'est considérer le logiciel comme un élément déterminant
du développement de l’entreprise ; c'est aussi chercher à s'assurer une avance technologique par
des choix d'architecture qui dépassent le cadre des besoins immédiats, liés à une application par-
ticulière.

Se donner une stratégie informatique, c'est par exemple choisir :

 L’internationalisation, autrement dit, concevoir le logiciel de telle manière que le

dialogue avec l'utilisateur puisse être mené dans toutes les langues ;
 La réutilisation qui n'est pas le fruit du hasard, mais le résultat d'une adhésion forte
de toute une organisation, depuis la définition de la ligne de produits jusqu'au dévelop-
pement de ces produits ;
 L’unicité de langage pour l'ensemble des développements ;
 L’indépendance par rapport aux dispositifs d'affichage, autrement dit, le décou-
plage entre l'information à afficher et la manière de l'afficher ;
 La portabilité des sources, voire des exécutables, qui réduit notablement les coûts
de développement et surtout de maintenance dans le cas d'un logiciel multi-cibles.
 24

3. LA PROCEDURE D’INFORMATISATION

Compte tenu du fait que l’informatisation ne s’improvise pas. Il y a nécessiteux de respecter les
étapes de la procédure d’informatisation en définissant les aspects ci-après :

Le schéma directeur : Définit globalement la politique d’organisation et d’automatisation du sys-

tème d’information. D’où, il est important de répertorier toutes les applications informatiques
existantes. Au besoin, insérer un nouveau projet s’il s’avère nécessaire. Pour faciliter le dévelop-
pement, le concepteur est appelé à découper le système d’information en sous-ensembles appe-
lées « domaines ».
Par exemple, à l’institut Supérieur de commerce de Kinshasa, on peut découper ce dernier en
plusieurs domaines, à savoir : académique, finances, administratifs, …

L’étude préalable : Après avoir découpé le système d’information en domaines, la présente

étape aboutit à la présentation générale du futur système de gestion en indiquant les principales
motivations par rapport au système en vigueur, le coût, les avantages et les moyens matériels à
mettre en œuvre.

Pour ce faire, trois phrases sont à parcourir :

 Une phase de recueil dont le but est l’analyse de l’existant ;

 Une phase de conception qui a pour objectif de modéliser le système futur sur base
des critiques formulées sur le système actuel ;
 Une phase d’appréciation dont le rôle est d’apprécier : les couts et les délais des
solutions définis ainsi que d’organiser la mise en œuvre de la réalisation.

L’étude détaillée consiste à élaborer un cahier de charges dans lequel le concepteur met toutes
les spécifications techniques liées à la réalisation de projet en tenant compte des besoins des
utilisateurs.

La réalisation consiste à mettre à la disposition des utilisateurs des programmes fonctionnant sur
un jeu d’essai approuvés par ces derniers.

Au-delàs de ces quatre fonctions qui déterminent le cycle de vie de développement d’une appli-
cation, nous pouvons ajouter :

La mise en œuvre qui consiste à transférer la responsabilité du produit fini à l’utilisateur. Pour
cela, l’équipe de réalisation procède par la formation des utilisateurs pour qu’ils fassent du pro-
duit livrée un bon usage. Ce n’est qu’après une période bien déterminée que le produit peut être
remis définitivement.
 25

La maintenance a pour rôle de suivre l’évolution de l’application dans le temps et dans l’espace
en prenant en compte les besoins des utilisateurs et l’évolution technologique.
 26

CHAPITRE II : PRESENTATION DE LA METHODE MERISE

Etant une méthode de conception des systèmes complexes, il se propose tout à la fois
des outils de modélisation, des modes opératoires permettant de les mettre en œuvre,
et une démarche méthodologique.

2.1. Historique de la méthode Merise

Merise est un acronyme signifiant Méthode d’Etude et de Réalisation Informatique par

les sous-ensembles ou pour les systèmes d’Entreprises. Elle a comme objectif d’aider et
de guider les SII dans leurs phases d’analyses, de conception et de developpement de
l’applicatif.

Nous devons la création, l’étude et la mise en place de cette methode à une equipe de
chercheurs et d’ingénieurs (Jean-Louis le Moigne, Hubert Tardieu, Dominique Nancy,
Henry Heckenroth, Daniel Pasco, Bernard Espinasse) qui en poserent les bases dans le
milieu des années 1970.

Contrairement à la plupart de méthodes qui été définies par les sociétés qui en ont as-
suré la commercialisation. Merise a été conçue par un ensemble des sociétés des services
constitué du centre technique informatique (CTI) et du centre d’étude techniques de
l’équipement (CETE) sous la direction du ministère de l’industrie pour couvrir les besoins
tant des administrations que des entreprises.
Le ministère de l’industrie vit en cette méthode un excellent moyen pour standardiser et
rationaliser les rapports existants les administrations et leurs sous- traitants. Le challenge
était de pouvoir proposer des outils ou des méthodologies permettants aux donneurs
d’ordres et au devéloppeurs de se comprendre et ainsi de mieux apprehender chacun
de leur coté, avec leur propre culture professionnelle, l’ensemble du sytème d’informa-
tion.

La méthode Merise présente comme avantage indéniable de permettre une définition

claire et précise de l’ensemble du système d’information et d’en définir correctement le
périmètre.

2.2. Signification de MERISE

Cet acronyme peut signifier :

MEthode pour Rassembler les Idées Sans Effort (Hubert Tardieu).

Méthode Eprouvée pour Retarder Indéfiniment le Sortie des Etudes.
Méthode d’Etude et de Réalisation Informatique pour les Système d’Entreprise.

:
 27

2.3. Présentation générale

La Méthode Merise se caractérise par :

- Une approche systémique en ayant une vue de l’entreprise en termes de sy-

tèmes ;
- Une séparation des données (le côté statique) et des traitements (le c ; ôté dyna-
mique) ;
- Une approche par niveau.

Les principes fondamentaux de la méthode MERISE reposent sur :

Apport de la systémique (organisation en tant que système)

Découpage de l’organisation en domaine
Analyse indépendante donnée-traitement
Une démarche à trois dimensions :

 La démarche : cycle de vie

 Le raisonnement : niveaux d’abstraction

 La maîtrise : niveau de décision.

2.4. Les trois composantes de la méthode MERISE

2.4.1. La démarche ou cycle de vie

 Etude préalable où l’on défini les propositions et l’évaluation des solutions
d’organisation et technique pour le système d’information d’un domaine.

 Etude détaillée pour la spécification complète du futur (SIO) en tenant

compte des points de vue de l’utilisateur.

 Etude technique pour la spécification complète du futur (SII) du point de

vue réalisateur.

 Production logiciel où l’on doit écrire le programme, la génération des fi-

chiers de la base de données et les tests.

 Mise en service (en œuvre) qui correspond à l’installation de l’application

informatique produite et la mise en place de la nouvelle organisation du tra-
vail.

 Maintenance pour rectifier les éventuelles anomalies, améliorer le système

mise en place, participer à son évolution.
 28

Définition des orientios Générales du

Schéma directeur ations à moyen terme des
Développement
Systèmes d’information.

PROJET
Proposition et évaluation de solutions
Etude préalable d’organisation et de solution techniques Conception
pour le système d’information d’un
Stop domaine d’activité.
Spécifications complètes du futur système
Etude détaillée d’information organisationnel du point de
vue des utilisateurs (e
xterne).
Spécifications complètes du futur système
Etude technique d’information organisationnel du point de
vue du réalisateur (interne).

Ecriture des programmes, génération des

Production logiciel fichiers ou des bases de données, tests. Réalisation

Installation de l’application informatique,

Mise en service mise en place de la nouvelle organisation.

Maintenance Rectification des anomalies, amélioration,

Maintenance
évolutions.

Le schéma directeur

Première étape de la conception, le schéma directeur défini le cadre général du déve-

loppement des systèmes d’information principalement en termes d’objectifs et de con-
traintes. Il détermine, pour les systèmes d’information :

 Le découpage en domaine ;

 Les orientations de l’informatisation ;

 Les axes organisationnels ;

 Les options socio-professionnelles ;

 La planification globale du développement ;

 Les cadres budgétaires.

L’étude préalable

Dans la ligne du schéma directeur, l’étude préalable constitue une étape fondamentale
de MERISE. Elle permet, avant de se lancer à fond dans un projet, d’élaborer globalement
 29

différentes solutions et d’en évaluer les diverses conséquences. Cette étape est confron-
tée à deux exigences contradictoires :

 Une durée relativement courte (quelques mois au plus) ;

 Une analyse suffisamment complète pour permettre une évaluation rai-

sonnable.

Elle portera en conséquence sur un sous-ensemble représentatif du domaine étudié.

L’étude préalable permet de proposer des solutions en précisant pour chacune :

 Le processus de fonctionnement du domaine ;

 Le degré et le type d’automatisation ;

 La perception des informations ;

 Le coût des moyens à mettre en œuvre (informatique en particulier) ;

 Les délais et étapes transitoires ;


schéma directeur.

L’étude détaillée

Cette étude permet, à partir des choix issus de l’étude préalable, de spécifier complète-
ment le futur système d’information. Cette conception comporte deux phases :

 La conception générale, dont l’objet est d’étendre à l’ensemble du domaine les prin-
cipes de fonctionnement retenus pour le sous-ensemble représentatif. Les diffé-
rentes spécifications sont complétées et validées ;

 La conception détaillée, qui produit, au niveau de chacune des tâches à automatiser,

une description complète en termes de support (dessin écran, imprimé), d’algo-
rithme (règles de calcul, de contrôle, etc.), d’action sur les données (mise à jour, con-
sultation).

L’étude détaillée permet d’obtenir, pour l’utilisateur, une description complète et con-
tractuelle du futur système d’information organisationnel. Elle permet également de ré-
ajuster les évaluations de moyens, coûts et délais estimés lors de l’étude préalable.

L’étude technique

L’étude technique est la traduction informatique de spécifications issues de l’étude dé-

taillée. Elle permet de déterminer :


grammes (transactionnels et batch) ;
 30

 La structure de chaque programme et des accès aux données.

La position de cette étape est souvent ambiguë. Demeurant étape d’étude, elle peut être
considérée comme la partie informatique de l’étude détaillée. Toutefois, son aspect for-
tement technique la rend très proche de la réalisation et l’assimile à la spécification de
celle-ci.

La production de logiciel

Elle consiste à traduire, dans des langages appropriés, les spécifications exprimées dans
les étapes précédentes. Cette production comprendra, entre autres :

 L’écriture des programmes dans un langage de programmation ;

 La génération des fichiers ou des bases de données ;
 Les tests de mise au point.

A l’issue de cette étape, une recette du logiciel est effectuée, prononçant la conformité
aux spécifications.

La mise en service

Elle consiste à installer les logiciels réalisés et à mettre progressivement l’ensemble du

système d’information au service des utilisateurs. Au cours de cette étape, on procède à
:

 La mise au point d’un planning d’installation tenant compte des phases tran-
sitoires ;

 La création et le chargement des informations de base ;

 La formation des utilisateurs ; la vérification du bon fonctionnement du logi-

ciel ;

 La mise en place progressive de la nouvelle organisation.

A l’issue de cette période de lancement, on pourra procéder, en fonction des événe-

ments, à ola recette provisoire puis définitive du système d’information.

La maintenance

Elle consiste à prendre en compte les évolutions apparaissant après le lancement opéra-
tionnel. Il faut, en fait, distinguer une étape supplémentaire, antérieure à la maintenance
le fonctionnement opérationnel.

La maintenance, qui demeure la plus importante de la vie d’un projet, ne devrait pas se
manifester autrement que par des tâches d’exploitation. Les évolutions conduisant à une
modification de l’application initiale proviennent des progrès technologiques, de la mo-
dification de l’environnement et des utilisateurs.
 31

Cette maintenance se traduit par un « rebouclage » du cycle de vie :

 L’étude de l’impact de la modification ;

 La spécification des modifications à effectuer ;

La remise en cause

Cette étape constate essentiellement qu’il existe des évolutions trop importantes pour
relever d’une simple maintenance. Ces évolutions peuvent trouver leur origine dans l’an-
cienneté de l’application, l’obsolescence technologique - prétexte à une révision totale
de la conception du système d’information - ou un changement important dans l’activité
ou dans les principes d’organisation.

Si le constat conclut à une remise en cause nécessaire du système d’information, le cycle

de vie reprend soit à une nouvelle étude préalable, soit plus radicalement à partir d’un
nouveau schéma directeur.

.2.4.2. Les raisonnements ou cycle d’abstraction

Il existe quatre niveaux d’abstraction en MERISE deuxième génération. Le décou-
page en niveaux a été confirmé par la communauté internationale [ANSI-X3-SPARC
75] :

 Le système d’information organisationnel (SIO) renferme les deux premiers niveaux

:
 Niveau conceptuel (exprimant les choix fondamentaux de gestion) : on doit
rechercher des éléments stables indépendamment des moyens à mettre en
œuvre, de leurs contraintes et de leur organisation.
 Niveau organisationnel exprimant les choix d’organisation des ressources hu-
maine et matérielles au travers de la définition des sites, des postes de travail,
 Le système d’information informatisé (SII) renferme quant à lui les deux derniers ni-
veaux :
 Niveau logique exprimant le choix des moyens et des ressources informa-
tiques en faisant abstraction de leurs caractéristiques techniques précises.
Exemple :
 Niveau physique traduisant les choix techniques et la prise en compte de leurs
spécificités. Exemple :
 32

Système d’information
natu-
rel

Définition des informations et des

Niveau concep- activité
s.
tuel
SI Type de ressource et affectation (choix
Niveau organisation-
O nel
d’organisation).

Moyen et ressources informatiques

Niveau lo- (choix logiciel
)
gique
SII
Niveau phy- Ressources effectives (choix technique).

sique

Application informatique, sup-

du système d’informa-
port
tion
Ce cycle d’abstraction avec quatre niveaux conduit à l’obtention de huit modèles
dont quatre concernent les données et les quatre autres les traitements :
 33

DONNEES TRAITEMENTS
MCD MCT
Signification desinformations sans contraintes Activité des domaines sans préciser les ressources
techniques, organisationnelles ou économiques. et leurs organisations
. Conceptuel

SIO
MOD MOT
Signification des informations avec contraintes Fonctionnement des domaines avec les Niveau
organisationnelles ou économiques. ressources utilisées et leurs organisations. Organisationnel

MLD MLT
Description des données en tenant compte de Fonctionnement des domaines avec les Niveau
leurs conditions d’utilisation par les traitements ressources et leurs organisations informatiques. Logique

SII
MPD MPT
Description de la ou des bases de données dans la Architecture technique des programmes. Niveau
syntaxedu SGF ou SGBD choisi. Physique

NB : Le SIO prend en compte la préoccupation des gestionnaires et des utilisateurs tandis

que le SII celles des informaticiens.

2.4.3. La maîtrise du projet ou cycle de décision

Le déroulement simultané de la démarche et des raisonnements doit être maitrisé. Dans
chaque modèle, à chaque étape, des choix doivent être effectués. Vers quel projet veut-
on aller ? Quels moyens veut-on lui affecter ?

La mise en œuvre de la méthode Merise se traduit en outre, par une succession de choix
permettant, d’une part, de contrôler la durée globale de la conception/réalisation du
projet, d’autre part, de définir un système en harmonie avec les objectifs généraux de
l’entreprise.

Ce cycle concerne donc les différents choix qui sont effectués tout au long du cycle de
vie de la méthode. La plupart de ces décisions marquent la fin d’une étape et le début
d’une autre. Pour chaque étape, MERISE prévoit une action :

 Préparer
 Exécuter
 Contrôler

Dans la pratique, le cycle de décision est intégré dans le cycle de vie. Cela se traduit
par des résultats types à l’issue de chaque étape et par des décisions attendues,
comme le montre la figure suivante :
 34

NB : Dans la pratique, ce sont les étapes de conception d’un projet (de l’étude préalable à
l’étude technique) qui sont les plus connues et utilisées, essentiellement à cause de l’efficacité
des modélisations mise en œuvre.

2.5. Etudes préalables et analyse de l’existant

Elle est une étape organisationnelle nécessaire losrque les processus de l’entreprise sont
très éloignés des outils modernes de gestion. Ce sont des entreprises qui ont une gestion
 35

trop ancienne et manuelle ou celles qui voudront changer de processus parce que tota-
lement développement spécifique en interne.

2.5.1. Etudes préalables

Les études préalables ont pour objectif de donner au maître d’ouvrage un maximum
d’informations objectives sur l’opportunité et la faisabilité générale de l’opération, avant
la prise de décision de lancer (ou de ne pas lancer) l’opération. Elles consistent à définir
d’une façon meilleure le problème à résoudre, et fournit les éléments nécessaires pour
répondre à la question oui ou non faut-il informatiser ?
A ce stade, il s‘agit de recenser et de comparer les différentes options possibles, pour
examiner les contraintes inacceptables qui rendraient impossibles la réalisation du projet
qu’elles soient techniques, opérationnelles ou financières.
Avant de se lancer dans l’exécution d’un projet, il est nécessaire de voir le problème de
la praticabilité (utilisation de l’ordinateur) et le problème de l’opportunité (aspect écono-
mique pour l’entreprise) ou l’organisation (aspect de la rentabilité).
Pour répondre à ces deux préoccupations, il est nécessaire d’effectuer l’analyse ou
l’étude préalable ainsi l’analyse du système existant (système actuel) a pour but de four-
nir un diagnostic de la situation actuelle (diagnostic fournit selon le besoin de l’entreprise
ou de l’organisation) à travers les utilisateurs.
La décision de réaliser une étude d’informatisation doit être soigneusement préparée.
L’étude préalable joue le même rôle que le schéma directeur, mais se limite à un do-
maine précis dans l’organisation.
Les objectifs de l’étude préalable sont :
 Poser correctement le problème à résoudre ;
 Rechercher une orientation de la solution par la définition de l’avant-projet.
Ainsi l’étude préalable permet de définir l’opportunité et la praticabilité d’infor-
matisation en posant d’une façon claire le problème à informatiser et les objec-
tifs à atteindre.
L’analyse préalable s’impose dans les situations telles que :
 Informatisation des applications ou nouvelles applications dans les cas des en-
treprises où il existe déjà le service informatique ;
 Introduction d’un système informatique ;
 Acquisition de nouveaux ordinateurs ; et
 36

 Changement des ordinateurs.

2.5.1.1. Formation de groupe d’étude

Le travail en informatique, notamment au niveau d’informatisation du système d’infor-

mation est toujours mené en équipe. Ainsi l’analyste doit après avoir défini les objectifs,
constituer le groupe d’étude chargé de conduire l’application.
Le groupe d’étude est constitué comme suit :
 L’informaticien (responsable du projet) ;
 Différents membres des services ou des départements concernés par le pro-
blème ;
 Un consultant extérieur ;
 Quelques utilisateurs ;
 Un ingénieur en organisation ;
 Un membre de comité de gestion/direction.
L’informaticien responsable du projet et les différents membres de service plus un
membre du comité de gestion ou de direction vont constituer le comité informatique.
Ce comité constitue le trait d’union entre la direction générale et les utilisateurs, notam-
ment pour le suivi de conduite et de la réalisation du projet ou application.
Après avoir formé le groupe d’étude, le responsable de projet doit organiser les séances
d’information.
Les séances de formation sont destinées aux membres du groupe pour leur expliquer le
bien-fondé de l’automatisation. Les séances d’information sont destinées au personnel
de service ou département concerné par l’informatisation pour leur informé de l’évolu-
tion de projet d’informatisation et éventuellement leur demandé quelques éclaircisse-
ments sur certaines fonctionnalités.

2.5.1.2. Planification des activités d’un projet

L’élaboration d’un projet est souvent une tache fastidieuse et un casse-tête autant pour
les chefs de projet que pour des particuliers. De l’idée à la réalisation en passant par les
phases de l’élaboration d’un projet, exige une certaine démarche et une organisation
pour atteindre avec efficience les objectifs fixés.

Nous pouvons donc définir la planification de projet comme une activité qui consiste à
organiser des taches à réaliser sur une période donnée. L’objectif de la planification est
 37

de déterminer le cout, les ressources mobilisées et la meilleure manière d’ordonnancer

toutes les tâches à effectuer, d’avoir une vision claire du projet et de le réaliser dans un
minimum de temps.

Ainsi, plusieurs méthodes ont vu le jour pour faciliter la gestion et la réalisation d’un
projet. Ces méthodes sont utilisées aussi bien en gestion qu’en informatique. Nous pou-
vons citer le plus utilisé d’entre elles :

- La méthode PERT (Program Evaluation Review Technic)

- La méthode de potentiel métra (MPM)

2.5.1.3. Techniques de recolte de donnes

Les techniques utilisées lors de l’analyse de l’existant pour recueillir les données sont
multiples, cependant en informatique les techniques comme :
 L’interview ;
 L’observation ;
 Documentaire ;
 Questionnaires (Enquête) sont les plus utilisées.

2.5.2. Analyse de l’existant

L’analyse de l’existant a pour but de recueillir les données qui vont servir pour élaborer
le diagnostic en vue de la recherche et de choix des solutions ou de la solution future
permettant l’amélioration du système actuel.
Ainsi l’analyse de l’existant est nécessaire car elle permet de répondre à la question oui
ou non faut-il informatiser. Tout problème n’est pas toujours informatisable. L’analyse de
l’existant comporte les étapes suivantes :
Analyse de la structure ;
Analyse des postes de travail ;
Analyse de documents ;
Analyse de moyens de traitement ;
Analyse de flux d’information ;
Diagnostic de l’existant.
 38

1) Analyse de la structure

Il y a lieu de faire une nette distinction entre l’analyse de la structure et l’organigramme

général de l’organisation. Dans la partie analyse ou l’étude de la structure, la préoccu-
pation majeure est d’étudier en profondeur la structure de département ou service con-
cerné directement par l’informatisation afin de déceler certains disfonctionnements.
L’analyse de la structure est réalisée à partir de l’organigramme de département ou ser-
vice concerné.
Dans le cas où il n’existe aucune structure, l’analyste (informaticien) doit lui-même re-
constitué l’organigramme en question en utilisant la technique d’interview ou de ques-
tionnaire.
Par exemple :
 De qui tu reçois les ordres ? Je reçois les ordres de…
 Qui est ton chef hiérarchique ? Mon chef est...
 Qui dépendent de toi ? Mes subalternes sont….
Au cours de l’analyse de la structure, l’analyste s’efforce de déceler les liens qui existant
entre les différents acteurs affectes dans le service (liens formels et informels) et l’organi-
sation mise en place.
Dans la pratique, l’analyse de la structure permet de déceler les anomalies existantes au
niveau de l’organisation de service concerné par l’informatisation. Et cette analyse se fait
en scrutant l’organigramme de service concerné.

MANAGER STOCK

CAISSIER

VENDEUR1 VENDEUR2 VENDEUR3

 39

2) Analyse de poste de travail

Après avoir analysé la structure de l’entreprise, on peut alors procéder à l’étude de poste
de travail.
L’analyse de poste permet de répertorier de manière impersonnelle tous les critères exi-
gibles pour accéder aux différents postes faisant partie de service à informatiser. Elle per-
met aussi de décrire les attributions de chaque poste.
Un poste de travail est défini comme une entité qui exerce une activité au sein d’un
service ou d’un département.
Le poste de travail, concerne chaque service et chaque département, ainsi l’analyste
pour réaliser ce travail aura comme point de référence, la structure de l’entreprise.
La fiche descriptive de poste : a pour rôle de récapituler les activités des intervenants
(Description des activités). Lors de l’étude de poste une fiche de descriptive de poste est
remplie pour chaque poste avec les informations que :
Le domaine de projet ;
Le nom de l’application ;
Le nom de développeur ;
La désignation de poste ;
Les critères pour accéder à ce poste ;
Les attributions de ce poste.

FICHE DESCRIPTIVE DES POSTES

Domaine de Projet :
Nom de l’application :
Nom de développeur :
Désignation de poste :
Criteres pour accéder à ce poste :
Les attributions de ce poste :

Exercice :
Les critères et les attributions ci-après ont été fixes pour le poste de manager de stock
dans le service commercial d’une entreprise de la place.
 40

PROFIL RECHERCHE
Pour travailler comme manager de stock, il faut être licencié en Science Commerciale,
âgé d’au +/- 28 ans, avoir travaillé dans le domaine des ventes, avoir au moins 5 années
d’expériences et détenir une excellente capacité managériale.

RESPONSABILITES
Sous la supervision de Directeur Commercial, le Manager de stock aura pour responsa-
bilités de faire les démarcher des clients dans son secteur ; être responsable de la réali-
sation des objectifs quantitatifs et qualitatifs pour les différentes unités ; Animer, organi-
ser, coordonner, gérer et contrôler l’activité et le suivi de la force de vente afin d’optimi-
ser les résultats ; mettre en œuvre et réaliser dans son secteur géographique la politique
commerciale définie par ou avec la direction et Analyse des résultats et prendre les me-
sures correctives nécessaires.
Travail à faire : Présenter la fiche descriptive pour ce poste.
FICHE DESCRIPTIVE DES POSTES
Domaine de Projet : gestion commerciale
Nom de l’application : gestion de stock et vente
Nom de développeur : Prof MUSANGU Marcel
Désignation de poste : Manager de stock
Criteres pour accéder à ce poste :
- Etre liciencié en science commerciale ;
- Etre âgé d’au moins 28 ans ;
- Avoir travaillé dans le domaine des ventes ;
- Avoir au moins 5 années d’expérience ;
- Avoir une excellence capacité managériale.
Les attributions de ce poste :
Rattaché au Directeur commercial, les taches de manager de stock seront les sui-
vantes :
- Démarrer des clients dans son secteur ;
- Etre responsable de la réalisation des objectifs quantitatifs et qualitatifs pour les
différentes unités.
 41

- Animer, organiser, coordonner, gérer et contrôler l’activité et le suivi de la force

de vente afin d’optimiser les résultats.
- Mettre en œuvre et réaliser dans son secteur géographique, la politique com-
merciale définie par ou avec la direction.

3) Analyse de documents utilisés

Cette étape consiste à analyser et décrire tous les documents entrant, restant et sortant
du service ou département à informatiser. L’analyse de documents utilisés commence
par l’énumération de documents suivants :
 Documents reçus par le service en provenance d’autres services internes ou externes de
l’entreprise ;
 Documents établis et conserves par le service ; et
 Documents diffuses par le service.

Pour chacun de ces catégories de documents, on cherche à connaitre leur code, leur
nature, leur fréquence et leur volume. Dans le souci de faciliter la présentation, nous
proposons l’utilisation de tableau ci-après :

LISTE DE DOCUMENTS UTILISES PAR LE SERVICE

 42

Le dictionnaire des données

Le dictionnaire des données est un document qui permet de recenser, de classer et de

trier toutes les informations (les données) collectées lors des entretiens ou de l'étude des
documents. Le dictionnaire peut être plus ou moins élaboré selon le niveau de granula-
rité souhaité. En voici un exemple :

Figure 4.1 Dictionnaire de données

Nom de la donnée
Cette cellule recevra une donnée, par exemple : Nom client.
Format
Ici sera indiqué le format de la donnée, par exemple : alphabétique.
Longueur
La longueur approximative ou exacte de la donnée sera indiquée, par exemple : 3
Type
Une croix sera inscrite dans la colonne pour indiquer si la donnée est élémentaire ou
calculée.
Règle de calcul
Ici sera indiquée de manière claire la formule ou le calcul nécessaire à appliquer pour
obtenir la donnée.
Règle de gestion
Dans cette zone sera indiquée, si nécessaire, la règle de gestion inhérente à la donnée.
Document
La rubrique document permet de saisir le document dans lequel a été trouvée la donnée.
Voici ce que pourrait être le dictionnaire :
Type

Nom de la Règle de cal- Règle de

Format Longueur Document
donnée E C cul gestion
 43

Alphabé-
Nom client 30 X Facture
tique

Tableau 4.2 Dictionnaire de données avec rubrique documents

Le nom est au format alphabétique, d'une longueur de 30 caractères, de type élémen-
taire, il n'y a aucune règle de gestion et le document dans lequel l'information a été
trouvée est la facture.
Remarque
La longueur du champ nom a été définie aléatoirement à 30 caractères. Il faut toujours
avoir à l'esprit que dans le doute il vaut mieux sur dimensionner les tailles. Le proverbe
qui s'adapte à la situation est « Qui peut le plus peut le moins ».
Exemple :
À la suite d’une demande de président d'une association, nous devons établir le diction-
naire des données de la gestion des adhérents.
Voici une représentation d'une fiche d'adhérent :

Figure II.1 Fiche Adhérent

À la lecture de la fiche, nous pouvons déterminer la présence de neuf informations diffé-
rentes :
 44

- Le numéro de l'adhérent ; Le nom ; Le prénom ; L'adresse ; Le code postal ; La ville ;

Le téléphone ; Le mail ; La date d'adhésion.
Voici le dictionnaire des données :
Tableau II.3 Dictionnaire de données
Règle de Règle de Docu-
Lon- Type
Nom Format calcul gestion ment
gueur
E C Fiche
Numéro N X //

Nom A 30 X //
Prénom A 30 X //
Adresse AN 50 X //
Code postal AN 10 X //
Ville A 50 X //
Téléphone AN 15 X //
Mail AN 50 X //
Date
Date X //
d’adhésion

Remarque
Le code postal est alphanumérique et de taille 10. Certaines personnes peuvent consi-
dérer qu'il serait plus judicieux de placer le format en numérique. Or qu'est- ce qui
prouve que dans certains pays la règle d'écriture des codes postaux est identique à la
règle congolaise des 5 chiffres ? En effet, certains pays mélangent des chiffres et des
lettres. Le format alphanumérique est le plus approprié dans ce cas-là. De manière gé-
nérale, il est souhaitable de ne formater en numérique que les champs sur lesquels il va
y avoir des calculs. Le raisonnement appliqué est le même pour le champ téléphone.

4) Analyse des moyens de traitement

Les moyens de traitement de l’information se subdivisent en 2 grandes catégories :

 Moyens matériels
 Moyens humains

A. Les moyens matériels

Cette analyse consiste à recenser les différents matériels utilisés dans le service ou dépar-
tement à informatiser pour traiter les informations.
 45

Dans la pratique pour faciliter l’analyse des moyens matériels, on établit des fiches appe-
lées « Fiche d’analyse des moyens de traitement » Dont voici le modèle :

A partir des informations des moyens de traitement, l’analyste peut lors de la recherche
de solution proposée le type des solutions appropriées pour les matériels futurs à utiliser
pour traiter les informations.
Ainsi, par exemple l’ordinateur qui a été acheté le 11/11/2003 a déjà vieilli.
D’où la nécessité d’acquérir d’autre ordinateurs beaucoup plus performants. Il se peut
aussi que la capacité normale de l’ordinateur au niveau de RAM soi insuffisante. Etc.
Avant de proposer le matériel, il faut d’abord analyser les moyens matériels existants. En
dehors de ces informations, il est aussi nécessaire dans le cas où l’entreprise est déjà
automatisée de recueillir les informations ci-après.
Les informations telles que :
 Le système d’exploitation utilisé ;
 Le type de réseau (ex. LAN, MAN, WAN)
 Moyen de communication doivent être recensé en vue de la proposition d’une meilleure
solution.

B. Les moyens humains

L’analyse des moyens humains est nécessaire pour mieux comprendre les qualifications
du personnel travaillant au sein du service concerné par l’application.
Au niveau de l’analyse de l’existant les informations telles que :
 Poste de travail ; Nom ; Niveau d’études ; Ancienneté ; Salaire net à payer ;Etc.
Doivent être recensés pour faciliter la présentation des données, on recommande l’éta-
blissement d’une fiche appelée « Fiche d’analyse des moyens humains ».
 46

Les informations recueillies lors de l’analyse des moyens humains permettront d’identi-
fier les problèmes et de proposer les meilleures solutions futures.
Ainsi par exemple si les travaux à réaliser sont trop complexe au niveau de la gestion de
stock, l’expert ayant une qualification L2 Théologie ne convient pas à ce poste malgré
son ancienneté. Une personne avec une qualification en gestion sera plus efficace. En
dehors de la qualification, d’autres facteurs aussi peuvent susciter le dysfonctionnement
tels que : la subjectivité dans la répartition de salaire, l’injustice sociale… peuvent contri-
buer à la baisse de la productivité.

5) Analyse de flux d’informations

L’analyse de schéma de circulation des informations (circuit) est l’une des méthodes uti-
lisées pour représenter ou analyser les flux d’information entre services. C’est la partie la
plus essentielle au niveau de l’analyse de l’existant. Cette analyse se réalise dans le cas
ci-après :
A. L’Entreprise n’est pas encore informatisée (service non informatisée)
Dans ce cas, l’analyste à l’aide de la technique d’interview reconstitue le circuit de circu-
lation des informations.
Les questions telles que :
 Mon chef est …
 Je reçois les ordres de …
 Je transmets les rapports à …
Peuvent aider quelques fois l’analyste à mieux reconstituer le circuit de circulation des
informations.
 47

B. L’entreprise est informatisée

Dans ce cas, pour reconstituer le schéma de circuit des informations. L’analyste peut se
référer au centre de traitement informatique (CTI).
C. Cas de réorganisation de l’entreprise
Dans ce cas, l’analyste doit réorganiser, c'est-à-dire proposer un nouveau schéma de cir-
culation des informations.
Les informations circulent dans les entreprises souvent sous forme de documents, dia-
gramme de circulation des informations.
Dans la pratique, il existe différents diagrammes pour présenter la circulation des infor-
mations ou la présentation du circuit des informations.
Dans ce cas, on présente les différentes opérations ainsi que les services concernés par
les opérations. Tout en tenant compte de poste de travail lors de la description de flux
d’information, on utilise les symboles informatiques appropriés.
Exemple : Modèle opération service.

5.1 Application de schéma de circulation des informations

Soit la narration d’une application de gestion des approvisionnements de produits phar-

maceutique.

La gestion des approvisionnements au sein du dépôt pharmaceutique Pharmex se dé-

roule de la manière suivante :
Chaque matin, le gérant vérifie le stock restant de chaque produit par rapport à la vente
précédente et aux différentes dépenses afin de déterminer les besoins journaliers en
médicaments puis il établit les réquisitions en trois exemplaires : la première pour les
 48

produits importés qu’il commande par téléphone à l’Entrepôt, la deuxième pour les dé-
pôts pouvant se déplacer avec leurs bus (cette commande s’effectue aussi par télé-
phone), la troisième pour donner au chargé des achats afin de pouvoir contacter les
autres dépôts pharmaceutiques (sans bus), les moins offrants et d’acheter les produits
selon leur spécialité.
La commande étant parvenue à l’Entrepôt, celui-ci vient livrer les produits avec les bons
de livraison qu’il établit en deux exemplaires, le gérant vérifie la conformité des produits
livrés à ceux qui ont été commandés. S’ils sont conforment, le gérant accuse réception
sur un exemplaire du bon de livraison qu’il transmet ensuite à la caisse pour paiement.
Celle-ci renvoie le bon de livraison réceptionné et l’argent au gérant ; celui-ci les remet à
l’entrepôt puis il transmet l’autre exemplaire du bon de livraison au Pharmacien qui le
reçoit, vérifie les différents produits livrés qu’il va ensuite consigner et enregistrer dans
le cahier d’entrée, classe ce bon de livraison et remet les produits au gérant pour leur
classement dans les rayons.
Pour la commande envoyée aux dépôts ayant des bus : les produits arrivent au dépôt
accompagné des factures. Le gérant les réceptionne, vérifient et émet le bon de dépense
qu’il transmet à la caisse pour paiement de ces factures ; la caisse débourse l’argent et
remet au gérant ; celui-ci émet le bon de commande qu’il transmet ensuite au dépôt
accompagné de leur argent, puis transmet les factures au Pharmacien ; celui-ci vérifie les
produits, les enregistrent dans le cahier d’entrée, classe ces factures, puis renvoie les pro-
duits au gérant pour leurs classements dans les rayons.
Enfin, la troisième réquisition remis au chargé des achats s’accompagne du bon de com-
mande émis par le gérant et de l’argent. Le chargé des achats transporte les produits
achetés au dépôt accompagnée de la réquisition et du bon de commande émis par le
gérant et des factures provenant de ces dépôts ; le gérant vérifie la conformité de la
commande à celle de la livraison puis transmet les factures et les produits au pharmacien
pour vérification et enregistrement dans le cahier d’entrée ; puis celui-ci renvoi les pro-
duits au gérant pour leurs classements dans les rayons.
49
 50

Légendes :

Abréviations
Rq : Réquisition
Fac : Facture
Ag: Argent
Prod : produits ou médicaments
BL : Bon de livraison
BLAR : Bon de livraison accusé réception
BC : Bon de commande
BD : Bon de dépense
CE : Cahier d’entrée
Explication du Schéma de circulation des informations
Code Nom Taches Description
poste poste
- Vérification des stocks restant
101 - Etablissement des Rq en trois exemplaires.
 51

- Envoie Rq à l’entrepôt, au dépôt bus et au

chargé des achats y compris l’Ag et Fac
102 - Réception Prod et BL
- Signature BL
- Accusé réception d’un de BL
- Envoie du bon de BLAR à l’entrepôt
- Envoie Prod et BL au pharmacien
103 - Réception Prod
- Classement Prod
104 - Réception Prod, Fact et vérification
100 Gérant Etablissement BD
- Envoie Fac et BD à la caisse
105 - Réception Fac et Ag provenant de la caisse
- Transmission BC et Ag au dépôt bus
- Envoie Prod et Fac au Pharmacien
106 - Réception Prod provenant du Pharmacien
- Classement Prod
107 - Réception Fac , Rq, Prod et Vérification.
- Envoie Prod et Fac au Pharmacien
108 - Réception Prod provenant du Pharmacien et
classement Prod
201 - Réception Rq
- Préparation des Prod
- Elaboration BL en deux exemplaires
200 Entre- - Envoie Prod et BL au gérant
pôt - Classement Rq
202 - Réception BLAR
- Archivage BLAR
- Réception Rq
301 - Préparation Prod
- Envoie Prod
300 - Classement Rq
 52

Dépôt 302 - Réception BC et Ag

bus - Classement BC
400 Chargé 401 - Réception Rq, BC et Ag
des - Transmission Prod, Rq et Fac au Gérant
achats

Soit la narration d’une application de gestion de passager dans une agence de voyage
(Cas de l’agence city train)

A son arrivée à l’agence, le client consulte le programme et les tarifs de voyage affichés
sur place. Il se présente au guichet où se tient la perceptrice de l’agence auprès de qui il
verse le montant prévus pour sa destination. Celle-ci enregistre son identité dans un do-
cument approprié (registre des passagers) et par la suite lui établir un ticket de voyage.
S’il possède des bagages apparemment importants, il se présente au près du bagagiste
pour le pesage afin de déterminer le poids, dont l’excédent au-delà de 20 Kg exempté,
sera mentionné par le bagagiste sur un jeton que l’intéressé ira présenter à la perceptrice
pour taxation.
À la vue de ce jeton, la perceptrice lui annonce le coût et perçoit par conséquent la
somme due, avant d’établir un ticket appelé titre de voyage qui sera remis à ce dernier.
Le client est invité désormais à prendre place dans la salle d’attente jusqu’à l’heure de
l’annonce des opérations d’embarquement.
A la clôture de toutes les opérations d’enregistrement de remise de ticket en faveur des
passagers ayant souscrit pour le voyage du jour, la perceptrice tient sa caisse en ordre
et transmet le registre des passagers et le sachet des tickets au chef d’agence ou à son
adjoint qui s’n saisi pour vérification et établissement de manifeste de voyage.
A quelques minutes de l’heure prévue de départ effectif, le chef d’agence ou son adjoint
invite le bagagiste et le manutentionnaire à procéder à l’embarquement des bagages et
frets sous son contrôle.
Il invite ensuite les passagers à se présenter selon l’ordre d’enregistrement au lieu d’em-
barquement dans le bus en présentant chacun son ticket de voyage dont la sache sera
empotée à chaque montée.
Le chef d’agence ou son adjoint remet au chauffeur ou à son commis de bord le docu-
ment de voyage à savoir :
 Le manifeste des passagers ;
 53

 Le bordereau d’expédition ;
 Le courrier ;
 Le fret de voyage avant d’ordonner le départ du bus.

A. Le schema de circulation des informations

B. Abréviation
TCV : Ticket de voyage
Pgm : Programme
TV : Tarif voyage
RP : Registre des passagers
 54

MV : Manifeste de voyage
MP : Manifeste de passager
BE : Bordereau d’expédition
FV : Fret de voyage

C. Explication du schema de circulation des informations

6) Diagnostic de l’existant

Le diagnostic de l’existant consiste à examiner les points forts et les points faibles de
système existant. Lors de diagnostic, on essaye de passer en revue toutes les étapes de
l’analyse de l’existant en commençant par l’analyse de la structure jusqu’à l’analyse de
flux de l’information. Compte tenu du fait que l’informatisation ne s’improvise pas, le
diagnostic de l’existant permet de détecter les points forts et les anomalies de système
actuel afin de se décider sur l’opportunité ou l’inopportunité de l’informatisation.
Le diagnostic de l’existant se termine par les deux sous sections ci-après :
Proposition des solutions ; et
Choix de la meilleure solution.
 55

Exemple de diagnostic de l’existant pour une application de gestion des impôts (IPR)

Le diagnostic de l’existant permet de prélever les points forts et les points faibles de sys-
tème sous analyse en vue de proposer des solutions pour l’amelioration de système.
1. POINTS FORTS
Le système existant a comme point forts ce qui suit :
 Volonté de servir le contribuable ;
 Bonne condition ergonomique des postes de travail ;
 Bonne présentation des documents ;
 Moyens matériels adéquates

2. POINT FAIBLES
Le système a comme point faible ce qui suit :
 Manque de sécuritées données ;
 Lenteur dans le traitement des données parce que le système est encore manuel
;
 Mauvaise conservation des documents ;
 Les matériels utilisés pour la gestion d’impôt professionnel sur les rémunérations
bien qu’adéquats ne répondant pas aux normes de la nouvelle technologie.

3. PROPOSITION DES SOLUTIONS

Pour la réorganisation du système existant nous recommandons à la
D.G.I/D.U.I.K/C.I.S/kimbanseke de mettre et de lutter en place des mécanismes permet-
tant de maximiser les recettes et de lutter contre la corruption.
En ce qui concerne notre étude, nous proposons deux solutions : solution manuelle et
solution informatique.

1.1. SOLUTION MANUELLE AMELIOREE

L’objectif de la solution manuelle améliorée est de réorganiser les procédures manuelles
en vue de remédier aux insuffisances constatées dans le système de gestion actuel.
a) Avantages
 56

La solution manuelle améliorée présente les avantages ci-après :

 Elle est moins coûteuse ;
 Elle est la plus réaliste car elle nécessite que de changement dans les méthodes
et procédures de travail.
b) Désavantages
 Lenteur d’exécution des tâches ;
 Risque de saturation devant un volume considérable d’information ;
 Perte des documents et de temps ;
 Probabilité d’erreurs de calcul élevée.
1.2. SOLUTION INFORMATIQUE
Elle consiste à automatiser cette tâche manuelle (gestion d’impôt professionnel sur les
rémunérations) en vue d’optimiser le fonctionnement du système.
a) Avantages
La solution informatique présente les avantages ci-après :
 Gain d’espace de stockage d’information ;
 Rapidité de traitement d’information ;
 Facilité de mise à jour des fichiers ;
 Meilleur suivi de l’information ;
 Fiabilité des résultats.
b) Désavantages
La solution informatique présente l’inconvénient d’être trop coûteuse pour les entre-
prises de par sa mise en œuvre et son maintien.

4. CHOIX DE LA SOLUTION OPTIMALE

En tenant compte par rapprochement des avantages et désavantages que représentent
chacune des solutions, nous optons pour la solution informatique pouvant permettre
une gestion saine et efficace pour la gestion d’impôt professionnel sur les rémunéra-
tions.
 57

CHAPITRE III : CONCEPTION DU SYSTEME D’INFORMATION OR-

GANISE (ETUDE DETAILLEE)
Dans cette section, nous allons nous occuper des aspects organisationnels de l’entreprise
sans se préoccuper des exigences techniques liées à l’informatisation. La description d’un
système d’information organisé se regroupe en deux ensembles. Tout d'abord le niveau
conceptuel et le niveau organisationnel. Merise propose pour ces deux niveaux des mo-
dèles de description de données et de traitements. Pour ce qui nous concerne dans le
cadre de ce livre, nous allons présenter le niveau conceptuel avec les quatres modèles ci-
après :
Le Modèle Conceptuel de Données (MCD) ; et
Le Modèle Conceptuel de Traitement (MCT)
Le Modèle Organisationnel de Données (MOD) ; et
Le Modèle Organisationnel de Traitement (MOT).

2.6. Le modèle conceptuel

Nous aborderons directement le modèle conceptuel des données et le modèle concep-

tuel des traitements.

2.6.1. Le modèle conceptuel des données (MCD)

Le but du MCD est de modéliser (formaliser) les données mémorisées du S.I. On ne

tient pas compte des aspects techniques, économiques, ni de problèmes de stockage
de l'information, ni des problèmes d'accès aux informations et ni des conditions d'utili-
sation. On a deux démarches pour explorer le S.I :
 La démarche déductive (ascendante). Cette démarche s'appuie sur une liste
d'informations.
 La démarche inductive (descendante). Elle met en évidence les entités de gestion
en les décrivant.
Le Modèle Conceptuel des Données introduit la notion d’entités, de relations et d e p
r o p r i é t é s. N o u s a l l o n s commencer p a r v o i r c e r t a i n s a s p e c t s « théoriques » avant
de plonger dans la pratique. Il décrit de façon formelle les données utilisées par le sys-
tème d'information. La représentation graphique, simple et accessible, permet à un
non-informaticien de participer à son élaboration. Les éléments de base constituant
un modèle conceptuel des données sont :
- Les propriétés
 58

- Les entités
- Les relations

a) Les propriétés
Les propriétés sont les informations de base du système d'information.
Un client possède un numéro de client, un nom, un prénom, habite à une adresse
précise, etc. Ces informations élémentaires essentielles sont des propriétés.
Les propriétés disposent d'un type. Elles peuvent être numériques, représenter une
date, leur longueur peut être aussi définie. Par exemple : le nom est une propriété de
type alphabétique et de longueur 50, c'est -à-dire que la valeur saisie ne comportera
aucun chiffre et ne dépassera pas cinquante caractères. Les types ne sont pas décrits
au niveau conceptuel, car ce niveau est trop proche de la définition du système phy-
sique. Nous y reviendrons plus tard.

b) Les entités ou objets

Une entité ou un objet en merise est un concept abstrait qui regroupe les propriétés.
Comme il est aisé de le constater, les clients sont définis par certaines propriétés (numéro,
nom, prénom...). Le fait de les regrouper amène naturellement à créer une entité
Clients. Le symbolisme retenu est le suivant :
CLIENTS
Entité Clients

Numéro
Nom
Prénom
Adresse Propriétés
Code_postal
Ville

Figure I.9. Représentation d’une entité

L’identifiant
Une de ces propriétés a un rôle bien précis, c'est l'identifiant nommé aussi la clé. L'iden-
tifiant permet de connaître de façon sûre et unique l'ensemble des propriétés qui
participent à l'entité. Par exemple, le fait de connaître la ville d'un client permet-il de
connaître son nom ? La réponse est non. La connaissance du nom du client permet-
 59

elle de connaître sa ville ? La réponse est toujours non, car en cas d'homonymie la
confusion entre un Nzuzi Losso et un Nzuzi Lossa peut être totale.
II faut donc trouver, ou inventer, une propriété qui lorsque sa valeur est connue
permet la connaissance de l'ensemble des valeurs qui s'y rattachent de façon formelle.
Ainsi, lorsque le numéro du client est connu, son nom, son prénom et toutes les va-
leurs des autres propriétés qui s'y rattachent sont connues de façon sûre et unique.
Au niveau du formalisme, cette propriété se souligne ou elle est précédée de signe dièse
#. Voici le schéma modifié de l'entité Clients.

CLIENTS

Entité Clients
#Numéro
Nom
Prénom
Adresse Propriétés
Code_postal
Ville
Identifiant

c) Les relations ou associations

Les relations ou les associations sont de liens permettant de mettre ensemble une ou
plusieurs entités. Nous avons vu que les entités regroupaient un ensemble d'informa-
tions élémentaires. Les entités sont souvent liées entre-elles.
Par exemple :
Un client peut commander des articles.
Si nous analysons cette phrase, on distingue deux entités (clients et articles) et un verbe
(commander) qui indique un lien entre clients et articles.
Formalisons cette phrase avec Merise.
 Relation
60
CLIENTS
#Nu-
méro_Client ARTICLES
Nom #Numéro_Ar-
Prénom Commander
ticles
Adresse Désignation
Code_Postal Prix_d’achat
Prix_de_vente
Ville

Voilà la première étape, première car la lecture du schéma doit être améliorée en in-
corporant une notion importante : les cardinalités.

Les cardinalités
Elles expriment le nombre de fois ou l'occurrence d'une entité participe aux occur-
rences de la relation.
Dans notre exemple on peut se poser les questions suivantes :
 Combien de fois au minimum un client peut-il commander un article ?
 Combien de fois au maximum un client peut-il commander un article ?

À la première question, nous pouvons répondre qu'un client, pour être client, doit com-
mander au moins un article.
À la deuxième question, nous pouvons répondre qu'un client peut commander plusieurs
articles.
Voici comment symboliser cet état :

Cardinalité minimale

CLIENTS
#Numéro_Client
Nom ARTICLES
Prénom #Numéro_Articles
Commander Désignation
Adresse
Code_Postal Prix_d’achat
(1, n) Prix_de_vente
Ville

Cardinalité maximale

Le n représente la notion de « plusieurs » ; ici nous avons représenté le fait qu'un

client peut commander un ou plusieurs articles.
II faut que nous nous posions les mêmes questions pour l'article :
- Combien de fois au minimum un article peut-i l être commandé par un client ?
 61

- Combien de fois au maximum un article peut-i l être commandé par un client ?

Pour le minimum, nous pouvons l'interpréter de la façon suivante :
- A-t-on des articles qui ne peuvent jamais être commandés ?
- Si nous répondons oui dans ce cas la cardinalité minimale est 0. Mais en réalité un
article doit toujours être commandé pour justifier de la pertinence de la relation.
Dans ce cas la cardinalité minimale est 1.
Pour le maximum :
- A-t-on des articles qui peuvent être commandés plusieurs fois ?
- Nous pouvons espérer que oui, dans ce cas la cardinalité maximale sera n.
Voici le schéma finalisé :
CLIENTS

#Numéro_Client ARTICLES
Nom (0, n)
Commander #Numéro_Articles
Prénom
Adresse Désignation
(1, n) Prix_d’achat
Code_Postal
Ville Prix_de_vente

Définitions
La cardinalité minimale (0 ou 1) exprime le nombre de fois minimum qu'une occur-
rence d'une entité participe aux occurrences d'une relation.
La cardinalité maximale (1 ou n) exprime le nombre de fois maximal qu'une occur-
rence d'une entité participe aux occurrences de la relation.

Remarque
SI le maximum est connu, il faut inscrire sa valeur. Par exemple, si dans les règles de ges-
tion le client n'a le droit de commander qu'un maximum de 3 articles en tout et pour
tout dans ce cas-là les cardinalités s'exprimeront de cette façon : (1,3).

Autre exemple :
Modélisons le fait qu'une mère élève des enfants. Nous avons deux entités, Mères et
Enfants :

MERES ENFANTS

#NuméroMère #Numéro_Enfant
Nom_Mère Nom_Enfant
Prénom_Mère Prénom_Enfant
 62

Une relation Elever :

MERES ENFANTS

#NuméroMère #Numéro_Enfant
Nom_Mère Elever Nom_Enfant
Prénom_Mère Prénom_Enfant

Des cardinalités :
Une mère peut élever un ou plusieurs enfants.
Un enfant peut être élevé par une et une seule mère.

MERES ENFANTS

#NuméroMère #Numéro_Enfant
Nom_Mère Elever Nom_Enfant
Prénom_Mère (1, n) (1, 1) Prénom_Enfant

Remarque
Bien sûr, tout est question d'interprétation. Au sein d'une équipe de développement il
peut y avoir des divergences de point de vue. Pour les cardinalités, il faut être le plus
logique possible, se référer aux règles de gestion édictées par le commanditaire de l'ap-
plication et se rappeler la maxime suivante : "Qui peut le plus peut le moins".

Les relations porteuses

Une relation est dite porteuse lorsqu'elle contient des propri étés.
Imaginons que l'on veuille connaître la quantité d'articles commandés par clients,
nous nous rendons compte qu'il faut utiliser une nouvelle propriété Quantité. Cette
nouvelle propriété dépend de clients, d'articles ou des deux ? La bonne réponse est
que Quantité dépend des deux entités.
Voici le modèle conceptuel correspondant :
 63

CLIENTS

#Numéro_Client ARTICLES
Nom (0, n)
Commander #Numéro_Articles
Prénom
Adresse Quantité Désignation
(1, n) Prix_d’achat
Code_Postal
Ville Prix_de_vente

Nous pouvons interpréter ce schéma de la façon suivante : Le client X a commandé la

quantité Y d'articles Z. Si nous désirons connaître la date d'achat, il nous suffit de créer
une entité Date à la relation Commander.
Remarque
 Une relation faisant intervenir deux entités est dite binaire.

MERES ENFANTS
#NuméroMère #Numéro_Enfant
Nom_Mère Nom_Enfant
Elever
Prénom_Mère Prénom_Enfant
(1, n) (1, 1)

 Une relation faisant intervenir trois entités est dite ternaire. Dans certains ouvrages
elle est caractérisée par l'appellation « Tri-pattes ».

PROFESSEUR ETUDIANTS

#NuméroMère Enseigner #Numéro_Enfant

Nom_Mère (1, 1)
Nom_Enfant
(1, n)
Prénom_Mère Prénom_Enfant

(1, 1)

AUDITOIRE

#NuméroMère
Nom_Mère
Prénom_Mère
 64

 Une relation réflexive est une relation d'une entité sur elle-même.
Par exemple, on désire modéliser le fait qu'un employé peut diriger d'autres em-
ployés.

EMPLOYE
#Numéro_Empl
Nom 0, n
Prénom
Diriger
Adresse
Code_Postal 1, 1
Ville
Telephone

À la lecture de ce schéma, nous interprétons donc qu'un employé peut diriger zéro ou
plusieurs autres employés et qu'un employé est dirigé par un et un seul autre em-
ployé.

d) Régles d’usages
- Toute entité doit comporter un identifiant.
- Toutes les p r o p r i é t é s de l'entité dépendent fonctionnellement de l'identifiant.
C'est-à-dire que connaissant la valeur de l'identifiant, nous connaissons de façon
sûre et unique la valeur des propriétés associées. Si nous recherchons le client
numéro 5, nous devons récupérer le nom et le prénom du client numéro 5 et pas
ceux d'une autre personne.
- Le nom d'une propriété ne doit apparaître qu'une seule fois dans le modèle
conceptuel des données. Si nous établissons une entité Clients et une nommée Pros-
pects, nous ne devons pas retrouver la propriété Nom dans les deux entités. Il faut
préférer la dénomination suivante Nom_client et Nom_prospect.
- Les propriétés résultantes d'un calcul ne doive nt pas apparaître dans le modèle
conceptuel des données.

Cas pratique
Reprenons le graphe concernant le cas du camping vu à la section précédent et réali-
sons le modèle conceptuel qui en découle.
 65

Le MCD pas à pas

Commençons par déterminer les entités. Par rapport au graphe, nous pouvons remar-
quer trois sources de dépendances fonctionnelles :
- CodeArticle ; Date ; NumCIi.
Chacune de ces sources peut représenter une entité :
- Articles ; Date ; Clients.
Voici la représentation graphique des entités :

Clients
Articles Date

Renseignons maintenant les entités avec leurs propriétés respectives :

Clients
Articles Date
#NumCli
#CodeArticle #date Nom
Désignation Prénom
Prix Adresse
Code_Postal
Vlle

Traçons les relations

Nous savons qu'une quantité d'articles est achetée par un client à une date donnée.
Nous voyons qu'il existe une relation entre les trois entités. La voici modélisée :
 66

Date
#date

Clients
0, n #NumCli
Articles Nom
#CodeAr- Prénom
ticle Adresse
Désignation Acheter Code_Pos-
Prix Qté tal
Vlle

Examinons les cardinalités. Sur le graphique précédent nous pouvons interpréter qu'au
minimum il ne se vend strictement rien. En pratique, nous pouvons imaginer qu'il ne se
passe pas une journée sans que se produise la vente d'un article à un client. En voici le
modèle conceptuel revu :
Date

#date

Clients
1, n
Articles #NumCli
Nom
#CodeArticle Prénom
Désignation Adresse
Acheter
Prix Code_Postal
Qté
Vlle

Maintenant, nous pouvons lire qu'au minimum un article est achet é dans une certaine
quantité, par au minimum un client à une date donnée. Voilà qui nous rapproche
plus de la réalité. Maintenant, nous pouvons lire qu'au minimum un article est acheté
dans une certaine quantité, par au minimum un client à une date donnée. Voilà qui
nous rapproche plus de la réalité.

Notions d’entité forte et d’entité faible

Une entité forte est une entité qui, disposant de son identifiant, peut être consi-
dérée de façon isolée. Tandisque une entité faible est une entité qui ne peut être con-
sidérée qu'en association avec une autre entité.
Voici un exemple :
 67

MERES ENFANTS

#NuméroMère #Numéro_Enfant
Nom_Mère Posseder Nom_Enfant
Prénom_Mère (1, n) (1, 1) Prénom_Enfant

Dans ce cas, l'entité forte est l'entité Mères et l'entité faible est l'entité Enfants.

3.1.2. Dictionnaire des données

Le dictionnaire des données est un document qui permet de recenser, de classer et de

trier toutes les informations (les données) collectées lors des entretiens ou de l'étude
des documents. Le dictionnaire peut être plus ou moins élaboré selon le niveau de
granularité souhaité.
En voici un exemple :
Tableau I.1. Dictionnaire de données
Nom de Type
Règle de Règle de
la don- Format Longueur Elémen- Document
Calculé calcul gestion
née taire

Nom de la donnée
Cette cellule recevra une donnée, par exemple : Nom client.
Format
Ici sera indiqué le format de la donnée, par exemple : alphabétique.

Longueur
La longueur approximative ou exacte de la donnée sera indiquée, par exemple :
3
Type
Une croix sera inscrite dans la colonne pour indiquer si la donnée est élémentaire ou
calculée.
Règle de calcul
Ici sera indiquée de manière claire la formule ou le calcul nécessaire à appliquer pour
obtenir la donnée.
Règle de gestion
Dans cette zone sera indiquée, si nécessaire, la règle de gestion inhérente à la donnée.
 68

Document
La rubrique document permet de saisir le document dans lequel a été trouvée la
donnée.
Voici ce que pourrait être le dictionnaire :
Tableau I.2 Dictionnaire de données avec rubrique documents
Type
Nom de la Règle de Règle de
Format Longueur Document
donnée E C calcul gestion

Nom client Alphabétique 30 X Facture

Le nom est au format alphabétique, d'une longueur de 30 caractères, de type élémen-

taire, il n'y a aucune règle de gestion et le document dans lequel l'information a été
trouvée est la facture.
Remarque
La longueur du champ nom a été définie aléatoirement à 30 caractères. Il faut toujours
avoir à l'esprit que dans le doute il vaut mieux sur dimensionner les tailles. Le proverbe qui
s'adapte à la situation est « Qui peut le plus peut le moins ».
Exemple :
Suite à une demande de président d'une association, nous devons établir le diction-
naire des données de la gestion des adhérents.
Voici une représentation d'une fiche d'adhérent :

Association des Anciens de Tigo

Fiche Adhérent
Numéro : 100
Nom : MAMPUYA
Prénom : Pescie
Adresse : Rue du 30 juin
Code Postal : 45 KIN II
Ville : KINSHASA
Téléphone : 00243 898900113
Mail : pesciemampuya@gmail.com
 69

Date d’adhésion : 12 Novembre 2009

Figure I.6. Fiche Adhérent
À la lecture de la fiche, nous pouvons déterminer la présence de neuf informations dif-
férentes :
1. Le numéro de l'adhérent.
2. Le nom.
3. Le prénom.
4. L'adresse.
5. Le code postal.
6. La ville.
7. Le téléphone.
8. Le mail.
9. La date d'adhésion.
Voici le dictionnaire des données :
Tableau I.3 Dictionnaire de données

Règle de Règle de
Type Document
Nom Format Longueur calcul gestion

E C Fiche
Numéro N X //
Nom A 30 X //
Prénom A 30 X //
Adresse AN 50 X //
Code postal
AN 10 X //

Ville A 50 X //
Téléphone AN 15 X //
Mail AN 50 X //
Date
Date x //
d’adhésion

Remarque
Le code postal est alphanumérique et de taille 10. Certaines personnes peuvent considé-
rer qu'il serait plus judicieux de placer le format en numérique. Or qu'est- ce qui prouve
que dans certains pays la règle d'écriture des codes postaux est identique à la règle
congolaise des 5 chiffres ? En effet, certains pays mélangent des chiffres et des lettres.
 70

Le format alphanumérique est le plus approprié dans ce cas-là. De manière générale, il

est souhaitable de ne formater en numérique que les champs sur lesquels il va y avoir des
calculs. Le raisonnement appliqué est le même pour le champ téléphone.

3.1.3. Les dépendances fonctionnelles

Le rôle de l'établissement des dépendances fonctionnelles est de nous aider à com-

prendre les liens existants entre chaque donnée. Cette démarche de recherche des
dépendances fonctionnelles est la pierre angulaire de toute l'analyse des données. En ef-
fet, cette activité étant la première dans l'élaboration de l'analyse, si elle est négligée c'est
tout l'ensemble qui en subira les conséquences.
Définition
Une donnée B dépend fonctionnellement (ou est en dépendance fonctionnelle) d'une
donnée A lorsque la connaissance de la valeur de la donnée A nous permet la connais-
sance d'une et au maximum une seule valeur de la donnée B.
Par exemple :
La connaissance de la valeur d'un numéro de client nous permet de connaître sans
ambiguïté la valeur d'un et d'un seul nom de client.
Dans la fiche d'adhérent, l'adhérent numéro 100 a pour nom MAMPUYA.
Formalisme
Le formalisme de représentation d'une dépendance fonctionnelle est le suivant :
Numéro adhérent —> (Nom adhérent, prénom, adresse, code postal, ville, téléphone,
mail, date d'adhésion).
Remarque
Numéro adhérent sera appelé la clé de la relation ou clé primaire ou encore identifiant de la
relation.
La partie gauche de la dépendance fonctionnelle (ici Numéro adhérent) est aussi ap-
pelée source de la dépendance fonctionnelle. La partie droite de la dépendance fonc-
tionnelle est appelée le but de la dépendance fonctionnelle.

3.1.3.1. Des données aux dépendances fonctionnelles

Toute activité conceptuelle nécessite de la part de maitre d’œuvre une identification

de données et traitements indispensables à l’informatisation.
 71

Pour être traitées de manière informatisée, les données doivent être décrites dans un
formalisme compris par le système informatique qui va les gérer. Voici les formats géné-
riques utilisés :
1. Le type alphabétique (rien que des caractères) ;
2. Le type alphanumérique (des caractères, des chiffres...) ;
3. Le type numérique (rien que des chiffres) ;
4. Le type date ;
5. Le type logique (0-1, Vrai-Faux, Oui-Non).
Suite à l'interview et la collecte des documents, il est nécessaire de centraliser toutes
les informations et règles de gestion (calcul d'un taux de remise par exemple) au sein
d'un document. Ce document se nomme le dictionnaire des données.

3.1.3.2. Dépendances fonctionnelles élémentaires

Une dépendance fonctionnelle A —> B est élémentaire s'il n'existe pas une donnée C,
sous-ensemble de A, décrivant une dépendance fonctionnelle de type C—>B.
Par exemple :
Référence Produit—> Désignation Numéro Commande.
Référence Produit —> Quantité Numéro Commande,
Référence Produit —> Désignation

La première dépendance fonctionnelle est correcte car ayant deux rubriques elle est
élémentaire.

La deuxième dépendance fonctionnelle est correcte également car la connaissance

d'un numéro de commande et d'une référence produit nous permet de connaître la
quantité commandée du produit. Elle est aussi élémentaire car c'est la connaissance du
couple (Numéro Commande, Référence Produit) et pas seulement d'un des éléments qui
permet la connaissance de la quantité.

La troisième dépendance fonctionnelle n'est pas élémentaire car il existe à l'intérieur

d'elle Référence Produit —> Désignation qui était déjà une dépendance fonctionnelle
 72

élémentaire. Pour connaître la Désignation, Numéro Commande est dans ce cas super-
flu.

3.1.3.3. Dépendances fonctionnelles élémentaires directes

On dit que la dépendance fonctionnelle A —> B est directe s'il n'existe aucun attribut C
tel que l'on puisse avoir A —>C et C —> B. En d'autres termes, cela signifie que la dépen-
dance fonctionnelle entre A et B ne peut pas être obtenue par transitivité.
Exemple :
NumClasse —> NumEleve
NumEleve —> NomElève
NumClasse —> NomElève
La troisième dépendance fonctionnelle n'est pas directe car nous pourrions écrire :
NumClasse —> NumElève —> NomElève

3.1.3.4. Dépendances fonctionnelles composées

Une dépendance fonctionnelle qui comporte plusieurs attributs est dite composée.
Voici un exemple de dépendance fonctionnelle composée :
(Numéro Coureur, Numéro course) —> (temps) Interprétation

Connaissant le numéro du coureur et le numéro de la course, nous connaissons de

façon certaine le temps chronométré d'un coureur précis sur une course précise.
Autre exemple :
(Code athlète, code sport) -» (année de pratique)
Interprétation
Connaissant le code de l'athlète et le code du sport nous pouvons connaître de façon
sûre et unique le nombre d'années de pratique. Comme nous pouvons le constater la
seule connaissance du code d'athlète ne nous permet pas de connaître le nombre
d'années de pratique, d e la même manière la seule connaissance du code du sport
ne permet pas la connaissance pleine et entière des années de pratique. Structurelle-
ment, il est nécessaire d'avoir les deux informations : le code de l'athlète et le code du
sport, pour pouvoir connaître les années de pratique d'un sport précis par un athlète
précis.
 73

Méthodologie d’élaboration des dépendances fonctionnelles

L'élaboration des dépendances fonctionnelles est réalisée à l'aide du dictionnaire des

données. La démarche consiste à rechercher :
 Les dépendances fonctionnelles formées par deux rubriques, élémentaires et di-
rectes.
 Les dépendances fonctionnelles composées.

Etude des cas pratiques

Monsieur Miguel, sa fille Olga et son gendre Emmanuel gèrent une concession dans la
commune de Nsele. La concession est ouverte du 1er juin au 30 septembre. Ils dispo-
sent de cinquante emplacements sur un terrain d'une superficie totale de quarante
hectares.
Ils sont équipés d'un logiciel spécialisé dans la réservation des emplacements qui fonc-
tionne très bien mais qui ne permet pas de gérer les achats de l'épicerie ou du bar selon
leurs règles de gestion. En effet, les vacanciers ne payent leurs achats qu'à la fin de leur
séjour. Concrètement, les achats sont inscrits manuellement sur une fiche bristol créée
pour chaque famille de vacanciers. À la fin de séjour, les cumuls sont réalisés et une
facture manuelle concernant les achats est établie. Les propriétaires du camping sou-
haiteraient disposer d'un logiciel permettant d'automatiser la création de la facture
grâce à la saisie journalière des achats.
Voici une représentation de la fiche bristol :

Alimentation YOKEBED
Fiche des Achats
Nom : KIANSOSA
Prénom : JULIE
Adresse : Rue KIMVULA
Code Postal : 15000
Ville : KINSHASA
Téléphone : 00243 999 998 880

Date Désignation Qté Prix Total

14/07/08 Repas « Cargolade » 4 22 88
 74

15/08/08 Café 1 1,20 1,20

15/7/08 Glade « Magnum » 2 2,10 4,20
16/7/08 Baguette 1 1,15 1,15
Total dû : 94,55

Figure I.7. Fiche des Achats

Résolution du cas
À la lecture de l'énoncé, nous devons déterminer et séparer les informations mémori-
sables des informations décrivant le contexte.
Les prénoms des propriétaires de la concession sont-ils des informations stockables
ou des informations d'ordre général ? Si nous analysons la demande d'informatisation
ces données ne font pas partie du système d'information.
Il en est de même pour les dates d'ouverture, de fermeture, le nombre d'emplacements
ou la superficie de la concession.
II paraît évident que nous devons nous intéresser à l'élément de base, c'est-à-dire la fiche
bristol. C'est elle qui contient les informations indispensables à l'élaboration de la facture
finale.
Nous pouvons y trouver le nom de la famille, son adresse, la liste des articles achetés,
leur prix unitaire, la quantité, le total. Il va être nécessaire de rajouter deux informations
non présentes : le numéro du client et le code de l'article.

Dictionnaire des données

Voici un dictionnaire de données qui pourrait être élaboré suite à la lecture de l'énoncé :
Tableau I.4 Dictionnaire de données
Règle de Règle de
Type Document
Nom Format Longueur calcul gestion
E C Bristol
Num_cli AN X //
Nom A 30 X //
Prénom A 30 X //
Adresse AN 50 X //
 75

Code pos-
AN 10 X //
tal
Ville A 50 X //
Code_Ar-
AN 15 X //
ticle
Désigna-
A 50 X //
tion
Prix_Uni-
N X //
taire
Qté N X //
Date Date X //
To- Prix Uni-
N X //
tal_Ligne taire * Qté
Total_Fac- Numé- Somme des
X //
ture rique Total-Ligne

Le dictionnaire des données recense l'ensemble des informations. Comme nous pou-
vons le constater certaines informations seront déduites (ou calculées) en fonction
d'informations élémentaires. C'est le cas du TotalLigne qui est le résultat de la multi-
plication du prix unitaire du produit et de sa quantité et du TotalFacture qui est la
somme des TotalLigne. Ces deux informations sont utiles pour le développeur de l'ap-
plication qui mettra en œuvre les procédures de calculs a posteriori. Dans le cycle de
modélisation Merise ces deux informations sont des données déduites et non stock-
ables, elles n'apparaîtront donc pas dans la suite du processus.

Détermination des dépendances fonctionnelles ou DF

À la lecture du dictionnaire nous pouvons déduire deux groupes d'informations dis-

tinctes. Un groupe caractérise les clients, l'autre les produits.
Dépendances fonctionnelles pour les clients
Posons-nous la question :
« Quand je connais le numéro du client, est-ce que je connais de façon sûre et unique
le nom du client ? ». Si la réponse est « oui » alors voici la transcription de la DF :
Numcli —> Nom
Voici maintenant l'ensemble des DF élémentaires
 76

Numcli —> Prénom

Numcli —> Adresse
Numcli —> Code Postal
Numcli —> Ville
Dépendances fonctionnelles pour les articles :
CodeArticle —> Désignation
CodeArticle —> PrixUnitaire
Remarque
Les DF auraient pu s'écrire de la façon suivante :
Numcli —> (Nom, Prénom, Adresse, Code Postal, Ville)
CodeArticle —> (Désignation, PrixUnitaire).

Intéressons-nous à la donnée Qté : est-ce que la connaissance du code de l'article nous

permet de connaître de façon sûre et unique une quantité ?
Autrement dit :
Connaissant « code article » nous pouvons connaître de façon sûre et unique la quan-
tité « n »?
Nous nous rendons compte que cette donnée Qté fait partie d’une dépendance
fonctionnelle composée.
Voici une proposition :
(Numcli, CodeArticle, Date) —> Qté
Et maintenant si nous nous posons la question :
« Connaissant le code du client, le code de l'article et la date d'achat pouvons- nous
connaître de façon sûre et unique la quantité achetée ? ».
Il est évident que la réponse est oui !
Voilà, nous venons de définir l'ensemble des dépendances fonctionnelles concer-
nant notre cas.
Rappel
Les dépendances fonctionnelles ne concernent que les données non déduites. C'est
pour cela que n'apparaissent pas les données concernant le total par ligne et le total glo-
bal de la facture qui sont des informations déduites par calcul.
 77

Graphe des dépendances fonctionnelles

Le graphe des dependances fonctionnelles est une étape intéerssante car il épure le dic-
tionnaire en ne retenant que les données non déduites et élémentaires et il permet une
representattion spatiale de ce que sera le futur modèle conceptuel des données.

Voici le graphe de DF concernant l’enoncé ci-dessus :

Figure I.8. Graphes des dépendances Focntionnelless

Matrice des dépendances fonctionnelles

Une autre facon de représenter les DF est de créer une matrice. Cependant, cette repré-
sentation ne présente pas le même intérêt que le graphe, qui, lui, permet une visoin plus
graphique du futur MCD.

Elle se e présente sous forme d’un tableau ayant pour entrées l’ensemble des données
du dictionnaire. Les entêtes de colonnes sont les données des DF. Le tableau est par-
couru colonne par colonne, et pour chaque colonne, ligne par ligne.

A chaque étape la question suivante est posée : la donnée source est-elle en DF avec la
donnée but ? En cas de réponse positive, nous inscrivons un « 1 » dans la case d’inter-
section.

Exemple :

Tableau I.5. Matrice des dépendances Focntionnelles

Sources
But 1 2 3 4 5 6 7 8 9 10 11 12
1 Numcli
2 Nom 1
3 Prénom 1
4 Adresse 1
5 Code postal 1
6 Ville 1
7 CodeArticle
8 Désignation 1
 78

9 Prix 1
10 Date
11 Qté 1
12 NumCli, CodeAr-
ticle, Date

Une version simplifée consiste à ne laisser que les colonnes sources ayant « 1 » d’inscrit.

Tableau I.6. Matrice des dépendances Focntionnelles Simplifiée

Sources
But 1 7 12
1 Numcli
2 Nom 1
3 Prénom 1
4 Adresse 1
5 Code postal 1
6 Ville 1
7 CodeArticle
8 Désignation 1
9 Prix 1
10 Date
11 Qté 1
12 NumCli, CodeAr-
ticle, Date

En conclusion, il est impératif de bien comprendre et bien maîtriser ces notions de

dépendances fonctionnelles, car elles sont les fondations des modèles Merise qui vont
suivre. Donc, il est nécessaire de passer du temps à bien les définir pour éviter les er-
reurs de conception plus tard.

3.1.4. Notions d'intégrité fonctionnelle

Une contrainte d'intégrité fonctionnelle (ou CIF) est définie par le fait qu'une des enti-
tés de l'association est complètement déterminée par la connaissance d'une ou de plu-
sieurs entités participant à cette même association.

Salle Ordinateur
0, n
#NumSalle Contenir #NumOrdina-
Nom teur
Capcité Constructeur

Nous pouvons lire qu'une salle peut contenir un ou plusieurs ordinateurs et qu'un or-
dinateur est contenu dans une et une seule salle. Dans le cas d'une association binaire
 79

comme celle-ci, une contrainte d'intégrité fonctionnelle existe à partir du moment où

une cardinalité de type 1,1 existe.
Certains auteurs proposent une écriture de ce type :

Salle Ordinateur
0, n
#NumSalle CIF #NumOrdina-
Nom teur
Capcité Constructeur

3.1.5. Notions d'identifiant relatif

Les identifiants relatifs font partie des extensions Merise/2.

Certaines entités ont une existence totalement dépendante d'autres entités. Dans ce
cas nous avons recours à un identifiant relatif.
Par exemple :
Nous devons gérer les exemplaires des livres commandés dans une bibliothèque :

Ouvrage Exemplaire
1, n
((R) #Num Exemplaire
#Num ISBN Posseder
Titre Date d’achat
Nom auteur Prix
Prénom auteur

Nous pouvons considérer qu'une bibliothèque achète plusieurs exemplaires du même

livre. Doit-elle numéroter les exemplaires dans l'ordre séquentiel croissant, c'est-à-dire
de 1 à 6 000, ou pour chaque ouvrage de 1 au nombre maximal de cet ouvrage
présent dans la bibliothèque ?
Il paraît évident que la solution la plus judicieuse est la seconde proposition. Ainsi, la
clé d'identification de l'exemplaire sera la concaténation du Num ISBN et du Num
Exemplaire. L'identification d'un identifiant relatif se traduit par le symbole (R) à côté de
la cardinalité.
Pour reconnaître un identifiant relatif, nous pouvons aussi nous poser la question « si je
supprime l'ouvrage X de ma bibliothèque, dois-je supprimer tous les exemplaires ? ». La
réponse est bien entendu oui. Nous pouvons donc dire que l'existence même de l'en-
tité Exemplaire dépend de l'existence de l'entité Ouvrage.
Voici un autre exemple encore plus évident :
Vous êtes le responsable informatique d'un centre de formation possédant un campus
sur lequel sont construits 3 bâtiments strictement identiques :
 80

Ils possèdent 3 étages et chaque étage héberge 12 salles informatiques dans les-
quelles peuvent être installés 10 ordinateurs.
Nous pouvons en conclure que dans chaque bâtiment, nous pouvons installer
360 ordinateurs et la capacité du campus est de 3*360 ordinateurs soit 1080. Imagi-
nons le scénario suivant : vous recevez une dotation de 1080 ordinateurs à répartir dans
toutes les salles. En outre, vous devez les numéroter pour les identifier.
Quelle solution choisissez-vous ?
Une solution serait de les numéroter de 1 à 1080.
1. Une autre serait de rendre la numérotation relative à la salle.
Par exemple, dans la salle 1 du premier étage du bâtiment A, la numérotation serait de
1-1 à 1-10, dans la salle 2 la numérotation irait de 2-1 à 2-10...
Maintenant, il serait judicieux de rendre la salle relative à l'étage. La numérotation de-
viendrait El-1-1, pour le premier ordinateur de la salle 1 de l'étage 1, ou E3-12-10 pour
le dixième ordinateur de la salle 12 de l'étage 3.
Vous venez de comprendre que maintenant nous pourrions rendre les étages relatifs
aux bâtiments et numéroter les ordinateurs de la façon suivante : BA - E3-12-10. Ainsi,
nous savons que nous avons affaire à l'ordinateur 10 de la salle
12 de l'étage 3 du bâtiment A. Si les ordinateurs peuvent être changés de lieu rien
qu'en regardant leur identifiant, vous pouvez les réinstaller dans leurs salles respec-
tives.
Voici le modèle conceptuel découlant de cet exemple :
 81

Imaginons que le centre de formation décide de vendre un bâtiment, tout disparaît en

cascade.

Conception d'un modèle conceptuel des données pas à pas

Pas à pas, nous allons créer un Modèle Conceptuel des Données en partant d'un cas
fictif.
Soit la narration ci-dessous :
Votre oncle, restaurateur, vous demande de lui réaliser un logiciel de gestion des com-
mandes de repas. Voici les indications qu'il vous donne :
II souhaite pouvoir gérer certaines informations concernant ses employés : nom,
prénom, adresse complète, téléphone et diplômes.
Au niveau de la prise de commande, il souhaite savoir si elle porte sur le service de midi
ou celui du soir et à quelle date elle a été passée.
Pour certains calculs statistiques, il souhaite aussi savoir quelle table a passé la com-
mande et quel serveur l'a prise.
La carte du restaurant propose l'ensemble des plats d'entrées, principaux et desserts.
Les menus proposés sont un assemblage des plats à la carte.
La carte des vins propose une sélection de vins qui sont stockés dans la cave du res-
taurant. Votre oncle désire connaître pour chaque bouteille son millésime, sa date
d'achat, son prix d'achat et son prix de vente. Il voudrait saisir aussi pour chaque cru
les informations concernant le viticulteur (nom, prénom, adresse complète, télé-
phone). À l'heure actuelle votre oncle, amoureux du vin, met sur chaque goulot de
chaque bouteille une étiquette contenant le prix d'achat ainsi que la date d'achat. Votre
système doit pouvoir remplacer ce traitement manuel.
Ensuite, certaines boissons comme les apéritifs, les digestifs, les sodas ou les cafés
sont gérés de façon simpliste juste par leur libellé et leur prix de vente. Chaque serveur
prenant une commande saisit l'ensemble des informations sur un Pocket PC qui trans-
met la commande via Wifi sur un ordinateur central.
À l'aide de ces quelques informations basiques, essayons de réaliser le modèle concep-
tuel. Nous allons commencer par identifier les règles de gestion et présenté un diction-
naire des données simplifiées.
 82

Les règles de gestion

Partant de cette narration nous pouvons identifier les règles de gestion ci-après :
1. L’employé prend des commandes ;
2. L’employé possède les diplômes ;
3. Une table est concernée par les commandes ;
4. La commande est passée à une date ;
5. Le menu est constitué des cartes de plat ;
6. Une carte de plat correspond à un type de plat ;
7. La commande est constituée de carte de plat ;
8. La commande dépend de service ;
9. Une commande peut contenir les boissons diverses ;
10. La commande sélectionne les cartes de vin ;
11. La carte de vin correspond à une bouteille ;
12. Le viticulteur fourni les bouteilles.

Le dictionnaire des données

Nom Format Longueur Type
E C
Numéro employé Numérique
Nom employé Alphabétique 30 X
Prénom employé Alphabétique 30 X
Adresse employé Alphanuméri 40 X
Code Postal employé Alphanuméri 5 X
Ville employé Alphabétique 40 X
Téléphone employé Alphanuméri 15 X
Diplômes des employés Alphabétique 30 X
Numéro viticulteur Numérique X
Nom viticulteur Alphabétique 30 X

Nom Format Longueur Type

E C
Prénom viticulteur Alphabétique 30 X
Adresse viticulteur Alphanuméri 40 X
Code postal viticulteur Alphanuméri 5 X
Ville viticulteur Alphabétique 40 X
 83

Téléphone viticulteur Alphanuméri 15 X

Numéro de la table Numérique X
Capacité Numérique X
Numéro de la boisson Numérique X
Désignation de la Alphabétique 20 X
Prix de vente de la Numérique X
Numéro du vin Numérique X
Nom du vin Alphabétique 30 X
Millésime du vin Numérique X
Prix de vente du vin Numérique X
Numéro de la bouteille Numérique X
Date d'achat de la Date X
Prix d'achat de la Numérique X
Numéro du menu Numérique X
Libellé du menu Alphabétique 30 X
Prix de vente du menu Numérique X
Numéro du plat Numérique X
Libellé du plat Alphabétique 30 X
Prix de vente du plat Numérique X
Numéro de type de plat Numérique
Désignation du type de Alphabétique 20 X
plat (entrée, plat

Type
Nom Format Longueur E c
Type de service (midi ou Alphabétique X
Date de prise de Date X
Numéro de la Numérique X

Voici une ébauche du dictionnaire des données, ceci est notre base de travail. Si au fil
de la conception ou de la réflexion certaines propriétés apparaissent, il suffira de les
rajouter.

Les dépendances fonctionnelles

A. Dépendances élémentaires
Numéro employé —> (Nom employé, Prénom employé, Adresse employé, Code Postal
employé, Ville employé, Téléphone employé).
 84

Numéro viticulteur —> (Nom viticulteur, Prénom viticulteur, Adresse viticulteur, Code
postal viticulteur, Ville viticulteur, Téléphone viticulteur).
Numéro de la boisson —> (Désignation de la boisson, Prix de vente de la boisson).
Numéro du vin —> (Nom du vin, Millésime du vin, Prix de vente du vin). Numéro de la
bouteille —> (Date d'achat de la bouteille, Prix d'achat de la bouteille).
Numéro du menu —> (Libellé du menu, Prix de vente du menu).
Numéro du plat —> (Libellé du plat, Prix de vente du plat).
Numéro type de plat —>Désignation du type de plat
Numéro de la table—> Capacité

B. Dépendances isolées
1. Diplômes des employés.
2. Type de service (midi ou soir).
3. Date de prise de commande.
4. Numéro de la commande.
Traitement des dépendances isolées
Pour les diplômes, deux possibilités s'offrent à nous :
1. Soit nous notons seulement un diplôme par employé.
2. Soit nous notons tous les diplômes d'un employé.
Dans le premier cas, la résolution du problème est simple : Numéro employé — > Di-
plôme.
Dans le deuxième cas, nous pouvons gérer la possibilité d'avoir soit un diplôme soit plu-
sieurs diplômes. Comme dit le proverbe : "Qui peut le plus peut le moins". Il semble judi-
cieux de pouvoir concevoir une analyse ne bloquant pas l'utilisateur. Nous allons donc
utiliser la deuxième alternative en ajoutant même une propriété Date d'obtention :
(Numéro employé, diplôme) —> Date d'obtention.
Pour la désignation du type de plat, nous pouvons être sûrs que lorsque l'on connaît
un numéro de plat on connaît de façon sûre et unique un type de plat.
Numéro du plat —> Type de plat.
Il nous reste :
1. Type de service
2. Date de prise de commande
3. Numéro de la commande
 85

Nous pouvons ressentir que tout tourne autour d'un numéro de commande. En fait,
une commande est prise par un serveur, concerne une table, est réalisée à une date don-
née, sur un type de service et comprend des plats et/ou des menus et/ou des vins et/ou
des boissons et comportera des quantités associées.

Nous pourrions essayer ceci :

1. Numéro de la commande —> Date de prise de commande.
2. Numéro de la commande —> Type de service.
3. Numéro de la commande —> Numéro de la table. Numéro de la commande —> Numéro
employé.
4. (Numéro de la commande, Numéro de la boisson) —> Quantité.
5. (Numéro de la commande, Numéro du vin) —> Quantité.
6. (Numéro de la commande, Numéro du plat) —> Quantité.
7. (Numéro de la commande, Numéro du menu) —> Quantité.
Remarque
La conception d'un modèle conceptuel est un processus dynamique, nous allons con-
sidérer maintenant que toutes nos dépendances fonctionnelles sont décrites et conti-
nuer à cheminer dans le projet en commençant à générer le MCD. De cette génération
et réflexion, des liens peuvent apparaître, liens qui peuvent être absents de la première
ébauche de dépendances fonctionnelles. Il suffit de les rajouter à posteriori.

Élaboration du Modèle Conceptuel des Données

Maintenant, considérons que nos dépendances fonctionnelles sont décrites et com-
mençons à générer pas à pas le Modèle Conceptuel des Données.

EMPLOYES
DIPLOMES
1, n 1, n #Num_Em-
Possèder ployés
#Diplome Nom
Date d’obten- Prénom
tion Adresse
Code_Postal
Ville
Téléphone

Nous pouvons dire qu'un employé peut posséder un ou plusieurs diplômes et qu'un
diplôme peut être possédé par un ou plusieurs employés. Par exemple le diplôme de
 86

graduat en hôtellerie cuisine est un diplôme pouvant être détenu par plusieurs em-
ployés.

TYPE DES PLATS

CARTE DES
1, 1 1, n #NumType
PLATS
Correspondre Designation
#NumPlat
LibelléPlat
Prix de vente

À un plat correspond un et un seul type de plat, c'est soit une entrée, soit un plat de
résistance, soit un dessert. À l'inverse, pour une entrée, il peut y avoir un ou plusieurs
plats différents.

Nous voyons ici qu'un menu peut être constitué d'au minimum un plat et d'au maximum
plusieurs. Par contre un plat peut faire partie d’un et un seul menu.

Une bouteille est fournie par un et un seul viticulteur et un viticulteur peut fournir
une ou plusieurs bouteilles.
 87

À un vin présent sur la carte des vins correspond une ou plusieurs bouteilles en stock et
à une bouteille précise correspond une et une seule carte de vin.

Nous pouvons considérer qu'un employé peut prendre zéro (le cuisinier par exemple)
ou plusieurs commandes. Par contre, une commande est prise par un et un seul em-
ployé.

Une commande concerne une et une seule table et une table peut passer une ou plu-
sieurs commandes.
 88

Une commande est passée à une et une seule date et à une date donnée il peut y
avoir une ou plusieurs commandes passées.

Une commande dépend d'un service (midi ou soir) et durant un service une ou plu-
sieurs commandes peuvent être passées.

Une commande peut contenir zéro ou plusieurs boissons dans des quantités diffé-
rentes et une boisson peut faire partie de zéro ou de plusieurs commandes dans des
quantités différentes.

Une commande peut contenir zéro ou plusieurs vins dans des quantités différentes et
un vin peut faire partie de zéro ou de plusieurs commandes dans des quantités diffé-
rentes.
 89

Une commande peut contenir zéro ou plusieurs menus dans des quantités différentes et
un menu peut faire partie de zéro ou de plusieurs commandes dans des quantités diffé-
rentes.

Une commande peut contenir zéro ou plusieurs plats dans des quantités différentes et
un plat peuvent faire partie de zéro ou de plusieurs commandes dans des quantités diffé-
rentes.
Voici la représentation globale du modèle conceptuel. Nous allons voir si nous pouvons
améliorer certains points.
 90

Conclusion
Cette phase est l'une des plus importantes, il est évident qu'il faut y passer du temps.
Il faut savoir aussi que plus vous pratiquerez les modèles conceptuels plus vous serez
à l'aise.
 91

N'hésitez pas à faire et refaire les exercices situés dans les études de cas pour vous per-
fectionner.

2.6.2. Le modèle conceptuel des traitements (MCT)

Le Modèle Conceptuel des Traitements met en lumière les traitements effectués sur
les données. Indépendamment de toute contrainte liée à l'organisation, le Modèle
Conceptuel des Traitements répond à la question « Quoi ? ». Le Modèle Conceptuel
des Traitements ne répond ni au comment, ni au quand, ni au qui, mais à Que sou-
haite-t-on obtenir ?

Les événements
Le MCT est aussi appelé Modèle événement-résultat. L'arrivée d'un ou plusieurs évé-
nements va générer une opération qui va-t-elle -même fournir un résultat. Selon leur
origine on distingue les événements externes (exemple : la commande d'un client) et
les événements internes générés par le système d'information (exemple : l'émission
d'une facture).
Un événement est représenté de la façon suivante :

Les opérations
Une opération est une suite d'actions ininterruptibles. Pour trouver les opérations, on
se sert du diagramme de flux conceptuel de niveau le plus bas et on décompose les
activités en un ensemble d'opérations élémentaires.

La synchronisation
La synchronisation agit au niveau des événements avec des opérateurs logiques : et, ou,
non.
 92

Représentation schématique d'un Modèle Conceptuel des Traitements

Elaboration d'un modèle conceptuel des traitements pas à pas

Nous allons nous entraîner sur un exemple :
Dans l'entreprise Baptiste & Co, voici comment sont traitées les commandes des
clients et la facturation :
Les commandes des clients arrivent par courrier au service secrétariat, généralement le
matin. En début d'après-midi, les commandes sont transmises au service de prépara-
tion des livraisons. Le responsable du service des livraisons vérifie l'identité du client et
le stock pour les marchandises commandées.
Si les stocks sont suffisants, un bon de préparation est rédigé, sinon il rédige un courrier
au client pour l'avertir de l'absence d'un des produits et la commande est mise en at-
tente.
 93

Dans le cas où le stock est suffisant, un employé du service des livraisons prépare la
livraison à l’aide du bon de préparation : il prélève et emballe les marchandises, ensuite
il saisit les bons de préparation et édite en double exemplaire le bon de livraison dont
un exemplaire est adressé au client en même temps que le colis, le deuxième exem-
plaire étant transmis au service comptable.
À partir du bon de livraison, un employé du service comptable saisit le numéro du bon,
vérifie les tarifs et les conditions de règlement et édite la facture en double exemplaire
: un exemplaire est adressé au client, l'autre est archivé en attente de comptabilisation.
En fin de semaine, un employé du service comptable récupère l'ensemble des factures
en attente de comptabilisation ; pour chacune d'elle, l'employé saisit le numéro de
facture et valide les données à l'écran. Après saisie, le grand livre est mis à jour.
94
 95

2.7. Le modèle organisationel

L’objet de cette étape est de mettre en évidence l’organisation à mettre en place pour
que le système d’information atteigne ses objectifs. A ce niveau, les modèles qui y sont
associés sont :
 96

 Pour les données, le modèle organisationnel des données (MOD) qui représente l’en-
semble des données par site organisationnel. Son formalisme est celui du MCD ;
 Pour les traitements : le modèle organisationnel des traitements (MOT) qui permet de
représenter par procédure les phases et les tâches exécutées par chaque poste de travail.
Son formalisme est celui du MCT
Bref, à cette étape on tentera de répondre à la question « qui fait quoi et où » tout en
tenant compte des choix d’organisation.

2.7.1. Le modèle organisationel des données

La modélisation organisationnelle des données va permettre de prendre en compte des

éléments relevant de l’utilisation des ressources de mémorisation :
 Le choix des informations à mémoriser informatiquement.
 La quantification (ou volume) et la durée de vie des informations à mémoriser.
 La répartition des données informatisées entre unités organisationnelles.
 L’accès aux données informatisées pour chaque unité organisationnelle.
Le modèle organisationnel des données apparaît donc comme une représentation, ex-
primée avec le formalisme entité-relation, des informations qui seront mémorisées infor-
matiquement compte tenu des volumes, de la répartition et de l’accessibilité, sans encore
tenir compte des conditions de structuration, de stockage et de performance liées à la
technologie de mémorisation qui sera utilisée.
Le développement du Client/serveur nécessite une répartition des données et des trai-
tements entre les clients et un ou plusieurs serveurs. Le MOD se caractérise par des pré-
occupations spécifiques.
 Détermination des données retenues au niveau organisationnel
 Détermination des droits d'accès aux données.
 Pour chaque donnée ou ensemble de données
 Les droits d'accès en consultation, Mise à Jour, doivent être définis pour
chaque utilisateur
 La visibilité des données par site organisationnel (S.I organisé en plusieurs
sites).
 La volumétrie des données actives (M à J) et passives (Archivage).
Le formalisme du MOD est identique à celui du MCD.
 97

2.7.1.1. Choix des données à mémoriser informatiquement

Il s’agit de choisir, à partir des données formalisées sur le modèle conceptuel des don-
nées, celles qui devront être effectivement mémorisées informatiquement dans le sys-
tème d’information informatisé. Notons au passage que d’autres informations pourront
être mémorisées manuellement sur support papier ou sur autres supports non informa-
tique. Ces informations feront toujours partie des informations constituant la mémoire
du système d’information organisationnel.
Le modèle organisationnel des données ainsi obtenu et ne prend pas en compte les
choix d’utilisation reparties. Les règles de passage du modèle conceptuel des données
au modèle organisationnel des données sont les suivantes :
 Supprimer des éléments (entités, relations, propriétés) qui ne seront pas mé-
morisés informatiquement.
 Modifier certains éléments (entités, relations, propriétés, cardinalités, …)
compte tenu du choix de mémorisation informatisé.
 Ajouter de nouvelles informations pour permettre de faire le lien entre les
données mémorisées et les données restées manuelles ; par exemple la réfé-
rence des fiches, des dossiers, etc.
Si le modèle conceptuel contient des informations qui sont toutes mémorisable informa-
tiquement, alors ce modèle devient le modèle organisationnel de données global.

Identification des types de sites et des types d'acteurs :

a. Type d'acteurs : Ensemble d'occurrence d'acteurs travaillant sur un même
type d’activité (ex : le service comptable)
b. Type de site : Ensemble de type d'acteurs regroupé s sur un critère organisa-
tionnel et/ou fonctionnel (ex. Agence régional)

Documents types :

Détermination des données à retenir au niveau organisationnel

• Le MOD ne doit contenir que les données utilisées dans les traitements automatisées.
 98

• Le MOD peut contenir de nouvelles informations ou données de type organisationnel

par rapport au MCD. (Exemple données ayant un lien avec le site organisationnel → @
du site, dépôt de rattachement, nombre de connexions…)

Détermination des droits d'accès

Les droits d'accès doivent être définis par type d'acteur et/ou par type de site.
• Droit d'accès à la consultation largement autorisé sauf dans les cas spéci-
fiques de données sensibles (salaires, données stratégiques,)
• Les droits d'accès en M à J représentent un enjeu fondamental dans la cons-
truction du SI s'assurer de l’unicité de la responsabilité de la M à J
• Définir des droits du M à J par ensemble homogène et cohérent de données
et par type d'acteur responsable.
 Distinguer les droits d'accès à la création initiale et les droits d'accès à la mo-
dification.

La visibilité des données par site organisationnel

A partir d'un MOD général, on établit un MOD par site. Cette opération s'appelle la frag-
mentation.
 99

Exemple de construction d’un MOD : Cas d’une applicatiion de suivi de temps de

vol :
 MOD - Global

 Quantification du modele organisationnel des donnees

La quantification du modèle organisationnel des données s’effectue essentiellement au
niveau du modèle organisationnel des données globales. Cette Quantification est sta-
tique et permet essentiellement de déterminer en première approximation le volume
des données à mémoriser.

 Quantification des proprietes

A ce niveau nous allons exprimer la taille des propriétés en termes de nombre de carac-
tères. Ensuite nous calculerons la taille de chaque objet et de chaque relation à partir
des tailles des propriétés. Certes cette évaluation est discutable car, … suivant la tech-
nique de mémorisation retenue aux niveaux logique et physique, l’occupation en octets
 100

peut être très variable. De plus, selon certains systèmes, le choix du mode de représen-
tation informatique peut être un paramètre d’optimisation.

 Détermination du nombre d’occurrences des objets et des relations

Il est très important de déterminer le nombre maximum d’occurrences des entités et des
relations que l’on voudra avoir dans la future base pour constituer la mémoire immé-
diate du système d’information.
Pour le nombre maximum d’occurrences des entités, on pourra l’estimer à partir de l’ef-
fectif du chargement initial et de la fréquence de création de nouvelles occurrences. Par
 101

contre le nombre maximum d’occurrences des relations est quant à lui un peu plus dif-
ficile à déterminer compte tenu de la nature même des relations : des associations entre
objets. Dans la plupart des cas ce dénombrement s’effectuera à partir du nombre d’oc-
currence d’un objet de sa collection et de la quantification de la cardinalité de la patte.

 Calcul de la multiplicite et de volume theorique

calcul du volume utile du modele organisationnel des donnees global :

Volume utile = (∑ volume objet + ∑ volume relations) x

coefficient de sécurité

Avec :
 Volume objet = taille de l’objet (To) x nombre maximum d’occurrences de l’objet (No)
 Volume relation = taille de la relation (Tr) x nombre maximum d’occurrences de la rela-
tion (Nr)
 Coefficient de sécurité variant entre 1,5 et 3 selon les technologies.

 calcul du volume des objets

 calcul du volume des relations

Volume relation = taille de la relation (Tr) x nombre maximum d’occurrences de la relation
(Nr).
 102

 calcul du volume utile

La sommation des volumes des objets (1) et celle des volumes des relations (2) étant
dégagés, nous pouvons maintenant calculer sans difficulté le volume utile du MOD
global :
Volume utile = (∑ volume objet + ∑ volume relations) x coefficient de sécurité
= ((1) + (2)) x coefficient de sécurité
= (2 763 000+ 140 000) x 3
= 8709000 octets
=8505 Ko
=8 Mo

 La repartition des donnees informatisees en unites organisationnelles et la prise en

compte de leur securite
Répartition des données informatisées en unités organisationnelles
Nous ferons cette répartition en fonction de notre processus(Planning). Nous rappelons
les entités et relations les constituants sur l’ébauche du MOD global suivant :
La connaissance de la répartition organisationnelle des données présente un intérêt cer-
tain pour orienter ultérieurement la répartition informatique des données, en particulier
dans des environnements clients/serveurs.
L’unité organisationnelle recouvre généralement un ensemble de postes représentant
par exemple un service ou un site géographique. Les utilisateurs d’une unité organisa-
tionnelle ont une vue commune et partagée d’un ensemble de données : le MOD local.
Le MOD local et l’unité organisationnelle sont donc un moyen d’exprimer, du point de
vue de l’utilisateur, les données accessibles par un ensemble de postes. Le MOD local est
un sous-ensemble du MOD global en termes :
• D’entités types, de relation types et de propriétés,
• D’occurrence d’entités ou de relation. Par exemple, une agence (unité organisa-
tionnelle) ne gère que les contrats de son secteur.

 La prise en compte de l’accessibilite aux donneeset de la securite

L’accessibilité des données d’un MOD local s’exprime par les actions élémentaires que
peuvent effectuer sur ce sous-ensemble de données les traitements réalisés dans le site
 103

organisationnel. Ces différents types d’accès, en lecture (L), en modification (M), en créa-
tion (C) et en suppression (S), sont précisés sur le MOD.
La sécurité des données définit des restrictions d’accès aux données mémorisées pour
certaines catégories d’utilisateurs.
Ces restrictions peuvent avoir un type limité d’actions (L, M, C, S) soit aux entités, relations
ou propriétés du MOD global ou local, soit à une sous-population des occurrences d’en-
tités ou des relations. La sécurité d’accès comprend la limitation d’actions à certaines
personnes et intègre aussi les aspects de confidentialité.
La sécurité d’accès passe par la définition de catégories ou de profils d’utilisateurs. Pour
chaque profil, on précise les éventuelles restrictions d’accès envisagées.
L’application de la répartition des informations informatisées en unités organisation-
nelles ainsi que leurs accessibilités et sécurités à notre cas d’étude se trouve présentée
sur le schéma suivant :
 104

2.7.2. Le modèle organisationel des traitements

II complète la description conceptuelle des traitements en intégrant tout ce qui est

d'ordre organisationnel dans le domaine étudié.
Le Modèle Organisationnel des Traitements précise :
1. Qui exécute les traitements ;
2. La nature des traitements ;
Le traitement peut être :
 Manuels ;
 Automatiques ;
 Semi-automatiques.
3. Les lieux où sont exécutés les traitements (poste de t ravail, serveur...) ;
4. Quand sont exécutés les traitements (notion de temporalité).
Le Modèle Organisationnel des Traitements est basé sur trois concepts principaux :
1. L'événement ;
2. La phase ou procédure ;
3. Le résultat.
II existe plusieurs représentations ou formalismes du Modèle Organisationnel des Trai-
tements en voici un exemple :
 105

2.7.2.1. Conception d'un modèle organisationnel des traitements pas à pas

Pour avoir une vue d'ensemble de la méthodologie du traitement des données, nous al-
lons dérouler un cas complet.
Dans l'entreprise Pescie 2000 spécialisée dans la publication de petites annonces,
les clients envoient de façon manuscrite le contenu de leur petite annonce recopié
sur une grille découpée dans le journal.
Dès que la petite annonce est arrivée au service secrétariat, un employé vérifie que l'an-
nonce est lisible et correctement exploitable. Dans le cas où l'annonce est illisible, elle
est retournée au client avec une lettre type annonçant que l'annonce est illisible.
Dans le cas où l'annonce est exploitable, elle est passée au service commercial qui véri-
fie la validité du montant dû et ensuite saisit et enregistre l'annonce. Une confirmation
de parution est ensuite envoyée au client.

1. Le diagramme des flux (ou modèle conceptuel de communication)

2. Le Modèle Conceptuel des Traitements

 106

3. Le Modèle Organisationnel des Traitements

 107

Le traitement manuel d’une opération indique une intervention humaine a contrario

du type automatique qui lui indique une séquence automatisée ou informatisée.

Conclusion
Le Modèle Organisationnel des Traitements permet d'avoir une vision claire et précise du
déroulement des opérations et de leurs traitements.
 108

CHAPITRE IV : CONCEPTION DU SYSTEME D’INFORMATION IN-

FORMATISE (ETUDES TECHNIQUES)

Le passage du système d’information organisationnel au système d’information informa-

tisé, c’est le passage des solutions d’organisation à des solutions informatiques. A ce
stade, l’analyse prendra en compte les aspects techniques du système d’information à
mettre en place. Il sera question aussi de définir le scenario de mise en œuvre et de
développement du nouveau système.
Ainsi, dans cette partie nous avons deux niveaux à présenter :
 Le niveau logique ; et
 Le niveau physique.
Les connaissances informatiques doivent trouver leur place, car c’est une étape informa-
tique qui exige la technicité dans ce domaine.

4.1. Modèle logique

Le niveau logique concerne la conception du logiciel correspondant aux parties
à automatiser du système. II prend en compte l'état de l’art technique général
plutôt que les aspects physiques dans un contexte particulier. II inclue une
description logique des données c'est à dire une description dans un formalisme
compatible avec l’état de l’art (modèle relationnel, modèle objet, fichiers, etc) mais
encore portable par rapport à des choix techniques précis. II inclue également
des modèles logiques de traitements décrivant le guidage fonctionnel, les boites
de dialogue, l'arborescence des fenêtres.
Le niveau logique vise deux objectifs, à savoir : la définition des caractéristiques de la
base des données à mettre en place, à travers le modèle logique des données (MLD) et
la détermination de la logique de traitement, matérialisée par le modèle logique de trai-
tement (MLT).

4.1.1. Modèle logique des données (MLD)

Le Modèle Logique des Données (MLD) est la suite normale du processus Merise. Son
but est de nous rapprocher au plus près du modèle physique. Pour cela, nous partons
du Modèle Organisationnel des Données et nous lui enlevons les relations, mais pas
 109

n'importe comment, il faut en effet respecter certaines règles. Voici la procédure à

suivre.
Pour l’obtention des tables présentant le plus de cohérence possible (éviter les redon-
dances et les valeurs nulles) dans leurs exploitations, il existe deux grands procédés pré-
conisés par la structure relationnelle de stockage de données :
Le processus de normalisation qui est une décomposition d’une table universelle de dé-
part en plusieurs tables par des projections définies judicieusement en fonction des dé-
pendances fonctionnelles entre attributs. Ce processus et totalement réversible et pos-
sède cinq formes normales dont les trois premières suffisent pour obtenir des tables ca-
noniques.
L’application des règles de transformation du formalisme entité-relation en formalisme
relationnel sur le MOD pour en dériver un MLD. Cette transformation est entièrement
algorithmique mais n’est pas totalement réversible. Le modèle ainsi obtenu est obliga-
toirement en deuxième forme normale du premier procédé mais pas nécessairement en
sa troisième forme. Bien que ce procédé soit privilégié par la méthode MERISE, il con-
viendra, en toute rigueur, de vérifier si les tables issues des entités sont en troisième
forme normale.
Puisque nous utilisons la méthode MERISE, nous appliquons en ce point le second pro-
cédé dont l’algorithme se présente comme suit :

4.1.1.1. Les règles de passage du MOD au MLD brut

A. Les entités

 Les objets deviennent des tables dans le sens mathématique du terme.

 Les propriétés des objets deviennent leurs attributs
 Les identifiants deviennent des clés primaires des tables

Cas (0, n), (1,1) ou (l, n), (0, l)

Les relations du type « père - fils » de cardinalité (0, n – 0,1) ou (1, n – 1,1) :
Elles disparaissent, Le père envoie sa clé au fils qui le pointe et, celle-ci devient une clé
étrangère, Si la relation possédait des attributs, ceux-ci émigrent dans la table « fils ».
Voici un modèle conceptuel de départ :
 110

Nous devons supprimer la relation Elever, cela se réalise de façon tout à fait méca-
nique. L'entité ayant la cardinalité de type 1,1 ou 0,1 absorbe l'identifiant de l'entité
la plus forte (0, n ou 1, n). Cet identifiant est alors appelé la clé étrangère.
Voici le Modèle Logique des Données découlant du Modèle conceptuel précédent
:

Cas (0, n), (0, n) ou (l, n), (l, n)

Les relations du type autre que « père - fils » :
Elles se transforment en tables dont la clé est une concaténation des clés des tables par-
ticipant à la relation, La table ainsi créée pointe les tables d’où elle tire ses clés, Si la rela-
tion portait des propriétés, celles-ci deviennent ses attributs.
Illustrons ce cas sur le Modèle Conceptuel des Données suivant :

Dans le cas où la cardinalité maximale est n de chaque côté de la relation, celle- ci se

transforme en entité et absorbe les identifiants de chaque entité reliée. Les identi-
fiants ainsi absorbés forment la nouvelle clé de l'entité. Cette nouvelle clé est donc for-
mée par la concaténation des clés étrangères des entités reliées.
 111

Voici la représentation virtuelle des fichiers de données :

Remarque
La concaténation des deux clés étrangères doit être unique. Les couples de clés sont
donc (I, I), (2,2), (2,3). Nous arrivons donc à la conclusion suivante : le client 1 qui adore le
Téléphone ne pourra pas en acheter plusieurs fois. Cette situation est anormale, je vous
rappelle que « qui peut le plus peut le moins ».
Continuons à modifier le Modèle Conceptuel des Données.

Le Modèle Logique des Données en découlant sera :

 112

La nouvelle représentation du fichier commande est maintenant ainsi :

Nous avons apporté une solution à notre problème initial. Cependant, le même client ne
pourra pas acheter deux fois le même sac de riz le même jour. Une solution élégante serait de
concaténer la date et l'heure d'achat.

Cas particuliers :
 0,1 – 1,1 et 1,1 – 0,1 : considérer l’objet ayant 0,1 pour cardinalité comme objet
père et appliquer la règle pour les relations du type « père – fils » ;
 0,1 – 0,1 : faire le choix entre les deux objets pour désigner l’objet père et appliquer
la règle pour les relations du type « père – fils »
 Pour des relations d’une dimension supérieure à deux, quelles que soient les cardi-
nalités, elles se transforment en tables dont la clé est une concaténation des clés
appartenant à toutes les tables participant à la relation. Si la relation porte une pro-
priété, celle-ci devient un attribut.

B. Modèle Logique des Données sur une relation réflexive

Reprenons ce Modèle Conceptuel des Données :
Les règles de passage du MCD au MLD s'appliquent toujours aussi mécaniquement.
L'entité ayant la cardinalité la plus faible absorbe l'identifiant de l'entité reliée. Ici, nous
n'avons qu'une seule entité, mais le principe est le même nous devons donc dupliquer
l'identifiant Numéro employé.
 113

EMPLOYES

#Numéro_Employé
Nom
Prénom
Adresse
Code_Postal
Ville
Telephone
#Numéro_Employé

Regardons la représentation du fichier de données.

Nous observons bien que les employés sont dirigés par l'employé numéro 2.

Conception d'un modèle logique des données pas à pas

Appliquons ces règles au modèle conceptuel du chapitre précédent :
 114

Reprenons au cas par cas et commençons par cet extrait du Modèle Conceptuel
des Données :
 115

Voici la traduction en Modèle Logique des Données

Voici la traduction en Modèle Logique des Données

Comme nous pouvons le constater, une nouvelle entité (Possède) est apparue. Cette
entité contient trois propriétés, dont deux clés étrangères. Le nouvel identifiant de
cette entité sera la concaténation des deux clés étrangères.

Ici, nous pouvons voir que la cardinalité (1,1) va nous indiquer l'entité qui va recevoir
la clé étrangère.

La propriété NumType va devenir clé étrangère dans l'entité Carte des Plats.
 116

Cette partie de MCD n'est pas complexe à transposer en MLD

Continuons le processus :

Ici, nous traitons le cas des identifiants relatifs :

 117

La nouvelle identifiant de l’entité bouteilles sera la concaténation de trois clés :

1. NumBouteille ;
2. #NumVin ;
3. #NumViticulteur.
Voici le modèle logique de données brut :
 118

Comme vous l'avez ressenti, le passage du modèle conceptuel ou de modèle organi-

sationnel au Modèle Logique des Données est purement mécanique, il suffit de
respecter les quelques règles énoncées plus haut. Il n'y a plus de travail de conceptuali-
sation ou de réflexion proprement dit. Lorsque nous réalisons un Modèle Logique des
Données nous ne faisons que « détruire » un Modèle Conceptuel ou organisationnel
 119

des Données pour recréer un autre modèle. Le modèle ainsi crée s’appelle modèle lo-
gique de données brut. Pourquoi brut parce qu’il contient encore de la redondance.
D’où la nécessité de recourir à la normalisation. Nous ne pouvons pas supprimer la re-
dondance à 100% dans un modèle relationnel mais il faut garder une redondance
qu’appelle la redondance calculée.

4.1.1.2. Les formes normales

Introduction aux formes normales
Pour être parfaites, les relations doivent respecter certaines règles. Cet ensemble de
règles se nomme : les formes normales.
Cette théorie a été élaborée par E.F. Codd en 1970. Son objectif est d'éviter les anoma-
lies dans les bases de données relationnelles :
1. Problèmes de mise à jour ;
2. Suppression des redondances d'informations ;
3. Simplification de certaines contraintes d'intégrité.
Pour parfaire une base de données relationnelle, il est nécessaire de connaître les trois
premières formes normales et la forme normale dite Boyce-Codd ; les suivantes ne sont
que des extensions peu usitées.
a) Première forme normale (1FN)
Une relation est en première forme normale si :
1. Tous les attributs ne contiennent qu'une seule valeur atomique (non divisible) ;
2. Les attributs ne contiennent pas de valeurs répétitives.
Exemple :
Clients (NumCli, Nom, Prénom, Adresse, Téléphone)
Cette relation n'est pas en première forme normale, car Adresse n'est pas ato-
mique. En effet voici une représentation d'un fichier ainsi décrit :

Cette représentation si elle était mise en pratique générerait un accès aux données
plus lent. Le simple fait de vouloir extraire les habitants d'une ville précise devra mettre
 120

en œuvre des procédures d'extraction de sous - chaînes sans fournir de garantie quant
au résultat retourné.
Voici une représentation 1FN correcte :
Clients (NumCli. Nom, Prénom, Adresse. CodeP, Ville, Téléphone)

Maintenant, récupérer les habitants d'une ville précise ne pose plus aucun pro-
blème, une simple requête SQL y parviendra de façon rapide et fiable.
b) Deuxième forme normale (2FN)
Une relation est en deuxième forme normale si :
1. Elle est en première forme normale ;
2. Si tous les attributs non-clés ne dépendent pas d'une partie de la clé primaire.
Autrement dit, toute propriété de la relation doit dépendre intégralement de toute la
clé.
Par exemple :
Commande ("Numcli, CodeArticle, Date, Qté commandée, Désignation) Cette relation
est-elle en première forme normale ? Oui.
Est-elle en deuxième forme normale ? Non, car la propriété Désignation ne dépend
pas intégralement de la clé (Numcli, CodeArticle, Date).
Commandes :

Connaissant {l,Artl,28/02/2016} pouvons-nous connaître de façon sûre et unique «

Téléphone samsung J7» ? La réponse est évidemment non ! Téléphone samsung J7
» ne dépend pas intégralement de la clé
{l,Artl,28/02/2016}. Voici comment corriger :
Commandes (Numcli, CodeArticle, Date, Qté commandée) Articles
 121

(CodeArticle, Désignation)

Articles

c) Troisième forme normale (3FN)

Une relation est en troisième forme normale si :
1. Elle est en deuxième forme normale ;
2. Si toutes les dépendances fonctionnelles par rapport à la clé sont directes (s'il n'y a
pas de DF transitives entre les attributs non clé).
Autrement dit, tous les attributs n'appartenant pas à la clé ne dépendent pas d'un at-
tribut non-clé.
Exemple :
La relation Commande (NuméroCommande. #CodeClient, NomClient, #RefClient) est-
elle en troisième forme normale ?
Est-elle en première forme normale ? Oui
Est-elle en deuxième forme normale ? Oui
Est-elle en troisième forme normale ? Non
En effet Nom client dépend d'une propriété non clé : CodeClient
Commandes :

Voici comment corriger :

Commande (NuméroCommande, #CodeClient, #RefArticle)
Clients (CodeClient, Nom client)
 122

Commandes :

Clients :

d) Forme normale de Boyce - Codd (BCNF)

Une relation est en forme normale de BOYCE-CODD (BCNF) si et seulement si :
1. Elle est en troisième forme normale ;
2. les seules dépendances fonctionnelles élémentaires qu'elle comporte sont
celles dans lesquelles une clé détermine un attribut.
Considérons la relation Vaches (Race, Pays. Région) avec les dépendances fonc-
tionnelles supposées :
Région―Pays
(Race. Pays) ―Région

Cette relation est bien en troisième forme normale car aucun attribut non clé ne dé-
pend d'une partie de la clé ou d'un attribut non clé. Cependant, on y trouve de nom-
breuses redondances, par exemple les deux premières lignes possèdent des pays et des
régions identiques.
Afin d'éliminer ces redondances. Boyce et Codd ont introduit une forme normale qui
porte leur nom (Boyce Codd Normal Form/BCNF) :
Une relation est en BCNF si et seulement si les seules dépendances fonctionnelles élé-
mentaires sont celles dans lesquelles une clé détermine un attribut.
 123

La relation Vaches pourra être décomposée en deux relations :

1. Races (Race, Région) ;
2. Régions (Région, Pays).

La dépendance fonctionnelle (Race, Pays) ―Région est perdue, mais elle peut être
recomposée par jointure.
Cette normalisation est très importante dans la pratique si l'on veut éviter de stocker
des informations redondantes. On considère, en général, que la troisième forme nor-
male est suffisante dans les cas courants.

e) Quatrième forme normale (4FN)

Une relation est en quatrième forme normale si et seulement si :
1. Elle est en BCNF ;
2. Lorsqu’il existe u n e d é p e n d a n c e m u lti valu ée élémentaire, ce l le -ci est unique.
Une relation en BCNF peut encore comporter des redondances.
Par exemple :
L'étudiant (NumEtu) pratique une ou plusieurs langues et suit un ou plusieurs cours.
Imaginons cette relation :
Etudiants (NumEtu, Langue, Cours) Et les postulats suivants :
II n'y a pas de dépendances fonctionnelles. La clé est : (NumEtu, Langue, Cours).
La relation Etudiants est en troisième forme normale et en troisième forme normale
Boyce Codd.
Cependant Etudiants contient encore des redondances :

L'étudiant numéro 1 ne connaît que l'anglais, mais suit 2 cours (les mathématiques et
l'histoire). Il y a donc une redondance sur la langue.
L'étudiant numéro 2 connaît deux langues (l'anglais et l'espagnol) mais ne suit qu'un
cours. Il y a redondance sur le cours.
 124

Les dépendances fonctionnelles ne suffisent pas à définir toutes les dépendances

entre les données.
Dépendances multivaluées
Pour une valeur d'étudiant, on a toutes les valeurs possibles de langue et, pour chacune
de ces valeurs, toutes les valeurs possibles de cours, mais langue et cours sont indé-
pendantes entre elles : on dit que l'on a une dépendance multivaluée entre la colonne
NumEtu et la colonne Langue et une dépendance multivaluée entre la colonne Nu-
mEtu et la colonne Cours.
On voit l'inconvénient de cette forme puisque, si l'on supprime une valeur possible
de la colonne Cours, par exemple l'organisme de formation retire l'économie de son
catalogue, il faut supprimer toutes les lignes où économie est inscrit.
Pour éviter ce genre de problèmes, il faut passer à la quatrième forme normale, qui se
peut se définir ainsi :
Une relation est en quatrième forme normale si et seulement si les seules dépendances
multivaluées élémentaires sont celles dans lesquelles une clé détermine la valeur d'une
colonne.
Ici, les colonnes sur lesquelles portent des dépendances multivaluées font partie de la
clé, donc la table n'est pas en 4FN et il faut la décomposer en deux tables :
1. Etudiants1 (NumEtu, Langue) ;
2. Etudiant2 (NumEtu, Cours) ;
2. Etudiant2 (NumEtu, Cours).

f) Cinquième forme normale (5FN)

Cette forme normale n'étant quasiment jamais utilisée, en voici juste la définition :
Une association est en cinquième forme normale si et seulement si :
1. Elle est en quatrième forme normale ;
2. Elle ne possède pas de dépendance de jointure.
La cinquième forme normale est une généralisation de la quatrième forme normale qui
nécessite de prendre en compte les dépendances de jointure induites par la connais-
sance des clés d'une relation.
L'étude des formes normales permet d'éviter certains pièges de conception risquant
d'impacter la future base de données. Il est donc important que durant le processus
 125

de modélisation, un instant soit pris pour vérifier qu'il n'y a pas d'incohérences fonction-
nelles. L’application des formes normales sur le modèle logique de données brut nous
permet d’obtenir un modèle loque de données valide.

Schéma relationnel associé

Le schéma relationnel associé permet de décrire les attributs des différentes tables qui
constituent notre modèle relationnel. Cette description doit comprendre les éléments ci-
après :
 Nom de l’attribut ;
 Format de données ;
 La taille de chaque attribut à placer entre parenthèse.

Exemple d’un schéma relationnel associé

 126

4.1.2. Modèle logique des traitements (MLT)

Le modèle logique de traitement se préoccupe d’une vision interne des moyens que
l’informaticien va utiliser pour construire le logiciel correspondant aux activités informa-
tisées définit dans le MOT.
Nous allons parler d’enchaînement de transaction découpage en module des réparti-
tions des données et traitement automatise. Ce modèle logique de traitement MLT doit
spécifier avec rigueur et en détail des contenues des traitements informatisés associés à
chaque tache organisationnelle.
En résume la problématique de la modélisation logique du traitement renseigne du
comment informatiser les activités présentées dans la modélisation organisationnelle de
traitement ; phase, taches.

Vocabulaire spécifique utilisé

Le passage du MOT au MLT est le passage d’un traitement manuel à un traitement auto-
matique. Il est donc normal qu’il entraîne aussi un changement de vocabulaire. C’est
ainsi que :
- Les opérations deviennent des unités logiques de traitement (ULT) ;
- Les procédures fonctionnelles ou organisationnelles deviennent des procédures
logiques ;
- Les postes de travail deviennent des sites logiques.

Règles de passage du MOT au MLT

Ce passage exige beaucoup de réflexion, d’imagination et de créativité de la part du
concepteur. Sa tâche peut cependant être facilitée en procédant méthodiquement
comme suit :
- Identifier d’abord les différentes ULT informatisables à partir du MOT. Les ULT cons-
titueront plus tard l’ensemble d’instructions exécutables ;
- Construire ensuite le MLT formé de l’ensemble des procédures logiques ou ULT, avec
un début et une fin.
Construire enfin les procédures logiques correspondant à chaque ULT ou domaine ;
chaque ULT reposant sur une maquette d’écran ou des boîtes de dialogue, c’est-à-dire
sur des interfaces.
 127

Remarque :
Il n’existe pas un formalisme standard à utiliser pour le modèle loque de traitement. Il est
conseillé à l’informaticien d’user de son expertise pour une bonne représentation.
Exemple de MLT pour la réservation de chambre
Procédure logique d’accueil
 128

 Procédure logique de réservation

129
130
131
132
 133

4.2. Modèle physique

Le niveau physique constitue la porte de sortie de la méthode merise, il tient compte des
préoccupations et de choix techniques nécessaires à l’implantation physique des don-
nées et à la mise en place des traitements : langage de programmation, choix du SGBD,
taille mémoire…
Le niveau physique est subdivisé en deux partie :
- Modèle physique de donnée (MPD) ; et
- Modèle physique de traitement (MPT).

4.2.1. Modèle physique des données (MPD)

Construire Le Modèle Physique des Données consiste à transformer le Modèle Logique
des Données en une suite de relations. Cette étape finalise le processus de traitement
des données. L'implémentation des bases de données peut être réalisée de façon opti-
male.
Comme exemple nous pouvons partir du modèle logique des données valide de la page
suivante :
 134

Voici l e schéma relationnel associé du modèle physique qui en découle :

 Diplômes (Diplômes)
 Possède (#NumEmployé, #Diplôme, Date d'obtention)
 Employés (NumEmployé, Nom, Prénom, Adresse, Code Postal, Ville, Téléphone)
 Tables (NumTable, Capacité)
 Date (Date)
 135

 Service (TypeService, Désignation)

 Boissons Diverses fNumBoissons, Désignation, Prix de vente)
 Contenir (#NumCommande, #NumBoissons, Quantité)
 Commande (NumCommande, #Numemployé, #Date, #TvpeService, #NumTable)
 Comprend (#NumMenu, #NumCommande, Quantité) Menus (NumMenu, Libellé, Prix
de vente) Constitué (#NumMenu, #NumPlat)
 Constituer (#NumCommande, #NumPlat, Quantité)
 Sélectionner (#NumCommande, #NumVin, Quantité)
 Carte des vins (NutnVin, Nom du vin, Millésime, Prix de vente)
 Carte des plats (NumPlat. LibelléPlat, Prix de vente, #NumType)
 Type des plats CNumTvpe, Désignation)
 Bouteilles (NumBouteille, Date Achat, Prix d'achat, # NumVin, #NumViti-
culteur)
 Viticulteur (NumViticulteur, Nom viticulteur, Prénom viticulteur, Adresse viti-
culteur, Code postal, Ville, Téléphone)
Comme vous le voyez, passer du modèle logique de données au modèle physique des
données ne présente aucune difficulté. On abandonne juste la représentation gra-
phique pour une représentation plus linéaire.

Transcription SQL du modèle physique

Par exemple, si nous devions porter notre modèle physique sur un Système de Gestion
de Base de Données (SGBD), il suffirait d'écrire les requêtes SQL de création de tables
correspondantes. En voici un exemple sur trois tables
CREATE TABLE CARTE_DES_VINS
(

NUMVIN INTEGER (2| NOT NULL, NOM_DU_VIN CHAR(40) MILLESIME INTEGER(2),

PRIX_DE_VENTE REAL(5,2)
PRIMARY KEY (NUMVIN) constraint pk_carte_des_vins
);

CREATE TABLE BOUTEILLES

(
 136

NUMVITICULTEUR INTEGER (2) NOT NULL, NUMVIN INTEGER(2) NOT NULL, NUMBOU-
TEILLE INTEGER(2) NOT NULL , DATE_ACHAT DATE(8) PRIX_D_ACHAT REAL(5,2)
PRIMARY KEY (NUMVITICULTEUR, NUMVIN, NUMBOUTEILLE) CONSTRAINT
PKBOUTEILLES
);
CREATE TABLE VITICULTEUR
(
NUMVITICULTEUR INTEGER(2) NOT NULL, NOMJVITICULTEUR CHAR(20)
PRÉNOM VITICULTEUR CHAR (20) ADRESSE_VITICULTEUR CHAR(40) CODE
POSTAL
CHAR (5) VILLE CHAR(40) TÉLÉPHONE CHAR(15)
PRIMARY KEY (NUMVITICULTEUR) CONSTRAINT PK VITICULTEUR
);

Nous pouvons remarquer l'expression de la clé primaire dans la table vin qui est la
concaténation des trois identifiants : NUMVITICULTEUR, NUMVIN, NUMBOUTEILLE.
Le Modèle Physique des Données est l'étape ultime dans le processus de gestion des
données de la méthode Merise. Toute l'analyse ayant été réalisée en amont, l'essentiel
du travail de réflexion ayant été encadré par le modèle conceptuel, le passage au mo-
dèle physique n'est qu'une simple formalité. Il peut être donné à un développeur pour
qu'il puisse créer la base de données correspondante sur un serveur de base de don-
nées quelconque.

4.2.2. Modèle physique des Traitements (MPT)

Le modèle physique des traitements représente la solution technique de la construction
du logiciel. C’est l’ensemble des programmes informatiques assurant l’exécution des trai-
tements informatisés du système d’information. Cet ensemble est organisé en une archi-
tecture technique de programmes matérialisant la logique des traitements spécifiée
dans le MLT, en fonction des possibilités techniques et des moyens de programmation.
Il faut reconnaître que la méthode MERISE n’a jamais eu l’ambition d’aborder de façon
détaillée cette modélisation physique des traitements. Aussi, aucun formalisme n’a
jusqu’à présent été proposé pour la spécification des programmes.
 137

Pour ce qui concerne le modèle physique des données, il est conseillé à l’informaticien
de présenter son la procédure d’utilisation de son logiciel sous forme d’une arbores-
cence ou en essayant de présenter tout simplement le menu principal de son applica-
tion.
 138

CHAPITRE V : ETUDE DES CAS AVEC PowerAMC

Repris sous le nom de SAP PowerDesigner, Power AMC est un puissant logiciel de con-
ception et de modélisation graphique de base de données destiné aux professionnels.
Power AMC vous permet de réaliser tous les types de modèles informatiques. C'est l'un
des seuls logiciels qui vous permet de travailler avec la méthode Merise qui est une mé-
thode d'analyse, de conception et de gestion de projet informatique adaptée pour gérer
des projets internes, dans un domaine bien précis.

5.1. Objectifs et prerequis

MERISE (Méthode d’Étude et de Réalisation Informatique pour les Systèmes d’Entreprise)

basée sur le modèle entité Association, est simple, efficace et utilisée par la majorité des
développeurs des applications informatiques ;

La méthode MERISE permet de décomposer les problèmes des systèmes d’informations

en données et traitements en trois niveaux :

 Conceptuel : (MCD, MCT) ;

 Logique : (MLD) ;
 Physique : (MPD).

PowerAMC est un environnement graphique de modélisation d'entreprise très simple

d'emploi qui permet d'effectuer les tâches suivantes :
o Modélisation intégrée via l'utilisation de méthodologies et de notation standard :
o Données (E/R, Merise)
o Application (UML)

o Génération automatique de code via des templates personnalisables :

o SQL (avec plus de 50 SGBD) ;

o Java ;
o .NET
 139

5.2. Les modèles MERISE et les modèles PowerAMC

1. Les modèles MERISE

On peut estimer la part de temps consacré à chacun des niveaux :

o Étude de l’existant : 50% ;

o MCD + MCT et MOT : 25% ;
o Validation et MLD : 10% ;
o MPD et MOpT : 15%.
2. Les modèles PowerAMC
 140

5.3. L’interface graphique de PowerAMC

5.3.1. Démarrage de PowerAMC

- Cliquez sur l'icône de programme de PowerAMC. La fenêtre principale de Po-

werAMC s'affiche avec la fenêtre Explorateur d'objets ancrée à gauche et la fe-
nêtre Résultats ancrée en bas
 141

La fenêtre d’Explorateur d'objets affiche le contenu de l'espace de travail sous forme

d'arborescence. Vous pouvez utiliser l'Explorateur d'objets pour organiser les objets con-
tenus dans chacun de vos modèles. L'espace de travail est le nom de la session courante
de PowerAMC. Espace de travail est également le noeud par défaut dans l'arborescence
de l'Explorateur d’objets. Le nouveau MCD que vous allez ouvrir sera créé et enregistré
dans un espace de travail. La fenêtre Résultats affiche la progression des processus exé-
cutés au sein de PowerAMC, par exemple la génération d'un MPD à partir d'un MCD.

I5.3.2. Création d'un nouveau MCD

- Sélectionnez Fichier-->Nouveau dans la barre de menus. La boîte de dialogue

Nouveau s'affiche. Elle contient la liste des types de modèle que vous pouvez
créer dans PowerAMC ;
- Sélectionnez Modèle Conceptuel de Données dans la liste Type de modèle ;
- Sélectionnez le bouton radio Nouveau modèle dans la partie supérieure droite
de la boîte de dialogue ;
 142

- Cliquez sur OK. Une fenêtre de modèle s'affiche. Elle contient une fenêtre de dia-
gramme (vide), une palette ainsi que les fenêtres Explorateur d'objets et Résultats
respectivement ancrées à gauche et en bas de la fenêtre principale.

5.3.3. Utilisation des outils de la palette

Les outils de la palette de MCD permettent de commander les principales fonctionnalités

nécessaires pour construire et modifier un MCD.
 143

Vous allez apprendre comment utiliser les outils en créant plusieurs objets dans le MCD
à l'aide de la palette :
 144

• Cliquez sur l'outil Entité dans la palette. Le curseur prend la forme d'une entité lorsque
vous le déplacez dans l'espace de travail du MCD ;
• Cliquez sur un emplacement vide dans l'espace de travail du MCD. Un symbole d'en-
tité s'affiche à l'endroit où vous avez cliqué. L'entité porte le nom par défaut Entité_n, où
n est un numéro affecté à l'entité dans l'ordre de création des objets

 L'outil Entité est toujours activé, cliquez à nouveau dans le diagramme du MCD
pour créer une autre entité. Deux entités figurent dans l'espace de travail le dia-
gramme du MCD.
 Cliquez sur l'outil Lien dans la palette. L'outil Entité est libéré et l'outil Lien est ac-
tivé.
 Cliquez sur la première entité et maintenez le bouton gauche de la souris enfoncé
et faites glisser le curseur sur la seconde entité. Relâchez le bouton de la souris
dans la seconde entité. Vous avez créé une association entre les deux entités.

 Cliquez le bouton droit de la souris. Vous libérez ainsi l'outil Association et activez
l'outil Pointeur. Libération d'un outil :Un outil reste actif jusqu'à ce que vous le
libériez. Vous pouvez libérer un outil en sélectionnant un autre outil, ou bien en
cliquant le bouton droit de la souris. Lorsque vous cliquez le bouton droit de la
souris, l'outil Pointeur est activé par défaut.
 Pointez le curseur au dessus de l'un des coins de la première entité et maintenez
le bouton gauche de la souris enfoncé. Faites glisser le curseur afin de tracer un
rectangle autour des deux entités. Relâchez le bouton de la souris.
Les entités et l'association sont sélectionnées. Des poignées s'affichent autour de la sé-
lection pour montrer les objets sélectionnés.
• Faites glisser les symboles à un nouvel emplacement.
• Cliquez sur l'outil Texte dans la palette. L'outil Texte est à présent actif.
 145

• Positionnez le curseur au-dessous de l'association. Un texte s'affiche dans la zone défi-

nie par le rectangle.
• Cliquez le bouton droit de la souris. Vous libérez ainsi l'outil Texte.
• Double-cliquez sur le texte. Une zone de texte s'affiche.
• Saisissez un texte court dans la zone de texte.
• Cliquez sur OK. Le texte s'affiche dans le diagramme. Il est encadré par des poignées.

Pointez sur l'une des poignées située dans la partie droite du texte jusqu'à ce que le texte
soit entièrement visible. Relâchez le bouton de la souris. Cliquez sur un emplacement
vide dans le diagramme. Les poignées situées autour du texte disparaissent.

Cliquez sur l'outil Pointeur dans la palette. Vous allez utiliser cet outil pour sélectionner
et supprimer l'un des symboles.
• Cliquez sur l'un des symboles d'entité. L'objet à supprimer est alors sélectionné.
• Appuyez sur la touche SUPPR. La boîte de dialogue Confirmation de suppression s'af-
fiche. Cette boîte de confirmation vous demande si vous souhaitez supprimer la sélec-
tion.

Suppression d'objets
 146

Si vous sélectionnez Supprimer les objets, vous effacez le symbole graphique et suppri-
mez l'objet dans le modèle. En revanche, si vous sélectionnez Supprimer les symboles
seulement, vous effacez le symbole graphique, mais conservez l'objet dans le modèle.
Boîte de confirmation de suppression non visible Si cette boîte ne s'affiche pas lorsque
vous souhaitez supprimer un objet, sélectionnez Outils-->Options générales dans la
barre de menus puis cochez la case Confirmer la suppression des objets.
• Cliquez sur OK. L'entité disparaît du diagramme et est aussi supprimée dans le modèle.
• Cliquez sur l'outil Rectangle de sélection dans la palette. L'outil Rectangle de sélection
est activé.
• Tracez un rectangle autour des objets restants et du texte. Relâchez le bouton de la
souris. Les objets et le texte sont sélectionnés.
• Appuyez sur la touche SUPPR, puis cliquez sur OK dans la boîte de dialogue de confir-
mation. Les objets restants et le texte sont supprimés.

5.3.4. Définition des préférences et des options de MCD

Avant de pouvoir commencer à travailler, vous allez définir certaines préférences d'affi-
chage et options de modèle relatives au MCD. Pour plus d'informations sur les préfé-
rences et options du MCD, reportez-vous au manuel PowerAMC - Guide des fonctionna-
lités générales.
• Sélectionnez Outils-->Préférences d'affichage dans la barre de menus. La boîte de dia-
logue Préférences d'affichage s'affiche à la page Général.
• Cliquez sur le noeud Objets dans l'arborescence Catégorie. La page Objets s'affiche.
• Sélectionnez les options suivantes. Les autres options doivent être désélectionnées.

Pour chaque symbole d'entité, tous les attributs d'entité et tous les attributs des identi-
fiants primaires sont affichés.
• Cliquez sur le bouton Définir comme défaut. Définit comme défaut Lorsque vous cli-
quez sur le bouton Définir comme défaut, vous appliquez les préférences d'affichage au
 147

diagramme actuel dans le modèle et à tous les diagrammes de même type que vous
créerez par la suite.
• Cliquez sur le noeud Lien d'association situé sous le noeud Objets dans l'arborescence
Catégorie. La page Lien d'association s'affiche. • Sélectionnez les options suivantes. Les
autres options doivent être désélectionnées

Pour chaque symbole de lien, le rôle du lien est affiché.

• Cliquez sur le bouton Définir comme défaut.
• Cliquez sur le noeud Format dans l'arborescence Catégorie. La page Format s'affiche.
• Cliquez sur le bouton Modifier situé en bas à droite de la page. La page Format de
symbole s'affiche.
• Assurez-vous que la case Ajuster au texte est cochée (valeur par défaut) dans la page
Taille.
• Cliquez sur OK dans chaque boîte de dialogue. Vous revenez à la fenêtre principale
de PowerAMC.
• Sélectionnez Outils-->Options du modèle dans la barre de menus. La boîte de dialogue
Options du modèle s'affiche. Le noeud Paramètres du modèle est sélectionné par défaut
dans l'arborescence Catégorie.
• Sélectionnez les options suivantes. Les autres options doivent être désélectionnées.

Divergences au niveau des domaines

Lorsque vous Cochez la case Type de données sans cocher la case Imposer la cohérence,
vous permettez la divergence entre la définition d'un domaine et les informations qui lui
sont associées. Toutefois, lorsque de telles divergences se produisent, PowerAMC vous
propose de mettre à jour le type de données dans toutes les informations auxquelles ce
domaine est appliqué.
 148

• Cliquez sur le noeud Conventions de dénomination. La page Conventions de déno-

mination s'affiche.
• Sélectionnez le bouton radio Nom sur la droite de l'option Afficher. Les noms d'objets
s'affichent dans les symboles d'objets dans le diagramme du MCD. • Cliquez sur OK

5.3.5. Définition des propriétés de MCD

Sélectionnez Modèle-->Propriétés du modèle dans la barre de menus. La feuille de pro-

priétés du modèle s'affiche.
• Saisissez Didacticiel dans la zone Nom. Il s'agit du nouveau nom du MCD. Le code
Didacticiel s'affiche automatiquement dans la zone Code.

• Cliquez sur Appliquer. Réutilisation du nom comme code Lorsque vous saisissez un
nom dans une feuille de propriétés d'objet, vous pouvez être amené à spécifier égale-
ment le code si l'option Réutilisation du nom comme code n'a pas été activée. Si tel est
le cas, vous pouvez activer cette option dans la boîte de dialogue Propriétés générales
(sélectionnez Outils-->Options générales-->Dialogue dans la barre de menus).
• Cliquez sur OK.

5.3.6. Création d'une règle de gestion

Vous allez créer une règle de gestion qui définit les modalités de répartition des droits
entre les auteurs.
 149

• Sélectionnez Modèle-->Règles de gestion dans la barre de menus. La boîte de dialogue

Liste des règles de gestion affiche les règles existantes.
• Cliquez sur l'outil Ajouter une ligne

Une flèche apparaît au début de la première ligne vide. Un nom et un code de règle de
gestion s'affichent par défaut. Nom et code par défaut Lorsque vous créez un nouvel
élément dans une liste, un nom et un code s'affichent automatiquement par défaut. Si
vous souhaitez attribuer un autre nom à l'élément, sélectionnez le nom par défaut, et
saisissez le nouveau nom. Le nom par défaut disparaît lorsque vous commencez à saisir
le nom de l'élément.

• Saisissez Pourcentage auteur dans la colonne Nom. Il s'agit du nom de la règle de

gestion. Un code identique au nom s'affiche automatiquement dans la colonne Code.
• Sélectionnez Validation dans la liste déroulante de la colonne Type de règle. Vous
définissez ainsi la règle de gestion comme règle de validation. En-tête de colonne non
visible Si un en-tête de colonne n'est pas visible dans la liste, cliquez sur l'outil Personna-
liser les colonnes et filtrer dans la barre d'outils. Une boîte de sélection répertoriant
toutes les colonnes disponibles pour la liste s'affiche. Cochez la case correspondant à la
colonne que vous souhaitez afficher et cliquez sur OK. La colonne s'affiche dans la liste.
• Cliquez sur le bouton Appliquer situé dans la partie inférieure de la boîte de dialogue.
 150

La création de la nouvelle règle de gestion est validée. Tri par ordre alphabétique Lors-
que vous cliquez sur le bouton Appliquer ou que vous fermez la liste des règles de ges-
tion, les règles de gestion sont triées par ordre alphabétique et non plus par ordre de
création.
• Cliquez sur la nouvelle règle de gestion. Une flèche s'affiche au début de la ligne.
• Cliquez sur l'outil Propriétés.

ou
Double-cliquez sur la flèche au début de la ligne. La feuille de propriétés de la nouvelle
règle de gestion s'affiche.

• Cliquez sur l'onglet Notes. La page Notes s'affiche et fait apparaître la zone Description.
• Saisissez La somme des pourcentages de droits versés à chacun des auteurs doit être
égale à 100% des droits d'auteur dans la zone Description.
Ce texte décrit la règle de gestion.
 151

• Cliquez sur OK dans les boîtes de dialogue successives. Vous validez ainsi la création
de la règle de gestion.

5.3.7. Création d'un domaine

Vous allez créer deux domaines qui définissent un type de données standardisé pour les
sommes d'argent et les pourcentages dans le domaine.
• Sélectionnez Modèle-->Domaines dans la barre de menus. La boîte de dialogue Liste
des domaines affiche les domaines existants.
• Cliquez sur l'outil Ajouter une ligne.

Une flèche apparaît au début de la première ligne vide. Un nom et un code de domaine
s'affichent par défaut.
 152

• Saisissez Montant dans la colonne Nom. Il s'agit du nom du domaine. Un code iden-
tique au nom s'affiche automatiquement dans la colonne Code.
• Cliquez sur le bouton Appliquer situé dans la partie inférieure de la boîte de dialogue.
La création du nouveau domaine est validée. Tri alphabétique des noms Lorsque vous
cliquez sur Appliquer ou sur OK, tous les noms dans la liste sont triés par ordre alphabé-
tique. L'ordre d'affichage des noms dans la liste est par conséquent modifié lorsque vous
effectuez l'une de ces opérations.
• Cliquez sur le nouveau domaine. Une flèche s'affiche au début de la ligne.
• Cliquez sur l'outil Propriétés

ou
Double-cliquez sur la flèche au début de la ligne. La feuille de propriétés du nouveau
domaine s'affiche.
 153

• Cliquez sur le bouton Point d'interrogation situé en regard de la zone Type de don-
nées. La boîte de dialogue Types de données standard s'affiche. Utilisez cette boîte de
dialogue pour spécifier le format des données auxquelles le domaine est affecté.
• Cliquez sur le bouton radio Monnaie. Le domaine a maintenant le type de données
Monnaie. Ce type de données permet de stocker des nombres à décimale fixe. Par la
suite, lorsque vous appliquez ce domaine aux informations utilisées pour stocker les
montants, ces dernières héritent du type de données que vous avez défini. Codes de
type de données Tous les types de données sont dotés d'un code composé de une à
trois lettres. Lorsque vous sélectionnez le bouton radio Monnaie, le code MN apparaît
dans la zone Code. Il s'agit du code pour un type de données monétaire.
• Saisissez 8 dans la zone Longueur. Le nombre de chiffres d'une information à laquelle
ce domaine est affecté sera 8.
• Saisissez 2 dans la zone Précision. Une information à laquelle ce domaine est affecté
peut comporter deux décimales.
 154

• Cliquez sur OK. Vous revenez à la feuille de propriétés du domaine. La valeur MN8,2
apparaît dans la colonne Type de données. MN est le code du type de données moné-
taire. 8 indique que la somme peut comporter huit chiffres et 2 indique qu'elle peut com-
porter deux décimales.
• Cliquez sur OK. Vous revenez à la Liste des domaines.
• Cliquez sur l'outil Ajouter une ligne.

Une flèche apparaît au début de la première ligne vide. Un nom et un code de domaine
s'affichent par défaut.
• Saisissez Pourcentage dans la colonne Nom. Il s'agit du nom du domaine. Un code
identique au nom s'affiche automatiquement dans la colonne Code.
• Cliquez sur le bouton Appliquer situé dans la partie inférieure de la boîte de dialogue.
La création du nouveau domaine est validée.
• Cliquez sur le nouveau domaine. Une flèche s'affiche au début de la ligne.
• Cliquez sur l'outil Propriétés.
 155

ou
Double-cliquez sur la flèche au début de la ligne. La feuille de propriétés du nouveau
domaine s'affiche.
• Cliquez sur le bouton Point d'interrogation situé en regard de la zone Type de don-
nées. La boîte de dialogue Types de données standard s'affiche. Utilisez cette boîte de
dialogue pour spécifier le format des données auxquelles le domaine est affecté.
• Cliquez sur le bouton radio Entier court. Le code SI indique que le domaine Pourcen-
tage spécifie des données de type entier court. Les zones Longueur et Précision ne sont
pas actives car il est inutile de spécifier une longueur et une précision pour un entier
court.
• Cliquez sur OK dans chacune des boîte de dialogue successives. Type de données par
défaut Lorsque vous ne définissez pas de type de données pour un domaine, celui-ci
utilise le type de données par défaut. Vous pouvez spécifier vous-même le type de don-
nées par défaut en sélectionnant Fichier-->Options du modèle.

5.3.8. Création d'une entité

Vous allez créer une entité qui contient des données relatives aux portraits, une entité
qui associe les ouvrages aux auteurs et deux entités qui différencient les catégories d'ou-
vrage, à savoir périodique et non-périodique.
• Cliquez sur l'outil Entité dans la palette d'outils.
• Cliquez sur un emplacement vide dans le diagramme. Un symbole d'entité s'affiche à
l'endroit où vous avez cliqué :

Lorsque vous la créez, l'entité se voit attribuer un nom par défaut qui inclut un numéro,
ce numéro est affecté dans l'ordre de création des objets.
• Cliquez sur l'outil Pointeur dans la palette d'outils.
• Double-cliquez sur le symbole de l'entité que vous venez de créer. La feuille de pro-
priétés de l'entité s'affiche.
 156

• Saisissez Portrait dans la zone Nom. Il s'agit du nom de l'entité. Un code identique au
nom s'affiche automatiquement dans la zone Code
• Cliquez sur OK. La nouvelle entité s'affiche avec le nom Portrait.

Vous avez créé cette entité en commençant par son symbole, puis en l'identifiant dans
sa feuille de propriétés. Vous pouvez également créer des entités dans la liste des entités.
• Sélectionnez Modèle-->Entités dans la barre de menus. La boîte de dialogue Liste des
entités affiche la liste des entités définies.
• Cliquez sur l'outil Ajouter une ligne.

Une flèche apparaît au début de la première ligne vide. Un nom et un code d'entité
s'affichent par défaut.
• Saisissez Périodique dans la colonne Nom. Le code est automatiquement défini avec
la même chaîne que le nom.
• Cliquez sur Appliquer. La création de la nouvelle entité est validée. Tri alphabétique
des noms Lorsque vous cliquez sur Appliquer ou sur OK, tous les noms dans la liste sont
triés par ordre alphabétique. L'ordre d'affichage des noms dans la liste est par consé-
quent modifié lorsque vous effectuez l'une de ces opérations.
• Cliquez sur l'outil Ajouter une ligne

Une flèche apparaît au début de la première ligne vide. Un nom et un code d'entité
s'affichent par défaut.
• Saisissez Non périodique dans la colonne Nom.
• Cliquez sur Appliquer. Les nouvelles entités apparaissent dans la liste.
 157

• Cliquez sur OK. Les nouvelles entités s'affichent dans le MCD

Déplacement des symboles d'entité.

Lorsque vous créez des entités à partir de la liste, celles-ci n'apparaissent pas disposées
comme dans l'illustration ci-avant. Vous ne pouvez pas contrôler la position d'insertion
des symboles créés ainsi. Pour déplacer un symbole, sélectionnez-le et faites-le glisser
jusqu'à son nouvel emplacement.

5.3.9. Création d'une entité associative

Vous allez remplacer la relation existante entre AUTEUR et TITRE avec une entité asso-
ciative. Cette entité associative aura une occurrence unique pour chaque combinaison
titre-auteur pour que vous puissiez attacher un pourcentage de droit d'auteur à chaque
cas unique.
• Cliquez le bouton droit de la souris sur la relation qui lie les entités Auteur et Titre. Un
menu contextuel s'affiche.
• Sélectionnez Transformer en Entité-->Standard depuis le menu contextuel.
Une nouvelle entité est insérée entre Auteur et Titre.
 158

5.3.10. Définition d'attributs d'entité

Vous allez définir des attributs pour les entités TITREAUTEUR, PORTRAIT, PERIODIQUE
et NON PERIODIQUE en affectant plusieurs informations à chacune d'entre elles. Pour
créer ces attributs d'entité, vous allez :
• Ajouter des informations dans une entité
• Créer un nouvel attribut d'entité
 Ajout d'informations à une entité Vous allez affecter des informations existantes aux enti-
tés TITREAUTEUR, PORTRAIT, PERIODIQUE et NON PERIODIQUE.
• Double-cliquez sur l'entité TitreAuteur. La feuille de propriétés de cette entité s'affiche.
• Cliquez sur l'onglet Attributs. La boîte de dialogue Attributs s'affiche. La liste est vide car
cette entité ne contient pas encore d'attribut.
• Cliquez sur le bouton Ajouter des informations.

Une boîte de Sélection s'affiche. Elle répertorie toutes les informations disponibles dans
le modèle.
• Cliquez sur l'en-tête de colonne Code. Les informations sont triées alphabétiquement
par code.
• Cochez la case Ordre TitreAuteur. Cochez la case Pourcentage TitreAuteur.
 159

Multisélection
Vous pouvez également appuyer sur la touche CTRL, sélectionner différentes informa-
tions, puis appuyer sur la touche BARRE D'ESPACEMENT pour cocher automatiquement
la case correspondant aux éléments sélectionnés dans la liste.
• Cliquez sur OK. Les informations s'affichent dans la liste des attributs de l'entité TitreAu-
teur.

• Cliquez sur OK. Dans le diagramme du MCD, l'entité TITREAUTEUR affiche ses attributs.
 160

• Répétez les étapes 1 à 7 en les appliquant aux entités suivantes :

Le MCD affiche ces entités avec leurs attributs.

 Création d'un attribut d'entité Vous allez créer un nouvel attribut Biographie pour
le texte de biographie de l'auteur.
• Double-cliquez sur le symbole d'entité AUTEUR. La feuille de propriétés de l'entité s'af-
fiche.
• Cliquez sur l'onglet Attributs. La page Attributs s'affiche. Elle répertorie tous les attri-
buts appartenant à l'entité Auteur.
• Sélectionnez l'attribut Avance auteur.
• Cliquez sur le bouton Insérer. Une ligne vide s'affiche au-dessus de la ligne Avance
auteur. Un nom et un code s'affichent par défaut.
• Saisissez Biographie auteur dans la colonne Nom pour l'attribut d'entité.
• Saisissez BIO_AUTEUR dans la colonne Code.
• Sélectionnez LONG_NOTES dans la zone de liste Domaine située en bas de la boîte de
dialogue. Le type de données Texte (TXT) apparaît dans la colonne Type de données.
 161

• Cliquez sur OK. Le nouvel attribut de l'entité Auteur s'affiche dans le symbole.

5.3.11. Définition d'un identifiant

Un identifiant est un attribut d'entité qui identifie de façon unique chaque occurrence
de l'entité. Vous allez définir Référence photo comme identifiant de l'entité PORTRAIT.
• Double-cliquez sur le symbole de l'entité PORTRAIT. La feuille de propriétés de l'entité
s'affiche.
• Cliquez sur l'onglet Attributs. La page Attributs s'affiche.
 162

• Cliquez sur l'attribut Référence photo. Une flèche apparaît au début de la ligne.
• Cliquez sur l'outil Propriétés.

ou
Double-cliquez sur la flèche au début de la ligne. La feuille de propriétés de l'attribut
s'affiche.
• Cochez la case Identifiant primaire dans la partie inférieure de la boîte de dialogue.
• Cliquez sur OK. Vous revenez à la page Attributs.
• Faites défiler la liste vers la droite jusqu'à ce que les colonnes O (Obligatoire) et P (Iden-
tifiant Primaire) soient visibles.
En-tête de colonne non visible Si un en-tête de colonne n'est pas visible dans la liste,
cliquez sur l'outil Personnaliser les colonnes et filtrer dans la barre d'outils. Une boîte de
sélection répertoriant toutes les colonnes disponibles pour la liste s'affiche. Cochez la
case correspondant à la colonne que vous souhaitez afficher et cliquez sur OK. La co-
lonne s'affiche dans la liste. Sur la ligne Référence photo, les coches qui apparaissent
dans les cases P et O indiquent respectivement que cet attribut est un identifiant primaire
et qu'il est obligatoire.
 163

• Faites défiler la liste vers la gauche jusqu'à ce que la colonne Nom soit visible.
• Cliquez sur l'attribut Photo. Une flèche apparaît au début de la ligne.
• Cliquez sur l'outil Propriétés.

ou
Double-cliquez sur la flèche au début de la ligne. La feuille de propriétés de l'attribut
s'affiche.
• Cochez la case Obligatoire dans la partie inférieure de la boîte de dialogue.
• Cliquez sur OK. Vous revenez à la page Attributs.
• Faites défiler la liste vers la droite jusqu'à ce que la colonne O soit visible. Une coche
apparaît dans la colonne O de l'attribut Photo, ce qui signifie que cet attribut est obliga-
toire. Ainsi, chaque occurrence de l'entité Portrait doit inclure une photo.
• Cliquez sur OK. L'attribut d'entité Référence photo apparaît souligné dans le symbole
de l'entité PORTRAIT, ce qui indique qu'il s'agit de l'identifiant.
 164

5.3.12. Création d'une relation

Vous allez créer une relation entre les entités AUTEUR et PORTRAIT.
• Cliquez sur l'outil Pointeur dans la palette d'outils.
• Faites glisser l'entité Portrait sous l'entité AUTEUR.

• Cliquer sur l'outil Relation dans la palette d'outils.

• Cliquez sur l'entité AUTEUR et maintenez le bouton gauche de la souris enfoncé, puis
faites glisser le curseur sur l'entité PORTRAIT. Relâchez le bouton de la souris dans l'entité
PORTRAIT. Vous avez créé une relation entre les deux entités. Les symboles de points de
contact à chaque extrémité indiquent que la cardinalité de la relation est de la forme
suivante:
• Un seul point de contact du côté AUTEUR indique qu'il n'y a qu'un auteur par portrait
• Trois points de contact du côté PORTRAIT indique que ce même auteur peut avoir
plusieurs portraits Les cercles situés avant les deux points de terminaison indiquent que
chaque côté de la relation est facultatif. Vous définissez la cardinalité d'une relation dans
la page Détails de la feuille de propriétés de relation.
Propriétés des relations
Les relations que vous créez à l'aide de l'outil Relation sont facultatives et ont la cardina-
lité 0..n par défaut. Vous pouvez changer ces propriétés, ainsi que d'autres propriétés
depuis la feuille de propriétés de la relation.
Définition des rôles dans une relation facultative
 165

Vous allez définir une relation facultative entre AUTEUR et PORTRAIT. Un auteur peut
ne pas avoir de portrait et un portrait peut ne pas représenter un auteur.
• Cliquez sur l'outil Pointeur dans la palette d'outils.
• Double-cliquez sur la relation entre AUTEUR et PORTRAIT. La feuille de propriétés de
la relation s'affiche.
• Saisissez Portrait Auteur dans la zone Nom.

• Cliquez sur la page Détails. La page Détails s'affiche.

• Saisissez le nom de rôle est montré dans dans la zone de groupe AUTEUR vers POR-
TRAIT. Ceci indique qu'un auteur est montré dans un portrait.
• Saisissez le nom de rôle montre dans la zone de groupe PORTRAIT vers AUTEUR. Ceci
indique qu'un portrait montre un auteur.
 166

• Cliquez sur OK. La relation s'affiche dans la fenêtre du modèle.

 167

Afficher les rôles de la relation

Vous pouvez afficher les rôles en sélectionnant Outils-->Préférences d'affichage dans la
barre de menus et en cochant la case Rôle dans la catégorie Relation.
La maitrise des outils exige de la pratique. Nous vous la conseillons pour produire niveau
apres niveau des modèles.
 168

BIBLIOGRAPHIE
1. ACSIOME. 1990. Modélisation dans la conception des systèmes d’information. Mas-
son, Paris.
2. AHO, A., ULLMAN, J. 1993. Concepts fondamentaux de l’informatique. Dunod, Paris.
3. AKOKA, J. 2001. Conception des bases de données relationnelles en pratique : con-
cepts, méthodes et cas corrigés. Vuibert, Paris.
4. ANDRÉ, P. et VAILLY, A. 2001. Conception des systèmes d’information – Panorama
des méthodes et des techniques, Ellipses, collection TECHNOSUP / Génie Logiciel, Paris.
5. ANDRÉ, P. et VAILLY, A. 2001. Spécification des logiciels – Deux exemples de pratiques
récentes : Z et UML, Ellipses, collection TECHNOSUP / Génie Logiciel, Paris.
6. BENETT, S., MCROBB, S., FARMER, R. 2001. Object-Oriented Systems Analysis and De-
sign using UML. McGrawwHill, London.
7. DATE, C. 1998. Introduction aux bases de données, 6e Edition, Thomson international
publishing, Melbourne.
8. DOMINIQUE D. 1998. L’essentiel sur Merise, Eyrolles, Paris
9. GABAY, J. 1993. Apprendre et pratiquer Merise. Masson, Paris.
10. GALACSI, 1984. Les systèmes d'information : analyse et conception, Dunod, Paris.
11. GALACSI, 1985. Comprendre les systèmes d'information : exercices corrigés d'ana-
lyse et de conception, Dunod, Paris.
12. GALACSI. 1989. Conception de bases de données : du schéma conceptuel au
schéma physique, Dunod, Paris.
13. GARDARIN, G. 2000. Maîtriser les bases de données, Eyrolles, Paris.
14. GUEDJ, G. 1996. AMC Designor, mise en œuvre de MERISE, Eyrolles, Paris.
15. HAINAUT, J. 1994. Bases de données et modèles de calcul – Outils et Méthodes pour
l’Utilisateur. InterEditions, Paris.
16. JEAN-LUC BAPTISTE. 2018, Merise, guide pratique (modelisation des données et des
traitements, manipulation avec le langage SQL, Conception d’une application mobile),
Editions ENI,France.
17. MATHERON, J. 1994. Exercices et cas pour comprendre MERISE. Eyrolles, Paris.
18. MATHEU, P. 2000. Des bases de données à l’Internet. Vuibert, Paris.
19. SOMMERVILLE, I. 1985. Le génie logiciel et ses applications, Inter Éditions,
20. TESSIER, C. 1995. La pratique des méthodes en informatique de gestion, Les Editions
d'Organisation, Paris.