Wir stellen den Assistenten für die Analyse natürlicher Sprache vor.

Überblick

Viele Organisationen sind auf Anwendungen angewiesen, die über einen langen Zeitraum entwickelt wurden, und erzielen dadurch Wettbewerbsvorteile. Diese Anwendungen verändern sich im Laufe der Zeit erheblich, was zu einer zunehmenden Komplexität führt. Oftmals arbeiten die ursprünglichen Entwickler dieser Anwendungen nicht mehr in den jeweiligen Organisationen. Dies führt dazu, dass neue Entwickler Schwierigkeiten haben, die Codebasis zu verstehen, um diese kritischen Anwendungen sicher und effizient warten zu können.

Rocket Softwares Enterprise und COBOL Analyzer verfügen über langjährige Erfahrung darin, Entwicklern bei Änderungen an komplexen Codebasen direkt Informationen bereitzustellen und so auch weniger erfahrenen Entwicklern die Durchführung von Wartungsaufgaben zu ermöglichen. Viele dieser Analysefunktionen wurden mit Rocket^® Enterprise Developer und Visual COBOL in die IDEs Eclipse^® und Visual Studio^® integriert. Doch das Aufkommen von KI und natürlichen Sprachschnittstellen hat neue Perspektiven für die Interaktion von Entwicklern mit ihren Entwicklungswerkzeugen eröffnet.

In der Version 10.0 von Enterprise Developer und Visual COBOL hat Rocket Software den Natural Language Analysis Assistant eingeführt. Diese Funktion unterstützt Entwickler dabei, die gesamte Anwendung, an der sie arbeiten, mithilfe moderner, standardisierter Entwicklungswerkzeuge zu verstehen, die sowohl COBOL als auch Nicht COBOL Entwicklern vertraut sind.

Entwickler können Änderungen an den Dateien oder Programmen vornehmen, in der Gewissheit, dass diese Änderungen keine negativen Auswirkungen auf den Rest der Anwendung haben werden.

Der Analyseassistent bietet ein Chatfenster, in dem der Entwickler Fragen in „menschlicher“ Sprache (derzeit nur Englisch) zu seinen COBOL oder PL/I-Anwendungen gegenüber einer Codebasis stellen kann, die in einem Enterprise Analyzer oder COBOL Analyzer Repository gespeichert ist.

Umfrage

Um sicherzustellen, dass Ihr Feedback und Ihre Anregungen in unsere zukünftige Roadmap einfließen, bitten wir Sie, an unserer Umfrage teilzunehmen.

Hinter den Kulissen

Wie funktioniert das genau?

Drei Komponenten eines architektonischen Überblicks auf hoher Ebene:

1. Die IDE

Hier stellt der Entwickler eine Frage im Chatfenster, und die Ergebnisse werden angezeigt.

2. Die Natural Language Engine

Die Natural Language Engine übernimmt die gesamte Arbeit. Sie nimmt die englischsprachige Frage des Entwicklers entgegen, wandelt sie in eine oder mehrere EA-Anfragen um, übergibt diese an EA und generiert anschließend eine natürlichsprachliche Antwort, die an die IDE zurückgesendet wird.

3. Der Remote Enterprise Analyzer Server

Alle Informationen über die potenziell riesige Anwendung finden Sie hier.

Der EA-Server führt die vom Engine empfangene Abfrage aus und gibt die Ergebnisse zurück.

Mehr zur Natural Language Engine

Nun wollen wir uns etwas genauer mit der Natural Language Engine befassen:

Die Funktionalität wurde mit Apache OpenNLP entwickelt, einer in Java geschriebenen Bibliothek zur Verarbeitung natürlicher Sprache. Sie läuft lokal und benötigt nur wenig Ressourcen, da sie keine leistungsstarken Prozessoren wie GPUs oder CUDA erfordert, die für KI-Anwendungen typisch sind. Es ist anzumerken, dass die Natural Language Engine auch kein großes Sprachmodell (LLM) verwendet.

