transformação modelo pc MDA 2

Atlas Transformation Language Transformação de Modelos Java em Modelos de Classes UML

DEI-ISEP

2008 / 2009

1050540 Pedro Dias

Atlas Transformation Language Transformação de Modelos Java em Modelos de Classes UML

DEI-ISEP

2008 / 2009

1050540 Pedro Dias

Licenciatura em Engenharia Informática

Outubro de 2009

Orientador ISEP: Alexandre Bragança

v

A todos os que me apoiaram

Atlas Transformation Language – Transformação de Modelos Java em Modelos de Classes UML

vii

Agradecimentos Ao meu orientador, Professor Doutor Alexandre Bragança, pela orientação,

supervisão e aconselhamento durante todo o período do projecto.

À Cristina Silva pelas contribuições na revisão deste relatório e pelo apoio,

disponibilidade, força e incentivos durante todo este percurso.

Aos meus pais, que muito contribuíram e me apoiaram ao longo de todo este percurso.

Aos meus amigos, pelas palavras de apoio durante o tempo dedicado a este projecto.


ix

Resumo A adopção de estratégias de desenvolvimento de software baseadas em modelos tem

despertado bastante interesse junto do meio académico e mais recentemente no meio

industrial. Neste novo paradigma, os artefactos de software são manipulados como

modelos e torna-se possível o estabelecimento de relações e transformações entre eles.

Neste contexto, é usual a geração do texto dos programas com base em modelos de

mais alto nível de abstracção. A tradução inversa neste contexto torna-se um pouco

mais complexa e propícia a erros pois é necessário efectuar o parsing do texto dos

programas.

No contexto do Model Driven Development, o objectivo último é que todos os

artefactos possam ser manipulados como modelos.

Este projecto teve como objectivo desenvolver suporte (experimental) para que

modelos java pudessem ser manipulados e transformados em modelos de classes

UML. Foi desenvolvido usando a Framework EMF do Eclipse e a linguagem de

transformação ATL e envolveu uma grande dose de investigação visto que os

conceitos eram novos e bastante abstractos.

É de salientar que o resultado deste projecto será integrado numa framework open

source de suporte ao desenvolvimento baseado em modelos de linhas de produtos de

software com base na metodologia MoDeLine.

Palavras Chave (Tema): Modelação, Model-Driven Engineering, Model-

Driven Development.

Palavras Chave (Tecnologias): Eclipse, Eclipse Modeling Framework, Atlas

Transformation Language, UML2


xi

Índice Agradecimentos .......................................................................................................vii

Resumo .................................................................................................................... ix

Índice ....................................................................................................................... xi

Índice de Figuras..................................................................................................... xv

Índice de Tabelas ................................................................................................... xvii

Índice de excertos de código .................................................................................. xix

Notação e Glossário ............................................................................................... xxi

1 Introdução ........................................................................................................ 1

1.1 Enquadramento .................................................................................................. 1

1.2 Apresentação do projecto/estágio ....................................................................... 1

1.2.1 Planeamento de projecto .............................................................................................. 1

1.2.2 Reuniões de acompanhamento...................................................................................... 2

1.3 Contributos deste trabalho ................................................................................. 2

1.4 Organização do relatório .................................................................................... 2

2 Contexto ............................................................................................................ 5

2.1 Model-Driven Engineering ................................................................................. 5

2.2 Eclipse Modeling Framework .......................................................................... 10

2.3 Metamodelo JavaModel ................................................................................... 12

2.4 Metamodelo de Classes UML ........................................................................... 14

3 Atlas Transformation Language (ATL) ...........................................................17

3.1 ATL module ...................................................................................................... 18

3.1.1 Header Section........................................................................................................... 19

3.1.2 Import Section ........................................................................................................... 19

3.1.3 Helpers ...................................................................................................................... 20

3.1.4 Rules ......................................................................................................................... 22


xii

3.1.5 Semântica da execução dos módulos .......................................................................... 25

3.2 ATL Query........................................................................................................ 26

3.2.1 Estrutura de uma ATL Query ..................................................................................... 27

3.2.2 Semântica da execução da Query................................................................................ 27

3.3 ATL Library ..................................................................................................... 28

3.4 Data Types ........................................................................................................ 28

3.5 ATL Comments ................................................................................................ 30

3.6 OCL Declarative Expressions .......................................................................... 30

4 Transformação de um Modelo Java para um Modelo de Classes UML em ATL

33

4.1 Criação do projecto ATL ................................................................................. 34

4.2 Criação das configurações ................................................................................ 37

4.3 Relações entre modelos ..................................................................................... 39

4.3.1 JModelElement (abstracta) / Element (abstracta) ........................................................ 39

4.3.2 JCompilationUnit ....................................................................................................... 40

4.3.3 JMember (abstracta)................................................................................................... 40

4.3.4 JPackage / Package .................................................................................................... 41

4.3.5 JClass / Class ............................................................................................................. 42

4.3.6 JField / Property......................................................................................................... 45

4.3.7 JInitializer .................................................................................................................. 46

4.3.8 JMethod / Operation .................................................................................................. 46

4.3.9 JParameter ................................................................................................................. 48

4.4 Criação de código ATL ..................................................................................... 49

4.5 Execução das configurações ............................................................................. 53

5 Conclusões .......................................................................................................55

5.1 Objectivos realizados ........................................................................................ 55

5.2 Limitações & trabalho futuro .......................................................................... 55

5.3 Apreciação final ................................................................................................ 56


xiii

Anexo 1 Metamodelo EMF_JavaModel .............................................................61

Anexo 2 Metamodelo UML2_UMLClassModel .................................................64


xv

Índice de Figuras Figura 1 – Noções básicas a) paradigma object-oriented b) paradigma MDE ..................................... 5

Figura 2 – Componentes principais do MDA....................................................................................... 6

Figura 3 – a) Model-Driven Architecture b) exemplo prático MDA ..................................................... 7

Figura 4 – Processo de transformação de modelos .............................................................................. 8

Figura 5 - Objectivo final da MDA da OMG ....................................................................................... 9

Figura 6 – Relação do projecto com a MDA. .................................................................................... 10

Figura 7 – Hierarquia de classes do modelo Ecore (a cinzento estão representadas as classes

abstractas)........................................................................................................................................ 11

Figura 9 – Diagrama de Classes do Metamodelo JavaModel ............................................................ 13

Figura 8 – Extracto do metamodelo Java2 (baseado no JavaModel) .................................................. 14

Figura 10 – Extracto do metamodelo UML do UML2 ........................................................................ 15

Figura 11 – Ambiente de Desenvolvimento ATL ................................................................................ 18

Figura 12 – Esquema da estrutura do tipo de dados ATL .................................................................. 29

Figura 13 – Esquema da transformação ATL java2uml ................................................................. 33

Figura 14 – Janela para criação de um novo projecto ATL ............................................................... 34

Figura 15 – Janela para criação de um novo ficheiro ATL ................................................................ 36

Figura 16 – Modelo Java exemplo do ficheiro java.java2 .................................................................. 37

Figura 17 – Janela que permite criar, gerir e correr as configurações .............................................. 38

Figura 18 – Modelo de Classes UML do ficheiro uml.uml .............................................................. 54

Figura 19 – Metamodelo EMF_JavaModel – Jclass ................................................................... 61

Figura 20 – Metamodelo EMF_JavaModel – JcompilationUnit ............................................ 61

Figura 21 – Metamodelo EMF_JavaModel – JField ................................................................... 61

Figura 22 – Metamodelo EMF_JavaModel – JInitializer ..................................................... 62

Figura 23 – Metamodelo EMF_JavaModel – JMember ................................................................ 62

Figura 24 – Metamodelo EMF_JavaModel – JMethod ................................................................ 62

Figura 25 – Metamodelo EMF_JavaModel – JModelElement ................................................... 62

Figura 26 – Metamodelo EMF_JavaModel – JPackage .............................................................. 62


xvi

Figura 27 – Metamodelo EMF_JavaModel – JParameter.......................................................... 63

Figura 28 – Metamodelo EMF_JavaModel – JVisibility ....................................................... 63

Figura 29 – Metamodelo UML2_UMLClassModel – EData Types ............................................. 64

Figura 30 – Metamodelo UML2_UMLClassModel – EClass::Comment ..................................... 64

Figura 31 – Metamodelo UML2_UMLClassModel – EClass::Feature ..................................... 64

Figura 32 – Metamodelo UML2_UMLClassModel – EEnum::VisibilityKind ....................... 64

Figura 33 – Metamodelo UML2_UMLClassModel – EClass::TypedElement ......................... 65

Figura 34 – Metamodelo UML2_UMLClassModel – EClass::TemplateableElement.......... 65

Figura 35 – Metamodelo UML2_UMLClassModel – EClass::ParameterableElement ....... 65

Figura 36 – Metamodelo UML2_UMLClassModel – EClass::ConnectableElement ............ 65

Figura 37 – Metamodelo UML2_UMLClassModel – EClass::BehavioralFeature .............. 66

Figura 38 – Metamodelo UML2_UMLClassModel – EClass::DeploymentTarget ................ 66

Figura 39 – Metamodelo UML2_UMLClassModel – EClass::EncapsulatedClassifier ... 66

Figura 40 – Metamodelo UML2_UMLClassModel – EClass::PackageableElement ............ 66

Figura 41 – Metamodelo UML2_UMLClassModel – EClass::Element ..................................... 67

Figura 42 – Metamodelo UML2_UMLClassModel – EClass::NamedElement ......................... 68

Figura 43 – Metamodelo UML2_UMLClassModel – EClass::Namespace ................................ 68

Figura 44 – Metamodelo UML2_UMLClassModel – EClass::Package ..................................... 69

Figura 45 – Metamodelo UML2_UMLClassModel – EClass::Type ............................................ 69

Figura 46 – Metamodelo UML2_UMLClassModel – EClass::Classifier .............................. 70

