Presentazione dell'Assistente per l'analisi del linguaggio naturale

Panoramica

Molte organizzazioni fanno affidamento su applicazioni sviluppate nel corso di un lungo periodo di tempo, da cui traggono vantaggio competitivo. Queste applicazioni subiscono modifiche significative nel corso del tempo, il che ne determina un crescente grado di complessità. In molti casi, gli sviluppatori originali di tali applicazioni non lavorano più all'interno delle organizzazioni. Ciò si traduce in difficoltà per i nuovi sviluppatori nel comprendere la base di codice per poter gestire queste applicazioni critiche in modo sicuro ed efficiente.

Rocket Software Enterprise e COBOL Analyzer vantano una lunga esperienza nel fornire agli sviluppatori informazioni tempestive su codebase complesse, consentendo anche ai programmatori meno esperti di svolgere attività di manutenzione. Molte di queste funzionalità di analisi sono state integrate negli IDE Eclipse^® e Visual Studio^® con Rocket^® Enterprise Developer e Visual COBOL. Tuttavia, l'avvento dell'intelligenza artificiale e delle interfacce in linguaggio naturale ha portato una nuova prospettiva su come gli sviluppatori desiderano interagire tramite i propri strumenti di sviluppo.

Nella versione 10.0 di Enterprise Developer e Visual COBOL, Rocket Software ha introdotto il Natural Language Analysis Assistant. Questa funzionalità aiuterà gli sviluppatori a comprendere appieno l'applicazione su cui stanno lavorando, utilizzando strumenti di sviluppo moderni e standard, familiari sia agli sviluppatori COBOL che a quelli non COBOL .

Gli sviluppatori potranno apportare modifiche ai file o ai programmi, certi che tali modifiche non avranno un impatto negativo sul resto dell'applicazione.

Analysis Assistant offre una finestra di chat in cui lo sviluppatore può porre domande in un linguaggio "umano" (per ora solo in inglese) sulle proprie applicazioni COBOL o PL/I confrontandole con una base di codice contenuta in un repository Enterprise Analyzer o COBOL Analyzer .

Sondaggio

Per garantire che la nostra futura roadmap tenga conto dei vostri commenti e delle vostre considerazioni, vi invitiamo a partecipare al nostro sondaggio.

Dietro le quinte

Quindi, come funziona?

Tre componenti di una panoramica architettonica di alto livello:

1. L'IDE

Qui lo sviluppatore pone una domanda nella finestra della chat e vengono visualizzati i risultati.

2. Il motore del linguaggio naturale

Il Natural Language Engine fa tutto il lavoro pesante. Prende la domanda in inglese dello sviluppatore, la trasforma in una o più query EA, le passa a EA e quindi genera una risposta in linguaggio naturale dal risultato, che viene poi inoltrata all'IDE.

3. Il server Remote Enterprise Analyzer

Qui troverete tutte le informazioni su questa applicazione potenzialmente enorme.

Il server EA esegue la query ricevuta dal motore e restituisce i risultati.

Ulteriori informazioni su The Natural Language Engine

Ora approfondiamo un po' di più il Natural Language Engine:

La funzionalità è stata sviluppata utilizzando Apache OpenNLP, una libreria di elaborazione del linguaggio naturale scritta in Java. Viene eseguita localmente e ha un ingombro piuttosto ridotto, senza richiedere processori avanzati come GPU o CUDA, tipici dell'intelligenza artificiale. È importante notare che il Natural Language Engine non è supportato da un Large Language Model (LLM).

Il motore è composto da due modelli precedentemente addestrati, che gestiscono due compiti distinti e distinti.

1. Categorizzazione

La fase di categorizzazione è quella in cui la query viene classificata. Si individua ciò che l'utente sta effettivamente chiedendo.

Ad esempio, l'utente sta chiedendo il conteggio di qualcosa nel programma, il flusso del programma o dei riferimenti?

2. Riconoscimento dell'entità nominata (NER)

Il modello NER viene utilizzato per individuare punti di interesse nella stringa di query che potrebbero fare riferimento a nomi. Ad esempio, nomi di programmi, nomi di sezioni o nomi di paragrafi.

3. Elaborazione linguistica

Infine, è necessaria un'ulteriore elaborazione linguistica per raccogliere ulteriore contesto per la query. Questo potrebbe includere la chiarificazione delle sottigliezze linguistiche di "A chiama B" o "A viene chiamato da B" e la garanzia che queste siano rappresentate correttamente nella query.

Una volta raccolte tutte le informazioni, vengono inviate potenzialmente più query a EA.

Per una dimostrazione dell'Assistente al linguaggio naturale, guarda questo video .

Linguaggio naturale e intelligenza artificiale per sviluppatori di applicazioni Mainframe SubSystem (MSS)

Oggigiorno è difficile trovare un articolo sulla stampa informatica e sui social media che non includa un riferimento all'intelligenza artificiale, in particolare per quanto riguarda l'assistenza agli sviluppatori nella scrittura del codice applicativo.

