Modélisation des services web pour la génération de code

D’autres solutions utilisent également l’IDMpour décrire des services ou appli- cations web, cette fois-ci avec pour objectif principal d’en générer une implé- mentation exécutable.

BPEL. Business Process Execution Language (BPEL)(ou WS-BPEL) [34] est un langage de programmation qui permet d’exprimer des processus d’entreprise et la description de leur enchaînement sur de multitudes d’applications réparties. Sa syntaxe est basée sur XML. Même siBPELpermet de créer des services web, il a été conçu avec un objectif plus restreint : permettre des interactions entre les processus de différentes entreprises via des services web. Sa grammaire est expressive pour lui permettre de modéliser des processus complexes, mais cette flexibilité vient avec un coût : celui d’apprendre un langage plus complexe. Une grande partie de cette complexité n’est pas nécessaire pour construire des services web dans notre contexte.

Solutions basées sur EMF. Le projetEclipse Modeling Framework (EMF)[57] est un framework de modélisation et une infrastructure pour la génération de code qui permet de construire des applications basées sur des modèles de données structurées. Il est très reconnu dans la communauté de l’IDM; par exemple, toute la partie pratique de [29], un ouvrage d’introduction à l’IDM, repose surEMF. Il comporte de nombreux outils permettant de concrétiser une démarche d’IDM, en fournissant par exemple des moyens pour construire des éditeurs graphiques, vérifier des modèles, . . . L’un de ces outils, Xtext [58], est unframeworkfacilitant le développement de langages de programmation et de

DSL. Xtext est similaire àMeta Programming System (MPS)[28], qui propose des fonctionnalités analogues hors de l’environnementEMF. Un autre de ces outils,

Graphical Modeling Framework (GMF)[59], permet de produire des éditeurs graphiques pour modèles ; il peut être utilisé de pair avec Xtext, comme présenté dans [17].

Bien sûr, les outils de EMF peuvent être mis en œuvre pour construire des services web, mais leur généricité peut être vue comme une complexité inutile lorsqu’on se cantonne uniquement à cet objectif. D’autre part, [11] met en évi- dence la difficulté à enseigner l’IDM: le manque de documentation des outils, par exemple, est un aspect qui peut bloquer beaucoup de praticiens. Tout comme

BPEL,EMFest trop complexe dans notre contexte.

M3D. M3D est un outil d’IDMpour la génération d’applications web introduit dans [8,9]. Les modèles d’entrée reposent sur quatre couches :

— une couche d’information, sous la forme d’un diagramme de classesUML; — une couche de services, basée surBusiness Process Model and Notation

(BPMN);

— une couche de présentation, dans un méta-modèle similaire à ce qui existe dans Spring ou Android ;

— une couche de processus, mettant en œuvre le langage Declare [62]. Les auteurs de M3D s’attaquent à des problématiques proches de la nôtre, comme le prototypage rapide d’applications web ou plus spécifiquement l’alignement entre les modèles et l’implémentation, dans un contexte où les développeurs ont besoin de flexibilité et ne peuvent l’obtenir qu’en modifiant directement l’implémentation générée. Leur solution est également similaire à la nôtre, dans le sens où elle met en œuvre l’IDMpour résoudre des problèmes proches. Cependant, M3D possède des limitations qui ne lui permettent pas d’être une solution viable dans notre contexte.

D’abord, les choix de se baser sur quatre méta-modèles différents et de permettre d’exprimer des interfaces utilisateur sont compréhensibles mais augmentent la complexité globale de la solution, notamment du point de vue de développeurs peu ou pas initiés à l’IDM. Cela rejoint les raisons évoquées précédemment pour

BPELetEMF.

Ensuite, l’approche globale se positionne dans un contexte de prototypage rapide uniquement, c’est-à-dire qu’elle pose l’hypothèse que les applications produites servent à stabiliser les spécifications et doivent être redéveloppées par ailleurs avant d’être mises en production. L’accent n’est donc pas mis sur la vérification de cohérence, qui permet d’augmenter la maintenabilité, ni sur la compatibilité avec plusieurs technologies ou standards de l’industrie. Les interfaces utilisateur générées sont basées surJSFet les serveurs surJ2EE, ce qui ne correspond pas au contexte technologique de Startup Palace. Cependant, le point important est que M3D n’est pas mûr pour une utilisation industrielle en production, hors

