UML2Django: Gerador de Código para Framework Web MVC

Transcrição

1 UNIVERSIDADE DE CAXIAS DO SUL DEPARTAMENTO DE INFORMÁTICA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO MARCOS D. PETRY UML2Django: Gerador de Código para Framework Web MVC Prof. João L. Tavares Orientador Caxias do Sul, Dezembro de 2008

2 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

3 AGRADECIMENTOS Agradeço a Deus por ter me dado forças para concluir este curso, me revitalizando em todos os momentos de fraqueza. Aos meus pais Ivan Luiz e Iana Fátima, por me entenderem a minha ausência devido ao trabalho e aos estudo, não deixaram de estar do meu lado me apoiado incondicionalmente. Ao meu orientador, Professor João Luiz Tavares, pela paciência, sabedoria, pelas suas correções e incentivo durante a implementação do trabalho e redação da monografia. A Universidade de Caxias do Sul, e ao docentes do departamento de informática, que durante os 7 anos de vida acadêmica nesta instituição, tive a honra de ser aluno. 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 precisei e me mostrando que a vida não é só trabalho e estudo. 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 presentes em momentos complicados. E por último, mas não menos importante, agradeço a minha querida e amada namorada Letícia, por ter me ajudado onde podia e ter me apoiado e me entendido em momentos difíceis com muito amor e carinho.

4 SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS LISTA DE FIGURAS LISTA DE TABELAS RESUMO RESUMO INTRODUÇÃO Motivação Objetivos Estrutura do Documento CONCEITOS PRELIMINARES Padrão de desenvolvimento MVC Ferramentas Gráficas de Modelagem UML Digramas de Classe Frameworks de desenvolvimento de aplicações Exemplos Linguagem de programação Python Exemplos DJANGO Características Persistência de dados (model) Visualização de dados (view) Controle de dados (Controller) Fluxo de Execução

5 4 IMPLEMENTAÇÃO Arquitetura geral da implementação proposta Parâmetros XMI utilizados pelo Parser Mapeamento de objetos XMI - Django Model Análise léxico-sintática Extração do XML Análise semântica Algoritmos de geração EXPERIMENTOS E RESULTADOS Uma Classe Duas Classes sem relacionamento duas Classes relacionadas Teste de Herança Teste multiplo CONCLUSÃO Validação do projeto Trabalhos Futuros ANEXOS REFERÊNCIAS

6 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 HyperText Markup Language Hypertext Transfer Protocol Model-view-controller Object Management Group Portable Document Format Trabalho de Conclusão de Curso Unified Modeling Language Uniform Resource Locator Extensible Markup Language XML Metadata Interchange

7 LISTA DE FIGURAS Figura 1.1: Imagem gerada pelo editor UML Figura 3.1: Estrutura do framework Django Figura 3.2: Fluxo de Execução do Framework Django Figura 4.1: Estrutura do parser XMI2Django Figura 4.2: Diagrama de classes do sistema Figura 5.1: UML Representando uma classe Figura 5.2: UML Representando duas classes sem relacionamento Figura 5.3: UML representando duas classes relacionadas Figura 5.4: UML representando herança Figura 5.5: Uml representando várias classes

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

9 RESUMO O desenvolvimento de aplicações WEB cresce contantemente e, como conseqüência disso, os recursos e as funcionalidades destas aplicações evolui. Portanto, desenvolver aplicações de qualidade em um curto período de tempo é um requisito cada vez mais valorizado. Uma maneira de melhorar o processo de desenvolvimento e a qualidade das aplicações é utilizando frameworks de desenvolvimento. Utilizando frameworks, o desenvolvedor pode focar-se de fato, no objetivo principal do sistema, evitando assim, o trabalho repetitivo de outras aplicações, como por exemplo a construção de logins e controles de acesso. Um exemplo de framework que faz este trabalho é o 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 Django não possui uma ferramenta de geração automática de código a partir de diagramas gráficos de modelagem, por exemplo. Esta funcionalidade auxiliaria muito os desenvolvedores que, atualmente, precisam descrever manualmente a camada de modelagem, dificultando também a documentação estruturada, como por exemplo através de diagrama de classes e padronizações ao estilo UML. Focado nestas limitações, inerentes a qualquer ferramenta de software livre que inicia sua evolução no meio da produção de aplicações, este trabalho propõe uma ferramenta que, aliada ao Django, tem a finalidade de gerar a camada de modelagem do framework a partir de diagramas UML. Dessa forma o desenvolvedor consegue criar o Model de forma mais rápida e fácil, ao mesmo tempo que mantém a documentação de classes de seu sistema. Palavras-chave: UML, VMC, Django, Framework, Python.

10 RESUMO he development of the applications WEB grows constantly, and, as a consequence of that, the resources and the functionalities of these applications evolves. Therefore, to develop applications of quality in a short period of time is a requirement each time more valuable. A way to improve the process of development and the quality of the applications, is using frameworks of development. Using frameworks, the developer can actually be focused in the main objective of the system, preventing, the repetitive work of other applications, as for example, the construction of logins and controls of access. An example of framework that makes this work is the Django. Django consists in a framework web of high level, writing in Python, that aims at 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 diagram s and standardizations of UML s style. Focused in these limitations, inherent to any tool of free software that initiates its evolution in the way of the production of applications, this work proposes a tool that, allied to the Django, has the object to generate the layer of modeling of framework from diagrams UML. In this way, the deleloper acchieve to create the Model of a faster and easy form, at the same time that it keeps the documentation of classes of its system. Palavras-chave: T.

