12 Livre Acsi (Merise-Uml) 1 Ere Edition

HIT-TECHNOLOGY SARL U: www.hittechnologie.
net
ACSI ET SI : MERISE ET UML
[email protected]
1ère Edition
ACSI : Analyse et Conception des Systèmes Informatiques
SI Système d’Information ou Informatique
MERISE : Méthode d’Etude et de Réalisation Informatique pour les Systèmes
d’Entreprise
UML : Unified Modeling Language : Introduction
Pour concepteur et développeur de bases de données,

d’applications et des Systèmes d’Information
A l’usage des BTS, Licence et Master
HIT-TECHNOLOGY SARL U
ANALYSE ET CONCEPTION DES

SYSTEMES INFORMATIQUES ET COURS et EXERCICES CORRIGES
D’INFORMATION : MERISE et UML
Formateur en développement applicatif

Enseignant à l’Université de Lomé et dans les Institutions privées (Togo)
Fondateur du Cabinet HIT-TECHNOLOGY SARL U
Alassani AKANATE [email protected]
[email protected]
Tel : (+228) 90 47 51 03 / 97 31 77 52 / 93 32 77 18
01 BP : 1341 Lomé-Togo.
«L’avenir de l’Homme se trouve dans sa manière de penser»
© Tous droits réservés 2017-2020 HIT-T
PRIX : 2 500 F CFA

LIVRE ACSI Livre par HIT-TPAR
: MERISE-UML SAUL U
LE CABINET HIT-T
HIT-T SARL U: web : www.hittechnologie.net E-mail : [email protected] Tel : 90-47-51-03 /97-31-77-52
Enregistré sous le décret n° 2012-008/PR du 07-03-2012, Arrêté n° 011/MCPSP/CAB/DPSP du 13-04-2012
DANS LA MÊME COLLECTION
1 ARCHITECTURE ET INTERCONNEXION RESEAU

2 SGBD MySQL ET SQL
3 ANALYSE ET CONCEPTION DES SYSTEMES D’INFORMATION (ACSI) AVEC MERISE
4 SGBD MICROSOFT ACCESS 2010
5 SGBD MICROSOFT EXCEL 2007-2010 (Excel débutant, intermédiaire et avancé)
6 SQL POUR MySQL ET ORACLE
7 SE-OS, CONFIGURATION ET SECURITE
8 SECURITE INFORMATIQUE ET RESEAU
9 INFORMATIQUE ET CONFIGURATION
10 OFFICE 2007-2010 ET INITIATION (Word-Excel-PowerPoint-Publisher)
DEVELOPPEMENT DE SITES WEB AVEC LE CMS/SGC JOOMLA ET LES BASES DE DONNEES
11
MySQL
12 P.O.O.: Java SE
13 P.O.O.: C++ et Qt
14 Ecrits Professionnels (EP)
15 Droit Social et de Travail (M. ALASSANI)
16 Economie Générale (M. AMANA)
17 Santé, Sécurité et Hygiène au travail (S. S. H. T.)
18 Tenue de caisse – Facturation
19 Electronique dans l’automobile
20 Climatisation dans l’automobile
21 MS SQL SERVER 2012-2014 et SQL / T-SQL
22 LES TECHNOLOGIES xDSL (Techniques d’accès à l’Internet)
23 MIEUX PARLER ANGLAIS
24 DROIT, NEGOCIATION ET CONTRATS INFORMATIQUES
25 SOCIAL MEDIA – NETWORKING (Marketing digital)
COLLECTION HIT-T SARL U (Disponible sur : www.hittechnologie.com ou www.hittechnologie.net )
ACSI ET SI: BTS/ LP/MP-HIT-T/Par A. AKANATE 1ère Edition HIT-TECHNOLOGY SARL U/ISIT Page 1 sur 110
Table des matières

A QUI S’ADRESSE CE LIVRE ? .................................................................................................................. 6
PREREQUIS ................................................................................................................................................... 6
POURQUOI CE LIVRE ? .............................................................................................................................. 6
OBJECTIFS SPECIFIQUES DE CE LIVRE ................................................................................................ 6
A PROPOS ...................................................................................................................................................... 6
INTRODUCTION GENERALE .................................................................................................................... 7
CHAPITRE I : GENERALITES, DEFINITIONS ET CONCEPTS ............................................................. 8
INTRODUCTION .......................................................................................................................................... 9
1. GENERALITES ........................................................................................................................................ 9
2. DEFINITIONS ........................................................................................................................................... 9
3. CONCEPTS ............................................................................................................................................. 11
3.1. Système ............................................................................................................................................ 11
3.1.1. Un système vu comme une « boîte noire » .................................................................................................. 11
3.1.2. Système : de la « boîte noire » à la« boîte blanche » ................................................................................... 11
3.2. Notion d'information ....................................................................................................................... 12
3.2.1. Composition d’une information................................................................................................................... 12
3.2.2. Rôle de l'information ................................................................................................................................... 12
3.2.3. Qualités requises pour une information ....................................................................................................... 12
3.2.4. Types d'information..................................................................................................................................... 13
3.3. Systèmes d'information .................................................................................................................... 13
3.3.1. Composition d’un système d’information ou d’organisation ....................................................................... 13
3.3.2. Périmètre d’un système d’information ........................................................................................................ 14
3.3.3. Fonctions d’un système d’information ........................................................................................................ 14
3.3.4. Critères d'un bon système informatique ...................................................................................................... 15
3.3.5. Classification des systèmes d'information ................................................................................................... 15
3.4. Base de données .............................................................................................................................. 16
3.5. Développement d’un logiciel : les quatre distinctions capitales ..................................................... 16
3.5.1. Première distinction : Développement = Conception + Réalisation ............................................................ 16
3.5.2. Deuxième distinction : Conception = Analyse fonctionnelle + Analyse organique..................................... 17
3.5.3. Troisième distinction : Analyse organique = Architecture système + Analyse détaillée ............................. 18
3.5.4. Quatrième distinction : les données et les traitements ................................................................................. 18
3.6. Cycle de vie d’un logiciel ................................................................................................................ 18
3.6.1. Composition du cycle de vie d’un logiciel .................................................................................................. 19
3.6.2. Différents modèles de cycle de vie .............................................................................................................. 19
3.6.2.1. Cycle de vie en cascade ..................................................................................................................... 20
3.6.2.2. Cycle de vie en V ............................................................................................................................... 20
3.6.2.3. Cycle de vie en spirale ....................................................................................................................... 22
3.7. Méthodes d'informatisation ............................................................................................................. 23
3.7.1. Méthode d'informatisation : règles .............................................................................................................. 23
3.7.2. Les avantages de l’utilisation des méthodes d’informatisation .................................................................... 23
3.7.3. Typologie des méthodes d'informatisation .................................................................................................. 24
3.7.3.1. Types d'approche des problèmes d'informatisation ............................................................................ 24
3.7.3.1.1. Méthodes classiques ..................................................................................................................... 24
3.7.3.1.2. Méthodes cartésiennes .................................................................................................................. 25
3.7.3.1.3. Méthodes systémiques .................................................................................................................. 25
3.7.3.1.4. Méthodes orientée-objet ............................................................................................................... 26
3.7.3.2. Les domaines d'application des systèmes d’informatisation .............................................................. 26
CONCLUSION ............................................................................................................................................. 26
CHAPITRE II : LES MODELES ET FORMALISMES DE MERISE ....................................................... 27
INTRODUCTION ........................................................................................................................................ 28
1. PHASES DANS LA CREATION D’UN SYSTEME D’INFORMATION (SI) ....................................... 28

1.1. La phase d'analyse .......................................................................................................................... 28
1.2. La phase conceptuelle ..................................................................................................................... 28
1.3. La phase logique ou organisationnelle ........................................................................................... 28
1.4. La phase physique ou opérationnelle .............................................................................................. 29
2. LES FORMALISMES ............................................................................................................................. 29
2.1. Formalisme MCC ............................................................................................................................ 29
2.1.1. Diagramme de contexte ............................................................................................................................... 29
2.1.2. Diagramme conceptuel de flux .................................................................................................................... 30
2.2. Formalisme MCD ............................................................................................................................ 31
2.2.1. Entités et classe d'entité ............................................................................................................................... 31
2.2.2. Relations et classes de relation .................................................................................................................... 31
2.2.3. La cardinalité ............................................................................................................................................... 32
2.2.4. Les identifiants ............................................................................................................................................ 32
2.2.5. Agrégation (ou identification relative) ........................................................................................................ 33
2.2.6. MCD : Règles (les formes normales et de BOYCE CODD) ....................................................................... 34
2.3. Formalisme MCT ............................................................................................................................ 35
2.3.1. Le concept d'évènement .............................................................................................................................. 35
2.3.2. Concept de processus .................................................................................................................................. 36
2.3.3. Opération ..................................................................................................................................................... 36
2.3.4. La synchronisation ...................................................................................................................................... 36
2.3.5. Construction du MCT.................................................................................................................................. 36
2.4. Formalisme MLD ............................................................................................................................ 37
2.4.1. Traduction d'une classe d'entité ................................................................................................................... 37
2.4.2. Traduction d'une classe de relation .............................................................................................................. 37
2.4.3. Traduction d'une classe d'agrégation ........................................................................................................... 37
2.5. Formalisme MOT ............................................................................................................................ 38
2.5.1. Le tableau des procédures fonctionnelles .................................................................................................... 38
2.5.2. Représentation du MOT .............................................................................................................................. 38
3. LES MODELES DE MERISE ................................................................................................................. 38
3.1. Les modèles de la communication ................................................................................................... 39
3.1.1. Diagramme de contexte ............................................................................................................................... 39
3.1.2. Le Modèle Conceptuel de la Communication (MCC) ou Diagramme conceptuel de flux .......................... 39
3.2. Les modèles de données .................................................................................................................. 39
3.2.1. Modèle Conceptuel de données (MCD) ...................................................................................................... 39
3.2.1.1. Repérage des entités .......................................................................................................................... 40
3.2.1.2. Construction des entités ..................................................................................................................... 40
3.2.1.3. Construction des relations .................................................................................................................. 41
3.2.1.4. Choix des cardinalités ........................................................................................................................ 43
3.2.1.5. Cas particuliers et pièges ................................................................................................................... 44
3.2.2. Le modèle logique des données (MLD) ...................................................................................................... 45
3.2.3. Le modèle Physique des données (MPD ou MPhD).................................................................................... 46
3.3. Les modèles des traitements ............................................................................................................ 47
3.3.1. Le modèle conceptuel des traitements (MCT) ............................................................................................. 47
3.3.1.1. L'évènement ....................................................................................................................................... 47
3.3.1.2. L'opération ......................................................................................................................................... 48
3.3.1.3. Le processus ...................................................................................................................................... 48
3.3.2. Le modèle organisationnel des traitements (MOT) ou MLT (modèle logique des traitements) .................. 48
3.3.2.1. Le poste de travail .............................................................................................................................. 48
3.3.2.2. La phase ............................................................................................................................................. 48

3.3.2.3. La tâche ............................................................................................................................................. 48
3.3.2.4. La procédure ...................................................................................................................................... 49
3.3.3. Le modèle opérationnel des traitements (MOT ou MOpT) ......................................................................... 49
3.3.4. Résumé des modèles MERISE .................................................................................................................... 49
3.3.4.1. Les modèles statiques ........................................................................................................................ 49
3.3.4.2. Les modèles dynamiques ................................................................................................................... 49
4. REGLES DE PASSAGE DU MCD AU MLDR ....................................................................................... 50
4.1. Une entité se transforme en une relation (table) ............................................................................. 50
4.2. Relation binaire aux cardinalités (X, 1) - (X,n), X=0 ou X=1......................................................... 50
4.3. Relation binaire aux cardinalités (X,n) - (X,n), X=0 ou X=1.......................................................... 51
4.4. Relation n-aire (quelles que soient les cardinalités) ....................................................................... 51
4.5. Association Réflexive....................................................................................................................... 52
4.5.1. Premier cas : cardinalité (X,1) - (X,n), avec X=0 ou X=1. .......................................................................... 52
4.5.2. Deuxième cas : cardinalité (X,n) - (X,n), avec X=0 ou X=1 ....................................................................... 53
4.6. Relation binaire aux cardinalités (0,1) - (1,1)................................................................................. 53
4.7. MCD : Etude de cas ........................................................................................................................ 54
5. LES CONTRAINTES : LES CLES ......................................................................................................... 55
5.1. Clé artificielle.................................................................................................................................. 55
5.2. Clé candidate .................................................................................................................................. 56
5.3. Clé étrangère ................................................................................................................................... 56
5.4. Clé naturelle .................................................................................................................................... 56
5.5. Clé primaire .................................................................................................................................... 56
6. COURBE DU SOLEIL ET ETAPES D’ELABORATION DES DIFFERENTS MODELES .................. 57
6.1.1. Courbe du soleil .......................................................................................................................................... 57
6.1.2. Courbe du soleil et cycle de vie ................................................................................................................... 57
6.1.3. Courbe du soleil et les modèles MERISE .................................................................................................... 58
CONCLUSION ............................................................................................................................................. 58
CHAPITRE III : LA DEMARCHE MERISE ET INTRODUCTION A UML ........................................... 59
INTRODUCTION ........................................................................................................................................ 60
1. LA DEMARCHE MERISE ...................................................................................................................... 60

1.1. Le schéma directeur ........................................................................................................................ 60
1.2. L'étude préalable ............................................................................................................................. 61
1.2.1. Étape 1 : Étude de l'existant......................................................................................................................... 61
1.2.2. Étape 2 : Scénarios futurs ............................................................................................................................ 62
1.2.3. Étape 3 : Une évaluation des Scénarios ....................................................................................................... 63
1.3. L'étude détaillée .............................................................................................................................. 63
1.3.1. Étape 1 : Étude générale du MOT futur ....................................................................................................... 64
1.3.2. Étape 2 : Étude poussée de chaque procédure fonctionnelle ....................................................................... 64
1.3.3. Étape 3 : Validation du MCD ...................................................................................................................... 64
1.3.4. Étape 4 : Passage au MLD........................................................................................................................... 64
1.4. L'étude technique............................................................................................................................. 64
1.4.1. Étape 1 : structuration des données ............................................................................................................. 65
1.4.2. Étape 2 : spécification de l'architecture interne du système ......................................................................... 65
1.4.3. Étape 3 : les procédures techniques de sécurité ........................................................................................... 65
1.4.4. Étape 4 : planification de la réalisation........................................................................................................ 65
1.5. La production .................................................................................................................................. 66
1.5.1. Étape 1 : programmation de l'application .................................................................................................... 66
1.5.2. Étape 2 : tests, mise au point ....................................................................................................................... 66
1.6. La mise en service ........................................................................................................................... 67
1.6.1. Étape 1 : l'installation .................................................................................................................................. 67

1.6.2. Étape 2 : la mise en exploitation .................................................................................................................. 67
1.7. La maintenance ............................................................................................................................... 67
1.7.1. La maintenance corrective ........................................................................................................................... 68
1.7.2. La maintenance adaptative .......................................................................................................................... 68
1.7.3. La maintenance perfective ........................................................................................................................... 68
1.7.4. La maintenance préventive .......................................................................................................................... 68
2. INTRODUCTION A UML ...................................................................................................................... 68
2.1. But de UML ..................................................................................................................................... 68
2.2. Exemples de représentation entité-association UML ...................................................................... 69
2.3. Les 9 diagrammes d’UML ............................................................................................................... 69
2.3.1. Diagramme des cas d’utilisation.................................................................................................................. 69
2.3.2. Diagramme de séquence (cf. collaboration) ................................................................................................ 70
2.3.3. Diagramme d’activité (cf. états-transition) .................................................................................................. 71
2.3.4. Diagramme de classes ................................................................................................................................. 71
2.3.5. Diagramme d’objets (cf. classes) ................................................................................................................. 72
2.3.6. Diagramme de collaboration (cf. séquence) ................................................................................................ 72
2.3.7. Diagramme d’états-transition (cf. activité) .................................................................................................. 72
2.3.8. Diagramme de composants.......................................................................................................................... 73
2.3.9. Diagramme de déploiement ......................................................................................................................... 73
2.4. Les différents diagrammes selon l’étape de la conception .............................................................. 74
2.5. Précisions ........................................................................................................................................ 74
3. ÉLEMENTS DE MERISE 2 : INTRODUCTION.................................................................................... 75
3.1. Spécialisation simple ....................................................................................................................... 75
3.2. Généralisation ................................................................................................................................. 77
4. COMPARAISON DE REPRESENTATION MERISE-UML ................................................................. 78
4.1. Outils de conception de Bases de Données : MERISE-UML .......................................................... 78
4.1.1. Outils (Open-source, multi-OS) .................................................................................................................. 78
4.1.2. Outils (propriétaires, payants) ..................................................................................................................... 78
5. QUI FAIT QUOI ...................................................................................................................................... 78
6. SECURITE D’UNE BDD / SI .................................................................................................................. 79
CONCLUSION ............................................................................................................................................. 80
CONCLUSION GENERALE ....................................................................................................................... 81
PHASES D’ANALYSE ET DOCUMENTS PRODUITS ............................................................................. 82
QUESTIONS-REPONSES ........................................................................................................................... 83
RECUEIL DES EXERCICES ...................................................................................................................... 89
CORRIGES PROPOSES DES EXERCICES .............................................................................................. 96
GLOSSAIRE ............................................................................................................................................... 106
BIBLIOGRAPHIE ET WEBOGRAPHIE ................................................................................................. 110
A QUI S’ADRESSE CE LIVRE ?

Ce livre s’adresse aux étudiants, aux professionnels en activité, aux chefs d’entreprise et toute
personne désireuse d’avoir des connaissances approfondies dans le domaine de conception et
développement des bases de données, des applications et des systèmes d’information. Cet
ouvrage constitue également un outil puissant pour la compréhension des concepts des
systèmes d’information des organisations.
PREREQUIS
 Connaissance en informatique,
 Maîtrise de l’outil informatique.
POURQUOI CE LIVRE ?
Ce livre répond aux attentes des apprenants dans le domaine de connaissance des bases de
conception et développement des bases de données, des applications et des systèmes
d’information. Le besoin en développement des bases de données et d’applications étant sans
cesse croissant, nous avons jugé utile de mettre en place ce livre pour l’utilisation des
étudiants et tous les apprenants désireux d’approfondir leurs connaissances dans ledit
domaine. Ce livre contient outre le cours, une collection d’exercices et corrigés afin de
permettre aux apprenants de s’exercer. Egalement, un glossaire a été fourni à la fin du livre.
OBJECTIFS SPECIFIQUES DE CE LIVRE
 Comprendre le concept de système informatique, système d’information,
 Connaître les différentes méthodes d’informatisation existantes,
 Comprendre le vocabulaire et la démarche MERISE,
 Comprendre les étapes de conception d’un Système d’Information (SI) ou informatique
avec la méthode MERISE ou UML,
 Comprendre les étapes de conception d’une base de données avec la méthode MERISE
ou UML,
 Comprendre et appliquer la démarche MERISE ou UML dans le processus de mise en
place d’un Système d’Information (SI) ou informatique,
 Acquérir les notions de base sur la méthode UML,
 Savoir sécuriser une base de données ou une application.
A PROPOS
HIT-TECHNOLOGY (HIT-T) SARL U est un cabinet spécialisé dans le développement des
applications web et mobiles. Il offre également des services tels que : Les formations en
Multimédia, Informatique et Télécommunications, l’installation des réseaux informatiques, la
maintenance informatique et réseau, la conception et la réalisation de sites web, la conception
et la réalisation des applications web et mobiles, le consulting dans le domaine de mise en
place des bases de données, des systèmes d’information, la sécurité réseau, pour ne citer que
ces points. Les formations sont offertes dans les filières tertiaires et technologiques. Le
cabinet est enregistré sous le décret n° 2012-008 / PR du 07-03-2012, Arrêté n° 011 /
MCPSP / CAB / DPSP du 13-04-2012.
INTRODUCTION GENERALE
Les nouvelles technologies de l’information et de la communication (NTIC) constituent
un concept large de nos jours. Mais il faut noter également que cet acronyme cible en général
le monde de l’Internet et des Télécommunications ou le numérique incluant ainsi le monde
des applications et logiciels web, mobiles, jeux, pour ne citer que ces points. Ce monde
nouveau constitue aujourd’hui un mystère. Une énigme parce que la plupart de ceux qui s’y
intéressent ne disposent pas des informations nécessaires.
Le développement des applications web ou mobiles et la mise en place des bases de
données performantes pour une gestion efficace d’une structure nécessite un certain niveau
d’expertise. Expertise ayant deux volets : la maîtrise en conception et développement des
interfaces graphiques et la maîtrise en conception et développement des bases de données.
Cette expertise peut être acquise par expérience ou par une formation professionnelle sur
l’utilisation des méthodes et outils d’analyse, de conception, de modélisation et de
développement des systèmes informatiques.
Ce document constitue à cet effet une clé incontournable pour les concepteurs et
développeurs de bases de données et applications leur permettant de voir plus clair et de
comprendre le monde de développement des systèmes informatiques qui est resté jusqu’ici
mystérieux.
MERISE pour Méthode d’Etude et de Réalisation Informatique pour les Systèmes
d’Entreprise constitue une des méthode clé pour la conception, la modélisation et le
développement des systèmes d’information ou informatique qui est essentiellement discuté
dans ce livre. Une introduction au passage sur MERISE 2 a été fournie dans cet ouvrage. La
deuxième méthode abordée dans ce livre est UML (Unified Modeling Language en anglais,
soit langage de modélisation objet unifié) qui est née de la fusion de trois méthodes qui
s’imposaient dans le domaine de la modélisation objet au milieu des années 1990. Il s’agit de :
OMT, Booch et OOSE. D’importants acteurs industriels (IBM, Microsoft, Oracle, DEC, HP,
Rational, Unisys, etc.) s’associent alors à l’effort et proposent UML 1.0 à l’OMG (Object
Management Group) qui l’accepte en novembre 1997 dans sa version 1.1. La version d’UML
en cours à la fin 2006 est UML 2.0 qui s’impose plus que jamais en tant que langage de
modélisation standardisé pour la modélisation des logiciels. Dans cet ouvrage, seule une
introduction sur le langage UML est donnée.
Le présent document est constitué de trois (3) chapitres. Le premier chapitre aborde les
généralités, concepts et définitions, le deuxième chapitre discute de la méthode MERISE,
l’une des méthodes d’analyse et de conception des systèmes d’informations (SI), des
applications et bases de données la plus utilisée dans le monde francophone et enfin le dernier
chapitre élucide la démarche de la méthode MERISE et introduit MERISE 2 puis le langage
UML (Unified Modeling Language) qui est également un langage de conception et de
développement des systèmes informatiques. Il faut noter que des exercices et corrigés, et un
glossaire sont également fournis à la fin du livre. Ce support a été réalisé en utilisant les
ouvrages cités en bibliographie. Il est en partie basé sur le livre de Charroux, Osmani et
Thierry-Mieg (2005) qui constitue une bonne introduction au langage UML.
CHAPITRE I : GENERALITES, DEFINITIONS ET CONCEPTS
Analyse Système MERISE

