TCC Rhaylson

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA DO PIAU
CAMPUS TERESINA CENTRAL

TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS
RHAYLSON SILVA DO NASCIMENTO
GENJPA: UMA FERRAMENTA DIRIGIDA POR MODELOS PARA GERAO DE

CDIGO JAVA/JPA
TERESINA, PIAU
2017

CDIGO JAVA/JPA
Projeto apresentado Banca Examinadora como

requisito para aprovao na disciplina de Traba-
lho de Concluso de Curso II do Curso Superior
de Tecnologia em Anlise e Desenvolvimento
de Sistemas do Instituto Federal de Educao,
Cincia e Tecnologia do Piau.
Orientador: Prof. Me . Fernando Castelo

Branco Gonalves Santana
TERESINA, PIAU
2017
FICHA CATALOGRFICA
Sistema de Bibliotecas
Gerada automaticamente com dados fornecidos pelo(a) autor(a)
Nascimento, Rhaylson Silva do

N244g GenJPA : Uma Ferramenta Dirigida por Modelos para Gerao de Cdigo Java/JPA /
Rhaylson Silva do Nascimento - 2017.
83 p. : il. color.
Trabalho de concluso de curso (Tecnologia) - Instituto Federal de Educao,

Cincia e Tecnologia do Piau, Campus Teresina Central, Tecnologia em Anlise e
Desenvolvimento de Sistemas, 2017.
Orientador : Prof Me. Fernando Castelo Branco Gonalves Santana.
1. UML. 2. Diagramas de Classes. 3. Engenharia Frente. 4. Java. 5. Java

Persistence API. I.Ttulo.
CDD 004

CDIGO JAVA/JPA
Projeto apresentado Banca Examinadora como

requisito para aprovao na disciplina de Traba-
lho de Concluso de Curso II do Curso Superior
de Tecnologia em Anlise e Desenvolvimento
de Sistemas do Instituto Federal de Educao,
Cincia e Tecnologia do Piau.
Aprovado pela banca examinadora em 28 de junho de 2017.

BANCA EXAMINADORA:
Prof. Me . Fernando Castelo Branco Gonalves Santana

Instituto Federal de Educao, Cincia e Tecnologia do Piau - IFPI
Prof. Dr. Fraciric Alves de Arajo

Prof. Me . Duanny Dreyton Bezerra Sousa

TERESINA, PIAU
2017
Dedico esta monografia minha me Lcia.
AGRADECIMENTOS
Agradeo, primeiramente, Deus por ter me dado o dom da vida.

Aos meus familiares pelo suporte e pelos valores sociais a mim repassados.
Aos amigos que estiveram ao meu lado no decorrer desta jornada acadmica, sempre
muito solcitos e presentes.
Ao meu orientador Fernando Castelo Branco Gonalves Santana pelo apoio e pela
pacincia despendida durante a elaborao desse trabalho.
Aos professores Duanny Dreyton Bezerra Sousa e Fraciric Alves de Arajo que aceita-
ram o convite para participar da banca de trabalho de concluso de curso.
Aos mestres do curso de Tecnologia em Anlise e Desenvolvimento de Sistemas por
repassarem seus valiosos conhecimentos dessa rea to rica que a computao.
Ao Instituto Federal de Educao Cincia e Tecnologia do Piau por me fornecer a
oportunidade de exercer pesquisas e estgios durante todo o curso.
RESUMO
A gerao de cdigo Java a partir de diagramas da UML, alm de ser tema de estudo no meio
acadmico prtica recorrente no mercado de software. Diversas ferramentas, dentre elas as trs
maiores do mercado de modelagem implementam a tcnica de engenharia frente (transformao
modelo-cdigo) em Java. Entretanto, observa-se inconsistncias no cdigo gerado por muitas
dessas aplicaes. Conceitos mais complexos do diagrama de classes, como o de agregao,
composio e navegabilidade deixam de ser transcritos durante a transformao, acarretando
na quebra das restries do projeto. Alm disso, a interao com o usurio uma funo
pouco explorada neste tipo de aplicao, limitando-se a apresentao de mensagens de erro. A
constatao desses problemas serviu de motivao para elaborao da ferramenta apresentada
nesta monografia, a GenJPA. Nela foi implementa uma engenharia frente mais completa,
baseada na linguagem Java e em anotaes da Java Persistence API, capaz de mapear itens mais
complexos do digrama de classes para o cdigo e assim diminuir a ocorrncia de inconsistncias.
Palavras-chaves: UML, Diagramas de Classes, Engenharia Frente, Java, Java Persistence

API.
ABSTRACT
The generation of Java code from UML diagrams, besides a studied theme in academia, is a
recurrent practice in the software market. Many tools, including the top three in modeling market,
implement foward engineering techniques (model-code transformation) in Java. However,
inconsistencies are observed in the generated code in many of these applications. More complex
concepts of classes diagram, such as aggregation, composition and navigability are no longer
transcribed during its transformation, resulting a breakdown on design constraints. In addition,
user interaction is an under-exploited function on this application, limiting to a mere error
message presentations. These problems were the motivation to the creation of the tool presented
on these work, the GenJPA. It was implemented a more complete engineering, based on Java
Language and notes from Java Persistence API, able to map more complex items from class
diagram to the code, thus aiming to reduce the occurrence of inconsistences.
Key-words: UML, Classes Diagram, Foward Engineering, Java, Java Persistence API.
LISTA DE ILUSTRAES
Figura 1 Transformao Inconsistente de uma Composio [1]. . . . . . . . . . . . . 16

Figura 2 Transformao Inconsistente da Navegabilidade [1]. . . . . . . . . . . . . . 16
Figura 3 Representao de Classes e Objetos. . . . . . . . . . . . . . . . . . . . . . 20
Figura 4 Organizao dos Diagramas na UML. Adaptado da UML Superstructure [2]. 21
Figura 5 Diagrama de Classes que Apresenta Entidades. Adaptado de Booch e outros [7]. 23
Figura 6 Model Driven Architecture [3]. . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 7 Execuo de um Programa Java. Adaptado de Devmedia [4]. . . . . . . . . 28
Figura 8 Classe Pessoa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 9 Atributos Privados da Classe Pessoa. . . . . . . . . . . . . . . . . . . . . . 31
Figura 10 Herana na UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 11 Associao Binria Simples. . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 12 Associao Unria ou Reflexiva. . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 13 Exemplos de Agregao e Composio. . . . . . . . . . . . . . . . . . . . 34
Figura 14 Diagrama de Classes Modelado na HiberObjects. Adaptado de Cgernert [5]. 36
Figura 15 Diagrama de Classes no padro MD-JPA [6] . . . . . . . . . . . . . . . . . 37
Figura 16 Interface da GenJPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 17 Funcionamento da GenJPA. . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 18 Classe CarregaArquivoXML.java . . . . . . . . . . . . . . . . . . . 43
Figura 19 Classes de Modelo da GenJPA. . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 20 Erro.java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 21 Feedback ao Usurio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 22 Arquivo de Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 23 Diagrama de Exemplo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 24 Diagrama de Exemplo aps a Transformao das Classes. . . . . . . . . . . 51
Figura 25 Diagrama de Exemplo Aps o Mapeamento das Generalizaes. . . . . . . 52
Figura 26 Diagrama de Exemplo Aps o Mapeamento dos Atributos Temporais. . . . 52
Figura 27 Diagrama de Exemplo Aps o Mapeamento das Associaes. . . . . . . . . 53
Figura 28 Diagrama de Exemplo com Composio. . . . . . . . . . . . . . . . . . . . 54
Figura 29 Diagrama de Exemplo com Agregao. . . . . . . . . . . . . . . . . . . . . 54
Figura 30 Cdigo Gerado pelo Diagrama com Associao Simples. . . . . . . . . . . 55
Figura 31 Cdigo Gerado pelo Diagrama com Agregao. . . . . . . . . . . . . . . . 55
Figura 32 Cdigo Gerado pelo Diagrama com Composio. . . . . . . . . . . . . . . 56
Figura 33 Feedback Final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
LISTA DE TABELAS
Tabela 1 Propriedades Especficas de Cada Item. . . . . . . . . . . . . . . . . . . . . 41

Tabela 2 Itens Bsicos do Diagrama de Classes. . . . . . . . . . . . . . . . . . . . . 42
Tabela 3 Excees da GenJPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Tabela 4 Classes de Controle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Tabela 5 Anotaes Suportadas pela GenJPA. . . . . . . . . . . . . . . . . . . . . . 50
LISTA DE ABREVIATURAS E SIGLAS
API Application Programing Interface
CASE Computer Assisted Software Engineering
CIM Computation Independent Model
EA Enterprise Architect
GUI Graphical User Interface
GWT Google Web Toolkit
IDE Integrated Development Environment
JPA Java Persistence API
JVM Java Virtual Machine
MTL Model To Text Transformation Language
MDA Model Driven Archtecture
MD Model Driven
MDD Model Driven Development
MDE Model Driven Engineering
MOF Meta Object Facility
OMG Object Management Group
OO Orientao a Objetos
ORM Object/Relational Mapping
PSM Platform Specific Model
UML Unified Modeling Language
XMI XML Metadata Interchange
XML Extensible Markup Language

SUMRIO
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.2 Objetivos Especficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 FUNDAMENTAO TERICA . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Orientao a Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Classes e Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2 Heranas e Polimorfismo . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3 Perspectiva de Dados no Diagrama de Classes . . . . . . . . . . . . . . . . 23
2.3 Engenharia Frente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.2 Metodologias Dirigidas por Modelos . . . . . . . . . . . . . . . . . . . . . 25
2.3.3 Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.2 Tipos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Mapeamento Objeto-Relacional . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Influncia da JPA nos Itens de Interesse do Modelo . . . . . . . . . . . . . . 30
2.7 Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7.1 Atributo da Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8 Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8.1 Generalizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8.2 Associao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8.3 Agregao e Composio . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . 35
3.1 GenCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 HiberObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 MD-JPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 GENJPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Mdulo de Extrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.1 Normalizao de Nomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2 Resultados da Etapa de Extrao . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Fase de Validao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Interpretao do Arquivo XML . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.2 Validao dos Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2.1 Validao dos Nomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2.2 Validao dos Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2.3 Validao das Generalizaes . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2.4 Validao das Associaes . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.3 Finalizao das Validaes . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Fase de Construo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Mdulo de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Mapeamento objeto-relacional . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1 Transformao de Classes em Entidades . . . . . . . . . . . . . . . . . . . 50
4.4.2 Mapeamento de Heranas . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.3 Mapeamento de Atributos Temporais . . . . . . . . . . . . . . . . . . . . . 52
4.4.4 Mapeamento de Associaes . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.4.1 Mapeamento de Composio . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.4.2 Mapeamento de Agregao . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 Gerao do Cdigo Executvel . . . . . . . . . . . . . . . . . . . . . . . . 55
5 CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
ANEXO A REGRAS DE EXTRAO EM ACCELEO . . . . . . . . 60
ANEXO B SISTEMA DE LEILO ONLINE . . . . . . . . . . . . . 62

B.1 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.2 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.2.1 Participante.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.2.2 Lance.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.2.3 Leilao.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.2.4 Item_Leilao.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
B.3 Diagrama Entidade-Relacionamento . . . . . . . . . . . . . . . . . . . . . 70
ANEXO C SISTEMA BANCRIO . . . . . . . . . . . . . . . . . . . 71

C.1 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
C.2 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
C.2.1 Conta_Comum.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
C.2.2 Conta_Poupanca.java . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.2.3 Conta_Especial.java . . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.2.4 Pessoa.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
C.2.5 Pessoa_Juridica.java . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.2.6 Pessoa_Fisica.java . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.2.7 Movimento.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
C.3 Diagrama Entidade-Relacionamento . . . . . . . . . . . . . . . . . . . . . 81
14
1 INTRODUO
Nesse captulo so apresentadas as razes que levaram a criao da ferramenta. Apresenta-

se tambm alguns dos conceitos introdutrios que fazem parte do domnio da aplicao, alm de
linguagens e ferramentas.
1.1 CONTEXTUALIZAO
A modelagem uma tcnica de engenharia aprovada, bem aceita e utilizada por enge-
nheiros para descrever e planejar seus projetos. Na indstria de software, modelos so utilizados
na especificao e visualizao dos diversos itens que compe a estrutura e comportamento
de um sistema de informao, bem como na documentao das decises tomadas durante seu
desenvolvimento [7]. Um modelo uma simplificao da realidade, ou seja, uma abstrao do
domnio do problema que descreve o sistema sob determinada perspectiva. Eles podem abranger
planos detalhados ou simplificados do projeto, possuindo sintaxe e semntica distinta que os
diferencia [8].
Assim como na arquitetura e na engenharia, onde existem mtodos padres para reali-
zao da modelagem de projetos, tambm existe uma linguagem padro para a modelagem de
sistemas de informao, mais especificamente daqueles que seguem o paradigma orientado a
objetos: a Linguagem Unificada de Modelagem (UML) (do ingls Unified Modeling Language).
A UML uma linguagem de modelagem visual que estabelece vocabulrio e regras especficos
para construo de modelos que apresentem a estrutura do projeto e forneam uma viso concei-
tual e fsica do sistema [7]. Ela define um conjunto de blocos de construo e itens relacionais
que permitem ao projetista criar modelos, em formato de diagrama, que apresentem uma ou mais
vises do sistema projetado.
Na UML, os diagramas so classificados em dois grupos de acordo com o tipo de viso
fornecida por seus componentes [1]: estruturais e comportamentais. Diagramas estruturais tm
seu foco voltado para representao e visualizao dos componentes estticos do sistema, ou seja,
aqueles que esto menos propensos a mudanas, como classes, interfaces e pacotes. J diagramas
comportamentais do nfase dinmica do software, descrevendo suas rotinas e funcionamento
interno. Quando agrupados, modelos estruturais e comportamentais fornecem uma ampla viso
das caractersticas do sistema.
O diagrama de classes o mais utilizado e um dos mais importantes da UML [8]. Nele,
est definido o principal bloco usado na implementao de sistemas orientados a objetos: a
classe [7]. Uma classe identifica e caracteriza determinado elemento de interesse da aplicao,
apresentando suas propriedades e comportamento. Por meio de classes, itens conceituais e
concretos, que formam o domnio do problema da aplicao, so identificados, fornecendo assim
Captulo 1. Introduo 15
uma viso estrutural da arquitetura do sistema.

