REPUBLIQUE DEMOCRATIQUE DU CONGO

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET

UNIVERSITAIRE

INSTITUT SUPERIEUR DE COMMERCE DE BUKAVU

DEPARTEMENT D’INFORMATIQUE DE GESTION

COURS DE METHODOLOGIE D’ANALYSE

INFORMATIQUE II
(Volume horaire : 60 heures)

G3 INFORMATIQUE DE GESTION

Par l’Assistant OMARI LUKENDO David dit OLD

ANNEE ACADEMIQUE 2022-2023

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 1
CONTEXTE GENERAL

L’émergence d’une institution (entreprise) se justifiera non seulement par la rigueur dans
l’administration mais aussi par l’implantation d’un système informatique dans tous ses services.

La conception d'un système d'information permettra après un temps, la réalisation d’un logiciel.

Cette réalisation n'est pas évidente car elle appelle à réfléchir sur l'ensemble de l'organisation. La

phase de conception nécessite des méthodes permettant de mettre en place un modèle sur lequel on va

s'appuyer pour avoir une application (logiciel). La modélisation consiste à créer une
représentation virtuelle d'une réalité de telle façon à faire ressortir les points aux quels on s'intéresse.

Ce type de méthode est appelé analyse. Il existe plusieurs méthodes d'analyse, celle qu’on doit voir

dans ce cours est : la méthode MERISE deuxième génération.

OBJECTIF GENERAL DU COURS

A la fin de ce cours de méthode d’analyse informatique II, l’étudiant de troisième année de

graduat en informatique de gestion qui l’aura suivi avec attention sera capable, grâce aux explications

et exemples de l’enseignant, d’analyser le système d’information d’une organisation (entreprise) en

utilisant la méthode MERISE deuxième génération et cette analyse conduira à proposer les modèles

qui permettront la réalisation d’un logiciel.

OBJECTIFS SPECIFIQUES

Au terme des enseignements, tout étudiant de troisième année de graduat en informatique de

gestion sera capable de/d’:

- Définir la méthode MERISE/2 ;

- Donnez les différentes extensions de la méthode MERISE/2 ;

- Expliquer et définir les contraintes dans les relations et les sous-types ;

- Déterminez et définir les différentes contraintes sur les sous-types et sur les associations ;

- Définir les évènements et les processus ;

- Elaborer le modèle de flux

- Elaborer sans problème le modèle conceptuel de traitement analytique (MCTA)

- Elaborer sans problème le modèle conceptuel de données analytique ou étendu

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 2
METHODES D’ANIMATION DU COURS

Pour que les objectifs ci-dessus soient atteints, les méthodes suivantes seront utilisées :

- Un enseignement actif-participatif pour faire participer et intéresser les étudiants au cours ;

- Le learning by doing pour permettre aux étudiants d’avoir une idée pratique et se

familiariser avec les notions pratiques ;

- Des travaux pratiques (individuel et en groupe) seront organisés de manière que les

étudiants soient initiés à l’esprit d’analyse.

PLAN ET DETAILS DES TRAVAUX JOURNALIERS

- Un travail dirigé sera organisé après chaque 15h du cours pour permettre l’évaluation de la

maitrise du cours, 4 travaux dirigés seront organisés au total ;

- Une interrogation sera organisée à la fin du cours ;

- Un travail pratique en groupe sera donné pour accentuer la compréhension et marier la

théorie à la pratique.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 3
PLAN DU COURS DETAILLE

INTRODUCTION

1. Contexte général du cours

2. Objectif général du cours

3. Objectifs spécifiques du cours

4. Méthodologie d’enseignement

5. Evaluation

CHAPITRE PREMIER : NOTIONS DE BASE

I.1. Définition de concepts

I.2. Le schéma systémique de l’entreprise

I.3. Cycle de vie d’un système d’information

a. Notion de cycle de vie

b. Différents modelés de cycle de vie d’un logiciel

CHAPITRE DEUXIEME : GESTION D’UN PROJET INFORMATIQUE

II.1. Etude préalable

II.2. Formation de groupe d’étude

II.3. Planification des travaux

II.4. Technique de récolte de donnes

II.5. Analyse de l’existant

CHAPITRE TROISIEME : METHODE MERISE DEUXIEME GENERATION

III.1. Origine de la méthode MERISE

III.2. Différentes phases d’un projet en MERISE

III.3. Différences entre merise et MERISE 2

III.4. Les trois axes de modélisation de MERISE 2

III.5. Axes de modélisation et niveaux d’abstraction

III.6. Pourquoi modéliser ?

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 4
CHAPITRE QUATRIEME : CONCEPTION D’UN SYSTEME D’INFORMATION

ORGANISATIONNEL

IV.1. LE NIVEAU CONCEPTUEL

IV.1.1. Les modèles de flux

IV.1.2. Le modèle conceptuel des données

IV.1.3. Contrainte d’intégrité fonctionnelle

V.1.4. Les Sous-type d'objet et sous-type de relation

V.1.5. Les contraintes d’intégrité statique

IV.1.6. Le modèle conceptuel de traitement analytique

IV.1.7. Cycles de vie des objets

IV.2. LE NIVEAU ORGANISATIONNEL

IV.2. 1. Modèle organisationnel de traitement (MOT)

IV.2. 2. Modèle organisationnel de données (MOD)

CHAPITRE SIXIEME : CONCEPTION D’UN SYSTEME D’INFORMATION

INFORMATISE

VI.1. LE NIVEAU LOGIQUE

VI.1.1. LE MODELE LOGIQUE DES DONNEES

VI.1.2. Le Modèle logique de traitement

VI.2. LE NIVEAU PHYSIQUE

VI.2.1. Le Modèle physique des données

VI.2.2. Le Modèle physique de traitement

CHAPITRE SEPTIEME : LES NOTIONS SUR LES METHODES AGILES

VII.1. LA METHODE UP : « LE PROCESSUS UNIFIE »

VII.1.1. Les principes d’UP.

VII.1.2. Les phases et itérations du processus (aspect dynamique)

VII.1.3. Les activités du processus (aspect statique)

VII.2. LE LANGAGE UML

VII.3. DIFFERENCE ENTRE LA METHODE MERISE ET UP

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 5
REFERENCES BIBLIOGRAPHIQUE

- J.L. BAPTISTE, MERISE/2, Guide pratique (nouvelle Edition), ENI Edition

- H. TARDEAU, A. ROCHFELD, R. COLLETI, la méthode MERISE, Principes et Outils,

les éditions d’organisation, 1979.

- P. COLIN, MERISE 2, Système d’information avancé, V92/2.
- E. d’analyse, MERISE 2, Concepts de base, Modèles et démarche, IUT 2 GRENOBLE

- D. NANCI, B. ESPINASSE, MERISE deuxième génération (4ème édition), éditions Vuibert

2001.

- M. DIVINE, Parlez-vous MERISE ? les éditions les phénomènes

- J.D. Gabay, UML 2 Analyse et conception, Dunod

- P. Roques, UML 2 Par la pratique, 5è édition, Eyrolles

https://sites.google.com/site/coursdinformatiqueenligne/cours/merise/methode-d-analyse

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 6
 INTRODUCTION GENERALE

6. Contexte général du cours

L’émergence d’une institution (entreprise) se justifiera non seulement par la rigueur dans

l’administration mais aussi par l’implantation d’un système informatique dans tous ses services.

La conception d'un système d'information permettra après un temps, la réalisation d’un logiciel.

Cette réalisation n'est pas évidente car elle appelle à réfléchir sur l'ensemble de l'organisation. La

phase de conception nécessite des méthodes permettant de mettre en place un modèle sur lequel on va

s'appuyer pour avoir une application (logiciel). La modélisation consiste à créer une
représentation virtuelle d'une réalité de telle façon à faire ressortir les points aux quels on s'intéresse.

Ce type de méthode est appelé analyse. Il existe plusieurs méthodes d'analyse, celle qu’on doit voir

dans ce cours est la méthode MERISE.

7. Objectif général du cours

A la fin de ce cours de méthode d’analyse informatique II, l’étudiant de troisième année de

graduat en informatique de gestion qui l’aura suivi avec attention sera capable, grâce aux explications

et exemples de l’enseignant, d’analyser un système d’information d’une organisation (entreprise) en

utilisant la méthode MERISE et cette analyse conduira à proposer les modèles qui permettront la

réalisation d’un logiciel.

8. Objectifs spécifiques

Au terme des enseignements, tout étudiant de troisième année de graduat en informatique de

gestion sera capable de/d’:

- Définir la méthode MERISE/2 ;

- Donnez les différentes extensions de la méthode MERISE/2 ;

- Expliquer et définir les contraintes dans les relations et les sous-types ;

- Donnez les différentes contraintes sur les sous-types et sur associations ;

- Définir les évènements et les processus ;

- Elaborer le modèle de conception de traitement analytique (MCTA)

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 7
 - Mettre en interaction les données aux traitements

9. Méthodes d’animation du cours

Pour que les objectifs ci-dessus soient atteints, les méthodes suivantes seront utilisées :

- Un enseignement actif-participatif pour faire participer et intéresser les étudiants au cours ;

- Le learning by doing pour permettre aux étudiants d’avoir une idée pratique et se

familiariser de notions pratiques ;

- Des travaux pratiques (individuel et en groupe) seront organisés de manière que les

étudiants soient initiés à l’esprit d’analyse.

10. Plan et détails des travaux journaliers

- Un travail dirigé sera organisé après chaque 15h du cours pour permettre l’évaluation de la

maitrise du cours, 4 travaux dirigés seront organisés au total ;

- Une interrogation sera organisée à la fin du cours ;

- Un travail pratique en groupe sera donné pour accentuer la compréhension et marier la

théorie à la pratique.

N.B : les notes de ce cours sont entièrement issues de ouvrages de MERISE cites en
bibliographie.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 8
CHAPITRE PREMIER : NOTIONS DE BASE

I.1. DEFINITION DES CONCEPTS.

a. Un système :

Un système est un ensemble d’éléments en interaction dynamique organisés en fonction d’un

but donnée (Joel. De Rosnay).
Plus explicitement, un système est un ensemble d’éléments matériels ou immatériels
(hommes, machines, méthodes, règles, etc.) en interaction et transformant, grâce à un
processus, des éléments (les entrées) en d’autres éléments (les sorties).

Exemple : une chaudière transforme par combustion du charbon en chaleur.

b. Un système d’information :

Un système d'information est un ensemble de méthodes et moyens recueillant, contrôlant,

mémorisant et distribuant les informations nécessaires à l’exercice de l’activité de tous points
de l’organisation.

Une partie du système d’information peut être informatisée. Nous parlons alors de
système informatisé. Ce système informatisé prend appui sur un système informatique
composé de matériel et logiciel de base.

Figure 1: Le SI, le SII, le S. Informatique

L’une des décompositions, désormais classique, du système entrepris en sous-systèmes

est la suivante : le système de pilotage, le système opérant et le système d’information.

Figure 2: Architecture d'un système d’une organisation

Toutefois, cette décomposition étant relativement éloignée de la réalité, une

représentation plus conforme amène à décomposer le système d’information en deux sous-

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 9
systèmes. Le système d’information de pilotage et le système d’information opérant. En effet,
l’information traitée par chacun de ces systèmes n’est pas de même nature. Par conséquent,
les systèmes informatisés traitant ces deux types d’informations seront bien évidemment
différents.

Les méthodes d’étude des systèmes d’information ont pour objectif de décrire ces
systèmes à l’aide de modèles, puis de réaliser les systèmes informatisés en découlant. La
méthode Merise fait partie de cette gamme de méthodes.

Les principes de conception de la méthode Merise sont essentiellement applicables à la

partie opérante, celle-ci faisant appel à des traitements prévisibles et s’appuyant sur des
données qu’il convient à modéliser.

Le système d’information de pilotage prend en charge le pilotage et le traitement de

gestion par exception (états statistiques, historiques, prise de décision, planification, …) ; le
système d’information opérant se voit confier la gestion courante (gestion de la production,
gestion de stock, facturation, comptabilité, …).

Le système d'information réalise alors quatre fonctions essentielles :

✓ Collecter les informations provenant des autres éléments du système ou de

l’environnement externe au système ;
✓ Mémoriser les données manipulées par le système ;
✓ Traiter les données stockées ;
✓ Transmettre des informations vers les autres composantes du système ainsi que vers
l’environnement externe au système.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 10
 CHAPITRE DEUXIEME : GESTION D’UN PROJET INFORMATIQUE.

Par définition, la gestion de projet informatique est le fait d’élaborer une politique par le
biais d’une équipe compétente, dirigée par un chef de projet.
Un projet informatique implique le fait de développer un nouveau logiciel ou d’installer
une solution de système d’information.

II.1. ETUDE PREALABLE

Les études préalables ont pour objectif de donner au maître d’ouvrage un maximum d’informations
objectives sur l’opportunité et la faisabilité générale de l’opération, avant la prise de décision de lancer
(ou de ne pas lancer) l’opération. Elles consistent à définir d’une façon meilleure le problème à
résoudre, et fournit les éléments nécessaires pour répondre à la question oui ou non faut-il informatiser
?
L’étude préalable joue le même rôle que le schéma directeur, mais se limite à un domaine précis dans
l’organisation.
Ainsi l’étude préalable permet de définir l’opportunité et la praticabilité d’informatisation en posant
d’une façon claire le problème à informatiser et les objectifs à atteindre.

II.2. FORMATION DE GROUPE D’ETUDE

Le travail en informatique, notamment au niveau d’informatisation du système d’information est
toujours mené en équipe. Ainsi l’analyste doit après avoir défini les objectifs, constituer le groupe
d’étude chargé de conduire l’application.
Le groupe d’étude est constitué comme suit :
1. L’informaticien (responsable du projet)

2. Différents membres des services ou des départements concernés par le problème

3. Un consultant extérieur

4. Quelques utilisateurs

5. Un ingénieur en organisation

6. Un membre de comité de gestion/direction

L’informaticien responsable du projet et les différents membres de service plus un membre du comité
de gestion ou de direction vont constituer le comité informatique. Ce comité constitue le trait d’union
entre la direction générale et les utilisateurs, notamment pour le suivi de conduite et de la réalisation
du projet.