prototype rapide.

Enfin, cette distance technologique avec l’industrie est confirmée par notre incapacité à trouver et essayer l’outil en lui-même : ni exécutable, ni code source, ni documentation technique, ni vidéo de démonstration disponible sur Internet à notre connaissance.

JHipster. JHipster [15] est une plateforme pour générer, développer et dé- ployer des applications web ou des microservices, qui repose sur un outil en ligne de commande lui-même basé sur Yeoman. Cet outil permet de définir interactivement des options de configuration et de lancer la génération de code. Les applications ainsi générées mettent en œuvre un serveur Java basé sur Spring Boot[38], une interface graphique basée sur Angular[22] ou sur React[18], ainsi que divers éléments d’architecture facilitant l’opération de microservices. Le développeur est alors libre de modifier le code généré pour obtenir l’application dont il a besoin.

Pour continuer à faire gagner du temps aux développeurs après cette phase de génération initiale, JHipster propose un sous-générateur d’entités. Dans JHipster, les entités peuvent être vues comme des parties d’un modèle de données. Le sous-générateur d’entités permet donc d’étendre le modèle de données de l’ap- plication en générant divers artéfacts qui découlent des définitions des entités ajoutées. Ces définitions sont également stockées de manière à gérer l’ajout ou la suppression ultérieurs de champs ou de relations.

Le sous-générateur d’entités peut être remplacé par deux alternatives : JDL- Studio [42] et JHipster UML [2]. Le premier est un éditeur en ligne3 qui permet de définir les entités de l’application via une syntaxe nomméeJHipster Domain Language (JDL)[1] ; le résultat peut être téléchargé dans un fichier et importé dans une application JHipster. Le second fonctionne de manière similaire mais permet l’importation de diagrammes de classesUMLen lieu et place deJDL. L’avantage de ces deux approches est de fournir une solution déclarative permet- tant une édition graphique des entités, qui sont au cœur de l’application.

Bien que relativement mature et issu de l’industrie, JHipster présente quelques limitations qui le rendent inadapté à nos cas d’usage. D’abord, il impose un certain nombre de choix technologiques, comme l’utilisation de Java et Spring Boot pour la partie serveur, qui ne sont pas compatibles avec le contexte techno- logique de Startup Palace. Ensuite, JDL-Studio et JHipster UML ne semblent pas maintenus très activement, ce qui laisse à penser qu’ils ne sont pas vraiment in-

tégrés à la démarche proposée par JHipster, mais sont des éléments dispensables et d’un niveau de maturité différent. Enfin, si l’intégration de JDL-Studio et de JHipster UML permet de mettre en œuvre une démarche d’IDM, celle-ci reste en pratique trop limitée dans les cas où les spécifications peuvent varier de manière importante : le code généré doit bien souvent être modifié manuellement, et les éléments de personnalisation qui en découlent peuvent être écrasés par des générations ultérieures.

3.4

Qualité des services web

Nous avons vu en introduction que cette thèse a pour objectif de faciliter la variabilité des spécifications (voirSection 1.2.2). Cet aspect s’illustre avec le scénario suivant, qui, bien que fictif, est très courant :

1. le projet de développer des services web commence ;

2. des développeurs se basent sur des spécifications (version 1) et implé- mentent des fonctionnalités ;

3. pour une raison quelconque, les spécifications évoluent et une version 2 est écrite ;

4. les développeurs étudient le différentiel entre la version 1 et la version 2 et corrigent les fonctionnalités concernées ;

5. plus tard, on découvre qu’une fonctionnalité pourtant inchangée entre les versions 1 et 2 n’est plus fonctionnelle car elle reposait sur des modules qui ont été modifiés sans que tous les autres modules qui en dépendent (directement ou pas) ne soient à nouveau testés complètement.

Les conséquences peuvent être une indisponibilité du service, ou pire une cor- ruption des données qui sont persistées. Ce genre de défaut peut être découvert par les développeurs du projet, mais il arrive aussi que l’application défectueuse arrive en production et que des utilisateurs se heurtent aux problèmes, ce qu’il faut bien évidement éviter à tout prix. Heureusement il existe des solutions pour éviter ce genre de régressions.