Você está na página 1de 23

Chapter

2

Engenharia Dirigida por Modelos: Abordagem e Aplicações

Denivaldo Lopes, Universidade Federal do Maranhão - UFMA

Abstract

Several paradigms were proposed to make face to the complexity of development, main- tenance and evolution of software systems. Structured programing, object oriented tech- nology, component technology, middleware technology and aspect programming are ex- amples of these paradigms. However, these paradigms have arrived to their limits and cannot provide support to the management of this complexity with efficiency. Recently, Model Driven Engineering has been proposed to make face to this complexity. In this new paradigm, the software development life-cycle is driven by formal models. Model Driven Architecture (MDA) of Object Management Group (OMG) and Eclipse Modeling Frame- work of Project Eclipse are examples of MDE. OMG proposes the creation of Platform Independent Model (PIM) and the transformation of this PIM in Platform Specific Model (PSM). In this minicourse, a study about the semi-automatic generation of mapping spec- ification and transformation definition generation is presented. In addition, examples of the application of MDE are presented.

Resumo

Ao longo dos anos, vários paradigmas foram propostos para gerenciarem a complexi- dade de desenvolvimento, manutenção e evolução de sistemas de software. Dentre estes paradigmas, pode-se citar Programação Estruturada, Tecnologia Orientada a Objeto, Tecnologia de Componentes, Tecnologia de Middleware e Programação por Aspectos. Entretanto, estes paradigmas não conseguem mais oferecer suporte ao gerenciamento desta complexidade com eficiência. Recentemente, a Engenharia Dirigida por Modelos (MDE - Model Driven Engineering) foi proposta para fazer face à esta complexidade cada vez mais crescente. Neste novo paradigma, o ciclo de vida de desenvolvimento de software é dirigido por modelos “formais”. A Arquitetura Dirigida por Modelos (MDA - Model Driven Architecture) da OMG (Object Management Group) e o framework EMF

(Eclipse Modeling Framework) do projeto Eclipse são exemplos de MDE. A OMG propõe basicamente a criação de modelos independentes da plataforma (PIM - Platform Inde- pendent Model) e a transformação destes PIMs em modelos específicos a plataforma (PSM - Platform Specific Model). Neste mini-curso, um estudo sobre a geração semi- automática de especificação de correspondência e a geração de definições de transfor- mação é apresentado. Além disto, exemplos da aplicação de MDE são discutidos.

2.1. Introdução

Recentemente, a indústria de software tem se defrontado cada vez mais com a complex- idade no desenvolvimento, manutenção e evolução de sistemas de software. Esta com- plexidade não se deve somente porque a quantidade de dados e código cresceu, mas sim porque os sistemas de softwares passaram a ser distribuídos e implementados em difer- entes plataformas.

Com o advento da Internet, os sistemas de software passaram a existir em um ambiente largamente distribuído e heterogêneo que estimulou ainda mais a difusão de sistemas de softwares. Neste novo contexto, novos requisitos começaram a aparecer e novas oportunidades começaram a surgir para a utilização de sistemas de software. Se por um lado, a indústria de software passou a receber uma alta demanda para a realização de novos projetos de sistemas de software ou a ser desafiada para evoluir sistemas de software existentes, por outro lado a indústria de software se deparou com um grau de complexidade para o desenvolvimento, manutenção e evolução de sistemas de softwares para o qual os paradigmas existentes não podiam mais oferecer soluções viáveis.

Dentre as razões que aumentaram a complexidade de desenvolvimento, manutenção e evolução de sistemas de software, pode-se enumerar [Bézivin et al. 2004]:

Os sistemas de software devem integrar novos aspetos, por exemplo, segurança, disponibilidade e performance desde o início da concepção do sistema até sua im- plantação, de forma uniforme;

Os clientes da indústria de software requisitam que seus sistemas de software evoluam mais rápido do que anteriormente. Estes devem evoluir não somente por que a lóg- ica do negócio e os requisitos do sistema mudam, mas também porque as platafor- mas tecnológicas estão constantemente evoluindo ou dando lugar a uma nova plataforma tecnológica. Estas mudanças estão acontecendo a uma velocidade nunca antes vista, sendo que a indústria de software é solicitada a fornecer sistemas de software com alta qualidade e em um curto espaço de tempo;

Embora novas tecnologias apareçam, tecnologias antigas não podem ser totalmente substituídas e, em geral, devem ser integradas com as novas tecnologias. Como conseqüência, os novos sistemas ou novas tecnologias devem ser concebidos para coexistir com os sistemas legados (legacy system).

Estes três fatores combinados criam uma situação sem precedentes que pode ser vista como a maior crise até então vista na indústria de software. Isto relembra a primeira crise de software no final dos anos 60 [Dijkstra 1972]. Naquela época, o desenvolvimento

de software estava se tornando uma tarefa complexa e de difícil gerenciamento. Até então, dava-se importância ao hardware, mas se passou a perceber que o software não podia ser deixado em segundo plano, pois estava se tornando cada vez mais complexo. Assim, uma mudança de postura foi necessária e resultou no surgimento de conceitos, metodologias e ferramentas para suportar a criação de sistemas de software, a partir de então a Engenharia de Software passou a ser concretizada [Sommerville 2008].

Ao longo dos anos, vários paradigmas foram propostos. Assim, a programação baseada em bits deu lugar a programação assembler (baseada em mnemônicos); a progra- mação assembler deu lugar a programação estruturada; a programação estruturada deu lugar a programação orientada a objeto; e esta última deu lugar aos componentes.

Nos anos 90, a indústria de software, organizações e a academia acreditavam que a solução para esta complexidade estaria nos middlewares. Desta forma, CORBA [OMG 2002] e DCOM [Microsoft 2004] foram propostos. Mais tarde, mesmo com o ad- vento dos Serviços Web [Martin et al. 2003], a complexidade ainda existia e acarretava projetos de sistemas de software mal sucedidos e dispendiosos. A partir de então, a academia e organizações perceberam que a solução não estava nos middlewares.

Afim de fornecer soluções racionais para suportar o gerenciamento desta complex- idade, a academia e organizações proporam abordagens baseadas em modelos. Um mod- elo pode ser definido como “uma abstração de um sistema físico que distingue o que é per- tinente do que não é com o intuito de simplificar a realidade” [Muller and Gaertner 2004]. Esta nova tendência tem resultado em MDE (Model Driven Engineering) [Favre 2004] [Fondement and Silaghi 2004] [Kent 2002] que pode ser definida como uma abordagem na qual modelos estão no centro do desenvolvimento, manutenção e evolução de soft- ware, permitindo a harmonização entre as diferentes tecnologias envolvidas e suportando diferentes domínios de aplicação. MDA (Model Driven Architecture) da OMG (Object Management Group) [OMG 2003a], Software Factories da Microsoft [Microsoft ] e EMF (Eclipse Modeling Framework) do projeto Eclipse [Budinsky et al. 2003] são exemplos de MDE.

