Conception Des Systemes Dinformation La

Institut Supérieur des Sciences Appliquées et de Technologie de Sousse
1 6
0 1
2 0 Conception des systèmes

2 d’information
La méthode Merise
Enseignant : Mr. Saidane
PLAN
Introduction générale
Notionsde base
Merise/Merise2
Les modèles de Merise 2
Modèles Conceptuels
Modèles de Flux
Modèle de Contexte (MC) et Diagrammes de Flux de Données (DFD)
Les Modèles dynamiques
Modèle Conceptuel des Traitements (MCT)
Modèle Conceptuel des Traitements Analytique (MCTA)
Mr. Saidane 2ième prépa- A.U. 2015-2016 2
1
Bibliographie
Les notes de ce cours sont entièrement issues de différents livres sur
Merise parmi lesquelles :
MERISE/2 : Modèles et Techniques MERISE avancés / Georges Panet, Raymond

Letouche / Les éditions d'organisation 1994
De l'autre côté de MERISE, Système d'information et modèles d'entreprise / Yves

Tabourier / Les éditions d'organisation 1986
La méthode MERISE / tome 1 : Principes et outils, tome 2 : Démarche et Pratiques /

H. Tardieu, A. Rochfeld, E. Colleti / Les éditions d'organisation 1983
L'essentiel sur MERISE / Dominique Dionisi / Eyrolles 1994
Parlez-vous MERISE ? / M. Diviné / Eyrolles

1 6
0 1
2 0
2 Introduction générale
2
Notions de base
Système
"un tout constitué d'éléments unis par des relations, ces éléments et
ces relations étant munis de propriétés".
Exemple : le système "d'entreprise"

employés, services, articles, emplacements de stockage
matricule de l'employé, son nom, référence de l'article
"est rattaché" entre employé et service, "est stocké" entre un article et un emplacement
de stockage
date d'entrée dans le service, la quantité stockée, etc.
Notions de base
Système (suite)
État d'un système
L'ensemble des valeurs, à un moment donné, des propriétés des éléments et des relations du
système.
Un système vit dans un environnement, subit et réagit à des stimuli. Ces réactions provoquent un
changement d'état.
entreprise
état 1
rejet
commande
réaction ou
client livraison
entreprise
état 2
3
Notions de base
Système (suite)
Un tout constitué d'éléments unis par des relations, doté d'une activité et répondant
à des stimuli.
J.L Le Moigne propose en 1977 de définir un système comme :

quelque chose (n'importe quoi, identifiable)
qui fait quelque chose (activité, fonction),
qui est doté d'une structure,
qui évolue dans le temps,
dans quelque chose (environnement),
pour quelque chose (finalité).
Notions de base
Système d’information
Le concept de SI d'une organisation recouvre deux notions :
l'organisation réelle se transformant, agissant, communiquant et mémorisant des

informations, notion qui apparente le SI à un objet naturel
le système construit par l'homme pour représenter les actions, la communication et la

mémorisation de l'information, notion qui apparente le SI à un objet artificiel.
conception système
système
d'information d'information
naturel artificiel
intégration
4
Notions de base
S. d'information / S. informatisé / S. informatique
Une partie du S. d'information peut être informatisé.

Le système informatisé s'appuie sur un système informatique (matériel,
logiciel, réseau..)
S. d'Information
S. Informatisé
S. Informatique
Notions de base
Les fonctions du SI
Recueillir, mémoriser et diffuser les infos
Assurer le traitement des infos
donnée traitements
s
+
5
Notions de base
Conception d’un système d’information
Cycle de vie : démarche par étapes : de l'étude de l'objet naturel à l'intégration du

système artificiel
Ingénierie des systèmes d’informations
supporter le cycle de vie des systèmes d'information des organisations

