La génération de code est progressivement devenue un aspect important du développement de logiciels d'aujourd'hui. Le processus d'écriture de logiciels exige des développeurs qu'ils réécrivent fréquemment un code similaire à plusieurs reprises. Cette pratique peut être à la fois chronophage et fastidieuse. Les développeurs ont pour objectif d'écrire occasionnellement des abstractions afin de garder leurs applications DRY (do not repeat yourself), cependant écrire une abstraction n'est pas toujours optimal, cela peut rendre le code produit moins clair et plus difficile à travailler. C'est là que la génération de code est utile, elle peut présenter un moyen efficace de gérer le travail fastidieux de réécriture de code répétitif et passe-partout. Actuellement, chez Berger-Levrault (BL), le développement de modules/connecteurs pour la publication et la consommation de données, assurant l'interopérabilité des systèmes internes et externes est fait manuellement. De plus, la correction des dysfonctionnements se fait sur une base annuelle. sur une base ad hoc. Outre les coûts de développement et de correction que cela implique, cela ne répond pas aux exigences de réactivité de certains domaines d'activité. D'où la nécessité de construire des systèmes d'échange adaptables utilisant des nœuds d'interopérabilité partiellement ou totalement générés automatiquement. Ainsi, on peut gérer la complexité du développement de tels connecteurs d'interopérabilité à partir de zéro et réduire le temps de réécriture manuelle de leur code.

Interopérabilité et BL.MOM

Le concept d'interopérabilité est devenu un critère essentiel auquel doivent répondre les systèmes d'information. Lorsque les systèmes d'information sont mis en production, ils font partie d'un réseau de systèmes multiples. Si ces systèmes peuvent partager et échanger des informations sans dépendre de l'intervention d'un acteur particulier, on peut les qualifier de systèmes interopérables. Une fois l'interopérabilité établie entre les systèmes d'information communicants, elle assure une augmentation de la productivité et de l'efficacité des processus intra et inter-entreprises. Le manque d'interopérabilité entre les applications et leurs sous-systèmes est un problème critique qui peut affecter la qualité globale du service.
L'interopérabilité des données est mise en œuvre par des systèmes de transport et d'échange de données, ces derniers doivent être fiables et sécurisés pour garantir un haut niveau d'interopérabilité. Dans le cadre de l'interopérabilité des données, BL MOM (Message Oriented Middleware) est une API développée par Berger Levrault comme l'un des moyens de mettre en place des échanges de données entre les applications communicantes BL et avec des applications externes. BL MOM est une API basée sur la messagerie, c'est-à-dire que les données sont véhiculées sous forme de messages. L'envoi et la réception des messages sont gérés en établissant un modèle de communication de type "publish/subscribe" permettant aux applications d'être faiblement couplées. Pour ce faire, BL MOM utilise la fonction Protocole AMQP avec le soutien de RabbitMQ qui met en œuvre les concepts de ce protocole. Pour plus d'informations sur RabbitMQ et son processus global, le lecteur est renvoyé à [1] et [2].

Génération de code : solutions et techniques

