Bellacosa Mainframe e a caixa preta do automatos

☕ Um Café no Bellacosa Mainframe

🌑 CID KAGENOU E A CAIXA-PRETA DOS AUTÔMATOS — QUANDO O COBOL DESCOBRIU QUE TAMBÉM ERA UMA MÁQUINA DE ESTADOS

Autômatos finitos, máquinas de estados, linguagens regulares, regex, engenharia reversa, CPU, COBOL, testes, protocolos, segurança — e o dia em que Shadow descobriu que não precisava abrir a caixa-preta para descobrir o segredo escondido dentro dela.

---

🎬 PRÓLOGO — HÁ ALGUMA COISA ESCONDIDA NESSA CAIXA

Imagine Cid Kagenou entrando em uma dungeon.

Nenhum monstro.

Nenhum artefato mágico.

Nenhuma princesa sequestrada.

Alpha olha desconfiada para o centro da sala.

Ali existe apenas uma pequena caixa preta.

Na frente dela:

• um terminal de entrada;

• uma pequena lâmpada;

• um botão escrito RESET.

Beta examina o equipamento.

— Shadow-sama, devemos desmontá-lo?

Cid cruza os braços.

— Não.

Silêncio dramático.

Naturalmente, todos imaginam que Shadow descobriu algum segredo ancestral.

Na realidade, ele simplesmente não sabe como abrir a caixa.

Mas, como frequentemente acontece em The Eminence in Shadow, uma frase improvisada acaba contendo uma ideia surpreendentemente profunda:

Não precisamos conhecer o interior de uma máquina para estudar seu comportamento.

E é justamente assim que começa nossa excursão pela Teoria dos Autômatos.

Pegue seu café.

Aperte o cinto.

Nosso ônibus vai balançar um pouco.

---

🚌 CAPÍTULO 1 — O ÔNIBUS DE TURING CHEGA À DUNGEON

A inspiração desta viagem vem de A. K. Dewdney, autor de The Turing Omnibus, livro concebido como uma série de excursões por diferentes territórios da Ciência da Computação.

A metáfora é maravilhosa.

Em vez de imaginar Ciência da Computação como um gigantesco manual técnico, imagine um ônibus.

Em cada parada visitamos alguma região:

AUTÔMATOS
     ↓
LINGUAGENS FORMAIS
     ↓
ALGORITMOS
     ↓
LÓGICA
     ↓
COMPLEXIDADE
     ↓
COMPUTABILIDADE
     ↓
INTELIGÊNCIA ARTIFICIAL
     ↓
...

Na primeira excursão encontramos justamente uma criatura aparentemente humilde:

o autômato finito.

Não deixe o nome assustar.

Vamos desmontar o conceito — sem desmontar nossa caixa.

---

📦 CAPÍTULO 2 — SHADOW ENCONTRA UMA CAIXA-PRETA

Nossa máquina possui uma entrada capaz de receber dois sinais:

0
1

Também possui uma lâmpada.

Quando determinada sequência é fornecida, a lâmpada eventualmente acende.

Podemos representar a máquina assim:

             ┌──────────────────────┐
0 ou 1 ─────►│                      │
             │      CAIXA-PRETA     │────► 💡
RESET ──────►│                      │
             └──────────────────────┘

Não sabemos o que existe dentro.

Pode haver:

transistores
circuitos
flip-flops
microcontrolador
relés
magia negra
um COBOL de 1978

Para nossa análise, isso não importa.

Estamos interessados em:

ENTRADA → COMPORTAMENTO → SAÍDA

Essa é uma abstração extremamente importante na computação.

Um programa COBOL pode executar:

CALL 'PAGTO001'

Você não precisa necessariamente conhecer cada instrução existente em PAGTO001 para utilizar sua interface corretamente.

Da mesma maneira, quando consumimos uma API:

POST /pagamento

podemos trabalhar com o contrato da API sem conhecer toda sua implementação.

A primeira lição da dungeon é, portanto:

Implementação e comportamento são coisas diferentes.

---

🧪 CAPÍTULO 3 — ALPHA COMEÇA OS EXPERIMENTOS

Vamos alimentar nossa máquina.

Depois de pressionar RESET:

0

Nada.

1

Nada.

0

Nada.

1

💡

A lâmpada acendeu.

Descobrimos:

0101

parece ser uma sequência aceita.

Alpha repete imediatamente:

0101

Nada.