mise en place d'une démarche rigoureuse allant des besoins informels de l'organisation à
une solution organisationnelle et technique
Notions de base
Conception d’un système d’information ?
6
Notions de base
analyse d'opportunité
Cycle de vie d’un
système avant-projet
d’information
analyse conceptuelle
solution
conceptuelle
conception
conception technique
organisationnelle
solution solution
technique organisationnelle
réalisation technique mise en place

organisation
solution exploitable
exploitation-maintenance
Notions de base
Méthode d’analyse et de conception d’un SI
Une démarche : succession d'étapes permettant progressivement de décrire le

système sous différentes vues et à différents niveaux d'abstraction.
Des modèles : permettant d'établir des abstractions du système étudié.
Exemple : SADT, MERISE, OMT...

MERISE : la plus courante en France pour l'analyse et la conception des SI
de gestion.
7
Merise / Merise 2
MERISE
Méthode d'Étude et de Réalisation

Informatique par les Sous-Ensembles ou
pour les Systèmes d'Entreprises
Merise / Merise 2
Quelques chiffres
premier contrat 1974, premier ouvrage en 1983
aujourd'hui 50 000 praticiens, plus de 40 ouvrages
démarrage Merise 2 en 1989 (Sema Group)
Objectifs Merise 2
fournir un ensemble complet de démarches, modèles
conserver une compatibilité totale avec Merise
amélioration de certains points clés
intégration des diagrammes de flux de données
adaptation aux standards en cours de définition
…
8
Merise / Merise 2
Méthode Merise = Démarche + Formalisme
Démarche : succession d’étapes :

pour mieux maîtriser le déroulement d’un projet.
Meilleure visibilité pour les utilisateurs sur certains résultats intermédiaires et garantir que
le résultat final sera celui attendu
Formalisme : défini par:

Un langage formel
Un langage semi-formel généralement graphique
Un langage naturel
Fonction :
Représenter le monde réel tel qu’il est perçu par le concepteur
Outil de communication entre informaticiens et utilisateurs
Constitué par un ensemble de modèles permettant d’assurer une bonne compréhension des
besoins des utilisateurs
Merise / Merise 2
La démarche SCHEMA DIRECTEUR
ETUDE PREALABLE
Sous Ensemble Représentatif
Rapport Observation
Cahier des Charges
P
ETUDE DETAILLEE R
Dossier d'étude
détaillée
O
ETUDE TECHNIQUE
Dossier d'étude
J
technique
E
PRODUCTION DE LOGICIEL Dossier de
programmation,
T
MISE EN SERVICE
MAINTENANCE
9
Merise 2
La démarche
Schéma Directeur
Niveau global de l’entreprise

Développement du système d’information
Orientation politique – Stratégie de l’entreprise
RESULTATS
Domaine d’étude : Définition, Articulation des domaines

Planification du développement
Lancement de projet
Merise 2
La démarche
Étude préalable
PHASE 1 : ETUDE DE L'EXISTANT (observation)
Interviews
Modèle Organisationnel des flux : Acteurs, actions, flux
DICTIONNAIRE
Modèle Organisationnel des Traitements : liste des tâches, événements /
résultats, postes de travail, Messages
Modèle Logique des Données : Fichiers existants
Modèle Conceptuel des Flux : Regroupements des actions, Processus
Modèle Conceptuel des Traitements : Pour chaque processus,
modélisation des procédures, liste des opérations
10
Merise 2
La démarche
Étude préalable
PHASE 1 : ETUDE DE L'EXISTANT
Modèle Conceptuel des Données : Liste des entités, associations,

propriétés
Validation données/traitements
Rédaction du rapport d'observation
Validation du rapport d'observation par les utilisateurs et les personnes
interviewées
Merise 2
La démarche
Étude préalable
PHASE 2 : SOLUTIONS FUTURES (conception,

proposition de solutions)
Diagnostic et critique des règles de gestion existantes
Prise en compte de nouvelles règles de gestion, de nouveaux

