Apresentando o Assistente de Análise de Linguagem Natural

Visão geral

Muitas organizações dependem de aplicações desenvolvidas ao longo de um extenso período e obtêm vantagem competitiva com base nelas. Essas aplicações sofrem mudanças significativas ao longo desse tempo, o que gera um grau crescente de complexidade. Em muitos casos, os desenvolvedores originais dessas aplicações não trabalham mais nessas organizações. Isso resulta em dificuldades para os novos desenvolvedores compreenderem a base de código e, consequentemente, manterem essas aplicações críticas de forma segura e eficiente.

O Enterprise e o COBOL Analyzer da Rocket Software possuem vasta experiência em fornecer aos desenvolvedores informações no momento da alteração de bases de código complexas, permitindo que desenvolvedores iniciantes realizem tarefas de manutenção. Muitas dessas funcionalidades de análise foram integradas aos ambientes de desenvolvimento integrados (IDEs) Eclipse^® e Visual Studio^® com o Rocket^® Enterprise Developer e o Visual COBOL. No entanto, o advento da Inteligência Artificial (IA) e das Interfaces de Linguagem Natural (ILN) trouxe uma nova perspectiva sobre como os desenvolvedores desejam interagir com suas ferramentas de desenvolvimento.

Na versão 10.0 do Enterprise Developer e do Visual COBOL, a Rocket Software introduziu o Assistente de Análise de Linguagem Natural. Esse recurso ajudará os desenvolvedores a compreenderem a aplicação completa em que estão trabalhando, utilizando ferramentas de desenvolvimento modernas e padronizadas, familiares tanto para desenvolvedores COBOL quanto para aqueles que não utilizam COBOL .

Os desenvolvedores poderão fazer alterações nos arquivos ou programas, com a segurança de que essas alterações não terão um impacto negativo no restante do aplicativo.

O Assistente de Análise oferece uma janela de bate-papo onde o desenvolvedor pode fazer perguntas em linguagem "humana" (por enquanto, apenas inglês) sobre seus aplicativos COBOL ou PL/I em relação a uma base de código armazenada em um repositório do Enterprise Analyzer ou do COBOL Analyzer .

Enquete

Para garantir que nosso planejamento futuro inclua seus comentários e considerações, participe da nossa pesquisa.

Nos bastidores

Então, como isso funciona?

Três componentes de uma visão geral arquitetônica de alto nível:

1. A IDE (Ambiente de Desenvolvimento Integrado)

Aqui o desenvolvedor faz uma pergunta na janela de bate-papo e os resultados são exibidos.

2. O Motor de Linguagem Natural

O mecanismo de linguagem natural faz todo o trabalho pesado. Ele recebe a pergunta em inglês do desenvolvedor, transforma-a em uma ou mais consultas EA, passa essas consultas para o EA e, em seguida, gera uma resposta em linguagem natural a partir do resultado, que é então enviada de volta para o IDE.

3. O servidor Remote Enterprise Analyzer

Todas as informações sobre a aplicação, que tem um enorme potencial, estão aqui.

O servidor EA executa a consulta recebida do mecanismo e retorna os resultados.

Mais sobre o mecanismo de linguagem natural

Agora vamos nos aprofundar um pouco mais no mecanismo de linguagem natural:

A funcionalidade foi desenvolvida usando o Apache OpenNLP, uma biblioteca de processamento de linguagem natural escrita em Java. Ela roda localmente e tem uma pegada bastante pequena, sem a necessidade de processadores avançados como GPU ou CUDA, que são típicos em IA. Vale ressaltar que o Natural Language Engine também não é baseado em um Modelo de Linguagem Amplo (LLM).

O motor inclui dois modelos que foram treinados previamente. Eles executam duas tarefas separadas e distintas.

1. Categorização

A fase de categorização é onde a consulta é classificada. Ela determina o que o usuário está realmente pedindo.

Por exemplo, o usuário está pedindo a contagem de algo no programa, o fluxo do programa ou referências?

2. Reconhecimento de Entidades Nomeadas (NER)

O modelo NER é usado para localizar pontos de interesse na string de consulta que podem se referir a nomes. Por exemplo, nomes de programas, nomes de seções ou nomes de parágrafos.

3. Processamento linguístico

Por fim, há um processamento linguístico adicional para obter contexto extra para a consulta. Isso pode incluir esclarecer as sutilezas linguísticas de "A liga para B?" ou "A é chamado por B?" e garantir que isso seja representado corretamente na consulta.

Após a coleta de todas as informações, várias consultas podem ser enviadas à EA.

Para uma demonstração do Assistente de Linguagem Natural, assista a este vídeo .

Linguagem Natural e Inteligência Artificial para desenvolvedores de aplicações de Subsistema Mainframe (MSS).

Hoje em dia, é difícil encontrar um artigo na imprensa de TI e nas redes sociais que não faça alguma referência à Inteligência Artificial, principalmente no que diz respeito ao auxílio aos desenvolvedores na escrita de código de aplicativos.

