MDA::Uma visão geral::Vantagens & Desvantagens (parte III)

Parte I::Apresentação | Parte II::Desenvolvimento | Parte III::Vantagens&Desvantagens
Como qualquer outra tecnologia, a utilização da Model Driven Architecture (MDA) proporciona uma série de vantagens, mas também possui desvantagens. Conhecer então seus pontos fracos e fortes possibilita explorar todo o seu potencial em favor da solução dos problemas enfrentados.

Benefícios da utilização da MDA

Através do emprego da MDA espera-se obter os seguintes benefícios: produtividade, portabilidade, interoperabilidade, manutenabilidade, teste e validação e documentação.

Produtividade. Na MDA o foco da atividade de desenvolvimento é deslocado para a construção do Platform Independent Model (PIM), pois os Platform Specific Model (PSM) deverão ser obtidos através de transformações automáticas suportadas pelas ferramentas MDA. Embora as transformações envolvidas sejam complexas, requerendo especialistas em sua especificação, depois de definidas podem ser aplicadas em diferentes contextos, possibilitando o retorno do investimento em termos de produtividade. Eventualmente algumas transformações comuns na indústria podem ser adquiridas ou mesmo colocadas em domínio público. Outro ganho possível se relaciona ao fato da construção do PIM não envolver detalhes específicos de implementação, concentrando a atividade na correta definição do sistema. Além disso, a quantidade de código que deverá ser manualmente gerada é reduzida [3].

Portabilidade. Como um mesmo PIM pode ser transformado em diferentes PSMs, possibilitando que um sistema possa operar em diferentes plataformas, então a construção do PIM é portável para qualquer plataforma para a qual exista a definição da transformação PIM para PSM especificamente envolvida [3]. Para plataformas menos populares é possível a definição particular das transformações desejadas, assim como o surgimento de novas plataformas irá requerer apenas a definição do mapeamento específico, o que em tese maximiza a portabilidade de qualquer PIM com relação as tecnologias atuais e futuras [1][8].

Interoperabilidade. Os PSMs dirigidos para plataforma diferentes não são interoperáveis diretamente. Mas para não deixar esta questão em aberto, a MDA também prevê a existência de bridges entre os PSMs e também entre o código de cada plataforma. A própria geração destas bridges pode ser automatizada pois é conhecida a origem de cada elemento do PSM em termos de sua definição no PIM e, por conseguinte, qual o elemento correspondente no outro PSM de interesse sistemas legados podem ser integrados através de adaptadores (wrappers) especificados em termos da MDA [1]. Um PIM baseado em uma máquina virtual não exigirá transformações, mas sim o PIM da máquina virtual, o qual deverá ser mapeado em um PSM destinado a uma plataforma específica, mantendo o sistema independente de plataforma e interoperável naquelas aonde exista uma máquina virtual apropriada [5].

Manutenabilidade. Através de alterações no PIM do sistema é possível a geração de novos PSMs e código correspondente muito rapidamente, agilizando e barateando os procedimentos de manutenção do sistema. Com isto correções, adaptações ou mesmo a adição de novas funcionalidades tornam-se tarefas mais simples de serem realizadas, prolongando a vida útil do sistema [1]. Espera-se que boas ferramentas MDA permitam manter a correspondência adequada entre PIM e PSM nas situações em um ou outro destes modelos sejam modificados.

Teste e Validação. Da mesma forma que os modelos construídos podem ser automaticamente transformados em outros modelos e também em código, é possível que sejam validados segundo critérios pré-definidos e também testados dentro dos parâmetros das plataformas em que deverão operar [5]. Isto também abre algumas possibilidades em termos de simulação, reforçando o grande potencial da MDA na geração de sistemas mais robustos, portáteis e adequados as necessidades identificadas.