Todas as linguagens de programao orientada a objetos fornecem notaes para o
conceito de classe. Por isso, comum que o diagrama citado seja utilizado como artefato de
entrada para o processo de engenharia frente [7]. Essa tcnica, implementada por ferramentas
especficas, consiste na gerao de cdigo a partir de modelos detalhados.
Utilizando regras de transformao que relacionam afbstraes do modelo elementos
de uma determinada linguagem de programao, tais ferramentas de transformao conseguem
automatizar a implementao do sistema. Nesse processo, os conceitos de classe, atributo,
operao, relacionamento, dentre outros do modelo de classes so usados para gerar a definio
bsica da aplicao, isto , seu esqueleto.
A maioria das ferramentas CASE do mercado so capazes de executar a engenharia
frente a partir de diagramas de classes, porm muitas apresentam falhas ao fazer o mapeamento
de alguns elementos mais complexos da UML, seja devido a limitaes da linguagem de destino
ou por desconsiderarem a existncia deles no diagrama [1]. Conceitos importantes do diagrama
de classes, como o de agregao e composio das associaes, no so mapeados para o cdigo
por nenhuma das principais ferramentas do mercado [1] [9].
A constatao de tal problema serviu de motivao para elaborao da ferramenta
apresentada nesta monografia, a GenJPA. Nela foram implementadas regras de mapeamento
mais especficas capazes de transcrever ao cdigo os conceitos que outras ferramentas deixam de
mapear.
1.2 JUSTIFICATIVA
A gerao de cdigo Java a partir de diagramas da UML, alm de ser tema de estudo
no meio acadmico prtica recorrente no mercado de software. Hoje, muitas ferramentas,
dentre elas as trs maiores do mercado de modelagem: Astah, Enterprise Architect (EA) e
Rational Software Architect (RSA), fornecem suporte gerao de cdigo Java [1]. Todavia,
como descreve Magalhes [1], observa-se inconsistncias no cdigo gerado por estas aplicaes.
Causada, principalmente, pela falta de regras especficas de mapeamento para itens mais
complexos da UML, a inconsistncia ocorre quando determinado conceito do modelo deixa de
ser transcrito para o cdigo durante a engenharia frente [1]. Nesse caso, por conta da perda
de informaes, o cdigo gerado apresenta divergncia com o projeto da aplicao e com isso
algumas restries do sistema deixam de existir.
Segundo Magalhes [1] e Gessenharter [9] as inconsistncias mais comuns ocorrem du-
rante a transformao de diagramas de classes, estando relacionadas aos conceitos de agregao,
composio e navegabilidade das associaes. Ambos os autores, aps analisarem o processo
de engenharia frente UML-Java executado por ferramentas de transformao, chegaram as
mesmas concluses:
Agregaes e composies sempre so mapeadas para o cdigo como associaes

simples, havendo perda de informaes (Figura 1).
A navegabilidade algumas vezes no levada em considerao durante a transforma-
o (Figura 2).
Figura 1 Transformao Inconsistente de uma Composio [1].
Figura 2 Transformao Inconsistente da Navegabilidade [1].
Alm da inconsistncia, Magalhes [1] apresenta tambm a deficincia das ferramentas

Astah, EA e RSA no que tange a Interao Humano Computador (IHC). Segundo o autor, os
mecanismos de interao fornecidos por todas elas so mnimos, limitando-se exibio de

mensagens de erro. Alm disso, estas ferramentas obrigam o usurio a trabalhar conforme suas
convenes de mapeamento, no oferecendo qualquer opo para configurao da transformao.
1.3 DISCUSSO
Alguns dos problemas apresentados podem ser solucionados dando mais ateno etapa
de transformao, casos da navegabilidade e interao com o usurio. Por outro lado, levando
em considerao que os conceitos de agregao e composio no possuem uma representao
correspondente na linguagem Java, torna-se necessrio o uso de tecnologias auxiliares, cuja
notao fornea abstraes capazes de mapear a semntica desses itens para o cdigo.
O mapeamento objeto-relacional consegue transportar para o cdigo os conceitos mais
complexos da associao do diagrama de classes da UML. Por isso, na GenJPA, foi usada uma
abordagem mista baseada nesse paradigma. Nela, cdigo Java em conjunto com anotaes
e propriedades da Java Persistence API (JPA) so usadas no mapeamento de agregaes e
composies da UML. Com isso conseguiu-se diminuir a inconsistncia e manter as restries
do modelo.
O processo de engenharia frente executado pela aplicao gera, de forma automtica, as
entidades de um sistema Java. Essas classes trabalham a nvel objeto-relacional, intermediando a
troca de informaes entre o banco de dados e a aplicao.
1.4 OBJETIVOS
1.4.1 Objetivo Geral
Implementar uma transformao que seja capaz de mapear ao cdigo conceitos mais
complexos do diagrama de classes para linguagem Java/JPA.
1.4.2 Objetivos Especficos
Identificar os componentes de interesse do diagrama de classes e suas variaes

sintticas;
Validar o diagrama de entrada;
Desenvolver o mdulo capaz de converter blocos da UML para suas respectivas
representaes em Java / JPA;
CONSIDERAES FINAIS
Os prximos captulos esto organizados da seguinte forma:

Fundamentao Terica: Nesse captulo so apresentados todos os conceitos teri-

cos utilizados no desenvolvimento da soluo proposta;
Trabalhos Relacionados: Nesse captulo so apresentados trabalhos cujo contedo
descreve ferramentas de transformao que implementam a engenharia frente a
partir de diagramas de classes tendo a linguagem Java como destino;
GenJPA: Captulo dedicado a apresentao da soluo implementada, detalhando
funcionalidades, mdulos e implementao;
Concluso: Nesse captulo feita a concluso do trabalho dado seus objetivos
propostos e so listados os trabalhos futuros para melhorar e/ou expandir a utilizao
da soluo.
19
2 FUNDAMENTAO TERICA
Nesse captulo so apresentados todos os conceitos relacionados implementao da

ferramenta proposta. Aqui so descritos os paradigmas, conceitos e tecnologias que serviram de
base para elaborao da GenJPA.
2.1 ORIENTAO A OBJETOS
Hoje, grande parte dos sistemas de informao so desenvolvidos seguindo um mesmo

paradigma de programao, que se mostra superior antiga viso baseada em algoritmos [7]:
o orientado a objetos (OO). Esse padro utiliza os conceitos de classificao e abstrao na
representao do conhecimento, permitindo que as informaes sejam estruturadas de uma
maneira mais prxima ao pensamento humano [8].
Tanto o Java quanto a UML tm suas sintaxes sedimentadas nos itens da orientao a
objetos. Por esta razo, se faz necessrio compreender os principais conceitos desse paradigma
antes de apresentar o funcionamento das duas linguagens.
2.1.1 Classes e Objetos
A viso orientada a objetos, diferentemente do mtodo procedural, no se limita apenas

conceitos do algoritmo (funes e rotinas), ela define maneiras mais sofisticadas para estruturar
as informaes, atravs das classes e dos objetos.
Na orientao a objetos, uma classe abstrai a notao de determinado conceito geral [10].
Ela pode ser vista como um molde ou uma planta de projeto, usada para dar origem a instncias
reais do conceito definido [7]. Utilizando classes, qualquer elemento do mundo real pode ser
abstrado para uma representao processvel por mquina.
A classe define uma srie de propriedades, chamadas de atributos, cujos valores va-
riam de uma instncia a outra. Alm de atributos, a classe pode definir mtodos, conhecidos
tambm como operaes capazes de executar determinada ao ou mudar o estado dos obje-
tos [10]. Normalmente, essas operaes contm parmetros usados como entrada para o seu
processamento.
A Figura 3 traz a representao dos conceitos de classes e objetos. Nela, a classe Pessoa,
usada na instanciao de trs objetos: Joo, Maria e Carlos.
Captulo 2. Fundamentao Terica 20
Figura 3 Representao de Classes e Objetos.
2.1.2 Heranas e Polimorfismo
No mundo real, algumas abstraes so derivadas de outras, levando isso em considerao

o paradigma OO define o relacionamento de polimorfismo e herana, tido como uma de suas
caractersticas mais poderosas [8].
Heranas trabalham com os conceitos de superclasse e subclasse. Nesse tipo de relaciona-
mento, uma classe geral utilizada para representar todas as propriedades e aes compartilhadas
por seus diversos filhos. Na herana, classes filhas herdam todas as caractersticas da sua classe
me, podendo ainda definir atributos e operaes adicionais [7].
Um caso especial de herana, baseada nos conceitos de tipo e subtipo origina outro con-
ceito da orientao a objetos: polimorfismo. Segundo Junior [10], o polimorfismo ocorre quando
uma classe filha reescreve algum mtodo de sua classe me, modificando o comportamento
padro dessa operao. Assim, no momento da invocao do mtodo, diferentes implementaes
podem ser executadas.
2.2 UML
Sistemas de informao caracterizam-se por sua dinamicidade, isto , a propriedade

que estes possuem de crescer com o decorrer do tempo, seja devido a mudanas no negcio
ou por erros na anlise inicial do projeto. Geralmente, so elementos de grande complexidade,
compostos por diversos itens, cuja arquitetura depende de inmeros fatores [8]. Por mais simples
que um software possa parecer inicialmente, uma srie de pontos como requisitos, custo de
produo, manutenes e reusabilidade devem ser definidos antes de seu desenvolvimento.
A UML fornece os mecanismos necessrios para especificao, visualizao, construo
e documentao da arquitetura desses sistemas complexos [7].
2.2.1 Conceitos
A UML (Unified Modeling Language) ou Linguagem Unificada de Modelagem a

notao padro da indstria de software para modelagem de sistemas de informao orientados a
objetos [8]. Booch e outros [7] a definem como uma linguagem de modelagem visual de grande
abrangncia, cuja sintaxe fornece todos os meios necessrios para modelagem e planejamento
dos mais diversos tipos de sistemas de informao. Em sua notao, a linguagem define uma srie
de regras e componentes, agrupados em diagramas, que em conjunto fornecem uma projeo do
sistema que se est desenvolvendo ou que se pretende desenvolver.
Trs tipos de blocos formam o vocabulrio da UML: itens, relacionamentos e diagra-
mas [7]. Itens so cidados de primeira classes usados para representar as caractersticas estticas
e dinmicas do sistema. Relacionamentos so os elementos que conectam estes itens, modelando
as colaboraes entre partes. Por fim, os diagramas so junes desses dois conceitos, cuja
funo fornecer uma viso de determinada caracterstica do sistema.
Diagramas da UML proveem abstraes que facilitam a especificao e visualizao
dos muitos artefatos que fazem parte da arquitetura de um sistema de informao [8]. Eles
representam simplificaes da realidade, que auxiliam a equipe de desenvolvimento no decor-
rer do projeto [7]. Dentro do ciclo de desenvolvimento, diagramas so usados para guiar a
implementao do sistema, bem como para documentar as decises tomadas.
Ao todo, a UML define 14 tipos de diagramas divididos em dois grupos (Figura 4). Essa
classificao se d de acordo com a viso fornecida pelo modelo e dos itens nele contidos.
Figura 4 Organizao dos Diagramas na UML. Adaptado da UML Superstructure [2].

Diagramas estruturais so usados para visualizao, especificao, construo e docu-

mentao de aspectos estticos do sistema, isto , sua estrutura relativamente estvel, cujos itens
esto menos propensos a mudanas. J os diagramas comportamentais modelam os aspectos
dinmicos do software, suas partes que sofrem influncia do fator tempo, como as rotinas e
interaes [1].
Segundo estudo realizado por Dobing e Parson [11], a frequncia de utilizao de alguns
diagramas da UML superior a outros. Modelos de casos de uso, sequncia e classes se fazem
mais presentes nos projetos. Dos trs, o diagrama de classes o mais utilizado, apresentando uma
taxa de uso superior a 70%. Diversos autores afirmam que esse diagrama o mais importante da
linguagem [7] [8] [1].
2.2.2 Diagrama de Classes
O diagrama de classes o mais utilizado e tambm o que se encontra com maior

frequncia em projetos de software orientados a objetos [8]. Esse diagrama exibe um conjunto de
classes, interfaces, colaboraes e relacionamentos, sendo capaz de abstrair o projeto arquitetural
do software [7]. Linguagens de programao orientadas a objetos, como Java, C++ e Visual
Basic apresentam em suas sintaxes abstraes relativas a muitos dos conceitos deste modelo.
O bloco de construo central do diagrama de classes a classe. Usada para representar
as diversas abstraes que fazem parte do domnio do problema, uma classe descreve um conjunto
de elementos que compartilham as mesmas caractersticas, comportamentos, relacionamentos
e significado [7]. Por meio de colaboraes, classes se conectam e executam as rotinas da
aplicao [8].
Conforme o nvel de detalhamento apresentado, os diagramas de classes so classificados
em trs tipos [12]:
Conceituais: so diagramas de classes cuja funo representar os relacionamentos
e itens bsicos do sistema. Na perspectiva conceitual, preocupa-se em descrever,
na forma de classes, as abstraes mais importantes do software e as associaes
essenciais estabelecidos entre elas. A perspectiva conceitual fornece uma viso geral
dos conceitos que fazem parte do domnio do problema.
Projeto: so diagramas que, alm de apresentar os principais conceitos e relaci-
onamentos do sistema, definem o comportamento das abstraes. Na perspectiva
de projeto, trabalha-se com o conceito de responsabilidade da classe, o qual define
sua funo dentro do sistema. Diagramas desse tipo fornecem uma viso ampla da
estrutura das classes e de suas operaes.
Implementao: nessa perspectiva o diagrama de classes apresenta completude,
isto , contm todas as classes que compem o software, bem como o detalhamento
dos relacionamentos. Diagramas de classes modelados conforme a perspectiva de
implementao esto conectados tecnologias especficas (linguagem de programa-

o).
2.2.3 Perspectiva de Dados no Diagrama de Classes
No contexto desse trabalho, cabe citar um caso especial do uso de diagramas de classes,
que ocorre quando os mesmos so utilizados na modelagem de classes persistentes do sistema.
Estas classes, tambm chamadas de entidades, possuem a caracterstica de gerar objetos cujos
dados transcendem o tempo de execuo da aplicao [8].
Classes persistentes esto relacionadas s tabelas de banco de dados relacionais e seus
objetos aos registros destas tabelas. O diagrama de classes, quando utilizado na modelagem desse
tipo de item, fornece uma viso estrutural do esquema lgico do banco de dados da aplicao [8].
Diagramas projetados conforme essa viso so usados na criao das tabelas de banco de dados
relacionais, bem como na gerao de entidades em sistemas orientado a objetos.
A Figura 5 mostra um diagrama de classes modelado conforme a perspectiva de dados.
Todas as classes do modelo geram instncias cujos dados precisam ser armazenados para posterior
consulta.
Figura 5 Diagrama de Classes que Apresenta Entidades. Adaptado de Booch e outros [7].
2.3 ENGENHARIA FRENTE
Os modelos do software so componentes de grande valor dentro do projeto, no entanto,

