Cours Système Analyse Merise les modèles Merise l'intêret de Merise

Rappel sur Merise

Merise répond aux critères précédents à sa manière :

1.1 Définir ce que l'utilisateur final désire

Des étapes de validation jalonnent le travail effectué. L'utilisateur est contraint de valider un "niveau" avant de passer au suivant. Par exemple, les enchaînements d'écrans de saisie de ristournes ou de  promotion consommateur ne seront pas dessinés si des définitions ne sont pas données ou ne sont pas claires pour le concepteur et l'utilisateur. Des étapes sur lesquelles il est possible de revenir ont été créées.

Les étapes retenues dans Merise correspondent aux trois niveaux suivants :

+ un niveau indépendant de l'organisation, fonctionnel, et appelé conceptuel ;

+  un niveau indépendant de l'informatique, l'organisationnel, et ;

+  l'informatique. Ce niveau est découpé en deux "sous-niveaux"  logique et physique. Le "sous-niveau" logique, indépendant du matériel, peut encore être découpé en spécification  externe, visible par l'utilisateur, et spécification interne, ou invisible à l'utilisateur. Il est inutile de faire valider ou approuver la spécification interne à l'utilisateur final.

D'autres étapes auraient pu être choisies. Certains niveaux, en particulier le niveau organisationnel, n'existent pas dans des méthodes anglo-saxonnes telles que Ssadm ou Sadt.

1.2 Vérifier la cohérence de sa demande

Le domaine à informatiser est abordé par trois côtés ou approches : communication, traitement et données. La validation permet de vérifier la cohérence de ces modèles entre eux.

  Communication, traitement et données.

Dans tout projet impliquant un dialogue ou un découpage nécessaire des projets (construction d'usine avec un découpage génie civil, électricité, instrumentation, informatique, tuyauterie...), les quiproquos viennent d'une définition insuffisante des fonctions couvertes par chaque métier. C'est pourquoi, avant de démarrer un projet, il est fondamental de fixer les limites de ce projet et de définir ses liens avec les autres projets. A chaque projet est rattaché un domaine de l'entreprise. Les liens entre projets sont représentés par les échanges entre domaines fonctionnels. La découpe de l'entreprise et les échanges entre systèmes internes ou externes à l'entreprise sont représentés dans les modèles de communication.

La deuxième approche qui vient naturellement à l'esprit quand il s'agit d'informatique est la description des traitements : "Que provoquent ou comment sont générés ces messages ou ces échanges d'information ?"

Enfin, vient la structuration des données, sur laquelle nous reviendrons au point trois.

Vérification de la cohérence entre les modèles de communication, données et traitements.

Une première validation, décrite dans tous les manuels concernant Merise, doit être effectuée entre données et traitements. Toute donnée ou information est utilisée dans un traitement et tout traitement peut accéder aux données nécessaires.

Toute méthode accordant une importance  privilégiée et justifiée aux données, telle que Niam ou Merise, doit garder son objectif de vérifier la faisabilité de la demande utilisateur en croisant ses besoins, exprimés sous forme de données, et ses besoins de traitement. Les données sont au service des traitements.

Une deuxième validation, intervenant avant la validation entre les données et les traitements, est la validation entre données et communication. Cette validation est plus facile et suppose que les modèles de communication ont été effectués : ne pas modéliser des données de lieu de livraison quand les messages contiennent des données de publicité consommateur ou de marketing. 

1.3 Les modèles de Merise

La combinaison des 4 niveaux et des 3 approches donne lieu à la "création" de 12 modèles de référence. Par exemple, le croisement du niveau conception et de l'approche données crée le MCD, ou modèle conceptuel de données.

+  Le modèle logique de données ou MLD, indépendant du système de gestion de base de données ou SGBD, n'est pas traité. La transformation entre les modèles entité relation (MCD ou MOD) et les modèles physiques relationnel et réseau est directe. Ceux-ci sont considérés comme logiques par les administrateurs de base de données. Certains appellent modèles logiques de données les modèles dépendant du SGBD, traités ici comme physiques. 

+  Le modèle organisationnel de communication ou MOC, traite les messages échangés entre sites différents : demande de présentation, demande de lancement de programme, mise à jour ou interrogation de données à distance. Ce domaine en pleine évolution n'est pas stable actuellement (architecture client serveur). Aucun exercice ne traite cet aspect.

+   Les modèles physiques de communication et de traitement ne sont pas décrits car l'ouvrage ne traite pas de programmation.

1.4 Structurer les données

La construction des représentations  graphiques des structures de données, appelés modèles de données, est couverte  par la plupart des méthodes actuelles :

Merise, Niam, modèles de Chen, Normalisation de tables relationnelles. Cela entraîne un sens de l'abstraction (inné ou acquis ?) non négligeable.  Une bonne définition des modèles de données est indispensable. Certaines méthodes, comme les méthodes anglo-saxonnes, sont plus orientées vers la gestion de projet. Une représentation des données plus compréhensible par l'utilisateur et non couverte par les méthodes de conception est la construction d'un jeu d'essai.

Merise formalise des ensembles de données, "client", "produit", "animal", dont les occurrences sont "sympathique",  "orgueilleux", "nouveauté", "commode", "avide", "sécurité" ou "pomme", "tomate" ou "hérisson", "taureau" ou "chat", par exemple. L'application finale créera "M. Sécurité", "une pomme" et "un chat", les occurrences des concepts manipulés par Merise, "client", "produit" et "animal". Il est difficile de modéliser les ensembles d'occurrences et les occurrences elles-mêmes. Merise manipule les ensembles d'occurrences, le jeu d'essai manipule les ensembles et les occurrences.

Construire un jeu d'essai est primordial. Il permet à l'utilisateur de préciser sa demande et au concepteur de construire le modèle de données si l'utilisateur ne sait pas interpréter les modèles et les dessins de ses enfants. C'est pourquoi ce livre comprend un exercice de construction de jeu d'essai. Celui-ci se situe après la modélisation des données. Un jeu d'essai permet aussi la fourniture d'un jeu de test pour la réception des programmes ou la sélection d'un progiciel.

1.5 Rester simple.

Modifier une application existante revient 100 fois plus cher que de la concevoir correctement dès son origine. Malheureusement, il est difficile de rester simple quand tout s'agite autour de vous, et l'application "naturelle" de Merise peut laisser croire à une méthode complexe. Vous verrez par la pratique qu'en gardant à l'esprit ce souci de simplicité, vous aurez le plaisir d'avancer sans remettre en question les étapes précédentes. Cette simplicité va  de pair avec la maîtrise du sujet de l'utilisateur final.