Documentação. A MDA é baseada na construção de modelos formais, que sob muitos aspectos correspondem a uma importante documentação do sistema. O PIM é o artefato mais importante, pois corresponde a uma documentação de alto nível [8]. Além disso, como tais modelos podem ser visualizados, armazenados e processados automaticamente, não são abandonados após a finalização do sistema, pois tanto o PIM, no nível de abstração mais alto, quanto o PSM, num nível de abstração intermediário, podem ser reutilizados para a incorporação de alterações no sistema ou mesmo sua migração para outras plataformas. Embora a formalização dos modelos necessários a MDA cumpra o papel de documentação do sistema, outras informações deverão ser adicionadas aos modelos, tais como os problemas e necessidades diagnosticadas bem como o racional das escolhas efetuadas [3].

Tais benefícios se refletem diretamente na redução dos custos de desenvolvimento, redução do tempo de desenvolvimento, aumento da qualidade das aplicações produzidas, aumento do retorno dos investimentos realizados e aceleração do processo de adoção de novas tecnologias, bem como simplificação dos problemas associados com a integração de sistemas [11].

Também se enfatiza o fato  dos modelos da MDA serem exibidos num maior ou menor nível de detalhes, permitindo a análise, conversão e comparação de modelos. Além disso, o mapeamento explícito entre os modelos, que possibilita sua transformação automática, permite a rastreabilidade e controle de versão dos artefatos utilizados [4].

A aplicação de padrões de projeto também é um dos benefícios a serem obtidos com a MDA, pois na transformação PIM para PSM é possível que padrões conhecidos possam ser aplicados no sistema em questão [5], automatizando algumas das etapas de construção dos componentes do sistema na tecnologia escolhida [14].

Booch [8] defende o emprego da MDA afirmando que seus praticantes não necessitam ser profissionais altamente gabaritados em UML, cujo trabalho iterativo em equipe deverá resolver as questões mais sérias das abstrações envolvidas na elaboração do PIM. Também argumenta que o uso de padrões de projeto é favorecido, que os ganhos em portabilidade e interoperabilidade são enormes e que com o desenvolvimento das ferramentas MDA os ganhos serão ainda maiores.

Outros aspectos, menos tangíveis, são: que a modelagem em alto nível favorece as tarefas de validação, pois os detalhes de implementação não estão inclusos no PIM; que a aplicação ou integração de plataformas diferentes tornam-se mais claramente definidas, facilitando a produção de implementações particulares [4].

Dificuldades na aplicação da MDA

A UML é uma linguagem de modelagem, que originalmente se destinava a oferecer uma forma visual de comunicação para representação dos principais conceitos e elementos de um sistema. Embora seja utilizada amplamente pela indústria de desenvolvimento de software, que reconhece suas muitas qualidades, deixa algumas lacunas: não possui uma semântica completamente formalizada, o que deixa brechas para diferentes interpretações e implementações de suas representações; não existe uma implementação de referência cuja semântica permita garantir a correta interpretação e transformação de seus modelos; não possui um formato de intercâmbio definido, o que dificulta o compartilhamento de seus modelos entre as ferramentas que a suportam; e requer o uso de várias outras linguagens de extensão para que sejam expressos elementos que não fazem parte do seu escopo (as restrições de atributos, por exemplo) ou para que seja armazenada e processada [15][9][17].

Apesar dos argumentos da “engenharia de modelagem”, um meta-modelo [9], tal como o PIM, permite a adição de novas funcionalidades com relativa facilidade, mas por si só não garante que tais funcionalidades se articulem de modo coerente. Assim continua nas mãos dos projetistas avaliar e garantir tal consistência, o que continua a exigir a alocação de profissionais experientes, onde percebemos que a MDA não contribui de forma efetiva neste sentido. COOK [18] argumenta que a neutralidade do PIM em termos de plataforma poderá significar, em última instância, perdas em termos de performance, o que poderá comprometer o desenvolvimento de sistemas com alto volume de transações ou em tempo real. Conforme MEDVIDOVIC et al. [19], apenas a UML não é suficiente para “capturar” todos os aspectos necessários a modelagem de uma arquitetura de software completa, necessitando de extensões ADL (Architecture Description Languages). O direcionamento da modelagem para domínios específicos (domain specific modeling) poderia trazer ganhos para MDA [7][18][20] possibilitando a geração de aplicações melhor ajustadas para suas efetivas condições de utilização.