Figura 47 – Metamodelo UML2_UMLClassModel – EClass::Parameter ................................ 71

Figura 48 – Metamodelo UML2_UMLClassModel – EClass::RedefinableElement ............ 71

Figura 49 – Metamodelo UML2_UMLClassModel – EClass::MultiplicityElement.......... 72

Figura 50 – Metamodelo UML2_UMLClassModel – EClass::Class ......................................... 72

Figura 51 – Metamodelo UML2_UMLClassModel – EClass::Property................................... 73

Figura 52 – Metamodelo UML2_UMLClassModel – EClass::Operation ................................ 74

Figura 53 – Metamodelo UML2_UMLClassModel – EClass::StructuredClassifier ....... 74

Figura 54 – Metamodelo UML2_UMLClassModel – EClass::BehavioredClassifier ....... 75


xvii

Índice de Tabelas Tabela 1 – Planeamento do projecto ................................................................................................... 2

Tabela 2 – Relação entre metamodelos: JModelElement.............................................................. 39

Tabela 3 – Relação entre metamodelos: JMember ........................................................................... 41

Tabela 4 – Relação entre metamodelos: JPackage ......................................................................... 42

Tabela 5 – Relação entre metamodelos: JClass ............................................................................. 44

Tabela 6 – Relação entre metamodelos: JField ............................................................................. 46

Tabela 7 – Relação entre metamodelos: JMethod ........................................................................... 48

Tabela 8 – Relação entre metamodelos: JParameter .................................................................... 49


xix

Índice de excertos de código Código 1 – Exemplo de uma header section ............................................................................. 19

Código 2 – Exemplo de uma import section .............................................................................. 20

Código 3 – Exemplo de um helper ................................................................................................. 21

Código 4 – Exemplo de uma matched rule ................................................................................. 23

Código 5 – Exemplo de uma called rule ..................................................................................... 25

Código 6 – Exemplo de uma query ................................................................................................. 27

Código 7 – Exemplo de um comment............................................................................................... 30

Código 8 – Exemplo do ficheiro .project ..................................................................................... 35

Código 9 – Header do ficheiro java2uml.atl .............................................................................. 36

Código 10 – Matched rule JPackage2Package ........................................................................... 50

Código 11 – Matched rule JClass2Class .................................................................................... 51

Código 12 – Matched rule JField2Property.............................................................................. 51

Código 13 – Helper alterar() ....................................................................................................... 52

Código 14 – Matched rule JMethod2Operation ......................................................................... 52

Código 15 – Matched rule JParameter2Parameter .................................................................. 53


xxi

Notação e Glossário

ATL

EMF

IDE

M2M

MDA

MDD

MDE

MDT

OCL

OMG

UML

XML

XMI

Atlas Transformation Language

Eclipse Modeling Framework

Integrated Development Environment

Model-To-Model

Model-Driven Architecture

Model-Driven Development

Model-Driven Engineering

Model Development Tool

Object Constraint Language

Object Management Group

Unified Modeling Language

Extensible Markup Language

XML Metadata Interchange


1

1 Introdução

1.1 Enquadramento

Este documento tem como finalidade servir como relatório final do projecto realizado

no âmbito da unidade curricular Projecto / Estágio da Licenciatura em Engenharia

Informática do Instituto Superior de Engenharia do Porto. O seu objectivo é descrever

todas as actividades desenvolvidas no decorrer do mesmo, realçando o seu

desenvolvimento técnico.

O tema deste projecto enquadra-se no campo do Model Driven Development (MDD),

tendo como base o Ambiente Integrado de Desenvolvimento (IDE) Eclipse e a sua

Framework de Modelação Eclipse Modeling Framework (EMF).

1.2 Apresentação do projecto/estágio

O projecto tem como objectivo estudar e testar experimentalmente a possibilidade de

dar suporte à transformação entre dois tipos de modelos, Modelos de programas Java

e Modelos de Classes UML. Para esta transformação entre modelos, ficou desde o

início definido que, devido à complexidade das ferramentas e à impossibilidade

temporal de as testar todas, se utilizaria apenas a ferramenta Atlas Transformation

Language (ATL).

Os modelos utilizados têm como base metamodelos, ou seja, modelos dos modelos. O

Modelo Java utilizado é baseado no seu metamodelo JavaModel, parte integrante do

EMF e o Modelo de Classes UML é baseado no seu metamodelo UML do UML2,

uma ferramenta de desenvolvimento de modelos (MDT) baseada no EMF.

1.2.1 Planeamento de projecto

O projecto teve a duração de cinco meses, começando em Maio de 2009 e terminando

em Setembro de 2009.

Para o planeamento do projecto foi utilizada a ferramenta Microsoft Office Project.


2

Tabela 1 – Planeamento do projecto

1.2.2 Reuniões de acompanhamento

Durante a elaboração do projecto foram realizadas reuniões semanais com o

orientador no Departamento de Engenharia Informática do Instituto Superior de

Engenharia do Porto.

O objectivo das reuniões era comunicar o ponto de situação do projecto e apresentar

problemas, soluções e melhorias.

1.3 Contributos deste trabalho

Este projecto permite uma fácil e rápida transformação de modelos java em modelos

de classes UML promovendo assim a reutilização de código.

O resultado deste projecto será integrado numa framework open source de suporte ao

desenvolvimento baseado em modelos de linhas de produtos de software baseada na

metodologia MoDeLine.

1.4 Organização do relatório

O primeiro capítulo pretende dar uma ligeira introdução ao projecto, mostrando qual o

seu enquadramento. Permite saber como foi planeado e acompanhado pelo orientador

do mesmo.


3

No segundo capítulo é apresentado o contexto do projecto e são explicados os

conceitos teóricos inerentes ao mesmo.

No terceiro capítulo é apresentada a Atlas Transformation Language (ATL).

No quarto capítulo são apresentadas as relações entre os metamodelos e é explicada a

transformação entre eles.

No quinto capítulo são apresentadas as conclusões relativamente ao projecto

desenvolvido ao longo de cinco meses.

Em anexo estão os metamodelos utilizados para a realização desta experiência pois

eram demasiado grandes para fazerem parte da estrutura principal do relatório.


5

2 Contexto

2.1 Model-Driven Engineering

Este projecto consiste em testar experimentalmente a transformação de modelos Java

em modelos de classes UML enquadrando-se no contexto da Model-Driven

Engineering (MDE). MDE é uma metodologia de desenvolvimento de software com

foco na criação e uso de modelos para aumento da produtividade, maximizando a

compatibilidade entre sistemas.

Os modelos fazem parte de um crescente número de processos de engenharia (tal

como engenharia de software). Contudo, na maior parte dos casos, são apenas

destinados a fazer parte da documentação em vez de serem parte integrante do

processo de engenharia.

Como oposto a esta abordagem, o campo da MDE considera os modelos como

entidades de primeira classe, sendo que tudo pode ser representado através de

modelos. Na figura seguinte podemos observar uma comparação possível entre os

conceitos do paradigma object-oriented e os do paradigma MDE.

Figura 1 – Noções básicas a) paradigma object-oriented b) paradigma MDE


6

A abordagem Model-Driven fornece um conjunto de operações dedicadas à

manipulação de modelos. Neste contexto, o modelo de transformação é a operação

central para tratamento de modelos. Destina-se a tornar possível especificar a maneira

como é produzido um número de modelos alvo baseados num conjunto de modelos

fonte (por exemplo, como se obtém um modelo de classes em notação UML baseado

num modelo de código java). No âmbito da MDE, é assumido que o modelo de

transformação, tal como outra ferramenta baseada em modelos pode ser modelada, o

que significa que ela também deverá ser considerada como modelo.

No âmbito deste projecto é dado foco à transformação entre modelos.

Um exemplo de tentativa de concretização da visão MDE é a iniciativa MDA da

OMG. A figura seguinte apresenta um exemplo dos componentes principais do MDA.

Figura 2 – Componentes principais do MDA


7

No campo da Model-Driven Engeneering, o modelo é definido de acordo com a

semântica de um modelo de modelos, também chamado metamodelo. Um modelo que

respeite a semântica definida por um metamodelo, diz-se que ele obedece (conforms)

a esse metamodelo. A figura seguinte sintetiza a relação entre modelos.

Figura 3 – a) Model-Driven Architecture b) exemplo prático MDA

Cada modelo é composto por um número distinto de elementos e, da mesma maneira

que um modelo obedece ao seu metamodelo, existem relações entre elementos de um

modelo e do seu metamodelo.

Um metamodelo, antes de o ser, é um modelo. Isto implica que também ele obedeça

ao seu metamodelo. Com este fim, a MDA define um terceiro nível de modelação,

correspondente ao metametamodelo, tal como ilustrado na figura anterior. No MDA o

papel de metametamodelo é da responsabilidade do MOF (ver figura 2). O

metametamodelo introduz a semântica que é requerida para especificar metamodelos.

De notar que um metametamodelo define-se a si mesmo, o que significa que ele é

especificado através das suas próprias semânticas, podendo-se assim dizer que um

metametamodelo obedece a si mesmo.


8

O ATL oferece suporte a dois standards da MDA, a Meta Object Facilities (MOF) do

Object Management Group (OMG) e o metametamodelo Ecore do Eclipse Modeling

Framework (EMF). Sendo que o Ecore do EMF pode ser considerado como uma

implementação com adaptações do MOF da OMG. Ou seja, o ATL está habilitado a

trabalhar com metamodelos que foram especificados de acordo com a semântica do

Ecore e do MOF. O EMF será alvo de apresentação na próxima secção.

No âmbito da MDE, a transformação de modelos permite especificar a maneira como

transformar modelos fonte (source) em modelos alvo (target), sendo possível definir a

correspondência dos elementos entre modelos.

Formalmente, uma transformação entre modelos define a maneira como criar um