Beta começa a escrever um relatório de 847 páginas explicando que provavelmente se trata de um artefato demoníaco.

Até alguém lembrar:

RESET.

Pressionamos RESET.

Executamos novamente:

0101

💡

Funciona.

Isso revela uma informação gigantesca.

A máquina lembra alguma coisa do que aconteceu anteriormente.

---

🧠 CAPÍTULO 4 — O SEGREDO CHAMA-SE ESTADO

Se a saída dependesse somente do último símbolo recebido, bastaria analisar:

entrada atual

Mas nossa experiência demonstra que o comportamento depende também da história anterior.

Existe alguma espécie de memória.

Na teoria dos autômatos chamamos essa informação de:

ESTADO

Estado não significa necessariamente uma variável armazenada em RAM.

Uma definição muito melhor seria:

Estado é a informação relevante sobre o passado necessária para decidir o comportamento futuro.

Essa frase vale ouro.

Imagine uma porta eletrônica.

Ela poderia possuir:

LOCKED
UNLOCKED

Quando recebe:

CARD_VALID

pode fazer:

LOCKED → UNLOCKED

Quando alguém abre a porta:

UNLOCKED → LOCKED

Não precisamos registrar toda a biografia da pessoa:

acordou às 07:00
tomou café
pegou o carro
chegou ao escritório
tirou o cartão do bolso
...

Nada disso interessa à porta.

A informação relevante é:

LOCKED

ou:

UNLOCKED

O estado é, portanto, uma espécie de compressão do passado.

---

🌑 CAPÍTULO 5 — SHADOW GARDEN DESCOBRE A MÁQUINA DE ESTADOS

Imagine uma catraca.

Estados:

Q0 = LOCKED
Q1 = UNLOCKED

Entradas:

COIN
PUSH

Podemos definir:

LOCKED + COIN → UNLOCKED
LOCKED + PUSH → LOCKED

UNLOCKED + PUSH → LOCKED
UNLOCKED + COIN → UNLOCKED

Isso pode ser colocado numa tabela:

Estado atual	Entrada	Novo estado
LOCKED	COIN	UNLOCKED
LOCKED	PUSH	LOCKED
UNLOCKED	PUSH	LOCKED
UNLOCKED	COIN	UNLOCKED

Temos uma máquina de estados.

E provavelmente você já programou alguma sem saber.

---

🧙 CAPÍTULO 6 — A DEFINIÇÃO MATEMÁTICA

Um autômato finito determinístico costuma ser definido pela quíntupla:

M = (Q, Σ, δ, q0, F)

Calma.

Não invoque ainda o compilador COBOL.

Vamos traduzir.

Q — conjunto de estados

Por exemplo:

Q = {q0,q1,q2,q3,q4,q5}

Σ — alfabeto

São os símbolos aceitos como entrada.

No nosso exemplo:

Σ = {0,1}

δ — função de transição

A famosa letra grega delta determina:

estado atual + entrada → próximo estado

Formalmente:

δ : Q × Σ → Q

Por exemplo:

δ(q3,0)=q5
δ(q3,1)=q4

q0 — estado inicial

É onde começamos depois do RESET.

F — estados finais

São os estados considerados de aceitação.

Quando terminamos de processar a entrada em algum deles:

💡

A sequência foi aceita.

---

💾 CAPÍTULO 7 — DELTA DESCOBRE QUE DELTA NÃO É APENAS UMA PERSONAGEM

Imagine a surpresa da própria Delta ao descobrir que existe uma função matemática chamada δ.

Se estivermos em:

q3

e recebermos:

1

podemos ter:

δ(q3,1)=q4

Isso significa simplesmente:

ESTADO ATUAL = Q3
ENTRADA = 1
NOVO ESTADO = Q4

Não existe mistério.

Na prática, poderíamos implementar isso em COBOL.

---

💻 CAPÍTULO 8 — O AUTÔMATO ENTRA NO COBOL

Considere:

01 WS-STATE       PIC X(02).
01 WS-INPUT       PIC X.

MOVE 'Q0' TO WS-STATE.

EVALUATE TRUE

   WHEN WS-STATE = 'Q0'
        AND WS-INPUT = '0'
        MOVE 'Q1' TO WS-STATE

   WHEN WS-STATE = 'Q0'
        AND WS-INPUT = '1'
        MOVE 'Q0' TO WS-STATE

   WHEN WS-STATE = 'Q1'
        AND WS-INPUT = '0'
        MOVE 'Q1' TO WS-STATE

   WHEN WS-STATE = 'Q1'
        AND WS-INPUT = '1'
        MOVE 'Q2' TO WS-STATE