Existem ainda as dificuldades na transformação PIM para PSM, pois além da oferta de uma enorme diversidade de plataformas (CCM, JavaEE, .NET [21], etc.), se tal transformação não for precisa o suficiente, a geração de código não será possível ou não produzirá os ganhos de produtividade esperados. Cada uma destas plataformas possui uma API bastante ampla, complexa e nem sempre bem documentada, é muito difícil a construção dos (standard mapping) para realização das transformações automáticas. Efetivamente só foram demonstrados os mapeamentos para CORBA [22][23] e JavaEE [14][18]. Existem sérias dúvidas quanto a capacidade e interesse da indústria de TI na confecção de UML profiles para todos os domínios específicos [15]. Ainda nesta questão, FOWLER [18] não vê ganhos adicionais da MDA quando comparada com os resultados do desenvolvimento sustentado por padrões, bibliotecas e frameworks.

Observamos também que dentre as diversas ferramentas oferecidas pelos inúmeros fornecedores que “adotaram” a MDA, nenhuma é capaz de realizar completamente as transformações entre PIM e PSM, ou mesmo efetuar a geração de código a partir do PSM, pelo menos não como idealizado pela proposta desta arquitetura. Efetivamente as ferramentas existentes apenas adaptam os métodos de trabalho previamente existentes numa “roupagem” MDA. Este cenário é desconfortável, pois remete a uma situação semelhante durante a década de 80, quando muito foi “prometido” para as ferramentas CASE (Computer Aided Software Engineering) e efetivamente pouco foi implementado e disponibilizado, mesmo que comercialmente [9][17][18].

Percebemos, finalmente, que nos mesmos argumentos que incentivam o uso da MDA residem algumas dúvidas, bastante sérias, quanto aos ganhos que podem ser obtidos.

Conclusões

A proposta da MDA é oferecer meios concretos para melhorar a produtividade, portabilidade, interoperabilidade, manutenabilidade e documentação de sistemas. Para isto esta arquitetura estabelece seu foco na modelagem da funcionalidade e comportamento de aplicações e sistemas distribuídos, separando os aspectos particulares das tecnologias que serão de fato usadas em sua implementação. Desta maneira é necessária a criação de modelos detalhados e representativos dos aspectos funcional-comportamental e tecnológico, onde se posiciona a UML e as demais linguagens que sustentam a MDA.

A UML, elemento central para a construção de modelos MDA, provê uma grande variedade de elementos para o projetista de software, tais como múltiplas visões inter-relacionadas do sistema, uma semântica que permite a expressão de meta-modelos e uma série de linguagens de extensão que permitem suprir outras necessidades. Mas como discutido, além de sua complexidade, a UML ainda não permite a definição semanticamente completa de modelos para qualquer domínio.

Embora seja coerente a proposta da OMG na utilização de outras linguagens complementares para expressão, armazenamento e processamento dos modelos necessários a operacionalização da MDA, isto adiciona uma complexidade indesejável ao processo.

Outro benefício proposto é a automação da tarefas de transformação através do emprego de técnicas de mapeamento dos modelos, mas neste ponto também residem dúvidas sobre a real capacidade das ferramentas oferecidas hoje e nos próximos anos, o que compromete parcialmente os ganhos prometidos.

Considerando este contraponto, concluímos que o principal benefício da MDA é, efetivamente, os ganhos de qualidade e neutralidade proporcionados pelas atividades de modelagem, especialmente quando realizada independente da plataforma. A automatização do processo de transformação destes modelos em outros tecnologicamente particularizados poderá trazer grandes ganhos, justificando os trabalhos de pesquisa realizados nesse sentido. Até lá, vale a pena utilizar os conceitos da “engenharia de modelagem”, mesmo que seus procedimentos sejam efetuados manualmente.

MDA::Uma visão geral

• Apresentação (parte I)
• Desenvolvimento (parte II)
• Vantagens & Desvantagens (parte III – este artigo)