eles no so os artefatos de maior importncia produzidos durante o desenvolvimento de um
sistema [7]. Todo o esforo empenhado pelos diversos membros da equipe, nas vrias etapas
que compem o ciclo de desenvolvimento de um sistema de informao, tm um nico objetivo:
entregar ao cliente uma aplicao funcional capaz de atender s necessidades de seu negcio a
partir da informatizao de rotinas antes no assistidas por computador.
Linguagens de modelagem como a UML auxiliam os desenvolvedores a produzir uma
implementao correta do software [8]. Diagramas como o de classes e o de sequncia, por
exemplo, possuem clara conexo com o cdigo, podendo ser usados na etapa de implementao.
Quando uma ferramenta utilizado para interpretar esses modelos e gerar o cdigo executvel
caracteriza-se a engenharia frente.
Esta seo apresenta os principais conceitos por trs desse processo, seus benefcios e as
metodologias de desenvolvimento de software que o utilizam.
2.3.1 Conceitos
Alm de ser uma linguagem para documentao, especificao e visualizao de projetos

de sistemas OO, a UML tambm uma linguagem para construo, isto , a partir de seus diagra-
mas possvel obter uma implementao funcional do sistema ou de parte dele. Segundo Booch
e outros [7], a UML foi projetada com a finalidade de ser mapeada para vrias linguagens de
programao, ou seja, muitos dos conceitos contidos em seus diagramas podem ser diretamente
conectados a estas linguagens.
A interpretao de diagramas da UML pode ser realizada da maneira tradicional, pelo
programador, ou de forma automtica, utilizando regras de transformao e ferramentas especifi-
cas [13]. No segundo caso, quando sistemas so usados para gerar sistemas, d-se o nome de
engenharia frente.
A engenharia frente o processo de transformao de um modelo em cdigo, imple-
mentado por ferramentas especficas de mapeamento [14]. Essas aplicaes definem regras
capazes de transportar componentes da UML para alguma linguagem de programao orientada a
objetos, transcrevendo os conceitos do diagrama para construes no cdigo de mesmo valor. As
ferramenta que implementam a engenharia frente so classificadas de acordo com a tcnica de
mapeamento empregada, podendo ser do tipo Template ou Programas Geradores de Cdigo [14].
Ferramentas Template fazem um mapeamento direto entre modelo e texto por meio
engines de transformao. Esse mapeamento do tipo um para um, onde cada conceito do
modelo conectado a um elemento do cdigo. Por outro lado, programas geradores de cdigo
implementam regras prprias de validao, mapeamento e transformao, estando voltadas para
domnios especficos de aplicao. Programas geradores de cdigo costumam apresentar uma
engenharia frente mais completa, cujo cdigo gerado tende a ser mais consistente. [13].
No campo da engenharia de software, ambos os tipos de ferramentas de transformao
servem de apoio para as metodologias dirigidas por modelos.
2.3.2 Metodologias Dirigidas por Modelos
Muitas vezes os prazos que se dispe para a entrega do sistema curto, mas, por outro
lado, sua complexidade alta. Como consequncia ocorre um aumento no custo de produo, j
que mais pessoas precisaro estar envolvidas no projeto para que se cumpra o prazo estabelecido.
Levando em considerao esse tipo de cenrio surgiram as metodologias dirigidas por modelos
(MDs) (do ingls Model Driven): abordagens que aplicam a tcnica de engenharia frente com
o objetivo de automatizar a construo do software e assim diminuir os custos de produo e
tempo de entrega [14].
Segundo Magalhes [1], nas MDs os diagramas so cidados de primeira classe, usados
no apenas na documentao do software, mas tambm para obteno de uma verso executvel
do mesmo. Modelos abstratos, criados durante o projeto, so enriquecidos at um ponto que se
possa obter uma implementao funcional do sistema.
Nessas metodologias, h uma preocupao maior com relao modelagem, gasta-se
mais tempo durante essa atividade para que os diagramas produzidos sejam os mais completos.
Todavia, o tempo gasto construindo tais modelos compensado com o tempo que seria gasto na
implementao de vrias linhas de cdigo [1].
Hoje, trs abordagens se destacam na indstria, sendo uma delas especificada pelo rgo
que rege a UML, o Grupo de Gerenciamento de Obejtos (OMG) (do ingls Object Management
Group) [1]. So elas:
Model Driven Development (MDD): abordagem que defende o uso de modelos em

todas as etapas do ciclo de desenvolvimento. Nela, os diagramas que abstraem as
interfaces, interaes e propriedades da aplicao, alm de usados na anlise, servem
para automatizar a implementao.
Model Driven Architecture (MDA): viso particular do Object Management Group
sobre a MDD. Na MDA, a UML tida como uma linguagem de programao. Nessa
metodologia, so estabelecidas uma srie de tecnologias que auxiliam a construo de
novas ferramentas de transformao. A abordagem defende, alm das transformaes
do tipo modelo-cdigo aquelas do tipo modelo-modelo.
Model Driven Engineering (MDE): metodologia que engoba as outras duas apresen-
tadas. Nessa abordagem, a construo do sistema pode ser totalmente automatizada.
Para isso, utilizam-se ferramentas de transformao capazes de geral cdigo estrutural
e comportamental a partir de diagramas de classes e sequncia.
Por utilizar padres estabelecidos pelo OMG e conectar-se com a UML, a MDA foi tomada
como referncia na implementao da ferramenta apresentada nesta monografia. A prxima
seo descreve de forma mais detalhada os conceitos da metodologia.
2.3.3 Model Driven Architecture
A Model Driven Architecture a abordagem padro da Object Management Group,

rgo que normatiza a UML, para se trabalhar com o desenvolvimento dirigido por modelos.
Nessa abordagem, a UML vista como uma linguagem de programao e no apenas como
mecanismo de documentao e projeto [15]. Essa metodologia defende o uso de modelos
desde os primeiras etapas do projeto, bem como a utilizao deles na automatizao das etapas
seguintes do desenvolvimento.
Na MDA, os modelos do software so agrupados em trs tipos de acordo com o nvel de
detalhamento apresentado: CIM, PIM e PSM [15]. Para compreender essa classificao, pode-se
levar em considerao as perspectivas de modelagem dos diagramas de classes.
Traando um paralelo, o modelo computacional independente (CIM) (do ingls Com-
putation Independent Model) est relacionado diagramas de classe modelados a partir da
perspectiva conceitual, que apresentam os principais conceitos do sistema e possuem alto nvel
de abstrao. J o modelo independente de plataforma (PIM) (do ingls Platform Independent
Model) se conecta aos diagramas modelados conforme a perspectiva de projeto, que apresentam
as propriedades das classes sem focar na implementao das operaes. Por fim, o modelo
especfico de plataforma (PSM) (do ingls Platform Specific Model ) se conecta com diagramas
de classes modelados sob a perspectiva de implementao, cujo contedo apresenta alto nvel de
detalhamento, sendo descritos para uma plataforma especfica.
Segundo Maia [15], a MDA consiste na definio inicial dos requisitos atravs do CIM,
a transformao deste CIM para um modelo independente de plataforma (PIM), utilizando uma
linguagem de modelagem, e a preparao deste modelo independente para construo de um
PSM, atravs do processo de engenharia frente. A Figura 6 demonstra esse procedimento.
Figura 6 Model Driven Architecture [3].

Modelos especficos de plataforma (PSM) so usados na realizao da engenharia frente

na MDA [1]. Por ser uma especificao da OMG, os conceitos que envolvem essa transformao
esto voltados quase que completamente para diagramas da UML.
A MDA estabelece uma srie de padres que ajudam na construo de ferramentas que
apoiem o processo de engenharia frente. Trs deles foram utilizados na implementao da
GenJPA.
Meta Object Facility (MOF): linguagem usada para especificar formalmente lingua-
gens de modelagem. Com o MOF possvel definir os blocos que fazem parte destas
linguagens atravs de elementos estruturais como classes, atributos e operaes. O
metamodelo da UML especificado usando essa linguagem. Nele so definidos quais
elementos fazem parte de cada um dos diagramas e quais as propriedades e relaci-
onamentos que podem ser estabelecidos entre estes itens. Segundo Magalhes [1],
linguagens definidas atravs da MOF podem ser mapeadas umas para as outras,
facilitando o processo de engenharia frente e as transformaes modelo-modelo.
XML Metadata Interchange (XMI): define um conjunto de regras que mapeiam os
diagramas baseados em MOF para documentos no formato XML. Atravs dessa
especificao, diagramas da UML podem ser representados em formato estruturado
permitindo assim interoperabilidade entre ferramentas de transformao e CASE [16].
O formato XMI prov uma facilitao para troca de modelos e uma padronizao
para sua representao.
Model to Text Transformation Language (MTL): linguagem utilizada para extrao
de dados de diagramas da UML em formato XMI. Baseia-se no metamodelo da UML
e tem como funo a transformao de diagramas em artefatos no formato texto,
como cdigo, especificaes de implantao, relatrios e documentos.
2.4 JAVA
Dentre as ferramentas de modelagem (CASE) e transformao h uma linguagem de

programao que recebe maior suporte, resultado, principalmente, da sua ampla difuso no
mercado de desenvolvimento. Dados retirados do site da linguagem, que na realidade trata-
se de um plataforma, comprovam seu sucesso comercial, especialmente, em ambiente web e
mobile. Com uma base operacional de 3 bilhes de dispositivos, dentre computadores, celulares
e microcontroladores, o Java hoje a principal linguagem de desenvolvimento do mercado [17].
2.4.1 Conceitos
A linguagem Java engloba os diversos conceitos do paradigma orientado sendo baseada

no C++ [18]. Assim como o C++, a sintaxe do Java trabalha com os conceitos de classes,
interfaces, operaes, atributos, herana e polimorfismo, todavia, no incorporando a herana
mltipla, o gerenciamento manual de memria e tratamento obrigatrio de excees [19]. O Java

tem forte apelo para o ambiente web, pois permite que os componentes heterogneos de uma
rede se comuniquem de forma transparente independentemente das suas arquiteturas, sistemas
operacionais e tipos de dispositivo [20].
Buscando segurana e principalmente a portabilidade do software, a plataforma Java
utiliza o conceito de mquina virtual na execuo de seus programas [20]. A Mquina Virtual
Java (JVM) (do ingls Java Virtual Machine) trabalha como intermediador entre aplicao e o
hardware do equipamento, interpretando o cdigo e fornecendo as instrues para as camadas
especficas do sistema operacional que devem execut-las [21]. Para cada sistema operacional, o
Java fornece uma implementao da JVM, sendo esta responsvel por interpretar as instrues
do programa e repass-las ao equipamento [20].
Segundo Braz [20], essa caracterstica possibilita que sistemas escritos com a lingua-
gem possam ser executados em qualquer arquitetura de hardware e sistema operacional sem
a necessidade de recompilao. Programas Java no so diretamente compilados para lingua-
gem de mquina, mas sim para um cdigo intermedirio (Bytecode) interpretvel por qualquer
implementao da JVM. Desse modo, uma mesma aplicao pode rodar em diferentes siste-
mas operacionais, oferecendo as mesmas funcionalidades. A Figura 7 mostra o processo de
compilao de um programa Java.
Figura 7 Execuo de um Programa Java. Adaptado de Devmedia [4].
Ao todo, a plataforma fornece trs especificaes (Java Standard Edition, Java Enterprise
Edition e Java Micro Edition) as quais contm uma srie de ferramentas e APIs (Application
Plataform Interface) usadas na construo de sistemas para ambiente Web, Desktop e Mobile
[20]. Cada especificao engloba um conjunto especfico de padres, tecnologias e bibliotecas
que tm o objetivo de agilizar a construo do software.
2.4.2 Tipos de Dados
O Java fornece uma infinidade de tipos de dados, isso porque trata-se de uma linguagem
estaticamente tipada, onde as propriedades da classe tm seu tipo determinado no momento da
criao [21]. Em seu pacote java.lang (raiz), a plataforma define seus tipos elementares, os
quais podem ser utilizados na definio de qualquer atributo.
Tipos definidos no pacote java.lang so importadas automaticamente no momento
da criao da classe. J os externos a esse pacote precisam ser importados ou referenciados
explicitamente nas classes que os utilizam.
2.5 MAPEAMENTO OBJETO-RELACIONAL
Apesar dos conceitos dos paradigmas orientado a objetos e relacional apresentarem

