Translate

Mostrar mensagens com a etiqueta No-Code. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta No-Code. Mostrar todas as mensagens

segunda-feira, 4 de maio de 2026

No-Code : O Que Todo Programador COBOL Precisa Saber Sobre a Revolução do Desenvolvimento Sem Programação

 

Bellacosa Mainframe e o no-code na stack mainframe

☕ Um Café no Bellacosa Mainframe

No-Code

O Que Todo Programador COBOL Precisa Saber Sobre a Revolução do Desenvolvimento Sem Programação

Você Não Está Sendo Substituído. Está Descobrindo Outra Forma de Construir Software.

"Toda década promete eliminar os programadores. Primeiro vieram os geradores de código. Depois os CASE Tools. Em seguida o RAD. Agora é o No-Code. Curiosamente, todas essas tecnologias continuam precisando de bons engenheiros de software."


Introdução

Quem trabalha com IBM Mainframe já ouviu inúmeras previsões durante a carreira.

"COBOL vai acabar."

"O Mainframe será substituído."

"Agora qualquer pessoa poderá criar sistemas."

Quase cinquenta anos depois dessas previsões, os maiores bancos do planeta continuam processando bilhões de transações em COBOL.

Agora surgiu uma nova promessa.

No-Code.

Segundo muitos anúncios de marketing, basta arrastar alguns blocos na tela e qualquer pessoa cria aplicações empresariais.

Será?

Como quase tudo na engenharia de software, a resposta é mais interessante do que parece.

Para um desenvolvedor COBOL, entender No-Code não significa abandonar décadas de conhecimento.

Significa compreender onde essa tecnologia realmente faz sentido.


O que é No-Code?

No-Code é uma abordagem de desenvolvimento onde aplicações são criadas utilizando componentes gráficos, configurações e regras visuais, praticamente sem escrever código tradicional.

Em vez de escrever:

IF SALDO > LIMITE
    MOVE "NEGADO" TO STATUS
END-IF

o desenvolvedor conecta dois blocos:

Saldo >
        \
         > Decisão
        /
Limite >

e define:

Sim → Negar operação

Não → Aprovar

A lógica continua existindo.

A diferença é apenas a forma de representá-la.


O princípio do No-Code

Todo software possui quatro elementos fundamentais:

  • Interface

  • Regras

  • Dados

  • Integrações

No-Code tenta transformar todos esses elementos em componentes reutilizáveis.

Em vez de programar:

Tela
↓

Código

↓

Banco

↓

API

o desenvolvedor monta:

Tela
↓

Blocos

↓

Fluxos

↓

Publicar

A origem do No-Code

Na realidade, No-Code não é novidade.

Ele apenas ganhou um novo nome.

Sua história começa muito antes da Internet.

Década de 1970

Mainframes já possuíam ferramentas declarativas.

CICS BMS

IMS MFS

ISPF Panels

Mapas de tela.

Você descrevia uma tela.

O sistema gerava a interface.

Isso já era uma forma de desenvolvimento declarativo.


Década de 1980

Surgiram os famosos CASE Tools.

Entre eles:

  • Texas Instruments IEF

  • AD/Cycle

  • COOL:Gen

  • Excelerator

  • CA Gen

Essas ferramentas prometiam:

"Desenhe o sistema."

"O software será gerado automaticamente."

Muito parecido com o discurso atual.


Década de 1990

Vieram:

  • Delphi

  • Visual Basic

  • PowerBuilder

  • Oracle Forms

Os componentes eram arrastados para formulários.

Pouco código.

Muito RAD (Rapid Application Development).


Década de 2000

Aplicações Web.

Frameworks.

CMS.

WordPress.

Joomla.

Drupal.

Muitos sites passaram a ser construídos sem programação.


Década de 2010

Cloud.

SaaS.

APIs REST.

Microserviços.

As plataformas começaram a conectar tudo.


Década de 2020

Explosão do verdadeiro No-Code.

Agora existem plataformas completas.

Aplicativos.

Workflows.

IA.

Bots.

Dashboards.

Integrações.

Tudo criado visualmente.


A diferença entre No-Code e Low-Code

Muita gente confunde.

No-Code

Destinado principalmente para usuários de negócio.

Exemplo:

Criar formulário

↓

Criar fluxo

↓

Publicar

Sem programação.


Low-Code

Destinado a desenvolvedores.

Permite código quando necessário.

Exemplo:

Fluxo visual

↓

Componente personalizado

↓

API

↓

Script

↓

Deploy

É muito mais poderoso.


Por que o No-Code cresceu tanto?

Porque o mercado possui um problema enorme.

Faltam desenvolvedores.

Empresas precisam entregar software rapidamente.

Nem toda aplicação exige uma equipe de engenharia.

Imagine criar:

  • formulário interno

  • cadastro

  • workflow de aprovação

  • pesquisa de satisfação

  • controle de férias

Não faz sentido desenvolver tudo em Java.

Nem em COBOL.

Nem em C#.

Uma ferramenta No-Code resolve em poucas horas.


Como funciona internamente?

Esse é um ponto importante.

No-Code não elimina programação.

Ele apenas esconde a programação.

Quando você cria:

Botão

↓

Enviar Email

a plataforma gera algo semelhante a:

HTML

CSS

JavaScript

API

Banco

Autenticação

Logs

Infraestrutura

Ou seja...

Alguém escreveu milhares de linhas de código para que você não precise escrevê-las.


As principais características

Uma plataforma No-Code normalmente possui:

Editor visual

Banco de dados

Autenticação

Controle de usuários

Integração com APIs

Dashboards

Automações

Relatórios

Workflow

Notificações

Segurança

Deploy automático


Principais metodologias

Embora cada fabricante possua sua implementação, quase todas seguem os mesmos conceitos.

Model Driven Development

Primeiro modela.

Depois gera.


Visual Programming

Fluxogramas.

Conexões.

Eventos.


Event Driven

Quando algo acontece...

Executa outra ação.

Cliente cadastrado

↓

Enviar Email

↓

Criar Pedido

↓

Registrar Log

↓

Atualizar CRM

Workflow Automation

Automação baseada em processos.

Muito utilizada em empresas.


Business Process Management (BPM)

Fluxos corporativos.

Aprovações.

Assinaturas.

Validações.

Integrações.


Domain Driven Modeling

