MDA::Uma visão geral::Desenvolvimento (parte II)

Parte I::Apresentação | Parte II::Desenvolvimento | Parte III::Vantagens&Desvantagens
O ciclo de desenvolvimento de sistemas através da Model Driven Architecture MDA é relativamente semelhante a outros processos de desenvolvimento de software, ou seja, compreende fases de levantamento de requisitos, análise, projeto (ou modelagem), codificação, teste e implantação.

Desenvolvimento com MDA

Uma das maiores diferenças do processo MDA em relação a outros reside na natureza dos artefatos criados durante a etapa de desenvolvimento.Segundo a especificação MDA tais artefatos devem ser modelos formais que possam ser processados automaticamente [3]. Existem três modelos ou visões (viewpoints) na MDA:

• Modelo computacional independente ou Computacional Independent Model (CIM);
• Modelo independente de plataforma ou Platform Independent Model (PIM); e
• Modelo específico de plataforma ou Platform Specific Model (PSM).

O código (code), embora não constitua um modelo propriamente dito, também é um elemento importante nesta arquitetura, pois representa seu resultado concreto, como veremos adiante.

Modelo computacional independente (CIM)

O Computacional Independent Model (CIM) representa uma visão do sistema de um ponto de vista estritamente computacional e independente em termos de plataforma, que descreve apenas os requisitos gerais de funcionamento do sistema, isto é, não exibe detalhes da estrutura dos sistema, mas considera um determinado tipo de sistema cujo ambiente possui necessariamente características comuns a outros sistemas do mesmo domínio computacional. Por isso também é denominado modelo de domínio (domain model) ou modelo de núcleo (core models) [1][5]. Sistemas em tempo real possuem requisitos bastante distintos de sistemas transacionais ou sistemas distribuídos baseados em componentes, assim a primeira visão do sistema deverá considerar em qual destes domínios se dará sua operação. Embora esta visão contenha informações importantes, não é tratada usualmente como um elemento essencial, diferente do PIM e PSM, que são fundamentais na MDA.

Modelo independente de plataforma (PIM)

O primeiro artefato especificado pela MDA é o Platform Independent Model (PIM) ou modelo independente de plataforma, cujo alto grau de abstração deve permitir representar o sistema de modo independente de qualquer tecnologia de implementação. O PIM é um modelo declarativo formal da estrutura funcional do sistema [4], ou seja, tem foco na operação do sistema e, por isso, deve oferecer a melhor descrição possível para suportar o negócio em questão, mas sem considerar qual plataforma será utilizada ou como tal sistema será construído [3][6], ou seja, é neutro tecnologicamente. É um modelo destinado a preservar a informação essencial a respeito do projeto da aplicação, sua arquitetura e infra-estrutura [8].

O PIM também constitui um modelo bastante rico em termos semânticos, pois pode ser representado gráfica ou textualmente em termos da UML e suas extensões (tais como a Object Constraint Language - OCL - que facilita a indicação de restrições), dando ao projetista meios de expressar mais precisamente suas intenções e, com isso, reduzindo o trabalho das etapas posteriores. Outro aspecto importante é que o PIM poderá armazenado em um repositório através da  Meta Object Facility (MOF), possibilitando sua recuperação e processamento posteriores.

Modelo específico de plataforma (PSM)

O segundo artefato determinado pela MDA é o Platform Specific Model (PSM) ou modelo específico de plataforma. Este modelo, também expresso através da UML, deve representar o sistema em termos de construções apropriadas de uma tecnologia particular, ou seja, considerando a operação descrita pelo PIM e também detalhes específicos da implementação em termos da tecnologia selecionada [3][4][5][6]. Assim um PSM voltado para a tecnologia EJB descreverá o sistema utilizando suas estruturas, tais como home interface, session bean ou entity bean; enquanto um PSM voltado para Web Services incluirá termos como SOAP, provider ou XML schemas. Um PSM será, como um PIM, também armazenado em repositório através da MOF.

Cada PSM deve ser o resultado de uma transformação automática do PIM em termos de uma tecnologia específica (standard mapping), implicando que um mesmo PIM pode originar diferentes PSM, conforme as transformações aplicadas [1][3][6]. Isto significa que uma determinada plataforma deverá ser escolhida, implicando na seleção de mecanismo de mapeamento particular, para a transformação de um artefato PIM em um PSM. A transformação de um PIM em um PSM CORBA[22] exigiria a escolha de elementos específicos definidos num UML profile [4], onde as classes UML representariam as interfaces, tipos e outras construções do CORBA [23] através de estereótipos (stereotypes).

