Présenté par : Nabila OUNASSER

Ingénieur de données et connaissances

Doctorante à L’ENSIAS
▪ 2 heures par semaine durant 15 semaines
▪ Alternance de Cours / TD
▪ Projet à réaliser : Etude de cas complète => Analyse et Conception
▪ • Modalité de contrôle :
▪ 1 contrôle
▪ Examen final
▪ Projet
▪ Analyser et Comprendre le client et son besoin.
▪ Concevoir des Systèmes d’Information
▪ Modéliser le système d’information
▪ La démarche MERISE : intégration des modèles dans le processus d’analyse et
conception
▪ Réaliser une conception de la communication (MERISE)
▪ Réaliser une conception des données (MERISE)
▪ Réaliser une conception des traitements (MERISE)
▪ Apprenez à analyser et concevoir des Systèmes d’Information !
▪ Dans ce cours, on va présenter les techniques permettant de comprendre, analyser et
concevoir le besoin des clients.
▪ L'objectif est de vous montrer comment modéliser un logiciel informatique.
▪ Le cours s'articule autour de 3 thèmes :
▪ Comprendre le besoin de son client
▪ Analyser et concevoir des logiciels
▪ Modéliser le système d’information
« Il s’agit de conduire l’étudiant d’un
énoncé informel à une spécification
fonctionnelle. Cette démarche doit
aboutir à un logiciel conforme à la
spécification, installé dans une
organisation et à en maîtriser l’évolution,
les coûts et les temps de développement. »
3
4
5
Exemple de Modèle
Au sens informatique, l’analyse consiste d’une part à comprendre et modéliser
le fonctionnement d’un domaine de gestion d’une organisation, et d’autre
part à concevoir la solution informatique adéquate.
 MERISE

M éthode d'
E tude et de
R éalisation ,

I nformatique pour les

S ystèmes d'
E ntreprise
▪ MERISE est une méthode de conception, de
développement et de réalisation de projets
informatiques. Le but de cette méthode est d'arriver à
concevoir un système d'information. La méthode
MERISE est basée sur la séparation des données et
des traitements à effectuer en plusieurs modèles
conceptuels et physiques.
Principes de base de la méthode Merise

Séparation des données et des traitements

– Traitements:
• Étude des évènements
• Indépendances entre les domaines
– Données
• Étude du vocabulaire de l’organisation
• Intégration des domaines: Vue globale

20
Principes de base de la méthode Merise

Modéle conceptuel Modéle conceptuel Modéle conceptuel

de communication de données de traitement

Modèle physique Modèle organisationnel

de données de traitements

21 Base de données Application

 Approche par niveaux et approche
par étapes

22
Trois niveaux de modélisation

23
Trois niveaux de modélisation

24
 Préoccupation Communications Données Traitements
Abstraction
Conceptuel MCC MCD MCT

Organisationnel MOC MOD MOT

Logique MLC MLD MLT

Physique MPC MPD MPT

 Merise

Les points forts :

➢ La méthode s'appuie sur une approche systémique : C’est
donc une approche globale.
➢ Les concepts sont peu nombreux et simples.
➢ Elle est assez indépendante vis à vis de la technologie.
➢ Elle est la plus utilisée en France dans les domaines de
gestion.
➢ Elle sert de référence aux enseignements sur les méthodes.
Merise
Les critiques :
✓ Elle ne s'occupe pas de l'interface utilisateur.
✓ Elle ne permet pas réellement une validation rapide de la part des
utilisateurs.
✓ Il est très difficile de valider les traitements par rapport aux
données et cela au niveau conceptuel ou organisationnel.
✓ La validation en cours de l’étude par des personnes concernées permet
d’assurer que le système en train de construction conforme aux objectifs.
Si on ne respecte pas les étapes de validation on risque de produire des
applications loin de la demande initiale ce qu’on nomme
✓ « l’effet tunnel ». Sans oublier que les applications développées sont destinées
aux utilisateurs et non au plaisir des informaticiens.
 Les cycles

De l’abstraction à la réalisation d’un Système d’information, on va devoir