A aplicação representa o negócio.

Não a tecnologia.


Vantagens

Desenvolvimento extremamente rápido

Horas.

Não meses.


Menor custo inicial

Poucos desenvolvedores.


Interface pronta

Layouts modernos.


Integração simples

Microsoft

Google

SAP

Salesforce

IBM

Oracle

Tudo via conectores.


Facilidade para prototipação

Ideal para MVP.


Atualizações automáticas

O fornecedor cuida da infraestrutura.


Baixa curva de aprendizado

Analistas conseguem construir aplicações simples.


Desvantagens

Agora vem a parte que o marketing raramente comenta.


Dependência do fornecedor

Seu sistema passa a depender totalmente da plataforma.


Vendor Lock-in

Trocar de ferramenta pode significar reconstruir tudo.


Limitações

Quando surge uma necessidade muito específica...

A plataforma pode simplesmente não permitir.


Performance

Nem sempre é ideal.

Algumas plataformas geram muito código desnecessário.


Escalabilidade

Funciona bem para centenas.

Nem sempre para milhões de usuários.


Licenciamento

Pode ficar caro.

Muito caro.

Especialmente conforme o número de usuários cresce.


Performance

Aqui existe um mito.

"No-Code é lento."

Nem sempre.

Depende da arquitetura.

Uma boa plataforma pode gerar aplicações excelentes.

Outra pode gerar aplicações enormes.

Tudo depende da qualidade do motor interno.


Segurança

Outro ponto crítico.

Toda plataforma precisa oferecer:

Autenticação

Criptografia

Auditoria

Controle de acesso

LGPD

Logs

Versionamento

Backup

Governança

Sem isso, ela dificilmente será aceita em ambientes corporativos.


Como desenvolver uma aplicação No-Code

Vamos imaginar um pequeno sistema de solicitação de férias.

Passo 1

Definir o processo.

Funcionário

↓

Solicita férias

↓

Gestor aprova

↓

RH confirma

↓

Sistema encerra

Passo 2

Criar entidades.

Funcionário

Departamento

Solicitação

Período

Gestor


Passo 3

Criar formulários.

Cadastro.

Consulta.

Aprovação.


Passo 4

Criar regras.

Se gestor aprovar...

Enviar ao RH.

Caso contrário...

Rejeitar.


Passo 5

Criar notificações.

Email.

Teams.

Slack.

WhatsApp.


Passo 6

Criar dashboards.

Solicitações abertas.

Pendentes.

Concluídas.

Tempo médio.


Passo 7

Publicar.

Sem compilação tradicional.


Boas práticas

Sempre modelar o processo primeiro.

Evitar criar fluxos gigantes.

Documentar regras.

Versionar alterações.

Controlar permissões.

Criar ambientes separados.

Testar integrações.

Monitorar desempenho.

Ter plano de contingência.


Os principais riscos

Criar aplicações sem arquitetura.

Duplicar regras.

Ausência de documentação.

Dependência da plataforma.

Integrações mal definidas.

Falta de testes.

Crescimento descontrolado.

Shadow IT.


Oportunidades para o programador COBOL

Aqui está o ponto mais importante deste artigo.

No-Code não compete com COBOL.

Ele complementa.

Imagine este cenário.

Cliente

↓

Portal Web

↓

Power Apps

↓

Power Automate

↓

API REST

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

DB2

Quem executa a lógica crítica?

COBOL.

Quem apenas apresenta uma interface bonita?

No-Code.


O papel do Mainframe

O Mainframe continua sendo responsável por:

Transações financeiras.

Processamento batch.

Contabilidade.

Pagamentos.

Cartões.

PIX.

Previdência.

Folha.

Seguros.

Toda essa lógica permanece exatamente onde sempre esteve.


O papel do No-Code

Construir rapidamente:

Painéis administrativos.

Dashboards.

Consultas.

Workflows.

Aprovações.

Aplicativos internos.

Portais.


A integração perfeita

Hoje, uma arquitetura moderna costuma ser assim:

Usuário
      │
      ▼
Power Apps / Mendix / OutSystems
      │
      ▼
REST API
      │
      ▼
IBM z/OS Connect
      │
      ▼
CICS
      │
      ▼
Programa COBOL
      │
      ▼
DB2 / VSAM / IMS

Perceba que o COBOL não desaparece.

Ele ganha uma nova camada de apresentação.


Principais plataformas No-Code

Entre as mais conhecidas estão:

  • Microsoft Power Apps

  • Microsoft Power Automate

  • Mendix (Siemens)

  • OutSystems

  • AppSheet (Google)

  • Bubble

  • Glide

  • Zoho Creator

  • Airtable

  • Retool

  • ServiceNow App Engine

  • Salesforce Lightning Platform

  • Oracle APEX (frequentemente classificado como Low-Code)

  • IBM watsonx Orchestrate (automação e IA)

  • IBM Business Automation Workflow

Cada uma possui foco diferente: aplicativos corporativos, automação de processos, portais, integração ou desenvolvimento empresarial.


Onde o No-Code NÃO funciona bem?

Há cenários em que o desenvolvimento tradicional continua sendo a melhor escolha:

  • Sistemas bancários de alta criticidade.

  • Motores de processamento em tempo real.

  • Aplicações com requisitos extremos de desempenho.

  • Sistemas embarcados.

  • Softwares que exigem controle detalhado de memória ou hardware.

  • Algoritmos científicos complexos.

  • Grandes motores de processamento batch.

Nesses casos, linguagens como COBOL, Java, C/C++, PL/I ou Assembler continuam sendo mais adequadas.


O futuro do No-Code

A próxima evolução já começou.

Ela combina:

  • No-Code

  • Low-Code

  • Inteligência Artificial Generativa

  • Agentes de IA

  • Automação inteligente

  • APIs

  • RPA

  • Event-Driven Architecture

Em vez de apenas montar telas, o desenvolvedor descreve um processo em linguagem natural, e a plataforma gera boa parte da aplicação. Ainda assim, alguém precisa revisar arquitetura, segurança, integração, testes e governança.


O impacto no ambiente Mainframe

Para o profissional de IBM Z, o maior impacto não é técnico, mas estratégico.

As equipes de negócio querem entregar soluções mais rápido. O Mainframe continua sendo o sistema de registro (System of Record), enquanto plataformas No-Code aceleram a criação de experiências digitais.

