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

MARCOS D. PETRY

UML2Django: Gerador de C´digo o para Framework Web MVC

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

Motiva¸˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 ca Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . 13 CONCEITOS PRELIMINARES . . . . . . . . . . . . . . . . . . . . . . 15

Padr˜o de desenvolvimento MVC . . . . . . . . . . . . . . . . . . . 15 a Ferramentas Gr´ficas de Modelagem . . . . . . . . . . . . . . . . . 16 a UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Digramas de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Frameworks de desenvolvimento de aplica¸oes . . . . . . . . . . . 18 c˜ Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Linguagem de programa¸˜o Python . . . . . . . . . . . . . . . . . 19 ca Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 21

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

Caracter´ ısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Persistˆncia de dados (model) . . . . . . . . . . . . . . . . . . . . . . 22 e Visualiza¸ao de dados (view) . . . . . . . . . . . . . . . . . . . . . . . 22 c˜ Controle de dados (Controller) . . . . . . . . . . . . . . . . . . . . . . 23 Fluxo de Execu¸˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 ca

4 IMPLEMENTACAO . . . . . . . . . . . . . . . . . . . . . . . . . . . ¸˜ 4.1 Arquitetura geral da implementa¸˜o proposta . . . . . . . . . . ca 4.2 Parˆmetros XMI utilizados pelo Parser . . . . . . . . . . . . . . a 4.3 Mapeamento de objetos XMI - Django Model . . . . . . . . . . 4.4 An´lise l´xico-sint´tica . . . . . . . . . . . . . . . . . . . . . . . . a e a 4.4.1 Extra¸ao do XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . c˜ 4.5 An´lise semˆntica . . . . . . . . . . . . . . . . . . . . . . . . . . . . a a 4.5.1 Algoritmo de gera¸˜o . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Heran¸a . . . . . . . . . . . . . . . . . . . . . . . . . . . . c 5.5 Teste m´ ltiplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u

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

25 25 25 29 29 31 32 32 35 35 35 36 37 38

˜ 6 CONCLUSAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.1 Valida¸˜o do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 ca 6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7 ANEXOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 45

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

LISTA DE ABREVIATURAS E SIGLAS

DRY GLC HTML HTTP MVC OMG PDF TCC UML URL XML XMI

Don’t repeat yourself Gram´tica Livre-de-Contexto a HyperText Markup Language Hypertext Transfer Protocol Model-view-controller Object Management Group Portable Document Format Trabalho de Conclus˜o de Curso a Unified Modeling Language Uniform Resource 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 Execu¸˜o do Framework Django . . . . . . . . . . . . . 24 ca 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¸a . . . . . . . . . . . . . . c Uml representando v´rias classes . . . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 36 36 37 38

LISTA DE TABELAS

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

RESUMO

O desenvolvimento de aplica¸˜es WEB cresce contantemente e, como conseq¨ˆncia co ue disso, os recursos e as funcionalidades destas aplica¸˜es evolui. Portanto, desenvolco ver aplica¸oes de qualidade em um curto per´ c˜ ıodo de tempo ´ um requisito cada vez e mais valorizado. Uma maneira de melhorar o processo de desenvolvimento e a qualidade das aplica¸oes ´ utilizando frameworks de desenvolvimento. Utilizando frameworks, o c˜ e desenvolvedor pode focar-se de fato, no objetivo principal do sistema, evitando assim, o trabalho repetitivo de outras aplica¸˜es, como por exemplo a constru¸˜o de co ca logins e controles de acesso. Um exemplo de framework que faz este trabalho ´ o e Django. Django constitui-se em um framework web de alto n´ ıvel, escrito em Python, que visa estimular o desenvolvimento r´pido. Apesar de suas in´meras facilidades, o a u Django n˜o possui uma ferramenta de gera¸˜o autom´tica de c´digo a partir de dia ca a o agramas gr´ficos de modelagem, por exemplo. Esta funcionalidade auxiliaria muito a os desenvolvedores que, atualmente, precisam descrever manualmente a camada de modelagem, dificultando tamb´m a documenta¸ao estruturada, como por exemplo e c˜ atrav´s de diagrama de classes e padroniza¸oes ao estilo UML. e c˜ Focado nestas limita¸oes, inerentes a qualquer ferramenta de software livre que c˜ inicia sua evolu¸ao no meio da produ¸ao de aplica¸oes, este trabalho prop˜e uma ferc˜ c˜ c˜ o ramenta que, aliada ao Django, tem a finalidade de gerar a camada de modelagem do framework a partir de diagramas UML. Dessa forma o desenvolvedor consegue criar o Model de forma mais r´pida e f´cil, ao mesmo tempo que mant´m a documenta¸ao 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 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

1

