Idiomas da Composição Arquitetural

5

Recentemente deparei com este artigo (PDF) falando sobre ACLs ou Arquitetura Idiomas de Composição. Eles são uma fusão de duas linhas de pesquisa anteriores: Linguagens de definição arquitetônica (como UML) e Linguagens de composição de objetos (como XAML, WWF ou linguagens de script).

O objetivo de uma ACL é ter uma descrição de alto nível da arquitetura de um programa, que também pode ser compilada em um programa executável. A descrição de alto nível auxilia na análise automatizada, enquanto a 'executabilidade' significa que as alterações podem ser testadas imediatamente.

Você ainda criaria os componentes do programa em uma linguagem de programação convencional (C, Java, Python, etc), mas eles seriam compostos em um programa completo pela ACL. Um dos benefícios esperados é que um programa pode ser transferido para uma plataforma diferente, trocando componentes "semelhantes, mas diferentes".

Eu tenho ansiado por algo assim há muito tempo (veja essa resposta eu dei em uma questão do StackOverflow alguns anos atrás).

O artigo menciona que os pesquisadores estavam trabalhando em uma linguagem chamada ACL / 1 que inicialmente visava o Java, mas seria portada para suportar também o .Net. No entanto, não consigo encontrar mais menção ao ACL / 1 em qualquer lugar. Houve mais algum trabalho feito sobre isso? Existem outras implementações do conceito de ACL disponíveis para uso ou experimentação?

    
por Chris Wenham 28.02.2011 / 18:27
fonte

1 resposta

2

Embora eu possa ver o benefício, não sou muito fã dessas linguagens abstratas. Eles tendem a fornecer principalmente uma boa solução genérica para um problema muito específico, arrendar os que eu vi. Eu acredito que eles não podem se tornar uma realidade tanto quanto eu acredito que arquitetos podem criar arquiteturas ricas e complexas usando nada além de um processador de texto.

Dito isto, acredito que será possível compor sistemas complexos a partir de blocos de construção já feitos. De certa forma, este dia já está aqui, alguns inventaram sua própria linguagem específica e funciona ... um pouco, desde que o aplicativo alvo permaneça no domínio da primeira aplicação da qual o framework foi derivado.

Problemas que podem ser resolvidos pela programação são vastos e, como tal, para criar uma única linguagem que faz tudo, invariavelmente, torna-se insuportável. A idéia de ter uma linguagem de integração para ajudar diferentes sistemas a se comunicarem entre si é boa e definições de protocolos como SOAP, Rest, * RPC tentam alcançar exatamente isso. Alguns são strongs para as interações dinâmicas, mas fornecem pouco para lidar com a modelagem de dados, outros lidam com dados muito bem, mas são fracos para lidar com as interconexões, outros ainda descreverão com precisão o comportamento esperado de um sistema, dando pouca ou nenhuma percepção de como Deve ser feito. Eu acho que o meu ponto aqui é que há sempre uma troca para fazer em algum lugar que irá mover o quadro um pouco mais abaixo no caminho da especialização. Junte isso à vasta diversidade de domínios e aplicativos, torna-se impossível antecipar todos eles para criar uma visão unificada de como uma arquitetura deve ser expressa. Uma arquitetura de software é muito mais do que uma definição estática de componentes que interagem e é aí que a maioria das ACL até hoje falha miseravelmente.

Uma abordagem melhor A IMHO seria criar um modelo aberto e vagamente definido para expressar a capacidade de um componente de forma programaticamente detectável. Um bom exemplo disso seria um moderno editor de GUI. A maioria permitirá a criação de novos componentes que incluem algum tipo de recurso declarativo que o editor pode usar para expor automaticamente o novo componente para futuras composições. A maioria dos editores de GUI atuais se destacam na composição de widgets, mas oferecem muito pouco para expressar as interações dinâmicas desses componentes.

A arquitetura baseada em agentes tentou lidar com esse problema, mas com pouco sucesso. Eu acho que eles estavam à frente de seu tempo, já que a comunicação era um componente central das comunidades de agentes, mas os protocolos e ferramentas para suportar essa riqueza de comunicação ainda estavam por ser projetados.

Até onde sei, a melhor tentativa atual para isso seria Spring Roo . Embora seja específico de linguagem (Java), ele tenta reunir componentes de alto nível separados em um único modelo de arquitetura.

A expressão da arquitetura de um sistema de software é relativa ao seu ponto de vista; A expressão deste ponto de vista conduzirá invariavelmente a uma redução da informação. A expressão de todas as dimensões de uma arquitetura de software é encontrada no código-fonte, mas para "vê-las" é necessário um grande esforço.

Como argumento de encerramento, acho que a criação dessa linguagem está sujeita ao princípio da incerteza de Heisenberg aplicado ao software, quanto mais precisamente você representa um aspecto do sistema, mais você perde os outros aspectos.

meu 2 cent ... pelo que vale a pena com as taxas de mudança nos dias de hoje ...

    
por 02.03.2011 / 07:54
fonte