Isso aumenta a importância de tecnologias como:

  • IBM z/OS Connect

  • APIs REST

  • OpenAPI

  • IBM MQ

  • Kafka

  • CICS Web Services

  • Db2 Services

  • OAuth e OpenID Connect

  • Arquiteturas orientadas a eventos

O programador COBOL deixa de ser apenas um desenvolvedor de programas batch e online para atuar como um engenheiro de serviços corporativos.


O Novo Perfil do Programador COBOL

O profissional mais valorizado nos próximos anos provavelmente será aquele que combina:

  • COBOL moderno

  • CICS

  • Db2

  • JCL

  • APIs REST

  • JSON

  • Git

  • DevOps

  • Segurança

  • Integração com plataformas Low-Code e No-Code

  • Arquitetura de sistemas

Ele não precisará construir cada tela manualmente. Em vez disso, projetará serviços confiáveis, escaláveis e seguros que poderão ser consumidos por aplicativos web, mobile, IA e plataformas No-Code.


Conclusão

No-Code não representa o fim da programação.

Representa uma mudança de foco.

Assim como os compiladores não eliminaram os programadores Assembly, e as linguagens de alto nível não eliminaram a engenharia de software, as plataformas No-Code não eliminam a necessidade de profissionais experientes.

Elas reduzem o esforço em tarefas repetitivas e aceleram a construção de aplicações simples, mas continuam dependentes de boas decisões de arquitetura, integração, segurança e governança.

No universo IBM Mainframe, essa realidade é ainda mais evidente. O COBOL permanece executando a lógica de negócios que movimenta bancos, seguradoras, governos e grandes empresas. O No-Code entra como uma camada de produtividade e experiência do usuário, consumindo serviços expostos pelo Mainframe por meio de APIs.

O futuro não será uma disputa entre COBOL e No-Code.

Será uma colaboração entre ambos.

O desenvolvedor que compreender essa integração deixará de enxergar o No-Code como ameaça e passará a utilizá-lo como mais uma ferramenta para entregar valor ao negócio.

Porque, no fim das contas, software nunca foi apenas escrever código.

Sempre foi resolver problemas. E essa continua sendo a missão de qualquer engenheiro de software — seja escrevendo milhares de linhas em COBOL, seja conectando componentes visuais que, por trás da interface, ainda dependem da mesma disciplina, do mesmo raciocínio lógico e da mesma engenharia que sustentam os sistemas mais importantes do mundo há décadas.

sexta-feira, 30 de maio de 2025

CASE Tools - Muito Além da Geração de Código: A Tecnologia que Mudou a Engenharia de Software para Sempre

 

Bellacosa Mainframe e os primeiros passos em Case Tools

☕ Um Café no Bellacosa Mainframe

CASE Tools

Muito Além da Geração de Código: A Tecnologia que Mudou a Engenharia de Software para Sempre

"As CASE Tools nunca tiveram como objetivo substituir programadores. Elas nasceram para transformar programação em Engenharia de Software. Quarenta anos depois, continuam influenciando praticamente todas as ferramentas modernas, da UML à Inteligência Artificial."


Introdução

Quando alguém fala em CASE Tools, é comum ouvir a resposta:

"Isso é tecnologia antiga."

Na realidade, poucas afirmações estão tão distantes da verdade.

As CASE Tools podem até não aparecer mais nas manchetes, mas seus conceitos continuam presentes em praticamente todas as plataformas modernas de desenvolvimento.

Se você utiliza:

  • UML;

  • Enterprise Architect;

  • IBM Application Discovery;

  • IBM Developer for z/OS;

  • GitHub Copilot;

  • IBM watsonx Code Assistant;

  • Low-Code;

  • No-Code;

  • DevOps;

  • Model Driven Engineering;

você está, direta ou indiretamente, utilizando ideias que nasceram há mais de quatro décadas.

Para quem trabalha com IBM Mainframe, compreender CASE Tools significa entender a origem da engenharia que permitiu a bancos, seguradoras e governos manterem sistemas críticos funcionando por décadas.


Afinal, o que são CASE Tools?

CASE significa:

Computer-Aided Software Engineering

ou

Engenharia de Software Assistida por Computador.

O objetivo nunca foi substituir programadores.

O objetivo sempre foi automatizar tarefas repetitivas da Engenharia de Software.

Em vez de começar escrevendo código, a ideia era começar criando modelos.

A partir desses modelos, as ferramentas poderiam gerar:

  • programas COBOL;

  • tabelas DB2;

  • layouts VSAM;

  • telas CICS;

  • documentação;

  • diagramas;

  • dicionários de dados;

  • especificações técnicas.

O código passava a ser consequência do projeto, não seu ponto de partida.


Por que elas surgiram?

Durante as décadas de 1970 e 1980 a indústria enfrentou a chamada Crise do Software.

Os computadores evoluíam rapidamente, mas os sistemas tornavam-se cada vez maiores e mais difíceis de manter.

Projetos atrasavam.

Custos aumentavam.

A documentação ficava desatualizada.

Mudanças simples provocavam erros inesperados.

As CASE Tools surgiram para trazer disciplina, padronização, rastreabilidade e reutilização ao desenvolvimento de software.


O grande diferencial

A maior inovação das CASE Tools não foi a geração automática de código.

Foi a criação de um repositório de conhecimento.

Nele eram armazenados:

  • processos;

  • entidades;

  • regras de negócio;

  • relacionamentos;

  • programas;

  • tabelas;

  • dependências;

  • documentação.

Hoje chamamos isso de metadados.

Na época, era uma revolução.


O papel no IBM Mainframe

Foi no Mainframe que as CASE Tools demonstraram todo o seu potencial.

Imagine uma instituição financeira com:

  • milhões de clientes;

  • milhares de transações CICS;

  • centenas de bancos DB2;

  • milhares de arquivos VSAM;

  • milhões de linhas de COBOL.

Sem uma visão integrada, compreender o impacto de uma simples alteração seria praticamente impossível.

As CASE Tools permitiram analisar dependências, gerar documentação, identificar impactos e padronizar o desenvolvimento, tornando viável a evolução contínua desses sistemas.


Elas desapareceram?

Não.

Mudaram de nome.