SGBD Information Logiciel
Informatique UML BDD
INTRODUCTION
Qu’on le veuille ou non, les bases de données, les systèmes d’information ou
informatiques tout comme les technologies de l’information et de la communication de
manière générale, sont omniprésentes dans les diverses activités de l’Homme moderne. La
connaissance de leur conception et leur mise en place s’avère donc indispensable pour les
besoins quotidiens dans la vie de l’Homme ou des entreprises. Cette première partie du
document fera l’état de l’art sur l’ensemble des concepts et définitions utilisés dans le
domaine de mise en place des bases de données, des systèmes d’information ou informatiques
et technologies de l’information et présentera également différentes méthodes
d’informatisation rencontrées sur le marché et leur domaine d’application. De ce fait, le
présent chapitre se focalisera également sur le vocabulaire du domaine de la conception et
développement des bases de données et applications et constituera en ce sens une solution
pour apprendre ces méthodes et techniques d’analyse et de conception des systèmes.
1. GENERALITES
Composé de deux mots, information et automatique, l’informatique est la science du
traitement automatique de l’information. C’est un ensemble des applications de cette science,
mettant en œuvre des matériels (ordinateurs) et des logiciels. Cette science de nos jours a
évolué et elle s’applique à tous les domaines de la vie humaine. Son évolution a été poussée
par l’avènement de l’Internet et le web et couvre tous les aspects tels que l’Internet, les
télécommunications, l’aéronautique, etc. Les nanotechnologies ont également fait leur
apparition traitant du domaine microscopique des composants électroniques et augmentant
ainsi les capacités des supports de stockage de masse et leur miniaturisation.
2. DEFINITIONS
Processus : séquence de phénomènes dynamiques (mouvements, réactions chimiques,
activités cellulaires, opérations techniques, actions ou comportements, interactions humaines)
menant à des résultats déterminables. En analyse des systèmes : tout changement dans le
temps de matière, d'énergie ou d'information qui se produit dans le système, traitant ces
variables d'entrée et les menant aux variables de sortie ou
Ensemble d'opérations, logiquement liées, aboutissant à certains résultats. En conception
de systèmes d'information, selon la méthode Merise, le processus se situe au niveau du
modèle conceptuel de traitement. Un processus peut être également défini comme étant un
ensemble des étapes ou phases de la méthode d’exécution ou de fonctionnement de quelque
chose, que ce soit dans les systèmes commerciaux ou techniques, mettant en cause les actions
de plus d’une personne, d’une unité ou d’une division.
Système d’opérations dans la production d’une unité : C’est un ensemble de séries de
mesures, de changements ou de fonctions qui produisent un résultat final.
Information : Elle est encore appelée donnée brute. Elément de connaissance susceptible
d'être codé pour être conservé, traité ou communiqué.
Système : Un système est un assemblage d'éléments reliés entre eux compris dans un
ensemble plus grand. En latin et en grec, le mot « système » veut dire combiner, établir,
rassembler. Un sous-système est un système faisant partie d'un autre système. Généralement,
un système est constitué de composants (ou d'éléments) organisés ensemble dans le but de
faciliter le flux d'informations, de matières ou d'énergie. ...
Système Informatique (ou SI): Le système Informatique constitue la partie automatisée
ou informatisée du système d’information de l’entreprise ou encore c’est l’ensemble des
moyens technique du système d’information.
Système d'information (SI) ou (information system IS en anglais) est un ensemble de
composants de collecte, de saisie, de traitement, de stockage et de communication de
l'information, ainsi que l'environnement dans lequel ils opèrent. (En anglais: MIS ou
Management of Information Systems).
Ensemble structuré: (1) de données, de leurs traitements et de leurs communications,
décrit à l'aide de structures, de procédures et de protocoles → dictionnaire de données (En
anglais: DD ou Data Dictionary).
(2) de moyens techniques: Le système informatique (matériel et logiciel) et de
communication de documents ayant pour but de générer, mémoriser, traiter, transférer et
exploiter des informations dans le cadre d'objectifs définis.
Modèle : Le mot modèle synthétise les deux sens symétriques et opposés de la notion de
ressemblance ou de représentation. En effet, il est utilisé ‘pour un objet dont on cherche à
donner une représentation, qu'on cherche à imiter (exemple : le « modèle » du peintre, le «
modèle » que constitue le maître pour le disciple),’ pour un concept ou objet qui est la
représentation d'une autre (le « modèle réduit », le « modèle » du scientifique) ou simplement
Un modèle est une représentation (graphique) de la réalité.
Abstraction : L'abstraction consiste à choisir, parmi l’ensemble des propriétés de
plusieurs objets du monde réel ou imaginables, un certain nombre d’entre elles pour
caractériser un objet-type, ou objet idéal, qui est ensuite plus commode à manier qu’une
énumération d’objets réels, surtout si elle est infinie. Ainsi les nombres pairs ou les nombres
premiers ont un caractère d’abstraction. Mais à vrai dire, les nombres eux-mêmes ont un
caractère d’abstraction. ...
Concrétisation : phénomène inverse de l'abstraction: passe du modèle au monde réel.
Concept : idée d'un objet conçu par l'esprit, permettant d'organiser les perceptions et les
connaissances ou
Un concept est une construction de l'esprit permettant de mieux saisir intellectuellement
le réel. Élément de base d'une théorie, le concept se veut une représentation abstraite d'un
objet. Personne, par exemple, n'a vu une classe sociale, car elle est un concept.
Entrepôt de données : Base de données spécialisée dans laquelle est centralisé un
volume important de données consolidées à partir des différentes sources de renseignement
d’une entreprise (notamment les bases de données internes) et qui est conçue de manière à ce
que les personnes intéressées aient accès rapidement à l’information stratégique dont elles ont
besoin (Data warehouse en anglais).
SGBD (Système de Gestion des Bases de Données) : Logiciel, le plus souvent produit
par un éditeur commercial, qui gère et contrôle l’accès à une base de données, assurant ainsi
une interface normalisée entre les applications et les bases de données (Database management
system ou DMS en anglais).
Application de bases de données : Utilisation de moyens informatiques pour répondre à
un besoin déterminé en faisant appel de manière importante à une ou plusieurs bases de
données à travers un système de gestion de bases de données (SGBD) (Database application).
Bases de données (BD) : Ensemble structuré d’éléments d’information, souvent agencés
sous forme de tables, dans lesquels les données sont organisées selon certains critères en vue
de permettre leur exploitation pour répondre aux besoins d’information d’une organisation
(Database en anglais).
Logiciel ou Application : C’est un ensemble de programmes ayant des relations logiques
et permettant d’exécuter des tâches bien précises.
3. CONCEPTS
3.1. Système
3.1.1. Un système vu comme une « boîte noire »
Dans ce concept, un système est représenté par une boîte noire ayant des entrées et des
sorties. En plus des entrées et sorties (résultats) ordinaires, le système subit des perturbations
ou évènements provenant du monde extérieur. C’est ce qu’illustre la figure 1.1 ci-dessous.
Figure 1.1 : Un système vu comme une « boîte noire »

