CodeLiberator

O CodeLiberator (TM) é o bloco mais inteligente da nossa estrutura de modernização dos legados para converter aplicativos legados completos, incluindo lógica de negócios, interface do usuário (UI) e camadas de acesso a dados. Essa ferramenta usa metadados criados pelo KnowledgeLiberator (TM) para transformar a lógica de negócios desenvolvida em linguagens de programação de 3ª e 4ª geração em aplicativos completamente novos usando a pilha de tecnologia Java.

Principais características do CodeLiberator:

• converter lógica de negócios de uma linguagem de programação para outra, por exemplo, COBOL para Java, Natural para Java, PL/I para Java, PL/I para COBOL, etc.
• converter o processamento de transações online: converter vários interfaces de usuário legadas como 3270 CICS/BMS, IMS-DC, terminais Unix para soluções thin client JSF, HTML/JavaScript (programação reativa) com JSON etc.
• converter o acesso a dados incorporados em aplicativos legados para executar a mesma lógica em bancos de dados migrados, preservando toda a lógica de acesso aos dados (recuperação de dados, lógica de manipulação) em RDBMS, NoSQL ou arquivos.

Conversão de linguagem…é mesmo fácil?

Há quem diga: a conversão de linguagens é fácil. Claro, criar equivalentes de definição de dados, instruções específicas de linguagem, fluxo de programa, etc. Até mesmo a criação de código orientado a objetos com classes base e herança é conceitualmente acessível. O diabo está nos detalhes: executar o código e criar exatamente a mesma saída para as mesmas entradas provavelmente pode ser considerado um critério de sucesso, mas a manutenção e o desempenho também devem ser considerados ao mesmo tempo. Por exemplo, uma string COBOL ou Natural não deve simplesmente ser convertida em uma string Java porque o comportamento inato das strings nos dois domínios de linguagem é diferente. Claro que se ainda insistirmos no mesmo comportamento – e normalmente este é o caso – então haverá codificação adicional em Java necessária, o que certamente afetaria a manutenção de forma negativa e aplicaria técnicas WET contra DRY. Vários sabores e versões de uma linguagem legada têm diferenças em sua implementação que devemos considerar.

Não podemos nos esquecer que geralmente convertemos códigos ‘ao vivo’ que fazem parte do dia a dia dos negócios e são desenvolvidos ativamente. Após a conversão, esse código deve estar em uma forma em que os desenvolvedores possam modifica-lo, desenvolve-lo, refatora-lo e fazer todo o que os desenvolvedores geralmente fazem com o código.

Ao converter para Java, o resultado pode ser mais parecido com o legado ou mais parecido com o Java. Existem muitos parâmetros de conversão que influenciam a satisfação de um desenvolvedor de legado quando olhar para o código Java, em oposição à satisfação de um desenvolvedor de Java ao procurar construções comuns e elementos de linguagem de Java no código novo.

Interfaces do usuário (UIs)

No mundo aberto moderno, não há tantas abordagens diferentes de alto nível para gerar interfaces de usuário (UIs). As interfaces da Web são as espécies predominantes – elas existem em várias implementações diferentes de html/javascript simples (com ou sem frameworks simples, por exemplo, jQuery) ou frameworks de aplicativos de nível superior, por exemplo, Angular, React e similares.

O nosso CodeLiberator captura as definições de tela e as transforma em um conjunto de descritores. Esses descritores são alimentados então em um “player” leve em um navegador da Web que cria o visual e a essência (‘the look and feel’) das telas originais. Esta parte do projeto, até esse ponto, é extremamente fácil do empreendimento.

O desafio está em recriar o comportamento original com movimentos de foco, manipulação de eventos, manipulação de dados, comunicação com o servidor, manipulação de erros, validação de dados, etc.

Nossa solução vem com um editor de tela que permite que os desenvolvedores trabalhem em uníssono com o código convertido assim que as alterações precisarem ser feitas.

Camada de acesso aos dados

Adicionamos uma camada entre o aplicativo convertido e o novo mecanismo de banco de dados selecionado para fornecer exatamente a mesma funcionalidade. Essa abordagem possibilita que, durante a conversão do aplicativo, a lógica do aplicativo não precise ser alterada, a funcionalidade e os algoritmos funcionem ‘as-is’. Usando essa abordagem, nossos clientes não precisam adicionar complexidade desnecessária à primeira etapa da migração, a refatoração não é necessária. Mude para o mundo aberto rapidamente (replataforma) e, quando o mainframe for deixado para trás, planeje o próximo movimento: refatorar, rearquitetar.

Essa camada adicionada torna possível abstrair o mecanismo de banco de dados e aproveitar a liberdade de escolher entre mecanismos de banco de dados SQL ou NoSQL.