Arquitetura de Software Web Internet
Preservação da trajetória de uma arquitetura de processos que evoluiu da representação industrial em desenhos para a representação matricial de software Web. Este documento reúne os principais marcos registrados, em ordem temporal.
Introdução — Nós Programadores
A ideia central de "Nós, programadores", da ada à inteligência artificial livro de Robert C. Martin (Autor) pode ser entendida como a história de uma mudança profunda: programar deixou de significar apenas escrever instruções para uma máquina e passou a significar modelar problemas, estruturas, processos e conhecimento em linguagem computacional. O programador começou como alguém que traduzia cálculos para máquinas, tornou-se construtor de algoritmos e sistemas, depois engenheiro de software e, hoje, tende a assumir cada vez mais o papel de arquiteto, projetista e orientador de agentes de IA. A máquina executa cada vez mais a implementação; o diferencial humano desloca-se para compreender o problema, abstrair, definir regras, validar resultados e criar soluções. A história, de Ada à IA 1843 — Ada Lovelace: ao escrever suas notas sobre a Máquina Analítica de Charles Babbage, Ada percebeu algo extraordinário: uma máquina poderia manipular não apenas números, mas símbolos segundo regras. Seu algoritmo para os números de Bernoulli é frequentemente considerado o primeiro programa publicado destinado a ser executado por uma máquina. 1930–1940 — fundamentos: Alan Turing formaliza a ideia de máquina computacional universal; máquinas eletromecânicas e depois eletrônicas mostram que algoritmos podem ser executados fisicamente. 1940–1950 — programação de máquina: ENIAC e outras máquinas são programadas diretamente por chaves, cabos, códigos e posteriormente linguagem de máquina. O programador precisava conhecer intimamente o hardware. 1950s — Assembly e primeiras linguagens: Assembly aproxima o ser humano da máquina. Depois surgem FORTRAN, LISP, COBOL e outras linguagens. Nasce a ideia revolucionária de que podemos descrever o que queremos calcular sem escrever cada operação eletrônica. 1960–1970 — estrutura e engenharia: ALGOL, BASIC, Pascal e outras linguagens introduzem estruturas mais poderosas. A programação começa a se tornar uma disciplina de engenharia. Surge também a preocupação com modularidade, manutenção e qualidade. 1970–1980 — C e Unix: C aproxima programação de alto nível e controle do hardware. Unix consolida uma filosofia de ferramentas pequenas, combináveis e reutilizáveis. A programação passa a construir ecossistemas, não apenas programas isolados. 1980–1990 — orientação a objetos e computadores pessoais: Smalltalk, C++, Objective-C e posteriormente Java popularizam a ideia de representar sistemas como objetos que possuem dados e comportamento. O PC democratiza a programação. 1990–2000 — Internet: HTML, JavaScript, PHP, Python, Java e outras tecnologias fazem o software sair do computador individual e tornar-se rede. Surge a Web como enorme plataforma de programação. 2000–2010 — software como serviço: frameworks, bancos de dados, APIs, computação em nuvem e smartphones transformam o desenvolvimento. O programador passa a integrar componentes existentes em arquiteturas cada vez maiores. 2010–2020 — dados e aprendizado de máquina: Python, TensorFlow, PyTorch e outras ferramentas tornam central a programação orientada a dados. Em vez de escrever todas as regras, o programador passa a ensinar modelos a partir de exemplos. 2020–2026 — programação assistida por IA: GitHub Copilot, modelos de linguagem, agentes de programação e ambientes como Cursor e outros sistemas mudam novamente o papel humano. O programador pode descrever uma intenção, deixar a IA gerar código, testar, corrigir e refatorar, enquanto ele supervisiona a arquitetura e o resultado. A grande transformação Podemos resumir os quase 200 anos assim: Ada → instruções para uma máquina Assembly → instruções mais próximas do ser humano Linguagens → algoritmos expressos em abstrações Orientação a objetos → modelos de entidades e comportamentos Web/cloud → sistemas distribuídos Machine Learning → sistemas que aprendem padrões IA generativa → sistemas que produzem código IA agentica → sistemas que planejam, executam, testam e corrigem tarefas E talvez este seja o ponto mais importante para o nosso projeto de preservação do conhecimento de programação: a programação não está desaparecendo; ela está mudando de camada. Antes, o conhecimento essencial era saber escrever cada instrução. Hoje, cada vez mais, é saber formular o problema, projetar a solução, escolher a arquitetura, especificar o comportamento desejado e avaliar criticamente aquilo que a IA produziu. Isso conecta diretamente a programação tradicional que você acumulou ao longo de décadas — de linguagens, bancos de dados, HTML, PHP/Python, sistemas especialistas etc. — com a próxima etapa: o programador como arquiteto de sistemas e orquestrador de inteligências artificiais.
Esta preservação registra um exemplo de trajetória de programação ao longo das cinco últimas décadas, acompanhando a transformação dos computadores, das linguagens, dos ambientes de desenvolvimento e, principalmente, da maneira de pensar a arquitetura dos sistemas.
A jornada começou por volta de 1970, no IBM 1130, com Assembler, RPG e Fortran. Depois veio a experiência com mainframes IBM, em que os sistemas eram organizados em programas, arquivos e dispositivos físicos, com Job Stream/JCL coordenando o processamento. A documentação e os fluxogramas faziam parte inseparável da construção dos sistemas.
A partir de aproximadamente 1985, o computador pessoal Intel 286/287 abriu outra etapa: DOS, Assembler, Basic, C, Clipper e Fortran, juntamente com o Framework III. Nesse ambiente surgiu a preocupação com a própria organização da produção de software e a ideia de “Automação da Engenharia de Software”.
Na década de 1990, a chegada do Windows e dos ambientes visuais trouxe CorelDraw e Visual Studio, com VB, VC e Visual FoxPro. O VFP tornou-se o principal ambiente de desenvolvimento pela possibilidade de controlar objetos, código e dados. Paralelamente, a LRG evoluiu para a LRGOOPT, utilizando a representação gráfica orientada a objetos no processo e no tempo para modelar processos industriais e administrativos.
A partir dos anos 2000, a Web introduziu outra transformação: ASP, depois PHP/MySQL, Dreamweaver e SQLyog, além da convivência com Visual FoxPro. Com a Internet, smartphones, tablets e computadores conectados, tornou-se possível pensar o software como uma rede de objetos, pessoas, dados, dispositivos e ações acessíveis por diferentes telas.
Na fase atual, a plataforma passou para Python, Django, SQLite, HTML, CSS e JavaScript, desenvolvida no VS Code. A experiência acumulada em mais de cinco décadas converge agora para a LRGOOSW — Linguagem de Representação Gráfica Orientada a Objetos para Software Web: uma tentativa de transportar para uma planilha a experiência arquitetural originalmente construída em desenhos, tornando a modelagem mais simples, rápida, barata, verificável e útil também para engenharia reversa e manutenção.
1. A origem: representar antes de programar
A ideia central da LRG nasceu da necessidade de compreender e representar um processo complexo antes de automatizá-lo. A primeira concepção não nasceu especificamente para aplicações Web. A arquitetura era pensada para grandes processos industriais, relacionando sensores, equipamentos, pessoas, comunicações e acontecimentos no processo. O desenho era o instrumento de representação: papel vegetal e cópias heliográficas. O princípio que atravessa toda a trajetória é simples e poderoso: conhecer e estruturar o funcionamento do sistema antes de construir ou modificar sua automação.
2. IBM 1130, mainframes e a primeira experiência de engenharia de software
IBM 1130
Início com Assembler, RPG e Fortran. A programação estava diretamente ligada à máquina, aos dispositivos e à organização física do processamento.
Ambiente IBM de grande porte
Experiência com mainframes, onde sistemas eram compostos por programas e o processamento era organizado por Job Stream/JCL. Cartões, impressoras, fitas e discos faziam parte da arquitetura operacional.
O sistema como conjunto organizado
Fluxogramas, documentação extensa e sequenciamento dos programas mostravam que programar um sistema grande significava também modelar seu funcionamento.
3. PC, DOS, Framework III e a ideia de “Automação”
A chegada do PC Intel 286/287 abriu uma nova fase. Vieram DOS, Assembler, Basic, C, Clipper, Fortran e o Framework III. Nesse ambiente surgiu a preocupação com a própria fabricação organizada do software: representar sistemas, controlar programas, linguagens, compilação e ligação. O Framework III foi utilizado como uma espécie de primeiro ambiente pessoal integrado de desenvolvimento. A experiência reforçou a ideia de que seria possível automatizar parte da própria engenharia de software. Entre os sistemas desenvolvidos ao longo dessa fase estiveram aplicações para engenharia elétrica, coordenação de projetos, bolsa de valores, loteria esportiva e acupuntura.
4. LRGOOPT: a arquitetura gráfica dos processos
A LRG foi criada na década de 1980. Na década de 1990, com a evolução do ambiente visual Windows, surgiu a LRGOOPT — Linguagem de Representação Gráfica Orientada a Objetos no Processo e no Tempo. A metodologia organizava a realidade em níveis, objetos, colaborações, mensagens e sequência temporal. Uma experiência marcante foi a representação de processos em grandes bases de distribuição de combustíveis. Com o CorelDraw, a representação gráfica tornou-se mais fácil de produzir e manter, e a metodologia também passou a registrar processos administrativos.
5. Web, Internet, smartphones e a transformação do problema
A Web introduziu uma mudança decisiva. O software deixou de estar confinado ao computador onde era executado. Uma aplicação passou a poder ser acionada por diferentes telas e dispositivos interligados pela rede. A trajetória passou por ASP, PHP/MySQL, Dreamweaver e SQLyog, mantendo durante anos a experiência acumulada com Visual FoxPro. A arquitetura começou a aproximar cada vez mais processo, interface, dados, rede e dispositivo.
6. Django/Python: uma nova plataforma de construção
Na fase mais recente, a plataforma passou a ser Python + Django + SQLite + HTML + CSS + JavaScript, com desenvolvimento no VS Code. Foi consolidada uma arquitetura Django com forte controle sobre o conjunto da aplicação e, posteriormente, um modelo de interface com template único e três colunas, adaptável a telas grandes e pequenas.
7. Da representação gráfica à representação matricial
A evolução tecnológica tornou possível substituir o grande desenho gráfico por uma planilha matricial, mais simples de preparar, revisar, manter e transportar. A intenção não é simplesmente documentar o software depois de pronto. A matriz deve servir como instrumento de engenharia: compreender o problema, estruturar o aplicativo, orientar o desenvolvimento e permitir posteriormente a engenharia reversa.
8. Representação Gráfica Orientada a Objetos para Software Web
O nome foi redefinido para: LRGOOSW — >A mudança explicita o objetivo atual: utilizar a experiência arquitetural da LRG para modelar o funcionamento de aplicações Web, especialmente aplicações Django. O antigo “Dicionário de Mensagens” passa a ser Dicionário de Dados. A intenção é manter uma relação direta 1:1 entre o models.py e o Dicionário de Dados, representando de maneira simplificada cada classe/tabela e seus campos, tipos, tamanhos e informações adicionais relevantes.
A página passa a ser observada por seus objetos de apresentação e interação. Entre eles: <a>, <button>, <select>, <table>, <thead>, <th>, <td>, <img>, <p>, <input> e outros definidos no modelo. Para permitir engenharia reversa e manutenção, a regra estabelecida é identificar os objetos por id ou name. O foco da planilha é o conjunto de objetos relevantes ao funcionamento do aplicativo; elementos do <head> e objetos fora do escopo definido são ignorados.
9. Bovespa: primeiro laboratório de engenharia reversa
O Aplicativo tornou-se o primeiro caso concreto para testar a LRGOOSW. O template apresenta três colunas funcionais: C1, C2 e C3.
| Área | Função predominante | Exemplos de objetos identificados |
|---|---|---|
| C1 | Grupos / histórico | p_grupos, i_grupos, grupos, th_grupos |
| C2 | Ativos / mercado | home, i_logo, wapp, ativos, th_ativos, ativo, valor, percentual, negocios, volume, acao |
| C3 | Carteira / alteração | p_carteira, i_carteira, carteira, th_carteira, a_altera, n_carteira, alteracao, f_id, f_B, f_QC, f_PC, f_DC, alterar |
O HTML atual já contém identificações explícitas nos objetos relevantes. Por exemplo, a coluna C1 contém objetos como p_grupos, i_grupos, grupos e th_grupos; C2 contém os objetos de navegação e ativos; C3 contém tabela, formulário, seleções, entradas e botão de alteração.
Engenharia reversa como teste da metodologia
A partir do aplicativo pronto, a LRGOOSW deve conseguir recuperar sua estrutura essencial. No sentido inverso, a matriz deverá ser capaz de servir como especificação para compreender, reconstruir e manter partes do aplicativo.
10. Princípios atualmente definidos de Desenvolvimento
- Modelar antes de programar o funcionamento do software Web.
- Representar o aplicativo por seus objetos de interface relevantes.
- Dar aos objetos identificação por id ou name.
- Organizar serviços/operações em linhas e objetos em colunas.
- Registrar os destinos possíveis decorrentes da interação com cada objeto.
- Manter o Dicionário de Dados diretamente relacionado às classes/tabelas do
models.py. - Não incluir o código interno das Views na matriz; a implementação permanece separada da representação arquitetural.
- Usar a engenharia reversa como instrumento de manutenção, reconstrução e redução do esforço futuro.
- Permitir tanto template único quanto aplicações com múltiplos templates.
- Manter a representação suficientemente simples para que a modelagem seja rápida, barata, verificável e facilmente atualizável.
O objetivo maior
A LRGOOSW pretende estabelecer uma ponte formal entre o problema real e o software Web que o executa.
E também permitir o caminho inverso:
A evolução da programação: Arquitetura de Software
As imagens abaixo foram incorporadas diretamente ao documento, tornando esta página autônoma quanto às imagens utilizadas nesta preservação das etapas do passado.