traitements, de nouveaux messages
Nouveaux modèles conceptuels : Flux, Traitements, Données
11
Merise 2
La démarche
Étude préalable
PHASE 2 : SOLUTIONS FUTURES (suite)
Proposition de plusieurs scénarios :

Nouvelle organisation : Postes de travail
Architecture matérielle et logicielle
Modèles Organisationnels des Flux et des Traitements, modèle Logique des

données
Évaluation du coût : Personnel, Matériel, fonctionnement, développement
Rédaction du cahier des charges

Validation du cahier des charges par les utilisateurs
Choix par le comité de pilotage
Merise 2
La démarche
Étude détaillée
Spécifications fonctionnelles en respectant les solutions retenues à

l'issue de l'étude préalable
Porte sur les niveaux conceptuel et organisationnel,
décrit la globalité du projet
Spécification des procédures transitoires

Principes de basculement du système actuel vers le futur
Modèle Organisationnel des Traitements durant la période
transitoire…
12
Merise 2
La démarche
Étude détaillée
Spécifications des procédures de secours

Procédures à mettre en œuvre en cas d'indisponibilité de ressources
informatiques.
Planification du développement
Panification de la mise en place
Merise 2
La démarche
Étude technique
Architectures
logicielles
Données
Optimisation
Programmes
Composants logiciels, modules, répartition client serveur, etc.
13
Merise 2
La démarche
Étude technique
Préparation de la réalisation
Outils de réalisation
Règles de développement
Structure des programmes, commentaires

Principes de qualification
Modalités des tests, jeu d’essais

Organisation du développement
Répartition entre les équipes, planning général de production du

logiciel, modalités d’assurance qualité
Merise 2
La démarche
Réalisation (ou production de logiciel)

Réalisation concrète de l’ensemble des spécifications proposées dans l’étude détaillée
et l’étude technique
Écriture des programmes
Génération des fichiers ou bases de données
Tests de mise au point
14
Merise 2
La démarche
La mise en œuvre
Objectif : rendre opérationnel le nouveau système d’information
Mise en place des ressources

Moyens techniques, documentation utilisateur, ressources humaines
Préparation du lancement
Formation du personnel
Mise en place effective
La maintenance
Merise / Merise 2
Les modèles
Représentation abstraite de la réalité qui exclut certains détails du monde
réel.
Permet de réduire la complexité d’un phénomène.
Reflète ce que le concepteur croit important pour la compréhension du
phénomène modélisé.
Flux Traitement Données
15
Introduction Merise
Les modèles de Mersie 2
Modèle de Contexte (MC)

Modèle de Flux Conceptuel (MFC)
Modèle Conceptuel des Données (MCD)
Modèle Conceptuel de Traitement (MCT)
Modèle Conceptuel des Traitements Analytique (MCTA)
Cycle de Vie des Objets (CVO)
Modèle de Flux Organisationnel (MFO)

Modèle Organisationnel des Données (MOD)
Modèle Organisationnel des Traitements (MOT)
Modèle Organisationnel des Traitements Analytique (MOTA)
Modèle Logique des Données (MLD)

Modèle Logique des Données Réparties (MLDr)
Modèle Logique des Traitements (MLT)
Modèle Logique des Traitements Répartis (MLTR)
Ces modèles sont complétés pour les études d'architectures techniques complexes par les modèles suivants :
Schéma d'Architecture Logique des Moyens Informatiques (SALMI)
Schéma d'Architecture Logique (SAL)
Schéma d'Architecture Logique Répartie (SALr)
Suivant le type de projet et l'étape du cycle de vie, il convient de sélectionner une partie de ces modèles.
exemple : cas du "petit projet" (quelques hommes/mois, pas de répartition, logiciel classique) : MC, MFC, MCD,
MCTA, CVO, MLD, MLT, maquettes.
1 6
0 1
2 0
2 Les Modèles de Flux
16
Les Modèles de Flux
Modèles conceptuels
Représente la finalité du système et sa raison d'être, en s'appuyant