INTRODUCAO ¸˜

A cada dia que passa, a funcionalidade e os recursos dos sistemas produzidos evolui, ao mesmo tempo em que ´ requerido uma maior agilidade no processo de e desenvolvimento dos mesmos. Desenvolver software em um curto per´ ıodo de tempo sempre foi um requisito desej´vel para programadores e empresas. a V´rios requisitos, padr˜es e t´cnicas s˜o criados diariamente, com a finalidade a o e a de aumentar a produ¸˜o e melhorar o processo de constru¸ao de sistemas. Como reca c˜ sultado, foram criados diversas ferramentas e frameworks, v´rios processos e rotinas a repetitivas foram automatizados por eles e o tempo gasto no processo de implementa¸˜o de fato diminuiu. Em geral, um Framework, assim como web frameworks, ca proporcionam uma infraestrutura de programa¸ao para aplica¸˜es, de forma que o c˜ co projetista possa se concentrar na escrita de c´digo eficiente e de f´cil manuten¸ao. o a c˜ Mas ainda h´ diversos pontos a melhorar, ou pelo menos para facilitar o processo de a produ¸ao de c´digo de forma automatizada, como por exemplo gera¸˜o autom´tica c˜ o ca a de c´digo nativo de um framework a partir do esquema de um diagrama de classes. o Os frameworks utilizados atualmente, seguem o padr˜o MVC (LEFF AVRAHAM; RAYa FIELD, 2001), que ´ um padr˜o de arquitetura de aplica¸˜es que visa separar a l´gica e a co o da aplica¸˜o (Model), da interface do usu´rio (View) e do fluxo da aplica¸ao (Conca a c˜ troller). O uso deste tipo de framework permite que a mesma l´gica de neg´cios o o possa ser acessada e visualizada por v´rias interfaces. Neste trabalho adotamos o a framework Django1 (MAURER, 2006), que utiliza o padr˜o MVC e tamb´m sua a e arquitetura de desenvolvimento estimula o desenvolvedor a aproveitar ao m´ximo o a c´digo j´ feito, evitando a repeti¸˜o. o a ca Como o objetivo de melhorar o processo de desenvolvimento com Django, este trabalho prop˜e-se a gerar camada Model do framework Django, atrav´s de c´digos o e o XML’s gerados por editores de diagramas de classe, permitindo assim al´m de aue mentar a velocidade de desenvolvimento de aplica¸˜es, a gera¸ao e documenta¸ao co c˜ c˜ b´sica do sistema. a
1

http://www.djangoproject.com/

12

1.1

Motiva¸˜o ca

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

1.2

Objetivos

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

Figura 1.1: Imagem gerada pelo editor UML

13

2. Gera¸˜o do script XMI, padr˜o da OMG (grupo de gerenciamento de objetos) ca a (OMG, 2007), para troca de informa¸˜es baseado em XML. O uso mais coco mum ´ na troca facilitada de metadados entre as ferramentas de modelagem e (baseadas no UML). Um exemplo 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.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.exporter> <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.version="1.4"/></XMI.header> <XMI.content> <UML:Model xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077B’ name = ’untitledModel’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’> <UML:Namespace.ownedElement> . . . </UML:Namespace.ownedElement> </UML:Model> </XMI.content> </XMI>

3. Tratamento das informa¸˜es do XML e gera¸ao de c´digo no padr˜o do fraco c˜ o a mework Django. O diagrama exemplificado na Figura 1 dever´ produzir o a seguinte c´digo Python no framework Django: o
1 2 3 4 5 6 7 8 9

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

1.3

Estrutura do Documento

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

14