Os princípios continuam presentes em tecnologias modernas como:

  • UML;

  • Model Driven Development (MDD);

  • Model Driven Engineering (MDE);

  • Domain-Driven Design (DDD);

  • Low-Code;

  • No-Code;

  • DevOps;

  • Infrastructure as Code;

  • Inteligência Artificial aplicada ao desenvolvimento.

A engenharia baseada em modelos continua mais viva do que nunca.


O que isso significa para o programador COBOL?

Significa que escrever código já não é suficiente.

O profissional moderno precisa compreender:

  • arquitetura;

  • modelagem;

  • regras de negócio;

  • engenharia reversa;

  • análise de impacto;

  • documentação automática;

  • integração entre sistemas;

  • automação.

Quem domina esses conceitos consegue evoluir sistemas complexos com muito mais segurança.


Esta série completa

Para explorar esse universo em profundidade, preparamos uma série especial dividida em quatro artigos.

📘 Parte 1 — A origem das CASE Tools

Conheça a história da Crise do Software, o nascimento da Engenharia de Software, os primeiros CASE Tools e como surgiu a ideia de modelar sistemas antes de escrever código.

Você entenderá por que essa tecnologia foi considerada revolucionária e como ela mudou a forma de construir aplicações corporativas.

https://eljefemidnightlunch.blogspot.com/2025/01/case-tools-tecnologia-que-tentou.html


📗 Parte 2 — Upper CASE, Lower CASE e Integrated CASE

Descubra como funcionavam as diferentes categorias de CASE Tools.

Entenda conceitos como:

  • Upper CASE;

  • Lower CASE;

  • I-CASE;

  • Forward Engineering;

  • Reverse Engineering;

  • Round Trip Engineering;

  • Repositórios;

  • Dicionários de Dados;

  • Metodologias clássicas de Engenharia de Software.

É a base conceitual que influenciou praticamente todas as ferramentas modernas.

https://eljefemidnightlunch.blogspot.com/2025/02/case-tools-upper-case-lower-case-i-case.html


📙 Parte 3 — CASE Tools no IBM Mainframe

Veja como bancos, seguradoras e órgãos governamentais utilizaram CASE Tools para administrar enormes ambientes COBOL.

Conheça a relação dessas ferramentas com:

  • COBOL;

  • CICS;

  • DB2;

  • IMS;

  • VSAM;

  • JCL;

  • IBM Application Discovery (ADDI);

  • IBM Developer for z/OS;

  • CA Gen;

  • Enterprise Architect;

  • PowerDesigner.

Uma leitura indispensável para quem trabalha com IBM Z.

https://eljefemidnightlunch.blogspot.com/2025/03/case-tools-case-tools-no-ibm-mainframe.html


📕 Parte 4 — Das CASE Tools à Inteligência Artificial

Entenda por que Low-Code, No-Code, MDD, MDE, DDD, DevOps e Inteligência Artificial representam uma evolução natural dos princípios introduzidos pelas CASE Tools.

Descubra como ferramentas como o IBM watsonx Code Assistant e assistentes baseados em IA continuam seguindo a mesma filosofia: automatizar tarefas repetitivas para que os engenheiros concentrem seus esforços na solução dos problemas de negócio.

https://eljefemidnightlunch.blogspot.com/2025/04/case-tools-das-case-tools-inteligencia.html


O maior legado das CASE Tools

Talvez a maior contribuição das CASE Tools tenha sido mudar a forma como enxergamos o desenvolvimento de software.

Elas mostraram que sistemas complexos não sobrevivem por décadas apenas porque utilizam uma boa linguagem de programação.

Eles sobrevivem porque foram construídos sobre princípios sólidos de engenharia.

Modelagem.

Padronização.

Rastreabilidade.

Reutilização.

Documentação.

Governança.

Esses conceitos permanecem essenciais, independentemente da linguagem, da plataforma ou da tecnologia utilizada.


Conclusão

A história das CASE Tools é, na verdade, a história da própria Engenharia de Software moderna.

O nome pode ter desaparecido das apresentações comerciais, mas suas ideias continuam presentes em praticamente todas as tecnologias atuais.

Quando utilizamos UML, geramos APIs automaticamente, criamos pipelines DevOps, fazemos engenharia reversa de aplicações COBOL ou pedimos que uma Inteligência Artificial produza código, estamos ampliando um conceito que nasceu há mais de quarenta anos.

Para o profissional de IBM Mainframe, conhecer CASE Tools não significa estudar uma tecnologia do passado.

Significa compreender por que os sistemas que movimentam bancos, seguradoras, bolsas de valores e governos continuam evoluindo com segurança após décadas de operação.

A tecnologia muda.

As ferramentas mudam.

As linguagens mudam.

Mas a Engenharia de Software continua sendo o verdadeiro diferencial.

"Quem aprende apenas uma linguagem de programação constrói aplicações. Quem compreende Engenharia de Software constrói sistemas capazes de atravessar gerações. Esse sempre foi o legado das CASE Tools."

 

segunda-feira, 28 de abril de 2025

CASE Tools Das CASE Tools à Inteligência Artificial – Parte IV

 

Bellacosa Mainframe apresenta o case tools parte iv

☕ Um Café no Bellacosa Mainframe

CASE Tools – Parte 4

Das CASE Tools à Inteligência Artificial

Como Low-Code, No-Code, Model Driven Engineering e IA São Apenas a Próxima Evolução da Mesma Ideia

"Toda geração acredita ter inventado uma nova forma de desenvolver software. A história mostra algo diferente: as ferramentas mudam, mas a engenharia continua sendo o verdadeiro diferencial."


Introdução

Chegamos ao último capítulo desta série sobre CASE Tools.

Ao longo dos artigos anteriores vimos como nasceu a Engenharia de Software moderna, conhecemos Upper CASE, Lower CASE e Integrated CASE e entendemos por que bancos, seguradoras e governos adotaram essas ferramentas para construir alguns dos sistemas mais confiáveis do mundo.

Mas uma pergunta permanece.

Se as CASE Tools eram tão revolucionárias, por que praticamente ninguém fala delas hoje?

A resposta é simples.

Elas nunca desapareceram.

Apenas mudaram de nome.

As ideias que surgiram nos anos 80 continuam presentes em praticamente todas as tecnologias modernas de desenvolvimento de software.

