TCC

UNIVERSIDADE DE CAXIAS DO SUL

DEPARTAMENTO DE INFORMATICA

CURSO DE BACHARELADO EM CIENCIA DA COMPUTACAO

MARCOS D. PETRY

UML2Django: Gerador de Codigo

para Framework Web MVC

Prof. Joao L. Tavares

Orientador

Caxias do Sul, Dezembro de 2008

“However, as every parent of a small child knows,

converting a large object into small fragments

is considerably easier than the reverse process.

— Andrew Stuart Tanenbaum

AGRADECIMENTOS

Agradeco a Deus por ter me dado forcas para concluir este curso, me revitalizando

em todos os momentos de fraqueza.

Aos meus pais Ivan Luiz e Iana Fatima, por me entenderem a minha ausencia

devido ao trabalho e aos estudo, nao deixaram de estar do meu lado me apoiado

incondicionalmente.

Ao meu orientador, Professor Joao Luiz Tavares, pela paciencia, sabedoria, pe-

las suas correcoes e incentivo durante a implementacao do trabalho e redacao da

monografia.

A Universidade de Caxias do Sul, e ao docentes do departamento de informatica,

que durante os 7 anos de vida academica nesta instituicao, tive a honra de ser aluno.

Aos meus colegas de trabalho, que me ajudaram-me com meu TCC e na minha

carreira profissioal.

Agradeco aos amigos de minha cidade natal que me apoiaram em momentos que

precisei e me mostrando que a vida nao e so trabalho e estudo.

Aos amigos que fiz na Universidade: Joel, Alexandre, Fran, Vinıcius, Cristian,

Enor e muitos outros, por acompanharem minha trajetoria academica, e estarem

presentes em momentos complicados.

E por ultimo, mas nao menos importante, agradeco a minha querida e amada

namorada Letıcia, por ter me ajudado onde podia e ter me apoiado e me entendido

em momentos difıceis com muito amor e carinho.

SUMARIO

LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . 6

LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1 INTRODUCAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . 13

2 CONCEITOS PRELIMINARES . . . . . . . . . . . . . . . . . . . . . . 15

2.1 Padrao de desenvolvimento MVC . . . . . . . . . . . . . . . . . . . 15

2.2 Ferramentas Graficas de Modelagem . . . . . . . . . . . . . . . . . 16

2.3 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 Digramas de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Frameworks de desenvolvimento de aplicacoes . . . . . . . . . . . 18

2.4.1 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5 Linguagem de programacao Python . . . . . . . . . . . . . . . . . 19

2.5.1 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 DJANGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Persistencia de dados (model) . . . . . . . . . . . . . . . . . . . . . . 22

3.1.2 Visualizacao de dados (view) . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.3 Controle de dados (Controller) . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Fluxo de Execucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 IMPLEMENTACAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Arquitetura geral da implementacao proposta . . . . . . . . . . . 25

4.2 Parametros XMI utilizados pelo Parser . . . . . . . . . . . . . . . 25

4.3 Mapeamento de objetos XMI - Django Model . . . . . . . . . . . 29

4.4 Analise lexico-sintatica . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4.1 Extracao do XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5 Analise semantica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.5.1 Algoritmo de geracao . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 EXPERIMENTOS E RESULTADOS . . . . . . . . . . . . . . . . . . . 35

5.1 Diagramas com uma Classe . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Diagramas com duas Classes sem relacionamento . . . . . . . . . 35

5.3 Diagramas com duas Classes relacionadas . . . . . . . . . . . . . 36

5.4 Teste de Heranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.5 Teste multiplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 CONCLUSAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 Validacao do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7 ANEXOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

LISTA DE ABREVIATURAS E SIGLAS

DRY Don’t repeat yourself

GLC Gramatica Livre-de-Contexto

HTML HyperText Markup Language

HTTP Hypertext Transfer Protocol

MVC Model-view-controller

OMG Object Management Group

PDF Portable Document Format

TCC Trabalho de Conclusao de Curso

UML Unified Modeling Language

URL Uniform Resource Locator

XML Extensible Markup Language

XMI XML Metadata Interchange

LISTA DE FIGURAS

Figura 1.1: Imagem gerada pelo editor UML . . . . . . . . . . . . . . . . . . 12

Figura 3.1: Estrutura do framework Django . . . . . . . . . . . . . . . . . . . 22

Figura 3.2: Fluxo de Execucao do Framework Django . . . . . . . . . . . . . 24

Figura 4.1: Estrutura do parser XMI2Django . . . . . . . . . . . . . . . . . . 26

Figura 4.2: Diagrama de classes do sistema . . . . . . . . . . . . . . . . . . . 33

Figura 5.1: UML Representando uma classe . . . . . . . . . . . . . . . . . . . 35

Figura 5.2: UML Representando duas classes sem relacionamento . . . . . . . 36

Figura 5.3: UML representando duas classes relacionadas . . . . . . . . . . . 36

Figura 5.4: UML representando heranca . . . . . . . . . . . . . . . . . . . . . 37

Figura 5.5: Uml representando varias classes . . . . . . . . . . . . . . . . . . 38

LISTA DE TABELAS

Tabela 4.1: Mapeamento de objetos XMI - Django Model . . . . . . . . . . . 30

RESUMO

O desenvolvimento de aplicacoes WEB cresce contantemente e, como consequencia

disso, os recursos e as funcionalidades destas aplicacoes evolui. Portanto, desenvol-

ver aplicacoes de qualidade em um curto perıodo de tempo e um requisito cada vez

mais valorizado.

Uma maneira de melhorar o processo de desenvolvimento e a qualidade das

aplicacoes e utilizando frameworks de desenvolvimento. Utilizando frameworks, o

desenvolvedor pode focar-se de fato, no objetivo principal do sistema, evitando as-

sim, o trabalho repetitivo de outras aplicacoes, como por exemplo a construcao de

logins e controles de acesso. Um exemplo de framework que faz este trabalho e o

Django. Django constitui-se em um framework web de alto nıvel, escrito em Python,

que visa estimular o desenvolvimento rapido. Apesar de suas inumeras facilidades, o

Django nao possui uma ferramenta de geracao automatica de codigo a partir de di-

agramas graficos de modelagem, por exemplo. Esta funcionalidade auxiliaria muito

os desenvolvedores que, atualmente, precisam descrever manualmente a camada de

modelagem, dificultando tambem a documentacao estruturada, como por exemplo

atraves de diagrama de classes e padronizacoes ao estilo UML.

Focado nestas limitacoes, inerentes a qualquer ferramenta de software livre que

inicia sua evolucao no meio da producao de aplicacoes, este trabalho propoe uma fer-

ramenta que, aliada ao Django, tem a finalidade de gerar a camada de modelagem do

framework a partir de diagramas UML. Dessa forma o desenvolvedor consegue criar

o Model de forma mais rapida e facil, ao mesmo tempo que mantem a documentacao

de classes de seu sistema.

Palavras-chave: UML, VMC, Django, Framework, Python.

ABSTRACT

UML2Django: a code generator for Web MVC Framework

The development of the WEB applications grows constantly, and, as a conse-

quence of that, the resources and the functionalities of these applications evolves

too. Therefore, to develop applications of quality in a short period of time is a

requirement more and more valuable.

Development frameworks aid to improve the process of development and the qual-

ity of the applications. Using frameworks, the developer can actually be focused on

