TABLE DE MATIERE

TABLE DE MATIERE ...................................................................................................................................... 1

INTRODUCTION GENERALE ...................................................................................................................... 2
OBJECTIFS DU COURS ................................................................................................................................... 2
CHAPITRE I. SYSTEME D’INFORMATION ET SYSTEME INFORMATIQUE ......................................... 3
CHAPITRE II. ANALYSE D’UN SYSTEMEN D’INFORMATION ............................................................... 8
CHAPITRE III. MODELISATION D’UN SYSTEME D’INFORMATION .................................................. 18
CHAPITRE IV : MODELISATION D’UN SYSTEME AVEC UML

1
INTRODUCTION GENERALE

Toute organisation se fixe des objectifs à atteindre pour améliorer sa rentabilité. Répondre à cette
préoccupation convient à la maitrise de son système d’information dans lequel transite
l’information entre les différents postes de travail.

L’information est une richesse précieuse parmi celles que peut avoir l’organisation qui nécessite un
bon système qui soit efficace, efficient avec faciliter d’accès.

Faire du progrès dans une entreprise est fonction de la qualité de son système d’information et du
personnel qui y travaille.

L’informatique est le meilleur moyen de gérer une organisation à travers l’utilisation de la base de
données. Mettre en place une base de données pour une grande ou petite entreprise revient à
connaitre le domaine d’activité sur le problème à résoudre, les utilisateurs de ladite base de
données, le processus à suivre pour une bonne mise en œuvre, la manière d’utilisation de la base de
données et autre exigences à appendre en comptes.

Pour se faire, il est important de prendre un bon moment à comprendre ces choses, et cela, en
suivant une méthodologie d’une analyse approfondie.

Ainsi dans le cadre de ce cours, nous allons apprendre à connaitre l’entreprise, la démarche à suivre
pour l’analyse de celle-ci et les méthodes à utiliser pour mettre en place un modèle de construction
d’une base de données répondant aux normes et exigences du problème à traiter.

OBJECTIFS DU COURS

A la fin de ce cours de Conception des systèmes d’informations, l’apprenant sera à mesure :

 D’acquérir les notions essentielles à la compréhension de l’entreprise entant que Système

et établir la différence qui peut exister entre un Système d’Information et celui
Informatique.
 D’analyser un Système d’Information et produire une documentation d’analyse complète.
 Concevoir une base de données par approche MERISE et UML
 De manipuler les données dans une base de données

2
CHAPITRE I. SYSTEME D’INFORMATION ET SYSTEME INFORMATIQUE

Analyser une entreprise dans un but ou processus d’automatisation du moyen de traitement et

circulation de l’information revient connaitre et comprendre cette dernière pour savoir quoi
chercher, où le trouver et comment s’y prendre. Ainsi, une entreprise est considérée comme un
Système à part entier contenant les sous-systèmes et les moyens qui facilitent la circulation de
l’information dans lequel il faut comprendre pour des fins de changement ou d’amélioration de la
gestion de l’information.

Ce présent chapitre présente séparément les notions liées au Système d’Information et

Informatique dans le souci de comprendre ce système pour vouloir porter une solution consistant à
l’automatisation.

Section 1. LES SYSTEMES D’INFORMATIONS

Le terme Système d’information comprend deux concepts. Pour mieux comprendre ce terme
système d’information, il convient de bien appréhender les concepts qui le composent dont dans la
suite, nous traiterons d’abord ces concepts de manière séparée.

1. Systèmes
1.1. Définition du concept système

Il n’existe pas une définition classique du concept « système », mais des approches définitionnelles
orientées vers un secteur d’activités.
Dans le domaine de gestion, l’approche définitionnelle du concept « système » est orientée vers le
point de vue de LEIBNIZ, complétée par BERTANLAFFY et enrichie par ROSNAY, partant de
Jean-Louis LEMOIGNE.
Joël de ROSNAY dit alors qu’un système est un ensemble d’éléments vivants en interaction
mutuelle et poursuivant un but commun.1
Nous pouvons alors comprendre le terme Système comme un ensemble d’éléments en interaction
dynamique en vue d’atteindre un objectif.

2. Informations
2.1. Définition
Elément de connaissance susceptible d'être codé pour être conservé, traité ou communiqué.
2.2. Notion d'information En informatique

La notion de données est très utilisée. Par exemple un programme a généralement des données sur
lesquelles il travaille. On peut définir une donnée comme une information numériques ou
alphanumériques, représentées sous forme codée, compréhensibles par la seule machine, pouvant
être enregistrées, traitées, conservées et communiquées.

1
Prof. KAFUNDA, Notes du cours de base de données, PROGRESS, Session 2016, P3, inédit
3
En réalité, on fait une distinction entre les données et l'information. La donnée est un fait brut non
interprété tandis que l'information est porteuse de sens. On peut dire qu'une information est un
ensemble de données interprétées dans un contexte particulier.
2.3. Les éléments d’une information
Une information est un ensemble de trois éléments :
 Une entité : l'être, l'objet ou le concept concerné
 Un attribut : un élément de la description de l'entité
 Une mesure : une valeur associée à l'attribut
2.4. Rôle de l'information

Tout acte de la vie d'une organisation s'accompagne ou est conditionné par des informations pour :
 Améliorer son fonctionnement
 Faciliter la prise de décision

3. Systèmes d’informations

3.1. Définition

Un système d'informations (SI) est un ensemble organisé de ressources (matériels, logiciels,

personnel, données et procédures) qui permet de collecter, regrouper, classifier, traiter et diffuser
de l'information dans un environnement donné2
Un SI est un ensemble d'éléments matériels ou immatériels (hommes, machines, méthodes, règles)
participant à la gestion, au traitement, au transport et à la diffusion de l'information au sein de
l'organisation.3

Né dans les domaines de l'informatique et des télécommunications, le concept de système

d'informations s'applique maintenant à l'ensemble des organisations, privées ou publiques.

3.2. Rôles d’un système d’information

La tâche principale du système d’information est donc de fournir un flux d’information qui d’une
part, reflète le plus fidèlement possible le flux physique, et autre part fournit au système de pilotage
les éléments nécessaires à une prise correcte de décision.
Ainsi les processus suivants peuvent être cité constituant le rôle du Système d’Information :

 Collecte et analyse de données en interne ou externe en prenant en compte que celle

nécessaire
 Traiter les données (Mise à jour, Calcul, Fusion, Tri et autres)
 Stockage de ces données
 Diffusion des résultats après traitement

3.3. Type des systèmes d’informations

Il existe trois critères de classification des systèmes d’informations :

2
De Courcy R, Les systèmes d'information en réadaptation, Québec, , 1992, no 5 vol. 1-2 P. 7-10, inédit
3
www.wikipedia.com, Consulter le 10 Mars 2017
4
 a. Selon les moyens utilisés :

 Le système manuel : la procédure est mise en charge totalement par les hommes ;
 Le système mécanique : lorsqu’il y a recours aux machines programmables ;
 Le système informatique : lorsqu’il y a intervention des ordinateurs

b. Selon le nombre d’intervenants :

 Le système individuel : lorsque la procédure est centrée autour d’une seule personne ;
 Le système organisationnel : lorsque la procédure est déclenchée et clôturée au sein de
la même organisation ;
 Le système inter-organisationnel : lorsque la procédure est déclenchée ailleurs pour se
clôturer à l’intérieur de l’organisation et vice-versa.
c. Selon le niveau hiérarchique :
 Le système stratégique : lorsque le traitement se fait au niveau des décideurs ;
 Le système tactique : lorsque le traitement se fait au niveau des exécutants ;

3.4. Sécurité d’un système d’informations

La sécurité des systèmes d'informations vise à garantir à ce qu’aucun dommage ne puisse mettre à
risque la bonne marche de l'entreprise. Cela consiste à diminuer la vulnérabilité du système contre
les des menaces accidentelles ou intentionnelle, limiter les atteintes ou dysfonctionnements induits,
et autoriser le retour à un fonctionnement normal à des coûts et des délais acceptables en cas de
destruction.
Pour ce qui concerne les données et les logiciels, la sécurité informatique implique qu'il faut assurer
les propriétés suivantes :
 La confidentialité (aucun accès illicite) : maintien du secret de l'information et accès aux
seules entités autorisées ;
 L'intégrité (aucune falsification) : maintien intégral et sans altération des données et
programmes ;
 L'exactitude (aucune erreur) ;
 La disponibilité (aucun retard) : maintien de l'accessibilité en continu sans interruption ni
dégradation ;
 La pérennité (aucune destruction) : les données et logiciels existent et sont conservés le
temps nécessaire ;
 La non-répudiation (aucune contestation).
Section 2. Système Informatique

Le système d’information dans une organisation à plusieurs missions entre autres la gestion, la
sécurité, la facilité dans le traitement de l’information.

Parmi les informations qui appartiennent au système d’information, certaines doivent ou peuvent
faire l’objet d’un traitement automatisé grâce aux outils informatiques à travers les nouvelles
technologies de l’information et de la communication. Ainsi le traitement de l’information dans une
organisation peut être manuel ou automatique.

Lorsqu’on fait appel à l’informatique dans une gestion quelconque d’une organisation, le système
de cette gestion est dite automatique, ainsi on peut alors parler du Système Informatique.

5
Signalons aussi que tous les domaines ou toutes tâche dans l’organisation ne pas toujours à
informatiser mais l’informatique offre une bonne gestion et touche une grande partie de
l’organisation.

Cette science au moyen de son outil, Ordinateur offre des avantages au traitement de l’information
comme :

 L’économie du temps
 La fiabilité dans le traitement
 La vitesse dans le traitement et rapidité de transmission
 Le stockage facile avec moins de répétition de l’information possible
 Le coût reste raisonnable

1. Définition
Un système d’information informatisée est un ensemble des moyens informatiques et de
télécommunication qui permet d’élaborer, traiter, stocker, acheminer, présenter ou détruire des
données.
Il est la partie informatique du système d’informations, composée de matériels, logiciels, réseaux et
procédures d’utilisation.

2. Qualités d’un système informatique

Un bon système informatique doit répondre aux qualités suivantes :
 La Fiabilité : Cette qualité attend à un système informatique de fournir des informations
fiables avec moins d’erreurs que possible
 La Rapidité : Exige que le système mette à la disposition de l’utilisateur les informations à
temps ou court délai
 La Pertinence : Une des qualités d’un bon système capable à fournir des informations utiles
 La Sécurité : Un bon système doit être à mesure d’assurer la sécurité de ses composants

3. Rôle et importance d’un système informatique

Le système informatique joue un rôle très important dans un système d’information parce que de
nos jours presque toutes les entreprises cherchent à informatiser certaines de leurs informations et
sur ce, elles doivent faire appel à un système informatique.

Un système informatique a pour rôle de faciliter l’organisation et surtout la mise en œuvre des
infrastructures d’un système d’information. Il permet le traitement automatisé de ses informations
grâce aux outils informatiques et il y a aussi les apports de la Nouvelle Technologie de
l’Information et de la Communication (NTIC).

Un système informatique est un ensemble d'équipements destiné au traitement automatique de

l'information.

Ce traitement de l'information consiste en :

L’enregistrement de l'information
La modification de l'information
La suppression de l'information
La restitution de l'information

6
 4. Composantes d’un système informatique
Un système informatique est le système de traitement automatique de l’information. Il se compose
de deux parties :

 La partie matérielle (Hardware) : l’ensemble des éléments physiques constituant la machine.

 La partie logicielle (Software) : l’ensemble des logiciels (programmes) de traitement de
l’information.

5. Différentes unités dans le traitement automatique

D’après la définition d’un système informatique, on peut déduire que la partie matérielle se
compose de trois unités :

1. Des unités d’entrée permettant de saisir les données à traiter.

2. Une unité de traitement ou l’Unité Centrale de Traitement « UCT », qui se compose de
plusieurs éléments :

 Une Mémoire centrale pour mémoriser les informations au moment du traitement

(RAM).
 Une unité arithmétique et logique pour générer les résultats à partir des données.
 Une unité de contrôle pour contrôler les opérations au niveau de l’UAL.
 Des organes de stockage permettant de conserver les informations de manière
permanente (DDR)
3. Des unités de sortie pour communiquer les résultats du traitement.

Périphérique d’entrée : Unité Centrale Périphérique de sortie :

Clavier, Souris, Microphone de Traitement Haut-parleur, Imprimante,
Ecran

Organe de
stockage : Disque dur, Clé
USB, CD-ROM

La partie matérielle comporte des éléments permettant de recevoir les données, autres permettant
de traiter les données et d’autres éléments communiquent les résultats de traitement avec
l’extérieur.

7
CHAPITRE II. ANALYSE D’UN SYSTEMEN D’INFORMATION