Un chef de projet informatique doit surtout avoir les atouts suivants :

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 11
• Connaissances générales en informatique : architecture des systèmes, bases de données,
méthodologies de développement,…
• Excellentes connaissances des langages de programmation spécifiques à l’Internet et à
l’Internet mobile (CSS, Java/J2EE, XHTML, AJAX, PHP, ActionScript, framework…)
• Connaissance des SGBDR.
• Maîtrise des méthodologies de développement (cycle en V, en escargot, méthode « agile
» …) et des méthodes orientées objet.

II.3. PLANIFICATION DES TRAVAUX

La conduite et la réalisation d’une application informatique nécessite l’ordonnancement de taches et la

planification.
Ainsi la planification concerne les domaines des études préalables, conceptuelles et de mise en œuvre.
Il existe différentes méthodes de planification en informatique. La plupart de ces méthodes découlent
de la Recherche Opérationnelle (RO). On peut citer les méthodes telles que :
- P.E.R.T (Program Evaluation Review Technic)
- METHODE POTENTIELS METRA
- DIAGRAMME de GANTT
Toutes ces méthodes sont vues dans le cours de recherche opérationnelle.

II.4. TECHNIQUE DE RECOLTE DE DONNEES

Les techniques utilisées lors de l’analyse de l’existant pour recueillir les données sont multiples,
cependant en informatique les techniques comme :
- L’interview
- L’observation
- Documentaire
- Questionnaires (Enquête) sont les plus utilisées.
a. L’interview ou entretien
C’est la technique la plus utilisée pour étudier le système existant.
Les entretiens : sont les interviews à travers lesquels on peut poser les questions pour connaitre en
détail ce qui ne fonctionne pas et ce qu’on peut améliorer.
La technique d’interview nécessite une préparation, ainsi l’analyste doit établir avant l’interview, les
différentes questions à poser aux interlocuteurs ces questions sont souvent conçu à l’aide des outils
informatiques. Cependant l’expérience de l’analyste compte beaucoup au cours de l’interview et à la
fin de l’interview.
- Ne pas utiliser les termes trop techniques ;
- Etre bien habillé ;

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 12
 - Préparer les questions ;
- Rappeler toujours le but de votre visite ;
- Ne pas interrompre celui qui parle ;
- Promettre toujours de passer une fois le travail terminer ;
- Maitriser la langue du travail.
b. L’observation
L’observation nécessite la présence de l’analyste dans les différents postes de travail concernés par
l’application. On recommande toujours au niveau de chaque poste de travail, un délai d’au moins
deux semaines pour observer (voir) la façon de travailler de l’agent ainsi que les documents traités.

c. Technique documentaire
Cette méthode consiste à consulter les documents existants afin de se faire une idée sur la pertinence
des informations contenues dans ce document. Dans le cas où l’entreprise garde des archives, ainsi on
peut toujours se référer à ces archives, pour récolter les données désirées.
d. Technique de questionnaires
Cette technique nécessite des moyens financiers énormes, liés aux problèmes des ressources humaines
et autres.
En outre, cette technique nécessite la présence des spécialistes dans l’élaboration des questions qui
peuvent être de types fermés ou ouverts.

NB :
- Les étapes évoquées ci-dessus sont appelées étapes préliminaires ou travaux
organisationnels.
- Après avoir défini les objectifs, formés des groupes d’études, planifier les travaux choisi les
techniques de récoltes de données, on peut alors passer à l’analyse du système existant.

II.5. ANALYSE DE L’EXISTANT

Avant de concevoir un nouveau système d’information, il est indispensable de bien connaître le

domaine concerné.
L’analyse de l’existant a pour but de recueillir les données qui vont servir pour élaborer le diagnostic
en vue de la recherche et de choix des solutions ou de la solution future permettant l’amélioration du
système actuel. Elle permet aussi de rechercher des points forts et des points faibles du système
existant.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 13
L’analyse de l’existant permet de comprendre la nature du système actuel, décrit la solution présente
du domaine d’étude au terme d’organisation1.
Ainsi l’analyse de l’existant est nécessaire car elle permet de répondre à la question oui ou non faut-il
informatiser.

- Analyse de flux d’information

L’analyse de schéma de circulation des informations (circuit) est l’une des méthodes utilisées pour
représenter ou analyser les flux d’information entre services. C’est la partie la plus essentielle au
niveau de l’analyse de l’existant.

Dans la pratique, il existe différents diagrammes pour présenter la circulation des informations ou la
présentation du circuit des informations.
Dans ce cas, on présente les différentes opérations ainsi que les services concernés par les opérations.
Tout en tenant compte de poste de travail lors de la description de flux d’information, on utilise les
symboles informatiques appropriés.

- Analyse de la structure

La préoccupation majeure est d’étudier en profondeur la structure de département ou service concerné

directement par l’informatisation afin de déceler certains disfonctionnements. L’analyse de la structure
est réalisée à partir de l’organigramme de département ou service concerné.
Dans le cas où il n’existe aucune structure, l’analyste (informaticien) doit lui-même reconstitué
l’organigramme en question en utilisant la technique d’interview ou de questionnaire.

- Analyse des postes de travail

Après avoir analysé la structure de l’entreprise, on peut alors procéder à l’étude de poste de travail.
L’analyse de poste permet de répertorier de manière impersonnelle tous les critères exigibles pour
accéder aux différents postes faisant partie de service à informatiser. Elle permet aussi de décrire les
attributions de chaque poste.
Un poste de travail est défini comme une entité qui exerce une activité au sein d’un service ou d’un
département.
Le poste de travail, concerne chaque service et chaque département, ainsi l’analyste pour réaliser ce
travail aura comme point de référence, la structure de l’entreprise.

- Analyse de documents

Cette étape consiste à analyser et décrire tous les documents entrant, restant et sortant du service ou
département à informatiser. L’analyse de documents utilisés commence par l’énumération de
documents suivants :

1
MVIBUDULU-KALUYIT, Note de cours de Méthode d’analyse informatique, G3 info/jour ISC-Gombe, inédit
2011-2012

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 14
 - Documents reçus par le service en provenance d’autres services internes ou externes de
l’entreprise ;
- Documents établis et conserves par le service ; et
- Documents diffuses par le service.
Pour chacun de ces catégories de documents, on cherche à connaitre leur code, leur nature, leur
fréquence et leur volume.

- Analyse de moyens de traitement

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

• Les moyens matériels

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

A partir des informations des moyens de traitement, l’analyste peut lors de la recherche de solution
proposée le type des solutions appropriées pour les matériels futurs à utiliser pour traiter les
informations.

• Les moyens humains

L’analyse des moyens humains est nécessaire pour mieux comprendre les qualifications du personnel
travaillant au sein du service concerné par l’application.

- Diagnostic de l’existant

Le diagnostic de l’existant consiste à examiner les points forts et les points faibles de système existant.
Lors de diagnostic, on essaye de passer en revue toutes les étapes de l’analyse de l’existant en
commençant par l’analyse de la structure jusqu’à l’analyse de flux de l’information. Compte tenu du
fait que l’informatisation ne s’improvise pas, le diagnostic de l’existant permet de détecter les points
forts et les anomalies de système actuel afin de se décider sur l’opportunité ou l’inopportunité de
l’informatisation.
Le diagnostic de l’existant se termine par les deux sous sections ci-après :
- Proposition des solutions ; et
- Choix de la meilleure solution.
▪ Le dictionnaire des données
Le dictionnaire des données est un document qui permet de recenser, de classer et de trier toutes les
informations (les données) collectées lors des entretiens ou de l'étude des documents. Le dictionnaire
peut être plus ou moins élaboré selon le niveau de granularité souhaité. En voici un exemple :

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 15
 Figure 3: Dictionnaire de données

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

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 16
CHAPITRE TROISIEME : LA METHODE MERISE DEUXIEME GENERATION

III.1. MERISE : Méthode d’analyse

Le sigle MERISE veut dire Méthode d’Étude et de Réalisation Informatique par les Sous-Ensembles
ou pour les Systèmes d’Entreprise.
La méthode Merise est le résultat des travaux menés par René Colletti, Arnold Rochfeld et Hubert
Tardieu dans les années 1970 et qui s'inséraient dans le cadre d'une réflexion internationale, autour
notamment du modèle relationnel d'Edgar Frank Codd. Elle est devenue un projet opérationnel au
début des années 1980 à la demande du ministère de l'industrie, et a surtout été utilisée en France, par
les sociétés de services en ingénierie informatique(SSII) de ses membres fondateurs et principalement
pour les projets d'envergure, notamment des grandes administrations publiques ou privées.
La S.S.I.I. (Société de service d'ingénierie informatique) a développé la méthode merise. Mais, il y a
d’autres grandes familles développées qui sont moins connues. On cite ici AXIAL (IBM), RACINES,
MINOS, NIAM, BON (OO).

Chaque méthode possède un ensemble de documents. Les méthodes se diffèrent aussi par le
vocabulaire utilisé ainsi que le découpage des étapes en particulier.

Les buts d'une méthode d'analyse sont :

✓ Standardiser le mode de travail des analystes ;

✓ Standardiser les documents d'analyse et de représentation ;
✓ Assurer une meilleure fiabilité (rien oublier) ;
✓ Simplifier le problème de maintenance et de modification.
Chaque méthode possède quatre caractéristiques (composantes) essentielles :

✓ Modèle qui permet de simplifier le système d'information ainsi que son organisation ;
✓ La démarche qui permet à l'utilisateur d'employer cette méthode ;
✓ Le langage qui permet de décrire les images du système d’information ;
✓ Les outils : principalement les logiciels qui accompagnent cette méthode.

Le but de la méthode Merise est de recenser la totalité des informations dont l'organisme a besoin pour
assurer toute ou une partie de ses activités fondamentales. Le point fort de Merise réside dans le fait
qu'elle est une démarche par étapes et par niveaux.

La méthode Merise est une méthode d'analyse, de conception et de réalisation de systèmes

d'informations.
La méthode Merise, très analytique, distingue nettement les données et les traitements, même si les
interactions entre les deux sont profondes et s'enrichissent mutuellement.

La méthode MERISE s'appuie sur une approche systémique des systèmes d'information.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 17
La méthode MERISE/2 est une extension de la méthode MERISE permettant à gérer les objets
spécifiques, simplifier certains formalismes et visualiser certaines contraintes.
III.2. Les étapes de la démarche MERISE

Elle permet d'appréhender le système d'information comme un objet à construire. D'où la

nécessité d'une représentation mentale et abstraite de cet objet, dont le développement ainsi
que l'entretien devront être assurés.
1. Schéma Directeur
Dans cette étape on doit réaliser certaines tâches :
- Définition des domaines d’étude ;
- Planification du développement de chaque domaine ;
- Constitution d'équipes (équipe par domaine) ;
- Description de moyens en personnels, matériels, logiciels ;
- Description des priorités ;
- Estimation des coûts.

2. Étude préalable sur le domaine

On doit au niveau de cette étude réaliser les tâches suivantes :

- Description de l'existant : Sur la base de documents et renseignements d'interviews, une

description du système au travers le graphe des flux (modèle de communication) est
nécessaire.
- Analyse de l'existant : Modélisation conceptuel des données et les traitements (MCD et
MCT).
- Spécification des besoins : Cette phase englobe la critique de l'existant et la définition des
orientations de nouveau système.
- Modélisation organisationnelle des scénarios : A partir de nouvelles règles de gestion
sont créés les nouveaux modèles de traitements (MOT) et validation de MCD.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 18
 3. Étude détaillée

La mission de cette étape est :

- Élaboration du MLD ;
- Identification des taches logicielles (procédures) ;
- Adapter le MLD au SGBD envisagé.

4. Étude technique

Dans cette étape, on doit

• Créer les fichiers ou tables de données ;

• Concevoir des écrans et spécifier les actions sur la base de données ;
• Élaborer des algorithmes.

5. Réalisation

Au sein de cette étape, on va essayer de

• Programmer ;
• Faire des jeux d'essai.

6. Mise en œuvre

Dans cette étape, les tâches à réaliser sont :

• Installation des programmes et base de données ;

• Organiser les postes de travail et liaison entre les services ;
• Préparer le catalogue de l’application ;
• Former les utilisateurs.

III.3. Les trois axes de modélisation de MERISE 2

La méthode MERISE 2 propose une démarche globale basée sur trois axes de modélisation :
- Axe d’architecture ou fonctionnel : qui permet de décrire ce que fait le système (les
activités) ;
- Axe statique : qui permet de décrire ce qu’est le système (les données) ;
- Axe dynamique ou comportemental : qui permet de décrire comment se comporte le
système (le processus et la succession de transformations de transformation effectuées sur
les données).

Figure 4: Les trois axes de modélisation avec MERISE 2

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 19
III.4. La différence entre MERISE et MERISE 2.
- Au niveau conceptuel, les évolutions par rapport à MERISE sont :
o Modification des modèles conceptuels de traitement en modèles conceptuels de
traitement analytique (MCT--> MCTA) ;
o L’extension du MCD ;
o L’introduction des CVO
- Le formalisme introduit dans Merise 2 (MCTA) se distingue du formalisme classique de
Merise (MCT) par les points suivants :
o Il met en évidence l'interaction entre les données et les traitements (grâce au
CVO),
o Il s'appuie sur une définition rigoureuse des événements déclencheurs,
o Il permet de représenter le parallélisme de certains traitements,
o Il prend en compte le cas où à l'arrivée d'un événement le système ne se trouve pas
dans l'état qui permettrait à une opération de se déclencher,
o Il distingue les événements déclencheurs des opérations et les ressources (données
consultées) nécessaires à l'exécution de ces opérations.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 20
CHAPITRE QUATRIEME : CONCEPTION DU SYSTEMES D’INFORMATION
ORGANISATIONNEL

