Odyssey-MDA: Uma Abordagem para a Transformação de Modelos de Componentes

Transcrição

1 Odyssey-MDA: Uma Abordagem para a Transformação de Modelos de Componentes Natanael E. N. Maia 1, Ana Paula T. B. Blois 1,2, Cláudia M. Werner 1 1 COPPE/UFRJ Programa de Engenharia de Sistemas e Computação Caixa Postal CEP Rio de Janeiro RJ 2 Pontifícia Universidade Católica do Rio Grande do Sul PUCRS-FACIN Av. Ipiranga, 6681 Prédio 30 Bloco 4 CEP Porto Alegre RS {ntmaia, anablois, werner}@cos.ufrj.br Abstract. This paper presents a MDA based approach to support the developer in obtaining platform specific component models. These models are obtained through the definition and execution of transformations which can be defined by the composition of small generic transformations (built-ins) or implemented and incorporated by an extension mechanism (plug-ins). To support the use of this approach, a machine for model transformation execution and an example of its use for the Enterprise JavaBeans platform are presented. Resumo. Este artigo apresenta uma abordagem baseada no paradigma MDA para apoiar o desenvolvedor na obtenção de modelos de componentes específicos para uma plataforma. Estes modelos são obtidos através da definição e execução de transformações que podem ser definidas pela composição de pequenas transformações genéricas (built-ins) ou implementadas e incorporadas através de um mecanismo de extensão (plugins). Para apoiar o uso dessa abordagem, uma máquina para execução de transformações e um exemplo de utilização para a plataforma Enterprise JavaBeans são apresentadas. Palavras-chave: Arquitetura Orientada por Modelos, Transformações de Modelos, Desenvolvimento Baseado em Componentes. 1. Introdução As organizações que desenvolvem software vêm, de maneira geral, reconhecendo a importância de se reaproveitar o esforço empregado no desenvolvimento de sistemas para reduzir prazos, otimizar recursos, e aumentar a produtividade e qualidade. Uma abordagem atualmente utilizada para se obter os benefícios da Reutilização de Software é o Desenvolvimento Baseado em Componentes (DBC), cujo objetivo é a construção de sistemas a partir de componentes de software reutilizáveis [Sametinger 1997]. A todo o momento, novas tecnologias aparecem no mercado e se tornam populares. Um grande desafio enfrentado no desenvolvimento de software é a escolha dessas tecnologias. Companhias precisam adotá-las pela demanda de seus clientes, pelos problemas que essas novas tecnologias se propõem a resolver, ou pelo fato das tecnologias antigas terem se tornado obsoletas e não existir mais suporte adequado. Como conseqüência, componentes existentes precisam ser migrados para uma nova tecnologia, ou para uma nova versão de uma tecnologia existente [Kleppe et al 2003].

2 Visando diminuir esse efeito, a OMG está desenvolvendo um framework conhecido como Model Driven Architecture (MDA) [MDA 2003], cujo objetivo é prover uma abordagem para: a) especificar um sistema independente da plataforma que irá suportá-lo; b) especificar plataformas possíveis para os sistemas em desenvolvimento; c) escolher uma plataforma para o sistema e; d) realizar transformações sobre a especificação inicial, a fim de obter uma especificação do sistema na plataforma escolhida. Com o uso dessa abordagem, os desenvolvedores passam a dar maior importância à modelagem dos requisitos de negócio da aplicação, não se preocupando com a plataforma onde serão implementados esses requisitos. Diante disto, este artigo descreve uma abordagem para a definição e execução de transformações sobre modelos de componentes. A abordagem permite que modelos de componentes independentes de plataforma sejam transformados em modelos específicos para uma plataforma escolhida. As transformações podem ser definidas pela composição de pequenas transformações genéricas (built-ins) ou implementadas e incorporadas à abordagem através de um mecanismo de extensão (plug-ins). O restante do artigo está organizado em cinco seções: A seção 2 descreve alguns padrões adotados. A seção 3 apresenta a abordagem para definição e execução de transformações sobre modelos de componentes Odyssey-MDA. A seção 4 descreve a implementação da abordagem através da máquina de transformações Odyssey-MDA. A seção 5 apresenta um exemplo de transformação para a plataforma Enterprise JavaBeans. A seção 6 apresenta os trabalhos relacionados. Finalmente, a seção 7 conclui o artigo e apresenta as principais contribuições da abordagem e trabalhos futuros. 2. Padrões Adotados A abordagem proposta está baseada nos padrões Meta-Object Facility (MOF) [MOF 2002], XML Metadata Interchange (XMI) [XMI 2002] e Java Metadata Interface (JMI) [JCP 2004]. O objetivo de utilizar estes padrões é tornar a abordagem flexível para a importação, transformação e exportação dos modelos, além de extensível para a implementação e incorporação de novas transformações. O padrão MOF especifica uma linguagem abstrata para descrever outras linguagens e é também conhecido como meta-meta-modelo (nível M3). As linguagens abstratas descritas a partir do MOF são chamadas de meta-modelo (M2) [Matula 2003]. Um exemplo dessas linguagens abstratas é o meta-modelo da UML, sendo que cada modelo UML está no nível M1. O padrão XMI permite o intercâmbio de dados entre ferramentas de modelagem, baseadas em UML, com repositórios de modelos, baseados no MOF, em ambientes heterogêneos e distribuídos. A especificação JMI permite a geração de interfaces em linguagem Java para um determinado meta-modelo MOF (M2), tornando possível a manipulação de instâncias deste meta-modelo. O meta-modelo da UML, por exemplo, é descrito a partir do MOF. Através do JMI, é possível manipular os elementos da UML (Classe, Interface, Atributo,...) como objetos Java, através das interfaces geradas. Esse tratamento pode ser adotado não somente para a UML, mas para qualquer meta-modelo baseado no MOF. O MDR [Matula 2003] é um repositório que implementa os padrões MOF e JMI, o que permite carregar meta-modelos baseados no MOF, e armazenar instâncias (M1) desses meta-modelos. As instâncias armazenadas no repositório podem ser manipuladas programaticamente, utilizando as interfaces geradas a partir do padrão JMI.

