Editions ENI Livres | Vidéos | e-Formations
Modélisation
MERISE
Le cœur du système d’information est le système de gestion de base de données (SGBD). L’intégralité des données applicatives qui nécessitent une persistance y est stockée. C’est donc le centre névralgique des applications de toute nature. Les données doivent y être en sécurité, accessibles à un très grand nombre d’utilisateurs concurrents. Leur recherche doit être rapide et sélective.
Dans ce chapitre, nous aborderons, au travers de la méthode MERISE, les SGBD de type relationnel qui organisent les données sous forme de tableaux et qui les rendent accessibles à travers un langage déclaratif (SQL). Nous ne parlerons pas des bases hiérarchiques, déductives ou objets qui sont plus marginales dans l’informatique d’entreprise. Nous n’aborderons pas non plus le langage SQL qui est en dehors du périmètre de cet ouvrage.
La modélisation de schémas relationnels est une tâche ardue, dévolue à l’architecte de base de données. C’est un exercice ô combien crucial pour le bon déroulement des opérations ultérieures. En effet, cette phase, qui se déroule en amont des phases de développement qui lui sont subordonnées, a de lourdes conséquences sur la structure des couches supérieures. Nous reviendrons sur les techniques de mapping objet/relationnel (ORM) qui font le lien entre la couche de stockage (SGBD) et celle d’accès aux données dans le chapitre Architectures d’intégration.
1. Origine
Le modèle entité/association est une technique fondamentale de modélisation des schémas de bases de données relationnelles. Son invention est française et attribuée à Moulin et Tardieu en 1975. Mais cette théorie sera ensuite largement reprise et diffusée à travers le monde par Peter Chen dans sa publication « The Entity Relationship Model ».
Il s’agit de la technique la plus usitée à ce jour pour concevoir le modèle de données d’une application. Elle articule un petit nombre de concepts autour d’une méthode en trois étapes que nous allons développer....
UML
Le besoin de modélisation se fait sentir dès lors qu’on projette une réalisation complexe, quel qu’en soit le domaine. Établir un modèle permet de prévoir, d’anticiper et d’évaluer les risques, le coût et l’organisation. Le modèle aide à rationaliser les projets. Il est surtout vecteur de communication entre des techniciens qui ont un champ sémantique ou une approche bien souvent incompréhensible par les décisionnaires ou les visionnaires. En ce sens-là, la modélisation a forcément besoin d’un langage pour exprimer son regard, quelque chose d’universel, d’unifié qui permette à toutes les parties prenantes d’une équipe - des analystes aux développeurs - de discuter simplement et surtout de se comprendre. Les entreprises peuvent difficilement se permettre de mal interpréter les besoins de leurs clients et encore moins de mal les transcrire en termes de système. Il va donc de soi qu’un langage unifié est essentiel. Voici donc le pourquoi d’UML.
En ce concerne le "quand", il faut remonter dans les années 90 lors de la fondation de l’OMG (Object Management Group) pour voir émerger des standards technologiques destinés aux systèmes orientés objet. Nous devons à ce consortium l’UML, le MDA (Model Driven Architecture) et certaines spécifications pour la modélisation de processus (BPMN) que nous avons abordé précédemment. Avant l’UML 1.1, on disposait de moult méthodes (BOOCH, OMT, OOSE, FUSION, OBA, … ). Ivar Jacobson est l’un des pères fondateurs du langage. Il contribua à fonder le processus unifié dont nous avons déjà parlé et qui est venu fusionner toutes ces méthodes de modélisation au sein d’UML en créant au passage le RUP (Rational Unified Process), un processus centré sur ce langage de modélisation. Nous sommes, depuis 2008, à la version 2.2 du langage.
Il sera ici encore question de formes, certes élémentaires - des rectangles, des ellipses, des lignes ou de petits bonshommes -, mais qui parlent d’elles-mêmes dès lors qu’on en connait le contexte. UML est un langage de modélisation...
