Por que ainda não estamos todos desenvolvendo o modelo? [fechadas]

Eu acredito muito no desenvolvimento orientado a modelos, acho que tem a possibilidade de aumentar a produtividade, a qualidade e a previsibilidade. Ao olhar para o MetaEdit, os resultados são surpreendentes. Mendix na Holanda está crescendo muito, muito rápido e tem ótimos resultados.

Eu também sei que existem muitos problemas

• versionamento de geradores, modelos e estrutura
• projetos que não são adequados para o desenvolvimento orientado a modelos (repetição insuficiente)
• riscos mais altos (quando o primeiro projeto falha, você tem menos resultados do que teria com o desenvolvimento mais tradicional)
• etc

Mas ainda assim esses problemas parecem solucionáveis ​​e os benefícios devem superar o esforço necessário.

Pergunta : Quais são os maiores problemas que fazem você nem considerar o desenvolvimento orientado a modelos?

Quero usar essas respostas não apenas para meu próprio entendimento, mas também como uma possível fonte para uma série de artigos internos que pretendo escrever.

Não há martelo de ouro. O que funciona bem em um domínio é bastante inútil em outro. Existe alguma complexidade inerente ao desenvolvimento de software, e nenhuma ferramenta mágica irá removê-lo.

Pode-se argumentar também que a geração de código só é útil se a própria linguagem (ou a estrutura) não for de alto nível o suficiente para permitir abstrações poderosas que tornariam o MDD relativamente inútil.

Pergunta interessante! Admito que não sou fã, mas tentei usar o desenvolvimento orientado a modelos várias vezes em projetos que se encaixam em alguns dos problemas que você acabou de levantar.

Aqui está minha lista de motivos:

• curva de aprendizado - as ferramentas de modelagem estão evoluindo tão rapidamente, que tenho dificuldade em encontrar engenheiros que entendam profundamente a ferramenta. Ainda acho que você é tão bom quanto sua ferramenta de modelagem. É certo que muitos dos problemas abaixo podem rastrear esse problema - sempre que você acha que uma ferramenta é muito limitadora, é possível que não a conheça bem.
• Estruturado demais - Pessoalmente, estive em situações em que descobri que a ferramenta de modelagem era simplesmente estruturada demais para permitir que eu descrevesse tudo o que precisava para descrever. E uma vez que passei a desenhar algumas partes do modelo fora da ferramenta, as coisas decaem rapidamente quando as pessoas começam a se desviar para fora da ferramenta para encontrar as informações.
• Custo do ajuste da ferramenta - toda vez que tentei gerar automaticamente o código, acabei refazendo o código manualmente depois de ver o que a ferramenta pensava ser correta. Sei que, depois de algumas voltas, esse problema diminui, mas isso significa que você precisa sobreviver às primeiras voltas. Eu geralmente senti que estávamos tocando um toupeira - faça modelo -> gere código -> corrija código -> atualize modelo -> corrija modelo, enxágue e repita.
• Gerenciamento de configuração do modelo - como o modelo descreve grandes partes do projeto, em algum nível o modelo CM será mais transversal que o código criado. A compartimentação dos arquivos de modelagem é uma arte em si mesma - faça algo errado e muitas vezes você acaba com o impasse do desenvolvedor ou com modelos desatualizados à medida que as pessoas desistem e seguem o código.
• tempo de colocação no mercado - tive problemas definitivos quando em uma situação em que a necessidade de trabalhar com software era urgente. Se o projeto e a equipe forem pequenos o suficiente, não vejo razão para perder tempo com uma ferramenta de modelagem quando o tempo pode ser gasto em codificação e teste. Nem todo projeto é grande o suficiente para exigir esse investimento.
• Custo da falha - quando vi projetos fugir das ferramentas de modelagem, é por causa do alto custo da falha - para usar as ferramentas, é necessário que todos os desenvolvedores estejam envolvidos. É um grande investimento em treinamento e aprendizado prático, e um erro muito caro se alguém configurou mal o modelo. Minha experiência é que são necessários dois ou três lançamentos para acertar o modelo - muitos projetos não sobrevivem a erros de modelagem por tempo suficiente para obter os benefícios.

Já foi citado, mas o No Silver Bullet aborda bem o assunto:

A essência de uma entidade de software é uma construção de conceitos interligados: conjuntos de dados, relacionamentos entre itens de dados, algoritmos e invocações de funções. Essa essência é abstrata, pois esse construto conceitual é o mesmo em muitas representações diferentes. No entanto, é altamente preciso e ricamente detalhado.

Acredito que a parte mais difícil da construção de software seja a especificação, o design e o teste dessa construção conceitual, não o trabalho de representá-lo e testar a fidelidade da representação. Ainda cometemos erros de sintaxe, com certeza; mas eles são imprecisos em comparação com os erros conceituais na maioria dos sistemas.

Se isso for verdade, a criação de software sempre será difícil. Não existe inerentemente nenhuma bala de prata.

Mais tarde, Brooks aponta o seguinte sobre o conceito de "programação automática":

Por quase 40 anos, as pessoas esperavam e escreviam sobre "programação automática" ou a geração de um programa para resolver um problema a partir de uma declaração das especificações do problema. Hoje em dia, alguns escrevem como se esperassem que essa tecnologia proporcionasse o próximo avanço.

Parnas implica que o termo é usado para glamour, não para conteúdo semântico, afirmando: "Em resumo, a programação automática sempre foi um eufemismo para a programação com uma linguagem de nível superior ao que estava atualmente disponível para o programador".

Ele argumenta, em essência, que na maioria dos casos é o método da solução, não o problema, cuja especificação deve ser dada.

Basicamente, eu argumentaria que o MDD é apenas mais um eufemismo para a programação com uma linguagem de nível superior ao anteriormente disponível.

Isso não quer dizer que a programação em uma linguagem de nível superior não possa ajudar - na verdade, muitas vezes pode. Mas a essência do problema permanece a mesma: não importa o tamanho da ferramenta ou o idioma que você esteja usando, no final do dia você precisará pensar em todos os problemas e resolver os problemas. O melhor que qualquer ferramenta ou processo pode fazer é remover o "fuzz" para que você possa se concentrar na questão importante, que é, como disse Brooks, "a especificação , o design e o teste dessa construção conceitual ".

Porque nem toda a programação é orientada a objetos, o que todas as ferramentas MDD parecem esperar. A própria UML é baseada na presunção de objetos. Claro que você pode usar diagramas de seqüência para modelar funções, mas muitas vezes isso é desajeitado.

Porque existem programadores como eu que obtêm mais progresso e resultados do TDD do que do MDD.

Porque Modelagem! = Programação.

Porque o custo / benefício era muito alto no lado do custo e insuficiente no lado do benefício. Provavelmente, isso mudou desde a última vez em que analisei o MDD; naquela época, você deveria pagar> US $ 6000 / assento (USD) por uma ferramenta que seria moderadamente capaz do MDD.

Como um modelo que descreve suficientemente uma função para gerar o código não é mais útil como modelo.

Porque existem programadores como eu que usam apenas modelos em um nível alto e depois trabalham os detalhes com o código. Você vê as coisas de maneira diferente no código e no software de modelagem.

Essas são algumas das razões pelas quais eu pessoalmente não pratico MDD. Fui exposto a isso, mas nada foi capaz de me converter. Talvez eu seja muito velha escola. Talvez eu seja uma escola muito nova (seja lá o que for). Não é apenas uma ferramenta que eu consegui pagar por si mesma.

Microsoft / Apple / Google não está pressionando :)