equivalncia a nvel de modelo (perspectiva de dados), a nvel de implementao o mapea-
mento de classes persistentes para banco de dados tende a ser mais complexo, isso porque a
maneira que cada tecnologia estrutura seus dados divergente, impossibilitando a troca direta de
informaes [6].
Enquanto banco de dados relacionais trabalham a nvel de tabelas e registros, aplicaes
orientadas a objetos trabalham com classes e objetos. Essa divergncia de conceitos torna
necessria a ocorrncia de transformaes toda vez que algum dado trafegue da aplicao para o
banco de dados ou do banco para a aplicao [6]. Para que uma classe Java consiga intermediar a
comunicao entre banco e aplicao, se faz necessrio um mecanismo que mapeie os conceitos
dos dois modelos. A esse mecanismo d-se o nome de mapeamento objeto-relacional (ORM)
(do ingls Object Relational Mapping) [6].
Ferramentas de mapeamento objeto-relacional possuem recursos capazes de mapear
classes persistentes para tabelas de base de dados relacionais, estabelecendo um caminho bidire-
cional para a troca de informaes. Para isso, fazem uso de mecanismos de extenso e arquivos
de configurao que estabelecem as regras a serem seguidas no processo de transformao de
classes para tabela e de tabelas para classe.
Segundo Torres [6], ferramentas desse tipo abstraem totalmente a estrutura fsica do
banco, permitindo que o desenvolvedor realize todas as operaes (criao, consultas, alterao,
incluso e excluso de dados) a nvel de aplicao.
A plataforma Java, em sua especificao, define a Java Persistence API como o padro
para implementao de ferramentas de mapeamento-objeto relacional (ORM) [22]. A JPA
estabelece o conjunto de regras, servios e anotaes bsicas que devem ser fornecidos por uma
ferramenta de mapeamento objeto-relacional.
Com JPA possvel mapear as classes da aplicao para o banco de dados, bem como
seus atributos, heranas e associaes. Para isso, so utilizadas anotaes (mecanismos de
extenso) acoplados a esses elementos no cdigo. A JPA consegue transportar todos os conceitos
da orientao a objetos para representaes equivalentes em banco de dados relacionais [22].
2.6 INFLUNCIA DA JPA NOS ITENS DE INTERESSE DO MODELO
Classes Java que representem entidades de banco de dados relacionais devem ser im-
plementadas conforme a sintaxe Bean estabelecida na JPA [23]. Essa especificao define as
anotaes, tipo de construtor, mtodos e atributos que uma classe Java deve conter para que se
torne uma representao de determinada tabela do banco de dados da aplicao, estabelecendo
assim um caminho bidirecional para a transformao de objetos em registros e registros em
objetos.
Segundo Oracle [23], uma Bean deve possuir as seguintes caractersticas:
1) Apresentar a anotao @Entity acima da sua declarao; 2) Conter um construtor
padro sem argumentos; 3) Declarar apenas atributos privados que possam ter seus valores lidos
e escritos; 4) Fornecer mtodos Getter e Setter para manipulao desses atributos, no
podendo apresentar outras operaes que no sejam de leitura e escrita de dados.
Para gerar o cdigo de classes Bean um subconjunto de itens do diagrama de classes
e de suas propriedades so necessrios, sendo denominados, nesta monografia, como itens de
interesse. Tais itens fornecem a base para o processo de engenharia frente implementado.
Uma breve descrio desses elementos e de suas representaes na UML, em Java e no
modelo objeto-relacional da JPA dada nas prximas sees.
2.7 CLASSE
Classes so representaes conceituais de itens que fazem parte do domnio do problema.

Usadas para abstrair elementos (conceituais ou concretos) da aplicao, uma classe descreve um
conjunto de instncias (objetos) que compartilham as mesmas propriedades, comportamentos,
relacionamentos e semntica [7]. Dentro de um modelo, a classe identificada por um nome,
que alm de nico, deve ter relao direta com o item ao qual ela abstrai [8]. Classes podem
conter propriedades e mtodos que definem sua estrutura e comportamento.
Em Java, classes so classificadores que do origem a objetos. A nvel objeto-relacional,
elas representam entidades, cujos objetos so convertidos em registros. A Figura 8 mostra a
representao da classe na UML.
Figura 8 Classe Pessoa.
2.7.1 Atributo da Classe
O atributo uma abstrao que apresenta determinada caracterstica da classe, compar-

tilhada por todos os seus objetos. Um atributo especifica um intervalo de valores para uma
propriedade do classificador, que serve para caracterizar e diferenciar os objetos [8]. Na classe, o
atributo identificado por um nome. Alm do nome, outras informaes podem estar atreladas a
este elemento, como visibilidade e tipo [7].
Tipo: caracterstica que determina a natureza dos dados armazenados pela proprie-
dade, restringindo seus valores a um subconjunto no espao (nmeros, caracteres,
valores lgicos, etc).
Visibilidade: usado para indicar o nvel de acesso propriedade. A visibilidade
representa um mecanismo de encapsulamento da informao. Existem quatro tipos
distintos na UML e em Java: privado, pblico, protegido e pacote [8].
Figura 9 Atributos Privados da Classe Pessoa.
A nvel de implementao OO os atributos caracterizam a classe, definindo suas propri-

edades. J a nvel objeto-relacional, tais elementos do origem colunas nas entidades, onde
so armazenados os dados dos registros. A Figura 9 mostra como os atributos se organizam na
classe.
2.8 RELACIONAMENTOS
Relacionamentos so usados para descrever mecanismos de colaborao entre as classes e

tambm na representao de conceitos mais ricos da orientao a objetos [7]. Um relacionamento
indica uma conexo entre classes, descrevendo um caminho para a troca de informaes ou um
mecanismo de cooperao entre instncias [8].
A UML apresenta trs tipos bsicos de relacionamento: associao, generalizao e
dependncia. Apenas dois deles (associao e generalizao) possuem relao direta com a
implementao.
2.8.1 Generalizao
O relacionamento de generalizao trabalha com os conceitos de superclasse e subclasse

na representao de heranas. Na generalizao, classes mais gerais compartilham seus atributos
e operaes com outras que apresentem estas mesmas caractersticas, mas que ao mesmo tempo
tenham diferenas pontuais de estrutura e comportamento [8]. As classes filhas (subclasses)
herdam todos os atributos, operaes e relacionamentos das suas classes mes (superclasses). A
Figura 10 apresenta um relacionamento de generalizao na UML.
Figura 10 Herana na UML.
Em Java, apenas heranas simples so suportadas. A nvel objeto-relacional, generaliza-

es so mapeadas no banco atravs de referncias entre tabelas.
2.8.2 Associao
Uma associao representa um relacionamento estrutural entre itens, indicando que

existe um caminho para troca de dados entre os objetos das classes envolvidas. Associaes
podem conectar uma, duas ou N-classes [8]. Dependendo da quantidade de classes conectadas,
uma associao pode ser classificada em unria (Figura 12), binria (Figura 11) ou N-ria.
Associaes binrias so as mais comuns no diagrama de classes, j as N-rias devem

ter seu uso evitado por dificultarem a leitura do modelo e abrirem espao para interpretaes
ambguas [7]. A informao bsica da associao seu nome, o qual descreve sua funo no
modelo. Alm do nome, uma associao tambm pode apresentar:
Multiplicidade: determina a quantidade mnima e mxima de instncias que pode
estar conectadas a cada uma das extremidades da associao. Por padro assume o
valor 1..1 (Um para Um), podendo ser alterada para 0..* (Zero ou Muitos), 1..* (Um
ou Muitos), * (Muitos). Por meio da multiplicidade possvel controlar a quantidade
de objetos envolvidos na associao.
Papel: usado como uma interface externa da classe. Geralmente relaciona-se com
atributos da implementao.
Navegabilidade: define o sentido em que os objetos podem trafegar na associao:
A < > B (bidirecional), A > B (apenas A acessa B) ou A< B (apenas B
acessa A).
A nvel de cdigo Java associaes do origem atributos nas classes com extremidade
navegveis. Nesse caso, o papel define a implementao do atributo. J a nvel objeto-relacional
as associaes, assim como as generalizaes, so representadas por meio de referncias entre
tabelas.
Figura 11 Associao Binria Simples.
Figura 12 Associao Unria ou Reflexiva.

2.8.3 Agregao e Composio
A agregao e a composio so associaes que, ao contrrio das simples, definem nveis

de importncia s classes envolvidas, trazendo significado extra ao modelo e consequentemente
implementao. So associaes binrias, onde uma classe, que representa o elemento todo,
possui relao de dependncia ou de controle com outra classe, que contm suas partes [8]. A
relao do todo com as partes determina o tipo de associao. A Figura 13 apresenta como
agregaes e composies so representadas na UML.
Agregao: nesse tipo de associao a classe que representa o todo necessita ter
suas informaes complementadas pelos objetos parte [8]. A agregao indica que
o todo s est completo quando em posse de todas as suas partes. Nesse tipo de
associao, o todo dependente das partes.
Composio: variao da agregao. Na composio, invs do objeto todo ser de-
pendente de suas partes, ocorre o contrrio. Essa associao especifica que instncias
da classe todo possuem controle total de suas partes, sendo responsvel pela criao
e destruio desses objetos. A composio estabelece que uma parte no pode existir
sem seu todo.
Figura 13 Exemplos de Agregao e Composio.

35
3 TRABALHOS RELACIONADOS
Esta captulo apresenta trabalhos cujo contedo descreve ferramentas de transformao

que implementam a engenharia frente a partir de diagramas de classes, tendo a linguagem Java
como destino. So mostradas as principais funcionalidades de cada ferramenta, bem como as
deficincias observadas em seu funcionamento.
Os problemas verificados serviram para tornar a ferramenta proposta mais completa.
3.1 GENCODE
A GenCode [14] uma ferramenta de apoio ao desenvolvimento de sistemas embar-

cados, capaz de ler, capturar e gerar cdigo Java a partir de diagramas de classes. Ela inclui
a especificao de classe, classe abstrata, superclasse, especializao, pacotes, declarao de
atributos, mtodos e construtores, alm de gets e sets.
O processo de transformao implementado na aplicao composto de duas etapas:
extrao dos dados e gerao do cdigo. Na primeira, o diagrama de entrada em formato XMI
tem seus dados lidos e armazenados na memria. Essa tarefa executada utilizando a biblioteca
de manipulao de arquivos do Java: java.io. Na segunda, tomando como referncia a
equivalncia de conceitos da orientao a objetos, cada componente do diagrama de classes
mapeado de forma direta para seu elemento correspondente na linguagem de destino. Assim, ao
final da transformao cada classe do modelo gera uma classe Java, propriedades dessas classes
geram atributos e assim por diante.
A GenCode, apesar de robusta, apresenta alguns problemas.
A leitura e extrao dos dados do modelo so feitas exclusivamente utilizando a API
nativa de arquivos do Java, no havendo qualquer apoio de motores de transformao
ou bibliotecas de processamento XML. Essa implementao pode gerar problemas
de desempenho durante o processamento de diagramas mais extensos, devido a
complexidade do arquivo XMI.
Nomes das classes, atributos e mtodos, assim como todos os outros itens do modelo
no passam por uma validao antes de serem transformados em cdigo, o que pode
resultar em erros de compilao, caso as notaes destes elementos estejam fora dos
padres da linguagem Java.
A ferramenta no conta com uma interface grfica, dificultando a interao com o
usurio.
A navegabilidade respeitada durante a transformao. Todavia, agregaes e
composies no so transcritas para o cdigo.
Captulo 3. Trabalhos Relacionados 36
3.2 HIBEROBJECTS
A HiberObjects [24] uma ferramenta de modelagem e gerao de cdigo para diversas

plataformas como Java Persistence API, classes Hibernate e servios Google Web Toolkit (GWT).
Com Hiberobjects possvel gerar o esqueleto do sistema atravs de diagramas de classes e o
corpo dos mtodos e construtores por meio de diagramas de sequncia, sendo esse seu principal
diferencial.
No mdulo Hibernate da aplicao, as entidades persitentes recebem o esteretipo
Persistent e as anotaes de mapeamento so adicionadas ao diagrama por meio do elemento
Annotation do diagrama de classes (Figura 14). A Hiberobjects funciona como um plugin
do eclipse e possui um mdulo de modelagem proprietrio para criao de diagramas, sendo
esse seu principal ponto negativo.
O mdulo de modelagem fornece apenas um nmero reduzido de componentes do
diagrama de classes, limitando as opes do projetista. Alm disso, a sua interface deixa a
desejar no quesito usabilidade quando comparada a outras ferramentas CASE. A Figura 14
apresenta um diagrama de classes modelado utilizando a ferramenta.
Figura 14 Diagrama de Classes Modelado na HiberObjects. Adaptado de Cgernert [5].
3.3 MD-JPA
O MD-JPA [6] especifica um perfil UML para modelagem de diagramas de classes

especficos para o padro JPA e um mdulo de transformao de cdigo fonte para estes modelos.
Esse perfil permite a representao dos aspectos estruturais de banco dados e sistemas de
informao em uma abordagem dirigida por modelos atravs de mecanismos de extenso da
UML (esteretipos). No MD-JPA, o metamodelo do diagrama de classes teve sua notao
Captulo 3. Trabalhos Relacionados 37
estendida para representar dados das anotaes da Java Persistence API. O perfil implementado
na ferramenta trabalha com o conceito de enriquecimento de modelos da MDA, onde um
diagrama simples, recebido como entrada, detalhado at se tornar um PSM.
O objetivo da MD-JPA permitir a modelagem completa da persistncia relacional
em conjunto com os conceitos da orientao a objetos. Como consequncia, seus diagramas
tendem a apresentar fortssimo relacionamento com a API JPA. Para que o cdigo seja gerado,
os esteretipos do perfil devem ser atribudos a nvel de elemento do modelo de forma indivi-
dual. Sendo assim, classes, heranas, atributos s podem ser transformados caso recebam um
esteretipo que os mapeie para o cdigo. Essa uma das principais desvantagens do perfil, pois
termina dificultando a tarefa do projetista, visto que mais tempo dever ser despendido para o
aprendizado da nova notao da UML e na construo dos modelos.
No processo de engenharia frente, foram utilizados os conceitos de transformaes entre
metamodelos. O digrama de classes MD-JPA inicialmente transformado em uma representao
no metamodelo do Java e depois transportado para implementao da linguagem por meio de
bibliotecas da IDE eclipse. O cdigo gerado uma abstrao completa do modelo do banco de
dados do sistema. No entanto, ainda ocorre a perda de informao, pois, segundo o desenvolvedor,
optou-se por no atribuir nenhuma semntica adicional de agregaes e composies, sendo elas
tratadas como associao simples durante a gerao do cdigo.
Por fazer uso de bibliotecas da IDE eclipse a MD-JPA s pode ser usada dentro do
ambiente, possuindo assim uma dependncia. A Figura 15 mostra um modelo PSM da MD-JPA.
Figura 15 Diagrama de Classes no padro MD-JPA [6]