the main objective of the system, preventing some repetitive work on other applica-

tions, as for instance, the implementaion of logins and controls of access. Djando is

one of this kind of framework. Django consists in a high level web framework (writing

in Python) that aims to stimulate the fast development. Although its innumerable

easinesses, the Django does not possess a tool of automatic generation of code from

graphical diagrams of modeling, for instance. This functionality would very assist

the developers that, currently, need to describe the modeling layer manually, also

making it difficult the structuralized documentation, as for example through class

diagrams and standardizations in UML style.

Focused on those limitations, inherent to any tool of free software that initiates

its evolution in the production of applications, this work proposes a tool that, allied

to the Django, has the goal to generate the framework modeling layer from UML

diagrams. In this way, the developer is able to create the Model Layer in a faster

and easy way, at the same time that it keeps the class documentation of the system.

Keywords: UML, MVC, Django, Framework, Python.

11

1 INTRODUCAO

A cada dia que passa, a funcionalidade e os recursos dos sistemas produzidos

evolui, ao mesmo tempo em que e requerido uma maior agilidade no processo de

desenvolvimento dos mesmos. Desenvolver software em um curto perıodo de tempo

sempre foi um requisito desejavel para programadores e empresas.

Varios requisitos, padroes e tecnicas sao criados diariamente, com a finalidade

de aumentar a producao e melhorar o processo de construcao de sistemas. Como re-

sultado, foram criados diversas ferramentas e frameworks, varios processos e rotinas

repetitivas foram automatizados por eles e o tempo gasto no processo de imple-

mentacao de fato diminuiu. Em geral, um Framework, assim como web frameworks,

proporcionam uma infraestrutura de programacao para aplicacoes, de forma que o

projetista possa se concentrar na escrita de codigo eficiente e de facil manutencao.

Mas ainda ha diversos pontos a melhorar, ou pelo menos para facilitar o processo de

producao de codigo de forma automatizada, como por exemplo geracao automatica

de codigo nativo de um framework a partir do esquema de um diagrama de classes.

Os frameworks utilizados atualmente, seguem o padrao MVC (LEFF AVRAHAM; RAY-

FIELD, 2001), que e um padrao de arquitetura de aplicacoes que visa separar a logica

da aplicacao (Model), da interface do usuario (View) e do fluxo da aplicacao (Con-

troller). O uso deste tipo de framework permite que a mesma logica de negocios

possa ser acessada e visualizada por varias interfaces. Neste trabalho adotamos o

framework Django1 (MAURER, 2006), que utiliza o padrao MVC e tambem sua

arquitetura de desenvolvimento estimula o desenvolvedor a aproveitar ao maximo o

codigo ja feito, evitando a repeticao.

Como o objetivo de melhorar o processo de desenvolvimento com Django, este

trabalho propoe-se a gerar camada Model do framework Django, atraves de codigos

XML’s gerados por editores de diagramas de classe, permitindo assim alem de au-

mentar a velocidade de desenvolvimento de aplicacoes, a geracao e documentacao

basica do sistema.

1http://www.djangoproject.com/

12

1.1 Motivacao

O Framework escolhido, o Django, recentemente ganhou bastante notoriedade no

mundo do software livre, devido a sua praticidade no desenvolvimento de aplicacoes,

foi adotado em diversas empresas e instituicoes, como por exemplo o Google, Go-

verno Brasileiro e a Universidade de Caxias do Sul.

Django e um framework web de alto nıvel escrito em Python que estimula o desen-

volvimento rapido e limpo, concentrando-se no maximo de automatizacao possıvel,

aderindo ao princıpio DRY (Don’t repeat yourself). Eliminando processos repetiti-

vos como criacao e autenticacao de formularios e tambem a geracao automatica de

interface de administracao, mecanismos de cache e internacionalizacao.

Atualmente, o desenvolvimento de aplicacoes em Django nao possui nenhuma

ferramenta que gere codigo a partir de ferramentas de modelagem, a camada de

modelagem e escrita manualmente. Desse modo, se a equipe necessitar de algum

tipo de documentacao, como por exemplo um diagrama de classes, ela tera que

repetir o processo de construcao.

1.2 Objetivos

O objetivo principal deste trabalho e o desenvolvimento de uma ferramenta para

a geracao automatica de codigo Python a partir da modelizacao de diagramas ge-

rados por ferramentas de modelagem UML. Esta ferramenta visa o aumento de

produtividade e tambem a diminuicao da possibilidade de erros de codificacao.

Nesta proposta, trataremos da implementacao desta ferramenta, integrada ao

framework Django, com o objetivo de gerar a classe de modelagem do framework

web a partir dos diagramas de classes criados pela ferramenta de criacao de modelos

UML.

Basicamente o processo desta geracao segue os seguintes passos:

1. Construcao dos diagramas de classes em uma interface grafica (ex. ArgoUML,

Umbrello), Por exemplo, o projeto de um diagrama de classes com seus res-

pectivos componentes para definicao de atributos, relacionamentos, cardinali-

dades, etc, conforme a Figura 1, abaixo:

Figura 1.1: Imagem gerada pelo editor UML

13

2. Geracao do script XMI, padrao da OMG (grupo de gerenciamento de objetos)

(OMG, 2007), para troca de informacoes baseado em XML. O uso mais co-

mum e na troca facilitada de metadados entre as ferramentas de modelagem

(baseadas no UML). Um exemplo de um fragmento de script XMI e ilustrado

abaixo:

1 <?xml version = ’1.0’ encoding = ’UTF-8’ ?>

2 <XMI xmi.version = ’1.2’ xmlns:UML = ’org.omg.xmi.namespace.UML’

3 timestamp = ’Tue Sep 09 13:16:17 BRT 2008’>

4 <XMI.header> <XMI.documentation>

5 <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0)</XMI.exporter>

6 <XMI.exporterVersion>0.24(5) revised on $Date: 2006-11-06 19:55:22 +0100

7 (Mon, 06 Nov 2006) $ </XMI.exporterVersion>

8 </XMI.documentation>

9 &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;nbsp; <XMI.metamodel xmi.name="UML"

10 xmi.version="1.4"/></XMI.header>

11 <XMI.content>

12 <UML:Model xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077B’

13 name = ’untitledModel’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’

14 isAbstract = ’false’>

15 <UML:Namespace.ownedElement>

16 .

17 .

18 .

19 </UML:Namespace.ownedElement>

20 </UML:Model>

21 </XMI.content>

22 </XMI>

3. Tratamento das informacoes do XML e geracao de codigo no padrao do fra-

mework Django. O diagrama exemplificado na Figura 1 devera produzir o

seguinte codigo Python no framework Django:

1 class Pessoa_Email(models.Model):

2 endereco = EmailField()

3

4 class Pessoa(models.Model):

5 nome = models.CharField()

6 cidade = models.CharField()

7 nascimento = models.DateField()

8 enviar_mail = models.BooleanField()

9 endereco = models.ForeignKey(Pessoa_Email)

1.3 Estrutura do Documento

O presente trabalho esta dividido em 6 capıtulos:.

O capıtulo 1 apresenta uma introducao do trabalho, bem como a motivacao, os

objetivos, ferramentas de apoio e a estrutura do documento.

No Capıtulo 2, serao abordados alguns conceitos preliminares necessarios para

um melhor entendimento trabalho, onde apresentamos o padrao de desenvolvimento

