O que exatamente é MDSE (Model driven Software Engineering)?

Hoje encontrei o acrônimo MDSE no infoq , e encontrei as informações que não eram claras e a descrição estava cheia de chavões:

O MDSE visa capacitar os engenheiros de software a trabalhar em um nível de abstração em que os requisitos, a arquitetura e as informações de design são maximamente ordenados (em termos de "entropia" de informações) e preservados. (Chame isso de "produto de trabalho de design"). Além disso, o MDSE deve fornecer aos engenheiros os meios para verificar e validar seus projetos, principalmente os termos de seu "produto de trabalho de design"

E, aparentemente, todo mundo está fazendo isso: (do artigo novamente)

Estamos no início da era do MDSE. Nos próximos 5 a 10 anos, veremos uma mudança significativa em direção ao MDSE, na medida em que acredito que até o final deste período, talvez 60 a 80% do software seja projetado usando técnicas baseadas em modelo.

Gostaria de ter uma descrição concreta e sem chavões do que é o MDSE. Está desenhando caixas UML e gerando código com ela, como fizeram nos anos 90 com o Rational Rose?

(enquanto estivermos nisso, se alguém tiver um exemplo de software gerado usando essas técnicas, eu realmente gostaria de ver um exemplo concreto).

"engenharia de software orientada a modelos (MDSE)" é a promessa de marketing dos fabricantes de ferramentas de software de que "em breve" partes significativas do software podem ser geradas a partir de modelos de software.

O parceiro de entrevista no artigo a que você está se referindo , Robert Howe é um fabricante de ferramentas (consulte http://www.verum.com/ para obter detalhes)

Mas, contra as promessas dos fabricantes de ferramentas, o mdse ainda não se tornou popular.

O sistema hybris internet shop é um exemplo prático de "MDSE": você, como desenvolvedor de software, mantém arquivos xml-model-files ("* -items.xml") e os codegenerators / intérpretes geram db-modell / java-code para persistência / guis fora disso. Se você precisar de um atributo adicional, adicione-o ao modelo xml e, após o trabalho do gerador / intérprete, você poderá usar o atributo para implementar a lógica de negócios.

O IMHO " orientado a modelos " é um grande exagero, especialmente quando usado em conjunto com chavões como "design" ou "engenharia de software" (em vez de "desenvolvimento"). Provavelmente foi inventado por algumas pessoas que têm a idéia errada de que "design de software" é feito desenhando alguns modelos gráficos com UML, como um arquiteto desenhando um plano para uma casa e "codificação" é como colocar tijolos para a casa, seguindo o modelo. (Espero não ter que explicar aqui por que isso está errado; se você tem uma opinião diferente, leia primeiro "Code as Design", de Jack Reeves, antes de me rebaixar.)

Esse é um ótimo modelo mental para as pessoas que se autodenominam "arquitetas", "analistas de negócios", "designers", "engenheiros de software", que estudaram cinco anos de ciência da computação, mas apenas meio ano de experiência real em programação (no máximo ) e agora procurando um emprego na indústria de software que inclua "projetar software" sem codificação. Eu acho que essa é a verdadeira razão pela qual essas chavões "orientadas a modelos" são tão populares.

Não me interpretem mal, sou um grande fã de modelos e geradores de código por reduzir a necessidade de escrever manualmente o código padrão. Em algumas áreas restritas como, por exemplo, bancos de dados, modelos (dados) podem ser realmente um bom instrumento para se comunicar com pessoas do domínio. Esboçar o fluxo de dados entre componentes por modelos é IMHO uma das técnicas mais importantes para inserir estrutura em um sistema de software (infelizmente, o pessoal da UML se esqueceu de incluir diagramas de fluxo de dados em suas notações; em vez disso, eles adicionaram várias coisas desnecessárias e redundantes que ninguém usa na prática).

Mas eu chamaria isso de " desenvolvimento de software suportado por modelos ", não " engenharia de software orientada a modelos ", que espero que fique claro que a modelagem apenas suporta as principais atividades em desenvolvimento, em vez de ser a principal atividade em si.

Isso me lembra muitos modelos Fat, conceito de controladores magros .
A idéia principal desse conceito é colocar o máximo possível da lógica de negócios no modelo e manter o controlador e uma visão muito simplistas.
Pessoalmente, acho essa uma idéia muito interessante, embora não tenha tido a chance de usá-la.
Surpreendentemente, 8 dos 10 principais links na pesquisa do Google falam contra ele.
Porém, se você pensa em um modelo não como uma classe única, mas como uma fachada de várias classes internas, faz todo sentido manter a lógica de negócios no modelo.