Você usa MDA/MDD/MDSD, algum tipo de abordagem baseada em modelo?Será o futuro?

StackOverflow https://stackoverflow.com/questions/21091

  •  09-06-2019
  •  | 
  •  

Pergunta

As linguagens de programação tiveram vários passos (r)evolutivos em sua história.Algumas pessoas argumentam que as abordagens baseadas em modelos serão a próxima grande novidade.Existem ferramentas como openArchitectureWare, AndroMDA, Sculptor/Fornax Platform etc.que prometem aumentos incríveis de produtividade.No entanto, percebi que ou é bastante fácil começar no início, mas também ficar preso em algum ponto quando você tenta algo imprevisto ou é muito difícil encontrar informações suficientes que lhe digam como iniciar seu projeto porque pode haver muitas coisas a considerar.

Eu acho que um insight importante para tirar alguma coisa de algo orientado por modelo é entender que o modelo não é necessariamente um conjunto de belas imagens ou modelo de árvore ou UML, mas pode muito bem ser uma descrição textual (por exemplo,uma máquina de estado, regras de negócios, etc.).

O que você pensa e o que sua experiência lhe diz?Existe um futuro para o desenvolvimento orientado por modelos (ou como você quiser chamá-lo)?

Atualizar: Não parece haver muito interesse neste tópico.Por favor, deixe-me saber se você tem alguma experiência (boa ou ruim) com abordagens baseadas em modelos ou por que você acha que não é nada interessante.

Foi útil?

Solução

Acho que vai levar algum tempo até que as ferramentas fiquem mais refinadas e mais pessoas ganhem experiência com MDD.No momento, se você quiser tirar algo do MDD, terá que investir bastante, então seu uso permanece limitado.

Olhando para openArchitectureWare, por exemplo:Embora seja bastante robusto e exista documentação básica, falta documentação sobre o funcionamento interno e ainda há problemas de escalabilidade, que não estão documentados - talvez isso melhore quando o Xtext e o Xpand forem reescritos.

Mas desprezando essas limitações, a geração em si é bastante fácil com oAW, você pode navegar em seus modelos perfeitamente no Xtend e Xpand e combinando vários fluxos de trabalho em fluxos de trabalho maiores, você também pode fazer coisas muito complexas.Se necessário você pode recorrer ao Java, assim você tem uma flexibilidade muito grande no que pode fazer com seus modelos.Escrever sua própria DSL com Xtext em oAW também é feito rapidamente, mas você obtém seu metamodelo, um analisador e um editor muito bom basicamente de graça.Além disso, você pode obter seus modelos basicamente de qualquer lugar, por ex.um componente que pode converter um banco de dados em um metamodelo e modelos correspondentes podem ser escritos sem grande esforço.

Então, eu diria que o MDD ainda está crescendo, à medida que as ferramentas e a experiência com ele aumentam.Ele já pode ser utilizado com sucesso, se você tiver o conhecimento necessário e estiver pronto para implementá-lo em sua empresa.No final das contas, acho que é uma coisa muito boa, porque muito código cola (também conhecido como copiar e colar) pode e deve ser gerado.Fazer isso com o MDD é uma maneira muito boa e estruturada de fazer isso, que facilita a reutilização, na minha opinião.

Outras dicas

Isenção de responsabilidade:Sou desenvolvedor de aplicativos de negócios.A visão a seguir é certamente moldada por minhas experiências nas trincheiras da TI corporativa.Estou ciente de que existem outros domínios de desenvolvimento de software.Especialmente no desenvolvimento de sistemas industriais e/ou embarcados, o mundo pode parecer diferente.

Acho que o MDSD ainda está muito ligado à geração de código.

A geração de código só é útil quando seu código contém muito ruído e/ou é muito repetitivo.Em outras palavras, quando seu código não consegue focar principalmente na complexidade essencial, mas está poluído com complexidade acidental.

Na minha opinião a tendência nas plataformas e frameworks atuais é exatamente remover a complexidade acidental e deixar o código da aplicação focar na complexidade essencial.

Portanto, estas novas plataformas/estruturas tiram grande parte do vento das velas do movimento MDSD.

DSLs (textuais) são outra tendência que tenta permitir o foco exclusivo na complexidade essencial.Embora as DSLs possam ser usadas como fonte para geração de código, elas não estão vinculadas principalmente à geração de código.DSLs (especialmente DSLs internas) basicamente permitem que ele seja aberto para ser interpretado/executado em tempo de execução.[a geração de código em tempo de execução está em algum ponto intermediário].

