Presentamos el Asistente de Análisis del Lenguaje Natural.

Descripción general

Muchas organizaciones dependen de aplicaciones desarrolladas a lo largo del tiempo y obtienen una ventaja competitiva gracias a ellas. Estas aplicaciones experimentan cambios significativos durante ese período, lo que genera una complejidad creciente. En muchos casos, los desarrolladores originales ya no trabajan en estas organizaciones. Esto provoca que los nuevos desarrolladores tengan dificultades para comprender el código fuente y así poder mantener estas aplicaciones críticas de forma segura y eficiente.

Rocket Software Enterprise y COBOL Analyzer cuentan con una larga trayectoria proporcionando a los desarrolladores información útil en el momento de los cambios en bases de código complejas, lo que permite a los desarrolladores noveles realizar tareas de mantenimiento. Muchas de estas capacidades de análisis se han integrado en los IDE Eclipse^® y Visual Studio^® con Rocket^® Enterprise Developer y Visual COBOL. Sin embargo, la llegada de la IA y las interfaces de lenguaje natural ha traído consigo una nueva perspectiva sobre cómo los desarrolladores desean interactuar con sus herramientas de desarrollo.

En la versión 10.0 de Enterprise Developer y Visual COBOL, Rocket Software introdujo el Asistente de Análisis de Lenguaje Natural. Esta función ayudará a los desarrolladores a comprender la aplicación completa en la que trabajan mediante herramientas de desarrollo modernas y estándar, familiares tanto para desarrolladores COBOL como para desarrolladores no COBOL .

Los desarrolladores podrán realizar cambios en los archivos o programas, con la seguridad de que estos cambios no tendrán un impacto negativo en el resto de la aplicación.

El Asistente de análisis ofrece una ventana de chat donde el desarrollador puede hacer preguntas en lenguaje "humano" (por ahora solo inglés) acerca de sus aplicaciones COBOL o PL/I contra una base de código guardada en un repositorio de Enterprise Analyzer o COBOL Analyzer .

Encuesta

Para ayudarnos a garantizar que nuestra hoja de ruta futura incluya sus comentarios y consideraciones, le rogamos que responda a nuestra encuesta.

Entre bastidores

¿Cómo funciona esto?

Tres componentes de una visión general de la arquitectura de alto nivel:

1. El IDE

Aquí es donde el desarrollador hace una pregunta en la ventana de chat y se muestran los resultados.

2. El motor de procesamiento del lenguaje natural

El motor de lenguaje natural se encarga de todo el trabajo pesado. Toma la pregunta en inglés del desarrollador, la convierte en una o varias consultas para EA, las pasa a EA y, a continuación, genera una respuesta en lenguaje natural a partir del resultado, que se devuelve al IDE.

3. El servidor de Enterprise Analyzer remoto

Toda la información sobre esta aplicación, que tiene un potencial enorme, se encuentra aquí.

El servidor EA ejecuta la consulta que recibe del motor y devuelve los resultados.

Más información sobre el motor de procesamiento del lenguaje natural.

Ahora profundicemos un poco más en el motor de lenguaje natural:

La funcionalidad se ha desarrollado utilizando Apache OpenNLP, una biblioteca de procesamiento del lenguaje natural escrita en Java. Se ejecuta localmente y tiene un tamaño reducido, sin requerir procesadores avanzados como GPU o CUDA, típicos de la IA. Cabe destacar que el motor de lenguaje natural tampoco se basa en un modelo de lenguaje grande (LLM).

El motor incluye dos modelos que han sido entrenados previamente. Estos se encargan de dos tareas separadas y distintas.

1. Categorización

La fase de categorización es donde se clasifica la consulta. Determina qué es lo que el usuario está solicitando realmente.

Por ejemplo, ¿el usuario está solicitando un recuento de algo en el programa, o un diagrama de flujo del programa, o referencias?

2. Reconocimiento de Entidades Nombradas (NER)

El modelo NER se utiliza para localizar puntos de interés en la cadena de consulta que pueden hacer referencia a nombres. Por ejemplo, nombres de programas, nombres de secciones o nombres de párrafos.

3. Procesamiento lingüístico

Finalmente, se realiza un procesamiento lingüístico adicional para obtener contexto extra para la consulta. Esto podría incluir aclarar las sutilezas lingüísticas de "A llama a B" o "A es llamado por B" y asegurar que esto se represente correctamente en la consulta.

Una vez recopilada toda la información, se envían potencialmente varias consultas a EA.

Para ver una demostración del Asistente de Lenguaje Natural, vea este vídeo .

Procesamiento del lenguaje natural e inteligencia artificial para desarrolladores de aplicaciones de subsistemas de mainframe (MSS).

Hoy en día es difícil encontrar un artículo en la prensa especializada en tecnología y en las redes sociales que no incluya alguna referencia a la Inteligencia Artificial, en particular en lo que respecta a la asistencia a los desarrolladores en la escritura de código para aplicaciones.