14

MVC, uma introducao basica sobre a linguagem python e frameworks de desenvol-

vimento.

O framework alvo da aplicacao, o Django, sera apresentado no capıtulo 3, onde

serao descritos detalhes de seus componentes mais usuais e como o padrao MVC e

aplicado a ele.

No capitulo 4, apresentamos o trabalho desenvolvido, onde e focado o parser

implementado no projeto, a estrutura do sistema, os elementos relevantes do arquivo

XMI, a gramatica utilizada para ler estes elementos e o processo de traducao para

a sintaxe da classe Django.

O capıtulo 5 e destinado a apresentar os testes com o sistema, onde diversos

diagramas de classes serao traduzidos para codigo Python do Django atraves da

ferramenta implementada neste trabalho.

O Capıtulo 6 e destinado a apreciacao das conclusoes final bem como das alter-

nativas de continuidade e trabalhos futuros da presente proposta.

15

2 CONCEITOS PRELIMINARES

Neste Capıtulo, introduziremos alguns conceitos fundamentais necessarios ao en-

tendimento dos componentes utilizados no trabalho. Na secao 2.1 apresentamos uma

breve introducao sobre o padrao de desenvolvimento MVC. Introduzimos algumas

explicacoes sobre UML na secao 2.2. Na secao 2.3 serao abordados definicoes sofre

frameworks. Concluindo o capıtulo, sera feita uma breve explicacao sobre Python,

a linguagem utilizada neste trabalho.

2.1 Padrao de desenvolvimento MVC

MVC e um padrao de arquitetura de aplicacoes que visa separar a logica da

aplicacao (Model), da interface do usuario (View) e do fluxo da aplicacao (Control-

ler). Permite que a mesma logica de negocios possa ser acessada e visualizada por

varias interfaces.

O MVC tambem e utilizado em padroes de projetos de software, entretanto, MVC

abrange mais da arquitetura de uma aplicacao do que e tıpico para um padrao de

projeto.

Em um projeto de software baseado no padrao MVC , define-se uma arquitetura

basica com 3 camadas possivelmente abstratas:

• Model: Implementa o modelo representando a estrutura de baixo nıvel do

projeto, podendo ser o modelo objeto-relacional que implementa a camada de

dados. Um caso de MVC de Interface poderia guardar informacoes de estado

dos controllers, por exemplo;

• Controller: Implementa a camada responsavel pelo gerenciamentos de eventos

no projeto, tais como cliques do usuario, chamando a camada Model para

processar os eventos. Tambem pode manter informacoes de estado do usuario

na aplicacao;

• View: Gera a interface com usuario de modo que esta somente requisite o

processamento de eventos pelo Controller;

16

Segundo (BEZERRA, 2007), Model-view-controller (MVC) e um padrao de ar-

quitetura de software. Com o aumento da complexidade das aplicacoes desenvol-

vidas torna-se fundamental a separacao entre os dados (Model) e o layout (View).

Desta forma, alteracoes feitas no layout nao afetam a manipulacao de dados, e estes

poderao ser reorganizados sem alterar o layout.

O model-view-controller resolve este problema atraves da separacao das tarefas

de acesso aos dados e logica de negocio, logica de apresentacao e de interacao com o

utilizador, introduzindo um componente entre os dois: o Controller. MVC e usado

em padroes de projeto de software, mas MVC abrange mais da arquitetura de uma

aplicacao do que e tıpico para um padrao de projeto.”

2.2 Ferramentas Graficas de Modelagem

A escolha de ferramentas de Geracao de Diagramas de classes foi definida tendo

como base dois criterios: ser software livre e possuir exportacao para XMI. Foram

encontradas as seguintes ferramentas que possuem estes requisitos: ArgoUML1 e

Umbrello2.

Umbrello UML Modeller permite a modelizacao de software atraves de diagramas

UML (Unified Modeling Language) originalmente para o ambiente KDE-Linux, com

extensoes recentes para Windows e MAC. Umbrello manipula todos os tipos de

diagramas UML e e capaz de gerar codigo para algumas linguagens como Java,

C++, Python, PHP, entre outras. No entanto, o codigo Python gerado a partir

dos diagramas do Umbrello ainda nao sao compatıveis com o framework Django,

necessitanto algumas adaptacoes manuais que, dependendo do tamanho do projeto,

pode tornar inviavel sua execucao.

ArgoUML e um software para modelagem UML escrito em Java. Possibilitando

ser instalado em qualquer plataforma com suporte a esta tecnologia. Possui suporte

completo para UML 1.4 padrao e oferece excelentes metodos para criacao e mani-

pulacao dos seus diagramas em UML. Oferece suporte para geracao de codigo Java