sur ses objectifs et les réalités externes qui le contraignent.
S'appuie sur un ensemble de règles de gestion qui décrivent le

"quoi" de l'entreprise (En général des règles d'actions ou de règles
de calcul).
Une règle de gestion est une traduction conceptuelle des objectifs

et des contraintes de l'entreprise.
Exemple
"un inventaire doit être dressé périodiquement"
" tout produit livré sera entré en stock"
"la centrale d'achat sera libre d'imposer des jours de commandes "
Remarque
l'analyste n'a aucune initiative sur les règles de gestion, son unique rôle est
de les trouver (interview), les faire valider puis les utiliser pour élaborer les
différents modèles conceptuels.
17
MFC
Faire ACTIVITES
architecture
MCT
Etre Se comporter MCTA
MCD
STRUCTURE COMPORTEMENT CVO
statique dynamique
Les différents modèles conceptuels

Les diagrammes de flux répondent à la question : Que fait le système ?
En ce sens, ce sont des modèles FONCTIONNELS (qui décrivent les fonctions)
Au niveau conceptuel
le Modèle de Contexte (MC) : où le domaine d’étude est vu comme une boite
noire. On ne représente que les flux extérieurs au domaine.
le Modèle de Flux Conceptuel (MFC) : ou encore diagramme de flux de
données (DFD) où l’on détaille les activités du domaine d’étude. On représente
aussi les flux internes au domaine.
Objectifs
Représentation des mouvements de données à l'intérieur d'un système
d'information et entre ce système et son environnement.
permet de décomposer le système en sous-systèmes, de formaliser les flux
d'informations entre ces sous-systèmes.
18
Utilisation du modèle
Au démarrage de l'étude : pour déterminer le domaine d'étude

(correspondant la plupart du temps à un domaine fonctionnel).
En fin d'analyse du système actuel : pour déterminer les activités

existantes.
Au début de l'analyse du système futur : pour préciser les contours

du domaine d'étude

Le Modèle de contexte (MC) sert à représenter les interactions entre le domaine
d'étude et l’environnement, et entre le domaine d'étude et les éventuels domaines
connexes (appelé aussi Modèle de Flux de niveau 0).
Le domaine d'étude y est représenté comme une boîte noire.
Les différents concepts
Acteur
externe 1
DOMAINE DE
flux L'ETUDE
Acteur
externe 2
Domaine
connexe 1
19
Modèle de Flux Conceptuels
Concepts associés
Domaine d'étude Domaine d’étude
Sous-ensemble cohérent de l'entreprise ou de l'organisme, bien délimité et formant le

contenu à étudier.
Il est:
précisé en fin d'analyse du système actuel,

modifié éventuellement au début de l'analyse du système futur par la suppression
ou l'ajout d'activités.
Il doit:
correspondre à un projet de taille réaliste,
être informatiquement opérationnel indépendamment du développement sur les

autres domaines,
minimiser les perturbations dans l'organisation lors de sa mise en place,

Concepts associés
Acteur externe
Un acteur externe est un élément émetteur ou récepteur de données, situé hors
du système d'information étudié.
Acteur Externe
Domaine connexe
Un domaine connexe est un composant du système d’information interagissant
avec le domaine d’étude . C’est un acteur interne à l’entreprise, mais externe
au domaine d’étude.
Domaine connexe
20
Concepts associés
Flux de données
Un flux est un transfert d’informations entre composants du système. Le
composant peut être un domaine, une activité ou un acteur externe .
Flux
Remarque
on ne fait pas apparaître les flux entre acteurs externes et domaines
connexes, ou entre les domaines connexes.
Modèle de Flux Conceptuels (MFC)

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