Die Engine beinhaltet zwei im Voraus trainierte Modelle. Sie bearbeiten zwei separate und unterschiedliche Aufgaben.

1. Kategorisierung

In der Kategorisierungsphase wird die Anfrage klassifiziert. Dabei wird ermittelt, wonach der Benutzer tatsächlich fragt.

Fragt der Benutzer beispielsweise nach der Anzahl von Elementen im Programm, nach dem Programmablauf oder nach Referenzen?

2. Named Entity Recognition (NER)

Das NER-Modell dient dazu, in der Suchanfrage relevante Stellen zu finden, die sich auf Namen beziehen können. Beispiele hierfür sind Programmnamen, Abschnittsnamen oder Absatznamen.

3. Sprachliche Verarbeitung

Abschließend erfolgt eine weitere linguistische Verarbeitung, um zusätzlichen Kontext für die Anfrage zu gewinnen. Dies kann die Klärung der sprachlichen Feinheiten von „Ruft A B an?“ oder „Wird A von B angerufen?“ umfassen und sicherstellen, dass dies in der Anfrage korrekt wiedergegeben wird.

Sobald alle Informationen gesammelt wurden, werden gegebenenfalls mehrere Anfragen an EA gesendet.

Eine Demonstration des Natural Language Assistant finden Sie in diesem Video .

Natürliche Sprache und künstliche Intelligenz für Entwickler von Mainframe-Subsystem (MSS)-Anwendungen

Es ist heutzutage schwer, in der IT-Presse und in den sozialen Medien einen Artikel zu finden, der nicht irgendeinen Bezug auf künstliche Intelligenz enthält, insbesondere im Zusammenhang mit der Unterstützung von Entwicklern beim Schreiben von Anwendungscode.

In der Welt von COBOL und PLI hat die Nutzung solcher Tools für Sprachen wie Java und C# etc. zugenommen. Die vorherrschenden Sprachen für MSS-Anwendungen, KI oder natürliche Sprache, sind jedoch noch nicht weit verbreitet. Dies gilt insbesondere für Anwendungen, die mit den Mainframe-Subsystemen von CICS, IMS und JES interagieren.

Viele Anbieter, die KI in diesem Bereich einsetzen möchten, erweitern bestehende automatisierte Refactoring-Lösungen um KI. Dies führt zu einer kompletten Neuentwicklung und Umstrukturierung der Anwendung in anderen Programmiersprachen. Dieser Ansatz hat sich jedoch nicht bewährt. Er mag zwar einigen Entwicklern helfen, aber nicht unbedingt denjenigen, die die Anwendung ursprünglich betreut haben.

Wir bei Rocket Software untersuchen, wie KI und natürliche Sprache Entwickler von MSS-Anwendungen bei ihren täglichen Herausforderungen unterstützen können, ohne das Risiko einer Konvertierung der Codebasis in eine andere Sprache.

Was sind also diese alltäglichen Herausforderungen?

• Monolithische Programme, die schwer zu warten und insbesondere schwer zu testen sind.
• Mangelndes Anwendungswissen von KMU
• Kompetenzprobleme im Zusammenhang mit den Mainframe-Subsystemen
• Mangel an „Shift-Left“- und automatisierten Tests
• Lange Vorlaufzeiten und hohe Kosten für die Bereitstellung von Testumgebungen

Es ist wichtig festzuhalten, dass keine dieser Herausforderungen mit den Sprachen zusammenhängt, in denen die Anwendungen geschrieben sind.

Wir haben die ersten beiden Herausforderungen auf der Liste bereits im Zusammenhang mit dem Natural Language Analysis Assistant (NLA) in diesem Blogbeitrag angesprochen. Kontinuierliche Investitionen und Innovationen in diesem Bereich werden die Einsatzmöglichkeiten erweitern, indem zusätzliche, bereits in Enterprise und COBOL Analyzer verfügbare Funktionen genutzt und die Bedienung vereinfacht werden.