observer sous plusieurs angles de vues l’organisation que l’on étudie.
Ces angles de vues sont appelés cycles.
MERISE présente dans sa démarche d’analyse trois cycles fondamentaux :
⚫ le cycle d’abstraction,
⚫ le cycle de vie (de developpement),
⚫ le cycle de décision.
 Le Cycle d’Abstraction
Niveau Conceptuel
• Ce qu’il faut faire
• Quoi ?
Niveau Organisationnel
• La manière de faire
• Pour les traitements
• QUI, QUAND OU?

Niveau Logique
• Choix des moyens et ressources
• Pour les données
Niveau Physique
• Les moyens de le faire
• Comment ?
LA COURBE DU SOLEIL

CONCEPTUEL CONCEPTUEL

ORGANISATIONNEL ORGANISATIONNEL

LOGIQUE LOGIQUE

PHYSIQUE PHYSIQUE

EXISTANT FUTUR
Cycle de vie
Le cycle de vie

1. Analyse / Conception
Le schéma directeur
L'étude préalable
L'étude détaillée
2. La réalisation
L’étude Technique
Production Logicielle
Mise en service
[Link] Maintenance
 CYCLE DE VIE

⚫ Le processus de développement est découpé en étapes :

1. Schéma directeur
2. l’étude préalable : elle aboutit à une prise de décision
d’informatisation, en cas de décision positive, elle est suivie
par
3. l’étude détaillée : elle aboutit àun cahier de réalisation
avec affectation des tâches
4. Réalisation : écriture des programmes et implantation des
bases
5. Mise en œuvre et maintenance.
Le cycle de vie
 Schéma Directeur
⚫ Etude globale du SI : Découpage en domaines
⚫ Buts:
⚫ Définir les grandes orientations politiques et stratégiques de
l’entreprise
⚫ Définir les besoins en SI en fonction de la stratégie de l’entreprise
⚫ Fixer les cadres budgétaires, la stratégie des besoins en personnel et
les contraintes diverses liées à l’environnement
⚫ Fixer les lignes directrices des développements informatiques
⚫ Définir les projets nécessaires à l’élaboration ou l’évolution du SI
⚫ Documents produits:
⚫ Le schéma directeur
⚫ Le plan de développement informatique
La réalisation
L’Étude Technique
Les principes de bases de Merise
 Découpage en domaines
⚫ Pour réduire la complexité de modélisation de
l’entreprise en un seul tenant, on découpe l’entreprise
en domaines d’activité (Vente, Stock, Achat,
Comptabilité,Gestion du personnel)
Un domaine d’activité de l’organisation est un sous-ensemble
relativement indépendant composé d’informations, règles et
de procédures de gestion

52
 Découpage en domaines
⚫Chaque domaine peut être considéré comme un
système autonome (ayant un SP, Si et un SO)
⚫Les domaines de l’entreprise échangent des flux
entre eux, certaines informations peuvent figurer
dans plusieurs systèmes d’information.
⚫Le SI de l’entreprise peut être considéré comme
la réunion non disjointe des SI de chaque
domaine.

53
Comment découper une organisation en
domaines ?
⚫la technique employée se base sur les ensembles
d’informations échangés, dits aussi flux
d’information. Ces flux peuvent être classés
comme suit :
1. Flux en provenance de l’environnement extérieur
2. Flux à destination de l’environnement extérieur
3. Flux interne échangé (entre les domaines)

54
55
 Analyse des flux
⚫L’analysedes flux permet de représenter le
fonctionnement global de l’entreprise
Acteurs et flux
⚫ Un acteur représente une entité active intervenant
dans le fonctionnement de l’entreprise :
⚫ Client, Fournisseurs, (acteur externe)
⚫ Un domaine de l’entreprise (Gestion Personnel, Comptabilité)
⚫ ….

⚫Un flux de données est la représentation d’un

échange d’informations entre deux acteurs
56
Graphe des flux
⚫ Le graphe des flux est une représentation graphique
des acteurs et des flux.

57
Graphe des flux
Lorsque le graphe comporte plusieurs acteurs
internes on regroupes parfois tous ces acteurs en
une même entité (correspondant au SI à étudier)
et on ne garde que les flux en entrée et en sortie.
C’est le ‘graphe des flux contextuel’.