Décider d’automatiser son système d’information dans le souci de bénéfice des avantages qu’offre
ce dernier est une préoccupation, l’automatisation en est une autre aussi. Il revient à proposer un
modèle représentant les objets du monde réel dont sa mise en œuvre consistera à l’informatisation.

Par contre, pour avoir un modèle à mettre en œuvre, il est important de comprendre le système et
son fonctionnement. En informatique cette démarche est appelée Conception des systèmes
d’informations.

En d’autre terme, le problème d’automatisation convient à respecter les besoins non fonctionnels
et fonctionnels précisé dans le cahier de charge. Ces besoins sont spécifiés d’une part par le Client
ou le futur utilisateur représenté par la maitrise d’Ouvrage (MOA) dont le concepteur représenté
par la Maitrise d’œuvre (MEO) doit procéder à la compréhension du problème pour une bonne
réussite du projet d’automatisation.

Cette compréhension du problème est un facteur essentiel qui permettra à la Maitrise d’œuvre de se
situer par rapport à toute l’entreprise, connaitre les informations à gérer et les personnes qui y
participeront dans le traitement. C’est grâce à une analyse ou étude préalable du système existant
qu’il sera possible.

II.1. Définition
L’analyse informatique peut être définie comme une démarche à suivre dans l’étude d’un système
d’information consistant à l’évolution du système actuel.

II.2. Organisation de l’univers des Ordinateurs

L’organisation de l’univers des ordinateurs est composée de quatre (4) domaines :

Matériel
Le matériel est un domaine qui permet de connaitre l’aspect interne des ordinateurs notamment le
fonctionnement des ceux-ci, leurs types, le type des processeurs etc…

Logiciel
Ce domaine par contre permet de résoudre les problèmes qui se posent dans les organisations
grâce à la réalisation des logiciels ou progiciels. Il permet aussi de dialoguer avec les machines ainsi
que la gestion de différentes sources de l’ordinateur.

Le Système d’Information
Le domaine des systèmes d’information est lié à l’implantation des ordinateurs dans les
organisations ainsi que l’informatisation ou automatisation des problèmes.

Les Conséquences Sociales

Ce domaine des conséquences sociales est basé sur l’impact de l’ordinateur dans la société.

8
II.3. Démarche d’Informatisation

1. Première démarche
Parmi les informations appartenant au système d’information, certaines peuvent faire office du
traitement automatique aux moyens des outils informatiques. Pour ce faire, il est important de
spécifier qu’une méthode d’informatisation soit utilisée, MERISE pour le cas présent.

a) Etude d’opportunité
Cette analyse permet de déterminer la faisabilité du projet sur l’automatisation au niveau technique,
humaine ou financier suivant les étapes telles que :

 Constitution d’un groupe d’étude

 Etablissement d’un planning prévisionnel
 Etude préalable
 Analyse de l’existant
 Critique de l’existant
 Proposition de la solution

 Constitution d’un groupe d’étude

Le problème d’automatisation peut constituer un travail complexe qui peut nécessiter la présence
de plus d’une personne. Ainsi, il est recommandé d’organiser des équipes puis affecter les gens
dans souci de bien mener le projet.

Dans chaque groupe, il sera question de déterminer le chef ou responsable qui suivra le
déroulement de l’automatisation.

Le groupe d’étude est constitué de :

 L’informaticien responsable du projet

 Différents membres des services ou des départements concernés par le problème
 Consultant extérieur
 L’Ingénieur en organisation
 Membre de comité de gestion
 Etude préalable
L’étude préalable permet de définir l’opportunité et la praticabilité d’information en posant d’une
façon claire le problème à informatiser et les objectifs à atteindre.

L’informatisation est une décision qui ne doit pas être prise à la légère mais plutôt elle doit être
bien préparée, c’est grâce à cette étude que l’analyse ou le groupe d’analystes va se limiter à un
domaine précis dans l’entreprise ou l’organisation faisant objet de champs d’investigation dans un
but d’amélioration du système d’information existant.

Cette étude joue le même rôle que le schéma directeur mais en se limite comme mentionner ci-haut
dans un domaine bien précis de l’organisation.

9
  L’étude préalable a pour objectif :
 Poser correctement le problème à résoudre
 Rechercher une orientation de la solution par la définition de l’avant-projet.
D’une manière générale, l’étude préalable permet de répondre si Oui ou Non faut-il informatiser.

Il est pour se faire nécessaire de voir la faisabilité ou la praticabilité (utilisation de l’ordinateur) et le

problème d’opportunité (aspect économique ou de la rentabilité par rapport à l’organisation de
l’entreprise) avant de se lancer dans un projet d’automatisation.

La réponse à ces préoccupations revient à effectuer une analyse ou une étude du système existant.

 Analyse de l’existant

De manière générale, lors de cette étape, il s’agit d’identifier les flux d’informations et les stations
traversées par ces flux, en relevant les documents (supports des flux) ou les supports plus ou moins
informels (bouche à oreille, gommettes de couleur etc…), les divers traitements qu’ils subissent au
niveau des stations et tous les « avatars » qu’ils peuvent subir.

C’est une partie fondamentale de l’étude d’opportunité et de la démarche d’informatisation car elle
fournit le diagnostic du système existant selon le besoin de l’entreprise à travers les utilisateurs.

NB : Pour plus d’informations sur cette partie, prière de consulter le point II.4 sur les détails de
l’analyse de l’existant.

Processus de récolte de données

La récolte de données lors de l’analyse de l’existant fait appel à plusieurs techniques, cependant en
informatique, les techniques suivantes sont utilisées :

 Interview
 Observation
 Documentaire
 Questionnaire (Enquête)

a) Interview
C’est une technique consistant à passer un temps de question réponse avec le personnel de
l’entreprise en étude dans le but de comprendre l’organisation de l’information ou la manière de la
faire circuler d’un poste à un autre.

Bref, comprendre le fonctionnement de manière détaillée du système d’information de l’entreprise.

Elle nécessite une préparation de la part de l’analyste avant l’évènement c’est-à-dire, préparer les
différentes questions à poser aux interlocutoires.

10
Pour mener à bien ce processus, il faut :

Maitriser la langue du travail

Bien préparer les questions
Bien poser les questions en évitant au maximum d’utiliser les termes techniques
Ne pas indisposer l’autre par votre accoutrement (Bien s’habiller)
Laisser l’interlocuteur parler sans l’interrompre
Toujours rappeler le but de votre visite avant de poser les questions
Promettre de repasser une fois le travail terminé

b) Observation
Toutes les informations à la compréhension du fonctionnement d’un système d’information d’une
organisation dans un but de détecter les failles ne pas souvent obtenu des questions-réponses ou
lors de l’interview car l’analyse et son interlocuteur ne voient pas les choses de la même façon ce
qui fait que l’analyse reçoit les informations de manière générale de son interlocuteur qui parfois ne
peut suffire pour une bonne étude, ainsi, la présence de l’analyse dans le travail des personnels des
différents postes dans un cadre d’observation est très utile qui favorise un bon jugement à la
confirmation de ce qui a été dit.

Cette technique est souvent plus importante dans des organisations ou entreprises dont
l’organigramme, les fiches et les manuels des procédures n’existent pas.

Grace à cette technique, il devient facile de comprendre la nature exacte du travail réalisé et les
conditions réelles du fonctionnement de l’entreprise ou en particulier le domaine étudié.

L’observation est une opération qui ne peut durer sans délai, ainsi, deux semaines au plus est
recommandé

c) Documentaire
Cette technique permet à l’analyse de comprendre la structure et le fonctionnement de l’entreprise
à l’aide des documents qu’elle peut conserver.

On peut alors se servir des archives de l’entreprise pour la récolte d’informations nécessaires. Dans
le cas où l’entreprise est ou a eu un projet d’automatisation, la documentation de dossier d’analyse
et de programmation permet de prendre connaissance de l’organisation de traitement
(organigramme des données, organigramme détaillé) et des informations (saisie, fichier, sortie).

d) Questionnaire
Cette technique permet l’obtention des informations liées à l’organisation et aux finances sur les
ressources humaines de l’entreprise.

La présence d’un spécialiste dans l’élaboration des questions qui peuvent être de type ouvert ou
fermé.

11
La formalisation de l’étude des flux, des stations qu’ils traversent et des divers documents
rencontrés peut se faire selon plusieurs méthodes :

 Diagramme de flux
 Schéma de circulation des informations
 Tableau de flux d’information

 Critique de l’existant
Cette partie de l’étude préalable consiste à effectuer une remise en question et/ou à mettre en relief
les forces ou points forts constatées sur la structure, le poste du travail, l’apport humain, le
document ou le moyen de traitement après que l’analyse de l’existant s’être bien faite.

Le point II.5 de ce cours traite en détail sur la façon d’élaborer une critique sur le système existant.

 Proposition de la solution
L’analyse de l’existant consiste à étudier le système existant, le comprendre pour détecter les failles
et les points forts dudit système qui seront dévoilés lors de la formulation de l’analyse critique.

De ce fait, il faut alors proposer une solution qui parfois peut être accompagnée des solutions
secondaires. Il ne sera pas question de la mise en œuvre mais juste de faire apparaitre les axes
fondamentaux ou le bien fait de la solution proposée en respectant les contraintes détecter.

Il est important de bien mettre en valeur les objectifs fixés et les contraintes car ils vont orienter
par la suite tout le développement de l’analyse.

b) Le cahier des charges

Le Cahier de charge est un document qui est rédigé par les deux parties, l’une de la maitrise
d’ouvrage que représente le client et de la maitrise d’œuvre représenté par le concepteur suivant un
processus de développement ou cycle de vie logiciel.

Le client présentera son problème de manière générale, après une analyse du système existant,
critique et adoption de la proposition de la solution, le concepteur rédigera alors un document
appelé Cahier de Charge. Il ne pas à confondre ce document du contrat qui reprend le coût, délai.

Plusieurs étapes sont à suivre pour bien effectuer l’analyse de l’existant entre autre :

1) Analyse de la structure et Activité de l’actuel Système

Cette analyse permet de comprendre la structure de l’entreprise, elle est réalisée à partir de
l’organigramme de l’entreprise.

L’analyste est censé en présenté dans le cas où l’entreprise n’en dispose pas, en se servant des
techniques d’interview.

Exemple des questions :

 Je fais quoi ?
 Je travaille dans quel service ou département ?
12
  Notre service dépend de quel service de l’organisation ?
Pendant cette analyse, l’analyste s’efforce de déceler les liens qui existent entre les services, entre les
agents (formel et informel), l’organisation mise en place.

Les activités de l’entreprise recensées permettront de connaitre sur la complexité et la taille de cette
dernière.

2) Analyse des documents utilisés

Les documents utilisés permettent d’avoir connaissance sur la nature d’informations étant propre à
l’entreprise relatif à son domaine d’activité, son engagement, sa localisation, sa politique, et celles
circulant dans l’entreprise en interne ou en externe envers le client.

L’analyse identifie par le moyen de chacun de ceux documents, les informations appropriées pour
ses entretiens, afin de mieux comprendre le fonctionnement de l’organisation dans le but de mettre
un système répondant aux besoins spécifiques de celle-ci.

Bref, l’étude fait l’inventaire de toutes les informations existantes archivées et circulant dans
l’entreprise en renseignant les informations suivantes :

a) Identification du Document
b) Rôle
c) Modèle
d) Description du document (N°, Nom rubrique, code rubrique, type de données, taille)
3) Analyse de poste de travail
L’analyse de poste de travail permet d’identifier chaque poste de travail entre autre :

a) Nom du poste
b) Le nom mnémonique (abréviation)
c) Tâche ou le travail réalisé
d) Moyen de traitement (Automatique, Semi-automatique ou Manuel)
e) Le nombre des personnels
f) Le volume d’information à traiter (Elevé, Moyen, Faible)
g) Observation (Très rapide, Rapide, Moyen, Lent, Très lent)
Un poste de travail peut être définit comme étant une entité exerçant une activité au sein d’un
service ou département de l’entreprise.

Les informations recueillies au cours de cette analyse faciliteront le diagnostic de l’existant pour une
proposition d’une solution adéquate.

13
Cette analyse est effectuée à l’aide d’une fiche appelée « Fiche descriptive d’analyse de poste »

FICHE DESCRIPTIVE D’ANALYSE DE POSTE

Application : Analyste :

Domaine : Date :

Coode Intitulé Nom Mném. Tâche Moyen de Nombre Volume Observ

traitement de pers.

0
1

a) Analyse de flux d’information

Le flux d’information constitue l’ensemble d’informations circulant dans les différents

départements ou service de l’entreprise et l’environnement extérieur.

Pour effectuer cette analyse, on commence à présenter une narration, ensuite le Dictionnaire de
données, suivi de l’analyse du schématique du flux d’information et enfin le schéma de circulation
des informations.

b) Narration
La narration consiste à raconter sous forme textuelle le mouvement de l’information dans la
réalisation d’un processus depuis son début jusqu’à la fin ou dès l’entrée jusqu’à l’archivage.

