Um artigo publicado no Stack Overflow Blog propõe repensar o conceito de programação orientada por modelos (Model Oriented Programming), como uma direção capaz de separar os requisitos do sistema de seu projeto de software e, em seguida, usar o próprio modelo para ajudar a criar e manter o sistema. O autor baseia-se em uma experiência anterior na qual, há 13 anos, desenvolveu uma linguagem e um ambiente de desenvolvimento chamados Mo+, que, segundo ele, utilizou em projetos empresariais, sem que a ideia se disseminasse amplamente.
O material não é um anúncio de uma linguagem disponível nem de um novo projeto de pesquisa, mas uma tese que defende mais pesquisa e desenvolvimento nessa área, especialmente em um contexto no qual a importância da inteligência artificial e a complexidade dos sistemas de software estão aumentando.
O modelo como estrutura e dados
O autor propõe definir o modelo por meio de dois elementos: uma estrutura que determina as regras ou o esquema, e dados que seguem essa estrutura. A estrutura é hierárquica, começa com um nó raiz e se ramifica em nós e propriedades, com a possibilidade de uma propriedade fazer referência a outro nó quando necessário. Nessa perspectiva, um esquema de banco de dados relacional pode ser representado na forma de uma hierarquia que inclui nós como banco de dados, tabela, coluna e chave, mesmo que os próprios dados estejam distribuídos em linhas e relações.
O artigo usa um cenário simplificado de restaurantes para explicar a ideia, incluindo restaurantes, clientes, funcionários, itens do menu e as relações entre eles. Ele apresenta mais de uma estrutura possível para representar o mesmo cenário, explicando que a escolha da estrutura afeta a facilidade de percorrer o modelo e a forma de escrever os programas que dependem dele.
Quatro formas de desenvolvimento orientado por modelos
- Modelagem informal: modelos na mente, no papel ou em diagramas que não são usados diretamente por ferramentas de software.
- Modelagem incorporada: um modelo dentro do código, como nos frameworks de ORM, como Entity Framework e NHibernate, ou em frameworks de interface do usuário, como Angular e React.
- Modelagem acoplada: um modelo externo, geralmente usando UML, fortemente vinculado aos elementos do código e às ferramentas de gerenciamento desses elementos.
- Modelagem separada: um modelo que se concentra nos requisitos, nos dados e no fluxo de trabalho, deixando o projeto detalhado para o código, de modo que cada elemento do modelo não esteja vinculado a um componente específico de software.
O autor considera que as maiores possibilidades estão na modelagem acoplada e na separada, especialmente na última, porque ela coloca os requisitos no modelo e o projeto no código, uma separação que, segundo sua experiência pessoal, tornou o processo de modelagem e programação mais fluido.
Do modelo ao sistema
O artigo divide o uso da programação orientada por modelos em três áreas. No modo de transição, o programa interpreta o modelo e produz código-fonte, arquivos de configuração ou documentação que podem ser desenvolvidos posteriormente. No modo de modelagem de modelos, a linguagem ajuda a criar e manter a estrutura e os dados do modelo. Já no modo de destino, a linguagem é usada diretamente para construir e gerenciar o ambiente do sistema, o que exige uma linguagem mais completa.
Recursos da linguagem proposta
A principal proposta é tornar a estrutura do modelo parte da gramática da linguagem, de modo que seja possível lidar diretamente com nós como Entity, Property e Relationship, em vez de criar classes e objetos específicos para representá-los. O autor também propõe um contexto orientado por modelos que depende da localização do programa dentro da árvore de dados, com uma pilha que permite subir para os nós-pai ou descer até os elementos filhos e pesquisá-los.
Outra ideia aparece nas «propriedades orientadas por modelos», que são partes independentes do código vinculadas a um determinado tipo de nó e que podem ser avaliadas em várias instâncias. Essas propriedades podem ser compostas para produzir código, como criar a definição de uma classe ou de suas propriedades, ou ser usadas em operações de pesquisa e filtragem. No modo de transição, a propriedade pode incluir uma operação put para salvar o resultado em um arquivo ou ambiente de destino.
O autor também propõe regras dinâmicas nas quais o interpretador adiciona os nós e as propriedades do modelo à gramática da linguagem no início de uma sessão de programação. Isso é útil quando o modelo padrão não contém informações suficientes ou quando o modelo é específico de uma organização ou área. Ele também apresenta regras contextuais que limitam as operações permitidas em diferentes partes do programa, para reduzir efeitos colaterais e separar as responsabilidades de leitura e escrita.
Por que essa proposta é importante?
O valor prático da ideia está na tentativa de tornar o modelo executável, e não apenas um documento de projeto separado do ciclo de desenvolvimento. Se for possível vincular requisitos, dados e fluxo de trabalho a mecanismos reutilizáveis de geração e manutenção, a repetição entre o modelo e o código poderá ser reduzida. No entanto, o artigo não apresenta uma linguagem padrão, ferramentas disponíveis nem resultados comparativos que comprovem a superioridade dessa abordagem em relação aos atuais frameworks de modelagem e geração de código.
Continuam em aberto questões importantes: como modelos grandes e mutáveis serão gerenciados? Como o código gerado será testado? E quais são os limites das regras dinâmicas em termos de legibilidade, segurança e integração com ferramentas de desenvolvimento? Por isso, o material parece ser um convite de pesquisa valioso para desenvolvedores de linguagens e pesquisadores, mais do que uma solução pronta para uso imediato.