FOMDA ML: uma Linguagem de Modelagem para Especificação de Transformadores de Modelos na MDA
Fabio Paulo Basso1, Raquel Mainardi Pillat1, Toacy Cavalcante Oliveira2, Samy Lima Assy1
1ADAPIT– Av. Ipiranga, 6681, Prédio 94 Sala 16, Partenon – Porto Alegre, RS – Brasil {fabio,raquel, samy}@adapit.com.br
2David R. Cheriton School of Computer Science, University of Waterloo – Canadá toacy@acm.org
Abstract. Some agile solutions to software development are extensions of the MDA framework. Features-Oriented Model-Driven-Architecture (FOMDA) is one of such solutions. It defines useful models to specify model transformers and organize it in transformation processes. Such paper presents a domain specific modeling language named FOMDA ML as a complement to the FOMDA approach and also shows a support tool to model transformations using the FOMDA ML.
Resumo. Algumas soluções para agilizar o desenvolvimento de sistemas são baseadas na MDA. Features-Oriented Model-Driven-Architecture (FOMDA) é dessas soluções.
Ela define modelos úteis para especificar transformadores de modelos e para organizá- los em processos de transformação. Este artigo apresenta uma linguagem de domínio específico (denominada FOMDA ML) como um complemento da abordagem FOMDA e uma ferramenta de suporte para esta linguagem.
Keywords: MDA, DSML, features model, mappings and transformations.
1. Introdução
A Model Driven Architecture [6] (MDA) permite agilizar o desenvolvimento de aplicativos. No entanto, existem algumas lacunas relacionadas com a gerência de transformadores de modelos. Uma solução para preencher estas lacunas é apresentada pela abordagem FOMDA (Features-Oriented Model-Driven-Architecture) [3] [4]. Este artigo apresenta uma contribuição para tal abordagem. Trata-se de uma linguagem de modelagem de transformadores de modelos que simplifica o uso da FOMDA.
Durante o uso da FOMDA identificou-se a necessidade de uma linguagem mais simples para projetar transformadores, mas que representasse as mesmas informações desta abordagem. A FOMDA define um perfil UML para modelar os transformadores, o que torna o projeto um tanto carregado. Para obter melhor produtividade e clareza nos projetos de transformadores foi necessário desenvolver uma Linguagem de Modelagem de Domínio Específico (DSML). Esta linguagem é denominada como FOMDA Modeling Language (FOMDA ML) e complementa os trabalhos [3][4].
O restante do trabalho está organizado como segue. A Seção 2 introduz e relaciona a abordagem FOMDA com o presente trabalho. A Seção 3 apresenta a FOMDA ML e a Seção 4 apresenta a validação, as restrições da solução e os trabalhos futuros. As conclusões são apresentas na Seção 5.
2. Trabalho em Andamento: A Abordagem FOMDA
O principal objetivo ao utilizar a abordagem FOMDA é definir transformadores de modelos adaptáveis a mudanças na configuração de arquiteturas/plataformas. Um
exemplo dessa mudança é substituir, na camada de aplicação, uma biblioteca ou framework. Os transformadores são especificados utilizando o diagrama de atividades da UML. Um projeto simples de transformadores permite aos usuários aplicar transformações de modelo para modelo (M2M) e de modelo para código (M2C) [4][5].
Outro mais complexo permite configurar um ambiente em que os usuários são guiados pelo sistema executor durante o processo de transformação [3].
FOMDA apresenta os mapeamentos e transformações na forma de um projeto de transformadores e oferece uma visão mais clara do processo de transformação do que é oferecida por abordagens como QVT [6]. A Figura 1 apresenta o tipo de problema que a abordagem FOMDA soluciona. No topo desta figura (canto esquerdo), é apresentado um exemplo que demonstra a necessidade de se desenvolver uma aplicação em muitas camadas. O exemplo mostra que a camada remota é opcional enquanto as demais são obrigatórias. Cada camada, quando utilizada, requer o uso de determinadas tecnologias que são exemplificadas abaixo da seta número 1. Três arquiteturas relacionadas com Java podem compor uma aplicação de acordo com as camadas utilizadas nesse exemplo.
Figura 1. O Problema Relacionado com as Plataformas na MDA
No canto direito da Figura 1 é apresentada uma solução para transformações de modelos com base na MDA. No topo (canto direito) desta figura, um modelo de entrada, em uma visão independente de plataforma, é ilustrado. Este é composto por uma classe, uma tabela, um formulário e um diagrama de atividades. Utilizando o transformador M2M1 é possível gerar um modelo específico de plataforma (ou de arquitetura). Esta pode ser formada pela primeira arquitetura mostrada no canto inferior esquerdo da Figura 1. O transformador M2M2 pode gerar um modelo específico de plataforma para a segunda arquitetura. Os transformadores M2C1 e M2C2 devem receber como entrada um modelo específico de plataforma e gerar código para a aplicação.
A MDA apresenta sugestões interessantes para desenvolver transformadores de modelos. O problema é que em sua definição não existe um formalismo que dite como as transformações, que acrescentam detalhes dependentes de plataformas em modelos de
1
2
3
sistemas, devem ser desenvolvidas e executadas. Ela também não define um formalismo que possa ser utilizado para especificar a ordem com que os transformadores são utilizados. A abordagem FOMDA resolve essas lacunas da MDA.
A FOMDA recomenda o Modelo de Features para identificar plataformas e disponibiliza extensões no diagrama de atividades da UML que podem ser utilizadas para documentar os transformadores de modelos e para descrever os fluxos de execução dos transformadores. Para especificar os transformadores e o fluxo de execução, também chamado de processo de transformação de modelos, a FOMDA recomenda o uso de um workflow. Na FOMDA, o projetista de transformações e o arquiteto de software focam na melhoria dos processos de produção com a MDA, utilizando um modelo para gerência de configurações que é integrado com os transformadores de modelos. O objetivo principal é automatizar a produção de sistemas e moldar a fábrica de software para mudanças nas arquiteturas de desenvolvimento de software.
A definição de um modelo para gerenciar configurações de arquiteturas é a primeira das etapas definidas na FOMDA e é realizada por um arquiteto de software. Ele precisa identificar quais são as tecnologias, padrões de projeto, padrões de codificação, que configuram possíveis arquiteturas de desenvolvimento de sistemas. A Figura 1 (topo e canto esquerdo) apresenta algumas informações vinculadas com desenvolvimento em muitas camadas e com tecnologias Java para plataformas web e desktop. Na FOMDA estas informações podem ser especificadas em um modelo de gerência de configuração e são chamadas de características de plataformas.
A Figura 2 apresenta um modelo de plataformas para gerenciar configurações como uma visão PDM (Platform Description Model) da MDA. Ele é um modelo de features que identifica características utilizadas para o desenvolvimento de sistemas nas camadas de aplicação apresentadas na Figura 1. As informações definidas na Figura 2 devem ser utilizadas para mapear e transformar qualquer modelo de um sistema, de qualquer domínio funcional, de uma visão PIM para outra visão PSM.
Figura 2. PDM/MF Usado para o Desenvolvimento de Sistemas Comerciais
Com o PDM especificado, o arquiteto pode configurar e/ou desenvolver os transformadores de modelos que pretende utilizar para transformar modelos de sistemas.
Isto será realizado sempre quando uma nova aplicação for desenvolvida e esta requerer uma configuração diferente de uma arquitetura/plataforma marcada no PDM. Esta configuração ocorre quando o projetista seleciona as características do modelo, marcando-as como mostrado na Figura 2 (canto inferior esquerdo). As características em destaque compõem uma plataforma alvo: A camada remota da aplicação é realizada com Http; Swing, Tiles e JSTL são tecnologias utilizadas na camada de apresentação;
Spring é a tecnologia utilizada na camada de negócios. Assim, as informações selecionadas no PDM determinam o que utilizar para desenvolver uma aplicação e, portanto, especifica detalhes para transformar um PIM em um PSM.
3. FOMDA ML – Uma Linguagem de Modelagem para a FOMDA
A FOMDA ML foi elaborada para facilitar as tarefas de definir transformadores flexíveis às mudanças arquiteturais e de compô-los dinamicamente. Antes dessa linguagem, tal tarefa era realizada com marcações em diagramas de atividades. Isto tornava o projeto dos transformadores carregado demais, o que dificultava a leitura e a composição dos transformadores. A FOMDA ML resolveu este problema. Ela é utilizada na abordagem depois de definir o PDM, em que é necessário identificar os mapeamentos que podem ser feitos de um modelo fonte para um modelo alvo ou de um modelo fonte para o código relacionado com uma característica. Por exemplo, a característica JSTL selecionada no PDM da Figura 2, pode determinar o mapeamento de um formulário (modelo fonte mostrado no topo e canto direito da Figura 1) para um código HTML que utiliza marcações específicas dessa tecnologia.
O projetista dos transformadores deve analisar as características do PDM com a finalidade de utilizá-las em transformações de modelos. Ele deve especificar um projeto de transformadores de modelos que combina transformações com as características definidas no PDM. Em [3][4] este projeto é realizado utilizando um workflow de baixo nível, ou seja, um diagrama de atividades que descreve a composição de transformadores, porém este não é o meio mais simples para modelar os mesmos. A FOMDA ML foi elaborada para facilitar a modelagem de transformadores de modelos.
Um transformador de modelos na FOMDA tem no mínimo um parâmetro de entrada, um algoritmo de transformação e uma saída [4]. No canto direito da Figura 2 é apresentado o modelo de um transformador elaborado com a FOMDA ML, que equivale ao workflow de baixo nível mencionado acima. Este modelo demonstra que para executar a transformação é necessário um parâmetro de entrada (elemento identificado como entrada) do tipo GUILayout.ScreenArea. A saída de um transformador pode ser qualquer tipo definido na UML ou na linguagem de transformação de modelos usada na ferramenta de MDA.
Para viabilizar o reuso de transformadores de modelos, a abordagem FOMDA recomenda o desenvolvimento de um transformador genérico. Assim, quando é necessário realizar uma transformação específica para uma determinada característica, este transformador requisita a execução de outros transformadores. O objetivo do projetista de transformadores é desmembrar o máximo possível os trechos dos algoritmos dos transformadores que aplicam transformações específicas para uma característica do PDM. Algoritmos de transformação são escritos em linguagens de transformação de modelos. Um exemplo de transformador genérico é identificado na Figura 3 como “Gerar formulário web”. Este pode requisitar a execução do transformador “JSTL Transformer”, quando a características JSTL estiver marcada no
PDM, e executar o transformador “Tiles Transformer”, quando a característica Tiles estiver selecionada.
O transformador da Figura 3 possui um parâmetro de entrada (um formulário) e os dois outros elementos do modelo, que contém números, são pontos de especialização.
Um ponto de especialização é um parâmetro de um transformador que define o tipo de um objeto que será disponibilizado para outros transformadores. O ponto de especialização 1 define que o transformador “Gerar formulário web” disponibiliza nele objetos do tipo GUILayout.Component.
Figura 3. Pontos de Especialização de Transformadores
Além disso, um ponto de especialização pode executar outros transformadores de modelos. Para isso, ele define o tipo de retorno do transformador a ser executado e também o parâmetro de entrada que o mesmo deve conter. Assim, para poder ser executado por um ponto de especialização, um transformador de modelos deve conter um parâmetro de entrada que seja, ao mesmo tempo, uma instância do tipo definido no ponto e que possua o mesmo tipo de retorno. Logo, um transformador somente será executado pelo ponto de especialização 1 se este tiver um parâmetro de entrada que seja instância de “GUILayout.Component” e se o seu retorno for declarado como “String”.
Portanto, os pontos de especialização são úteis para desmembrar uma transformação específica para uma característica do PDM.
Na FOMDA, também são utilizadas consultas para executar transformadores de modelos. A Figura 4 apresenta uma consulta estereotipada com <<Query>>, que foi adicionada no ponto de especialização 1. Esta consulta testa se a característica JSTL está selecionada no PDM, para chamar então a execução do transformador “JSTL Transformer”. O uso de consultas em modelo foi exemplificado em [4], utilizando os workflows definidos na abordagem FOMDA.
Figura 4. Delegando Transformações com Queries
A consulta exemplificada na Figura 4 é executada pelo ponto de especialização 1.
Esta, por sua vez, executa o transformador “JSTL Transformer” somente se este está em conformidade com o tipo do ponto de especialização e com o tipo de saída dele.
Transformador e ponto de especialização estão em conformidade e, portanto, o uso do
transformador “JSTL Transformer” no ponto de especialização “componente” é permitido. Outra maneira de definir a execução de um transformador por um ponto de especialização é apresentada na Figura 5. A relação de realização da UML foi utilizada para indicar que o Transformador “Tiles Transformer” especializa o ponto 2. A relação é possível de ser estabelecida porque o transformador contém um parâmetro de entrada do mesmo tipo do ponto de especialização e o retorno de ambos é igual.
Figura 5. Delegando Transformações com Relação de Especialização de Pontos e Uso de Variáveis Compartilhadas
Outra possibilidade para transformadores de modelos na abordagem FOMDA é o uso de variáveis compartilhadas. À direita da Figura 5 o transformador “Generates Java GUI Layout” compartilha uma variável, o que significa dizer que ele disponibiliza um objeto para ser utilizado por outros transformadores. Parâmetros de entrada de outros transformadores podem fazer uso do dado contido na variável compartilhada. No workflow de baixo nível da abordagem FOMDA isso é realizado utilizando uma transição estereotipada com <<LinkedValue>>, de um parâmetro de entrada para uma variável compartilhada. Na FOMDA ML utiliza-se uma dependência.
Parâmetros de entrada podem conter também uma dependência pelo retorno de um transformador de modelos. A Figura 6 apresenta um exemplo em que o parâmetro de entrada denominado “guiPSMClass” depende do resultado do transformador “Generates Java GUI Layout”. Nos casos em que se utiliza dependência de valores por variável compartilhada ou por retorno de transformadores, a execução do transformador dependente implica na execução do transformador que disponibiliza o resultado ou a variável. No exemplo da Figura 6 o transformador “ScreenArea mapping to Swing type 2”, ao buscar o valor contido no parâmetro “guiPsmClass”, executa o transformador
“Generates Java GUI Layout”. Este, ao concluir a transformação retorna o resultado que é armazenado pelo parâmetro “guiPsmClass”, que é então utilizado pelo primeiro transformador.
Figura 6. Dependência pelo Retorno de um Transformador
3.1 Uma Ferramenta de Suporte para a FOMDA ML
O sistema WorkCASE Toolkit (WCT) oferece suporte à linguagem FOMDA ML. Ele foi utilizado para validar a solução apresentada nesse artigo. O mesmo é de licença comercial, mas uma versão de uso gratuito para a academia está sendo elaborada. A Figura 7 (A) apresenta o objetivo principal do sistema, que é apoiar o desenvolvimento dirigido por modelos em fábricas de software. No WCT é possível especificar as camadas de aplicação apresentadas na Figura 1, a partir de um modelo de domínio simples, sem marcações. Usando o WCT, engenheiros de softwares são habilitados ao desenvolvimento rápido de aplicações, utilizando uma série de facilitadores que auxiliam na definição de detalhes na transformação PIM 0 -> PIM 1 -> PSM, como:
formulários e interfaces gráficas de usuário, mapeamento objeto relacional, modelagem de classes de projeto, dentre outros.
Figura 7 – Ferramenta WorkCASE Toolkit
Na Figura 7 (B) e (C) são apresentadas duas telas do plugin WMTP, parte componente do sistema WCT relacionada com esse artigo. Este permite desenvolver os transformadores de modelos usando a FOMDA ML. A Figura 7 (B) apresenta um diagrama, em que é possível especificar um modelo de descrição de plataformas, um PDM. O plugin oferece também um diagrama para modelar os transformadores de modelos, apresentado na Figura 7 (C). Para mais informações sobre o sistema WorkCASE Toolkit consulte www.adapit.com.br.
4. Validação da Solução, Restrições e Trabalhos Futuros
A FOMDA ML foi utilizada no WCT para o desenvolvimento de transformadores de modelos na fábrica de software da empresa Adapit. Transformadores M2M e M2C foram desenvolvidos e mapeados para as características selecionadas no PDM, como sugere a abordagem FOMDA. Assim, durante a execução das transformações, transformadores especialistas, com detalhes de uma arquitetura, permitiram que o código gerado ao final de cada iteração do processo de desenvolvimento apresentasse tantos detalhes de implementação que, em poucos casos, foi necessária a intervenção do
desenvolvedor para complementar o código. A FOMDA ML também facilitou a adaptação dos transformadores para outra arquitetura, também baseada em Java.
Os transformadores de modelos foram desenvolvidos para a WCT em uma linguagem própria para transformadores de modelos, desenvolvida para operar com a FOMDA ML. Linguagens de modelagem para composição de transformadores foram apresentadas e comparadas nos trabalhos [3] e [4]. Linguagens gráficas como UMLX, QVT e ATL são utilizadas para especificar o algoritmo dos transformadores e não possuem relação com a FOMDA. Pretende-se utilizar estas e outras linguagens e testar a execução de transformadores desenvolvidos em linguagens distintas. Neste sentido, um aspecto ruim da FOMDA ML é que transformadores desenvolvidos com base em XSLT não podem ser utilizados nos processos de transformação. Na FOMDA ML existe a necessidade de a ferramenta de MDA converter especificações textuais UML em elementos baseados no MOF.
Um estudo para integrar os processos de transformação de modelos, definidos com a FOMDA ML, com processos de desenvolvimento de software definidos com o SPEM está sendo desenvolvido. O objetivo do estudo é estender a FOMDA ML para integrar processos organizacionais com os processos de produção baseados em modelos. A conclusão desse estudo permitirá automatizar processos de desenvolvimento de software, trazendo maior agilidade nas etapas de produção. O estudo também prevê uma integração de melhorias de processos para os requisitos nos níveis F e G da MPS-Br com os processos de produção baseados em modelos definidos com a FOMDA ML.
5. Conclusões
O presente trabalho apresentou uma linguagem de domínio específico para especificar transformadores de modelos usando a abordagem FOMDA. Esta abordagem possibilita que detalhes de sistemas sejam representadas como características de um Modelo de Features. Estas podem ser mapeadas para transformações, o que significa que permitem executar transformadores de modelos específicos para uma configuração de plataforma.
Os transformadores de modelos foram elaborados utilizando a FOMDA Modeling Language (FOMDA ML). O uso desta linguagem facilitou o uso da abordagem FOMDA, pois simplificou a tarefa de desenvolver os transformadores de modelos, de compô-los dinamicamente e de mapeá-los para diversas arquiteturas.
Referências
[1] B. Tekinerdogan, S. Bilir, and C. Abatlevi. Integrating Platform Selection Rules in the Model Driven Architecture Approach. In Proc. of MDA-FA, June 2004. pp 184-200.
[2] C. Kang et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study (CMU/SEI-90-TR-21).
Software Engineering Institute, Carnegie Mellon University. Pittsburg, PA. November, 1993.
[3] F. Basso, L. Becker, T. Oliveira. Using the FOMDA Approach to Support Object-Oriented Real-Time Systems Development; In Proc. of ISORC 2006.
[4] F. Basso, L. Becker, T. Oliveira. Uma Solução para Reuso e Manutenção de Transformadores de Modelos Usando a Abordagem FOMDA. In: SBES, 2007, João Pessoa.
[5] K. Czarnecki K., H. Simon. Classification of Model Transformation Approaches. In Proc. of OOPSLA’03 Workshop on Generative Techniques in the Context of MDA; 2003
[6] Object Management Group MDA Specifications. October 2004. Available at <http://www.omg.org/
/mda/specs.htm>.