nativo e outras linguagens (C++, C# e PHP) atraves de plugins disponibilizados

em seu site. Infelizmente, a exportacao para codigo Python esta somente nos planos

de seus desenvolvedores.

As ferramentas acima salvam o diagrama no formato padrao XMI (XML Meta-

data Interchange) (OMG, 2007), que segundo Eduardo Bezerra, define XMI como

sendo:

”um padrao baseado em XML para exportar modelos definidos em

UML. Esse padrao e importante, pois permite a interoperabilidade

1http://argouml.tigris.org/2http://uml.sourceforge.net/

17

entre diversas ferramentas CASE: um diagrama produzido em uma

ferramenta A pode ser importado para uma ferramenta B de outro

fabricante, considerando que os fabricantes A e B sao suporte ao

padrao XMI”(BEZERRA, 2007)

2.3 UML

A UML e uma linguagem visual para modelar sistemas orientados a objeto. Isso

quer dizer que a UML e uma linguagem que define elementos graficos que podem

ser utilizados na modelagem de sistemas. Esses elementos permitem representar os

conceitos de orientacao a objetos atraves dos diagramas criados. Seguindo a notacao

UML, e possivel representar diversas perspectivas do sistema. Ainda segundo (BE-

ZERRA, 2007), cada elemento grafico da UML possui sintaxe e uma semantica.

A sintaxe de um elemento corresponde a forma predeterminada de desenhar o ele-

mento. A semantica define o que significa o elemento e com que objeto ele deve ser

utilizado. Tanto a sintaxe quanto a semantica dos elementos sao extensıveis. Essa

extensibilidade permite que a UML seja adaptada as caracterısticas de cada projeto

de desenvolvimento.

Embora a UML possua diversos diagramas para representar o sistema (ativida-

des, casos de uso, colaboracao, sequencia, entre outros) o sistema desenvolvido utiliza

somente diagramas de classe, pois e o diagrama mais indicado para o proposito do

mesmo.

2.3.1 Digramas de Classe

Um diagrama de classes basicamente descreve a estrutura de um sistema, mos-

trando as classes implantadas, seus atributos, e as relacoes entre as classes. Cada

classe do diagrama possui um conjunto de objetos: Nome da classe, atributos, rela-

cionamentos e metodos.

2.3.1.1 Atributos

Definicao das caracterısticas da classe, cada elemento de sua lista de atributos

possui um nome e um tipo de dado.

2.3.1.2 Relacionamentos

Um relacionamento representa uma ligacao entre classes, e uma ligacao binaria

(com duas extremidades) onde cada extremidade e ligada a uma classe, atraves de

uma linha. Existem diferentes tipos de relacionamento: Agregacao, composicao,

Heranca.

18

2.3.1.3 Metodos

Metodos sao funcoes requeridas a um objeto ou seja, as acoes que os objetos de

uma classe pode executar.

2.4 Frameworks de desenvolvimento de aplicacoes

Estamos em uma epoca onde as informacoes sao recebidas rapidamente, notıcias

de qualquer parte do mundo chegam as pessoas de forma quase instantanea. Grande

parte dessa informacao e veiculada atraves da WEB. Para isso o desenvolvimento

de aplicacoes web e muito explorado.

Apesar da quantidade de ferramentas de desenvolvimento ser bastante grande,

implementar aplicacoes para Internet nao e algo trivial. Construir uma aplicacao

web totalmente funcional a algo bastante trabalhoso. Muitas tarefas sao necessarias

para que tal feito seja completo: A Configuracao e a criacao de tabelas em base de

dados, criacao de consultas e relacionamentos para as mesmas, geracao de codigo

HTML, mapear as URL para ler os codigos, controle de usuarios, e estes itens sao

so a parte basica do desenvolvimento.

O desenvolvimento para WEB e muito repetitivo; os passos a serem seguidos

sao praticamente os mesmos para cada nova aplicacao a ser criada. Como tenta-

tiva de minimizar ao maximo estes repetitivos passos, foram criadas bibliotecas e

frameworks para facilitar o desenvolvimento de aplicacoes, fazendo com que o de-

senvolvedor focalize basicamente o objetivo do novo sistema, deixando a cargo do

framework manter as tarefas mais macantes.

Um framework e uma camada de abstracao na qual um determinado conjunto

de codigos implementa uma certa funcionalidade generica, facilmente customizada

pelo usuario, criando assim um funcionalidade expecifica. E funcao do framework

tambem, validar o codigo criado pelo usuario.

Os frameworks para desenvolvimento web geralmente seguem o padrao de arqui-

tetura de sistema MVC para separar as camadas de negocio, persistencia e interface.

2.4.1 Exemplos

A maioria das linguagens voltadas para o desenvolvimento WEB posuem fra-

meworks: Ruby possui um dos mais famosos framework WEB da atualidade, o

Ruby on Rails 3. Python possui uma gama consideravel de ferramentas como o

3http://www.rubyonrails.org

19

Django, TurboGears4, Pylons5, Zope6/Plone7, web2py8 entre outros. PHP9 que e

uma das mais utilizadas linguagens para peogramacao WEB possui os frameworks

CakePHP10, CodeIgniter11, Prado12, symfony13, Zend14, entre outros. Perl possui o

Catalyst15, Maypole16, Jifty17, e a maioria deles segue o padrao MVC.

2.5 Linguagem de programacao Python

Python18 e uma linguagem de programacao de alto nıvel, interpretada, intera-

tiva, orientada a objetos e de tipagem dinamica e forte, lancada por Guido van

Rossum em 1991. Atualmente possui um modelo de desenvolvimento comunitario e

aberto gerenciado pela organizacao sem fins lucrativos Python Software Foundation.

Apesar de varias partes da linguagem possuırem padroes e especificacoes formais,

a linguagem como um todo nao e formalmente especificada. O padrao de imple-

mentacao e o CPython, o que significa que foi desenvolvida a partir da linguagem

C, mas existe tambem as variantes Jython e IronPython que sao reimplementacao

do Python produzidas em Java e .NET respectivamente.

A linguagem foi projetada com a filosofia de enfatizar a importancia do esforco do

programador sobre o esforco computacional. Prioriza a legibilidade do codigo sobre a

velocidade ou expressividade. Combina uma sintaxe concisa e clara com os recursos

poderosos de sua biblioteca padrao e por modulos e frameworks desenvolvidos por

terceiros.

2.5.1 Exemplos

Atraves dos exemplo abaixo, e possivel verificar a simplicidade da linguagem:

2.5.1.1 Fibonacci

1 a =1

2 b =1

3 while a < 800:

4 print a ,

4http://turbogears.org5http://pylonshq.com6http://www.zope.org7http://www.plone.org8http://mdp.cti.depaul.edu9http://www.php.net

10http://www.cakephp.org11http://codeigniter.com12http://www.pradosoft.com13http://www.symfony-project.org14http://www.zend.com15http://www.catalystframework.org16http://maypole.perl.org17http://jifty.org18http://www.python.org

20

5 a,b = b,a+b

2.5.1.2 Numeros Primos

1 ehprimo = True

2 numero = input ( " Informe o numero : " )

3 i = 2

4 while i < numero :

5 if numero % i == 0:

6 ehprimo = False

7 break

8 i += 1

9 if ehprimo :

10 print " Primo : " , numero

11 else :

12 print numero , ’ possui fator ’ , i

2.5.1.3 Calculo de Fatorial

1 n = int ( raw_input ( " Fatorial de : " ))

2 fatorial = 1

3 print " % d ! = " %n ,

4 i = n

5 while i > 0:

6 fatorial = fatorial * i

7 print " % d " %i ,

8 if i != 1: print " . " ,

9 i -= 1

21

3 DJANGO

Django (DJANGO, 2008) e um framework para desenvolvimento rapido para

web, escrito em Python, que utiliza o padrao MVC (model-view-controller). Foi

criado originalmente como sistema para gerenciar um site jornalıstico na cidade de

Lawrence, no Kansas. Tornou-se um projeto de codigo aberto e foi publicado sob

a licenca BSD1 em 2005. O nome Django foi inspirado no musico de jazz Django

Reinhardt.

Django utiliza o princıpio DRY (Don’t Repeat Yourself), onde faz com que o

desenvolvedor aproveite ao maximo o codigo ja feito, evitando a repeticao.

Na secao 3.1, abordaremos as caracterısticas do framework, onde serao explicados

os componentes principais da ferramenta, tais como Controllers, Templates, Models,

Middlewares e URLDispacher. Na secao 3.2 sera explicado o fluxo de execucao de

uma requisicao no Django.

3.1 Caracterısticas

Atraves do ORM2 do Django e definida a modelagem de dados atraves de classes

em Python, clamadas modelos. Com isso e possıvel independente de qual banco

de dados escolhido, gerar suas tabelas e manipular seus dados sem necessidade de

utilizar linguagem SQL.

Os Models tambem possibilitam criar formularios automaticos e gerar uma inter-

face de administracao praticamente completa e facilmente configuravel e extensıvel,

aumentando ainda mais o desenvolvimento das aplicacoes.

O Django possui uma linguagem de templates muito extensıvel e amigavel. Atraves

dela e possivel fazer a separacao de design, conteudo e codigo Python.

A figura 3.1 ilustra a estrutura global do Django, exibindo a ligacao entre os

componentes principais do framework. Os componentes estao classificados em cores,

representando as camadas do sistema.

1http://www.opensource.org/licenses/bsd-license.php2Object-Relational Mapping

22

Figura 3.1: Estrutura do framework Django

3.1.1 Persistencia de dados (model)

A Classe de Modelagem e basicamente, a fonte de todos os registros no projeto.

Ele contem todos os campos essenciais e relacoes de tudo que e armazenado no

Banco de dados. Geralmente, cada modelo mapeia uma unica tabela de dados.

3.1.2 Visualizacao de dados (view)

.

A visualizacao dos dados pelos usuarios e feita atraves das views e dos templates.

Sao atraves deles que os dados recebidos pelos models sao manipulados. Os acessos

aos dados sao feitos atraves das views.

As views sao as secoes do site, onde os dados recebidos pela camada de per-

sistencia sao apresentados, criados, editados e deletados por scripts python. Por

exemplo, em uma aplicacao de um blog, haveriam as seguintes views:

• Inıcio - exibicao das 5 ultimas postagens;

• Postagem - pagina para uma unica entrada;

• Postagem-Comentario - comentarios de uma determinada postagem;

• Ano-arquivo - exibe todos os meses com as inscricoes no ano determinado;

23

• Mes-arquivo - exibe todos os dias com entradas do mes em questao;

• Dia-arquivo - exibe todas as entradas em determinado dia;

O sistema de templates do django e um modulo que visa separar a apresentacao dos

dados logicos do site. O Template define certos espacos onde sao definidos lacos de

repeticoes, condicionais e outras funcionalidades do django para manipular variaveis

passadas pela view. Normalmente, os templates sao utilizados para produzir docu-

mento HTML, mas os templates do Django sao capazes de gerar qualquer formato

de tipo texto tambem.

3.1.3 Controle de dados (Controller)

Entre a camada de visualizacao e o usuario, ha a camada de controle, responsavel

pelo processamento de acoes de requisicoes e resposta do usuario (HTTP Request e

HTTP Response). Para realizar este processamento o Django conta com Middlewa-

res e Url Dispatcher.

As middlewares sao trechos de codigo que analisam requisicoes feitas pelo usuario.

Atraves dele e possıvel enviar informacoes para view de forma transparente ao

usuario como, por exemplo, detalhes sobre secoes e autenticacao.

Depois de passar pelos middlewares, a requisicao e analisada pelo URL Dispat-

cher, que verifica o endereco que o usuario acessa e verifica se o mesmo consta no

arquivo de URLs da aplicacao. Cada URL esta associada a uma view, se a URL

requisitada nao se encontra no arquivo um erro do tipo 4043 e informado.

3.2 Fluxo de Execucao

Atraves de um browser, o usuario faz uma requisicao a um site Django, de acordo

com a URL informada. O Framework verifica se a mesma esta nos seus registros

de URL. Apos a localizacao da URL, uma view correspondente e invocada, a view

requisita informacoes a classe de modelagem que devolve os dados. Com os dados

recebidos da classe de modelagem, o Django armazena em variaveis e envia para um

template. O template recebe as variaveis da view e renderiza o template no formato

desejado (HTML, PDF). A pagina renderizada e exibida na tela para o usuario. O

processo detalhado pode ser visto na Figura 3.2.

3404 Error. The Page Was Not Found

24

Figura 3.2: Fluxo de Execucao do Framework Django

25

4 IMPLEMENTACAO

Neste Capıtulo abordamos a implementacao da proposta de geracao de codigo

python no framework Django a partir de modelos de diagramas de classes. Na secao

4.1 introduzimos a arquitetura geral do sistema proposto, mostrando seus compo-

nentes principais e seus relacionamentos. Na secao 4.2 mostramos a delimitacao do

escopo dos elementos XMI tratados pelo nosso gerador.

4.1 Arquitetura geral da implementacao proposta

A implementacao do Parser XMI-DjangoModel foi feita inteiramente utilizando

Python, a mesma linguagem do Framework web Django. Nao foi definida nenhuma

interface grafica, pois nao ha necessidade para tal. Basicamente o script recebe

como parametro o arquivo XML e gera a classe de modelagem. A Figura 4.1 ilustra

a arquitetura geral do analisador XMI2Django proposta neste trabalho.

Os principais modeladores de graficos UML possuem um metodo de exportacao

em arquivo texto para que os diagramas criados possam ser acessados em outro

modelador. O metodo que resulta este texto, esta escrito em padrao XMI, um

formato definido pela OMG para representacao, intercambio e compartilhamento de

objetos, modelos e meta-modelos utilizando XML.

Teoricamente, os dados XMI exportados em um modelador, deverao ser lidos

em outro sem maiores problemas, logo o parser do trabalho em questao, ira gerar

o codigo Django independente da ferramenta de modelagem UML utilizada, desde

que ele exporte o arquivo XMI

4.2 Parametros XMI utilizados pelo Parser

Boa parte das tags contidas no XML gerado pelo editor UML nao sao utilizadas

no parser, pois muitas delas sao geradas com a finalidade de exportacoes para outros

aplicativos (como por exemplo, outro editor UML). No trabalho em questao sao

utilizadas, para uma geracao correta da classe de modelagem do Django, os seguintes

elementos:

26

Figura 4.1: Estrutura do parser XMI2Django

• UML:Namespace.ownedElement

O elemento raiz do xmi, e onde todos os itens do diagrama em questao

estao inseridos;

• UML:DataType

Lista de tipos de dados (name, xmi.id);

• UML:Class

Classes do diagrama de classes (name, xmi.id);

• UML:Classifier.feature

Tag XMI que contem a tag UML:Attribute;

• UML:Attribute

Atributos da classe (name, xmi.id);

• UML:ModelElement.taggedValue

Tag XMI que contem a tag XML:TaggedValue;

• UML:TaggedValue

Lista de valores marcados;

27

• UML:TaggedValue.type

Tag XMI que contem a tag UML:TagDefinition;

• UML:TagDefinition

Apontador para o valor marcado (xmi.idref);

• UML:TaggedValue.dataValue

Valor do Valor Marcado (name);

• UML:StructuralFeature.type

Tag XMI que contem a tag UML:DataType;

• UML:DataType

Um apontador para um tipo de dado (xmi.idref);

• UML:Association

Lista de associacoes entre classes;

• UML:Association.connection

Tag XMI que contem a tag UML:AssociationEnd;

• UML:AssociationEnd

Tipo de associacao (Composicao, agregacao, heranca) (aggregation);

• UML:AssociationEnd.participant

Lista de objetos participantes da associacao, para o parser, ele trata apenas

classes;

• UML:Class

Um apontador para a classe (xmi.idref);

• UML:AssociationEnd.multiplicity

Tag XMI que contem a tag UML:Multiplicity;

• UML:Multiplicity

Tag XMI que contem a tag UML:Multiplicity.range;

• UML:Multiplicity.range

Tag XMI que contem a tag UML:MultiplicityRange;

• UML:MultiplicityRange

Multiplicidade da associacao (1 para n, 1 para 1) (lower, upper);

28

• UML:TagDefinition

Nome do Valor Marcado (name, xmi.id).

Abaixo esta parte do codigo XMI gerado pelo editor UML que e utilizado pelo

parser. Nele esta modelado o diagrama UML apresentado no capıtulo de Introducao.

Duas classes, a primeira (Cidade) com um atributo (nome) e a segunda (Estado)

com dois atributos (Nome e Zona) e um relacionamento 1:n entre elas. O codigo

inteiro esta nos anexos:


2 <UML:Class xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077C’

3 name = ’Cidade’ visibility = ’public’ isSpecification = ’false’ isRoot = ’false’

4 isLeaf = ’false’ isAbstract = ’false’ isActive = ’false’>

5 <UML:Classifier.feature>

6 <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077F’

7 name = ’nome’ visibility = ’public’ isSpecification = ’false’ ownerScope = ’instance’

8 changeability = ’changeable’ targetScope = ’instance’>

9 <UML:StructuralFeature.type>

10 <UML:DataType xmi.idref = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000786’/>

11 </UML:StructuralFeature.type>

12 </UML:Attribute>

13 </UML:Classifier.feature>

14 </UML:Class>

15 <UML:DataType xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000786’

16 name = ’CharField’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’

17 isAbstract = ’false’/>


19 name = ’IntegerField’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’


21 <UML:Class xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000792’

22 name = ’Estado’ visibility = ’public’ isSpecification = ’false’ isRoot = ’false’



25 <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000795’






31 </UML:Attribute>

32 <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007AF’

33 name = ’zona’ visibility = ’public’ isSpecification = ’false’ ownerScope = ’instance’





38 </UML:Attribute>


40 </UML:Class>

41 <UML:Association xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C2’

42 name = ’’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’>

43 <UML:Association.connection>

44 <UML:AssociationEnd xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C3’

45 visibility = ’public’ isSpecification = ’false’ isNavigable = ’true’ ordering = ’unordered’

46 aggregation = ’composite’ targetScope = ’instance’ changeability = ’changeable’>

47 <UML:AssociationEnd.multiplicity>

29

48 <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C4’>

49 <UML:Multiplicity.range>

50 <UML:MultiplicityRange

51 xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C5’

52 lower = ’1’ upper = ’1’/>

53 </UML:Multiplicity.range>

54 </UML:Multiplicity>

55 </UML:AssociationEnd.multiplicity>

56 <UML:AssociationEnd.participant>

57 <UML:Class xmi.idref = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077C’/>

58 </UML:AssociationEnd.participant>

59 </UML:AssociationEnd>



62 aggregation = ’none’ targetScope = ’instance’ changeability = ’changeable’>


64 <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007CA’>


66 <UML:MultiplicityRange

67 xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C9’

68 lower = ’1’ upper = ’-1’/>





73 <UML:Class xmi.idref = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000792’/>



76 </UML:Association.connection>

77 </UML:Association>


4.3 Mapeamento de objetos XMI - Django Model

O gerador proposto tem como objetivo traduzir elementos XMI em codigo Python

segundo o framework Django. A Tabela 4.1 ilustra os componentes (tags) XMI con-

siderados e sua respectiva traducao no framework Django. Cada linha da tabela

podera ser gerada por uma ou varias regras de producao gramaticais aliadas a re-

gras semanticas para geracao de codigo Python.

4.4 Analise lexico-sintatica

O parser considerado neste projeto e um top-down descendente para gramaticas

do tipo LL1. Considerando o escopo delimitado na secao 2.2, a gramatica livre-de-

contexto (GLC) definida aqui compreende apenas a geracao de producoes relativas

aos componentes de representacao de Classe, atributos e relacionamentos do padrao

XMI. Para tanto, limitamos nossa gramatica a estas tags especıficas. Alem disso,

nao foi criada nenhuma validacao da sintaxe do XMI, pois, partimos do pressuposto

1Left-to-Right, Leftmost derivation com lookahead. Para isto, a gramatica livre-de-contextodeve estar livre de recursao a esquerda e deve estar fatorada.

30

Tag XMI Django

UML:Class Classe DjangoUML:Attribute Atributo da Classe DjangoUML:DataType Tipo do atributoUML:Association, Geracao de um atributo da classe

UML:AssociationEnd, Django que representara a associacao, sejaUML:AssociationEnd.participant, ela chave Estrangeira ou umUML:MultiplicityRange mapeamento N para NUML:TagDefinition,

UML:TaggedValue.type, Parametros utilizados nos atributos da classeUML:TaggedValue.dataValue

Tabela 4.1: Mapeamento de objetos XMI - Django Model

que a mesma esteja correta, pois foi gerada automaticamente atraves de um sistema

ja consolidado.

Como a estrutura do XMI e basicamente uma estrutura em forma de arvore, a

gramatica utilizada no parser e bem simples. A seguir apresentamos a GLC proposta

em formato BNF:

1 <UML:Namespace.ownedElement> ::= <UML:DataType> <UML:Class> <UML:Association>

2 <UML:DataType> ::= name "=" "’" valor "’" xmi.id "=" "’" valor "’"

3 | xmi.idref "=" "’" valor "’"

4 <UML:Class> ::= UML:Classifier.feature name "=" "’" valor "’" xmi.id "=" "’" valor "’"

5 | xmi.idref = "valor"

6 <UML:Class> ::= UML:Class name "=" "’" valor "’" xmi.id "=" "’" valor "’" <UML:Classifier.feature>

7 <UML:Class> ::= UML:Class xmi.idref "=" "’" valor "’"

8

9 <UML:Classifier.feature> ::= <UML:Attribute>

10 <UML:Attribute> :: = UML:ModelElement.taggedValue UML:StructuralFeature.type"

11 name "=" "’" valor "’" xmi.id "=" "’" valor "’"

12 <UML:ModelElement.taggedValue> ::= "UML:TaggedValue"

13 <UML:TaggedValue> :: = "UML:TaggedValue.type" "UML:TaggedValue.dataValue"

14 <UML:TaggedValue.type> ::= "UML:TagDefinition"

15 <UML:TagDefinition> ::= xmi.idref "=" "’" valor "’"

16 <UML:TaggedValue.dataValue> ::= name "=" "’" valor "’"

17 <UML:StructuralFeature.type> ::= "UML:DataType"

18 <UML:Association> ::= "UML:Association.connection"

19 <UML:Association.connection> ::= "UML:AssociationEnd" "UML:AssociationEnd.participant"

20 "UML:AssociationEnd.multiplicity"

21 <UML:AssociationEnd> ::= aggregation "=" "’" valor "’"

22 <UML:AssociationEnd.participant> ::= "UML:Class"

23 <UML:AssociationEnd.multiplicity> ::= "UML:Multiplicity.range"

24 <UML:Multiplicity.range> ::= UML:MultiplicityRange

25 <UML:MultiplicityRange> ::= lower "=" "’" valor "’" upper "=" "’" valor "’"

Para auxiliar a extracao de dados relevantes do XML, foi utilizado o pacote

padrao do Python, o xml.dom.minidom. Com ele foi possıvel tratar os nomes de

tags e diferencas entre os atributos das mesmas. Embora existam outros parsers

31

XML escritos em Python, como por exemplo o ElementTree2 e o BeautifulSoup3 o

pacote padrao da linguagem foi o escolhido. A justificativa desta escolha se deve

ao fato do pacote padrao ja fazer parte da distribuicao atual do Python, sendo

assim, o sistema tende a manter uma maior compatibilidade com futuras versoes do

interpretador.

4.4.1 Extracao do XML

A extracao dos dados e feita atraves do pacote xml.dom.minidom, como referido

acima, uma implementacao mais leve da interface DOM4. E uma implementacao

mais simples que o DOM padrao e significativamente menor. O Minidom analiza

o codigo no arquivo XML e cria a estrutura DOM, sendo esta mais facil para ma-

nipulacao dos itens dos arquivos XML. Uma vez tendo o objeto DOM, e possivel

acessar partes de seu documento XML atraves das suas propriedades e metodos.

Estas propriedades sao definidas na especificacao DOM5. A principal propriedade

do objeto e a documentElement, responsavel pela extracao das tags expecıficas do

XML. O exemplo pode ser visto abaixo:

>>> from xml.dom import minidom

>>> dom = minidom.parseString("<myxml>Some data</myxml>")

>>> dom.documentElement.nodeValue

>>> print dom.documentElement.tagName

u’myxml’

Tambem foi criada uma funcao em Python chamada finditem com a finalidade

de buscar e retornar uma lista de itens-filho, de uma tag expecıfica, de acordo com

o nome enviado por parametro:

1 def findItem(raiz,item):

2 return [x for x in raiz.childNodes if x.nodeName == item]

A busca dos elementos principais do diagrama (classes, tags, tipo de dados e

associacoes) e feita atraves do item raiz (UML:Namespace.ownedElement):



3

4 raiz = doc.documentElement.getElementsByTagName(’UML:Namespace.ownedElement’)[0] #elemento raiz

5

6 xmi_tipos = findItem(raiz,"UML:DataType") #lista de tipos

7 lst_tipos = TipoDados(xmi_tipos)

8

2http://effbot.org/zone/element-index.htm3http://www.crummy.com/software/BeautifulSoup/4Document Object Model interface5http://www.w3.org/DOM/

32

9 xmi_tags = findItem(raiz,"UML:TagDefinition") #valores marcados

10 lst_tags = TipoTags(xmi_tags)

11

12 xmi_classes = findItem(raiz,"UML:Class") #lista de classes

13 xmi_associacoes = findItem(raiz,"UML:Association") #lista de associac~oes

14 xmi_herancas = findItem(raiz,"UML:Generalization") #lista de herancas

15 classes = ListaClasses(xmi_classes,lst_tipos,lst_tags,xmi_associacoes,xmi_herancas)

Para cada classe encontrada no XMI, e feita a extracao do nome de identificador

da classe e tambem e realizada a busca dos atributos da mesma.



3

4 for classe in xmi_classes:

5 nome = classe.attributes.get(’name’).value

6 container = findItem(classe,’UML:Classifier.feature’)[0]

7 xmi_atributos = findItem(container,’UML:Attribute’)

A cada atributo encontrado, e extraıdo o nome e o identificador do tipo do

atributo. O nome do tipo do atributo e buscado na lista de tipos, extraıda anteri-

ormente:

1 xmi_atributos = findItem(container,’UML:Attribute’)

2 for att in xmi_atributos:

3 container_tipo = findItem(att,’UML:StructuralFeature.type’)[0]

4 container_tipo2 = findItem(container_tipo,’UML:DataType’)[0]

5 nome = att.attributes.get(’name’).value

6 valor= lst_tipos.get_nome(container_tipo2.attributes.get(’xmi.idref’).value)

4.5 Analise semantica

A traducao para codigo Django, utiliza uma estrutura intermediaria de dados,

utilizando programacao orientada a objeto escrita em Python, para assim gerar o

codigo Django. A figura 4.5 representa o diagrama desta estrutura intermediaria.

De acordo com os dados contidos no arquivo XML, e feita a busca de elementos

e extraıdo os dados relevantes. Estes dados sao armazenadas em forma de objetos

python de acordo com a Figura 4.5. Quando a leitura estiver completa, os objetos

python sao lidos e escritos na tela, ja no padrao de modelagem da camada Model do

Django.

4.5.1 Algoritmo de geracao

A geracao das classes e realizada atraves da busca das classes do objeto Klasse

(Figura 4.5), onde o objeto possui uma variavel que informa se a classe herda de

outra ou nao, pois o codigo traduzido de uma classe herdada e diferente.

33

Figura 4.2: Diagrama de classes do sistema

1 for cl in self.classes.lista:

2 if cl.herda_de:

3 yield ’class %s(%s):’ % (cl.nome,cl.herda_de)

4 else:

5 yield ’class %s(models.Model):’ % cl.nome

Para cada classe, e verificado se a mesma possui atributos, cada atributo e escrito

como uma variavel da classe recebendo como valor, o tipo de campo Field do Django.

E verificado tambem se o atributo possui valores marcados, se possuir, estes sao

escritos como parametros do Field.

1 yield ’class %s(models.Model):’ % cl.nome

2 for att in cl.atributos:

3 extra = ""

4 if len(att.extras):

5 for ex in att.extras:

6 extra+="%s=%s," %(ex[’nome’],ex[’valor’])

7 yield ’ %s = models.%s(%s)’ % (att.nome, att.valor,extra[:-1])

As Associacoes da classe sao geradas de forma semelhante aos atributos, pois sao

escritas tambem como variaveis da classe. Alem da verificacao de valore marcados,

e verificado o tipo de cardinalidade. Se a cardinalidade for “um para muitos” (1:n)

e gerado um campo ForeignKey, se for uma relacao “muitos para muitos” (n:n) e

gerado um campo ManyToMany.

1 for rel in cl.associacoes:

2 extra = ""

34

3 if len(rel.extras):

4 for ex in rel.extras:

5 extra+=", %s=’%s’" %(ex[’nome’],ex[’valor’])

6 if rel.cardinalidade[0] == ’*’ and rel.cardinalidade[1] == ’*’:

7 yield ’ %s = models.ManyToManyField(%s%s)’ % \

8 (str.lower(str(rel.classe)), rel.classe, extra)

9 for rel in cl.associacoes:

10 extra = ""

11 if len(rel.extras):

12 for ex in rel.extras:

13 extra+=", %s=’%s’" %(ex[’nome’],ex[’valor’])

14 if rel.cardinalidade[0] == ’*’ and rel.cardinalidade[1] == ’*’:

15 yield ’ %s = models.ManyToManyField(%s%s)’ % \


17 else:

18 yield ’ %s = models.ForeignKey(%s%s)’ % \


35

5 EXPERIMENTOS E RESULTADOS

As classes criadas pelo Parser, foram testadas no Django. Foram criados diversos

diagramas, contendo uma grande variedade de tipos de dados, atributos, agregacoes

e heranca. Em todos os casos abaixo foram gerados codigos, sendo estes perfeita-

mente aplicados no framework.

5.1 Diagramas com uma Classe

Primeiro teste feito com o Parser, e o mais simples, verifica a classe “Pessoa”

contida no XML e lista os atributos (nome) e (nascimento), conforme a figura 5.1.

Figura 5.1: UML Representando uma classe

O codigo gerado corresponde a Classe do Django com o nome “Pessoa” e com

as variaveis (nome) e (nascimento) representando seus atributos, conforme o quadro

abaixo:

1 # coding: utf-8

2 # Este ~A c© um modulo de auto gera~A§~A£o de classes django.

3

4 from django.db import models

5


7 nome = models.CharField(max_length=15)


5.2 Diagramas com duas Classes sem relacionamento

Basicamente o mesmo teste que o anterior, criado para testar varias classes. Nele

sao geradas duas classes, a classe “Cidade”, com um atributo (nome) e a Classe

“Estado” com dois atributos (nome) e (zona)

36

Figura 5.2: UML Representando duas classes sem relacionamento

O codigo gerado contem duas classes Django com os nomes “Cidade” e “Estado”.

A classe “Cidade” possui o atributo (nome) e a classe “Estado” possui os atributos

(nome) e (zona), conforme o quadro abaixo:

1 ## coding: utf-8


3


5

6 class Cidade(models.Model):


8

9 class Estado(models.Model):


11 zona = models.CharField(max_length=2)

5.3 Diagramas com duas Classes relacionadas

O mesmo teste que o anterior, agora testando associacoes entre classes. Neste

caso foi utilizado um relacionamento 1:n, este relacionamento e representado pelo

atributo do tipo ForeignKey da classe Django

Figura 5.3: UML representando duas classes relacionadas

Neste caso o codigo gerado e semelhante ao do teste 5.2, mas, como pode ser

visto na linha 12, foi acrescentado uma variavel do tipo ForeignKey representando

um relacionamento.

1 ## coding: utf-8


3


5

37



8



11 zona = models.CharField(max_length=2)

12 cidade = models.ForeignKey(Cidade)

5.4 Teste de Heranca

O teste abaixo foi realizado para representar as herancas de classes Django. Sao

representadas tres classes, uma classe principal chamada “Pessoa”, e outras duas

classes que descendem da classe anterior, “Fisica” e “Jurıdica”.

Figura 5.4: UML representando heranca

No codigo gerado, o parser gerou a Classe “Pessoa” herdando da classe Django

e as classes “Fisica” e “Jurıdica” herdando de “Pessoa”.

1 # coding: utf-8


3


5



8

9 class Fisica(Pessoa):

10 cpf = models.IntegerField()

11

12 class Juridica(Pessoa):

13 cnpj = models.IntegerField()

38

5.5 Teste multiplo

Este exemplo ilustra um sistema real, contendo varias classes e varios tipos de

campos e associacoes.

Figura 5.5: Uml representando varias classes

O codigo gerado pode ser visto no quadro a seguir:

1 # coding: utf-8


3


5



8 zona = models.IntegerField()

9

10 class Usuario(models.Model):

11 username = models.CharField(max_length=10)

12 password = models.CharField(max_length=20)

13



16 estado = models.ForeignKey(Estado)

17



20 cidade = models.ForeignKey(Cidade)

21 usuario = models.ForeignKey(Usuario, unique=’True’)

39

22 fotos = models.ManyToManyField(Fotos)

23

24 class Fotos(models.Model):

25 foto = models.ImageField(upload_to=’/upload/teste/’)

26 data = models.DateField(auto_now_add=True)

27

28 class PessoaFisica(Pessoa):

29 rg = models.IntegerField()


31

32 class PessoaJuridica(Pessoa):

33 cnpj = models.IntegerField()

34

40

6 CONCLUSAO

6.1 Validacao do projeto

O principal objetivo deste trabalho foi alcancado. O objetivo central de gerar

uma classe Django a partir de um diagrama de classes foi completamente atingido.

Praticamente todos os elementos Model que o Django suporta (Classes, atributos,

Valores de atributos, Chaves estrangeiras, relacionamentos N:N e heranca) foram

extraidos com sucesso.

Com a utilizacao do gerador de codigo, a criacao da camada logica do sistema

ficou muito mais facil de ser desenvolvida, pois agora o usuario possui uma visua-

lizacao grafica de todo o sistema, facilitando a visualizacao da estrutura do sistema

a ser desenvolvido.

Apesar do sistema conseguir extrair perfeitamente os dados do XMI, os testes

mais profundos da ferramenta foram feitos utilizando o modelador ArgoUML, por

isso, a compatibilidade com outros modeladores, como por exemplo o Umbrello, nao

esta completamente garantida.

6.2 Trabalhos Futuros

A intencao e que os trabalhos com o parser possam continuar, atraves da criacao

de outros testes utilizando diferentes modeladores UML e comparando seu resultado

com o desenvolvido ate o momento.

Ha interesse em disponibilizar o parser como software livre, tendo como principal

meta, a evolucao do sistema adicionando novas funcoes, melhorias de performance

no codigo e no gerador, uma atualizacao do mesmo com possıveis mudancas da

estrutura de modelagem do framework Django

Atualmente ha uma projeto de implementacao de maquina de workflow em

django chamado GoFlow 1. Uma das possibilidades de trabalho futuro, seria a

integracao de diagramas de estados com uma maquina de workflow. A proposta se-

ria de a partir de diagramas de estado serem gerados rotinas de workflow, da mesma

1http://code.google.com/p/goflow/

41

forma que hoje sao geradas classes a partir de diagramas de classe.

42

7 ANEXOS

1 <?xml version = ’1.0’ encoding = ’UTF-8’ ?>

2 <XMI xmi.version = ’1.2’ xmlns:UML = ’org.omg.xmi.namespace.UML’ timestamp = ’Tue Sep 09 13:16:17 BRT 2008’>

3 <XMI.header> <XMI.documentation>

4 <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0)</XMI.exporter>

