Você está pronto para o MDA?

tradução livre de: http://www.agilemodeling.com/essays/readyForMDA.htm

Você está pronto para o MDA (Arquitetura Orientada por Modelos)?

A Arquitetura Orientada por Modelo (MDA) da “Object Management Group (OMG)” ganhou significado destaque na indústria de TI no ano passado. Contudo o MDA é realmente uma maravilhosa teoria, existem claramente diversos desafios para serem superados. Assumindo que você não ache esses desafios tão amedrontadores, você está preparado para o MDA? Os pontos críticos que você deve considerar são:

1. Você atualmente possui projetistas (Analistas de Sistemas)  altamente qualificados? MDA somente funciona quando você tem pessoas com as habilidades corretas, e eu sinto que na melhor das situações somente 2% de todos desenvolvedores possuem essas habilidades.
2. Você possui pessoas em sua equipe que podem se tornar projetistas altamente qualificados? Se você não tem numero suficiente de projetistas agora, porém nos próximos anos você poderá identificar, treinar e guiar nestas habilidades.
3. Você está em condições de atrair e reter projetistas altamente qualificados? Se você não tem numero super projetistas que o MDA requere você pode sempre contrata-los, porém muitas outras empresas irão pensar dessa forma e se desesperarão para empregar essas pessoas, então você precisa ser muito bom para rete-las.
4. Você possui pessoas que são ambos bons projetistas e codificadores? Até mesmo quando você está criando esses modelos sofisticados você ainda sim precisará de código, seja isso codigo ASL (action semantic language) nos seus modelos independentes de plataforma, código OCL (object constraint language) ou mesmo código especifico de plataforma em Java ou C# para implementar a lógica que sua ferramenta não gera.
5. Seus Stakeholders(pessoas interessadas no projeto) são sofisticados o bastante para entender PIMs? Nos anos 80 quando ferramentas complexas de modelagem foram primeiramente popularizadas, descobrimos que nossos stakeholders de negocios tinham grande dificuldade para entender os modelos abstratos que criavamos. Aprendemos que precisamos usar tecnicas e ferramentas mais simples com nosso usuario e que quando o fizemos eles começaram a se envolver ativamente com a especificação dos sistemas.
6. Você encontraria um conjunto de ferramentas de modelagem que completa suas necessidades atuais? Quão Usavel/”Entendivel” elas são? MDA somente funciona se voçe encontrar ferramentas que supram suas necessidades atuais, da mesma forma voçe descobrirá que precisa encontrar ferramentas simples de se modelar – apesar do XMI da OMG (XML model interchange) parecer ótima em teoria mas na realidade não existe ainda um conjunto de ferramentas na qual não aprensentem uma perda de informação quando compartilhando modelos entre elas.
7. Você possu uma estratégia de teste viavel? Parte de modelar um sistema é validar seu funcionamento. Infelizmente eu não sei de nenhuma ferramenta que suporte alguma forma de Modelagem orientada a teste (TDM), ou deveriamos chamar MDA orientado a teste (TDMDA). então como você irá provar se seu sistema funciona? Veja o que Jason Gorman pensa sobre o assunto.
8. Está disposto a juntar sua fortuna a do vendedor da ferramenta? Com o metodo MDA de se desenvolver você se torna extremamente dependente das ferramentas de modelagem que você usa. Isso não seria tão ruim se fosse facil compartilhar modelos entre varias ferramentas, mas francamente os vendedores de ferramentas possuem pouquissima motivação para suportar esta funcionalidade, pois eles preferem ter você preso no produto deles. E pior, cada ferramenta tem sua propria extensão (exemplo: Seu proprio ASL, varios modelos não-UML) você não tem a possibilidade de falcilmente transitar pelas ferramentas.
9. (Não compreendi o contexto, tradução pode estar falha)O gerenciamento senior será longo o necessário para se ter sucesso? Para realmente colher os beneficios do MDA você precisa ter um sistema intermediario estrategico de controle. Como as estrategias adotadas sucederam no passado?
10. Lhe é permitido ser agil? Está adotando o MDA para acalmar as preocupações dos burocratas entre nós ou está desejando ter sucesso em desenvolvimento de software. Caso esteja, você deveria tentar obter uma abordagem agil do MDA.