END-EVALUATE.

Parabéns.

Acabamos de implementar parte de um autômato finito.

Uma implementação mais organizada poderia separar:

READ-INPUT
PROCESS-TRANSITION
CHECK-FINAL-STATE

Observe como conceitos aparentemente matemáticos começam a aparecer naturalmente no COBOL.

---

🔄 CAPÍTULO 9 — O RESET É O INITIALIZE DA DUNGEON

O botão RESET possui uma importância enorme.

Ele coloca a máquina novamente em:

q0

Imagine testar:

0101

e depois:

0100101

sem RESET.

O segundo teste não começa realmente do zero.

A máquina pode estar carregando o estado produzido pelo primeiro.

Na prática estamos testando algo parecido com:

01010100101

Isso possui uma conexão direta com testes de software.

Um teste confiável deve começar de condições conhecidas.

Algo como:

GIVEN estado conhecido
WHEN evento acontece
THEN resultado esperado

Em COBOL isso poderia significar:

INITIALIZE WS-AREA
MOVE ZERO TO WS-COUNTER
MOVE '00' TO WS-STATUS

Estado residual é uma fonte clássica de bugs.

---

🔬 CAPÍTULO 10 — SHADOW COMEÇA A ENGENHARIA REVERSA

Executamos vários experimentos.

Descobrimos que a caixa aceita:

0101
0100101
0100100101
0100100100101

Vamos reorganizar:

01             01
01 001         01
01 001 001     01
01 001 001 001 01

Há claramente um padrão:

01 (001)* 01

O símbolo:

*

é chamado estrela de Kleene.

Significa:

zero ou mais repetições.

Portanto:

(001)*

pode produzir:

ε
001
001001
001001001
001001001001
...

ε representa a palavra vazia.

Consequentemente:

01(001)*01

produz:

0101
0100101
0100100101
0100100100101
...

Acabamos de entrar no território das linguagens regulares.

---

📜 CAPÍTULO 11 — REGEX NÃO NASCEU PARA VALIDAR E-MAIL

Quando alguém fala em expressão regular, muitos programadores imediatamente pensam:

^[0-9]{5}-[0-9]{3}$

CEP.

Ou alguma criatura monstruosa utilizada para validar endereço de e-mail.

Mas existe uma teoria matemática muito mais profunda por trás disso.

A relação fundamental é:

┌─────────────────────┐
│ EXPRESSÃO REGULAR   │
└──────────┬──────────┘
           │
           ⇅
┌─────────────────────┐
│ AUTÔMATO FINITO     │
└──────────┬──────────┘
           │
           ⇅
┌─────────────────────┐
│ LINGUAGEM REGULAR   │
└─────────────────────┘

Essas são diferentes maneiras de descrever a mesma classe fundamental de linguagens.

Uma regex pode ser transformada em um autômato.

Um autômato pode ser utilizado para reconhecer uma linguagem regular.

Essa relação aparece na implementação de scanners, parsers simples, ferramentas de busca e compiladores.

---

⚠️ CAPÍTULO 12 — CID PERCEBE O PROBLEMA DA INDUÇÃO

Agora surge uma questão maravilhosa.

Testamos:

0101
0100101
0100100101
0100100100101

Todas funcionaram.

Podemos afirmar que:

01(001)*01

é realmente a linguagem completa da máquina?

Não.

Talvez a máquina aceite apenas:

n <= 4

Talvez rejeite a quinta repetição.

Ou a número 847.

Ou talvez exista algum comportamento especial depois de 65.535 símbolos.

Experimentar alguns casos não demonstra automaticamente uma regra infinita.

Esse é um princípio extremamente importante também para testes.

---

🧪 CAPÍTULO 13 — “FUNCIONOU NO MEU TESTE”

O programador executa:

100 → OK
200 → OK
300 → OK
400 → OK

e declara:

— Funciona.

Shadow aparece atrás dele.

— Você testou 32767?

Silêncio.

— E 32768?

Mais silêncio.

— 99999999?

O programador começa a suar.

Testes demonstram comportamento para os casos efetivamente observados.

Não provam automaticamente comportamento universal.

É exatamente o problema encontrado na caixa-preta.

---

🕵️ CAPÍTULO 14 — MAS E SE SOUBERMOS QUANTOS ESTADOS EXISTEM?

