UNIVERSIDADE DE CAXIAS DO SUL DEPARTAMENTO DE INFORMATICA CURSO DE BACHARELADO E M CIENCIA DA COMPUTACAO MARCOS D.

D. PETRY UML2Django: Gerador de Cdigo o para Framework Web MVC Prof. Joo L. Tavares a Orientador Caxias do Sul, Dezembro de 2008

However, as every parent of a small child knows, converting a large object into s mall fragments is considerably easier than the reverse process. Andrew Stuart Ta nenbaum

AGRADECIMENTOS Agradeo a Deus por ter me dado foras para concluir este curso, me revitalizando c c em todos os momentos de fraqueza. Aos meus pais Ivan Luiz e Iana Ftima, por me entenderem a minha ausncia a e devido ao trabalho e aos estudo, no deixaram de est ar do meu lado me apoiado a incondicionalmente. Ao meu orientador, Professor Joo Luiz Tavares, pela pacincia, sabedoria, pea e las suas correoes e incentivo durant e a implementao do trabalho e redaao da c ca c monogra a. A Universidade de Caxias do ul, e ao docentes do departamento de informtica, a que durante os 7 anos de vida acadmica nesta instituio, tive a honra de ser aluno. e ca Aos meus colegas de traba lho, que me ajudaram-me com meu TCC e na minha carreira pro ssioal. Agradeo aos ami gos de minha cidade natal que me apoiaram em momentos que c precisei e me mostra ndo que a vida no s trabalho e estudo. aeo Aos amigos que z na Universidade: Joel, Alexandre, Fran, Vin cius, Cristian, Enor e muitos outros, por acompanharem minha trajetria acadmica, e estarem o e presentes em momentos complicados. E por ultimo, mas no menos importante, agradeo a minha querida e amada a c 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 . . . . . . . . . . . . . . . . . . . LISTA DE FI GURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LISTA DE TABEL AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ABSTRACT 1 1.1 1.2 1 .3 2 2.1 2.2 2.3 2.3.1 2.4 2.4.1 2.5 2.5.1 3 3.1 3.1.1 3.1.2 3.1.3 3.2 ......... ......................... .............................. 6 7 8 9 10 11 INTRODUCAO Motivao . . . . . . jetivos . . . . . . . strutura do Documento OS PRELIMINARES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 ca Ob . . . . . . . . 12 E . . . . . 13 CONCEIT 15

Padro de desenvolvimento MVC . . . . . . . . . . . . . . . . . . . 15 a Ferrament as Gr cas de Modelagem . . . . . . . . . . . . . . . . . 16 a UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Digramas de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Frameworks de desenvol vimento de aplicaoes . . . . . . . . . . . 18 c Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Linguagem de programao Python . . . . . . . . . . . . . . . . . 19 ca Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 21 DJANGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caracter sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 P ersistncia de dados (model) . . . . . . . . . . . . . . . . . . . . . . 22 e Visu alizaao de dados (view) . . . . . . . . . . . . . . . . . . . . . . . 22 c Control e de dados (Controller) . . . . . . . . . . . . . . . . . . . . . . 23 Fluxo de Execuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 ca

4 IMPLEMENTACAO . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Arquite tura geral da implementao proposta . . . . . . . . . . ca 4.2 Parmetros XMI utiliza dos pelo Parser . . . . . . . . . . . . . . a 4.3 Mapeamento de objetos XMI - Dj ango Model . . . . . . . . . . 4.4 Anlise lxico-sinttica . . . . . . . . . . . . . . . . . . . . . . . . a e a 4.4.1 Extraao do XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . c 4.5 Anlise semntica . . . . . . . . . . . . . . . . . . . . . . . . . . . . a a 4.5.1 Algoritmo de gerao . . . . . . . . . . . . . . . . . . . . . . . . . . ca 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 Herana . . . . . . . . . . . . . . . . . . . . . . . . . . . . c 5.5 Teste m ltiplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u . . . . . . . . . . . . . . 25 25 25 29 29 31 32 32 35 35 35 36 37 38 6 CONCLUSAO . . . . Validao do projeto 2 Trabalhos Futuros . ANEXOS . . . . . . . 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 40 40 42 6.1 ca 6. 7 4

REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LISTA DE ABREVIATURAS E SIGLAS DRY GLC HTML HTTP MVC OMG PDF TCC UML URL XML XMI Dont repeat yourself Gramtica Livre-de-Contexto a HyperText Markup Language Hypert ext Transfer Protocol Model-view-controller Object Management Group Portable Doc ument Format Trabalho de Concluso de Curso a Uni ed Modeling Language Uniform Resou rce Locator Extensible Markup Language 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 Execuo do Framework Django . . . . . . . . . . . . . 24 c a 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 Represen tando uma classe . . . . . . . . . . . . UML Representando duas classes sem rela cionamento UML representando duas classes relacionadas . . . . UML representando herana . . . . . . . . . . . . . . c Uml representando vrias classes . . . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 36 36 37 38

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

RESUMO

O desenvolvimento de aplicaes WEB cresce contantemente e, como conseqncia co ue diss o, os recursos e as funcionalidades destas aplicaes evolui. Portanto, desenvolco v er aplicaoes de qualidade em um curto per c odo de tempo um requisito cada vez e mai s valorizado. Uma maneira de melhorar o processo de desenvolvimento e a qualidad e das aplicaoes utilizando frameworks de desenvolvimento. Utilizando frameworks, o c e desenvolvedor pode focar-se de fato, no objetivo principal do sistema, evit ando assim, o trabalho repetitivo de outras aplicaes, como por exemplo a construo de co ca logins e controles de acesso. Um exemplo de framework que faz este trabal ho o e Django. Django constitui-se em um framework web de alto n vel, escrito em P ython, que visa estimular o desenvolvimento rpido. Apesar de suas inmeras facilida des, o a u Django no possui uma ferramenta de gerao automtica de cdigo a partir de di a ca a o agramas gr cos de modelagem, por exemplo. Esta funcionalidade auxiliaria m uito a os desenvolvedores que, atualmente, precisam descrever manualmente a cama da de modelagem, di cultando tambm a documentaao estruturada, como por exemplo e c at ravs de diagrama de classes e padronizaoes ao estilo UML. e c Focado nestas limitaoe s, inerentes a qualquer ferramenta de software livre que c inicia sua evoluao no m eio da produao de aplicaoes, este trabalho prope uma ferc c c o ramenta que, aliada a Django, tem a nalidade de gerar a camada de modelagem do framework a partir de d iagramas UML. Dessa forma o desenvolvedor consegue criar o Model de forma mais rp ida e fcil, ao mesmo tempo que mantm a documentaao a a e c 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 r equirement more and more valuable. Development frameworks aid to improve the pro cess of development and the quality of the applications. Using frameworks, the d eveloper 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. Djang o consists in a high level web framework (writing in Python) that aims to stimul ate the fast development. Although its innumerable easinesses, the Django does n ot possess a tool of automatic generation of code from graphical diagrams of mod eling, for instance. This functionality would very assist the developers that, c urrently, need to describe the modeling layer manually, also making it di cult the structuralized documentation, as for example through class diagrams and standar dizations in UML style. Focused on those limitations, inherent to any tool of fr ee 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 f ramework 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 evo lui, ao mesmo tempo em que requerido uma maior agilidade no processo de e desenv olvimento dos mesmos. Desenvolver software em um curto per odo de tempo sempre foi um requisito desejvel para programadores e empresas. a Vrios requisitos, padres e tcnicas so criados diariamente, com a nalidade a o e a de aumentar a produo e melhora r o processo de construao de sistemas. Como reca c sultado, foram criados diversas ferramentas e frameworks, vrios processos e rotinas a repetitivas foram automati zados por eles e o tempo gasto no processo de implementao de fato diminuiu. Em ger al, um Framework, assim como web frameworks, ca proporcionam uma infraestrutura de programaao para aplicaes, de forma que o c co projetista possa se concentrar na e scrita de cdigo e ciente e de fcil manutenao. o a c Mas ainda h diversos pontos a melh rar, ou pelo menos para facilitar o processo de a produao de cdigo de forma automa tizada, como por exemplo gerao automtica c o ca a de cdigo nativo de um framework a p artir do esquema de um diagrama de classes. o Os frameworks utilizados atualment e, seguem o padro MVC (LEFF AVRAHAM; RAYa FIELD, 2001), que um padro de arquitetur a de aplicaes que visa separar a lgica e a co o da aplicao (Model), da interface do u surio (View) e do uxo da aplicaao (Conca a c troller). O uso deste tipo de framework permite que a mesma lgica de negcios o o possa ser acessada e visualizada por vria s interfaces. Neste trabalho adotamos o a framework Django1 (MAURER, 2006), que utiliza o padro MVC e tambm sua a e arquitetura de desenvolvimento estimula o dese nvolvedor a aproveitar ao mximo o a cdigo j feito, evitando a repetio. o a ca Como o objetivo de melhorar o processo de desenvolvimento com Django, este trabalho pro pe-se a gerar camada Model do framework Django, atravs de cdigos o e o XMLs gerados por editores de diagramas de classe, permitindo assim alm de aue mentar a velocid ade de desenvolvimento de aplicaes, a geraao e documentaao co c c bsica do sistema. 1 http://www.djangoproject.com/