Se ha incrementado la adopción de herramientas como Java y C#, entre otros, en el ámbito de COBOL y PLI. Sin embargo, los lenguajes predominantes para aplicaciones MSS, como la IA o el lenguaje natural, aún no se han generalizado. Esto es especialmente cierto para las aplicaciones que interactúan con los subsistemas de mainframe de CICS, IMS y JES.

Muchos proveedores que buscan incorporar IA a este escenario están ampliando las soluciones de refactorización automatizada existentes para incluir IA, lo que implica una reescritura y reestructuración completa de la aplicación utilizando otros lenguajes. Sin embargo, este enfoque no tiene un historial comprobado. Si bien puede ser útil para algunos desarrolladores, no necesariamente se trata de los desarrolladores que mantuvieron la aplicación originalmente.

En Rocket Software estamos analizando cómo la IA y el lenguaje natural pueden ayudar a los desarrolladores de aplicaciones MSS con sus desafíos diarios, sin el riesgo de convertir la base del código a otro lenguaje.

¿Cuáles son, entonces, esos desafíos cotidianos?

• Programas monolíticos que son difíciles de mantener y, sobre todo, de probar.
• Falta de conocimiento de la PYME en la aplicación
• Problemas de habilidades relacionados con los subsistemas de mainframe
• Falta de 'desplazamiento a la izquierda' y de pruebas automatizadas
• Amplio plazo de entrega y coste de aprovisionamiento de entornos de prueba

Es importante señalar que ninguno de estos desafíos está relacionado con los idiomas en los que están escritas las aplicaciones.

Ya comenzamos a explorar los dos primeros desafíos de la lista al hablar del Asistente de Análisis de Lenguaje Natural en esta misma entrada. La inversión e innovación continuas en este ámbito ampliarán su uso al aprovechar nuevas funciones, ya disponibles en Enterprise y COBOL Analyzer, que lo simplificarán.

Si consideramos el requisito general de refactorizar código monolítico, imaginemos escribir en la ventana de chat : «Crear un nuevo programa llamado BBANKLCP a partir de la sección AA-Loan-Calculation del programa BBANK70P» . Este programa utiliza las capacidades existentes de segmentación y refactorización para crearlo y modificar el código original para su uso. Esto ayudaría a descomponer el código monolítico, facilitando su mantenimiento y simplificando su prueba, incluyendo la introducción de pruebas unitarias.

En cuanto a las pruebas unitarias, para facilitar la implementación de pruebas de "desplazamiento a la izquierda", la siguiente solicitud podría ser: Escribir una prueba unitaria para el programa BBANKCLP. Esto podría crear automáticamente todos los componentes del marco de pruebas unitarias, incluyendo (cuando sea necesario) los componentes de simulación/sustitución requeridos.

Yendo un paso más allá y considerando reducir los plazos de preparación de las pruebas, podríamos escribir la solicitud "Crear una instancia de prueba de Enterprise Server para ejecutar el programa BBANKCLP" . Esto proporcionaría una instancia de prueba con la configuración justa para la prueba, ya sea CICS o Batch.

El lenguaje COBOL no es uno de los principales desafíos que consideraríamos abordar. Sin embargo, proporcionar la función de completado o generación de código al código del subsistema dentro del programa COBOL sería ventajoso para los desarrolladores que se inician en MSS. Por ello, solicitudes como "Crear código que proporciona entrada y salida a la pantalla CICS MBANK10 " podrían generar comandos CICS SEND y RECEIVE. Solicitudes similares también podrían estar disponibles para acceder a archivos de datos, SQL y datos IMS. Esto también se aplicaría al código para llamar a otros programas en un contexto CICS o invocar un servicio web.

El último problema, la falta de conocimiento especializado de la aplicación, es donde la asistencia para la comprensión y documentación del código se vuelve esencial. Solicitudes como «Explique el párrafo AA-COMPLEX-CODE», «¿Cómo se utiliza el elemento de datos WS-UNCLEAR-FIELD-NAME?» o « ¿Cuál es el origen del elemento de datos WS-WHAT-SETS-THIS-FIELD?» serían de gran ayuda para su comprensión. Además, para facilitar el mantenimiento del programa al próximo desarrollador, sería beneficioso añadir estos comentarios al código .

Estas son solo algunas de las ideas que estamos explorando, basándonos en los temas que hemos tratado con nuestros clientes. Y habrá más por venir.

Para ayudarnos a garantizar que nuestra hoja de ruta futura tenga en cuenta sus necesidades, le rogamos que participe en nuestra encuesta.

Pruébalo

Si ya es cliente de Enterprise, COBOL Analyzer, Enterprise Developer o Visual COBOL, ya puede acceder a la versión 10.0. 

De lo contrario, póngase en contacto con su ejecutivo de cuenta o solicite una licencia de prueba en este enlace: https://www.rocketsoftware.com/products/enterprise-suite/request-contact

No dudes en ponerte en contacto directamente con Gary. Si tienen alguna pregunta o comentario, no duden en contactarme; estaré encantado de hablar sobre sus desafíos y nuestras soluciones.