Betrachten wir die allgemeine Anforderung der Refaktorisierung monolithischer Codes. Stellen wir uns vor, wir schreiben im Chatfenster : „Erstellen Sie ein neues Programm namens BBANKLCP aus dem Abschnitt AA-Kreditberechnung des Programms BBANK70P .“ Dieses Programm nutzt dann die vorhandenen Funktionen für Code-Slicing und Refactoring, um das neue Programm zu erstellen und den ursprünglichen Code entsprechend anzupassen. Dadurch wird der Monolith aufgebrochen, die Wartung vereinfacht und der Code leichter testbar, was auch die Einführung von Unit-Tests erleichtert.

Um Unit-Tests zu fördern und das „Shift-Left“-Testing einzuführen, könnte die nächste Anfrage lauten : „Schreiben Sie einen Unit-Test für das Programm BBANKCLP.“ Dadurch könnten automatisch alle Komponenten des Unit-Test-Frameworks erstellt werden, einschließlich (falls erforderlich) aller benötigten Mocking-/Stubbing-Komponenten.

Um die Testvorbereitungszeiten weiter zu verkürzen, könnten wir eine Anfrage stellen : „Erstelle mir eine Enterprise Server -Testinstanz zum Ausführen des Programms BBANKCLP“ . Dadurch würde eine Testinstanz mit genau der für den Test erforderlichen Konfiguration bereitgestellt, egal ob es sich um CICS oder Batch handelt.

Die COBOL Sprache zählt nicht zu den Hauptherausforderungen, die wir angehen würden. Die Bereitstellung von Codevervollständigung oder -generierung für Subsystemcode innerhalb des COBOL Programms wäre jedoch für Entwickler, die neu in der Arbeit mit MSS sind, von Vorteil. Daher könnten Anfragen wie „ Code erstellen, der Ein- und Ausgaben für den CICS-Bildschirm MBANK10 bereitstellt“ CICS-SEND- und RECEIVE-Befehle generieren. Ähnliche Anfragen könnten auch für den Zugriff auf Datendateien, SQL- und IMS-Daten verfügbar sein. Dies würde gleichermaßen für Code gelten, der andere Programme in einem CICS-Kontext aufruft oder einen Webservice initiiert.

Das letzte Problem, der Mangel an Fachkenntnissen im Anwendungsbereich, macht Unterstützung beim Codeverständnis und der Dokumentation unerlässlich. Anfragen wie „ Erläutern Sie den Absatz AA-COMPLEX-CODE“, „Wie wird das Datenelement WS-UNCLEAR-FIELD-NAME verwendet ?“ oder „Woher stammt das Datenelement WS-WHAT-SETS-THIS-FIELD?“ würden das Verständnis erleichtern. Um dem nächsten Entwickler die Wartung des Programms zu erleichtern, wäre es zudem hilfreich, wenn diese Kommentare im Code ergänzt würden.

Dies sind nur einige der Ideen, die wir auf Grundlage der Gespräche mit unseren Kunden untersuchen. Und weitere werden folgen.

Um sicherzustellen, dass unsere zukünftige Roadmap Ihre Bedürfnisse berücksichtigt, bitten wir Sie, an unserer Umfrage teilzunehmen.

Probier es aus

Wenn Sie bereits Kunde von Enterprise, COBOL Analyzer, Enterprise Developer oder Visual COBOL sind, können Sie bereits auf die Version 10.0 zugreifen. 

Falls nicht, wenden Sie sich bitte an Ihren Kundenbetreuer oder fordern Sie über diesen Link eine Testlizenz an: https://www.rocketsoftware.com/products/enterprise-suite/request-contact

Sie können Gary gerne direkt kontaktieren. Bei Fragen oder Anregungen stehe ich Ihnen gerne zur Verfügung und bespreche mit Ihnen Ihre Herausforderungen und unsere Lösungsansätze.