Les générateurs de code sont des programmes qui peuvent produire le code source d'un autre logiciel, aidant ainsi les développeurs à résoudre les problèmes de code répétitifs qui ne peuvent être résolus par l'écriture d'abstractions. Ces outils peuvent être utiles pour améliorer la qualité et la productivité du code, faciliter la maintenance et raccourcir le temps de développement des logiciels. En outre, un code généré contiendrait très probablement moins d'erreurs et pourrait être facilement adapté pour maintenir l'évolution du logiciel généré. L'utilisation de techniques de configuration et de génération automatiques/semi-automatiques pour produire des créateurs de schémas de messages et des modules de connexion assurant l'interopérabilité dans le contexte de Berger-Levrault favoriserait la réutilisation du code existant et la possibilité de générer à la volée des modules d'interopérabilité. À son tour, ce processus de génération devrait contribuer à réduire le temps et les efforts nécessaires pour développer de nouveaux connecteurs à partir de zéro chaque fois que le besoin s'en fait sentir. Cela favorisera par la suite le principe de la liaison automatique des émetteurs et des récepteurs des données échangées, sous le contrôle d'une autorité de confiance.
Au fil des ans, de nombreux outils et méthodes de génération de code ont été proposés. La génération de code basée sur des modèles (TBCG) de l'ingénierie dirigée par les modèles (MDE) est sans doute l'une des techniques Model-to-Text les plus populaires. Les outils basés sur la TBCG peuvent être classés en deux groupes principaux : les outils basés sur le modèle et ceux basés sur le code. D'une part, les outils basés sur les modèles permettent de générer le code de base d'une application à partir d'un méta-modèle abstrait défini généralement par des diagrammes UML. Différents outils basés sur des modèles ont été proposés, tels que Acceleo, Xpand, Xtend 2et EGL. D'autre part, les outils basés sur le code prennent un modèle textuel en entrée pour produire du code dans un langage choisi en sortie. Voici un exemple de ces outils : JET, Apache Velocityet FreeMarker. Les outils basés sur des modèles sont les plus aptes à manipuler des données d'entrée complexes, fournissant un support adéquat pour les modèles non triviaux. Les outils basés sur le code se sont avérés plus performants que ces derniers dans de nombreuses études, en particulier lorsqu'il s'agit de manipuler des modèles plus importants. Ces outils sont largement utilisés pour la génération de code passe-partout, cependant, il en existe plusieurs autres conçus pour effectuer la transformation et la génération de code tout en adoptant diverses techniques Model-to-Text ou Text-to-Text. Certains de ces outils sont des analyseurs de code qui conviennent mieux aux générations de code intuitives, directes et plus spécifiques, tels que ANTLR, Rôtissoireet JavaParser.

Outils de rétroconception tels que MoDisco peut être bénéfique dans le contexte de la génération de code. L'idée MoDisco a été construit, qui consiste en l'extraction de modèles à partir de systèmes patrimoniaux existants peut être utile pour gérer leurs complexités. Ainsi, il fournit un support utile pour raisonner sur les systèmes, les réutiliser et les faire évoluer.

Générateur de connecteurs BL MOM

Le générateur de connecteurs BL MOM est le nom de notre proposition pour la génération automatique de connecteurs d'interopérabilité entiers ou partiels à utiliser par nos applications. Le générateur peut produire, sur la base de paramètres de configuration, des modules de publication/consommation de messages, des créateurs de schémas de messages, des wrappers de messages et des modules d'autoconfiguration. L'objectif principal est d'alléger la complexité de l'écriture du code de nouveaux connecteurs et créateurs de schémas à partir de zéro et de réduire leur temps de développement global. Plus précisément, notre outil peut générer le contexte d'interopérabilité une fois pour plusieurs consommateurs et éditeurs, qui consiste en :

• Un site projet d'autoconfiguration pour prendre en charge les structures de configuration et l'autoconfiguration ;
• A projet d'enveloppes de messages pour le traitement des types de messages ;
• A projet de définition du schéma de messages bibliothèques de schémas de messages encapsulants et spécification (lorsqu'il s'agit de Avro est utilisé) et tous les éléments qui sont communs à tous les connecteurs d'un même échange de données (contexte métier). En outre, il génère des squelettes de projets consommateurs et éditeurs à enrichir par les développeurs.

Les modules d'interopérabilité de la BL sont plus souvent développés en tant que Applications Spring BootNous avons donc choisi d'utiliser certaines API/outils Java qui permettent de générer des squelettes personnalisés de modules d'interopérabilité et des projets entiers de créateurs de schémas de messages, de wrappers de messages et d'autoconfiguration. En particulier, parmi d'autres bibliothèques, nous utilisons (i) Initialisation du printemps pour générer des squelettes de projets Java, (ii) Torréfacteur Java pour la génération de codes de classe, et (iii) Apache Velocity pour la génération de projets POM, de fichiers Html pour la spécification, et d'autres fichiers. En combinaison, ces outils sont utilisés pour générer des projets prêts à l'emploi. Applications Spring Bootadaptés pour répondre aux objectifs initiaux d'interopérabilité. Le choix des outils a été fait après avoir évalué différents outils basés sur des modèles pour la génération de code, ainsi que quelques outils basés sur le code et l'ingénierie inverse. Nous avons conclu que ce type d'outil n'est pas adapté à nos besoins particuliers, consistant en la génération de code répétitif au sein de nos modules d'interopérabilité. En fait, nous pensons qu'une solution basée sur des outils tels que Xtend2, Modisco, JHipsteretc. n'offriraient pas la flexibilité souhaitée, qui est cruciale pour nos perspectives. La solution optimale serait facilement adaptable pour répondre aux différentes exigences, anciennes et nouvelles, et permettrait d'envisager des cas d'utilisation avancés à l'avenir, comme l'adaptation des connecteurs existants, des schémas de messages, etc.
La première étape, avant de procéder à la génération du code, consiste à analyser le code existant des modules de connecteurs et des projets de définition de schémas de messages, afin de différencier les éléments redondants et variables du code. Ces derniers peuvent représenter les données d'entrée du système de génération qui doivent être prises en compte pour adapter chaque projet généré à un contexte métier donné. Pour ce faire, nous nous appuyons sur une formalisation à un méta-niveau décrivant la représentation et les relations existantes entre les éléments variables qui permettent la configuration d'un connecteur et d'un module de définition de schéma de messages. 