38
4 GENJPA
Ferramentas de apoio metodologias dirigidas por modelos devem fornecer mecanismos

capazes de mapear modelos escritos em uma linguagem de modelagem para implementaes
concretas em linguagem de programao [15]. A Object Management Group, rgo que norma-
tiza a UML e outras tecnologias de modelagem e projeto, especifica a Model Driven Architecture
como metodologia padro para o desenvolvimento de software dirigidos por modelos [25]. A
MDA estabelece um conjunto de convenes, tecnologias e ferramentas para o apoio do processo
de engenharia baseada por modelos. Atravs dessas tecnologias, novas ferramentas que auxiliam
a construo automatizada de sistemas (engenharia frente) podem ser desenvolvidas.
A construo de novas ferramentas de apoio s MDs, mais precisamente daquelas que
realizam o processo de engenharia frente, se faz necessria por duas razes: alguns domnios
de aplicao ainda no possuem ferramentas do tipo ou porque as ferramentas existentes dentro
de um domnio apresentam deficincias ao transformar modelo em cdigo.
Grande parte das ferramentas de transformao, sejam elas desenvolvidas no meio
acadmico ou pela prpria indstria, apresentam problemas de consistncia entre modelo e
cdigo gerado. Muitas vezes, ao se depararem com conceitos mais complexos da UML, tais
ferramentas terminam ignorando a existncia desses elementos no diagrama, no mapeando-os
durante a transformao para o cdigo [1] [9].
Durante a anlise de aplicaes que realizam transformaes do diagramas de classes
para a linguagem Java, verificou-se que elementos semanticamente mais ricos do diagrama
de classes nunca tinham seu significado transportado ao cdigo, havendo assim uma perda de
informaes. Observou-se tambm a deficincia dessas ferramentas no quesito interao humano-
computador: uma delas no apresentavam GUI, mecanismo bsico para interao, j aquelas
que apresentavam limitavam o projetista a trabalhar conforme suas prprias convenes, no
oferecendo mecanismos para gerao de cdigo mais condizente com a realidade da aplicao
desenvolvida.
Percebeu-se ento a necessidade de uma ferramenta de apoio ao processo de engenharia
frente capaz de sanar ou minimizar a ocorrncia destes problemas, isto , uma ferramenta
que diminusse a ocorrncia de inconsistncias e que fornecesse mecanismos de interao ao
usurio para o controle de algumas caractersticas do mapeamento. Seguindo esses preceitos foi
concebida a GenJPA.
A GenJPA uma ferramenta de transformao que trabalha com diagramas de classes da
UML modelados conforme a perspectiva de dados, fazendo um mapeamento desses modelos
para cdigo Java enriquecido com anotaes JPA. Como resultado, a ferramenta capaz de
retornar uma implementao das classes persistentes do softwares (Entidades), que trabalham a
Captulo 4. GenJpa 39
nvel objeto-relacional intermediando a troca de informaes entre aplicao e banco de dados.

No decorrer do desenvolvimento da aplicao, alm dos fatores associados ao mapea-
mento, tambm levou-se em considerao aspectos relacionados consistncia da transformao
modelo-cdigo e da interao com o usurio. Buscaram-se maneiras de diminuir a perda de
informaes durante o processo de engenharia frente e de tornar o projetista membro partcipe
da transformao.
Para isso, regras especiais de mapeamento e uma interface grfica com o usurio foram
desenvolvidas. Por meio dessas regras, baseadas em anotaes e elementos da JPA, conceitos
como o de agregao e composio puderam ser devidamente transportados para o cdigo. A
interface apresenta-se como elemento intermediador, oferecendo ao projetista a possibilidade
de repassar informaes que sero usadas pela ferramenta durante a gerao do cdigo, como
estruturas de dados e mapeamento de heranas.
O processo de engenharia frente implementado na GenJPA realizado em trs etapas:
extrao das informaes do diagrama, validao dos dados e gerao do cdigo. Cada uma
destas etapas executada por um mdulo especfico que utiliza uma ou mais tecnologias da
MDA.
A GenJPA foi desenvolvida em Java e executa em ambiente Desktop na forma de um
formulrio SWING (Figura 16). Na leitura do diagrama, optou-se pela utilizao de modelos
no formato XMI por ser um padro para troca de diagramas entre ferramentas CASE e de
transformao. Com isso foi possvel desvincular a ferramenta implementada da ferramenta
CASE usada na modelagem dos diagramas.
Figura 16 Interface da GenJPA.

O cdigo resultante do processo de engenharia frente pode ser utilizadas em qualquer

sistema que faa uso de banco de dados relacionais. Sendo assim, sistemas Web, Desktop e at
mesmo Mobile podem ter seu tempo de implementao diminudo com a ajuda da GenJPA.
As prximas sees descrevem o processo de engenharia frente implementado na
aplicao. So apresentados os componentes, tecnologias e funcionalidades de cada mdulo da
ferramenta.
No decorrer de cada seo, alguns diagramas so usados para representar os conceitos
apresentados. Todos esses diagramas foram modelados utilizando o Papyrus [26], um plugin
do Eclipse que fornece suporte representao de diagramas no formato XMI. A Figura 17
apresenta uma viso geral do mtodo de transformao desenvolvido.
MDULO DE EXTRAO MDULO DE VALIDAO MDULO DE CONSTRUO
DIAGRAMA DE CLASSES
(XMI)
Gerao do cdigo Java/JPA

(Classes, Atributos, Heranas
Extrao dos dados
e Relacionamentos).
Acceleo (M2T) e
normalizao dos
nomes.
Adio das anotaes JPA

Validao dos
s Classes e atributos.
nomes de atributos,
classes e estruturas.
ARQUIVO COM OS
DADOS DE INTERESSE
Figura 17 Funcionamento da GenJPA.
4.1 MDULO DE EXTRAO
O mdulo de extrao percorre o modelo de entrada, recuperando as informaes dos

itens de interesse do diagrama e estruturando esses dados para um formato que facilite sua
recuperao pelos mdulos de validao e mapeamento da aplicao. Esse procedimento
realizado atravs de transformaes do tipo modelo-texto, onde instncias de elementos da
UML, inicialmente estruturadas a nvel de metamodelo no formato XMI, so convertidas em
tags inseridas em um arquivo XML. Como resultado desse processo, obtm-se um arquivo
bem formado contendo apenas as informaes necessrias para a gerao do cdigo. Na
implementao dessa funcionalidade, utilizou-se a Linguagem de Transformao Modelo-Texto

Acceleo.
Para cada bloco do diagrama de classes descrito, uma regra de transformao em Acceleo
foi implementada. Essas regras seguem a mesma definio: Selecione todas as instncias de
determinado bloco do modelo, extraia suas propriedades de interesse e escreva esses dados no
arquivo de sada em formato estruturado.
A etapa de extrao finalizada quando todas as regras tiverem sido executadas, isto
, quando todos os dados de interesse haverem sido escritos no arquivo XML de sada. As
Tabelas 2 e 1 apresentam todas as tags geradas pelas regras de transformao Acceleo.
Item Propriedade Descrio Tag Gerada

Class name Nome da Classe <id></id> <nome></nome>
name Nome do Atributo <nome></nome>
type Tipo do Atributo <tipo></tipo>
Property
visibility Visibilidade do Atributo <visibilidade></visibilidade>
default Valor Default <default></default>
general Superclasse da Herana <general></general>
Generalization
specific Subclasse da Herana <specific></specific>
Association name Identificador da Associ- <nome></nome>
ao
type Classe da Extremidade <classe></classe>
A
Extremidade A agregation Tipo de agregao lado <agregacao></agregacao>
A
lower Valor mnimo da multi- <minimo></minimo>
plicidade A
upper Valor mximo da multi- <maximo></maximo>
plicidade A
isNavigable Identifica se o lado A <navegavel></navegavel>
navegvel
type Classe da Extremidade <classe></classe>
B
Extremidade B agregation Tipo de agregao lado <agregacao></agregacao>
B
lower Valor mnimo da multi- <minimo></minimo>
plicidade B
upper Valor mximo da multi- <maximo></maximo>
plicidade B
isNavigable Identifica se o lado B <navegavel></navegavel>
navegvel
Tabela 1 Propriedades Especficas de Cada Item.

Item do Diagrama Elemento do Metamodelo Tag Gerada na Sada

Classe Class <classe></classe>
Atributo Property <atributo></atributo>
Associao Association <associacao></associacao>
Generalizao Generalization <heranca></heranca>
Tabela 2 Itens Bsicos do Diagrama de Classes.
4.1.1 Normalizao de Nomes
Durante a extrao dos dados, algumas propriedades (nomes de classes e atributos)

passam por processamento adicional com o objetivo de padroniz-los s recomendaes da
linguagem Java. A classe NormalizadorDeNomes.java do mdulo de extrao fornece
mtodos que implementam essas convenes, formatando o contedo das propriedades nome-
veis antes de serem transformados em tags no arquivo de sada.
Nesse processo, espaos em branco, caracteres especiais e acentos so removidos do
texto. Alm da remoo desses caracteres, a classe executa formataes adicionais no texto para
que fique de acordo com as seguintes convenes do Java:
1) Nomes de classes devem iniciar com letra maiscula; 2) Nomes de atributos devem
iniciar com letra minscula; 3) Nomes compostos devem possuir a primeira letra de cada palavra
aps a primeira em maisculo; 4) Nomes de classes e atributos s podem ser compostos por
letras, nmeros e pelo caractere especial _ 5) Recomenda-se que os nomes contenham apenas
caracteres suportado pelo padro ASCII;
4.1.2 Resultados da Etapa de Extrao
Ao final da fase de extrao, o arquivo model.xml gerado. Esse arquivo contm

todas as informaes necessrias para gerao das entidades e de seus relacionamentos, sendo
usado pelo mdulo de validao na verificao do diagrama.
4.2 FASE DE VALIDAO
Na etapa de validao, os dados contidos no arquivo model.xml so usados na instan-

ciao das classes do pacote modelo da GenJPA. Estas classes so abstraes de itens do Java
e da UML usados pelos mdulos de validao e construo na execuo de suas funes. O
mdulo de verificao trabalha como intermediador entre diagrama e cdigo, transformando
elementos do modelo em representaes mais prximas do resultado final, bem como realizando
a validao desses itens.
Nessa etapa, a ferramenta faz uma verificao minuciosa do contedo e estrutura dos
objetos gerados a partir da leitura do modelo, visando a deteco de construes incompatveis
com a linguagem Java. Todos os itens de interesse so validadas individualmente, tendo seus
erros agrupados em listas. Nesse processo, so identificados elementos cuja notao causariam
erros de compilao quando transcritos para o cdigo.
A definio das regras de validaes se deu em observncia sintaxe da linguagem Java
e de suas limitaes, bem como considerando algumas das convenes da Java Persitence API
relacionadas aos tipos de dados de classes Bean.
4.2.1 Interpretao do Arquivo XML
Utilizando a API JDOM [27] a classe CarregaArquivoXML.java (Figura 18) faz

a leitura das tags contidas no arquivo model, agrupando-as em torno do bloco do diagrama que
as define. Para cada item do modelo, foi implementada uma classe (Figura 19) cujos atributos
abstraem a notao do elemento no arquivo XML, permitindo que os dados contidos nas tags
possam ser utilizados na instanciao de seus objetos.
A classe CarregaArquivoXML.java faz uso dessas itens ao transportar as instn-
cias das classes, atributos e associaes para a aplicao. Ela l os dados contidos nas tags
que abstraem esses elementos e os utiliza na criao dos objetos correspondentes. Essas instn-
cias so ento agrupadas em listas para que possam ser recuperadas de maneira mais gil pela
aplicao.
Figura 18 Classe CarregaArquivoXML.java
Ao final da leitura, trs listas so geradas dentro da classe CarregaArquivoXML:

uma contendo as instncias das classes, outra com as associaes e a ltima com as heranas.
Essas listas estticas permanecem na memria da aplicao at o fim da sua execuo, sendo
usadas no processo de validao do modelo e construo do cdigo.
Figura 19 Classes de Modelo da GenJPA.
4.2.2 Validao dos Objetos
O mdulo de validao da GenJPA implementa regras que verificam a integridade dos

blocos do modelo, identificando aqueles cuja notao apresenta alguma incompatibilidade com
o Java ou que ferem construes da UML. Esse mdulo processa as listas de classes, associaes
e heranas, sinalizando, por meio de excees, elementos invlidos do modelo.
Na ferramenta, quatro tipos de Exception foram implementadas para execuo dessa
sinalizao. Definidas como classes Java, cada uma identifica a existncia de erros na definio
do elemento ou de suas propriedades. A Tabela 3 descreve essas excees e a situao em que
so reportadas.
Exceo Java Ocorrncia

NomeInvalidoException.java Reportada quando o mdulo de validao identifica
erros de nomenclatura nas classes e atributos.
TipoInvalidoException.java Reportada quando o mdulo de validao identifica
erros de tipagem nos atributos das classes.
HerancaInvalidaException.java Reportada quando o mdulo de validao identifica
generalizaes que no estejam de acordo com a
sintaxe Java.
AssociacaoInvalidaException.java Reportada quando o mdulo de validao identifica
associaes em desacordo com as especificaes da
UML.
Tabela 3 Excees da GenJPA.

