Você está fazendo MDA (Model Driven Architecture) agora? Se sim, quais ferramentas você usa, e como é trabalhar fora?

Question

Architecture Model Driven é a idéia de que você criar modelos que expressam o problema que você precisa resolver de uma forma que é livre de qualquer (ou, no máximo, pelo menos) tecnologias de implementação, e então você gerar implementação para um ou mais específicos plataformas. A alegação é que trabalhando em um nível mais alto de abstração é muito mais poderoso e produtivo. Além disso, seus modelos sobreviver tecnologias (assim você ainda tem alguma coisa quando a sua primeira língua / plataforma torna-se obsoleto que você pode usar para a sua solução de próxima geração). Outro benefício importante reivindicada é que muito do clichê e "trabalho pesado" pode ser gerada. Uma vez que o computador entende a semântica da sua situação, ele pode ajudá-lo mais.

Alguns afirmam esta abordagem é 10 vezes mais produtivo, e que é o caminho todos nós estaremos construindo software em 10 anos.

No entanto, tudo isso é apenas teoria. Eu estou querendo saber o que os resultados são quando a borracha encontra a estrada. Além disso, a versão "oficial" do MDA é a partir do OMG , e parece muito pesado. É fortemente baseado em UML, o que pode ser considerado bom ou ruim dependendo de quem você perguntar (Estou inclinado para "ruim").

Mas, apesar dessas preocupações, é difícil argumentar com a idéia de trabalhar em um nível mais alto de abstração e "ensinar" o computador para compreender a semântica do seu problema e solução. Imagine uma série de modelos ER que simplesmente expressar a verdade, e então imaginar usando aqueles para gerar uma parte significativa de sua solução, pela primeira vez em um conjunto de tecnologias e, em seguida, novamente em um outro conjunto de tecnologias.

Assim, Eu adoraria ouvir de pessoas que realmente estão fazendo MDA agora ( "oficiais" ou não). Quais as ferramentas que você está usando? Como é trabalhar fora? Como grande parte da promessa teórica você tem sido capaz de capturar? Você vê um aumento real eficácia 10X?

Answer 1

Eu tentei uma vez. Aproximadamente a meio caminho através do projeto percebi que meus modelos eram irremediavelmente fora da data do meu código e foram tão complexo que mantê-los até à data era proibitivo e me atrasando.

O problema é que o software está cheia de casos de ponta. Modelos são ótimos em capturar a imagem maior, mas uma vez que você começar a realmente código de implementação que você mantenha encontrar todos aqueles casos de ponta e antes de muito tempo você notar que o modelo é muito granular e você tem que fazer uma escolha entre a manutenção do modelo ou ficar algum código escrito. Talvez a geração clichê é um benefício para o arranque, mas depois que os benefícios desaparecem rapidamente e eu descobri que eu tenho uma queda drástica na produtividade. Os modelos acabou por desaparecer desse projeto.

Answer 2

A falta de resposta a esta pergunta é um tanto sinistra ... talvez eu vou deixar campo que Dijkstra .

... Como os computadores apareceu em uma década quando a fé no progresso e salubridade da ciência e da tecnologia era praticamente ilimitado, ele pode ser sábio para lembrar que, tendo em vista dos seus objectivos originais, a humanidade é esforços científicos sobre, digamos, a últimos cinco séculos têm sido um fracasso espetacular.

Como você todos se lembram, a primeira e principal objetivo foi o desenvolvimento do Elixir que daria a um que bebeu Eterna Juventude. Mas desde não há muito sentido em eterna a pobreza, o mundo da ciência rapidamente embarcou em seu segundo projeto, viz. Pedra Filosofal que permitir que você faça o ouro tanto quanto você necessário.

...

A busca para a programação ideal linguagem e o homem-máquina ideal a interface que faria o software crise derreter como neve ao sol tinha -e ainda tem - todo o características da procura do Elixir ea Pedra. esta pesquisa recebe forte apoio de dois lados, em primeiro lugar a partir do fato de que o operação de milagres é o mínimo que você pode esperar de computadores, e em segundo lugar a partir da financeira e apoio político de uma sociedade que sempre pediu o Elixir e a Pedra em primeiro lugar.

Duas grandes fluxos podem ser distinguidos, a busca para a pedra ea busca para o Elixir.