Versão adaptada do artigo de JANDL JUNIOR, P.. Uma análise da OMG Model Driven Architecture. Análise (Jundiaí), v. 11, p. 35­49, 2005. 

Para Saber Mais

(A numeração dos itens não é sequencial, pois só constam os elementos citados.)

• [1] SOLEY, Richard. & OMG Staff Strategy Group. Model Driven Architecture. Object Management Group White Paper, 2000. Disponível em: http://www.omg.org/mda/mda_files/model_driven_architecture.htm, recuperado em 02/01/2017.
• [3] KLEPPE, Anneke, WARMER , Jos & BAST, Wim. MDA Explained: The Model Driven Architecture - Practice and Promise. Addison-Wesley, Reading, MA, 2003.
• [4] MILLER, Joaquin & MUKERJI, Jishnu. Model Driven Architecture (MDA). Object Management Group Architecture Board ORMSC. 2001. Disponível em: https://pdfs.semanticscholar.org/fab3/6d29bd18fe7743ab710caf9faacb495f10d7.pdf, recuperado em 26/10/2004.
• [5] MILLER, Joaquin & MUKERJI, Jishnu (eds). MDA Guide Version 1.0.1. Objetc Management Group. 2003-05-01. Disponível em: http://www.omg.org/mda/mda_files/MDA_Guide_Version1-0.pdf, recuperado em 02/01/2017.
• [7] MELLOR, S., SCOTT, K., UHL, A., WEISE, D.. MDA Distilled. Addison-Wesley, Reading, MA, 2004.
• [8] BOOCH, Grady. MDA: A motivated manifesto IN Dr. Dobb's Magazine. 2004-08-01. Disponível em: http://www.drdobbs.com/architecture-and-design/mda-a-motivated-manifesto/184415169, recuperado em 02/01/2017.
• [9] THOMAS, D.. MDA: Revenge of the modelers or UML utopia? IN IEEE Software, pages 22–24, May-Jun 2004.
• [11] OMG. MDA (Model-Driven Architecture) Executive Overview. On-line: http://www.omg.org/mda/executive_overview.htm, recuperado em 02/01/2017. 
• [14] ALEXANDRE, T.. Using design patterns to build dynamically extensible collaborative virtual environments. IN Proceedings of the 2nd international conference on Principles and practice of programming in Java, pages 21–23. Computer Science Press, Inc., 2003.
• [15] THOMAS, D.. Unified or universal modeling language? IN Journal of Object Technology, 2(1):7–12, Jan-Feb 2003.
• [17] FOWLER, Martin. Model Driven Architecture. On-line: http://martinfowler.com/bliki/ModelDrivenArchitecture.html, recuperado em 02/11/2004, 2004.
• [18] COOK, S.. Domain-Specific Modeling and Model Driven Architecture. On-line: http://www.bptrends.com/publicationfiles/01-04\%20COL\%20Dom\%20Spec\%20Modeling\%20Frankel-Cook.pdf, recuperado em 02/11/2004. MDA Journal, 2004.
• [19] MEDVIDOVIC, N, RESENBLUM, D. S., REDMILES, D. F., ROBBINS, J. E.. Modeling software architectures in the unified modeling language. IN ACM Transactions on Software Engineering and Methodology (TOSEM), 11(1):2–57, 2002.
• [20] AGRAWAL, A.. Metamodel based model transformation language. IN Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 386–387. ACM Press, 2003.
• [21] MICROSOFT. Microsoft .NET Platform. On-line: http://www.microsoft.com/net/, recuperado em 28/09/2004.
• [22] OMG. UML Profile for CORBA. Object Management Group White Paper, 2004. On-line: http://www.omg.org/technology/documents/formal/profile_corba.htm, recuperado em 22/10/2004.
• [23] OMG. Common Object Request Broker Architecture. Object Management Group White Paper, 2004. On-line: http://www.omg.org/technology/documents/formal/corba_iiop.htm, recuperado em 26/10/2004