5 <XMI.exporterVersion>0.24(5) revised on $Date: 2006-11-06 19:55:22 +0100 (Mon, 06 Nov 2006) $ </XMI.exporterVersion>

6 </XMI.documentation>

7 <XMI.metamodel xmi.name="UML" xmi.version="1.4"/></XMI.header>

8 <XMI.content>

9 <UML:Model xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077B’

10 name = ’untitledModel’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’

11 isAbstract = ’false’>


13 <UML:Class xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077C’

14 name = ’Cidade’ visibility = ’public’ isSpecification = ’false’ isRoot = ’false’



17 <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077F’



20 <UML:StructuralFeature.multiplicity>

21 <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007BF’>


23 <UML:MultiplicityRange xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007BE’

24 lower = ’1’ upper = ’1’/>



27 </UML:StructuralFeature.multiplicity>




31 </UML:Attribute>


33 </UML:Class>


35 name = ’CharField’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’



38 name = ’IntegerField’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’


40 <UML:Class xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000792’

41 name = ’Estado’ visibility = ’public’ isSpecification = ’false’ isRoot = ’false’



44 <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000795’


43





50 <UML:MultiplicityRange xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C0’

51 lower = ’1’ upper = ’1’/>







58 </UML:Attribute>

59 <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007AF’