SI complet

Acteurs Acteurs
externes externes
61
La première étape de ce modèle est d'arriver à isoler le système en le délimitant. Il
s'agit donc de définir le système et les éléments externes avec lesquels il échange
des flux d'information. Ces éléments extérieurs sont appelés acteurs externes (ou
partenaires).
Le diagramme de contexte a pour but de représenter les flux d'informations entre
l'organisation et les acteurs externes selon une représentation standard dans laquelle
chaque objet porte un nom :
•l'organisation est représentée par un rectangle
•les acteurs externes sont représentés par des ellipses en pointillés
•les flux d'information sont représentés par des flèches dont l'orientation désigne le
sens du flux d'information
 Exemple : Gestion des sinistres dans une société
d’assurance
A l'arrivée d'une déclaration de sinistre, on
l'examine. Si la déclaration est recevable, on
demande l'avis d'un expert, sinon on notifie le
refus à l'assuré. Au retour de l'expertise et après
réception de la facture du garage, on calcule le
montant du remboursement et on envoie le chèque
au client.

58
Graphe des flux
Liste des acteurs
SOCIETE D’ASSURANCE (int),
CLIENT (ext),
EXPERT (ext),
GARAGE (ext)

Liste des flux

DECLARATION,
DEMANDE AVIS,
FACTURE,
REFUS,
AVIS EXPERT,
CHEQUE

59
▪ Modèle Conceptuel de Communications
▪ Flux entre les domaines et activités

▪ Modèle Organisationnel de Communications

▪ Flux entre les acteurs

▪ Modèle Physique de Communications

▪ Flux physiques (réseaux, serveurs, PC…)
 Il consiste à découper l'organisation en entités appelées acteurs
internes (ou domaines). Lorsque les domaines d'une organisation sont
trop importants, ils peuvent être décomposés eux-mêmes en sous-
domaines.

La dernière étape est l'analyse des flux d'information, c'est-à-dire la

définition des processus.
Ce diagramme permet de compléter le diagramme de contexte en décomposant
l'organisation en une série d'acteurs internes. Dans ce diagramme la représentation
standard est la suivante :
•Les acteurs internes sont représentés par des ellipses
•les messages internes sont représentés par des flèches
Exercice (GESTION DES CARTES BLEUES)
Le demandeur désirant obtenir une carte bleue doit en faire la
demande auprès de son agence.
La carte bleue n'est pas accordée si le demandeur n'est pas un
client de l'agence.
Chaque jour, l'agence transmet au centre de gestion des
cartes bleues les demandes de ses clients.
Dès que l'agence a reçu la carte bleue en provenance du
centre (en général 4 jours après la demande), elle adresse au
client un avisde mise àdisposition et un avis de prélèvement de
la cotisation annuelle. Le client vient alors retirer sa carte.
Si au bout de 2 mois la carte n'a pas été retirée, elle est détruite.
. Etablir le graphe des flux
62
▪ Modèle Conceptuel de Communications
▪ Flux entre les domaines et activités

▪ Modèle Organisationnel de Communications

▪ Flux entre les acteurs

▪ Modèle Physique de Communications

▪ Flux physiques (réseaux, serveurs, PC…)
▪ L'expression des besoins est une étape consistant à définir ce que l'on
attend du système d'information automatisé, il faut pour cela :
▪ faire l'inventaire des éléments nécessaires au système d'information
▪ délimiter le système en s'informant auprès des futurs utilisateurs
▪ Cela va permettre de créer le MCC (Modèle conceptuel de la
communication) qui définit les flux d'informations à prendre en compte.
▪ L'étape suivante consiste à mettre au point le MCD (Modèle conceptuel
des données) et le MCT (Modèle conceptuel des traitements) décrivant
les règles et les contraintes à prendre en compte.
▪ Le modèle organisationnel consiste à définir le MOT (Modèle
organisationnel des traitements) décrivant les contraintes dues à
l'environnement (organisationnel, spatial et temporel).
▪ Le modèle logique représente un choix logiciel pour le système
d'information.
▪ Le modèle physique reflète un choix matériel pour le système
d'information.
▪ Modèle Conceptuel des Données
▪ Entité, Association, Propriété, cardinalité

