Présentation de l'assistant d'analyse du langage naturel

Aperçu

De nombreuses organisations dépendent d'applications développées sur une longue période et en tirent un avantage concurrentiel. Ces applications subissent d'importantes modifications au fil du temps, ce qui engendre une complexité croissante. Souvent, les développeurs d'origine ne travaillent plus au sein de ces organisations. Par conséquent, les nouveaux développeurs peinent à comprendre le code source afin de pouvoir maintenir ces applications critiques de manière sûre et efficace.

Les Enterprise et COBOL Analyzer de Rocket Software bénéficient d'une longue expérience dans l'analyse des code source complexes, permettant aux développeurs d'obtenir des informations précieuses au moment précis où ils modifient des bases de code complexes et facilitant ainsi la maintenance, même pour les développeurs débutants. Nombre de ces fonctionnalités d'analyse ont été intégrées aux environnements de développement intégrés Eclipse^® et Visual Studio^® grâce à Rocket^® Enterprise Developer et Visual COBOL. Cependant, l'avènement de l'IA et des interfaces en langage naturel a profondément modifié la façon dont les développeurs interagissent avec leurs outils de développement.

Dans la version 10.0 d' Enterprise Developer et de Visual COBOL, Rocket Software a introduit l'Assistant d'analyse du langage naturel. Cette fonctionnalité aidera les développeurs à comprendre l'intégralité de l'application sur laquelle ils travaillent grâce à des outils de développement modernes et standardisés, familiers aussi bien aux développeurs COBOL qu'aux COBOL .

Les développeurs pourront apporter des modifications aux fichiers ou aux programmes, en étant assurés que ces modifications n'auront pas d'impact négatif sur le reste de l'application.

L'assistant d'analyse propose une fenêtre de discussion où le développeur peut poser des questions en langage « humain » (uniquement en anglais pour le moment) sur ses applications COBOL ou PL/I par rapport à une base de code hébergée dans un référentiel Enterprise Analyzer ou COBOL Analyzer .

Enquête

Pour nous aider à prendre en compte vos commentaires et vos considérations dans notre future feuille de route, veuillez répondre à notre enquête.

Dans les coulisses

Alors, comment ça marche ?

Les trois composantes d'une vue d'ensemble architecturale de haut niveau:

1. L'IDE

C'est ici que le développeur pose une question dans la fenêtre de chat et que les résultats s'affichent.

2. Le moteur de traitement du langage naturel

Le moteur de langage naturel effectue tout le travail complexe. Il prend la question en anglais du développeur, la transforme en une ou plusieurs requêtes EA, transmet ces requêtes à EA, puis génère une réponse en langage naturel à partir du résultat, qui est renvoyée à l'IDE.

3. Le serveur Enterprise Analyzer à distance

Toutes les informations concernant cette application potentiellement très importante se trouvent ici.

Le serveur EA exécute la requête qu'il reçoit du moteur et renvoie les résultats.

Plus d'informations sur le moteur de langage naturel

À présent, approfondissons un peu le moteur de langage naturel:

Cette fonctionnalité a été développée à l'aide d' Apache OpenNLP, une bibliothèque de traitement automatique du langage naturel écrite en Java. Elle s'exécute localement et est peu gourmande en ressources, ne nécessitant pas de processeurs avancés tels qu'un GPU ou CUDA, généralement utilisés en IA. Il est important de noter que le moteur de traitement automatique du langage naturel ne repose pas non plus sur un modèle de langage étendu (LLM).

Le moteur comprend deux modèles pré-entraînés. Ils gèrent deux tâches distinctes.

1. Catégorisation

La phase de catégorisation consiste à classer la requête. Elle détermine ce que l'utilisateur demande réellement.

Par exemple, l'utilisateur demande-t-il le nombre d'éléments dans le programme, le déroulement du programme ou des références ?

2. Reconnaissance d'entités nommées (NER)

Le modèle NER est utilisé pour localiser dans la chaîne de requête les points d'intérêt susceptibles de faire référence à des noms. Par exemple, des noms de programmes, de sections ou de paragraphes.

3. Traitement linguistique

Enfin, un traitement linguistique supplémentaire est effectué afin de recueillir des informations contextuelles complémentaires pour la requête. Il peut s'agir notamment de clarifier les subtilités linguistiques de « A appelle-t-il B » ou « A est-il appelé par B ? » et de s'assurer que cela est correctement représenté dans la requête.

Une fois toutes les informations recueillies, plusieurs requêtes peuvent être envoyées à EA.

Pour une démonstration de l'assistant en langage naturel, regardez cette vidéo .

Langage naturel et intelligence artificielle pour les développeurs d'applications Mainframe SubSystem (MSS)

Il est difficile de trouver aujourd'hui dans la presse informatique et sur les réseaux sociaux un article qui ne fasse pas référence à l'intelligence artificielle, notamment en ce qui concerne l'assistance aux développeurs dans l'écriture du code applicatif.

