Tcc

UNIVERSIDADE DE CAXIAS DO SUL ´ DEPARTAMENTO DE INFORMATICA ˆ ˜ CURSO DE BACHARELADO EM CIENCIA DA COMPUTAC ¸ AO

MARCOS D. PETRY

UML2Django: Gerador de C´ odigo para Framework Web MVC

Prof. Jo˜ao 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

Agrade¸co a Deus por ter me dado for¸cas para concluir este curso, me revitalizando em todos os momentos de fraqueza. Aos meus pais Ivan Luiz e Iana F´atima, por me entenderem a minha ausˆencia devido ao trabalho e aos estudo, n˜ao deixaram de estar do meu lado me apoiado incondicionalmente. Ao meu orientador, Professor Jo˜ao Luiz Tavares, pela paciˆencia, sabedoria, pelas suas corre¸co˜es e incentivo durante a implementa¸c˜ao do trabalho e reda¸ca˜o da monografia. A Universidade de Caxias do Sul, e ao docentes do departamento de inform´atica, que durante os 7 anos de vida acadˆemica nesta institui¸c˜ao, tive a honra de ser aluno. Aos meus colegas de trabalho, que me ajudaram-me com meu TCC e na minha carreira profissioal. Agrade¸co aos amigos de minha cidade natal que me apoiaram em momentos que precisei e me mostrando que a vida n˜ao ´e s´o trabalho e estudo. Aos amigos que fiz na Universidade: Joel, Alexandre, Fran, Vin´ıcius, Cristian, Enor e muitos outros, por acompanharem minha trajet´oria acadˆemica, e estarem presentes em momentos complicados. E por u ´ltimo, mas n˜ao menos importante, agrade¸co 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 1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

˜ INTRODUC ¸ AO

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 11

1.1

Motiva¸c˜ ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2

Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3

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

2

CONCEITOS PRELIMINARES . . . . . . . . . . . . . . . . . . . . . .

15

2.1

Padr˜ ao de desenvolvimento MVC . . . . . . . . . . . . . . . . . . . 15

2.2

Ferramentas Gr´ aficas de Modelagem . . . . . . . . . . . . . . . . . 16

2.3

UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 2.4

Frameworks de desenvolvimento de aplica¸co ˜es . . . . . . . . . . . 18

2.4.1 2.5

Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Linguagem de programa¸c˜ ao Python . . . . . . . . . . . . . . . . . 19

2.5.1 3

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

Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

DJANGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1

21

Caracter´ısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1

Persistˆencia de dados (model) . . . . . . . . . . . . . . . . . . . . . . 22

3.1.2

Visualiza¸ca˜o de dados (view) . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.3

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

3.2

Fluxo de Execu¸c˜ ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

˜ . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 IMPLEMENTAC ¸ AO 4.1 Arquitetura geral da implementa¸c˜ ao proposta . . . . . . . . . . 4.2 Parˆ ametros XMI utilizados pelo Parser . . . . . . . . . . . . . . 4.3 Mapeamento de objetos XMI - Django Model . . . . . . . . . . 4.4 An´ alise l´ exico-sint´ atica . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Extra¸ca˜o do XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 An´ alise semˆ antica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Algoritmo de gera¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

25 25 25 29 29 31 32 32

5 EXPERIMENTOS E RESULTADOS . . . . . . . . . . . . . . . . . . 5.1 Diagramas com uma Classe . . . . . . . . . . . . . . . . . . . . . 5.2 Diagramas com duas Classes sem relacionamento . . . . . . . . 5.3 Diagramas com duas Classes relacionadas . . . . . . . . . . . . 5.4 Teste de Heran¸ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Teste m´ ultiplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

35 35 35 36 37 38

˜ 6 CONCLUSAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.1 Valida¸c˜ ao do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7

ANEXOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

ˆ REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

LISTA DE ABREVIATURAS E SIGLAS

DRY

Don’t repeat yourself

GLC

Gram´atica 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 Conclus˜ao 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 Execu¸c˜ao do Framework Django . . . . . . . . . . . . . 24 Figura 4.1: Estrutura do parser XMI2Django . . . . . . . . . . . . . . . . . . 26 Figura 4.2: Diagrama de classes do sistema . . . . . . . . . . . . . . . . . . . 33 Figura Figura Figura Figura Figura

5.1: 5.2: 5.3: 5.4: 5.5:

UML Representando uma classe . . . . . . . . . . . . UML Representando duas classes sem relacionamento UML representando duas classes relacionadas . . . . UML representando heran¸ca . . . . . . . . . . . . . . Uml representando v´arias classes . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

35 36 36 37 38

LISTA DE TABELAS

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

RESUMO

O desenvolvimento de aplica¸c˜oes WEB cresce contantemente e, como conseq¨ uˆencia disso, os recursos e as funcionalidades destas aplica¸c˜oes evolui. Portanto, desenvolver aplica¸co˜es 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 aplica¸co˜es ´e utilizando frameworks de desenvolvimento. Utilizando frameworks, o desenvolvedor pode focar-se de fato, no objetivo principal do sistema, evitando assim, o trabalho repetitivo de outras aplica¸c˜oes, como por exemplo a constru¸c˜ao 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 r´apido. Apesar de suas in´ umeras facilidades, o Django n˜ao possui uma ferramenta de gera¸c˜ao autom´atica de c´odigo a partir de diagramas gr´aficos de modelagem, por exemplo. Esta funcionalidade auxiliaria muito os desenvolvedores que, atualmente, precisam descrever manualmente a camada de modelagem, dificultando tamb´em a documenta¸ca˜o estruturada, como por exemplo atrav´es de diagrama de classes e padroniza¸co˜es ao estilo UML. Focado nestas limita¸co˜es, inerentes a qualquer ferramenta de software livre que inicia sua evolu¸ca˜o no meio da produ¸ca˜o de aplica¸co˜es, este trabalho prop˜oe uma ferramenta 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 r´apida e f´acil, ao mesmo tempo que mant´em a documenta¸ca˜o de classes de seu sistema.

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

UML2Django: a code generator for Web MVC Framework

ABSTRACT

The development of the WEB applications grows constantly, and, as a consequence 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 quality of the applications. Using frameworks, the developer can actually be focused on the main objective of the system, preventing some repetitive work on other applications, 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

˜ INTRODUC ¸ AO