12 1.1 Motivao ca

O Framework escolhido, o Django, recentemente ganhou bastante notoriedade no mun do do software livre, devido a sua praticidade no desenvolvimento de aplicaes, co foi adotado em diversas empresas e instituioes, como por exemplo o Google, Goc ver no Brasileiro e a Universidade de Caxias do Sul. Django um framework web de alto n escrito em Python que estimula o desene vel volvimento rpido e limpo, concentran do-se no mximo de automatizaao poss a a c vel, aderindo ao princ pio DRY (Dont repe urself). Eliminando processos repetitivos como criaao e autenticaao de formulrios e tambm a geraao automtica de c c a e c a interface de administraao, mecanismos de ca e internacionalizaao. c c Atualmente, o desenvolvimento de aplicaoes em Django no po ssui nenhuma c a ferramenta que gere cdigo a partir de ferramentas de modelagem, a camada de o modelagem escrita manualmente. Desse modo, se a equipe necessitar d e algum e tipo de documentaao, como por exemplo um diagrama de classes, ela ter qu e c a repetir o processo de construo. ca 1.2 Objetivos

O objetivo principal deste trabalho o desenvolvimento de uma ferramenta para e a geraao automtica de cdigo Python a partir da modelizaao de diagramas gec a o c rados por ferramentas de modelagem UML. Esta ferramenta visa o aumento de produtividad e e tambm a diminuiao da possibilidade de erros de codi cao. e c ca Nesta proposta, tr taremos da implementao desta ferramenta, integrada ao ca framework Django, com o o bjetivo de gerar a classe de modelagem do framework web a partir dos diagramas d e classes criados pela ferramenta de criaao de modelos c UML. Basicamente o proces so desta geraao segue os seguintes passos: c 1. Construo dos diagramas de classes em uma interface gr ca (ex. ArgoUML, ca a Umbrello), Por exemplo, o projeto de um dia grama de classes com seus respectivos componentes para de niao de atributos, relaci onamentos, cardinalic dades, etc, conforme a Figura 1, abaixo: Figura 1.1: Imagem gerada pelo editor UML

13 2. Gerao do script XMI, padro da OMG (grupo de gerenciamento de objetos) ca a (OMG, 2007), para troca de informaes baseado em XML. O uso mais coco mum na troca facil itada de metadados entre as ferramentas de modelagem e (baseadas no UML). Um exe mplo de um fragmento de script XMI ilustrado e abaixo: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<?xml version = 1.0 encoding = UTF-8 ?> <XMI xmi.version = 1.2 xmlns:UML = org.omg.x namespace.UML timestamp = Tue Sep 09 13:16:17 BRT 2008> <XMI.header> <XMI.documenta tion> <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0)</XMI.exporte r> <XMI.exporterVersion>0.24(5) revised on $Date: 2006-11-06 19:55:22 +0100 (Mon , 06 Nov 2006) $ </XMI.exporterVersion> &nbsp; </XMI.documentation> &amp;amp;amp ;amp;amp;amp;amp;amp;amp;amp;amp;amp;nbsp; <XMI.metamodel xmi.name="UML" xmi.ver sion="1.4"/></XMI.header> <XMI.content> <UML:Model xmi.id = 127-0-1-1--2d55673f:1 1c47d175d4:-8000:000000000000077B name = untitledModel isSpecification = false isRoot = false isLeaf = false isAbstract = false> <UML:Namespace.ownedElement> . . . </UML: amespace.ownedElement> </UML:Model> </XMI.content> </XMI>

3. Tratamento das informaes do XML e geraao de cdigo no padro do fraco c o a mework D ango. O diagrama exempli cado na Figura 1 dever produzir o a seguinte cdigo Python n o framework Django: o 1 2 3 4 5 6 7 8 9 class Pessoa_Email(models.Model): endereco = EmailField() class Pessoa(models.Mo del): nome = models.CharField() cidade = models.CharField() nascimento = models. DateField() enviar_mail = models.BooleanField() endereco = models.ForeignKey(Pes soa_Email) 1.3 Estrutura do Documento O presente trabalho est dividido em 6 cap a tulos:. O cap tulo 1 apresenta uma introd uo do trabalho, bem como a motivaao, os ca c objetivos, ferramentas de apoio e a est rutura do documento. No Cap tulo 2, sero abordados alguns conceitos preliminares ne cessrios para a a um melhor entendimento trabalho, onde apresentamos o padro de de senvolvimento a