c) Dictionnaire de données
Dans ce dictionnaire, on renseignera les postes participant à un processus d’activité dans
l’entreprise et les différents documents produits qui seront représentées dans un tableau.
Recensement des postes Dictionnaire de données

Client BC : Bon de commande

d) Analyse schématique de flux d’information

L’analyse de flux d’informations présente schématiquement la narration à travers le (la) :
Diagramme de flux d’information

14
C’est un graphe orienté généralement avec cycle dont le poste de travail représente le sommet et le
document et son mouvement l’arc. Ce diagramme est accompagné d’une légende expliquant les
arcs.

1. Validation de la fiche pour l’élaboration de l’attestation de naissance.

 La matrice de flux d’information

Cette matrice représente à partir d’un tableau ayant la forme de celui de Proximité contenant une
mesure de ressemble et/ou de dissemblance entre les éléments pris deux à deux. L’élément ici est
le poste de travail et la mesure n’est rien d’autre que la relation existant entre deux postes prise
deux à deux.

Ce diagramme explique de manière claire les relations qui existent entre les différents postes de
travail et à la diagonale de cette matrice, il n’y a rien.

Poste 1 Poste 2 Poste n

Poste 1 - Relation Relation

Poste 2 Relation - Relation

Poste 3 Relation Relation -

 Tableau de flux d’informations

Le tableau d’analyse quant à lui, permet de recenser les différents documents traités au niveau de
l’analyse de l’existant en mettant en évidence leur type, leur système de codification (nom), leur
désignation en claire, leur origine et la destination.

15
N° Nom Code Information Origine Destination Observation

0
Facture FAC Qté, PU Caisse Client Lent
1

Dans le cas d’un système déjà informatisé, on parlera alors de l’étude des documents et fichiers :

 Le support, le contenu, les modalités de mise à jour

 La fréquence d’utilisation, le taux d’activité, le volume

5) Analyse des moyens de traitement

Les moyens de traitement tiennent compte des plusieurs aspects :

 Matériels
 Humains
 Financiers

a) Moyens Matériels
L’analyse de moyen matériel permet d’identifier les outils au sein de l’entreprise dans le traitement
des informations.

Cette analyse est fonction d’une fiche appelée « Fiche d’analyse des Moyens »

FICHE D’ANALYSE DES MOYENS MATERIELS

Projet : ………………………………….
Analyste : ………………………….…
Date : ………………………………………
N° Matériel Quantité Date d’acquisition Date d’amortissement Etat

Dans le cas d’une entreprise déjà automatisée, en dehors de ces informations, il est nécessaire de
connaitre :

 Le moyen de communication
 Le système d’exploitation utilisé
 Le type de réseau informatique s’il y a en

16
 b) Moyens Humains
L’analyse de moyen humain permet à l’analyste de d’avoir une aperçue générale sur le personnel
c’est-à-dire leur niveau d’étude, assiduité au travail, leur performance, leur capacité à comprendre
les nouvelles choses, l’expérience par rapport à l’ancienneté.
Cette analyse est fonction d’une fiche appelée « Fiche d’analyse des moyens humains ».

FICHE D’ANALYSE DE MOYENS HUMAINS

Projet : ……………………………
Analyste : ………………………
Date : ………………………………
N° Poste Niveau Ancienneté Observation

01

c) Moyens Financiers
L’analyse des moyens financiers permet à l’analyste de se mettre au courant sur la faisabilité du
projet par rapport au coût.

II.5. Diagnostic ou Bilan de l’existant

Lors de ce processus, l’analyste a le devoir de recenser les problèmes de l’utilisateur dans le souci de
déterminer les vraies causes afin d’apporter une bonne solution à proposer.

Cette critique doit être réaliste et pragmatique en mettant en évidence les points forts et faibles
pour que la solution soit orientée en fonction de cette faiblesse et retenant les points forts.
L’élaboration du diagnostic suit la démarche suivante :
 Recensement des problèmes
 Analyse des causes
 Elaboration de la solution

1) Recensement des problèmes

L’analyste doit identifier avec certitude les problèmes après une explication ou avoir entendu les
plaintes du client ou observer le fonctionnement de l’entreprise en générale ou d’un domaine en
particulier.

17
CHAPITRE III. MODELISATION D’UN SYSTEME D’INFORMATION

III.1. Introduction

Il est difficile de modéliser un domaine sous une forme directement utilisable par un SGBD. Une
ou plusieurs modélisations intermédiaires sont donc utiles, le modèle entités-associations constitue
l’une des premières et des plus courantes. Ce modèle, présenté par Chen (1976), permet une
description naturelle du monde réel à partir des concepts d’entité et d’association.
Un modèle est une représentation simplifiée d’une réalité traduisant au mieux cette réalité.
Pour bien faire recours à l’ordinateur dans un but d’automatisation, il est préférable de partir d’un
modèle représentant les objets du monde réel.

III.2. Principe d’organisation des informations en informatique

L’organisation des informations en informatique est la manière de gérer les données produites à
partir d’un traitement.

Il existe deux façons de faire approches :

 Fichier
 Base de données
L’organisation par Fichier est un moyen de gérer les données dans une organisation qui soient
généralement homogène malgré le volume. Le ficher ne garantit pas la structure et accepte les
redondances. Par contre, lors que les données sont de nature diverse ou hétérogène et possèdent
de nombreux liens entre elles, et que la structure est obligatoire ou importante, la sécurité de
données garantissant leurs disponibilités et leurs intégrités, alors, on fera appel à l’approche Base de
données.

Le Fichier tout comme les Base de données utilisent un Système appelé « Système de Gestion » qui
est un logiciel permettant la facilité de gérer les données. Pour le Fichier, c’est le Système de
Gestion de Fichier (SGF) et Le Système de Gestion de Base de données (SGBD) est utilisé pour la
gestion d’une base de données.

Tout système d’exploitation contient un système de Gestion des Fichiers (SGF) spécifique.
Toutefois, pour les applications d’applications personnalisées, on utilise des logiciels tels que :

DBase
Filemaker
L’implantation physique d’une base de données même sur des mémoires secondaires se fait via la
notion de fichier et cela en fonction du SGBD qui reste invisible à l’utilisateur.

Une base de données par contre présente des avantages que le SGF ne dispose pas tels que :

18
 La non redondance
La structure
L’exhaustivité
Indépendance
Confidentialité
Accès interactif
L’utilisation du fichier ne garantit pas :

La sécurité
Le contrôle de concurrence
La rapidité dans l’accès aux données
Les bases de données sont des solutions les meilleures qu’elles soient pour organiser et gérer les
données.

Plusieurs modèles des bases de données existent entre autre :

Hiérarchique
Réseau
Relationnel
Objet
La famille NoSql (Non relationnel)

III.3. Différentes méthodes d’analyse informatique

En Informatique, plusieurs méthodes d’analyses et de conceptions sont utilisées :

 CLASSIQUE
 MERISE
 RACINE
 NIAM
 FLORY
 IMS
 UML : qui ne pas vraiment une méthode compte tenu de l’aspect programmation. On parle
d’UML comme un langage de modélisation
Dans la suite, nous allons nous servir de MERISE et UML comme méthode de modélisation.

III.4. La Méthode MERISE

1. Présentation
MERISE une méthode de développement des projets informatiques de gestion. Elle tire son nom
du MERISIER qui est un arbre porte-greffe. De façon Analogue, MERISE est le résultat de la
greffe de plusieurs méthodes. Une deuxième explication vient du fait que le mot MERISE se
trouvait en haut à gauche d'un dictionnaire ouvert à la lettre M. Elle s'adresse à toutes les
applications sur micro, mini-ordinateur ou grands systèmes informatiques. Par commodité,

19
l'organisme à informatiser sur lequel s'applique la méthode est appelé ici entreprise. Merise est
actuellement la n méthode la plus répandue en France. Historiquement, la première version
officielle de Merise date des travaux coordonnés par le Ministère de l’industrie en 1979 ; le groupe
de projet comprenait, outre une équipe de recherche dirigée par M. H. TARDIEU, plusieurs
sociétés de service. Depuis, plusieurs versions ont été développées. Voici venu le temps des
MERISES. L'ouvrage de référence de la méthode est celui de MM H. TARDIEU, ROCHFELD et
COLETTI4.
Reconnu comme standard, Merise devient un outil de communication. En effet, Merise réussit le
compromis difficile entre le souci d’une modélisation précise et formelle, et la capacité d’offrir un
outil et un moyen de communication accessible aux non-informaticiens. Un des concepts clés de la
méthode Merise est la séparation des données et des traitements.
Cette méthode est donc parfaitement adaptée à la modélisation des problèmes abordés d’un point
de vue fonctionnel. Les données représentent la statique du système d’information et les
traitements sa dynamique.

2. Définition
MERISE signifie Méthode d’Étude et de Réalisation Informatique pour les Systèmes d’Entreprise.
C’est certainement le langage de spécification le plus répandu dans la communauté de
l’informatique des systèmes d’information, et plus particulièrement dans le domaine des bases de
données. Une représentation Merise permet de valider des choix par rapport aux objectifs, de
quantifier les solutions retenues, de mettre en œuvre des techniques d’optimisation et enfin de
guider jusqu’à l’implémentation.

3. Organisation par Niveau

MERISE est une méthode d’analyse, elle analyse le système pour dégager des modèles. Elle
préconise une démarche en étape et fait appel à des modèles pour présenter les objets qui
composent le système d’information, les relations existant entre ces objets ainsi que les règles de
gestion.

Elle présente une description du système d’information par niveaux :

a. Niveau Conceptuel

Le niveau conceptuel représente les contenues de la base en terme conceptuel, indépendant de

toute considération informatique c’est-à-dire au niveau conceptuel, on conçoit le Système
d’Information en faisant abstraction de toutes les contraintes techniques ou organisationnelles et

4
MICHEL DIVINE, Parlez-vous MERISE, Ed 2008, p.2
20
cela tant au niveau des données que des traitements. Il correspond à la description des finalités de
l’entreprise en expliquant sa raison d’être et traduit les objectifs et les contraintes qui pèsent sur
elle.

C’est à ce niveau que l’on découvre ce qu’il faut faire en répondant à la question « QUOI ? » (Le
quoi faire, avec quelles données) ; on fait le choix sur la gestion.

Ce niveau implique :
 Modèle conceptuel de données (MCD)
 Modèle conceptuel de Traitement (MCT)

b. Niveau Organisationnel

Ce niveau permet de définir l’organisation qu’il est souhaitable de mettre en place dans
l’entreprise, pour atteindre les objectifs visés. Il précise les postes de travail, la chronologie des
opérations, les choix d’automatisation, l’accès aux bases de données tout en intégrant les
contraintes éventuelles.

A ce niveau, on envisage le partage des tâches, la répartition géographique des traitements et

l’organisation des données. Les questions que l’on se posera du point de vue des traitements sont :
« QUI ? », « Où ? » et « QUAND ? » ; on fait le choix sur l’organisation.

Ce niveau se traduit en terme de :

 Modèle organisationnel de données (MOD)
 Modèle organisationnel de Traitement (MOT)

c. Niveau Logique

Ce niveau permet de décrire les outils à utiliser pour la mise en place du système. Il
envisage aussi la répartition géographique des traitements et des données comme au niveau
organisationnel mais cette fois-ci en déterminant l’unité de stockage.

Il est indépendant du matériel informatique, des langages de programmation ou de gestion des

données. C’est la réponse à la question « AVEC QUOI ? » ou « AVEC QUEL OUTIL ? » ; on fait
le choix sur le logiciel.
Il y a :
 Modèle logique de données (MLD)
 Modèle logique de Traitement (MLT)

d. Niveau Physique

Le niveau physique permet de définir l’organisation réelle physique des données. Il apporte les
solutions techniques en faisant le choix matériel ou technique pour le système d’information.

On répond à la question « COMMENT ? » et se traduit par :

 Modèle physique de données (MPD)

21
  Modèle opérationnel ou physique de Traitement (MOPT)

3.2. Le Niveau Conceptuel

L'objectif est de représenter l'activité de l'entreprise et de formaliser son "système
d'information" indépendamment de son organisation. Le compte rendu de cette étude est
matérialisé sous la forme de dessins normalisés, de modèles complétés par un dossier
explicatif. Le but de ce chapitre est d'expliquer comment décrire l'entreprise concernée en
respectant les normes de chaque modèle.

Le modèle de communication formalise les échanges d'informations entre systèmes

fonctionnels et identifie les systèmes "à mémoire". Le modèle de traitement formalise, comme son
nom l'indique, les traitements effectués par un système fonctionnel, comment l'entreprise
réagit à une réception d'informations, ou quand, spontanément, elle décide d'émettre des
informations.