Durante a verificao, diversas excees podem ser retornadas pelo mdulo de validao.
Cada ocorrncia identifica um elemento invlido do diagrama, o qual dever passar por rees-
truturao antes de ser transformado em cdigo. A GenJPA agrupa essas ocorrncias de modo
que, ao final da validao, possam ser usadas para guiar as alteraes necessrias no modelo.
Para isso, todas as excees, assim que lanadas, tem seus dados capturadas e estruturadas como
objetos da classe Erro.java (Figura 20): tal erro, alm de identificar seu elemento causador,
fornece ainda uma descrio detalhada do problema ocorrido.
Incorporada ao mdulo de validao, uma lista recebe todas as instncia de Erro.java.
A mesma usada ao final da etapa para gerao do arquivo de Log da aplicao, cujo contedo
identifica todos os elementos que impedem o prosseguimento da transformao.
Figura 20 Erro.java.
4.2.2.1 Validao dos Nomes
Mesmo depois de normalizados nomes de classes e atributos podem conter sequncia de

caracteres cujo contedo gerariam erros de compilao quando transformados em cdigo exe-
cutvel. Excees do tipo NomeInvalidoException.java so lanadas pela ferramenta
sempre que algum nome descumpra as seguintes convenes:
Nomes de classes, atributos ou de qualquer outro item do cdigo no podem conter

palavras reservadas da linguagem Java:
Nomes de classes e atributos devem ser iniciados por uma letra ou pelo caractere $
(cifro). Nmeros e o caractere especial _ (underline) podem ser usados no corpo
dos nomes, mas nunca iniciando-os;
4.2.2.2 Validao dos Tipos
Na GenJPA, existe uma classe cujas funes so realizar o controle das importaes, a
converso e a validao dos tipos de atributos. Essa classe (GerenciadorDeTipos.java)
mantm um conjunto de listas contendo referncias para os tipos primitivos, Wrapers, temporais,
listas, conjuntos e mapas do Java; e tambm para tipos da UML e proprietrios das principais
ferramentas de modelagem.
Em posse desses dados, a (GerenciadorDeTipos.java) faz as validaes referen-
tes aos tipos de atributos, verificando se os tipos contidos no modelo possuem correspondentes
em Java. Para retornar essa informao, a classe percorre todos atributos do diagrama verificando
se os valores contidos em suas propriedades "tipo"esto referenciando valores da UML ou do
Java. Nesse processo, atributos que tenham tipos relacionados UML tm seus valores alterados
para Java.
Para isso, a classe faz uma pesquisa em sua lista de referncias da linguagem de destino,
buscando um tipo correspondente ao valor definido no atributo processado. Caso a busca tenha
sucesso, o valor da propriedade "tipo"do objeto alterado para o aquele encontrado na busca. Se
esse valor representar um tipo externo ao pacote raiz do Java, uma instncia de Importe gerada
pela classe de gerenciamento e relacionada ao atributo, indicando a necessidade de importao.
Excees TipoInvalidoException.java so lanadas sempre que o tipo de um
atributo do modelo no possua valor correspondente nas listas da classe GerenciadorDeTipos.java.
4.2.2.3 Validao das Generalizaes
A linguagem Java suporta apenas heranas do tipo simples, isto , uma subclasse pode ter
apenas uma classe me. Por outro lado, a UML permite, no diagrama de classes, a modelagem
de heranas mltiplas. Por conta dessa divergncia, as generalizaes contidas no modelo no
podem ser diretamente mapeadas para o cdigo.
Na GenJPA, heranas mltiplas so sinalizadas com HerancaInvalidaException.java.
4.2.2.4 Validao das Associaes
As regras de verificao das associaes foram implementadas embasadas no documento

oficial de especificao da UML: o UML Superstructure [2]. Nesse documento, existem duas
recomendaes cuja definio influenciam diretamente na consistncia e qualidade do cdigo
gerado. Excees do tipo AssociacaoInvalidaException.java so lanadas pela
ferramenta caso alguma das seguintes restries seja descumprida:
Ao menos uma das extremidades da associao deve ser navegvel.

Para que o todo mantenha o controle sobre suas partes, associaes do tipo composi-
o devem apresentar multiplicidade 1..1 para * (um para muitos).
4.2.3 Finalizao das Validaes
Ao final das verificaes, o mdulo de validao faz uma consulta lista de erros para
determinar o prosseguimento ou no do processo de engenharia frente. Dependendo do
resultado desta consulta, duas so as situaes possveis:
Quando a lista contm erros, o mdulo transfere os dados da mesma para o arquivo
de Log da ferramenta (Figura 22). Feito isso, uma mensagem apresentada na interface da
aplicao (Figura 21), informando ao usurio que o diagrama contm elementos cuja notao
incompatvel com as transformaes, devendo passar assim por reformulao. O processo
dado como finalizado e a ferramenta encerra sua execuo.
Figura 21 Feedback ao Usurio.
Figura 22 Arquivo de Log.
Quando a lista se encontra vazia, o mdulo de construo recebe uma mensagem infor-
mando que os blocos do modelo encontram-se em total acordo com as convenes da linguagem
de destino, podendo assim passar pela transformao.
Os objetos contidos nas listas de classes, associaes e heranas so ento repassados a
este mdulo para que se encarregue de gerar o cdigo final.
4.3 FASE DE CONSTRUO
Na etapa de construo, os objetos contidos nas listas de classes, associaes e heranas

so mapeadas para o cdigo. Esse processo executado por classes de controle, cuja funo
transportar determinado conceito da UML para representaes em cdigo Java/JPA. Nessas
classes, encontram-se definidas as construes sintticas da linguagem Java, bem como da
API JPA. Os blocos bsico do modelo, assim como conceitos especiais da associao e tipos
temporais, tm sua notao transcrita ao cdigo durante a etapa.
A gerao do cdigo se d em duas fases: mapeamento objeto-relacional / gerao do
cdigo. Na primeira, os blocos recebem as propriedades da JPA na forma de anotaes. Na
segunda, as classes so agrupadas e passam pela transformao final, dando origem ao cdigo.
Ao fim dessa fase, todas as entidades do sistema tm sua implementao gerada, podendo
ento ser usadas na criao do banco de dados da aplicao modelada.
4.3.1 Mdulo de Controle
O mdulo de controle agrupa todas as classes da GenJPA que mapeiam a linguagem de

destino. Nesse mdulo, as classes encontram-se divididas em dois grupos: as relacionadas com
o Java e as conectadas com a JPA.
As classes de controle Java contm regras para gerao da estrutura bsica de uma
classe na linguagem, fornecendo a sintaxe que define os conceitos de classe, atributos, heranas
e mtodos de controle de acesso (Get e Set). J as classes de controle JPA abstraem as
caractersticas do banco de dados, fornecendo a definio da sintaxe de anotaes e propriedades
da JPA, usadas no mapeamento objeto-relacional.
A Tabela 4 apresenta as classes de controle e suas funes.
Tipo de Cdigo Classe de Controle Definio

ClasseControlador.java Contm a sintaxe dos con-
Java ceitos de Importe, Construtor,
Classe e Herana.
AtributoControlador.java Contm a sintaxe bsica para
definio de atributos, gets e
sets.
AssociaoControlador.java Contm a sintaxe para a trans-
formao de associaes do
modelo em atributos.
EntityControlador.java Contm a sintaxe para defini-
o de uma entidade.
JPA IdControlador.java Contm a sintaxe para defini-
o de chaves primrias em en-
tidades.
InheritanceControlador.java Contm a sintaxe para mapea-
mento de heranas.
TemporalControlador.java Contm a sintaxe para mapea-
mento de tipos temporais.
CascadeFetchControlador.java Contm a sintaxe para mape-
amento de agregaes e com-
posies.
OneToOneControlador.java Contm a sintaxe para mapea-
mento de associaes 1..1.
OneToManyManyToOneControlador.java Contm a sintaxe para mapea-
mento de associaes 1..*.
ManyToManyControlador.java Contm a sintaxe para mapea-
mento de associaes *..*.
Tabela 4 Classes de Controle.
4.4 MAPEAMENTO OBJETO-RELACIONAL
Nessa etapa, os objetos tm sua notao estendidas com anotaes JPA para que possam
ser transportados para o banco. Esse processo consiste na adio de anotaes aos atributos e
classes do modelo. Agregaes, composies e associaes simples so mapeadas para o cdigo
por esses elementos.
Para efeito explicativo, toma-se como base o diagrama da Figura 23. Todo o processo de
mapeamento ser demostrado utilizando-o.
Figura 23 Diagrama de Exemplo.
A Tabela 5 mostra quais as anotaes JPA suportadas pela ferramenta e as classes de

controle que as mapeiam. As subsees seguintes descrevem todo o processo de mapeamento
objeto-relacional.
Classe de Mapeamento Anotao da JPA

EntityControlador.java @Entity
@Id
IdControlador.java
@GeneratedValue
TemporalControlador.java @Temporal
InheritanceControlador.java @Inheritance
OneToOneControlador.java @OneToOne
@OneToMany
OneToManyManyToOneControlador.java
@ManyToOne
ManyToManyControlador.java @ManyToMany
Tabela 5 Anotaes Suportadas pela GenJPA.
4.4.1 Transformao de Classes em Entidades
As classes passam por um mapeamento que indica sua natureza persistente. Trs anota-
es JPA fornecidas pelas classes EntityControlador.java e IdControlador.java
transformam classes comuns em entidades. Tais anotaes so acopladas aos objetos do tipo
classe tornando suas instncias persistentes.
Aqui a propriedade id gerada e adicionada como um atributo da classe. Essa proprie-
dade serve como chave primria da classe no banco de dados.
@Entity: identifica que a classe uma entidade.

@Id: acoplado ao atributo id identifica a chave primria da entidade.
@GeneratedValue: acoplado ao atributo id indica que a chave primria deve ser
gerada automaticamente pelo banco.
A Figura 24 mostra o diagrama de exemplo aps passar pelo mapeamento.
Figura 24 Diagrama de Exemplo aps a Transformao das Classes.
Todas as classes receberam a anotao @Entity. Um id foi gerado para a classe

Pessoa e Conta. ContaCorrente no recebeu esta propriedade, pois herda do relacionamento de
generalizao.
4.4.2 Mapeamento de Heranas

As heranas do modelo so mapeadas para o banco pela classe InheritanceControlador.java.
Ela abstrai a anotao @Inheritace da JPA, que durante o enriquecimento atribuda a todas as superclasses da
lista de classes.
O conceito de herana mapeado de trs maneiras distintas no banco relacional. Na interface da GenJPA,
o usurio pode selecionar qual o tipo ser usado durante a transformao.
Single Table: Uma tabela nica ser criada contendo todos os atributos das classes participantes da
herana.
Join Table: Uma tabela criada para cada classe mantendo a referncia da herana.
Table per Class: Uma tabela criada para cada classe, todavia perdendo as referncias da herana.
A Figura 25 mostra o diagrama de classes de exemplo aps o mapeamento das generalizaes.

Figura 25 Diagrama de Exemplo Aps o Mapeamento das Generalizaes.
A classe Conta recebeu a anotao @Inheritance do tipo Join Table. Esse o valor padro de
mapeamento de generalizaes caso o usurio no altere a opo na interface grfica da ferramenta.
4.4.3 Mapeamento de Atributos Temporais

Atributos cujo tipo seja java.util.Date ou java.util.Calendar recebem a anotao @Temporal
da JPA que indica ao banco a natureza temporal desses elementos.
A Figura 26 mostra o diagrama de exemplo aps esse mapeamento.
Figura 26 Diagrama de Exemplo Aps o Mapeamento dos Atributos Temporais.
O atributo nascimento da classe Pessoa recebeu a anotao @Temporal.

4.4.4 Mapeamento de Associaes

As associaes do modelo so mapeadas para o banco levando em considerao sua navegabilidade,
multiplicidade e tipo de agregao. A JPA fornece quatro anotaes para mapeamento de associaes:
@OneToOne: aplicado aos atributos gerados por associaes cuja multiplicidade 1..1 para 1..1 (Um
para Um);
@ManyToOne: aplicado aos atributos gerados por associaes cuja multiplicidade 1..* para 1..1
(Muitos para Um);
@OneToMany: aplicado aos atributos gerados por associaes cuja multiplicidade 1..1 para 1..*
(Um para Muitos);
@ManyToMany: aplicado aos atributos gerados por associaes cuja multiplicidade * para * (Muitos
para Muitos);
Para gerar o atributo correspondente uma associao, a GenJPA verifica as multiplicidades de ambas
as extremidades da mesma, bem como as navegabilidades. Aps determinar a notao do atributo e cri-lo, a
ferramenta acopla a anotao de mapeamento correspondente propriedade.
A Figura 27 apresenta o diagrama de exemplo aps ter sua associao mapeada.
Figura 27 Diagrama de Exemplo Aps o Mapeamento das Associaes.
A associao transformada no atributo conta da classe Pessoa, o qual tambm recebeu a anotao
@OneToMany. A navegabilidade da associao foi respeitada, mantendo-se as restries do projeto.
4.4.4.1 Mapeamento de Composio

A propriedade cascade das anotaes de mapeamento de associaes indica a relao de dependncia
entre as classes. Essa propriedade determina como os registros devem ser tratados no banco. Se uma associa-
o no diagrama do tipo composio, a anotao de mapeamento do atributo resultante recebe a propriedade
cascade=CascadeType.ALL. Ela indica a relao de controle entre a tabela todo e suas partes. A Figura 28
apresenta o resultado dessa etapa no diagrama de exemplo caso sua associao fosse do tipo composio.
Figura 28 Diagrama de Exemplo com Composio.
O atributo conta gerado pela associao recebe a anotao @OneToMany em conjunto com a propriedade
cascade=CascadeType.ALL. Isso indica ao banco que todas as operaes realizadas em Pessoa devem ser
refletidas em seus objetos conta. Incluses, excluses e alteraes feitas em Pessoa so imediatamente refletidas nas
Contas relacionadas. Esse mapeamento mantm o significado da composio.
4.4.4.2 Mapeamento de Agregao