L'informatique consiste à mettre à disposition de l'utilisateur des moyens ou des outils de gestion
informatique. Avant de spécifier les moyens informatiques, il est nécessaire de définir le travail de cet
ou de ces utilisateurs finaux, de définir l'organisation du travail au sein de l'entreprise. Afin de
déterminer cette organisation, l'analyse des objectifs et des fonctions majeures de l'entreprise doit être
menée. Ainsi, l'informatisation est conçue en fonction de l'organisation et l'organisation en fonction
des objectifs à atteindre.
L'enchaînement de l'informatique, de l'organisation et de la fonction nécessite un découpage en
niveaux de la démarche d'informatisation. Ces niveaux sont nommés conceptuel pour l'étude des
fonctions et organisationnel pour l'étude de l'organisation.
Ce chapitre traite des raisonnements mis en œuvre par le concepteur pour l’élaboration des modèles
nécessaires à la compréhension et à la conception du système d’information organisationnel (SIO).
Il précise comment élaborer et exprimer les différents modèles de données et de traitements de niveau
conceptuel et organisationnel qui spécifient ce SIO.
Notons que dans ce chapitre, la présentation des différents modèles associés au SIO concerne
essentiellement la dimension du cycle d’abstraction de la méthode (les raisonnements).
Deux niveaux interviennent lors de la conception d’un SIO, il s’agit de :
- Niveau conceptuel ; et
- Niveau organisationnel.

IV.1. LE NIVEAU CONCEPTUEL

Le plus invariant, le niveau conceptuel, définit les fonctions réalisées dans l'organisme. Il répond à la
question QUE FAIT L'ORGANISME ? Il est déterminé par son activité. L'étape précédente,
l'interrogation du pourquoi de l'activité, cette remise en question de l'entreprise, n'est pas abordée par
Merise.
On peut encore dire que le niveau conceptuel traite des évènements et fournit des résultats sans se
soucier de la manière dont sont acquises et restituées des informations portées par ces évènements et
résultats.
La description conceptuelle du système permet de représenter sa raison d'être et sa finalité en
s'appuyant sur ses objectifs et les réalités qui le contraignent. Il s'agit dans un premier temps de décrire
les règles de gestion qui permettront l'élaboration des modèles conceptuels de données et de
traitements.
Une règle de gestion traduit un objectif prioritaire sans se soucier de la manière de le mettre en
œuvre.
Pour ce niveau, nous allons développer :

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 21
 - Diagramme de flux,
- Modèle conceptuel des données analytique (MCDA),
- Modèle conceptuel de traitement analytique (MCTA),
- Cycle de vie des objets (CVO),

IV.1.1. Les Modèles de Flux

Les diagrammes de flux répondent à la question : Que fait le système ?

En ce sens, ce sont des modèles FONCTIONNELS (qui décrivent les fonctions)

Il existe 2 types principaux de diagrammes de flux :

1) Le modèle de contexte (MC) où le domaine d’étude est vu comme une boite noire. On ne représente
que les flux extérieurs au domaine.

2) Le modèle de flux de données (DFD) ou encore modèle de flux conceptuels (MFC) où l’on détaille
les activités du domaine d’étude. On représente aussi les flux internes au domaine.

a. Vocabulaire associé aux modèles de flux

- Domaine d’étude

Le domaine d'étude est un sous-ensemble cohérent de l'entreprise ou de l'organisme, bien délimité et

formant le contenu du sujet à étudier.

Dans les modèles de flux, le domaine d'étude est représenté par un rectangle à trait plein. Le nom du
domaine est placé à l’intérieur du rectangle.

- Acteur externe

Un acteur externe est un élément émetteur ou récepteur de données, situé hors du système
d'information étudié.

Dans les modèles de flux, un acteur externe est représenté par un cercle plein. Le nom de l’acteur est
placé à l’intérieur du cercle.

- Domaine connexe

Un domaine connexe est un composant du système d’information interagissant avec le domaine

d’étude. C’est un acteur interne à l’entreprise, mais externe au domaine d’étude.

Dans le modèle de flux, un domaine connexe est représenté par un rectangle (ou un rond). Le nom du
domaine connexe est placé à l’intérieur du rectangle.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 22
 - Activité

L’activité est un ensemble de traitements homogènes qui transforment ou manipulent des données.
Une activité peut souvent être vue comme un sous-domaine d’étude, un morceau du domaine
d’étude.

Chaque activité peut être éclatée. Cet éclatement se traduit alors par l’élaboration d’un nouveau
diagramme qui décompose ce processus éclaté en plusieurs processus plus élémentaires.

Dans les modèles de flux, une activité est représentée graphiquement par un rectangle. Le nom de
l'activité est placé à l’intérieur du rectangle.

- Flux de données

Un flux est un transfert d’informations entre composants du système. Le composant peut être un
domaine, une activité ou un acteur externe.

Dans les modèles de flux, un flux de données est représenté graphiquement par une flèche orientée du
composant émetteur du flux vers le composant récepteur. Le libellé du flux est inscrit en regard de la
flèche tracée.

Formalisme graphique illustrant par exemple un échange entre un acteur externe et le domaine d'étude
:

c. Modèle de Contexte (MC)

Le modèle de contexte sert à représenter les interactions entre le domaine d'étude et
l’environnement, et entre le domaine d'étude et les éventuels domaines connexes. Le domaine
d'étude y est représenté comme une boîte noire. Le modèle de contexte utilise les concepts
suivants :
- Le domaine d'étude
- Les acteurs externes
- Les flux de données
- Les domaines connexes

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 23
Exemple de modèle de contexte : au sein d’une société commerciale, on étudie le domaine « gestion
des ventes ».

Remarque :
On ne fait pas apparaître les flux entre acteurs externes et domaines connexes, ou entre les domaines
connexes.
Exemple : le flux correspondant à la livraison de marchandises n’apparaît pas.

d. Modèle de flux Conceptuels (MFC)