Le modèle de données est la référence de l'activité de l'entreprise, la manière dont elle perçoit et
mémorise son activité. Il formalise toutes les informations mémorisées. Ces informations
sont structurées, regroupées en ensembles appelés individus et en ensembles appelés relations
entre les individus : les rectangles et les ellipses de MERISE qui vous seront bientôt familiers.

3.2.1. Modèle Conceptuel de Communication (MCC)

Représente, au niveau conceptuel, les échanges d’information entre les acteurs

La première étape d’une étude de l’existant, pour modéliser les habitudes de travail dans
l’organisation concernée, consiste à :

 Délimiter le domaine étudié

 Réduire la complexité en identifiant des sous problèmes traités individuellement
 Identifier les acteurs externes et internes
 Modéliser les échanges d’informations entre les différents acteurs

3.2.1.1. Acteur
Il est représenté par un cercle et libellé par le nom de l’acteur. L’acteur représente une unité active
intervenant dans le fonctionnement d’un système opérant. Il peut être stimulé par des flux
d’information, transformer et émettre des flux d’information.

22
Un acteur « fait quelque chose » et est actif. Un acteur est un rôle plutôt qu’une personne physique.
Il peut être pertinent de modéliser séparément deux fonctions assumées par une même personne
physique

On distingue les acteurs internes et externes :

Acteurs internes sont ceux faisant partie du système d’information étudié (Ex : guichet,
caisse, facturation,...). Si le système est complexe, on peut considérer un acteur interne comme un
sous domaine et détailler ce sous-domaine dans un nouveau MCC.

Acteurs externes sont éléments externes avec lesquels le système échange des flux
d’information. Ex : clients, fournisseurs...

3.2.1.2. Flux d’information

Il est échange d’informations entre deux acteurs (émetteur et récepteur) dont l’un est au moins
interne. Ce flux est représenté par une flèche entre deux acteurs, étiquetée par le nom du flux.

Le flux peuvent être physique, (bien, marchandise, etc.), monétaires (espèces, chèque, traite, etc.)
ou d’information. Un flux physique ou monétaire s’accompagne toujours d’un flux d’information
et le support d’information peut être la voix (information orale), le papier (information
documentaire) ou numérique (Information informatique).
Ex : documents, appels téléphoniques, données informatiques

23
3.2.2. Modèle Conceptuel des Traitements MCT

La modélisation des traitements pour but de faire la représentation dynamique du système

d’information, c'est-à-dire de représenter l’enchaînement des traitements réalisés.

Cette modélisation s’effectue à deux niveaux :

Le niveau conceptuel où l’on s’intéresse aux opérations en dehors de toute mise en
œuvre organisationnelle.
Le niveau organisationnel, où se pose les questions du qui, où, quand.

L’objectif du MCT est de répondre à la question QUOI faire par rapport à un événement. C’est la
chronologie qui importe. Autrement dit, le MCT est une représentation de la succession des règles
de gestion dont l’entreprise veut se doter pour répondre aux événements auxquels elle doit faire
face, du fait de son activité et de son environnement.

3.2.2.1. Composition du MCT

a) L’événement

C’est une sollicitation du système d’information qui génère une réaction de la part de celui-ci.

Un événement peut être externe au domaine étudié (ex: commande client) ou interne au SI,
souvent le résultat d’un processus antérieur (ex : ordre de préparation). Un événement peut-être
aussi temporel, c'est-à-dire lié à des dates qui rythment l’exécution de certains traitements (délai de
maintenance, relances).
b) L’opération

C’est un ensemble d’actions accomplies par le système d’information en réaction à un événement

ou à une conjonction d’événements et non interruptibles par un événement externe.
Remarque : Une opération déclenche au moins un résultat. Une opération est représentée
par un verbe ou mieux un substantif (ex : Préparer la commande ou préparation de la
commande)

24
 c) Le résultat

Un résultat peut-être un document, un message externe, un nouvel état du SI (nouvelle situation,

nouvelles données), créé par une opération, qui peut lui-même jouer le rôle d’événement.
Un résultat externe représente une information envoyée à l’extérieur du SI (ex : facture)
Un résultat interne est un nouvel état du système d’information (ex: ordre de préparation)

d) La synchronisation

C’est une condition booléenne (ET / OU) traduisant les règles de gestion que doivent respecter les
événements pour déclencher une opération. Dans le cas ET, elle marque qu'un événement déjà là
doit en attendre un ou plusieurs autres.

Remarque : Pour qu'il soit question de synchronisation, il faut la présence de plusieurs événements
déclencheurs; aussi, le symbole de synchronisation est laissé à blanc dans le cas d'un événement
unique. Si tous les événements entrants sont liés par le même opérateur, on peut seulement faire
figurer l'opérateur dans le symbole de synchronisation sinon il faut numéroter les événements (a, b,
c …) et constituer l'expression à l'aide des événements et des opérateurs. (Ex : (a ET b) OU c).
e) Règle d'émission

Condition, traduisant les règles de gestion, qui permet d'exprimer des conditions de sortie des
résultats.
Remarques : L'expression d'une règle d'émission peut être composée de plusieurs conditions
élémentaires reliées par les opérateurs ET, OU. On peut également utiliser l'opérateur NON pour
exprimer la négation d'une condition.

f) Rôle des règles de gestion

Recensées lors de l'étude de l'existant ou définies pour le futur SI, elles décrivent les
enchaînements d'opérations. Elles rendent possible le regroupement des actions au sein d'une
seule opération non interruptible au niveau conceptuel.

g) Le processus

C’est un enchaînement synchronisé d'opérations au sein d'un même domaine, généralement

déclenché par un événement externe (externe au domaine ou au SI tout entier).
En résumé nous dirons qu’un MCT est la représentation de l’enchaînement des opérations d’un
processus.

3.2.2.2. Elaboration du MCT

Représente formellement les activités exercées par le domaine (à la base de la

connaissance du SI). Il repose sur la prise en compte des échanges (flux) du domaine avec
son environnement et s’effectue en faisant abstraction de l’organisation et des choix
technologiques.

25
La définition des interactions du domaine avec son environnement prime sur la manière dont
on assurera ces activités.

De ce qui précède, nous disons que le MCT est un « zoom » sur le MCC. Dans
les MCC, on représente les messages échangés entre acteurs tandis que dans les MCT, on
représente comment un acteur de l’organisation réagit quand il reçoit ce message et quelle
opération il effectue.

3.2.2.3. Modèle d’un MCT

3.2.3. Modèle Conceptuel de données (MCD)

Quand nous construisons directement les tables d’une base de données dans un SGBD, nous
sommes exposés à deux types de problèmes :
a. nous ne savons pas toujours dans quelle table placer certaines colonnes ;
b. nous avons du mal à prévoir les tables de jonction intermédiaires.
Il est donc nécessaire de recourir à une étape préliminaire de conception.

26
3.2.3.1. Notions
Le Modèle Conceptuel des Données (MCD) a pour but de représenter de façon structurée les
données qui seront utilisées par le système d'information. Il décrit la sémantique c’est-à-dire le sens
attaché à ces données et à leurs rapports et non à l’utilisation qui peut en être faite.

On établit le MCD après avoir recensé et donné un nom à l’ensemble des données du domaine
étudié. Ensuite on étudie les relations existantes entre ces données (les dépendances
fonctionnelles), pour aboutir au MCD

Quand on analyse les données sur un objet (abstrait ou concret) du réel, il est nécessaire de faire le
tri entre ce qui est nécessaire pour le système d’information et ce qui ne l’est pas.
Exemple d’un étudiant : je prends les infos sur son identité, sa santé, ses préférences.
3.2.3.2. Composition du MCD
1. Entité
Une Entité représente un objet du Système d’Information (acteur, document, concept, …), ou plus
exactement un ensemble d’objets ayant les mêmes caractéristiques (sens).

En d’autres termes, une Entité est une population d’individus homogènes (qui est de même
nature). Par exemple, tous les étudiants d’une université peuvent former une même Entité (entité
Etudiant) et tous les cours dispensés forment également une autre Entité (entité Cours). Et
mêmement pours les Enseignants (Enseignants). Car, dans le cas d’étudiants, nous savons que d’un
étudiant à l’autre, les informations ne changement pas. Chaque étudiant a un nom, un post nom, un
sexe, un adresse, …. Et chaque cours a un intitulé, un volume horaire, une pondération et un
maximum. L’étudiant et le cours ne peuvent pas se regrouper car, un étudiant n’a pas de
pondération et un cours n’a pas d’adresse.

Enseignant
Etudiant Cours

Dans une Entité, on met les informations nécessaires et suffisantes pour caractériser cette entité.
Ces informations sont appelées Propriétés ou Attributs. Les propriétés (Attributs) sont collectées
lors de l’établissement du dictionnaire des données. Les propriétés prennent des valeurs pour
chaque occurrence d’une entité.

27
 Notons à cet effet que :

a. un Attribut est une propriété particulière d’une Entité ou une information élémentaire qui
permet de décrire une Entité.

Cours Enseignants
Etudiants
Nom Intitulé Nom
Vol horaire Grade
Post nom
Adresse Adresse
Sexe
Age
Adresse

b. Une Occurrence est un exemplaire, un objet, un élément particulier de la famille

représentée par l’entité. Les propriétés d’une entité prennent des valeurs pour chaque occurrence.
Chaque occurrence d’entité est identifiée de manière unique par un identifiant, qui est une
propriété particulière telle que 2 occurrences de l’entité ne peuvent pas avoir la même valeur pour
cette propriété.

On représente souvent les occurrences d’une entité sous forme d’un tableau. Les lignes
correspondent aux occurrences, et les colonnes correspondent aux propriétés.

Dans notre cas, l’Entité Etudiant peut avoir à titre d’exemple les occurrences ou objets suivants :

Nom Post nom Sexe Age Adresse

Kage Mujinga F 24 11, av. Public, Kinshasa
Kulunsi Fumutoto M 23 62, av. état, Kinshasa
Kumure Eddy M 18 5, av. école, Kinshasa
Kumure Eddy M 25 5, av. école, Kinshasa
Masamba Christelle F 19 12, av. Sainte, Kinshasa
Muteba Naweji M 19 37, av. Polis, Kinshasa
Ndunga Live F 20 10, av. Vanga, Kinshasa
Ngandu Nathalie F 21 6, av. Kit, Kinshasa
Sefu Kenu M 22 37, av. Polis, Kinshasa

En regardant attentivement ces occurrences, nous remarquons qu’un attribut d’une Entité peut
être porté par plusieurs occurrences (objets) de cette Entité. D’où, risque fréquent de confusion
entre occurrence (on parle d’incohérence). Tel est le cas des occurrences Kumure qui portent le
même Nom, Postnom et Sexe. Pour pallier à ce problème, il est indispensable d’utiliser un
attribut sans doublon c’est-à-dire ne prenant à la fois deux valeurs dans une même entité. Cet
attribut unique est appelé identifiant.

28
 2. Identifiant
Un Identifiant est un attribut ou propriété particulière, qui permet de distinguer sans ambiguïté
toutes les occurrences de l’entité. Il est toujours souligné et ne peut changer aussi longtemps que
son occurrence existe. Ainsi nous pourrons avoirs pour notre exemple (fig.9), les entités, les
attributs et les identifiants suivants :

Etudiant Cours Enseignant

Codecours
Matricule matricule
Nom Intitulé Nom
Postnom Vol horaire Postnom
Sexe Pondération Grade
Age Maximum Spécialité
Adresse Adresse

3. Association
C’est un lien entre deux entités (ou plus). Il a un nom, souvent un verbe, qui caractérise le type de
relation entre les entités. Une association possède parfois des Attributs. En d’autres termes, une
association est liaison qui a une
Signification précise entre plusieurs Entités.

Cours
Suivre Code_cours Dispenser
Intitulé
Vol_horaire
Pondération
Maximum

Etudiant Enseignant
Matricule matricule
Nom Nom
Postnom Postnom
Sexe Grade
Age Spécialité
Adresse Adresse

En observant ce schéma, nous remarquons que l’entité Etudiant n’est pas en relation directe avec
l’entité Enseignant, mais elles sont en relation indirecte à travers l’entité Cours. C’est normal.
4. Cardinalités
Ce sont des expressions qui permettent d’indiquer combien de fois au minimum et au maximum le
lien entre 2 entités peut se produire.
En d’autres termes, les cardinalités d’une Entité dans une association expriment le nombre de fois
qu’une occurrence de cette Entité est impliquée dans l’association, au minimum et au maximum.

29
Pour une association de 2 entités, il y a 4 cardinalités à indiquer. Il y a trois valeurs typiques : 0, 1
et N (plusieurs). Les cardinalités traduisent des règles de gestion. Ce sont des règles propres au SI
étudié, qui expriment des contraintes sur le modèle.

Entité Min, Max

Association

a. La cardinalité minimale