MVC, uma introdu¸ao b´sica sobre a linguagem python e frameworks de desenvolc˜ a vimento. O framework alvo da aplica¸˜o, o Django, ser´ apresentado no cap´ ca a ıtulo 3, onde ser˜o descritos detalhes de seus componentes mais usuais e como o padr˜o MVC ´ a a e aplicado a ele. No capitulo 4, apresentamos o trabalho desenvolvido, onde ´ focado o parser e implementado no projeto, a estrutura do sistema, os elementos relevantes do arquivo XMI, a gram´tica utilizada para ler estes elementos e o processo de tradu¸ao 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 ser˜o traduzidos para c´digo Python do Django atrav´s da a o e ferramenta implementada neste trabalho. O Cap´ ıtulo 6 ´ destinado ` aprecia¸ao das conclus˜es final bem como das altere a c˜ o nativas de continuidade e trabalhos futuros da presente proposta.

15

2

CONCEITOS PRELIMINARES

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

2.1

Padr˜o de desenvolvimento MVC a

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

16

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

2.2

Ferramentas Gr´ficas de Modelagem a

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

2.3

UML

A UML ´ uma linguagem visual para modelar sistemas orientados a objeto. Isso e quer dizer que a UML ´ uma linguagem que define elementos gr´ficos que podem e a ser utilizados na modelagem de sistemas. Esses elementos permitem representar os conceitos de orienta¸˜o a objetos atrav´s dos diagramas criados. Seguindo a nota¸ao ca e c˜ UML, ´ possivel representar diversas perspectivas do sistema. Ainda segundo (BEe ZERRA, 2007), cada elemento grafico da UML possui sintaxe e uma semˆntica. a A sintaxe de um elemento corresponde a forma predeterminada de desenhar o ele` mento. A semˆntica define o que significa o elemento e com que objeto ele deve ser a utilizado. Tanto a sintaxe quanto a semˆntica dos elementos s˜o extens´ a a ıveis. Essa extensibilidade permite 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, colabora¸˜o, seq¨ˆncia, entre outros) o sistema desenvolvido utiliza ca ue somente diagramas de classe, pois ´ o diagrama mais indicado para o prop´sito 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 rela¸oes entre as classes. Cada c˜ classe do diagrama possui um conjunto de objetos: Nome da classe, atributos, relacionamentos e m´todos. e 2.3.1.1 Atributos

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

18

2.3.1.3

M´todos e

M´todos s˜o fun¸oes requeridas a um objeto ou seja, as a¸oes que os objetos de e a c˜ c˜ uma classe pode executar.

2.4

Frameworks de desenvolvimento de aplica¸˜es co