Agora alguém nos fornece uma informação adicional:

A máquina possui seis estados.

Isso muda profundamente o problema.

Imagine:

q0
q1
q2
q3
q4
q5

Depois de transições suficientes, algum estado inevitavelmente precisará reaparecer.

Por quê?

Porque só existem seis possibilidades.

Se continuarmos andando:

q0 → q1 → q2 → q3 → q4 → q5 → ?

o próximo estado necessariamente será algum estado já existente.

Surge então um ciclo:

        ┌──────────────┐
        ↓              │
q2 → q3 → q4 → q5 ────┘

E ciclos explicam repetições.

Como:

(001)*

Aqui começamos a enxergar a intuição que posteriormente aparece em resultados como o Pumping Lemma.

---

🏰 CAPÍTULO 15 — EXISTEM MONSTROS QUE O AUTÔMATO NÃO CONSEGUE DERROTAR

Considere:

ab
aabb
aaabbb
aaaabbbb

A regra é:

aⁿbⁿ

Precisamos garantir:

quantidade de a = quantidade de b

Agora imagine:

aaaaaaaaaaaaaaaa....

Para saber quantos b deverão aparecer posteriormente, precisamos lembrar quantos a foram encontrados.

Mas nosso autômato possui memória finita.

Se existem apenas:

q0 q1 q2 q3 q4 q5

como representar:

1
2
3
4
...
1.000.000

quantidades diferentes?

Não consegue.

Encontramos uma fronteira computacional.

---

🪜 CAPÍTULO 16 — A ESCADA DAS MÁQUINAS

Quando precisamos de memória adicional, utilizamos modelos mais poderosos.

De forma simplificada:

AUTÔMATO FINITO
       ↓
AUTÔMATO COM PILHA
       ↓
MODELOS MAIS PODEROSOS
       ↓
MÁQUINA DE TURING

O autômato com pilha pode trabalhar com estruturas como:

((()))

Cada abertura:

(

pode empilhar alguma informação.

Cada fechamento:

)

remove algo da pilha.

Isso permite reconhecer estruturas que um simples autômato finito não consegue reconhecer.

E estamos nos aproximando da Hierarquia de Chomsky e da teoria das linguagens formais.

A pequena lâmpada começou a ficar perigosamente interessante.

---

🖥️ CAPÍTULO 17 — ESTÁVAMOS ESTUDANDO UMA CPU?

Existe uma bela provocação no texto original adaptado:

estivemos estudando o funcionamento de uma CPU simples.

Precisamos colocar uma pequena ressalva técnica.

Uma CPU moderna não é simplesmente aquele pequeno DFA.

Entretanto, componentes de hardware e circuitos sequenciais podem ser modelados por máquinas de estados.

Imagine:

FETCH
  ↓
DECODE
  ↓
EXECUTE
  ↓
MEMORY
  ↓
WRITEBACK
  ↓
FETCH

O processador possui estados internos.

Sinais e resultados influenciam as próximas transições.

Assim, a teoria dos autômatos possui ligação genuína com projeto de hardware.

---

🏧 CAPÍTULO 18 — VOCÊ ESTÁ CERCADO POR MÁQUINAS DE ESTADOS

Olhe ao redor.

Um elevador:

STOPPED
MOVING_UP
MOVING_DOWN
DOOR_OPEN
DOOR_CLOSING

Um caixa eletrônico:

IDLE
 ↓
CARD_INSERTED
 ↓
PIN_VALIDATED
 ↓
AUTHENTICATED
 ↓
TRANSACTION
 ↓
EJECT_CARD

Uma aplicação:

LOGGED_OUT
 ↓
AUTHENTICATING
 ↓
LOGGED_IN
 ↓
SESSION_EXPIRED

Um pedido:

CREATED
 ↓
PAID
 ↓
PROCESSING
 ↓
SHIPPED
 ↓
DELIVERED

Até muitos protocolos de rede podem ser entendidos como máquinas de estados.

---

💳 CAPÍTULO 19 — O AUTÔMATO ENTRA NO MAINFRAME

Agora imagine processamento de cartões.

Uma transação poderia atravessar:

RECEIVED
    ↓
VALIDATED
    ↓
AUTHORIZED
    ↓
CAPTURED
    ↓
SETTLED

Ou:

RECEIVED
    ↓
VALIDATED
    ↓
DECLINED

Isso poderia estar espalhado por:

COBOL
CICS
Db2
VSAM
IBM MQ
batch
APIs

Mas conceitualmente temos uma máquina de estados.

Um programa poderia fazer:

EVALUATE WS-STATUS

   WHEN 'RECEIVED'
        PERFORM 2000-VALIDATE

   WHEN 'VALIDATED'
        PERFORM 3000-AUTHORIZE

   WHEN 'AUTHORIZED'
        PERFORM 4000-CAPTURE

   WHEN 'CAPTURED'
        PERFORM 5000-SETTLEMENT

END-EVALUATE.

O programador COBOL está implementando teoria dos autômatos sem necessariamente perceber.

---

⚔️ CAPÍTULO 20 — A TRANSIÇÃO PROIBIDA

Aqui aparece uma aplicação extremamente útil para manutenção de sistemas legados.

A documentação diz:

CREATED → PAID → SHIPPED

Mas encontramos:

CREATED → SHIPPED

Pergunta:

essa transição é válida?

Talvez tenhamos encontrado o bug.

Em vez de olhar apenas para milhares de linhas COBOL, podemos tentar descobrir:

ESTADOS
EVENTOS
TRANSIÇÕES
ESTADOS FINAIS

Um programa de 12.000 linhas talvez possa ser resumido como:

14 estados
43 transições
11 eventos
5 estados finais

Isso é ouro para engenharia reversa.

---

🔥 CAPÍTULO 21 — WAR ROOM ÀS 03:17

03:17.

Naturalmente.

O telefone toca.

Produção caiu.

No log:

03:17:00 RECEIVED
03:17:01 VALIDATED
03:17:02 AUTHORIZED
03:17:03 CAPTURED
03:17:04 ERROR

O programador procura:

IF
EVALUATE
GO TO
PERFORM

O DBA examina Db2.

O especialista CICS olha dumps.

O pessoal de infraestrutura examina CPU.

Shadow permanece no fundo da sala.

Até fazer uma pergunta:

CAPTURED → ERROR é uma transição permitida?

Silêncio.

Talvez o problema não esteja em uma instrução individual.

Talvez exista uma transição de negócio impossível.

E aí está nosso easter egg das 03:17.

---

🛡️ CAPÍTULO 22 — O AUTÔMATO VIRA RED TEAM

Máquinas de estados também ajudam a pensar segurança.

Imagine:

DISCONNECTED
     ↓ LOGIN
AUTHENTICATING
     ↓ SUCCESS
AUTHENTICATED

Mas alguém descobre:

DISCONNECTED
     ↓ EVENTO-X
ADMIN

Isso é interessantíssimo.

O atacante encontrou uma transição que não deveria existir.

Problemas semelhantes aparecem em:

protocolos
autenticação
workflows
APIs
sistemas distribuídos
model-based testing
fuzzing
engenharia reversa

Uma excelente estratégia de segurança é perguntar:

Quais estados existem e quais transições deveriam ser impossíveis?

---

🤖 CAPÍTULO 23 — A CAIXA-PRETA ENCONTRA A INTELIGÊNCIA ARTIFICIAL

Existe ainda uma conexão conceitual com IA.

Nosso experimento faz:

ENTRADAS
   ↓
OBSERVAÇÕES
   ↓
HIPÓTESE
   ↓
MODELO

Em aprendizado de máquina fazemos, em sentido muito amplo:

DADOS
   ↓
PADRÕES
   ↓
MODELO

Naturalmente um LLM moderno não deve ser confundido com o pequeno autômato da nossa dungeon.

Mas existe uma pergunta epistemológica comum:

Quanto podemos descobrir sobre um sistema observando somente seu comportamento externo?

Essa questão reaparece quando trabalhamos com sistemas proprietários, serviços remotos e modelos aos quais não temos acesso interno.

A caixa-preta continua conosco.

---

🔧 CAPÍTULO 24 — COMO USAR ESSA IDEIA NUM COBOL LEGADO

Agora uma dica extremamente prática.

Você recebe um programa desconhecido.

Não comece tentando entender todas as linhas simultaneamente.

PASSO 1 — descubra as entradas

Procure:

arquivos
COMMAREA
MQ
parâmetros
Db2
VSAM
SYSIN

PASSO 2 — identifique os estados

Procure campos como:

STATUS
STATE
SITUATION
TYPE
PHASE
STAGE
FLAG

PASSO 3 — encontre onde mudam

Pesquise:

MOVE 'XX' TO WS-STATUS