14 MVC, uma introduao bsica sobre a linguagem python e frameworks de desenvolc a vimen to. O framework alvo da aplicao, o Django, ser apresentado no cap ca a tulo 3, onde s ero descritos detalhes de seus componentes mais usuais e como o padro MVC a a e ap licado a ele. No capitulo 4, apresentamos o trabalho desenvolvido, onde focado o parser e implementado no projeto, a estrutura do sistema, os elementos relevant es do arquivo XMI, a gramtica utilizada para ler estes elementos e o processo de traduao para a c a sintaxe da classe Django. O cap tulo 5 destinado a apresentar os testes com o sistema, onde diversos e diagramas de classes sero traduzidos para cd igo Python do Django atravs da a o e ferramenta implementada neste trabalho. O Ca p tulo 6 destinado ` apreciaao das concluses nal bem como das altere a c o nativas continuidade e trabalhos futuros da presente proposta.

15 2 CONCEITOS PRELIMINARES

Neste Cap tulo, introduziremos alguns conceitos fundamentais necessrios ao ena tend imento dos componentes utilizados no trabalho. Na seo 2.1 apresentamos uma ca brev e introduao sobre o padro de desenvolvimento MVC. Introduzimos algumas c a explicaoe s sobre UML na seo 2.2. Na seao 2.3 sero abordados de nies sofre c ca c a co framew oncluindo o cap tulo, ser feita uma breve explicaao sobre Python, a c a linguagem uti lizada neste trabalho. 2.1 Padro de desenvolvimento MVC a

MVC um padro de arquitetura de aplicaoes que visa separar a lgica da e a c o aplicaa (Model), da interface do usurio (View) e do uxo da aplicao (Controlc a ca ler). Perm ite que a mesma lgica de negcios possa ser acessada e visualizada por o o vrias int erfaces. a O MVC tambm utilizado em padres de projetos de software, entretanto, MV C ee o abrange mais da arquitetura de uma aplicaao do que t c e pico para um padro d a projeto. Em um projeto de software baseado no padro MVC , de ne-se uma arquitetu ra a bsica com 3 camadas possivelmente abstratas: a Model: Implementa o modelo re presentando a estrutura de baixo n vel do projeto, podendo ser o modelo objeto-rel acional que implementa a camada de dados. Um caso de MVC de Interface poderia gu ardar informaoes de estado c dos controllers, por exemplo; Controller: Implementa a camada responsvel pelo gerenciamentos de eventos a no projeto, tais como clique s do usurio, chamando a camada Model para a processar os eventos. Tambm pode mante r informaoes de estado do usurio e c a na aplicaao; c View: Gera a interface com usu o de modo que esta somente requisite o a processamento de eventos pelo Controlle r;

16

Segundo (BEZERRA, 2007), Model-view-controller (MVC) um padro de are a quitetura de software. Com o aumento da complexidade das aplicaoes desenvolc vidas torna-se fundamental a separaao entre os dados (Model) e o layout (View). c Desta forma, al teraoes feitas no layout no afetam a manipulao de dados, e estes c a ca podero ser re rganizados sem alterar o layout. a O model-view-controller resolve este problema atravs da separao das tarefas e ca de acesso aos dados e lgica de negcio, lgica de a resentaao e de interao com o o o o c ca utilizador, introduzindo um componente entre os dois: o Controller. MVC usado e em padres de projeto de software, mas MVC abr ange mais da arquitetura de uma o aplicaao do que t c e pico para um padro de projet . a 2.2 Ferramentas Gr cas de Modelagem a A escolha de ferramentas de Gerao de Diagramas de classes foi de nida tendo ca como base dois critrios: ser software livre e possuir exportaao para XMI. Foram e c enco ntradas as seguintes ferramentas que possuem estes requisitos: ArgoUML1 e Umbrel lo2 . Umbrello UML Modeller permite a modelizao de software atravs de diagramas ca e UML (Uni ed Modeling Language) originalmente para o ambiente KDE-Linux, com exte nses recentes para Windows e MAC. Umbrello manipula todos os tipos de o diagramas UML e capaz de gerar cdigo para algumas linguagens como Java, e o C++, Python, P HP, entre outras. No entanto, o cdigo Python gerado a partir o dos diagramas do U mbrello ainda no so compat aa veis com o framework Django, necessitanto algumas adap taes manuais que, dependendo do tamanho do projeto, co pode tornar invivel sua exec uo. a ca ArgoUML um software para modelagem UML escrito em Java. Possibilitando e ser instalado em qualquer plataforma com suporte a esta tecnologia. Possui supor te completo para UML 1.4 padro e oferece excelentes mtodos para criaao e mania e c p ulaao dos seus diagramas em UML. Oferece suporte para geraao de cdigo Java c c o nati vo e outras linguagens (C++, C# e PHP) atravs de plugins disponibilizados e em se u site. Infelizmente, a exportaao para cdigo Python est somente nos planos c o a de seus desenvolvedores. As ferramentas acima salvam o diagrama no formato padro XMI (XML Metaa data Interchange) (OMG, 2007), que segundo Eduardo Bezerra, de ne XMI como sendo: um padro baseado em XML para exportar modelos de nidos em a UML. Esse padro important e, pois permite a interoperabilidade ae 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 fab ricantes A e B so suporte ao a padro XMI(BEZERRA, 2007) a 2.3 UML

A UML uma linguagem visual para modelar sistemas orientados a objeto. Isso e que r dizer que a UML uma linguagem que de ne elementos gr cos que podem e a ser utilizad os na modelagem de sistemas. Esses elementos permitem representar os conceitos d e orientao a objetos atravs dos diagramas criados. Seguindo a notaao ca e c UML, pos ivel representar diversas perspectivas do sistema. Ainda segundo (BEe ZERRA, 200 7), cada elemento gra co da UML possui sintaxe e uma semntica. a A sintaxe de um el emento corresponde a forma predeterminada de desenhar o ele` mento. A semntica de n e o que signi ca o elemento e com que objeto ele deve ser a utilizado. Tanto a sin taxe quanto a semntica dos elementos so extens a a veis. Essa extensibilidade permit e que a UML sej adaptada as caracter a ` sticas de cada projeto de desenvolvimento. Embora a UML possua diversos diagramas para representar o sistema (atividades, casos de uso, colaborao, seqncia, entre outros) o sistema desenvolvido utiliza ca ue somente diagramas de classe, pois o diagrama mais indicado para o propsito do e o 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 relaoes entre as classes. Cada c cla sse do diagrama possui um conjunto de objetos: Nome da classe, atributos, relaci onamentos e mtodos. e 2.3.1.1 Atributos De niao das caracter c sticas da classe, cada elemento de sua lista de atributos possu i um nome e um tipo de dado. 2.3.1.2 Relacionamentos Um relacionamento representa uma ligao entre classes, uma ligao binaria ca e ca (com duas extremidades) onde cada extremidade ligada a uma classe, atravs de e e uma linha. Existem diferentes tipos de relacionamento: Agregaao, composio, c ca Herana. c

18 2.3.1.3 Mtodos e Mtodos so funoes requeridas a um objeto ou seja, as aoes que os obje tos de e a c c uma classe pode executar. 2.4 Frameworks de desenvolvimento de aplicaes co

Estamos em uma poca onde as informaoes so recebidas rapidamente, not e c a cias de qu lquer parte do mundo chegam as pessoas de forma quase instantnea. Grande ` a part e dessa informaao veiculada atravs da WEB. Para isso o desenvolvimento c e e de apl icaoes web muito explorado. c e Apesar da quantidade de ferramentas de desenvolvim ento ser bastante grande, implementar aplicaes para Internet no algo trivial. Const ruir uma aplicaao co ae c web totalmente funcional a algo bastante trabalhoso. Mui tas tarefas so necessrias a a para que tal feito seja completo: A Con gurao e a criaao de tabelas em base de ca c dados, criao de consultas e relacionamentos para as mesm as, geraao de cdigo ca c o HTML, mapear as URL para ler os cdigos, controle de usurio s, e estes itens so o a a s a parte bsica do desenvolvimento. o a O desenvolvimento para WEB muito repetitivo; os passos a serem seguidos e so praticamente os mesmo s para cada nova aplicaao a ser criada. Como tentaa c tiva de minimizar ao mximo es tes repetitivos passos, foram criadas bibliotecas e a frameworks para facilitar o desenvolvimento de aplicaoes, fazendo com que o dec senvolvedor focalize basicam ente o objetivo do novo sistema, deixando a cargo do framework manter as tarefas mais maantes. c Um framework uma camada de abstrao na qual um determinado conjunto e ca de cdigos implementa uma certa funcionalidade genrica, facilmente customizad a o e pelo usurio, criando assim um funcionalidade expeci ca. E funo do framework a c a tambm, validar o cdigo criado pelo usurio. e o a Os frameworks para desenvolvimen to web geralmente seguem o padro de arquia tetura de sistema MVC para separar as camadas de negcio, persistncia e interface. o e 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 peogramaao WEB possui os frameworks c Cak ePHP10 , CodeIgniter11 , Prado12 , symfony13 , Zend14 , entre outros. Perl possu i o Catalyst15 , Maypole16 , Jifty17 , e a maioria deles segue o padro MVC. a 2.5 Linguagem de programao Python ca