1

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 desej´avel para programadores e empresas. V´arios requisitos, padr˜oes e t´ecnicas s˜ao criados diariamente, com a finalidade de aumentar a produ¸c˜ao e melhorar o processo de constru¸ca˜o de sistemas. Como resultado, foram criados diversas ferramentas e frameworks, v´arios processos e rotinas repetitivas foram automatizados por eles e o tempo gasto no processo de implementa¸c˜ao de fato diminuiu. Em geral, um Framework, assim como web frameworks, proporcionam uma infraestrutura de programa¸ca˜o para aplica¸c˜oes, de forma que o projetista possa se concentrar na escrita de c´odigo eficiente e de f´acil manuten¸ca˜o. Mas ainda h´a diversos pontos a melhorar, ou pelo menos para facilitar o processo de produ¸ca˜o de c´odigo de forma automatizada, como por exemplo gera¸c˜ao autom´atica de c´odigo nativo de um framework a partir do esquema de um diagrama de classes. Os frameworks utilizados atualmente, seguem o padr˜ao MVC (LEFF AVRAHAM; RAYFIELD, 2001), que ´e um padr˜ao de arquitetura de aplica¸c˜oes que visa separar a l´ogica da aplica¸c˜ao (Model), da interface do usu´ario (View) e do fluxo da aplica¸ca˜o (Controller). O uso deste tipo de framework permite que a mesma l´ogica de neg´ocios possa ser acessada e visualizada por v´arias interfaces. Neste trabalho adotamos o framework Django1 (MAURER, 2006), que utiliza o padr˜ao MVC e tamb´em sua arquitetura de desenvolvimento estimula o desenvolvedor a aproveitar ao m´aximo o c´odigo j´a feito, evitando a repeti¸c˜ao. Como o objetivo de melhorar o processo de desenvolvimento com Django, este trabalho prop˜oe-se a gerar camada Model do framework Django, atrav´es de c´odigos XML’s gerados por editores de diagramas de classe, permitindo assim al´em de aumentar a velocidade de desenvolvimento de aplica¸c˜oes, a gera¸ca˜o e documenta¸ca˜o b´asica do sistema. 1

http://www.djangoproject.com/

12

1.1

Motiva¸ c˜ ao

O Framework escolhido, o Django, recentemente ganhou bastante notoriedade no mundo do software livre, devido a sua praticidade no desenvolvimento de aplica¸c˜oes, foi adotado em diversas empresas e institui¸co˜es, como por exemplo o Google, Governo Brasileiro e a Universidade de Caxias do Sul. Django ´e um framework web de alto n´ıvel escrito em Python que estimula o desenvolvimento r´apido e limpo, concentrando-se no m´aximo de automatiza¸ca˜o poss´ıvel, aderindo ao princ´ıpio DRY (Don’t repeat yourself). Eliminando processos repetitivos como cria¸ca˜o e autentica¸ca˜o de formul´arios e tamb´em a gera¸ca˜o autom´atica de interface de administra¸ca˜o, mecanismos de cache e internacionaliza¸ca˜o. Atualmente, o desenvolvimento de aplica¸co˜es em Django n˜ao possui nenhuma ferramenta que gere c´odigo a partir de ferramentas de modelagem, a camada de modelagem ´e escrita manualmente. Desse modo, se a equipe necessitar de algum tipo de documenta¸ca˜o, como por exemplo um diagrama de classes, ela ter´a que repetir o processo de constru¸c˜ao.

1.2

Objetivos

O objetivo principal deste trabalho ´e o desenvolvimento de uma ferramenta para a gera¸ca˜o autom´atica de c´odigo Python a partir da modeliza¸ca˜o de diagramas gerados por ferramentas de modelagem UML. Esta ferramenta visa o aumento de produtividade e tamb´em a diminui¸ca˜o da possibilidade de erros de codifica¸c˜ao. Nesta proposta, trataremos da implementa¸c˜ao 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 cria¸ca˜o de modelos UML. Basicamente o processo desta gera¸ca˜o segue os seguintes passos: 1. Constru¸c˜ao dos diagramas de classes em uma interface gr´afica (ex. ArgoUML, Umbrello), Por exemplo, o projeto de um diagrama de classes com seus respectivos componentes para defini¸ca˜o de atributos, relacionamentos, cardinalidades, etc, conforme a Figura 1, abaixo:

Figura 1.1: Imagem gerada pelo editor UML

13

2. Gera¸c˜ao do script XMI, padr˜ao da OMG (grupo de gerenciamento de objetos) (OMG, 2007), para troca de informa¸c˜oes baseado em XML. O uso mais comum ´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: <XMI xmi.version = ’1.2’ xmlns:UML = ’org.omg.xmi.namespace.UML’ timestamp = ’Tue Sep 09 13:16:17 BRT 2008’> <XMI.header> <XMI.documentation> <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0) <XMI.exporterVersion>0.24(5) revised on $Date: 2006-11-06 19:55:22 +0100 (Mon, 06 Nov 2006) $   &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;nbsp; <XMI.metamodel xmi.name="UML" xmi.version="1.4"/> <XMI.content> . . .

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

3. Tratamento das informa¸c˜oes do XML e gera¸ca˜o de c´odigo no padr˜ao do framework Django. O diagrama exemplificado na Figura 1 dever´a produzir o seguinte c´odigo Python no framework Django: class Pessoa_Email(models.Model): endereco = EmailField()

1 2 3

class Pessoa(models.Model): nome = models.CharField() cidade = models.CharField() nascimento = models.DateField() enviar_mail = models.BooleanField() endereco = models.ForeignKey(Pessoa_Email)

4 5 6 7 8 9

1.3

Estrutura do Documento

O presente trabalho est´a dividido em 6 cap´ıtulos:. O cap´ıtulo 1 apresenta uma introdu¸c˜ao do trabalho, bem como a motiva¸ca˜o, os objetivos, ferramentas de apoio e a estrutura do documento. No Cap´ıtulo 2, ser˜ao abordados alguns conceitos preliminares necess´arios para um melhor entendimento trabalho, onde apresentamos o padr˜ao de desenvolvimento

14

