Antes de estudarmos os Modelos Dirigidos à Arquitetura (Model Driven Arquitecture – MDA) devemos entender o que é um modelo. Um modelo é uma abstração da realidade, que podem ser utilizados para descrever visões de sistemas sem ambiguidades. Um exemplo de uma linguagem que constrói modelos é a UML (Unified Modeling Language).
Existem dois tipos de modelos: Modelos de negócio e Modelos de software. Um modelo de negócio também é chamado de CIM (Computational Independent Model) porque ele não é necessariamente totalmente ligado a ou suportado por software, diferente de modelos de software que são suportados e permitem entre outras coisas gerar código.
Outros dois tipos de modelo são: o modelo dinâmico e o modelo estático. O modelo dinâmico descreve as visões dinâmicas de um software como, por exemplo, os modelos de diagramas de estados ou de sequencia da UML. Enquanto que os modelos estáticos descrevem visões estáticas de um software, como, por exemplo, os diagramas de classes da UML.
Por fim, temos também um Modelo Independente de Plataforma (PIM- Platform Independent Model) e um Modelo Específico de Plataforma (PSM - Platform Specific Model) que é voltado para uma determinada plataforma ou tecnologia. Através desses modelos independentes de tecnologia, como é o caso da UML, podemos gerar um modelo mais especifico de plataforma, como um modelo EJB, e através deste último poderíamos gerar código direto para a plataforma. A Figura 1 mostra como isso poderia ocorrer.
Figura 1. Exemplo de como ocorre a transformação de um PIM para um PSM e do PSM para código.
Normalmente as definições são um conjunto de regras que definem como as construções de uma linguagem são traduzidas em construção para outra linguagem. Dessa forma, uma das principais propriedades de transformações é que elas devem preservar semântica do modelo.
As transformações não se resumem apenas em transformar modelos em outros modelos mais específicos ou em código, mas também são consideradas transformações a engenharia reversa, migração, otimizações e refatorações.
Segue na Figura 2 um exemplo de uma transformação de um PIM para um PSM,
Figura 2. Transformando um PIM para um PSM.
Apesar dos dois modelos Cliente serem descritos usando a mesma linguagem, ou seja diagrama de classes UML, tem-se que o PSM é mais específico porque incorpora decisões que não dizem respeito ao problema em si, mas à maneira mais adequada de implementar um diagrama de classes.
O Modelo Dirigido a Arquitetura (Model Driven Architecture - MDA) é um framework para desenvolvimento de software definido pela OMG (Object Management Group) que é baseado na noção de modelos, onde o desenvolvimento e a evolução dos sistemas são guiados pela construção e transformação de modelos.
Conforme exemplificamos anteriormente o MDA é composto por dois modelos: o PIM (Platform Independent Model) que possui um alto nível de abstração e é independente de tecnologia, e o PSM (Platform Specific Model) que é dirigido a uma tecnologia específica e cada PIM pode ser transformado em uma ou mais PSMs.
Entre as vantagens do MDA temos:
- Produtividade: onde o foco do desenvolvedor é o PIM e a escolha dos PSMs adequados e não o seu desenvolvimento.
- Portabilidade: onde é atingida focando o desenvolvimento em PIMs que são independentes de plataformas ou tecnologias.
- Interoperabilidade: onde é dada pelas relações entre PSMs, também chamadas de pontes em MDA.
- Manutenção e Documentação: onde o código é gerado a partir do PSM, que por sua vez é gerado a partir do PIM. Dessa forma, o modelo abstrato (PIM) é a representação do sistema gerado, ou seja, é a documentação em alto-nível do código. Esta documentação nunca é abandonada, podemos gerar PSMs para novas tecnologias a partir do mesmo PIM, mantendo o código sempre consistente com a documentação.
No restante do artigo analisaremos mais de perto a ferramenta iUML, verificando o que ela nos oferece em termos de funcionalidades e quais são seus pontos positivos e negativos. Também analisaremos outras ferramentas open source disponíveis no mercado e faremos algumas conclusões de como está o desenvolvimento dessas ferramentas.
Analisando a iUML
O iUML fornece um ambiente único para construção e teste de modelos de sistema usando o "Executable iUML" (ou xUML) e inclui um poderoso gerenciador de requisitos, suporte a gerencia de configuração e capacidade multiusuário. O download do iUML está disponível no site da Abstract Soluctions. A iUMLite é a versão free do iUML. Segue na Figura 3 uma imagem mostrando a interface do iUML.
Figura 3. Ambiente do iUML.
No núcleo da ferramenta está o iUML Modeller que permite a entrada de modelos UML e descrições associadas. Além disso, a iUML mantém a consistência entre diferentes visões do mesmo elemento, eliminando assim a necessidade de entrar com a mesma informação duas vezes, mesmo quando múltiplos usuários estão editando o mesmo modelo.
Outro componente é o iUML Simulator que complementa o iUML Modeller e habilita a verificação do comportamento dos modelos e sistemas através da simulação no "UML Executable".
Como dito anteriormente o iUML oferece aos projetistas a habilidade de definir e verificar o comportamento do sistema com o "Executable UML" (xUML). Os modelos xUML tornam-se a única representação necessária para descrever o comportamento do sistema. Este comportamento pode ser testado e verificado através do iUML Simulator antes que qualquer código mais detalhado seja necessário. Dessa forma, os erros são identificados mais cedo no ciclo de projeto quando eles são mais fáceis de serem modificados e menos caros para corrigir.
iUML Simulator fornece um ambiente para teste e debug. Além disso, o iUML suporta todas as construções necessárias para que possamos de uma forma precisa e sem ambiguidade descrever e simular sistemas incluindo: casos de uso, diagramas de sequencia, diagramas de colaboração, gráficos de estado e diagramas de estado. Outro diferencial da ferramenta é a automatização, que permite a criação de diagramas a partir de outros diagramas, como, por exemplo, diagramas de colaboração a partir de gráficos de estados. Ele também compreende as regras do xUML e, portanto, impede o usuário de criar sintaticamente ou semanticamente modelos inválidos.
Outro componente da iUML é a linguagem Action Specification Language (ASL) que é utilizada para especificar um processamento mais detalhado no modelo como: ações, operações, sequencia de inicialização, loops e métodos de teste. Basicamente a ASL é inserida ao longo dos diagramas para especificar detalhes de como funciona o sistema. Este sistema de diagramas e os códigos ASL podem ser traduzidos em uma Platform Independent Model (PIM) executável que pode ser executado no iUML Simulator. O modelo pode posteriormente ser traduzido em um Platform Specific Model (PSM), em praticamente qualquer linguagem de programação. Segue na Figura 4 um exemplo do ambiente de desenvolvimento do ASL.
Figura 4. Ambiente de desenvolvimento ASL.
O PIM (Platform Independent Models) no iUML pode ser convertido automaticamente para um PSI (Platform Specific Implementation) numa linguagem de destino usando iCCG. Na próxima seção detalharemos mais o iCCG.
iCCG
O iCCG é uma estrutura geral de tradução de modelos implementado como um conjunto de modelos xUML. Ele fornece um framework que captura o projeto do software e o conhecimento do código nos modelos xUML. Segue na Figura 5 uma imagem explicativa sobre o funcionamento do iCCG.
Figura 5. Funcionamento do iCCG.
Utilizando o iCCG também podemos criar um gerador de código para um projeto específico, isso permite uma alta flexibilidade e sofisticação.
Dessa forma, o iCCG tem sido utilizado para construir geradores de código para uma ampla variedade de arquiteturas de sistema, variando de sistemas embutidos mais simples com um único processador até complexas redes com múltiplos nós.
Portanto, utilizando o iCCG, os usuários tem flexibilidade para:
- gerar o esqueleto do código e permitir completarmos o código manualmente;
- codificar diretamente no modelo da aplicação e usar o iCCG para montá-lo;
- codificar modelos com a linguagem independente de plataforma (ASL), e usar iCCG para gerar 100% do código alvo;
- modificar o iCCG para implementar múltiplas estratégias de codificação para alcançar diferentes tipos de otimizações do código alvo;
- traduzir modelos de aplicativos em qualquer formato intermediário exigido por ferramentas de desenvolvimento.
Pontos Positivos
Um ponto bastante positivo da iUML é a possibilidade das definições de um sistema serem traduzidas para qualquer linguagem até mesmo uma linguagem que ainda não exista.
Outra vantagem interessante é que apesar da ferramenta oferecer seis tipos de diagramas, apenas três diagramas são necessários para implementação e geração do código (Diagrama de Classe, Diagrama de Colaboração e Diagrama de Máquina de Estados).
Utilizar o iUML obriga os desenvolvedores a modelarem antes de codificar, o que é sempre recomendado.
Pontos Negativos
Infelizmente a ferramenta não é muito utilizada, pois não há muito material ou discussões acerca desta. O download da ferramenta é quase impossível de ser encontrada e aparentemente não tem mais suporte visto que a última release foi realizada em Abril de 2010 e possui suporte apenas para Windows 2000 Professional e Windows XP.
Grande parte dos problemas da iUML estão relacionados com a linguagem ASL. Entre os problemas estão:
- Chamadas a operações no ASL requer o nome e o número da operação, o que significa que uma pequena alteração em um diagrama pode exigir mudanças radicais na ASL. Essa situação pode piorar ainda mais, visto que os códigos da ASL podem ser inseridos em diversos lugares no modelo.
- Existem inúmeras peculiaridades na interface do iUML que torna o uso do programa extremamente frustrante.
- O ambiente de desenvolvimento para o ASL não é nada amigável, somente temos uma área para inserir textos e não temos autodetecção de nenhum tipo, nem mesmo erros de sintaxe.
- As mensagens de erro do ASL são complicadas de entender e os números de linha em que ocorrem os erros não condizem com as linhas onde realmente ocorreram os erros no código fonte.
Além disso, o iUML possui um número relativamente grande de bugs não corrigidos ainda.
iUML compreende um modelador e um simulador, onde o modelador permite a captura inteligente de uma plataforma independente, modelos UML executáveis com diagramas UML suportados pela Action Specification Language (ASL) e o simulador provê um ambiente de execução onde os modelos podem ser executados, depurados, visualizados e testados.
A iUML também suporta mapeamentos pré-definidos para uma implementação específica de plataforma que preserva a semântica da aplicação. Através do iCCG temos suporte a definição de mapeamentos configuráveis por usuários de uma PIM (Platform Independent Models) para uma PSI (Platform Specific Implementation). Os mapeamentos são especificados usando modelos UML executáveis.
Apesar de ter sido utilizada por grandes corporações nos seus primórdios a ferramenta possui muitos pontos negativos e não possui suporte desde o ano 2010 o que a torna obsoleta. A imensa quantidade de bugs e falta de funcionalidades como no ambiente da ASL nos remete a uma ferramenta ainda bastante imatura.
Outras ferramentas
Entre outras ferramentas temos a AndroMDA que é um framework de gerador de código, é um projeto open source e baseado na utilização de modelos UML exportados para o padrão XMI da OMG. O AndroMDA gera componentes Java e permite a utilização de plug-ins que podem estender as funcionalidades da ferramenta. Um dos problemas desta ferramenta é que ela não suporta a modelagem diretamente na própria ferramenta, sendo necessária a utilização de outras ferramentas externas. Além disso, a AndroMDA é bastante dependente do padrão XMI, não tem uma sincronia tão perfeita entre o código e o modelo e a ferramenta está limitada apenas à geração de código Java. Outra situação que chamou a atenção é que a ferramenta tem como última versão o ano de 2012, o que parece estar descontinuada.
A ferramenta Mod4j (Model for Java ou Modelagem para Java) é um ambiente open source que suporta MDA, onde cada um dos modelos da ferramenta representa um PSM e como resultado temos um código gerado na linguagem Java. O Mod4j suporta quatro modelos: o Presentation Model que gera HTML e Servlets, o Service Model que gera Data Transfer Objects, Spring e Serviços Locais ou Remotos, o Business Domain Model que modela o domínio da aplicação gerando Serviços de Domínio e Configurações Spring, e o Data Contract Model que define objetos de transferência e gera Data Access Objects, Configurações Spring e Mapeamentos Hibernate. O ambiente de modelagem da ferramenta é integrada com a IDE Eclipse e também suporta a utilização do Maven. Também são permitidos pontos de extensão em cada camada, permitindo ao desenvolvedor especializar uma aplicação gerada automaticamente. Infelizmente a Mod4j tem como última documentação e atualização a data de 2010, o que também indica uma possível descontinuidade da ferramenta.
Outras duas ferramentas utilizadas para geração de código para plataforma Java que foram analisadas é a Taylor e a Acceleo. A Taylor gera código para plataforma J2EE, sendo caracterizada por ser um projeto open source e possuir uma boa quantidade de transformação para EJBs, JPA e JWS, no entanto, de forma semelhante às demais tem como última atualização no seu site o ano de 2011. Assim como as ferramentas discutidas acima a Acceleo também tinha uma boa proposta e uma boa quantidade de funcionalidade para geração de código Java, mas está obsoleta com diversos links desatualizados e outros quebrados na própria página principal da ferramenta.
Por fim, temos a EMF (Eclipse Modeling Framework) que é um framework para implementação de modelos estruturados com mecanismos de geração de código, a fim de manter o foco no próprio modelo e não nos detalhes de implementação. O projeto EMF é um conjunto de plug-ins que são aplicados no Eclipse.
O EMF transforma um modelo baseado em um subconjunto do diagrama de classes da UML em código-fonte Java. Além disso, possui um metamodelo denominado Ecore que descreve modelos e algumas funcionalidades que são utilizadas no código-fonte gerado como: notificação de mensagens, suporte a persistência, entre outros. Segue na Figura 6 uma imagem de como se dá essa transformação.
Figura 6. Visão geral da transformação do EMF.
Através do metamodelo Ecore podemos definir os seguintes elementos: EClass que representa a classe do diagrama de classes, EAttribute que representa um atributo da classe e possui um nome e tipo, EReference que representa a associação entre duas classes e EDataType que representa o tipo do atributo. Após estas definições do modelo, o EMF gera os skeletons e assinaturas de métodos para estas operações. Após isso o desenvolvedor implementa o comportamento destas operações. O EMF também disponibiliza um editor gráfico que permite a criação de modelos, recursos de arrastar e soltar elementos do metamodelo Ecore, adição atributos, tipo de dados, entre outras informações que irão gerar o código-fonte Java. Segue na Figura 7 um exemplo do editor gráfico.
Figura 7. Editor gráfico do EMF.
A EMF é muito simples e ágil na construção de modelos o que facilita a sua manipulação. O código-fonte gerado é conciso e simplifica a escrita do código. Além disso, o EMF oferece uma interface bastante rica e versátil com diferentes visões e permite importação de modelos gerados em outras ferramentas. Outro ponto positivo é que ela é mantida pela Fundação Eclipse, sendo assim constantemente evoluída.
Um ponto negativo da EMF é que ela apenas implementa um subconjunto da abordagem MDA. Dessa forma, o EMF não contém todos os mapeamentos necessários para implementar uma aplicação a nível corporativo como XML, EAI, WEB, EJBs, entre outras tecnologias que precisam ser utilizadas e combinadas. Portanto, a EMF ainda tem um longo caminho para ser considerada como um padrão de facto na indústria de software.
Apesar de ganharmos em produtividade, as ferramentas MDA open source em sua grande maioria não conseguiram continuar evoluindo com o passar do tempo. Além de obsoletas muitas estão abandonas e outras como a EMF oferece ainda pouquíssimos recursos para ser utilizada para softwares comerciais. Isso acaba produzindo certa dúvida da comunidade, afinal o que aconteceu com essas ferramentas, visto que o conceito de MDA está bem fundamentado e evoluído na comunidade acadêmica?
Bibliografia
[1] iUML Tutorial. Disponível em http://www.mif.vu.lt/~donatas/Vadovavimas/Temos/MDD/MDA/ExecutableUML/iUML_Tutorial.pdf
[2] Research Proposal : Strategy for Platform Independent Testing. Disponível em http://www.diva-portal.org/smash/get/diva2:533327/FULLTEXT01.pdf
[3] TESTING xUML: A STUDY OF IMPLEMENTING AND TESTING MODEL DRIVEN ARCHITECTURE. Disponível em http://etd.lib.umt.edu/theses/available/etd-11142008-131938/unrestricted/FlahertyDylan-Thesis.pdf
[4] iUML Modeller and Simulator. Disponível em http://www.kc.com/PRODUCTS/iuml/index.php
[5] Generate components quickly with AndroMDA. Disponível em http://www.andromda.org.
[6] Steinberg, D. EMF: Eclipse Modeling Framework, 2008.