Python18 uma linguagem de programao de alto n e ca vel, interpretada, interativa, or ientada ` objetos e de tipagem dinmica e forte, lanada por Guido van a a c Rossum em 1991. Atualmente possui um modelo de desenvolvimento comunitrio e a aberto ger enciado pela organizaao sem ns lucrativos Python Software Foundation. c Apesar de vr ias partes da linguagem possu a rem padres e especi caoes formais, o c a linguagem com um todo no formalmente especi cada. O padro de impleae a mentao o CPython, o que s i ca que foi desenvolvida a partir da linguagem ca e C, mas existe tambm as variant es Jython e IronPython que so reimplementaao e a c do Python produzidas em Java e . NET respectivamente. A linguagem foi projetada com a loso a de enfatizar a importnci a do esforo do a c programador sobre o esforo computacional. Prioriza a legibilida de do cdigo sobre a c o velocidade ou expressividade. Combina uma sintaxe concisa e clara com os recursos poderosos de sua biblioteca padro e por mdulos e framewor ks desenvolvidos por a o terceiros. 2.5.1 Exemplos Atravs dos exemplo abaixo, possivel veri car a simplicidade da linguagem: e e 2.5.1 .1 1 2 3 4 Fibonacci a =1 b =1 while a < 800: print a , http://turbogears.org http://pylonshq.com 6 http://www.zope.org 7 http://www.plo ne.org 8 http://mdp.cti.depaul.edu 9 http://www.php.net 10 http://www.cakephp.or g 11 http://codeigniter.com 12 http://www.pradosoft.com 13 http://www.symfony-pr oject.org 14 http://www.zend.com 15 http://www.catalystframework.org 16 http://m aypole.perl.org 17 http://jifty.org 18 http://www.python.org 5 4

20 5 a,b = b,a+b 2.5.1.2 Nmeros Primos u 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 Clculo de Fatorial a 1 2 3 4 5 6 7 8 9 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) um framework para desenvolvimento rpido para e a web, escri to em Python, que utiliza o padro MVC (model-view-controller). Foi a criado origi nalmente como sistema para gerenciar um site jornal stico na cidade de Lawrence, n o Kansas. Tornou-se um projeto de cdigo aberto e foi publicado sob o a licena BSD1 em 2005. O nome Django foi inspirado no msico de jazz Django c u Reinhardt. Djan go utiliza o princ pio DRY (Dont Repeat Yourself), onde faz com que o desenvolvedor aproveite ao mximo o cdigo j feito, evitando a repetiao. a o a c Na seao 3.1, aborda emos as caracter c sticas do framework, onde sero explicados a os componentes princi pais da ferramenta, tais como Controllers, Templates, Models, Middlewares e URLD ispacher. Na seao 3.2 ser explicado o uxo de execuao de c a c uma requisiao no Djang c 3.1 Caracter sticas Atravs do ORM2 do Django de nida a modelagem de dados atravs de classes e e e em Pyt hon, clamadas modelos. Com isso poss e vel independente de qual banco de dados esc olhido, gerar suas tabelas e manipular seus dados sem necessidade de utilizar li nguagem SQL. Os Models tambm possibilitam criar formulrios automticos e gerar uma i ntere a a face de administrao praticamente completa e facilmente con gurvel e extens c a a vel, aumentando ainda mais o desenvolvimento das aplicaes. co O Django possui u ma linguagem de templates muito extens e amigvel. Atravs vel a e dela possivel fazer a separaao de design, contedo e cdigo Python. e c u o A gura 3.1 ilustra a estrutura global do Django, exibindo a ligaao entre os c componentes principais do framewor k. Os componentes esto classi cados em cores, a 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 Persistncia de dados (model) e

A Classe de Modelagem basicamente, a fonte de todos os registros no projeto. e E le contm todos os campos essenciais e relaoes de tudo que armazenado no e c e Banco de dados. Geralmente, cada modelo mapeia uma unica tabela de dados. 3.1.2 . A v isualizaao dos dados pelos usurios feita atravs das views e dos templates. c a e e S atravs deles que os dados recebidos pelos models so manipulados. Os acessos a e a aos dados so feitos atravs das views. a e As views so as seoes do site, onde os dad os recebidos pela camada de pera c sistncia so apresentados, criados, editados e de letados por scripts python. Por e a exemplo, em uma aplicaao de um blog, haveriam as seguintes views: c In - exibiao das 5 ultimas postagens; cio c Postagem - p ra uma unica entrada; a Postagem-Comentrio - comentrios de uma determinada postage m; a a Ano-arquivo - exibe todos os meses com as inscrioes no ano determinado; c V isualizao de dados (view) ca

23 Ms-arquivo - exibe todos os dias com entradas do ms em questo; e e a Dia-arquivo exibe todas as entradas em determinado dia; O sistema de templates do django um mdulo que visa separar a apresentao dos e o ca dados lgicos do site. O Template de ne certos espaos onde so de nidos laos de o c a c repetioes, condicionais e outras funcio nalidades do django para manipular variveis c a passadas pela view. Normalmente, o s templates so utilizados para produzir docua mento HTML, mas os templates do Dja ngo so capazes de gerar qualquer formato a de tipo texto tambm. e 3.1.3 Controle d e dados (Controller) Entre a camada de visualizaao e o usurio, h a camada de controle, responsvel c a a a pelo processamento de aoes de requisioes e resposta do usurio (HTTP Request e c c a H TTP Response). Para realizar este processamento o Django conta com Middlewares e Url Dispatcher. As middlewares so trechos de cdigo que analisam requisioes feitas pelo usurio. a o c a Atravs dele poss e e vel enviar informaes para view de forma parente ao co usurio como, por exemplo, detalhes sobre seoes e autenticaao. a c c Dep ois de passar pelos middlewares, a requisiao analisada pelo URL Dispatc e cher, qu e veri ca o endereo que o usurio acessa e veri ca se o mesmo consta no c a arquivo de URLs da aplicaao. Cada URL est associada a uma view, se a URL c a requisitada no se encontra no arquivo um erro do tipo 4043 informado. a e 3.2 Fluxo de Execuo ca Atravs de um browser, o usurio faz uma requisiao a um site Django, de acordo e a c c om a URL informada. O Framework veri ca se a mesma est nos seus registros a de URL. Aps a localizao da URL, uma view correspondente invocada, a view o ca e requisita informaoes ` classe de modelagem que devolve os dados. Com os dados c a recebidos da classe de modelagem, o Django armazena em variveis e envia para um a template. O template recebe as variveis da view e renderiza o template no formato a deseja do (HTML, PDF). A pgina renderizada exibida na tela para o usurio. O a e a process o detalhado pode ser visto na Figura 3.2. 3 404 Error. The Page Was Not Found