Que tipo de desenvolvimento é popularizado tem muito a ver com ferramentas, apoio e evangelismo. É muito difícil romper com algo sem ter um grande apoio (o Ruby on rails talvez seja a exceção, mas ainda é pequeno comparado ao Java / C # / Python)

Por causa de uma lei simples que afetou todas essas ferramentas de modelagem, CASE, UML e outras:

Ficar entre um programador e seu código é muito caro.

Se você fizer isso, precisará criar um compilador / intérprete adequado; os geradores de código resultarão em um fluxo de trabalho terrível e um feedback terrível para o programador (mensagens de erro e outras).

Uma das grandes idéias do Design Orientado a Domínio é que os Modelos devem estar no código, não em algo externo ao código.

Por fim, a pergunta é: por que seus modelos não se encaixam no código? Se você está desenvolvendo um desenvolvimento incorporado e está preso ao C ou precisa gerar código para plataformas diferentes, a geração de código pode valer o custo. Para todos os outros, uma linguagem de programação mais poderosa e um melhor design de código geralmente são melhores do que projetar o código em algo diferente do código.

• Parece um aborrecimento gigantesco para pouquíssimo benefício.
• Eu sempre pareço estar brincando com casos extremos e coisas estranhas, o material mágico nunca parece realmente funcionar direito.
• OO não é uma bala de prata; jogar uma metodologia de geração de software no OO não o torna prateado.

Mas não gosto de soluções empresariais em geral.

Eu tive a discussão e adoraria fazer o MDA, mas a maior desvantagem é o suporte de ferramentas por enquanto. Estou usando uma derivação do MDA que gosto de chamar de "avaliação do modelo de tempo de execução", mas mais sobre isso mais tarde.

As desvantagens do MDA são, como eu sei:

• Suporte a refatoração ausente: vamos supor que eu queira modelar as entidades do meu modelo de dados com o MDA (Base de dados típica nº 1). Se eu tenho meu modelo, digamos, em um diagrama UML, e eu o altero, nada do meu código muda com ele (pelo menos as classes geradas) e, em vez de ainda ter um aplicativo em funcionamento com atributos melhor nomeados, recebo um muitos erros eu tenho que corrigir manualmente.
• Falta suporte à depuração: geralmente as traduções do modelo para o código são feitas tendo em mãos alguma linguagem de transformação. Isso normalmente não seria problema, mas quando depuramos, não devemos nos preocupar com o código que geramos, e um depurador deve entrar no modelo de transformação. Em vez disso, ele entra no código gerado e, como todos sabemos, as transformações devem ter uma boa aparência, não o código gerado. Okey, podemos imprimi-lo bastante, mas em um mundo ideal, o código gerado é um artefato do compilador e nunca deve ser aberto em um editor para uma sessão de depuração (eu poderia viver com ele, e esse argumento é um pouco teoricamente, mas é uma razão contra o MDA)
• Modelos codificados são fáceis: Em outros exemplos, o Modelo pode modelar algum aspecto do domínio e, em seguida, é compilado no código. Sim, é MDA, mas a maioria dos modelos MDA são apenas arquivos de configuração sofisticados, que podem ser facilmente manipulados em tempo de execução.
• É difícil testar as transformações: se você usar transformações em um IDE especializado, elas serão feitas pelo "compilador" dos IDEs. Mas as transformações devem ser vistas como parte do código do aplicativo e, como tal, também devem passar pelos requisitos de cobertura de teste e código do aplicativo.

No momento, o que eu prefiro é "Avaliação do Modelo de Tempo de Execução" (se alguém souber um nome aceito para isso, por favor me esclareça). Minhas entidades são armazenadas em classes Java comuns, e tudo o que preciso "modelar" é feito por anotações que li no início do aplicativo. Nenhuma transformação necessária, foi apenas um pouco difícil de acertar meu metamodelo.

Todo o resto é feito com arquivos de propriedades ou XML para dados hierárquicos. Se você tem um modelo, ele é sempre hierárquico; portanto, não há nada que você possa modelar que você também não possa expressar com XML. E se você precisar de um editor de modelo especial, que provavelmente precisará escrever também, também poderá criar um editor que funcione no tempo de execução do aplicativo e torne o aplicativo mais configurável do que tudo o que você poderia modelar.

Eu sinto que a maioria das pessoas que usam o No Silver Bullet de Fred Brooks para explicar por que as pessoas não estão fazendo MDD estão perdendo o ponto que Brooks faz. Certamente, a conclusão final é que a complexidade intrínseca real no desenvolvimento de software nunca desaparece e, portanto, o MDD não resolve isso.

Mas uma razão pela qual Brooks discute essa complexidade intrínseca é compará-la à grande quantidade de tempo que normalmente gastamos lutando com linguagens, bibliotecas e ferramentas, ou seja, não lidando com a complexidade intrínseca do problema que estamos tentando resolver. Portanto, é exatamente aqui que o MDD brilha: eliminando toda a confusão e criando uma linguagem, modelo ou outro formalismo personalizado para lidar com a complexidade real em questão.

Portanto, sob essa perspectiva, o No Silver Bullet é um excelente motivo para investir em MDD. Ou seja, se não fosse pelo problema que acredito dificultar a adoção do MDD: o desenvolvimento real de um ambiente orientado a modelos que permite que você se concentre completamente na complexidade intrínseca do problema que você está tentando resolver é muito mais difícil do que apenas resolvendo o problema diretamente em uma linguagem de propósito geral. Principalmente porque as ferramentas MDD existentes são extremamente complexas.

Compare assim: é muito mais fácil escrever um programa em C do que escrever um compilador C. Em vez de apenas resolver um problema e lidar com o cruft em uma linguagem de uso geral, criar um ambiente MDD para outros desenvolvedores exige que você basicamente escreva um programa que resolva todos os possíveis problemas relacionados ao cruft no espaço do problema. Isso é bastante desafiador.

Que eu saiba, MDE e MDA não atendem suficientemente às necessidades do desenvolvedor do controlador incorporado. Certamente, os modelos podem ser usados ​​para descrever um sistema, mas não acho que o desenvolvedor incorporado esteja pronto para confiar no modelo para fornecer o melhor ou até o código-fonte correto.

Existem vários plug-ins para o Eclipse que permitem que um desenvolvedor use o modelo para criar / atualizar o código Java ou o código Java para criar / atualizar o modelo. Parece uma ferramenta útil. Infelizmente, todo o meu desenvolvimento é feito em ANSI / ISO C, e não tenho nenhum plug-in, que eu saiba, que me permita fazer a mesma coisa.

Além disso, como um desenvolvedor pode instruir o modelo a implementar o código como um HSM orientado a eventos ou algum outro padrão de design sobre qualquer outro padrão de design (ou antipadrão)? Se o código for atualizado manualmente para usar um padrão de design desconhecido, o modelo pode descrevê-lo com precisão?

Como você implementa as funções que não se encaixam em um modelo?

Resposta curta ... porque o modelo orientado está frequentemente relacionado à geração de código e o código é frágil; o que precisamos é a eliminação do código e o direcionamento do modelo é certamente o caminho a percorrer.

Alguns descartaram a questão argumentando que não há martelo de ouro e que o desenvolvimento de software é inerentemente complexo.

Concordo plenamente com eles que não há martelo de ouro, mas não acho que esse modelo seja uma busca de martelos de ouro ou balas de prata!

Eu gostaria de ir mais longe com complexidade; existem dois tipos de complexidade, os quais chamo de complexidade orgânica ou natural, complexidade inerente ao negócio e a seus processos, mas também temos complexidade cerimonial.

Complexidade que se infiltra na instrução do sistema por instrução, dia após dia. A complexidade cerimonial - complexidade desnecessária - emerge essencialmente da manipulação descontrolada de código técnico com código orientado aos negócios, mas também da falta de estrutura e uniformidade no sistema.

Hoje, toda a complexidade que assombra o desenvolvimento de sistemas de informação e causa falhas e cintura é complexidade cerimonial; complexidade que pode ser eliminada.

A complexidade cerimonial é desperdício, desperdício causado pelo código, menos valor, alterar código invariante e adverso; código que deve ser reduzido ao mínimo estrito.

Como fazer isso? Fácil! Simplesmente não escreva e não gere, em primeiro lugar!

Código técnico necessário e invariável; código usado para leitura / gravação, exibição, comunicação ... É aí que os modelos entram, descrevendo a estrutura lógica dos dados - eu acrescentaria de maneira relacional - os modelos podem permitir o manuseio genérico da leitura / gravação padrão, exibição e comunicação de dados.

É como um sistema operacional, você não o reescreve para todos os projetos que usa. Portanto, o que é necessário é um mecanismo técnico que lide com aspectos invariantes de software, dado um modelo. Eu o chamo de mecanismo AaaS (Arquitetura como Serviço).

Quanto ao código desnecessário, é um código desnecessário, portanto, pode deixá-lo não escrito.

Isso nos deixa com o código necessário, orientado aos negócios, que deve ser escrito, os dados necessários, orientados aos negócios, que devem ser projetados e a interface do usuário necessária e a experiência que deve ser projetada e imaginada.

Ao eliminar o código frágil, podemos adotar a arquitetura como serviço, um novo paradigma para o desenvolvimento de software baseado muito mais em modelagem e design do que em código.

Acredito que existem várias razões, mas uma é certa que o MDD não consta do currículo das universidades. Normalmente, o mais próximo é um curso que ensina modelagem e os modelos permanecem como esboços (sem verificação, geração de código, depuração no nível do modelo). Esse curso de "modelagem" também apresenta a UML e os alunos ficam intrigados com o motivo de aprender uma notação tão grande e complexa quando o valor dos modelos criados é baixo.

Compare isso com outro campo da engenharia, como desenvolvedores de hardware embarcado ou engenheiros de controle, onde os alunos têm uma experiência bem diferente. Com ferramentas como Simulink ou Labview, os alunos podem desenhar um modelo e, em seguida, ele gera o código, ou pelo menos você pode executá-lo em simulação.

No passado, as universidades ensinavam compiladores e analisadores, mas agora deveriam ensinar como criar geradores, implementar DSLs etc.

O Desenvolvimento Orientado a Modelo não faz sentido, porque este é um modelo de cima para baixo para codificar a abordagem. É impossível criar um aplicativo em execução completo apenas a partir de um modelo e, portanto, o MDD é inútil!

O que faço é usar apenas a UML em um nível mais alto de abstração para criar o esqueleto do meu aplicativo. Quero dizer, criar pacotes, classes etc ... e começar imediatamente a codificar na linguagem Java.

Eu descobri que a sincronização ao vivo com ferramentas como Togethersoft, Omondo era realmente útil quando iniciei a modelagem pela primeira vez em 2004. Um novo estágio foi introduzido recentemente pelo Omondo, que é um tipo de mapeamento entre Java, modelo e ID do banco de dados. Realmente poderoso e funciona bem em meus projetos.

Meus diagramas UML me ajudam agora a acelerar meu projeto e não são mais inúteis :-)