3 3. Abordagem Odyssey-MDA A abordagem Odyssey-MDA permite ao desenvolvedor realizar a transformação dos modelos de componentes independentes de plataforma, conhecidos como PIM (Platform Independent Model), em modelos específicos para uma plataforma em particular (PSM Platform Specific Model) e, posteriormente, obter a implementação destes componentes. Basicamente, esse processo consiste na realização das seguintes etapas: a) Definição de plataformas e transformações O desenvolvedor define as plataformas desejadas e as transformações necessárias para que os modelos PIM sejam transformados em modelos específicos (PSM) para essas plataformas. b) Modelagem inicial dos componentes A modelagem dos componentes é realizada de forma independente da plataforma onde esses componentes serão implementados. c) Marcação do modelo interno dos componentes Os elementos do modelo interno dos componentes (modelo de classes) são preparados com um mecanismo de marcação para guiar a realização das transformações posteriores. d) Escolha da plataforma e execução de transformações O desenvolvedor escolhe uma plataforma previamente definida. As transformações são aplicadas sobre o modelo previamente marcado para a obtenção do PSM para a plataforma escolhida. e) Geração da implementação Uma representação em código fonte do modelo PSM pode ser gerada na linguagem de programação da plataforma. Conforme é apresentado na Figura 1, o cenário típico de utilização da abordagem considera o desenvolvedor elaborando o seu modelo inicial em uma ferramenta CASE ou ambiente de modelagem de sua preferência. Figura 1. Cenário de utilização da Odyssey-MDA Conforme apresentado na Figura 1, através de uma ferramenta CASE, ambiente de modelagem ou ambiente de reutilização, o desenvolvedor deve realizar marcações sobre os elementos do seu modelo interno de componentes (modelo de classes), utilizando estereótipos ou etiquetas (tagged-values). Essas marcações são necessárias para que os mapeamentos mais adequados sejam selecionados, com o intuito de transformar tais elementos em elementos do modelo de saída. O conjunto de estereótipos e etiquetas possíveis para marcar o modelo é definido em função do objetivo da transformação a ser realizada, e pode ser baseado em algum profile da UML, como o UML Profile For EDOC [EDOC 2004]. Após a realização essas marcações, o desenvolvedor deve exportar o modelo de origem (PIM marcado) em formato XMI e importá-lo na máquina de transformações Odyssey-MDA, onde transformações podem ser executadas sobre o modelo de origem, resultando em um modelo de saída (PSM). O PSM gerado pode ser exportado também