24 Figura 3.2: Fluxo de Execuao do Framework Django c

25 4 IMPLEMENTACAO Neste Cap tulo abordamos a implementaao da proposta de geraao de cdigo c c o python framework Django a partir de modelos de diagramas de classes. Na seo ca 4.1 introd uzimos a arquitetura geral do sistema proposto, mostrando seus componentes princ ipais e seus relacionamentos. Na seao 4.2 mostramos a delimitaao do c c escopo dos e lementos XMI tratados pelo nosso gerador. 4.1 Arquitetura geral da implementao proposta ca A implementaao do Parser XMI-DjangoModel foi feita inteiramente utilizando c Pytho n, a mesma linguagem do Framework web Django. No foi de nida nenhuma a interface gr ca , pois no h necessidade para tal. Basicamente o script recebe a aa como parmetro o arquivo XML e gera a classe de modelagem. A Figura 4.1 ilustra a a arquitetura g eral do analisador XMI2Django proposta neste trabalho. Os principais modeladores de gr cos UML possuem um mtodo de exportaao a e c em arquivo texto para que os diagra mas criados possam ser acessados em outro modelador. O mtodo que resulta este tex to, est escrito em padro XMI, um e a a formato de nido pela OMG para representaao, in tercmbio e compartilhamento de c a objetos, modelos e meta-modelos utilizando XML. Teoricamente, os dados XMI exportados em um modelador, devero ser lidos a em out ro sem maiores problemas, logo o parser do trabalho em questo, ir gerar a a o cdigo Django independente da ferramenta de modelagem UML utilizada, desde o que ele e xporte o arquivo XMI 4.2 Parmetros XMI utilizados pelo Parser a Boa parte das tags contidas no XML gerado pelo editor UML no so utilizadas aa no p arser, pois muitas delas so geradas com a nalidade de exportaoes para outros a c apl icativos (como por exemplo, outro editor UML). No trabalho em questo so aa utiliza das, para uma geraao correta da classe de modelagem do Django, os seguintes c elem entos:

26 Figura 4.1: Estrutura do parser XMI2Django UML:Namespace.ownedElement O elemento raiz do xmi, onde todos os itens do diagrama em questo e a esto inseridos; a UML: DataType Lista de tipos de dados (name, xmi.id); UML:Class Classes do diagrama d e classes (name, xmi.id); UML:Classi er.feature Tag XMI que contm a tag UML:Attribu te; e UML:Attribute Atributos da classe (name, xmi.id); UML:ModelElement.taggedV alue Tag XMI que contm a tag XML:TaggedValue; e UML:TaggedValue Lista de valores marcados;

27 UML:TaggedValue.type Tag XMI que contm a tag UML:TagDe nition; e UML:TagDe nition Apo ntador para o valor marcado (xmi.idref); UML:TaggedValue.dataValue Valor do Valo r Marcado (name); UML:StructuralFeature.type Tag XMI que contm a tag UML:DataType ; e UML:DataType Um apontador para um tipo de dado (xmi.idref); UML:Association Lista de associaoes entre classes; c UML:Association.connection Tag XMI que contm a tag UML:AssociationEnd; e UML:AssociationEnd Tipo de associaao (Composio, agregaao, herana) (aggregation); c ca c c UML:AssociationEnd.participant Lista de objetos pa rticipantes da associaao, para o parser, ele trata apenas c classes; UML:Class Um apontador para a classe (xmi.idref); UML:AssociationEnd.multiplicity Tag XMI que contm a tag UML:Multiplicity; e UML:Multiplicity Tag XMI que contm a tag UML:Mult iplicity.range; e UML:Multiplicity.range Tag XMI que contm a tag UML:Multiplicity Range; e UML:MultiplicityRange Multiplicidade da associao (1 para n, 1 para 1) (lo wer, upper ); ca

28 UML:TagDe nition Nome do Valor Marcado (name, xmi.id). Abaixo est parte do cdigo XMI gerado pelo editor UML que utilizado pelo a o e parser. Nele est modelado o diag rama UML apresentado no cap a tulo de Introduo. ca 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 cdigo o inteiro est nos anexos: a 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

<UML:Namespace.ownedElement> <UML:Class xmi.id = 127-0-1-1--2d55673f:11c47d175d4: -8000:000000000000077C name = Cidade visibility = public isSpecification = false isR = false isLeaf = false isAbstract = false isActive = false> <UML:Classifier.featur ML:Attribute xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077F name = nome visibility = public isSpecification = false ownerScope = instance changeabil changeable targetScope = instance> <UML:StructuralFeature.type> <UML:DataType xmi.i dref = 127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000786/> </UML:StructuralFea ture.type> </UML:Attribute> </UML:Classifier.feature> </UML:Class> <UML:DataType xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000786 name = CharField is Specification = false isRoot = false isLeaf = false isAbstract = false/> <UML:DataT mi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000787 name = IntegerField i sSpecification = false isRoot = false isLeaf = false isAbstract = false/> <UML:Clas .id = 127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000792 name = Estado visibilit y = public isSpecification = false isRoot = false isLeaf = false isAbstract = fals ve = false> <UML:Classifier.feature> <UML:Attribute xmi.id = 127-0-1-1--2d55673f:11 c47d175d4:-8000:0000000000000795 name = nome visibility = public isSpecification = fa se ownerScope = instance changeability = changeable targetScope = instance> <UML:Str uralFeature.type> <UML:DataType xmi.idref = 127-0-1-1--2d55673f:11c47d175d4:-8000 :000000000000786/> </UML:StructuralFeature.type> </UML:Attribute> <UML:Attribute xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007AF name = zona visibili ty = public isSpecification = false ownerScope = instance changeability = changeable getScope = instance> <UML:StructuralFeature.type> <UML:DataType xmi.idref = 127-0-1 -1--2d55673f:11c47d175d4:-8000:000000000000786/> </UML:StructuralFeature.type> </ UML:Attribute> </UML:Classifier.feature> </UML:Class> <UML:Association xmi.id = 1 27-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C2 name = isSpecification = fals e isRoot = false isLeaf = false isAbstract = false> <UML:Association.connection> <UM ssociationEnd xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C3 visi bility = public isSpecification = false isNavigable = true ordering = unordered agg ion = composite targetScope = instance changeability = changeable> <UML:AssociationEn .multiplicity>

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