Elle est exprimée presque toujours par l’une des deux valeurs 0 ou 1. Elle traduit combien de fois
au minimum une occurrence de l’entité participe à l’association.
Exemples : Pour la cardinalité minimum entre client et commander il faut se poser la question :

Pour un client donné, combien de fois au minimum il commande ?

Si la réponse est « tout client doit passer au moins une commande sinon ce n’est pas un client » on
met la cardinalité
mini à 1.

Client 1 Produit
Commande
Qté

Mais on peut très bien imaginer que l’entreprise veut aussi mémoriser les clients potentiels
(prospects), qui n’ont encore rien commandé. Dans ce cas, un client peut très bien ne pas avoir
encore commandé, et on met la cardinalité mini à 0.

Client 0 Produit
Commande
Qté

b. La cardinalité maximale

Elle traduit combien de fois au maximum l’entité peut être en relation avec l’association. Cela peut
être plusieurs fois (si c’est un nombre indéterminé, on indique la valeur n) ou une seule fois. On
répond à la question : Combien au maximum l’entité peut participer à l’association ? Si la réponse

30
est « au plus une fois », la cardinalité maximale prend pour valeur 1. Si la réponse est « plusieurs »,
la cardinalité maximale prend la valeur N.
Exemple : Un salarié est affecté au plus à un seul service ;
Dans un service sont affectés plusieurs salariés.

Salarié 1 n Service
Est affecté

Il peut arriver rarement qu’une cardinalité maximale ait une valeur limitée.
Exemple : Un élève doit suivre au minimum une option et au maximum 3 options.

Elève 1 ,3 1,n Option

Suivre

A titre récapitulatif, nous prenons un exemple et commentons les cardinalités.

c. Exemple illustratif

Fournisseur

IdFournisseur 1,n Livrer

Nom
QtéLiv
Prenom DateLiv
NumPhone NomLivreur
Adresse

1,n
Client Article
1,n Commander 0,n
NumClient QtéCom CodeArticle
Nom DateCom Libellé
Prenom PrixUnitaire
Adresse

En observant ce schéma (nous signalons que logiquement il n’est pas correcte et nous allons le
corrigé plus tard quand parlerons de la normalisation à la page 33), nous pouvons emmètre les
commentaires ci – après :

31
  Un client commande au moins un article et un article peut être commandé plusieurs fois
(n) tandis qu’un article peut être commandé 0 fois ou plusieurs fois (n (n ici différent du
premier n)) ;
 Une cardinalité minimale 1 se justifie par le fait que les occurrences de ladite entité ont
besoin de l’association pour exister. Comme pour notre schéma, un client n’existe pas
avant d’avoir commandé quoi que ce soit, c’est pourquoi le cardinalité de l’entité Client
dans l’association Commander est 1 ;
N.B : pour établir correctement les cardinalités d’une association, il faut poser des questions et
surtout dans le bon sens autour de cette association. Par exemple pour notre schéma, nous
posons deux types de question. Du coté Client et du coté Article pour l’association
Commander et du coté Article et du coté Fournisseur pour l’association Livrer :
- Association Commander :
• Du coté Client : Un client peut commander combien d’articles ? et la réponse est
« Un ou plusieurs articles » ;
• Du coté Article : Un article peut être commandé par combien de clients ? et la
réponse est « 0 ou plusieurs clients ».
- Association Livrer :
• Du coté Fournisseur : Un fournisseur livre combien d’articles ? et la réponse est
« Un ou plusieurs articles » ;
• Du coté Article : Un article est livré par combien de fournisseur ? et la réponse
est « Un ou plusieurs fournisseurs »

Parce que nous savons déjà comment établir les cardinalités, revenons un peu sur les
associations et voyons quelles sont les types d’associations que l’on peut trouver.
5. Types d’associations
1) Association plurielle
On parle de l’association plurielle lorsque deux entités sont plusieurs fois en relation entre elle.

Posséder

Personne 0,n 1,1

Logement
CodePers 1 ,n Résider 1,n NumLog
Nom DateEnter
AdresseLog
Prenom
1,n
Adresse 1, 1

Louer

Dans cet exemple (cas d’une agence immobilier), une personne peut posséder, résider ou louer un
logement géré par une agence. Les logements qui ne sont pas géré par l’agence ne sont pas dans

32
l’entité Logement. Et nous supposons qu’un Logement est détenu par une seule personne dont les
propriétés figurent dans l’entité Personne.

2) Association réflexive
Une association réflexive est une association qui permet à une entité d’être plusieurs fois en
relation avec elle – même.
Dans cet exemple, tout employé est
Employés 0 ,1 dirigé par un autre employé (sauf le
Diriger Directeur Général) et un employé peut
NumMat
Nom DateDebut diriger plusieurs autres employés.
Prenom 0,n
Adresse

3) Association ternaire

Une association ternaire est une association qui relie trois entités au même moment. Ce genre
d’association est obtenu après normalisation. C’est-à-dire, lorsqu’autour d’une entité, toutes les
associations ont pour cardinalité maximale 1 au centre et n à l’extérieur, cette entité doit être
remplacée par une entité branchée à toutes les entités voisines avec des cardinalités identiques 0,n.
Horaire

Codehoraire
Date
HeureDebut

0,n

Avoir lieu
pendant

1,1
Film
Salle 0,n Projection 1,1 0,n
Avoir lieu 1,1 Concerner NumFilm
NumSalle dans NumProj Titre
Capacité Tarif Durée

A l’issu de cet exemple d’un cinéma, nous remarquons que l’entité Projection est uniquement
entourée d’associations dont les cardinalités maximales sont 1 du côté projection et n de l’autre
côté. En plus, une donnée d’un Horaire, d’un film et d’une salle suffit déjà pour déterminer une
projection unique. L’attribut Date dans l’entité Horaire en est l’élément déterminant.

A cet effet, on peut remplacer l’entité Projection par une association Projeter branchée aux trois
entités Horaire, Salle et Film on obtient ainsi une association dite ternaire.

33
 Horaire

Codehoraire
Date
HeureDebut

0,n
Film
Salle 0,n 0,n
Projeter NumFilm
NumSalle NumProj Titre
Capacité Tarif Durée

La difficulté de concevoir une ou plusieurs associations ternaires directement est d’établir les
bonnes cardinalités. Il est donc conseiller d’en passer par un schéma entité – association dans
lequel on ne trouve que des associations binaires, puis de repérer les entités remplaçables par des
associations, comme nous l’avons fait à la figure n°19.

Cette règle de conduite permet d’éviter d’introduire une association

ternaire abusive comme dans l’exemple suivant :

Vol

CodeVol
Destination
HeureDep
heureArr

0,n

Avoir lieu
pendant

1, 1
Avion
Pilote 0,n Depart 1,1 0,n
Assurer 1,n Utiliser NumAvion
MatriPilote NumDep Modele
Nom Date Propriete
Grade heurDepEf AnneeFab

Nous remarquons dans cet exemple qu’une cardinalité (1, n) de l’entité Départ ne permet pas de la
remplacer par une association ternaire.

Par ailleurs, une association peut être branchée à plus de 3 entités, on parle de l’Association
Quaternaire (4-aire). Dans ce cas, il est absolument important de s’assurer de la légitimité de cette
association dite 4-aire, en vérifiant les cardinalités dans un schéma intermédiaire faisant apparaitre à
la place de ladite association, une entité branchant 4 associations.

34
 Semaine
NumSem
DateDebut

0,n
Jour 0,n 0,n Horaire
Occuper
NumJour NumHor
Motif
Libelle heureDebut

0,n

Salle
CodeSalle
Nom
Capacite

3.2.3.3. Règle de normalisation

Un bon schéma entité – association doit répondre aux règles de normalisation suivantes :
1. Normalisation des entités

Toutes les entités qui sont remplaçable par une association doivent être remplacées (comme nous
l’avons fait aux figures n°19 et 20)
2. Normalisation des noms

Le nom d’une entité, d’une association ou d’un attribut doit être unique. Ainsi, il est
préférable :
- Pour les entités, d’utiliser un nom commun au pluriel (Ex. Etudiants)
- Pour les associations, d’utiliser un verbe à l’infinitif (Ex. Effectuer) éventuellement à la
forme passif (Ex. Etre commandé) ou encore accompagné d’un adverbe (Ex. Avoir lieu
dans, pendant, à) ;
- Pour les attributs, d’utiliser un nom commun au singulier (Ex. nom, numéro, désignation)
éventuellement accompagné du nom de l’entité ou de l’association dans laquelle il se trouve
(Ex. nom de client, numéro d’article).
- Lorsque les mêmes noms reviennent plusieurs fois dans 2 entités, de fusionner les 2 entités.
Exemple :

35
 Professeurs Assistants Enseignants

CodeProf CodeAss CodeEns

Nom Prof NomAss Fusion NomEns
Postnom Prof PostnomAss PostnomEns
Adresse Prof AdresseAss TitreEns
AdresseEns

- Lorsque 2 attributs d’entités contiennent les mêmes informations, il faut carrément

supprimer l’un dans une entité. Car il s’agit là d’une redondance qui peut entrainer une
incohérence.
Exemple :

Clients 1,n 1,1 Commandes

Passer
NumClient NumCom
DateCom
NomClient
AdresseLiv
adresseLiv

Clients 1,n 1,1 Commandes

Passer
NumClient NumCom
DateCom
NomClient
AdresseLiv

3. Normalisation des identifiants :

Chaque entité doit posséder un identifiant. En ce qui concerne celui – ci, il est important de :
- Eviter des identifiants composés de noms d’attributs (Ex. nom et postnom), car d’une part
c’est mauvais pour la performance et d’autres part, l’unicité supposée par une telle
démarche fini tôt ou tard par être démentie ;
- Préférer un identifiant court question de rendre la recherche la plus rapide possible. Eviter
à cet effet des chaînes de caractères comme des numéros de plaques d’immatriculation, de
téléphone, de sécurité sociale ou de code postal. Car ceux – ci sont bel et bien des chaîne
de caractères, même si elles ne comportent que des chiffres, elles peuvent commencer par
0. Ce qui n’est pas possible en informatique avec un entier. Ainsi dans un schéma entité –
association, il est préférable d’utiliser les identifiants entier et éventuellement
automatiquement incrémentés ;
- Eviter également les identifiants susceptibles de changer au cours du temps.

36
 4. Normalisation des attributs :

Remplacer les attributs en plusieurs exemplaires en une association supplémentaire de cardinalité

maximale n et ne pas ajouter d’attributs calculables à partir d’autres attributs.

En effet, d’une part les attributs en plusieurs exemplaires posent problème d’évolutivité du modèle
(Ex.: cas d’une personne ayant plus d’une adresse et d’un numéro de téléphone) et d’autre part, les
attributs calculables induisent un risque d’incohérence entres les valeurs des attributs de base et les
attributs calculés.
On évitera aussi les attributs calculables classiques comme l’âge
qui est calculable à partir de la date de naissance.

Employés
1,n Occuper
Employés Num-employé type
num-employé Nom
Nom Normalisation 1,n 1,n
Adresse principale Adresses
Adresse secondaire
Num-telephone-portable Posséder Num-adresse
Num-telephone-domicil Libellé
1,n

Num-telephone

Code-numtelep
Numero-telephone
Type-num-telephone

Articles 0,n 1,n Commandes

Figurer
NumArticle quantite NumCom
DateCom
Designation
Montant-total
Prix-unitaire

5. Normalisation des attributs des associations

Les attributs d’associations doivent dépendre directement des identifiants de toutes les entités en
association.

Par exemple, la ‘‘quantité commandée’’ dépend à la fois du ‘‘numéro Client’’ et du ‘‘numéro article’’ par
contre, la ‘‘date commande’’ non. Il faut donc faire une entité ‘‘Commandes’’ à part et la même chose
pour ‘‘Livraisons’’.

37
L’inconvénient de cette règle de normalisation et qu’elle est difficile à appliquer pour les
associations qui ne possèdent pas d’attributs. Pour vérifier malgré tout qu’une association sans
attribut est bien normaliser, on peut donner temporairement à cette association un attribut
imaginaire (mais pertinent) qui permet de vérifier la règle.

Par exemple, entre les entités ‘‘ Livres’’ et ‘‘ auteur ‘’, l’association ‘‘ Ecrire ‘’ ne possède pas
d’attribut. Imaginons que nous ajoutions un attribut ‘‘pourcentage’’ qui contient le pourcentage du
livre écrit par chaque auteur (de même livre). Comme cet article pourcentage dépend à la fois du
numéro de livre et du numéro d’auteur, l’association écrire est bien normalisée.
Article
Livraisons
1,n Contenir 1,n
CodeArticle
QteLivre NumLivraison
Libellé
DateLivraison
PrixUnitaire
1,n
0,n
Client
Effectuer
NumClient Concerner NomLivreur
Nom QteCom
Prenom 1,n
Adresse 1,n Fournisseur
1,n Commandes IdFournisseur
1,n Nom
Passer Numcommande
Prenom
Datecommande
NumPhone
Adresse