4 em formato XMI, para posterior importação na ferramenta CASE inicial, ou transferência para algum gerador de código. A abordagem Odyssey-MDA permite ainda, a definição e execução de transformações bidirecionais. Neste caso, o desenvolvedor pode gerar um PSM a partir de um PIM (transformação direta ou forward), efetuar refinamentos e alterações no modelo PSM e propagar essas alterações de volta ao modelo PIM original (transformação reversa ou reverse). Essa propagação é feita de forma extensível, elementos já existentes no modelo de destino são atualizados pela transformação e não substituídos. Outras formas de resolução de conflitos relacionados à sincronização não são tratadas atualmente nesta abordagem [Gardner et al 2003]. Outro cenário de transformação reversa é a extração das informações independentes de plataforma de um modelo PSM, ou código fonte pré-existente, para a criação de um PIM. Isso seria bastante útil em casos onde um componente originalmente modelado de forma específica para a tecnologia onde foi implementado, tenha que ser migrado para outra tecnologia. 4. O protótipo desenvolvido Cada transformação definida é formada por uma especificação declarativa em XML e um conjunto de mecanismos. A especificação declarativa é responsável por definir os mapeamentos entre os elementos dos modelos de entrada e saída. Tais mapeamentos são definidos através de critérios de busca (finders) para a seleção dos elementos a serem transformados e pela atribuição de um mecanismo responsável pela realização da transformação desses elementos. Os finders são responsáveis por selecionar os elementos do modelo de entrada. Os elementos podem ser selecionados pelo nome, pelos estereótipos ou pelas etiquetas (tagged-values). Por exemplo, todas as classes que possuem o estereótipo <<entrada>> ou todas as classes cuja etiqueta persistent tenha o valor true. Os mapeamentos são específicos para cada tipo de elemento a ser mapeado. Para mapear subtipos de Classifier no meta-modelo da UML (ex: classes, interfaces), é proposto o mapeamento classifier-map. Para mapear subtipos de Features (ex: atributos e operações), é proposto o sub-mapeamento feature-map. Para mapear um Classifier para Feature, ou o contrário, é proposto o sub-mapeamento classifier-feature-map. A máquina de transformações Odyssey-MDA provê uma infra-estrutura de mecanismos genéricos, denominados built-ins, que realizam transformações simples sobre elementos UML. A Tabela 1 apresenta os built-ins existentes e qual a transformação efetuada por cada um. Por exemplo, as classes de um modelo PIM podem ser transformadas para classes, interfaces, atributos e operações no modelo PSM, conforme previsto nos built-ins 6, 7, 8 e 9 da Tabela 1, respectivamente. Tabela 1. Mecanismos genéricos de transformação (built-ins) Built-in Transformação Built-in Transformação 1. ComponentComponent Componente Componente 9. ClassOperation Classe Operação 2. ComponentClass Componente Classe 10. InterfaceInterface Interface Interface 3. ComponentInterface Componente Interface 11. InterfaceAttribute Interface Atributo 4. ComponentAttribute Componente Atributo 12. InterfaceOperation Interface Operação 5. ComponentOperation Componente Operação 13. AttributeAttribute Atributo Atributo 6. ClassClass Classe Classe 14. AttributeOperation Atributo Operação 7. ClassInterface Classe Interface 15. OperationOperation Classe Operação 8. ClassAttribute Classe Atributo

5 Como os built-ins são genéricos, deve existir uma forma para configurar os elementos manipulados por esses built-ins e assim, controlar o comportamento da transformação. Para transformar, por exemplo, uma classe em uma interface (ClassInterface), os atributos desses elementos, definidos no meta-modelo da UML, podem ser informados ao built-in através de um conjunto de propriedades. A Tabela 2 apresenta as propriedades possíveis para a configuração dos built-ins. Elemento manipulado Componente Classe Interface Atributo Operação Todos Tabela 2. Propriedades possíveis para configuração dos built-ins Propriedades isroot, isleaf, isabstract, isactive isroot, isleaf, isabstract, isactive isroot, isleaf, isabstract ownerscope, changeability ownerscope, isquery, concurrency, isroot, isleaf, isabstract, parameters name, nametransformation, stereotype, taggedvalues, visibility, isspecification Nos casos onde é necessário algum tipo de transformação textual sobre o nome dos elementos, a propriedade nametransformation pode ser utilizada para realizar tais transformações (substituições) através de expressões regulares, sendo possível, por exemplo, transformar o nome atributo em getatributo (transformação forward), ou o nome setatributo em atributo (transformação reverse). Na seção 5, um exemplo do uso dessa propriedade é apresentado. Para possibilitar a realização das transformações bidirecionais (PIM PSM), cada mecanismo implementa a interface Transformation que define as transformações em ambos os sentidos, através das operações transformationlefttoright e transformationrighttoleft. Por exemplo, no caso do mecanismo ClassInterface, a operação transformationlefttoright recebe uma Classe como parâmetro e retorna a Interface gerada a partir dessa Classe. Já a operação reversa (transformationrighttoleft) recebe uma Interface e retorna a Classe. Os built-ins disponíveis na máquina de transformações são até o momento suficientes para a definição de uma grande variedade de transformações entre os tipos suportados. Entretanto, podem existir casos onde o desenvolvedor necessita de alguma transformação não disponível. Neste caso, ele pode desenvolver seu próprio mecanismo (plug-in), que deve implementar a interface Transformation e manipular os elementos desejados através das interfaces JMI. 5. Exemplo de Utilização Para ilustrar o funcionamento da abordagem, é apresentado um exemplo de transformação que recebe como entrada o modelo de classes de um componente independente de plataforma (PIM) e gera um modelo de classes PSM desse componente na plataforma EJB (Enterprise JavaBeans). A Figura 2 apresenta o resultado da transformação executada sobre um modelo PIM recebido como entrada. A classe Cliente foi marcada previamente pelo estereótipo <<Entity>> e, de acordo com os padrões definidos pela plataforma EJB, foi transformada na classe ClienteBean, e nas interfaces Cliente e ClienteHome no modelo PSM de saída. Mudanças na classe ClienteBean podem ser propagadas de volta à classe Cliente no modelo PIM inicial, através da execução reversa da transformação, utilizando a operação transformationlefttoright da interface Transformation.