Para representar o conceito de agregao utilizada a propriedade fetch=FetchType.EAGER no
atributo gerado pela associao. Ela determina que as informaes contidas nos registros sejam retornadas no
momento em que o objeto sejas consultado. A Figura 29 apresenta o resultado dessa etapa no diagrama de exemplo
caso sua associao fosse do tipo agregao.
Figura 29 Diagrama de Exemplo com Agregao.

O atributo conta, gerado pela associao, recebe a anotao @OneToMany em conjunto com a propri-
edade fetch=FetchType.EAGER. Dessa maneira, sempre que uma Pessoa tiver seus dados consultados no
banco todas as contas a ela relacionada viro em cascata. Tal construo possui valor semntico equivalente ao de
agregao da UML.
4.5 GERAO DO CDIGO EXECUTVEL
Aps o fim do mapeamento-objeto relacional, a classe ClasseControlador.java percorre a lista

de classes transformando os atributos, heranas, importes, anotaes e propriedades relacionados a cada instncia
de classe em cdigo Java/JPA. Para isso, utiliza as regras de mapeamento sinttico que define. Um arquivo com
extenso .java recebe os dados gerados por ClasseControlador.java. Para cada classe do modelo, um
arquivo .java gerado.
A Figura 30 mostra o cdigo gerado pelo diagrama com associao simples, omitindo importes e mtodos
de acesso. J a Figura 31 mostra o cdigo gerado a partir do diagrama com composio. Por fim, a Figura 32 mostra
o cdigo gerado a partir do diagrama com agregao. Nos trs casos, foram respeitadas as navegabilidades.
Figura 30 Cdigo Gerado pelo Diagrama com Associao Simples.
Figura 31 Cdigo Gerado pelo Diagrama com Agregao.

Figura 32 Cdigo Gerado pelo Diagrama com Composio.
Ao final da transformao, uma mensagem exibida na interface da aplicao informando ao usurio que
o processo est finalizado (Figura 33). Tm-se fim a engenharia frente.
Figura 33 Feedback Final.

57
5 CONCLUSO
Esta monografia apresentou a GenJPA, uma ferramenta de apoio metodologias dirigidas por mode-
los baseada em princpios e tecnologias de Model Driven Architecture. Foram descritas suas funcionalidades,
caractersticas e tecnologias empregadas no seu desenvolvimento.
A GenJPA gera cdigo Java/JPA, automatizando a implementao das entidades da aplicao, bem como a
estrutura fsica do banco de dados. Para isso, os conceitos da engenharia frente foram seguidos. A transformao
modelo-cdigo na ferramenta alm de mapear os blocos bsicos do diagrama de classes, tambm abrange os
conceitos mais ricos do modelo (agregao, composio e navegabilidade), diminuindo assim a ocorrncia de
inconsistncias.
Sistemas Java que faam uso de uma camada de dados podem ter seu tempo diminudo ao utilizar a
GenJPA. O cdigo resultante do processo de engenharia frente implementada no limita-se a um domnio, podendo
ser utilizado em sistemas Web, Mobile e Desktop.
As informaes contidas nesta monografia podem servir de ajuda para outros desenvolvedores interessados
em implementar ferramentas de apoio Mtodos Dirigidos por Modelo para novos domnios de aplicao.
5.1 TRABALHOS FUTUROS
Apesar de cumprir aquilo que se props, algumas melhorias poderiam ser feitas na ferramenta apresentada,
como:
Mostrar o resultado das validaes diretamente na interface da aplicao;

Aumentar a quantidade de anotaes da JPA suportadas, bem como as opes de mapeamento
fornecidas ao usurio para o controle da transformao;
Implementar uma verso Web que contemple as duas melhorias citadas.
58
REFERNCIAS
1 MAGALHAES, L. P. A. Um estudo sobre a engenharia de ida e volta entre UML e java. Dissertao (Mestrado)
UNIVERSIDADE FEDERAL DE MINAS GERAIS, 2011. Citado 8 vezes nas pginas 8, 14, 15, 16, 22, 25, 27
e 38.
2 OMG. UML Superstructure. 2011. <http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF>. [Online;
acessado 30-Maio-2017]. Citado 3 vezes nas pginas 8, 21 e 46.
3 RAMALHO, F. PLP - Paradigma de Programao Orientado a Modelos. 2008. UNIVERSIDADE FEDERAL
DE CAMPINA GRANDE. Citado 2 vezes nas pginas 8 e 26.
4 ROMANATO, A. Introduo ao Java Virtual Machine. Citado 2 vezes nas pginas 8 e 28.
5 CGERNERT. Database Development with HiberObjects. 2008. <https://techieexchange.wordpress.com/2008/
02/07/database-development-with-hiberobjects/>. [Online; acessado 24-Junho-2017]. Citado 2 vezes nas pginas 8
e 36.
6 TORRES, A. MD-JPA: Um perfil UML para modelagem do mapeamento objeto-relacional com JPA em uma
abordagem dirigida por modelos. Dissertao (Mestrado) UNIVERSIDADE FEDERAL DO RIO GRANDE DO
SUL, 2009. Citado 4 vezes nas pginas 8, 29, 36 e 37.
7 BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usurio. [S.l.]: Elsevier Brasil, 2006. Citado 13
vezes nas pginas 8, 14, 15, 19, 20, 21, 22, 23, 24, 30, 31, 32 e 33.
8 GUEDES, G. T. UML 2-Uma Abordagem Prtica-1a Edio. [S.l.]: Novatec Editora, 2011. Citado 13 vezes
nas pginas 14, 19, 20, 21, 22, 23, 24, 30, 31, 32, 34, 62 e 71.
9 GESSENHARTER, D. Mapping the uml2 semantics of associations to a java code generation model. Model
Driven Engineering Languages and Systems, Springer, p. 813827, 2008. Citado 2 vezes nas pginas 15 e 38.
10 JUNIOR, P. J. Java: Guia do programador. [S.l.]: Novatec Editora, 2007. Citado 2 vezes nas pginas 19 e 20.
11 DOBING, B.; PARSONS, J. How uml is used. Communications of the ACM, ACM, v. 49, n. 5, p. 109113,
2006. Citado na pgina 22.
12 SZLENK, M. Formal semantics and reasoning about uml class diagram. In: IEEE. Dependability of Computer
Systems, 2006. DepCos-RELCOMEX06. International Conference on. [S.l.], 2006. p. 5159. Citado na pgina 22.
13 PARADA, A. G.; SIEGERT, E.; BRISOLARA, L. B. de. Generating java code from uml class and sequence
diagrams. In: IEEE. Computing System Engineering (SBESC), 2011 Brazilian Symposium on. [S.l.], 2011. p.
99101. Citado na pgina 24.
14 PARADA, A. G.; SIEGERT, E.; BRISOLARA, L. B. de. Gencode: A tool for generation of java code from uml
class models. In: Proc. 26th South Symposium on Microelectronics (SIM 2011). [S.l.: s.n.], 2011. p. 173176.
Citado 3 vezes nas pginas 24, 25 e 35.
15 MAIA, N. E. N. ODYSSEY-MDA: uma abordagem para a transformao de modelos. Dissertao (Mestrado)
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO, 2006. Citado 2 vezes nas pginas 26 e 38.
16 OMG. XML Metadata Interchange. 2015. <http://www.omg.org/spec/XMI/>. [Online; acessado
01-Maro-2017]. Citado na pgina 27.
17 CODINGAME. Top Programming Languages to Learn in 2017. 2017. <https://www.codingame.com/blog/
top-programming-languages-to-learn-in-2017/>. [Online; acessado 15-Maio-2017]. Citado na pgina 27.
18 MENDES, D. R. Programao Java com nfase em Orientao a Objetos. [S.l.]: Novatec Editora, 2009.
Citado na pgina 27.
19 CLARO, D. B.; SOBRAL, J. B. M. Programao em java. Livro programando em Java 1a edio, p. 12, 2008.
Citado na pgina 28.
Referncias 59
20 BRAZ, C. C. M. Introduo Linguagem Java. 2005. <http://www.ebah.com.br/content/ABAAAAf70AJ/

introducao-a-java>. [Online; acessado 22-Maio-2017]. Citado na pgina 28.
21 CAELUM. Java e Orientao a Objetos. 2008. <https://www.caelum.com.br/download/
caelum-java-objetos-fj11.pdf>. [Online; acessado 22-Maio-2017]. Citado 2 vezes nas pginas 28
e 29.
22 K19. Persistncia com JPA 2 e Hibernate. 2015. <http://online.k19.com.br/libraries/handouts/k21>. [Online;
acessado 30-Maio-2017]. Citado 2 vezes nas pginas 29 e 30.
23 ORACLE. The Java EE 5 Tutorial. 2010. <http://docs.oracle.com/javaee/5/tutorial/doc/bnbqa.html>. [Online;
acessado 30-Maio-2017]. Citado na pgina 30.
24 HIBEROBJECTS. HIBEROBJECTS. Citado na pgina 36.
25 OMG. MDA - The Architecture Of Choice For A Changing World. 2016. <http://www.omg.org/mda/>. [Online;
acessado 15-Maio-2017]. Citado na pgina 38.
26 PAPYRUS. Papyrus: Modeling Environment. 2017. <https://eclipse.org/papyrus/>. [Online; acessado
30-Maio-2017]. Citado na pgina 40.
27 JDOM. JDOM. 2017. <http://www.jdom.org/>. [Online; acessado 22-Maio-2017]. Citado na pgina 43.
60
ANEXO A REGRAS DE EXTRAO EM ACCELEO
Este anexo contm a implementao das regras de extrao dos itens de interesse do diagrama de classes.
O cdigo est escrito em Acceleo, implementao da linguagem Model To Text Language da MDA.
[comment encoding = UTF-8 /]

[module main('http://www.eclipse.org/uml2/4.0.0/UML')]
[template public main(model : Model)]