MVC, uma introdu¸ca˜o b´asica sobre a linguagem python e frameworks de desenvolvimento. O framework alvo da aplica¸c˜ao, o Django, ser´a apresentado no cap´ıtulo 3, onde ser˜ao descritos detalhes de seus componentes mais usuais e como o padr˜ao 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 gram´atica utilizada para ler estes elementos e o processo de tradu¸ca˜o para a sintaxe da classe Django. O cap´ıtulo 5 ´e destinado a apresentar os testes com o sistema, onde diversos diagramas de classes ser˜ao traduzidos para c´odigo Python do Django atrav´es da ferramenta implementada neste trabalho. O Cap´ıtulo 6 ´e destinado `a aprecia¸ca˜o das conclus˜oes final bem como das alternativas de continuidade e trabalhos futuros da presente proposta.

15

2

CONCEITOS PRELIMINARES

Neste Cap´ıtulo, introduziremos alguns conceitos fundamentais necess´arios ao entendimento dos componentes utilizados no trabalho. Na se¸c˜ao 2.1 apresentamos uma breve introdu¸ca˜o sobre o padr˜ao de desenvolvimento MVC. Introduzimos algumas explica¸co˜es sobre UML na se¸c˜ao 2.2. Na se¸ca˜o 2.3 ser˜ao abordados defini¸c˜oes sofre frameworks. Concluindo o cap´ıtulo, ser´a feita uma breve explica¸ca˜o sobre Python, a linguagem utilizada neste trabalho.

2.1

Padr˜ ao de desenvolvimento MVC

MVC ´e um padr˜ao de arquitetura de aplica¸co˜es que visa separar a l´ogica da aplica¸ca˜o (Model), da interface do usu´ario (View) e do fluxo da aplica¸c˜ao (Controller). Permite que a mesma l´ogica de neg´ocios possa ser acessada e visualizada por v´arias interfaces. O MVC tamb´em ´e utilizado em padr˜oes de projetos de software, entretanto, MVC abrange mais da arquitetura de uma aplica¸ca˜o do que ´e t´ıpico para um padr˜ao de projeto. Em um projeto de software baseado no padr˜ao MVC , define-se uma arquitetura b´asica 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 informa¸co˜es de estado dos controllers, por exemplo; • Controller: Implementa a camada respons´avel pelo gerenciamentos de eventos no projeto, tais como cliques do usu´ario, chamando a camada Model para processar os eventos. Tamb´em pode manter informa¸co˜es de estado do usu´ario na aplica¸ca˜o; • View: Gera a interface com usu´ario de modo que esta somente requisite o processamento de eventos pelo Controller;

16

Segundo (BEZERRA, 2007), Model-view-controller (MVC) ´e um padr˜ao de arquitetura de software. Com o aumento da complexidade das aplica¸co˜es desenvolvidas torna-se fundamental a separa¸ca˜o entre os dados (Model) e o layout (View). Desta forma, altera¸co˜es feitas no layout n˜ao afetam a manipula¸c˜ao de dados, e estes poder˜ao ser reorganizados sem alterar o layout. O model-view-controller resolve este problema atrav´es da separa¸c˜ao das tarefas de acesso aos dados e l´ogica de neg´ocio, l´ogica de apresenta¸ca˜o e de intera¸c˜ao com o utilizador, introduzindo um componente entre os dois: o Controller. MVC ´e usado em padr˜oes de projeto de software, mas MVC abrange mais da arquitetura de uma aplica¸ca˜o do que ´e t´ıpico para um padr˜ao de projeto.”

2.2

Ferramentas Gr´ aficas de Modelagem

A escolha de ferramentas de Gera¸c˜ao de Diagramas de classes foi definida tendo como base dois crit´erios: ser software livre e possuir exporta¸ca˜o para XMI. Foram encontradas as seguintes ferramentas que possuem estes requisitos: ArgoUML1 e Umbrello2 . Umbrello UML Modeller permite a modeliza¸c˜ao de software atrav´es de diagramas UML (Unified Modeling Language) originalmente para o ambiente KDE-Linux, com extens˜oes recentes para Windows e MAC. Umbrello manipula todos os tipos de diagramas UML e ´e capaz de gerar c´odigo para algumas linguagens como Java, C++, Python, PHP, entre outras. No entanto, o c´odigo Python gerado a partir dos diagramas do Umbrello ainda n˜ao s˜ao compat´ıveis com o framework Django, necessitanto algumas adapta¸c˜oes manuais que, dependendo do tamanho do projeto, pode tornar invi´avel sua execu¸c˜ao. 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 padr˜ao e oferece excelentes m´etodos para cria¸ca˜o e manipula¸ca˜o dos seus diagramas em UML. Oferece suporte para gera¸ca˜o de c´odigo Java nativo e outras linguagens (C++, C# e PHP) atrav´es de plugins disponibilizados em seu site. Infelizmente, a exporta¸ca˜o para c´odigo Python est´a somente nos planos de seus desenvolvedores. As ferramentas acima salvam o diagrama no formato padr˜ao XMI (XML Metadata Interchange) (OMG, 2007), que segundo Eduardo Bezerra, define XMI como sendo: ”um padr˜ ao baseado em XML para exportar modelos definidos em UML. Esse padr˜ao ´e importante, pois permite a interoperabilidade 1 2

http://argouml.tigris.org/ http://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 s˜ao suporte ao padr˜ ao 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 gr´aficos que podem ser utilizados na modelagem de sistemas. Esses elementos permitem representar os conceitos de orienta¸c˜ao a objetos atrav´es dos diagramas criados. Seguindo a nota¸ca˜o UML, ´e possivel representar diversas perspectivas do sistema. Ainda segundo (BEZERRA, 2007), cada elemento grafico da UML possui sintaxe e uma semˆantica. A sintaxe de um elemento corresponde a` forma predeterminada de desenhar o elemento. A semˆantica define o que significa o elemento e com que objeto ele deve ser utilizado. Tanto a sintaxe quanto a semˆantica dos elementos s˜ao extens´ıveis. Essa extensibilidade permite que a UML sej´a adaptada a`s caracter´ısticas de cada projeto de desenvolvimento. Embora a UML possua diversos diagramas para representar o sistema (atividades, casos de uso, colabora¸c˜ao, seq¨ uˆencia, entre outros) o sistema desenvolvido utiliza somente diagramas de classe, pois ´e o diagrama mais indicado para o prop´osito do mesmo. 2.3.1

Digramas de Classe

Um diagrama de classes basicamente descreve a estrutura de um sistema, mostrando as classes implantadas, seus atributos, e as rela¸co˜es entre as classes. Cada classe do diagrama possui um conjunto de objetos: Nome da classe, atributos, relacionamentos e m´etodos. 2.3.1.1

Atributos

Defini¸ca˜o 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 liga¸c˜ao entre classes, ´e uma liga¸c˜ao binaria (com duas extremidades) onde cada extremidade ´e ligada a uma classe, atrav´es de uma linha. Existem diferentes tipos de relacionamento: Agrega¸ca˜o, composi¸c˜ao, Heran¸ca.

18

2.3.1.3

M´etodos

M´etodos s˜ao fun¸co˜es requeridas a um objeto ou seja, as a¸co˜es que os objetos de uma classe pode executar.

2.4

Frameworks de desenvolvimento de aplica¸c˜ oes

Estamos em uma ´epoca onde as informa¸co˜es s˜ao recebidas rapidamente, not´ıcias de qualquer parte do mundo chegam a`s pessoas de forma quase instantˆanea. Grande parte dessa informa¸ca˜o ´e veiculada atrav´es da WEB. Para isso o desenvolvimento de aplica¸co˜es web ´e muito explorado. Apesar da quantidade de ferramentas de desenvolvimento ser bastante grande, implementar aplica¸c˜oes para Internet n˜ao ´e algo trivial. Construir uma aplica¸ca˜o web totalmente funcional a algo bastante trabalhoso. Muitas tarefas s˜ao necess´arias para que tal feito seja completo: A Configura¸c˜ao e a cria¸ca˜o de tabelas em base de dados, cria¸c˜ao de consultas e relacionamentos para as mesmas, gera¸ca˜o de c´odigo HTML, mapear as URL para ler os c´odigos, controle de usu´arios, e estes itens s˜ao s´o a parte b´asica do desenvolvimento. O desenvolvimento para WEB ´e muito repetitivo; os passos a serem seguidos s˜ao praticamente os mesmos para cada nova aplica¸ca˜o a ser criada. Como tentativa de minimizar ao m´aximo estes repetitivos passos, foram criadas bibliotecas e frameworks para facilitar o desenvolvimento de aplica¸co˜es, fazendo com que o desenvolvedor focalize basicamente o objetivo do novo sistema, deixando a cargo do framework manter as tarefas mais ma¸cantes. Um framework ´e uma camada de abstra¸c˜ao na qual um determinado conjunto de c´odigos implementa uma certa funcionalidade gen´erica, facilmente customizada ´ fun¸c˜ao do framework pelo usu´ario, criando assim um funcionalidade expecifica. E tamb´em, validar o c´odigo criado pelo usu´ario. Os frameworks para desenvolvimento web geralmente seguem o padr˜ao de arquitetura de sistema MVC para separar as camadas de neg´ocio, persistˆencia e interface. 2.4.1