6 Figura 2. Resultado da transformação EJB sobre o modelo PIM As Figuras 3 e 4 ilustram a parte declarativa da transformação, a qual consiste de um documento XML contendo os mapeamentos entre os elementos, os finders (Figura 3) e as propriedades de configuração (Figura 4). A especificação do mapeamento da transformação (transformation-map) é composta por mapeamentos do tipo classifier-map. Cada mapeamento contém finders responsáveis por selecionar elementos nos modelos de origem e destino, de acordo com o atributo side. Na Figura 3, temos a especificação de um classifier-map (Entity- EntityBean) que utiliza o mecanismo genérico ClassClass. Este mecanismo transforma todos os classifiers encontrados pelo finder, que é responsável por selecionar elementos marcados com o estereótipo <<Entity>> no modelo de entrada (PIM). Ainda na Figura 3, são ilustrados outros exemplos de mapeamentos como o feature-map, responsável por realizar a cópia de atributos do elemento Entity para o EntityBean, e para a geração de métodos do tipo get e set para cada atributo do elemento de entrada. <transformation-map name="ejb Mapping"> <classifier-map name="entity-entitybean" implementation="classclass"> <finder side="left" type="stereotype" value="entity" /> <finder side="right" type="stereotype" value="entitybean" /> <feature-map name="copy attribute" implementation="attributeattribute">...</feature-map> <feature-map name="entitybean getter method" implementation="attributeoperation">...</feature-map> <feature-map name="entitybean setter method" implementation="attributeoperation">...</feature-map> </classifier-map> </transformation-map> Figura 3. Parte da especificação do mapeamento EJB (finders e feature-maps) Os mecanismos genéricos são independentes de plataforma, e por isso necessitam de configurações para guiar sua execução. Estas configurações são definidas no XML de especificação da transformação através das tags properties. Na Figura 4, são apresentadas algumas dessas tags. A tag nametransformation (forward) adiciona o sufixo Bean ao nome da classe gerada no modelo PSM. A segunda tag nametransformation (reverse), remove (através de substituição com expressão regular) o sufixo Bean para a geração do nome do elemento no modelo PIM. No exemplo da Figura 2, a classe Cliente é transformada para ClienteBean no modelo PSM. <property name="stereotype" value="entitybean" direction="forward" /> <property name="nametransformation" direction="forward" value="#classifier_name#bean" /> <property name="nametransformation" direction="reverse"> <property name="input" value="#classifier_name#" /> <property name="regex" value="(.*)bean$" /> <property name="subst" value="$1" /> </property> Figura 4. Parte da especificação do mapeamento EJB (propriedades de configuração do built-in ClassClass)