Quando alguém utiliza uma plataforma Low-Code, desenha um diagrama UML, cria um pipeline DevOps, gera uma API automaticamente ou pede para uma Inteligência Artificial escrever código, está utilizando conceitos que nasceram com as CASE Tools.

A tecnologia mudou.

Os princípios continuam exatamente os mesmos.


O fim das CASE Tools?

Durante a década de 1990 muitas empresas começaram a afirmar que as CASE Tools haviam fracassado.

Em parte isso era verdade.

Diversos produtos desapareceram.

Outros foram comprados.

Alguns mudaram completamente de estratégia.

Mas o motivo não foi a inutilidade da tecnologia.

Foi sua complexidade.


Imagine uma ferramenta que exigia:

  • meses de treinamento;

  • especialistas dedicados;

  • servidores caros;

  • processos extremamente rígidos;

  • equipes enormes de analistas.

Esse modelo funcionava muito bem para um banco com cinco mil desenvolvedores.

Mas não para uma empresa com vinte programadores.

Enquanto isso, o mercado começava a exigir velocidade.

Nasciam a Internet comercial, o desenvolvimento Web e novos modelos de negócio.

O software precisava evoluir em semanas, não em anos.


A chegada da Orientação a Objetos

Na mesma época surgia outro movimento importante.

A Orientação a Objetos.

Ferramentas como:

  • Rational Rose

  • Together

  • Select Enterprise

  • Enterprise Architect

passaram a utilizar UML.

Os enormes diagramas estruturados das CASE Tools começaram a dar lugar aos diagramas orientados a objetos.

Mas observe.

Ainda eram modelos.

Ainda existia documentação.

Ainda existia engenharia.

Mudou apenas a linguagem utilizada para representar os sistemas.


UML: uma CASE Tool disfarçada

Muita gente acredita que UML substituiu CASE.

Na realidade, UML tornou-se uma evolução natural.

Observe.

Antes.

DFD

↓

Modelo

↓

Código

Depois.

UML

↓

Modelo

↓

Código

O conceito permaneceu.

Modelar primeiro.

Implementar depois.


Model Driven Development (MDD)

No final dos anos 90 surgiu um conceito extremamente interessante.

Model Driven Development.

Ou simplesmente

MDD.

A ideia era simples.

O modelo deixa de ser apenas documentação.

Ele passa a ser o elemento principal do projeto.

O código torna-se um produto derivado.

Veja.

Modelo

↓

Transformação

↓

Código

↓

Sistema

Não parece familiar?

É exatamente a filosofia das CASE Tools.


Model Driven Engineering (MDE)

Depois surgiu um conceito ainda mais amplo.

Model Driven Engineering.

Agora não apenas o software.

Toda a engenharia passa a girar em torno dos modelos.

Os modelos passam a representar:

  • processos;

  • infraestrutura;

  • segurança;

  • bancos de dados;

  • APIs;

  • microsserviços;

  • eventos;

  • integrações.

Hoje diversas empresas trabalham exatamente assim.


Domain Driven Design (DDD)

Outro conceito importante.

Eric Evans publicou em 2003 o livro Domain-Driven Design.

Muitos acreditam que ele não possui relação com CASE.

Na realidade possui várias.

O DDD afirma que o mais importante não é o código.

É compreender profundamente o negócio.

Era exatamente isso que os analistas das CASE Tools já defendiam décadas antes.


Low-Code

Agora chegamos a uma tecnologia bastante conhecida.

Low-Code.

O nome sugere:

Pouco código.

Mas não significa ausência de programação.

Significa automatizar tarefas repetitivas.

Imagine construir um cadastro.

Em vez de escrever centenas de linhas.

Você desenha.

A ferramenta gera:

  • telas;

  • banco;

  • APIs;

  • validações;

  • documentação.

Parece familiar?

Sim.

É exatamente o que uma CASE Tool fazia.


No-Code

O No-Code leva essa ideia ainda mais longe.

O usuário de negócio pode criar aplicações utilizando componentes visuais.

Fluxos.

Formulários.

Integrações.

Regras.

Tudo configurado visualmente.

O código existe.

Mas fica escondido.

Mais uma vez.

A filosofia continua a mesma.


BPM

Outra evolução importante.

Business Process Management.

Ferramentas como:

  • IBM BPM

  • Camunda

  • Bizagi

  • Appian

permitem desenhar processos.

Depois executá-los automaticamente.

Observe.

Primeiro o modelo.

Depois a execução.

Mais uma herança das CASE Tools.


APIs e OpenAPI

Hoje criamos APIs utilizando especificações.

Por exemplo.

Cliente

↓

GET

↓

POST

↓

PUT

A partir dessa especificação diversas ferramentas geram:

  • documentação;

  • SDKs;

  • código;

  • testes.

É exatamente o conceito de geração automática.


DevOps

Existe uma dúvida muito comum.

DevOps substituiu CASE?

Não.

CASE responde:

Como construir?

DevOps responde:

Como entregar?

Observe.

CASE

↓

Código

↓

Git

↓

Pipeline

↓

Deploy

↓

Produção

São tecnologias complementares.


Infrastructure as Code

Outro exemplo.

Hoje descrevemos servidores usando arquivos.

Terraform.

Ansible.

CloudFormation.

Depois.

Tudo é criado automaticamente.

Em vez de desenhar programas.

Agora modelamos infraestrutura.

É engenharia dirigida por modelos novamente.


Kubernetes

Mesmo Kubernetes utiliza essa filosofia.

Descrevemos um ambiente.

O orquestrador cria tudo.

Deployment

↓

Pods

↓

Services

↓

Volumes

Primeiro descrevemos.

Depois a plataforma constrói.


GitHub Copilot

Agora chegamos ao assunto do momento.

A Inteligência Artificial.

Quando você escreve:

"Crie um programa COBOL para consultar saldo."

O Copilot gera código.

Mas observe.

Ele não conhece toda a empresa.

Não conhece todas as regras.

Não conhece todas as integrações.

Ele apenas produz uma sugestão.


ChatGPT

O mesmo ocorre aqui.

Uma IA pode ajudar a criar:

  • programas;

  • documentação;

  • testes;

  • SQL;

  • JCL;

  • APIs.

Mas ainda depende do engenheiro para validar:

  • arquitetura;

  • desempenho;

  • segurança;

  • conformidade;

  • regras de negócio.

A IA acelera.

O engenheiro decide.


IA + CASE