<UML:Multiplicity xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C4> <UML:Multiplicity.range> <UML:MultiplicityRange xmi.id = 127-0-1-1--2d55673f:11c 47d175d4:-8000:00000000000007C5 lower = 1 upper = 1/> </UML:Multiplicity.range> </UML :Multiplicity> </UML:AssociationEnd.multiplicity> <UML:AssociationEnd.participan t> <UML:Class xmi.idref = 127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077C/> </UML:AssociationEnd.participant> </UML:AssociationEnd> <UML:AssociationEnd xmi .id = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C6 visibility = public isS pecification = false isNavigable = true ordering = unordered aggregation = none tar ope = instance changeability = changeable> <UML:AssociationEnd.multiplicity> <UML:Mu ltiplicity xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007CA> <UML:M ultiplicity.range> <UML:MultiplicityRange xmi.id = 127-0-1-1--2d55673f:11c47d175d 4:-8000:00000000000007C9 lower = 1 upper = -1/> </UML:Multiplicity.range> </UML:Multi plicity> &nbsp;&nbsp; </UML:AssociationEnd.multiplicity> <UML:AssociationEnd.par ticipant> <UML:Class xmi.idref = 127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000 000792/> </UML:AssociationEnd.participant> </UML:AssociationEnd> </UML:Associatio n.connection> </UML:Association> </UML:Namespace.ownedElement> 4.3 Mapeamento de objetos XMI - Django Model O gerador proposto tem como objetivo traduzir elementos XMI em cdigo Python o seg undo o framework Django. A Tabela 4.1 ilustra os componentes (tags) XMI consider ados e sua respectiva traduao no framework Django. Cada linha da tabela c poder ser gerada por uma ou vrias regras de produao gramaticais aliadas ` rea a c a gras semn ticas para geraao de cdigo Python. a c o 4.4 Anlise lxico-sinttica a e a

O parser considerado neste projeto um top-down descendente para gramticas e a 1 d o tipo LL . Considerando o escopo delimitado na seao 2.2, a gramtica livre-dec a co ntexto (GLC) de nida aqui compreende apenas a gerao de produes relativas ca co aos com ponentes de representaao de Classe, atributos e relacionamentos do padro c a XMI. P ara tanto, limitamos nossa gramtica a estas tags espec a cas. Alm disso, e no foi cri da nenhuma validaao da sintaxe do XMI, pois, partimos do pressuposto a c Left-to-Right, Leftmost derivation com lookahead. Para isto, a gramtica livre-decontexto a deve estar livre de recurso a esquerda e deve estar fatorada. a 1

30 Tag XMI UML:Class UML:Attribute UML:DataType UML:Association, UML:AssociationEnd , UML:AssociationEnd.participant, UML:MultiplicityRange UML:TagDe nition, UML:Tagg edValue.type, UML:TaggedValue.dataValue Django Classe Django Atributo da Classe Django Tipo do atributo Geraao de um atri buto da classe c Django que representar a associao, seja a ca 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 atravs de um sistema e j consolidado. a Como a es trutura do XMI basicamente uma estrutura em forma de rvore, a e a gramatica utili zada no parser bem simples. A seguir apresentamos a GLC proposta e em formato BN F: 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 <UML:Namespace.ownedElement> ::= <UML:DataType> <UML:Class> <UML:Association> <U ML:DataType> ::= name "=" "" valor "" xmi.id "=" "" valor "" xmi.idref "=" "" valor "" <UML:Class> ::= UML:Classifier.feature name "=" "" valor "" xmi.id "=" "" valor "" xmi.idref = "valor" <UML:Class> ::= UML:Class name "=" "" valor "" xmi.id "=" "" valor "" <UML:Classifier.feature> <UML:Class> ::= UML:Class xmi.idref "=" "" val or "" <UML:Classifier.feature> ::= <UML:Attribute> <UML:Attribute> :: = UML:Model Element.taggedValue UML:StructuralFeature.type" name "=" "" valor "" xmi.id "=" "" valor "" <UML:ModelElement.taggedValue> ::= "UML:TaggedValue" <UML:TaggedValue> : : = "UML:TaggedValue.type" "UML:TaggedValue.dataValue" <UML:TaggedValue.type> :: = "UML:TagDefinition" <UML:TagDefinition> ::= xmi.idref "=" "" valor "" <UML:Tagge dValue.dataValue> ::= name "=" "" valor "" <UML:StructuralFeature.type> ::= "UML:D ataType" <UML:Association> ::= "UML:Association.connection" <UML:Association.con nection> ::= "UML:AssociationEnd" "UML:AssociationEnd.participant" "UML:Associat ionEnd.multiplicity" <UML:AssociationEnd> ::= aggregation "=" "" valor "" <UML:Ass ociationEnd.participant> ::= "UML:Class" <UML:AssociationEnd.multiplicity> ::= " UML:Multiplicity.range" <UML:Multiplicity.range> ::= UML:MultiplicityRange <UML: MultiplicityRange> ::= lower "=" "" valor "" upper "=" "" valor "" Para auxiliar a extrao de dados relevantes do XML, foi utilizado o pacote ca padro do Python, o xml.dom.minidom. Com ele foi poss tratar os nomes de a vel tags e dif erenas entre os atributos das mesmas. Embora existam outros parsers c

31 XML escritos em Python, como por exemplo o ElementTree 2 e o BeautifulSoup 3 o p acote padro da linguagem foi o escolhido. A justi cativa desta escolha se deve a ao fato do pacote padro j fazer parte da distribuio atual do Python, sendo aa ca assim , o sistema tende a manter uma maior compatibilidade com futuras verses do o inte rpretador. 4.4.1 Extrao do XML ca

A extrao dos dados feita atravs do pacote xml.dom.minidom, como referido ca e e aci ma, uma implementao mais leve da interface DOM4 . E uma implementaao ca c mais simpl es que o DOM padro e signi cativamente menor. O Minidom analiza a o cdigo no arquivo XML e cria a estrutura DOM, sendo esta mais fcil para mao a nipulaao dos itens do s arquivos XML. Uma vez tendo o objeto DOM, possivel c e acessar partes de seu do cumento XML atravs das suas propriedades e mtodos. e e 5 Estas propriedades so de nid as na especi cao DOM . A principal propriedade a ca do objeto a documentElement, res ponsvel pela extrao das tags expec e a ca cas 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.tagNa me umyxml Tambm foi criada uma funo em Python chamada nditem com a nalidade e ca de car e retornar uma lista de itens- lho, de uma tag expec ca, de acordo com o nome env iado por parmetro: a 1 2 def findItem(raiz,item): return [x for x in raiz.childNodes if x.nodeName == ite m] A busca dos elementos principais do diagrama (classes, tags, tipo de dados e ass ociaoes) feita atravs do item raiz (UML:Namespace.ownedElement): c e e 1 2 3 4 5 6 7 8 def findItem(raiz,item): return [x for x in raiz.childNodes if x.nodeName == ite m] raiz = doc.documentElement.getElementsByTagName(UML:Namespace.ownedElement)[0] #elemento raiz xmi_tipos = findItem(raiz,"UML:DataType") #lista de tipos lst_tip os = TipoDados(xmi_tipos) 2 3 http://e bot.org/zone/element-index.htm http://www.crummy.com/software/BeautifulSo up/ 4 Document Object Model interface 5 http://www.w3.org/DOM/

32 9 10 11 12 13 14 15 xmi_tags = findItem(raiz,"UML:TagDefinition") #valores marcados lst_tags = TipoT ags(xmi_tags) xmi_classes = findItem(raiz,"UML:Class") #lista de classes xmi_ass ociacoes = findItem(raiz,"UML:Association") #lista de associa~es co 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, feita a extraao do nome de identi cador e c da c lasse e tambm realizada a busca dos atributos da mesma. ee 1 2 3 4 5 6 7 def findItem(raiz,item): return [x for x in raiz.childNodes if x.nodeName == ite m] 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, extra o nome e o identi cador do tipo do e do atributo. O nome do tipo do atributo buscado na lista de tipos, extra anterie da ormente: 1 2 3 4 5 6 xmi_atributos = findItem(container,UML:Attribute) for att in xmi_atributos: contai ner_tipo = findItem(att,UML:StructuralFeature.type)[0] container_tipo2 = findItem( container_tipo,UML:DataType)[0] nome = att.attributes.get(name).value valor= lst_tip os.get_nome(container_tipo2.attributes.get(xmi.idref).value) 4.5 Anlise semntica a a A traduo para cdigo Django, utiliza uma estrutura intermediria de dados, ca o a util izando programaao orientada a objeto escrita em Python, para assim gerar o c ` cdig o Django. A gura 4.5 representa o diagrama desta estrutura intermediria. o a De ac ordo com os dados contidos no arquivo XML, feita a busca de elementos e e extra o s dados relevantes. Estes dados so armazenadas em forma de objetos do a python de acordo com a Figura 4.5. Quando a leitura estiver completa, os objetos python so lidos e escritos na tela, j no padro de modelagem da camada Model do a a a Django. 4.5.1 Algoritmo de gerao ca A geraao das classes realizada atravs da busca das classes do objeto Klasse c e e ( Figura 4.5), onde o objeto possui uma variavel que informa se a classe herda de outra ou no, pois o cdigo traduzido de uma classe herdada diferente. a o e

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.he rda_de) else: yield class %s(models.Model): % cl.nome Para cada classe, veri cado se a mesma possui atributos, cada atributo escrito e e como uma varivel da classe recebendo como valor, o tipo de campo Field do Django . a veri cado tambm se o atributo possui valores marcados, se possuir, estes so E e a escritos como parmetros do Field. a 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 Associaoes da classe so geradas de forma semelhante aos atributos, pois so c a a escritas tambm como variveis da classe. Alm da veri cao de valore marcados, e a e ca ri cado o tipo de cardinalidade. Se a cardinalidade for um para muitos (1:n) e gerad o um campo ForeignKey, se for uma relaao muitos para muitos (n:n) e c e gerado um ca mpo 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 r l.cardinalidade[0] == * and rel.cardinalidade[1] == *: yield %s = models.ManyToManyF ield(%s%s) % \ (str.lower(str(rel.classe)), rel.classe, extra) for rel in cl.asso ciacoes: extra = "" if len(rel.extras): for ex in rel.extras: extra+=", %s=%s" %(e x[nome],ex[valor]) if rel.cardinalidade[0] == * and rel.cardinalidade[1] == *: yiel = 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.c lasse, 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, agregaes c o e herana. Em todos os casos abaixo foram gerados cdigos, sendo estes perfeitac o mente aplicados no framework. 5.1 Diagramas com uma Classe Primeiro teste feito com o Parser, e o mais simples, veri ca a classe Pessoa contida no XML e lista os atributos (nome) e (nascimento), conforme a gura 5.1. Figura 5.1: UML Representando uma classe O cdigo gerado corresponde a Classe do D jango com o nome Pessoa e com o as variveis (nome) e (nascimento) representando seu s atributos, conforme o quadro a abaixo: 1 2 3 4 5 6 7 8 # coding: utf-8 # Este ~ c um modulo de auto gera~~o de classes django. A AA from django.db import models 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 vrias classes. Nele a so geradas duas classes, a classe Cidade, com um atributo (nome) e a Classe a Esta do com dois atributos (nome) e (zona)