7 Além dos mapeamentos apresentados, ainda é possível especificar a criação dos relacionamentos (associação, generalização, realização, dependência) entre os elementos do modelo de saída gerado pela execução da transformação. Por restrição de espaço, neste artigo é dada maior ênfase ao mapeamento de componentes, classes, interfaces, atributos e operações. A Figura 5 mostra a interface gráfica da máquina de transformações Odyssey- MDA. Na árvore localizada no lado esquerdo da interface pode ser visto o modelo PIM, inicialmente desenvolvido e marcado em uma ferramenta CASE qualquer e importado via XMI. Após escolher a transformação desejada, o usuário pode selecionar os modelos de entrada, de saída e a direção da transformação (forward ou reverse). A transformação é, então, realizada e o modelo PSM pode ser exportado, em formato XMI, para uma ferramenta de geração de código como a Odyssey-MDA-codegen [Odyssey 2005], ou alguma outra ferramenta CASE qualquer. Figura 5. Modelos PIM e PSM na máquina Odyssey-MDA 6. Trabalhos Relacionados Dentre as abordagens existentes a respeito de transformações de modelos, destacam-se a Model Transformation Framework [MTF 2004], e a UML Model Transformation Tool [UMT 2004]. O MTF é um conjunto de ferramentas que apóia o desenvolvedor na realização de comparações, verificação de consistência e implementação de transformações entre modelos UML. A infra-estrutura de armazenamento e manipulação dos modelos é realizada em EMF (Eclipse Modeling Framework). A Odyssey-MDA, diferentemente do MTF, manipula modelos desenvolvidos em qualquer ferramenta CASE ou ambiente de desenvolvimento que utiliza os padrões MOF/JMI/XMI. O UMT é uma ferramenta para transformação e geração de código para modelos UML/XMI. No UMT, transformações são definidas em XSLT/Java e manipulam os modelos através de representações XMI simplificadas (XMI Light). Além disso, o UMT não suporta a definição de transformações bidirecionais. Czarnecki e Helsen (2003) propõem uma classificação de outras abordagens existentes de transformações entre modelos. As abordagens são classificadas em 5 principais grupos: manipulação direta, relacional, baseadas em transformações de grafos, dirigidas à estrutura e híbridas. Com base nessa classificação, a abordagem Odyssey-MDA é híbrida, pois combina características dirigidas à estrutura (built-ins) com manipulação direta (plug-ins).

8 7. Conclusão Este artigo apresenta a abordagem Odyssey-MDA a qual permite que modelos de componentes elaborados de forma independente de plataforma sejam transformados em modelos específicos para uma plataforma. A abordagem é apoiada pela máquina de transformações Odyssey-MDA, desenvolvida em linguagem Java, com as seguintes características: (1) independência de ambiente de desenvolvimento, pois utiliza XMI como formato de representação para transporte; (2) possibilidade de executar transformações bidirecionais; e (3) facilidade de extensão, provendo mecanismos genéricos (built-ins) e a possibilidade de definição de novas transformações (plug-ins). Atualmente, a máquina de transformações Odyssey-MDA utiliza modelos UML, mas futuramente espera-se que seja possível transformar qualquer modelo, cujo metamodelo seja baseado no MOF. Está sendo desenvolvido um exemplo completo de transformações de um modelo de classes PIM em um modelo EJB. O modelo EJB gerado pode ser utilizado em conjunto com outras ferramentas de geração de código e engenharia reversa, representando assim uma solução mais ágil ao desenvolvimento de software. É previsto ainda um estudo de caso para avaliar a máquina de transformações em situações reais. Referências Czarnecki, K., Helsen, S. (2003) Classification of Model Transformation Approaches. Proceedings of the 2nd OOPSLA Workshop on Generative Techniques in the Context of the Model Driven Architecture, USA, EDOC (2004) UML Profile For Enterprise Distributed Object Computing (EDOC) specification, OMG. Gardner, T., Griffin, C., Koehler, J., Hauser, R A Review of OMG MOF 2.0 Query / Views / Transformations Submissions and Recommendations towards the final Standard. OMG Document: ad/ JCP (2004) Java Metadata Interface (JMI) API 1.0 specification, Disponível em acesso em 23/09/2005. Kleppe, A., Warmer, J., Bast, W. (2003) MDA Explained: The Model Driven Architecture Practice and Promise. Boston, MA, Addison-Wesley, Matula, M. (2003) NetBeans Metadata Repository, Disponível em acesso em 23/09/2005. MDA (2003) Model Driven Architecture, OMG, Disponível em acesso em 23/09/2005. MOF (2002) Meta Object Facility (MOF) specification, version 1.4, OMG. MTF (2004) Model Transformation Framework, Disponível em acesso em 23/09/2005. Odyssey (2005) Disponível em acesso em 27/09/2005. Sametinger, J. (1997) Software Engineering with Reusable Components. Springer, UMT (2004) UMT-QVT UML Model Transformation Tool, Disponível em acesso em 23/09/2005. XMI (2002) XML Metadata Interchange (XMI) specification, v1.2, OMG.