Portanto, mesmo que as DSLs sejam frequentemente mencionadas junto com o MDSD, acho que elas são realmente uma alternativa ao MDSD.E dado o hype actual, eles também tiram o ímpeto do movimento MDSD.

Se você atingiu o objetivo de remover a complexidade acidental do seu código (eu sei que isso é fictício), então você chegou a um modelo textual do seu problema de negócios.Isto não pode ser mais simplificado!

Caixas e diagramas bonitos não oferecem outra simplificação ou elevação do nível de abstração!Eles podem ser bons para visualização, mas mesmo isso é questionável.Uma imagem nem sempre é a melhor representação para compreender a complexidade!

Além disso, o estado atual das ferramentas envolvidas no MDSD acrescenta outro nível de complexidade acidental (pense:sincronização, comparação/fusão, refatoração...) que basicamente anula o objetivo final da simplificação!

Veja o seguinte modelo ActiveRecord, como ilustração da minha teoria:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

Não creio que isto possa ser mais simplificado.Além disso, qualquer representação gráfica com caixas e linhas não seria uma simplificação e não ofereceria mais conveniência (pense em layout, refatoração, pesquisa, comparação...).

O desenvolvimento orientado a modelos já existe há muito tempo.

A mais bem-sucedida das primeiras tentativas foi a James Martins Integrated Engineering Facility, que ainda existe e é comercializada pela CA sob a marca nada legal "Coolgen".

Então, por que não conquistou o mundo se era tão bom?

Bem, essas ferramentas são boas para tornar as coisas simples mais simples, mas não tornam as coisas difíceis mais fáceis e, em muitos casos, tornam as coisas difíceis mais difíceis!

Você pode passar horas tentando persuadir uma linguagem de modelagem gráfica 4GL a "fazer a coisa certa" quando sabe que codificar a coisa certa em Java/C/SQL ou qualquer outra coisa seria trivial.

Acho que talvez não haja uma resposta definitiva – daí a falta de “interesse” nesta questão.

Mas pessoalmente tive experiências mistas com o MDA.A única vez que foi uma boa experiência foi com ótimas ferramentas - eu costumava usar o TogetherSoft (acredito que de alguma forma eles acabaram na Borland) - eles foram um dos primeiros a introduzir a edição que não era "geração de código", mas sim edição do código/ model diretamente (para que você pudesse editar o código ou o modelo, era tudo uma coisa).Eles também tiveram refatoração (que foi a primeira vez que me lembro disso após ambientes de smalltalk).

Desde aquela época, não vi mais o MDA crescer em popularidade, pelo menos no mainstream, então, em termos de popularidade, não parece ser o futuro (então esse é o tipo de resposta).

É claro que popularidade não é tudo, e as coisas tendem a voltar, mas por enquanto acho que as ferramentas MDA+ são vistas por muitos como ferramentas de "geração de código baseada em assistente" (independentemente do que realmente sejam), então eu acho que levará algum tempo ou talvez nunca até que realmente decole.

Um dos problemas do MDD é que, por funcionar em um nível de abstração superior, requer desenvolvedores que possam subir também no nível de abstração.Isso reduz muito o universo de desenvolvedores que conseguem entender e utilizar tais metodologias.

Por favor, deixe-me saber se você tem alguma experiência (boa ou ruim) com abordagens baseadas em modelos ou por que você acha que não é nada interessante.

Acho que os contribuidores aqui fazem parte do campo "No Silver Bullet" (eu definitivamente faço).Se o MDA funcionasse (equivale a “enormes poupanças”), saberíamos disso, isso é certo.A questão é:até onde "meta" você pode ir enquanto mantém seu sistema gerenciável?Este foi o ponto de viragem na UML 2.0 quando introduziram um meta-metamodelo mais formal.Até agora, não vi um uso real do poder de modelização da UML 2.0 (mas meu mundo é bastante limitado).Além disso, você tem apenas duas opções com uma abordagem baseada em modelo:gerar código ou ter um tempo de execução explorando seu modelo.O gerador de código livre de restrições definitivo é chamado de "humano", enquanto os tempos de execução finais são encontrados nos 4GLs (qual é o número atual hoje em dia?).Talvez isso explicasse a falta de entusiasmo.