Chaque module de connexion possède un ensemble de propriétés prédéfinies liées au module java à générer, aux propriétés requises en entrée par BL-MOM, telles que le module, le tenantId, ou aux informations d'identification de connexion à l'interface utilisateur. RabbitMQ serveur. Il est également possible d'avoir des propriétés de configuration spécifiques au projet. Chaque module connecteur est lié par la publication ou l'abonnement à un ou plusieurs Topics, chacun d'entre eux pouvant véhiculer un ensemble d'événements métier. Les modules de définition des schémas de messages permettent de créer des bibliothèques Java de Apache Avro et de maintenir une documentation compatible avec le code. Dans ce cas, le code complet de ce type de projet peut être généré automatiquement à partir d'une définition des schémas de messages à inclure dans le projet. Un schéma de message est caractérisé par un Sujet d'intérêt, un ensemble de sous-schémas, et la définition des champs composant chaque schéma : le nom, la taille maximale, le caractère optionnel ou non, et le type. Ce dernier peut lui-même être un sous-schéma.
Afin de générer initialement un squelette pour les différents types de projets de modules d'interopérabilité, une instance d'une Initialisation du printemps est utilisé. Pour interagir avec ce serveur, nous utilisons la fonction Initialisation du printemps API REST pour pouvoir fournir les paramètres de configuration du projet que nous souhaitons générer. Le principal avantage de l'utilisation de notre propre déploiement Initialisation du printemps est que nous pouvons personnaliser les squelettes générés en fonction de nos besoins spécifiques. Par exemple, en définissant une version spécifique de Java, ou en ajoutant nos propres dépendances qui ne seraient pas incluses dans la version publique du squelette. Initialisation du printemps.

L'architecture du générateur de connecteurs BL MOM se compose d'un ensemble d'éléments faiblement couplés REST des services, chacun effectuant des tâches de génération spécifiques et communiquant entre eux par le biais de leurs points de terminaison pour générer différents types de projets, en fonction des paramètres de configuration reçus des utilisateurs finaux sous la forme de messages JSON :

• Le site Initialiser le service est responsable de la production de squelettes de projets Spring personnalisés en interagissant avec l'élément Initialisation du printemps serveur.
• Le service de génération de créateurs de schémas génère des projets pour créer des bibliothèques Java de Apache Avro messages. Il demande également au service de génération Concordian de maintenir des spécifications Html de ces messages compatibles avec leur code.
• Le service de génération de connecteurs supervise la génération de parties des modules de production et de consommation de messages d'un ou plusieurs sujets existants. Ces modules doivent être complétés pour prendre en compte le code lié au contexte commercial, dans lequel nous pouvons spécifier par exemple ce qui doit être fait après la réception d'un message.
• Enfin, les services de génération de wrappers de messages et d'autoconfiguration génèrent des modules correspondant à leurs noms respectifs.

Le générateur de connecteurs BL MOM permet de créer automatiquement non seulement des projets de définition de schéma de message, de wrapper de message et d'auto-configuration, mais aussi autant d'éditeurs et de consommateurs que nécessaire pour un même contexte d'échange de données. En d'autres termes, un wrapper est généré une fois pour chaque contexte d'interopérabilité, et autant de connecteurs que nécessaire sont créés pour chaque nouveau besoin.