activités. Il n’y a pas ici de notion d’organisation mais d’objectifs à réaliser. On
représente les flux entre activités et avec l’environnement.
Pour analyser les communications et les activités, on procède par « zooms » successifs
sur le domaine étudié pour élaborer des modèles de plus en plus détaillés qui
permettront d'avoir une cartographie détaillée du système et de préparer le passage au
modèle conceptuel de représentation des traitements.
21
Un MFC détermine, par affinages successifs des activités, la composition du domaine d'étude
sans décrire le comportement.
On appelle diagramme de flux 1 (DFD1), le diagramme de 1er niveau décrivant les macros
activités du domaine d'étude et les flux échangés.
On appelle diagramme de flux (DFDi), tout diagramme qui affine une activité.
Le modèle de contexte est également appelé le diagramme de flux de données de niveau 0.
MODELE DE CONTEXTE
MODELE DE FLUX
DF1
DF2 DF2
DF3 DF3

Concepts associés
Domaine d’étude (définition 2)

Représente les domaines d’activités concernés par le projet. Le domaine
d’activité est lui même composé de plusieurs activités. Ainsi, le domaine
d’étude « gestion commerciale » peut être composé de : Gestion des
commandes, Gestion des factures, Gestion des comptes client.
Activité
L'activité est un ensemble de traitements homogènes qui transforment ou
manipulent des données.
La décomposition d'une activité doit être indépendante des autres, mais peut
par contre entraîner la décomposition des flux entrants et sortants.
22
Mécanisme de décomposition : Pourquoi décomposer ?
La décomposition d’un domaine ou d’une activité en plusieurs activités peut faire

apparaître de nouveaux flux dus :
à l’échange d’informations entre activités

la décomposition d’un flux présent au niveau n en plusieurs flux au niveau n+1.
Pour préparer le passage à la modélisation de la dynamique du système.
Pour faciliter la communication par une progression maîtrisée vers le détail du

système.

Mécanisme de décomposition : Jusqu’où décomposer ?
Le niveau d'arrêt de la décomposition avec ce formalisme est le moment où

l'activité correspond à une opération (au sens Merise) et donc vérifie la règle
d'ininterruption (dès lors que le traitement est déclenché, il se déroule sans attente
de ressources complémentaires extérieures - cf. MCT -). A partir de ce moment il
devient nécessaire de passer à la modélisation dynamique du système.
Remarque :
On peut également s’arrêter un « cran » avant c’est à dire au moment où les
activités correspondent à des processus (cf. MCT).
23
1 6
0 1
2 0
2
Le Modèle Conceptuel des
Traitements
Le Modèle Conceptuel des Traitements (MCT))

Les modèles dynamiques :
Au niveau conceptuel : décrire l'activité de l'entreprise en éliminant les
considérations d'organisation telles que la répartition du travail, le déroulement
dans le temps, la nature des tâches... et bien sûr les contraintes techniques.
La modélisation des aspects dynamiques repose sur les concepts

d'évènements vus comme des stimulateurs de l'activité.
Le MCT :
Obtenir une représentation de l'enchaînement des opérations du système et des
conditions du déclenchement de son activité par des stimulations extérieures, les
évènements.
24
Le MCT
Concepts associés
synchronisation
événements
opération
émission
résultat
Le MCT
Concepts associés
Evènement
Représentation d'un fait nouveau et porteur d'informations pour le système.