Exemplos

A maioria das linguagens voltadas para o desenvolvimento WEB posuem frameworks: Ruby possui um dos mais famosos framework WEB da atualidade, o Ruby on Rails 3 . Python possui uma gama consideravel de ferramentas como o

3

http://www.rubyonrails.org

19

Django, TurboGears4 , Pylons5 , Zope6 /Plone7 , web2py8 entre outros. PHP9 que ´e uma das mais utilizadas linguagens para peograma¸ca˜o WEB possui os frameworks CakePHP10 , CodeIgniter11 , Prado12 , symfony13 , Zend14 , entre outros. Perl possui o Catalyst15 , Maypole16 , Jifty17 , e a maioria deles segue o padr˜ao MVC.

2.5

Linguagem de programa¸c˜ ao Python

Python18 ´e uma linguagem de programa¸c˜ao de alto n´ıvel, interpretada, interativa, orientada `a objetos e de tipagem dinˆamica e forte, lan¸cada por Guido van Rossum em 1991. Atualmente possui um modelo de desenvolvimento comunit´ario e aberto gerenciado pela organiza¸ca˜o sem fins lucrativos Python Software Foundation. Apesar de v´arias partes da linguagem possu´ırem padr˜oes e especifica¸co˜es formais, a linguagem como um todo n˜ao ´e formalmente especificada. O padr˜ao de implementa¸c˜ao ´e o CPython, o que significa que foi desenvolvida a partir da linguagem C, mas existe tamb´em as variantes Jython e IronPython que s˜ao reimplementa¸ca˜o do Python produzidas em Java e .NET respectivamente. A linguagem foi projetada com a filosofia de enfatizar a importˆancia do esfor¸co do programador sobre o esfor¸co computacional. Prioriza a legibilidade do c´odigo sobre a velocidade ou expressividade. Combina uma sintaxe concisa e clara com os recursos poderosos de sua biblioteca padr˜ao e por m´odulos e frameworks desenvolvidos por terceiros. 2.5.1

Exemplos

Atrav´es dos exemplo abaixo, ´e possivel verificar a simplicidade da linguagem: 2.5.1.1 1 2 3 4

Fibonacci

a =1 b =1 while a < 800: print a , 4

http://turbogears.org http://pylonshq.com 6 http://www.zope.org 7 http://www.plone.org 8 http://mdp.cti.depaul.edu 9 http://www.php.net 10 http://www.cakephp.org 11 http://codeigniter.com 12 http://www.pradosoft.com 13 http://www.symfony-project.org 14 http://www.zend.com 15 http://www.catalystframework.org 16 http://maypole.perl.org 17 http://jifty.org 18 http://www.python.org 5

20

5

a,b = b,a+b

2.5.1.2 1 2 3 4 5 6 7 8 9 10 11 12

ehprimo = True numero = input ( " Informe o numero : " ) i = 2 while i < numero : if numero % i == 0: ehprimo = False break i += 1 if ehprimo : print " Primo : " , numero else : print numero , ’ possui fator ’ , i

2.5.1.3 1 2 3 4 5 6 7 8 9

N´ umeros Primos

C´alculo de Fatorial

n = int ( raw_input ( " Fatorial de : " )) fatorial = 1 print " % d ! = " %n , i = n while i > 0: fatorial = fatorial * i print " % d " %i , if i != 1: print " . " , i -= 1

21

3

DJANGO

Django (DJANGO, 2008) ´e um framework para desenvolvimento r´apido para web, escrito em Python, que utiliza o padr˜ao 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 c´odigo aberto e foi publicado sob a licen¸ca BSD1 em 2005. O nome Django foi inspirado no m´ usico de jazz Django Reinhardt. Django utiliza o princ´ıpio DRY (Don’t Repeat Yourself), onde faz com que o desenvolvedor aproveite ao m´aximo o c´odigo j´a feito, evitando a repeti¸ca˜o. Na se¸ca˜o 3.1, abordaremos as caracter´ısticas do framework, onde ser˜ao explicados os componentes principais da ferramenta, tais como Controllers, Templates, Models, Middlewares e URLDispacher. Na se¸ca˜o 3.2 ser´a explicado o fluxo de execu¸ca˜o de uma requisi¸ca˜o no Django.

3.1

Caracter´ısticas

Atrav´es do ORM2 do Django ´e definida a modelagem de dados atrav´es 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 tamb´em possibilitam criar formul´arios autom´aticos e gerar uma interface de administra¸c˜ao praticamente completa e facilmente configur´avel e extens´ıvel, aumentando ainda mais o desenvolvimento das aplica¸c˜oes. O Django possui uma linguagem de templates muito extens´ıvel e amig´avel. Atrav´es dela ´e possivel fazer a separa¸ca˜o de design, conte´ udo e c´odigo Python. A figura 3.1 ilustra a estrutura global do Django, exibindo a liga¸ca˜o entre os componentes principais do framework. Os componentes est˜ao classificados em cores, representando as camadas do sistema. 1 2

http://www.opensource.org/licenses/bsd-license.php Object-Relational Mapping

22

Figura 3.1: Estrutura do framework Django 3.1.1

Persistˆ encia de dados (model)

A Classe de Modelagem ´e basicamente, a fonte de todos os registros no projeto. Ele cont´em todos os campos essenciais e rela¸co˜es de tudo que ´e armazenado no Banco de dados. Geralmente, cada modelo mapeia uma u ´nica tabela de dados. 3.1.2

Visualiza¸c˜ ao de dados (view)

. A visualiza¸ca˜o dos dados pelos usu´arios ´e feita atrav´es das views e dos templates. S˜ao atrav´es deles que os dados recebidos pelos models s˜ao manipulados. Os acessos aos dados s˜ao feitos atrav´es das views. As views s˜ao as se¸co˜es do site, onde os dados recebidos pela camada de persistˆencia s˜ao apresentados, criados, editados e deletados por scripts python. Por exemplo, em uma aplica¸ca˜o de um blog, haveriam as seguintes views: • In´ıcio - exibi¸ca˜o das 5 u ´ltimas postagens; • Postagem - p´agina para uma u ´nica entrada; • Postagem-Coment´ario - coment´arios de uma determinada postagem; • Ano-arquivo - exibe todos os meses com as inscri¸co˜es no ano determinado;

23

• Mˆes-arquivo - exibe todos os dias com entradas do mˆes em quest˜ao; • Dia-arquivo - exibe todas as entradas em determinado dia; O sistema de templates do django ´e um m´odulo que visa separar a apresenta¸c˜ao dos dados l´ogicos do site. O Template define certos espa¸cos onde s˜ao definidos la¸cos de repeti¸co˜es, condicionais e outras funcionalidades do django para manipular vari´aveis passadas pela view. Normalmente, os templates s˜ao utilizados para produzir documento HTML, mas os templates do Django s˜ao capazes de gerar qualquer formato de tipo texto tamb´em. 3.1.3

Controle de dados (Controller)

Entre a camada de visualiza¸ca˜o e o usu´ario, h´a a camada de controle, respons´avel pelo processamento de a¸co˜es de requisi¸co˜es e resposta do usu´ario (HTTP Request e HTTP Response). Para realizar este processamento o Django conta com Middlewares e Url Dispatcher. As middlewares s˜ao trechos de c´odigo que analisam requisi¸co˜es feitas pelo usu´ario. Atrav´es dele ´e poss´ıvel enviar informa¸c˜oes para view de forma transparente ao usu´ario como, por exemplo, detalhes sobre se¸co˜es e autentica¸ca˜o. Depois de passar pelos middlewares, a requisi¸ca˜o ´e analisada pelo URL Dispatcher, que verifica o endere¸co que o usu´ario acessa e verifica se o mesmo consta no arquivo de URLs da aplica¸ca˜o. Cada URL est´a associada a uma view, se a URL requisitada n˜ao se encontra no arquivo um erro do tipo 4043 ´e informado.

3.2

Fluxo de Execu¸ c˜ ao

Atrav´es de um browser, o usu´ario faz uma requisi¸ca˜o a um site Django, de acordo com a URL informada. O Framework verifica se a mesma est´a nos seus registros de URL. Ap´os a localiza¸c˜ao da URL, uma view correspondente ´e invocada, a view requisita informa¸co˜es `a classe de modelagem que devolve os dados. Com os dados recebidos da classe de modelagem, o Django armazena em vari´aveis e envia para um template. O template recebe as vari´aveis da view e renderiza o template no formato desejado (HTML, PDF). A p´agina renderizada ´e exibida na tela para o usu´ario. O processo detalhado pode ser visto na Figura 3.2.