Agora imagine unir os dois mundos.

Uma CASE Tool conhece:

  • arquitetura;

  • banco;

  • programas;

  • dependências;

  • documentação.

A IA conhece:

  • linguagem natural;

  • geração de código;

  • testes;

  • documentação.

Resultado.

Uma combinação extremamente poderosa.


Imagine um banco.

O analista escreve.

Adicionar PIX Internacional.

A plataforma consulta o repositório CASE.

Descobre:

  • programas afetados;

  • tabelas;

  • APIs;

  • batchs;

  • CICS;

  • MQ.

Depois.

A IA sugere:

  • alterações COBOL;

  • SQL;

  • documentação;

  • testes.

Esse provavelmente será o futuro da Engenharia de Software.


O impacto no IBM Mainframe

O Mainframe talvez seja a plataforma que mais ganhará com essa evolução.

Por quê?

Porque seus sistemas possuem enorme conhecimento acumulado.

Décadas de regras de negócio.

Milhões de linhas COBOL.

Milhares de programas.

Sem documentação adequada.

A IA trabalha melhor quando possui contexto.

As antigas CASE Tools fornecem exatamente esse contexto.


IBM Application Discovery

Ferramentas como IBM ADDI caminham exatamente nessa direção.

Primeiro.

Entender o sistema.

Depois.

Permitir modernização.

Isso reduz riscos enormes.


IBM watsonx Code Assistant

Outro exemplo.

O IBM watsonx Code Assistant for Z utiliza IA para auxiliar na modernização de aplicações COBOL.

Mas ele não trabalha isoladamente.

Quanto maior o conhecimento sobre o sistema — dependências, modelos, documentação e arquitetura — melhores tendem a ser as recomendações produzidas.

Mais uma vez, percebemos a importância dos princípios introduzidos pelas CASE Tools.


O papel do programador COBOL

Existe uma preocupação comum.

"A IA vai substituir o programador?"

A história das CASE Tools responde essa pergunta.

Durante quarenta anos ouvimos:

  • geradores de código acabarão com os programadores;

  • 4GL eliminarão COBOL;

  • RAD substituirá desenvolvimento tradicional;

  • CASE automatizará tudo;

  • Low-Code eliminará engenheiros.

Nada disso aconteceu.

O que mudou foi o perfil do profissional.

Hoje vale mais quem entende:

  • negócio;

  • arquitetura;

  • integração;

  • segurança;

  • desempenho;

  • governança.

O código tornou-se apenas uma parte da engenharia.


As habilidades do futuro

O desenvolvedor COBOL moderno precisa ampliar seu conjunto de competências.

Além da linguagem, é importante dominar:

  • Modelagem de sistemas;

  • UML e BPMN;

  • APIs REST;

  • JSON e XML;

  • SQL e modelagem de dados;

  • Engenharia reversa;

  • Análise de impacto;

  • Git e DevOps;

  • Cloud híbrida;

  • Inteligência Artificial aplicada ao desenvolvimento;

  • Automação de testes;

  • Documentação viva.

Essas habilidades não substituem o COBOL.

Elas potencializam seu valor.


O futuro não será escrito apenas em código

Estamos entrando em uma era em que o software será construído a partir de vários elementos.

Diagramas.

Modelos.

Prompts.

Documentação.

Metadados.

IA.

Código.

Todos convivendo.

Quem compreender somente programação verá apenas uma parte do processo.

Quem compreender Engenharia de Software enxergará o sistema completo.


O maior legado das CASE Tools

Talvez o maior ensinamento das CASE Tools não tenha sido gerar código.

Foi mostrar que software é conhecimento organizado.

Programas mudam.

Linguagens mudam.

Frameworks desaparecem.

Mas o conhecimento do negócio permanece.

É justamente esse conhecimento que bancos conseguem preservar durante quarenta ou cinquenta anos.

Não por acaso, muitas regras escritas em COBOL nos anos 80 continuam processando bilhões de transações diariamente.

O segredo nunca foi apenas a linguagem.

Foi a engenharia que permitiu manter esses sistemas compreensíveis e evolutivos.


Conclusão

Ao longo desta série vimos que as CASE Tools não pertencem apenas à história da computação. Elas continuam presentes, ainda que sob novos nomes e novas interfaces.

Upper CASE transformou a análise de requisitos em uma disciplina estruturada.

Lower CASE automatizou a implementação e reduziu tarefas repetitivas.

Integrated CASE mostrou que todo o ciclo de vida do software poderia compartilhar um único repositório de conhecimento.

Depois vieram UML, MDD, MDE, DDD, Low-Code, No-Code, DevOps, Infrastructure as Code e, finalmente, a Inteligência Artificial. Todas essas abordagens carregam, em maior ou menor grau, a mesma ideia fundamental: o conhecimento deve ser capturado, organizado, reutilizado e automatizado sempre que possível.

Para quem trabalha com IBM Mainframe e COBOL, essa conclusão é especialmente importante. Os sistemas que sustentam bancos, seguradoras e governos não sobreviveram por décadas apenas porque foram escritos em uma linguagem robusta. Eles sobreviveram porque foram construídos com disciplina, arquitetura e engenharia.

A Inteligência Artificial certamente mudará a forma como produzimos software. Mas ela não elimina a necessidade de compreender processos, regras de negócio, impactos e dependências. Pelo contrário: quanto melhor estruturado estiver esse conhecimento, melhores serão os resultados obtidos com a IA.

As CASE Tools nos ensinaram que a verdadeira riqueza de um sistema não está em suas linhas de código, mas no conhecimento que elas representam. Essa lição continua tão atual hoje quanto era há quarenta anos.

"A Inteligência Artificial pode escrever milhares de linhas de código em poucos segundos. Mas somente a Engenharia de Software transforma esse código em sistemas capazes de durar décadas. Essa sempre foi a missão das CASE Tools. Continua sendo a missão dos engenheiros de software."

 

sexta-feira, 23 de fevereiro de 2024

RAD (Rapid Application Development) — Como Implementar RAD na Prática, Principais Metodologias, Ferramentas - Parte II

 

Bellacosa Mainframe apresenta o rad parte ii

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

Parte II — Como Implementar RAD na Prática, Principais Metodologias, Ferramentas e o Papel da Inteligência Artificial

"Desenvolver rapidamente nunca significou programar rapidamente. Significou aprender rapidamente."