▪ Modèle Organisationnel des Données

▪ Modèle Logique des Données
▪ Entité, Relation, Champ, Clé primaire, Clé étrangère, Clé candidate, Index

▪ Modèle Physique des Données

▪ Fichier, table, Index
Le modèle conceptuel des données (MCD) a pour but d'écrire
de façon formelle les données qui seront utilisées par le
système d'information. Il s'agit donc d'une représentation des
données, facilement compréhensible, permettant de décrire le
système d'information à l'aide d'entités.

Il consiste à modéliser les données utiles et à mémoriser pour

le SI projeter ;
Déterminer leur structuration, Décrire les liens entre données.
Relation

Relation
Entités et classe d'entité
Entités et classe d'entité

Une entité est la représentation d'un élément matériel ou

immatériel ayant un rôle dans le système que l'on désire décrire.
On appelle classe d'entité un ensemble composé d'entités de
même type, c'est-à-dire dont la définition est la même. Le
classement des entités au sein d'une classe
s'appelle classification (ou abstraction). Une entité est
une instanciation de la classe. Chaque entité est composée de
propriétés, données élémentaires permettant de la décrire.
Entités et classe d'entité

Exemple : Prenons par exemple une Ford Fiesta, une Renault

Laguna et une Peugeot 306. Il s'agit de 3 entités faisant partie
d'une classe d'entité que l'on pourrait appeler voiture. La Ford
Fiesta est donc une instanciation de la classe voiture. Chaque
entité peut posséder les propriétés couleur, année et modèle.
 Entités et classe d'entité

Les classes d'entités sont représentées par un

rectangle. Ce rectangle est séparé en deux champs :
•le champ du haut contient le libellé. Ce libellé est
généralement une abréviation pour une raison de
simplification de l'écriture. Il s'agit par contre de
vérifier qu'à chaque classe d'entité correspond un et
un seul libellé, et réciproquement
•le champ du bas contient la liste des propriétés de la
classe d'entité
 Relations et classes de relation

Une relation (appelée aussi parfois association) représente les