A utilização de modelos para o desenvolvimento de sistemas de software não é algo novo. De fato, modelos estão sendo usados há algumas décadas para a con- cepção e projeto de sistemas de software. Nos anos 80 e 90, várias linguagens de mode- lagem como Booch, OMT e UML foram propostas e suportadas por ferramentas CASE [Sommerville 2008]. Entretanto, neste período, os modelos eram apenas usados nas fases iniciais de desenvolvimento de software. Logo que a codificação era iniciada, os mode- los eram esquecidos ou descartados, nem mesmo servindo como documentação, pois não tinham sincronia com o código final.

MDE trouxe uma proposta diferente da utilização de modelos, pois modelos pas- sam a ser usados em todas as fases do processo de desenvolvimento de software. Assim, cada modelo que é usado em uma fase pode ser projetado em outro modelo na fase subja- cente, adquirindo ou omitindo novas informações. Por exemplo, um modelo sem aspectos de plataforma pode ser usado na fase de projeto. Em seguida, uma transformação pode introduzir aspectos de uma determinada plataforma, e outra transformação pode gerar o código fonte na fase de implementação.

Um dos objetivos de MDE é suportar a separação entre interesses (concerns) que consiste em omitir determinados aspectos ou fazê-los aparecer dependendo das necessi- dades. Com o advento de MDE, alguns conceitos tomaram força tal como transformação de modelos, linguagem de transformação, metamodelos, processos e metodologias. UML (Unified Modeling Languages) e EDOC (Enterprise Distributed Object Computing) são linguagens de modelagem cuja especificação contém um metamodelo usado para permitir

a

criação de modelos. ATL (Atlas Transformation Language) [Jouault and Kurtev 2006]

e

QVT transformation language [OMG 2007] são exemplos de linguagens de transfor-

mação. A especificação dos relacionamentos entre o metamodelo de UML e um meta- modelo de Java é um exemplo de especificação de correspondência [Lopes 2005]. Várias metodologias baseadas em MDE são propostas na literatura [Lopes et al. 2006][Gavras et al. 2004].

Neste capítulo, MDE é apresentada, discutindo-se seus principais conceitos e tec- nologias. Alguns exemplos de aplicações de MDE são apresentados como desenvolvi- mento de Serviços Web, desenvolvimento de sistemas de informação médica, compartil- hamento de programação em larga escala para a TV Digital e garantia de interoperabili- dade entre os diferentes componentes de um Sistema de Detecção de Intrusão.

2.2. Conceitos básicos da Engenharia Dirigida por Modelos

Segundo o dicionário Hachette, um modelo é “algo proposto à imitação”.

No wikipedia, um modelo “apresenta apenas uma visão ou cenário de um frag- mento do todo. Normalmente, para estudar um determinado fenômeno complexo, criam- se vários modelos”. Embora esta definição seja muito generalista, ela dá uma idéia de imitação e simplificação de parte da realidade.

Na informática, diversos conceitos para modelo foram propostos. Um modelo “é uma abstração de um sistema físico que distingue o que é pertinente do que não é com

o intuito de simplificar a realidade. Um modelo contém todos os elementos necessários

à representação de um sistema real” [Muller and Gaertner 2004]. Um modelo é “uma

simplificação de um sistema e é criado com uma finalidade específica. O modelo deve ser capaz de responder as perguntas em lugar de um sistema em estudo. As respostas fornecidas pelo modelo devem ser as mesmas que aquelas fornecidas pelo sistema, a condição que as perguntas e respostas restem no limite do domínio definido pelo objetivo geral do sistema” [Bézivin and Gérard 2002]. Para [Kleppe et al. 2003], um modelo é “uma descrição de um (ou de uma parte de) sistema expresso em uma linguagem bem definida, isto é, respeitando um formato preciso (uma sintaxe) e um significado (uma semântica). Esta descrição deve ser conveniente para uma interpretação automatizada por computador”.

Embora diferentes conceitos possam ser encontrados na literatura para modelo, a maioria dos conceitos transmitem a mesma idéia: imitação do real, representação, sim- plificação, abstração e descrição limitada de um sistema. Observa-se também que um modelo é criado com um objetivo específico e dentro de um contexto particular. Assim, o

objetivo e o contexto são os elementos que irão dirigir as escolhas feitas durante a criação de um modelo. Um modelo não é uma descrição completa de um sistema, mas ele permite

a elaboração de ponderações sobre o sistema em estudo dentro de um contexto limitado.

Os modelos são necessários justamente por que eles permitem simular os sistemas físicos

antes de sua construção, fornecendo uma maneira simples, manipulável e econômica de prever os elementos de um sistema e de suas relações. Um modelo pode também ser de- duzido de um sistema existente ou de um sistema em desenvolvimento. Os modelos são essenciais para estabelecer uma comunicação eficaz entre os membros de uma equipe e entre as equipes implicadas em um projeto, e por assegurar a robustez arquitetural de um sistema em concepção ou em análise [Mellor et al. 2004] [Frankel 2003].

Diferentes tipos de modelos existem. Figura 2.1 mostra diferentes tipos de mod- elos: modelos físicos, modelos matemáticos, manequim e os modelos na informática (modelo UML). Neste capítulo, os modelos na informática constituem o foco deste es- tudo, em particular modelos no contexto de MDE.

y

Vy

22 2 V = Vx + Vy V Vx x
22
2
V = Vx + Vy
V
Vx
x

Modelo físico

de MDE. y Vy 22 2 V = Vx + Vy V Vx x Modelo físico

Manequins