Estamos em uma ´poca onde as informa¸oes s˜o recebidas rapidamente, not´ e c˜ a ıcias de qualquer parte do mundo chegam as pessoas de forma quase instantˆnea. Grande ` a parte dessa informa¸ao ´ veiculada atrav´s da WEB. Para isso o desenvolvimento c˜ e e de aplica¸oes web ´ muito explorado. c˜ e Apesar da quantidade de ferramentas de desenvolvimento ser bastante grande, implementar aplica¸˜es para Internet n˜o ´ algo trivial. Construir uma aplica¸ao co a e c˜ web totalmente funcional a algo bastante trabalhoso. Muitas tarefas s˜o necess´rias a a para que tal feito seja completo: A Configura¸˜o e a cria¸ao de tabelas em base de ca c˜ dados, cria¸˜o de consultas e relacionamentos para as mesmas, gera¸ao de c´digo ca c˜ o HTML, mapear as URL para ler os c´digos, controle de usu´rios, e estes itens s˜o o a a s´ a parte b´sica do desenvolvimento. o a O desenvolvimento para WEB ´ muito repetitivo; os passos a serem seguidos e s˜o praticamente os mesmos para cada nova aplica¸ao a ser criada. Como tentaa c˜ tiva de minimizar ao m´ximo estes repetitivos passos, foram criadas bibliotecas e a frameworks para facilitar o desenvolvimento de aplica¸oes, fazendo com que o dec˜ senvolvedor focalize basicamente o objetivo do novo sistema, deixando a cargo do framework manter as tarefas mais ma¸antes. c Um framework ´ uma camada de abstra¸˜o na qual um determinado conjunto e ca de c´digos implementa uma certa funcionalidade gen´rica, facilmente customizada o e ´ pelo usu´rio, criando assim um funcionalidade expecifica. E fun¸˜o do framework a ca tamb´m, validar o c´digo criado pelo usu´rio. e o a Os frameworks para desenvolvimento web geralmente seguem o padr˜o de arquia tetura de sistema MVC para separar as camadas de neg´cio, persistˆncia 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 peograma¸ao WEB possui os frameworks c˜ CakePHP10 , CodeIgniter11 , Prado12 , symfony13 , Zend14 , entre outros. Perl possui o Catalyst15 , Maypole16 , Jifty17 , e a maioria deles segue o padr˜o MVC. a

2.5

Linguagem de programa¸˜o Python ca

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

Atrav´s dos exemplo abaixo, ´ possivel verificar 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.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

4

20

5

a,b = b,a+b

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

N´meros Primos u

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

C´lculo de Fatorial a

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 r´pido para e a web, escrito em Python, que utiliza o padr˜o MVC (model-view-controller). Foi a criado originalmente como sistema para gerenciar um site jornal´ ıstico na cidade de Lawrence, no Kansas. Tornou-se um projeto de c´digo aberto e foi publicado sob o a licen¸a BSD1 em 2005. O nome Django foi inspirado no m´sico de jazz Django c u Reinhardt. Django utiliza o princ´ ıpio DRY (Don’t Repeat Yourself), onde faz com que o desenvolvedor aproveite ao m´ximo o c´digo j´ feito, evitando a repeti¸ao. a o a c˜ Na se¸ao 3.1, abordaremos as caracter´ c˜ ısticas do framework, onde ser˜o explicados a os componentes principais da ferramenta, tais como Controllers, Templates, Models, Middlewares e URLDispacher. Na se¸ao 3.2 ser´ explicado o fluxo de execu¸ao de c˜ a c˜ uma requisi¸ao no Django. c˜

3.1

Caracter´ ısticas

Atrav´s do ORM2 do Django ´ definida a modelagem de dados atrav´s de classes e e e em Python, clamadas modelos. Com isso ´ poss´ e ıvel independente de qual banco de dados escolhido, gerar suas tabelas e manipular seus dados sem necessidade de utilizar linguagem SQL. Os Models tamb´m possibilitam criar formul´rios autom´ticos e gerar uma intere a a face de administra¸˜o praticamente completa e facilmente configur´vel e extens´ ca a ıvel, aumentando ainda mais o desenvolvimento das aplica¸˜es. co O Django possui uma linguagem de templates muito extens´ e amig´vel. Atrav´s ıvel a e dela ´ possivel fazer a separa¸ao de design, conte´do e c´digo Python. e c˜ u o A figura 3.1 ilustra a estrutura global do Django, exibindo a liga¸ao entre os c˜ componentes principais do framework. Os componentes est˜o classificados 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 Persistˆncia de dados (model) e

A Classe de Modelagem ´ basicamente, a fonte de todos os registros no projeto. e Ele cont´m todos os campos essenciais e rela¸oes de tudo que ´ armazenado no e c˜ e Banco de dados. Geralmente, cada modelo mapeia uma unica tabela de dados. ´ 3.1.2 . A visualiza¸ao dos dados pelos usu´rios ´ feita atrav´s das views e dos templates. c˜ a e e S˜o atrav´s deles que os dados recebidos pelos models s˜o manipulados. Os acessos a e a aos dados s˜o feitos atrav´s das views. a e As views s˜o as se¸oes do site, onde os dados recebidos pela camada de pera c˜ sistˆncia s˜o apresentados, criados, editados e deletados por scripts python. Por e a exemplo, em uma aplica¸ao de um blog, haveriam as seguintes views: c˜ • In´ - exibi¸ao das 5 ultimas postagens; ıcio c˜ ´ • Postagem - p´gina para uma unica entrada; a ´ • Postagem-Coment´rio - coment´rios de uma determinada postagem; a a • Ano-arquivo - exibe todos os meses com as inscri¸oes no ano determinado; c˜ Visualiza¸˜o de dados (view) ca

23

• Mˆs-arquivo - exibe todos os dias com entradas do mˆs em quest˜o; e e a • Dia-arquivo - exibe todas as entradas em determinado dia; O sistema de templates do django ´ um m´dulo que visa separar a apresenta¸˜o dos e o ca dados l´gicos do site. O Template define certos espa¸os onde s˜o definidos la¸os de o c a c repeti¸oes, condicionais e outras funcionalidades do django para manipular vari´veis c˜ a passadas pela view. Normalmente, os templates s˜o utilizados para produzir docua mento HTML, mas os templates do Django s˜o capazes de gerar qualquer formato a de tipo texto tamb´m. e 3.1.3 Controle de dados (Controller)

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

3.2

Fluxo de Execu¸˜o ca

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

3

404 Error. The Page Was Not Found

24

Figura 3.2: Fluxo de Execu¸ao do Framework Django c˜

25

4

IMPLEMENTACAO ¸˜

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

4.1

Arquitetura geral da implementa¸˜o proposta ca

A implementa¸ao do Parser XMI-DjangoModel foi feita inteiramente utilizando c˜ Python, a mesma linguagem do Framework web Django. N˜o foi definida nenhuma a interface gr´fica, pois n˜o h´ necessidade para tal. Basicamente o script recebe a a a como parˆmetro o arquivo XML e gera a classe de modelagem. A Figura 4.1 ilustra a a arquitetura geral do analisador XMI2Django proposta neste trabalho. Os principais modeladores de gr´ficos UML possuem um m´todo de exporta¸ao a e c˜ em arquivo texto para que os diagramas criados possam ser acessados em outro modelador. O m´todo que resulta este texto, est´ escrito em padr˜o XMI, um e a a formato definido pela OMG para representa¸ao, intercˆmbio e compartilhamento de c˜ a objetos, modelos e meta-modelos utilizando XML. Teoricamente, os dados XMI exportados em um modelador, dever˜o ser lidos a em outro sem maiores problemas, logo o parser do trabalho em quest˜o, ir´ gerar a a o c´digo Django independente da ferramenta de modelagem UML utilizada, desde o que ele exporte o arquivo XMI

4.2

Parˆmetros XMI utilizados pelo Parser a

Boa parte das tags contidas no XML gerado pelo editor UML n˜o s˜o utilizadas a a no parser, pois muitas delas s˜o geradas com a finalidade de exporta¸oes para outros a c˜ aplicativos (como por exemplo, outro editor UML). No trabalho em quest˜o s˜o a a utilizadas, para uma gera¸ao correta da classe de modelagem do Django, os seguintes c˜ elementos:

26

Figura 4.1: Estrutura do parser XMI2Django • UML:Namespace.ownedElement O elemento raiz do xmi, ´ onde todos os itens do diagrama em quest˜o e a est˜o inseridos; a • 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´m a tag UML:Attribute; e • UML:Attribute Atributos da classe (name, xmi.id); • UML:ModelElement.taggedValue Tag XMI que cont´m a tag XML:TaggedValue; e • UML:TaggedValue Lista de valores marcados;

27

• UML:TaggedValue.type Tag XMI que cont´m a tag UML:TagDefinition; e • UML:TagDefinition Apontador para o valor marcado (xmi.idref); • UML:TaggedValue.dataValue Valor do Valor Marcado (name); • UML:StructuralFeature.type Tag XMI que cont´m a tag UML:DataType; e • UML:DataType Um apontador para um tipo de dado (xmi.idref); • UML:Association Lista de associa¸oes entre classes; c˜ • UML:Association.connection Tag XMI que cont´m a tag UML:AssociationEnd; e • UML:AssociationEnd Tipo de associa¸ao (Composi¸˜o, agrega¸ao, heran¸a) (aggregation); c˜ ca c˜ c • UML:AssociationEnd.participant Lista de objetos participantes da associa¸ao, para o parser, ele trata apenas c˜ classes; • UML:Class Um apontador para a classe (xmi.idref); • UML:AssociationEnd.multiplicity Tag XMI que cont´m a tag UML:Multiplicity; e • UML:Multiplicity Tag XMI que cont´m a tag UML:Multiplicity.range; e • UML:Multiplicity.range Tag XMI que cont´m a tag UML:MultiplicityRange; e • UML:MultiplicityRange Multiplicidade da associa¸˜o (1 para n, 1 para 1) (lower, upper ); ca

28

• UML:TagDefinition Nome do Valor Marcado (name, xmi.id). Abaixo est´ parte do c´digo XMI gerado pelo editor UML que ´ utilizado pelo a o e parser. Nele est´ modelado o diagrama UML apresentado no cap´ a ıtulo de Introdu¸˜o. 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 c´digo 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’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’ isActive = ’false’> <UML:Classifier.feature> <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077F’ name = ’nome’ visibility = ’public’ isSpecification = ’false’ ownerScope = ’instance’ changeability = ’changeable’ targetScope = ’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:DataType xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000786’ name = ’CharField’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’/> <UML:DataType xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000787’ name = ’IntegerField’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’/> <UML:Class xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000792’ name = ’Estado’ visibility = ’public’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’ isActive = ’false’> <UML:Classifier.feature> <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000795’ name = ’nome’ visibility = ’public’ isSpecification = ’false’ ownerScope = ’instance’ changeability = ’changeable’ targetScope = ’instance’> <UML:StructuralFeature.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’ visibility = ’public’ isSpecification = ’false’ ownerScope = ’instance’ changeability = ’changeable’ targetScope = ’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 = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C2’ name = ’’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’> <UML:Association.connection> <UML:AssociationEnd xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C3’ visibility = ’public’ isSpecification = ’false’ isNavigable = ’true’ ordering = ’unordered’ aggregation = ’composite’ targetScope = ’instance’ changeability = ’changeable’> <UML:AssociationEnd.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:11c47d175d4:-8000:00000000000007C5’ lower = ’1’ upper = ’1’/> </UML:Multiplicity.range> </UML:Multiplicity> </UML:AssociationEnd.multiplicity> <UML:AssociationEnd.participant> <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’ isSpecification = ’false’ isNavigable = ’true’ ordering = ’unordered’ aggregation = ’none’ targetScope = ’instance’ changeability = ’changeable’> <UML:AssociationEnd.multiplicity> <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007CA’> <UML:Multiplicity.range> <UML:MultiplicityRange xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C9’ lower = ’1’ upper = ’-1’/> </UML:Multiplicity.range> </UML:Multiplicity> &nbsp;&nbsp; </UML:AssociationEnd.multiplicity> <UML:AssociationEnd.participant> <UML:Class xmi.idref = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000792’/> </UML:AssociationEnd.participant> </UML:AssociationEnd> </UML:Association.connection> </UML:Association> </UML:Namespace.ownedElement>

4.3

Mapeamento de objetos XMI - Django Model

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

4.4

An´lise l´xico-sint´tica a e a

O parser considerado neste projeto ´ um top-down descendente para gram´ticas e a 1 do tipo LL . Considerando o escopo delimitado na se¸ao 2.2, a gram´tica livre-dec˜ a contexto (GLC) definida aqui compreende apenas a gera¸˜o de produ¸˜es relativas ca co aos componentes de representa¸ao de Classe, atributos e relacionamentos do padr˜o c˜ a XMI. Para tanto, limitamos nossa gram´tica a estas tags espec´ a ıficas. Al´m disso, e n˜o foi criada nenhuma valida¸ao da sintaxe do XMI, pois, partimos do pressuposto a c˜
Left-to-Right, Leftmost derivation com lookahead. Para isto, a gram´tica livre-de-contexto a deve estar livre de recurs˜o 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:TagDefinition, UML:TaggedValue.type, UML:TaggedValue.dataValue

Django Classe Django Atributo da Classe Django Tipo do atributo Gera¸ao de um atributo da classe c˜ Django que representar´ a associa¸˜o, 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 atrav´s de um sistema e j´ consolidado. a Como a estrutura do XMI ´ basicamente uma estrutura em forma de ´rvore, a e a gramatica utilizada no parser ´ bem simples. A seguir apresentamos a GLC proposta e em formato BNF:

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> <UML: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 "=" "’" valor "’" <UML:Classifier.feature> ::= <UML:Attribute> <UML:Attribute> :: = UML:ModelElement.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:TaggedValue.dataValue> ::= name "=" "’" valor "’" <UML:StructuralFeature.type> ::= "UML:DataType" <UML:Association> ::= "UML:Association.connection" <UML:Association.connection> ::= "UML:AssociationEnd" "UML:AssociationEnd.participant" "UML:AssociationEnd.multiplicity" <UML:AssociationEnd> ::= aggregation "=" "’" valor "’" <UML:AssociationEnd.participant> ::= "UML:Class" <UML:AssociationEnd.multiplicity> ::= "UML:Multiplicity.range" <UML:Multiplicity.range> ::= UML:MultiplicityRange <UML:MultiplicityRange> ::= lower "=" "’" valor "’" upper "=" "’" valor "’"

Para auxiliar a extra¸˜o de dados relevantes do XML, foi utilizado o pacote ca padr˜o do Python, o xml.dom.minidom. Com ele foi poss´ tratar os nomes de a ıvel tags e diferen¸as 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 pacote padr˜o da linguagem foi o escolhido. A justificativa desta escolha se deve a ao fato do pacote padr˜o j´ fazer parte da distribui¸˜o atual do Python, sendo a a ca assim, o sistema tende a manter uma maior compatibilidade com futuras vers˜es do o interpretador. 4.4.1 Extra¸˜o do XML ca

A extra¸˜o dos dados ´ feita atrav´s do pacote xml.dom.minidom, como referido ca e e ´ acima, uma implementa¸˜o mais leve da interface DOM4 . E uma implementa¸ao ca c˜ mais simples que o DOM padr˜o e significativamente menor. O Minidom analiza a o c´digo no arquivo XML e cria a estrutura DOM, sendo esta mais f´cil para mao a nipula¸ao dos itens dos arquivos XML. Uma vez tendo o objeto DOM, ´ possivel c˜ e acessar partes de seu documento XML atrav´s das suas propriedades e m´todos. e e 5 Estas propriedades s˜o definidas na especifica¸˜o DOM . A principal propriedade a ca do objeto ´ a documentElement, respons´vel pela extra¸˜o das tags expec´ e a ca ıficas do XML. O exemplo pode ser visto abaixo: >>> from xml.dom import minidom >>> dom = minidom.parseString("<myxml>Some data</myxml>") >>> dom.documentElement.nodeValue >>> print dom.documentElement.tagName u’myxml’ Tamb´m foi criada uma fun¸˜o em Python chamada finditem com a finalidade e ca de buscar e retornar uma lista de itens-filho, de uma tag expec´ ıfica, de acordo com o nome enviado por parˆmetro: a
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¸oes) ´ feita atrav´s 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 == item] raiz = doc.documentElement.getElementsByTagName(’UML:Namespace.ownedElement’)[0] #elemento raiz xmi_tipos = findItem(raiz,"UML:DataType") #lista de tipos lst_tipos = TipoDados(xmi_tipos)

2 3

http://effbot.org/zone/element-index.htm http://www.crummy.com/software/BeautifulSoup/ 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 = TipoTags(xmi_tags) xmi_classes = findItem(raiz,"UML:Class") #lista de classes xmi_associacoes = 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 extra¸ao do nome de identificador e c˜ da classe e tamb´m ´ realizada a busca dos atributos da mesma. e e
1 2 3 4 5 6 7

def findItem(raiz,item): return [x for x in raiz.childNodes if x.nodeName == item] 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 identificador 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: 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´lise semˆntica a a

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

A gera¸ao das classes ´ realizada atrav´s 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 n˜o, pois o c´digo 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.herda_de) else: yield ’class %s(models.Model):’ % cl.nome

Para cada classe, ´ verificado se a mesma possui atributos, cada atributo ´ escrito e e como uma vari´vel da classe recebendo como valor, o tipo de campo Field do Django. a ´ verificado tamb´m se o atributo possui valores marcados, se possuir, estes s˜o E e a escritos como parˆmetros 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 Associa¸oes da classe s˜o geradas de forma semelhante aos atributos, pois s˜o c˜ a a escritas tamb´m como vari´veis da classe. Al´m da verifica¸˜o de valore marcados, e a e ca ´ verificado o tipo de cardinalidade. Se a cardinalidade for “um para muitos” (1:n) e ´ gerado um campo ForeignKey, se for uma rela¸ao “muitos para muitos” (n:n) ´ e c˜ 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¸˜es co e heran¸a. Em todos os casos abaixo foram gerados c´digos, sendo estes perfeitac o mente aplicados no framework.

5.1

Diagramas com uma Classe

Primeiro teste feito com o Parser, e o mais simples, verifica a classe “Pessoa” contida no XML e lista os atributos (nome) e (nascimento), conforme a figura 5.1.

Figura 5.1: UML Representando uma classe O c´digo gerado corresponde a Classe do Django com o nome “Pessoa” e com o as vari´veis (nome) e (nascimento) representando seus 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 A A 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 v´rias classes. Nele a s˜o geradas duas classes, a classe “Cidade”, com um atributo (nome) e a Classe a “Estado” com dois atributos (nome) e (zona)

36

Figura 5.2: UML Representando duas classes sem relacionamento O c´digo gerado cont´m duas classes Django com os nomes “Cidade” e “Estado”. o e A classe “Cidade” possui o atributo (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 A A 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) zona = models.CharField(max_length=2)

5.3

Diagramas com duas Classes relacionadas

O mesmo teste que o anterior, agora testando associa¸˜es entre classes. Neste co caso foi utilizado um relacionamento 1:n, este relacionamento ´ representado pelo e atributo do tipo ForeignKey da classe Django

Figura 5.3: UML representando duas classes relacionadas Neste caso o c´digo gerado ´ semelhante ao do teste 5.2, mas, como pode ser o e visto na linha 12, foi acrescentado uma vari´vel 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 A A 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(max_length=2) cidade = models.ForeignKey(Cidade)

5.4

Teste de Heran¸a c

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

Figura 5.4: UML representando heran¸a c

No c´digo gerado, o parser gerou a Classe “Pessoa” herdando da classe Django o e as classes “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 A A from django.db import models class Pessoa(models.Model): nome = models.CharField(max_length=45) class Fisica(Pessoa): cpf = models.IntegerField() class Juridica(Pessoa): cnpj = models.IntegerField()

38

5.5

Teste m´ ltiplo u

Este exemplo ilustra um sistema real, contendo v´rias classes e v´rios tipos de a a campos e associa¸oes. c˜

Figura 5.5: Uml representando v´rias classes a O c´digo gerado pode ser visto no quadro 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 A A 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.ForeignKey(Estado) class Pessoa(models.Model): nome = models.CharField(max_length=40) cidade = models.ForeignKey(Cidade) usuario = models.ForeignKey(Usuario, unique=’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.ImageField(upload_to=’/upload/teste/’) data = models.DateField(auto_now_add=True) class PessoaFisica(Pessoa): rg = models.IntegerField() nascimento = models.DateField() class PessoaJuridica(Pessoa): cnpj = models.IntegerField()

40

6

˜ CONCLUSAO

6.1

Valida¸˜o do projeto ca

O principal objetivo deste trabalho foi alcan¸ado. O objetivo central de gerar c 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¸a) foram c extraidos com sucesso. Com a utiliza¸ao do gerador de c´digo, a cria¸ao da camada l´gica do sistema c˜ o c˜ o ficou muito mais f´cil de ser desenvolvida, pois agora o usu´rio possui uma visuaa a liza¸ao gr´fica de todo o sistema, facilitando a visualiza¸ao da estrutura do sistema c˜ a c˜ 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˜o a est´ completamente garantida. a

6.2

Trabalhos Futuros

A inten¸ao ´ que os trabalhos com o parser possam continuar, atrav´s da cria¸ao c˜ e e c˜ de outros testes utilizando diferentes modeladores UML e comparando seu resultado com o desenvolvido at´ o momento. e H´ interesse em disponibilizar o parser como software livre, tendo como principal a meta, a evolu¸ao do sistema adicionando novas fun¸oes, melhorias de performance c˜ c˜ no c´digo e no gerador, uma atualiza¸˜o do mesmo com poss´ o ca ıveis mudan¸as da c estrutura de modelagem do framework Django Atualmente h´ uma projeto de implementa¸˜o de m´quina de workflow em a ca a 1 django chamado GoFlow . Uma das possibilidades de trabalho futuro, seria a integra¸˜o de diagramas de estados com uma m´quina de workflow. A proposta seca a ria 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˜o 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.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.exporter> <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.name="UML" xmi.version="1.4"/></XMI.header> <XMI.content> <UML:Model xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077B’ name = ’untitledModel’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’> <UML:Namespace.ownedElement> <UML:Class xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077C’ name = ’Cidade’ visibility = ’public’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’ isActive = ’false’> <UML:Classifier.feature> <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:000000000000077F’ name = ’nome’ visibility = ’public’ isSpecification = ’false’ ownerScope = ’instance’ changeability = ’changeable’ targetScope = ’instance’> <UML:StructuralFeature.multiplicity> <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007BF’> <UML:Multiplicity.range> <UML:MultiplicityRange xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007BE’ lower = ’1’ upper = ’1’/> </UML:Multiplicity.range> </UML:Multiplicity> </UML:StructuralFeature.multiplicity> <UML:StructuralFeature.type> <UML:DataType xmi.idref = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000786’/> </UML:StructuralFeature.type> </UML:Attribute> </UML:Classifier.feature> </UML:Class> <UML:DataType xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000786’ name = ’CharField’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’/> <UML:DataType xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000787’ name = ’IntegerField’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’/> <UML:Class xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000792’ name = ’Estado’ visibility = ’public’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’ isActive = ’false’> <UML:Classifier.feature> <UML:Attribute xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000795’ name = ’nome’ visibility = ’public’ isSpecification = ’false’ ownerScope = ’instance’

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’> <UML:StructuralFeature.multiplicity> <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C1’> <UML:Multiplicity.range> <UML:MultiplicityRange xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C0’ &nbsp; lower = ’1’ upper = ’1’/> </UML:Multiplicity.range> </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:00000000000007AF’ name = ’zona’ visibility = ’public’ isSpecification = ’false’ ownerScope = ’instance’ changeability = ’changeable’ targetScope = ’instance’> <UML:StructuralFeature.multiplicity> <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007BD’> <UML:Multiplicity.range> <UML:MultiplicityRange xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007BC’ lower = ’1’ upper = ’1’/> </UML:Multiplicity.range> </UML:Multiplicity> </UML:StructuralFeature.multiplicity> <UML:StructuralFeature.type> <UML:DataType xmi.idref = ’127-0-1-1--2d55673f:11c47d175d4:-8000:0000000000000786’/> </UML:StructuralFeature.type> </UML:Attribute> </UML:Classifier.feature> </UML:Class> <UML:Association xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C2’ name = ’’ isSpecification = ’false’ isRoot = ’false’ isLeaf = ’false’ isAbstract = ’false’> <UML:Association.connection> <UML:AssociationEnd xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C3’ visibility = ’public’ isSpecification = ’false’ isNavigable = ’true’ ordering = ’unordered’ aggregation = ’composite’ targetScope = ’instance’ changeability = ’changeable’> <UML:AssociationEnd.multiplicity> <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C4’> <UML:Multiplicity.range> <UML:MultiplicityRange xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C5’ lower = ’1’ upper = ’1’/> </UML:Multiplicity.range> </UML:Multiplicity> </UML:AssociationEnd.multiplicity> <UML:AssociationEnd.participant> <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’ isSpecification = ’false’ isNavigable = ’true’ ordering = ’unordered’ aggregation = ’none’ targetScope = ’instance’ changeability = ’changeable’> <UML:AssociationEnd.multiplicity> <UML:Multiplicity xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007CA’> <UML:Multiplicity.range> <UML:MultiplicityRange xmi.id = ’127-0-1-1--2d55673f:11c47d175d4:-8000:00000000000007C9’ 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:11c47d175d4:-8000:0000000000000792’/> </UML:AssociationEnd.participant> </UML:AssociationEnd> </UML:Association.connection> </UML:Association> </UML:Namespace.ownedElement> </UML:Model> </XMI.content> </XMI>

45

ˆ REFERENCIAS

BEZERRA, E. Princ´ ıpios de An´lise e Projeto de Sistemas com Uml. [S.l.]: a 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.

Sign up to vote on this title
UsefulNot useful