11 11 1 INTRODUÇÃO 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 desenvolvimento dos mesmos. Desenvolver software em um curto período de tempo sempre foi um requisito desejável para programadores e empresas. Vários requisitos, padrões e técnicas são criados diariamente, com a finalidade de aumentar a produção e melhorar o processo de construção de sistemas. Como resultado, foram criados diversas ferramentas e frameworks, vários processos e rotinas 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, proporcionam uma infraestrutura de programação para aplicações, de forma que o projetista possa se concentrar na escrita de código eficiente e de fácil manutenção. Mas ainda há diversos pontos a melhorar, ou pelo menos para facilitar o processo de produção de código de forma automatizada, como por exemplo geração automática de código nativo de um framework a partir do esquema de um diagrama de classes. Os frameworks utilizados atualmente, seguem o padrão MVC (LEFF AVRA- HAM; RAYFIELD, 2001), que é um padrão de arquitetura de aplicações que visa separar a lógica da aplicação (Model), da interface do usuário (View) e do fluxo da aplicação (Controller). O uso deste tipo de framework permite que a mesma lógica de negócios possa ser acessada e visualizada por várias interfaces. Neste trabalho adotamos o framework Django 1 (MAURER, 2006), que utiliza o padrão MVC e também sua arquitetura de desenvolvimento estimula o desenvolvedor a aproveitar ao máximo o código já feito, evitando a repetição. 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 XML s gerados por editores de diagramas de classe, permitindo assim além de aumentar a velocidade de desenvolvimento de aplicações, a geração e documentação básica do sistema. 1

12 Motivação O Framework escolhido, o Django, recentemente ganhou bastante notoriedade no mundo do software livre, devido a sua praticidade no desenvolvimento de aplicações, foi adotado em diversas empresas e instituições, como por exemplo o Google, Governo Brasileiro e a Universidade de Caxias do Sul. Django é um framework web de alto nível escrito em Python que estimula o desenvolvimento rápido e limpo, concentrando-se no máximo de automatização possível, aderindo ao princípio DRY (Don t repeat yourself). Eliminando processos repetitivos como criação e autenticação de formulários e também a geração automática de interface de administração, mecanismos de cache e internacionalização. Atualmente, o desenvolvimento de aplicações em Django não possui nenhuma ferramenta que gere código a partir de ferramentas de modelagem, a camada de modelagem é escrita manualmente. Desse modo, se a equipe necessitar de algum tipo de documentação, como por exemplo um diagrama de classes, ela terá que repetir o processo de construção. 1.2 Objetivos O objetivo principal deste trabalho é o desenvolvimento de uma ferramenta para a geração automática de código Python a partir da modelização de diagramas gerados por ferramentas de modelagem UML. Esta ferramenta visa o aumento de produtividade e também a diminuição da possibilidade de erros de codificação. Nesta proposta, trataremos da implementação desta ferramenta, integrada ao framework Django, com o objetivo de gerar a classe de modelagem do framework web a partir dos diagramas de classes criados pela ferramenta de criação de modelos UML. Basicamente o processo desta geração segue os seguintes passos: 1. Construção dos diagramas de classes em uma interface gráfica (ex. ArgoUML, Umbrello), Por exemplo, o projeto de um diagrama de classes com seus respectivos componentes para definição de atributos, relacionamentos, cardinalidades, etc, conforme a Figura 1, abaixo: Figura 1.1: Imagem gerada pelo editor UML

13 13 2. Geração do script XMI, padrão da OMG (grupo de gerenciamento de objetos) (OMG, 2007), para troca de informações baseado em XML. O uso mais comum é na troca facilitada de metadados entre as ferramentas de modelagem (baseadas no UML). Um exemplo de um fragmento de script XMI é ilustrado abaixo: 1 <?xml version = 1.0 encoding = UTF-8?> 2 <XMI xmi.version = 1.2 xmlns:uml = org.omg.xmi.namespace.uml 3 timestamp = Tue Sep 09 13:16:17 BRT 2008 > 4 <XMI.header> <XMI.documentation> 5 <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0)</XMI.exporter> 6 <XMI.exporterVersion>0.24(5) revised on $Date: :55: (Mon, 06 Nov 2006) $ </XMI.exporterVersion> 8 </XMI.documentation> 9 &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;nbsp; <XMI.metamodel xmi.name="uml" 10 xmi.version="1.4"/></xmi.header> 11 <XMI.content> 12 <UML:Model xmi.id = d55673f:11c47d175d4:-8000: B 13 name = untitledmodel isspecification = false isroot = false isleaf = false 14 isabstract = false > 15 <UML:Namespace.ownedElement> </UML:Namespace.ownedElement> 20 </UML:Model> 21 </XMI.content> 22 </XMI> 3. Tratamento das informações do XML e geração de código no padrão do framework Django. O diagrama exemplificado na Figura 1 deverá produzir o seguinte código Python no framework Django: 1 class Pessoa_ (models.Model): 2 endereco = Field() 3 4 class Pessoa(models.Model): 5 nome = models.charfield() 6 cidade = models.charfield() 7 nascimento = models.datefield() 8 enviar_mail = models.booleanfield() 9 endereco = models.foreignkey(pessoa_ ) 1.3 Estrutura do Documento O presente trabalho está dividido em 6 capítulos:. O capítulo 1 apresenta uma introdução do trabalho, bem como a motivação, os objetivos, ferramentas de apoio e a estrutura do documento. No Capítulo 2, serão abordados alguns conceitos preliminares necessários para um melhor entendimento trabalho, onde apresentamos o padrão de desenvolvimento

14 14 MVC, uma introdução básica sobre a linguagem python e frameworks de desenvolvimento. O framework alvo da aplicação, o Django, será apresentado no capítulo 3, onde serão descritos detalhes de seus componentes mais usuais e como o padrão MVC é aplicado a ele. No capitulo 4, apresentamos o trabalho desenvolvido, onde é focado o parser 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ção para a sintaxe da classe Django. O capítulo 5 é destinado a apresentar os testes com o sistema, onde diversos diagramas de classes serão traduzidos para código Python do Django através da ferramenta implementada neste trabalho. O Capítulo 6 é destinado à apreciação das conclusões final bem como das alternativas de continuidade e trabalhos futuros da presente proposta.