Autre conséquence de la normalisation des attributs des associations est que, une entité avec une
cardinalité de 1,1 ou 0,1 aspire les attributs de l’association comme dans la figure suivante, l’attribut
‘’Nomlivreur’’ doit passer à l’entité ‘’Livraisons’’.

Livraisons
Fournisseurs 1,n Effectuer
1,1
IdFournisseur NumLivraison
Nomlivreur DateLivraison
Nom
Prenom
NumPhone
Adresse

6. Normalisation des associations

Il faut supprimer les associations Fantômes, Redondante ou en plusieurs exemplaires.

38
 Fournisseurs Fournisseurs
1,1
IdFournisseur IdFournisseur
Nom Posséder Nom
Normalisation
Prenom Prenom
Adresse 1,1 Adresse
Contacts NomContact
Numtelephone
NumContact
NomContact
Numtelephone

1,1 Reglements
Payer
Fournisseurs 0,n
NumReglement 1,1
DateReglement
IdFournisseur Montant
Nom
Correspondre
Prenom
NumPhone 0,n
1,1 Factures
Adresse Recevoir 0,n
NumFacture
DateFacture
MontantTotal

Association Redondante : Si un ‘’Client’’ ne peut pas régler la facture d’un autre client, alors
l’association ‘’Payer’’ est inutile et doit être supprimer. Dans le cas contraire, elle doit être
maintenue.

39
 Joueurs Joueurs

NumJoueur NumJoueur
Nom Nom
Poste Poste
NumPhone NumPhone
Adresse Normalisation Adresse

0,n 1,1 0,n

Jouer

Jouer 1 Jouer 2 Etre Remplaçant 2,2 ou 1,n

Livraisons

1,1 NumMatch
1,1 1,1 Date
Matchs
NumMatch
Date

En ce qui concerne les associations redondantes, cela signifie que s’il existe deux chemins pour se
rendre d’une entité à une autre, alors ils doivent avoir deux significations ou deux durées de vie
différentes. Sinon, il faut supprimer le chemin le plus cours, car il est déductible à partir de l’autre
chemin. Dans notre exemple précédant, si on supprime l’association ‘’Payer’’, on peut retrouver le
client qui a payé le règlement en passant par la facture qui correspond.

Remarque : une autre solution pour ce problème consiste à retirer l’entité ‘’Règlement’’ et d’ajouter
une association ‘’régler’’ avec les mêmes attributs (Sauf l’identifiant) entre les entités ‘’Clients’’ et
‘’factures’’.

7. Normalisation des cardinalités

Une cardinalité minimal est toujours 0 ou 1 et non 2, 3 ou n et une cardinalité maximale est
toujours est 1 ou n, pas 2, 3, …

Cela signifie que si une cardinalité maximale est connue et vaut 2, 3 ou plus, alors nous considérons
quand même qu’elle est indéterminée et vaut n. cela se justifie par le faite que même si nous
connaissons n au moment de la conception, il se peut que cette valeur évolue au cours du temps. Il
vaut donc mieux considérer n comme une inconnue dès le départ.

Cela signifie également qu’on ne modélise pas les cardinalités minimales qui valent plus de 1 car ce
genre de valeur est aussi amené à évoluer. Par ailleurs, avec une cardinalités maximale de 0,
l’association n’aura aucune signification.

Dans une SGBD relationnel, nous pourrions assurer les cardinalités valant 2, 3 ou plus, via
l’utilisation de déclencheurs. Mais cette notion n’est pas aborder ici car nous nous contentons, au
contraire, de décrire ce qu’il est possible de faire sans utiliser de déclencheur.
40
3.2.3.4. Les formes normales
A ces 7 règles de normalisation, il convient d’ajouter les 3 formes premières formes normales
traditionnellement énoncées pour les schémas relationnels, mais qui trouvent tout aussi bien leur
place en ce qui concerne les schémas entités-associations.
a. Première forme normale
A un instant donné dans une entité, pour un individu (occurrence), un attribut ne peut prendre
qu’une valeur et non pas, un ensemble ou liste de valeurs.
Si un attribut prend plusieurs valeurs, alors ces valeurs doivent
faire l’objet d’une entité supplémentaire en association avec la première.

Livres Livres
1,n
CodeLivre CodeLivre
Ecrire
Titre Titre
Auteur Editeur
ère 1,n
Editeur 1 Forme Nbrpages
Nbrpages Annee Auteurs
Annee NumAuteur
Nom

b. Deuxième forme normale

L’identifiant peut être composé de plusieurs attribut mais les autres attributs de l’entité doivent
dépendre de l’identifiant en entier et non pas une partie de cet identifiant.

Cette deuxième forme normale peut être oubliée si on suit le conseil de n’utiliser que des
identifiants non composés et de type entier. En vérité, elle a été vidée de sa substance par la règle
de normalisation des attributs des associations.

Considérons malgré tout le contre – exemple suivant : dans une entité ‘’Clients’’ dont l’identifiant
est composé des attributs ‘’nom’’ et ‘’prenom’’, la date de fête d’un client ne dépend pas de son
identifiant en entier mais seulement de ‘’prenom’’. Elle ne doit pas figurer dans l’entité ‘’Clients’’
faire une entité ‘’Calendrier’’ à part, en association avec l’entité ‘’Clients’’.
c. Troisième forme normale de Boyce-Codd (importante)

Tous les attributs d’une entité doivent dépendre directement de son identifiant et d’aucun autre
attribut.

Si ce n’est pas le cas, il faut placer l’attribut pathologique dans une entité séparée, mais en
association avec la première.
NumAvion Constructeur Modele Capacite Proprietaire
1 Airbus A380 180 Air France
2 Boeing B747 314 British Airways
3 Airbus A380 180 KLM

41
Redondance des occurrences dans les colonnes ‘’constructeur’’ et ‘’capacite’’ qui peut entrainer
une incohérence.

Par exemple, l’entité ‘’Avions’’ dont les valeurs sont données dans le tableau 3, n’est pas en
troisième forme de Boyce-Codd, car la ‘’Capacite’’ et le ‘’Constructeur’’ d’un avion ne dépend pas
du ‘’NumAvion’’ mais de son ‘’Modele’’. Voici la solution normalisée.

Avions Avions 1,n

NumAvion NumAvion Ecrire
Construicteur Propriete
Modele ème 1,n
3 Forme
Capacite Modeles
Propriete
NumModele
Modele
Construicteur
Capacite

3.2.3.5. Exercice

Exercice 1

Une banque désire informatiser les opérations de retrait et de dépôt d’espèces de ses clients sur leur
compte. Un client peut avoir plusieurs comptes à la banque et un compte peut être commun à
plusieurs clients.

T.D. Concevoir le MCD correspondant

Exercice 2

Une librairie veut informatiser sa gestion. Elle a des clients dans différentes communes de la ville
qui lui passent des commandes. Chaque client a un numéro, un nom, un post nom, un prénom, un
niveau d’étude et un numéro de téléphone. Une commande a un numéro, une date et peut
comporter plusieurs livres différents. Un livre (ayant un code livre, un intitulé, le nombre de
chapitres, de pages) est écrit par un ou plusieurs auteurs et est publié par un éditeur qui a un
numéro, un nom, une adresse, une ville, un numéro de téléphone et un courriel. Un auteur est
identifié par son code, son nom, sa spécialité, sa profession, son adresse et son email. Dans une
commune, on compte sa référence, son libellé et le nombre d’habitants.
Suivant ce constat, identifiez les entités, les attributs et les relations et établissez le MCD
correspondant

Exercice 3
Un cabinet de médecin souhaite modéliser son SI de consultation. Etant informaticien, il vous est
demandé de concevoir un MCD correspondant en sachant que :

Un médecin est identifié par son numéro d’ordre, son nom, sa spécialité et son numéro de
téléphone.
42
 Un médecin ne peut recevoir qu’un patient dans une consultation mais un patient peut subir
plusieurs consultation ;
Pour chaque patient, on veut connaître son nom, son prénom, son âge, son sexe et son
adresse.
Dans une consultation, le médecin doit savoir le poids du patient, sa taille, sa température,
sa tension atérienne, ses antécédents et sa plainte.
Plusieurs médecins peuvent prescrire les mêmes médicaments pour le même patient
consulté mais toute consultation n’aboutit pas à une prescription et les médicaments
prescrits ont un nombre précis de prise.

Pour chaque médicament il faut connaître son code produit, son intitulé, sa famille, sa date
de fabrication et sa date de péremption.
A une consultation, plusieurs factures peuvent être établies et celles – ci sont payées par le
même patient.
Dans une facture il faut connaître à part son numéro, le montant, le libellé et la date.

Trouvez au départ les entités, les attributs et les relations.

3.3. Le Niveau Organisationnel et Logique

3.3.1. Modèle Logique de données
3.3.1.1. Notions
Jusqu'à présent nous avons établi des MCD basés sur une analyse d'un domaine bien défini. La
finalité d'un MCD est de nous faciliter la création d'une base de données pour gérer un tel
domaine.

Nous savons également qu'une base de données est constituée par un ensemble de tables, dont
chacune est composée de champs de données.

Or, le MCD ne connaît pas la notion de table, tandis qu'une base de données ne connaît pas le
concept des classes (Entités) reliées entre-elles via des associations avec des multiplicités
(Cardinalités).

Pour cela, il existe un autre modèle, le modèle logique des données (MLD), qui utilise
essentiellement le formalisme des tables logiques. Un MLD, qui est toujours basé sur un MCD
donné, contient donc toutes les informations de ce MCD, mais les représente à l'aide d'un
formalisme différent qui est très adapté aux structures d'une base de données.

Tandis que le MCD représente un système d'information d'une façon générale et indépendante
d'un système informatique, le MLD tient compte de la réalisation par le biais d'un SGBD.

Un MLD est essentiellement composé de tables logiques reliées entre elles par des flèches.

43
3.3.1.2. Règles de transformation du MCD au MLD
Notons, avant de parler des règles de passage du MCD au MLD, qu’on dit qu’une association
binaire (entre 2 entités ou réflexive) est du type :
1 :1 (un à un) si aucune des deux cardinalités maximales n’est n ;
1 :n (un à plusieurs) si une des deux cardinalités maximales est n ;
n :m (plusieurs à plusieurs) si les deux cardinalités maximales sont n

En fait, un schéma relationnel ne peut faire la différence entre 0,n et 1,n. Par contre, il peut la faire
entre 0,1 et 1,1 (voir les règles 2 et 4)

Règle 1 : Des Entités

Toute Entité (classe) est transformée en Table. Les Attributs de l’Entité deviennent les Colonnes
(attributs) de la table. L'Identifiant de la classe devient la Clé primaire de la table. La clé primaire
est soulignée et on écrit tout en majuscule.

CLIENTS
NUMCLIENT
NOM
PRENOM
ADRESSE

Règle 2 : D’Associations binaires du type 1:n

Toute association binaire du type 1:n disparaît au profit d’une clé étrangère dans la table du coté 0,1
ou 1,1 qui référence la clé primaire de l’autre table. Cette clé étrangère ne peut recevoir la valeur
vide (Nul) si la cardinalité est 1,1.

La clé étrangère est écrite en couleur. Les deux tables sont liées par une flèche nommée selon
l'association, qui pointe de la table à clé étrangère vers la table qui contient la clé primaire
correspondante. Lorsque l'association contient elle-même des attributs
(classe association), ceux-ci deviennent également attributs de la table dans laquelle a été ajoutée
la clé étrangère.

44
Livraisons

NumLivraison
DateLivraison
NomLivreur

1,n
Effectuer

1,1
Fournisseur

IdFournisseur
Nom
Prenom
NumPhone
Adresse
FOURNISSEURS
IDFOURNISSEUR
NOM
PRENOM
LIVRAISONS NUMPHONE
ADRESSE
NUMLIVRAISON Effectuer #NUMLIVRAISON
DATELIVRAISON
NOMLIVREUR

Règle 3 : D’Associations binaires du type n : m

Une association binaire de type n:m devient une table supplémentaire (appelée table de jonction,
de jointure ou d’association) dont la clé primaire est composé de deux clés étrangères qui
référencent les deux clés primaires des tables en association.

Lorsque l'association contient elle-même des attributs, ceux-ci deviennent attributs de la table
supplémentaire. Un attribut d'une classe association qui fait partie de l'identifiant devra
appartenir à la clé primaire Règle 4 :

45
Une association binaire du type 1:1 est traduite comme une association binaire de type 1:n sauf
que la clé étrangère se voit imposer une contrainte d’unicité en plus d’une éventuelle contraire de
non vacuité (cette contrainte d’unité impose à la colonne (attribut) correspondant de ne prendre
que des valeurs distinctes).

