Galera comecei recentemente a pesquisar sobre MDA (Model Driven Architecture), achei um framework interessante, trata-se do AndroMDA http://www.andromda.org/. Gostaria de saber se alguem aqui no forum ja teve algum contato com ferramentas desse tipo. Estou batendo cabeça com o AndroMDA e com os proprios conceitos da MDA. Gostaria que este tópico, nos proporcionasse uma forma de trocar ideias e experiencias sobre a MDA. E se alguem usa ferramentas MDA, que compartilhe informações atraves de dicas ou quem sabe ate de tutoriais.
Não é um conceito fácil de digerir. As poucas vezes que tentei ler alguma documentação, introdução
no site do andromda acabei esbarrando em muita teoria MDA, muita configuração para executar
alguma coisa, pouco resultado, etc…
Dai vem a velha pergunta, vale a pena?
[quote]Não é um conceito fácil de digerir. As poucas vezes que tentei ler alguma documentação, introdução
no site do andromda acabei esbarrando em muita teoria MDA, muita configuração para executar
alguma coisa, pouco resultado, etc…
[/quote] Também esbarrei no mesmo problema. Quando achava que estava entendendo os conceitos da MDA, percebi que eu estava ficando mais confuso ainda!!! 
[quote]Dai vem a velha pergunta, vale a pena?[/quote] Essa é uma boa pergunta quando nos referimos a coisas relativamente novas. Corremos o risco de estudar uma coisa que pode não bombar no mundo de T.I, mas por outro lado temos que analisar e tirar as conclusões. Quando a orientação a Objetos surgiu foram poucos os que se aventuraram nessa nova empreitada, tanto que a OO se popularizou a pouco tempo. A Promessa da MDA é boa, e a promessa das ferramentas MDA é melhor ainda (espero que não fique só nas promessas ) . A ideia de gerar pedaços de código ou ate mesmo sistemas completos a partir de modelos (UML por exemplo) é muito atraente. Imagine o ganho em produtividade… é tentador! Por isso resolvi dar uma estudada. Mas ta dificil digerir!
Eu participo do desenvolvimento de um gerador aqui na empresa. Cenário clássico hein, toda
empresa tenta automatizar isso…
Já demos muito com a cabeça na parede nesta questão, mas atualmente estamos num estágio
razoável onde conseguimos gerar código que poupa algum tempo.
Sim, a ideia de gerar pedaços ou sistemas completos a partir de modelos UML é muito atraente…
e difícil, trabalhosa. E até hj não há uma solução redondinha que traz todas essas promessas do MDA.
Se vc encontrar, por favor compartilhe conosco 
E vao continuar batendo. Isso nao tem cabimento.
[quote=fabiofalci]
Sim, a ideia de gerar pedaços ou sistemas completos a partir de modelos UML é muito atraente…
e difícil, trabalhosa. E até hj não há uma solução redondinha que traz todas essas promessas do MDA.
Se vc encontrar, por favor compartilhe conosco [/quote]
Eu nao entendo esse tipo de pensamento. Por que diabos eu vou querer programar em UML e depois transformar em Java, se é muito mais facil, pratico, seguro, confiavel, escrever direto em Java (ou qqr outra linguagem)? UML nao é linguagem de programação, Java é. Se voce precisa da representaçao do código. Engenharia reversa nele, o contrário não funciona e nao vai funcionar tao cedo.
Ah, mas meus analistas nao sabem programar. Entao contrate uns que sabem.
Ah, mas meus analistas nao querem programar. Tem muita gente que nao quer, meu irmao, por exemplo, é contador.
Pra implementar qualquer coisa, antes é preciso pensar. Depois vai se implementar o resultado desse “pensamento”. Por que eu vou por esse resultado em um monte de bolinha e quadradinho, se eu tenho uma ferramenta adequada, largamente utilizada e adaptada a logica humana, chamad linguagem de programacao, pra fazer isso?
Concordo 100% contigo cara.
Quando coloquei ali a citação de que é atraente gerar, estava apenas traduzindo um
sentimento de quase todo diretor de TI que conheço!
Ou vc nunca viu esse filme? Alguém tentar vender para algum diretor uma ferramenta de
geração milagrosa? Os diretores não adoram isso?
[quote=fabiofalci]Concordo 100% contigo cara.
Quando coloquei ali a citação de que é atraente gerar, estava apenas traduzindo um
sentimento de quase todo diretor de TI que conheço!
Ou vc nunca viu esse filme? Alguém tentar vender para algum diretor uma ferramenta de
geração milagrosa? Os diretores não adoram isso?[/quote]
Adoram, eles sonham tanto com essas ferramentas quanto os industriais com os robos. Os robos ja sao uma realidade em muitas areas, o MDA vai demorar ainda.
editando so pra concluir:
Os gerentes e diretores sonham com essas ferramentas porque eles pensam que um dia vao apertar um bota e vai sair tudo funcionando como eles imaginaram. Mas mesmo com MDA vai ser necessario sempre uma logica que so os programadores tem, e so adquirem com experiencia. Eles acham que vao se livrar da logica complexa da programacao, mas so estao mudando a ferramenta - e para uma menos adequada.
[quote]Eu nao entendo esse tipo de pensamento. Por que diabos eu vou querer programar em UML e depois transformar em Java, se é muito mais facil, pratico, seguro, confiavel, escrever direto em Java (ou qqr outra linguagem)? UML nao é linguagem de programação, Java é.[/quote]. Concordo com vc nesse ponto. Mas como muitos aqui, que trabalham em empresas com chefes arrogantes e que nao possuem metade do conhecimento que temos, regras devem ser seguidas. A principal regra onde trabalho é “Cumpra o prazo de entrega do produto X”. Ferramentas como Visual Paradigm em sua versão paga possui muitos recursos da MDA que quebram muito nosso galho em relação a economia de tempo. Ela gera todoas as classes modelo (entidades) e todo mapeamento do hibernate. Isso ja economiza muito do nosso pouco tempo. [quote]Ah, mas meus analistas nao sabem programar. Entao contrate uns que sabem.
Ah, mas meus analistas nao querem programar. Tem muita gente que nao quer, meu irmao, por exemplo, é contador.[/quote]
Onde trabalho os analistas sabem programar (e bem). Porém , se eles sabem que gerar parte do codigo inicial de um projeto (esqueleto) vai nos dar um tempo a mais, pq nao automatizar isso? Se um dia a MDA evoluir a um ponto aonde os programadores não serão mais necessarios, vou vender sorvete .
[quote=sergio_java]
Onde trabalho os analistas sabem programar (e bem). Porém , se eles sabem que gerar parte do codigo inicial de um projeto (esqueleto) vai nos dar um tempo a mais, pq nao automatizar isso? Se um dia a MDA evoluir a um ponto aonde os programadores não serão mais necessarios, vou vender sorvete . [/quote]
Automatizar as tarefas repetitivas nada tem a ver com MDA, MDA nao gera esqueleto, ele, teoricamente, gera a implementacao da regra baseado nos modelos.
Ter ferramentas que geram parte das tarefas repetitivas eu até acho valido, desde que seja lembrado de que nada que faz parte da regra de negocios especifica da aplicacao deve ser considerada tarefa repetitiva.
[quote]Automatizar as tarefas repetitivas nada tem a ver com MDA, MDA nao gera esqueleto, ele, teoricamente, gera a implementacao da regra baseado nos modelos.[/quote] Como falei no começo do post comecei a estudar o assunto recentemente, e ainda estou me enrolando em certos conceitos! me desculpe!
[quote]Ter ferramentas que geram parte das tarefas repetitivas eu até acho valido, desde que seja lembrado de que nada que faz parte da regra de negocios especifica da aplicacao deve ser considerada tarefa repetitiva.[/quote] Concordo com vc! As regras de negocio nunca devem ser tratadas como tarefas repetitivas! Que tal vc dar umas dicas de onde encontrar um bom material sobre MDA. Por onde vc estudou? Ja deu alguma mexida em alguma ferramente que implemente este paradigma de desenvolvimento tipo o AndroMDA?
Entao, Sergio, nao leve a mal meus comentarios, nao sao pessoais.
Bem, como voce ja deve ter notado o obvio, eu nunca estudei a fundo MDA e muito menos qqr ferramenta pra ele. Basta um breve lida sobre o que é MDA e qual a sua proposta pra eu ja nao acreditar.
Mas se voce quer um dica eu posso te dar uma, comprovada por experiencia propria. Estude TDD. Isso funciona, pelo menos pra mim funcionou. Eu posso claramente dividir minha produtividade como desenvolvedor em antes e depois de TDD.
No mais se voce se sente a vontade e pretende aprender MDA, vai fundo. Talvez eu esteja redondamente errado e essa é uma metodologia que pode dar certo.
Olá,
com UML é perfeitamente possível gerar código, sem dúvidas. Se procurar com calma irão ver que no geral a maioria dos desenvolvedores sabem muito pouco sobre o assunto. Claro que gerar código à partir de um modelo não é fácil, no entanto, existem algumas iniciativas muito boas nessa área.
Sergio,
talvez o que você precise fazer é pesquisar por MDSD ao invés de MDA. MDSD é um conceito, digamos assim, mais arrojado do que MDA. MDA + AndroMDA certamente não é a melhor opção nos dias de hoje. Pesquise por MDSD, DSL e DSL Workbenchs.
Abraço,
Thiago
Ops,
só mais uma dica: o Eclipse Galileo é atualmente uma das melhores ferramenta para MDA e MDSD, Sergio. Se você conhecer o Eclipse Galileo Modeling Package realmente bem, tu tá bem na fita!
[quote=sergio_java]
Essa é uma boa pergunta quando nos referimos a coisas relativamente novas. Corremos o risco de estudar uma coisa que pode não bombar no mundo de T.I, mas por outro lado temos que analisar e tirar as conclusões. Quando a orientação a Objetos surgiu foram poucos os que se aventuraram nessa nova empreitada, tanto que a OO se popularizou a pouco tempo. A Promessa da MDA é boa, e a promessa das ferramentas MDA é melhor ainda (espero que não fique só nas promessas ) . A ideia de gerar pedaços de código ou ate mesmo sistemas completos a partir de modelos (UML por exemplo) é muito atraente. Imagine o ganho em produtividade… é tentador! Por isso resolvi dar uma estudada. Mas ta dificil digerir![/quote]
MDA não é novo. É tão velho quanto andar pra frente com a diferença de parecer não sair do lugar.
Valew pelas dicas galera. YvGa , não levei a mau seus comentarios!, eu gosto quando as pessoas me questionam e me corrigem de forma contrutiva . Em relação ao Eclipse Galileo vou dar uma pesquisada, o AndroMDA não ta sendo digerido facilmente por mim!!!
Bem, minha experiência com o AndroMDA tem sido bastante satisfatória, mas acho que isto se deve ao fato de eu ter dedicado algum tempo para explorar suas funcionalidades. Acho que a adoção de algumas práticas de MDD (MDA é um caso particular de MDA e marca registrada da OMG) requer, antes de mais nada, um ajuste de expetativas. Algumas constatações de quem já colocou vários projetos no ar utilizando esta técnica:
- A ferramenta não vai gerar 100% do código
UML perde feio em expressividade para qualquer linguagem que tenha IF-THEN-ELSE quando chega-se em determinado nível de especificação. Faz muito mais sentido usar o MDD para gerar o esqueleto do projeto e os grandes blocos (classes de domínio, serviços, interfaces, etc).
Por outro lado, uma linguagem gráfica, e o UML é apenas uma das opções disponíveis, é melhor para capturar e visualizar os relacionamentos entre entidades/componentes de um sistema, assim como os passos de uma atividade.
- Mais customização ==> Menos modelagem
MDD faz sentido quando vc. não precisa modelar tudo o que vai ser gerado. Se vc. precisa colocar 100% do que vai ser gerado no modelo, vc está usando MDA e, o AndroMDA em particular, de forma errada. É fundamental investir tempo na customização dos scripts de geração para que vc possa modelar menos. ex: no AndroMDA, quando vc. marca uma classe como <>, os scripts de geração irão não apenas gerar a classe java correspondente (com getters/setters para cada atributo público), mas tb DAOs, arquivos de configuração, etc. Mas este é um exemplo simples. Sem o compromisso do roundtrip, é possível fazer coisas muito mais interessantes com MDA do que apenas gerar uma classe java a partir de uma classe no diagrama UML. Alguns exemplos: Relatórios e validação de arquivos, que são casos de código extremamente repetitivo.
- Custo x Benefício
Dado o tempo necessário para customizar uma ferramenta de MDD para atender suas necessidades, e o AndroMDA não é exceção, vc sempre deve fazer uma análise de custo x benefício antes adotá-la em um projeto. Alguns indicadores de que o projeto é adequado são os seguintes:
- Tendência de evolução “lateral”, ou seja, novas funcionalidades “parecidas”, mas onde não há possibilidade de se utilizar um esquema de herança ou parametrização
- Necessidade de se manter um padrão consistente de implementação, mesmo em um sistema sujeito a constantes evoluções e alto turnaround de pessoal
E ae psevestre , blz? Cara pelo que eu estou vendo você ja teve algum contato com esse tipo de desenvolvimento de software baseados em modelos.
Sobre o lance da customização dos scripts, [quote]É fundamental investir tempo na customização dos scripts de geração para que vc possa modelar menos[/quote] você so configura uma vez isso? ou para toda geração de codigo vc tem que ficar customizando? Isso leva muito tempo? Desculpe a ignorancia!!!
[quote=sergio_java]E ae psevestre , blz? Cara pelo que eu estou vendo você ja teve algum contato com esse tipo de desenvolvimento de software baseados em modelos.
Sobre o lance da customização dos scripts, [quote]É fundamental investir tempo na customização dos scripts de geração para que vc possa modelar menos[/quote] você so configura uma vez isso? ou para toda geração de codigo vc tem que ficar customizando? Isso leva muito tempo? Desculpe a ignorancia!!![/quote]
No AndroMDA há vários níveis de customização:
- Parâmetros
Servem para customizar o comportamento de um cartucho específico. Por exemplo, o no caso do cartucho spring há opções para definir o mecanismo de gerenciamento de transações, uso ou não de EJBs, etc.
- Merge Points
Permite mesclar elementos adicionais aos artefatos gerados pelo AndroMDA. Ex: O cartucho JSF já gera o web.xml, faces-config.xml etc para vc. Se vc quiser utilizar um servlet ou filtro já pronto, vc. pode colocar o código necessário em arquivos específicos e o artefato final irá conter tanto a parte gerada automaticamente a partir do modelo quanto os elementos fixos (+/- como no XDoclet).
- Substituição de templates de geração
É possível indicar um diretório onde o AndroMDA irá buscar determinado template e, neste caso, a versão específica do projeto será utilizada no lugar da nativa que está no cartucho.
- Inclusão de novos templates
Usando-se uma combinação de merge points e propriedades, pode-se fazer um cartucho gerar artefatos adicionais a partir do modelo
- Implementação de novos cartuchos
Vc. pode criar seu próprio cartucho, aproveitanto um já existente ou criando-o do zero
A lista acima está em ordem crescente de complexidade e decrescente de freqüência com que é feita na prática. De fato, só cheguei a recorrer ao caso (5) em um cenário muito específico. Por outro lado, as configurações (1) e (2) ocorrem em quase todo projeto - normalmente no início do mesmo.
Moral da historia, MDA começa a ficar interessante quando sua arquitetura for um CRUD onde 90% do trabalho é gerar getter e setter.
Isso não é verdade. Independente do gerador de código que estivesse utilizando nenhum sistema está livre de customizações. Utilizando as configurações citadas acima é suficiente para determinar até onde gerar e de que forma gerar para que as customizações fiquem o mais suave possível.
Se o desenvolvedor está dentro desta área (ou seja, MDA, MDSD) ele provavelmente saberá quais patterns utilizar de forma que tire o maior proveito possível do gerador de código sem prejudicar possíveis customizações
Enfim, deve haver casos que MDSD e MDA não é a solução ideal, mas IMHO MDA e MDSD vai bem além dos simples CRUD’s.