[comment @main /]
[file (self.name+'.xml', false)]
<elementos>
[for(c:Class | model.packagedElement->filter(Class))]
<classe>
<id>[c.name/]</id>
<nome>[c.name.normalizarClasse()/]</nome>
[for(g:Generalization | c.generalization)]
<heranca>
<general>[g.general.name/]</general>
<specific>[g.specific.name/]</specific>
</heranca>
[/for]
[for(p:Property | c.ownedAttribute)]
[if(p.association=null)]
<atributo>
<visibilidade>[p.visibility.toString()/]</visibilidade>
<tipo>[p.type.name/]</tipo>
<nome>[p.name.normalizarAtributo()/]</nome>
[if(p.default<>null)]
<default>[p.default/]</default>
[/if]
</atributo>
[/if]
[/for]
</classe>
[/for]
[for(a:Association | model.packagedElement-
>filter(Association))]
<associacao>
<nome>[a.name/]</nome>
[a.associationEnd()/]
</associacao>
[/for]
</elementos>
[/file]
[/template]
[query private associationEnd(a:Association):
String = a.memberEnd->iterate(p:Property; result:String='' |
if result.size() = 0 then
result.concat('<membroA>'+
'\n\t<classe>'+p.type.name+'</classe>'+
'\n\t<agregacao>'+p.aggregation+'</agregacao>'+
'\n\t<minimo>'+p.lower+'</minimo>'+
'\n\t<maximo>'+p.upper+'</maximo>'+
if p.isNavigable() = true then
'\n\t<navegavel>true</navegavel>' else
'\n\t<navegavel>false</navegavel>' endif
+'\n</membroA>\n'
)
ANEXO A. Regras de Extrao em Acceleo 61
else
result.concat('<membroB>'+
'\n\t<classe>'+p.type.name+'</classe>'+
'\n\t<agregacao>'+p.aggregation+'</agregacao>'+
'\n\t<minimo>'+p.lower+'</minimo>'+
'\n\t<maximo>'+p.upper+'</maximo>'+
if p.isNavigable() = true then
'\n\t<navegavel>'+true+'</navegavel>' else
'\n\t<navegavel>false</navegavel>' endif
+'\n</membroB>')
endif
)
/]
[query public normalizarClasse(s:String) : String = invoke

('org.eclipse.acceleo.module.umlToJpa.validacao.NormalizadorDeNomes','
normalizarNomeClassificador(java.lang.String)',Sequence{self})/]
[query public normalizarAtributo(s:String) : String = invoke

normalizarNomeAtributo(java.lang.String)',Sequence{self})/]
[query public normalizarMetodo(s:String) : String = invoke

normalizarNomeMetodo(java.lang.String)',Sequence{self})/]
62
ANEXO B SISTEMA DE LEILO ONLINE
Este anexo apresenta o cdigo gerado pela GenJPA a partir de um diagrama de classes que modela um
Sistema de Leilo Online [8]. As entidades geradas pela ferramenta foram utilizadas na gerao de um banco de
dados relacional. O diagrama Entidade-Relacionamento apresentado no final deste anexo representa o banco de
dados gerado pelas classes Beans.
B.1 DIAGRAMA DE CLASSES
B.2 ENTIDADES
B.2.1 Participante.java
package modelo;
import javax.persistence.Entity;
import java.util.List;
import javax.persistence.GeneratedValue;
import javax.persistence.OneToMany;
import javax.persistence.Id;
@Entity
public class Participante{
ANEXO B. Sistema de Leilo Online 63
public Participante () {
}
@Id
@GeneratedValue
private Long id;
private String nome;
private String login;
private String senha;
private String email;
private String endereco;
private String telefone;
@OneToMany
private List<Lance> lance;
public String getNome (){

return this.nome;
}
public void setNome (String nome){

this.nome = nome;
}
public String getLogin (){

return this.login;
}
public void setLogin (String login){

this.login = login;
}
public String getSenha (){

return this.senha;
}
public void setSenha (String senha){

this.senha = senha;
}
public String getEmail (){

return this.email;
}
public void setEmail (String email){

this.email = email;
}
public String getEndereco (){

return this.endereco;
}
public void setEndereco (String endereco){

this.endereco = endereco;
}
public String getTelefone (){

return this.telefone;
}
public void setTelefone (String telefone){

this.telefone = telefone;
}
public List<Lance> getLance (){

return this.lance;
}
public void setLance (List<Lance> lance){

this.lance = lance;
}
public Long getId (){

return this.id;
}
public void setId (Long id){

this.id = id;
}
B.2.2 Lance.java
package modelo;
import javax.persistence.ManyToOne;
import java.util.Calendar;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
@Entity
public class Lance{
public Lance () {
}
@Id
@GeneratedValue
private Long id;
private Double val_lance;
@Temporal(TemporalType.TIMESTAMP)
private Calendar hora_lance;
@ManyToOne
private Item_Leilao item_leilao;
public Double getVal_lance (){

return this.val_lance;
}
public void setVal_lance (Double val_lance){

this.val_lance = val_lance;
}
public Calendar getHora_lance (){

return this.hora_lance;
}
public void setHora_lance (Calendar hora_lance){

this.hora_lance = hora_lance;
}
public Item_Leilao getItem_leilao (){

return this.item_leilao;
}
public void setItem_leilao (Item_Leilao item_leilao){

this.item_leilao = item_leilao;
}

return this.id;
}

this.id = id;
}
B.2.3 Leilao.java
package modelo;
import javax.persistence.CascadeType;
import java.util.Date;
@Entity
public class Leilao{
public Leilao () {
}
@Id
@GeneratedValue
private Long id;
private Date dt_inicio;
private Calendar hor_inicio;
private Date dt_final;
private Calendar hor_final;
@OneToMany(cascade=CascadeType.ALL)
private List<Item_Leilao> item_leilao;
public Date getDt_inicio (){

return this.dt_inicio;
}
public void setDt_inicio (Date dt_inicio){

this.dt_inicio = dt_inicio;
}
public Calendar getHor_inicio (){

return this.hor_inicio;
}
public void setHor_inicio (Calendar hor_inicio){

this.hor_inicio = hor_inicio;
}
public Date getDt_final (){

return this.dt_final;
}
public void setDt_final (Date dt_final){

this.dt_final = dt_final;
}
public Calendar getHor_final (){

return this.hor_final;
}
public void setHor_final (Calendar hor_final){

this.hor_final = hor_final;
}
public List<Item_Leilao> getItem_leilao (){

}
public void setItem_leilao (List<Item_Leilao> item_leilao){

}

return this.id;
}

this.id = id;
}
B.2.4 Item_Leilao.java
package modelo;
@Entity
public class Item_Leilao{
public Item_Leilao () {
}
@Id
@GeneratedValue
private Long id;
private String titulo_item;
private String descricao_item;
private Double lance_minimo;
private String caminho_foto;
private Integer arrematado;
public String getTitulo_item (){

return this.titulo_item;
}
public void setTitulo_item (String titulo_item){

this.titulo_item = titulo_item;
}
public String getDescricao_item (){

return this.descricao_item;
}
public void setDescricao_item (String descricao_item){

this.descricao_item = descricao_item;
}
public Double getLance_minimo (){

return this.lance_minimo;
}
public void setLance_minimo (Double lance_minimo){

this.lance_minimo = lance_minimo;
}
public String getCaminho_foto (){

return this.caminho_foto;
}
public void setCaminho_foto (String caminho_foto){

this.caminho_foto = caminho_foto;
}
public Integer getArrematado (){

return this.arrematado;
}
public void setArrematado (Integer arrematado){

this.arrematado = arrematado;
}

return this.id;
}

this.id = id;
}
B.3 DIAGRAMA ENTIDADE-RELACIONAMENTO

71
ANEXO C SISTEMA BANCRIO
Este anexo apresenta o cdigo gerado pela GenJPA a partir de um diagrama de classes que modela um
Sistema de Leilo Online [8]. As entidades geradas pela ferramenta foram utilizadas na gerao de um banco de
dados relacional. O diagrama Entidade-Relacionamento apresentado no final deste anexo representa o banco de
dados gerado pelas classes Beans.
C.1 DIAGRAMA DE CLASSES
C.2 ENTIDADES
C.2.1 Conta_Comum.java
package modelo;
import javax.persistence.InheritanceType;
import javax.persistence.Inheritance;
ANEXO C. Sistema Bancrio 72
@Entity
@Inheritance(strategy=InheritanceType.JOINED)
public class Conta_Comum{
public Conta_Comum () {
}
@Id
@GeneratedValue
private Long id;
private Long nr_conta;
private Date dt_abertura;
private Date dt_encerramento;
private Integer situacao;
private Integer senha;
private Double saldo;
@OneToMany
private List<Movimento> movimento;
public Long getNr_conta (){

return this.nr_conta;
}
public void setNr_conta (Long nr_conta){

this.nr_conta = nr_conta;
}
public Date getDt_abertura (){

return this.dt_abertura;
}
public void setDt_abertura (Date dt_abertura){

this.dt_abertura = dt_abertura;
}
public Date getDt_encerramento (){

return this.dt_encerramento;
}
public void setDt_encerramento (Date dt_encerramento){

this.dt_encerramento = dt_encerramento;
public Integer getSituacao (){

return this.situacao;
}
public void setSituacao (Integer situacao){

this.situacao = situacao;
}
public Integer getSenha (){

return this.senha;
}
public void setSenha (Integer senha){

this.senha = senha;
}
public Double getSaldo (){

return this.saldo;
}
public void setSaldo (Double saldo){

this.saldo = saldo;
}
public List<Movimento> getMovimento (){

return this.movimento;
}
public void setMovimento (List<Movimento> movimento){

this.movimento = movimento;
}

return this.id;
}

this.id = id;
}
C.2.2 Conta_Poupanca.java
package modelo;
import javax.persistence.ManyToOne;
@Entity
public class Lance{
public Lance () {
}
@Id
@GeneratedValue
private Long id;
private Double val_lance;
private Calendar hora_lance;
@ManyToOne
private Item_Leilao item_leilao;
public Double getVal_lance (){

return this.val_lance;
}
public void setVal_lance (Double val_lance){

this.val_lance = val_lance;
}
public Calendar getHora_lance (){

return this.hora_lance;
}
public void setHora_lance (Calendar hora_lance){

this.hora_lance = hora_lance;
public Item_Leilao getItem_leilao (){

}
public void setItem_leilao (Item_Leilao item_leilao){

}

return this.id;
}

this.id = id;
}
C.2.3 Conta_Especial.java
package modelo;
@Entity
public class Conta_Especial extends Conta_Comum{
public Conta_Especial () {
}
private Double limite_conta;
public Double getLimite_conta (){

return this.limite_conta;
}
public void setLimite_conta (Double limite_conta){

this.limite_conta = limite_conta;
}
}
C.2.4 Pessoa.java
package modelo;
import javax.persistence.InheritanceType;
import javax.persistence.Inheritance;
import javax.persistence.FetchType;
import javax.persistence.ManyToMany;
@Entity
@Inheritance(strategy=InheritanceType.JOINED)
public class Pessoa{
public Pessoa () {
}
@Id
@GeneratedValue
private Long id;
private String nome_pessoa;
private String end_pessoa;
private Long cep_pessoa;
private String tel_pessoa;
private Double renda_pessoa;
private Integer sit_pessoa;
@ManyToMany(fetch=FetchType.EAGER)
private List<Conta_Comum> conta_comum;
public String getNome_pessoa (){

return this.nome_pessoa;
}
public void setNome_pessoa (String nome_pessoa){

this.nome_pessoa = nome_pessoa;
}
public String getEnd_pessoa (){

return this.end_pessoa;
}
public void setEnd_pessoa (String end_pessoa){

this.end_pessoa = end_pessoa;
}
public Long getCep_pessoa (){

return this.cep_pessoa;
}
public void setCep_pessoa (Long cep_pessoa){

this.cep_pessoa = cep_pessoa;
}
public String getTel_pessoa (){

return this.tel_pessoa;
}
public void setTel_pessoa (String tel_pessoa){

this.tel_pessoa = tel_pessoa;
}
public Double getRenda_pessoa (){

return this.renda_pessoa;
}
public void setRenda_pessoa (Double renda_pessoa){

this.renda_pessoa = renda_pessoa;
}
public Integer getSit_pessoa (){

return this.sit_pessoa;
}
public void setSit_pessoa (Integer sit_pessoa){

this.sit_pessoa = sit_pessoa;
}
public List<Conta_Comum> getConta_comum (){

return this.conta_comum;
}
public void setConta_comum (List<Conta_Comum> conta_comum){

this.conta_comum = conta_comum;
}

return this.id;
}

this.id = id;
}
C.2.5 Pessoa_Juridica.java
package modelo;
@Entity
public class Pessoa_Juridica extends Pessoa{
public Pessoa_Juridica () {
}
private Long cnpj_pessoa;
public Long getCnpj_pessoa (){

return this.cnpj_pessoa;
}
public void setCnpj_pessoa (Long cnpj_pessoa){

this.cnpj_pessoa = cnpj_pessoa;
}
C.2.6 Pessoa_Fisica.java
package modelo;
@Entity
public class Pessoa_Fisica extends Pessoa{
public Pessoa_Fisica () {
}
private Long cpf_pessoa;
private Long rg_pessoa;
public Long getCpf_pessoa (){

return this.cpf_pessoa;
}
public void setCpf_pessoa (Long cpf_pessoa){

this.cpf_pessoa = cpf_pessoa;
}
public Long getRg_pessoa (){

return this.rg_pessoa;
}
public void setRg_pessoa (Long rg_pessoa){

this.rg_pessoa = rg_pessoa;
}
C.2.7 Movimento.java
package modelo;
@Entity
public class Movimento{
public Movimento () {
}
@Id
@GeneratedValue
private Long id;
private Integer tipo_mov;
private Date dt_mov;
private Calendar hor_mov;
private Double val_mov;
public Integer getTipo_mov (){

return this.tipo_mov;
}
public void setTipo_mov (Integer tipo_mov){

this.tipo_mov = tipo_mov;
}
public Date getDt_mov (){

return this.dt_mov;
}
public void setDt_mov (Date dt_mov){

this.dt_mov = dt_mov;
}
public Calendar getHor_mov (){

return this.hor_mov;
}
public void setHor_mov (Calendar hor_mov){

this.hor_mov = hor_mov;
}
public Double getVal_mov (){

return this.val_mov;
}
public void setVal_mov (Double val_mov){

this.val_mov = val_mov;
}

return this.id;
}

this.id = id;
}
C.3 DIAGRAMA ENTIDADE-RELACIONAMENTO

TCC Rhaylson

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

TCC Rhaylson

Încărcat de

Drepturi de autor:

Formate disponibile

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA DO PIAU

CAMPUS TERESINA CENTRAL

RHAYLSON SILVA DO NASCIMENTO

GENJPA: UMA FERRAMENTA DIRIGIDA POR MODELOS PARA GERAO DE

GENJPA: UMA FERRAMENTA DIRIGIDA POR MODELOS PARA GERAO DE

Projeto apresentado Banca Examinadora como

Orientador: Prof. Me . Fernando Castelo

Nascimento, Rhaylson Silva do

Trabalho de concluso de curso (Tecnologia) - Instituto Federal de Educao,

Orientador : Prof Me. Fernando Castelo Branco Gonalves Santana.

1. UML. 2. Diagramas de Classes. 3. Engenharia Frente. 4. Java. 5. Java

GENJPA: UMA FERRAMENTA DIRIGIDA POR MODELOS PARA GERAO DE

Projeto apresentado Banca Examinadora como

Aprovado pela banca examinadora em 28 de junho de 2017.

Prof. Me . Fernando Castelo Branco Gonalves Santana

Prof. Dr. Fraciric Alves de Arajo

Prof. Me . Duanny Dreyton Bezerra Sousa

Agradeo, primeiramente, Deus por ter me dado o dom da vida.

Palavras-chaves: UML, Diagramas de Classes, Engenharia Frente, Java, Java Persistence

Figura 1 Transformao Inconsistente de uma Composio [1]. . . . . . . . . . . . . 16

Tabela 1 Propriedades Especficas de Cada Item. . . . . . . . . . . . . . . . . . . . . 41

API Application Programing Interface

CASE Computer Assisted Software Engineering

CIM Computation Independent Model

GUI Graphical User Interface

GWT Google Web Toolkit

IDE Integrated Development Environment

JPA Java Persistence API

JVM Java Virtual Machine

MTL Model To Text Transformation Language

MDA Model Driven Archtecture

MDD Model Driven Development

MDE Model Driven Engineering

MOF Meta Object Facility

OMG Object Management Group

ORM Object/Relational Mapping

PSM Platform Specific Model

UML Unified Modeling Language

XMI XML Metadata Interchange

XML Extensible Markup Language

ANEXO A REGRAS DE EXTRAO EM ACCELEO . . . . . . . . 60

ANEXO B SISTEMA DE LEILO ONLINE . . . . . . . . . . . . . 62

ANEXO C SISTEMA BANCRIO . . . . . . . . . . . . . . . . . . . 71

Nesse captulo so apresentadas as razes que levaram a criao da ferramenta. Apresenta-

uma viso estrutural da arquitetura do sistema.

Agregaes e composies sempre so mapeadas para o cdigo como associaes

Figura 1 Transformao Inconsistente de uma Composio [1].

Figura 2 Transformao Inconsistente da Navegabilidade [1].

Alm da inconsistncia, Magalhes [1] apresenta tambm a deficincia das ferramentas

mecanismos de interao fornecidos por todas elas so mnimos, limitando-se exibio de

1.4.1 Objetivo Geral

1.4.2 Objetivos Especficos

Identificar os componentes de interesse do diagrama de classes e suas variaes

Os prximos captulos esto organizados da seguinte forma:

Fundamentao Terica: Nesse captulo so apresentados todos os conceitos teri-

Nesse captulo so apresentados todos os conceitos relacionados implementao da

2.1 ORIENTAO A OBJETOS

Hoje, grande parte dos sistemas de informao so desenvolvidos seguindo um mesmo

2.1.1 Classes e Objetos

A viso orientada a objetos, diferentemente do mtodo procedural, no se limita apenas

Figura 3 Representao de Classes e Objetos.

2.1.2 Heranas e Polimorfismo

No mundo real, algumas abstraes so derivadas de outras, levando isso em considerao