modelo Mb, que obedece a um metamodelo MMb, apartir de um modelo Ma, que

obedece a um metamodelo MMa. E, não esquecendo que a característica da MDE é

considerar tudo como sendo modelos, a própria transformação Mt é definida como um

modelo e esta obedece a um metamodelo MMt que define a semântica do modelo de

transformações. Todos os metamodelos também obedecem ao metametamodelo

MMM, que como já referido, define o modelo dos modelos.

Figura 4 – Processo de transformação de modelos


9

A figura 5 apresenta uma visão da possível realização da abordagem MDE/MDA

quando adoptada globalmente no processo de desenvolvimento/engenharia de

software. Em particular, o MDA propõe dois grandes “tipos” de modelos: modelos

independentes da plataforma (PIM) e modelos específicos de plataforma (PSM). Essa

figura mostra as possíveis relações entre modelos usados em diversas fases do ciclo de

desenvolvimento e também segundo diferentes perspectivas (i.e., business aspects,

technical aspects, etc.). Essas relações são derivadas das transformações entre os

modelos. Este projecto visa, em particular, estudar a viabilidade de “promover” o

código java a modelo, de forma a poder ser integrado numa abordagem MDE.

Estamos portanto no contexto das actividades identificadas na figura pela elipse a

vermelho.

Figura 5 - Objectivo final da MDA da OMG

Em particular neste projecto, pretende-se até verificar um pouco mais além do que a

figura apresenta, ou seja, verificar se o componente Code pode também ele ser um

modelo. Neste contexto o projecto aborda a transformação entre o modelo do código

java (modelo fonte) e o modelo de classes UML específico para java (modelo alvo).


10

Figura 6 – Relação do projecto com a MDA.

Portanto, a intenção deste projecto é fazer a transformação ATL (secções 3 e 4) do

Code Java, representado através do metamodelo JavaModel (secção 2.3), num

modelo de classes UML, representado pelo metamodelo UML do UML2 (secção 2.4).

A ferramenta que dá suporte a estes modelos é a EMF (secção 2.2). Na continuação

deste projecto será ainda feita a transformação inversa.

Por fim este projecto será integrado num projecto paralelo que efectua a

transformação de modelos Java, que obedecem ao JavaModel, em Modelos Java do

Eclipse e vice-versa, identificado pela elipse a tracejado vermelho. Posteriormente

serão ambos integrados numa framework open source de suporte ao desenvolvimento

baseado em modelos de linhas de produtos de software baseada na metodologia

MoDeLine.

2.2 Eclipse Modeling Framework

Todo o projecto foi desenvolvido sobre o Eclipse, um ambiente de desenvolvimento

integrado (IDE) escrito em Java e que permite desenvolver aplicações tanto em Java

como noutras linguagens através dos diversos plugins para esse efeito. Vários

projectos têm sido desenvolvidos sobre esta plataforma, um deles, que está

directamente relacionado com a modelação é denominado Eclipse Modeling Project.

É um projecto da comunidade Eclipse focado na evolução e promoção de tecnologias

de desenvolvimento baseadas em modelos, fornecendo um conjunto de ferramentas e

frameworks.


11

Uma dessas frameworks é denominada Eclipse Modeling Framework (EMF),

utilizada neste projecto, que permite a modelação e geração de código para construção

de ferramentas e outras aplicações baseadas em modelos de dados estruturados.

Através da framework em questão, é possível criar modelos EMF e gerar os

respectivos editores através de três tipos de fontes:

Modelo Rational Rose

Conjunto de interfaces e classes Java anotadas

eXtensible Markup Language (XML) Schema

O resultado dessa criação é um modelo Ecore (.ecore), que corresponde ao

modelo EMF (mais concretamente, metamodelo) e um modelo gerador

(.genmodel) que controla a geração de código para o metamodelo.

Figura 7 – Hierarquia de classes do modelo Ecore (a cinzento estão representadas as classes abstractas)

O modelo gerador pode ser expandido para serem visualizados todos os seus

elementos, e cada um destes tem propriedades, a eles associados, que controlam o

comportamento do gerador de código. É através deste modelo que é possível

modificar e iniciar facilmente a geração de diferentes tipos de códigos:

Model Code

Edit Code


12

Editor Code

Test Code

Relativamente ao Model Code, após a sua geração, são criadas classes de interface

e uma classe enum (se o modelo for importado do Rose), completas (se o modelo foi

definido usando classes Java anotadas) e criado um novo par de interfaces para o

próprio package e para o factory.

Serão ainda criados dois novos packages com os sufixos “impl” e “util” que

contêm implementações das interfaces e classes úteis adicionais e dois tipos de

ficheiros “manifest” para o Plug-in do modelo: “plugin.xml” e “MANIFEST.MF”.

Em qualquer momento é possível voltar a gerar o código pois as mudanças serão

efectuadas no caso de ter havido alguma alteração no código. Pode-se ainda

selectivamente gerar subconjuntos do Model Code, tal como um package ou

class e gerar o código respectivo.

Quanto ao Edit e Editor Codes, por pré-definição são criados dois plug-ins: o

“Edit” que inclui adaptadores que fornecem uma vista estruturada e comandos para

a edição dos objectos do modelo e o “Editor” que fornece um user interface (UI)

para o editor e um wizard.

No que diz respeito ao Test Code, este após gerado possui esqueletos de teste

JUnit para o exercício de quaisquer funções e operações definidas no modelo, que

normalmente devem ser preenchidos. Contêm apenas uma simples classe exemplo que

mostra como carregar e validar um modelo de uma aplicação stand-alone.

2.3 Metamodelo JavaModel

Para a transformação entre modelos, seja qual for a aplicação a utilizar, é necessária a

existência de dois tipos de modelos, o modelo de entrada (fonte) e o modelo de saída


13

(alvo). O modelo de entrada é o nome dado ao modelo que se quer transformar, que

no caso em estudo diz respeito ao Modelo Java. É um modelo baseado no seu

metamodelo JavaModel, utilizado internamente pelo EMF, que apesar da sua

documentação e integração fora do EMF serem limitadas, servem perfeitamente para

a nossa experiência.

Figura 9 – Diagrama de Classes do Metamodelo JavaModel

Visto que para a realização do trabalho era necessária a criação de um modelo

baseado no JavaModel e não era fornecida essa possibilidade, foi necessário criar um

projecto paralelo com o auxílio do EMF para a criação de um novo metamodelo

(chamado java2). Este metamodelo é exactamente igual ao JavaModel, com a

possibilidade de criação de modelos.


14

Figura 8 – Extracto do metamodelo Java2 (baseado no JavaModel)

2.4 Metamodelo de Classes UML

Como modelo de saída, nome dado ao modelo resultante da transformação, temos o

Modelo de Classes UML baseado no seu metamodelo, presente no UML2, uma das

Model Development Tools (MDT) pertencentes ao Eclipse Modeling Project, referido

anteriormente.

As MDT são ferramentas que fornecem a implementação de metamodelos padrão e

exemplares para o desenvolvimento de modelos baseados em metamodelos. O UML2,

uma dessas ferramentas, é uma implementação desenvolvida em EMF, baseada na

Unified Modeling Language (UML) do Object Management Group (OMG) para a

plataforma Eclipse.

Os objectivos da componente UML2 são fornecer:

uma aplicação útil do metamodelo UML para suporte do desenvolvimento de

ferramentas de modelação

um XML Metadata Interchange (XMI) Schema para facilitar a alternância

entre modelos semânticos

casos de teste com o intuito de validar a especificação

regras de validação para definir e aplicar níveis de conformidade


15

Figura 10 – Extracto do metamodelo UML do UML2


17

3 Atlas Transformation Language (ATL) Atlas Transformation Language é uma linguagem de transformação de modelos

especificada tanto em metamodelo como em texto. No campo da MDE, a ATL

possibilita a especificação de maneira a produzir modelos alvo (target) através de

modelos fonte (source). É uma mistura de programação declarativa com imperativa. O

estilo preferido da escrita da transformação é declarativo pois permite expressar de

uma forma simples as correspondências entre os elementos dos modelos fonte e alvo.

Contudo, também é possível uma construção imperativa para expressar facilmente a

correspondência que se torna difícil expressar de forma declarativa.

Um programa de transformação ATL é composto por regras que definem qual a

correspondência entre elementos dos modelos para criar e inicializar um novo modelo

alvo. É também possível definir um modelo de consulta (query) que permite

especificar os pedidos a modelos e ainda a possibilidade de factorização através da

definição de bibliotecas (libraries) ATL.

Desenvolvido sobre a plataforma Eclipse, disponibiliza ferramentas de

desenvolvimento standard, tais como o debugger e syntax highlighting, que permitem

um mais simples desenho das transformações. O ambiente de desenvolvimento ATL

oferece facilidades adicionais para o tratamento de modelos pois permite uma ponte

entre o texto comum, dedicado à especificação de metamodelos, e a sua

correspondente representação visual.


18

Figura 11 – Ambiente de Desenvolvimento ATL

A linguagem ATL define três diferentes tipos de unidades. ATL module, ATL Query

e ATL Library. Qualquer que seja o seu tipo, são definidos nos seus próprios e

distintos ficheiros, caracterizados pela extensão .atl.

3.1 ATL module

As transformações Model-To-Model (M2M) são descritas nos módulos ATL (ATL

modules). Esta unidade do ATL permite especificar como produzir um conjunto de

modelos alvo através de um conjunto de modelos fonte. Todos os modelos devem ser

associados aos seus respectivos metamodelos. Um módulo ATL aceita um número

fixo de modelos de entrada e retorna um número fixo de modelos alvo. Como

consequência, um módulo não pode gerar um número indeterminado de modelos alvo

similares, ou seja, modelos que obedeçam ao mesmo metamodelo.

A estrutura de um módulo ATL é composta por uma header section, uma