A busca da Pedra é baseada em o pressuposto de que a nossa "programação ferramentas" são muito fracos. Um exemplo é a crença de que a programação atual línguas não possuem as "características" que precisamos. PL / I foi um dos mais espetacular Deseja-se pedras produzidas. eu ainda lembre-se o anúncio em Datamation de 1968, em que um sorridente Susie Mayer anuncia em cores que ela tenha resolvido todos os seus problemas de programação mudando para PL / I. Foi apenas muito previsível que, alguns anos mais tarde, pobre Susie Mayer não sorria. desnecessário quer dizer, a busca continuou e, no devido vez que um próximo candidato a pedra era produzido sob a forma de Ada (atrás Cortina de Ferro perceptivelmente referido como PL / II). Mesmo o mais elementar astrologia para iniciantes é suficiente para prevêem que Ada não será a última pedra deste tipo.

...

Outra série de pedras na forma de "ferramentas de programação" é produzido sob a bandeira do "software engenharia", que, como o passar do tempo, tem procurado substituir intelectual disciplina por disciplina de gestão de na medida em que já aceitou como sua carta "Como programar se você não pode ".

Answer 3

Eu estou fazendo minha própria pesquisa independente na área de Desenvolvimento de Software Model-Driven desde 1999. Eu finalmente desenvolveu uma metodologia de modelagem genérica em 2006 que eu rotulado ABSE (Atom-Based Software Engineering).

Assim, ABSE acumula-se em dois aspectos fundamentais:

• A programação é sobre decomposição do problema
• Tudo pode ser representado em uma árvore

Alguns ABSE características:

• Ele pode suportar todas as outras formas de engenharia de software, desde o tradicional métodos orientados a arquivo de até Desenvolvimento Baseado em Componentes, Programação Orientada a Aspectos, Modelagem específica de domínio, Software Product Lines e fábricas de software.

• É bastante genérico para ser aplicado ao software da empresa, incorporado, jogos, aviônicos, internet, qualquer domínio de fato.

• Você não precisa ser um cientista de foguetes para uso se de forma eficaz. ABSE é acessível para o "mero mortal desenvolvedor". Não há nenhuma complexidade como o encontrado em OAW / MDA / XMI / GMF / etc cadeias de ferramentas.

• A sua meta-metamodelo foi projetado para suportar 100% de geração de código do modelo. No round-trip necessário. O costume / mix código gerado é suportado diretamente pelo metamodelo.

• O modelo pode ser simultaneamente manipulada. Fluxos de trabalho e controle de versão pode ser aplicado (suporte ferramenta necessária).

Pode soar como é do lado utópico, mas na verdade eu deixei a fase de pesquisa e agora estou na fase de implementação de uma IDE que coloca todos os acima em prática. Acho que vou ter um protótipo básico pronto em algumas semanas (cerca de fim de abril). O IDE (nomeado AtomWeaver) está sendo construído através ABSE, então AtomWeaver será a primeira prova de conceito-da metodologia ABSE.

Então, isso não é MDA (felizmente!), Mas pelo menos é uma abordagem muito manejável. Como o inventor do ABSE, estou compreensivelmente animado sobre isso, mas tenho certeza de Desenvolvimento de Software vai ter um impulso em 2009 orientado por modelo!

Fique atento ...

Answer 4

Model-Driven Development Software é ainda uma área de nicho, mas não são publicados estudos de caso e um crescente corpo de outra literatura mostrando o sucesso sobre os métodos de mão-codificado.

MDA da OMG é apenas uma abordagem, outras pessoas estão mostrando sucesso usando Domain-Specific Languages ??(que não usam o UML para modelagem).

A chave é gerar o código a partir dos modelos e atualizar o seu gerador se ele não está gerando o que você quer - não modificar seu código. ferramental especializado para ajudá-lo a fazer isso já existe há anos, mas agora interesse nesta abordagem tem crescido ao longo dos últimos cinco anos ou mais, devido à movimentação da Microsoft para esta área e por meio de projetos open-source como openArchitectureWare do mundo Eclipse.

Eu corro um par de sites: www.modeldrivensoftware.net e www.codegeneration.net onde você pode obter mais discussão, entrevistas, artigos e opções de ferramentas sobre estes temas.

Answer 5

Eu comecei a trabalhar com tecnologias e DSLs baseadas em modelos em 1997, e estou cada vez mais entusiasmado com MDE.

Posso testemunhar que chegar a mais 10 vezes produtividade (e talvez ainda mais ;-) é possível sob certas circunstâncias. Eu tenho implementado muitas fábricas de software baseadas em modelos que foram capazes de gerar software executável com modelos muito simples, a partir da camada de persistência para a camada de interface do usuário, associado à sua documentação técnica gerada.

Mas eu não seguem o padrão MDA por várias razões. A promessa MDA é a de expressar o seu software em um modelo PIM, e têm a capacidade de transformá-lo automaticamente em uma ou várias pilhas técnicos (PSMs).

Mas:

• que precisa para atingir várias pilhas técnicos na vida real? que precisa para atingir uma arquitetura única e bem definida?
• a magia do MDA está na transformação PIM> PSM, mas a transformação model2model de forma iterativa e incremental é difícil:
  • model2model é muito mais complicado do que model2text de implementar, depurar, manter.
  • como raramente é possível para gerar 100% de um software, os detalhes têm de ser adicionados ao modelo PSM resultante, e preservado transformação após a transformação. Isso significa que uma operação de mesclagem (3-way, para lembrar os detalhes adicionados). E quando se trata de modelos, a fusão gráfico de objetos é muito mais complicado que fusão textual (que funciona muito bem).
  • você tem que lidar com um modelo PSM (isto é um modelo que se parece muito perto de seu código-fonte gerado final). É interessante para o fornecedor ferramenta, desde geradores de código ready-to-use perfis PSM e associados podem ser vendidas e enviadas com a ferramenta MDA.

Eu defendo para as estratégias de MDE onde o PIM é um DSL que fala sobre sua arquitetura lógica (independentemente de qualquer pilha técnica), e gerar o código a partir deste PIM com um costume e gerador de código específico.

Pros:

• você não tem que lidar com um modelo PSM complexo e técnico. Você tem o seu código em vez.
• usando técnicas de DSL, o PIM é mais eficiente, sustentável, expressivo e fácil de interpretar por geradores de código e documentos. Modelos manter simples e precisa.
• torna a obrigação de definir suas necessidades e conceitos arquitectónicos muito cedo (uma vez que é o seu metamodelo PIM), independentemente de qualquer pilha técnico. Normalmente, é sobre a identificação de vários tipos de dados, serviços, componentes de interface do usuário, com a sua definição, capacidades e características (atributos, links para outros conceitos; ...).
• o código gerado atender às suas necessidades, uma vez que é costume. E você pode mantê-la ainda mais simples se o seu código gerado estende algum extra mantida manualmente classes do framework.
• você capitalizar o conhecimento de várias formas ortogonais:
  • modelos capitalizar a funcionalidades / negócios
  • geradores de código capitalizar as decisões de mapeamento técnicas de seus componentes de arquitetura lógica para uma pilha técnica particular.
  • o PIM DSL capitalizar uma definição de sua arquitetura lógica
• com a PIM-oriented lógico-arquitetura, é possível gerar todo o código técnico e outros arquivos não-código (configs, propriedades, ...). Os desenvolvedores podem concentrar-se na implementação de funcionalidades de negócios que não poderiam ser plenamente expressa com o modelo, e, geralmente, não têm de lidar com a pilha técnico mais.
• Mescla as operações são todas sobre arquivos de código fonte plana, e isso funciona muito bem.
• você ainda pode definir vários geradores de código se você segmentar várias pilhas técnicos.

Contras:

• você tem que implementar e manter seu próprio código específico e geradores de documentos
• em geral, para tirar o melhor da abordagem DSL, você tem que, emcolete em ferramental específico (validação do modelo, assistentes específicos, diálogos, menus, importação / exportação ...).
• quando a atualização / melhorar o seu DSL, às vezes você precisa migrar seus modelos. Normalmente, isso pode ser feito com algum código de migração descartável, ou manualmente (dependendo do impacto).
• todos estes contras exigem uma equipe de desenvolvimento específico com habilidades baseadas em modelos

Esta abordagem particular pode ser implementado em cima de um modelador UML extensível com perfis UML, ou com editores de modelos específicos (textual ou gráfica).

A grande diferença entre MDA e MDE pode ser resumido como:

• MDA é um conjunto de Geral ferramentas e linguagens de Propósito, proporcionando off-the-shelf perfis md e ferramentas para as necessidades de todos. Isto é perfeito para os fornecedores de ferramentas, mas eu suspeito que todos necessidades e contextos são diferentes.
• Com DSL específica MDE + e ferramentas, você precisa de alguns desenvolvedores baseadas em modelos qualificados suplementares que irão manter a sua fábrica de software personalizado (modelador, extensões Modeler, geradores ...), mas você capitalizar em todos os lugares e gerenciar muito simples-precise- modelos sustentáveis.

Há um tipo de conflito de interesses entre as duas abordagens. Uma defende a reutilização de off-the-shelf componentes baseadas em modelos precapitalized, e no outro, você faz sua própria capitalização com a definição de DSLs e ferramentas associadas.

Answer 6

Nós usamos MDA e EMF como ferramentas. Ele nos salva um monte de homens-hora através da geração de código em vez de codificação manual. Ele requer alta qualificação de análise, mas é o que se trata. Por isso, concentra-se principalmente na própria problemas e também ferramentas / frameworks que fazem a geração de código e run-time apoio do código gerado. Finalmente, posso confirmar que nós temos 10x aumento de produtividade com MDA.