Un article publié sur Stack Overflow Blog invite à repenser le concept de programmation orientée modèle (Model Oriented Programming), en tant qu’approche susceptible de séparer les exigences du système de sa conception logicielle, puis d’utiliser le modèle lui-même pour contribuer à la création et à la maintenance du système. L’auteur s’appuie sur une expérience antérieure au cours de laquelle il a développé, il y a 13 ans, un langage et un environnement de développement baptisés Mo+, et affirme les avoir utilisés dans des projets d’entreprise, sans que l’idée ne se diffuse largement.
L’article n’est ni l’annonce d’un langage disponible ni celle d’un nouveau projet de recherche, mais une thèse appelant à davantage de recherche et de développement dans ce domaine, notamment dans un contexte où l’intelligence artificielle gagne en importance et où les systèmes logiciels deviennent plus complexes.
Le modèle comme structure et comme données
L’auteur propose de définir le modèle à partir de deux éléments : une structure qui détermine les règles ou le schéma, et des données qui respectent cette structure. La structure est hiérarchique : elle commence par un nœud racine et se ramifie en nœuds et en propriétés, une propriété pouvant, si nécessaire, faire référence à un autre nœud. Selon cette perspective, le schéma d’une base de données relationnelle peut être représenté sous forme hiérarchique, avec des nœuds tels que la base de données, la table, la colonne et la clé, même si les données elles-mêmes sont réparties entre des lignes et des relations.
L’article utilise un scénario simplifié de restaurants pour illustrer l’idée, comprenant les restaurants, les clients, les employés, les éléments du menu et leurs relations. Il présente plusieurs structures possibles pour représenter le même scénario, en expliquant que le choix de la structure influe sur la facilité de parcours du modèle et sur la manière d’écrire les programmes qui s’appuient sur celui-ci.
Quatre formes de développement orienté modèle
- Modélisation informelle : des modèles présents dans l’esprit, sur papier ou dans des diagrammes qui ne sont pas utilisés directement par des outils logiciels.
- Modélisation intégrée : un modèle intégré au code, comme dans les frameworks ORM tels qu’Entity Framework et NHibernate, ou dans les frameworks d’interface utilisateur tels qu’Angular et React.
- Modélisation couplée : un modèle externe, généralement créé avec UML, fortement lié aux éléments du code et aux outils qui les gèrent.
- Modélisation découplée : un modèle centré sur les exigences, les données et le flux de travail, la conception détaillée étant laissée au code, de sorte que chaque élément du modèle ne soit pas lié à un composant logiciel précis.
L’auteur estime que les possibilités les plus importantes résident dans la modélisation couplée et la modélisation découplée, notamment cette dernière, car elle place les exigences dans le modèle et la conception dans le code. Il affirme que son expérience personnelle a rendu le processus de modélisation et de programmation plus fluide.
Du modèle au système
L’article divise l’utilisation de la programmation orientée modèle en trois domaines. Dans le mode transitoire, le programme interprète le modèle et produit du code source, des fichiers de configuration ou de la documentation pouvant être développés ultérieurement. Dans le mode de modélisation des modèles, le langage contribue à créer et à maintenir la structure et les données du modèle. Quant au mode cible, il utilise directement le langage pour construire et gérer l’environnement du système, ce qui nécessite un langage plus complet.
Fonctionnalités du langage proposé
La principale proposition consiste à faire de la structure du modèle une partie des règles du langage, afin de pouvoir manipuler directement des nœuds tels que Entity, Property et Relationship, au lieu de créer des classes et des objets spécifiques pour les représenter. L’auteur propose également un contexte de modèle reposant sur la position du programme dans l’arbre de données, avec une pile permettant de remonter vers les nœuds parents ou de descendre vers les éléments enfants et d’effectuer des recherches parmi eux.
Une autre idée apparaît sous la forme de « propriétés orientées modèle » : des fragments de code autonomes associés à un type de nœud donné et pouvant être évalués sur plusieurs instances. Ces propriétés peuvent être combinées pour produire du code, par exemple pour créer la définition d’une classe ou de ses propriétés, ou être utilisées dans des opérations de recherche et de filtrage. Dans le mode transitoire, la propriété peut inclure une opération put destinée à enregistrer le résultat dans un fichier ou dans un environnement cible.
L’auteur propose également des règles dynamiques, dans lesquelles l’interpréteur ajoute les nœuds et les propriétés du modèle aux règles du langage au démarrage d’une session de programmation. Cela peut être utile lorsque le modèle standard ne contient pas suffisamment d’informations, ou lorsque le modèle est propre à une organisation ou à un domaine donné. Il propose aussi des règles contextuelles qui limitent les opérations autorisées dans différentes parties du programme, afin de réduire les effets secondaires et de séparer les responsabilités de lecture et d’écriture.
Pourquoi cette proposition est-elle importante ?
La valeur pratique de cette idée réside dans la tentative de rendre le modèle exécutable, plutôt que de le réduire à un document de conception distinct du cycle de développement. S’il était possible de relier les exigences, les données et le flux de travail à des mécanismes de génération et de maintenance réutilisables, la répétition entre le modèle et le code pourrait diminuer. Toutefois, l’article ne présente ni langage standardisé, ni outils disponibles, ni résultats comparatifs démontrant la supériorité de cette approche sur les frameworks actuels de modélisation et de génération de code.
D’importantes questions restent donc ouvertes : comment gérer les modèles volumineux et évolutifs ? Comment tester le code généré ? Quelles sont les limites des règles dynamiques en matière de lisibilité, de sécurité et d’intégration avec les outils de développement ? L’article apparaît ainsi davantage comme une invitation à la recherche, précieuse pour les concepteurs de langages et les chercheurs, que comme une solution prête à l’emploi.