Si les associations fantômes ont été éliminées, il devrait avoir au moins un côté de cardinalité 0,1.
C’est alors dans la table du côté opposé que doit aller la clé étrangère. Si les deux côtés sont de
cardinalité 0,1 alors la clé étrangère peut être placée indifféremment dans l’une des tables.

Employes 0,1 Services

1,1
NumEmploye Diriger NumService
Nom NomService
Adresse AdresService

EMPLOYES SERVICES

NUMEMPLOYE NUMSERVICE
NOM NOMSERVICE
ADRESSE ADRESSERVICE
#NUMEMPLOYE

En réalité, la règle 4 proposée ici considère qu’une association binaire du type 1:1 correspond à
une association binaire du type 1:n particulière. Une alternative consiste à voir une association
binaire du type 1:1 comme une association binaire du type n:m particulière. Il suffit pour cela
d’ajouter une contrainte d’unicité sur chacune des clés étrangères de la table de jonction
supplémentaire. En voici un exemple :

46
Mais rien ne garantit, dans cette traduction alternative, qu’un service possède un dirigeant, alors
que c’est obligatoire. La première traduction est donc préférable.

Remarque : d’autres technique sont parfois proposées pour cette règle 4 comme, fusionner les
tables, utiliser une clé primaire identique, utiliser deux clés étrangères réflexives, mais elles ne sont
pas exploitable dans le cas générale.

Règle 5 :

Une association non binaire est traduite par une table supplémentaire dont la clé primaire est
composée d’autant de clés étrangère que d’entité en association. Les attributs deviennent des
colonnes (attributs) de cette nouvelle table.

Par exemple, l’association ‘’Projeter’’ devient la table :

Horaire Horaire

Codehoraire Codehoraire
Date Date
HeureDebut HeureDebut

0,n
Salle 0,n PROJECTIONS FILM
Projeter
NumSalle #NUMFILM NUMFILM
Tarif
Capacite #NUMSALLE TITRE
0,n #CODEHORAIRE DUREE
TARIF
Film
NumFilm
Titre SALLE
Durée
NUMSALLE
CAPACITE

47
3.3.1.3 Exercices

Exercice 6
Faire le MLD de l’exercice 2
Exercice 7
Faire le MLD de l’exercice 4
Exercice 8
Faire le MLD de l’exercice 5

3.3.2. Le Modèle Organisationnel de Traitement (MOT)

3.3.2.1. Notions

Le modèle organisationnel des traitements s'attache à décrire les propriétés des traitements non
traitées par le modèle conceptuel des données, c'est-à-dire :

 le temps
 les ressources
 le lieu
Le modèle organisationnel des traitements consiste donc à représenter le modèle conceptuel des
traitements dans un tableau dont les colonnes sont la durée, le lieu, les responsables et ressources
nécessaires à une action.

La première étape du modèle organisationnel des traitements consiste à découper les opérations
en procédures fonctionnelles, une succession de traitements déclenchée par un événement.

Il s'agit donc d'associer dans un tableau :

 les procédures fonctionnelles

 l'heure de début et de fin
 le lieu du poste de travail
 le responsable du poste de travail
 les ressources du poste de travail

Le modèle organisationnel des traitements permet de structurer les opérations sur le seul critère
de l’enchaînement logique. Une opération sera exécutée après une autre si elle a besoin, pour «
fonctionner », des résultats de l’autre.

Cette architecture abstraite, théorique, doit, pour pouvoir être mise en place, prendre en compte
trois nouveaux concepts, le lieu, le moment et la nature des opérations.

MOT = MCT + lieu + moment + nature

48
 3.3.2.2. Passage du MCT au MOT
Le point de départ du processus de passage d’un MCT à un MOT, c’est un Modèle Conceptuel
de Communications et un Modèle Conceptuel des Traitements. Le MCC fournit la liste des
acteurs :

Acteur A Acteur B Acteur C

Le MCT est ensuite importé dans cette structure :

Acteur Acteur B Acteur

A C

Ce travail n’est pas toujours aussi simple. Il peut y avoir répartition d’une opération conceptuelle
entre plusieurs acteurs. Dans ce cas, les deux graphes (le MCT et le MOT) n’auront pas le même
nombre de sommets.

49
3.4. Le Niveau Physique
3.4.1. Le modèle physique des données (MPD)
3.4.1.1 Définition
Le modèle physique des données (MPD) est la traduction du modèle logique des données (MLD)
dans une structure de données spécifique au système de gestion de bases de données (SGBD)
utilisé.

Le MPD est donc représenté par des tables définies au niveau du système de gestion de bases de
données. C'est donc au niveau du MPD que nous quittons la méthode générale de création d'un
MCD et de sa transformation en MLD, pour nous tourner vers la manipulation d'un SGBD
spécifique.

3.4.1.2 Passage du MLD au MPD

Le passage MLD MPD se fait par les étapes suivantes:

Implémentation physique de chaque table du MLD dans le SGBD utilisé.

Pour chaque table, indiquer au SGBD quel(s) champ(s) constitue(nt) la clé primaire.
Pour chaque table, indiquer au SGBD la (les) clé(s) étrangère(s), et la (les) clé(s)
primaire(s) correspondante(s).

Pour ce faire, la plupart des SGBD actuellement sur le marché nous offrent 2 possibilités.
1. Utilisation d'une ou de plusieurs interfaces graphiques,

Nous aident dans la création des tables physiques, la définition des clés primaires, des attributs,
des contraintes, des cardinalités et des relations.
2. Utilisation des codes SQL

Utilisation des consoles ou des éditeurs de textes, grâce à quoi nous saisissons des codes de
langage de ce langage.

50
 CHAPITRE IV : MODELISATION D’UN SYSTEME AVEC UML

Le développement de ce chapitre tente de faire une modélisation du système par l’approche

UML, en y montrant les procédures de création de quelques diagrammes de base.

4.1. Introduction

La description de la programmation par objets a fait ressortir l'étendue du travail conceptuel

nécessaire : définition des classes, de leurs relations, des attributs et méthodes, des interfaces, etc.

Pour programmer une application, il ne convient pas de se lancer tête baissée dans l'écriture du
code : il faut d'abord organiser ses idées, les documenter, puis organiser la réalisation en
définissant les modules et étapes de la réalisation. C'est cette démarche antérieure à l'écriture que
l'on appelle modélisation ; son produit est un modèle.

Les spécifications fournies par la maîtrise d'ouvrage en programmation impérative étaient

souvent floues : les articulations conceptuelles (structures de données, algorithmes de traitement)
s'exprimant dans le vocabulaire de l'informatique, le modèle devait souvent être élaboré par celle-
ci. L'approche objet permet en principe à la maîtrise d'ouvrage de s'exprimer de façon précise
selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra être immédiatement
compris par les informaticiens. En principe seulement, car la modélisation demande aux maîtrises
d'ouvrage une compétence et un professionnalisme qui ne sont pas aujourd'hui répandus.

4.2. Les diagrammes d’UML

UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et

décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles,
concevoir des solutions et communiquer des points de vue.

UML s’articule maintenant autour de 13 diagrammes différents, dont 4 nouveaux diagrammes

introduits par UML 2.0. Chacun d’eux est dédié à la représentation d’un système logiciel suivant
un point de vue particulier. Par ailleurs, UML modélise le système suivant deux modes de
représentation : L’un concerne la structure du système pris « au repos », l’autre concerne sa
dynamique de fonctionnement. Les deux représentations sont nécessaires et complémentaires
pour schématiser la façon dont est composé le système et comment ses composantes
fonctionnent entre elles.

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
 Diagramme d’objet
 Diagramme de composant (modifié dans UML 2)

51
 Diagramme de déploiement (modifié dans UML 2)
 Diagramme de paquetage (nouveau dans UML 2)
 Diagramme de structure composite (nouveau dans UML 2)
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

 Diagramme d’état-transition (machine d’état)
 Diagramme d’activités (modifié dans UML 2)
 Diagramme de séquence (modifié dans UML 2)
 Diagramme de communication (anciennement appelé collaboration)
 Diagramme global d’interaction (nouveau dans UML 2)
 Diagramme de temps (nouveau dans UML 2)

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

4.2.1. Diagramme de cas d’utilisation

4.2.1.1. Introduction

Bien souvent, la maîtrise d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut
donc un moyen simple d'exprimer leurs besoins. C'est précisément le rôle des diagrammes de cas
d'utilisation qui permettent de recueillir, d'analyser et d'organiser les besoins, et de recenser les
grandes fonctionnalités d'un système. Il s'agit donc de la première étape UML d'analyse d'un
système.

Un diagramme de cas d'utilisation capture le comportement d'un système, d'un sous-système,

d'une classe ou d'un composant tel qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité du
système en unités cohérentes, les cas d'utilisation, ayant un sens pour les acteurs. Les cas
d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système, ils sont donc une
vision orientée utilisateur de ce besoin au contraire d'une vision informatique.

Il ne faut pas négliger cette première étape pour produire un logiciel conforme aux attentes des
utilisateurs. Pour élaborer les cas d'utilisation, il faut se fonder sur des entretiens avec les
utilisateurs.

52
4.2.1.2. Eléments du diagramme de cas d’utilisation

a. Acteur

Un acteur est l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose
qui interagit avec un système.

Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou
autre système) qui interagit directement avec le système étudié.

Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en
recevant des messages susceptibles d’être

Il se représente par un petit bonhomme avec son nom (i.e. son rôle) inscrit dessous.

Il est également possible de représenter un acteur sous la forme d'un classeur stéréotypé << actor
>>.

b. Cas d’utilisation

Un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de l'extérieur.
Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour
l'acteur qui l'initie. Un cas d'utilisation modélise donc un service rendu par le système, sans
imposer le mode de réalisation de ce service.

Un cas d'utilisation se représente par une ellipse contenant le nom du cas (un verbe à l'infinitif),
et optionnellement, au-dessus du nom, un stéréotype

Exemple de représentation d'un cas d'utilisation.

53
Dans le cas où l'on désire présenter les attributs ou les opérations du cas d'utilisation, il est
préférable de le représenter sous la forme d'un classeur stéréotypé << use case >> .

4.1.2.2. Représentation d’un diagramme de cas d’utilisation

Exemple simplifié de diagramme de cas d'utilisation modélisant une borne d'accès à une banque.

54
 Comme le montre la figure, la frontière du système est représentée par un cadre. Le nom du
système figure à l'intérieur du cadre, en haut. Les acteurs sont à l'extérieur et les cas d'utilisation à
l'intérieur.

4.1.2.3. Relation entre acteurs et cas d’utilisation

- Relation d’association

Une relation d'association est chemin de communication entre un acteur et un cas d'utilisation et
est représenté un trait continu.

1. Acteurs principaux et secondaires

Un acteur est qualifié de principal pour un cas d'utilisation lorsque ce cas rend service à cet acteur.
Les autres acteurs sont alors qualifiés de secondaires. Un cas d'utilisation a au plus un acteur
principal. Un acteur principal obtient un résultat observable du système tandis qu'un acteur
secondaire est sollicité pour des informations complémentaires. En général, l'acteur principal
initie le cas d'utilisation par ses sollicitations. Le stéréotype << primary >> vient orner
l'association reliant un cas d'utilisation à son acteur principal, le stéréotype << secondary >> est
utilisé pour les acteurs secondaires Quand un cas n'est pas directement relié à un acteur, il est
qualifié de cas d'utilisation interne.

55
2. Types de relations

Il existe principalement deux types de relations :

 Les dépendances stéréotypées, qui sont explicitées par un stéréotype (les plus
utilisés sont l'inclusion et l'extension) ;
 et la généralisation/spécialisation.
Une dépendance se représente par une flèche avec un trait pointillé Si le cas A inclut ou étend le
cas B, la flèche est dirigée de A vers B.

Le symbole utilisé pour la généralisation est une flèche avec un trait plein dont la pointe est un
triangle fermé désignant le cas le plus général.

- Relation d’inclusion

Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B
: le cas A dépend de B. Lorsque A est sollicité, B l'est obligatoirement, comme une partie de A.
Cette dépendance est symbolisée par le stéréotype << include >> Par exemple, l'accès aux
informations d'un compte bancaire inclut nécessairement une phase d'authentification avec un
identifiant et un mot de passe.

Les inclusions permettent essentiellement de factoriser une partie de la description d'un cas
d'utilisation qui serait commune à d'autres cas d'utilisation

56
 Les inclusions permettent également de décomposer un cas complexe en souscas plus
simples.

Cependant, il ne faut surtout pas abuser de ce type de décomposition : il faut éviter de réaliser du
découpage fonctionnel d'un cas d'utilisation en plusieurs sous-cas d'utilisation pour ne pas retomber
dans le travers de la décomposition fonctionnelle.

Attention également au fait que, les cas d'utilisation ne s'enchaînent pas, puisqu'il n'y a aucune
représentation temporelle dans un diagramme de cas d'utilisation.

- Relation d’extension