36

Figura 5.2: UML Representando duas classes sem relacionamento O cdigo gerado contm duas classes Django com os nomes Cidade e Estado. o e A classe Cidade possui o atrib to (nome) e a classe Estado possui os atributos (nome) e (zona), conforme o quadro abaixo: 1 2 3 4 5 6 7 8 9 10 11 ## coding: utf-8 # Este ~ c um modulo de auto gera~~o de classes django. A AA from django.db import models class Cidade(models.Model): nome = models.CharField(max _length=15) class Estado(models.Model): nome = models.CharField(max_length=25) z ona = models.CharField(max_length=2) 5.3 Diagramas com duas Classes relacionadas O mesmo teste que o anterior, agora testando associaes entre classes. Neste co cas o foi utilizado um relacionamento 1:n, este relacionamento representado pelo e a tributo do tipo ForeignKey da classe Django Figura 5.3: UML representando duas classes relacionadas Neste caso o cdigo gerado semelhante ao do teste 5.2, mas, como pode ser o e visto na linha 12, foi acres centado uma varivel do tipo ForeignKey representando a um relacionamento. 1 2 3 4 5 ## coding: utf-8 # Este ~ c um modulo de auto gera~~o de classes django. A AA from django.db import models

37 6 7 8 9 10 11 12 class Cidade(models.Model): nome = models.CharField(max_length=15) class Estado( models.Model): nome = models.CharField(max_length=25) zona = models.CharField(ma x_length=2) cidade = models.ForeignKey(Cidade) 5.4 Teste de Herana c O teste abaixo foi realizado para representar as heranas de classes Django. So c a representadas trs classes, uma classe principal chamada Pessoa, e outras duas e cl asses que descendem da classe anterior, Fisica e Jur dica. Figura 5.4: UML representando herana c No cdigo gerado, o parser gerou a Classe Pessoa herdando da classe Django o e as cl asses Fisica e Jur dica herdando de Pessoa. 1 2 3 4 5 6 7 8 9 10 11 12 13 # coding: utf-8 # Este ~ c um modulo de auto gera~~o de classes django. A AA from django.db import models class Pessoa(models.Model): nome = models.CharField(max_ length=45) class Fisica(Pessoa): cpf = models.IntegerField() class Juridica(Pess oa): cnpj = models.IntegerField()

38 5.5 Teste m ltiplo u Este exemplo ilustra um sistema real, contendo vrias classes e vrios tipos de a a campos e associaoes. c Figura 5.5: Uml representando vrias classes a O cdigo gerado pode ser visto no qua dro a seguir: o 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # coding: utf-8 # Este ~ c um modulo de auto gera~~o de classes django. A AA from django.db import models class Estado(models.Model): nome = models.CharField(max_ length=10) zona = models.IntegerField() class Usuario(models.Model): username = models.CharField(max_length=10) password = models.CharField(max_length=20) class Cidade(models.Model): nome = models.CharField(max_length=30) estado = models.Fo reignKey(Estado) class Pessoa(models.Model): nome = models.CharField(max_length= 40) cidade = models.ForeignKey(Cidade) usuario = models.ForeignKey(Usuario, uniq ue=True)

39 22 23 24 25 26 27 28 29 30 31 32 33 34 fotos = models.ManyToManyField(Fotos) class Fotos(models.Model): foto = models.I mageField(upload_to=/upload/teste/) data = models.DateField(auto_now_add=True) cla ss PessoaFisica(Pessoa): rg = models.IntegerField() nascimento = models.DateFiel d() class PessoaJuridica(Pessoa): cnpj = models.IntegerField()

40 6 CONCLUSAO 6.1 Validao do projeto ca O principal objetivo deste trabalho foi alcanado. O objetivo central de gerar c u ma 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 herana) foram c extraidos com sucesso. Com a utilizaao do gerador de cdigo, a criaao da camada lgica do sistema c o c o cou muito mais fcil de ser desenvolvida, pois agora o usurio poss ui uma visuaa a lizaao gr ca de todo o sistema, facilitando a visualizaao da estrutur a do sistema c a c a ser desenvolvido. Apesar do sistema conseguir extrair perfeit amente os dados do XMI, os testes mais profundos da ferramenta foram feitos util izando o modelador ArgoUML, por isso, a compatibilidade com outros modeladores, como por exemplo o Umbrello, no a est completamente garantida. a 6.2 Trabalhos Futuros