Ex : Arrivée d'une déclaration de sinistre dans une compagnie d'assurance. Cet
évènement est porteur d'informations concernant l'assuré, le bien assuré...
Pour qu'il y ait évènement :
il doit se produire quelque chose (à l'extérieur ou à l'intérieur de l'organisation)

ce fait doit être perçu par le système (qui devra donc se doter des moyens appropriés
de le percevoir)
ce fait n'intéresse le système que dans la mesure où il est identifié comme un
déclencheur possible de son activité.
25
Le MCT
Concepts associés
Plusieurs types d'évènements :
Les évènements que le système perçoit en provenance de l'extérieur : les

évènements externes
Le résultat d'une opération peut participer en tant qu'évènement au

déclenchement de l'opération suivante. On parle d'évènement interne. Ce
type d'évènement ne peut déclencher l'opération suivante que s'il est combiné
avec au moins un autre évènement.
Un résultat ne participant pas à la poursuite de l'activité du système sont

destiné à être émis vers l'extérieur : on parle alors d'évènements résultats ou
simplement de résultats.
Mr. Saidane 51
Le MCT
Concepts associés
Synchronisation
Le déclenchement d'une opération peut être conditionné par plusieurs
évènements.
Représenter les conditions d'entrée, c'est à dire préciser les associations
d'évènements dont la présence est indispensable au déclenchement de l'opération.
La synchronisation est à la fois une association d'évènements "candidats" et
une expression booléenne formée à partir des opérateurs ET et OU.
Rapport d’expertise Facture de réparation Dossier
a b c
A ET b ET C
26
Le MCT
Concepts associés
Opération
La réponse à l'arrivée d'un évènement est le déclenchement d'un bloc de
traitements.
Une opération = un bloc de traitement

une séquence continue d'actions et qui doit s'exécuter sans interruption
(principe de non interruptibilité) dès qu'elle est déclenchée (pas d'attente
d'évènement externe).
aboutit à l'émission d'évènements internes (poursuite de l'activité) ou de
résultats (signaux vers l'extérieur).
L'ensemble des évènements rattachés à une opération peut être considéré comme
les ressources nécessaires au bon déroulement de l'opération.
La production de résultats peut être soumise à des conditions de sortie de

l'opération appelées règles d'émission.
Le MCT
Concepts associés
Opération (suite)
Une opération est donc décrite par :

sa désignation (un libellé + éventuellement un code)
les actions élémentaires descriptives des travaux à accomplir; ces actions sont
essentiellement des actions sur les données (consultation, mise à jour). Dans les
schémas elles sont très souvent omises.
les évènements émis (évènement internes ou résultats) et les conditions de ces
émissions.
27
Le MCT
Concepts associés
Opération (suite)
Déclaration de sinistre
A ET b ET C
opération
Vérifier la garantie
émission
Risque couvert Risque non couvert
Sinistre Sinistre
accepté Dossier rejeté Lettre de
ouvert rejet
Le MCT
Concepts associés
Expression des opérations
Vérifier la garantie OPC1 Vérifier la garantie Code + libellé
opération -Vérifier existence du client

- vérifier que le bien est assuré
actions
-Vérifier la garantie du bien
…
Vérifier la garantie Règles
d’émission
Opération
avec règles
d’émission
28
Le MCT
Concepts associés
Opération : L’opération n’est pas interruptible
Aucun évènement ne peut être pris en charge au cours de l’exécution d’une
opération.
Une opération doit s’exécuter du début jusqu’à la fin sans interruption.
E1 E2 E1 E2 E3
* *
Opération X Opération X
Action_1 Action_1
Action_2 Action_2
Action_3 Action_3
E3
Action_4 Action_4
Représentation incorrecte Représentation correcte

Le MCT
Concepts associés
Lorsque des règles de gestion s’exécutent sans interruption, elles doivent
appartenir à une même opération. E1 E2
Cette représentation est incorrecte du fait qu’il n’y pas
d’interruption réelle au niveau de l’exécution des 2 lots *
de règles de gestion. Opération Y
Action_1
Action_2
*
Opération Z Rx
Action_3
Action_4
Ry Rz
29
Le MCT
Concepts associés
Deux solutions sont possibles :
1) Unifier les deux opérations en une seule opération exécutant Action_1,

Action_2, Action_3 et Action_4 sans interruption et produisant les résultats Rx,
Ry et Rz.
E1 E2
*
Opération Y2
Action_1
Action_2
Action_3
Action_4
Rz Rz Rz
Le MCT
Concepts associés
2) Faire appel à un autre évènement oublié au niveau de la synchronisation de
l’opération z.
E1 E2
*
E0
Opération Y
Action_1 *
Action_2 Opération Z2
Action_3
Rx
Action_4
Ry Rz
30
Le MCT
Concepts associés
Opération périodique
Dans certains cas le déclenchement d’une opération n’est pas conditionné par l’arrivée
d’un évènement externe, c’est le cas pour des opérations périodiques qui sont exécutées à
intervalle de temps régulier.
On dit qu’elles sont déclenchées par un évènement « calendaire » ou « temporel ».
Exemple
Début de Payement
période accepté
*
Remise_En_Banque
Moyen de paiement
remis en banque
Le MCT
Concepts associés
Processus
enchaînement synchronisé d'opérations
représente une unité de préoccupation de l'entreprise.
Il est propre à un domaine d'activité.
E1
Syn. 1
Opértion
R1
Syn. 2
31
Le MCT
Concepts associés
Domaine / Processus
Si le domaine est vaste, on le découpe en plusieurs sous-domaines chacun décrit par un
processus.
Exemple : Commercialisation des produits d'une entreprise.
Les sous-domaines à distinguer sont l'activité commerciale, la facturation.
facture
règlement facturation
processus 1
client
double commande
commande
vente vente
processus 2
Le MCT
Exemple (suite)
L'ensemble des événements, opérations et résultats décrivant un processus
constitue le modèle conceptuel de traitements de ce processus.
commande
validée
•On rappelle qu'une opération n’est pas interruptible. La
facturation ne nécessite pas le paiement, mais l'émission
du reçu ne peut s'effectuer qu'après celui-ci. Il y a donc
facturé présence de deux opérations : l'une générant la facture,
l'autre le reçu.
règlement
facture
•Remarque : facture est à la fois un événement résultat
ET
(transmis à l'extérieur) et un événement interne
participant au déclenchement de l'opération suivant. Cette
encaissé double flèche traduit la règle de gestion imposant la
facturation préalable à l'encaissement.
reçu
32
Le MCT
La consommation
Un évènement peut être candidat au déclenchement de plusieurs opérations
…mais une occurrence de cet évènement ne peut prendre part qu'à une seule de
ces opérations. On dit qu’il y eu consommation de l’événement.
demande contrat •Cette représentation n'est acceptable que si les
deux situations ne peuvent avoir lieu simultanément.
Dans l’exemple le client ne peut pas simultanément
étudier la demande donner son accord et ne pas donner suite à la
évènement
proposition.
consommable
proposition
accord fin de validité

client
ET ET
ouvrir police annuler la proposition
police ouverte proposition annulée
Le MCT
Démarche d'élaboration du MCT
Le plus simple est de partir des modèles de flux.

Le point d'arrêt de la décomposition avec le formalisme du MFC
correspond au moment où l'activité peut être assimilé à une opération et
est donc ininterruptible,
mais le dernier niveau utile pour passer au MCT est plutôt le
niveau précédent, celui où l'activité peut être assimilé à un
processus.
Le modèle de flux ne permet pas d'exprimer la notion de temps et de

séquence. On doit alors passer à un raisonnement évènementiel et faire
intervenir le temps, les règles de synchronisation et les règles d'émission.
33
Le MCT
Démarche d'élaboration du MCT
A partir du MC
Pour chaque évènement entrant, rechercher les actions effectuées.
Vérifier que tous les évènements sortants sont produits.
Rajouter au besoin les évènements calendaires.
Dossier
Résultat_bac
Candidat Avis(accord/refus)
Scolarité
Dossiers_complets
Président listes
Le MCT
…A partir du MC
dossier
Vérifier pièces
Complet incomplet
Dossier rejeté
Dossier complet listes Résultats_bac
Et
Enregistrement résultats
résultat
34

Langue

Conception Des Systemes Dinformation La

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Des Systemes Dinformation La

Transféré par

Droits d'auteur :

Formats disponibles

Institut Supérieur des Sciences Appliquées et de Technologie de Sousse

2 0 Conception des systèmes

Enseignant : Mr. Saidane

Mr. Saidane 2ième prépa- A.U. 2015-2016 2

MERISE/2 : Modèles et Techniques MERISE avancés / Georges Panet, Raymond

De l'autre côté de MERISE, Système d'information et modèles d'entreprise / Yves

La méthode MERISE / tome 1 : Principes et outils, tome 2 : Démarche et Pratiques /

L'essentiel sur MERISE / Dominique Dionisi / Eyrolles 1994

Parlez-vous MERISE ? / M. Diviné / Eyrolles

Institut Supérieur des Sciences Appliquées et de Technologie de Sousse

Enseignant : Mr. Saidane

Exemple : le système "d'entreprise"

Mr. Saidane 2ième prépa- A.U. 2015-2016 5

Mr. Saidane 2ième prépa- A.U. 2015-2016 6

J.L Le Moigne propose en 1977 de définir un système comme :

Mr. Saidane 2ième prépa- A.U. 2015-2016 7

Le concept de SI d'une organisation recouvre deux notions :

l'organisation réelle se transformant, agissant, communiquant et mémorisant des

le système construit par l'homme pour représenter les actions, la communication et la

Mr. Saidane 2ième prépa- A.U. 2015-2016 8

Une partie du S. d'information peut être informatisé.

Mr. Saidane 2ième prépa- A.U. 2015-2016 9

Mr. Saidane 2ième prépa- A.U. 2015-2016 10

Cycle de vie : démarche par étapes : de l'étude de l'objet naturel à l'intégration du

Ingénierie des systèmes d’informations

supporter le cycle de vie des systèmes d'information des organisations

Mr. Saidane 2ième prépa- A.U. 2015-2016 11

Mr. Saidane 2ième prépa- A.U. 2015-2016 12

réalisation technique mise en place

Mr. Saidane 2ième prépa- A.U. 2015-2016 13

Une démarche : succession d'étapes permettant progressivement de décrire le

Des modèles : permettant d'établir des abstractions du système étudié.

Exemple : SADT, MERISE, OMT...

Mr. Saidane 2ième prépa- A.U. 2015-2016 14

Méthode d'Étude et de Réalisation

Mr. Saidane 2ième prépa- A.U. 2015-2016 15

Mr. Saidane 2ième prépa- A.U. 2015-2016 16

Démarche : succession d’étapes :

Formalisme : défini par:

Mr. Saidane 2ième prépa- A.U. 2015-2016 17

Mr. Saidane 2ième prépa- A.U. 2015-2016 18

Niveau global de l’entreprise

Domaine d’étude : Définition, Articulation des domaines

Mr. Saidane 2ième prépa- A.U. 2015-2016 19

PHASE 1 : ETUDE DE L'EXISTANT (observation)

Mr. Saidane 2ième prépa- A.U. 2015-2016 20

PHASE 1 : ETUDE DE L'EXISTANT

Modèle Conceptuel des Données : Liste des entités, associations,

Mr. Saidane 2ième prépa- A.U. 2015-2016 21

PHASE 2 : SOLUTIONS FUTURES (conception,

Diagnostic et critique des règles de gestion existantes

Prise en compte de nouvelles règles de gestion, de nouveaux

Nouveaux modèles conceptuels : Flux, Traitements, Données

Mr. Saidane 2ième prépa- A.U. 2015-2016 22

PHASE 2 : SOLUTIONS FUTURES (suite)

Proposition de plusieurs scénarios :

Architecture matérielle et logicielle

Modèles Organisationnels des Flux et des Traitements, modèle Logique des

Rédaction du cahier des charges

Mr. Saidane 2ième prépa- A.U. 2015-2016 23

Spécifications fonctionnelles en respectant les solutions retenues à

décrit la globalité du projet

Spécification des procédures transitoires