Nós, da itemis (www.itemis.com), usamos muito o desenvolvimento de software orientado a modelos.Até agora tivemos experiências muito boas.Shure, não é uma solução mágica, mas ajuda a melhorar a qualidade do software e, portanto, mais uso para nossos clientes.

O Desenvolvimento Orientado a Modelos será o futuro se, e somente se, os modelos que ele usa puderem ser tão flexíveis quanto escrever o código que deveria gerar.Acho que a razão pela qual não está indo tão bem agora é que é difícil fazer o mesmo "ida e volta" que as linguagens de programação baseadas em texto vêm fazendo há décadas.

Com linguagens de programação baseadas em texto, alterar o modelo é tão simples quanto alterar algumas linhas de código.Com uma linguagem de programação gráfica (também conhecida como diagrama MDD como UML), você precisa encontrar uma maneira de traduzir esse modelo de volta ao seu equivalente baseado em texto (que já era expressivamente eficiente em primeiro lugar) e pode ser muito, muito bagunçado.

IMHO, a única maneira pela qual o MDD pode ser útil se for construído desde o início para ser tão expressivo e flexível quanto sua contraparte baseada em texto.A tentativa de usar linguagens de design gráfico descendentes existentes (como UML) para ferramentas que são inerentemente construídas de baixo para cima usando abstrações em camadas (como linguagens de programação) representa uma enorme incompatibilidade de impedância.Não consigo definir o que é, mas ainda falta algo no MDD que o tornaria tão útil quanto as pessoas afirmam que é ...

Esta é uma resposta muito tardia, mas atualmente estou procurando ferramentas MDD para substituir o Rose RT, que infelizmente está sendo suplantado pelo Rhapsody.Estamos no espaço C++ incorporado e distribuído em tempo real e aproveitamos MUITO o MDD.Estamos tentando avançar para uma ferramenta melhor e difundir seu uso em nossa grande empresa.É uma batalha difícil por causa de algumas das boas razões mencionadas aqui.

Penso no MDD apenas um nível acima do compilador, assim como o compilador está acima do assembly.Quero uma ferramenta que me permita, como arquiteto, desenvolver a estrutura do aplicativo e editar extensivamente a geração de código (scripts) para usar essa estrutura e qualquer middleware que estivermos usando para passagem de mensagens.Quero que os desenvolvedores criem classes UML completas e diagramas de estado que incluam todo o código necessário para gerar o aplicativo e/ou biblioteca.

É verdade que você pode fazer qualquer coisa com código, mas eu resumiria aproximadamente os benefícios do MDD assim:

  1. Algumas pessoas criam a estrutura do aplicativo, os adaptadores de middleware e os colam na ferramenta MDD.Eles constroem a “casa”.
  2. Outras pessoas criam classes completas, diagramas e códigos de transição de máquinas de estado.Isso permite que eles se concentrem no aplicativo e não na "casa".
  3. É fácil ver quando as pessoas têm um design estranho, já que o diagrama é o código.Não temos todos os desenvolvedores especialistas e é bom trazer os juniores dessa forma.
  4. Principalmente é o código de máquina de estado desagradável que pode acontecer em algo como um projeto de robótica móvel.Quero que as pessoas façam diagramas de estado que eu possa entender, criticar e trabalhar neles.
  5. Você também pode ter uma boa refatoração, como arrastar operações e atributos para cadeias de herança ou para outras classes, etc.Eu gosto mais disso do que vasculhar arquivos.

Enquanto digito isso, percebo que você pode fazer tudo em código.Eu gosto de uma ferramenta fina colocada sobre o código para impor uniformidade, documentar o design e permitir uma refatoração um pouco mais fácil.

O principal problema que encontro e para o qual não tenho uma boa resposta é que não existe um conjunto padrão de funcionalidade e formato de arquivo para esses modelos.As pessoas se preocupam com a possibilidade de o fornecedor ir embora e depois ficar preso.(Isso basicamente aconteceu com Rose RT.) Você não tem isso com o código-fonte.No entanto, você teria a versão mais recente da ferramenta e o código do curso gerado por último :).Estou disposto a apostar que o benefício supera o risco.

Ainda não encontrei uma ferramenta como essa, mas estou tentando fazer com que alguns fornecedores me ouçam e talvez aceitem dinheiro para que isso aconteça.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top