15 15 2 CONCEITOS PRELIMINARES Neste Capítulo, introduziremos alguns conceitos fundamentais necessários ao entendimento dos componentes utilizados no trabalho. Na seção 2.1 apresentamos uma breve introdução sobre o padrão de desenvolvimento MVC. Introduzimos algumas explicações sobre UML na seção 2.2. Na seção 2.3 serão abordados definições sofre frameworks. Concluindo o capítulo, será feita uma breve explicação sobre Python, a linguagem utilizada neste trabalho. 2.1 Padrão de desenvolvimento MVC MVC é um padrão de arquitetura de aplicações que visa separar a lógica da aplicação (Model), da interface do usuário (View) e do fluxo da aplicação (Controller). Permite que a mesma lógica de negócios possa ser acessada e visualizada por várias interfaces. O MVC também é utilizado em padrões de projetos de software, entretanto, MVC abrange mais da arquitetura de uma aplicação do que é típico para um padrão de projeto. Em um projeto de software baseado no padrão MVC, define-se uma arquitetura básica com 3 camadas possivelmente abstratas: Model: Implementa o modelo representando a estrutura de baixo nível do projeto, podendo ser o modelo objeto-relacional que implementa a camada de dados. Um caso de MVC de Interface poderia guardar informações de estado dos controllers, por exemplo; Controller: Implementa a camada responsável pelo gerenciamentos de eventos no projeto, tais como cliques do usuário, chamando a camada Model para processar os eventos. Também pode manter informações de estado do usuário na aplicação; View: Gera a interface com usuário de modo que esta somente requisite o processamento de eventos pelo Controller;