L'adozione di tali strumenti per linguaggi come Java e C#, ecc., nel mondo di COBOL e PLI, è aumentata. Tuttavia, i linguaggi predominanti per le applicazioni MSS, l'intelligenza artificiale o il linguaggio naturale, devono ancora diventare mainstream. Questo è particolarmente vero per le applicazioni che interagiscono con i sottosistemi mainframe di CICS, IMS e JES.

Molti dei fornitori che cercano di integrare l'intelligenza artificiale in questo scenario stanno estendendo le "soluzioni di refactoring automatizzato" esistenti per includerla, il che si traduce in una completa riscrittura e riarchitettura dell'applicazione utilizzando altri linguaggi. Tuttavia, questo approccio non ha una comprovata esperienza. Sebbene possa fornire supporto ad alcuni sviluppatori, non sono necessariamente gli sviluppatori ad aver curato la manutenzione dell'applicazione in primo luogo.

Noi di Rocket Software stiamo studiando come l'intelligenza artificiale e il linguaggio naturale possano aiutare gli sviluppatori di applicazioni MSS ad affrontare le loro sfide quotidiane, senza il rischio di dover convertire la base di codice in un altro linguaggio.

Quali sono quindi queste sfide quotidiane?

• Programmi monolitici difficili da manutenere e soprattutto da testare.
• Mancanza di conoscenza applicativa delle PMI
• Problemi di competenze relativi ai sottosistemi mainframe
• Mancanza di "shift left" e test automatizzati
• Tempi di consegna e costi elevati per la fornitura di ambienti di test

È importante notare che nessuna di queste sfide riguarda i linguaggi in cui sono scritte le applicazioni.

Abbiamo già iniziato ad esplorare le prime due sfide dell'elenco, discutendo del Natural Language Analysis Assistant in questo articolo. I continui investimenti e l'innovazione in quest'area ne amplieranno l'utilizzo sfruttando ulteriori funzionalità, già disponibili in Enterprise e COBOL Analyzer, ma rendendolo più semplice da usare.

Considerando il requisito generale di refactoring del codice monolitico, immaginiamo di scrivere nella finestra di chat "Crea un nuovo programma chiamato BBANKLCP" dalla sezione AA-Loan-Calculation del programma BBANK70P, che utilizza le funzionalità di slicing e refactoring del codice esistenti per creare quel nuovo programma e modificare il codice originale per utilizzarlo. Ciò contribuirebbe a scomporre il monolite, semplificando la manutenzione e rendendo questo codice più facile da testare, inclusa la semplificazione dell'introduzione dei test unitari.

Per quanto riguarda i test unitari, per introdurre il test "shift left", la richiesta successiva potrebbe essere "Scrivi un test unitario per il programma BBANKCLP". Questo potrebbe creare automaticamente tutti i componenti del Framework per i test unitari, inclusi (ove necessario) eventuali componenti di mocking/stubbing richiesti.

Facendo un ulteriore passo avanti e considerando la riduzione dei tempi di preparazione dei test, potremmo scrivere una richiesta "Create me an Enterprise Server test instance to run program BBANKCLP" . Questo fornirebbe un'istanza di test con la configurazione sufficiente a supportare il test, che sia CICS o Batch.

Il linguaggio COBOL non è una delle principali sfide che considereremmo di affrontare. Tuttavia, fornire il completamento o la generazione del codice al codice del sottosistema all'interno del programma COBOL sarebbe vantaggioso per gli sviluppatori alle prime armi con MSS. Ecco perché richieste come "Crea codice che fornisce input e output alla schermata CICS MBANK10 " potrebbero generare comandi CICS SEND e RECEIVE. Richieste simili potrebbero essere disponibili anche per l'accesso a file di dati, SQL e dati IMS. Ciò si applicherebbe anche al codice per chiamare altri programmi in un contesto CICS o per invocare un webservice.

L'ultimo problema, la mancanza di conoscenza dell'applicazione SME, è dove l'assistenza per la comprensione del codice e la documentazione diventa essenziale. Richieste come "Spiega il paragrafo AA-COMPLEX-CODE", "Come viene utilizzato l'elemento dati WS-UNCLEAR-FIELD-NAME" o "Qual è l'origine dell'elemento dati WS-WHAT-SETS-THIS-FIELD" sarebbero tutte utili per questa comprensione. E per aiutare ulteriormente il prossimo sviluppatore a mantenere questo programma, una richiesta di "Aggiungere questi commenti al codice" sarebbe utile.

Queste sono solo alcune delle idee che stiamo esplorando, basate sulle problematiche che abbiamo discusso con i nostri clienti. E ce ne saranno altre in arrivo.

Per aiutarci a garantire che la nostra futura tabella di marcia tenga conto delle vostre esigenze, vi invitiamo a partecipare al nostro sondaggio.

Provalo

Se sei già cliente di Enterprise, COBOL Analyzer, Enterprise Developer o Visual COBOL, puoi già accedere alla versione 10.0. 

In caso contrario, contatta il tuo Account Executive o richiedi una licenza di prova tramite questo link: https://www.rocketsoftware.com/products/enterprise-suite/request-contact

Sentiti libero di contattare Gary direttamente per qualsiasi domanda o feedback, sarò felice di discutere le tue sfide e le nostre soluzioni.