O MDD adiciona outra etapa ao processo de desenvolvimento, que é uma desvantagem em situações em que não há um bom modelo e a primeira solução parcial imprevisível ou quase quebrada do mercado pode muito bem ganhar as bolas de gude.

Tem sido um problema ter modelos de processos de negócios executáveis. Em teoria, você não precisaria de programadores para isso. A prática mostra que, com o MDE, fazer com que o modelo real funcione é tão complicado quanto escrever código.

Eu diria que para um desenvolvedor experiente seria muito mais fácil preencher as classes geradas a partir de UML do que se preocupar com, por exemplo, ExecutableUML. Por outro lado, para o ExecutableUML, você precisa de uma quantidade significativa de conhecimento em ciência da computação, portanto não pode contar com o gerente de negócios criando isso sozinho. Em teoria, ele apenas combinava blocos prontos (classes), mas na verdade a "cola" é o que causa problemas.

Além disso, a utilidade do MDE é limitada a sistemas com muita reutilização de componentes.

MBSE - Engenharia de Software Baseada em Modelos é o termo mais pertinente.

Colocando o problema das várias ferramentas que são efetivamente soluções pontuais, o MBSE exige um fluxo de trabalho de projeto diferente. A DSML (linguagem de modelagem específica de domínio) precisa estar no nível de abstração necessário para comunicar efetivamente os requisitos para revisão com as partes interessadas. Então você precisa transformar o modelo através de níveis cada vez maiores de refinamento para eventualmente gerar código.

Quando você tem o DSML e os processos de transformação / geração totalmente e corretamente implementados, a geração de artefatos tem um custo muito baixo. Mas até chegar a esse estágio de ferramentas depuradas, é muito doloroso.

A maioria das histórias de sucesso do MDD está na área de Engenharia de Linha de Produto (PLE), onde uma sucessão de produtos similares é gerada usando ferramentas estabelecidas. Obviamente, muitos dos geradores de código Java são realmente versões simplificadas do MDD. Algum XML entra e gera código.

Você escreveu:

Sei também que existem muitos problemas ... projetos que não são adequados para o desenvolvimento orientado a modelos (repetição insuficiente)

Se o seu código for repetitivo, você escolheu uma linguagem de programação ruim ou está usando muito mal. Com idiomas melhores, não há necessidade de repetição. Considere a biblioteca do Ruby Active Record. As tabelas de banco de dados são criadas gravando migrações. Não há necessidade de repetir a definição do esquema em nenhum outro local. Você não precisa definir uma classe com membros de dados correspondentes às colunas da tabela. Uma única linha de código conecta uma classe a uma tabela.

Eu vejo o desenvolvimento orientado a modelos como uma solução alternativa complexa e ineficiente para linguagens de programação fracas.