Ce document pédagogique est destiné aux étudiants en Génie Informatique de l'Université Sidi Mohamed Ben Abdellah, suivant le cours de Systèmes d'information. Il introduit les principes fondamentaux de la modélisation des Systèmes d'Information.
Le contenu explore le Modèle Conceptuel de Traitements (MCT), précédé d'une présentation des Modèles de Flux (MF). Il aborde les concepts clés : acteurs, événements, opérations, résultats et synchronisation. Des exemples illustrent l'application pratique de ces outils de la méthode MERISE.
Modélisation Merise : Cours Modèle Conceptuel de Traitements MCT
Télécharger PDFLe Modèle Conceptuel de Traitements (MCT) en Conception de Systèmes d'Information
Ce cours est dédié à la modélisation des systèmes d'information, plus spécifiquement au Modèle Conceptuel de Traitements, un élément clé de la méthode MERISE.
Introduction : Les Modèles de Flux
Les modèles de flux représentent les interactions et les échanges au sein d'un système ou entre différents systèmes, constituant ainsi la base de l'étude d'un projet.
- Le Modèle des Flux de Données (MFD) aide à définir le périmètre du système à modéliser en identifiant ses frontières et en le décomposant en sous-systèmes.
- Le diagramme de flux est une représentation graphique des acteurs et des échanges de flux.
Concepts du Modèle de Flux
Le modèle de flux, souvent désigné par MCC (Modèle Conceptuel de Communication) ou DF (Diagramme de Flux) / MFD, repose sur plusieurs concepts fondamentaux :
- Le domaine fonctionnel : Il s'agit d'un découpage logique de l'organisation étudiée.
- L'activité : Un ensemble homogène de traitements visant à transformer ou manipuler des données.
- L'acteur : Représente une entité active (personne, service, système externe) qui intervient dans le fonctionnement du système.
- Le flux : Symbolise un échange entre deux acteurs. Ces échanges peuvent être de diverses natures : matière, finance, personnel, actif (matériel, savoir) ou information.
Focus sur les Flux d'Informations
Dans le cadre de l'analyse des flux selon la méthode MERISE, l'accent est principalement mis sur les flux d'informations. Si d'autres types de flux (matière, finance) sont cruciaux, ils doivent être représentés par les informations qui les accompagnent ou les déclenchent.
En résumé : Rôle des Modèles de Flux (MF)
Les Modèles de Flux (MF) illustrent les échanges entre systèmes fonctionnels, qu'ils soient internes ou externes à l'organisation (partenaires).
- Ces flux peuvent concerner des produits, de l'énergie, du personnel, des valeurs ou des informations.
- Les systèmes fonctionnels impliqués sont soit externes (partenaires), soit internes (domaines, sous-domaines).
- Les messages d'information échangés peuvent être "informants" (porteurs de données) ou "enclencheurs" (déclenchant une action).
Exemple de Représentation Graphique d'un Flux
Considérons un scénario client-entreprise :
- Un client passe une commande.
- Le service commercial peut accepter ou refuser la commande.
- Si la commande est acceptée, le magasin gère l'expédition des marchandises et le bon de livraison.
- Le magasin réceptionne également les retours de marchandises du client.
Cet exemple illustre les flux d'information et de matière entre le client, le service commercial et le magasin.
Matrice des Flux Organisés
La matrice des flux organisés permet de visualiser de manière structurée les échanges entre différents acteurs. Elle indique quels acteurs envoient et reçoivent quels types de flux.
Par exemple, entre :
- Client et Facturation : Le client reçoit une facture, la facturation envoie une facture et une demande de facturation au Magasin.
- Client et Caisse : Le client envoie un chèque.
- Caisse et Banque : La caisse envoie une remise de chèque à la Banque.
- Magasin et Transporteur : Le magasin envoie un ordre de livraison au Transporteur, le Transporteur fournit un bon de livraison au Client.
Le Modèle Conceptuel de Traitements (MCT) : Objectifs
Les MCT ont pour but de détailler les activités au sein du domaine d'étude. Ils constituent un "zoom" sur le modèle de flux.
- Alors que les modèles de flux montrent les messages échangés entre acteurs, les MCT décrivent comment un acteur interne réagit à la réception de ces messages et quelles opérations il exécute.
- Le MCT est donc essentiel pour comprendre le comportement dynamique du système d'information.
Introduction aux Traitements dans MERISE
Le terme "traitement" est souvent assimilé à la simple transformation de données, impliquant la description d'un algorithme.
Cependant, dans la méthode MERISE, le concept de traitement est plus large :
- Il se rapporte au fonctionnement global du Système d'Information (SI) en lien avec le système opérant (les processus métier réels) et le système de pilotage (les décisions de gestion).
- Décrire les traitements, c'est documenter les processus déclenchés au sein du domaine en réponse aux événements et stimulations de son environnement.
Formalisme du MCT
Le formalisme de MERISE pour le MCT est une représentation graphique inspirée des réseaux de Pétri. Il offre des avantages significatifs :
- Il permet une vérification formelle de la cohérence des modèles.
- Il autorise une simulation pas à pas des activités du Système d'Information.
Les MCT sont généralement spécifiés à deux niveaux :
- Le niveau processus (macro-découpage).
- Le niveau opération conceptuelle (détail des activités).
Les Concepts de Base du MCT
Le Modèle Conceptuel de Traitements s'articule autour de plusieurs concepts fondamentaux :
- L'acteur
- Le processus
- L'événement / Résultat-message
- L'opération
- La synchronisation
Les Acteurs dans le MCT
Dans un MCT, seuls les acteurs externes au domaine d'étude sont pris en compte, à l'exception du système de pilotage. Les acteurs internes, bien qu'identifiés dans l'analyse des flux pour leur rôle organisationnel, sont abstraits au niveau conceptuel afin de se concentrer sur la logique des traitements.
Le Processus
Définition : Un processus est un ensemble structuré d'événements, d'opérations et de résultats consécutifs qui concourent à un même but. Il représente un sous-ensemble d'activités de l'organisation, délimité par des événements initiaux et des résultats finaux qui marquent un état stable du domaine.
- Le découpage en processus est souvent intrinsèque au secteur d'activité de l'organisation et est considéré comme un invariant pour le concepteur.
- Exemple : Dans le domaine de l'assurance automobile, on peut identifier des processus comme la prospection, la gestion des contrats et la gestion des sinistres.
Critères de Découpage d'un Processus
Un processus est défini comme l'ensemble des opérations qui traitent un type spécifique d'événement externe.
Exemple : Le processus de "prêt" inclut toutes les opérations consécutives à une demande de prêt, telles que :
- L'élaboration du devis.
- L'instruction du dossier de prêt.
- La mise en place du prêt.
L'Opération Conceptuelle
Définition : Une opération est la représentation d'un ensemble de traitements exécutés par le système en réaction à un ou plusieurs stimuli. Elle décrit le comportement du domaine et de son Système d'Information face à des types d'événements spécifiques.
- Une opération est déclenchée par la survenance d'un événement, ou par la synchronisation de plusieurs événements.
- Elle est effectuée par un intervenant interne, un domaine ou un sous-domaine.
- Une opération englobe toutes les activités que le domaine peut réaliser en exploitant les informations portées par l'événement et celles déjà présentes dans la mémoire du SI.
Contenu d'une Opération Conceptuelle
Une opération est définie par un ensemble de fonctions qui peuvent inclure :
- Des décisions
- Des règles de gestion
- Des actions sur les données mémorisées
- Des traitements sur les données
- Des actions diverses
Exemples : L'élaboration d'un devis ou l'instruction d'un dossier de prêt.
La segmentation en plusieurs opérations n'est justifiée que par l'attente d'informations complémentaires, issues d'événements nécessaires à la poursuite de l'activité. Une opération peut produire plusieurs messages en sortie, constituant des résultats.
Les notions rattachées à l'opération sont :
- Les événements
- La synchronisation
- Les résultats
Exemple d'Opération de Commande
Si une commande de fruits est l'événement déclencheur de l'opération "Vendre", les résultats possibles de cette opération pourraient être :
- Un ordre de livraison
- Un ordre de réapprovisionnement
- Une proposition de produit de substitution au client
Ainsi, la "commande" est l'événement, et l'"ordre de livraison" ou la "proposition de substitution" sont les résultats de l'opération "Vendre".
L'Événement
Définition : Un événement est la représentation d'un fait nouveau, ou stimulus, qui franchit la frontière du domaine à un instant donné et provoque une réaction. Un événement est toujours émis par un acteur et est destiné au domaine.
- Chaque événement est porteur d'un message, qui est l'ensemble des informations reçues lors de sa réalisation.
- Exemple : L'événement "réception d'un client demandant un prêt" contient un message incluant les informations client, le montant du capital, la durée du prêt et le type d'amortissement.
Types d'Événements
On distingue trois catégories d'événements :
- Événements externes : Proviennent d'un acteur extérieur à l'organisation ou au champ d'étude, et ont un caractère aléatoire.
- Événements internes : Restent au sein du domaine pour assurer la continuité d'un processus. Ils sont nécessaires au découpage en opérations, agissent comme le résultat d'une opération précédente et servent de liaison, sans avoir le caractère de "fait nouveau".
- Événements "artificiels" : Sont basés sur une date ou un compteur.
Exemples d'événements artificiels :
- Date : Un mois après l'envoi d'une proposition, une lettre de relance est envoyée.
- Compteur : Après trois relances, une lettre de mise en demeure est expédiée.
Ces événements artificiels reflètent des choix de gestion ou des contraintes externes à l'organisation.
Attention : Événement vs. Ressource
Il est crucial de ne pas confondre un événement avec une ressource nécessaire à la réalisation d'une opération.
Exemple : Pour élaborer une offre de prêt, la vérification du fichier client pour un éventuel interdit bancaire est une étape. Le fichier client est une ressource, pas un événement, car il ne constitue pas un fait nouveau ou un stimulus déclencheur.
Le Résultat
Définition : Le résultat est la formalisation de la réaction du domaine (d'une opération) à un événement ou à un ensemble d'événements synchronisés. Un résultat est émis par une activité du domaine et est destiné à un acteur.
- Un résultat est porteur d'un message, qui contient l'ensemble des informations produites au moment de l'émission du résultat.
- Dans le cas fréquent où le résultat est matériel (ex: un produit), c'est le message qui l'accompagne qui est modélisé.
Exemple de Résultat
- Résultat : Une lettre envoyée au client.
- Message : Contient le nom, l'adresse du client et la nature de la décision.
Types de Résultats
On distingue :
- Les résultats externes : Destinés à un acteur extérieur au domaine d'étude.
- Les résultats internes : Permettent d'assurer la continuité du processus. Ils peuvent être un flux destiné à une autre opération ou une mise à jour du Système d'Information, rendue disponible pour les opérations futures.
Exemples de Résultats
- Résultat externe : Une lettre d'acceptation de prêt envoyée au client.
- Résultat interne (flux) : Un bordereau de remise de chèques.
- Résultat interne (mise à jour du SI) : Un dossier client est ouvert.
Interaction Événement/Résultat
Considérons l'exemple d'une compagnie d'assurance :
- L'assuré (acteur) envoie une "Déclaration d'accident" (événement) au "Domaine assurance auto".
- En réaction, le domaine génère un "chèque" (résultat) qui est envoyé à l'assuré (acteur).
Condition d'Émission des Résultats
Une opération peut générer plusieurs messages de sortie ou résultats. L'émission d'un résultat dépend de certaines conditions, qui peuvent être basées sur les informations du message reçu, des données mémorisées ou des règles de gestion non formalisées. Ces conditions peuvent être exprimées par des expressions logiques.
- Plusieurs résultats de nature et de destination différentes peuvent être émis sous une même condition.
- La présence d'une condition (un test) dans le déroulement des activités ne justifie pas, au niveau conceptuel, une segmentation en différentes opérations.
Exemple de Conditions d'Émission
Pour une opération de "Prise de commande" de fruits :
- Si "fruits en stock" est vrai, un "Ordre de livraison" est émis.
- Si "Pas de fruits en stock" est vrai, une "Proposition de produit de substitution" est émise, ainsi qu'un "Ordre de réapprovisionnement".
Un autre exemple concret :
- Une "Demande de prêt" déclenche l'"Instruction du prêt".
- Si l'instruction est "OK", le "Prêt en gestion" est activé et un "Échéancier" est produit.
- Si l'instruction n'est "OK", le "Prêt est refusé" et un "Courrier client" est envoyé.
Les conditions d'émission des résultats découlent de règles de gestion complexes, parfois difficiles à représenter graphiquement. Par exemple : "Le courrier est envoyé au client si le prêt est refusé, si la demande a été formulée par courrier ET s'il s'agit d'une demande individuelle."
La Synchronisation
Définition : La synchronisation représente une pré-condition pour l'activation d'une opération qui requiert plusieurs événements. Elle permet de découper un processus en plusieurs opérations et est spécifiée par le nom des événements et un prédicat qui précise leur participation.
- La synchronisation est traduite par une expression logique (utilisant ET, OU, NON) qui s'applique sur la présence ou l'absence des occurrences d'événements sollicitant l'opération.
- Si la condition de synchronisation est vérifiée, l'opération peut démarrer, et les occurrences d'événements déclencheurs (avec leurs messages associés) sont "consommées".
- Si la condition n'est pas vérifiée, la synchronisation et les occurrences d'événements restent en attente jusqu'à ce que la condition soit remplie.
Exemple de Synchronisation pour un Prêt
La mise en place d'un prêt ne se fera que si trois conditions sont simultanément remplies :
- La proposition de prêt est établie.
- Le délai de réflexion légal est écoulé.
- Le client a donné son accord.
Si, par exemple, le délai de réflexion est écoulé mais l'accord du client n'est pas encore reçu, l'opération restera en attente.
La synchronisation peut être formulée ainsi : "Proposition ET Délai de réflexion écoulé ET Accord client" mène à l'"Mise en place du prêt", qui elle-même mène à l'"Enregistrement du prêt" et place le "Prêt en gestion".
Description Structurée d'un Composant MCT
Un composant typique dans un MCT (représentant une opération) inclut :
- Les événements contributifs entrants.
- La synchronisation (expression logique).
- L'opération (nom et fonctions : fonction 1, fonction 2, etc.).
- Les résultats émis, chacun avec sa condition d'émission et sa destination.
- Les acteurs associés (émetteurs d'événements ou récepteurs de résultats).
Synchronisation : Notion de Consommation
Une fois qu'une opération est déclenchée, l'événement qui l'a initiée peut être mémorisé dans le SI, mais il perd son caractère de stimulus. On dit que l'événement est "consommé".
Cette notion est importante car elle permet qu'un même événement puisse potentiellement être en entrée de plusieurs opérations. Seule l'opération pour laquelle la synchronisation est réalisée en premier sera activée, consommant ainsi l'événement.
Exemple Avancé de Synchronisation avec Consommation
Considérons un scénario avec une "Proposition" de prêt :
- Chemin A : Si ("Accord client" ET "Délai de réflexion écoulé"), alors l'opération "Mise en place du prêt" est déclenchée, menant à l'"Enregistrement du prêt" et au "Prêt en gestion".
- Chemin B : Si ("Délai commercial écoulé" ET NON "Accord client"), alors l'opération "Invalidation de la proposition" est déclenchée, menant à la "Proposition invalidée" et potentiellement à une "Suppression".
Ici, la "Proposition" peut être consommée par l'un des deux chemins en fonction des événements ultérieurs.
Exercice de Modélisation de Synchronisation
Problème : Pour aller au cinéma, j'ai besoin de l'accord de ma mère et de celui de mon père. Cependant, l'accord de ma grand-mère paternelle peut remplacer celui de mon père.
Modélisation avec synchronisation :
Soient :
- `a` = Accord de la grand-mère
- `b` = Accord du père
- `c` = Accord de la mère
L'opération "ALLER AU CINEMA" est déclenchée si la condition de synchronisation suivante est remplie : `(a OU b) ET c`.
Règles de Base pour la Description d'une Opération Conceptuelle
Pour une description complète et cohérente d'une opération conceptuelle, les éléments suivants doivent être définis :
- Le code de l'opération.
- Son libellé.
- Sa définition précise.
- Le domaine auquel elle appartient.
- La liste des actions qu'elle effectue.
- La liste des événements en entrée et leur provenance.
- La définition de la synchronisation (prédicat).
- La liste des résultats produits, avec leur condition d'émission et leur destination.
Transition du Modèle de Flux (MF) au Modèle Conceptuel de Traitements (MCT)
La construction du MCT à partir du MF suit des étapes structurées :
- Traduire les flux entrants du MF en événements pour le MCT.
- Traduire les flux sortants du MF en résultats pour le MCT.
- Intégrer les contraintes légales ou réglementaires comme des événements artificiels.
- Découper chaque processus en opérations conceptuelles, en s'assurant que chaque opération est non-interruptible par un événement externe.
Règles de Syntaxe du MCT
Pour garantir la validité d'un MCT, plusieurs règles de syntaxe doivent être respectées :
- Un acteur doit émettre au moins un événement ou recevoir au moins un résultat.
- Un événement doit provenir d'au moins un acteur.
- Un résultat doit provenir d'au moins une opération.
- Tout résultat doit avoir au moins une destination : un acteur, une opération ou une synchronisation.
- Une opération est déclenchée soit directement par un événement ou un résultat, soit par une synchronisation unique.
- Une synchronisation doit lier au moins deux événements ou résultats par une expression logique.
- Le MCT est dynamique et doit interagir avec son environnement.
- Les événements ne peuvent pas naître spontanément.
- Les résultats doivent être utilisés ; une expression logique associée à une synchronisation ou à l'émission d'un résultat ne peut jamais être toujours fausse.
Exemple d'Application : Gestion des Cartes Bleues
Considérons le processus de "Gestion des cartes bleues" pour illustrer l'application des concepts de flux et de traitements.
Scénario :
- Un demandeur souhaite obtenir une carte bleue et en fait la demande auprès de son agence bancaire.
- La carte bleue n'est accordée que si le demandeur est déjà client de l'agence.
- Chaque jour, l'agence transmet les demandes de ses clients au centre de gestion des cartes bleues.
- Dès réception de la carte bleue par l'agence (généralement 4 jours après la demande), l'agence adresse au client un avis de mise à disposition et un avis de prélèvement de la cotisation annuelle.
- Le client vient ensuite retirer sa carte.
- Si la carte n'est pas retirée dans un délai de 2 mois, elle est détruite.
Comment modéliser ce processus ?
1. Diagramme des flux (MF) :
- Acteurs : Demandeur/Client, Agence, Centre de gestion des cartes bleues.
- Flux :
- Demandeur/Client -> Agence : Demande de carte bleue.
- Agence -> Centre de gestion : Demandes de cartes bleues (quotidien).
- Centre de gestion -> Agence : Carte bleue.
- Agence -> Demandeur/Client : Avis de mise à disposition, Avis de prélèvement.
- Demandeur/Client -> Agence : Retrait de carte.
2. Modèle Conceptuel de Traitements (MCT) :
- Processus : Gestion des cartes bleues.
- Événements :
- "Demande de carte bleue" (externe, du client).
- "Réception carte bleue du centre" (interne, de l'acteur "Centre de gestion" vers l'"Agence").
- "Délai 2 mois écoulé" (artificiel, pour la destruction de la carte non retirée).
- Opérations :
- "Vérifier éligibilité et Transmettre demande" : Déclenchée par "Demande de carte bleue". Vérifie si le demandeur est client. Si oui, transmet la demande au centre de gestion.
- "Notifier client et Préparer retrait" : Déclenchée par "Réception carte bleue du centre". Émet un "Avis de mise à disposition" et un "Avis de prélèvement" au client. Déclenche un événement interne "Carte disponible" et met en place un événement artificiel "Délai retrait carte" (2 mois).
- "Remettre carte" : Déclenchée par "Retrait de carte" (client).
- "Détruire carte non retirée" : Déclenchée par l'événement artificiel "Délai 2 mois écoulé" et la condition "Carte non retirée".
- Synchronisation : L'opération "Détruire carte non retirée" est un exemple de synchronisation où le délai et l'absence de retrait agissent comme pré-conditions.
Cet exemple montre comment les flux initiaux sont transformés en événements et résultats, déclenchant des opérations soumises à des règles et synchronisations spécifiques dans le MCT.
Foire Aux Questions (FAQ) sur le MCT
Qu'est-ce qui distingue principalement un Modèle de Flux (MF) d'un Modèle Conceptuel de Traitements (MCT) dans la méthode MERISE ?
Le Modèle de Flux (MF), ou Modèle Conceptuel de Communication (MCC), décrit les échanges externes et internes (flux) entre les acteurs du système. Il met en évidence "qui échange quoi" avec "qui". En revanche, le Modèle Conceptuel de Traitements (MCT) approfondit la logique interne du domaine d'étude en expliquant "comment" le système réagit à ces flux. Il détaille les opérations (traitements) déclenchées par les événements et les résultats produits.
Quels sont les concepts clés pour décrire une opération conceptuelle dans un MCT ?
Une opération conceptuelle est décrite par son libellé, sa définition, et l'ensemble de fonctions qu'elle réalise (décisions, règles de gestion, actions sur les données). Elle est déclenchée par des événements (simples ou synchronisés) et produit des résultats. Les conditions d'émission des résultats et les mécanismes de synchronisation (expressions logiques) sont également des éléments fondamentaux pour caractériser son comportement.
Comment la notion de "consommation d'événement" et la "synchronisation" garantissent-elles la cohérence d'un MCT ?
La synchronisation est une pré-condition logique (ET, OU, NON) qui doit être satisfaite par un ensemble d'événements pour qu'une opération puisse se déclencher. Une fois l'opération activée, les événements qui ont permis cette activation sont "consommés", ce qui signifie qu'ils perdent leur caractère de stimulus et ne peuvent plus déclencher la même opération. Cette consommation garantit qu'une opération ne se déclenche qu'une fois pour un ensemble spécifique d'événements, assurant ainsi la cohérence et la progression logique des traitements dans le système.