3.1.2. Système : de la « boîte noire » à la« boîte blanche »
Le système se décompose en sous-systèmes dont on définit les entrées (issues de
l'extérieur ou sorties d'autres sous-systèmes) et les sorties (à destination de l'extérieur ou
devenant les entrées d'autres sous-systèmes). La figure 1.2 ci-dessous illustre cette
description.
Figure 1.2 : Système : de la « boîte noire » à la« boîte blanche »

Chaque sous-système est lui-même un système : affinages successifs jusqu'à l'obtention
d'une « boîte blanche ».
3.2. Notion d'information
En informatique, la notion de données est très utilisée. Par exemple un programme a
généralement des données sur lesquelles il travaille. On peut définir une donnée comme une
information numérique ou alphanumérique, représentée sous forme codée, compréhensible
par la seule machine, pouvant être enregistrée, traitée, conservée et communiquée.
En réalité, on fait une distinction entre les données et l'information. La donnée est un fait
brut non interprété tandis que l'information est porteuse de sens. On peut dire qu'une
information est un ensemble de données interprétées dans un contexte particulier.
3.2.1. Composition d’une information
Une information est un ensemble de trois éléments à savoir :
 une entité : l'être, l'objet ou le concept concerné,
 un attribut : un élément de la description de l'entité,
 une mesure : une valeur associée à l'attribut.
Une information apporte un renseignement au sujet d'une entité. Elle nous permet de
représenter une entité et de transformer cette représentation.
3.2.2. Rôle de l'information
Tout acte de la vie d'une organisation s'accompagne ou est conditionné par des
informations pour :
 améliorer son fonctionnement,
 faciliter la prise de décision.
3.2.3. Qualités requises pour une information
Une information, pour être exploitable dans le sens de l’évolution d’une organisation et
une bonne prise de décision par le système de pilotage doit avoir les caractéristiques
suivantes :
 Pertinence (mesure la qualité d’une information) : relation directe entre l’action à
accomplir ou la décision à prendre :
 précision : ni trop importante, ni trop faible,
 sécurité (pour reconstituer l’information en cas d’accident),
 intégrité (contraintes statiques ou dynamiques),
 confidentialité (protection contre tentatives d’accès),
 non redondance (un seul exemplaire de chaque information),

 Convivialité (qualité de représentation sur support externe et facilité d’accès par les
utilisateurs),
 âge (temps entre enregistrement et sortie des résultats),
 fréquence (nombre de transmissions par unité de temps).
 Cohérence (d’unité, de temps, etc.).
 Rentabilité : coût d’obtention ≤ gain, meilleur service.
3.2.4. Types d'information
L’information peut être classée suivant plusieurs catégories à savoir : le niveau
d’agrégation, le flux, l’utilisation et la nature du support.
Niveau d'agrégation :
 brutes,
 élaborées.
Flux
 logistique,
 monétaire,
 de personnel,
 de l'actif.
Utilisation
 planification stratégique,
 gestion administrative,
 régulation opérationnelle.
Nature du support
 oral,
 documentaire,
 informatique.
3.3. Systèmes d'information
Une entreprise crée de la valeur en traitant de l'information, en particulier dans le cas des
sociétés de service. Ainsi, l'information possède une valeur d'autant plus grande qu'elle
contribue à l'atteinte des objectifs de l'organisation.
Un système d'Information (noté SI) représente l'ensemble des éléments participant à la
gestion, au traitement, au transport et à la diffusion de l'information au sein de l'organisation.
Une organisation (entreprise par exemple) peut être vue comme un système qui
transforme les entrées en sorties. Par exemple une usine de jus d’ananas transforme les entrées
qui sont des ananas en sorties qui sont des bouteilles de jus d’ananas.
3.3.1. Composition d’un système d’information ou d’organisation
Le système d’information décrit ci-dessus peut être divisé en deux sous-systèmes à savoir:
 le système opérant : constitué de la partie du système qui s'occupe effectivement de
transformer les ananas (les machines, les ouvriers, les techniciens, ...),
 le système de pilotage : définit les objectifs de l'entreprise et s'efforce de tout mettre en

œuvre pour qu'ils soient atteints. Pour cela, il prend des décisions.
Ces décisions sont prises à partir de paramètres venant du système opérant.
C'est le système d'information qui relève ces paramètres, les traites et les transmet au système
de pilotage. Il peut être vu comme la partie qui relie les deux systèmes précédents. Très
concrètement le périmètre du terme Système d'Information peut être très différent d'une
organisation à une autre et peut recouvrir selon les cas tout ou partie différents éléments. Cette
description des trois systèmes d’organisation est illustrée par la figure 1.3.
Figure 1.3 : Représentation et interaction entre les différents systèmes d’organisation

3.3.2. Périmètre d’un système d’information
La notion du système d’information peut recouvrir différents aspects comme suit :
 base de données de l'entreprise,
 progiciel de gestion intégré (ERP),
 Outil de gestion de la relation client (Customer Relationship Management),
 Outil de gestion de la chaîne logistique (SCM - Supply Chain Management),
 Applications métiers,
 Infrastructure réseau,
 Serveurs de données et systèmes de stockage,
 Serveurs d'application,
 Dispositifs de sécurité.
3.3.3. Fonctions d’un système d’information
Les systèmes d'information ont trois grandes fonctions dans le fonctionnement d’une
organisation à savoir :
 la mémorisation (des informations brutes ou résultats de traitement),
 la circulation : accès à la mémoire et échange entre les acteurs,

 le traitement : rapprochement, calcul, comparaison d'informations.
A ces trois fonctions, on peut en ajouter une quatrième :
 la collecte et saisie des informations.
3.3.4. Critères d'un bon système informatique
Les critères d’un bon système informatique sont entre autres :
 Productivité (en rationalisant le processus d'informatisation) :

 Établissement d'une ligne directrice des informatisations,
 Planification et suivi des performances,
 Efficacité des études informatiques,
 Utilisation judicieuse des technologies.
 Qualité :
 Conformité de la réalisation par rapport aux besoins,
 Documentation correcte,
 Adaptabilité,
 Fiabilité,
 Facilité d'utilisation.
 Rentabilité (c’est-à-dire un gain pour l'organisation relativement au coût de
l'informatisation).
3.3.5. Classification des systèmes d'information
On doit cette classification à Blumenthal. On distingue les grandes catégories suivantes
dans la classification des systèmes d’information.
 SICOP : Système d'Information de Contrôle Opérationnel Physique
 SICOL : Système d'Information de Contrôle Opérationnel Logistique :
 SICOMP : Système d'Information de Contrôle Opérationnel de Matières Premières,
 SICOPR : Système d'Information de Contrôle Opérationnel de Production,
 SICOPC : Système d'Information de Contrôle Opérationnel de Produits
Commercialisables.
 SICOAP : Système d'Information de Contrôle Opérationnel des Actifs Physiques :
 SICOIM : Système d'Information de Contrôle Opérationnel des Installations et
Matériels,
 SICOPI : Système d'Information de Contrôle Opérationnel de Projet
d'Investissement.
 SICOA: Système d'Information de Contrôle Opérationnel et Administratif
 SICOF : Système d'Information de Contrôle Opérationnel Financier :
 SICOC : Système d'Information de Contrôle Opérationnel de Comptabilité,
 SICOT : Système d'Information de Contrôle Opérationnel de Trésorerie.
 SICOM : Système d'Information de Contrôle Opérationnel Monétaire (notamment pour
la paie, la gestion des avantages et indemnités, et l'administration du personnel).
3.4. Base de données

Selon Wikipédia: «En informatique, une base de données (Abrégée : « BD » ou « BdD »
ou encore DB en anglais) est un lot d'informations stockées dans un dispositif informatique».
Selon Marc Grange « Une base de données est un ensemble structuré d'informations non
redondantes dont l'organisation est régie par un modèle de données».
Cette organisation doit respecter les points suivants :
 Structuration (à l'aide du modèle de données),
 Non répétition (non redondance ou redondance minimale) des données.
3.5. Développement d’un logiciel : les quatre distinctions capitales
Il y a quatre distinctions capitales dans le développement d’un logiciel.
3.5.1. Première distinction : Développement = Conception + Réalisation
Le développement se compose de deux activités qu’on peut distinguer : la
conception et la réalisation.
La conception consiste à comprendre et prévoir ce qu’il y’a à faire. En effet, la conception est
un processus très itératif. C’est ce qu’illustre la figure 1.4 ci-dessous.
Observe
use
Evaluate Generate
system ideas
Prototype
design
Figure 1.4 : Les étapes de la conception.

On parle également de la conception participative. Qu’en est-il exactement ?
« La conception participative implique les utilisateurs tout au long du processus de
conception. Les utilisateurs participent en tant qu'experts de l'utilisation de la technologie
dans son contexte, et en tant qu'innovateurs en contribuant des idées qui permettent d'explorer
de nouvelles voies de conception » (Wendy Mackay).‫‏‬
La réalisation consiste à faire concrètement ce qu’il y’a à faire.
La distinction entre la conception et la réalisation est une façon d’organiser la division
du travail. Le premier principe de la méthode consiste à considérer ces deux activités comme
deux étapes successives. La figure 1.5 présente le concept de conception et de réalisation
d’un logiciel.
Figure 1.5 : Concept de conception et de réalisation d’un logiciel
Le projet se déroule dans le temps : il commence avec la conception, il se termine

avec la réalisation.
La division du travail consiste à mettre en évidence les étapes de la réalisation d’un
logiciel.
3.5.2. Deuxième distinction : Conception = Analyse fonctionnelle + Analyse organique
La conception se divise en deux parties :
L’analyse fonctionnelle: L’analyse fonctionnelle s’occupe des fonctions (ou des services)
que le système offre à ses utilisateurs. Ce sont les « cas d’utilisation » (diagramme d’UML) du
logiciel.
L’analyse organique (ou architectonique) : L’analyse organique s’occupe de la façon dont sera
construit le système pour répondre aux attentes de l’analyse fonctionnelle. Cette distinction est
présentée sur la figure 1.6.
Figure 1.6 : Concept de conception

Avec cette distinction, on fait apparaître les points de vue suivants :
Pour l’utilisateur, ce qui compte, c’est l’usage du système : les cas d’utilisation
(vocabulaire UML). L’analyse fonctionnelle permettra de modéliser l’ensemble des cas
d’utilisation.
Pour l’informaticien, ce qui compte c’est l’architecture interne du système.
L’analyse fonctionnelle garantit qu’on va bien faire ce qui est demandé : répondre aux
exigences du client.
L’analyse organique garantit que ce qu’on va faire, on va bien le faire.
L’utilisateur et l’informaticien sont désignés différemment dans le vocabulaire de gestion
des projets comme suit.
Maître (Maîtrise) d'œuvre (MOE) ou l’informaticien: Personne physique ou morale qui
reçoit mission du maître d'ouvrage pour assurer la conception et la réalisation de l'ouvrage.
Maître (Maîtrise) d'ouvrage (MOA) ou l’utilisateur : Personne physique ou morale
propriétaire de l'ouvrage. Il détermine les objectifs, le budget et les délais de réalisation.
Note : Le mot informaticien est employé lorsque l’on traite des projets informatiques.
Ces différents points de vue entre l’utilisateur et l’informaticien sont résumés dans le
tableau 1.1.
Tableau 1.1 : Points de vue de l’utilisateur et de l’informaticien sur la réalisation d’un
système informatique
Analyse fonctionnelle Analyse organique

Point de vue de l’utilisateur Point de vue de l’informaticien
Point de vue du maître d’ouvrage Point de vue du maître d’œuvre
Point de vue de celui qui commande le Point de vue de celui qui réalise le
logiciel logiciel
Le QUOI Le COMMENT
Externe Interne
Build the right system Build the system right
Construire le bon système Construire bien le système
3.5.3. Troisième distinction : Analyse organique = Architecture système + Analyse détaillée

L’analyse organique se divise en deux parties :
L’architecture système (ou analyse organique générale): elle s’occupe de l’organisation des
sous-systèmes logiciels et matériels du système complet. C’est aussi à ce niveau qu’on
situera l’architecture des données.
L’analyse détaillée (ou analyse organique détaillée) : elle s’occupe du découpage en
procédure et en fonctions informatiques de chacun des sous-systèmes logiciels. A ce niveau
vont apparaître les en-têtes des fonctions, voire leurs pseudo-codes.
3.5.4. Quatrième distinction : les données et les traitements
Les trois distinctions précédentes sont centrées sur la question des traitements. La dernière
distinction est celle qui est faite entre les données et les traitements.
Les données seront analysées pour elle-même, indépendamment des traitements qu’on
leur appliquera.
Dans une approche « base de données », la distinction entre données et traitement sera
radicale. Dans une approche « orientée-objet », aux données, analysées pour elles-mêmes,
elles seront associées aux traitements de l’application (les méthodes des objets).
Avec la méthode MERISE et la programmation objet, les données sont revenues au
cœur de la conception des logiciels. C’est l’apport de la méthode systémique (système
d’information) par rapport à la méthode analytique (descendante) plus classique.
Le MCD (Modèle Conceptuel des Données) de MERISE et le diagramme des classes
d’UML sont les deux outils de conception qui permettent de faire une analyse systématique
des données.
3.6. Cycle de vie d’un logiciel
Le « cycle de vie d'un logiciel » (en anglais software lifecycle), désigne toutes les étapes
du développement d'un logiciel, de sa conception à sa disparition. L'objectif d'un tel
découpage est de permettre de définir des jalons intermédiaires permettant la validation du
développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la
vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en

œuvre.
L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus
élevé qu'elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie
permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais
de sa réalisation et les coûts associés.
3.6.1. Composition du cycle de vie d’un logiciel
Le cycle de vie d’un logiciel comprend généralement les activités suivantes :
 Définition des objectifs, consistant à définir la finalité du projet et son inscription dans
une stratégie globale,
 Analyse des besoins et faisabilité, c'est-à-dire l'expression, le recueil et la
formalisation des besoins du demandeur (le client ou MOA) et de l'ensemble des
contraintes,
 Conception générale. Il s'agit de l'élaboration des spécifications de l'architecture
générale du logiciel,
 Conception détaillée, consistant à définir précisément chaque sous-ensemble du
logiciel,
 Codage (Implémentation ou programmation), consiste en la traduction dans un
langage de programmation (Java, C++, VB, etc.) des fonctionnalités définies lors des
différentes phases de conception,
 Tests unitaires, permettant de vérifier individuellement que chaque sous-ensemble ou
module du logiciel est implémenté conformément aux spécifications,
 Intégration, dont l'objectif est de s'assurer de l'interfaçage des différents éléments
(modules) du logiciel. Elle fait l'objet de tests d'intégration consignés dans un
document,
 Qualification (ou recette), c'est-à-dire la vérification de la conformité du logiciel aux
spécifications initiales,
 Documentation, visant à produire les informations nécessaires pour l'utilisation du
logiciel et pour des développements ultérieurs,
 Mise en production, c’est la mise en exploitation du logiciel chez le client ou
l’utilisateur,
 Maintenance, comprenant toutes les actions correctives (maintenance corrective) et
évolutives (maintenance évolutive) sur le logiciel.
La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du
choix d'un modèle de cycle de vie entre le client et l'équipe de développement.
3.6.2. Différents modèles de cycle de vie
On distingue différents modèles de cycle de vie lors de la conception et de réalisation
d’un logiciel suivant la démarche de développement adopté entre le concepteur-développeur
du logiciel et le client.
3.6.2.1.Cycle de vie en cascade

Dans le cycle de vie en cascade, les étapes se succèdent dans le temps. Chaque étape
produit des documents qui sont utilisés pour en vérifier la conformité avant de passer à l’étape
suivante. Le cycle de vie en cascade est souvent schématisé de la manière suivante : En
utilisant le découpage définit ci-haut, on aurait ainsi le modèle de cycle de vie suivant
représenté par la figure 1.7.
Figure 1.7 : Modèle de cycle de vie en cascade

© Barry W. Boehm, A Spiral Model of Software Development and Enhancement, IEE
Computer, May 1988.
3.6.2.2.Cycle de vie en V
Le modèle de cycle de vie en V part du principe que les procédures de vérification de la
conformité du logiciel aux spécifications doivent être élaborées dès les phases de conception.
C’est une méthode de développement du logiciel. Dans cette méthode, la conception et la
réalisation forment les deux branches du cycle en V.
Figure 1.8 : Cycle de vie en V, Conception et réalisation

Ces deux étapes sont détaillées en reprenant les 3 distinctions abordées
précédemment et en ajoutant des distinctions dans la réalisation (Voir la figure 1.9).
Figure 1.9 : Cycle de vie en V, Conception et réalisation avec les détails

Conception = Analyse fonctionnelle + Architecture système + Analyse détaillée.
Réalisation = Codage + Tests unitaires + Tests d’intégration + Recette.
C’est le lien entre les étapes de chaque branche qui justifie le cycle en V.
Quand on fait l’analyse fonctionnelle, on peut préparer la procédure de recette.
Quand on fait l’architecture système, on peut préparer les tests d’intégration des sous-
systèmes.
Quand on fait l’analyse détaillée, on peut préparer les tests unitaires.
Ainsi, cela permettra-t-il, en cas de problème de test (unitaire, d’intégration ou de
recette), de revenir facilement à la partie de la conception à laquelle le problème correspond.
Cette démarche est illustrée par la figure 1.10.
Figure 1.10 : Cycle de vie en V, Conception et réalisation avec les détails et projection
entre les étapes
La figure 1.11 ci-dessous illustre un modèle de cycle de vie en V d’après Fichot et
Romain 1990.
Figure 1.11 : Modèle de cycle de vie en V
3.6.2.3.Cycle de vie en spirale

Le cycle de vie en spirale est un modèle générique de cycle de vie évolutif qui a été
proposé par Barry W. Boehm en 1984. Ce modèle, axé sur la maîtrise et la réduction des
risques, est davantage un cadre de travail guidant la construction d'une démarche spécifique
de projet, plutôt qu'une démarche formalisée.
Chaque boucle de spirale permet :
 d'identifier les objectifs propres de la boucle,
 d’identifier les moyens alternatifs pour atteindre les objectifs,
 de connaître les contraintes de chaque alternative.
Elle donne lieu au choix d'une alternative, validée par un prototype le cas échéant, et à
l'exécution de l'alternative choisie. A l'issue de la boucle, une revue des produits et des
résultats fournit une évaluation qui sert d'entrée pour la boucle suivante.
La dernière boucle est séquencée comme un cycle de vie en cascade. La figure 1.12 ci-
dessous présente un modèle de cycle de vie en spirale.
Figure 1.12 : Modèle de cycle de vie en spirale
3.7. Méthodes d'informatisation

Une méthode d'informatisation est composée :
 des modèles : ensembles de concepts et de règles destinés à expliquer et construire la
représentation de phénomènes organisationnels,
 des langages : pour élaborer les spécifications, et faciliter leur communication,
 une démarche : processus pour effectuer les travaux préconisés, étape par étape,
 des outils (AGL) ou techniques : pour aider à la mise en œuvre des trois composantes
ci-dessus (modèles, langages et démarche).
Une méthode est un mode d'emploi particulier d'un modèle. Elle dit comment observer
les éléments.
3.7.1. Méthode d'informatisation : règles
Les méthodes d’informatisation suivent un certain nombre de règles telles que :
 Appui sur des concepts théoriques : définition des concepts,
 Proposition d’une démarche : cadre général pour définir le travail à accomplir par les
intervenants,
 Possibilité pour sa mise en œuvre par des outils : pour faciliter la manipulation des
concepts,
 Atteinte d’un but : l’informatisation éventuelle (⇒ argumentation et faisabilité).
Note: une méthode ne remplace ni l’expérience, ni la connaissance, ni le talent.
3.7.2. Les avantages de l’utilisation des méthodes d’informatisation
L'emploi des méthodes d’informatisation doit permettre:
 de réduire la complexité du processus d'informatisation,
 d'offrir des moyens de pilotage dans la construction du système d'informatisation,

 de capitaliser les expériences et les solutions qui ont déjà fait leur preuve dans des
situations posant problème,
 de coordonner les projets (réduire les coûts et d'augmenter la productivité dans
l'accomplissement des tâches),
 la qualité de réalisation des étapes (garantie de pérennité) → tâches d'évolution plus
aisées,
 une diminution du nombre des anomalies : les corrections et la localisation se font plus
facilement ce qui implique que les tâches de maintenance sont moins onéreuses,
 une discipline commune au sein des équipes (définitions des rôles et des
responsabilités),
 un langage commun entre les intervenants (qualité des documentations, intégration
rapide d'une nouvelle personne formée à la méthode).
3.7.3. Typologie des méthodes d'informatisation
On utilise souvent deux critères de classification des méthodes d'informatisation :
 le type d'approche,
 les domaines d'application.
3.7.3.1.Types d'approche des problèmes d'informatisation
Suivant le type d’approche des problèmes d’informatisation, on distingue les méthodes
d’informatisation suivantes :
 les méthodes classiques,
 les méthodes cartésiennes (Exemple : SADT),
 les méthodes systémiques (Exemple : MERISE),
 les méthodes à objets (Exemple : UML).
Nous présenterons dans les sections qui suivent la classification des types
d'informatisation.
3.7.3.1.1. Méthodes classiques

Dans ce type de méthode, on adopte la spécification complète du système. Il faut alors
caractériser la totalité des données et traitements. Ce qui implique l’élaboration de plusieurs
vues à savoir:
 Entité/association → MERISE,
 Fonctions → SADT ou SA/RT.
Inconvénients:
 Systèmes figés (évolution de l’environnement),
 Perte de la sémantique du système (buts, comportements…).
3.7.3.1.2. Méthodes cartésiennes

Discours de la Méthode (1637) de René Descartes sous-titré "pour bien conduire sa
raison, et chercher la vérité dans les sciences"
Quatre règles méthodologiques:
 Le principe du doute: tout en se défaisant des opinions toutes faites, ne rien croire sans
preuve dûment perçue par soi-même, d'où éviter la précipitation,
 La règle de division: pour mieux résoudre un problème, il faut le décomposer,
 La gradation des difficultés: aller du plus simple au plus complexe,
 L'exhaustivité pour bien connaître un sujet.
Dans le système anglo-saxon, cette approche se réduit à une approche fonctionnelle.
 décomposition hiérarchique des processus et des flux de données (ou flux
d'information),
 analyse et conception du système d'information à partir de la définition des fonctions,
 processus d'analyse et de conception.
Un traitement de l'information répond aux règles de procédures de gestion pour produire
des sorties. La démarche de travail est descendante, "top-down" c’est-à-dire on part du
général pour aller vers le particulier. Elle débute par l'identification d'une fonction globale de
gestion. Toute fonction est décomposée en sous-fonctions, et ainsi de suite, par raffinements
successifs, jusqu'à ce que les ensembles élémentaires soient intelligibles.
Une représentation en arbre: les fonctions globalement perçues sont éclatées en processus
spécifiques. Les relations entre ces derniers sont également recherchées. Programmation
modulaire et décomposition fonctionnelle: S.A.D.T., J.S.D.
3.7.3.1.3. Méthodes systémiques
Les méthodes systémiques utilisent le concept de l’analyse systémique. Alors qu’est-ce que
l’analyse systémique ?
L’analyse systémique est l’analyse qui envisage les éléments d'une conformation complexe,
les faits (notamment les faits économiques), non pas isolément mais globalement, en tant que
parties intégrante d'un ensemble dont les différents composants sont dans une relation de
dépendance réciproque. Il existe neuf niveaux imbriqués de complexité selon cette théorie.
A chaque niveau, le système comporte tous les caractères du niveau inférieur.
Ces neuf (9) niveaux sont :
 l'objet passif et sans nécessité: niveau le plus simple de description,
 l'objet actif: connu par son activité, son comportement,
 l'objet actif régulé: le système peut refuser certains comportements possibles en
fonction de son comportement précédent,
 l'objet s'informe: régulation du système par l'intermédiaire de flux d'information,
 l'objet décide son activité: le système a un comportement non inévitable, c'est-à-dire
qui est le résultat d'une décision: 2 types d'informations: l'information-représentation et
l'information-décision,
 l'objet actif a une mémoire: le système peut avoir besoin de la représentation

d'événements passés,
 l'objet actif se coordonne: il existe au sein du système des processus de coordination,
 l'objet actif s'auto-organise: il est capable de s'adapter et d'inventer de nouvelles
organisations,
 l'objet actif s'auto-finalise: le système génère ses projets, détermine ses finalités.
3.7.3.1.4. Méthodes orientée-objet
Cette méthode utilise une spécification comme un système ouvert.
 Interface avec l’existant (communication avec l’homme),
 Caractérisation du comportement ou du but du système,
 Décomposition en sous-systèmes ou objets.
Cette démarche nécessite plusieurs vues.
Plusieurs vues : Comportement → UML
Buts → KADS.
3.7.3.2.Les domaines d'application des systèmes d’informatisation
Suivant les domaines d’application, on distingue les méthodes d’informatisation
suivantes :
 les méthodes d'élaboration de schémas directeurs (Exemple : RACINES),

 les méthodes de rédaction de cahiers des charges (Exemples : AROC, MUSCADE),
 les méthodes de conception des architectures techniques (Exemple : TACT),
 les méthodes de conception des systèmes d'information,
 les méthodes de programmation (XP),
 les méthodes de sécurité des systèmes (Exemple : MARION),
 les méthodes de conduite des projets (Exemples : GANTT, PERT, MCP).
CONCLUSION
Le présent chapitre a défini les différents concepts et a fait une généralité sur les
différentes méthodes d’informatisation telles les méthodes systémiques (MERISE) et les
méthodes orientées-objets (UML : qui est un langage de conception). Le chapitre suivant va
discuter essentiellement de la méthode d’informatisation MERISE parmi tous les types vus au
chapitre I et se focalisera sur les différents formalismes, les modèles MERISE et les
différentes règles de passage du MCD au MLDR.
CHAPITRE II : LES MODELES ET FORMALISMES DE MERISE
INTRODUCTION
La méthode MERISE a été créée en France dans les années 1970. Cette méthode utilise le
système dit d'entités-relations. Il s'agit d'un outil et d'une technique d'analyse permettant de
construire des schémas théoriques de raisonnement sur des applications tournant avec des
bases de données dites relationnelles (comme celles d'Access, de MySQL, de PostGreSQL,
etc.).
Les SGBD relationnels (SGBDR) sont les plus courants des SGBD jusqu'au début des
années 2000 ou alors la plupart des bases de données étaient relationnelles. Mais avec l'arrivée
des géants du numérique et du web, ces entreprises qui gèrent des quantités importantes de
données comme Facebook, Google, Amazon, Microsoft, il s'est développé un mouvement
important de développement de bases de données non-relationnelles, également dites NoSQL.
A noter que nous présenterons dans ce livre la méthode MERISE dans sa globalité,
puisque cette méthode existe en plusieurs versions : MERISE 1 et MERISE 2. L’introduction
sur MERISE 2 sera donnée au chapitre III.
1. PHASES DANS LA CREATION D’UN SYSTEME D’INFORMATION (SI)
La méthode d’informatisation MERISE considère quatre phases dans la création d'une
base de données à savoir : La phase d’analyse, la phase conceptuelle, la phase logique et la
phase physique.
1.1. La phase d'analyse
La phase d’analyse est une phase essentielle qui consiste à étudier l'existant : y-a-t-il un
système qui gère déjà tout ou partie de l'information, qu'il s'agisse d'un logiciel ou d'un
ensemble de documents papiers? Comment ces informations sont-elles stockées ? Quelles
sont les informations stockées? Que manque-t-il? Qu'est-ce qui convient ou ne convient pas
aux utilisateurs? Interroger les futurs utilisateurs : qu'attendent-ils du futur SGBD? Quelles
sont les opérations qu'ils désirent automatiser? Recueillir les informations existantes, étudier
les divers liens qui peuvent exister entre ces informations, mettre en évidence les règles de
gestion employées, … Des informations recueillies par l’équipe des concepteurs du nouveau
système ou base de données, elle passe à la phase conceptuelle dans laquelle elle essayera de
concevoir un système ou base de données qui résout les problèmes soulevés ou difficultés
liées à l’ancien système ou l’ancienne base de données.
1.2. La phase conceptuelle
Elle consiste à représenter l'organisation des données de manière générale. Elle aboutit
sur la création du modèle conceptuel des données (MCD) dans lequel les données sont
représentées sous forme d'entités liées entre elles par des relations. Les détails de conception
du MCD seront données dans la section ‘Les modèles de MERISE’.
1.3. La phase logique ou organisationnelle

Dans cette phase, la base de données est représentée sous une forme logique plus proche
de leur représentation réelle au sein du SGBD : les informations sont représentées uniquement
sous forme de tables au sein d'un modèle logique des données (Relationnelles) (MLD) ou
MLDR. Il faut retenir qu’on parle de MLDR dans le cas d’étude des SGBD relationnels à
l’instar du SGBD MySQL, SQL Server, Access, etc. Un SGBD relationnel est un SGBD qui
présente des informations sous forme de tables disposant des colonnes ou champs et des
lignes ou entrées. Dans la suite du document, les deux termes c’est-à-dire MLD et MLDR
auront la même signification et désigneront le modèle logique des données relationnelles
(MLDR). Les détails de conception du MLDR seront données dans la section ‘Les modèles de
MERISE’.
1.4. La phase physique ou opérationnelle
La phase physique est équivalente au Modèle Physique de Données (MPD ou MPhD)
dans la démarche MERISE. Elle est une suite de la démarche MERISE après le MLDR. A
cette étape, l’on doit avoir une connaissance avancée du SGBD à utiliser pour la réalisation de
la base de données. Elle consiste à construire réellement la base de données au sein du SGBD.
Cette partie fait l’objet d’un autre ouvrage.
A retenir
Les quatre phases de la méthode MERISE:

1. Analyse (étude de l'existant et enquête),
2. Conception (création du MCD),
3. Logique (création du MLD),
4. Physique (production de la base de données dans MySQL, PostGreSQL, MS Access,
etc.) ou MPhD dans la démarche MERISE.
Note : La base de données est un exemple de système d’information. Comme pour une base
de données, les mêmes démarches de conception et de réalisation s’appliquent à tous les
systèmes informatiques et d’information.
2. LES FORMALISMES
Les modèles MERISE utilisent des formalismes, une manière formelle et standard de
décrire le modèle. Nous donnons dans la suite de cette section les principaux formalismes
utilisés par la méthode MERISE.
2.1. Formalisme MCC
2.1.1. Diagramme de contexte
Le diagramme de contexte a pour but de représenter les flux d'informations entre
l'organisation et les acteurs externes selon une représentation standard dans laquelle chaque
objet porte un nom.
 l'organisation est représentée par un rectangle,
 les acteurs externes sont représentés par des ellipses en pointillés,
 les flux d'information sont représentés par des flèches dont l'orientation désigne le sens
du flux d'information.
La figure 2.1 ci-dessous montre un exemple de représentation d’un diagramme de
contexte.
Figure 2.1 : Diagramme de contexte
2.1.2. Diagramme conceptuel de flux

Ce diagramme (appelé aussi modèle conceptuel de la communication) permet de
compléter le diagramme de contexte en décomposant l'organisation en une série d'acteurs
internes. Dans ce diagramme, la représentation standard est la suivante :
 les acteurs internes sont représentés par des ellipses,
 les messages internes sont représentés par des flèches.
Cette représentation est illustrée par la figure 2.2 ci-dessous.
Figure 2.2 : Représentation type d’un diagramme conceptuel de flux
MCC : Exemple
Soit le service de payement en ligne offert par l’entreprise représentée ci-dessous.
Voici l’établissement du MCC qui illustre les échanges de flux depuis l’ordre de livraison à
l’avis d’encaissement.
Figure 2.3 : Un exemple de MCC simplifié
2.2. Formalisme MCD

2.2.1. Entités et classe d'entité
Une entité est la représentation d'un élément matériel ou immatériel ayant un rôle dans le
système que l'on désire décrire.
On appelle classe d'entité un ensemble composé d'entités de même type, c'est-à-dire dont
la définition est la même. Le classement des entités au sein d'une classe s'appelle
classification (ou abstraction). Une entité est une instanciation de la classe. Chaque entité est
composée de propriétés, données élémentaires permettant de la décrire.
Prenons par exemple une Ford Fiesta, une Mazda, une Renault Laguna et une Peugeot
306. Il s'agit de 4 entités faisant partie d'une classe d'entité que l'on pourrait appeler voiture.
La Ford Fiesta est donc une instanciation de la classe voiture. Chaque entité peut posséder les
propriétés couleur, année et modèle.
Les classes d'entités sont représentées par un rectangle. Ce rectangle est séparé en deux
champs :
 le champ du haut contient le libellé. Ce libellé est généralement une abréviation pour
une raison de simplification de l'écriture. Il s'agit par contre de vérifier qu'à chaque
classe d'entité correspond un et un seul libellé, et réciproquement,
 le champ du bas contient la liste des propriétés de la classe d'entité.
La figure 2.4 montre un exemple de représentation d’une classe d’entité.
Libellé
Identifiant
Propriété1
Propriété2
…
Figure 2.4 : Exemple de représentation d’une classe d’entité
2.2.2. Relations et classes de relation
Une relation (appelée aussi parfois association) représente les liens sémantiques qui
peuvent exister entre plusieurs entités. Une classe de relation contient donc toutes les relations
de même type (qui relient donc des entités appartenant à des mêmes classes d'entité). Une
classe de relation peut lier plus de deux classes d'entité. Voici les dénominations des classes
de relation selon le nombre d'intervenants.
 une classe de relation récursive (ou réflexive) relie la même classe d'entité,
 une classe de relation binaire relie deux classes d'entité,
 une classe de relation ternaire relie trois classes d'entité,
 une classe de relation n-aire relie n classes d'entité.
Les classes de relations sont représentées par des hexagones (parfois des ellipses) dont
l'intitulé décrit le type de relation qui relie les classes d'entité (généralement un verbe). On
définit pour chaque classe de relation un identificateur de la forme Ri permettant de désigner
de façon unique la classe de relation à laquelle il est associé.
La représentation d’une relation (ici relation faire) est illustrée par la figure 2.5.
Ri
CLE1 Faire CLE2
… …
Figure 2.5 : Représentation d’une relation (ou classe de relation)
On peut éventuellement ajouter des propriétés aux classes de relation.

2.2.3. La cardinalité
Les cardinalités permettent de caractériser le lien qui existe entre une entité et la relation à
laquelle elle est reliée. La cardinalité d'une relation est composée d'un couple comportant une
borne maximale et une borne minimale, intervalle dans lequel la cardinalité d'une entité peut
prendre sa valeur :
 la borne minimale (généralement 0 ou 1) décrit le nombre minimum de fois qu'une
entité peut participer à une relation,
 la borne maximale (généralement 1 ou n) décrit le nombre maximum de fois qu'une
entité peut participer à une relation.
La figure 2.6 ci-dessous illustre comment placer les cardinalités
x:n x:n
Entité A Entité B
Relation IdB
IdA
…… ……
Figure 2.6 : Cardinalités entre deux classes d’entité

 Une cardinalité 1 : n signifie que chaque entité appartenant à une classe d'entité
participe au moins une fois à la relation.
 Une cardinalité 0 : n signifie que chaque entité appartenant à une classe d'entité ne
participe pas forcément à la relation.
2.2.4. Les identifiants
Un identifiant est un ensemble de propriétés (une ou plusieurs) permettant de désigner une
et une seule entité (une instance ou occurrence). La définition originale est la suivante :
L'identifiant (ou clé primaire dans la phase physique) est une propriété particulière d'un
objet telle qu'il n'existe pas deux occurrences de cet objet pour lesquelles cette propriété
pourrait prendre une même valeur.
Les attributs d'une classe d'entité permettant de désigner de façon unique chaque instance
de cette entité sont appelés identifiants absolus. Le modèle conceptuel des données propose de
faire précéder d'un # les identifiants (parfois de les souligner).
CLE
Identifiant
Propriété1
Propriété2
…
Figure 2.7 : Présentation d’un identifiant au sein d’une classe d’entité

Ainsi, chaque classe d'entité doit posséder au moins un attribut identifiant, et l'ensemble de
ses attributs identifiants doivent être renseignés à la création de l'entité.
2.2.5. Agrégation (ou identification relative)
Lorsqu'un identifiant est constitué uniquement d'attributs intrinsèques à une entité, c'est-à-
dire ne faisant référence à aucune autre entité, on le nomme identifiant absolu. Les entités
comportant des identifiants absolus peuvent être définies indépendamment des autres
occurrences d'entités, on dit que ces entités sont indépendantes.
Certaines entités ne peuvent toutefois être identifiées que par l'intermédiaire d'autres
entités, c'est la raison pour laquelle on parle d'identification relative. On parlera par exemple
de la 4ème porte au 2ème étage du bâtiment B au lieu de dire la porte n°3451...
Ainsi, l'agrégation (appelée aussi identification relative) permet de spécifier qu'une entité
est nécessaire pour en identifier une autre.
 la classe d'entité permettant d'identifier est appelée classe d'entité agrégeante.
 la classe d'entité identifiée est appelée classe d'entité agrégée.
La représentation de ce type de relation est donnée par la figure 2.8.
Figure 2.8 : Représentation d’une agrégation
MCD : Exemple de représentation globale
Figure 2.9 : Exemple de représentation globale d’un MCD
2.2.6. MCD : Règles (les formes normales et de BOYCE CODD)

Les formes normales et de BOYCE-CODD de la méthode MERISE précisent les règles à
appliquer lors de l’élaboration d’un MCD pour obtenir un MCD optimal, c’est-à-dire éviter
par exemple le problème de redondance de données lors de l’implémentation de la base de
données, réduire le nombre de relations ou de tables en minimisant ainsi la taille de la base de
données. Ces règles permettent également d’éviter de faire apparaître dans une entité les
propriétés autres que celles qui appartiennent à l’entité elle-même.
On distingue trois (3) formes normales et la forme normale de BOYCE-CODD.
1ère forme normale et 2ème forme normale
Soit la table LigneCommande suivante :
Figure 2.10 : Table LigneCommande, MCD mal élaboré
Règle : En appliquant la 1ère et la 2ème formes normales, on obtient ce qui suit :
Figure 2.11 : scission de la table LigneCommande en table LigneCommande et produit

En effet, dans la table LigneCommande, les propriétés Ref_Produit et Désignation
n’appartiennent pas à l’entité LigneCommande. Dans ce cas, les deux premières règles
exigent la création d’une entité à laquelle appartiennent ces propriétés. La quantité étant
commune aux deux entités, il est recommandé qu’elle (quantité) soit une propriété de la
relation ‘Concerne’.
3ème forme
Soit la table Client suivante :
Figure 2.12 : Table Client, MCD mal élaboré

Règle : En appliquant la 3ème forme normale, on obtient ce qui suit :
Figure 2.13 : scission de la table Client en table Client et Catégorie
En effet, il apparaît clairement que les propriétés Catégorie Code et Catégorie Nom
n’appartiennent pas à l’entité Client. Il est donc clair qu’il faut créer l’entité Catégorie.
Forme normale de BOYCE-CODD

Soit la table cours suivante :
Figure 2.14 : Table Cours, MCD mal élaboré

Règle : En appliquant la forme normale de BOYCE-CODD, on obtient ce qui suit :
Figure 2.15 : scission de la table Cours en table Professeur et Classe

Ces quatre (4) règles sont à observer lors de l’élaboration d’un Modèle Conceptuel de
Données (MCD).
2.3. Formalisme MCT
2.3.1. Le concept d'évènement
Un événement représente un changement dans l'univers extérieur au système d'information,
ou dans le système d'information lui-même.
 un évènement externe est un changement de l'univers extérieur,
 un évènement interne est un changement interne au système d'information.
On représente un évènement par une ellipse en trait plein pour les évènements internes à
l'organisation, en trait pointillé pour les évènements externes (voir la figure 2.16 ci-dessous).
Figure 2.16 : Représentation des événements internes et externes

2.3.2. Concept de processus
Un processus est un sous-ensemble de l'activité de l'entreprise, cela signifie que l'activité
de l'entreprise est constituée d'un ensemble de processus. Un processus est lui-même composé
de traitements regroupés en ensembles appelés opérations.
2.3.3. Opération
Une opération est un ensemble d'actions exécutées par le système suite à un événement,
ou à une conjonction d'événements. Cet ensemble d'actions est ininterruptible, c'est-à-dire que
les événements ne sont pas pris en compte (ils ne sont pas forcément ignorés pour autant) tant
que l'opération n'a pas été accomplie.
2.3.4. La synchronisation
La synchronisation d'une opération définit une condition booléenne sur les événements
contributifs devant déclencher une opération. Il s'agit donc de conditions au niveau des
événements régies par une condition logique réalisée grâce aux opérateurs :
 OU
 ET
 NON
2.3.5. Construction du MCT
Le modèle conceptuel des traitements permet de représenter schématiquement la gestion
des évènements. La figure 2.17 illustre deux modèles de représentation d’un MCT (Modèle
Conceptuel des Traitements).
Figure 2.17 : Représentation générale d’un MCT
MCT : Exemple
Cet exemple illustre l’approvisionnement en coke d’une entreprise X chez un fournisseur

Y. A une commande donnée correspond à trois traitements différents possibles à savoir :
 La coke est en stock, on retourne un ordre de livraison,
 Pas de coke en stock, deux possibilités se présentent à l’entreprise X, soit elle relance la
commande de coke, soit elle lance une nouvelle commande pour demander un produit
de substitution.
Cette description est illustrée par la figure 2.18.
Figure 2.18 : MCT, un exemple simplifié

2.4. Formalisme MLD
Le modèle logique des données consiste à décrire la structure de données utilisée sans
faire référence à un langage de programmation. Il s'agit donc de préciser le type de données
utilisées lors des traitements.
Ainsi, le modèle logique est dépendant du type de base de données utilisé.
Le modèle relationnel
2.4.1. Traduction d'une classe d'entité
Chaque classe d'entité du modèle conceptuel devient une table dans le modèle logique.
Les identifiants de la classe d'entité sont appelés clés de la table, tandis que les attributs
standards deviennent des attributs de la table, c'est-à-dire des colonnes.
2.4.2. Traduction d'une classe de relation
Le passage du modèle conceptuel au modèle logique au niveau des classes de relation se
fait selon les cardinalités des classes d'entité participant à la relation :
 Si une des classes d'entités possède une cardinalité faible : la table aura comme
attributs, les attributs de la classe ayant une cardinalité faible, puis le (ou les) attribut(s)
de relation et enfin les attributs de la seconde classe précédé du nom de la classe.
 Si les deux classes d'entités possèdent une cardinalité forte : la table aura comme
attributs, les attributs des deux classes de relation précédés des noms des classes
respectives, puis le (ou les) attribut(s) de relation.
2.4.3. Traduction d'une classe d'agrégation
Dans le cas de la présence d'une classe d'agrégation, la classe d'entité agrégée a comme
attributs supplémentaires les attributs de la classe d'entité agrégeante.
2.5. Formalisme MOT

Le modèle organisationnel des traitements s'attache à décrire les propriétés des
traitements non traitées par le modèle conceptuel des Traitements, c'est-à-dire :
 le temps,
 les ressources,
 le lieu,
 Etc.
Le modèle organisationnel des traitements consiste donc à représenter le modèle
conceptuel des traitements dans un tableau dont les colonnes sont la durée, le lieu, les
responsables et les ressources nécessaires à une action.
2.5.1. Le tableau des procédures fonctionnelles
La première étape du modèle organisationnel des traitements consiste à découper les
opérations en procédures fonctionnelles, une succession de traitements déclenchée par un
évènement.
Il s'agit d'associer dans un tableau:
 les procédures fonctionnelles,
 l'heure de début et de fin (Période),
 la nature,
 le lieu du poste de travail,
 le responsable du poste de travail,
 les ressources du poste de travail.
2.5.2. Représentation du MOT
La représentation du MOT est illustrée par le tableau 2.1 ci-dessous.
Tableau 2.1 : Représentation d’un MOT.

3. LES MODELES DE MERISE
A chaque niveau de la conception du système d'information, un modèle est élaboré. Il
permet de décrire le système au niveau de conception considérée. Sachant que la
communication, les données et les traitements sont examinés, on a les modèles suivants :
 Au niveau conceptuel : Le Modèle Conceptuel de la Communication (MCC), le
Modèle Conceptuel des Données (MCD), le Modèle Conceptuel des Traitements
(MCT).
 Au niveau Organisationnel : Le Modèle Logique des Données (MLD), le Modèle
Logique des Traitements (MLT) ou Modèle Organisationnel des Traitements (MOT).
 Au niveau physique : Le modèle Physique des Données (MPD ou MPhD), le Modèle

Opérationnel des Traitements (MOT ou MOpT).
3.1. Les modèles de la communication
Le modèle conceptuel de la communication est généralement le seul modèle utilisé dans ce
cadre.
3.1.1. Diagramme de contexte
Le diagramme de contexte a pour but de représenter les flux d'informations entre
l'organisation et les acteurs externes selon une représentation standard dans laquelle chaque
objet porte un nom.
 l'organisation est représentée par un rectangle,
 les acteurs externes sont représentés par des ellipses en pointillés,
 les flux d'information sont représentés par des flèches dont l'orientation désigne le sens
du flux d'information.
3.1.2. Le Modèle Conceptuel de la Communication (MCC) ou Diagramme conceptuel de flux
Le MCC (Modèle conceptuel de la communication) définit les flux d'informations à
prendre en compte. La première étape de ce modèle est d'arriver à isoler le système en le
délimitant.
 Il s'agit donc de définir le système et les éléments externes avec lesquels il échange des
flux d'information. Ces éléments extérieurs sont appelés acteurs externes (ou
partenaires).
 La seconde étape consiste à découper l'organisation en entités appelées acteurs internes
(ou domaines). Lorsque les domaines d'une organisation sont trop importants, ils
peuvent être décomposés eux-mêmes en sous-domaines.
 La dernière étape est l'analyse des flux d'information, c'est-à-dire la définition des
processus.
3.2. Les modèles de données
C'est la représentation schématique d'un ensemble de données relatives aux phénomènes
qui présentent de l'intérêt pour une application.
On retrouve trois niveaux de modèles de données dans la démarche MERISE à savoir.
 le modèle conceptuel de données,
 le modèle logique de données, appelé aussi modèle fonctionnel de données,
 le modèle physique de données.
3.2.1. Modèle Conceptuel de données (MCD)
Après la phase d'analyse, nous pouvons commencer à représenter les informations sous
forme conceptuelle. Le Modèle Conceptuel de Données (MCD) que nous allons construire
contient deux éléments principaux : les entités et les relations.
Une entité est un élément du problème. Elle est définie par un ensemble de propriétés.
Chacune des propriétés est l'un des éléments qui caractérise l'entité. Il faut distinguer une
entité et une occurrence d'entité (ou instance). Une entité correspond au type général d'une
donnée (exemple: le type "employé") alors qu'une occurrence d'une entité est un représentant
particulier de cette entité (l'employé "David AMAH").
Une relation est un lien possible qui relie deux entités. Par exemple, si un employé peut être
affecté à un entrepôt, il y aura une relation "affectation" entre l'entité entrepôt et l'entité
"employé". Cela ne signifie pas nécessairement qu'il y aura affectation pour chacun des
employés, juste qu'il est possible qu'un employé soit affecté à un entrepôt. Une relation peut
éventuellement être reliée à plus de deux entités et peut avoir certaines propriétés.
Après avoir fait une analyse aussi complète que possible du problème à informatiser, la
construction du MCD se fait en quatre étapes :
 repérage des entités,
 construction des entités, choix des propriétés,
 construction des relations,
 choix des cardinalités.
3.2.1.1. Repérage des entités
Une entité est un composant du problème : une personne, une facture, un livre, ... C'est la
représentation d'un objet matériel ou immatériel pourvu d'une existence propre et conforme
aux choix de gestion de l'entreprise. Comme dit plus haut, ce que l'on considère comme entité
est un type général (exemple: l'entité personne représente toutes les personnes) à ne pas
confondre avec une occurrence d'entité (David AMAH étant une personne, on le considère
comme une occurrence de l'entité personne). Une entité doit avoir une existence
indépendamment de toute autre entité.
Exemple : On considère le problème suivant :
Un libraire gère des œuvres littéraires. Une œuvre est une création littéraire.
Une œuvre a au moins un auteur et est dans une édition (un livre). Une édition possède un
ISBN unique et a un unique éditeur. Elle peut contenir plusieurs œuvres. On veut mémoriser
pour chaque édition le nombre d'exemplaires en stock et pour chaque exemplaire son état.
Dans ce problème, les entités sont :
 l'entité "œuvre" : Une création littéraire, un récit...

 l'entité "auteur" : une personne créatrice d'œuvre,
 l'entité "édition" : un livre contenant une ou plusieurs œuvres littéraires,
 l'entité "éditeur" : la société qui va imprimer les livres,
 l'entité "exemplaire" : un exemplaire physique de livre.
L'ISBN, par exemple, n'est pas une entité puisqu'il s'agit d'un élément qui caractérise l'entité
"édition".
3.2.1.2. Construction des entités
L'étape suivante correspond à la construction des entités. On commence par donner un
nom à chacune des entités. Il faut ensuite rechercher les propriétés de ces entités. On devra
garder à l'esprit les points suivants :
 Toute propriété est élémentaire (elle n'est pas la composition d'éventuelles propriétés
plus petites),
 Une propriété ne doit pas être "instable" ou "calculable" : si une propriété peut être
obtenue par calcul à partir d'autres éléments qui vont apparaître dans la base de données
(notamment d'autres propriétés), on ne doit pas la considérer,
 Toute entité doit posséder une propriété particulière appelée sa clé (ou identifiant). Une
clé doit caractériser de manière unique chaque occurrence de l'entité. Par exemple, le
nom de famille d'une personne ne peut pas être considéré comme une clé d'une entité
"personne" puisque deux personnes peuvent avoir le même nom de famille. Le numéro
de sécurité sociale est par contre tout à fait acceptable. Il vaut mieux éviter les
identifiants trop longs (on préférera un code de quelques chiffres à un intitulé d'une
vingtaine de lettres par exemples),
 Si aucune des propriétés "naturelles" ne peut servir de clé, on en rajoute une
artificiellement (par exemple "CodeLivre" ou "IdEmployé"). On parle alors de clé
artificielle.
 Chaque propriété ne doit dépendre que d'une seule entité.
Une entité se représente ensuite graphiquement sous la forme d'une boîte dans laquelle on
indique en titre le nom de l'entité suivi de toutes ses propriétés. On indique d'une manière
particulière l'identifiant. La figure 2.19 illustre la représentation d’une classe d’entité dans le
Modèle Conceptuel des Données (MCD).
Note : Pour simplifier, la classe d’entité sera appelée tout simplement entité et les entités
des occurrences ou tuples dans la suite de ce livre.
Entité
Identifiant
Propriété1
Propriété2
…
Figure 2.19 : Représentation d’une entité au sein d’un MCD

Exemple : Dans l'exemple du libraire, on peut construire les entités suivantes (les propriétés
sont indiquées après le nom de l'entité, l'identifiant est en gras) :
 œuvre : IdOeuvre, titre
 Auteur : IdAuteur, nom, prénom
 Edition : ISBN, titre, nb pages
 Editeur : IdEditeur, nom
 Exemplaire : IdExemplaire, état.
Notons que, dans le cas de l'édition, l'ISBN est un identifiant tout à fait acceptable. Dans
les autres cas, aucune des propriétés ne convenant comme identifiant, il a fallu créer une
propriété particulière appelé identifiant artificiel pour cet effet (Id...).
3.2.1.3. Construction des relations
L'étape suivante consiste à énumérer toutes les relations possibles entre entités. Si une
relation a une chance d'apparaître (et de nous intéresser), alors on doit la considérer dans le
MCD. On parle également parfois d'association.
La représentation d’une relation (ici relation faire) est illustrée par la figure 2.20.
Entité A Faire Entité B

… …
Figure 2.20 : Représentation d’une relation au sein d’un MCD

On notera les points suivants :
 Une relation est en général entre deux entités. Il est possible d'avoir une relation entre
plus que deux entités. Par exemple, une relation Vente entre Acheteur, Vendeur et Lieu
pour une base de données de transaction immobilière. Il est néanmoins souvent possible
(et préférable !) de se restreindre à des relations entre deux entités. Dans le cas ici, la
relation Vente pourrait être remplacée par une entité Acte de vente qui est en relation
avec l'acheteur, le vendeur et le lieu.
 Il est tout à fait possible d'avoir plusieurs relations entre deux entités.
 Il est également possible d'avoir une relation dite réflexive, c'est-à-dire entre une entité
et elle-même. Par exemple, on peut avoir une relation Responsable entre une table
employé et elle-même. Dans ce cas, il convient tout de même de remarquer que chacune
des "pattes" de la relation a une signification différente. Ici, l'une des "pattes" signifiera
est "responsable de" et l'autre signifiera "a comme responsable".
 Une relation peut avoir des propriétés. Par exemple, si une relation lie l'entité Facture et
l'entité Produit, elle possède certainement la propriété "quantité" (une facture contient
un produit x en quantité y). D'ailleurs, si une propriété dépend de plus d'une entité
(comme c'est le cas ici avec la quantité qui dépend à la fois de la facture et du produit),
c'est certainement qu'elle dépend d'une relation, et non pas d'une entité.
 Il faut éviter les relations que l'on peut déduire d'autres relations par transitivité. Par
exemple, dans une base de données gérant une université, si on dispose d'entités
étudiant, formation et cours. On a les relations fait partie entre formation et cours (un
cours fait partie d'une formation) et inscription entre étudiant et formation. Il est inutile
d'avoir en plus une relation inscription entre étudiant et cours : tout étudiant inscrit à
une formation est systématiquement inscrit à tous les cours qui composent la formation.
Exemple : Solution : Dans l'exemple du libraire, on a les relations suivantes représentées par
la figure 2.21.
Figure 2.21 : Construction des relations : Cas du libraire

3.2.1.4. Choix des cardinalités
Une fois les relations établies, il convient ensuite de caractériser le nombre de fois où
chacune de ces relations peut apparaître réellement. Ceci se fait à l'aide des cardinalités. Dans
une relation classique (c’est-à-dire entre deux entités), quatre cardinalités sont à déterminer.
La figure 2.22 présente comment placer les cardinalités dans un Modèle Conceptuel de
Données (MCD).
Figure 2.22 : Choix et emplacement de cardinalités

 minA est le nombre minimal de fois où une occurrence de l'entité A participe à une
relation du type considéré. Il s'agit en général de 0 ou 1.
 maxA est le nombre maximal de fois où une occurrence de l'entité A participe à la
relation. Il s'agit en général de 1 ou n (n pour plusieurs fois, ou un nombre quelconque de
fois).
 minB et maxB fonctionnent de la même manière, mais en considérant l'entité B.
Notons qu'il est souvent difficile de choisir entre une cardinalité de type 0 : n et une
cardinalité de type 1 : n. Il est important de noter que ce choix a souvent peu d'importance.
Exemple : Dans l'exemple du libraire, considérons la relation édite qui existe entre les entités
éditeur et édition. Ainsi, dans l'exemple du libraire, une édition (un livre) a toujours un et un
seul éditeur (soit un minimum de un éditeur, et un maximum de un éditeur). Un éditeur par
contre peut éditer au minimum une édition et au maximum plusieurs éditions (un nombre
quelconque de fois). Après le choix des noms des entités, de la relation et des cardinalités, il
faut représenter le MCD complet de la base de données. Le MCD partiel entre deux entités est
illustré par la figure 2.23 tandis que la figure 1.6 illustre le MCD complet du système.
Figure 2.23 : Le MCD partiel
Figure 2.24 : Le MCD complet: Cas du libraire

3.2.1.5. Cas particuliers et pièges
Quelques points particuliers sont à garder à l'esprit lors de la réalisation d'un MCD.
 Un identifiant est obligatoire pour chaque entité.
 Il ne doit pas y avoir de redondance d'informations : une information quelconque ne
doit pas être représentée plus d'une fois dans le MCD.
 Evitez autant que possible les relations entre plus de deux entités. Souvent, il est
possible de remplacer la relation par une entité.
 Restez dans la mesure du possible avec des cardinalités de valeurs 0, 1 ou n. Il est de
toute manière souvent possible de se ramener à ce cas dans les rares cas où des
cardinalités d'un autre type semblent plus naturelles.
 Dans l'idéal, il faut trouver un bon compromis entre niveau de détail et "taille" de la
base de données. Il est toujours possible de multiplier les entités, mais il vaut mieux le
faire que si cela a vraiment du sens et un intérêt dans le problème. Par exemple, si on a
une entité personne, on peut considérer l'adresse comme une entité séparée (reliée à
personne par une relation "habite à") ou comme une propriété de la personne (ce qui est
fait usuellement). En règle générale, il est plus économique de définir l'adresse comme
une propriété, mais dans un cas où il est courant que des personnes habitent au même
endroit, la règle de non-redondance incite plutôt à utiliser une nouvelle entité.
A retenir
La méthode générale de construction du MCD :
1. recherche des entités,
2. recherche des propriétés (dont la clé de chaque entité),
3. recherche des relations entre entités,
4. recherche des cardinalités (0:1, 1:1, 0:n ou 1:n)
3.2.2. Le modèle logique des données (MLD)

Le Modèle Logique des Données (MLD) reprend le contenu du MCD précédent, mais
précise la volumétrie, la structure et l'organisation des données telle qu'elles pourront être
implémentées. Il s'agit du passage entre le Modèle Conceptuel de Donnée et l'implémentation
physique de la base. Par exemple, à ce stade, il est possible de connaître la liste exhaustive des
tables qui seront créées dans une base de données relationnelle. Le MLD est lui aussi
indépendant du matériel et du logiciel, il ne fait que prendre en compte l'organisation des
données. C'est d'ailleurs le point primordial de la modélisation : si l'organisation des données
est relationnelle (si elles sont "liées" entre elles), alors le MLD est Relationnel et devient le
MLDR, ou Modèle Logique de Données Relationnelles.
Le MLD est une transcription (également appelée dérivation) du MCD dans un
formalisme adapté à une implémentation ultérieure, au niveau physique, sous forme de base
de données relationnelle ou réseau, ou autres (exemple: simples fichiers).
La transcription d'un MCD en modèle relationnel s'effectue selon quelques règles simples
qui consistent d'abord à transformer toute entité en table, avec l'identifiant comme clé
primaire, puis à observer les valeurs prises par les cardinalités maximum de chaque
association pour représenter celle-ci soit (exemple: cardinalité max 1-n ou 0-n) par l'ajout
d'une clé étrangère dans une table existante, soit (exemple: cardinalité max n-n) par la
création d'une nouvelle table dont la clé primaire est obtenue par concaténation de clés
étrangères correspondant aux entités liées.
Exemple 1
x:1 x:n
Entité A Entité B
Relation
IdA IdB
…… ……
Figure 2.25 : Exemple de règles de passage du MCD au MLDR
Se transforme en :
Entité A Entité B
IdA
IdB
#IdB
……
……
Figure 2. 26 : Importation de clé primaire du côté x:n vers le côté x:1

A noter que la clé importée (ici IdB qui se retrouve dans la table A) ne devient pas une clé
de la table : c'est une propriété comme une autre. Notons aussi que le lien se fait entre champs
(on relie IdA à IdB) et non pas, comme dans le MCD, entre les tables. IdB est appelée clé
étrangère (foreign key) dans la table Entité A.
Exemple 2
x :n x:n
Entité A Entité B
Relation IdB
IdA
…… ……
Figure 2.27 : Les autres cas de figures du MCD que l’on peut rencontrer
Se transforme en :
Entité A Entité B
IdA IdB
…… Relation
……
#IdA
#IdB
Figure 2.28: La relation devient une table avec comme clé primaire la concaténation des
clés des deux tables
Les opérateurs de l'algèbre relationnelle (projection, sélection, jointure, opérateurs
ensemblistes), le langage d'interrogation des données peuvent ensuite directement s'appliquer
sur le modèle relationnel ainsi obtenu et normalisé en utilisant les différentes formes
normales.
Cette démarche algorithmique ne fournit pas à ce niveau d'élément sur l'optimisation de la
durée ou des ressources nécessaires pour exécuter les traitements dans l'environnement de
production cible.
La transcription du MCD en MLD doit également être précédée d'une étape de
synchronisation et de validation des modèles de données (MCD) et de traitement (MCT et
MLT), au moyen de vues. Cela afin d'y introduire les informations d'organisation définies au
MLT, d'éliminer les propriétés conceptuelles non utilisées dans les traitements ou redondantes
et enfin de vérifier que les données utilisées pour un traitement sont bien atteignables par
'navigation' entre les entités/relations du MCD.
3.2.3. Le modèle Physique des données (MPD ou MPhD)
Le MPD permet de préciser les systèmes de stockage employés. Les données qui sont
stockées et gérées dans un ordinateur le sont souvent par un système de gestion de base de
données (SGBD). Le MPD est l'implémentation du MLD dans le SGBD retenu.
Une fois le système d'information analysé et modélisé en Modèle Conceptuel de Donnée
(MCD), et après être passé par le Modèle Logique de Données Relationnelles (MLDR), nous
arrivons au Modèle Physique de Données (MPD). Il s'agit maintenant de créer la base de
données correspondante à l'étude entamée. C'est à ce stade seulement que le système de
gestion de base de données choisi intervient.
Le SQL (Structured Query Language), ou Langage d'Interrogation Structuré, a été
reconnu en tant que norme officielle de langage de requête relationnelle. Toutefois, les
syntaxes d'extraction des données et de création des tables varient quelques peu d'un système
de gestion de base de données à l'autre.
Le modèle physique consiste donc à ressortir le script SQL de création des tables en
précisant la longueur des champs et les différentes clés.
Ensuite, il faudra évaluer le poids global de la base de données et faire une projection sur
un certain nombre d’années. Ce qui permet de tabler sur la capacité du disque requise pour
l’exploitation de la base de données pendant cette période.
Des exemples de logiciels supportant MERISE sont :
 JMerise,
 AMC Designer,
 TRAMIS,
 SELECT.
Il faut noter que de nos jours, il existe une large gamme de logiciels supportant MERISE.
Un exemple en est MySQL Workbench. Le livre vous présente une liste également non
exhaustive des logiciels pour l’élaboration du MCD dans le chapitre III. Ces logiciels
supportent soit MERISE soit UML.
3.3. Les modèles des traitements
Si les modèles de données se penchent sur l'aspect statique, les modèles des traitements
s'occupent de l'aspect dynamique. Ils portent sur les "manipulations" que subissent les
données. On en distingue également trois :
 le modèle conceptuel des traitements,
 le modèle organisationnel des traitements,
 le modèle opérationnel des traitements.
3.3.1. Le modèle conceptuel des traitements (MCT)
Le Modèle Conceptuel des Traitements est un schéma représentant les traitements, en
réponse aux événements à traiter (par exemple : la prise en compte de la commande d'un
client). Le MCT repose sur les notions d'événements et d'opérations, celle de processus en
découle.
3.3.1.1. L'évènement
Un évènement est assimilable à un message porteur d'informations donc potentiellement
de données mémorisables (par exemple : l'événement 'commande client à prendre en compte'
contient au minimum l'identification du client, les références et les quantités de chacun des
produits commandés).
Un évènement peut :
 déclencher une opération (exemple: 'commande client à prendre en compte' déclenche
l'opération 'prise en compte commande'),
 être le résultat d'une opération (exemple: 'colis à expédier' suite à l'opération de
'préparation colis'), et à ce titre être, éventuellement, un évènement déclencheur d'une
autre opération.
3.3.1.2. L'opération
Une opération se déclenche uniquement par le stimulus d'un ou de plusieurs évènements
synchronisés. Elle est constituée d'un ensemble d'actions correspondant à des règles de
gestion de niveau conceptuel, stables pour la durée de vie de la future application (exemple:
pour la prise en compte d'une commande : vérifier le code client (présence, validité), vérifier
la disponibilité des articles commandés, ...).
Le déroulement d'une opération est ininterruptible : les actions à réaliser en cas
d'exceptions, les évènements, résultats correspondants doivent être formellement décrits
(exemple: en reprenant l'exemple précédent, si le code client indiqué sur la commande est
incorrect prévoir sa recherche à partir du nom ou de l'adresse indiqués sur la commande, s'il
s'agit d'un nouveau client, prévoir sa création et les informations à mémoriser, ...).
3.3.1.3. Le processus
Un processus est une vue du MCT correspondant à un enchaînement pertinent
d'opérations du point de vue de l'analyse (exemple: l'ensemble des évènements et opérations
qui se déroulent entre la prise en compte d'une nouvelle commande et la livraison des articles
au client).
3.3.2. Le modèle organisationnel des traitements (MOT) ou MLT (modèle logique des
traitements)
Le MOT décrit avec précision l’organisation à mettre en place pour réaliser une, ou le cas
échéant plusieurs opérations figurant dans le MCT, c’est-à-dire qui fait quoi, où, quand,
comment. A un MCT correspond donc généralement plusieurs MLT.
Les notions introduites à ce niveau sont le poste de travail, la phase, la tâche et la
procédure.
3.3.2.1. Le poste de travail
Le poste de travail décrit la localisation, les responsabilités et les ressources nécessaires
pour chaque profil d’utilisateurs du système (exemple : client-web, responsable commercial,
responsable des stocks, etc.).
3.3.2.2. La phase
La phase est un ensemble d’actions (Cf MCT/Opération) réalisées sur un même poste de
travail.
La phase peut être soit manuelle (exemple : confectionner des colis), soit automatisée et
interactive (exemple: saisie d’un formulaire client) ou automatisée batch (exemple:
production et envoi de tableaux de bord quotidiens dans les boîtes aux lettres électroniques).
3.3.2.3. La tâche
La tâche est une description détaillée d’une phase automatisée interactive : spécification
de l’interface et du dialogue homme-machine, localisation et nature des contrôles à effectuer,
etc.
3.3.2.4. La procédure
La procédure est un regroupement de phases, équivalent organisationnel des notions
d’opérations et d’actions conceptuelles, mais se déroulant sur une période de temps
homogène.
Des procédures d’origines non conceptuelles peuvent être rajoutées du fait des choix
d’organisation retenus (exemple: procédures d’échanges d’informations liées à
l’externalisation de certaines activités, prise en compte des questions de sécurité en cas de
choix de solution Web, ...).
3.3.3. Le modèle opérationnel des traitements (MOT ou MOpT)
Le Modèle Opérationnel des Traitements permet de spécifier les fonctions telles qu'elles
seront ensuite réalisées par le programmeur.
3.3.4. Résumé des modèles MERISE
Il existe essentiellement six (6) modèles MERISE par lesquels l’on doit toujours passer
dans le cadre de mise en place d’un système informatique. A ces six (6) modèles, il faut
ajouter le modèle conceptuel de la communication (MCC) et le diagramme de contexte. Il faut
noter également que ces six modèles peuvent être regroupés en deux (2) catégories à savoir :
les modèles statiques et les modèles dynamiques.
3.3.4.1. Les modèles statiques
Les modèles statiques sont les modèles élaborés lors de la mise en place d’une base de
données. Ce sont les modèles liés aux données. On recense dans cette catégorie les modèles
comme:
 Le MCD (Modèle Conceptuel des Données),
 Le MLDR (Modèle Logique des Données Relationnelles) ou le MOD,
 Le MPD (Modèle Physique des Données).
3.3.4.2. Les modèles dynamiques
Les modèles dynamiques sont les modèles élaborés lors de la mise en place d’une
interface homme-machine (IH-M), c’est-à-dire le côté graphique d’un logiciel. Cette catégorie
regroupe les modèles liés aux traitements. Dans cette catégorie, on cite entre autres:
 Le MCT (Modèle Conceptuel des Traitements),
 Le MOT (Modèle Organisationnel des Traitements) ou MLT,
 Le MOpT (Modèle Opérationnel des Traitements).
Le tableau 2.2 illustre ce classement des six (6) modèles.
Tableau 2.2 : Classement des modèles MERISE en catégories et niveau de conception
4. REGLES DE PASSAGE DU MCD AU MLDR

Ces règles sont à appliquer scrupuleusement selon le cas.
4.1. Une entité se transforme en une relation (table)
Toute entité du MCD devient une relation du MLDR, et donc une table de la Base de
Données. Chaque propriété de l'entité devient un attribut de cette relation, et donc une colonne
de la table correspondante. L'identifiant de l'entité devient la clé primaire de la relation (elle
est donc soulignée), et donc la clé primaire de la table correspondante. Soit l’entité du MCD
de la figure 2.29 ci-dessous.
Achat
ID_achat
Designation
Quantite
Pu
Figure 2.29 : Passage du MCD au MLDR de cas 1

Ce MCD en MLDR devient :
Achat (ID_achat, Designation, Quantite, Pu)
4.2. Relation binaire aux cardinalités (X, 1) - (X,n), X=0 ou X=1
La clé primaire de la table à la cardinalité (X,n) devient une clé étrangère dans la table à la
cardinalité (X,1).
Etude de cas 1 : Soit le système d’information décrit comme suit : Un employé travaille dans
une et une seule société. Une société a 1 ou n employés.
Représentation du MCD (Figure 2.30).
Figure 2.30 : Etude de cas 1, MCD

Le Modèle Logique des Données Relationnelle (MLDR) est donné comme suit:
 EMPLOYE (id_Employe, Nom_Employe, #id_Societe)
 SOCIETE (id_Societe, Nom_Societe)
Le Modèle Physique des Données (MPD), ou schéma de base est donné comme suit:
Figure 2.31 : Etude de cas 1, MPD

4.3. Relation binaire aux cardinalités (X,n) - (X,n), X=0 ou X=1
Il y a création d'une table supplémentaire ayant comme clé primaire une clé composée
des identifiants des 2 entités. On dit que la clé primaire de la nouvelle table est la
concaténation des clés primaires des deux autres tables. Si la relation est porteuse de données,
celles-ci deviennent des attributs pour la nouvelle table.
Etude de cas 2 : Soit le système d’information décrit comme suit : Une commande est
composée de 1 ou n produits distincts en certaine quantité. Un produit est présent dans 0 ou n
commandes en certaine quantité.
Représentation du MCD (figure 2.32) :

Le Modèle Logique des Données Relationnelles (MLDR) est donné comme suit:
 COMMANDE (id_Commande, Date_commande)
 PRODUIT (id_Produit, libelle)
 COMPOSE (id_Commande, id_Produit, quantite)

4.4. Relation n-aire (quelles que soient les cardinalités)
Il y a création d'une table supplémentaire ayant comme clé primaire la concaténation des
identifiants des entités participant à la relation. Si la relation est porteuse de données, celles-ci
deviennent des attributs pour la nouvelle table.
Etude de cas 3 : Soit le système d’information décrit comme suit : Un étudiant parle une ou
plusieurs langues avec un niveau. Chaque langue est donc parlée par 0 ou n étudiants avec un
niveau. Pour chaque niveau, il y a 0 ou plusieurs étudiants qui parlent une langue.

 ETUDIANT (id_Etudiant, Nom_Etudiant)
 NIVEAU (id_Niveau, Nom_Niveau)
 LANGUE (id_Langue, Nom_Langue)
 PARLE (id_Etudiant, id_Niveau, id_Langue)

4.5. Association Réflexive
4.5.1. Premier cas : cardinalité (X,1) - (X,n), avec X=0 ou X=1.
La Clé Primaire de l'entité se dédouble et devient une Clé Etrangère dans la relation ou
nouvelle table. Exactement comme si l'entité se dédoublait et était reliée par une relation
binaire (X,1) - (X,n) (Cf règle 2).
Etude de cas 4 : Soit le système d’information décrit comme suit : Prenons l'exemple d'une
société organisée de manière pyramidale : chaque employé a 0 ou 1 supérieur hiérarchique
direct. Simultanément, chaque employé est le supérieur hiérarchique direct de 0 ou plusieurs
employés.

 EMPLOYE (id_Employe, Nom_Employe, #id_Sup_Hierarchique)
#id_Sup_Hierarchique est l'identifiant (id_Employe) du supérieur hiérarchique direct de

l'employé considéré.

4.5.2. Deuxième cas : cardinalité (X,n) - (X,n), avec X=0 ou X=1
De même, tout se passe exactement comme si l'entité se dédoublait et était reliée par une
relation binaire (X,n) - (X,n) (Cf règle 3). Il y a donc création d'une nouvelle table.
Etude de cas 5 : Soit le système d’information décrit comme suit : Prenons cette fois
l'exemple d'une organisation de type familiale : chaque personne a 0 ou n descendants directs
(enfants), et a aussi 0 ou n ascendants directs (parents).

 PERSONNE (id_Personne, Nom_Personne)
 PARENTE (#id_Parent, #id_Enfant)
#id_Parent est l'identifiant (id_Personne) d'un ascendant direct de la personne. #id_Enfant
est l'identifiant (id_Personne) d'un descendant direct de la personne. La table PARENTE sera
en fait l'ensemble des couples (parents-enfants) présent dans cette famille.

4.6. Relation binaire aux cardinalités (0,1) - (1,1).
La clé primaire de la table à la cardinalité (0,1) devient une clé étrangère dans la table à la
cardinalité (1,1).
Etude de cas 6 : Soit le système d’information décrit comme suit : Dans ce centre de
vacances, chaque animateur encadre 0 ou 1 groupe, chaque groupe étant encadré par un et un
seul animateur.

 ANIMATEUR (id_Animateur, Nom_Animateur)
 GROUPE (id_Groupe, Nom_Groupe, #id_animateur)

Ces 6 règles représentent tous les cas que vous pourrez rencontrer dans la conception
de vos systèmes informatiques et d’information.
4.7. MCD : Etude de cas
Soit une compagnie de parapente (avion) qui désire informatiser et gérer sa flotte et soit
le MCD obtenu après l’analyse du cahier des charges.
Figure 2.42 : Etude de cas, MCD parapente
Voici, en suivant les règles de passage du MCD au MLDR, le Modèle Logique des
Données Relationnelles obtenu.
Figure 2.43 : Etude de cas, MLD parapente
5. LES CONTRAINTES : LES CLES

La notion de clé dans le processus de mise en place d’une base de données permet
d’assurer l’unicité des données c’est-à-dire d’éviter la redondance des données ou de lier deux
ou plusieurs tables entre elles ou encore d’assurer l’intégrité référentielle. Selon l’objectif
visé, on distingue plusieurs types de clés à savoir :
 les clés artificielles,
 les clés candidates,
 les clés étrangères,
 les clés naturelles,
 les clés primaires.
Dans la suite, nous définirons de manière succincte chaque type de clés énumérée ci-dessus.
5.1. Clé artificielle
En opposition à une clé naturelle, dans le domaine des bases de données, aussi parfois
appelée clé de remplacement (de l'anglais surrogate key) désigne un ensemble de données
adjointes aux données d'une table pour les indexer.
La génération de la clé artificielle est effectuée par le concepteur de la table. Toute clé
indexant chaque ligne de manière unique est valable. Parmi les méthodes de génération
courantes de clé artificielle, nous pouvons citer les clés incrémentales (les lignes sont
numérotées au fur et à mesure de leur introduction dans la table).
Les clés artificielles sont les seules clés possibles quand :
 il n'existe pas de clé candidate dans la table initiale (il existe des lignes doublons),
D'autres raisons courantes pour adjoindre une clé artificielle à une table sont :
 il existe un risque significatif que des doublons de lignes existantes soient introduit s
ultérieurement dans la table,
 les clés candidates sont peu utilisables (par exemple, elles sont trop longues, ce qui
nuit aux performances d'interrogation),
 il existe une instabilité trop importante sur les données faisant partie des clés
candidates entraînant des modifications trop fréquentes (correction d'erreurs de
saisie, changement de référentiel…).
5.2. Clé candidate
C’est un ensemble des données permettant d'indexer chaque ligne d'une table donnée de
manière différenciée. Une même table peut posséder plusieurs clés candidates distinctes. Une
table avec des lignes en doublon ne possède aucune clé candidate.
La clé primaire appartient nécessairement à l'ensemble des clés candidates. Une table
sans lignes en doublon possède nécessairement une ou plusieurs clés candidates. Une table
avec des lignes en doublon ne possède aucune clé candidate. Lorsqu'une table ne possède
aucune clé candidate, ou que les clés candidates sont peu adaptées (par exemple très longues),
le gestionnaire de la base de données peut être amené à ajouter des données d'indexation
arbitraires à la table, créant ainsi une clé artificielle.
Une clé choisie parmi les clés candidates pour indexer une base est appelée une clé naturelle.
5.3. Clé étrangère
Dans une base de données relationnelle, est une contrainte qui garantit l'intégrité
référentielle entre deux tables.
Une clé étrangère identifie une colonne ou un ensemble de colonnes d'une table comme
référençant une colonne ou un ensemble de colonnes d'une autre table (la table référencée).
Les colonnes de la table référencée doivent faire partie d'une contrainte de clé primaire ou
d'une contrainte d'unicité. La contrainte de clé étrangère garantit que les valeurs de chaque
ligne de la table référençant existent dans la table référencée : ainsi une ligne de la table
référençant ne peut pas contenir un ensemble de valeurs qui n'existe pas dans la table
référencée. Une contrainte de clé étrangère permet ainsi d'établir des liens entre plusieurs
tables : il s'agit d'un des principes fondamentaux des bases de données relationnelles.
5.4. Clé naturelle

Une clé naturelle est une clé choisie parmi les clés candidates pour indexer une entrée de
table à laquelle cette dernière (clé naturelle) appartient.
5.5. Clé primaire
La clé primaire est un identifiant (ou champ ou groupe de champs) qui permet d’identifier
ou d’indexer de manière unique un enregistrement ou une entrée d’une table. La clé primaire
appartient nécessairement à l'ensemble des clés candidates.
6. COURBE DU SOLEIL ET ETAPES D’ELABORATION DES DIFFERENTS

MODELES
6.1.1. Courbe du soleil
Le lever du soleil est comparé au stade de démarrage du processus d’analyse du système
actuel. Le midi est comparé au stade du début de basculement, l’ancien système est modifié
progressivement jusqu’au basculement total au coucher du soleil. Le lever et le coucher du
soleil constitue la phase physique dans la mise en place du nouveau système. La phase
conceptuelle est comparée au midi. Les phases intermédiaires entre le lever-le midi et le midi-
le coucher sont simulées à la phase organisationnelle ou logique. La figure 2.44 représente la
courbe du soleil ainsi décrite.
Figure 2.44 : Courbe du soleil
6.1.2. Courbe du soleil et cycle de vie

Ici, cette courbe du soleil est comparée au cycle de vie d’un système informatique ou
d’un logiciel. La figure 2.45 illustre cette comparaison.
Figure 2.45 : Courbe du soleil et cycle de vie d’un logiciel
6.1.3. Courbe du soleil et les modèles MERISE

Dans cette partie, la courbe du soleil est comparée aux différentes étapes d’élaboration
des différents modèles MERISE. Notons que cette comparaison ressort clairement les
modèles des données et les modèles des traitements. De cette comparaison, on retrouve les
trois principales phases lors de la mise en place d’un système à savoir :
 le lever correspondant à la phase physique (MPhD, MOpT ou MPT)),
 Le midi correspondant la conceptuelle (MCD, MCT),
 Les phases intermédiaires entre le lever et le coucher représentent la phase logique ou
organisationnelle (MLD, MLT ou MOT).
La figure 2.46 représente cette comparaison de la courbe du soleil et les différentes
phases et modèles élaborés ainsi décrite.
Figure 2.46 : Courbe du soleil et les modèles MERISE

CONCLUSION
L’implémentation d’un système informatique ou d’information suit plusieurs étapes en
vue de minimiser des erreurs lors de la phase finale. Ces étapes sont matérialisées par les
phases de la méthode MERISE qui est une méthode de conception et de réalisation des
systèmes informatiques ou d’information. Le rôle de la méthode MERISE s’étend sur d’autres
aspects à savoir la conception et la réalisation des interfaces hommes-machine ou IH-M. Il
s’agit du domaine de la conception et de la réalisation des applications web, mobiles et jeux.
Le chapitre III abordera la démarche MERISE et une introduction des méthodes
d’informatisation orientée-objet : Langage UML.
CHAPITRE III : LA DEMARCHE MERISE ET INTRODUCTION A

UML
INTRODUCTION
La première partie de ce chapitre aborde la thématique de la démarche de la méthode
systémique MERISE et la dernière partie discutera d’une seconde méthode d’informatisation
orientée-objets qui est connue comme étant un langage de conception et de modélisation des
systèmes d’information.
1. LA DEMARCHE MERISE
MERISE est une méthode de conception des systèmes d'information qui utilisent, comme
nous l'avons vu, un certain nombre de modèles. Mais MERISE est également une démarche.
La démarche est la méthode qui organise en étape la conception d'un système d'information à
l'aide des modèles sur une période donnée. La démarche MERSISE passe par les étapes
successives suivantes :
 le schéma directeur,
 l'étude préalable,
 l'étude détaillée,
 l'étude technique,
 la production,
 la qualification,
 la maintenance.
Graphiquement, la démarche MERISE est représentée comme l’indique la figure 3.1.
Figure 3.1 : Représentation graphique de la démarche MERISE

1.1. Le schéma directeur
« Un schéma directeur est une opération de courte durée visant l’anticipation à moyen
terme, la prospective et la planification stratégique afin d’assurer la cohérence entre les
finalités, les stratégies, les objectifs et sa politique de mobilisation des ressources
organisationnelles, technologiques, humaines et financières. »
Appliqué à l'informatique, le schéma directeur d'une organisation a pour but de proposer
un plan d'automatisation progressive des tâches de gestion d'une entreprise, d'une
administration... c'est-à-dire des tâches bien définies dans un ensemble organisé.
Le concept de schéma directeur de l'informatique (SDI) est né dans la banque et la grande

administration face au besoin de planifier des investissements de plus en plus lourds, de
maîtriser les aspects humains liés à la modification des méthodes de travail.
Le schéma directeur de l'informatique permet d'envisager des scenarii qui portent sur les
domaines.
Un domaine est un découpage du système d'information de l'entreprise, défini dans un
schéma directeur en fonction de sa stratégie. Par exemple, une banque peut avoir défini les
domaines Gestion de clientèle, Gestion des participations financières, Gestion de trésorerie,
Gestion des Ressources Humaines, etc. Le découpage en domaines correspond grosso modo
aux grandes fonctions de l'entreprise, hiérarchisées par ses objectifs stratégiques (centres
d'intérêt).
Le schéma directeur peut se faire en plusieurs étapes :
 Etape 1 : définir les objectifs et la structure de travail,
 Etape 2 : déterminer les composants de l'entreprise,
 Etape 3 : formaliser et chiffrer les solutions,
 Etape 4 : planifier les actions,
 Etape 5 : définir la structure de pilotage.
Le schéma directeur donne lieu à un document appelé plan de développement.
1.2. L'étude préalable
L’étude préalable s'applique à un domaine ou à une grande fonction de l'entreprise.
Également appelée, étude de faisabilité, elle a pour objectif d'obtenir le descriptif complet de
la nouvelle solution pour le domaine envisagé, mais en plusieurs phases, de sorte à envisager
les différentes hypothèses possibles et à s'orienter progressivement vers la solution optimum.
Le point final de l'étude préalable est de:
 décider d'une solution type en parfaite connaissance de cause quant à sa faisabilité:
coût, rentabilité, délai, budget, moyens à mettre en œuvre, impact organisationnel,
 établir le cahier des charges pour la réalisation; sélectionner un sous-traitant ou un
progiciel.
Pour mener à bien une étude préalable, on part de la situation existante. L'étude préalable
est faite par des utilisateurs et des organisateurs en liaison avec la direction générale et les
informaticiens. On en distingue plusieurs étapes dont chacune est divisée en phases:
1.2.1. Étape 1 : Étude de l'existant
L’étape 1 consiste à suivre les phases suivantes :
 Phase 1 : Rédiger une Fiche de présentation générale du problème. Cette fiche situe
le domaine dans le système d'information, à partir du schéma directeur et de la demande
de la direction générale. Par interview de la direction générale, se faire préciser les
grands objectifs relatifs au domaine et les consigner dans une Fiche d'objectifs de la
Direction Générale (Fiche D.G.).
 Phase 2 : Procéder à des interviews des postes de travail concernés et rédiger des
comptes rendus d'interviews, en y joignant tous les documents concernés actuellement
en vigueur. S'il y a des traitements qui se font à l'aide ou par ordinateur, joindre les
fiches de description de fichiers actuels.
 Phase 3 : A partir des comptes rendus, établir les documents suivants:
 le graphe de circulation actuel,
 la carte de circulation des informations du domaine,
 le graphe des flux,
 le MOT actuel.
 Phase 4 : A partir des documents recueillis lors des interviews, établir un dictionnaire
des données actuel pour toutes les données manipulées et épurer ce dictionnaire.
 Phase 5 : A partir du dictionnaire des données, construire la structure d'accès
théoriques (SAT) en ne prenant que les données élémentaires, sans les données
calculées, en listant toutes les dépendances fonctionnelles et en éliminant les
transitivités. En déduire une représentation graphique du MCD actuel.
 Phase 6 : Déduire les règles de gestion à partir du MCD et du MCT actuels.
 Phase 7 : à partir des comptes rendus d'interviews, établir une fiche de synthèse faisant
état des points les plus épineux, des souhaits des utilisateurs, en s'efforçant de critiquer
l'organisation actuelle. Dégager de cette fiche un certain nombre d'objectifs de la "fiche
d'objectifs D.G.", établir une liste hiérarchisée de tous les objectifs sur une fiche
d'objectifs synthèse. Faire approuver celle-ci par la direction générale et par les divers
responsables.
 Phase 8 : étudier les interfaces avec les autres domaines (d'après la carte générale de
circulation de l'information du schéma directeur, par exemple) et les consigner dans une
fiche des interfaces.
1.2.2. Étape 2 : Scénarios futurs
Les phases suivantes composent la deuxième étape de l’étude préalable :
 Phase 1 : à partir de la fiche d'objectif synthèse et des règles de gestion actuelles,

inventorier les règles de gestion futures et les inscrire sur une fiche de règles de gestion
futures. A partir du MCD actuel, de la fiche des interfaces et des règles de gestion
futures, établir le MCD futur.
 Phase 2 : à partir du MCT actuel et des règles de gestion futures, concevoir le MCT
futur.
 Phase 3 : pour chaque scénario, faire l'étude organisationnelle qui donnera :
 une fiche des règles d'organisation,
 une esquisse de MOT futur.
Après ces phases successives, il faut faire ensuite l'étude opérationnelle (toujours par
scénario) en définissant le matériel et les logiciels nécessaires. S'il existe plusieurs sites, cette
étude tient compte des aspects spécifiques de chaque site. L'étude opérationnelle donnera lieu
à:
 une fiche de configuration de matériel pour l'architecture générale et pour chaque site
s'il y en a plusieurs,
 une liste des logiciels.
1.2.3. Étape 3 : Une évaluation des Scénarios

Pour chaque scénario, rédiger un rapport d'évaluation du scénario comportant :
 une évaluation des coûts de:
 matériel (achat, location),
 stockage,
 logiciels (programmation, achat de progiciels, ...),
 traitement (unités centrales, consommation d'électricité, ...),
 communication (location de lignes de transmission),
 exploitation (fournitures de consommable, entretien des locaux ...),
 maintenance (contrats de maintenance chez le constructeur),
 personnel (utilisateurs, service informatique, sous-traitant, ...),
 formation (utilisateurs, informaticiens).
 une évaluation des avantages :
 quantifiables et chiffrables au plan financier (recettes attendues, économies de
personnel, ...),
 quantifiables et non chiffrables au plan financier (diminution des temps de gestion,
simplification des procédures, ...),
 non quantifiables (rapidité des traitements, aide à la décision, image de marque,
fidélisation d'une clientèle, ...).
 une évaluation de l'impact sur l'organisation :
 impact sur les postes de travail,
 acceptabilité du personnel.
 une évaluation de la faisabilité :
 en matériels (rédiger un compte rendu de l'étude technique),
 en logiciels,
 en personnel (personnel disponible, embauche, formation, sous-traitance).
 une évaluation approximative des délais :
 de livraison des matériels,
 de programmation des logiciels (délais rarement respectés),
 de recrutement et de formation.
 une évaluation de la mise en œuvre :
 cadencement du lancement des applications,
 périodes transitoires,
 etc.
L'étude préalable donne lieu à un document appelé dossier de choix.
1.3. L'étude détaillée
L'étude préalable ne porte que sur les processus majeurs. La description des données et
des traitements y est succincte. L'étude détaillée va décrire tous les processus composant le
fonctionnement du futur système; définir précisément les informations utilisées et
mémorisées; spécifier complètement les tâches à effectuer. Elle se déroule en plusieurs étapes:
1.3.1. Étape 1 : Étude générale du MOT futur

Cette étude se fait en suivant les phases suivantes :
 Phase 1 : réalisation du tableau des procédures fonctionnelles,
 Phase 2 : construction du diagramme d'enchaînement des procédures
fonctionnelles,
 Phase 3 : construction du graphe de circulation.
1.3.2. Étape 2 : Étude poussée de chaque procédure fonctionnelle
Dans cette étape, chaque procédure fonctionnelle est étudiée de manière poussée. Cela
donne lieu à :
 une fiche de description de la procédure fonctionnelle,

 une description des documents éventuels,
 des tables de décision éventuelles,
 une description éventuelle des états de sortie,
 pour les transactions :
 des grilles d'écrans (à faire approuver par les utilisateurs concernés),
 des grilles de contrôles,
 une fiche de répartition des tâches entre l'homme et la machine (à faire approuver par
les utilisateurs).
 le modèle externe non validé.
1.3.3. Étape 3 : Validation du MCD
Les données et les traitements ayant été étudiés de manière indépendante, la validation
du MCD permet de confronter les données aux traitements et de rendre l'ensemble cohérent.
1.3.4. Étape 4 : Passage au MLD
Pour le passage au MLD, appliquer scrupuleusement les règles de passage du MCD au
MLDR vues dans le chapitre II.
L'étude détaillée donne lieu, pour chaque application à un cahier des charges utilisateurs.
1.4. L'étude technique
L'étude technique est la traduction informatique des spécifications issues de l'étude
détaillée. Elle s'occupe des spécifications techniques pour la réalisation.
Les objectifs de l'étude technique sont de présenter les spécifications informatiques
nécessaires à la production du logiciel. A cet effet, elle définit complètement :
 la structure de mémorisation informatique des données (fichiers ou base de données),
 l'architecture interne du système,
 les procédures de sécurité,
 le plan de réalisation.
L'étude technique peut être menée en suivant les étapes suivantes :
1.4.1. Étape 1 : structuration des données

Il faut établir dans cette première étape la description physique des données à partir du
MLD (Modèle Logique des données) :
 définir les clés d'accès,
 établir une quantification de l'activité des éléments de stockage des données,
 procéder à l'optimisation physique,
 déduire l'allocation des espaces physiques, l'organisation et le mode d'accès,
 décrire les dispositifs de protection d'accès et de confidentialité.
1.4.2. Étape 2 : spécification de l'architecture interne du système
Cette étape consiste à découper les Unités Fonctionnelles (UF) en Unités de Traitement
(UT) :
 découper chaque UF en UT.
Ensuite découper les UT en modules :
 découper chaque UT en modules,
 établir la liste des Entrées/Sorties pour chaque module,
 établir la liste des données utilisées ou échangées,
 établir une description pour chaque module sous forme d'algorithmes ou
d'organigramme,
 déterminer les jeux d'essai à élaborer répondant aux exigences de la qualité.
Terminer de concevoir les Entrées/Sorties :
 définir les spécifications des écrans ainsi que les dialogues associés,
 définir les formats détaillés et les spécifications des sorties,
 établir une liste des entrées/sorties pour chaque UT.
1.4.3. Étape 3 : les procédures techniques de sécurité
C’est une étape très capitale vous permettant de sécuriser vos données.
Contrôle des données :
 description des caractéristiques liées au contrôle des données.
Sécurité et confidentialité :
 description des mécanismes relatifs à la sécurité et à la confidentialité des données,
 description les procédures de reconstitution des supports de données, de redémarrage et
de sauvegarde.
1.4.4. Étape 4 : planification de la réalisation
Cette étape consiste à réaliser le planning pour les phases suivantes :
 Planification de l’implémentation de la base de données,
 Planification de l’écriture du code,
 Planification des tests unitaires et d’intégration,
 Planification de la mise en place des procédures techniques de sécurité.
L'étude technique donne lieu à un cahier des charges techniques.

1.5. La production
La production consiste en l'écriture effective des programmes dans le langage approprié,
à la génération des fichiers ou des bases de données et aux tests. Par ailleurs, une fois la
conception terminée, on passe à la réalisation. La réalisation peut se faire avec n’importe quel
langage. Toutefois, dans le cas d’un Système Informatique (SI) centré sur une base de
données, on utilisera probablement le SQL pour la partie directement liée à la base de données.
Pour l’interface utilisateur, on utilisera indifféremment les langages comme: Visual Basic,
C, C++, Java, PHP, JavaScript, Action Script 3, mais aussi des environnements de
développement rapide de type 4D (quatrième dimension) ou d’Oracle Database XE (freeware
depuis mars 2006).
La production du logiciel doit permettre de faciliter la maintenance future.
Ses objectifs sont :
 la production du logiciel conforme aux spécifications de l'étude technique,
 de tester techniquement le logiciel de manière qu'il soit prêt à être livré aux utilisateurs.
La production du logiciel peut se faire en suivant les étapes suivantes :
1.5.1. Étape 1 : programmation de l'application
Il s’agit de l’étape durant laquelle il faudra :
 Planifier et organiser le travail :
 intégrer les normes et standards de programmation,
 organiser l'environnement de programmation,
 définir une organisation pour permettre la gestion de l'environnement de
programmation (matériel, temps machine, …).
 Coder les modules :
 transformer les spécifications techniques des modules en code source,
 vérifier et mettre au point le code source,
 corriger les défauts et erreurs constatés.
 Préparer les jeux d'essai :
 définir les jeux d'essai,
 préparer les données en vue des tests unitaires et d'enchaînement de modules.
1.5.2. Étape 2 : tests, mise au point
Cette étape est principalement constituée de deux phases :
 Phase 1 : Il s’agit d’exécuter les tests unitaires :
 chaque module écrit, correspondant à une unité de traitement doit faire l'objet d'un
premier test à partir du jeu d'essai.
 Phase 1 : tests d'intégration :
 ces tests doivent permettre de vérifier le bon fonctionnement de l'ensemble du logiciel.
Ils sont généralement effectués par le responsable technique du projet.
La production donne lieu à un dossier de réalisation.
1.6. La mise en service

L'objectif principal de la mise en service est de rendre opérationnel le système
d'information. Elle consiste à installer l'ensemble du logiciel développé et à mettre l'ensemble
du SI au service des utilisateurs. Elle permet de conclure l'ensemble du cycle conception-
développement.
Son objectif principal est de mettre en place tous les moyens nécessaires à la réception et
au lancement du nouveau SI.
La mise en service se déroule en deux étapes:
1.6.1. Étape 1 : l'installation
Elle a pour but de livrer le logiciel aux utilisateurs et de préparer le démarrage de
l'exploitation. Elle comprend :
 la commande, l'installation, le contrôle et la réception du matériel,
 la mise en place des procédures nouvelles liées aux changements d'organisation,
 l'organisation et le déroulement de la formation des utilisateurs et des exploitants,
 l'exécution des jeux d'essai utilisateurs,
 l'appréciation de la conformité des résultats,
 la réception provisoire.
1.6.2. Étape 2 : la mise en exploitation
Cette étape consiste en :
 l'exploitation en grandeur réelle du nouveau système,
 le lancement progressif du nouveau système en parallèle au système existant si possible,
 le fonctionnement en vrai grandeur pendant une période déterminée,
 le bilan de l'exploitation,
 la réception définitive du produit.
Elle donne lieu au dossier d'exploitation et au manuel utilisateur.
1.7. La maintenance
La maintenance est définie selon BOEHM comme l'ensemble des opérations de
modification d'un logiciel opérationnel laissant intactes ses fonctionnalités de base. Elle
consiste en la rectification des anomalies, les améliorations et les évolutions.
Ses objectifs sont :
 maintenir le système en fonctionnement,
 rectifier les anomalies de fonctionnement et prendre en compte les demandes
d'évolution,
 établir un scénario de développement des versions,
 planifier les corrections apportées au système pour minimiser les coûts d'intervention,
 s'assurer du bon fonctionnement des nouvelles révisions avant toute nouvelle mise en
exploitation,
 procéder à cette mise en exploitation après l'accord des parties prenantes,
 assurer une bonne gestion des différentes configurations du logiciel par la tenue à jour
de la documentation du système.
Il existe plusieurs niveaux, catégories et formes de maintenance. Parmi les niveaux et
catégories, on distingue : la maintenance corrective, la maintenance adaptative, la
maintenance perfective et la maintenance préventive.
1.7.1. La maintenance corrective
Elle ne porte que sur le logiciel développé. Elle ne remet pas en cause les modèles de
données ou de traitements. Elle consiste en la correction des erreurs du logiciel. Elle
représente souvent 17 à 20 % du temps de maintenance.
1.7.2. La maintenance adaptative
Elle est liée à l'environnement du logiciel (contexte d'utilisation du logiciel, génération
des ordinateurs, exploitation logiciel sur des matériels distincts ...). Elle peut faire évoluer le
MCD et le MCT. Elle représente 18 à 25 % du temps de maintenance.
1.7.3. La maintenance perfective
La maintenance perfective consiste à améliorer le fonctionnement du logiciel. Elle peut
entraîner une remise en question des modèles physiques et du MOT. C'est la catégorie de
maintenance la plus fréquente (environ 60 %).
1.7.4. La maintenance préventive
La maintenance préventive a pour objectif de diminuer le nombre d'opérations de
maintenance pour en diminuer le coût. Elle n'est vraiment possible que si certaines conditions
sont réunies :
 le système est développé dans un esprit de maintenance ultérieur,
 le système est continuellement amélioré pour faire face et intégrer les nouvelles
technologies,
 le système est maintenu en pensant à la maintenance ultérieure.
2. INTRODUCTION A UML
UML pour Unified Modeling Language est un langage de modélisation unifiée issu de
plusieurs organismes internationaux. UML est un langage graphique qui permet de réaliser les
étapes de la conception. UML propose 9 diagrammes différents. Chaque diagramme est
adapté à une étape ou à un point de vue de la conception. Ce n’est qu’un langage, ce n’est pas
une méthode. C’est un langage formalisé : les symboles graphiques ont une signification
précise.
2.1. But de UML
Le Langage UML (Unified Modeling Language) permet une description conceptuelle
des structures de données d'une application. Les concepts de base (correspondent aux
concepts d'abstraction et de réalité) sont entre autres :
 objet → entité,
 lien → association,
 propriété →attribut.
En plus : la représentation multiple.
Un schéma est composé de :
 types d'entité,
 associations,
 types d'entités et d’associations possédant des attributs.
2.2. Exemples de représentation entité-association UML
La figure 3.2 montre un exemple de représentation des entités-associations UML.
Figure 3.2 : Exemple de représentation des entités-associations UML
2.3. Les 9 diagrammes d’UML

Le tableau 3.1 présente les diagrammes UML ainsi que les domaines ou phases
d’intervention de chaque diagramme. Dans la suite de ce document, nous présenterons et
expliquerons chaque diagramme.
Tableau 3.1 : Les 9 diagrammes UML
Diagramme Cf. Fonctionnel Données Organique Architecture Objet

1 Cas Oui
2 Séquence Collab. Oui Oui Oui
(séquence
3 Activités Etats-transition Oui (flots) (peu)
4 Classes Objets Oui Oui Oui
5 Objets Classes Oui Oui
6 Collaboration Séquence Oui Oui
7 Etats-transition Activités (peu) Oui
8 Composants Oui
9 Déploiement Oui
2.3.1. Diagramme des cas d’utilisation

Il représente les fonctions du système du point de vue de l’utilisateur. Pour établir le
diagramme des cas d’utilisation, on part du cahier des charges c’est-à-dire d’un document
qui précise ce que le maître d’ouvrage attend du système qu’il souhaite faire réaliser par le
maître d’œuvre. Il faut établir un dialogue constant avec le client et les utilisateurs afin
d’éviter des écarts dans le résultat final. La figure 3.3 présente un exemple d’un diagramme
des cas d’utilisation élaboré avec le logiciel Enterprise Architect.
Ce diagramme présente les résultats observables des besoins de l’utilisateur. Un cas
d’utilisation constitue un processus d’échange de messages ou de signaux entre l’utilisateur
et l’application.
Note : Les diagrammes UML extraits de mémoire Alassani AKANATE 2012 ont été
élaborés avec l’outil Enterprise Architect.
Figure 3.3 : Un exemple de diagramme des cas d’utilisation (Mémoire Alassani AKANATE,
2012)
Ce diagramme est un diagramme des cas d’utilisation pour un service de consultation
et un service SMS. La consultation de ces services nécessite un système d’information
externe ou fournisseur. Ici, le service est consulté par une entité appelée « User ».
Note : Le diagramme des cas d’utilisation est le tout premier diagramme UML à
élaborer lors de la conception et réalisation d’un système d’information. De ce dernier,
découleront tous ou partie des autres diagrammes.
2.3.2. Diagramme de séquence (cf. collaboration)
Tout comme le diagramme de collaboration, il montre les interactions entre les objets. Il se
concentre sur la séquence temporelle de ces interactions.
Avec les objets « acteur » et « système », il permet de représenter le déroulement des
scénarios (instances des cas d’utilisation). La figure ci-dessous présente un exemple de
diagramme de séquence.
Figure 3.4 : Un exemple de diagramme de séquence (Mémoire Alassani AKANATE, 2012)

Le diagramme de séquence présente les différentes étapes pour la consultation des
services vus et énumérés dans le diagramme des cas d’utilisation.
2.3.3. Diagramme d’activité (cf. états-transition)
Le diagramme d’activités visualise un graphe d’activité (équivalent au MOT MERISE).
Le diagramme d’activités est une variante du diagramme d’états-transitions qui met en avant
les activités (fonctionnel) et les transitions plutôt que les états (architectonique) et les
transitions.
2.3.4. Diagramme de classes
Il représente la structure statique du système en termes de classes et de relations. Outre les
classes, on y trouve les interfaces et les paquetages. La figure 3.5 présente un exemple de
diagramme de classe.
Figure 3.5 : Un exemple de diagramme de classe (Mémoire Alassani AKANATE, 2012)
Le diagramme de classe montre l’ensemble des classes et des fonctions pour le métier du
système à mettre en place. Le diagramme de classe d’UML correspond au modèle conceptuel
des données (MCD) dans la démarche MERISE. La figure 3.6 illustre un autre diagramme de
classe.
Figure 3.6 : Diagramme de classe, exemple bis (Mémoire Alassani AKANATE, 2012)
2.3.5. Diagramme d’objets (cf. classes)
Il représente les objets et leurs liens. Il représente la structure statique du système.
C’est un diagramme d’instances du diagramme de classes.
2.3.6. Diagramme de collaboration (cf. séquence)
Tout comme le diagramme de séquence, il montre les interactions entre les objets. Par
ailleurs, le diagramme de collaboration montre les interactions entre les objets à travers la
représentation d’envois et de réceptions de messages.
2.3.7. Diagramme d’états-transition (cf. activité)
Il représente des automates d’états finis du point de vue des états et des transitions. La
figure 3.7 présente un exemple de diagramme d’état.
Figure 3.7 : Un exemple de diagramme d’état (Mémoire Alassani AKANATE, 2012)

Ce diagramme est caractérisé par un début, une fin et des états transitoires.
2.3.8. Diagramme de composants
Il représente les composants physiques d’une application (fichiers, bibliothèques, etc.).
2.3.9. Diagramme de déploiement
Il représente le déploiement des composants sur les dispositifs matériels. La phase de
déploiement va décrire la plate-forme, les différents nœuds, terminaux et l’environnement dans
lequel sera utilisée l’application. La figure 3.8 montre un exemple de diagramme de
déploiement.
Figure 3.8 : Un exemple de diagramme de déploiement (Mémoire Alassani AKANATE,

2012)
La figure 3.9 montre le diagramme de nœuds déduit du diagramme de déploiement.
Figure 3.9 : Un exemple de diagramme de nœuds (Mémoire Alassani AKANATE, 2012)

2.4. Les différents diagrammes selon l’étape de la conception
A chaque étape de la conception, il faut élaborer un diagramme comme dans le cas de la
méthode MERISE.
 Analyse fonctionnelle : avec des diagrammes des cas d’utilisation (1), de séquence
(2) et d’activités (3).
 Analyse des données : avec un diagramme des classes (4).
 Analyse organique détaillée : avec des diagrammes de séquence (3) et
éventuellement des diagrammes d’objets (5), de collaboration (6), d’états (7).
 Architecture : avec des diagrammes de composants (8) et de déploiement (9).
C’est ce qu’illustre le tableau 3.2.
Tableau 3.2 : Différents diagrammes UML selon le niveau de conception.
Point de vue Diagramme UML

Statique – non objet Cas d’utilisation
ANALYSE
Séquence
FONCTIONNELLE Dynamique – non objet
Activités
Statique - objet Classes
Dynamique - objet Séquence

ANALYSE ORGANIQUE Objets
Collaboration
Dynamique Etats-transitions
2.5. Précisions Plutôt non objet Activités

Le tableau 3.3 apporte plus de précision sur les diagrammes UML ou modèles MERISE
mis en place suivant le niveau d’évolution dans la conception du système informatique ou
d’information.
Tableau 3.3 : Types de diagrammes ou modèles selon l’étape de la conception
Etapes Point de vue Diagramme Paternité Nb de diag.
Analyse Tout Dynamique Flux (contexte) MERISE 1

fonctionnelle
Tout Statique Cas d’utilisation UML 1
Parties Dynamique Séquence UML * / UC

système
Parties Dynamique Activité UML 1 / UC
Analyse des Tout Statique Classes UML - 1

données MERISE
3. ÉLEMENTS DE MERISE 2 : INTRODUCTION

Il faut noter que MERISE 2 sort du contexte de ce livre.
Voici ci-dessous quelques éléments et spécifications de MERISE 2 :
 Spécialisation/Généralisation,
 Contraintes de spécialisation,
 Restrictions et sous-types d’associations,
 Contraintes intra-associations,
 Contraintes inter-associations,
 Décomposition d’une association.
Nous traitons dans la section qui suit le premier point c’est-à-dire la spécialisation/
généralisation.
3.1. Spécialisation simple
Elle permet de modéliser, dans l’ensemble des occurrences d’une entité, des sous-
ensembles d’occurrences présentant des spécificités. Ces spécificités peuvent porter sur des
propriétés, des relations ou des appellations.
Exemple : Un assuré peut être une entreprise, un particulier ou les deux.
Entités : ASSURE, ENTREPRISE, PARTICULIER.
Propriétés de l’assuré : N°Assuré, Nom, Adresse, type et tél.
Un particulier a en plus une profession et une classe d’âge.
Une entreprise a un N°SIREN et une forme juridique.
Représentation graphique
Figure 3.10 : Spécialisation simple
Autre exemple : La figure 3.11 ci-dessous illustre un autre exemple de représentation de

la spécialisation simple.
Figure 3.11 : Un autre exemple de la spécialisation simple

Contraintes sur la spécialisation
 Expriment les participations des occurrences de l’entité sur-type aux entités sous-types,
 Types de contrainte :
 Rien : pas de contrainte, un assuré peut être particulier, entreprise, ni particulier, ni
entreprise, ou encore les deux à la fois.
Figure 3.12 : Schématisation du concept de spécialisation simple
 X : Exclusivité, un assuré peut être soit entreprise, soit particulier, soit ni entreprise ni
particulier mais pas les deux à la fois.
Figure 3.13 : Schématisation du concept de spécialisation simple avec exclusion
 T : Totalité, tout assuré est un particulier, une entreprise, ou les deux.
Figure 3.14 : Schématisation du concept de spécialisation simple et totalité

 XT : Partition, tout assuré est soit une entreprise, soit un particulier.
Figure 3.15 : Schématisation du concept de spécialisation simple et partition
Figure 3.16 : Représentation XT

3.2. Généralisation
Dans la généralisation, ce sont les entités sous-types qui préexistent
 les identifications des entités sous-types sont indépendantes de l’identification de
l’entité surtype.
Exemple
Figure 3.17 : Représentation type d’une généralisation
Contraintes intra-associations :
 On ne peut pas toujours représenter, avec les cardinalités, les contraintes d’intégrité
fonctionnelle (CIF).
 Des entreprises qui effectuent des travaux, avec la contrainte : chaque entreprise
n’effectue qu’un seul type de travaux.
Note : MERISE 2 fait l’objet d’un autre ouvrage. La section ci-dessus constitue un aperçu sur
les spécifications et le nouveau vocabulaire utilisé dans MERISE 2.
4. COMPARAISON DE REPRESENTATION MERISE-UML

La représentation des données bien qu’identique dans les deux méthodes
d’informatisation, il faut néanmoins relever quelques différences surtout la représentation des
cardinalités. Il faut aussi noter que le sens de la lecture des relations dans les deux méthodes
n’est pas identique.
La représentation des entités-relations dans la méthode MERISE est la suivante :
Figure 3.18 : Représentation entité-relation dans MERISE

La représentation des entités-associations dans le langage UML est la suivante :
Figure 3.19 : Représentation entité-association dans UML

4.1. Outils de conception de Bases de Données : MERISE-UML
On distingue des outils Open-sources des outils propriétaires ou payants.
4.1.1. Outils (Open-source, multi-OS)
 MySQLWorkbench: http://mysqlworkbench.org/,
 JMerise: http://www.jfreesoft.com/JMerise/,
 Dia: http://dia-installer.de/,
 Rise Editor: http://www.risetobloome.com/,
 DB-Main: http://www.db-main.be/,
 https://www.draw.io/,
 ET bien d’autres.
4.1.2. Outils (propriétaires, payants)
 Enterprise Architect,
 Power AMC: www.sybase.com,
 Windesign: http://www.win-design.com/fr/,
 Modelio SQL Designer: http://www.modeliosoft.com/fr/modules/sql-designer.html,
 ET bien d’autres.
5. QUI FAIT QUOI
Il est important d’identifier le rôle de chaque partie prenante dans un processus de mise
en place d’un système informatique ou d’information. Le tableau 3.4 présente les différentes
parties prenantes d’un exemple type d’un projet de mise en place d’une solution informatique
ou d’informatisation.
Tableau 3.4 : Parties prenantes et leurs rôles dans la mise en place d’une solution
informatique ou d’informatisation
QUI QUOI
Le maître d’ouvrage (utilisateur) Exprime les besoins dans un cahier des charges
L’analyste Comprend les besoins exprimés et produit un

diagramme des cas d’utilisation et de séquence.
L’architecte Conçoit les besoins compris et produit diagrammes
de classes et autres diagrammes.
Le programmeur Réalise les besoins conçus.
Le testeur Teste les besoins réalisés
Note : Le MOE désigne en général la maîtrise d’œuvre (informaticien ou celui qui réalise le
métier) et le MOA désigne la maîtrise d’ouvrage (utilisateur).
Il est vrai que certains métiers dont les priorités sont opérationnelles ne disposent pas
toujours de la capacité d’abstraction et de la rigueur conceptuelle nécessaires à la
formalisation. La professionnalisation de la MOE a pour but de les doter de ces compétences.
Cette professionnalisation réside essentiellement dans l’aptitude à modéliser le système
d’information du métier.
6. SECURITE D’UNE BDD / SI
Afin d'éviter des catastrophes, il est primordial de sécuriser la base de données ainsi que
le réseau sur lequel elle se trouve.
Il faudra donc :
 Mettre en place des comptes utilisateurs avec différents niveaux d'accès au niveau de la
base de données. Ainsi chaque utilisateur pourra accéder à telles ou telles parties de la
base de données à l'aide d'un login et d'un mot de passe.
 L'accès aux tables systèmes ne devra être possible que par un administrateur. Ainsi les
utilisateurs ne pourront pas mettre en demeure le bon fonctionnement de la base de
données. Un opérateur pourra éventuellement veiller au contrôle des données au sein de
la base.
 Développer une stratégie de Sauvegarde de la base de données. Ainsi, en cas de
problème sur cette dernière, la restitution des données pourra se faire aussi rapidement
que possible, et l'entreprise n'aura rien perdu en productivité.
 Sécuriser le réseau local de l'entreprise : les données des entreprises étant
confidentielles, il est nécessaire que des personnes malveillantes n'y accèdent pas.
Ainsi, il est nécessaire de mettre en place un Firewall et un Antivirus. Si l'entreprise a
des commerciaux qui doivent se connecter à la base de données de l'extérieur (via
internet par exemple), il faudra mettre en place une sécurité accrue pour éviter les failles
de sécurité. (citons par exemple le ver Slammer de Janvier 2003 qui a attaqué les
serveurs SQL Server car ils avaient autorisé les connexions via Internet).
 Mettre en place des sécurités au niveau des utilisateurs du réseau local. La standardiste
n'a pas forcément besoin d'accéder aux données confidentielles de la base de données ...
Ceci se fait via la configuration de l'Active Directory et de la configuration des
différentes stratégies des comptes utilisateurs ...
CONCLUSION
La mise en place d’un système informatique ou d’un système d’information passe par
plusieurs étapes. Ces étapes sont matérialisées par les outils de conception et de réalisation
tels que la méthode d’informatisation MERISE et le langage UML. Ces deux méthodes
abordent les problèmes différemment mais la finalité reste la même. Il faut noter également
que le vocabulaire utilisé par les deux méthodes reste différent. La méthode MERISE utilise
différents formalismes et modèles tandis que le langage UML utilise la notion de diagrammes
pour formaliser les différentes étapes de conception et de réalisation du système. Nous avons
également donné une comparaison de représentation des entités-relations dans les deux
méthodes et des exemples types de modèles ou diagrammes élaborés à chaque phase du
développement d’un système informatique ou d’un système d’information. Le système
d’information a plusieurs sens et peut désigner une base de données, un système informatique
ou logiciel ou un système de sécurité dans une organisation. Un système d’information
(logiciel ou base de données) une fois mis en place nécessite une sécurité, il faudra alors créer
des comptes utilisateurs, des logins, mots de passe ou utiliser d’autres méthodes comme des
pare-feu ou firewall pour sécuriser tout l’ensemble du système.
CONCLUSION GENERALE
À la différence d'autres méthodes (par exemple UML), MERISE se positionne comme
une méthode de conception de SI sur le plan de son organisation générale. Cette méthode a
pour principal avantage de permettre la compréhension et la formalisation des besoins du
métier que vers la réalisation de logiciel. Elle favorise donc le dialogue entre concepteurs et
maîtrise d’ouvrage, tout particulièrement dans les projets de développement de systèmes de
gestion intégrée (type ERP). Cette méthode a souvent été décriée comme méthode « historique
et franco-française ». Rappelons que MERISE est davantage tournée vers l'ingénierie de
conception générale (SI métier) que vers le génie logiciel (conception détaillée) : ce qui n’a
jamais été le positionnement de MERISE, dès sa création dans les années 70. Sur le plan des
formalismes, cette méthode est encore tout à fait valable pour : la modélisation générale des
données en vue de la construction d'une BDD relationnelle ; la modélisation des processus
métiers d'un SI, automatisé en partie par du logiciel; la formalisation des besoins utilisateur
dans le cadre d’un cahier des charges, préalablement au travail de conception.
Ce livre intitulé « LIVRE ACSI : MERISE-UML TOME I» constitue un outil pour la
conception et la réalisation des systèmes informatiques et des systèmes d’information. Le livre
a présenté dans le premier chapitre la terminologie et les concepts généraux liée aux systèmes
d’information et informatiques, aux bases de données, les différentes méthodes d’étude de
conception et de réalisation. Le deuxième chapitre s’est focalisé sur la méthode MERISE
(Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise), ses
différents formalismes et modèles et le troisième chapitre a abordé la démarche MERISE et
une introduction du langage UML.
UML pour Unified Modeling Language est un langage visuel pour le développement
d'applications informatiques. Il est le résultat de la fusion de plusieurs méthodes (Booch,
Jacobson et Rumbaugh) défini par le consortium OMG (Object Managment Group) :
http://www.omg.org/uml
PHASES D’ANALYSE ET DOCUMENTS PRODUITS

Le cycle de vie en V correspond aussi à un cycle de consommation et de production
des documents.
Les activités du cycle de vie en V utilisent les documents des activités précédentes et
produisent des documents.
L’analyse fonctionnelle se base sur le cahier des charges. Elle aboutit à un document
d’analyse fonctionnelle. Ce document pourra être validé par le client de façon à vérifier la
bonne compréhension du cahier des charges par l’informaticien. Ce document servira
d’entrée pour l’architecture et l’analyse détaillée.
L’architecture se base sur le document d’analyse fonctionnelle et sur le cahier des charges.
Elle aboutit à un document d’architecture.
L’analyse détaillée se base sur le document d’analyse fonctionnelle et sur le document
d’architecture. A ce niveau, on n’utilise plus le cahier des charges. Elle aboutit à un
document d’analyse détaillée.
Note :
L’analyse fonctionnelle produit aussi un document de recettes qui sera utilisé à la fin
par l’activité de recette.
L’architecture produit aussi un document d’intégration qui sera utilisé par
l’activité d’intégration.
L’analyse détaillée produit aussi un document de tests unitaires qui sera utilisé par l’activité
de tests unitaires.
QUESTIONS-REPONSES
1. Définir MERISE.
Réponse
MERISE : Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise.
2. Définir Système d’Information.
Réponse
Systèmes d'Information : ensemble des moyens (humains et matériels) et des méthodes se rapportant à la
collecte, au stockage, au traitement et à la circulation de l'information dans une organisation et son
environnement.
3. Définir le mot Analyse.
Réponse
Analyse : processus d'examen de l'existant.
4. Définir Conception.
Réponse
Conception: Processus de définition de la future application informatique.
5. Définir ACSI.
Réponse
ACSI = Analyse et Conception des Systèmes d'Information (ou informatiques). Utilise une méthode
d’informatisation (MERISE, UML, etc.) pour la conception et la réalisation de système.
6. Définir BD.
Réponse
BD= Bases de données.
• Bases de Données [définition des informaticiens] : ensemble des données (de l'organisation)
structurées et liées entre elles :
 stocké sur support à accès direct (disque magnétique),
 géré par un SGBD (Système de Gestion de Bases de Données),
 accessible par un ensemble d'applications.
7. Qu’est-ce que l’Informatique de Gestion ?
Réponse
L’Informatique de Gestion est l’informatisation des systèmes d'information.
8. Que signifie AGL ?
Réponse
AGL signifie Atelier de Génie Logiciel (CASE =Computer Aided Software Engineering en anglais) :
ingénierie du logiciel assisté par ordinateur.
9. Que signifie le mot Système ?
Réponse
Le mot Système signifie ensemble d'éléments en interaction dynamique, dont les éléments sont
organisés et coordonnés en vue d'atteindre un objectif, qui évolue dans un environnement donné.
10. Donner la représentation d’un système vue comme une « boîte noire »
Réponse
11. Donner la composition d’un système organisationnel.

Réponse
 Système de décision,
 Système d’information,
 Système opérationnel.
12. Définir chacun des trois (3) sous-systèmes du système organisationnel.
Réponse
 Système de Décision (ou pilotage, management, etc.)
o Guide l'organisation vers ses objectifs (activités de planification et de contrôle) :
coordonne, imagine, finalise, élabore les objectifs.
o Gérer.
 Système d'Information
o Intermédiaire entre les systèmes de décision et opérationnel, par qui transite toute
information,
o mémorise l’information (conservation de l'information pour des besoins ultérieurs),
o traite l’information (rapprochements, calculs, comparaisons),
o fait circuler l’information (accès à la mémoire, échange entre acteurs),
 Système Opérant (ou logistique, technologique, physique, de production, etc.).
o Effectue la transformation : reçoit, traite, envoie,
o Acheter ; Produire ; Stocker ; Vendre.
13. Donner la différence entre le système d’information et le système informatique.
Réponse
Le système informatique est la partie informatisée du système d’information automatisable.
14. Nomenclature 2005 :

Donner les synonymes du mot développeur (d’application).
Réponse
 Analyste-programmeur,
 Réalisateur en informatique,
 Analyste fonctionnel,
 Analyste réalisateur.
15. Qu’est-ce qu’une méthode d’informatisation en informatique de gestion ?
Réponse
Une méthode d'informatisation en informatique de gestion :
 définit un processus d'informatisation du système d'information (totalement ou partiellement
c’est-à-dire pour tout ou partie du cycle de vie du logiciel),
 possède une portée (champ d'étude c’est-à-dire domaine étudié),
 décrit une démarche c’est-à-dire un ensemble de travaux en les ordonnant (succession
d’étapes).
16. Donner au moins trois (3) règles des méthodes d'informatisation.
Réponse
Trois (3) règles des méthodes d'informatisation :
 S'appuyer sur des concepts théoriques : définition des concepts,
 Proposer une démarche : cadre général pour définir le travail à accomplir par les intervenants,
 Permettre sa mise en œuvre par des outils : pour faciliter la manipulation des concepts,
 Atteindre un but : l’informatisation éventuelle (⇒argumentation et faisabilité).
17. Donner au moins trois (3) composants des méthodes d'informatisation.
Réponse
Trois (3) composants des méthodes d'informatisation
 Modèles : ensemble de concepts et de règles destinés à expliquer et construire la
représentation de phénomènes organisationnels,
 Langages : destinés à l’élaboration des spécifications, à faciliter la communication,
 Démarche,
 Outils et techniques : aides à la mise en œuvre des modèles, langages, démarche.
18. Donner au moins trois (3) objectifs des méthodes d'informatisation.
Réponse
Trois (3) objectifs des méthodes d'informatisation:
 Réduire la complexité des informatisations (exemple : en identifiant et donc en maîtrisant les
facteurs de cette complexité),
 Rendre cohérents tous les projets (exemple : même approche, même « style » des dossiers,
meilleure intégration entre projets)
 Capitaliser les expériences (exemple : réutilisation des solutions ayant résolu les mêmes
problèmes, acquisition de savoir-faire)
 Augmenter la qualité des travaux d'informatisation (exemple : mêmes standards)
 Augmenter la productivité des travaux d'informatisation (exemple : standardisation augmente
l’efficacité),
 Améliorer les communications entre intervenants (utilisateurs et informaticiens).
19. Donner trois (3) Types d'approche des problèmes d'informatisation.
Réponse
20. Donner cinq (5) méthodes d'informatisation.
Réponse
Cinq (5) méthodes d'informatisation :
 MERISE et MERISE/2 (Méthode d'étude et de réalisation informatique pour les systèmes
d’entreprise)
o H. TARDIEU pour Séma-Matra et Gamma International, France, 1983
o Informatisation complète
 JSD (Jackson System Development)

o M. JACKSON, Systems Ltd, Royaume-Uni, 1983
o Conception du système d'information et du système informatique
 SSADM (Structured Systems Analysis and Design Method)
o LBMS pour CCTA, Grande-Bretagne, 1986
 AXIAL (Analyse et Conception de Systèmes d’Information Assistés par Logiciels)
o IBM, France, 1986
 MCX et MCO (Méthode générale d'analyse des applications informatiques)
o X. CASTELLANI, France, 1983
 OOA (Object-Oriented Analysis)
o P. COAD et E. YOURDON, 1991
 OMT (Object Modeling Technique)
o J. RUMBAUGH, 1991
o Conception du système d'information et du système informatique
 OOSE (Object-Oriented Software Engineering)
o I. JACOBSON, 1992
 UML (Unified Modeling Language)
o G. BOOCH, I. JACOBSON et J. RUMBAUGH, 1999
N. B. : UML est un langage de modélisation et non pas une méthode.
21. Donner la démarche d’une méthode d'informatisation traditionnelle
Réponse
 Étude préalable,
 Analyse fonctionnelle,
 Analyse organique,
 Programmation,
 Mise en service.
22. Citer les modèles MERISE pour les différents niveaux de sa démarche
Réponse
Les modèles de MERISE
A chaque niveau de la conception du système d'information, un modèle est élaboré. Il permet de
décrire le système au niveau de conception considéré. Sachant que la communication, les données et
les traitements sont examinés, on a les modèles suivants :
Au niveau conceptuel :
 Le Modèle Conceptuel de la Communication (MCC),
 Le Modèle Conceptuel des Données (MCD),
 Le Modèle Conceptuel des Traitements (MCT).
Au niveau Organisationnel :
 Le Modèle Logique des Données (MLD),
 Le Modèle Logique des Traitements (MLT) ou Modèle Organisationnel des Traitements
(MOpT).
Au niveau physique :
 Le modèle Physique des Données (MPD ou MPhD),
 Le Modèle Opérationnel des Traitements (MOT ou MOpT).
23. Que signifie MCC ?
Réponse
Le Modèle Conceptuel de la Communication (MCC)
Le MCC (Modèle conceptuel de la communication) définit les flux d'informations à prendre en compte.
24. Quels sont les trois (3) modèles de données dans la démarche MERISE ?
Réponse
On retrouve trois niveaux de modèles de données
 Le modèle conceptuel de données,
 Le modèle logique de données, appelé aussi modèle fonctionnel de données,
 Le modèle physique de données.
25. Que signifie concrètement le MPD ou MPhD ?
Réponse
La modèle Physique des données (MPD ou MPhD) permet de préciser les systèmes de stockage
employés. Les données qui sont stockées et gérées dans un ordinateur le sont souvent par un système
de gestion de base de données (SGBD). Le MPD est l'implémentation du MLD dans le SGBD retenu.
Une fois le système d'information analysé et modélisé en Modèle Conceptuel de Donnée (MCD), et
après être passé par le Modèle Logique de Donnée Relationnel (MLDR), nous arrivons au Modèle
Physique de Donnée (MPD). Il s'agit maintenant de créer la base correspondante à l'étude entamée.
C'est à ce stade seulement que le système de gestion de base de données choisie intervient.
26. Quels sont les modèles des traitements vus en MERISE?
Réponse
Si les modèles de données se penchent sur l'aspect statique, les modèles des traitements s'occupent de
l'aspect dynamique. Ils portent sur les "manipulations" que subissent les données. On en distingue
également trois :
 le modèle conceptuel des traitements (MCT),
 le modèle organisationnel des traitements (MOT),
 le modèle opérationnel des traitements (MOT).
27. Quelles sont les notions qu’apporte le MOT par rapport au MCT ?
Réponse
Le modèle organisationnel des traitements (MOT) encore appelé MLT (Modèle Logique des
Traitements), il décrit avec précision l’organisation à mettre en place pour réaliser une, ou le cas
échéant plusieurs, opérations figurant dans le MCT : c’est à dire qui fait quoi, où, quand, comment. A
un MCT correspond donc généralement plusieurs MLT.
Les notions introduites à ce niveau sont le poste de travail, la phase, la tâche et la procédure.
28. Donner la constitution d’une information. Quel est son but ?
Réponse
Une information est un ensemble constitué de trois (3) éléments :
 une entité : l'être, l'objet ou le concept concerné,
 un attribut : un élément de la description de l'entité,
 une mesure : une valeur associée à l'attribut.
But : une information apporte un renseignement au sujet d'une entité. Elle nous permet de représenter
une entité et de transformer cette représentation.
29. Déduire alors le rôle de l’information dans une organisation.
Réponse
Rôle de l'information :
Tout acte de la vie d'une organisation s'accompagne ou est conditionné par des informations pour :
 améliorer son fonctionnement,
 faciliter la prise de décision.
30. Citer quatre (4) périmètres que peut recouvrir le système d’information.
Réponse
 Base de données de l'entreprise,
 Progiciel de gestion intégré (ERP),
 Outil de gestion de la relation client (Customer Relationship Management),
 Outil de gestion e la chaîne logistique (SCM - Supply Chain Management),
 Applications métiers,
 Infrastructure réseau,
 Serveurs de données et systèmes de stockage,
 Serveurs d'application,
 Dispositifs de sécurité.
31. Citer les fonctions des systèmes d'information
Réponse
Les systèmes d'information ont trois grandes fonctions :
La mémorisation (des informations brutes ou résultats de traitement)
La circulation : accès à la mémoire et échange entre les acteurs
Le traitement : rapprochement, calcul, comparaison d'informations.
32. Qu’est-ce que le cycle de vie d’un logiciel ou application ?
Réponse
Le « cycle de vie d'un logiciel » (en anglais software lifecycle), désigne toutes les étapes du
développement d'un logiciel, de sa conception à sa disparition.
33. Rappeler les principales activités du cycle de vie d’un logiciel ou application.
Réponse
Le cycle de vie du logiciel comprend généralement les activités suivantes :
Définition des objectifs : cette phase consiste à définir la finalité du projet et son inscription dans
une stratégie globale.
Analyse des besoins et faisabilité, c'est-à-dire l'expression, le recueil et la formalisation des
besoins du demandeur (le client) et de l'ensemble des contraintes.
Conception générale. Il s'agit de l'élaboration des spécifications de l'architecture générale du
logiciel.
Conception détaillée, consistant à définir précisément chaque sous-ensemble du logiciel.
Codage (Implémentation ou programmation), soit la traduction dans un langage de
programmation des fonctionnalités définies lors de phases de conception.
Tests unitaires, permettant de vérifier individuellement que chaque sous-ensemble du logiciel est
implémenté conformément aux spécifications.
Intégration, dont l'objectif est de s'assurer de l'interfaçage des différents éléments (modules) du
logiciel. Elle fait l'objet de tests d'intégration consignés dans un document.
Qualification (ou recette), c'est-à-dire la vérification de la conformité du logiciel aux spécifications
initiales.
Documentation, visant à produire les informations nécessaires pour l'utilisation du logiciel et pour
des développements ultérieurs.
Mise en production,
Maintenance, comprenant toutes les actions correctives (maintenance corrective) et évolutives
(maintenance évolutive) sur le logiciel.
34. En quoi consiste la phase de conception du logiciel ?
Réponse
Cette phase est constituée en deux sous-phases à savoir :
Conception générale : Il s'agit de l'élaboration des spécifications de l'architecture générale du logiciel.
Conception détaillée : consistant à définir précisément chaque sous-ensemble du logiciel.
35. Qu’est-ce que la phase d’intégration ?
Réponse
Intégration, dont l'objectif est de s'assurer de l'interfaçage des différents éléments (modules) du
logiciel. Elle fait l'objet de tests d'intégration consignés dans un document.
RECUEIL DES EXERCICES

EXERCICE 1
1. Qu’est-ce qu’un identifiant ? Attribut ? Entité ?
2. Soit le S.I. suivant d'une organisation de type familiale : chaque personne a 0 ou n
descendants directs (enfants), et a aussi 0 ou n ascendants directs (parents).
a. De quel type de règle de passage s’agit-il ?
b. Donner le MCD du SI ainsi décrit.
c. Donner le MLDR.
d. En déduire le MPD.
EXERCICE 2
1. Donner les différentes phases de la démarche MERISE.
2. Définir les termes suivants : Système, Système informatique, Système d'information.
3. Qu’est-ce qu’une information ?
4. Donner la définition de l'étude préalable ?
5. Donner la définition de l'étude détaillée.
6. Définir les mots suivants « Modèle », « Concept »
EXERCICE 3
1. Donner quatre (4) avantages de l’utilisation des méthodes d’informatisation.
2. Donner les typologies des méthodes d’informatisation.
3. Donner un exemple des méthodes systémiques et un exemple des méthodes orienté- objets.
4. Définir et dire à quel niveau des modèles MERISE se situe MCC ? MLD ? MOpT ?
5. Quel est le but de MERISE ?
EXERCICE 4
1. Définir le MOT.
2. Donner la différence fondamentale entre le MOT et le MCT.
3. Soit le modèle conceptuel des données (MCD) suivant :
a. Donner la Règle de passage du MCD au MLDR qui apparaît dans le MCD ci-dessus.
b. Donner le modèle logique des données relationnelles (MLDR) correspondant en respectant
la règle de passage du MCD au MLDR.
EXERCICE 5
Soit le SI suivant décrit verbalement : Un étudiant parle une ou plusieurs langues avec un
niveau. Chaque langue est donc parlée par 0 ou n étudiants avec un niveau. Pour chaque
niveau, il y a 0 ou plusieurs étudiants qui parlent une langue.
a. Traduire ce cahier des charges en MCD.

b. Déduire le MLDR de ce SI en respectant les règles de passages.
c. Réalise le modèle physique des données (MPD) du SI.
EXERCICE 6
Soit le MCD suivant :
1. Rappeler la règle de passage du MCD au MLD qui apparaît dans ce MCD.

2. Réaliser le modèle logique des données (MLD) du SI.
3. Réaliser le modèle physique des données (MPD) du SI
EXERCICE 7
4. Définir et dire à quel niveau des modèles MERISE se situe MCC ? MLD ? MOT ?
EXERCICE 8: Etude de cas
Soit le système d’information de l’activité de gestion des locations saisonnières d’une
agence immobilière. Une analyse de l’existant a permis de dégager les entités suivantes :
Entité Objectif Propriétés

NumPropriétaire
Nom
Prénom
Adresse1
Regroupe toutes les informations Adresse2
PROPRIETAIRE relatives aux propriétaires CodePostal
d’appartements Ville
NumTel1
NumTel2
E-mail
Cacumulé
Regroupe toutes les informations NumLocation
APPARTEMENT des appartements meublés mis à la Catégorie : 1, 2, ou 3 étoiles
location Type : T2, T3, T4
NbPersonnes
AdresseLocation
Photo
Equipements
NumLocataire
NomLocataire
PrénomLocataire
Regroupe toutes les informations Adresse1Locataire
sur les locataires qui ont effectué au moins Adresse2Locataire
LOCATAIRE
une location par CodePostalLocataire
l’intermédiaire de l’agence VilleLocataire
NumTel1Locataire
NumTel2Locataire
E-mailLocataire
Regroupe toutes les informations NumContrat
relatives à une location qui va avoir Etat : réservé, confirmé, soldé
CONTRAT lieu ou qui a actuellement lieu. Une DateCréation
location s’étend éventuellement sur DateDébut
plusieurs semaines consécutives. DateFin
CodeTarif
PrixSemHS (prix semaine haute
Regroupe les informations liées à la
TARIF saison)
tarification
PrixSemBS (prix semaine basse
saison)
1. Pourquoi l’information CAcumulé de l’entité PROPRIETAIRE est-elle une propriété ?

2. La propriété Equipements est destinée à décrire les principaux équipements de
l’appartement : téléviseur, lave-vaisselle, ... Quels sont les inconvénients liés à une
telle propriété ?
3. Présenter le modèle conceptuel des données décrivant ce système d’information en
tenant compte des règles de gestion suivantes :
- La notion de co-propriété ne doit pas être prise en compte ce qui revient à dire que
tout appartement appartient à un et un seul propriétaire.
- A tout appartement correspond un code tarif
- Seules les noms des entités figureront sur le modèle.
4. On restreint le domaine étudié à la gestion des locations des appartements possédés
par M. Kodjo. Les entités recensées sont données ci-dessous :

Regroupe toutes les informations NumAppartement
APPARTEMENT
relatives aux appartements de M. Kodjo Adresse
NumPériode
Cette entité admet une occurrence
PERIODE NumSemaine
par semaine réservée ou occupée
Année
NumLocataire
Nom
Prénom
LOCATAIRE
sur le locataire Adresse2
CodePostal
Ville
Tel
Pour une semaine donnée, un appartement de M. Kodjo peut être :

- soit réservé ou occupé par un locataire
- soit libre
- soit indisponible (ce cas correspond à l’occupation de l’appartement par M. Kodjo)
Discuter la proposition de modélisation suivante qui est destinée à représenter l’occupation
des appartements de M. Kodjo :
5. On souhaite décrire pour chaque appartement les différentes pièces qui le composent
ainsi que leur superficie. Par exemple : l’appartement n° 345 possède une kitchenette
de 4 m2, une salle de bains de 4 m2, un séjour de 20 m2 et une terrasse de 5m2.
Enrichir le modèle conceptuel afin de représenter une telle réalité.
EXERCICE 9 : Etude de cas
Le service du personnel d’une entreprise souhaite gérer les employés. Ces derniers sont
identifiés par un numéro. Ils sont répartis dans différents services repérés par un numéro, un
nom et une localisation. On souhaite stocker également le nom, la date d’embauche, la
qualification, le numéro d’employé du manager pour chaque employé ainsi que le salaire de
base.
Parmi les employés de l’entreprise, on souhaite intégrer pour les commerciaux en plus de leur
salaire de base une rubrique mentionnant le montant des commissions.
TAF :
1. Etablir le Modèle Conceptuel des Données (MCD) correspondant.
2. Donner le MLDR correspondant.
3. Donner le MPhD de ce SI.
4. En utilisant le SGBD SQL Server, réaliser l’implémentation de ce SI.
EXERCICE 10 Etude de cas
Un comité d'entreprise veut gérer un ensemble d'informations sociales concernant les enfants
de ses salariés. Un technicien, amateur d'informatique, a réalisé le tableau suivant :
TAF :
1. Indiquer les faiblesses qu'amène ce tableau
2. Réaliser le M.C.D. qui corrigerait ces faiblesses
3. Réaliser le M.L.D. correspondant
5. En utilisant le SGBD MySQL, réaliser l’implémentation de ce SI.
EXERCICE 11
1. Définir ‘Modèle‘, ‘Concept’ et ‘Donnée’.
2. Donner les avantages d’une méthode de développement.
3. Donner trois (3) types d’approches des problèmes d’informatisation.
EXERCICE 12
A la suite de la description des besoins d’un responsable d’entreprise, un informaticien ressort le
Modèle Conceptuel de Données suivant :
TAF :
1. Rappeler les différentes règles de passage du MCD au MLDR identifiées dans le MCD ci-
dessus.
2. Donner le MLDR correspondant.
EXERCICE 13
Soit le MPD implémenté dans la base de données relationnelle constituée de deux tables :
CLIENT ET COMMANDE.
CLIENT
NoClient NomClient TypeClient
1 PROFESSIONNEL
2 AMAH PARTICULIER
2 KAO MEDECIN
COMMANDE
NoCommande DateCommande DateLivraison NoClient
101 15/12/1999 3
102 17/12/1999 16/12/1999 1
103 17/12/1999 22/12/1999 1
TAF :
1. Identifier les faiblesses de conception et réalisation de ce SI constitué de deux tables.
2. Retrouver le MLDR à partir de ces deux tables.
3. En déduire le MCD de ce SI.
EXERCICE 14
1. Définir « Génie Logiciel.

2. Donner les facteurs internes de la qualité du logiciel.
3. Donner les facteurs externes de la qualité du logiciel.
4. Qu’est-ce qu’un projet ?
5. Donner sous forme d’un triangle les contraintes d’un projet.
6. Rappeler les principales activités du cycle de vie d’un logiciel ou application.
7. En quoi consiste la phase de conception du logiciel ?
8. Qu’est-ce que la phase d’intégration ?
EXERCICE 15
1. Citer trois (3) types de maintenances dans le processus de développement d’un logiciel.
2. Qu’est-ce qu’une méthode de développement logiciel ?
3. Donner les avantages d’une méthode de développement.
4. Donner trois (3) types d’approches des problèmes d’informatisation.
5. Qu’est-ce que MERISE ? UML ? Quelle différence y-a-t’ il entre les deux méthodes
d’informatisation ?
La société HIT-TECHNOLOGY décide d’informatiser le suivi de ses fournisseurs. Pour
y arriver, elle procède par étapes. La première étape est décrite verbalement comme suit :
Un fournisseur peut avoir une ou plusieurs livraisons. Une livraison ne peut provenir que d’un
seul fournisseur. Une livraison est caractérisée par son numéro et sa date de livraison et un
fournisseur est caractérisé par un code unique, sa raison sociale, son adresse et son téléphone.
TAF :
1. Donner le schéma entités-associations ou le MCD de ce système d’information.
2. Donner la (les) règle (s) de passage du MCD au MLD qui figure (ent) dans le MCD de la
question précédente.
3. Donner le schéma relationnel ou le MLDR de ce système d’information.
4. Donner le schéma physique ou le modèle physique de données (MPhD) de ce système
d’information.
EXERCICE 17
1. Quels sont les enjeux de l’informatisation pour l'organisation ?
2. Quels sont les facteurs de la complexité de l'informatisation ?

3. Quels sont les critères d'un bon système informatique ?

Voici le résultat simplifié d’une analyse faite auprès d’une compagnie d'assurance qui
désire informatiser la gestion des contrats auto. Sachant que :
• Un client peut assurer plusieurs voitures auprès de la compagnie. Chaque voiture est assurée
par un seul contrat. Un contrat assure une seule voiture.
• En ce qui concerne un client, la compagnie désire connaître son nom, prénom, adresse
complète, numéro de téléphone ainsi qu’un numéro de compte bancaire avec indication de la
banque.
• Chaque contrat contient un numéro de contrat unique, la prime annuelle à payer, la date de
paiement annuel, la marque de la voiture, le modèle de la voiture, le numéro
d’immatriculation de la voiture, la valeur de la voiture et la da te d'acquisition de la voiture.
1. Etablir le Dictionnaire de Données de ce SI.
2. Concevoir le Modèle Conceptuel des Données (MCD) correspondant à ce système
d’information ainsi décrit.
3. En-déduire le MLDR puis le MPD de ce SI.
EXERCICE 19
1. Rappeler et expliquer les différentes phases dans la démarche MERISE.
2. A quels niveaux de la démarche MERISE les modèles suivants sont réalisés : MPD,
MCD, MLT, MOpT, MLDR ?
3. A quelle étape de la démarche MERISE le «Cahier des charges utilisateurs » est-il
rédigé ?
4. A quelle étape de la démarche MERISE le «Cahier des charges technique » est-il rédigé ?
5. A quelle étape de la démarche MERISE le «dossier de réalisation » est-il rédigé ?
6. Qu’est-ce qu’une méthode ?
7. Quelles sont les ressources d’un Système d’Information ?
CORRIGES PROPOSES DES EXERCICES

Réponse exo 1
a. Qu’est-ce qu’un identifiant ? Attribut ? Entité ?
Réponse
Un identifiant est une propriété qui permet d’identifier ou d’indexer de manière unique chaque occurrence
(enregistrement, tuple, instance) de la table.
Un attribut est une propriété, un champ ou une colonne de la table.
Une entité est une table ou relation dans la phase de réalisation de la BDD.
b. SI
Réponse
1. Association Réflexive de type : cardinalité (X,n) - (X,n), avec X=0 ou X=1.
2. MCD
3. MLD (R)
Réponse
PERSONNE (id_Personne, Nom_Personne)
PARENTE (#id_Parent, #id_Enfant)
#id_Parent est l'identifiant (id_Personne) d'un ascendant direct de la personne.

#id_Enfant est l'identifiant (id_Personne) d'un descendant direct de la personne.
La table PARENTE sera en fait l'ensemble des couples (parents-enfants) présent dans cette famille.
4. MPD
Réponse
Réponse exo 2
1. Les différentes phases de la démarche MERISE sont.
Réponse
Le schéma directeur,
L'étude préalable,
L'étude détaillée,
L'étude technique,
La production,
La qualification,
La maintenance.
2. Définir les termes suivants : Système, Système informatique, Système d'information.
Réponse
Système : Un système est un assemblage d'éléments reliés entre eux compris dans un ensemble plus
grand.
Système informatique : C’est l’ensemble de logiciel d’une organisation (c’est la partie informatisée /
automatisée du système d’information automatisable)
Système d’information ou (information system) : c’est un ensemble de composants logiciels et matériels
permettant la collecte, le stockage, le traitement et la communication de l'information ainsi que
l'environnement dans lequel ils opèrent dans une organisation.
3. Qu’est-ce qu’une information ?
Réponse
Constituée de trois (3) éléments, une information apporte un renseignement au sujet d'une entité. Elle
nous permet de représenter une entité et de transformer cette représentation.
Une information est un ensemble trois éléments :
 Une entité : l'être, l'objet ou le concept concerné,
 Un attribut : un élément de la description de l'entité,
 Une mesure : une valeur associée à l'attribut.
4. Qu’est-ce que l'étude préalable ?
Réponse
L'étude préalable :
Une étude préalable s'applique à un domaine ou à une grande fonction de l'entreprise. Également
appelée: étude de faisabilité.
L'objectif de cette étape est d'obtenir le descriptif complet de la nouvelle solution pour le domaine
envisagé, mais en plusieurs phases, de sorte à envisager les différentes hypothèses possibles et à
s'orienter progressivement vers la solution optimum.
5. Donner la définition de l'étude détaillée.
Réponse
L'étude détaillée :
L'étude préalable ne porte que sur les processus majeurs. La description des données et des
traitements y est succincte. L'étude détaillée va décrire tous les processus composants le
fonctionnement du futur système; définir précisément les informations utilisées et mémorisées;
spécifier complètement les tâches à effectuer.
6. Définir les mots suivants « Modèle », « Concept »
Réponse
Un modèle est une représentation de la réalité.
Un concept est une construction de l'esprit permettant de mieux saisir intellectuellement le réel.
Réponse exo 3
Réponse
Trois (3) objectifs/avantages des méthodes d'informatisation:
 Réduire la complexité des informatisations (exemple : en identifiant et donc en maîtrisant les
facteurs de cette complexité),
 Rendre cohérents tous les projets (ex. : même approche, même « style » des dossiers, meilleure
intégration entre projets),
 Capitaliser les expériences (ex. : réutilisation des solutions ayant résolu les mêmes problèmes,
acquisition de savoir-faire),
 Augmenter la qualité des travaux d'informatisation (exemple : mêmes standards),
 Augmenter la productivité des travaux d'informatisation (exemple : standardisation augmente
l’efficacité),
 Améliorer les communications entre intervenants (utilisateurs et informaticiens).
Réponse
3. Donner un exemple des méthodes systémiques et un exemple des méthodes orientées- objets.
Réponse
4. Définir et dire à quel niveau des modèles MERISE se situent MCC ? MLD ? MOpT ?
Réponse
MCC : Modèle Conceptuel de Données, c’est en effet l’un des premiers modèles élaborés permettant
de ressortir les différents flux et acteurs intervenant dans le système. Il se situe au niveau conceptuel.
MLD : Modèle Logique de Données se situe entre le MCD et le MPhD. Il se situe au niveau
organisationnel.
MOpT : Modèle Opérationnel des Traitements, la dernière, il se situe au niveau de l’implémentation
de l’Interface Homme-Machine (IH-M). Il se situe au niveau physique.
Réponse
But : Conception et réalisation des Systèmes d’Information.
Réponse exo 4
1. Définir le MOT.
Réponse
MOT : Modèle Organisationnel des Traitements. C’est un modèle élaboré au niveau de la phase
logique de la démarche MERISE.
2. Donner la différence fondamentale entre le MOT et le MCT.
Réponse
Le modèle organisationnel des traitements (MOT) encore appelé MLT (Modèle Logique des
Traitements), il décrit avec précision l’organisation à mettre en place pour réaliser une, ou le cas
échéant plusieurs, opérations figurant dans le MCT : c’est à dire qui fait quoi, où, quand,
comment. A un MCT correspond donc généralement plusieurs MLT.
Les notions introduites à ce niveau sont le poste de travail, la phase, la tâche et la procédure.
3. Soit le modèle conceptuel des données (MCD) suivant :
c. Donner la Règle de passage du MCD au MLDR qui apparaît dans le MCD ci-dessus.
Réponse
Règle de passage (x-1) (x-n) avec x=0 ou x=1 : importation de la clé primaire du côté (x-n) vers le
côté (x-1).
Justification :
Relation binaire aux cardinalités (X, 1) - (X, n), X=0 ou X=1
La Clé Primaire de la table à la cardinalité (X,n) devient une Clé Etrangère dans la table à la
cardinalité (X,1).
d. Donner le modèle logique des données relationnelles (MLDR) correspondant en respectant la
règle de passage du MCD au MLDR.
Réponse
EMPLOYE (id_Employe, Nom_Employe, #id_Societe)
SOCIETE (id_Societe, Nom_Societe,)
Réponse exo 5
Soit le SI suivant décrit verbalement : Un étudiant parle une ou plusieurs langues avec un
niveau. Chaque langue est donc parlée par 0 ou n étudiants avec un niveau. Pour chaque
niveau, il y a 0 ou plusieurs étudiants qui parlent une langue.
a. Traduire ce cahier des charges en MCD.

Réponse
MCD
Etudiant (1, n) (0, n) Langue

NoEtudiant
Parler
NoLangue
Nom_Etudiant Nom_Langue
(0, n)
Niveau
NoNiveau
Nom_Niveau
b. Déduire le MLDR de ce SI en respectant les règles de passages.

Réponse
Etudiant (NoEtudiant, Nom_Etudiant)
Niveau (NoNiveau, Nom_Niveau)
Langue (NoLangue, Nom_Langue)
Parle (NoEtudiant, NoNiveau, NoLangue)
c. Réalise le modèle physique des données (MPD) du SI.
Réponse
MPD
Etudiant
NoEtudiant int Langue
Nom_Etudiant varchar(30) NoLangue int
Nom_Langue varchar(30)
NoEtudiant = NoEtudiant
Niveau NoLangue = NoLangue
NoNiveau int
Nom_Niveau varchar(30)
Parler
NoNiveau = NoNiveau NoEtudiant int
NoLangue int
NoNiveau int
Réponse exo 6
Soit le MCD suivant :
1. Rappeler la règle de passage du MCD au MLD qui apparaît dans ce MCD.

Réponse
Relation binaire aux cardinalités (X,n) - (X,n), X=0 ou X=1
Il y a création d'une table supplémentaire ayant comme Clé Primaire une clé composée des
identifiants des 2 entités. On dit que la Clé Primaire de la nouvelle table est la concaténation des Clés
Primaires des deux autres tables. Si la relation est porteuse de donnée, celles -ci deviennent des
attributs pour la nouvelle table.
2. Réaliser le modèle logique des données (MLD) du SI.
Réponse
association (n°association)
adhérents (n°adhérent)
regrouper (n°association, n°adhérent)
3. Réaliser le modèle physique des données (MPD) du SI
Réponse
MPD
adhérents
association
Noadhérent int
Noassociation int
Noadhérent=Noadhérent
Noassociation = Noassociation regrouper

Noassociation int
Noadhérent int
Réponse exo 7
Réponse
Cf réponse exo 3:
Réponse
Cf réponse exo 3:
Réponse
Cf réponse exo 3:
4. Définir et dire à quel niveau des modèles MERISE se situe MCC ? MLD ? MOT ?
Réponse
Cf réponse exo 3:
Réponse
MERISE : Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprises.
But : Conception et réalisation des Systèmes d’Information.
Réponse exo 8 : Etude de cas

Soit le système d’information de l’activité de gestion des locations saisonnières d’une
agence immobilière. Une analyse de l’existant a permis de dégager les entités suivantes :

NumPropriétaire
Nom
Prénom
Adresse1
PROPRIETAIRE relatives aux propriétaires CodePostal
d’appartements Ville
NumTel1
NumTel2
E-mail
Cacumulé
NumLocation
Regroupe toutes les informations Catégorie : 1, 2, ou 3 étoiles
APPARTEMENT des appartements meublés mis à la Type : T2, T3, T4
location NbPersonnes
AdresseLocation
Photo
Equipements
NumLocataire
NomLocataire
PrénomLocataire
Regroupe toutes les informations Adresse1Locataire
sur les locataires qui ont effectué Adresse2Locataire
LOCATAIRE
au moins une location par CodePostalLocataire
l’intermédiaire de l’agence VilleLocataire
NumTel1Locataire
NumTel2Locataire
E-mailLocataire
Regroupe toutes les informations NumContrat
relatives à une location qui va avoir Etat : réservé, confirmé, soldé
CONTRAT lieu ou qui a actuellement lieu. Une DateCréation
location s’étend éventuellement sur DateDébut
plusieurs semaines consécutives. DateFin
CodeTarif
PrixSemHS (prix semaine haute
Regroupe les informations liées à
TARIF saison)
la tarification
PrixSemBS (prix semaine basse
saison)
1. Pourquoi l’information CAcumulé de l’entité PROPRIETAIRE est-elle une propriété ?

Réponse
Bien que pouvant être une donnée calculée par le système d'information, il est préférable d'avoir le
chiffre d'affaire cumulé en propriété de manière à pouvoir accéder plus rapidement à l'information
(allègement des traitements). C'est une "dénormalisation".
2. La propriété Equipements est destinée à décrire les principaux équipements de l’appartement :
téléviseur, lave-vaisselle, ... Quels sont les inconvénients liés à une telle propriété ?
Réponse
Le fait de regrouper toutes les caractéristiques des équipements dans une même propriété ne
permettra pas de faire des traitements précis sur ces derniers. Par exemple, il sera impossible de lister
tous les appartements de type T2 qui possède un lave-vaisselle.
L'isolement des différents composants peut être réalisé de deux manières;
- Introduire dans l'entité APPARTEMENT des propriétés booléennes telles que
Téléviseur, Lave-vaisselle, etc.
- Créer une entité TYPE-EQUIPEMENT et mettre en place une association (m-n) entre l'entité
APPARTEMENT et l'entité TYPE-EQUIPEMENT.
3. Présenter le modèle conceptuel des données décrivant ce système d’information en tenant compte
des règles de gestion suivantes :
- La notion de co-propriété ne doit pas être prise en compte ce qui revient à dire que tout
appartement appartient à un et un seul propriétaire.
- A tout appartement correspond un code tarif
- Seules les noms des entités figureront sur le modèle.
Réponse
4. On restreint le domaine étudié à la gestion des locations des appartements possédés par M. Kodjo.
Les entités recensées sont données ci-dessous :

Regroupe toutes les informations
NumAppartement
APPARTEMENT relatives aux appartements de M.
Adresse
Kodjo
NumPériode
Cette entité admet une occurrence
PERIODE NumSemaine
par semaine réservée ou occupée
Année
NumLocataire
Nom
Prénom
LOCATAIRE
sur le locataire Adresse2
CodePostal
Ville
Tel
Pour une semaine donnée, un appartement de M. Kodjo peut être :

- soit réservé ou occupé par un locataire
- soit libre
- soit indisponible (ce cas correspond à l’occupation de l’appartement par M. Kodjo)
Discuter la proposition de modélisation suivante qui est destinée à représenter l’occupation
des appartements de M. Kodjo :
Réponse
Cette représentation n'est pas satisfaisante car elle admet que le locataire 2 par exemple occupe
l'appartement n°1 pour la période 3 et que le locataire 15 occupe également l'appartement n°1 pour la
période 3. Le système d'information accepte qu'un appartement soit loué pour la même période à deux
locataires différents.
Il faut pouvoir représenter le fait que pour un couple d'occurrence APPARTEMENT-PERIODE, on
n'admette qu'une et une seule occurrence de LOCATAIRE.
5. On souhaite décrire pour chaque appartement les différentes pièces qui le composent ainsi que leur
superficie. Par exemple : l’appartement n° 345 possède une kitchenette de 4 m2, une salle de bains
de 4 m2, un séjour de 20 m2 et une terrasse de 5m2.
Enrichir le modèle conceptuel afin de représenter une telle réalité
Réponse
Réponse exo 17
1. Quels sont les enjeux de l’informatisation pour l'organisation ?
Réponse
 Augmenter la productivité en améliorant l’efficacité des utilisateurs,
 Améliorer les conditions de travail : enrichissement des tâches,
 Rendre un meilleur service (de qualité, rapide, etc.) aux partenaires de l'organisation.
2. Quels sont les facteurs de la complexité de l'informatisation ?
Réponse
 Difficultés techniques de l'informatique : complexité de la mise en œuvre des
matériels, complexité de la construction logicielle, réflexion abstraite, contraintes techniques,
 Constantes novations (matérielle et logicielle),
 Symbiose requise entre l'application informatique et toute l'organisation (et ses
partenaires),
 Multiplicité des décisions et nombreux domaines (humain, financier, technique, etc.)

de l'organisation concernés.
3. Quels sont les critères d'un bon système informatique ?
Réponse
 Productivité (en rationalisant le processus d'informatisation) :
 Établissement d'une ligne directrice des informatisations,
 Planification et suivi des performances,
 Efficacité des études informatiques,
 Utilisation judicieuse des technologies.
 Qualité :
 Conformité de la réalisation par rapport aux besoins,
 Documentation correcte,
 Adaptabilité,
 Fiabilité,
 Facilité d'utilisation.
 Rentabilité (c’est-à-dire le gain pour l'organisation relativement au coût de
l'informatisation).
Note : Le reste des exercices seront des travaux de recherche pour l’étudiant.
GLOSSAIRE
A M
Abstraction : L'abstraction consiste à choisir, MERISE : Méthode d’Etude et de
parmi l’ensemble des propriétés de plusieurs
Réalisation Informatique pour les Systèmes
objets du monde réel ou imaginables, un
d’Entreprise, c’est une méthode systémique
certain nombre d’entre elles pour caractériser
d’informatisation.
un objet-type, ou objet idéal, qui est ensuite
plus commode à manier qu’une énumération MERISE 2 : Méthode d’Etude et de
d’objets réels, surtout si elle est infinie. Ainsi Réalisation Informatique pour les Systèmes
les nombres pairs ou les nombres premiers ont d’Entreprise version 2.
un caractère d’abstraction. Mais à vrai dire, les
MLDR : Modèle Logique des Données
nombres eux-mêmes ont un caractère Relationnelles, deuxième modèle statique
d’abstraction. ... déduit du Modèle Conceptuel de Données
ACSI : Analyse et Conception des Systèmes (MCD) dans la démarche MERISE élaboré
Informatiques (d’Information). dans la phase organisationnelle, décrit Quels
sont les fichiers physiques qui seront
AGL : Atelier de Génie Logiciel (CASE
implantés.
=Computer Aided Software Engineering en
anglais) : ingénierie du logiciel assisté par Modèle : Le mot modèle synthétise les deux
ordinateur. sens symétriques et opposés de la notion de
ressemblance ou de représentation. En effet,
Analyse : processus d'examen de l'existant.
il est utilisé ‘pour un objet dont on cherche à
Analyse systémique : Analyse qui envisage donner une représentation, qu'on cherche à
les éléments d'une conformation complexe, les imiter (exemple : le « modèle » du peintre, le
faits (notamment les faits économiques), non « modèle » que constitue le maître pour le
pas isolément mais globalement, en tant que disciple),’ pour un concept ou objet qui est la
parties intégrante d'un ensemble dont les représentation d'une autre (le « modèle réduit
différents composants sont dans une relation de », le « modèle » du scientifique) ou
dépendance réciproque. simplement
Application de bases de données : Utilisation Un modèle est une représentation de la
de moyens informatiques pour répondre à un réalité.
besoin déterminé en faisant appel de manière
MOT : Modèle Organisationnel des
importante à une ou plusieurs bases de données
Traitements, décrit Comment déployer les
à travers un système de gestion de bases de
traitements sur les machines et postes de
données (SGBD) (Database application).
travail.
Architectonique : C’est la technique de la
MPD/MPhD : Modèle Physique des
construction, mais aussi la structure ou
Données, troisième modèle statique dans la
l’organisation de la construction. Est
démarche MERISE élaboré dans la phase
architectonique ce qui est conforme à la
physique. L’élaboration de ce modèle
technique de l’architecture.
nécessite la connaissance du SGBD (Système
Attribut : Un attribut est encore appelé champ de Gestion des Bases de Données).
ou colonne de la table dans la phase de la
MySQL : My SQL, est un SGBD
réalisation. relationnel. Il occupe la 3ème place dans le

classement mondial 2017 des SGBD les plus
B
utilisés derrière Oracle, SQL Server et devant
Base de données (BD ou BDD) : Une base de SQLite, Ingres, PostGreSQL, etc.
données est un ensemble de tables, ayant pour
but d’exploiter des informations de façon N
conviviale et rapide ou ensemble de données NTIC : Nouvelles Technologies de
(de l’organisation) structurées et liées entre l’Information et de la Communication.
elles.
O
 stocké sur support à accès direct (disque), OMG: Object Managment Group.
 géré par un SGBD (Système de Gestion de
Bases de Données), OMGL : Acronyme signifiant Outils et
Modèles pour le Génie Logiciel.
 accessible par un ensemble d'applications.
Opération : C’est un ensemble d'actions
C
exécutées par le système suite à un
C++ : Langage de programme mis en place par événement, ou à une conjonction
Microsoft. d'événements.
Cardinalité : La cardinalité caractérise la Outil : C’est un logiciel supportant une
participation d’une entité à une association. méthode.
Cardinalité maximale : Elle donne le P
nombre maximum de participation de
Processus : C’est un sous-ensemble de
chacune des occurrences de l’entité à
l'activité de l'entreprise, cela signifie que
l’association.
l'activité de l'entreprise est constituée d'un
Cardinalité minimale : Elle donne le
ensemble de processus. Un processus est lui-
nombre minimum de participation de chacune
même composé de traitements regroupés en
des occurrences de l’entité à l’association.
ensembles appelés opérations.
Champ : Voir attribut ou colonne.
R
CIF : Contraintes d’Intégrité Fonctionnelle.
La réalisation : Elle consiste à faire
Clé artificielle : En opposition à une clé concrètement ce qu’il y’a à faire.
naturelle, dans le domaine des bases de
Relations : 1. Une relation est une liaison
données, aussi parfois appelée clé de
que vous définissez entre des tables ayant un
remplacement (de l'anglais surrogate key)
sujet en commun et dont les informations
désigne un ensemble de données adjointes
sont stockées dans différentes tables. 2. Sous
aux données d'une table pour les indexer.
ensemble du produit cartésien d’une liste de
Clé candidate : C’est un ensemble des domaines. C’est en fait un tableau à deux
données permettant d'indexer chaque ligne dimensions dont les colonnes correspondent
d'une table donnée de manière différenciée. aux domaines et dont les lignes contiennent
Une même base de données peut posséder des tuples. Une relation est un peu comme
plusieurs clés candidates distinctes. Une table une classe (programmation orientée objet)
avec des lignes en doublon ne possède aucune qui ne posséderait que des attributs et donc
clé candidate. chaque instance représenterait un tuple. Une
Clé étrangère : Dans une base de données relation (2) est donc une table comportant
relationnelle, est une contrainte qui garantit des colonnes (appelées aussi attributs) dont le
l'intégrité référentielle entre deux tables. nom et le type caractérisent le contenu qui
Clé naturelle : C’est une clé choisie parmi les sera inséré dans la table.
clés candidates pour indexer une base. Requêtes : Une requête est composée d’une
Clé primaire : La clé primaire est un ou plusieurs tables vous permettant une
visualisation sélective ou ordonnée de vos
identifiant (ou champ ou groupe de champs)
tables.
qui permet d’identifier ou d’indexer de
manière unique un enregistrement ou une S
entrée d’une table. La clé primaire appartient SAT : Structure d'Accès Théoriques.
nécessairement à l'ensemble des clés
candidates. SDI : Schéma Directeur de l'Informatique.
Colonne : C’est un champ de la table. SGBD : Système de Gestion des Bases de

Données, logiciel ou application qui facilite
Concept : idée d'un objet conçu par l'esprit, la création des bases de données et la
permettant d'organiser les perceptions et les manipulation de données. Les bases de
connaissances. données sont créées dans un SGBD.
Conception : La conception est le processus SICOA: Système d'Information de Contrôle
de définition de la future application Opérationnel et Administratif.
informatique.
SICOP : Système d'Information de Contrôle
Conception participative : Conception au Opérationnel Physique.
cours de laquelle les utilisateurs participent en
temps qu'experts de l'utilisation de la SQL : Structured Query Language, langage
technologie dans son contexte, et en temps de requêtes unifiées en français est le langage
qu'innovateurs en contribuant des idées qui universel pour interagir avec les bases de
permettent d'explorer de nouvelles voies de données relationnelles.
conception. Synchronisation : La synchronisation d'une
Concrétisation : phénomène inverse de opération définit une condition booléenne sur
l'abstraction: passe du modèle au monde réel. les événements contributifs devant
déclencher une opération.
D
Système : ensemble d'éléments en
Domaine : 1. Ensemble des valeurs d’un interaction dynamique, dont les éléments
attribut. 2. C’est un découpage du système sont organisés et coordonnés en vue
d'information de l'entreprise, défini dans un d'atteindre un objectif, qui évolue dans un
schéma directeur en fonction de sa stratégie. environnement.
Par exemple, une banque peut avoir défini les
domaines Gestion de clientèle, Gestion des Système d’organisation : Le système
participations financières, Gestion de d’organisation est constitué de trois entités :
trésorerie, Gestion des Ressources Humaines, le système de décision, le système opérant et
etc. le système d’information.
E Le système de décision (ou système de

pilotage) : C’est le système qui reçoit des
Enregistrement : Un enregistrement informations du système opérant et prend des

représente une entrée ou une ligne de la table. décisions pour la bonne marche de
Evénement : Un événement représente un l’organisation ou de l’entreprise.
changement dans l'univers extérieur au Système d’Information (SI) : Systèmes
système d'information, ou dans le système d'Information, ensemble des moyens
d'information lui-même. (humains et matériels) et des méthodes se
rapportant à la collecte, au stockage, au
G
traitement et à la circulation de l'information
Génie Logiciel (ou l'ingénierie des systèmes dans une organisation. Le système
d'information) : C’est l’ensemble des activités d’information sert d’intermédiaire entre le
de conception et de mise en œuvre des système opérant et le système de pilotage.
produits et des procédures tendant à
Système Informatique (SI) : Le Système
rationaliser la production du logiciel et de son
Informatique est la partie informatisée ou à
suivi
automatiser du système d’information
I automatisable.
Identifiant : Un identifiant (dans la phase de Le système opérant : C’est le système qui
la conception) est appelé clé primaire de la transforme ou qui traite des données d’entrée
table dans la phase de la réalisation. de l’organisation afin d’obtenir des
Informatique de Gestion : C’est informations à transmettre au système de
l’informatisation des systèmes d'information. pilotage.
J T
Java : Langage de programmation mis en place Tables : Une table est une structure que l’on
par Sun. définit afin de recevoir des informations
traitant d’un même sujet. Composée de
L
champs, elle définit les règles de validation
Logiciel ou Application: C’est un ensemble de ceux-ci. A l’utilisation, elle contiendra les
des programmes, procédés et règles, et données rentrées relatives à la table.
éventuellement de la documentation, relatifs au
TIC : Technologies de l’Information et de la
fonctionnement d'un ensemble de traitements
Communication.
de l'information
U
M
UML : Unified Modeling Language, langage
Maître (Maîtrise) d'œuvre (MOE): Personne
de modélisation unifiée en français, est un
physique ou morale qui reçoit mission du
langage offrant une interface graphique pour
maître d'ouvrage pour assurer la conception et
l’élaboration de différents diagrammes dits
la réalisation de l'ouvrage.
‘Diagrammes UML’ dans les phases de
Maître (Maîtrise) d'ouvrage (MOA) : développement d’un système informatique
Personne physique ou morale propriétaire de ou d’information. C’est une ‘méthode’
l'ouvrage. Il détermine les objectifs, le budget orientée-objets d’informatisation.
et les délais de réalisation.
Note : UML est un langage et non une
MCC : Modèle Conceptuel de la méthode.
Communication. UML 2 : Unified Modeling Language

version 2, deuxième version d’UML, langage
MCD : Modèle Conceptuel des Données, l’un
de modélisation unifiée deuxième version
des trois (3) modèles statiques dans la
d’UML en français, offre d’autre concepts
démarche MERISE élaboré dans la première
qui ne sont pas offerts dans la première
phase de la conception d’une base de données.
version d’UML.
Les autres modèles statiques sont : MLDR et
MPD. C’est le modèle qui décrit Comment les V
données sont structurées. VB : Visual Basic, c’est un langage de
MCT : Modèle Conceptuel des Traitements, programmation mise en place par Microsoft.
décrit Comment les traitements utilisant les
données sont structurés.
BIBLIOGRAPHIE ET WEBOGRAPHIE
 A. ROCHFELD et J. MOREJON, La méthode MERISE, tome 3 : gamme opératoire, Les
Éditions d'Organisation, 1989
 G. PANET et R. LETOUCHE, MERISE/2, modèles et techniques MERISE avancés, Les
Éditions d'Organisation, 1994
 D. NANCI et B. ESPINASSE, Ingénierie des Systèmes d’Informations : MERISE
Deuxième génération, Vuibert, 2001
 Modélisation objet avec UML, Pierre-Alain Muller et Nathalie Gaertner, Eyrolles, 2000,
2ème édition (MO.UML), C’est la référence française sur UML. A noter
particulièrement l’excellent chapitre 2 sur l’approche objet. Existe en format poche :
collection « Best of » chez Eyrolles.
 Introduction à UML, Tom Penders, OEM 2002.
 Mémento UML, Pascal Roques, Eyrolles, 2005 (UML 2) La synthèse la plus concise !
 UML2 en action, Pascal Roques et Franck Vallée, Eyrolles 2004. Le même que le
précédent en plus développé mais aussi plus abstrait.
 UML2 et les designs patterns, Craig Larman, Pearson Education 2005.
 Modélisation UML avec Rational Rose 2000, Terry Quatrani, Eyrolles 2000.
 merise.developpez.com/
Contacts
Tel: (+228) 90 47 51 03 / 93 32 77 18 / 97 31 77 52
E-mail:[email protected]
Site web: www.hittechnologie.net
01 BP 1341 Lomé-Togo
Avec HIT-T SARL U, faites la différence!

12 Livre Acsi (Merise-Uml) 1 Ere Edition

Transféré par

Droits d'auteur :

Formats disponibles

12 Livre Acsi (Merise-Uml) 1 Ere Edition

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

12 Livre Acsi (Merise-Uml) 1 Ere Edition

Transféré par

Droits d'auteur :

Formats disponibles

HIT-TECHNOLOGY SARL U: www.hittechnologie.

ACSI ET SI : MERISE ET UML

Pour concepteur et développeur de bases de données,

A l’usage des BTS, Licence et Master

ANALYSE ET CONCEPTION DES

Formateur en développement applicatif

«L’avenir de l’Homme se trouve dans sa manière de penser»

© Tous droits réservés 2017-2020 HIT-T

PRIX : 2 500 F CFA

DANS LA MÊME COLLECTION

1 ARCHITECTURE ET INTERCONNEXION RESEAU

COLLECTION HIT-T SARL U (Disponible sur : www.hittechnologie.com ou www.hittechnologie.net )

Table des matières

POURQUOI CE LIVRE ? .............................................................................................................................. 6

OBJECTIFS SPECIFIQUES DE CE LIVRE ................................................................................................ 6

INTRODUCTION GENERALE .................................................................................................................... 7

CHAPITRE I : GENERALITES, DEFINITIONS ET CONCEPTS ............................................................. 8

CHAPITRE II : LES MODELES ET FORMALISMES DE MERISE ....................................................... 27

1. PHASES DANS LA CREATION D’UN SYSTEME D’INFORMATION (SI) ....................................... 28

3.3.2.2. La phase ............................................................................................................................................. 48

CHAPITRE III : LA DEMARCHE MERISE ET INTRODUCTION A UML ........................................... 59

1. LA DEMARCHE MERISE ...................................................................................................................... 60

1.6.1. Étape 1 : l'installation .................................................................................................................................. 67

CONCLUSION GENERALE ....................................................................................................................... 81

PHASES D’ANALYSE ET DOCUMENTS PRODUITS ............................................................................. 82

RECUEIL DES EXERCICES ...................................................................................................................... 89

CORRIGES PROPOSES DES EXERCICES .............................................................................................. 96

GLOSSAIRE ............................................................................................................................................... 106

BIBLIOGRAPHIE ET WEBOGRAPHIE ................................................................................................. 110

A QUI S’ADRESSE CE LIVRE ?

CHAPITRE I : GENERALITES, DEFINITIONS ET CONCEPTS

Analyse Système MERISE

Figure 1.1 : Un système vu comme une « boîte noire »

Figure 1.2 : Système : de la « boîte noire » à la« boîte blanche »

 non redondance (un seul exemplaire de chaque information),

 le système de pilotage : définit les objectifs de l'entreprise et s'efforce de tout mettre en

Figure 1.3 : Représentation et interaction entre les différents systèmes d’organisation

 la circulation : accès à la mémoire et échange entre les acteurs,

 Productivité (en rationalisant le processus d'informatisation) :

3.4. Base de données

Figure 1.4 : Les étapes de la conception.

Figure 1.5 : Concept de conception et de réalisation d’un logiciel

Le projet se déroule dans le temps : il commence avec la conception, il se termine

Figure 1.6 : Concept de conception

Analyse fonctionnelle Analyse organique

Point de vue du maître d’ouvrage Point de vue du maître d’œuvre

Build the right system Build the system right

Construire le bon système Construire bien le système

3.5.3. Troisième distinction : Analyse organique = Architecture système + Analyse détaillée

vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en

3.6.2.1.Cycle de vie en cascade

Figure 1.7 : Modèle de cycle de vie en cascade

Figure 1.8 : Cycle de vie en V, Conception et réalisation

Figure 1.9 : Cycle de vie en V, Conception et réalisation avec les détails

Figure 1.11 : Modèle de cycle de vie en V

3.6.2.3.Cycle de vie en spirale

Figure 1.12 : Modèle de cycle de vie en spirale

3.7. Méthodes d'informatisation

 d'offrir des moyens de pilotage dans la construction du système d'informatisation,