3

404 Error. The Page Was Not Found

24

Figura 3.2: Fluxo de Execu¸ca˜o do Framework Django

25

4

˜ IMPLEMENTAC ¸ AO

Neste Cap´ıtulo abordamos a implementa¸ca˜o da proposta de gera¸ca˜o de c´odigo python no framework Django a partir de modelos de diagramas de classes. Na se¸c˜ao 4.1 introduzimos a arquitetura geral do sistema proposto, mostrando seus componentes principais e seus relacionamentos. Na se¸ca˜o 4.2 mostramos a delimita¸ca˜o do escopo dos elementos XMI tratados pelo nosso gerador.

4.1

Arquitetura geral da implementa¸c˜ ao proposta

A implementa¸ca˜o do Parser XMI-DjangoModel foi feita inteiramente utilizando Python, a mesma linguagem do Framework web Django. N˜ao foi definida nenhuma interface gr´afica, pois n˜ao h´a necessidade para tal. Basicamente o script recebe como parˆametro 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 gr´aficos UML possuem um m´etodo de exporta¸ca˜o em arquivo texto para que os diagramas criados possam ser acessados em outro modelador. O m´etodo que resulta este texto, est´a escrito em padr˜ao XMI, um formato definido pela OMG para representa¸ca˜o, intercˆambio e compartilhamento de objetos, modelos e meta-modelos utilizando XML. Teoricamente, os dados XMI exportados em um modelador, dever˜ao ser lidos em outro sem maiores problemas, logo o parser do trabalho em quest˜ao, ir´a gerar o c´odigo Django independente da ferramenta de modelagem UML utilizada, desde que ele exporte o arquivo XMI