Tem havido uma crescente adoção de ferramentas desse tipo para linguagens como Java e C#, etc., no mundo do COBOL e do PLI. Mas as linguagens predominantes para aplicações MSS, IA ou Processamento de Linguagem Natural ainda não se tornaram comuns. Isso é especialmente verdadeiro para aplicações que interagem com os subsistemas de mainframe CICS, IMS e JES.

Muitos fornecedores que buscam trazer IA para esse cenário estão expandindo as soluções de refatoração automatizada existentes para incluir IA, o que resulta em uma reescrita e reestruturação completa da aplicação usando outras linguagens. Mas essa abordagem não possui um histórico comprovado. Embora possa auxiliar alguns desenvolvedores, não são necessariamente os desenvolvedores que mantiveram a aplicação originalmente.

Na Rocket Software, estamos analisando como a IA e o processamento de linguagem natural podem auxiliar os desenvolvedores de aplicativos MSS em seus desafios diários, sem o risco de converter a base de código para outra linguagem.

Então, quais são esses desafios do dia a dia?

• Programas monolíticos que são difíceis de manter e, principalmente, de testar.
• Falta de conhecimento prático por parte das PMEs
• Questões de habilidades relacionadas aos subsistemas do mainframe
• Falta de "deslocamento para a esquerda" e testes automatizados.
• Prazo de entrega extenso e custo elevado para o provisionamento de ambientes de teste.

É importante ressaltar que nenhum desses desafios está relacionado aos idiomas em que os aplicativos são escritos.

Já começamos a explorar os dois primeiros desafios da lista ao discutir o Assistente de Análise de Linguagem Natural anteriormente neste post. O investimento contínuo e a inovação nesta área ampliarão seu uso, aproveitando recursos adicionais já disponíveis no Enterprise e no COBOL Analyzer, mas tornando-os mais fáceis de usar.

Considerando a necessidade geral de refatorar código monolítico, imagine escrever na janela de bate-papo : "Crie um novo programa chamado BBANKLCP a partir da seção AA-Loan-Calculation do programa BBANK70P", que então utiliza os recursos de fatiamento e refatoração de código existentes para criar esse novo programa e modificar o código original para usá-lo. Isso ajudaria a dividir o monolito, facilitando a manutenção e tornando o código mais fácil de testar, inclusive simplificando a introdução de testes unitários.

Com relação aos testes unitários, para ajudar a introduzir o conceito de "shift left" (deslocamento para a esquerda), a próxima solicitação poderia ser: "Escreva um teste unitário para o programa BBANKCLP". Isso poderia criar automaticamente todos os componentes da estrutura de testes unitários, incluindo (quando necessário) quaisquer componentes de simulação/estupramento necessários.

Indo um passo além e considerando a redução do tempo de preparação dos testes, poderíamos escrever uma solicitação do tipo "Criar uma instância de teste do Enterprise Server para executar o programa BBANKCLP" . Isso provisionaria uma instância de teste com a configuração necessária para suportar o teste, seja ele CICS ou Batch.

A linguagem COBOL não é um dos principais desafios que consideraríamos abordar. No entanto, fornecer autocompletar ou gerar código para subsistemas dentro do programa COBOL seria vantajoso para desenvolvedores iniciantes no trabalho com MSS. É por isso que solicitações como "Criar código que fornece entrada e saída para a tela CICS MBANK10" poderiam gerar comandos CICS SEND e RECEIVE. Solicitações semelhantes também poderiam estar disponíveis para acesso a arquivos de dados, SQL e dados IMS. Isso se aplicaria igualmente a códigos para chamar outros programas em um contexto CICS ou invocar um serviço web.

A questão final, a falta de conhecimento especializado da aplicação, é onde a assistência para a compreensão do código e a documentação se torna essencial. Solicitações como "Explique o parágrafo AA-COMPLEX-CODE", "Como o item de dados WS-UNCLEAR-FIELD-NAME está sendo usado?" ou "Qual é a origem do item de dados WS-WHAT-SETS-THIS-FIELD?" ajudariam nesse entendimento. E para auxiliar ainda mais o próximo desenvolvedor na manutenção deste programa, uma solicitação para "Adicionar esses comentários ao código" também seria benéfica.

Essas são apenas algumas das ideias que estamos explorando, com base nos problemas que discutimos com nossos clientes. E há muito mais por vir.

Para nos ajudar a garantir que o nosso planeamento futuro tenha em conta as suas necessidades, participe no nosso inquérito.

Experimente!

Se você já é cliente do Enterprise, COBOL Analyzer, Enterprise Developer ou Visual COBOL, já pode acessar a versão 10.0. 

Caso contrário, entre em contato com seu Executivo de Contas ou solicite uma licença de avaliação neste link: https://www.rocketsoftware.com/products/enterprise-suite/request-contact

Sinta-se à vontade para entrar em contato diretamente com Gary. Se tiver alguma dúvida ou comentário, fique à vontade para entrar em contato. Terei prazer em discutir seus desafios e nossas soluções.