Zoo Animal * * +dormir() Leão Tigre Urso dormir() dormir() dormir() { Sobre de costas
Zoo
Animal
*
*
+dormir()
Leão
Tigre
Urso
dormir()
dormir()
dormir()
{ Sobre de costas
{ Sobre uma árvore
{ Sobre o ventre
}
}
}

Modelo UML

Figure 2.1. Diferentes tipos de modelos

Um modelo para ser entendido por computadores e pessoas, deve ser criado “for- malmente”, isto é, deve seguir uma sintaxe e semântica bem definidas, evitando-se am- bigüidade e, permitindo tando a manipulação por pessoas quanto por computadores. Isto revela a necessidade de modelos formais. Uma linguagem de modelagem é que permite a criação de modelos. Assim, um modelo pode ser, por exemplo, concebido em uma linguagem matemática ou em uma linguagem gráfica.

Uma linguagem de modelagem é uma especificação formal bem definida que con- tém os elementos de base para construir modelos. Além disto, uma linguagem de mode- lagem é concebida dentro de um domínio limitado e com objetivos específicos. Assim, a existência de várias linguagens de modelagem parece ser razoável, cada uma sendo adap- tada a um domínio específico. UML e EDOC são exemplos de linguagem de modelagem. A linguagem concebida para criar modelos é frequentemente descrita por um metamod- elo, isto é, o que precede o modelo. Por sua vez, um metamodelo é “um modelo de uma linguagem de modelagem” [Favre 2004].

Um metamodelo é criado usando outras linguagens conhecidas como linguagem de metamodelagem. Cada linguagem de metamodelagem corresponde a um metameta- modelo. Um metametamodelo é “um modelo que define a linguagem para expressar metamodelos. A relação entre um memetamodelo e um metamodelo é similar à relação entre um metamodelo e um modelo” [OMG 2007]. Dentre as linguagens de metamode- lagem, destacam-se MOF (Meta-Object Facility) da OMG [OMG 2007] e Ecore do Pro- jeto Eclipse [Budinsky et al. 2003]. A relação entre modelo e metamodelo e a relação entre metamodelo e metametamodelo constituem a base da arquitetura a quatro-níveis, base para toda abordagem dirigida por modelos. A Figura 2.2 mostra a arquitetura a quatro-níveis.

self-described The MOF MMM Co n fo rms To Co n fo rms To Co
self-described
The MOF MMM
Co n fo rms To
Co n fo rms To
Co n fo rm sTo
The UPM MM
The UML MM
The CWM MM
Co n fo rms To
Co n fo rms To
A UML model
A UML model
m1
m2
Co n fo rm sTo
Co n fo rms To
A particular
use of m1
Another use of
m1
MMM
– Metametamodel
MM
– Metamodel
m
– model
Figure 2.2. Arquitetura a quatro-níveis de modelos
Level M0
Level M1
Level M2
Level M3

As relações entre o nível M3 e M2, o nível M2 e M1 e o nível M1 e M0 são do tipo ConformsTo (conforme à). Os níveis podem ser descritos como a seguir [Frankel and Parodi 2002] [Mellor et al. 2004]:

M3 (metametamodelo): o nível M3 constitui a base da arquitetura de metamode- lagem. A função primordial deste nível é definir linguagens para especificar meta- modelos. Um metametamodelo define um modelo de mais alto nível de abstração que o metamodelo, e este primeiro é tipicamente mais compacto que o segundo. MOF e EMF são exemplos de metametamodelos;

M2 (metamodelo): um metamodelo é conforme a um metametamodelo. A função principal do nível de metamodelo é definir uma linguagem para especificar mode- los. Os metamodelos são tipicamente mais elaborados que os metametamodelos. A linguagem UML possui um metamodelo que descreve estruturalmente como devem ser criados os modelos UML;

M1 (modelo): um modelo é conforme a um metamodelo. A função principal do nível de modelo é definir uma linguagem para descrever um domínio da informação. Por exemplo, um modelo de um sistema bancário utilizando a linguagem UML;

M0 (informação): os objetos de usuários representam as informações finais. A principal responsabilidade dos objetos de usuários é descrever um domínio da in- formática em específico em uma plataforma final. Por exemplo, o código fonte do sistema bancário.

Dentre os aspectos de MDE, pode-se citar:

“MDE tem sua ênfase nas pontes entre espaços tecnológicos e na integração de campos de conhecimento desenvolvido por diferentes comunidades” [Favre 2004];

“MDE é mais abrangente em escopo do que MDA. MDE combina processo e análise com arquitetura” [Kent 2002];

MDE propõe “um framework (1) para claramente definir metodologias, (2) para de- senvolver sistemas em qualquer nível de abstração, (3) para organizar e automatizar as atividades de teste e validação. Além disto, esta técnica assegura que qualquer especificação deve ser expressa por modelos, que são compreendidos por humanos e computadores” [Fondement and Silaghi 2004].

2.2.1.

Abordagens: MDA e EMF

MDA é uma proposta da OMG em que modelos estão no centro do desenvolvimento, manutenção e evolução de sistemas de software. MDA é “uma evolução do OMA para assegurar a integração e a interoperabilidade durante o ciclo de vida de um sistema desde o modelo do negócio (business modeling) e sua concepção até a construção de compo- nentes, a montagem, a integração, a implantação, a gestão e a evolução” [OMG 2001]. MDA permite separar as especificações das funcionalidades de um sistema (o PIM - Platform Independent Model) das especificações de plataforma de um sistema (o PSM - Platform Specific Model). A Figura 2.3 ilustra a descrição do metamodelo MDA.

<<based on>>

PIM Mapping Techniques

from Mapping PIM to PIM <<independant of>>

UML <<expressed with>>
UML
<<expressed with>>
MOF
MOF

<<expressed with>>

Other Languages
Other Languages

<<expressed with>>

1 1 * * <<are described with>> PIM 1 1 * * 1 1 *
1 1
* *
<<are described with>>
PIM
1 1
* *
1 1
* *
Metamodel
from Mapping PIM to PSM
1 1
* *
1 1
* *
<<are described with>>
PSM
1 1

<<based on>>

PSM Mapping Techniques

* *

from Refactoring PSM to PIM

<<depends on>>

Infrastructure
Infrastructure

from Mapping PSM to PSM

Figure 2.3. Descrição do metamodelo MDA [OMG 2001]

MDA é constituída de diversas tecnologias e especificações padronizadas pela OMG, dentre elas:

MOF (Meta-Object Facility): foi adotado em 1997 pela OMG. A especificação de MOF define uma linguagem abstrata e um framework para a especificação, a con- strução e o gerenciamento de metamodelos neutros de tecnologia. MOF também define um framework para a implementação de repositórios que contêm os metada- dos (i.e. modelos) descritos pelos metamodelos.

UML (Unified Modeling Language): é uma linguagem de modelagem baseada na Orientação a Objeto [OMG 2003c]. UML não é uma metodologia 1 de modelagem,

1 Uma metodologia serve para canalizar e ordenar a criatividade de pessoas que são responsáveis pela modelagem de uma aplicação.

mas pode ser utilizada em conjunto com a metodologia UP (Unified Process) ou RUP (Rational Unified Process). UML permite a modelagem de diferentes aspectos ou ponto de vista de um sistema. Para isto, UML contém:

diagramas que modelam aspectos estruturais:

diagrama de classe;

diagrama de objetos;

diagrama de componentes;

diagrama de implantação.

diagramas que modelam aspectos comportamentais:

diagrama de caso de uso;

diagrama de seqüência;

diagrama de colaboração;

diagrama de estado-transição;

diagrama de atividade.

OCL (Object Constraint Language): é uma linguagem formal para expressar re- strições. OCL complementa UML, pois permite inserir restrições nos modelos. É importante ressaltar que OCL não é uma linguagem de programação e não causa efeitos colaterais ao sistema [OMG 2003b];

XMI (XML Metadata Interchange): permite a troca de modelos serializados em XML. XMI é focalizado na troca de metadados conforme o MOF [OMG 2003d]. Embora XMI já esteja na versão 2.1, as ferramentas de modelagem em sua grande maioria ainda trabalham com XMI versão 1.2. O objetivo de XMI é permitir a seri- alização e troca de metamodelos conforme ao MOF e de modelos conforme a estes metamodelos na forma de arquivos utilizando dialetos XML. XMI permite também serializar metamodelos que são criados com outras linguagens de metamodelagem como Ecore. Isto é possível porque XMI não define um dialeto XML único, mas um conjunto de regras que permitem criar um DTD ou XML schema para diferentes metamodelos;

MOF QVT (MOF Query/View/Transformation): em 2002, a OMG iniciou um pro- cesso de padronização através de seu RFP MOF 2.0 Query/View/Transformation (QVT) para estimular a criação de uma linguagem de transformação de modelos padronizada. Uma dezena de submissões foi apresentada a OMG em resposta a este RFP, sendo que a proposta do grupo QVT-Merge foi retida como versão pre- liminar. Atualmente, há uma versão aceita do MOF QVT 2.0 [OMG 2007]. A especificação de MOF QVT 2.0 é baseada em MOF e OCL e possui os seguintes elementos principais:

Query: uma requisição é uma expressão que é avaliada sobre um modelo. O resultado de uma requisição é uma ou várias instâncias de tipos definidos no modelo fonte ou definidos pela linguagem de requisições. No contexto de MDA, OCL é a linguagem mais utilizada para fazer requisições;

View: uma vista é um modelo que é completamente derivado de um outro modelo. Uma vista não pode ser modificada separadamente de seu modelo do qual ela foi derivada. Uma requisição é um tipo restrito de vista gerado por transformações;

Transformations: uma transformação gera um modelo alvo a partir de um modelo fonte.

EMF é uma proposta do Projeto Eclipse para prover gerenciamento da complex- idade em sistemas de softwares [Budinsky et al. 2003] que fornece um framework de modelagem e de geração de código que suporta a criação de ferramentas e de aplicações dirigidas por modelos [Budinsky et al. 2003]. EMF é constituído de:

Ecore: é uma linguagem de metamodelagem que faz parte de EMF. A Figura 2.4 apresenta um fragmento do metamodelo de Ecore;

Plug-in para Eclipse: EMF é implementado como um plug-in para Eclipse, fornecendo um editor de modelos Ecore, i.e. metamodelos. Uma vez criado um modelo Ecore, este pode ser utilizado para gerar um outro plug-in que permite a edição de modelos conforme ao metamodelo criado;

JET: é uma linguagem de transformação para gerar código fonte a partir de um modelo Ecore. Esta linguagem possui uma sintaxe semelhante a JSP (Java Server Pages) que torna fácil a criação de templates que expressam o código que tem que ser gerado. JET possui um motor de template genérico que pode ser usado para gerar código em SQL, XML ou Java.

EModelElement EPackage ENamedElement +name : EString +ePackage +ePackage +eClassifiers +eClassifiers 0 0 * *
EModelElement
EPackage
ENamedElement
+name : EString
+ePackage +ePackage
+eClassifiers +eClassifiers
0 0 *
*
+eType +eType
EClassifier
ETypedElement
EStructuralFeature
0 1 0 1
0 * 0 *
EParameter
+eAlIOperations
+eAlIOperations
+eOperation
+eOperation
EOperation
0 * 0 *
0 * 0 *
+eParameters
+eParameters
+eOperations
+eOperations
+eContainingClass +eContainingClass
EAttribute
+eAttributes +eAttributes
+eAttributeType +eAttributeType
EDataType
0
0
*
*
EClass
+eReferences
+eReferences
EReference
0 0
* *
+eReferenceType +eReferenceType
+containment : EBoolean
+eSuperTypes +eSuperTypes
0
0
* *
+lowerBound : EInt
+upperBound : EInt
+eOpposite
+eOpposite
0 0 1
1
Figure 2.4. Metamodelo de Ecore [Budinsky et al. 2003]

MDA é baseado nas tecnologias e especificações da OMG e estimula a utilização de modelos UML e a criação de perfis UML. Embora perfis UML sejam uma extensão de

UML que introduzem novos aspectos, a linguagem UML é considerada a única linguagem de modelagem da OMG. Enquanto a abordagem adotada em EMF é a criação de novos metamodelos específicos ao domínio, estimulando assim a criação de linguagens especí- ficas ao domínio (DSL - Domain Specific Language). Uma DSL é uma linguagem de especificação ou linguagem de programação dedicada a um domínio particular, uma téc- nica de representação de problema particular ou a uma técnica de solução em específico [Cook 2004].

2.2.2. Linguagem Específica do Domínio

Linguagem Específica do Domínio (DSL) é uma linguagem de modelagem cuidadosa- mente projetada para facilitar a modelagem dentro de um domínio específico [Cook 2004]. Uma DSL pode ser criada para resolver problemas de vários domínios tal como teleco- municações, transporte público, exploração espacial, médico e química.

DSL permite atingir um nível de abstração além da programação para especificar

o sistema diretamente usando os conceitos do domínio [Lee and Chae 2006]. O objetivo

de DSL é gerar o sistema final a partir de especificações de alto nível. Uma DSL é uma linguagem voltada para atender as necessidades específicas de um domínio de problema particular e facilitar o desenvolvimento de soluções para este domínio [Wu et al. 2007]. Ao se utilizar uma DSL, objetiva-se assistir usuários finais para escrever programas mais concisos, descriptivos e indepentes de plataforma.

Se por um lado as DSLs permiterm caracterizar melhor um domínio, a garantia de

interoperabilidade entre a família de uma DSL é um desafio [Dib et al. 2008]. Uma abor- dagem para permitir a interoperabilidade é o desenvolvimento de tradutores para facilitar

a transformação entre as DSLs.

2.2.3. Transformação de modelos

A transformação de modelos pode ser definida como uma função:

modelB = trans f (de f Trans f , modelA, metaModelA, metaModelB)

onde:

trans f é a função que recebe como paramêtros uma definição de transformação (de f Trans f ), um modelo de entrada (modelA), o metamodelo utilizado para criar o mod- elo de entrada (metaModelA) e o metamodelo (metamodelB) usado para criar um novo modelo originado a partir do modelo de entrada (modelA). O retorno da função é o mod- elo de saída (modelB);

modelB é o modelo criado pela função trans f ;

de f Trans f é a definição de transformação que define quais elementos do meta- modelo de entrada (metamodelA) são mapeados nos elementos do metamodelo de saída (metamodelB);

modelA é o modelo de entrada;

metamodelA é o metamodelo usado para criar o modelo modelA;

metamodelB é o metamodelo usado para criar o modelo de saída modelB.

A definição de transformação é criada utilizando uma linguagem de transfor- mação. Esta define operacionalmente a transformação de um modelo fonte em um modelo alvo. Ela manipula elementos de modelos de acordo com os metamodelos utilizados na construção dos mesmos.

Várias características podem ser atribuídas a uma linguagem de transformação. A Figura 2.5 contém a descrição de uma taxonomia para linguagens de transformação proposta em [Czarnecki and Helsen 2003].

mandatory optional Model Transformation Directionality Transformation Rules Tracing Rule Application Scoping Rule
mandatory
optional
Model Transformation
Directionality
Transformation Rules
Tracing
Rule Application Scoping
Rule organization
Source-Target Relationship
Rule Scheduling
Rule Application Strategy

Figure 2.5. Taxonomia para linguagem de transformação [Czarnecki and Helsen 2003]

Uma linguagem de transformação pode ser classificada quanto:

Direcionalidade (Directionality): uma linguagem de transformação pode ser unidi- recional ou bidirecional;

Rastreabilidade (Tracing): uma linguagem de transformação pode permitir o reg- istro de informações sobre as transformações feitas, possibilitando uma ação re- versa;

Organização das regras (Rule organization): as regras podem ser organizadas em módulos ou ser baseada em um mecanismo de reuso ou possuir uma estrutura orga- nizacional;

Agendamento das regras (Rule Scheduling): o agendamento pode ser quanto a forma implícita ou explícita, quanto a seleção em condicional, iterativa e não deter- minística e quanto a iteração em recursiva e iterativa;

Estratégia de aplicação das regras (Rule Application Strategy): as regras podem ser executadas em uma ordem pré-definida ou aleatória;

Relação entre fonte e alvo (Relationship between source and target): uma trans- formação pode resultar em um novo modelo ou em apenas modificações feitas no mesmo modelo de origem;

Escopo de aplicação de regra (Rule application scoping): está relacionado a atuação da regra, i.e. quanto aos elementos do modelo fonte e alvo;

Regras de transformação (Rule transformation): as regras podem ser parametrizadas, baseadas em estruturas intermediárias ou fazer separação sintática LHS/RHS.

Diversas linguagens foram propostas na literatura, dentre elas destacam-se BOTL [Marschall and Braun 2003], YATL [Patrascoiu 2004] e ATL [Jouault and Kurtev 2006].

2.3. Linguagem de Transformação de modelos ATL

ATL (Atlas Transformation Language) é uma linguagem para a realização de transfor- mações de modelos no contexto de MDE [Jouault and Kurtev 2006]. ATL é uma lin- guagem de transformação independente de repositório, podendo trabalhar tanto com MDR (MetaData Repository) [netBeans.org 2007] quanto EMF [Budinsky et al. 2003].

Uma requisição em ATL é uma expressão em OCL que pode retornar tipos primi-

tivos, elementos de um modelo, coleções, n-uplets ou uma combinação destes tipos (e.g. coleções de n-uplets). A versão atual de ATL não suporta a transformação incremental

e nem a bidirecionalidade. Entretanto, os desenvolvedores de ATL preconizam a utiliza-

ção do suporte de rastreabilidade para realizar esta característica em ATL. A abordagem

imperativa em ATL contém instruções que explicitam as etapas de execução de um pro- cedimento denominado de helpers.

Em ATL, uma definição de transformação começa pela declaração do nome do módulo que permite a criação de espaços de nomes. Deve-se utilizar a palavra reservada create seguida do nome do metamodelo de saída e da palavra reservada f rom seguida do metamodelo de entrada. Assim, definem-se os metamodelos usados no processo de transformação. ATL também permite o uso de bibliotecas de definições de transformação

pelo uso da palavra reservada uses que funciona similarmente a import de Java. Uma re- gra de transformação puramente declarativa usa a palavra reservada f rom para especificar

o elemento de entrada, a palavra to para especificar o elemento de saída e um conjunto

de ligações (bindings) representadas pelo símbolo < . A Listagem 2.1 ilustra um frag- mento de uma definição de transformação em ATL para transformar uma classe em UML

em outra classe em Java.

Listing 2.1. Estrutura de uma definição de transformação em ATL

1

module

UML2JAVA

;

create

OUT

:

JAVA

from

IN

:

UML

;

3

rule

Class2JClass{

 
 

from

uclass

:

UML

!Class

5

to

jclass

:

JAVA

!JClass(

 

uclass.name

<-

jclass.name

7

)

 

}

2.4.

Uma abordagem para aplicação de MDE

Em [Lopes 2005], uma separação explícita entre especificação de correspondência e a definição de transformação é proposta conforme a Figura 2.6.

conformsTo conformsTo MMM source MM target MM conformsTo +left +right mapping MM conformsTo conformsTo
conformsTo
conformsTo
MMM
source MM
target MM
conformsTo
+left
+right
mapping MM
conformsTo
conformsTo
transformation MM
mapping M
conformsTo
generatedFrom
basedOn
transformation M
transformation
program
conformsTo
conformsTo
exec
transformation
source M
target M
engine
MMM: MetaMetaModel
MM: MetaModel
M: Model

Figure 2.6. Separação entre especificação de correspondência e definição de transformação [Lopes 2005]

Na abordagem proposta, a especificação de correspondência (mappingspeci fication) especifica as similaridades entre os metamodelos fonte e alvo. A definição de transfor- mação é gerada a partir da especificação de correspondência.

2.4.1. Metodologia

A metodologia proposta consiste em criar a especificação de correspondência e logo a seguir utilizá-la para gerar a definição de transformação [LOPES et al. 2005]. Para se criar a especificação de correspondência é necessário se criar um operador:

mappingSpeci fication = match(metamodelA, metamodelB)

onde:

match é um operador para gerar a especificação de correspondência;

mappingSpeci fication contém a especificação dos elementos que são similares;

metamodelA e metamodelB são os metamodelos para os quais se criará uma es- pecificação de correspondência.

2.4.2. Algoritmos

Uma especificação de correspondência pode ser definida como uma função:

Match (M a ,M b ) =C M a M b /M c

onde:

Match (M a ,M b ) é a função que recebe dois metamodelos e gera um modelo de

correspondência;

C M a M b /M c é a especificação de correspondência.

Em [Denivaldo Lopes 2005], um algoritmo para metamodel matching é proposto. Este algoritmo torna possível criar a especiação de correspondência de forma semi-automática como a seguir:

1.

Criar C: criar um conjunto C.

2.

Inicializar: atribui 0/ to C.

3.

Encontrar classes folhas: definisse as classes que não possuem filhos.

4.

Selecionar classes iguais ou similares;

5.

Colocar cada classe selecionada em C: depois de iteragir (4) até um ponto, colocar o par de classes selecionadas em C.

6.

Selecionar tipos de dados iguais ou similares;

7.

Colocar cada par de tipo de dados em C: depois de iteragir (6) até um ponto fixo, colocar cada par de tipo de dado selecionado em C.

8.

Selecionar similaridades e igualdade entre enumerações: define quais literais de duas enumerações correspondem;

9.

Colocar cada par enumeração em C: depois iteragir (8) até um ponto fixo, colocar cada par de enumeração em C.

2.4.3.

Ferramentas MT4MDE e SAMT4MDE

A Figura 2.7 mostra a arquitetura de MT4MDE (Mapping Tool for MDE) e de SAMT4MDE (Semi-Automatic Matching Tool for MDE) [Denivaldo Lopes 2005].

MT4MDE é composto de:

GUI é a interface gráfica com o usuário de MT4MDE;

Kernel executa todas as funcionalidades básicas de MT4MDE;

XMI importer/exporter toma um metamodelo no formato XMI e traduz para o mesmo metamodelo conforme a eCore. Este também permite tomar um metamod- elo conforme a eCore e traduzi-lo no formato XMI;

Mapping metamodel é um metamodelo usado para criar modelos de correspondên- cia;

ITFGenLanguage é uma interface para manipular os geradores de definições de transformação que criam definições de transformação a partir do modelo de corre- spondência.

GUI

MT4MDE (plug-in)

GUI MT4MDE (plug-in) Mapping metamodel Kernel ITFGenLanguage XMI importer/exporter ITFMatch (plug-ins) TDGenerator

Mapping

metamodel

Kernel

ITFGenLanguageGUI MT4MDE (plug-in) Mapping metamodel Kernel XMI importer/exporter ITFMatch (plug-ins) TDGenerator LeafSearcher

GUI MT4MDE (plug-in) Mapping metamodel Kernel ITFGenLanguage XMI importer/exporter ITFMatch (plug-ins) TDGenerator

XMI

importer/exporter

ITFMatch

(plug-ins)

TDGenerator

XMI importer/exporter ITFMatch (plug-ins) TDGenerator LeafSearcher Cross-kind relationship applier Comparator
XMI importer/exporter ITFMatch (plug-ins) TDGenerator LeafSearcher Cross-kind relationship applier Comparator

LeafSearcher

Cross-kind relationship applier

Comparator

pre-matching

Matcher

relationship applier Comparator pre-matching Matcher Internal Representation Search Engine Dictionary Matcher

Internal

Representation Search Engine
Representation
Search
Engine
pre-matching Matcher Internal Representation Search Engine Dictionary Matcher (plug-in) Metamodel Handler Validator

Dictionary

Matcher (plug-in)

Representation Search Engine Dictionary Matcher (plug-in) Metamodel Handler Validator Mapping model generator Match

Metamodel

Handler

Engine Dictionary Matcher (plug-in) Metamodel Handler Validator Mapping model generator Match Quality Measurer

Validator

Mapping model

generator

Match Quality

Measurer

post-matchingValidator Mapping model generator Match Quality Measurer Figure 2.7. Arquitetura de MT4MDE e SAMT4MDE [Denivaldo

Figure 2.7. Arquitetura de MT4MDE e SAMT4MDE [Denivaldo Lopes 2005]

A arquitetura de SAMT4MDE é composta de:

Matcher implementa a interface ITFMatch e coordena a crição de correspondências entre dois metamodelos;

Internal Representation é uma representação mais adaptada para a criação de cor- respondências como sendo um conjunto de elementos inter-relacionados;

MetamodelHandler permite a navegação em metamodelos;

LeafSearch realiza a busca de metaclasses que são folhas na estrutura do modelo;

Cross-kind relationship applier aplica as relações definidas em [Pottinger 2003];

Search Engine busca por similaridades entre os elementos de metamodelos;

Dictionary é uma base de dados que armazena dicionários de domínios;

Validator recebe os elementos correspondentes e interage como usuário a fim de validá-los;

Mapping model generator cria um modelo de correspondência a partir dos elemen- tos validados;

Match quality measurer avalia os resultados e fornece medidas de qualidade de correspondência.

A Figura 2.8 mostra a execução do plug-in MT4MDE e SAMT4MDE. Nesta Figura, SAMT4MDE gerou uma especificação de correspondência de acordo com o algo- ritmo proposto para metamodel matching. As correspondências determinadas devem ser validadas pelo usuário do plug-in MT4MDE e SAMT4MDE.

ser validadas pelo usuário do plug-in MT4MDE e SAMT4MDE. Figure 2.8. Execução de MT4MDE e SAMT4MDE

Figure 2.8. Execução de MT4MDE e SAMT4MDE [Denivaldo Lopes 2005]

2.5. Aplicações de MDE

Diversos estudos de caso destacam os principais benefícios de uma abordagem dirigida por modelos tal como em [Middleware Company 2003].

Nesta seção, várias aplicações de MDE são apresentadas.

2.5.1. Desenvolvendo Serviços Web com MDE

Em [Lopes and Hammoudi 2003] e [Lopes 2005], uma abordagem de desenvolvimento de serviços Web baseada em modelos é proposta. Nesta abordagem, as tecnologias que compõem os serviços Web são trazidas para o espaço tecnológico de MDE através da criação de metamodelos para cada uma das tecnologias. Assim, tem-se a Figura 2.9 que descreve um modelo para a Arquitetura Orientada a Modelos (SOA - Service Oriented Architecture).

Em seguida, deve-se especificar as correspondências entre o metamodelo utilizado para criar o PIM, por exemplo UML, e o metamodelo de serviço Web, por exemplo WSDL. A Figura 2.10 ilustra as correspondências entre UML e WSDL.

Após a criação da especificação de correspondência, pode-se criar a definição de transformação do PIM em UML para o PSM de serviços Web. Uma vez obtido o PSM, deve-se criar uma transformação de modelo-à-código para se obter o código fonte na plataforma de Serviços Web, i.e. documento WSDL, BPEL e UDDI.

Composes Publishes BPEL4WS UDDI References +services +services 1 * 1 * 1 * +ref +service
Composes
Publishes
BPEL4WS
UDDI
References
+services
+services
1 *
1 *
1 *
+ref
+service Describes
Service
WSDL
1 *
Uses
+soap
SOAP
+smtp
+http
+ftp
HTTP
FTP
SMTP

Figure 2.9. Execução de MT4MDE e SAMT4MDE [Lopes 2005]

UML metamodel Mapping WSDL metamodel (UML) (WSDL) ModelElement WSDLElement Document a t i on 0
UML metamodel
Mapping
WSDL metamodel
(UML)
(WSDL)
ModelElement
WSDLElement
Document a t i on
0 *
0
1
Namespace
Type
+types
+types
0 0
1 1
Part
Package
0 * *
0
P2D
+part
+part
AssociationEnd
Message
+message
+message
0
0 * *
Operation
Generalization
+generalization +specification
+generalization+specification
A2T
+operataions 0
+operataions
0 * *
+child
+child
+parent
+parent
PortType
GeneralizableElement
+type 0
+type 0
* *
+portType
+portType
Class
C2S
Definition
+_targetNameSpace
+name
Interface
0 * *
0
+binding
+binding
0 *
+binding
+binding
Attribute
Binding
O2O
0
0
* *
+boperations
+boperations
Operation
+specification
BindingOperation
+method
M2Bo
Method
Port
P2Part
+port
+port
0 * *
0
Parameter
Service
+service
+service
Dt2T
0
0 * *
DataType
source
composition
target
Me
Mapping Element

Figure 2.10. Execução de MT4MDE e SAMT4MDE [Lopes 2005]

2.5.2. Suportando a distribuição em larga escala de programas da TV digital

Em [Lima et al. 2007], um abordagem dirigida por modelos é proposta para permitir a distribuição em larga escala de programas de TV digital. Para distribuir programações de TV em larga escala é necessário traduzir as programações de um padrão para outro padrão

de criação de programas de TV ou outro formato multimídia. Para isto, um metamodelo para os padrões NCL e outro para SMIL foram propostos. Em seguida, a arquitetura da Figura 2.11 foi proposta para permitir a conversão de um padrão para o outro. É importante ressaltar que NCL é voltado para TV digital enquanto SMIL é voltado para criar documentos multimídia na Internet.

Transformation Transformation Engine Definition SMIL NCL SMIL NCL MetaModel MetaModel Document Document (XML)
Transformation
Transformation
Engine
Definition
SMIL
NCL
SMIL
NCL
MetaModel
MetaModel
Document
Document
(XML)
(XML)
conformsTo
conformsTo
SMIL
NCL
INJECTOR
EXTRACTOR
Model
Model
SMIL
NCL

Figure 2.11. Arquitetura proposta para conversão entre tipos de programação [Lima et al. 2007]

2.5.3. Desenvolvimento de Sistemas de Informação Médica

Em [Melo et al. 2006], o desenvolvimento de um Sistema de Informação Médico segundo uma abordagem MDE é proposto. O PIM do Sistema de Informação Médica é modelado em UML (incluindo perfis UML) e o PSM é gerado na plataforma de Serviços Web e na plataforma da Oracle para serviços Web. Após, transformações de modelo-à-modelo são definidas em ATL, i.e. definições de transformação de UML para Serviços Web. Em seguida, transformações de modelo-à-código em ATL permitem gerar o código final em Java e Serviços Web. A Figura 2.12 mostra uma parte do PIM do Sistema de Informação Médica.

Diseases +RegisterDiseases() +RemoveDiseases() * : : void void DefinitiveDiagnose Doctor * Exams +SearchDoctor()
Diseases
+RegisterDiseases() +RemoveDiseases() * : : void void
DefinitiveDiagnose
Doctor
*
Exams
+SearchDoctor() +ListDoctor() : void : void
*
1
+VerifyEnoughDataDD() +SupplyDefinitiveDiagnosis() : bool
+RegisterExams() : void
1
*
+RemoveExams() * : void
PresumptionDiagnose
+CreateDiseasesProbableList() +VerifyEnoughDataDP() : bool : Diseases
GeneralList
Sugeries
1
* +RegisterSugeries() +RemoveSugeries() : : void void
+ObtainGeneralList() : GeneralList
*
DifferentialDiagnose
Symptomas
+ObtainRemoteList() : void
+ListCompatibleDiseases() +ObtainLocalList() : void : Diseases
*
+RegisterSimptom() +RemoveSymptom() : : void void
*
<<DataTypeService>>
Medication
*
*
RemoreList «datatype»
+RegisterMedication() +RemoveMedication() : : void void
*
+CreateRemoteList() +FindSharedInformationBases() : Diseases
ScreenedList
Patinent
LocalList
+ShowScreenedList() : void
+CreateLocalList() : Diseases
+RemovePatinent() +RegisterPatinent() : : void void
+AssociateSymptoms() +AsociateDiseases() : void : void

Figure 2.12. PIM do Sistema de Informação Médica [Melo et al. 2006]

2

4

6

8

10

12

14

A Listagem 2.2 apresenta uma parte da definição de transformação de UML para a plataforma da Oracle para Serviços Web. Vale ressaltar que a plataforma da Oracle para Serviços Web é definida como bibliotecas e anotações na linguagem Java.

Listing 2.2. Definição de transformação de UML para a plataforma de Serviços Web da Oracle

rule C2JClass{ from c : UML!Class (c.stereotype -> exists(e|e.name=’Service’)) to conf : JAVAM!JClass(
rule
C2JClass{
from
c
:
UML!Class
(c.stereotype
->
exists(e|e.name=’Service’))
to
conf
:
JAVAM!JClass(
name
<-
c.name,
visibility
<-
if
c.visibility
=
#vk_public
then
#public
else
if
c.visibility
=
#vk_private
then
#private
Else
#protected
endif
endif,
*** ),
annot:JAVAM!Annotation(
value
<-
’@WebService(name
=
+
c.name
+
’,
serviceName
=
+
c.name
+
’,targetNamespace=
http://’
+
c.name
+
’.ws’)
}

2.5.4. Gerenciamento de Dados em Sistemas de Detecção de Intrusão

Sistemas de Detecção de Intrusão (IDS - Intrusion Detection System) manipulam infor- mações que devem ser compartilhadas entre diferentes ferramentas. Em [Silva et al. 2006], uma abordagem MDE é proposta para permitir a interoperabilidade e, também, o geren- ciamento das informações do IDS-NIDIA. A interoperabilidade e o gerenciamento das informações do IDS-NIDIA são feitas através de modelos criados conforme o metamod- elo apresentado na Figura 2.13.

NetworkUser +networkuser +interfacenetuser : String LocalBehavior +port : String * +datamachineuser
NetworkUser
+networkuser
+interfacenetuser : String
LocalBehavior
+port : String
*
+datamachineuser
+datamachineuser
DiskUse
+name : String
+description : String
+parameterin : String
+parameterout : String
*
+localbehaviour
DataMachineUser
1
+diskuser
+totalspacedisk : String
+hostuser : String
+usedspacedisk : String
*
+profileids
1
+freespacedisk : String
*
1
+datamachineuser
RemoteBehavior
ProfileIDS
1
+datamachineuser
+name : String
+description : String
+parameterin : String
+parameterout : String
*
MemoryUser
+name : String
+memoryuser
+totalspacemem : String
+freespacemem : String
+remotebehaviour
1
+profileids
*
LayerIDS +remotelayer
RemoteLayer
RemoteAgent
+layerids
+name : String
+remotelayer
+remoteagent
+description : String
1
+remoteexecution : String
+name : String
+domain : String
+layerids +layerids* +remotestatus : String
+remoteagent
+description : String
*
+level : String
1
*
1
1
LocalAgent
+localagent
LocalLayer
+locallayer
+locallayer +localagent
+name : String
+localexecution : String
+description : String
+localstatus : String
*
1
*
1

Figure 2.13. Metamodelo do profile para o IDS-NIDIA [Silva et al. 2006]

Os modelos gerados a partir do metamodelo do profile para o IDS-NIDIA é ar- mazenado no repositório MDR (Meta-Data Repository) e são exportados utilizando XMI.

Assim, uma ferramenta ou nova extensão do IDS-NIDIA feita em outra linguagem de pro- gramação pode ter acesso as informações do profile.

2.6. Conclusão

Neste capítulo, apresentou-se a Engenharia Dirigida por Modelos, especificamente abordou-

se MDA e EMF, DSL, transformações de modelos, a ferramenta MT4MDE e SAMT4MDE. Em seguida, apresentou-se alguns exemplos de aplicação de MDE.

MDE é um novo paradigma que apresenta ampla utilização permitindo a interop-

erabilidade entre diferentes espaços tecnológicos e a garantia de que a lógica do negócio

é preservada quanto a mudanças tecnológicas e quanto ao surgimento de novos requisi-

tos. Através de modelos e transformações de modelos, mantêm-se a coerência entre os requisitos e o sistema implementado e a qualidade do sistema desenvolvido.

Ressaltou-se neste capítulo, a importância de ferramentas que possam automatizar

o processo de desenvolvimento em MDE. Assim, apresentou-se MT4MDE que permite

a edição de modelos de correspondência e a geração de definições de transformação, e SAMT4MDE que permite criar um modelo de correspondência de acordo com um algo- ritmo de metamodel matching.

Por fim, vários exemplos de utilização de MDE mostraram que este paradigma é viável e traz benefícios como a garantia de qualidade de software.

Agradecimentos

O trabalho apresentado neste capítulo foi financiado pelo CNPq e FAPEMA.

O autor agradece a equipe que compõe o Laboratório de Engenharia de Software

e Rede de Computadores (LESERC) pela cooperação na realização dos trabalhos apre- sentados.

Bibliografia

[Budinsky et al. 2003] Budinsky, F., Steinberg, D., Merks, E., Ellersick, R., and Grose, T. J. (2003). Eclipse Modeling Framework: A Developer’s Guide. Addison-Wesley Pub Co, 1st edition.

[Bézivin and Gérard 2002] Bézivin, J. and Gérard, S. (2002). A Preliminary Identifica- tion of MDA Components. OOPSLA 2002 Workshop on Generative Techniques in the context of Model Driven Architecture.

[Bézivin et al. 2004] Bézivin, J., Hammoudi, S., Lopes, D., and Jouault, F. (2004). Ap- plying MDA Approach for Web Service Platform. 8th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2004), pages 58–70.

[Cook 2004] Cook, S. (2004). Domain-Specific Modeling and Model Driven Architec- ture. MDA Journal, pages 1–10.

[Czarnecki and Helsen 2003] Czarnecki, K. and Helsen, S. (2003).

Classification of

Model Transformation Approaches. proceedings of the 2nd OOPSLA’03 Workshop on Generative Techniques in the Context of MDA.

[Denivaldo Lopes 2005] Denivaldo Lopes, Slimane Hammoudi, Z. A. (2005). Schema Matching in the Context of Model Driven Engineering: From Theory to Practice. Pro- ceedings of the International Conference on Systems, Computing Sciences and Soft- ware Engineering (SCSS 2005).

[Dib et al. 2008] Dib, A., Feraud, L., Ober, I., and Percebois, C. (2008). Towards a rigorous framework for dealing with domain specific language families. Information and Communication Technologies: From Theory to Applications - ICTTA 2008.

[Dijkstra 1972] Dijkstra, E. W. (1972). The Humble Programmer. ACM Turing - Award Lecture.

[Favre 2004] Favre, J. M. (2004). Towards a Basic Theory to Model Driven Engineering. UML 2004 - Workshop in Software Model Engineering (WISME 2004).

[Fondement and Silaghi 2004] Fondement, F. and Silaghi, R. (2004). Defining Model Driven Engineering Processes. WiSME@UML 2004.

[Frankel and Parodi 2002] Frankel, D. and Parodi, J. (2002). Using Model-Driven Architecture TM to Develop Web Services. Technical report, IONA Technologies PLC.

[Frankel 2003] Frankel, D. S. (2003).

Model Driven Architecture: Applying MDA to

Enterprise Computing. Wiley and OMG Press.

[Gavras et al. 2004] Gavras, A., Belaunde, M., Pires, L. F., and Almeida, J. P. A. (2004). Towards an MDA-based Development Methodology. First European Workshop on Software Architecture (EWSA 2004).

[Jouault and Kurtev 2006] Jouault, F. and Kurtev, I. (2006). On the Architectural Align- ment of ATL and QVT. SAC’06: Proceedings of the 2006 ACM symposium on Applied computing, pages 1188–1195.

[Kent 2002] Kent, S. (2002). Model Driven Engineering. Integrated Formal Methods - IFM, pages 286–298.

[Kleppe et al. 2003] Kleppe, A., Warmer, J., and Bast, W. (2003). MDA Explained: The Model Driven Architecture: Practice and Promise. Addison-Wesley, 1st edition.

[Lee and Chae 2006] Lee, J. S. and Chae, H. (2006). Domain-specific language approach to modelling UI architecture of mobile telephony systems. IEE Proceedings of Soft- ware.

[Lima et al. 2007] Lima, B., Jr., J. G. S., and Lopes, D. (2007). Using MDA to Support Hypermedia Document Sharing. IEEE International Conference on Software Engi- neering Advances -ICSEA 2007.

[Lopes 2005] Lopes, D. (2005). Study and Applications of the MDA Approach in Web Service Platforms. Ph.D. thesis (written in French), University of Nantes.

[Lopes and Hammoudi 2003] Lopes, D. and Hammoudi, S. (2003). Web Services in the Context of MDA. The 2003 International Conference on Web Services (ICWS’03), pages 424–427.

[LOPES et al. 2005] LOPES, D., HAMMOUDI, S., and ABDELOUAHAB, Z. (2005). Schema matching in the context of model driven engineering: From theory to prac- tice. Proceedings of the International Conference on Systems, Computing Sciences and Software Engineering (SCSS 2005).

[Lopes et al. 2006] Lopes, D., Hammoudi, S., Jr., J. G. S., and Bontempo, A. P. (2006). Metamodel Matching: experiments and comparison. In IEEE International Conference on Software Engineering Advances (ICSEA 06).

[Marschall and Braun 2003] Marschall, F. and Braun, P. (2003). Model Transformations for the MDA with BOTL. Proceedings of the Workshop on Model Driven Architecture:

Foundations and Applications.

[Martin et al. 2003] Martin, J., Arsanjani, A., Tarr, P., and Hailpern, B. (2003). Services: Promises and Compromises. Queue, 1(1):48–58.

Web

[Mellor et al. 2004] Mellor, S. J., Scott, K., Uhl, A., and Weise, D. (2004). MDA Dis- tilled: Principles of Model-Driven Architecture. Addison-Wesley, 1st edition.

[Melo et al. 2006] Melo, S. A. B., Lopes, D., and Abdelouahab, Z. (2006). Developing Medical Information System with MDA and Web Services. The 2006 International Conference on Software Engineering Research and Practice - SERP’06.

[Microsoft ] Microsoft. Software Factories. Available at http://msdn.microsoft.com/ar- chitecture/overview/softwarefactories/.

[Microsoft 2004] Microsoft (2004).

COM: Component Object Model Technologies.

Available at http://www.microsoft.com/com/.

[Middleware Company 2003] Middleware Company (2003). Model Driven Develop- ment for J2EE Utilizing a Model Driven Architecture (MDA) Approach. Techni- cal report, The Middleware Company. Available at http://www.middleware-compa- ny.com/casestudy.

[Muller and Gaertner 2004] Muller, P.-A. and Gaertner, N. (2004). Modélisation Objet avec UML. Eyrolles, 514.

[netBeans.org 2007] netBeans.org (2007). MetaData Repository (MDR). Available at http://mdr.netbeans.org.

[OMG 2001] OMG (2001).

ormsc/2001-07-01.

Model Driven Architecture (MDA)- document number

[OMG 2002] OMG (2002).

The Common Object Request Broker Architecture: Core

Specification, Version 3.0.6 formal/02-12-02.

[OMG 2003a] OMG (2003a). MDA Guide Version 1.0.1, Document Number: omg/2003- 06-01. OMG.

[OMG 2003b] OMG (2003b). Object Constraint Language (OCL) Specification, ad/03-

10-14.

[OMG 2003c] OMG (2003c). Unified Modeling Langage: Superstructure version 2.0 Final Adopted Specification, OMG ptc/03-08-02.

[OMG 2003d] OMG (2003d). XML Metadata Interchange (XMI) Specification, Version 2.0, formal/03-05-02.

Query/View/-

at

[OMG 2007] OMG Transformation

(2007).

Specification

Meta

-

Object

Facility

(MOF)

2.0

Final

Adopted

Specification.

Available

http://www.omg.org/docs/ptc/07-07-07.pdf.

[Patrascoiu 2004] Patrascoiu, O. (2004). Mapping EDOC to Web Services using YATL. 8th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2004), pages 286–297.

[Silva et al. 2006] Silva, M., Lopes, D., and Abdelouahab, Z. (2006). A Remote IDS based on Multi-agent Systems, Web Services and MDA. International Conference on Software Engineering - ICSEA 2006.

[Sommerville 2008] Sommerville, I. (2008). Software Engineering. Pearson-Addison Wesley, 8rd edition.

[Wu et al. 2007] Wu, H., Gray, J., and Mernik, M. (2007). Grammar-Driven Generation of Domain-Specific Language Debuggers. Software: Practice and Experience.