60 name = ’zona’ visibility = ’public’ isSpecification = ’false’ ownerScope = ’instance’



63 <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007BD’>


65 <UML:MultiplicityRange xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007BC’

66 lower = ’1’ upper = ’1’/>







73 </UML:Attribute>


75 </UML:Class>

76 <UML:Association xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C2’

77 name = ’’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’>

78 <UML:Association.connection>



81 aggregation = ’composite’ targetScope = ’instance’ changeability = ’changeable’>





86 lower = ’1’ upper = ’1’/>





91 <UML:Class xmi.idref = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077C’/>





96 aggregation = ’none’ targetScope = ’instance’ changeability = ’changeable’>


98 <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007CA’>



101 lower = ’1’ upper = ’-1’/>




44


106 <UML:Class xmi.idref = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000792’/>



109 </UML:Association.connection>

110 </UML:Association>


112 </UML:Model>

113 </XMI.content>

114 </XMI>

45

REFERENCIAS

BEZERRA, E. Princıpios de Analise e Projeto de Sistemas com Uml. [S.l.]:

Campus, 2007.

DJANGO. Django — the web framework for perfectionists with deadlines.

http://www.djangoproject.com/.

LEFF AVRAHAM; RAYFIELD, J. T. Web-Application Development using the Mo-

del/View/Controller Design Pattern. , v.1, n.1, 2001.

MAURER, I. Python Web Frameworks, part 1: Develop for the Web with Django

and Python. , v.1, n.1, july 2006.

OMG. Object manager group - MOF 2.0/XMI Mapping, Version 2.1.1. , v.1, n.1,

2007.

TCC

Documents

Transcript of TCC