ou:

SET STATUS-APPROVED TO TRUE

PASSO 4 — construa uma tabela

Por exemplo:

Estado	Evento	Próximo estado
RECEIVED	VALID	VALIDATED
RECEIVED	INVALID	REJECTED
VALIDATED	APPROVE	AUTHORIZED
VALIDATED	DENY	DECLINED

PASSO 5 — desenhe o diagrama

Você pode descobrir uma arquitetura lógica que ninguém documentou.

PASSO 6 — procure transições impossíveis

Pergunte:

REJECTED → SETTLED ?
CANCELLED → AUTHORIZED ?
SHIPPED → CREATED ?

Esses caminhos merecem investigação.

---

🧠 CAPÍTULO 25 — O VERDADEIRO PODER DA ABSTRAÇÃO

Observe tudo que removemos da caixa:

voltagem
resistores
transistores
temperatura
fiação
material
clock
fabricante

E preservamos:

Q
Σ
δ
q0
F

Esse processo chama-se abstração.

Não estamos dizendo que detalhes físicos não existem.

Estamos dizendo:

para responder determinada pergunta, eles não são necessários.

Isso aparece em toda a computação.

Quando trabalhamos com COBOL:

arquivo lógico

podemos não precisar conhecer imediatamente a geometria física do disco.

Quando usamos Db2:

SELECT ...

não precisamos controlar manualmente cada bloco armazenado.

Quando utilizamos MQ:

PUT
GET

trabalhamos sobre uma abstração.

Camadas de abstração são uma das razões pelas quais conseguimos construir sistemas gigantescos.

---

☕ EPÍLOGO — SHADOW DESCOBRE O QUE SIGNIFICA COMPUTAR

Nossa excursão começou com:

0
1
RESET
💡

Parecia quase infantil.

Mas então descobrimos:

caixa-preta
     ↓
estado
     ↓
transição
     ↓
autômato
     ↓
linguagem
     ↓
expressão regular
     ↓
limites de memória
     ↓
linguagens formais
     ↓
computabilidade

Essa é a beleza da Ciência da Computação.

COBOL é importante.

Python é importante.

Java é importante.

Assembler é importante.

Mas existe um universo abaixo das linguagens:

LÓGICA
AUTÔMATOS
ALGORITMOS
LINGUAGENS FORMAIS
COMPLEXIDADE
COMPUTABILIDADE
INFORMAÇÃO

Um programador pode passar décadas escrevendo programas sem visitar profundamente esse território.

Mas quando começa a estudá-lo, algo muda.

Ele deixa de enxergar apenas:

IF
MOVE
PERFORM
EVALUATE

e começa a enxergar:

ESTADOS
TRANSIÇÕES
LINGUAGENS
MODELOS
INVARIANTES
LIMITES

E isso muda inclusive a maneira de investigar um COBOL legado.

Aquele monstro de 15.000 linhas talvez não seja simplesmente um amontoado de PERFORM, IF, copybooks e tabelas Db2.

Talvez escondido lá dentro exista algo muito mais elegante:

             ┌─────────────┐
             │  RECEIVED   │
             └──────┬──────┘
                    ↓
             ┌─────────────┐
             │  VALIDATED  │
             └──────┬──────┘
                ┌───┴───┐
                ↓       ↓
          AUTHORIZED  DECLINED
                ↓
            CAPTURED
                ↓
             SETTLED

Uma máquina de estados.

Uma descendente conceitual daquela pequena caixa-preta.

E talvez essa seja a grande lição deixada pela primeira parada do ônibus de Dewdney.

Não precisamos começar abrindo a máquina.

Primeiro podemos observar.

Experimentar.

Modelar.

Formular hipóteses.

Descobrir estados.

Mapear transições.

Procurar ciclos.

Encontrar exceções.

E somente depois descer às entranhas da implementação.

Alpha observa o diagrama.

Beta termina o volume 37 de As Crônicas Secretas da Máquina de Estados de Shadow-sama.

Delta continua indignada porque roubaram seu nome para uma função matemática.

Cid olha para a caixa-preta.

A lâmpada acende.

0100100101

Ele sorri.

— Exatamente como eu havia previsto.

Não havia previsto coisa nenhuma.

Mas desta vez estava correto.

☕ Um Café no Bellacosa Mainframe

Porque algumas vezes compreender 15.000 linhas de COBOL começa desenhando seis círculos e algumas flechas em um pedaço de papel.