A operação de transformação de um PIM em um PSM é o passo crucial do processo de desenvolvimento MDA [3], pois representa o maior ganho oferecido dado que é relativamente comum que um mesmo sistema tenha que operar em diferentes plataformas, evitando a repetição dos esforços de desenvolvimento [6].

Código

O código é o produto final da MDA e deve ser o resultado da transformação de um dado PSM considerando uma tecnologia de implementação específica. A geração de código é uma etapa relativamente simples dada a proximidade do PSM com a tecnologia particular em uso [3]. Em algumas circunstâncias, quando existir suporte para múltiplas linguagens de programação deverá ser efetuada a seleção da linguagem de implementação desejada. Além do código também poderão ser gerados outros artefatos necessários ao sistema, tais como arquivos de configuração, entradas de registro, scripts, etc.

Após a geração do código será provável a necessidade de alguns ajustes e complementações, que deverão ser feitos por uma equipe de programação, mas espera-se que em quantidades bastante menores do que com as atuais ferramentas.

Transformações automáticas

O grande diferencial da MDA reside na forma de realização das transformações entre os modelos PIM, PSM e o código. Tradicionalmente as transformações entre modelos de um processo de software são realizadas manualmente. Diferentemente na MDA, os modelos deverão ser usados para geração automática da maior parte do sistema [6]. Na MDA todas transformações devem ser realizadas automaticamente por ferramentas apropriadas, o que pode significar maior rapidez e flexibilidade na geração de aplicações de melhor qualidade, caracterizando assim os benefícios imediatos de sua aplicação [3]. As transformações entre modelos ou mapeamento (mappings) são entendidas como o conjunto de regras e técnicas aplicadas em um modelo de modo que seja obtido um outro com as características desejadas. A MDA considera a existência de quatro tipos de transformações diferentes [4]:

• PIM para PIM. Utilizada para o aperfeiçoamento ou simplificação dos modelos sem a necessidade de levar em conta aspectos dependentes de plataforma.
• PIM para PSM. Transformação “padrão” do modelo independente de plataforma para outro específico durante o ciclo de desenvolvimento típico de aplicações.
• PSM to PSM. Esta transformação permite a migração da solução entre plataformas diferentes, bem como o direcionamento de partes da implementação para tecnologias específicas, usadas por questões de interoperabilidade ou benefícios obtidos através do uso de certas plataformas.
• PSM to PIM. Quando é necessário obter-se uma representação neutra em termos de tecnologia de soluções específicas.

Entre as transformações pode existir o processo de marcação (marking), que constitui uma forma “leve” e pouco intrusiva de extensões dos modelos com elementos voltados a facilitar uma transformação particular [7]. Por exemplo, um PIM (sem marcações) pode receber anotações destinadas à uma plataforma A ou B, originando marked PIMs e mantendo o PIM original sem qualquer “contaminação”.

Embora hoje existam muitas ferramentas capazes de gerar algum código a partir de modelo particulares, usualmente tal código é pouco mais que um “esqueleto” (um template), exigindo que a finalização da implementação seja feita através de atividades de programação convencional. Atualmente [3] não dispomos de ferramentas que sejam capazes de realizar completamente a transformação PIM para PSM e deste para código, requisitando a intervenção manual de programadores para finalização dos modelos e da codificação, mas que as ferramentas MDA existentes são capazes de gerar protótipos funcionais, embora simplificados, do sistema acelerando o ciclo de desenvolvimento. As transformações completas são possíveis em ambientes dotados de restrições [4], dentre as quais: ausência de legados a considerar; o modelo de partida é semanticamente rico; e os algoritmos de transformação são de alta qualidade.

A geração de código não é considerada o aspecto mais importante da MDA [3][4], pois este é bastante próximo à estrutura declarativa e atributos, sendo simples a estrutura funcional de métodos de acesso (setter and getter methods), por outro lado é bastante complexa a geração das características comportamentais do sistema como um todo. Exatamente por isso, projetistas que utilizam a MDA não devem esperar que a primeira versão gerada para o sistema seja perfeita, pois o próprio processo MDA assume a necessidade de múltiplas iterações entre o projeto e a implementação obtida, ou seja, a necessidade de refinamento como meio de produzir-se sistemas de qualidade [4][12].

MDA::Uma visão geral

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

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.
• [6] SIEGEL, Jon. Developing in OMG’s New Model-Driven Architecture. Object Management Group White Paper, 2001. Disponível em: https://www.icmgworld.com/corp/developer/whitepapers/UsingMDA.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.
• [12] SIEGEL, J.. Using OMG’s Model-Driven Architecture (MDA) to integrate Web Services. Object Management Group White Paper, 2004. Disponível em: http://www.omg.org/mda/, recuperado em 26/10/2004. Object Management Group White Paper, 2002.
• [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.