INSIA – SIGL 2
La méthode MERISE MCT
Bertrand LIAUDET
| SOMMAIRE DCF ET MCT DIAGRAMME CONCEPTUEL CONCEPTUEL DES TRAITEMENTS | DES | FLUX | MODELE |
1
3
0. Introduction 3
1. Rappels - Les étapes du développement d’un logiciel 3
2. Rappels - Le cycle d’abstraction 4
3. La modélisation 5
4. Objectif du MCT : la description conceptuelle de l’entreprise : le QUOI 5
5. Les différents modèles et leurs relations 5
1. Le Diagramme Conceptuel des Flux – DCF (ou diagramme de contexte) 6
Description de l’activité de l’entreprise 6
Exemples de projet (cahier des charges) 6
Distinction entre système entreprise et système logiciel 6
Distinction entre acteur externe et acteur interne 7
Distinction entre la cause de l’activité et activité elle-même 8
Distinction entre le flux et l’activité 9
Diagramme conceptuel des flux (diagramme de contexte) : un seul acteur interne 10
Deux acteurs externes spéciaux : les échéances et les décisions 10
2. Tableau des processus 12
Processus 12
Flux IN (en entrée) et flux OUT (en sortie) 12
Le tableau des processus 12
Syntaxe et sémantique 12
Exemples 13
Validation du diagramme de contexte : découverte de nouveaux flux 14
Vérification syntaxique du tableau des processus 15
Erreur habituelle à éviter ! 15
3. Le Modèle Conceptuel des Traitements 16
Présentation 16
Exemple 16
Opération et règles de gestion 17
Activités, règles de gestion, fonctions 18
Événement – événement déclencheur (IN) – résultat (OUT) 18
Synchronisation 18
Exemples de synchronisation et de conditions de sortie 19
Formalisme général d’une opération 20
Présentation du MCT 20
MCT et MCD : MCT analytique 21
Vérification du MCT 21
Complément du modèle : la notion d’état 23
Expression d’un MCT 23
4.Exercices 25
Grande surface 25
Vente par correspondance des billets d’un tournoi de tennis. 25
Commandes des fournisseurs 25
Abonnements à l’opéra 26
Organisme de formation 26
Réparation automobile 26
Société Graphico 27
Première édition : décembre 2008
Il est facile de décrire la méthode MERISE de l’analyse organisationnelle, encore que son application exige à coup sûr savoir et pratique.
| 0. | Introduction |
| 1. | Rappels - Les étapes du développement d’un logiciel |
Il y a quatre distinctions capitales dans le développement d’un logiciel.
temps
Le projet se déroule dans le temps : il commence avec la conception, il se termine avec la réalisation.
La conception se divise en deux parties :
temps
| ANALYSE FONCTIONNELLE | ANALYSE ORGANIQUE |
| EXTERNE | INTERNE |
| Le QUOI | Le COMMENT |
| Point de vue de l’utilisateur et du client, le maître d’ouvrage, MOA : celui qui commande le logiciel | Point de vue de l’informaticien et du maître d’œuvre, MOE: celui qui réalise le logiciel |
| Build the right system | Build the system right |
L’analyse organique se divise en deux parties :
• L’architecture système (ou analyse organique générale): elle s’occupe de l’organisation des sous-systèmes logiciels et matériels du système complet.
Quatrième distinction : données versus traitements : l’analyse des données.
La dernière distinction est celle qui est faites entre les données et les traitements.
Le MCD va nous permettre de faire l’analyse fonctionnelle des traitements.
| 2. | Rappels - Le cycle d’abstraction | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| LE CYCLE D’ABSTRACTION | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Niveaux | DONNEES | TRAITEMENTS | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CONCEPTUEL QUOI | M C D Modèle conceptuel des données Signification des informations sans contraintes techniques, organisationnelle ou économique. Modèle entité – association | M C T Modèle conceptuel des traitements Activité du domaine sans préciser les ressources et leur organisation | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ORGA- NISATIONNEL QUI, OU, QUAND | M O D Modèle organisationnel des données Signification des informations avec contraintes organisationnelles et économiques. (Répartition et quantification des données ; droit des utilisateurs) | M O T Modèle organisationnel des traitements Fonctionnement du domaine avec les ressources utilisées et leur organisation (répartition des traitements sur les postes de travail) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| LOGIQUE COMMENT | M L D Modèle logique des données Description des données tenant compte de leurs conditions d’utilisation (contraintes d’intégrité, historique, techniques de mémorisation). Modèle relationnel | M L T Modèle logique des traitements Fonctionnement du domaine avec les ressources et leur organisation informatique. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PHYSIQUE COMMENT | M P D Modèle physique des données Description de la (ou des) base(s) de données dans la syntaxe du Système de Gestion des données (SG.Fichiers ou SG Base de Données) Optimisation des traitements (indexation, dénormalisation, triggers). | M P T Modèle physique des traitements Architecture technique des programmes
La modélisation est l’activité qui consiste à produire un modèle. Un modèle est ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose. On s’intéresse ici à la modélisation des traitements. Un modèle des données est une représentation de l’ensemble des traitements. Un modèle doit être systématique : d’une part, il concerne la totalité des traitements, d’autre part la lecture du modèle doit permettre de rendre compte de la réalité représentée (les traitements du monde réel) sans ambiguïté.
Lorsque quelqu’un essaye de faire comprendre ce qu’est son activité, le plus souvent il ne fait pas la distinction entre les contraintes d’ordre conceptuel, organisationnel, logique ou matériel. Le rôle de l’analyse fonctionnelle (du DCF et du MCT) sera de décrire l’activité du domaine indépendamment des contraintes organisationnelles (l’organisation des services de l’entreprise, par exemple), logiques (on envoie des courriers ou on envoie des mails) et matérielles (l’entreprise dispose d’un réseau informatique ou n’en dispose pas). • Objectif : représenter formellement les activités exercées par le domaine (l’entreprise ou une partie de l’entreprise). • Intérêt : la connaissance de ces activités est la base du système d’information. • Abstraction : le MCT fait abstraction de l’organisation, c’est-à-dire des moyens et des ressources nécessaires à l’exécution de ces activités. • Le QUOI : Le MCT exprime le QUOI et pas le PAR QUI, le QUAND, le OU ou le COMMENT.
DFD américain et DCF MERISEIl existe plusieurs modèles de représentation des traitements au niveau de l’analyse fonctionnelle : DCF et MCT (Diagramme Conceptuel des Flux Modèle conceptuel des traitements) Le DFD est à peu près équivalent au DCF. DCF et MCTOn va le voir, le DCF est la préparation du MCT.
Description de l’activité de l’entrepriseLa description de l’activité de l’entreprise est complexe : elle mélange les différentes activités, leurs causes, leurs conséquences, la façon dont elles sont réalisées en fonction de l’organisation de l’entreprise et des méthodes et techniques propres à l’entreprise. Cette description rend les choses difficiles à comprendre. L’objectif du DCF est de rendre compte de façon schématique et non ambiguë de l’activité de l’entreprise. Exemples de projet (cahier des charges)Une boulangerie produit des paquets de gâteaux maison qu’elle vend en magasin mais aussi enregistre la date du don, son montant ainsi que le nom et l’adresse du donateur. Une fois par correspondance. Elle souhaite informatiser son système de gestion des ventes par correspondance. Une association reçoit des dons de donateurs privés. Pour chaque don, l’association par an, le 15 janvier, l’association envoie des reçus fiscaux aux donateurs de l’année. Les reçus fiscaux précisent le nom et l’adresse du donateur, l’année fiscale, le montant et la date du don. Pour chaque don, on précise la date d’envoi du reçu fiscal. Toutes les données concernant les dons et les donateurs sont conservées. A l’occasion, l’association envoie des courriers aux donateurs (mailing). Pour chaque courrier, on conserve la date et le texte du courrier. On conserve aussi la liste de tous les donateurs à qui on a écrit. Dans ces cahiers des charges, il ne s’agit pas seulement de développer un logiciel, mais il s’agit aussi de mettre en place un nouvel outil, informatique, pour gérer l’entreprise. On peut distinguer 3 lieux : l’entreprise (le système entreprise), le monde extérieur et le logiciel (système logiciel). Ces trois lieux sont des abstractions concentriques : l’entreprise inclut le logiciel et le monde extérieur inclut l’entreprise. On va ensuite décrire les échanges entre ces trois lieux : • Le monde extérieur communique avec l’entreprise. • L’entreprise communique avec son système logiciel. • Le monde extérieur peut aussi communiquer directement avec le système logiciel (borne automatique, site internet…). Place du SIO et du SII dans le schémaLe SIO est un ensemble inclus dans le système entreprise. Le SIO contient une partie du système logiciel. Le SII, c’est la partie du système logiciel contenue par le SIO. Le SII est donc inclus dans le système logiciel. Place du DCF dans le schémaLe DCF décrit : • les relations entre le monde extérieur et le système entreprise considérée comme un tout. Le MCT ajoutera : • Les relations entres les activités de l’entreprise considérée comme un tout et la base de données. Distinction entre acteur externe et acteur interneLes acteursL’acteur est une unité active : il fait quelque chose. Les acteurs peuvent être : • des personnes : le client, le comptable, etc. • des services : le secrétariat, le service comptable, la banque, etc. • des machines : un lecteur de badge qui fait office de contrôle d’entrée, un site internet de vente en ligne dans une entreprise de VPC et de vente en magasin. Acteur externeLe monde extérieur est le lieu des acteurs externes : principalement le client, mais aussi les fournisseurs, etc. Acteur interneL’entreprise est le lieu des acteurs internes : le secrétariat, le service comptabilité, un lecteur de badge, un guichet automatique, etc. L’acteur peut être la source d’un échange avec un autre acteur ou le récepteur d’un échange avec un autre acteur. L’acteur peut transformer et/ou renvoyer les flux reçus. Exemple : Distinction entre la cause de l’activité et activité elle-mêmeActivitéL’activité, c’est le travail effectué à l’intérieur de l’entreprise. Tant que l’activité se déroule, le système n’est pas au repos : il est actif. Traitement, opération et tâche sont des activités. Cause de l’activité : l’événement déclencheurLes activités sont déclenchées par des événements. Avant l’événement déclencheur, le système est au repos. Production et fin de l’activité : les résultatsLes activités produisent des résultats. Le dernier résultat marque la fin de l’activité. A la fin de l’activité, le système retrouve la situation de repos. Exemple : une entreprise de vente par correspondance. Tant que l’entreprise n’a pas reçu de commande, elle est au repos (en considérant que toutes les autres tâches sont effectuées). Dès qu’on reçoit une commande, il s’agit d’un événement déclencheur. L’activité commence. L’activité consiste à traiter la commande : enregistrer les informations de la commande, préparer la remise en banque du chèque, préparer la livraison, remettre le chèque en banque, poster la commande. L’activité s’arrête avec la remise en banque du chèque et l’envoi de la commande. Distinction entre le flux et l’activitéL’activité L’activité concerne un acteur et un seul. Elle ne décrit pas un échange entre plusieurs acteurs. Le fluxLe flux décrit un échange entre deux acteurs. Il est émis par un acteur à destination d’un autre acteur. On ne s’intéresse qu’aux flux qui mettent en jeu au moins un acteur interne. Autrement dit, on ne s’intéresse pas aux flux entre les acteurs externes. Le flux est échange concret de quelque chose. On classe les flux en 5 catégories : • Matière (ce qui est transformé ou consommé) • Finance • Personnel • Actif (matériel ou savoir-faire nécessaire pour exercer l’activité) • Information Exemple : une entreprise de vente par correspondance (cf. exemple précédent)Il y a 3 flux dans cet exemple : • Du client vers l’entreprise : envoi d’une commande. • De l’entreprise vers la banque : dépôt d’un chèque. • De l’entreprise vers le client : envoi du produit commandé. Le premier flux correspond à un événement déclencheur. Les deux autres à des résultats. Diagramme de contexte Diagramme conceptuel des flux (diagramme de contexte) : un seul acteur interneLe DCF ou diagramme de contexte, c’est le schéma qui montre tous les flux du système, mais en faisant abstraction du détail des acteurs internes pour n’en considérer qu’un seul : l’acteur interne « entreprise ». Dans un DCF, on ne s’intéresse pas aux relations structurelles et chronologiques entre les flux : on ne cherche pas à savoir que Commande est suivi de Livraison et de Dépôt de chèque. Ces relations structurelles seront abordées dans le tableau des processus et dans le MCT. Par contre, on numérote tous les flux, du premier (n°1) au dernier (n°N). Diagramme Conceptuel des Flux (diagramme de contexte) Notion d’échéanceUne échéance est un événement particulier qui est à l’origine d’une activité dans l’entreprise. Par exemple : le 15 janvier est l’échéance de l’activité d’envoi des reçus fiscaux. L’acteur à l’origine de cet événement est un acteur externe de type « agenda ». Il porte le nom de l’événement qu’il produit. Notion de décisionUne décision est un événement particulier qui est à l’origine d’une activité dans l’entreprise. Par exemple : l’association décide, de temps en temps, de faire des mailings. L’acteur à l’origine de cet événement est un acteur externe de type « décision ». Distinction entre acteur opérant et acteur décisionnelIl faut noter qu’une même personne dans l’entreprise peut à la fois être acteur interne et acteur décisionnel. En tant qu’acteur interne, il est opérant. En tant qu’acteur externe, il est décideur.
ProcessusUn processus correspond à l’ensemble des activités réalisées par l’entreprise à partir d’un ou plusieurs événements déclencheurs et aboutissant à un ou plusieurs résultats. En principe, un processus trouve le système au repos et en attente et le laisse, une fois toutes les activités réalisées, à nouveau au repos et en attente. Flux IN (en entrée) et flux OUT (en sortie)Les flux à l’origine des événements déclencheurs sont les flux IN. Ce sont les flux qui vont du monde extérieur vers l’entreprise. Les flux à l’origine d’un résultat sont les flux OUT. Ce sont les flux qui vont de l’entreprise vers le monde extérieur. Le tableau des processusA partir d’un diagramme de contexte, un processus se décrit donc en précisant le ou les flux à l’origine du processus (IN) et le ou les flux à la sortie du processus (OUT). Dans le tableau des processus, on précise de façon générale, pour chaque processus, les activités menées par l’entreprise.
Syntaxe et sémantiqueLes processus (comme les flux) sont numérotés de 1 à N. Un processus a au moins un flux IN. Un flux IN est déclencheur d’une activité et une seule : il n’apparaît donc qu’une seule fois dans le tableau des processus. Un processus peut ne pas avoir de flux OUT (mais c’est rare : en général, quand l’entreprise est stimulée par le monde extérieur, elle répond en renvoyant quelque chose au monde extérieur). Un processus qui n’a pas de flux OUT est un processus qui ne fait que mettre à jour le système d’information. On peut représenter son action en utilisant la notion d’état. ExemplesVente par correspondanceEtapes de l’analyse des processus 1. on numérote tous les flux. 2. on prend les processus IN un par un, et on se demande s’il y a d’autres flux IN associés et quels sont les flux OUT correspondants. 3. on liste les principales activités associés au processus. 4. on nomme le processus et on le numérote
Traduction en fonction : Livraison NomDuProcessus (IN : flux In, OUT : flux out){ Activités } GestionCommande (IN : commande ; OUT : Livraison ; OUT : Dépôt de chèque) { Saisie des données Préparation du bordereau bancaire Dépôt du chèque Préparation de la livraison } Association et donateurs
Traduction en fonctions : NomDuProcessus (IN : flux In, OUT : flux out){ Activités } GestionDon (IN : Envoi d’un don; OUT : Dépôt de chèque) { Saisie des données Préparation du bordereau bancaire Dépôt du chèque } GestionReçu (IN : Echéance du reçu; OUT : Envoi d’un reçu) { Edition des reçus Mise sous plis Envoi } GestionMailing (IN : Décision de mailing; OUT : Mailing) { Préparation du courrier Sélection des donateurs Edition du courrier Mise sous pli Envoi } Validation du diagramme de contexte : découverte de nouveaux fluxExemple : Dans le cas de l’association et des donateurs, on aurait pu ne trouver initialement que 3 flux : Ce qui nous aurait donné le tableau des processus suivant :
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
