Augmentez votre productivité grâce à l'ingénierie dirigée par les modèles (Partie 1)

Introduction

Lorsqu'on nous demande quelle est notre profession, nous, les développeurs, ne manquons pas de mots. Nous pouvons nous décrire de différentes manières : "développeur logiciel", "programmeur informatique", "informaticien", "codeur", "ingénieur logiciel" ou d'autres rôles plus spécialisés, comme "architecte logiciel", "ingénieur DevOps", "défenseur des développeurs", etc. Nous utilisons parfois ces termes de manière interchangeable ou choisissons celui qui résonne le plus en nous. Mais à bien y réfléchir, un "programmeur informatique" est-il vraiment la même chose qu'un "ingénieur logiciel" ? Dans de nombreux cas, c'est possible. Comme beaucoup, voire la plupart des développeurs, j'aime beaucoup programmer. C'est sans aucun doute la pierre angulaire de notre profession et ce qui a attiré bon nombre d'entre nous dans ce secteur d'activité.

Toutefois, il est important de reconnaître que ce domaine repose sur des abstractions. À première vue, le travail d'un programmeur informatique a radicalement changé depuis l'époque des cartes perforées. La plupart d'entre nous ne connaissent pas le langage Assembly, ni même le langage C, considéré à l'époque (et encore aujourd'hui) comme un langage de programmation de "haut niveau". La tâche d'un programmeur (ou "codeur") consiste en fin de compte à transmettre des instructions au matériel sous-jacent pour qu'il effectue certaines opérations. Cependant, ce n'est pas ainsi que la plupart d'entre nous envisageons notre travail au quotidien. Nous pensons plutôt à un niveau d'abstraction plus élevé, en termes de solutions. Ainsi, la programmation, aussi amusante et stimulante qu'elle puisse être, est un moyen d'arriver à une fin. C'est pourquoi le terme "ingénieur logiciel" est un terme plus général qui englobe l'ensemble du processus de développement. Si le génie logiciel est comme la construction d'une maison, la programmation en est la partie qui consiste à poser les briques.

Malheureusement, la programmation n'est pas toujours amusante ou propice à la résolution de problèmes. En particulier dans le cas de langages verbeux comme Java, c'est souvent une corvée. C'est le résultat du "boilerplate" : du code répétitif et fastidieux à écrire à la main, mais qui reste nécessaire et utile. C'est souvent l'aspect le moins productif de la programmation et, par coïncidence, le plus automatisable. Bien que les IDE soient capables de générer du code standard, comme les getters et setters, toString(), equals et hashCode()ils ne peuvent répondre qu'aux besoins génériques du langage, et non à ceux du domaine. Si seulement il existait un moyen d'éliminer le processus fastidieux d'écriture manuelle du modèle de base spécifique au domaine...

Qu'est-ce que l'ingénierie dirigée par les modèles ?

L'ingénierie dirigée par les modèles (Model-Driven Engineering - MDE) est une discipline qui promeut l'utilisation de modèles comme des artefacts de première classe dans le processus d'ingénierie, en élevant le niveau d'abstraction. Appliqué à l'ingénierie logicielle, cela signifie qu'au lieu du code source l'artefact principal d'intérêt, nous nous intéressons davantage au modèle du domaine.

Bien que l'EDM soit souvent un terme et une discipline académiques, il a attiré l'attention d'un plus grand nombre de personnes par le biais de l'expression "low-code" (code réduit) - ce dont les universitaires sont également conscients. ce dont les universitaires sont également conscients. On peut arguer que l'EDM a une portée plus large que le mouvement "low-code", mais dans la pratique, ces différences sémantiques sont souvent d'un intérêt académique - pardonnez le jeu de mots !

Vous vous demandez peut-être ce qu'est un modèle. Il s'agit de tout ce qui décrit le domaine de manière déclarative. Vous pouvez considérer un modèle comme des données spécifiques à un domaine. L'essentiel est que ces données soient structurées de manière prévisible. Dans le jargon du MDE, nous appelons cette structure le métamodèle. Le métamodèle est lui-même un modèle qui décrit le "plan" du domaine - de la même manière que le plan d'un architecte fournit un guide pour la construction d'un bâtiment. Pour que cela soit plus clair, prenons quelques exemples.

Métamodèles

L'idée d'un métamodèle est de restreindre ce qui peut être exprimé à l'aide d'outils et de langages à usage général. Voici quelques exemples de technologies de métamodélisation le schéma XML (XSD)le schéma JSON ou tout schéma de base de données. En effet, si vous avez déjà travaillé avec une base de données relationnelle, un document XML ou un fichier de configuration quelconque, vous êtes déjà familiarisé avec ce concept, même si vous n'y avez pas pensé en ces termes.

Il existe de nombreux exemples, mais pour des raisons de brièveté et d'illustration, je ne les fournirai pas directement ici. Mais lorsque vous commencez à penser aux schémas comme des métamodèles et les données structurées conformes à ces schémas comme des modèlescela peut avoir un sens intuitif. Prenons l'exemple du fichier fichier "CustomersOrders.xsd" de ce tutoriel. Ce fichier modélise effectivement les concepts du domaine et la manière dont ils sont liés les uns aux autres. Le fichier "fichier "CustomersOrder.xml est une instance de ce modèle conforme au métamodèle "CustomersOrders.xsd" métamodèle. Si vous connaissez la programmation orientée objet, vous pouvez considérer les métamodèles comme des classes et les modèles comme des objets (c'est-à-dire des instances de ces classes). Dans la programmation orientée objet, une classe définit le schéma des instances concrètes (objets). Un autre exemple est ce schéma JSON minimal. Il définit une personne qui possède trois propriétés : firstName, lastName et age.

Dans ces deux cas, avez-vous remarqué que le métamodèle lui-même est écrit dans le même langage que le modèle ? En d'autres termes, un fichier XSD utilise la même syntaxe que XML, et un schéma JSON est lui-même écrit en JSON ! Le corollaire est que les métamodèles eux-mêmes sont des modèles qui se conforment à un métamodèle. Incroyable, non ? En d'autres termes, il existe un schéma pour le métamodèle. Heureusement, dans la plupart des cas, ce méta-métamodèle de haut niveau est généralement le point de départ. Les métamodèles se conforment généralement à eux-mêmes. Ce n'est pas une blague. il existe littéralement un fichier XSD qui définit le métamodèle pour les XSD!

Cadre de modélisation Eclipse

Après avoir défini le concept principal de l'ingénierie dirigée par les modèles, passons maintenant à un peu d'outillage. Bien que les schémas et les modèles puissent être (et soient souvent) définis à l'aide d'outils conventionnels et de formats de sérialisation tels que JSON et XML, il serait bénéfique, pour vraiment adopter l'IDM, de se familiariser avec les outils spécialisés utilisés par les professionnels de l'IDM. En raison de l'histoire de l'IDM, avec ses racines fortement universitaires et d'entreprise, la Fondation Eclipse est largement considérée comme la plateforme d'accueil des outils MDE les mieux établis. L'élément central est le Eclipse Modelling Framework (EMF). À la base, le projet définit un cadre pour la définition de métamodèles et d'outils permettant de travailler avec eux de manière programmatique en Java. Comme vous l'avez peut-être deviné, il comprend le métamodèle métamodèle - appelé Ecore. Voici un schéma simplifié des principaux concepts et de la hiérarchie d'Ecore :

Il y a bien d'autres choses à faire, bien sûr. voici un diagramme UML plus détaillé. Mais ne vous inquiétez pas, ce n'est pas quelque chose que vous devez savoir. Ce sont des concepts qui deviendront intuitifs lorsque vous utiliserez Ecore pour définir votre métamodèle. Il existe bien sûr des tutoriels disponibles en ligne pour EMFbien que bien que certains d'entre eux puissent être assez anciens. Ils sont toujours d'actualité, car la CEM est stable depuis longtemps.

Vous pouvez définir les métamodèles Ecore à l'aide de l'éditeur d'arbre intégré, de langages visuels comme UML ou textuels comme Emfaticqui est beaucoup plus facile à utiliser que le XML, qui est à la base de tous les métamodèles Ecore. Des outils d'entreprise comme Papyrus et Sirius sont construits au-dessus d'EMF et fournissent des outils plus puissants pour travailler avec les modèles. Vous pouvez même définir votre métamodèle comme une grammaire pour un langage spécifique à un domaine en utilisant Xtext.

Cela fait beaucoup à assimiler ! L'idée est de vous donner un aperçu des outils et des technologies disponibles. Comme vous pouvez le constater, l'outillage de l'EDM et ses principes sont assez riches, bien établis et relativement matures. Vous pouvez définir vos modèles et métamodèles graphiquement ou textuellement, et comme beaucoup d'outils sont construits sur EMF, une fois que vous avez défini votre métamodèle, vous pouvez générer du code Java à partir de celui-ci et travailler avec lui de manière programmatique si vous le souhaitez.

Gestion des modèles

Maintenant que vous connaissez la métamodélisation et les outils qui peuvent être utilisés pour définir des (méta)modèles, vous vous demandez peut-être à juste titre : et alors ? Qu'est-ce que je peux faire avec ces modèles ? Pourquoi consacrer tout ce temps et tous ces efforts à la définition d'un schéma qui, en fin de compte, limite ce que je peux exprimer à l'aide d'un langage général ? C'est là qu'intervient la valeur réelle de l'EDM. Le métamodèle est nécessaire pour que vous puissiez travailler avec des modèles à un niveau abstrait. La gestion des modèles est le processus d'action sur les modèles. Ces tâches comprennent ce qui suit :

• Visualisation: Présentation de différentes vues et représentations graphiques d'un modèle à des fins et pour des publics variés.

• Recherche: Obtention de données à partir du modèle, impliquant souvent des expressions à forte intensité de calcul.

• Validation: Les métamodèles ne sont souvent pas assez puissants pour exprimer toutes les contraintes relatives à un modèle de domaine, de sorte qu'une logique programmatique supplémentaire est nécessaire pour s'assurer que les modèles sont bien formés.

• Comparaison: Comparer les modèles et agir sur les différences au niveau des programmes.

• Fusionner: Prendre plusieurs modèles d'entrée et produire un seul modèle de sortie.

• Migration: Mise en correspondance d'un modèle avec une version évoluée du métamodèle.

• Transformation: Modification d'un modèle ou production d'un modèle de sortie différent (qui peut être conforme à un métamodèle différent).

• Génération de textes: Utilisation d'un ou de plusieurs modèles pour générer des textes, tels que le code source et la documentation.

Comme vous l'avez peut-être deviné, il existe également des outils pour toutes ces tâches. Le langage de facto utilisé pour valider les modèles dépassant les capacités d'Ecore est le langage de contraintes d'objets (OCL). Vous pouvez en apprendre plus sur ce langage en consultant un tutoriel d'introduction.Je ne m'attarderai donc pas sur les détails ici. Cependant, il est utile de savoir que de nombreux autres langages de gestion de modèles s'appuient sur les expressions, la syntaxe et la sémantique d'OCL ou s'en inspirent. La littérature sur les transformations de modèle à modèle est vaste et souvent très complexe, puisqu'il s'agit du principal domaine de recherche universitaire en matière d'EDM. Il existe bien sûr des langages pour les transformations de modèles, tels que ATL et QVTmais nous ne nous y attarderons pas.

En tant que développeur, que devons-nous vraiment ce qui nous importe vraiment ? La productivité, n'est-ce pas ? C'est le point de départ de toute cette discussion. Étant donné qu'une grande partie de notre journée est consacrée à l'écriture de la documentation et du code standard, nous voulons en générer automatiquement le plus possible afin de pouvoir nous concentrer sur les choses amusantes et les parties qui requièrent plus d'attention ou d'expertise en matière d'ingénierie. C'est là que la transformation de modèle en texte peut être utile. Il existe des normes, telles que MOF M2T et des outils qui s'y conforment, tels que Acceleomais vous êtes peut-être familier avec des outils plus conventionnels tels que Jakarta Server Pages (JSP). Si Java sur le web semble être une relique du début des années 2000, le principe qui le sous-tend est toujours valable. Après tout, le PHP signifie littéralement "Hypertext Preprocessor" et est encore largement utilisé. Mais qu'est-ce que JSP et PHP ont à voir avec la génération de code et l'ingénierie dirigée par les modèles ? C'est ce que nous verrons dans la deuxième partie de ce billet de blog. Avant cela, jetons un coup d'œil sur un outil qui sera utilisé pour démontrer cela.

Epsilon

Nous avons brièvement abordé les principaux concepts de l'EDM et certains outils, mais comment tout cela s'articule-t-il ? Nous disposons de différentes technologies de métamodélisation, de sorte que les modèles peuvent être dans différents formats, mais la plupart des outils que j'ai mentionnés jusqu'à présent sont basés sur EMF. De plus, comme chaque tâche de gestion de modèle a son propre outil, avec une syntaxe et une sémantique variables pour définir la logique d'interrogation/transformation, il peut sembler que MDE est trop complexe et trop lourd étant donné la courbe d'apprentissage abrupte. Cependant, il existe un projet (basé sur Eclipse, naturellement) qui vise à unifier les différentes technologies de modélisation et les tâches de gestion de modèles : Epsilon. Je le dis sans détour : j'ai largement contribué à Epsilon pendant mon doctorat, ce qui me donne un peu de parti pris !

Je ne m'attarderai pas sur l'explication d'Epsilon et de son architecture. la documentationmais je fournirai une brève introduction. Fondamentalement, Epsilon fournit une famille de langages de gestion de modèles spécifiques à une tâche, construits au-dessus d'un langage d'interrogation commun appelé EOL. Ce langage s'inspire de la syntaxe d'OCL mais se comporte beaucoup plus comme Java puisqu'il est implémenté en Java et fait un usage intensif des capacités de réflexion de Java. Vous pouvez même appeler du code Java natif à partir d'EOL. EOL est donc essentiellement un langage de programmation complet avec toutes les constructions de programmation impérative habituelles, ainsi que des opérations déclaratives pour travailler avec des collections.

Epsilon prend également en charge plusieurs technologies de modélisation et n'est pas lié à EMF. Bien qu'il prenne très bien en charge les modèles EMF et s'intègre à d'autres outils EMF, sa couche de connectivité de modèle (Model Connectivity Layer) n'a pas été conçue pour les modèles EMF. couche de connectivité de modèle signifie que les langages sont découplés du format de persistance du modèle sous-jacent. Vous pouvez donc l'utiliser avec différents types de modèles tels que XML, CSV et d'autres formats de feuilles de calcul, des bases de données compatibles JDBC, Simulink, etc. Simulink, etc. Ainsi, Epsilon fournit une solution tout-en-un pour la gestion des modèles, sans avoir à travailler avec différents outils basés sur la technologie de modélisation. Vous pouvez même combiner plusieurs modèles de différents types dans le même programme et les utiliser de manière uniforme.

C'est tout pour l'instant...

Ouf, c'est beaucoup à assimiler ! Mais je vous promets que dans la prochaine partie, tout cela sera présenté à travers un exemple pratique. Plus précisément, je vais montrer comment j'ai utilisé Epsilon pour automatiser efficacement l'écriture d'un gros morceau de code de base pour le SDK Java de Vonage.

Si vous avez des commentaires ou des suggestions, n'hésitez pas à nous contacter sur X, anciennement connu sous le nom de Twitter ou à notre Slack communautaire. J'espère que cet article vous a été utile et je vous invite à me faire part de vos réflexions/opinions. Si vous l'avez apprécié, jetez un coup d'œil à mes autres articles sur Java.