A intenao que os trabalhos com o parser possam continuar, atravs da criaao c e e c d outros testes utilizando diferentes modeladores UML e comparando seu resultado com o desenvolvido at o momento. e H interesse em disponibilizar o parser como sof tware livre, tendo como principal a meta, a evoluao do sistema adicionando novas funoes, melhorias de performance c c no cdigo e no gerador, uma atualizao do mesmo co poss o ca veis mudanas da c estrutura de modelagem do framework Django Atualmente h uma projeto de implementao de mquina de work ow em a ca a 1 django chamado GoFlow . Uma das possibilidades de trabalho futuro, seria a integrao de diagramas de estado s com uma mquina de work ow. A proposta seca a ria de a partir de diagramas de esta do serem gerados rotinas de work ow, da mesma 1 http://code.google.com/p/go ow/

41 forma que hoje so geradas classes a partir de diagramas de classe. a

42 7 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

<?xml version = 1.0 encoding = UTF-8 ?> <XMI xmi.version = 1.2 xmlns:UML = org.omg.x namespace.UML timestamp = Tue Sep 09 13:16:17 BRT 2008> <XMI.header> <XMI.documenta tion> <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0)</XMI.exporte r> <XMI.exporterVersion>0.24(5) revised on $Date: 2006-11-06 19:55:22 +0100 (Mon , 06 Nov 2006) $ </XMI.exporterVersio </XMI.documentation> <XMI.metamodel xmi.na me="UML" xmi.version="1.4"/></XMI.header> <XMI.content> <UML:Model xmi.id = 127-0 -1-1--2d55673f:11c47d175d4:-8000:000000000000077B name = untitledModel isSpecificat ion = false isRoot = false isLeaf = false isAbstract = false> <UML:Namespace.ownedE t> <UML:Class xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077C name = Cidade visibility = public isSpecification = false isRoot = false isLeaf = fals ract = false isActive = false> <UML:Classifier.feature> <UML:Attribute xmi.id = 127-0 -1-1--2d55673f:11c47d175d4:-8000:000000000000077F name = nome visibility = public isS pecification = false ownerScope = instance changeability = changeable targetScope = tance> <UML:StructuralFeature.multiplicity> <UML:Multiplicity xmi.id = 127-0-1-1-2d55673f:11c47d175d4:-8000:00000000000007BF> <UML:Multiplicity.range> <UML:Multip licityRange xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007BE lower = 1 upper = 1/> </UML:Multiplicity.range> </UML:Multiplicity> </UML:StructuralFeatur e.multiplicity> <UML:StructuralFeature.type> <UML:DataType xmi.idref = 127-0-1-1-2d55673f:11c47d175d4:-8000:0000000000000786/> </UML:StructuralFeature.type> </UM L:Attribute> </UML:Classifier.feature> </UML:Class> <UML:DataType xmi.id = 127-01-1--2d55673f:11c47d175d4:-8000:0000000000000786 name = CharField isSpecification = false isRoot = false isLeaf = false isAbstract = false/> <UML:DataType xmi.id = 1 1--2d55673f:11c47d175d4:-8000:0000000000000787 name = IntegerField isSpecification = false isRoot = false isLeaf = false isAbstract = false/> <UML:Class xmi.id = 127 -2d55673f:11c47d175d4:-8000:0000000000000792 name = Estado visibility = public isSpec ification = false isRoot = false isLeaf = false isAbstract = false isActive = fals Classifier.feature> <UML:Attribute xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000 :0000000000000795 name = nome visibility = public isSpecification = false ownerScope nstance

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 9 9 100 101 102 103 104

changeability = changeable targetScope = instance> <UML:StructuralFeature.multiplici ty> <UML:Multiplicity xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000 07C1> <UML:Multiplicity.range> <UML:MultiplicityRange xmi.id = 127-0-1-1--2d55673f :11c47d175d4:-8000:00000000000007C0 &nbsp; lower = 1 upper = 1/> </UML:Multiplicity.r ange> </UML:Multiplicity> &nbsp; </UML:StructuralFeature.multiplicity&amp;amp;gt ; &amp;nbsp;&nbsp; <UML:StructuralFeature.type> <UML:DataType xmi.idref = 127-0-1 -1--2d55673f:11c47d175d4:-8000:0000000000000786/> </UML:StructuralFeature.type> < /UML:Attribute> <UML:Attribute xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:000 00000000007AF name = zona visibility = public isSpecification = false ownerScope = nce changeability = changeable targetScope = instance> <UML:StructuralFeature.multipl icity> <UML:Multiplicity xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:000000000 00007BD> <UML:Multiplicity.range> <UML:MultiplicityRange xmi.id = 127-0-1-1--2d556 73f:11c47d175d4:-8000:00000000000007BC lower = 1 upper = 1/> </UML:Multiplicity.range > </UML:Multiplicity> </UML:StructuralFeature.multiplicity> <UML:StructuralFeatu re.type> <UML:DataType xmi.idref = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000 00000786/> </UML:StructuralFeature.type> </UML:Attribute> </UML:Classifier.featur e> </UML:Class> <UML:Association xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:0 0000000000007C2 name = isSpecification = false isRoot = false isLeaf = false isAb = false> <UML:Association.connection> <UML:AssociationEnd xmi.id = 127-0-1-1--2d556 73f:11c47d175d4:-8000:00000000000007C3 visibility = public isSpecification = false is Navigable = true ordering = unordered aggregation = composite targetScope = instance ngeability = changeable> <UML:AssociationEnd.multiplicity> <UML:Multiplicity xmi.i d = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C4> <UML:Multiplicity.rang e> <UML:MultiplicityRange xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000 000007C5 lower = 1 upper = 1/> </UML:Multiplicity.range> </UML:Multiplicity> </UML:As sociationEnd.multiplicity> <UML:AssociationEnd.participant> <UML:Class xmi.idref = 127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077C/> </UML:AssociationEnd.p articipant> </UML:AssociationEnd> <UML:AssociationEnd xmi.id = 127-0-1-1--2d55673 f:11c47d175d4:-8000:00000000000007C6 visibility = public isSpecification = false isNa vigable = true ordering = unordered aggregation = none targetScope = instance chang ity = changeable> <UML:AssociationEnd.multiplicity> <UML:Multiplicity xmi.id = 1270-1-1--2d55673f:11c47d175d4:-8000:00000000000007CA> <UML:Multiplicity.range> <UML :MultiplicityRange xmi.id = 127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C 9 lower = 1 upper = -1/> </UML:Multiplicity.range> </UML:Multiplicity> &nbsp;&nbsp; < /UML:AssociationEnd.multiplicity>

44 105 106 107 108 109 110 111 112 113 114 <UML:AssociationEnd.participant> <UML:Class xmi.idref = 127-0-1-1--2d55673f:11c47 d175d4:-8000:0000000000000792/> </UML:AssociationEnd.participant> </UML:Associati onEnd> </UML:Association.connection> </UML:Association> </UML:Namespace.ownedEle ment> </UML:Model> </XMI.content> </XMI>

45 REFERENCIAS BEZERRA, E. Princ pios de Anlise e Projeto de Sistemas com Uml. [S.l.]: a Campus, 2 007. DJANGO. Django the web framework for perfectionists with deadlines. http:// www.djangoproject.com/. LEFF AVRAHAM; RAYFIELD, J. T. Web-Application Developmen t using the Model/View/Controller Design Pattern. , v.1, n.1, 2001. MAURER, I. P ython 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.