Quando você parar para pensar sobre isso existem pouquissimas oportunidades para MDA no desenvolvimento de aplicações para negocios. Sim, provavelmente existem  belas oportunidades usando ferramentas MDA para simulação ou para o desenvolvimento de software; Esses ambientes tendem a ter desenvolvedores com o conjunto de habilidades necessárias e existem diversas ferramentas especialmente direcionadas para nichos de mercado. Porém isso é somente uma pequenissima porcentagem de todo mercado.

—————————————
Are You Ready For the MDA?

The Object Management Group (OMG)’s  Model-Driven Architecture (MDA) has gained significant mindshare within the IT industry this past year.  Although the MDA is a really wonderful theory, there are clearly  many challenges which need to be overcome.  Assuming that you don’t find these challenges too daunting, are you ready for the MDA?  The critical issues that you must consider are:

1.Do you currently have highly skilled modelers?  MDA only works when you have people with the right skills, and gut feel tells me that at best only one or two percent of all developers have these skills.
2.Do you have people on staff that could become highly skilled modelers?  If you don’t have sufficient numbers of modelers now, perhaps over the next few years you might be able to identify and then train and mentor people in those skills.
3.Are you able to attract and retain highly-skilled modelers?  If you don’t have the uber-modelers that the MDA requires you can always hire them, although many other organizations will also think along these lines and will be desperate to hire these people away from you so you’ll need to be very good at retaining them.
4.Do you have people who are both strong modelers and strong coders?  Even when you’re creating these sophisticated models you’ll still need to code, be it action semantic language (ASL) code in your platform independent models (PIMs), object constraint language (OCL), or even platform specific source code in Java or C# to implement the logic which your tool(s) didn’t generate.
5.Are your stakeholders sophisticated enough to understand PIMs?  In the late 1980s, when complex modeling tools were first popularized, we discovered that our business stakeholders had great difficulty understanding the abstract models which we created.  We learned that we needed to use simpler techniques and simpler tools with our users, and that when we did so that they could become actively involved with specifying systems.
6.Can you find a modeling toolset which fulfills your actual needs?  How usable/learnable is the tool(s)? MDA only works if you can find modeling tools which meet your actual needs.  You will likely discover that you need to find a single modeling tool – although the OMG’s XML model interchange (XMI) sounds great in theory the reality is that there doesn’t yet seem to be a combination of tools which doesn’t exhibit a loss of information when sharing models between them.
7.Do you have a viable testing strategy in place?  Part of building a system is validating that it works.  Unfortunately I don’t know of any modeling tools which support some form of test-driven modeling (TDM), or perhaps we should call it test driven MDA (TDMDA), so how are you going to prove that your system actually works?  See Jason Gorman’s thoughts on the issue.
8.Are you willing to tie your fortunes to that of the tool vendor?   With the MDA approach to development you become extremely reliant upon the modeling tools which you use.  This wouldn’t be so bad if it was easy to share models between various tools, but frankly the tool vendors have little motivation to actually support this functionality because they prefer to have you locked into their product.  Worse yet, because each tool has it’s own unique extensions (e.g. their own ASL, various non-UML models) you won’t be able to easily transition staff between tools.
9.Will senior management stay the course long enough to succeed?  To truly reap the benefits of MDA you need to have a cross-system, multi-year strategy in place.  How well have these sorts of strategies worked out in the past?
10.Are you allowed to be agile? Are you adopting the MDA to soothe the worries of the bureaucrats among us, or are you doing it to actually be successful at software development.  Hopefully it’s the latter, and if so shouldn’t you try to take an agile approach to the MDA?

When you stop and think about it there is very little opportunity for MDA within business application development.  Yes, there are very likely wonderful opportunities using MDA tools for software simulation or the development of embedded software; these environments tend to have developers with the requisite skillset and there are several tools specifically targeted at these market niches.  However, this is a spectacularly small percentage of the overall market.

Arquitetura Orientada a Modelo

Simples tradução de:  MDA Guide Version 1.0.1, pagina 6, Capitulo 1.2 – Primeiro Paragrafo
1.2 Entrar na Modelagem:

Ao mesmo tempo uma curiosa mudança de pensamento apareceu na industria de IT, assim que as linguagens de modelagem de sistemas finalmente começaram a se unificar e convergir em direção a inicial sopa de OMT, IDEF, Booch, Shlaer-Mellor, outras linguagens e metodos, o interesse em modelar dados e aplicações cresceu significativamente. Se contruirmos prédios do modo que construimos software, seremos incapazes de conecta-los, muda-los ou até mesmo redecora-los de forma fácil para adequar a novos usos, e pior, eles constantemente desabarão. Enquanto isso pode significar novos lucros para desenvolvedores, isto se torna inaceitável para os que vivem e trabalham nestes prédios.

De fato não temos muitas desculpas para construir software sem antes cuidadosamente o projetar, este trabalho que não somente possibilita um sistema mais facil de desenvolver, integrar e manter, mas também nos permite automatizar ao menos algumas partes da construção. Imagine se o contrutor pudesse pegar a planta, enfiar na maquina, e a fundação simplesmente aparecesse. Pouco provavel fora do mundo dos “Jetsons”, mas algo que ocorreria todos os dias no mundo do software. Podemos criar modelos, definir padoes como o UML, MOF e CWM da OMG, e automatizar a criação das fundações de modelos de dados e aplicação. Ainda melhor, quando precisarmos conectar estes “prédios” uns aos outros poderemos automatizar a geração de pontes e tradutores baseados nos modelos definidos, assim quando um novo tipo de aço resistente a fogo for inventado, poderemos gerar a nova infraestrutura.

Esta é a promessa do Arquitetura Orientada a Modelo (MDA): permitir a definição de uma aplicação e modelo de dados, legivel pela maquina que permitirá alta flexibilidade de:
* Implementação: nova infraestrutura de implementação (o efeito “tecnologia mais atual”) pode ser integrada ou almejada para um design existente.

• Integração: Como não somente a implementação mas também o projeto existe no momento de integração, podemos automatizar a produção de pontes de integração de dados e conexões para novas estruturas de integração.
• Manutenção: A possibilidade de projetar de uma forma legivel pela maquina dá ao desenvolvedor acesso direto a especificação do sistema tornando a manutenção muito mais simples.
• Teste e Simulação: Assim como os modelos desenvolvidos podem ser usados para gerar codigo, eles podem de mesma forma ser validados aos requisitos, testados em varias infraestruturas e podem ser usados para simular diretamente o comportamento do sistema que esta sendo desenvolvido.

_______________________________
1.2 Enter Modeling

At the same time, a curious change of thought has appeared in the IT industry. As the languages for modeling systems have finally started to coalesce and converge from the primordial soup of OMT, IDEF, Booch, Shlaer-Mellor and scores of other languages and methods, the interest in modeling data and applications has picked up significantly. After all, if we built buildings the way we built software, we would be unable to connect them, change them or even redecorate them easily to fit new uses; and worse, they would constantly be falling down. While this might generate new income for construction workers, it might not be acceptable to those who live and work in those buildings.

In fact, we have very little excuse to build software without first doing careful design work; design not only leads to systems that are easier to develop, integrate and maintain–but also because we have the ability to automate at least some of the construction. Imagine if the construction worker could take his blueprint, crank it through a machine, and have the foundation of the building simply appear. Not likely
outside the Jetsons’ world, but an everyday occurrence in the software world. We can take models, defined in standards like OMG’s own UML, MOF and CWM, and automate the construction of data storage and application foundations. Even better, when we need to connect these “buildings” to each other we can automate the generation of bridges and translators based on the defining models; and when a new,
more fire-resistant type of steel is invented, we can regenerate for the new infrastructure.

This is the promise of Model Driven Architecture: to allow definition of machine-readable application and data models which allow long-term flexibility of:

• Implementation: new implementation infrastructure (the “hot new technology”effect) can be integrated or targeted by existing designs
• Integration: since not only the implementation but the design exists at time of integration, we can automate the production of data integration bridges and the connection to new integration infrastructures
• Maintenance: the availability of the design in a machine-readable form gives developers direct access to the specification of the system, making maintenance much simpler
• Testing and simulation: since the developed models can be used to generate code, they can equally be validated against requirements, tested against various infrastructures and can used to directly simulate the behavior of the system being designed.

Fonte:  http://www.omg.org/docs/omg/03-06-01.pdf