4.2

Parˆ ametros XMI utilizados pelo Parser

Boa parte das tags contidas no XML gerado pelo editor UML n˜ao s˜ao utilizadas no parser, pois muitas delas s˜ao geradas com a finalidade de exporta¸co˜es para outros aplicativos (como por exemplo, outro editor UML). No trabalho em quest˜ao s˜ao utilizadas, para uma gera¸ca˜o 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 quest˜ao est˜ao 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 cont´em a tag UML:Attribute; • UML:Attribute Atributos da classe (name, xmi.id); • UML:ModelElement.taggedValue Tag XMI que cont´em a tag XML:TaggedValue; • UML:TaggedValue Lista de valores marcados;

27

• UML:TaggedValue.type Tag XMI que cont´em 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 cont´em a tag UML:DataType; • UML:DataType Um apontador para um tipo de dado (xmi.idref); • UML:Association Lista de associa¸co˜es entre classes; • UML:Association.connection Tag XMI que cont´em a tag UML:AssociationEnd; • UML:AssociationEnd Tipo de associa¸ca˜o (Composi¸c˜ao, agrega¸ca˜o, heran¸ca) (aggregation); • UML:AssociationEnd.participant Lista de objetos participantes da associa¸ca˜o, para o parser, ele trata apenas classes; • UML:Class Um apontador para a classe (xmi.idref); • UML:AssociationEnd.multiplicity Tag XMI que cont´em a tag UML:Multiplicity; • UML:Multiplicity Tag XMI que cont´em a tag UML:Multiplicity.range; • UML:Multiplicity.range Tag XMI que cont´em a tag UML:MultiplicityRange; • UML:MultiplicityRange Multiplicidade da associa¸c˜ao (1 para n, 1 para 1) (lower, upper );

28

• UML:TagDefinition Nome do Valor Marcado (name, xmi.id). Abaixo est´a parte do c´odigo XMI gerado pelo editor UML que ´e utilizado pelo parser. Nele est´a modelado o diagrama UML apresentado no cap´ıtulo de Introdu¸c˜ao. 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 c´odigo inteiro est´a nos anexos: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47



29

48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78

  

4.3

Mapeamento de objetos XMI - Django Model