liens sémantiques qui peuvent exister entre plusieurs entités.
Une classe de relation contient donc toutes les relations de
même type (qui relient donc des entités appartenant à des
mêmes classes d'entité). Une classe de relation peut lier plus de
deux classes d'entité.
Relations et classes de relation

Voici les dénominations des classes de relation selon le

nombre d'intervenants :
•une classe de relation récursive (ou réflexive) relie la
même classe d'entité
•une classe de relation binaire relie deux classes d'entité
•une classe de relation ternaire relie trois classes d'entité
•une classe de relation n-aire relie n classes d'entité
 Relations et classes de relation
Les classes de relations sont représentées par des hexagones (parfois des
ellipses) dont l'intitulé décrit le type de relation qui relie les classes
d'entité (généralement un verbe). On définit pour chaque classe de
relation un identificateur de la forme Ri permettant de désigner de façon
unique la classe de relation à laquelle il est associé.

On peut éventuellement ajouter des propriétés aux classes de relation.

Relations et classes de relation
 La cardinalité

Les cardinalités permettent de caractériser le lien qui existe entre une entité
et la relation à laquelle elle est reliée. La cardinalité d'une relation est
composée d'un couple comportant une borne maximale et une borne
minimale, intervalle dans lequel la cardinalité d'une entité peut prendre sa
valeur :
 La cardinalité
• La borne minimale (généralement 0 ou 1) décrit le nombre minimum de fois
qu'une entité peut participer à une relation
• La borne maximale (généralement 1 ou n) décrit le nombre maximum de fois
qu'une entité peut participer à une relation

Une cardinalité 1.N signifie que chaque entité appartenant à une classe d'entité
participe au moins une fois à la relation.
Une cardinalité 0.N signifie que chaque entité appartenant à une classe d'entité ne
participe pas forcément à la relation.
 La cardinalité
Exemple : Individus Personne et Adresse, Association Personne HABITE Adresse
 Les identifiants

Un identifiant est un ensemble de propriétés (une ou plusieurs)

permettant de désigner une et une seule entité. La définition originale est
la suivante :
L'identifiant est une propriété particulière d'un objet telle qu'il n'existe
pas deux occurrences de cet objet pour lesquelles cette propriété pourrait
prendre une même valeur.
 Les identifiants
Les attributs d'une classe d'entité permettant de désigner de façon unique
chaque instance de cette entité sont appelés identifiants absolus.
Le modèle conceptuel des données propose de faire précéder d'un # les
identifiants (parfois de les souligner).

Ainsi, chaque classe d'entité doit posséder au moins un attribut identifiant, et l'ensemble
de ses attributs identifiants doivent être renseignés à la création de l'entité.
▪
▪ Modèle Conceptuel des Traitements
▪ Individu, Opération, Règle de gestion, Evénements, Résultats, Synchronisation des
opérations : Définition du Quoi, Que faire
▪ Modèle Organisationnel des Traitements
▪ Phase, Unité Géographique de Traitement (UGF), Procédure, Poste de travail, Tâche :
Définition du Qui fait Quoi sur Quel Poste de travail, ...
▪ Modèle Logique des Traitements
▪ Transaction, Grille d'écran

▪ Modèle Physique des Traitements

Le modèle conceptuel des traitements permet de traiter la dynamique
du système d'information, c'est-à-dire les opérations qui sont réalisées
en fonction d'événements.

Ce modèle permet donc de représenter de façon schématique l'activité

d'un système d'information sans faire référence à des choix
organisationnels ou des moyens d'exécution, c'est-à-dire qu'il permet
de définir simplement ce qui doit être fait, mais il ne dit pas quand,
comment ni où...
Le MCT se déduit du MCC dans la mesure où il représente un zoom sur le MCC.
Le MCT consiste à "ouvrir" chaque domaine ou sous domaine identifié par le
MCC de façon à
définir les OPERATIONs faites dans ce domaine.
Le MCT se construit surtout par la réponse à la question QUOI, QUE
Exemple : dans le MCC précédent, l'intervenant Client envoie une Commande
au domaine Vendre.
QUE fait le domaine Vendre de cette Commande ?
Il traite la commande ! Donc "Traiter la commande" est une OPERATION interne
au domaine
Vendre.
L'opération peut être déclenchée soit par un seul message déclencheur, soit par
une combinaison de
messages déclencheurs ; dans ce cas une SYNCHRONISATION a pour objet
d'indiquer les règles
logiques entre ces messages qui déterminent le déclenchement de l'opération.
Le concept d'événement

Un événement représente un changement dans l'univers extérieur au

système d'information, ou dans le système d'information lui-même.

•un événement externe est un changement de l'univers extérieur

•un événement interne est un changement interne au système
d'information
Le concept d'événement

On représente un événement par une ellipse en trait plein pour les événements
internes à l'organisation, en trait pointillé pour les événements externes.
Définition d'un processus

Un processus est un sous-ensemble de l'activité de l'entreprise,

cela signifie que l'activité de l'entreprise est constituée d'un
ensemble de processus. Un processus est lui-même composé
de traitements regroupés en ensembles appelés opérations.
Opération

Une opération est un ensemble d'actions exécutées par le système

suite à un événement, ou à une conjonction d'événements.
Cet ensemble d'actions est ininterruptible, c'est-à-dire que les
événements ne sont pas pris en compte (ils ne sont pas forcéments
ignorés pour autant) tant que l'opération n'a pas été accomplie.
La synchronisation

La synchronisation d'une opération définit une condition

booléenne sur les événements contributifs devant
déclencher une opération. Il s'agit donc de conditions au
niveau des événements régies par une condition logique
réalisée grâce aux opérateurs :
•OU
•ET
•NON
 Construction du MCT

Le modèle conceptuel des

traitements permet de
représenter schématiquement la
gestion des événements :
+ clé étrangère
Exercise conception SI
jeudiÊ2ÊfévrierÊ2023 18:58

#MCC
Ex1

Ex2

Ex3
 Ex4

Ex5

#Mct

Ex1

Ex2
CamScanner
CamScanner
CamScanner
CamScanner
CamScanner
CamScanner
CamScanner
CamScanner
CamScanner
CamScanner