Ce modèle permet de décider quelles activités, inter-reliées de quelle manière, permettront de résoudre
au mieux le problème posé, et cette réflexion est menée sans s'encombrer dans un premier temps du
comportement du système (ordonnancement, règles d'émission, synchronisations…).

Les modèles de flux conceptuels permettent de décomposer le domaine d’étude en activités. Il n’y a
pas ici de notion d’organisation mais d’objectifs à réaliser. On représente les flux entre activités et
avec l’environnement.

Pour analyser les communications et les activités, on procède par « zooms » successifs sur le domaine
étudié pour élaborer des modèles de plus en plus détaillés qui permettront d'avoir une cartographie
détaillée du système et de préparer le passage au modèle conceptuel de représentation des traitements.

Le modèle de contexte est également appelé le diagramme de flux de données de niveau 0. Nous
obtenons ensuite des diagrammes de premier, deuxième, troisième, … niveau, par éclatements
successifs des activités à chacun de ces niveaux.

La décomposition d’un domaine ou d’une activité en plusieurs activités peut faire apparaître de
nouveaux flux dus :

- À l’échange d’informations entre activités

- À la décomposition d’un flux présent au niveau n en plusieurs flux au niveau n+1.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 24
 Exemple : si on reprend le modèle de contexte précédent, on s’aperçoit que le domaine des ventes
peut être éclaté en trois activités. Nous obtenons ainsi le diagramme de flux de données de niveau
1:

GESTION DES VENTES

Remarque :

On peut décomposer le modèle de flux de niveau 1 en un modèle de flux de niveau 2 et etc jusqu’à
arriver à un modèle où l’activité correspond à une opération au sens Merise (règle d’ininterruption).
Exemple : l’activité « gestion des factures » peut être encore décomposée en activités « facturation » et
« Suivi des règlements ».

Règles de décomposition des activités

Pourquoi décomposer ?

- Pour désagréger les groupes de flux, pour arriver à la définition des flux-types du domaine
étudié
- Pour préparer l'étude dynamique du système d'information, pour arriver à l ’identification des
processus et des opérations conceptuelles

Comment décomposer ?

- Identifier les groupes de données entrant et sortant du domaine d’étude pour construire le
modèle de contexte
- Identifier les activités générant ou traitant les flux de données pour construire le DFD de
niveau 1 (approche par les données) ou identifier une activité de niveau 1 comme un ensemble
d ’activités participant à une même finalité (approche par les objectifs)

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 25
Jusqu'où décomposer ?

Lorsqu'une activité a atteint le niveau d'interruptabilité (dès lors que le traitement est déclenché, il se
déroule sans attente de ressources complémentaires extérieures). L'activité est alors une opération
conceptuelle qui sera décrite lors de l'étude dynamique du SI dans le MCTA.

IV.1.2. Modèles conceptuels des données analytiques

Dans les années 1990 un certain nombre d’éléments ont été ajoutés au MCD de la MERISE originale
afin de lui permettre de spécifier un certain nombre des choses qui n’étaient pas faisable avec la
première version de la méthode. Le résultat de ces ajouts est appelé modèle conceptuel de données
analytique (MCDA).

Le MCDA permet :

- De spécifier les différentes contraintes d’extensions.

- D’exprimer les contraintes ensemblistes (inter associations) qui ne sont pas exprimer sur le
MCD brut

Pour obtenir le MCDA, la règle est la suivante :

MCDA = MCD + Contraintes d’extensions + Sous-types.

a. Définition

Le modèle conceptuel des données est une représentation statique du système d’information de
l’entreprise. Au niveau conceptuel, il s’agit de modéliser les données fondamentales de l’entreprise
(les invariants décrits par les règles de gestion). Il ne doit être fait aucune hypothèse sur l’utilisation
ultérieure de ces données.

b. Vocabulaire
▪ Propriété
La propriété correspond à la plus petite partie logique d’information manipulée dans l’entreprise, il
peut s’agir d’une propriété simple comme une référence ou un nom, mais aussi d'une propriété
composée comme une date ou une adresse.
Il faut autant que possible :
o Éviter les propriétés calculables et redondantes,
o Faire la chasse aux synonymies (référence article et num de produit) et aux polysémies
(préciser s’il s’agit de l’adresse du client ou celle du fournisseur).
Les propriétés sont les informations de base du système d'information. Un client possède un numéro
de client, un nom, un prénom, habite à une adresse précise, etc. Ces informations élémentaires
essentielles sont des propriétés.
Les propriétés disposent d'un type. Elles peuvent être numériques, représenter une date, leur longueur
peut être aussi définie. Par exemple : le nom est une propriété de type alphabétique et de longueur 50,
c'est-à-dire que la valeur saisie ne comportera aucun chiffre et ne dépassera pas cinquante caractères.
Les types ne sont pas décrits au niveau conceptuel, car ce niveau est trop proche de la définition du

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 26
système physique. Nous y reviendrons plus tard.
▪ Objet type (ou individu)
L’objet est un regroupement de propriétés (ou attributs). Il est le reflet d’une entité de l’organisme
dotée d’une existence propre. Il est identifiable et ne doit représenter qu’un seul concept sémantique.
Chaque propriété d’un objet peut être assimilée à une variable. Les valeurs qui lui seront affectées
représentent les occurrences de cette propriété. Si l'on affecte une valeur à chacune des propriétés
composant un objet, on obtient une occurrence de celui-ci.

Figure 5: Objet, Occurrence d'objet

- L’identifiant (clé) : Une de ces propriétés à un rôle bien précis, c'est l'identifiant nommé aussi
la clé. L'identifiant permet de connaître de façon sûre et unique l'ensemble des propriétés qui
participent à l'entité. Par exemple, le fait de connaître la ville d'un client permet-il de connaître son
nom ? La réponse est non. La connaissance du nom du client permet-elle de connaître sa ville ? La
réponse est toujours non, car en cas d'homonymie la confusion entre OMARI LUKENDO de
l’ISC/Bukavu et OMARI LUKENDO de l’ISC/Uvira aussi est totale.
II faut donc trouver, ou inventer, une propriété qui lorsque sa valeur est connue permet la
connaissance de l'ensemble des valeurs qui s'y rattachent de façon formelle.
Ainsi, lorsque le numéro du l’assistant est connu, son nom, son prénom et toutes les valeurs des autres
propriétés qui s'y rattachent sont connues de façon sûre et unique.
Au niveau du formalisme, cette propriété se souligne ou on la précède de signe dièse #.

D’où, l'identifiant d'un objet est une propriété ou un ensemble de propriété qui permet de connaître
sans ambiguïté chacune de ses occurrences. Dans l’exemple ci-dessus, il s'agit de la propriété
Référence.

Relation

Représente une association entre plusieurs objets ; son existence est conditionnée par celles de objets
mis en relation (par exemple la relation "commander" entre client et commande).

La relation peut être vue comme une association entre divers objets du modèle. Elle est la traduction

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 27
des verbes du langage de l’entreprise. La relation COMMANDER entre COMMANDE et CLIENT
est la traduction de la phrase : "un client peut passer une ou des commandes". Cette association
permet en particulier de savoir à qui livrer ou facturer une commande.
Contrairement aux objets, une association n’a pas d’existence propre. Son existence est conditionnée
à celle des objets qui la composent.
L’ensemble des objets entrant dans la composition d’une relation est appelé collection de la relation,
celle-ci comportant au moins deux objets. La dimension de la relation est égale au nombre d'objets de
sa collection. Elle est dit n-aire (binaire, ternaire.) ou de dimension n (2, 3..).

On peut avoir :
- La relation réflexive,
-
Une relation peut ou non être porteuse de propriétés.

Identifiant : La relation possède un identifiant qui est la combinaison (concaténation, enchaînement)

des identifiants des objets mis en relation. L’identifiant d’une relation n’est pas mentionné sur les
schémas.

Figure 6: Identifiant de relation

Relation réflexive : Elle relie un objet à lui-même. Une occurrence de la relation associe une
occurrence de l'objet à une autre occurrence de ce même objet (exemple PARENTE).

Figure 7: Relation réflexive

▪ Cardinalités
Indiquent pour chaque couple objet-relation les nombres minimum et maximum de valeurs de la

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 28
relation pouvant exister pour chaque valeur d'objet.

Par exemple, dans la relation "commander » entre client et commande les cardinalités du couple
client-commander sont (0,n) si un client peut exister comme prospect, il peut ne pas avoir passer
de commandes, d'autre part un client peut avoir n commandes, les cardinalités du couple
commande-commander sont (1,1) une commande intervient dans une et une seule relation
car elle concerne un et un seul client.

Figure 8: Notions de base du MCD

Les cardinalités représentent pour chaque couple objet-relation les nombres minimum et maximum
d’occurrences de la relation pouvant exister pour une occurrence d’objet. Elles mesurent donc la
participation des occurrences d'objets aux relations.

• (0,1) : une occurrence d'objet peut exister sans pour autant participer à la relation (0) et ne
participe jamais plus d'une fois.
• (0,n) : c'est la cardinalité la plus ouverte; une occurrence d'objet peut exister sans pour autant
participer à la relation (0) et peut participer sans limitation.
• (1,1) : une occurrence d'objet participe une et une seule fois à la relation.
• (1,n) : une occurrence d'objet participe au moins une fois à la relation et peut participer sans
limitation.
Pour être complet, un modèle conceptuel doit comporter les cardinalités correspondantes à chaque
couple objet-relation. Les diagrammes d’occurrences mais surtout les règles de gestion aident à
déterminer les cardinalités. Elles sont des traductions de règles de gestion.

Figure 9: Cardinalité ?

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 29
 Figure 10: Diagramme d’occurrences

Du diagramme d'occurrences ci-dessus il ressort qu'un article peut être en stock dans plusieurs dépôts,
qu'un article peut ne pas être en stock et qu'à un moment donné un dépôt peut être vide.
Règles de gestion :
Un article peut exister sans être stocké.
Il peut être stocké dans plusieurs dépôts.
Un dépôt peut exister même s'il ne stocke rien.

Figure 11: Cardinalité

❖ Lecture de la cardinalité
Exemple d’un client qui commande un article
- Combien de fois au minimum un client peut-il commander un article ?
- Combien de fois au maximum un client peut-il commander un article ?
À la première question, nous pouvons répondre qu'un client, pour être client, doit commander au
moins un article.
À la deuxième question, nous pouvons répondre qu'un client peut commander plusieurs articles.
Voici comment symboliser cet état :

Figure 12: Lecture de cardinalité

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 30
Le n représente la notion de « plusieurs » ; ici nous avons représenté le fait qu'un client peut
commander un ou plusieurs articles.
II faut que nous nous posions les mêmes questions pour l'article :
- Combien de fois au minimum un article peut-il être commandé par un client ?
- Combien de fois au maximum un article peut-il être commandé par un client ?
Pour le minimum, nous pouvons l'interpréter de la façon suivante :
- A-t-on des articles qui ne peuvent jamais être commandés ?
- Si nous répondons oui dans ce cas la cardinalité minimale est 0.
Pour le maximum :
- A-t-on des articles qui peuvent être commandés plusieurs fois ?
- Nous pouvons espérer que oui, dans ce cas la cardinalité maximale sera n.
Voici le schéma finalisé :

Figure 13: Exemple complet de cardinalité

Contrainte d'Intégrité Fonctionnelle

Une Contrainte d'Intégrité Fonctionnelle (CIF) définie sur une relation représente le fait que l'un des
objets de sa collection est identifié sans aucun doute par la connaissance d’un ou plusieurs autres.
Une relation binaire ayant des cardinalités (0,1) ou (1,1) exprime une CIF. Une CIF exprime une règle
de gestion et est représentée par une flèche pointant sur l’objet déterminé.

Figure 14: Une contrainte d'intégrité fonctionnelle

Le schéma ci-dessus exprime les règles de gestion :

Un article ne peut exister sans être stocké.
Il ne peut être stocké qu'à un seul endroit.
Les CIF sont utilisées pour décomposer les relations. Elles permettent donc de simplifier des relations
de dimensions supérieures à 2.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 31
Exemple : dans une entreprise industrielle, les ordres de fabrication sont établis par le siège en
direction de divers sites de production. On suppose la règle de gestion suivante :
• un ordre de fabrication ne concerne qu'un seul site.

La connaissance de l’ordre de fabrication permet donc de déterminer le site correspondant (existence

d'une CIF de "ordre de fabrication" vers "site"). Cette contrainte d'intégrité permet de décomposer la
relation ternaire (Figure 27) en deux relations binaires (Figure 28).

Figure 15: Relation ternaire et CIF Figure 16:Décomposition de relation

IV.1.4. Sous-type d'objet et sous-type de relation

a. Sous-type d'objet
Un sous-type d’objet correspond à un sous-ensemble d’occurrences d’objet dotées de caractéristiques
propres (propriétés spécifiques et/ou relations spécifiques). On pourra aussi employer les termes
d’objet générique (sur-type) et objet spécialisé (sous-type).

▪ L'objet générique ou sur-type porte les caractéristiques communes aux objets spécialisés.

Figure 17: Sur-type/ Sous-type

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 32
 ▪ Chaque sous-type hérite des propriétés et des relations du sur-type.

Figure 18: Héritage et spécification

▪ Le mécanisme de spécialisation permet d’avoir plusieurs niveaux de description d'un même

objet : de la description la plus générale à la description la plus spécifique.

Figure 19: Hiérarchie d'héritage

▪ Cas particulier de spécialisation : la spécialisation par états

Un sous-type correspond dans ce cas à un état de l’objet. Il peut y avoir transfert d’une occurrence de
l’objet d’un sous-type à un autre sous-type, contrairement au cas précédent (Figure 36) qui correspond
à une spécialisation par « catégorie". Nous verrons que les CVO constituent une alternative à la
modélisation des états.

Figure 20: Spécialisation par états

b. Sous type de relation

Un sous-type de relation correspond à un sous-ensemble d'occurrences d'une relation dotées de

propriétés et/ou de cardinalités spécifiques.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 33
 Figure 21: Sous type de relation

IV.1.5. Les contraintes d'intégrité statiques

Une contrainte apporte des informations complémentaires sur les dépendances entre les propriétés ou
des objets.
Notons que pour ce qui concerne les retombées, les contraintes n’en ont aucune sur la structure de la
base de données mais elles sont prises en compte directement au niveau de la programmation ou soit
directement dans l’application (qui est une mauvaise idée) mais aussi soit directement dans la base de
données sous forme de triggers et procédures stockées.
Ces contraintes peuvent porter sur : Les contraintes de base, les sous-types d’objets et des relations.
▪ Les contraintes de base :
- Couverture
- Disjonction
▪ Des sous-types d'objets :
- Contrainte de partition (notée +)
- Contrainte d'exclusion (notée x)
- Contrainte de totalité (notée T)
▪ Des relations ou des pattes de relations :
- Contrainte de partition (+)
- Contrainte d'exclusion (x)
- Contrainte de totalité (T)
- Contrainte d'inclusion (I)
- Contrainte d'égalité (=)

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 34
 a. Contraintes de base : couverture et disjonction
- Contrainte de couverture : toute occurrence de l'objet générique doit appartenir à au moins un
des sous-types.

Figure 22: Couverture

- Contrainte de disjonction : toute occurrence de l'objet générique doit appartenir à un seul

sous-type (les sous-types sont mutuellement exclusifs).

Figure 23: Disjonction

b. Contraintes d'intégrité entre les sous-types d'objets

Figure 24: Contraintes d'intégrité entre les sous-types d’objet

- Contrainte de partition

Un auteur est soit invité, soit accepté, soit refusé.

Figure 25: Partition= Disjonction + couverture

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 35
 - Contrainte de totalité

Une personne physique peut être à la fois Particulier et Entrepreneur individuel, elle est l'un ou
l'autre.

Figure 26: Totalité= Couverture et non disjonction

- Contrainte d’exclusion

Un contrat ne peut être à la fois un contrat de crédit et un contrat d'épargne, il existe d'autres types
de contrats.

Figure 27: Disjonction et non couverture

c. Contraintes d’intégrité sur les relations

Ici aussi il s'agit de contraintes ensemblistes.

- Contrainte de partition (couverture et disjonction)

Une contrainte de partition permet d'exprimer que toutes les occurrences d'un objet (dit objet pivot)
impliqué dans deux (ou plus) relations sont présentes dans une et une seule d'entre elles (ou exclusif).
Toute personne est soit résidente en France soit résidente à l’étranger, mais ne peut être les deux.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 36
 Figure 28: Partition

- Contrainte d'exclusion (non couverture et disjonction)

Une contrainte d’exclusion interdit qu’une occurrence d’un objet (dit objet pivot) impliqué dans deux
(ou plus) relations soit présente dans deux d'entre elles.
On ne peut être salarié et étudiant, certaines personnes ne sont ni l'un ni l'autre.

Figure 29: Exclusion

- Contrainte de totalité (couverture et non disjonction)

Une contrainte de totalité permet d’exprimer que toutes les occurrences d’un objet (dit objet pivot)
impliqué dans deux (ou plus) relations sont présentes dans au moins l'une d'entre elles (ou inclusif).
Toute personne est étudiante dans un établissement, ou salarié dans une entreprise ou les deux à la
fois.

Figure 30: Totalité

Note : Pour les contraintes de partition, d’exclusion et de totalité, si aucun objet pivot n’est

mentionné la contrainte porte sur la collection de la relation.

On ne peut être salarié et étudiant du même établissement.

Figure 31: Plusieurs Objets Pivots

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 37
 - Contrainte d'inclusion
Cas 1 : pas d'objet pivot explicitement désigné
Une contrainte d’inclusion permet d’exprimer que l’ensemble des occurrences d’une relation est inclus
dans l'ensemble des occurrences d'une autre relation.
Le président du comité d’organisation d’une conférence est choisi parmi les membres du comité
d'organisation (de cette même conférence).

Figure 32: Inclusion sans objet pivot explicite

La relation président du CO est appelée "portée" de la contrainte d'inclusion,

La relation membre du CO est la "cible" de la contrainte d'inclusion.
Cas 2 : un objet pivot
Dans ce cas la contrainte d'inclusion porte sur l'ensemble des occurrences d'un objet (dit objet pivot).
L’ensemble des occurrences de l’objet pivot présentes dans une des relations est inclus dans
l'ensemble des occurrences de l'objet pivot présentes dans l'autre relation.
Si un employé est rattaché à un service il doit dépendre d'un site de l'entreprise (par contre il peut
dépendre d'un site sans être rattaché à un service).

Figure 33: Inclusion avec objet pivot

Portée de la CI : "rattaché", cible de la CI : "dépend", objet pivot : EMPLOYE

Note : dans le cas 1 le pivot est constitué des deux objets Personne et Conférence.

- Contrainte d'égalité

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 38
Une contrainte d'égalité est une combinaison de deux inclusions symétriques.
Tout employé rattaché à un service dépend de l'un des sites de l'entreprise. Inversement tout employé
dépendant d'un site doit être rattaché à un service.

Figure 34: Contrainte d’égalité

IV.1.6. Le modèle conceptuel de traitement et MCTA

- Modèle conceptuelle de traitement

a. Vocabulaire de base

La modélisation des aspects dynamiques repose sur le concept d’événements vus comme des
stimulateurs de l'activité. Il s’agit d’obtenir une représentation de l’enchaînement des opérations du
système et des conditions de déclenchement de son activité par des stimulations extérieures.
La dynamique du fonctionnement obéit à des règles issues d'un enrichissement des concepts des
réseaux de Pétri.
❖ Evènement

C’est la représentation d'un fait nouveau pour le système étudié ; ce fait est porteur d'information.
C’est par exemple l'arrivée d'une déclaration de sinistre dans une compagnie d'assurance. Cet
événement est porteur d'informations concernant l'assuré, le bien assuré et le sinistre affectant
celui-ci.
- Opération
C'est la réaction du système, sous forme de traitements, face à l'arrivée d'un événement ou d'un
ensemble événements. L'arrivée de l’événement "Déclaration de sinistre" déclenche l'opération
"vérifier la garantie".
- Résultat
C'est la représentation de la réponse du système, générée par une opération. L'opération "vérifier
la garantie" produit les résultats "sinistre pris en compte" ou "sinistre rejeté".
- synchronisation
C'est la représentation d'une pré-condition au déclenchement d'une opération. Elle peut faire intervenir
plusieurs événements. Le déclenchement de l’opération "rembourser assuré" est conditionné par la
présence des événements "rapport d'expertise" ET "facture de réparation".

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 39
 Figure 35: Concepts de base de MCT

b. Evènement

Un événement est une circonstance portée à la connaissance du système et à laquelle il doit réagir.
Pour qu'il y ait événement il faut que certaines conditions soient vérifiées :
- il doit se produire quelque chose (à l'extérieur ou à l'intérieur de l'organisation),
- ce fait doit être perçu par le système (qui devra donc se doter des moyens appropriés
de le percevoir)
- ce fait n'intéresse le système que dans la mesure où il est identifié comme un
déclencheur possible de son activité.
On distingue plusieurs types d’événements :
• Les événements que le système perçoit en provenance de l'extérieur et sur lesquels il n'a
aucune maîtrise : les événements externes ;
• Le résultat d'une opération peut participer en tant qu’événement au déclenchement de
l'opération suivante. On parle d’événement interne. Ce type d’événement ne peut déclencher
l'opération suivante que s'il est combiné avec au moins un autre événement. Si ce n'est pas le
cas, l’événement ne doit pas apparaître dans le modèle conceptuel, il s'agit la plupart du temps
d'un résultat intermédiaire de l'opération.
• Un résultat ne participant pas à la poursuite de l'activité du système et destiné à être émis vers
l'extérieur : on parle alors d’événements résultats ou simplement de résultats.
c. Synchronisation

Il est fréquent de rencontrer des opérations dont le déclenchement est conditionné par plusieurs
événements. Il faut alors représenter les conditions d'entrée, c'est à dire préciser quelles sont
les associations d’événements dont la présence est indispensable au déclenchement de
l'opération.
Cette représentation se fait par la synchronisation.
La synchronisation est à la fois une association d’événements "candidats" et une expression

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 40
booléenne formée à partir des opérateurs ET et OU.
Pour faciliter la lecture il est recommandé d'attacher à chacun des événements concernés un label plus
facile à manipuler que le nom de l’événement et qui représente une occurrence de l’événement.

Figure 36: Synchronisation

d. Opération

L’arrivée d'un événement déclenche un ensemble de traitements appelé opération.

Une opération ne peut être déclenchée que par l'arrivée de l’événement ou de l'ensemble
d’événements qui lui est rattaché. Cet ensemble d’événements peut être considéré comme les
ressources nécessaires au bon déroulement de l'opération.
Une opération est une séquence continue d'actions et qui doit s'exécuter sans interruption
(principe de non interruptibilité) dès qu'elle est déclenchée. Une opération constitue donc un
bloc de traitement, qui ne doit pas souffrir d'aucune interruption durant son exécution (pas
d'attente d’événement externe). L'exécution d'une opération produit l'émission d’événements
internes (poursuite de l'activité) et/ou de résultats (signaux vers l'extérieur).
Une même opération peut produire plusieurs résultats. Nous avons vu qu'il est possible de
représenter les conditions de déclenchement d'une opération. De la même manière, la production de
résultats peut être soumise à des conditions de sortie de l'opération appelées règles d'émission.
Une opération est donc décrite par :
- sa désignation (un libellé + éventuellement un code),
- les actions élémentaires descriptives des travaux à accomplir; ces actions sont essentiellement
des actions sur les données (consultation, mise à jour).
- les événements émis (événement internes ou résultats) et les conditions de ces émissions.
L'opération "vérifier garantie" déclenchée à l'arrivée de l’événement "déclaration de sinistre" génère
les résultats : "sinistre rejetée" et "lettre de rejet" ou "sinistre accepté" et "dossier ouvert".

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 41
 Figure 37: Opération

Différents graphiques :

e. Processus

Le processus est un enchaînement synchronisé d'opérations qui représente une unité de

préoccupation de l'entreprise. Il est propre à un domaine d'activité.

Figure 38: Le processus

Exemple de processus :

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 42
 Figure 39: Exemple de processus

Pour décrire un domaine on peut être amené à définir plusieurs processus. Si le domaine est vaste, on
le découpe en plusieurs sous-domaines chacun décrit par un processus.
Exemple : commercialisation des produits d'une entreprise.
La gestion des ventes reçoit des commandes puis transmet le double des bons de commandes à la
facturation et les bons de livraisons à la gestion des livraison. La facturation établit des
factures, reçoit les règlements et expédie des reçus. La gestion des livraisons livrent les articles aux
clients. Nous pouvons établir le diagramme de flux de niveau 1 suivant. Les sous-domaines à
distinguer sont les activités vente, facturation et livraison. Chacun de ces sous-domaines est
couvert par un processus distinct. Les opérations conceptuelles sont définies à chaque point
d'arrivée des événements externes au processus décrit : "commande", "commande validée",
"règlement", "bon de livraison".

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 43
L'ensemble des événements, opérations et résultats décrivant un processus constitue le modèle
conceptuel de traitements de ce processus.

Figure 40:MCT du Processus facturation

On rappelle qu'une opération est interruptible. En particulier, elle ne peut pas s'interrompre dans
l'attente d'un événement externe (ou d'une combinaison d’événements interne). Si tel est le cas il
convient de décrire une seconde opération s'appuyant sur cet événement en attente.

Considérons par exemple le processus de facturation. Les résultats attendus sont d'une part une
facture, d'autre part un reçu après règlement du client. La facturation ne nécessite pas le
paiement, mais l'émission du reçu ne peut s'effectuer qu'après celui-ci. Il y a donc présence de
deux opérations : l'une générant la facture, l'autre le reçu.

Remarque : facture est à la fois un événement résultat (transmis à l'extérieur) et un événement interne
participant au déclenchement de l'opération suivant. Cette double flèche traduit la règle de gestion
imposant la facturation préalable à l'encaissement.
f. La consommation
Un événement peut être candidat au déclenchement de plusieurs opérations sachant qu'une
occurrence de cet événement ne peut prendre part qu'à une seule de ces opérations.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 44
 Figure 41: Evènement consommable

Exemple : lorsqu'un client désire assurer un bien, il demande à la compagnie de lui faire une
proposition. Une fois élaborée, cette proposition est soumise au client et reste valable durant un certain
temps au bout duquel faute de réponse du client elle est annulée.
Cette représentation n'est acceptable que si les deux situations ne peuvent avoir lieu
simultanément. Dans l’exemple précédent le client ne peut pas simultanément donner son accord et ne
pas donner suite à la proposition.

- Le modèle conceptuel de traitement analytique (MCTA)

Le MCTA représente les actions indépendamment de leur organisation et de la technique

employée. Il permet de décrire les opérations constituant un processus et de montrer, pour
chacune d'elles, les interactions entre les traitements et les données.

La tendance actuelle consiste à développer le couplage traitements-objets, notamment par

l'introduction des Cycles de Vie des Objets. Les CVO permettent en effet de rendre compte des
changements d’états des principaux objets des modèles de données, au cours de la vie des processus.
Ces modifications d’états portées sur le MCTA complètent les opérations conceptuelles.
Nous commencerons par compléter la définition des opérations conceptuelles puis
Introduirons la notion d’état d’objet, notion qui sera reprise et approfondie lorsque nous présenterons
les CVO.
a. Opération conceptuelle
L'opération conceptuelle est :
Déclenchée par un ou plusieurs événements,

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 45
 Met en œuvre un ensemble de règles conceptuelles formalisées,
Consulte et met à jour des entités de la mémoire permanente par l’intermédiaire
d'actions,
Laisse les données du SI dans un état cohérent par rapport aux contraintes d'intégrité
de la mémoire permanente,
Ne peut être interrompue par l'attente d'un événement externe ou temporel.
Représentation graphique :

Figure 42: Représentation graphique des opérations dans le MCTA

Exemple intuitif : Nous sommes dans le cadre d’une formation permanente. Une demande
d'inscription à un stage déclenche l’opération “ enregistrer candidature ”. Cette opération :
s'assure que le stage existe,
crée une occurrence de l'entité stagiaire dans l'état candidat.

Figure 43: Opération: Enregistrer candidature

b. Etat d’objet

Un état d'objet est un stade transitoire par lequel passe un objet (une entité de la mémoire

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 46
permanente) au cours de son cycle de vie.
Exemple :
"à livrer", "en attente", "livrée", "facturée" : états de COMMANDE
"créé", "complet", "ouvert", "en cours" : états de STAGE
"candidat", "recalé", "reçu", "inscrit", "en attente", "en formation" : états de STAGIAIRE
Les états des objets sont représentés dans le MCTA pour montrer l'évolution des objets durant
l'exécution des opérations conceptuelles.

Représentation graphique dans le MCTA

Figure 44: Etats des objets avant et après l'exécution de l'opération

Les différents cas possibles :

Figure 45: Evolution des états d'objet

Dans le cas d'une consultation on peut :

soit ne pas représenter l'état de l'objet, si l'état n'a pas d'importance ;
soit représenter l'état de l'objet, c'est le cas d'une consultation qui s'assure qu'un objet est bien
dans un état donné.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 47
 c. Actions
Une action est une manipulation des données d'un objet ou d'une relation du SI. Elle peut créer /
consulter / modifier / supprimer une et une seule occurrence d'entité (objet ou relation) de la
mémoire permanente. Dans les MCT les actions s'expriment en langue naturelle à l'intérieur des
opérations. Dans le MCTA les actions agissant sur les états d'objets sont représentées
graphiquement.

Figure 46: Action des opérations dans le MCTA

L'ordre des actions d'une opération conceptuelle sera, dans la mesure du possible, présenté de haut en
bas. L'opération conceptuelle ENREGISTRER CANDIDATURE est composée de deux actions : une
consultation permettant de vérifier que le stage est créé, une création d'un stagiaire dans un état
candidat.

Figure 47: Actions du MCT au MCTA

Une action de consultation peut exprimer une condition de déclenchement sur une mise à jour.
C'est le cas ici où l'on souhaiterait exprimer que le stagiaire est créé (état candidat) si le stage existe
(état créé). Dans ce cas il s'agit d'exprimer explicitement une condition de déclenchement sur une

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 48
opération de mise à jour (Figure ci-dessous).
Une action peut donc être accompagnée d'une condition de déclenchement qui peut ou non être
itérative.

d. Conditions sur les actions

Condition de Déclenchement
Le déclenchement d'une action peut être soumis à une condition, c'est à dire à une règle qui porte sur
l'état de la structure de données au moment où l’événement est constaté.

Figure 48: Condition de déclenchement

La condition de déclenchement C permet le respect des contraintes d'intégrité statiques

exprimées dans le modèle de données.

Dans l'exemple ci-dessous un exemplaire est soit prêté, soit réservé (il ne peut être les deux). S'il n'est
ni l'un ni l'autre il est disponible. Un abonné peut emprunter un livre (il devient actif) ou établir une
réservation (il est en attente). Un abonné inactif n'a ni prêt, ni réservation en cours.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 49
 Figure 49: Condition de déclenchement et respect de CI

Condition itérative

Le déclenchement itératif d’une action peut être contrôlé par une règle qui définit les paramètres de
l'itération. Dans le schéma ci-dessous le N signifie que l'opération intervient sur toutes les occurrences
de l’objet concerné respectant la condition de déclenchement. On parle d'action collective.

Figure 50: Condition itérative

Evènement interne

Un événement interne correspond à un changement d'état particulier d'objet. Provoqué par une
opération, il participe à son tour au déclenchement de l'exécution d'une opération. L’événement
interne mis en évidence au niveau du MCTA se situe entre deux états cohérents du système. Par
exemple dans le MCTA ci-dessous on exprime qu'une commande peut être créée sans être facturée.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 50
 Figure 51: Evènement interne déclencheur

Les ressources informationnelles nécessaires à l’exécution d’une opération, mais non

Déclenchantes, sont représentées par des actions de consultation et non plus par des événements
internes comme dans le MCT (Figure suivante).

Figure 52: Evènement interne non déclencheur

Remarquons que dans l’exemple précédent (Figure 75) l’événement interne « bon de commande
accepté » n’est pas remplacé par une opération de consultation. En effet, l'opération Facturer est
déclenchée si un membre du personnel est disponible ET au moins un bon de commande a été accepté.

IV.1.7. Les Cycles de vie des objets

a. Introduction
Une entité décrite dans le modèle de données n'est pas figée à tout jamais. Elle passe durant sa vie par
différents états qui peuvent être constatés à partir des diverses valeurs prises par :
Ses propriétés,
Ou celles des objets qui lui sont liés,
Ou encore par sa participation (ou sa non-participation) dans les relations où elle intervient.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 51
Cette succession d'états est représentée par un graphe orienté dont les sommets sont de deux types:
les divers états de l'objet,
les événements provoquant le passage d'un état à un autre.

Evénement et Transition
La définition de l’événement reste identique. Un événement peut être externe, interne, temporel.
Dans le CVO les événements déclenchent la transition d'un état à l'autre.
Un événement peut déclencher plusieurs transitions.
Un événement interne est généré par au moins une transition d'états d'objet.
Une transition correspond au passage d'un objet d'un état dans un autre. Elle est représentée
par un double arc orienté, reliant deux états par l'intermédiaire d'un événement.
Représentation graphique et exemple partiel

Figure 53: Etat, évènement et transition dans le CVO

Objectif
o Donner une vision synthétique du cycle de vie des principaux objets,
o compléter le MCD en mettant en évidence des contraintes d'intégrité statiques entre les
états d'objet et les propriétés spécifiques aux états,
o mettre en évidence des contraintes d'intégrité dynamiques sur les enchaînements d’états,
o faciliter la construction du MCTA.
Commentaires MCTA / CVO
Les deux modèles représentent les aspects dynamiques du SI, cependant :
o les CVO modélisent le cycle de vie de chaque objet du système alors que le MCTA modélise
le cycle de vie du système.
o le CVO est construit autour de l'objet et décrit l'ensemble des événements affectant l'objet au
cours de son cycle de vie. Le MCTA est construit autour des opérations et donne une vision
globale des conséquences d'un même événement
o le MCTA donne une vision synthétique de la coordination des événements, le CVO donne une

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 52
 vision synthétique de la coordination entre états.

b. Les principales transitions

Les trois schémas de base qui peuvent être représentés sur un CVO sont la séquence,
l'alternative et l'itération.

Séquence

Alternative

Itération

En général les cycles de vie des objets sont interconnectés. Lors de la représentation du CVO d'un
objet (dit objet principal) on pourra représenter par une flèche pointillée les transitions d'états
sur les objets qui lui sont liés.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 53
 Figure 54: CVO interconnectés

c. Etats d’objet

Nous reprenons la définition introduite précédemment :

Un état d'objet est un stade transitoire par lequel passe un objet (une entité de la
mémoire permanente) au cours de son cycle de vie.
Le CVO d'un objet comporte :
o un ou plusieurs états initiaux,
o un ou plusieurs états intermédiaires,
o un ou plusieurs états finaux.
Les états d'un objet sont identifiés à partir :
o de la valeur de propriétés de l'objet
Un article est mis dans l'état "stocké" si la propriété "quantité en stock" est supérieure à 0.

o de la valeur des propriétés des objets qui lui sont liés

Une commande est dans l'état "bloquée" si la quantité en stock d'un article commandé est
inférieure à la quantité commandée.
o de la valeur des états des objets qui lui sont reliés
Un stagiaire est dans l'état "liste d'attente" si le stage auquel il est candidat est dans l'état

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 54
"complet".

o de ses relations ou absence de relations avec d'autres objets

Une commande est dite "en attente" si elle n’intervient pas dans la relation "livrer".

o de la valeur des propriétés de ses relations avec d'autres objets

Un produit est dit "en rupture de stock" dans un dépôt si sa quantité en stock est inférieure à un seuil
critique.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 55
A chaque état d'objet ou configuration d'états il est donc important d'associer des contraintes
d'intégrités qui correspondent à des états cohérents de la structure de données. Ces contraintes
d'intégrités seront exprimées avec le CVO des objets.
Etats d'objets et sous-types
C'est généralement le caractère transitoire de l'état d'objet qui le différencie d'un sous-type.
Exemple : HOMME et FEMME sont des sous-types de PERSONNE
"Célibataire", "veuf", "divorcé"... sont des états de l'objet PERSONNE.
Dans un MCD il est préférable d'utiliser la spécialisation par "catégorie" c'est à dire qu'il n'y a pas de
transfert d'une occurrence d'un sous-type à un autre.
Il n'est cependant pas interdit de faire de la spécialisation par "état" c'est à dire de permettre des
transferts d'occurrence.
d. Spécialisation de CVO
On peut représenter le CVO d'un objet à différents niveaux de détail. C'est ainsi que dans un premier
temps nous identifierons l'état "en vente" d'un article ce qui correspond à un état "standard"
pendant un processus de vente. Cet état peut ensuite être décomposé pour mettre en évidence des
états particuliers par lequel passe cet objet durant le même processus. C'est ainsi que nous
pourrons identifier l'état "en vente normale" et "en vente soldée".

Figure 55: Spécialisation d'états

e. Variables d'état et Structures parallèles

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 56
Un objet peut, à un certain moment de sa vie, être dans plusieurs états. Un logement peut être "libre"
ou "occupé" tout en étant par ailleurs "en vente", "vendu", "en location" ou "loué". Il peut donc être
intéressant de gérer plusieurs variables d'état pour un objet. L'objet admet différents états
caractérisés par la valeur de ses différentes variables.
La vie d'une variable d'état peut dépendre partiellement ou totalement de la vie d'une ou
plusieurs autres variables d'état de ce même objet. On a alors des structures parallèles dans le
CVO.
Exemple : Pour l'objet PERSONNE on s'intéresse à deux variables d'états
V1 correspond à l'état matrimonial,
V2 correspond à l'état civil.
L’événement "naissance" met la personne dans l'état "célibataire" (/V1) et "mineur (/V2). Nous
sommes dans le cas où un même événement fait passer l'objet dans deux états

Il est possible au niveau du MCTA de faire apparaître le fait qu'une même opération déclenchée
par le même événement modifie plusieurs variables d'état d'un objet.

Les différents cas de structures parallèle

1er cas : un événement commun aux deux variables

C'est le cas vu précédemment ; à l'arrivée d'un événement E2 (naissance) l'objet (personne) passe dans
l'état 2 et 3 (célibataire et mineur).

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 57
2ème cas : dans le CVO d'une variable, consultation de l'état d'une autre variable.
A l'arrivée de E3 (mariage), l'objet (personne) ne passe dans l'état 5 (marié) que si C1 est
vérifiée (si personne est "majeur").

3ème cas : Une transition dans le cycle de vie d'une variable constitue un événement interne qui
déclenche une transition sur le cycle de vie d'une autre variable.
Autrement dit la transition état1-état2 constitue un événement interne qui fait passer l'objet A dans un
état 3. Intuitivement, le passage de l'état "mineur" à "majeur" vis à vis de la variable "état
civil", provoque le passage à l'état "électeur" de la variable "état administratif".
f. Vérification et élaboration de CVO
Règles de vérification
Les règles suivantes sont destinées à vérifier qu'aucun événement ou état n'a été oublié dans un CVO.
Elles contribuent également à valider le MCTA en vérifiant sa complétude.
❖ Pour chaque objet on doit avoir :
un événement déclenchant sa création dans un état initial,
un événement pour chaque transition possible d'état,
un événement qui déclenche sa transition vers un état final ou sa suppression.
Note : la création pourra être représentée par une transition sans état initial, la suppression par une
transition sans état final
Chaque événement doit affecter au moins un objet.
Chaque objet doit être affecté par au moins un événement.
Enchaînement des modèles (cf. page suivante)
La construction des CVO s'appuient sur le MCTA et sur le MCD. Ce processus est itératif et les CVO
permettent à leur tour d'enrichir et de valider le MCTA et le MCD.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 58
Si le système à modéliser comporte de nombreuses règles dynamiques, il est conseillé de
commencer par les CVO.
Démarche pratique
1. Choisir un objet au cycle de vie complexe,
2. Commencer par décrire le cycle de vie "standard" de l'objet,
3. Compléter le CVO par les événements et états facultatifs qui ne font pas partie du cycle de vie
standard,
4. Définir précisément chaque état en indiquant les contraintes d'intégrité qui le caractérisent,
5. Connecter le graphe aux autres CVO,
6. Construire éventuellement des CVO spécialisés.

Une planche d'illustration : MCD, MCTA, CVO

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 59
 CVO partiels des objets (ne tient compte que de l’évènement demande d’objet)

Abonné inactif = pas de prêt ni de réservation, Exemplaire prêté = existe prêt

Abonné actif = existe prêt, Exemplaire réservé = existe réservation
Abonné en attente = existe réservation, Exemplaire disponible = pas de prêt ni de réservation

Attention : l’analyste n’a aucune initiative sur les règles de gestion, son unique rôle est de le trouver
(interview), les faires valider puis les utiliser pour élaborer les différents modèles conceptuels.

IV.2. LE NIVEAU ORGANISATIONNEL

La description organisationnelle du système représente l’organisation permettant d’atteindre les
objectifs définis au niveau conceptuel. Il s'agit donc de décrire le fonctionnement du SI dans le cadre
d'une organisation cible. Les descriptions du niveau organisationnel pour les traitements et les données
ne préfigurent pas des moyens à mettre en œuvre pour y parvenir.

La description organisationnelle permet de décrire les vues partielles du système pour chaque type
d'acteur par site de l'organisation. Il s'agit de décrire D'OU sont visibles les données et les traitements,
QUI fait quoi en matière de données et de traitement, QUAND réalise-t-on les traitements et
manipule-t-on les données.
Les choix d'organisation sont pris en compte à ce niveau, à savoir :
La répartition des traitements entre l'homme et la machine,
Le mode de fonctionnement : temps réel ou temps différé,
L’affectation des données et des traitements par type de site organisationnel et par type de
poste de travail.

Exemple intuitif :
Règles d'organisation : le système alterne les flots de circulation, en autorisant un passage en
séquence dans une durée limitée des véhicules des différents axes.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 60
IV.2.1. Modèle Organisationnel des Traitements (MOT) et MOTA
MOT = MCT + lieu + moment + nature
- Modèle organisationnel de traitement

La construction du modèle organisationnel de traitements se concentre sur le comment et va consister à

:
Définir les différentes ressources à mettre en œuvre (ce terme ressource est très général et
concerne aussi bien des moyens techniques ou humains, de l’espace, du temps et des données).
Décomposer les opérations spécifiées au niveau conceptuel en des éléments plus fins et
homogènes : les tâches.
Construire un enchaînement chronologique des activités.
Organiser l’ensemble des ressources permettant d’assurer l’exécution des tâches envisagées.
En résumé, il s’agit de spécifier avec plus de détails le contenu de chaque opération conceptuelle dont
l’expression des tâches était jusqu’ici très sommaire et de construire une ou plusieurs solutions
d’organisation.
A la différence des modèles conceptuels (données ou traitements), l’élaboration d’un modèle
organisationnel ne présente pas de difficulté théorique, liée à l’effort d’abstraction. Par contre
l’extrême diversité des solutions d’organisation envisageables ou le niveau de détail nécessaire rendent
cette phase parfois délicate.
Une solution d’organisation doit préciser au minimum :
l’organisation prévue pour les utilisateurs, avec les différents postes de travail et/ou services;
la circulation des informations entre ces centres d’activités;
dans les postes de travail, les différentes tâches à réaliser et selon quelle chronologie.
La construction des variantes du MOT pose ainsi tout le problème du changement dans l’entreprise.
Ce n’est pas un problème purement technique; il est donc important, en respectant les choix de
l’entreprise, de favoriser une approche ouverte de ce changement, approche sociotechnique et
participative.
Le MOT se préoccupe d’une vision externe des moyens que l’entreprise va mettre en œuvre pour
informatiser son système d’information. On s’intéressera à la répartition et à l’organisation des tâches
entre l’homme et l’informatique, à la disponibilité des données. En résumé, le gestionnaire se pose la
question :
Comment vais-je informatiser et organiser les activités de mon domaine ?

Formalisme de modélisation des traitements au niveau organisationnel

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 61
Malgré son importance en matière de conception de système d'information organisationnel, le MOT ne
nécessite pas de formalisme spécifique; il reprend très largement les concepts du MCT, parfois
réadaptés et enrichis, auxquels sont ajoutés de nouveaux concepts, dont celui de poste de travail.
a. Le poste de travail
Le poste de travail type, ou poste type, constitue l’une des principales dimensions du modèle
organisationnel. Un poste type est un centre d’activité élémentaire du domaine comprenant tout ce qui
est nécessaire à l’exécution de traitements. Il s’agit ici de déterminer les poste où se fera où
s’exécutera le travail. Un poste de travail deviendra un site de travail à l’étape informatique.
b. Moment
Quand exécuté-t-on l’opération ? Ici on définit le déroulement des taches ainsi que la périodicité donc
exécution peut être soit quotidienne hebdomadaire, mensuel.
Agencement temporel.
c. Nature
Manuelle : si c’est l’homme qui exécute l’opération ;
Automatique : si c’est la machine qui exécute l’opération ;
Interactive : si c’est l’homme et la machine qui exécutent l’opération.

Figure 56: Le MOT

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 62
 - Modèle Organisationnel des Traitements Analytique (MOTA)

Objectifs du MOT :

Etudier et décrire le fonctionnement du système d'information.

Répartir l'utilisation des données et des traitements par type de site et type d'acteur.
Représenter la mise en œuvre organisationnelle des activités.
Avant si les acteurs étaient sur des sites différents, il n'y avait pas de différences ; maintenant,
on parle de l'acteur sur son poste de travail, donc on peut faire apparaître des différences.
Tandis que l’objectif du MOTA est de :
Localiser et valider les traitements par site.
Rapprocher les données et les traitements.
Définir la nature du traitement.

Différences entre MOT et MOTA

Le MOT :
Des procédures fonctionnelles vers les actions élémentaires.
Son but : l’organisation du poste de travail.
Le MOTA :
Des opérations organisationnelles vers les fonctions.
Son but : la réutilisation des composants.
La démarche de construction du MOTA :
Choisir une opération conceptuelle.
Expliciter les événements déclencheurs.
Identifier les opérations organisationnelles en respectant les règles.
Analyser les actions sur les données.
Décomposer en fonctions (C’est le composant élémentaire de l'opération, C'est un
module de traitements réutilisable, Elle est décrite dans le même formalisme que
l'opération, Elle est construite par décomposition de l'opération, Elle sert de validation
avec le MOD (et le CVO organisationnel), chaque transition du CVO doit trouver une
fonction qui l'assure) élémentaires.
Pour chaque fonction :
o identifier les flux de données entrant/sortant
o expliciter le couplage avec le CVO/MOD

IV.2.3. Modèle Organisationnel des Données (MOD)

Comme nous l’avons vu précédemment, la modélisation conceptuelle des données visait à représenter
la signification des informations utilisées dans un domaine d’activité de l’entreprise sans tenir compte
de contraintes organisationnelles, économiques ou techniques. Elle exprimait des objets concrets ou

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 63
abstraits, des associations entre ces objets et des informations descriptives, formalisées en termes
d’entités, de relations et de propriétés.
La modélisation organisationnelle des données va permettre de prendre en compte des éléments
relevant de l’utilisation des ressources de mémorisation :
Le choix des informations à mémoriser informatiquement.
La quantification (ou volume) et la durée de vie des informations à mémoriser.
La répartition des données informatisées entre unités organisationnelles.
L'accès aux données informatisées pour chaque unité organisationnelle
Le modèle organisationnel de données apparaît donc comme une représentation, exprimée avec le
formalisme entité - relation, des informations qui seront mémorisées informatiquement compte tenu
des volumes, de la répartition et de l'accessibilité, sans encore tenir compte des conditions de
structuration, de stockage et de performance liées à la technologie de mémorisation informatique qui
sera utilisée.
❖ Choix de données à mémoriser
Il s’agit de choisir, à partir des informations formalisées sur le MCD, celles qui devront être
effectivement mémorisées informatiquement dans le système d’information informatisé (SII) (ou
données informatisées). Notons que les autres informations seront mémorisées « manuellement »
(support papier ou autre non informatique) mais feront toujours partie des informations constituant la
mémoire du système d’information organisationnel (SIO).
Le modèle organisationnel des données ainsi obtenu est de niveau global; il ne prend pas en compte
les choix d'utilisations réparties. Ce MOD dérive directement du MCD auquel on peut être conduit à :
Supprimer des éléments (entités, relations, propriétés) qui ne seront pas mémorisés
informatiquement.
Modifier certains éléments (entités, relations, propriétés, cardinalités...) compte tenu du choix
de mémorisation informatisé.
Ajouter de nouvelles informations " pour permettre de faire le lien entre les données
mémorisées et les données restées manuelles; par exemple la référence de fiches, de dossiers,
d’un ensemble de mesures réalisées, de plans... " pour mémoriser des états du système
d’information consécutifs au déroulement des traitements dans le MOT.
Quantification des cardinalités
Le nombre d'occurrences des entités est généralement assez aisé à estimer; celui des relations est
beaucoup plus difficile, compte tenu de la nature même des relations: des associations entre objets.
Dans la plupart des cas, ce dénombrement s'effectuera à partir du nombre d'occurrences d'une entité de
sa collection et de la quantification de la cardinalité de la « patte ».
Dans le modèle conceptuel de données, les cardinalités maximales multiples sont spécifiées jusqu’à
présent par n. Il faut, au niveau du MOD, évaluer cette multiplicité. Prenons par exemple la
modélisation de la figure suivante :

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 64
La valeur de la cardinalité maximale n de Facture par rapport à ligne doit être précisée. La valorisation
des cardinalités peut s’exprimer par :
- la cardinalité maximale,
- la cardinalité maximale à 95 %,
- la cardinalité modale,
- la cardinalité moyenne.
Le choix de telle ou telle valeur se fera selon l’intérêt dans le processus d’optimisation; dans tous les
cas, au niveau du MOD, on définira la cardinalité moyenne, en particulier pour calculer le nombre
d'occurrences des relations.
La quantification de la cardinalité mini s'exprime par le taux de participation. En effet, au niveau
conceptuel, la cardinalité mini peut prendre les valeurs 0 (optionnelle) ou 1 (obligatoire). Le taux de
participation ne se détermine que pour les cardinalités mini à 0 et mesure le pourcentage d'occurrences
de l'entité qui participent aux occurrences de la relation. Il prend donc une valeur décimale comprise
entre { ] 0, 1 [ .}
La quantification de la cardinalité moyenne n’est pas toujours facile. Soit on fixe arbitrairement cette
cardinalité, soit à partir de statistiques sur les populations d’entités concernées par la relation, il est
possible de la déterminer de façon plus précise. Par exemple, pour l’exemple précédent, on pourrait
avoir la distribution des lignes de facture par facture illustré par la figure suivante :

Pour notre exemple, on peut supposer que la loi de répartition des cardinalités est approximativement
triangulaire, comme le montre la figure :

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 65
Etant donné une telle répartition triangulaire, on peut calculer la cardinalité moyenne par la formule
suivante :
Etant donné une telle répartition triangulaire, on peut calculer la cardinalité moyenne par la formule
suivante :
Cardinalité moyenne = [(m + 2M + N) / 4] x P
P= 𝐸𝑓𝑓𝑒𝑐𝑡𝑖𝑓 𝑃𝑟é𝑠𝑒𝑛𝑡 /𝐸𝑓𝑓𝑒𝑐𝑡𝑖𝑓 𝑇𝑜𝑡𝑎𝑙
Avec :
m = valeur mini (0 exclu)
M = valeur modale
N = valeur maxi
P = taux de participation
Par exemple, si M = 3; N = 17; m = 1; P = 1; on a :
Cardinalité moyenne = ((1 + 2 x 3 + 17) / 4) x 1 = 6
Notons que la cardinalité moyenne d’une cardinalité (1,1) est toujours 1 et que la cardinalité moyenne
d’une cardinalité (0,1) est égale au taux de participation.
Dans le cas de plusieurs populations, on recherche la moyenne de chaque population, puis on calcule
la moyenne pondérée.
Par exemple :

Moyenne de la population A = VA, % de la population totale = a

Moyenne de la population B = VB, % de la population totale = b
Moyenne de la population C = VC, % de la population totale = c
Moyenne pondérée = a.VA + b.VB + c.VC
Évaluation du volume global du modèle organisationnel de données

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 66
Le chiffrage se fait de proche en proche dans le modèle organisationnel de données. En effet si le
concepteur n’a pas de problèmes majeurs pour définir la taille des propriétés, il peut avoir plus de
difficultés pour estimer la population des entités, des relations et la cardinalité moyenne des
relations, n’ayant pas toute l’information nécessaire. Il est alors conduit à tirer parti au maximum des
estimations dont il dispose pour chiffrer son modèle.
La quantification des propriétés, entités relations et cardinalités est généralement présentée sous forme
de tableaux où figurent les différentes valeurs estimées.

A partir des éléments quantifiés précédemment déterminés, le concepteur peut procéder à une
évaluation brute du volume total des données à mémoriser, pour la mémoire immédiate.
Ce chiffrage en volume brut n’estime que l’occupation des données utiles. Il ne tient pas compte du
volume résultant du mode de mémorisation des pattes entre entités et relations. Cet aspect dépendra du
mode de mémorisation informatique et sera chiffré au niveau du modèle logique de données en tenant
compte de l’optimisation et des caractéristiques techniques du système de gestion de base de données
utilisé.
Il faut considérer cette estimation en volume brut comme une valeur minimum pour l’occupation
ultérieure du volume informatique. Elle peut cependant, en introduisant un facteur multiplicatif (1,5 à
2,5 suivant les technologies), fournir une indication pour le volume de la base de données résultante.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 67
CHAPITRE CINQUIEME : CONCEPTION D’UN SYSTEME D’INFORMATION INFORMATISE

Ce chapitre précisera comment élaborer et exprimer les différents modèles, comment passer d'un
niveau d'abstraction au suivant et transformer les différents modèles et enfin, comment aborder toute
optimisation.
L'objectif du SII est la définition des moyens informatiques à disposition des postes de travail
(utilisateurs) afin d'effectuer les opérations organisées. Cette définition passe par la description de :
- l'aspect externe de ces moyens informatiques sous forme de masques d'écran et de leur
succession.
- les actions de ces moyens informatiques sur la structure logique des données et, pour cela,
- la structure logique des données (MLD) indépendamment de tout choix de matériel ou de
logiciel de développement informatique.
V.1. NIVEAU LOGIQUE
Le niveau logique représente le dernier niveau validé par l'utilisateur final (sauf si celui-ci réalise la
programmation). Il comprend une vue de l’utilisateur de l'informatique (vue externe de l'informatique)
et une vue plus spécifique (vue interne).

V.1.1. LE MODELE LOGIQUE DES DONNEES

La méthode Merise propose une modélisation logique, puis physique des données. La modélisation
logique des données est une représentation des données, issue de la modélisation conceptuelle puis
organisationnelle des données. Elle est exprimée dans un formalisme général et compatible avec l’état
de l’art technique, et tient compte des aspects coût/performance liés aux traitements.
La modélisation logique des données conduira aux opérations suivantes :
- Transformation du MOD, exprimé en formalisme entité-relation, en un MLD (modèle logique
de données) exprimé dans un formalisme logique adapté au SGBD (voire système de gestion
de fichiers) envisagé;
- Quantification en volume du modèle logique;
- Valorisation de l’activité générée par les modèles externes associés aux traitements (tâches du
MOT);
- Optimisation générale.
Le Modèle Logique des Données (MLD) est la suite normale du processus Merise. Son but est de nous
rapprocher au plus près du modèle physique. Pour cela, nous partons du Modèle Conceptuel des
Données et nous lui enlevons les relations, mais pas n'importe comment, il faut en effet respecter
certaines règles.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 68
 - Cas (0, n), (1,1) ou (l,n),(0,l)
Voici un modèle conceptuel de départ :

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

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

Illustrons ce cas sur le Modèle Conceptuel des Données suivant :

Dans le cas où la cardinalité maximale est n de chaque côté de la relation, celle-ci se transforme en
entité et absorbe les identifiants de chaque entité reliée. Les identifiants ainsi absorbés forment la
nouvelle clé de l'entité. Cette nouvelle clé est donc formée par la concaténation des clés étrangères des
entités reliées.

Remarque

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 69
La concaténation des deux clés étrangères doit être unique. Les couples de clés sont donc (I, I), (2,2),
(2,3)... Nous arrivons donc à la conclusion suivante : le client 1 qui adore le Roquefort ne pourra pas
en acheter plusieurs fois. Cette situation est anormale, je vous rappelle que « qui peut le plus peut le
moins ».

Continuons à modifier le Modèle Conceptuel des Données.

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

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

Reprenons ce Modèle Conceptuel des Données :

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 70
Les règles de passage du MCD au MLD s'appliquent toujours aussi mécaniquement. L'entité ayant la
cardinalité la plus faible absorbe l'identifiant de a l'entité reliée. Ici. nous n'avons qu'une seule entité,
mais le principe est le f même nous devons donc dupliquer l'identifiant Numéro employé.

b. Règles simples de passage du MCD au MLD

- L'entité qui possède la cardinalité maximale égale à 1 recevra l'identifiant ou les identifiants
des entités ayant les cardinalités maximales les plus fortes.
- Les relations ayant toutes leurs entités reliées avec des cardinalités maximales supérieures à 1
se transformeront en entité en absorbant les identifiants des entités jointes.
- Toute relation porteuse de propriétés se transformera en entité et absorbera comme clé
étrangère les identifiants des entités qui lui sont liées.

V.1.2. LE MODELE LOGIQUE DE TRAITEMENT

Le MLT se préoccupe d’une vision interne des moyens que l’informaticien va utiliser pour construire
le logiciel correspondant aux activités informatisées définies dans le MOT. On parlera d’enchaînement
de transactions, de découpage en modules, de répartition des données et traitements informatisés.

a. Unité Logique de Traitement (ULT)

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

b. Faisabilité
Cette construction exige beaucoup de réflexion, d’imagination et de créativité de la part du concepteur.
Pour arriver à les réaliser plus facilement, il faut procéder comme suit :
- Identifier d’abord les différentes ULT informatisables à partir du MOT. Les ULT
constitueront plus tard l’ensemble d’instructions exécutables.
- L’ensemble des procédures logiques ou ULT construit ensuite le MLT, avec un début et une
fin.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 71
 - Construire enfin les procédures logiques correspondant à chaque ULT ou domaine; chaque
ULT reposant sur une maquette d’écran ou des boîtes de dialogue, c’est-à-dire sur des
interfaces.

c. Formalisme

Les unités logiques de traitement sont représentées de la manière suivante :

Si l’unité logique de traitement est connectée à une base de données, elle sera représentée de la
manière suivante :

N.B : Pour la connexion de la base de données, il faut mettre le nom de la table correspondante
REMARQUE :
Le nombre des unités logiques de traitement corresponde aux nombres d’interfaces possibles.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 72
V.2. NIVEAU PHYSIQUE
Les réponses apportées à ce dernier niveau permettent d'établir la manière concrète dont le système sera
mis en place

V.2.1. LE MODELE PHYSIQUE DES DONNEES

Construire Le Modèle Physique des Données consiste à transformer Le Modèle Logique des Données
en une suite de relations. Cette étape finalise le processus de traitement des données. L'implémentation
des bases de données peut être réalisée de façon optimale.

Voici les relations (ou schéma relationnel) du modèle physique qui en découlent :
Diplômes (Diplômes)
Possède (#NumEmployé, #Diplôme, Date d'obtention)
Employés (NumEmployé, Nom, Prénom, Adresse, Code Postal, Ville, Télé-phone)
Tables (NumTable, Capacité)
Date (Date)
Service (TypeService, Désignation)
Boissons Diverses fNumBoissons, Désignation, Prix de vente)

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 73
Contenir (#NumCommande, #NumBoissons, Quantité)
Commande (NumCommande, #Numemployé, #Date, #TvpeService. #NumTable)
Comprend (#NumMenu, #NumCommande, Quantité) Menus (NumMenu, Libellé, Prix de vente)
Constitué (#NumMenu, #NumPlat) Constituer (#NumCommande, #NumPlat, Quantité)
Sélectionner (#NumCommande, #NumVin, Quantité)
Carte des vins (NutnVin, Nom du vin, Millésime, Prix de vente) Carte des plats (NumPlat. LibelléPlat,
Prix de vente, #NumType) Type des plats CNumTvpe, Désignation)
Bouteilles (NumBouteille, Date Achat, Prix d'achat, # NumVin, #NumViticulteur)
Viticulteur (NumViticulteur, Nom viticulteur, Prénom viticulteur, Adresse viticulteur, Code postal,
Ville, Téléphone)

Comme vous le voyez, passer du modèle logique de données au modèle physique des données ne
présente aucune difficulté. On abandonne juste la représentation graphique pour une représentation
plus linéaire.

a. Transcription SQL du Modèle physique

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

CREATE TABLE CARTE_DES_VINS (

NUMVIN INTEGER (2| NOT NULL,
NOM_DU_VIN CHAR(40)
MILLESIME INTEGER(2),
PRIX_DE_VENTE REAL(5,2)
PRIMARY KEY (NUMVIN) constraint pk_carte_des_vins
);
CREATE TABLE BOUTEILLES (
NUMVITICULTEUR INTEGER (2) NOT NULL, NUMVIN INTEGER(2) NOT NULL ,
NUMBOUTEILLE INTEGER(2) NOT NULL , DATE_ACHAT DATE(8) PRIX_D_ACHAT
REAL(5,2)
PRIMARY KEY (NUMVITICULTEUR, NUMVIN, NUMBOUTEILLE) CONSTRAINT
PKBOUTEILLES
);
CREATE TABLE VITICULTEUR (

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 74
NUMVITICULTEUR INTEGER(2) NOT NULL, NOMJVITICULTEUR CHAR(20)
PRÉNOM__VITICULTEUR CHAR (20) ADRESSE_VITICULTEUR CHAR(40) CODE__POSTAL
CHAR (5) VILLE CHAR(40) TÉLÉPHONE CHAR(15)
PRIMARY KEY (NUMVITICULTEUR) CONSTRAINT PK VITICULTEUR

);

V.2.2. LE MODELE PHYSIQUE DE TRAITEMENT (MPT)

Le modèle physique de traitement n’est rien que la présentation de la manière dont les différents
modules seront agencés sous forme de menu. Il n’existe pas un formalisme approprié, ni des règles de
passage de MLT au MPT.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 75
CHAPITRE SEPTIEME : LES NOTIONS SUR LES METHODES AGILES

Une méthode agile est une méthode de développement informatique permettant de concevoir des
logiciels en impliquant au maximum l’utilisateur, avec une grande réactivité à ses demandes. Ces
méthodes se veulent plus pragmatiques que leurs homologues classiques et commencent à être
appliquées dans tous environnements.

VII.1. LA METHODE UP : « LE PROCESSUS UNIFIE »

Nous n’allons pas dans le cadre de ce chapitre donner une présentation détaillée d’UP. Cependant, il
nous a paru intéressant de dégager les idées fondatrices d’UP dans le cadre d’une présentation
générale. Nous allons tout d’abord expliciter les principes de la méthode UP. Nous compléterons
ensuite cette présentation générale en décrivant l’architecture à deux dimensions d’UP et ses
principaux concepts, nous passerons aussi en revue les différentes phases d’UP, et pour finir nous
détaillerons les activités d’UP.

VII.1.1. Les principes d’UP.

Le processus de développement UP, associé à UML, met en œuvre les principes suivants :
Processus guidé par les cas d’utilisation : L’orientation forte donnée ici par UP est démontrée
que le système à construire se définit d’abord avec les utilisateurs. Les cas d’utilisation
permettent d’exprimer les interactions du système avec les utilisateurs, donc de capturer les
besoins.
Processus itératif et incrémental : les risques sont évalués et traités au fur et à mesure des
itérations, les premières itérations permettent d’avoir un feed-back des utilisateurs, les tests et
l’intégration se font de manière continue, les avancées sont évaluées au fur et à mesure de
l’implémentation
Processus centré sur l’architecture : Les auteurs d’UP mettent en avant la préoccupation de
l’architecture du système dès le début des travaux d’analyse et de conception.
Processus orienté par la réduction des risques : L’analyse des risques doit être présente à tous
les stades de développement d’un système. Il est important de bien évaluer les risques des
développements afin d’aider à la bonne prise de décision.

VII.1.2. Les concepts et les deux dimensions d’UP

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 76
 ❖ Définition des principaux concepts et schéma d’ensemble
Le processus unifié décrit qui fait quoi, comment et quand les travaux sont réalisés tout au long du
cycle de vie du projet. Quatre concepts d’UP répondent à ces questions :
Rôle (qui ?) : Un rôle définit le comportement et les responsabilités d’une ressource ou d’un
groupe de ressources travaillant en équipe. Le rôle doit être considéré en termes de « casquette
» qu’une ressource peut revêtir sur le projet. Une ressource peut jouer plusieurs rôles sur le
projet.
Activité (comment ?) : Les rôles ont des activités qui définissent le travail qu’ils effectuent.
Une activité est une unité de travail qu’une ressource, dans un rôle bien précis, peut effectuer
et qui produit un résultat dans le cadre du projet.
Artefact (quoi ?) : Un artefact est un ensemble d’informations qui est produit, modifié ou
utilisé par le processus. Les artefacts sont les produits effectifs du projet. Les artefacts sont
utilisés comme input par les ressources pour effectuer une activité et sont le résultat d’output
d’activités du processus.
Workflow (quand ?) : est une séquence d’activités qui produit un résultat mesurable. En UML,
il peut être exprimé par un diagramme de séquence, un diagramme de communication ou un
diagramme d’activité.

❖ Schéma d’ensemble
UP peut être décrit suivant deux dimensions traduites en deux axes :
Un axe horizontal représentant le temps et montrant l’aspect dynamique du processus. Sur cet
axe, le processus est organisé en phases et itérations.
Un axe vertical représentant l’aspect statique du processus. Sur cet axe, le processus est
organisé en activités et workflows.

Figure 57: Schéma d'ensemble d'UP

VII.1.3. Les phases et itérations du processus (aspect dynamique)

Le processus unifié, organisé en fonction du temps, est divisé en quatre phases successives.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 77
 Inception (Lancement).
Elaboration.
Construction.
Transition.
Capture de besoin (Inception)
Cette phase correspond à l'initialisation du projet où l'on mène une étude d'opportunité et de faisabilité
du système à construire. Une évaluation des risques est aussi réalisée dès cette phase.
En outre, une identification des principaux cas d'utilisation accompagnée d'une description générale
est modélisée dans un diagramme de cas d'utilisation afin de définir le périmètre du projet. Il est
possible, à ce stade, de faire réaliser des maquettes sur un sous-ensemble des cas d'utilisation
identifiés.
Ce n'est qu'à l'issue de cette première phase que l'on peut considérer le projet véritablement lancé.
Élaboration
Cette phase reprend les résultats de la phase d'inception et élargit l'appréciation de la faisabilité sur la
quasi-totalité des cas d'utilisation. Ces cas d'utilisation se retrouvent dans le diagramme des cas
d'utilisation qui est ainsi complété.
Cette phase a aussi pour but d'analyser le domaine technique du système à développer afin d'aboutir à
une architecture stable. Ainsi, toutes les exigences non recensées dans les cas d'utilisation, comme par
exemple les exigences de performances du système, seront prises en compte dans la conception et
l'élaboration de l'architecture. L'évaluation des risques et l'étude de la rentabilité du projet sont aussi
précisées. Un planning est réalisé pour les phases suivantes du projet en indiquant le nombre
d'itérations à réaliser pour les phases de construction.
Construction
Cette phase correspond à la production d'une première version du produit. Elle est donc fortement
centrée sur les activités de conception, d'implémentation et de test. En effet, les composants et
fonctionnalités non implémentés dans la phase précédente le sont ici.
Au cours de cette phase, la gestion et le contrôle des ressources ainsi que l'optimisation des coûts
représentent les activités essentielles pour aboutir à la réalisation du produit. En parallèle est rédigé le
manuel utilisateur de l'application.

Transition
Après les opérations de test menées dans la phase précédente, il s'agit dans cette phase de livrer le
produit pour une exploitation réelle. C'est ainsi que toutes les actions liées au déploiement sont traitées
dans cette phase.
De plus, des « bêta tests » sont effectués pour valider le nouveau système auprès des utilisateurs.
Itérations

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 78
Une phase peut être divisée en itérations. Une itération est un circuit complet de développement
aboutissant à une livraison (interne ou externe) d'un produit exécutable.
Ce produit est un sous-ensemble du produit final en cours de développement, qui croît
incrémentalement d'itération en itération pour devenir le système final.
Chaque itération au sein d'une phase aboutit à une livraison exécutable du système.
VII.1.4. Les activités du processus (aspect statique)
Les activités menées à l'intérieur des quatre phases sont plus classiques, car déjà bien documentées
dans les méthodes existantes par ailleurs. Nous nous limiterons donc à ne donner qu'une brève
explication de chaque activité.
Expression des besoins
UP propose d'appréhender l'expression des besoins en se fondant sur une bonne compréhension du
domaine concerné pour le système à développer et une modélisation des procédures du système
existant.
Ainsi, UP distingue deux types de besoins :
▪ Les besoins fonctionnels qui conduisent à l'élaboration des cas d'utilisation,
▪ Les besoins non fonctionnels (techniques) qui aboutissent à la rédaction d'une matrice des
exigences.
Analyse
L'analyse permet une formalisation du système à développer en réponse à l'expression des besoins
formulée par les utilisateurs. L'analyse se concrétise par l'élaboration de tous les diagrammes donnant
une représentation du système tant statique (diagramme de classe principalement), que dynamique
(diagramme des cas d'utilisation, de séquence, d'activité, d'état-transition...).
Conception
La conception prend en compte les choix d'architecture technique retenus pour le développement et
l'exploitation du système. La conception permet d'étendre la représentation des diagrammes effectuée
au niveau de l'analyse en y intégrant les aspects techniques plus proches des préoccupations physiques.

Implémentation
Cette phase correspond à la production du logiciel sous forme de composants, de bibliothèques ou de
fichiers. Cette phase reste, comme dans toutes les autres méthodes, la plus lourde en charge par rapport
à l'ensemble des autres phases (au moins 40 %).
Test
Les tests permettent de vérifier :
▪ La bonne implémentation de toutes les exigences (fonctionnelles et techniques),
▪ Le fonctionnement correct des interactions entre les objets,
▪ La bonne intégration de tous les composants dans le logiciel.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 79
Classiquement, différents niveaux de tests sont réalisés dans cette activité : test unitaire, test
d'intégration, test de réception, test de performance et test de non-régression.
VII.2. LE LANGAGE UML
UML est une notation graphique conçue pour représenter, spécifier, construire et documenter les
systèmes logiciels. Ses deux principaux objectifs sont la modélisation de systèmes utilisant les
techniques orientées objet, depuis la conception jusqu’à la maintenance, et la création d’un langage
abstrait compréhensible par l’homme et interprétable par les machines. UML s’adresse à toutes les
personnes chargées de la production, du déploiement et du suivi de logiciels (analystes, développeurs,
chefs de projets, architectes…), mais peut également servir à la communication avec les clients et les
utilisateurs du logiciel. Il s’adapte à tous les domaines d’application et à tous les supports. Il permet de
construire plusieurs modèles d’un système, chacun mettant en valeur des aspects différents :
fonctionnels, statiques, dynamiques et organisationnels. UML est devenu un langage incontournable
dans les projets de développement.
Une méthode de développement définit à la fois un langage de modélisation et la marche à suivre lors
de la conception. Le langage UML propose uniquement une notation dont l’interprétation est définie
par un standard, mais pas une méthodologie complète. Plusieurs processus de développement complets
fondés sur UML existent, comme le Rational Unified Process (RUP), de Booch, Jacobson et
Rumbaugh, ou l’approche MDA (Model Driven Architecture) proposée par l’OMG, mais ils ne font
pas partie du standard UML.
UML est le résultat d’un large consensus, continuellement enrichi par les avancées en matière de
modélisation de systèmes et de développement de logiciels. C’est le résultat d’un travail d’experts
reconnus, issus du terrain. Il couvre toutes les phases du cycle de vie de développement d’un système
et se veut indépendant des langages d’implémentation et des domaines d’application.
UML dans sa version 2 propose treize diagrammes qui peuvent être utilisés dans la description d’un
système. Ces diagrammes sont regroupés dans deux grands ensembles.
❖ Les diagrammes structurels – Ces diagrammes, au nombre de six, ont vocation à représenter
l’aspect statique d’un système (classes, objets, composants…).
Diagramme de classe – Ce diagramme représente la description statique du système en
intégrant dans chaque classe la partie dédiée aux données et celle consacrée aux traitements.
C’est le diagramme pivot de l’ensemble de la modélisation d’un système.
Diagramme d’objet – Le diagramme d’objet permet la représentation d’instances des classes
et des liens entre instances.
Diagramme de composant (modifié dans UML 2) – Ce diagramme représente les différents
constituants du logiciel au niveau de l’implémentation d’un système.
Diagramme de déploiement (modifié dans UML 2) – Ce diagramme décrit l’architecture
technique d’un système avec une vue centrée sur la répartition des composants dans la
configuration d’exploitation.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 80
 Diagramme de paquetage (nouveau dans UML 2) – Ce diagramme donne une vue d’ensemble
du système structuré en paquetage. Chaque paquetage représente un ensemble homogène
d’éléments du système (classes, composants…).

Diagramme de structure composite (nouveau dans UML 2) – Ce diagramme permet de décrire

la structure interne d’un ensemble complexe composé par exemple de classes ou d’objets et de
composants techniques. Ce diagramme met aussi l’accent sur les liens entre les sous-
ensembles qui collaborent.
❖ Les diagrammes de comportement – Ces diagrammes représentent la partie dynamique d’un
système réagissant aux événements et permettant de produire les résultats attendus par les
utilisateurs. Sept diagrammes sont proposés par UML :
Diagramme des cas d’utilisation – Ce diagramme est destiné à représenter les besoins des
utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans
l’analyse d’un système.
Diagramme d’état-transition (machine d’état) – Ce diagramme montre les différents états des
objets en réaction aux événements.
Diagramme d’activités (modifié dans UML 2) – Ce diagramme donne une vision des
enchaînements des activités propres à une opération ou à un cas d’utilisation. Il permet aussi
de représenter les flots de contrôle et les flots de données.
Diagramme de séquence (modifié dans UML 2) – Ce diagramme permet de décrire les
scénarios de chaque cas d’utilisation en mettant l’accent sur la chronologie des opérations en
interaction avec les objets.
Diagramme de communication (anciennement appelé collaboration) – Ce diagramme est une
autre représentation des scénarios des cas d’utilisation qui met plus l’accent sur les objets et
les messages échangés.
Diagramme global d’interaction (nouveau dans UML 2) – Ce diagramme fournit une vue
générale des interactions décrites dans le diagramme de séquence et des flots de contrôle
décrits dans le diagramme d’activités.
Diagramme de temps (nouveau dans UML 2) – Ce diagramme permet de représenter les états
et les interactions d’objets dans un contexte où le temps a une forte influence sur le
comportement du système à gérer.
Aujourd’hui UML 2 décrit les concepts et le formalisme de ces treize diagrammes mais ne propose pas
de démarche de construction couvrant l’analyse et la conception d’un système. Ce qui a pour
conséquence par exemple de ne pas disposer d’une vision des interactions entre les diagrammes.
➢ Différentes vues et diagrammes D’UML
Toutes les vues proposées par UML sont complémentaires les unes des autres, elles permettent de
mettre en évidence différents aspects d’un logiciel à réaliser. On peut organiser une présentation

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 81
d’UML autour d’un découpage en vues, ou bien en différents diagrammes, selon qu’on sépare plutôt
les aspects fonctionnels des aspects architecturaux, ou les aspects statiques des aspects dynamiques.
Nous adopterons plutôt dans la suite un découpage en diagrammes, mais nous commençons par
présenter les différentes vues, qui sont les suivantes :

La vue fonctionnelle, interactive, qui est représentée à l’aide de diagrammes de cas et de

diagrammes des séquences. Elles cherchent à appréhender les interactions entre les différents
acteurs/utilisateurs et le système, sous forme d’objectif à atteindre d’un côté et sous forme
chronologique de scénarios d’interaction typiques de l’autre.
La vue structurelle ou statique, réunit les diagrammes de classes et les diagrammes de
packages. Les premiers favorisent la structuration des données et tentent d’identifier les
objets/composants constituant le programme, leurs attributs, opérations et méthodes, ainsi que
les liens ou associations qui les unissent. Les seconds s’attachent à regrouper les classes
fortement liées entre elles en des composants les plus autonomes possibles. A l’intérieur de
chaque package, on trouve un diagramme de classes.
La vue dynamique, qui est exprimée par les diagrammes d’états. Cette vue est plus
algorithmique et orientée « traitement », elle vise à décrire l’évolution (la dynamique) des
objets complexes du programme tout au long de leur cycle de vie. De leur naissance à leur
mort, les objets voient leurs changements d’états guidés par les interactions avec les autres
objets. Le diagramme d’activité est une sorte d’organigramme correspondant à une version
simplifiée du diagramme d’états. Il permet de modéliser des activités qui se déroulent en
parallèle les unes des autres, quand ce parallélisme peut poser problème. En général, les
diagrammes d’états à eux seuls ne permettent pas de faire apparaître les problèmes spécifiques
posés par la synchronisation des processus en concurrence, pour assurer la cohérence du
comportement et l’absence d’inter-blocage. Etablir un diagramme d’activité peut aider à
mettre au point un diagramme d’états.
UML n'est qu'un langage de modélisation. Nous n'avons pas aujourd'hui la norme, de démarche
unifiée pour construire les modèles et conduire un projet mettant en œuvre UML. Cependant les
auteurs d'UML, ont décrit, dans un ouvrage [Jacobson2000a] le processus unifié (UP, Unified Process)
qui doit être associé à UML.

Cours de MAI 2 conçu par l’Assistant OMARI LUKENDO David dit OLD de l’ISC/Bukavu Page 82