On observe une adoption croissante de ces outils pour des langages comme Java et C#, notamment dans l'univers COBOL et PLI. Cependant, les langages prédominants pour les applications MSS, l'IA et le traitement du langage naturel, restent encore marginal. Cela est particulièrement vrai pour les applications interagissant avec les sous-systèmes mainframe CICS, IMS et JES.

De nombreux fournisseurs souhaitant intégrer l'IA à ce contexte étendent leurs solutions de refactorisation automatisée existantes pour y inclure l'IA, ce qui entraîne une réécriture et une refonte complètes de l'application dans d'autres langages. Cependant, cette approche n'a pas fait ses preuves. Bien qu'elle puisse aider certains développeurs, elle ne provient pas nécessairement de ceux qui ont initialement maintenu l'application.

Chez Rocket Software, nous étudions comment l'IA et le langage naturel peuvent aider les développeurs d'applications MSS à relever leurs défis quotidiens, sans le risque de convertir le code source dans un autre langage.

Alors, quels sont ces défis quotidiens ?

• Des programmes monolithiques difficiles à maintenir et surtout à tester.
• Manque de connaissances des PME en matière d'application
• Problèmes de compétences liés aux sous-systèmes du mainframe
• Absence de « décalage vers la gauche » et de tests automatisés
• Délais et coûts importants liés à la mise en place d'environnements de test

Il est important de noter qu'aucun de ces défis n'est lié aux langages dans lesquels les applications sont écrites.

Nous avons déjà commencé à explorer les deux premiers défis de cette liste en évoquant l'assistant d'analyse du langage naturel plus haut dans cet article. Les investissements et les innovations continus dans ce domaine permettront d'étendre son utilisation en exploitant davantage de fonctionnalités, déjà disponibles dans Enterprise et COBOL Analyzer, tout en simplifiant son utilisation.

Si l'on considère l'exigence générale de refactorisation du code monolithique, imaginons que l'on écrive dans la fenêtre de discussion: « Créer un nouveau programme appelé BBANKLCP à partir de la section AA-Calcul-de-prêt du programme BBANK70P » . Ce programme utiliserait alors les fonctionnalités existantes de découpage et de refactorisation pour créer ce nouveau programme et modifier le code original en conséquence. Cela permettrait de décomposer le monolithe, de simplifier la maintenance et de faciliter les tests, notamment en simplifiant l'introduction des tests unitaires.

Concernant les tests unitaires, afin de faciliter l'adoption du « shift left testing », la prochaine requête pourrait être: « Écrire un test unitaire pour le programme BBANKCLP ». Cela permettrait de créer automatiquement tous les composants du framework de tests unitaires, y compris (le cas échéant) les composants de simulation/stubbing nécessaires.

Pour aller plus loin et réduire les délais de préparation des tests, nous pourrions formuler une requête: « Créez-moi une instance de test Enterprise Server pour exécuter le programme BBANKCLP » . Cela provisionnerait une instance de test avec la configuration minimale requise pour le test, qu’il s’agisse d’un test CICS ou par lots.

Le langage COBOL ne figure pas parmi les principaux défis que nous envisageons de relever. Cependant, la fourniture de fonctionnalités de saisie semi-automatique ou de génération de code pour les sous-systèmes au sein du programme COBOL serait avantageuse pour les développeurs découvrant MSS. C'est pourquoi des requêtes telles que « Créer du code permettant la saisie et la sortie vers l'écran CICS MBANK10 » pourraient générer les commandes CICS SEND et RECEIVE. Des requêtes similaires pourraient également être disponibles pour accéder aux fichiers de données, aux données SQL et aux données IMS. Ceci s'appliquerait également au code permettant d'appeler d'autres programmes dans un contexte CICS ou d'invoquer un service web.

Le dernier point, le manque de connaissances des experts métiers, rend l'assistance à la compréhension du code et à la documentation essentielle. Des demandes telles que « Expliquez le paragraphe AA-COMPLEX-CODE », « Comment l'élément de données WS-UNCLEAR-FIELD-NAME est-il utilisé ? » ou « Quelle est l'origine de l'élément de données WS-WHAT-SETS-THIS-FIELD ? » contribueraient grandement à cette compréhension. De plus, pour faciliter la maintenance de ce programme par le prochain développeur, l' ajout de commentaires au code serait également bénéfique.

Ce ne sont là que quelques-unes des idées que nous explorons, inspirées des problématiques abordées avec nos clients. Et d'autres suivront.

Pour nous aider à faire en sorte que notre feuille de route future tienne compte de vos besoins, veuillez participer à notre enquête.

Essayez-le

Si vous êtes déjà client d' Enterprise, de COBOL Analyzer, Enterprise Developer ou de Visual COBOL, vous pouvez déjà accéder à la version 10.0. 

Sinon, veuillez contacter votre responsable de compte ou demander une licence d'essai via ce lien: https://www.rocketsoftware.com/products/enterprise-suite/request-contact

N'hésitez pas à contacter Gary directement. N'hésitez pas à me faire part de vos questions ou commentaires, je serai ravi de discuter de vos défis et de nos solutions.