16 16 Segundo (BEZERRA, 2007), Model-view-controller (MVC) é um padrão de arquitetura de software. Com o aumento da complexidade das aplicações desenvolvidas torna-se fundamental a separação entre os dados (Model) e o layout (View). Desta forma, alterações feitas no layout não afetam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout. O model-view-controller resolve este problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interação com o utilizador, introduzindo um componente entre os dois: o Controller. MVC é usado em padrões de projeto de software, mas MVC abrange mais da arquitetura de uma aplicação do que é típico para um padrão de projeto. 2.2 Ferramentas Gráficas de Modelagem A escolha de ferramentas de Geração de Diagramas de classes foi definida tendo como base dois critérios: ser software livre e possuir exportação para XMI. Foram encontradas as seguintes ferramentas que possuem estes requisitos: ArgoUML 1 e Umbrello 2. Umbrello UML Modeller permite a modelização de software através de diagramas UML (Unified Modeling Language) originalmente para o ambiente KDE-Linux, com extensões recentes para Windows e MAC. Umbrello manipula todos os tipos de diagramas UML e é capaz de gerar código para algumas linguagens como Java, C++, Python, PHP, entre outras. No entanto, o código Python gerado a partir dos diagramas do Umbrello ainda não são compatíveis com o framework Django, necessitanto algumas adaptações manuais que, dependendo do tamanho do projeto, pode tornar inviável sua execução. ArgoUML é um software para modelagem UML escrito em Java. Possibilitando ser instalado em qualquer plataforma com suporte a esta tecnologia. Possui suporte completo para UML 1.4 padrão e oferece excelentes métodos para criação e manipulação dos seus diagramas em UML. Oferece suporte para geração de código Java nativo e outras linguagens (C++, C# e PHP) através de plugins disponibilizados em seu site. Infelizmente, a exportação para código Python está somente nos planos de seus desenvolvedores. As ferramentas acima salvam o diagrama no formato padrão XMI (XML Metadata Interchange) (OMG, 2007), que segundo Eduardo Bezerra, define XMI como sendo: um padrão baseado em XML para exportar modelos definidos em UML. Esse padrão é importante, pois permite a interoperabilidade

17 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 padrão XMI (BEZERRA, 2007) 2.3 UML A UML é uma linguagem visual para modelar sistemas orientados a objeto. Isso quer dizer que a UML é uma linguagem que define elementos gráficos que podem 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ção UML, é possivel representar diversas perspectivas do sistema. Ainda segundo (BEZ- ERRA, 2007), cada elemento grafico da UML possui sintaxe e uma semântica. A sintaxe de um elemento corresponde à forma predeterminada de desenhar o elemento. A semântica define o que significa o elemento e com que objeto ele deve ser utilizado. Tanto a sintaxe quanto a semântica dos elementos são extensíveis. Essa extensibilidade permite que a UML sejá adaptada às caracterí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 somente diagramas de classe, pois é o diagrama mais indicado para o propósito do mesmo Digramas de Classe Um diagrama de classes basicamente descreve a estrutura de um sistema, mostrando as classes implantadas, seus atributos, e as relações entre as classes. Cada classe do diagrama possui um conjunto de objetos: Nome da classe, atributos, relacionamentos e métodos Atributos Definição das características da classe, cada elemento de sua lista de atributos possui um nome e um tipo de dado Relacionamentos Um relacionamento representa uma ligação entre classes, é uma ligação binaria (com duas extremidades) onde cada extremidade é ligada a uma classe, através de uma linha. Existem diferentes tipos de relacionamento: Agregação, composição, Herança.

18 Métodos Métodos são funções requeridas a um objeto ou seja, as ações que os objetos de uma classe pode executar. 2.4 Frameworks de desenvolvimento de aplicações Estamos em uma época onde as informações são recebidas rapidamente, notícias de qualquer parte do mundo chegam às pessoas de forma quase instantânea. Grande parte dessa informação é veiculada através da WEB. Para isso o desenvolvimento de aplicações web é muito explorado. Apesar da quantidade de ferramentas de desenvolvimento ser bastante grande, implementar aplicações para Internet não é algo trivial. Construir uma aplicação web totalmente funcional a algo bastante trabalhoso. Muitas tarefas são necessárias para que tal feito seja completo: A Configuração e a criação de tabelas em base de dados, criação de consultas e relacionamentos para as mesmas, geração de código HTML, mapear as URL para ler os códigos, controle de usuários, e estes itens são só a parte básica do desenvolvimento. O desenvolvimento para WEB é muito repetitivo; os passos a serem seguidos são praticamente os mesmos para cada nova aplicação a ser criada. Como tentativa de minimizar ao máximo estes repetitivos passos, foram criadas bibliotecas e frameworks para facilitar o desenvolvimento de aplicações, fazendo com que o desenvolvedor focalize basicamente o objetivo do novo sistema, deixando a cargo do framework manter as tarefas mais maçantes. Um framework é uma camada de abstração na qual um determinado conjunto de códigos implementa uma certa funcionalidade genérica, facilmente customizada pelo usuário, criando assim um funcionalidade expecifica. É função do framework também, validar o código criado pelo usuário. Os frameworks para desenvolvimento web geralmente seguem o padrão de arquitetura de sistema MVC para separar as camadas de negócio, persistência e interface 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 Django, Tur- 3

19 19 bogears 4, Pylons 5, Zope 6 /Plone 7, web2py 8 entre outros. PHP 9 que é uma das mais utilizadas linguagens para peogramação WEB possui os frameworks CakePHP 10, CodeIgniter 11, Prado 12, symfony 13, Zend 14, entre outros. Perl possui o Catalyst 15, Maypole 16, Jifty 17, e a maioria deles segue o padrão MVC. 2.5 Linguagem de programação Python Python 18 é uma linguagem de programação de alto nível, interpretada, interativa, orientada à objetos e de tipagem dinâmica e forte, lançada por Guido van Rossum em Atualmente possui um modelo de desenvolvimento comunitário e aberto gerenciado pela organização sem fins lucrativos Python Software Foundation. Apesar de várias partes da linguagem possuírem padrões e especificações formais, a linguagem como um todo não é formalmente especificada. O padrão de implementação é o CPython, o que significa que foi desenvolvida a partir da linguagem C, mas existe também as variantes Jython e IronPython que são reimplementação do Python produzidas em Java e.net respectivamente. A linguagem foi projetada com a filosofia de enfatizar a importância do esforço do programador sobre o esforço computacional. Prioriza a legibilidade do código sobre a 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 terceiros Exemplos Através dos exemplo abaixo, é possivel verificar a simplicidade da linguagem: Fibonacci 1 a =1 2 b =1 3 while a < 800: 4 print a,

20 20 5 a,b = b,a+b Números Primos 1 ehprimo = True 2 numero = input ( " Informe o numero : " ) 3 i = 2 4 while i < numero : 5 if numero % i == 0: 6 ehprimo = False 7 break 8 i += 1 9 if ehprimo : 10 print " Primo : ", numero 11 else : 12 print numero, possui fator, i Cálculo de Fatorial 1 n = int ( raw_input ( " Fatorial de : " )) 2 fatorial = 1 3 print " % d! = " %n, 4 i = n 5 while i > 0: 6 fatorial = fatorial * i 7 print " % d " %i, 8 if i!= 1: print ". ", 9 i -= 1

21 21 3 DJANGO Django (DJANGO, 2008) é um framework para desenvolvimento rápido para web, escrito em Python, que utiliza o padrão MVC (model-view-controller). Foi criado originalmente como sistema para gerenciar um site jornalístico na cidade de Lawrence, no Kansas. Tornou-se um projeto de código aberto e foi publicado sob a licença BSD 1 em O nome Django foi inspirado no músico de jazz Django 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ção. Na seção 3.1, abordaremos as características do framework, onde serão explicados os componentes principais da ferramenta, tais como Controllers, Templates, Models, Middlewares e URLDispacher. Na seção 3.2 será explicado o fluxo de execução de uma requisição no Django. 3.1 Características Através do ORM 2 do Django é definida a modelagem de dados através de classes em Python, clamadas modelos. Com isso é possível independente de qual banco de dados escolhido, gerar suas tabelas e manipular seus dados sem necessidade de utilizar linguagem SQL. Os Models também possibilitam criar formulários automáticos e gerar uma interface de administração praticamente completa e facilmente configurável e extensível, aumentando ainda mais o desenvolvimento das aplicações. O Django possui uma linguagem de templates muito extensível e amigável. Através dela é possivel fazer a separação de design, conteúdo e código Python. A figura 3.1 ilustra a estrutura global do Django, exibindo a ligação entre os componentes principais do framework. Os componentes estão classificados em cores, representando as camadas do sistema Object-Relational Mapping

22 22 Figura 3.1: Estrutura do framework Django Persistência de dados (model) A Classe de Modelagem é basicamente, a fonte de todos os registros no projeto. Ele contém todos os campos essenciais e relações de tudo que é armazenado no Banco de dados. Geralmente, cada modelo mapeia uma única tabela de dados Visualização de dados (view). A visualização dos dados pelos usuário é feita através das views e do templates. São através deles que os dados recebidos pelos models são manipulados. Os acessos aos dados são feitos através das views. As views são as seções do site, onde os dados recebidos pela camada de persistência são apresentados, criados, editados e deletados por scripts python. Por exemplo, em uma aplicação de um blog, haveria as seguintes views: Inicio - exibição das 5 últimas postagens; Postagem - página para uma única entrada; Postagem-Comentário - comentários de umas determinada postagem; Ano-arquivo - exibe todos os meses com as inscrições no ano determinado;

23 23 Mês-arquivo - exibe todos os dias com entradas do mês em questão; 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 dados lógicos do site. O Template define certo espaços onde são definidos laços de repetições, condicionais e outras funcionalidades do django para manipular variáveis passadas pela view. Normalmente, os templates são utilizados para produzir documento HTML, mas os templates do Django são capazes de gerar qualquer formato de tipo texto também Controle de dados (Controller) Entre a camada de visualização e o usuário, há a camada de controle, responsável pelo processamento de ações de requisições e resposta do usuário (HTTP Request e 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ções feitas pelo usuário. Através dele é possível enviar informações para view de forma transparente ao usuário como, por exemplo, detalhes sobre seções e autenticação. Depois de passar pelos middlewares, a requisição é analisada pelo URL Dispatcher, que verifica o endereço que o usuário acessa e verifica se o mesmo conta no arquivo de URLs da aplicação. Cada URL está associada a uma view, se a URL requisitada não se encontra no arquivo um erro do tipo é informado. 3.2 Fluxo de Execução Através de um browser, o usuário faz uma requisição a um site Django, de acordo com a URL informada. O Framework verifica se a mesma está nos seus registros de URL. Após a localização da URL, uma view correspondente é invocada, a view requisita informações à classe de modelagem que devolve os dados. Com os dados recebidos da classe de modelagem, o Django armazena em variáveis e envia para um template. O template recebe as variáveis da view e renderiza o template no formato desejado (HTML, PDF). A página renderizada é exibida na tela para o usuário. O processo detalhado pode ser visto na Figura Error. The Page Was Not Found

24 24 Figura 3.2: Fluxo de Execução do Framework Django

25 25 4 IMPLEMENTAÇÃO Neste Capítulo abordamos a implementação da proposta de geração de código python no framework Django a partir de modelos de diagramas de classes. Na seção 4.1 introduzimos a arquitetura geral do sistema proposto, mostrando seus componentes principais e seus relacionamentos. Na seção 4.2 mostramos a delimitação do escopo dos elementos XMI tratados pelo nosso gerador. 4.1 Arquitetura geral da implementação proposta A implementação do Parser XMI-DjangoModel foi feita inteiramente utilizando Python, a mesma linguagem do Framework web Django. Não foi definida nenhuma interface gráfica, pois não há necessidade para tal. Basicamente o script recebe como parâmetro o arquivo XML e gera a classe de modelagem. Figura 4.1: Estrutura do parser XMI2Django

26 26 Os principais modeladores de gráficos UML possuem um método de exportação 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 formato definido pela OMG para representação, intercâmbio e compartilhamento de objetos, modelos e meta-modelos utilizando XML. Teoricamente, os dados XMI exportados em um modelador, deverão ser lidos em outro sem maiores problemas, logo o parser do trabalho em questão, irá gerar o código Django independente da ferramenta de modelagem UML utilizada, desde que ele exporte o arquivo XMI 4.2 Parâmetros XMI utilizados pelo Parser Boa parte das tags contidas no XML gerado pelo editor UML não são utilizadas no parser, pois muitas delas são geradas com a finalidade de exportações para outros aplicativos (como por exemplo, outro editor UML). No trabalho em questão são utilizadas, para uma geração correta da classe de modelagem do Django os sequintes elementos: UML:Namespace.ownedElement O elemento raiz do xmi, é onde todos os itens do diagrama em questão estão inseridos; UML:DataType Lista de tipos de dados (name, xmi.id); UML:Class Classes do diagrama de classes (name, xmi.id); UML:Classifier.feature Tag XMI que contem a tag UML:Attribute; UML:Attribute Atributos da classe (name, xmi.id); UML:ModelElement.taggedValue Tag XMI que contem a tag XML:TaggedValue; UML:TaggedValue Lista de valores marcados;

27 27 UML:TaggedValue.type Tag XMI que contem a tag UML:TagDefinition; UML:TagDefinition Apontador para o valor marcado (xmi.idref); UML:TaggedValue.dataValue Valor do Valor Marcado (name); UML:StructuralFeature.type Tag XMI que contem a tag UML:DataType; UML:DataType Um apontador para um tipo de dado (xmi.idref); UML:Association Lista de associações entre classes; UML:Association.connection Tag XMI que contem a tag UML:AssociationEnd; UML:AssociationEnd Tipo de associação (Composição, agregação, herança) (aggregation); UML:AssociationEnd.participant Lista de objetos participantes da associação, para o parser, ele trata apenas classes; UML:Class Um apontador para a classe (xmi.idref); UML:AssociationEnd.multiplicity Tag XMI que contem a tag UML:Multiplicity; UML:Multiplicity Tag XMI que contem a tag UML:Multiplicity.range; UML:Multiplicity.range Tag XMI que contem a tag UML:MultiplicityRange; UML:MultiplicityRange Multiplicidade da associação (1 para n, 1 para 1) (lower, upper);

28 28 UML:TagDefinition Nome do Valor Marcado (name, xmi.id). Abaixo está parte do código XMI gerado pelo editor UML que é utilizado pelo parser. Nele está modelado o diagrama UML apresentado no capítulo de Introdução. 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 inteiro está nos anexos: 1 <UML:Namespace.ownedElement> 2 <UML:Class xmi.id = d55673f:11c47d175d4:-8000: C 3 name = Cidade visibility = public isspecification = false isroot = false 4 isleaf = false isabstract = false isactive = false > 5 <UML:Classifier.feature> 6 <UML:Attribute xmi.id = d55673f:11c47d175d4:-8000: F 7 name = nome visibility = public isspecification = false ownerscope = instance 8 changeability = changeable targetscope = instance > 9 <UML:StructuralFeature.type> 10 <UML:DataType xmi.idref = d55673f:11c47d175d4:-8000: /> 11 </UML:StructuralFeature.type> 12 </UML:Attribute> 13 </UML:Classifier.feature> 14 </UML:Class> 15 <UML:DataType xmi.id = d55673f:11c47d175d4:-8000: name = CharField isspecification = false isroot = false isleaf = false 17 isabstract = false /> 18 <UML:DataType xmi.id = d55673f:11c47d175d4:-8000: name = IntegerField isspecification = false isroot = false isleaf = false 20 isabstract = false /> 21 <UML:Class xmi.id = d55673f:11c47d175d4:-8000: name = Estado visibility = public isspecification = false isroot = false 23 isleaf = false isabstract = false isactive = false > 24 <UML:Classifier.feature> 25 <UML:Attribute xmi.id = d55673f:11c47d175d4:-8000: name = nome visibility = public isspecification = false ownerscope = instance 27 changeability = changeable targetscope = instance > 28 <UML:StructuralFeature.type> 29 <UML:DataType xmi.idref = d55673f:11c47d175d4:-8000: /> 30 </UML:StructuralFeature.type> 31 </UML:Attribute> 32 <UML:Attribute xmi.id = d55673f:11c47d175d4:-8000: AF 33 name = zona visibility = public isspecification = false ownerscope = instance 34 changeability = changeable targetscope = instance > 35 <UML:StructuralFeature.type> 36 <UML:DataType xmi.idref = d55673f:11c47d175d4:-8000: /> 37 </UML:StructuralFeature.type> 38 </UML:Attribute> 39 </UML:Classifier.feature> 40 </UML:Class> 41 <UML:Association xmi.id = d55673f:11c47d175d4:-8000: C2 42 name = isspecification = false isroot = false isleaf = false isabstract = false > 43 <UML:Association.connection> 44 <UML:AssociationEnd xmi.id = d55673f:11c47d175d4:-8000: C3 45 visibility = public isspecification = false isnavigable = true ordering = unordered 46 aggregation = composite targetscope = instance changeability = changeable > 47 <UML:AssociationEnd.multiplicity>

29 29 48 <UML:Multiplicity xmi.id = d55673f:11c47d175d4:-8000: C4 > 49 <UML:Multiplicity.range> 50 <UML:MultiplicityRange 51 xmi.id = d55673f:11c47d175d4:-8000: C5 52 lower = 1 upper = 1 /> 53 </UML:Multiplicity.range> 54 </UML:Multiplicity> 55 </UML:AssociationEnd.multiplicity> 56 <UML:AssociationEnd.participant> 57 <UML:Class xmi.idref = d55673f:11c47d175d4:-8000: C /> 58 </UML:AssociationEnd.participant> 59 </UML:AssociationEnd> 60 <UML:AssociationEnd xmi.id = d55673f:11c47d175d4:-8000: C6 61 visibility = public isspecification = false isnavigable = true ordering = unordered 62 aggregation = none targetscope = instance changeability = changeable > 63 <UML:AssociationEnd.multiplicity> 64 <UML:Multiplicity xmi.id = d55673f:11c47d175d4:-8000: CA > 65 <UML:Multiplicity.range> 66 <UML:MultiplicityRange 67 xmi.id = d55673f:11c47d175d4:-8000: C9 68 lower = 1 upper = -1 /> 69 </UML:Multiplicity.range> 70 </UML:Multiplicity> 71 </UML:AssociationEnd.multiplicity> 72 <UML:AssociationEnd.participant> 73 <UML:Class xmi.idref = d55673f:11c47d175d4:-8000: /> 74 </UML:AssociationEnd.participant> 75 </UML:AssociationEnd> 76 </UML:Association.connection> 77 </UML:Association> 78 </UML:Namespace.ownedElement> 4.3 Mapeamento de objetos XMI - Django Model O gerador proposto tem como objetivo traduzir elementos XMI em código Python segundo o framework Djando. A Tabela 4.1 ilustra os componentes (tags) XMI considerados e sua respectiva tradução no framework Django. Cada linha da tabela poderá ser gerada por uma ou várias regras de produção gramaticais aliadas à regras semânticas para geração de código Python. 4.4 Análise léxico-sintática O parser considerado neste projeto é um top-down descendente para gramáticas do tipo LL 1. Considerando o escopo delimitado na seção 2.2, a gramática livre-decontexto (GLC) definida aqui compreende apenas a geração de produções relativas aos componentes de representação de Classe, atributos e relacionamentos do padrão XMI. Para tanto, limitamos nossa gramática a estas tags específicas. Além disso, não foi criada nenhuma validação da sintaxe do XMI, pois, partimos do pressuposto 1 Left-to-Right, Leftmost derivation com lookahead. Para isto, a gramática livre-de-contexto deve estar livre de recursão a esquerda e deve estar fatorada.

30 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ção de um atributo da classe Django que representará a associação, seja ela chave Estrangeira ou um mapeamento N para N Parametros utilizados nos atributos da classe Tabela 4.1: Mapeamento de objetos XMI - Django Model que a mesma esteja correta, pois foi gerada automaticamente através de um sistema já consolidado. Como a estrutura do XMI é basicamente uma estrutura em forma de árvore, a gramatica utilizada no parser é bem simples. A seguir apresentamos a GLC proposta em formato BNF: 1 <UML:Namespace.ownedElement> ::= <UML:DataType> <UML:Class> <UML:Association> 2 <UML:DataType> ::= name "=" " " valor " " xmi.id "=" " " valor " " 3 xmi.idref "=" " " valor " " 4 <UML:Class> ::= UML:Classifier.feature name "=" " " valor " " xmi.id "=" " " valor " " 5 xmi.idref = "valor" 6 <UML:Class> ::= UML:Class name "=" " " valor " " xmi.id "=" " " valor " " <UML:Classifier.feature> 7 <UML:Class> ::= UML:Class xmi.idref "=" " " valor " " 8 9 <UML:Classifier.feature> ::= <UML:Attribute> 10 <UML:Attribute> :: = UML:ModelElement.taggedValue UML:StructuralFeature.type" 11 name "=" " " valor " " xmi.id "=" " " valor " " 12 <UML:ModelElement.taggedValue> ::= "UML:TaggedValue" 13 <UML:TaggedValue> :: = "UML:TaggedValue.type" "UML:TaggedValue.dataValue" 14 <UML:TaggedValue.type> ::= "UML:TagDefinition" 15 <UML:TagDefinition> ::= xmi.idref "=" " " valor " " 16 <UML:TaggedValue.dataValue> ::= name "=" " " valor " " 17 <UML:StructuralFeature.type> ::= "UML:DataType" 18 <UML:Association> ::= "UML:Association.connection" 19 <UML:Association.connection> ::= "UML:AssociationEnd" "UML:AssociationEnd.participant" 20 "UML:AssociationEnd.multiplicity" 21 <UML:AssociationEnd> ::= aggregation "=" " " valor " " 22 <UML:AssociationEnd.participant> ::= "UML:Class" 23 <UML:AssociationEnd.multiplicity> ::= "UML:Multiplicity.range" 24 <UML:Multiplicity.range> ::= UML:MultiplicityRange 25 <UML:MultiplicityRange> ::= lower "=" " " valor " " upper "=" " " valor " " Para auxiliar a extração de dados relevantes do XML, foi utilizado o pacote padrão do Python, o xml.dom.minidom. Com ele foi possível tratar os nomes de tags e diferenças entre os atributos das mesmas. Embora existam outros parsers

31 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 ao fato do pacote padrão já fazer parte da distribuição atual do Python, sendo assim, o sistema tende a manter uma maior compatibilidade com futuras versões do interpretador Extração do XML A extração dos dados é feita através do pacote xml.dom.minidom, uma implementação mais leve da interface DOM 4. É uma implementação mais simples que o DOM padrão e significativamente menor. O Minidom analiza o código no arquivo XML e cria a estrutura DOM, sendo estra mais fácil para manipulação dos itens dos arquivos XML. Uma vez tendo o objeto DOM, é possivel acessar partes de seu documento XML através das suas propriedades e métodos. Estas propriedades são definidos na especificação DOM 5. A principal propriedade do objeto é a documentelement, responsável pela extração das tags expecíficas do XML. O exemplo pode ser visto abaixo: >>> from xml.dom import minidom >>> dom = minidom.parsestring("<myxml>some data</myxml>") >>> dom.documentelement.nodevalue >>> print dom.documentelement.tagname u myxml Também foi criada uma função em Python chamada finditem com a finalidade de buscar e retornar uma lista de itens-filho, de uma tag expecífica, de acordo com o nome enviado por parâmetro: 1 def finditem(raiz,item): 2 return [x for x in raiz.childnodes if x.nodename == item] A busca dos elementos principais do diagrama (classes, tags, tipo de dados e associações) é feita através do item raiz (UML:Namespace.ownedElement): 1 def finditem(raiz,item): 2 return [x for x in raiz.childnodes if x.nodename == item] 3 4 raiz = doc.documentelement.getelementsbytagname( UML:Namespace.ownedElement )[0] #elemento raiz 5 6 xmi_tipos = finditem(raiz,"uml:datatype") #lista de tipos 7 lst_tipos = TipoDados(xmi_tipos) Document Object Model interface 5

32 32 9 xmi_tags = finditem(raiz,"uml:tagdefinition") #valores marcados 10 lst_tags = TipoTags(xmi_tags) xmi_classes = finditem(raiz,"uml:class") #lista de classes 13 xmi_associacoes = finditem(raiz,"uml:association") #lista de associaç~oes 14 xmi_herancas = finditem(raiz,"uml:generalization") #lista de herancas 15 classes = ListaClasses(xmi_classes,lst_tipos,lst_tags,xmi_associacoes,xmi_herancas) Para cada classe encontrada no XMI, é feita a extração do nome de identificador da classe e também é realizada a busca dos atributos da mesma. 1 def finditem(raiz,item): 2 return [x for x in raiz.childnodes if x.nodename == item] 3 4 for classe in xmi_classes: 5 nome = classe.attributes.get( name ).value 6 container = finditem(classe, UML:Classifier.feature )[0] 7 xmi_atributos = finditem(container, UML:Attribute ) A cada atributo encontrado, é extraído o nome e o identificador do tipo do atributo. O nome do tipo do atributo é buscado na lista de tipos, extraida anteriormente: 1 xmi_atributos = finditem(container, UML:Attribute ) 2 for att in xmi_atributos: 3 container_tipo = finditem(att, UML:StructuralFeature.type )[0] 4 container_tipo2 = finditem(container_tipo, UML:DataType )[0] 5 nome = att.attributes.get( name ).value 6 valor= lst_tipos.get_nome(container_tipo2.attributes.get( xmi.idref ).value) 4.5 Análise semântica A tradução para código Django, utiliza uma estrutura intermediaria de dados, utilizando programação orientada a objeto escrita em python, para assim gerar o código Django. A figura 4.5 representa o diagrama desta estrutura intermediária: De acordo com os dados contidos no arquivo XML, é feita a busca de elementos e extraído os dados relevantes. Estes dados são armazenadas em forma de objetos python de acordo com a Figura 4.5. Quando a leitura estiver completa, os objetos python são lidos e escrito na tela, já no padrão de modelagem da camada Model do Django Algoritmos de geração A geração das classes é realizada através da busca das classes do objeto Klasse (Figura 4.5, onde o objeto possui uma variavel que informa se a classe herda de outra ou não, pois o código traduzido de uma classe herdade é diferente. 1 for cl in self.classes.lista: 2 if cl.herda_de: 3 yield class %s(%s): % (cl.nome,cl.herda_de)

33 33 Figura 4.2: Diagrama de classes do sistema 4 else: 5 yield class %s(models.model): % cl.nome Para cada classe, é verificado se a mesma possui atributos, cada atributo é escrito como uma variável da classe recebendo como valor, o tipo de campo Field do Django. É verificado também se o atributo possui valores marcados, se possuir, estes são escritos como parâmetros do Field. 1 yield class %s(models.model): % cl.nome 2 for att in cl.atributos: 3 extra = "" 4 if len(att.extras): 5 for ex in att.extras: 6 extra+="%s=%s," %(ex[ nome ],ex[ valor ]) 7 yield %s = models.%s(%s) % (att.nome, att.valor,extra[:-1]) As Associações da classe são geradas de forma semelhante aos atributos, pois são escritas também como variáveis da classe. Além da verificação de valore marcados, é verificado o tipo de cardinalidade. Se a cardinalidade for um para muitos (1:n) é gerado um campo ForeignKey, se for uma relação muitos para muitos (n:n) é gerado um campo ManyToMany. 1 for rel in cl.associacoes: 2 extra = "" 3 if len(rel.extras): 4 for ex in rel.extras: 5 extra+=", %s= %s " %(ex[ nome ],ex[ valor ]) 6 if rel.cardinalidade[0] == * and rel.cardinalidade[1] == * :

34 34 7 yield %s = models.manytomanyfield(%s%s) % \ 8 (str.lower(str(rel.classe)), rel.classe, extra) 9 for rel in cl.associacoes: 10 extra = "" 11 if len(rel.extras): 12 for ex in rel.extras: 13 extra+=", %s= %s " %(ex[ nome ],ex[ valor ]) 14 if rel.cardinalidade[0] == * and rel.cardinalidade[1] == * : 15 yield %s = models.manytomanyfield(%s%s) % \ 16 (str.lower(str(rel.classe)), rel.classe, extra) 17 else: 18 yield %s = models.foreignkey(%s%s) % \ 19 (str.lower(str(rel.classe)), rel.classe, extra)

35 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 e herança. Em todos os casos abaixo foram gerados códigos, sendo estes perfeitamente aplicados no framework. 5.1 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 as variáveis nome e nascimento representnado seus atributos 1 # coding: utf-8 2 # Este ~A c um modulo de auto gera~a ~A o de classes django. 3 4 from django.db import models 5 6 class Pessoa(models.Model): 7 nome = models.charfield(max_length=15) 8 nascimento = models.datefield() 5.2 Duas Classes sem relacionamento Basicamente o mesmo teste que o anterior, criado para testar várias classes. Nele são geradas duas classes, classe Cidade, com um atributo (nome) e a Classe Estado com dois atributos (nome e zona)

36 36 Figura 5.2: UML Representando duas classes sem relacionamento O código gerado contem duas classes Django com os nomes Cidade e Estado, a classe cidade possui o atributo nome e a classe Estado possui os atributos nome e zona. 1 ## coding: utf-8 2 # Este ~A c um modulo de auto gera~a ~A o de classes django. 3 4 from django.db import models 5 6 class Cidade(models.Model): 7 nome = models.charfield(max_length=15) 8 9 class Estado(models.Model): 10 nome = models.charfield(max_length=25) 11 zona = models.charfield(max_length=2) Neste caso o código gerado é semelhante ao do teste 5.2, mas, como pode ser visto na linha 12, foi acrescentado uma variável do tipo ForeignKey representando um relacionamento. 5.3 duas Classes relacionadas O mesmo teste que o anterior, agora testando associações entre classes. Neste caso foi utilizado um relacionamento 1:n, este relacionamento é representado pelo atributo do tipo ForeignKey da classe Django Figura 5.3: UML representando duas classes relacionadas 1 ## coding: utf-8 2 # Este ~A c um modulo de auto gera~a ~A o de classes django. 3 4 from django.db import models

37 class Cidade(models.Model): 7 nome = models.charfield(max_length=15) 8 9 class Estado(models.Model): 10 nome = models.charfield(max_length=25) 11 zona = models.charfield(max_length=2) 12 cidade = models.foreignkey(cidade) 5.4 Teste de Herança O teste abaixo foi realizado para representar as heranças de classes Django. São representadas três classes, uma classe principal chamada Pessoa, e outras duas classes que descendem da classe anterior, Fisica e Jurídica. Figura 5.4: UML representando herança O código gerado, o parser gerou a Classe Pessoa herdando da classe Django e as classes Fisica e Jurídica herdando de Pessoa. 1 # coding: utf-8 2 # Este ~A c um modulo de auto gera~a ~A o de classes django. 3 4 from django.db import models 5 6 class Pessoa(models.Model): 7 nome = models.charfield(max_length=45) 8 9 class Fisica(Pessoa): 10 cpf = models.integerfield() class Juridica(Pessoa): 13 cnpj = models.integerfield()

38 Teste multiplo Este exemplo foi ilustra um sistema real, contendo várias classes, e vários tipos de campos e associações. Figura 5.5: Uml representando várias classes O código gerado pode ser visto a seguir: 1 # coding: utf-8 2 # Este ~A c um modulo de auto gera~a ~A o de classes django. 3 4 from django.db import models 5 6 class Estado(models.Model): 7 nome = models.charfield(max_length=10) 8 zona = models.integerfield() 9 10 class Usuario(models.Model): 11 username = models.charfield(max_length=10) 12 password = models.charfield(max_length=20) class Cidade(models.Model): 15 nome = models.charfield(max_length=30) 16 estado = models.foreignkey(estado) class Pessoa(models.Model): 19 nome = models.charfield(max_length=40) 20 cidade = models.foreignkey(cidade) 21 usuario = models.foreignkey(usuario, unique= True )