import section opcional e um conjunto de helpers e rules que não

pertencem a nenhuma secção específica, podendo ser declarados sem qualquer ordem.


19

3.1.1 Header Section

A header section define o nome do módulo de transformação, o nome das

variáveis correspondentes aos modelos fonte e alvo e codifica o modo de execução do

módulo.

Definição da sintaxe da header section:

module nome_do_módulo;

create modelos_de_saída [from|refining] modelos_de_entrada;

O nome_do_módulo é, como o próprio nome indica, a denominação do módulo e

deve ser igual ao nome do ficheiro ATL em que se insere. A declaração dos modelos

alvo faz-se a seguir da palavra create e a dos modelos fonte a seguir à palavra

from (no modo normal) ou refining (no caso de uma transformação “refinada”).

Ambos os modelos devem obedecer ao esquema nome_do_modelo :

nome_do_metamodelo. É possível declarar mais do que um modelo de saída ou

entrada separando com vírgulas os modelos declarados. Visto que o nome dos

modelos declarados irá ser usado para identificá-los, cada nome tem de ser único.

module Pai2Pessoa; create OUT : Pessoa from IN : Pai;

Código 1 – Exemplo de uma header section

Neste exemplo é representada a header section do ficheiro

Pai2Pessoal.atl, usada para transformar modelos em que o seu metamodelo é o

Pai, em modelos cujo metamodelo é Pessoa.

3.1.2 Import Section

A import section é o local onde são declaradas as bibliotecas ATL que têm de

ser importadas. É possível declarar diversas bibliotecas distintas, usando o nome da

biblioteca pretendida sem a sua respectiva extensão, através de sucessivas instruções.


20

Definição da sintaxe da import section:

uses nome_da_biblioteca_sem_extensão;

uses strings;

Código 2 – Exemplo de uma import section

Exemplo de um import cujo objectivo é importar a biblioteca de Strings.

3.1.3 Helpers

Os helpers podem ser vistos como o equivalente, no ATL, aos métodos Java.

Possibilitam a definição de código factorizado, combatendo assim a redundância, e

podem ser chamados em diferentes pontos da transformação ATL.

Definição da sintaxe de um helper:

helper [context tipo_do_contexto]? def : nome [(parâmetros?)]? :

tipo_do_retorno = expressão;

Um helper é composto pelo seu tipo_do_contexto, o seu nome e respectivo

conjunto de parâmetros (se aplicável), um tipo_do_retorno e a expressão do

helper.

O contexto é introduzido pela palavra context e define o tipo de elementos a que o

helper se aplica, ou seja, o tipo de elementos a partir do qual será possível chamá-

lo. O contexto pode ser omitido da definição do helper, ficando o helper

associado ao contexto global do módulo ATL, o que significa que, no âmbito desse

helper, a variável self é uma referência para o seu módulo/query.

O nome do helper é introduzido pela palavra def e seguido pelos parâmetros, se

existentes, dentro de parênteses. A definição dos parâmetros tem de obedecer ao

esquema nome_do_parâmetro : tipo_do_parâmetro e no caso da


21

existência de vários parâmetros, estes podem ser declarados separados por vírgulas. O

nome_do_parâmetro deve ser único dentro de um mesmo helper.

Tanto o tipo_de_contexto como o tipo_do_parâmetro e o tipo_do

retorno devem ser de um tipo de dados suportados pelo ATL. O corpo do helper

deve ser especificado como uma expressão Object Constraint Language (OCL),

explicada na secção 3.6, sendo um dos tipos de expressões suportadas.

Podem existir vários helpers com o mesmo nome numa única transformação,

contudo devem ter assinaturas distintas para serem distinguíveis pelo ATL.

Também é possível definir atributos. Um attribute helper é um tipo específico

de helper que aceita a inexistência de parâmetros e pode ser definido no contexto

de um módulo ATL ou de um elemento do modelo.

Um helper sem parâmetros e um attribute helper são apenas equivalentes

num ponto de vista funcional pois existe uma diferença significativa quando

consideradas as semânticas de execução. Enquanto que o valor de retorno de um

helper é calculado todas as vezes que ele é chamado, o valor de retorno de um

attribute helper é calculado apenas uma vez, quando o valor é requisitado pela

primeira vez. Sendo assim, pode-se concluir que declarar um attribute helper é

mais eficiente.

Um attribute helper que é definido no contexto de um módulo ATL é

inicializado (durante a fase de inicialização) na ordem em que ele é declarado no

ficheiro ATL. Sendo assim, pode-se concluir que a ordem é importante pois isso

implica que um attribute helper tenha que ser declarado depois de outro

attribute helper do qual ele dependa para a sua inicialização. Caso a ordem

não seja a correcta será desencadeado um erro durante a fase de inicialização da

execução de um programa ATL.

helper def : médiaInferior(seq : Sequence(Integer), valor : Real) : Boolean =

let média : Real = seq->sum()/seq->size() in média<valor;

Código 3 – Exemplo de um helper


22

Este helper, chamado médiaInferior, é definido no contexto de um módulo

ATL (visto que nenhum contexto está explicitamente especificado). O resultado deste

helper será o retorno de um valor booleano. No caso do valor da média dos valores

contidos no parâmetro seq, sequência (Sequence) de inteiros, for menor

comparativamente a um valor real dado (valor) o resultado será true, caso

contrário será false. O corpo do helper é uma expressão “let”, que define e

inicializa a variável média. Resumindo, a variável será comparada com o valor de

referência.

3.1.4 Rules

Existem três tipos diferentes de regras (rules), que correspondem a dois diferentes

modos de programação fornecidos pelo ATL. As matched rules correspondem à

programação declarativa e as lazy rules e called rules que à programação

imperativa.

As matched rules são o principal constituinte das transformações declarativas no

ATL. Permitem especificar para que tipos de elementos fonte se deve gerar elementos

alvo e a maneira como os elementos alvo devem ser inicializados.

Definição da sintaxe de uma matched rule: rule nome_da_regra { from var_fonte : modelo_fonte[(condição)]? [using { variável_entrada1:tipo_variável_entrada1=expressão1; ... variável_entradan:tipo_variável_entradan=expressãon; }]? to variável_saída1 : tipo_variável_saída1(associações1), variável_saída2 : distinct tipo_variável_saída2 foreach(e in collection)(associações2), ... variável_saídan : tipo_variável_saídan (associaçõesn) [do { declarações_imperativas }]? }


23

A regra especifica a maneira como os elementos do modelo alvo devem ser

inicializados para cada modelo fonte correspondente. As matched rules são

introduzidas pela palavra rule, seguidas pelo nome_da_regra, que as identifica.

São obrigatoriamente compostas pelos padrões das fontes e dos alvos, e pelas secções

opcionais compostas por variáveis locais e imperativas.

O padrão fonte é definido depois da palavra-chave from e permite especificar o

elemento do modelo fonte, correspondente a determinado metamodelo, que será

transformado. O padrão alvo é introduzido pela palavra-chave to e permite

especificar os elementos (atributos e associações) que serão gerados quando o padrão

fonte da regra tem correspondência e como estes elementos gerados são inicializados.

O padrão alvo de uma matched rule dá origem a elementos distintos para cada

elemento do modelo alvo da regra que é gerado quando tem correspondência. Uma

associação (ou correspondência) é definida por nome_da_caracteristica

expressão.

Isto significa que cada regra gerará elementos alvo para cada elemento fonte que

esteja de acordo com as correspondências definidas.

Um elemento de um modelo fonte de uma transformação ATL não deve ser

correspondente a mais do que uma matched rule nem pode gerar valores

primitivos, sendo assim, deve-se ter cuidado para respeitar sempre esta restrição.

As secções de variáveis locais são introduzidas pela palavra-chave using,

permitindo declarar e inicializar localmente estas variáveis que serão apenas visíveis

no âmbito da regra em que estão inseridas.

As secções opcionais imperativas, introduzidas pela palavra-chave do tornam possível

especificar código imperativo que será executado depois da inicialização dos

elementos alvo gerados pela regra. rule InformacaoPai2InformacaoPessoa { from s : MMPai!InformacaoPai to t : MMPessoa!InformacaoPessoa ( name <- a.name, surname <- a.surname ) }

Código 4 – Exemplo de uma matched rule


24

Esta regra chamada InformacaoPai2InformacaoPessoa, tem como objectivo

transformar o modelo fonte InformacaoPai no modelo alvo InformacaoPessoa. Esta

regra apenas contem os padrões obrigatórios. O modelo alvo não define nenhum

filtro, o que significa que todas as classes InformacaoPai do metamodelo MMPai

serão correspondidas pela regra. O elemento padrão t alocará as classes

InformacaoPessoa e estas serão inicializadas com os atributos correspondentes da

classe InformacaoPai.

As lazy rules são idênticas às matched rules, mas apenas podem ser aplicadas

quando chamadas por outras regras.

As called rules facilitam a programação imperativa, e tal como os helpers,

têm de ser explicitamente chamadas para serem executadas, podendo aceitar

parâmetros. Contudo, podem gerar elementos em modelos alvo tal como as matched

rules. As called rules têm de ser chamadas através de uma secção de código

imperativo, quer a partir de uma matched rule ou outra called rule, excepto

quando se utiliza o entrypoint (cada transformação ATL apenas pode utilizar

um).