O gerador proposto tem como objetivo traduzir elementos XMI em c´odigo Python segundo o framework Django. A Tabela 4.1 ilustra os componentes (tags) XMI considerados e sua respectiva tradu¸ca˜o no framework Django. Cada linha da tabela poder´a ser gerada por uma ou v´arias regras de produ¸ca˜o gramaticais aliadas `a regras semˆanticas para gera¸ca˜o de c´odigo Python.

4.4

An´ alise l´ exico-sint´ atica

O parser considerado neste projeto ´e um top-down descendente para gram´aticas do tipo LL1 . Considerando o escopo delimitado na se¸ca˜o 2.2, a gram´atica livre-decontexto (GLC) definida aqui compreende apenas a gera¸c˜ao de produ¸c˜oes relativas aos componentes de representa¸ca˜o de Classe, atributos e relacionamentos do padr˜ao XMI. Para tanto, limitamos nossa gram´atica a estas tags espec´ıficas. Al´em disso, n˜ao foi criada nenhuma valida¸ca˜o da sintaxe do XMI, pois, partimos do pressuposto 1

Left-to-Right, Leftmost derivation com lookahead. Para isto, a gram´atica livre-de-contexto deve estar livre de recurs˜ ao a esquerda e deve estar fatorada.

30

Tag XMI UML:Class UML:Attribute UML:DataType UML:Association, UML:AssociationEnd, UML:AssociationEnd.participant, UML:MultiplicityRange UML:TagDefinition, UML:TaggedValue.type, UML:TaggedValue.dataValue

Django Classe Django Atributo da Classe Django Tipo do atributo Gera¸ca˜o de um atributo da classe Django que representar´a a associa¸c˜ao, seja ela chave Estrangeira ou um mapeamento N para N Parametros utilizados nos atributos da classe

Tabela 4.1: Mapeamento de objetos XMI - Django Model que a mesma esteja correta, pois foi gerada automaticamente atrav´es de um sistema j´a 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 2 3 4 5 6 7

::= ::= name "=" "’" valor "’" xmi.id "=" "’" valor "’" | xmi.idref "=" "’" valor "’" ::= UML:Classifier.feature name "=" "’" valor "’" xmi.id "=" "’" valor "’" | xmi.idref = "valor" ::= UML:Class name "=" "’" valor "’" xmi.id "=" "’" valor "’" ::= UML:Class xmi.idref "=" "’" valor "’"

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

::= :: = UML:ModelElement.taggedValue UML:StructuralFeature.type" name "=" "’" valor "’" xmi.id "=" "’" valor "’" ::= "UML:TaggedValue" :: = "UML:TaggedValue.type" "UML:TaggedValue.dataValue" ::= "UML:TagDefinition" ::= xmi.idref "=" "’" valor "’" ::= name "=" "’" valor "’" ::= "UML:DataType" ::= "UML:Association.connection" ::= "UML:AssociationEnd" "UML:AssociationEnd.participant" "UML:AssociationEnd.multiplicity" ::= aggregation "=" "’" valor "’" ::= "UML:Class" ::= "UML:Multiplicity.range" ::= UML:MultiplicityRange ::= lower "=" "’" valor "’" upper "=" "’" valor "’"

Para auxiliar a extra¸c˜ao de dados relevantes do XML, foi utilizado o pacote padr˜ao do Python, o xml.dom.minidom. Com ele foi poss´ıvel tratar os nomes de tags e diferen¸cas entre os atributos das mesmas. Embora existam outros parsers

31

XML escritos em Python, como por exemplo o ElementTree 2 e o BeautifulSoup 3 o pacote padr˜ao da linguagem foi o escolhido. A justificativa desta escolha se deve ao fato do pacote padr˜ao j´a fazer parte da distribui¸c˜ao atual do Python, sendo assim, o sistema tende a manter uma maior compatibilidade com futuras vers˜oes do interpretador. 4.4.1

Extra¸c˜ ao do XML

A extra¸c˜ao dos dados ´e feita atrav´es do pacote xml.dom.minidom, como referido ´ uma implementa¸ca˜o acima, uma implementa¸c˜ao mais leve da interface DOM4 . E mais simples que o DOM padr˜ao e significativamente menor. O Minidom analiza o c´odigo no arquivo XML e cria a estrutura DOM, sendo esta mais f´acil para manipula¸ca˜o dos itens dos arquivos XML. Uma vez tendo o objeto DOM, ´e possivel acessar partes de seu documento XML atrav´es das suas propriedades e m´etodos. Estas propriedades s˜ao definidas na especifica¸c˜ao DOM5 . A principal propriedade do objeto ´e a documentElement, respons´avel pela extra¸c˜ao das tags expec´ıficas do XML. O exemplo pode ser visto abaixo: >>> from xml.dom import minidom >>> dom = minidom.parseString("<myxml>Some data") >>> dom.documentElement.nodeValue >>> print dom.documentElement.tagName u’myxml’ Tamb´em foi criada uma fun¸c˜ao 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 parˆametro: 1 2

def findItem(raiz,item): return [x for x in raiz.childNodes if x.nodeName == item]

A busca dos elementos principais do diagrama (classes, tags, tipo de dados e associa¸co˜es) ´e feita atrav´es do item raiz (UML:Namespace.ownedElement): 1 2

def findItem(raiz,item): return [x for x in raiz.childNodes if x.nodeName == item]

3 4

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

5

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

6 7 8

2

http://effbot.org/zone/element-index.htm http://www.crummy.com/software/BeautifulSoup/ 4 Document Object Model interface 5 http://www.w3.org/DOM/ 3

32

9 10

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

11 12 13 14 15

xmi_classes = findItem(raiz,"UML:Class") #lista de classes xmi_associacoes = findItem(raiz,"UML:Association") #lista de associa¸ c~ oes xmi_herancas = findItem(raiz,"UML:Generalization") #lista de herancas classes = ListaClasses(xmi_classes,lst_tipos,lst_tags,xmi_associacoes,xmi_herancas)

Para cada classe encontrada no XMI, ´e feita a extra¸ca˜o do nome de identificador da classe e tamb´em ´e realizada a busca dos atributos da mesma. 1 2

def findItem(raiz,item): return [x for x in raiz.childNodes if x.nodeName == item]

3 4 5 6 7

for classe in xmi_classes: nome = classe.attributes.get(’name’).value container = findItem(classe,’UML:Classifier.feature’)[0] 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 anteriormente: 1 2 3 4 5 6

xmi_atributos = findItem(container,’UML:Attribute’) for att in xmi_atributos: container_tipo = findItem(att,’UML:StructuralFeature.type’)[0] container_tipo2 = findItem(container_tipo,’UML:DataType’)[0] nome = att.attributes.get(’name’).value valor= lst_tipos.get_nome(container_tipo2.attributes.get(’xmi.idref’).value)

4.5

An´ alise semˆ antica

A tradu¸c˜ao para c´odigo Django, utiliza uma estrutura intermedi´aria de dados, utilizando programa¸ca˜o orientada a` objeto escrita em Python, para assim gerar o c´odigo Django. A figura 4.5 representa o diagrama desta estrutura intermedi´aria. De acordo com os dados contidos no arquivo XML, ´e feita a busca de elementos e extra´ıdo os dados relevantes. Estes dados s˜ao armazenadas em forma de objetos python de acordo com a Figura 4.5. Quando a leitura estiver completa, os objetos python s˜ao lidos e escritos na tela, j´a no padr˜ao de modelagem da camada Model do Django. 4.5.1

Algoritmo de gera¸c˜ ao

A gera¸ca˜o das classes ´e realizada atrav´es 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 n˜ao, pois o c´odigo traduzido de uma classe herdada ´e diferente.

33

Figura 4.2: Diagrama de classes do sistema

1 2 3 4 5

for cl in self.classes.lista: if cl.herda_de: yield ’class %s(%s):’ % (cl.nome,cl.herda_de) else: yield ’class %s(models.Model):’ % cl.nome

Para cada classe, ´e verificado se a mesma possui atributos, cada atributo ´e escrito como uma vari´avel da classe recebendo como valor, o tipo de campo Field do Django. ´ verificado tamb´em se o atributo possui valores marcados, se possuir, estes s˜ao E escritos como parˆametros do Field. 1 2 3 4 5 6 7

yield ’class %s(models.Model):’ % cl.nome for att in cl.atributos: extra = "" if len(att.extras): for ex in att.extras: extra+="%s=%s," %(ex[’nome’],ex[’valor’]) yield ’ %s = models.%s(%s)’ % (att.nome, att.valor,extra[:-1])

As Associa¸co˜es da classe s˜ao geradas de forma semelhante aos atributos, pois s˜ao escritas tamb´em como vari´aveis da classe. Al´em da verifica¸c˜ao 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 rela¸ca˜o “muitos para muitos” (n:n) ´e gerado um campo ManyToMany. 1 2

for rel in cl.associacoes: extra = ""

34

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

if len(rel.extras): for ex in rel.extras: extra+=", %s=’%s’" %(ex[’nome’],ex[’valor’]) if rel.cardinalidade[0] == ’*’ and rel.cardinalidade[1] == ’*’: yield ’ %s = models.ManyToManyField(%s%s)’ % \ (str.lower(str(rel.classe)), rel.classe, extra) for rel in cl.associacoes: extra = "" if len(rel.extras): for ex in rel.extras: extra+=", %s=’%s’" %(ex[’nome’],ex[’valor’]) if rel.cardinalidade[0] == ’*’ and rel.cardinalidade[1] == ’*’: yield ’ %s = models.ManyToManyField(%s%s)’ % \ (str.lower(str(rel.classe)), rel.classe, extra) else: yield ’ %s = models.ForeignKey(%s%s)’ % \ (str.lower(str(rel.classe)), rel.classe, extra)

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, agrega¸c˜oes e heran¸ca. Em todos os casos abaixo foram gerados c´odigos, sendo estes perfeitamente 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 c´odigo gerado corresponde a Classe do Django com o nome “Pessoa” e com as vari´aveis (nome) e (nascimento) representando seus atributos, conforme o quadro abaixo: 1 2