Recapitulando

Na primeira parte desta série vimos que o RAD nasceu como resposta a um problema que ainda existe.

Empresas mudam rapidamente.

Os negócios mudam rapidamente.

Os clientes mudam rapidamente.

O software precisa acompanhar esse ritmo.

James Martin percebeu isso no início dos anos 90, muito antes de ouvirmos falar de Scrum, DevOps, Cloud Computing ou Inteligência Artificial.

Mas existe uma pergunta ainda mais importante.

Como colocar RAD em prática?

É exatamente isso que veremos agora.

Porque conhecer a teoria é relativamente simples.

O verdadeiro desafio está em transformar uma equipe tradicional em uma equipe capaz de entregar software continuamente.


A filosofia do RAD

Antes de falar de ferramentas precisamos compreender uma característica importante.

RAD não é uma ferramenta.

RAD não é uma linguagem.

RAD não é um framework.

RAD é uma filosofia de desenvolvimento.

Essa diferença muda tudo.

Uma empresa pode utilizar Java.

Outra COBOL.

Outra Python.

Outra C#.

Outra JavaScript.

Todas podem aplicar RAD.

O que muda não é a tecnologia.

É a maneira como ela é utilizada.


O primeiro passo: definir um problema pequeno

O maior erro cometido por equipes iniciantes é querer desenvolver todo o sistema de uma única vez.

RAD faz exatamente o contrário.

Começa pequeno.

Muito pequeno.

Imagine um banco.

Ao invés de desenvolver todo o Internet Banking...

Começa apenas pela consulta de saldo.

Depois extrato.

Depois PIX.

Depois investimentos.

Depois cartões.

Cada funcionalidade nasce praticamente como um pequeno projeto.

Essa abordagem reduz riscos.

Se algo der errado...

O prejuízo é pequeno.


Segundo passo: montar uma equipe enxuta

RAD funciona melhor quando existe pouca burocracia.

Normalmente encontramos equipes compostas por:

  • Analista de Negócios

  • Usuário-chave

  • Desenvolvedor

  • Especialista em Banco de Dados

  • Testador

  • Arquiteto

Não significa que grandes empresas trabalhem apenas com seis pessoas.

Significa que cada módulo possui autonomia.

Quanto menor a cadeia de aprovação...

Maior a velocidade.


Terceiro passo: envolver o usuário desde o primeiro dia

Este talvez seja o segredo mais importante.

No desenvolvimento tradicional o usuário aparece em três momentos.

Levantamento.

Homologação.

Produção.

No RAD ele participa praticamente todos os dias.

Imagine um gerente de crédito.

Na segunda-feira ele vê uma tela.

Na terça sugere mudanças.

Na quarta recebe uma nova versão.

Na quinta encontra outro detalhe.

Na sexta aprova.

Foram cinco dias.

Não cinco meses.


Quarto passo: criar um protótipo

Muitos desenvolvedores acreditam que um protótipo precisa funcionar.

Nem sempre.

Às vezes basta desenhar as telas.

Hoje existem dezenas de ferramentas para isso.

Figma.

Balsamiq.

Adobe XD.

Draw.io.

PowerPoint.

Até papel e caneta funcionam.

O objetivo não é impressionar.

É descobrir rapidamente se a ideia faz sentido.


Quinto passo: construir um MVP

Outro conceito herdado pelo desenvolvimento moderno.

MVP significa:

Minimum Viable Product

Ou Produto Mínimo Viável.

É a menor versão possível capaz de gerar valor.

Não significa software incompleto.

Significa software focado.

Imagine um sistema de empréstimos.

Ao invés de desenvolver quarenta funcionalidades...

Construa apenas cinco.

Se resolverem o problema principal...

O MVP cumpriu seu papel.


Sexto passo: validar rapidamente

Depois do MVP vem o momento mais importante.

Mostrar ao usuário.

Sem apresentações longas.

Sem centenas de slides.

Sem documentos enormes.

Coloque o sistema na frente dele.

Observe.

Escute.

Anote.

Melhore.

Repita.

Esse ciclo acontece inúmeras vezes.


Sétimo passo: melhorar continuamente

RAD nunca considera o software terminado.

Sempre existe espaço para melhorias.

Esse conceito influenciou diretamente o DevOps.

A aplicação evolui continuamente.

Pequenas melhorias.

Pequenos ajustes.

Pequenas correções.

Pequenas entregas.

O resultado costuma ser muito superior a uma única entrega gigantesca.


Como medir se o RAD está funcionando?

Toda metodologia precisa de indicadores.

Caso contrário ela vira opinião.

Algumas métricas importantes são:

Tempo até a primeira entrega

Quanto tempo levou para o usuário ver algo funcionando?

Dias?

Semanas?

Meses?

Quanto menor esse tempo...

Melhor.


Tempo de resposta às mudanças

Quanto tempo leva para alterar uma regra?

Horas?

Dias?

Semanas?

Se pequenas alterações exigem meses...

O processo ainda é pesado.


Número de retrabalhos

Se o usuário rejeita constantemente o software...

Algo está errado.

RAD busca reduzir retrabalho através do feedback constante.


Satisfação do usuário

Talvez seja o indicador mais importante.

Software existe para resolver problemas.

Não para produzir documentação.


As metodologias que herdaram conceitos do RAD

Embora o RAD seja uma metodologia própria, diversos movimentos posteriores incorporaram suas ideias.

Scrum

Sprint.

Incrementos.

Revisões.

Backlog.

Todos esses conceitos possuem enorme afinidade com RAD.

A principal diferença é que Scrum adicionou uma estrutura mais formal para gerenciamento.


Extreme Programming (XP)

XP talvez seja a metodologia que mais herdou conceitos do RAD.

Ela enfatiza:

  • feedback constante;

  • integração contínua;

  • programação em pares;

  • testes automatizados;

  • pequenas entregas.

Na prática, XP leva o RAD para um nível técnico ainda maior.


Lean Software Development

O Lean nasceu inspirado no Sistema Toyota.

Seu foco é eliminar desperdícios.

Curiosamente...

RAD também fazia exatamente isso.

Ambos valorizam aquilo que gera valor ao cliente.


DevOps

Muitos imaginam que DevOps trata apenas de infraestrutura.

Não.

DevOps também reduz o tempo entre desenvolver e colocar em produção.