Definição da sintaxe de uma called rule: [entrypoint]? rule nome_da_regra''(''parâmetros''){ [using { variável1:tipo_variável1 = expressão1; ... variáveln:tipo_variáveln = expressãon; }]? [to variável_saída1 : tipo_variável_saída1(associações1), variável_saída2 : distinct tipo_variável_saída2 foreach(e in collection)(associações2), ... variável_saídan : tipo_variável_saídan (associaçõesn) [do { declarações_imperativas }]? }


25

Tal como as matched rules, estas são introduzidas pela palavra-chave rule e

podem incluir as secções opcionais para variáveis locais e imperativas. Contudo, visto

que não necessita de fazer correspondência, uma called rule não inclui o padrão

fonte. E o seu padrão alvo, que possibilita a geração de elementos de modelos alvo, é

opcional.

Visto que não se faz a correspondência de nenhum elemento de um modelo fonte, a

inicialização de elementos de um modelo alvo tem de ser baseada na combinação de

variáveis locais, parâmetros e atributos do módulo. O padrão alvo é definido da

mesma maneira que o de uma matched rule, introduzido igualmente pela palavra-

chave to.

Uma called rule tem de ser única numa transformação ATL e não pode ter o

mesmo nome que um helper nem chamar-se “main”.

rule NovaPessoa (nome: String, sobrenome: String) { to t : MMPessoa!Pessoa ( nomep <- nome ) do { t.sobrenomep <- sobrenome }

}

Código 5 – Exemplo de uma called rule

Esta called rule, chamada NovaPessoa, tem como objective gerar elementos

alvo do tipo Pessoa. A regra aceita dois parâmetros que correspondem com o nome e

o sobrenome do modelo Pessoa que será criado pela execução da regra. A regraé ao

mesmo tempo um padrão alvo chamado t e uma secção de código imperativo. Este

padrão aloca a classe Pessoa sempre que a regra é chamada e inicializa o nome do

atributo. O código imperativo coloca no sobrenomep o valor do parâmetro sobrenome.

3.1.5 Semântica da execução dos módulos

A execução, no modo normal, de um módulo ATL é organizada em três fases

sucessivas:


26

Fase de inicialização do modelo.

Fase de correspondência dos elementos do modelo fonte (source).

Fase de inicialização dos elementos do modelo alvo (target).

A primeira fase de execução corresponde à fase de inicialização do modelo, onde os

atributos definidos no contexto do módulo de transformação são inicializados. Se

houver o uso de atributos definidos no contexto de elementos de modelos fonte, esses

atributos também serão inicializados. Se for definida alguma called rule no

âmbito desse módulo, o código dessa regra, incluindo a geração de elementos do

modelo alvo, serão executados depois da inicialização dos atributos do módulo ATL.

Durante a fase de correspondência dos elementos fonte, as condições de

correspondência das matched rules declaradas, são testadas com os elementos dos

modelos fonte do módulo. Quando a correspondência é eficaz, a máquina ATL aloca

um conjunto de elementos do modelo alvo que correspondem aos elementos do

padrão alvo declaradas na regra.

A última fase corresponde à inicialização dos elementos gerados durante a fase

anterior. Neste ponto, cada elemento do modelo alvo alocado é inicializado pela

execução do código das ligações que estão associadas ao elemento padrão alvo. A

secção de código imperativo que pode ser especificado no âmbito de uma matched

rule, é executado uma vez que o passo de inicialização da regra esteja completo.

Este código imperativo pode provocar a execução de algumas called rules que

foram definidas no âmbito do módulo ATL.

A execução de um modo refining significa que não ocorrem cópias e as alterações

são directamente aplicadas no modelo fonte.

3.2 ATL Query

Uma query ATL consiste num modelo para transformação do valor de tipos de

dados primitivos. O seu uso mais comum é na geração de outputs de texto


27

(codificados em strings) a partir de um conjunto de modelos fonte. Contudo estas

queries não são limitadas à computação de Strings e podem ser retornadas como

valores numéricos ou booleanos.

3.2.1 Estrutura de uma ATL Query

Depois de uma secção para imports, deve ser definida uma instância para

queries. Esta instância é introduzida pela palavra-chave query e especifica a

maneira como um resultado deve ser computado.

Definição da sintaxe de uma query:

query nome_da_query = expressão

query ContaPessoa = MMPessoa!Pessoa.allInstances()->size().toString() .writeTo('resultado.txt');

Código 6 – Exemplo de uma query

Esta query é executada no modelo MMPessoa contendo o número de entidades

Pessoa. A query primeiramente selecciona o conjunto de todas as classes Pessoa

no modelo e vê o tamanho do conjunto. Tendo em conta que se pretende gravar este

valor num ficheiro, o valor resultante da operação size() (inteiro) será convertido

para string (operação toString()) e posteriormente escrito no ficheiro

“resultado.txt”

3.2.2 Semântica da execução da Query

Tal como um módulo ATL, a execução de uma query é organizada em sucessivas

fases. A primeira é a fase de inicialização que corresponde à fase de inicialização dos

módulos ATL e é dedicada á inicialização dos atributos que são definidos no contexto

do módulo ATL.


28

A segunda fase é a fase computacional em que o valor de retorno da query é

calculado pela execução do código declarativo de um elemento query de uma

query ATL.

Os helpers que foram definidos juntamente com a query podem ser chamados

em ambas as fases.

3.3 ATL Library

O desenvolvimento de bibliotecas ATL (ATL libraries) permite definir

conjuntos de helpers que podem ser chamados de diferentes unidades ATL.

Tal como os outros tipos de unidades, uma ATL library pode incluir uma

import section opcional e ainda permitir definir diversos helpers que

estarão disponíveis numa unidade ATL a importar.

Comparativamente a um módulo ATL, não existem elementos de modelos default,

sendo assim é impossível declarar helpers que estão definidos no contexto default

de um módulo, o que significa que todos os helpers definidos numa biblioteca

ATL devem ser explicitamente associados a um contexto.

Uma library não pode ser executada independentemente, sendo que não está

associada a nenhuma inicialização de um tempo de execução, impossibilitando ainda

definir attribute helpers.

3.4 Data Types

A linguagem ATL é baseada na Object Constraint Language (OCL) do OMG para os

seus tipos de dados. O esquema do tipo de dados é muito parecido com o definido

pela OCL.

O esquema seguinte mostra uma vista geral da estrutura de tipos de dados

considerados no ATL. Os diferentes tipos de dados apresentados representam

possíveis instâncias da classe OclType. Esta classe pode ser considerada como a

definição de tipos no âmbito da linguagem ATL. Os diferentes elementos representam


29

as instâncias definidas pelo OCL (com excepção dos tipos de dados Map e ATL

module) e executadas pelo ATL.

Figura 12 – Esquema da estrutura do tipo de dados ATL

O elemento raiz da estrutura das instâncias OclType é do tipo abstracto OclAny a

partir do qual todos os outros tipos estão directamente ou indirectamente relacionados.

A ATL considera os seguintes tipos de dados principais:

Primitive

Collection

EnumLiteral

Tuple

Map

OclModelElement

ATL module


30

O tipo de dados primitive corresponde ao tipo de dados básico da linguagem

(String, boolean e numerical). O conjunto de tipos collection

introduzido pelo OCL permite diversas formas de tratamento de colecções de

elementos. Tipos de dados adicionais que incluem os enumerations, tuple, map

e model element. Este último corresponde ao tipo de entidades que podem ser

declaradas com os modelos tratados pelo motor ATL.

Por fim, o tipo de dados ATL module, específica da linguagem ATL e associada com

as unidades ATL: modules e queries.

3.5 ATL Comments

Os comentários na ATL começam com dois hífenes “--“ e terminam no final da linha.

O editor ATL no Eclipse coloca os comentários a verde-escuro (standard).

-- Toda a linha faz parte do comentário

Código 7 – Exemplo de um comment

3.6 OCL Declarative Expressions

Para além das expressões declarativas que correspondem a instâncias de tipos de

dados suportados, a OCL define expressões declarativas adicionais:

Expressões “if”

Expressões “let”

A expressão “if” fornece uma facilidade de expressão alternativa. É expressada com

uma estrutura if-then-else-endif, de acordo com a seguinte sintaxe:


31

if condição

then

expressão1

else

expressão2

endif

De acordo com a avaliação da expressão booleana, a expressão “if” retorna o valor

correspondente à expressão1, no caso de a condição ser avaliada como verdadeira,

ou o valor da expressão2, no caso de a expressão ser avaliada como falsa.

Uma expressão deste tipo pode ser composta por outras expressões OCL, incluindo

expressões “let” e “if”.

A expressão “let” permite definir e inicializar novas variáveis. É definida de acordo

com a seguinte sintaxe:

let nome_da_variável : tipo_da_variável = expressão_inicialização_var

in expressão

A expressão de inicialização da variável, expressão_inicialização_var,

pode ser de qualquer tipo de expressão OCL, inclusive expressões “let”.


33

4 Transformação de um Modelo Java para

um Modelo de Classes UML em ATL

Para a transformação de um Modelo Java para um Modelo de Classes UML foi

utilizada a linguagem ATL, já descrita no capítulo anterior. O Modelo Java utilizado

para realizar a experiência obedece ao metamodelo JavaModel do EMF, ao qual, no

âmbito da transformação, será chamado EMF_JavaModel e o Modelo de Classes

UML, que será o resultado da transformação, obedece ao metamodelo UML do

UML2 e será denominado de UML2_UMLClassModel. À transformação será dado

o nome java2uml.

Figura 13 – Esquema da transformação ATL java2uml

Esta transformação chamada java2uml permite criar o modelo uml, que obedece

ao seu metamodelo UML2_UMLClassModel a partir do modelo java que obedece

ao seu metamodelo EMF_JavaModel. A transformação em questão obedece ao

ATL. Os três metamodelos (EMF_JavaModel, ATL e UML2_UMLClassModel)

obedecem à semântica do seu metametamodelo Ecore.


34

4.1 Criação do projecto ATL

Para executar a transformação pretendida, é necessário a criação de um ficheiro de

transformação ATL e dos ficheiros dos modelos fonte (source) e alvo (target).

O primeiro passo neste processo de desenho da transformação ATL é criar um

projecto ATL. Na plataforma Eclipse escolher:

File > New > ATL Project

Esta operação desencadeia o aparecimento de uma janela para criar um projecto ATL,

na qual é necessário introduzir o nome do projecto. Neste momento é aconselhado dar

um nome sugestivo, tal como concatenar o nome do modelo fonte java, o carácter 2

(“para”) e o nome do modelo alvo uml. Neste caso será dado o nome java2uml,

pois o objectivo é transformar modelos java em modelos uml.

A criação do projecto só é validada após carregar no botão Finish.

Figura 14 – Janela para criação de um novo projecto ATL

Para cada projecto, o Eclipse cria uma pasta do projecto na vista Navigator. O projecto gerado recentemente pode ser aberto nessa vista e inicialmente será


35

encontrado no seu interior o ficheiro (.project) que contém metadata Eclipse relativa ao projecto.

<?xml version="1.0" encoding="UTF-8"?>

<projectDescription>

<name>java2uml</name>

<comment></comment>

<projects>

</projects>

<buildSpec>

<buildCommand>

<name>org.eclipse.m2m.atl.adt.builder.atlBuilder</name>

<arguments>

</arguments>

</buildCommand>

</buildSpec>

<natures>

<nature>org.eclipse.m2m.atl.adt.builder.atlNature</nature>

</natures>

</projectDescription>

Código 8 – Exemplo do ficheiro .project

O passo seguinte consiste na criação do ficheiro de transformação ATL. Pode ser criado através da vista Navigator, escolhendo:

New > ATL File

Esta operação desencadeia o aparecimento da janela para criar um ficheiro ATL. O nome dado ao ficheiro (.atl) será o mesmo que o do projecto java2uml.


36

Figura 15 – Janela para criação de um novo ficheiro ATL

Após a criação do ficheiro ATL, pretende-se utilizar esse ficheiro para criar um

módulo ATL onde serão escritas todas as transformações.

O seguinte código fonte ATL representa o header do ficheiro java2uml.atl, ou

seja, o cabeçalho da transformação do modelo java que obedece ao seu metamodelo

EMF_JavaModel para o modelo uml que obedece ao seu metamodelo

UML2_UMLClassModel:

module java2uml;

create uml : UML2_UMLClassModel from java : EMF_JavaModel;

Código 9 – Header do ficheiro java2uml.atl

Visto que para o processo de transformação em questão são necessários dois modelos,

foram criados os dois ficheiros a eles correspondentes. O ficheiro java.java2,

contendo elementos a título exemplificativo, com todo o tipo de elementos possíveis

de serem criados num ficheiro deste género, e o ficheiro uml.uml sem nenhum


37

conteúdo, pois será nele que serão criados novos elementos após a transformação

ATL.

Figura 16 – Modelo Java exemplo do ficheiro java.java2

4.2 Criação das configurações

Para executar a transformação ATL, primeiramente é necessário instalar uma

configuração para o lançamento da transformação. Este configuração resume toda a

informação que é necessária para a execução de uma transformação ATL. A

informação inclui o caminho de todos os ficheiros envolvidos, tanto o dos modelos

como também o dos metamodelos e bibliotecas.

No menu principal da plataforma Eclipse, escolher:

Run > Run Configurations


38

Figura 17 – Janela que permite criar, gerir e correr as configurações

De seguida deve-se seleccionar ATL Transformation e carregar em New, sendo

criado um novo ficheiro de configuração ATL.

Neste ficheiro é necessário especificar o caminho (/java2uml/java2uml.atl),

do módulo ATL, que poderá ser encontrado no workspace. É ainda necessário dizer

qual o caminho para os metamodelos EMF_JavaModel e

UML2_UMLClassModel, que podem ser encontrados carregando no botão EMF

Regestry, onde são mostrados todos os packages registados no EMF.

Deve ainda ser escolhido o tipo de manipulador de modelos (Model handler)

respectivo a cada metamodelo. No caso do EMF_JavaModel deve-se escolher o

EMF, e no caso do UML2_UMLClassModel deve-se escolher o UML2.

Por fim especifica-se ainda quais os caminhos para os modelos fonte e alvo, também

eles encontrados no workspace.

É extremamente importante que esteja tudo bem configurado, caso contrário, mesmo

ocorrendo a transformação, esta não será perfeita.


39

4.3 Relações entre modelos

Neste momento está tudo configurado, resta escrever o código relativo ao módulo de

transformações. Para tal, primeiramente, é necessário analisar ambos os metamodelos

que serão usados e encontrar relações entre eles.

Esta fase foi extremamente difícil, pois os metamodelos apesar de terem algumas

semelhanças, são bastante diferentes. Para além disso, apesar de haver muita

documentação relativa ao metamodelo UML do UML2 ao qual, no âmbito da

transformação, se designou por UML2_UMLClassModel, a documentação do

metamodelo JavaModel é inexistente, portanto foi um grande desafio tentar

compreender o seu funcionamento e encontrar elementos coincidentes entre eles.

Visto que se pretende transformar o metamodelo JavaModel, procedeu-se ao estudo

das semelhanças às suas classes e respectivos atributos e referências.

4.3.1 JModelElement (abstracta) / Element (abstracta)

A classe JModelElement, classe abstracta, é o elemento base do

EMF_JavaModel, sendo que todos os restantes elementos do metamodelo ao qual

pertence são suas subclasses. O seu equivalente no UML2_UMLClassModel é a

classe Element, cujas características são semelhantes. Relativamente aos atributos

do JModelElement:

Atributo name, nome de um elemento, corresponde a um atributo com o

mesmo nome, pertencente à classe NamedElement, que suporta expressões

no tipo de dados string.

Tabela 2 – Relação entre metamodelos: JModelElement

EMF_JavaModel UML2_UMLClassModel

EClass::JModelElement EClass:Element

EAttribute::name:EString EAttribute::name:EString

(NamedElement)


40

4.3.2 JCompilationUnit

A classe JCompilationUnit representa toda a unidade de compilação Java. Esta

classe não pode ser representada no metamodelo UML2_UMLClassModel.

Visto que não existe correspondência directa no metamodelo

UML2_UMLClassModel, sugere-se várias alternativas. Estas não foram abordadas

no contexto deste trabalho pois como está inserido num projecto maior ainda nada foi

decidido. As possíveis alternativas seriam:

Para um elemento JCompilationUnit, embora não seja representado

explicitamente no UML2, poderia implicitamente dizer-se que este existe para

todas as classes do modelo UML que não estão definidas no contexto de outra

classe (isto é, não são “inner classes”).

Usar mecanismos de extensão dos modelos UML, como por exemplo

estereótipos (stereotypes) para acrescentar informação que o modelo não

suporta.

Alterar o metamodelo UML2_UMLClassModel para incluir este conceito.

4.3.3 JMember (abstracta)

A classe JMember é também uma classe abstracta, subclasse directa de

JModelElement e superclasse directa das classes:

JClass

JField

JInitializer

JMethod

Não existe nenhuma classe abstracta no UML2_UMLClassModel cujo objectivo

seja o mesmo que esta. No entanto é possível relacionar os seus atributos:

Atributo static, variável booleana, com o isStatic, do mesmo tipo, que

pertence à classe Feature.


41

Atributo visibility, variável booleana, com uma variável com o mesmo

nome mas cujo tipo é VisibilityKind, da classe NamedElement.

Atributo comment cuja equivalente é a variável body da classe Comment.

Visto que não existe equivalência para a classe JMember, automaticamente não faria

sentido existir uma referência equivalente à referência containingType. Estas

relações estão esquematizadas na tabela 2.

Tabela 3 – Relação entre metamodelos: JMember


EClass::JMember -

EGeneric Super Type::JModelElement


(NamedElement)

EAttribute::static:Eboolean EAttribute::isStatic:Boolean

(Feature)

EAttribute::visibility:JVisibility EAttribute::visibility:VisibilityKind

(NamedElement)

EAttribute::comment:EString EAttribute::body:String (Comment)

EReference::containingType:JClass -

4.3.4 JPackage / Package

A Classe JPackage do JavaModel tem uma classe equivalente no

UML2_UMLClassModel chamada Package, no entanto, relativamente às suas

superclasses, enquanto que o JPackage apenas tem o JModelElement, o seu

correspondente tem as superclasses:

Element

NamedElement

PackageableElement

ParameterableElement

TemplateableElement


42

Relativamente aos atributos:

Referência types, referência para JClasses de um JPackage, é

equivalente ao packagedElement que especifica os packageable

elements (JClasses) que pertencem a esse Package.

Tabela 4 – Relação entre metamodelos: JPackage


EClass::JPackage EClass::Package

EGeneric Super

Type::JModelElement

EGeneric Super Types::Element; NamedElement;

Namespace; ParameterableElement;

PackageableElement; TemplateableElement

EAttribute::name:EString EAttribute::name:EString (NamedElement)

EReference::types:JClass EReference::packagedElement:PackageableElement

4.3.5 JClass / Class

A classe JClass do JavaModel pode ser transformada numa Class e tem como

superclasses:

JMember

JModelElement

Enquanto que a Class tem como superclasses:

BeavioredClassifier

Classifier

Element

EncapsulatedClassifier

NamedElement

Namespace

PackageableElement



43

RedefinableElement

StructuredClassifier

TemplateableElement

Type

Atributos e referências da classe JClass com correspondentes no metamodelo

UML2_UMLClassModel:

Atributo abstract, booleano, corresponde ao atributo isAbstract,

booleano, da classe Classifier.

Atributo final, booleano, corresponde ao atributo isLeaf, booleano, da

classe RedefinableElement.

Referência fields, que referencia todos os elementos do tipo JField de

uma JClass, corresponde à referência ownedAttribute da classe

StructuredClassifier, que referencia todos os elementos do tipo

Property (elemento equivalente a JField no metamodelo

UML2_UMLClassModel).

Referência methods, que referencia todos os elementos do tipo JMethod de

uma JClass, corresponde à referência ownedOperation da classe

Class, que referencia todos os elementos do tipo Operation (elemento

equivalente a JMethod no metamodelo UML2_UMLClassModel).

Referência superTypes, que referencia todas as superclasses de uma dada

classe, corresponde à referência superClass da classe Class.

Referência package, que referencia todos o JPackage ao qual uma dada

JClass pertence (se aplicável), corresponde a uma referência com o mesmo

nome, da classe Type.

Referência types, que referencia todos os elementos JClass que fazem

parte de uma dada JClass, corresponde à referência nestedClassifier

da classe Class.


44

Os restantes atributos e referências não têm qualquer relação com outros no

metamodelo UML2_UMLClassModel.

Todas estas relações enunciadas estão esquematizadas na tabela 4.

Tabela 5 – Relação entre metamodelos: JClass


EClass::JClass EClass::Class

EGeneric Super Type::JMember; EGeneric Super

Types::EncapsulatedClassifier;

BeavioredClassifier;

StructuredClassifier; Classifier; Type;

packageableElement; RedefinableElement;

Namespace; TemplateableElement;

Element; ParameterableElement;

NamedElement;


EAttribute::static:Eboolean EAttribute::isStatic:Boolean (Feature)


(NamedElement)


EAttribute::abstract:Eboolean EAttribute::isAbstract:Boolean

(Classifier)

EAttribute::final:EBoolean EAttribute::isLeaf:Boolean

(RedefinableElement)

EAttribute::interface:EBoolean -

EAttribute::throwable:EBoolean -

EReference::fields:JField EReference::ownedAttribute:Property

(StructuredClassifier)

EReference::methods:JMethod EReference::ownedOperation:Operation

EReference::superTypes:JClass EReference::superClass:Class

EReference::allSuperTypes:JClass -

EReference::members:JMember -

EReference::componentType:JClass -

EReference::arrayType:JClass -

EReference::unit:JCompilationUnit -

EReference::allMethods:JMethod -

EReference::allFields:JField -

EReference::package:JPackage EReference::package:Package (Type)


45

EReference::types:JClass EReference::nestedClassifier:Classifier

EReference::allTypes:JClass -

4.3.6 JField / Property

A classe JField pode ser transformada numa Property e tem como superclasses:

JMember

JModelElement

As superclasses da Property são:

ConnectableElement

DeploymentTarget

Element

Feature

MultiplicityElement

NamedElement


RedefinableElement

StructuralFeature

TemplateableElement

TypedElement

Atributos e referências da classe JField com correspondentes no metamodelo

UML2_UMLClassModel:

Atributo final, tipo booleano, corresponde ao atributo isLeaf, também

booleano, da classe RedifinableElement.

Atributo volatile, do tipo booleano, corresponde ao atributo

isReadOnly, do mesmo tipo, pertencente à classe StructuralFeature.

Relações esquematizadas na Tabela 5.


46

Tabela 6 – Relação entre metamodelos: JField


EClass::JField EClass::Property

EGeneric Super Type::JMember EGeneric Super

Types::ConnectableElement;

DeploymentTarget; Element; Feature;

MultiplicityElement; NamedElement;

ParameterableElement;

StructuralFeature;

TemplateableElement; TypedElement


(NamedElement)

EAttribute::static:Eboolean EAttribute::isStatic:Boolean

(Feature)


(NamedElement)



(RedifinableElement)

EAttribute::transient:EBoolean -

EAttribute::volatile:EBoolean EAttribute::isReadOnly:Boolean

(StructuralFeature)

EAttribute::initializer:EString -

EReference::type:JClass -

4.3.7 JInitializer

Esta classe não pode ser representada no metamodelo UML2_UMLClassModel.

4.3.8 JMethod / Operation

A Classe JMethod corresponde à classe Operation no UML2_UMLClassModel

e tem como superclasses:

JMember

JModelElement

As superclasses da classe Operation são:


47

BehavioralFeature

Element

Feature

NamedElement

Namespace


RedefinableElement

TemplateableElement

Atributos e referências da classe JMethod com correspondentes no metamodelo

UML2_UMLClassModel:

Atributo abstract, do tipo booleano, corresponde ao atributo

isAbstract, também booleano, da classe Classifier.

Atributo final, tipo booleano, corresponde ao atributo isLeaf, também

booleano, da classe RedifinableElement.

Atributo synchronized, do tipo booleano, corresponde ao atributo

concurrency, do tipo CallConcurrencyKind, pertencente à classe

BehavioralFeature.

Referência ownedParameter, do tipo Parameter, que referencia todos

os elementos do tipo Parameter que pertencem à Operation.


48

Tabela 7 – Relação entre metamodelos: JMethod


EClass::JMethod EClass::Operation

EGeneric Super Types::JMember EGeneric Super Types::BehavioralFeature;

Element; Feature; NamedElement; Namespace;

ParameterableElement; RedefinableElement;

TemplateableElement;


EAttribute::static:Eboolean EAttribute::isStatic:Boolean (Feature)


(NamedElement)


EAttribute::abstract:Eboolean EAttribute::isAbstract:Boolean (Classifier)


(RedifinableElement)

EAttribute::native:EBoolean -

EAttribute::synchronized:EBoolean EAttribute::concurrency:CallConcurrencyKind

(BehavioralFeature)

EAttribute::constructor:EBoolean -

EAttribute::body:EString -

EReference::parameters:JParameter Ereference::ownedParameter:Parameter

(Behavioral Feature)

EReference::exceptions:JClass -

EReference::returnType:JClass -

4.3.9 JParameter

A classe JParameter no EMF_JavaModel corresponde à classe Parameter do

UML2_UMLClassModel e apenas tem uma superclasse designada por

JModelElement. No entanto, a classe Parameter tem as superclasses:

ConnectableElement

Element


MultiplicityElement


49

NamedElement

TypedElement

A única referência com equivalência é a method, do tipo JMethod, que referencia

qual o JMethod ao qual o JParameter pertence. Esta corresponde à referencia

operation, do tipo Operation, da classe Parameter.

Tabela 8 – Relação entre metamodelos: JParameter


EClass::JParameter EClass::Parameter

EGeneric Super

Type::JModelElement

EGeneric Super

Types::ConnectableElement;

Element; ParameterableElement;

MultiplicityElement;

NamedElement; TypedElement


(NamedElement)

EAttribute::final:EBoolean -

EReference::method:JMethod EReference::operation:Operation

EReference::type:JClass -

4.4 Criação de código ATL

Visto que já se sabe todas as relações entre os metamodelos, procede-se com a criação

das regras (rules) de código ATL. Em todas as regras será utilizada a variável s

para os modelos fonte (source) e a variável t para os modelos alvo (target).

Primeiramente faz-se a construção do código ATL de transformação do elemento

JPackage para Package. O seguinte código representa uma matched rule

usada para essa transformação:


50

rule JPackage2Package{ from s: EMF_JavaModel!JPackage to t: UML2_UMLClassModel!Package ( --Attributes-- name <- s.name, --String --Associations-- packagedElement <- s.types --PackageableElement --Class ) }

Código 10 – Matched rule JPackage2Package

Esta regra, chamada JPackage2Package, representa a transformação dos

elementos do modelo fonte JPackage (metamodelo EMF_JavaModel) para os

elementos do modelo alvo Package (metamodelo UML2_UMLClassModel). Esta

regra apenas contém os padrões fonte e alvo, obrigatórios.

O padrão fonte não tem nenhum filtro definido, significa então que todas as classes

JPackage do metamodelo EMF_JavaModel serão correspondidas de acordo a

regra. O padrão alvo contém um único elemento padrão, chamado “t”, que criará

classes Package para cada elemento correspondente JPackage.

Os atributos dos elementos gerados são inicializados com os correspondentes

atributos dos elementos do modelo fonte.

Para as restantes transformações foram também usadas matched rules, sendo que

o funcionamento descrito é idêntico para todas elas.

O código ATL relativo à transformação do elemento JClass para Class é

representado através da seguinte matched rule:


51

rule JClass2Class{ from s: EMF_JavaModel!JClass to t: UML2_UMLClassModel!Class ( --Attributes-- isAbstract <- s.abstract, --Boolean isLeaf <- s.final, --Boolean name <- s.name, --String visibility <- s.visibility, --VisibilityKind --Associations-- nestedClassifier <- s.members, --Classifier --(JClass) ownedAttribute <- s.members, --Property --(JField) ownedOperation <- s.members, --Operation --(JMethod) ownedComment <- t2 --Comment ), t2: UML2_UMLClassModel!Comment ( --Attributes-- body <- s.comment --String )

}

Código 11 – Matched rule JClass2Class

O código ATL relativo à transformação do elemento JField para Property é


rule JField2Property{ from s: EMF_JavaModel!JField to t: UML2_UMLClassModel!Property ( --Attributes-- name <- s.name, --String isLeaf <- s.final, --Boolean visibility <- s.visibility, --VisibilityKind isStatic <- s.static, --Boolean isReadOnly <- s.volatile.alterar(), --Boolean --Associations-- ownedComment <- t2 --Comment ), t2: UML2_UMLClassModel!Comment ( body <- s.comment --String )

}

Código 12 – Matched rule JField2Property


52

Nesta regra é utilizado um helper simples chamado “alterar”. Quando

chamado, no caso da variável do tipo booleana ser true é alterada para false e vice

versa. Esse helper é apresentado através do código seguinte:

helper context Boolean def: alterar() : Boolean = if self= true then false else true

endif;

Código 13 – Helper alterar()

O código ATL relativo à transformação do elemento JMethod para Operation é


rule JMethod2Operation{ from s: EMF_JavaModel!JMethod to t: UML2_UMLClassModel!Operation ( --Attributes-- name <- s.name, --String isAbstract <- s.abstract, --Boolean isStatic <- s.static, --Boolean isLeaf <- s.final, --Boolean visibility <- s.visibility, --VisibilityKind --concurrency <- if s.synchronized ='True' then 'Sequencial' else 'Concurrent' endif, --Associations-- ownedParameter <- s.parameters, --Parameter ownedComment <- t2 --Comment ), t2: UML2_UMLClassModel!Comment ( --Attributes-- body <- s.comment --String )

}

Código 14 – Matched rule JMethod2Operation

O código ATL relativo à transformação do elemento JParameter para Parameter é



53

rule JParameter2Parameter{ from s: EMF_JavaModel!JParameter to t: UML2_UMLClassModel!Parameter ( --Attributes-- name <- s.name --String )

}

Código 15 – Matched rule JParameter2Parameter

4.5 Execução das configurações

Por fim, no menu principal da plataforma Eclipse, escolher:

Run > Run Configuration > Run

As configurações são executadas, é feita a transformação ATL e o ficheiro uml.uml

é alterado dando origem ao modelo de Classes UML exemplo, representado na figura

seguinte.


54

Figura 18 – Modelo de Classes UML do ficheiro uml.uml

Neste momento pode ser feita qualquer alteração ao modelo java, seguida da execução

das configurações, sendo automaticamente gerado um novo modelo uml relativo à

nova transformação.


55

5 Conclusões

5.1 Objectivos realizados

O objectivo proposto de desenvolver suporte experimental para que modelos java

pudessem ser manipulados e transformados em modelos de classes UML foi atingido.

Numa primeira fase foi necessário estudar e compreender a framework EMF do

Eclipse, e os metamodelos relativos aos modelos Java e aos modelos de classes UML.

Neste ponto foi encontrada uma grande dificuldade relativa à compreensão do

metamodelo do Java, o JavaModel, presente no EMF, pois não existe documentação a

ele relativa.

Em seguida passou-se ao estabelecimento de relações entre os metamodelos, que

apesar de não ter sido concluído deveu-se apenas à incompatibilidade entre

determinados elementos dos metamodelos.

Por fim, estudou-se a linguagem de transformação ATL e passou-se à construção das

transformações que permitiram atingir o objectivo principal, em que qualquer que

fosse o modelo Java criado pudesse ser transformado com sucesso num modelo de

classes UML.

5.2 Limitações & trabalho futuro

Um dos problemas encontrados ao longo de análise das relações entre metamodelos

prendeu-se com a falta de documentação relativa ao metamodelo JavaModel, o que

dificultou muito a compreensão dos conceitos a ele inerentes.

Relativamente ao objecto em si, a transformação entre modelos, apresenta algumas

limitações. Nem todos os elementos do metamodelo JavaModel, sejam eles atributos

ou referências, têm uma representação igual ou equivalente no metamodelo UML do

UML2, apesar da sua grandeza e complexidade. No entanto não invalida o sucesso

deste projecto pois o objectivo deste consistia nisso mesmo, pesquisar, analisar e

desenvolver suporte experimental.


56

Num trabalho futuro pretende-se que seja desenvolvido o processo inverso a este

projecto, suporte para a manipulação de Modelos de Classes UML e transformação

em Modelos Java. Ambas as transformações serão integradas numa framework open

source de suporte ao desenvolvimento baseado em modelos de linhas de produtos de

software baseada na metodologia MoDeLine.

5.3 Apreciação final

A nível pessoal, o projecto foi bastante gratificante pois promoveu o desenvolvimento

de soft e hard skills.

Permitiu o contacto e experiência com este novo paradigma, Model-Driven

Development, em que os artefactos de software são manipulados como modelos e

ainda o conhecimento de novas plataformas de desenvolvimento, frameworks e

linguagens de modelação.

Foi muito gratificante ver que o trabalho desenvolvido ao longo destes meses foi

concluído e será utilizado para um projecto de maior grandeza.

Deixo uma nota de agradecimento ao Professor Doutor Alexandre Bragança por todo

o apoio disponibilizado desde o primeiro dia, promovendo o sucesso deste projecto.


57

Bibliografia Atlas Transformation Language (ATL):

(2006) ATL: Atlas Transformation Language, ATL User Manual, version 0.7,

Lina & Inria(Atlas Group), University of Nantes, France, Fev.

http://www.eclipse.org/m2m/atl/

http://wiki.eclipse.org/index.php/ATL

Eclipse:

http://www.eclipse.org/

http://wiki.eclipse.org/Eclipse

http://help.eclipse.org/

Eclipse Modeling Framework (EMF):

Steinberg, D., Budinsky, F., Merks, E., Ellersick, R., Grose, T.J. (2003)

Eclipse Modeling Framework: A Developer's Guide, Addison Wesley

Professional.

Tibrea, E. (2006), Enriching EMF models with behavioral specifications,

Hamburg University of Science and Technology, Software Systems Institute

(STS), Hamburg, German.

http://www.eclipse.org/modeling/emf/

http://wiki.eclipse.org/EMF

Eclipse Modeling Project:

http://www.eclipse.org/modeling/

http://wiki.eclipse.org/Modeling

Model-Driven Architecture (MDA):

http://www.omg.org/mda/mda_files/Model-Driven_Architecture.pdf

http://www.omg.org/mda/


58

Model-Driven Engineering (MDE):

Schmidt, D.C. (2006) Model-Driven Engineering, IEEE Computer Society,

Vanderbilt University.

Jézéquel, J. (2006), Introduction to Model-Driven Engineering, Univ. Rennes

1 & INRIA, Triskell Team, IRISA, France.

Bézivin, J. (2004), In Search of a Basic Principle for Model Driven

Engineering, The European Journal for the Informatics Professional, Vol. V,

No. 2, pp.21-24.

Model Development Tools (MDT):

http://www.eclipse.org/modeling/mdt/

http://wiki.eclipse.org/MDT

Model-To-Model (M2M):

http://www.eclipse.org/m2m/

http://wiki.eclipse.org/M2M

Object Constraint Language (OCL):

http://wiki.eclipse.org/MDT/OCL

Object Management Group (OMG):

http://www.omg.org/

Unified Modeling Language (UML):

(2009) OMG Unified Modeling Language (OMG UML), Infrastructure,

Version 2.2, formal/2009-02-04, Object Management Group, Fev

(http://www.omg.org/spec/UML/2.2/Infrastructure/PDF/).

(2009) OMG Unified Modeling Language (OMG UML), Superstructure,

Version 2.2, formal/2009-02-02, Object Management Group, Fev

(http://www.omg.org/spec/UML/2.2/Superstructure/PDF/).

http://www.uml.org/

http://www.uml.org/


59

UML2:

http://www.eclipse.org/uml2/

http://wiki.eclipse.org/MDT-UML2


Pedro Dias 61

Anexo 1 Metamodelo EMF_JavaModel

Figura 19 – Metamodelo EMF_JavaModel – Jclass

Figura 20 – Metamodelo EMF_JavaModel – JcompilationUnit

Figura 21 – Metamodelo EMF_JavaModel – JField


62

Figura 22 – Metamodelo EMF_JavaModel – JInitializer

Figura 23 – Metamodelo EMF_JavaModel – JMember

Figura 24 – Metamodelo EMF_JavaModel – JMethod

Figura 25 – Metamodelo EMF_JavaModel – JModelElement

Figura 26 – Metamodelo EMF_JavaModel – JPackage


63

Figura 27 – Metamodelo EMF_JavaModel – JParameter

Figura 28 – Metamodelo EMF_JavaModel – JVisibility


Pedro Dias 64

Anexo 2 Metamodelo

UML2_UMLClassModel

Figura 29 – Metamodelo UML2_UMLClassModel – EData Types

Figura 30 – Metamodelo UML2_UMLClassModel – EClass::Comment

Figura 31 – Metamodelo UML2_UMLClassModel – EClass::Feature

Figura 32 – Metamodelo UML2_UMLClassModel – EEnum::VisibilityKind


65

Figura 33 – Metamodelo UML2_UMLClassModel – EClass::TypedElement

Figura 34 – Metamodelo UML2_UMLClassModel – EClass::TemplateableElement

Figura 35 – Metamodelo UML2_UMLClassModel – EClass::ParameterableElement

Figura 36 – Metamodelo UML2_UMLClassModel – EClass::ConnectableElement


66

Figura 37 – Metamodelo UML2_UMLClassModel – EClass::BehavioralFeature

Figura 38 – Metamodelo UML2_UMLClassModel – EClass::DeploymentTarget

Figura 39 – Metamodelo UML2_UMLClassModel – EClass::EncapsulatedClassifier

Figura 40 – Metamodelo UML2_UMLClassModel – EClass::PackageableElement


67

Figura 41 – Metamodelo UML2_UMLClassModel – EClass::Element


68

Figura 42 – Metamodelo UML2_UMLClassModel – EClass::NamedElement

Figura 43 – Metamodelo UML2_UMLClassModel – EClass::Namespace


69

Figura 44 – Metamodelo UML2_UMLClassModel – EClass::Package

Figura 45 – Metamodelo UML2_UMLClassModel – EClass::Type


70

Figura 46 – Metamodelo UML2_UMLClassModel – EClass::Classifier


71

Figura 47 – Metamodelo UML2_UMLClassModel – EClass::Parameter

Figura 48 – Metamodelo UML2_UMLClassModel – EClass::RedefinableElement


72

Figura 49 – Metamodelo UML2_UMLClassModel – EClass::MultiplicityElement

Figura 50 – Metamodelo UML2_UMLClassModel – EClass::Class


73

Figura 51 – Metamodelo UML2_UMLClassModel – EClass::Property


74

Figura 52 – Metamodelo UML2_UMLClassModel – EClass::Operation

Figura 53 – Metamodelo UML2_UMLClassModel – EClass::StructuredClassifier


75

Figura 54 – Metamodelo UML2_UMLClassModel – EClass::BehavioredClassifier

transformação modelo pc MDA 2

Documents

Transcript of transformação modelo pc MDA 2