Les trois éléments d’un langage de modélisation
Maintenant que le lecteur est un fin connaisseur du Canevas de l’empathie (Osterwalder et al., , pp. 10–25), il est temps de lui dire l’objectif que nous visons dans cette série de cours : nous souhaitons qu’il soit capable d’inventer ses propres langages de modélisation et de les partager sous forme d’applications informatiques afin d’en faire profiter les autres.
La meilleure façon d’acquérir ce savoir-faire est d’apprendre en premier lieu à développer des logiciels offrant la possibilité de manipuler sur l’ordinateur des langages déjà existants. C’est ce que nous nous proposons de faire, et notre première appli sera consacrée au Canevas de l’empathie.
Ce court billet définit les notions clés avec lesquelles il faut absolument être à l’aise parce qu’elles nous suivrons tout au long de la série. Après l’avoir lu, vous saurez ce que sont un modèle, un langage, un métalangage, une syntaxe abstraite, une syntaxe concrète et une sémantique.
Syntaxe abstraite, syntaxe concrète et sémantique
Un langage de modélisation est un ensemble de règles suivies par ses utilisateurs pour représenter et transmettre leurs idées autour d’un thème spécifique. Le Canevas de l’empathie est, par exemple, un langage de modélisation qui a pour thème la compréhension de ce que les clients d’une entreprise recherchent.
Quand on veut créer un langage de modélisation, la première chose à faire est de lister les concepts à propos desquels on aimerait pouvoir parler avec lui, et les relations entre ces concepts qu’il doit permettre d’exprimer. Cette liste s’appelle la syntaxe abstraite (Brambilla et al., , p. 57).
Ci-dessous, nous avons reproduit le modèle que nous avons réalisé dans le billet précédent avec le Canevas de l’empathie.
En tant que langage de modélisation, le Canevas de l’empathie met à notre disposition les concepts de but, de problème et d’attente. Ces concepts sont connectés ainsi : les clients ont des problèmes qui les empêchent d’atteindre leurs buts, mais seules les solutions qui correspondent à leurs attentes auront leur faveur. Il y a donc, dans la syntaxe abstraite du Canevas de l’empathie, au moins trois concepts et deux relations : une relation entre les buts et les problèmes (les problèmes empêchent les clients d’atteindre leurs buts), et une relation entre les problèmes et les attentes (les clients ont des attentes précises qui déterminent les solutions qu’ils jugent acceptables pour leurs problèmes).
Une fois que la syntaxe abstraite du langage de modélisation est fixée, on passe à sa syntaxe concrète (Brambilla et al., , p. 57). Ce terme désigne la notation que le langage apporte pour communiquer les concepts de la syntaxe abstraite et leurs relations.
Par exemple, sur la figure 1, nous avons dessiné un cercle, l’avons divisé en trois parties, et avons écrit les buts, les problèmes et les attentes de nos lecteurs respectivement dans celles de droite, du bas et du haut parce que la syntaxe concrète du Canevas de l’empathie impose de faire ainsi. Elle ne nous oblige pas toutefois à les mettre dans des rectangles, et encore moins à ajouter des couleurs. Des choix de style comme le nôtre sur la figure 1 sont dits non normatifs (Object Management Group, ) parce qu’ils ne sont pas règlementés par la syntaxe concrète.
Le Canevas de l’empathie est un langage de modélisation graphique qui représente ses concepts par du dessin (le cercle en arrière-plan) combiné à du texte. Sa syntaxe concrète est une syntaxe concrète graphique. De nombreux langages sont purement textuels : ils ne modélisent les choses que par du texte structuré de manière particulière. Leurs syntaxes concrètes sont des syntaxes concrètes textuelles.
On termine un langage de modélisation en clarifiant sa sémantique (Brambilla et al., , p. 57), c.-à-d. la signification donnée à chaque concept et relation entre concepts permis par la syntaxe abstraite. La sémantique met tout le monde d’accord sur la bonne façon d’interpréter et de comprendre les modèles construits avec le langage.
Par exemple, la sémantique du Canevas de l’empathie indique que les buts, les problèmes et les attentes sont respectivement ce que les clients veulent faire advenir ou voir se réaliser, les entraves qui les mettent en difficulté ou les bloquent, et les types de solutions qu’ils cherchent pour les surmonter.
Gardons la même syntaxe abstraite et la même syntaxe concrète mais imaginons une tout autre sémantique. Disons par exemple que les buts, les problèmes et les attentes sont respectivement les situations que les clients veulent absolument éviter, les mauvaises habitudes qui les y conduisent, et les types de solutions qu’ils cherchent pour changer. Le modèle de la figure 1 n’a alors plus aucun sens, même s’il respecte parfaitement la notation de la syntaxe concrète.
Qu’est-ce qu’un métalangage de modélisation ?
Un métalangage est un langage qui sert à modéliser la syntaxe abstraite, la syntaxe concrète ou la sémantique des autres langages. Dit autrement, un modèle conçu avec un métalangage présente la syntaxe abstraite, la syntaxe concrète ou la sémantique d’un autre langage.
Un métalangage spécialisé dans la syntaxe abstraite doit pouvoir modéliser sa propre syntaxe abstraite. Un métalangage spécialisé dans la syntaxe concrète doit pouvoir modéliser sa propre syntaxe concrète. Et un métalangage spécialisé dans la sémantique doit pouvoir modéliser sa propre sémantique.
Les métalangages les plus connus sont :
- l’Essentiel de la Facilité de modélisation par métaobjets (EMOF, de l’anglais Essential Meta Object Facility), normalisé par (Object Management Group, , pp. 25–34) pour modéliser les syntaxes abstraites ;
- la Forme de Backus-Naur étendue (EBNF, de l’anglais Extended Backus-Naur Form), normalisée par (ISO/IEC, ) pour modéliser les syntaxes concrètes textuelles ;
- et la Définition des diagrammes (DD, de l’anglais Diagram Definition), normalisée par (Object Management Group, ) pour modéliser les syntaxes concrètes graphiques.
Pour la sémantique, on utilise souvent une langue naturelle, c.-à-d. le français, l’anglais, etc. L’existence des dictionnaires, qui définissent, par exemple, les mots français en français, prouve que les langues naturelles peuvent décrire leur propre sémantique.
Qu’est-ce qu’un modèle ?
Un modèle est une représentation réduite de quelque chose. Nous voulons dire par là que :
- un modèle a toujours un sujet : la chose qui est modélisée ;
- un modèle représente son sujet : il permet de se passer de lui ;
- un modèle réduit son sujet : il ne s’intéresse qu’à une partie pertinente de ses propriétés (Brambilla et al., , p. 2) ; on peut indéfiniment le raffiner en précisant des détails que ses auteurs ont mis de côté.
En génie logiciel, la production d’un modèle se fait en respectant la syntaxe abstraite, la syntaxe concrète et la sémantique d’un langage de modélisation.
OK, il reste encore un point à éclaircir : pourquoi faut-il modéliser ? À quoi servent les modèles ?
Leur rôle est de décrire ou prescrire (Brambilla et al., , p. 2).
Un modèle descriptif montre le sujet tel qu’il est ou était. Le but est de rendre le modèle conforme au sujet. En peinture, un portrait est un modèle descriptif.
Un modèle prescriptif montre le sujet tel qu’il doit être, devrait être ou sera. Le but est de rendre le sujet conforme au modèle. En génie civil, les plans dessinés par un architecte sont des modèles prescriptifs que les ingénieurs doivent prendre en compte pour construire le bâtiment.
Prenez le temps d’assimiler toutes les définitions que nous venons de donner. Dans les prochains billets, nous modéliserons respectivement avec EMOF et DD la syntaxe abstraite et la syntaxe concrète du Canevas de l’empathie. Nous pourrons alors commencer à coder.
Questions
Quelle approche préférez-vous ?
- s’occuper d’abord de la syntaxe abstraite ; ensuite de la syntaxe concrète ; puis, pour finir, de la sémantique ;
- s’occuper d’abord de la syntaxe abstraite ; ensuite de la sémantique ; puis, pour finir, de la syntaxe concrète.
Bibliographie
Brambilla, Marco, et al. Model-Driven Software Engineering in Practice. Synthesis Lectures on Software Engineering. Morgan & Claypool, .
ISO/IEC. ISO/IEC 14977. Information technology — Syntactic metalanguage — Extended BNF. . Disponible en ligne sur International Organization for Standardization — dernier accès le .
Object Management Group. Diagram Definition (DD). Version 1.1. . Disponible en ligne sur Object Management Group — dernier accès le .
Object Management Group. OMG Meta Object Facility (MOF) Core Specification. Version 2.5.1. . Disponible en ligne sur Object Management Group — dernier accès le .
Osterwalder, Alexander, et al. Value Proposition Design. Hoboken, New Jersey : John Wiley & Sons, .
Roques, Pascal. UML 2 par la pratique. 6e éd. Paris, France : Eyrolles, .
Crédits photographiques
Rawpixel.com (nom d’utilisateur sur Shutterstock). ‹Démarrer une entreprise.› n.d. Disponible en ligne sur Shutterstock (numéro de référence : 326979212) — dernier accès le . Photo mise en avant.