# coding: utf-8 c um modulo de auto gera~ # Este ~ A A§~ A£o de classes django.

3 4

from django.db import models

5 6 7 8

class Pessoa(models.Model): nome = models.CharField(max_length=15) nascimento = models.DateField()

5.2

Diagramas com duas Classes sem relacionamento

Basicamente o mesmo teste que o anterior, criado para testar v´arias classes. Nele s˜ao 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 c´odigo gerado cont´em 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 2

## coding: utf-8 c um modulo de auto gera~ # Este ~ A A§~ A£o de classes django.

3 4

from django.db import models

5 6 7

class Cidade(models.Model): nome = models.CharField(max_length=15)

8 9 10 11

class Estado(models.Model): nome = models.CharField(max_length=25) zona = models.CharField(max_length=2)

5.3

Diagramas com duas Classes relacionadas

O mesmo teste que o anterior, agora testando associa¸c˜oes 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 c´odigo gerado ´e semelhante ao do teste 5.2, mas, como pode ser visto na linha 12, foi acrescentado uma vari´avel do tipo ForeignKey representando um relacionamento. 1 2

## coding: utf-8 c um modulo de auto gera~ # Este ~ A A§~ A£o de classes django.

3 4 5

from django.db import models

37

6 7

class Cidade(models.Model): nome = models.CharField(max_length=15)

8 9 10 11 12

class Estado(models.Model): nome = models.CharField(max_length=25) zona = models.CharField(max_length=2) cidade = models.ForeignKey(Cidade)

5.4

Teste de Heran¸ ca

O teste abaixo foi realizado para representar as heran¸cas de classes Django. S˜ao representadas trˆes classes, uma classe principal chamada “Pessoa”, e outras duas classes que descendem da classe anterior, “Fisica” e “Jur´ıdica”.

Figura 5.4: UML representando heran¸ca

No c´odigo gerado, o parser gerou a Classe “Pessoa” herdando da classe Django e as classes “Fisica” e “Jur´ıdica” herdando de “Pessoa”.

1 2

# coding: utf-8 c um modulo de auto gera~ # Este ~ A A§~ A£o de classes django.

3 4

from django.db import models

5 6 7

class Pessoa(models.Model): nome = models.CharField(max_length=45)

8 9 10

class Fisica(Pessoa): cpf = models.IntegerField()

11 12 13

class Juridica(Pessoa): cnpj = models.IntegerField()

38

5.5

Teste m´ ultiplo

Este exemplo ilustra um sistema real, contendo v´arias classes e v´arios tipos de campos e associa¸co˜es.

Figura 5.5: Uml representando v´arias classes O c´odigo gerado pode ser visto no quadro a seguir: 1 2

# coding: utf-8 c um modulo de auto gera~ # Este ~ A A§~ A£o de classes django.

3 4

from django.db import models

5 6 7 8

class Estado(models.Model): nome = models.CharField(max_length=10) zona = models.IntegerField()

9 10 11 12

class Usuario(models.Model): username = models.CharField(max_length=10) password = models.CharField(max_length=20)

13 14 15 16

class Cidade(models.Model): nome = models.CharField(max_length=30) estado = models.ForeignKey(Estado)

17 18 19 20 21

class Pessoa(models.Model): nome = models.CharField(max_length=40) cidade = models.ForeignKey(Cidade) usuario = models.ForeignKey(Usuario, unique=’True’)

39

22

fotos = models.ManyToManyField(Fotos)

23 24 25 26

class Fotos(models.Model): foto = models.ImageField(upload_to=’/upload/teste/’) data = models.DateField(auto_now_add=True)

27 28 29 30

class PessoaFisica(Pessoa): rg = models.IntegerField() nascimento = models.DateField()

31 32 33 34

class PessoaJuridica(Pessoa): cnpj = models.IntegerField()

40

˜ CONCLUSAO

6

6.1

Valida¸ c˜ ao do projeto

O principal objetivo deste trabalho foi alcan¸cado. 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 heran¸ca) foram extraidos com sucesso. Com a utiliza¸ca˜o do gerador de c´odigo, a cria¸ca˜o da camada l´ogica do sistema ficou muito mais f´acil de ser desenvolvida, pois agora o usu´ario possui uma visualiza¸ca˜o gr´afica de todo o sistema, facilitando a visualiza¸ca˜o 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, n˜ao est´a completamente garantida.

6.2

Trabalhos Futuros

A inten¸ca˜o ´e que os trabalhos com o parser possam continuar, atrav´es da cria¸ca˜o de outros testes utilizando diferentes modeladores UML e comparando seu resultado com o desenvolvido at´e o momento. H´a interesse em disponibilizar o parser como software livre, tendo como principal meta, a evolu¸ca˜o do sistema adicionando novas fun¸co˜es, melhorias de performance no c´odigo e no gerador, uma atualiza¸c˜ao do mesmo com poss´ıveis mudan¸cas da estrutura de modelagem do framework Django Atualmente h´a uma projeto de implementa¸c˜ao de m´aquina de workflow em django chamado GoFlow 1 . Uma das possibilidades de trabalho futuro, seria a integra¸c˜ao de diagramas de estados com uma m´aquina de workflow. A proposta seria de a partir de diagramas de estado serem gerados rotinas de workflow, da mesma 1

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

41

forma que hoje s˜ao geradas classes a partir de diagramas de classe.

42

7

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

ANEXOS

<XMI xmi.version = ’1.2’ xmlns:UML = ’org.omg.xmi.namespace.UML’ timestamp = ’Tue Sep 09 13:16:17 BRT 2008’> <XMI.header> <XMI.documentation> <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0) <XMI.exporterVersion>0.24(5) revised on $Date: 2006-11-06 19:55:22 +0100 (Mon, 06 Nov 2006) $ <XMI.metamodel xmi.name="UML" xmi.version="1.4"/> <XMI.content>
43

46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

changeability = ’changeable’ targetScope = ’instance’>     

44

105 106 107 108 109 110 111 112 113 114



45

ˆ REFERENCIAS

BEZERRA, E. Princ´ıpios de An´ alise 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 Model/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.