La relation d'extension est probablement la plus utile, car elle a une sémantique qui a un sens du
point de vue métier au contraire des deux autres qui sont plus des artifices d'informaticiens.

On dit qu'un cas d'utilisation A étend un cas d'utilisation B lorsque le cas d'utilisation A peut être
appelé au cours de l'exécution du cas d'utilisation B. Exécuter B peut éventuellement entraîner
l'exécution de A : contrairement à l'inclusion, l'extension est optionnelle. Cette dépendance est
symbolisée par le stéréotype << extend >>.

L'extension peut intervenir à un point précis du cas étendu. Ce point s'appelle le point
d'extension. Il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique
point d'extension, et est éventuellement associé à une contrainte indiquant le moment où
l'extension intervient. Une extension est souvent soumise à condition. Graphiquement, la
condition est exprimée sous la forme d'une note

- Relation de généralisation

Un cas A est une généralisation d'un cas B si B est un cas particulier de A. Dans la figure
précédente, la consultation d'un compte via Internet est un cas particulier de la consultation. Cette

57
relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se
traduit par le concept d'héritage dans les langages orientés objet.

La seule relation possible entre deux acteurs est la généralisation : un acteur A est une
généralisation d'un acteur B si l'acteur A peut-être substitué par l'acteur B. Dans ce cas, tous les
cas d'utilisation accessibles à A le sont aussi à B, mais l'inverse n'est pas vrai.

Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein dont la
pointe est un triangle fermé désignant l'acteur le plus général (comme nous l'avons déjà vu pour
la relation de généralisation entre cas d'utilisation).

Par exemple, la figure ci-dessous montre que le directeur des ventes est un préposé aux
commandes avec un pouvoir supplémentaire : en plus de pouvoir passer et suivre une
commande, il peut gérer le stock. Par contre, le préposé aux commandes ne peut pas gérer le
stock.

4.2.2. Diagramme de séquence

4.2.2.1. Définition

Le diagramme de séquence décrit les interactions entre un groupe d’objets en montrant, de façon
séquentielle, les envois de message qui interviennent entre les objets. Le diagramme peut
également montrer les flux de données échangées lors des envois de message.

Le diagramme de séquence décrit la dynamique du système. À moins de modéliser un très petit

système, il est difficile de représenter toute la dynamique d’un système sur un seul diagramme.
Aussi la dynamique globale sera représentée par un ensemble de diagrammes de séquence, chacun
étant généralement lié à une sous fonction du système.

58
 4.2.2.2. Concepts du diagramme de séquence
a. Ligne de vie

Une ligne de vie représente l’ensemble des opérations exécutées par un objet.

Un message reçu par un objet déclenche l’exécution d’une opération. Le retour d’information
peut être implicite (cas général) ou explicite à l’aide d’un message de retour.

b. Message synchrone et asynchrone

Dans un diagramme de séquence, deux types de messages peuvent être distingués :

Message synchrone
Dans ce cas l’émetteur reste en attente de la réponse à son message avant de poursuivre ses
actions. La flèche avec extrémité pleine symbolise ce type de message. Le message retour peut ne
pas être représenté car il est inclus dans la fin d’exécution de l’opération de l’objet destinataire du
message.

Message asynchrone
Dans ce cas, l’émetteur n’attend pas la réponse à son message, il poursuit l’exécution de ses
opérations. C’est une flèche avec une extrémité non pleine qui symbolise ce type de message.

59
4.2.4. Diagramme de classe

4.2.4.1. Définition

Le diagramme de classes est considéré comme le plus important de la modélisation orientée

objet, il est le seul obligatoire lors d'une telle modélisation.

Alors que le diagramme de cas d'utilisation montre un système du point de vue des acteurs, le
diagramme de classes en montre la structure interne. Il permet de fournir une représentation
abstraite des objets du système qui vont interagir pour réaliser les cas d'utilisation. Il est important
de noter qu'un même objet peut très bien intervenir dans la réalisation de plusieurs cas
d'utilisation. Les cas d'utilisation ne réalisent donc pas une partition des classes du diagramme de
classes. Un diagramme de classes n'est donc pas adapté (sauf cas particulier) pour détailler,
décomposer, ou illustrer la réalisation d'un cas d'utilisation particulier.

Il s'agit d'une vue statique, car on ne tient pas compte du facteur temporel dans le comportement
du système. Le diagramme de classes modélise les concepts du domaine d'application ainsi que les
concepts internes créés de toutes pièces dans le cadre de l'implémentation d'une application.
Chaque langage de Programmation orienté objet donne un moyen spécifique d'implémenter le
paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes
permet de modéliser les classes du système et leurs relations indépendamment d'un langage de
programmation particulier.

Les principaux éléments de cette vue statique sont les classes et leurs relations : association,
généralisation et plusieurs types de dépendances, telles que la réalisation et l'utilisation.

Le diagramme de classes est considéré comme le plus important de la modélisation orientée

objet, il est le seul obligatoire lors d’une telle modélisation.

4.2.2. Diagramme de séquence

4.2.2.1. Définition

Le diagramme de séquence décrit les interactions entre un groupe d’objets en montrant, de façon
séquentielle, les envois de message qui interviennent entre les objets. Le diagramme peut
également montrer les flux de données échangées lors des envois de message.

Le diagramme de séquence décrit la dynamique du système. À moins de modéliser un très petit

système, il est difficile de représenter toute la dynamique d’un système sur un seul diagramme.
Aussi la dynamique globale sera représentée par un ensemble de diagrammes de séquence, chacun
étant généralement lié à une sous fonction du système

4.2.2.2. Concepts du diagramme de séquence

a. Ligne de vie
Une ligne de vie représente l’ensemble des opérations exécutées par un objet.
60
Un message reçu par un objet déclenche l’exécution d’une opération. Le retour
d’information peut être implicite (cas général) ou explicite à l’aide d’un message de retour.

b. Message synchrone et asynchrone

Dans un diagramme de séquence, deux types de messages peuvent être distingués :

Message synchrone
Dans ce cas l’émetteur reste en attente de la réponse à son message avant de poursuivre ses
actions. La flèche avec extrémité pleine symbolise ce type de message. Le message retour peut ne
pas être représenté car il est inclus dans la fin d’exécution de l’opération de l’objet destinataire du
message.

Message asynchrone
Dans ce cas, l’émetteur n’attend pas la réponse à son message, il poursuit l’exécution de ses
opérations. C’est une flèche avec une extrémité non pleine qui symbolise ce type de message.

61
 Il est aussi possible dans certains outils de modélisation d’indiquer plus simplement la création
d’une nouvelle instance d’objet en utilisant le mot-clé « create ».

4.3.4.2. Concepts du diagramme de classe

La description du diagramme de classe est fondée sur :

 le concept d’objet ;
 le concept de classe comprenant les attributs et les opérations ;
 les différents types d’association entre classes.

1. Objet.

Un objet est un concept, une abstraction ou une chose qui a un sens dans le contexte du système
à modéliser.

Il est caractérisé par les valeurs de ses propriétés qui lui confèrent des états significatifs suivant les
instants considérés. Le formalisme de représentation d’un objet est donné après celui d’une
classe.

2. classe comprenant les attributs et les opérations.

a. Une classe.

Une classe décrit un groupe d’objets ayant les mêmes propriétés (attributs), un même
comportement (opérations), et une sémantique commune (domaine de définition).

Un objet est une instance d’une classe. La classe représente l’abstraction de ses objets.

62
Une classe se représente avec UML sous forme d'un rectangle divisé en trois sections. Le premier
contient le nom donné à la classe (non souligné). Les attributs d'une classe sont définis par un
nom, un type (éventuellement une valeur par défaut, c'est-à-dire une valeur affectée à la propriété
lors de l'instanciation) dans le second compartiment. Les opérations sont répertoriées dans le
troisième volet du rectangle.

Formalisme d’une classe.

b. Attribut.
Un attribut est une propriété élémentaire d’une classe. Pour chaque objet d’une classe, l’attribut
prend une valeur.

Formalisme d’attribut.

Caractéristiques.

La description complète des opérations d’une classe comporte un certain nombre de

caractéristiques qui doivent respecter le formalisme suivant :

 Visibilité Nom d’opération (paramètres).

 Visibilité : se reporter aux explications données plus loin sur ce point.
 Nom d’opération : utiliser un verbe représentant l’action à réaliser.
 Paramètres : liste de paramètres (chaque paramètre peut être décrit, en plus de son nom, par
son type et sa valeur par défaut). L’absence de paramètre est indiquée par ().
 Type résultat : type de (s) valeur(s) retourné(s) dépendant des types disponibles dans le
langage d’implémentation. Par défaut, une opération ne retourne pas de valeur.
3. Visibilité des attributs et opérations.

Chaque attribut ou opération d’une classe peut être de type public, protégé, privé ou paquetage.

63
Les symboles + (public), # (protégé), - (privé) et ~ (paquetage) sont indiqués devant chaque
attribut ou opération pour signifier le type de visibilité autorisé pour les autres classes.

Les droits associés à chaque niveau de confidentialité sont : -

Public (+) Ŕ Attribut ou opération visible par tous.

- Protégé (#) Ŕ Attribut ou opération visible seulement à l’intérieur de la classe et pour

toutes les sous-classes de la classe.
- Privé (-) Ŕ Attribut ou opération seulement visible à l’intérieur de la classe.
- Paquetage (~) Ŕ Attribut ou opération ou classe seulement visible à l’intérieur du
paquetage où se trouve la classe.

3. Association, multiplicité, navigabilité et contraintes

Lien et association

Un lien est une connexion physique ou conceptuelle entre instances de classes donc entre objets.

Une association décrit un groupe de liens ayant une même structure et une même sémantique.

Un lien est une instance d’une association. Chaque association peut être identifiée par son nom.

Une association entre classes représente les liens qui existent entre les instances de ces classes.

Multiplicité

La multiplicité indique un domaine de valeurs pour préciser le nombre d’instance d’une classe
vis-à-vis d’une autre classe pour une association donnée. La multiplicité peut aussi être utilisée
pour d’autres usages comme par exemple un attribut multivalué.

"1" signifie un exactement

"1..*" signifie de un à plusieurs

"*" et "0..*" signifient de zéro à plusieurs

* = plusieurs par défaut, une ligne simple = un

4.2.5. Diagramme d’activités

Le diagramme d’activité permet de mettre l’accent sur les traitements. Il est donc
particulièrement adapté à la modélisation du cheminement de flots de contrôle et de flots de
données. Il permet ainsi de représenter graphiquement le comportement d’une méthode ou le
déroulement d’un cas d’utilisation.

64
 Dans la phase de conception, les diagrammes d’activités sont particulièrement adaptés à la
description des cas d’utilisation. Plus précisément, ils viennent illustrer et consolider la
description textuelle des cas d’utilisation. De plus, leur représentation sous forme
d’organigrammes les rend facilement intelligibles et beaucoup plus accessibles que les diagrammes
d’états-transitions.

Les diagrammes d’activités sont également utiles dans la phase de réalisation car ils permettent
une description si précise des traitements qu’elle autorise la génération automatique du code.

Action (action)

Une action est le plus petit traitement qui puisse être exprimé en UML. Une action a une
incidence sur l’état du système ou en extrait une information. Les actions sont des étapes
discrètes à partir desquelles se construisent les comportements. La notion d’action est à
rapprocher de la notion d’instruction élémentaire d’un langage de programmation (comme C++
ou Java). Une action peut être, par exemple :

 une affectation de valeur à des attributs ;

 un accès à la valeur d’une propriété structurelle (attribut ou terminaison d’association) la
création d’un nouvel objet ou lien ;
 un calcul arithmétique simple ;
 l’émission d’un signal ;
 la réception d’un signal ;

Le diagramme d’activités présente un certain nombre de points communs avec le :

- diagramme d’état-transition puisqu’il concerne le comportement interne des opérations

- ou des cas d’utilisation. Cependant le comportement visé ici s’applique aux
- flots de contrôle et aux flots de données propres à un ensemble d’activités et non
- plus relativement à une seule classe.
- Les concepts communs ou très proches entre le diagramme d’activité et le diagramme
- d’état-transition sont :
- • transition,
- • noeud initial (état initial),
- • noeud final (état final),
- • noeud de fin flot (état de sortie),

- • ◊ noeud de décision (choix).

65
 Activité

Une activité représente le comportement d’une partie du système en termes d’actions et de

transitions. Une activité est composée de trois types de nœuds :

• nœud d’exécution (action, transition),

• nœud de contrôle (nœud initial, nœud final, flux de sortie, nœud de bifurcation, nœud de
jonction, nœud de fusion-test, nœud de test-décision, pin d’entrée et de sortie), • nœud d’objet.
Une activité peut recevoir des paramètres en entrée et en produire en sortie.

Formalisme et exemple
Nous donnons une première représentation simple à la figure.

66