Essa busca pela velocidade é um dos princípios centrais do RAD.


Agile

Podemos dizer que o RAD foi um dos grandes precursores do movimento ágil.

Nem todos concordam com essa afirmação.

Mas basta observar os princípios.

Feedback rápido.

Cliente presente.

Entregas frequentes.

Iterações.

Tudo isso já aparecia no RAD.


Ferramentas clássicas do RAD

Nos anos 90 existia uma verdadeira explosão de ferramentas RAD.

Algumas desapareceram.

Outras evoluíram.

Outras continuam presentes.

Entre elas:

PowerBuilder

Uma das maiores referências da época.

Construía aplicações corporativas rapidamente.


Oracle Forms

Durante muitos anos dominou aplicações empresariais.

Principalmente no ambiente Oracle.


Visual Basic

Talvez o maior símbolo do RAD para plataformas Windows.

Arrastar componentes.

Criar telas.

Conectar banco.

Gerar aplicações em poucas horas.


Delphi

Um dos ambientes RAD mais famosos da história.

Compilação extremamente rápida.

Excelente desempenho.

Grande produtividade.

Até hoje possui uma comunidade fiel.


GeneXus

Muito conhecido na América Latina.

Gera aplicações automaticamente para diversas plataformas.

Utilizado inclusive em grandes instituições financeiras.


Magic xpa

Ferramenta RAD voltada ao ambiente corporativo.

Muito utilizada em integração de sistemas.


Ferramentas modernas

O conceito continua vivo.

Mudaram apenas os nomes.

Hoje encontramos:

Microsoft Power Apps

Google AppSheet

OutSystems

Mendix

ServiceNow App Engine

Salesforce Lightning

Oracle APEX

Retool

FlutterFlow

Bubble

Appian

Zoho Creator

Todas seguem praticamente a mesma ideia.

Construir rapidamente.

Validar rapidamente.

Entregar rapidamente.


RAD e Low-Code

É impossível falar de RAD sem mencionar Low-Code.

Na prática...

Low-Code tornou o RAD muito mais poderoso.

Imagine criar uma tela.

Conectar um banco.

Criar APIs.

Publicar na nuvem.

Tudo isso praticamente sem escrever código.

O RAD encontrou no Low-Code um parceiro natural.


RAD e No-Code

O No-Code leva esse conceito ainda mais longe.

Usuários de negócio conseguem construir soluções simples.

Sem depender completamente da TI.

Isso acelera protótipos.

Validações.

Experimentos.

Naturalmente, sistemas críticos ainda exigem desenvolvimento profissional.

Especialmente no Mainframe.


Inteligência Artificial e RAD

Talvez este seja o maior salto desde os anos 90.

Hoje a IA consegue:

Gerar código.

Criar documentação.

Escrever testes.

Produzir APIs.

Criar consultas SQL.

Explicar código legado.

Converter linguagens.

Criar protótipos.

Documentar regras de negócio.

Isso reduz drasticamente o tempo de desenvolvimento.

Mas existe um detalhe importante.

A IA acelera.

Ela não substitui engenharia.

Alguém continua precisando tomar decisões arquiteturais.


Performance no RAD

Existe outro mito bastante conhecido.

"Software desenvolvido rapidamente é lento."

Não necessariamente.

Performance depende muito mais da arquitetura.

Uma aplicação construída em RAD pode apresentar excelente desempenho quando possui:

  • arquitetura bem definida;

  • banco de dados otimizado;

  • índices corretos;

  • consultas eficientes;

  • cache adequado;

  • testes de carga;

  • monitoramento constante.

O problema não está na velocidade do desenvolvimento.

Está na ausência de engenharia.


Governança

Projetos RAD também precisam de controle.

Sem governança surge o caos.

Algumas práticas recomendadas:

Versionamento no Git.

Code Review.

Integração Contínua.

Pipeline automatizado.

Testes automatizados.

Documentação mínima.

Monitoramento.

Catálogo de APIs.

Padronização de componentes.


Segurança

Outro erro comum.

"Ainda é protótipo."

Quantos incidentes começaram exatamente assim?

Mesmo durante prototipação devemos considerar:

Autenticação.

Autorização.

Criptografia.

Proteção de dados.

LGPD.

Auditoria.

Logs.

Quanto antes a segurança entrar no projeto...

Menor o custo.


Quando RAD não é a melhor escolha?

Existem situações em que outras abordagens podem ser mais adequadas.

Por exemplo:

Projetos militares.

Sistemas embarcados extremamente críticos.

Software aeroespacial.

Equipamentos médicos.

Aplicações certificadas.

Ambientes altamente regulados.

Nesses casos o custo da documentação extensa pode ser menor que o risco de falhas.

Mesmo assim, muitos princípios do RAD continuam sendo utilizados durante prototipação e validação.


O erro mais comum

Muitos gestores acreditam que RAD significa fazer tudo mais rápido.

Na realidade significa aprender mais rápido.

Existe uma enorme diferença.

Velocidade sem aprendizado produz retrabalho.

Aprendizado contínuo produz velocidade.

Essa talvez seja a maior lição deixada por James Martin.


O que um programador COBOL pode aproveitar hoje?

Mesmo trabalhando exclusivamente com IBM Z, praticamente todos os conceitos desta parte podem ser aplicados.

Você pode criar protótipos de telas antes de desenvolver transações CICS.

Pode validar regras de negócio com usuários antes de alterar programas COBOL.

Pode utilizar APIs simuladas para testar integrações.

Pode automatizar builds, testes e deploys em pipelines DevOps.

Pode expor programas COBOL como serviços REST por meio do z/OS Connect e receber feedback em ciclos curtos.

Pode utilizar Inteligência Artificial para documentar código legado, sugerir refatorações e acelerar a criação de testes.

O ambiente mudou muito desde 1991, mas o objetivo continua exatamente o mesmo: reduzir a distância entre a necessidade do negócio e a entrega de uma solução funcional.

No próximo café entraremos definitivamente no universo IBM Mainframe. Veremos como aplicar RAD em aplicações COBOL, CICS, IMS, DB2, VSAM e z/OS, como integrar essa metodologia com DevOps, Git, APIs, z/OS Connect, testes automatizados e modernização, além de entender por que o RAD continua extremamente relevante na era do IBM Z e da Inteligência Artificial.