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 Only two things are infinite, the universe and human stupidity, and I m not sure about the former. Albert Einstein

3 AGRADECIMENTOS... AGRADECIMENTOS

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 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 Teste de Herança duas Classes relacionadas classes com vários tipos de relacionamento CONCLUSÃO Validação do projeto Trabalhos Futuros REFERÊNCIAS

6 LISTA DE ABREVIATURAS E SIGLAS TCC XMI UML MVC XML DRY URL GLC Trabalho de Conclusão de Curso XML Metadata Interchange Unified Modeling Language Model-view-controller Extensible Markup Language Don t repeat yourself Uniform Resource Locator Gramática Livre-de-Contexto

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 Representnado uma classe Figura 5.2: Uml Representnado duas classes sem relacionamento Figura 5.3: Uml representando herança Figura 5.4: Uml representando duas classes relacionadas Figura 5.5: Uml representando várias classes

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

9 RESUMO UML2Django: Gerador de Código para Framework Web MVC Palavras-chave: UML, VMC, Django, Framework, Python.

10 Uml2Django: Code Generator for Web MVC Framawork RESUMO englishabstract

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 editores, 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 novamente. Atualmente existem uma série de aplicativos de geração de código, mas não para Python 2, linguagem do Framework escolhido. 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 3 e Umbrello 4. 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 framwrok 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 a geração de código Java nativo e para 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 Meta

13 13 data Interchange) (GROUP, 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 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) 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 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:

14 1 <?xml version = 1.0 encoding = UTF-8?> 2 <XMI xmi.version = 1.2 xmlns:uml = org.omg.xmi.namespace.uml timestamp = Tue Sep 09 13:16:17 BRT 2008 > 3 <XMI.header> <XMI.documentation> 4 <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0)</XMI.exporter> 5 <XMI.exporterVersion>0.24(5) revised on $Date: :55: (Mon, 06 Nov 2006) $ </XMI.exporte 6 </XMI.documentation> 7 &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;nbsp; <XMI.metamodel xmi.name="uml" xmi.version="1.4"/></xmi.h 8 <XMI.content> 9 <UML:Model xmi.id = d55673f:11c47d175d4:-8000: B 10 name = untitledmodel isspecification = false isroot = false isleaf = false 11 isabstract = false > 12 <UML:Namespace.ownedElement> </UML:Namespace.ownedElement> 17 </UML:Model> 18 </XMI.content> 19 </XMI> Tratamento das informações do XML e geração de código no padrão do framework Django. O diagrama exemplificado na Figura X.X produz 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 3 partes:. Na primeira parte, Capítulo 2, serão abordados os conceitos preliminares necessários para o entendimento dos componentes trabalho, onde apresentamos o padrão de desenvolvimento MVC, uma introdução básica sobre a linguagem python e frameworks de desenvolvimento. O capitulo 3 é dedicado ao framework alvo da aplicação, o Django, onde serão descritos detalhes de seus componentes mais usuais e como o padrão MVC é aplicado a ele. No capitulo 4, apresentamos a proposta de implementação deste trabalho, onde será 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

15 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.

16 16 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á abordados definições sofre frameworks. E na seção 2.4 será feita uam brave 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 padrão 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 basica com 3 camadas possivelmente abstratas: Model: Implementa o modelo representando a estrutura de baixo nivel do projeto, podendo ser o modelo objeto-relacional que implementa a camada de dados, e ou num caso de MVC de Interface poderia guardar informações de estado dos controles. Controller: Implementa a camada respónsavel pelo gerenciamentos de eventos no projeto, tais como cliques do usuario, chamando a camada Model para processar os eventos, tambem pode manter informações de estado do usuario na aplicação. View: Gera a interface com usuario de modo que esta somente requisite o processamento de eventos pelo Controller.

17 17 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 afectam 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 interacçã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. (BEZERRA, 2007) 2.2 UML A uml é uma linguagem visual para modelar sistemas orientados a bojeto. 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. 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. (BEZERRA, 2007) Embora a UML possua diversos diagramas para representar o sistema (atividades, casos de uso, colaboração, seuquncia, 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 o as classes do sistema, 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

18 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 Métodos Métodos são Função requerida a um objeto ou seja, as ações que os objetos de uma classe pode executar. 2.3 Frameworks de desenvolvimento de aplicações Estamos em uma época onde as informações são recebidas rapidamente, noticias de qualquer parte do mundo chegam as pessoas de forma quase que instantânea. Grande parte dessa informação é veiculada através da WEB. Para isso o desenvolvimento de Aplicação web é algo 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, o 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 se foque basicamente no 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 implementam uma certa funcionalidade genérica. sendo esta 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 inter-

19 19 face Exemplos A maioria das linguagens voltadas para o desenvolvimento WEB posuem frameworks: Ruby possui um dos mais famosos frameworks WEB da atualidade, o Ruby on Rails. Python possui uma gama consideravel de ferramentas como o Django, TurboGears, pylons, Zope/Plone, web2py entre outros. PHP que é uma das mais utilizadas linguagens para peogramação WEB possui os frameworks CakePHP, CodeIgniter, PRADO, symfony, Zend, entre outros. Perl possui o Catalyst, Maypole, Jifty 2.4 Linguagem de programação Python Python é uma linguagem de programação de alto nível interpretada, interativa, orientada a 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 facto é a implementação CPython. 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, 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

20 20 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 THE WEB FRAMEWORK FOR PERFECTIONISTS WITH DEADLINES,????) é 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 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. 3.1 Características Através do ORM 1 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 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 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 de mapeia uma única tabela de dados. 1 Object-relational mapping

22 22 Figura 3.1: Estrutura do framework Django 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, nele 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 ultimas 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. 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 modulo que visa separar a apresentação dos dados lógicos do site. O Template define certo espaços onde são definidas laços de repetições, condicionais e outras funcionalidades do django para manipular variaveis passadas pela view. Normalmente, os templates são utilizados para produzir HTML, mas os templates do Django são capazes de gerar qualquer formato de tipo texto Controle de dados (Controller) Entre a camada de visualização e o usuário, há a camada de controle, ela é responsável pelo processamento de ações de requisições e resposta do usuário (Http

23 23 Request e http Response). Para realizar este processamento o Django conta com Middlewares e Url Dispatcher: As middlerares são trechos de código que analisam requisições feitas pelo usuário. Através dele é possível enviar informações pra view de foram 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 404 é 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 a 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 3.2. Figura 3.2: Fluxo de Execução do Framework Django

24 24 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 criada 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. Os principais modeladores Figura 4.1: Estrutura do parser XMI2Django 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, que nada mais é que um formato definido pela OMG para representação, intercâmbio e partilha de objectos, 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 independnete de qual modelador UML utilizado, desde que ele exporte o arquivo XMI

25 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 editore 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 r a i z do xmi, é onde todos os i t e n s do diagrama em questã o UML: DataType L i s t a de t i p o s de dados (name, xmi. id ) o UML: Class C l a s s e s do diagrama de c l a s s e s (name, xmi. id ) + UML: C l a s s i f i e r. f e a t u r e # UML: A t t r i b u t e Atributos da c l a s s e (name, xmi. id ) UML: ModelElement. taggedvalue o UML: TaggedValue L i s t a de v a l o r e s marcados + UML: TaggedValue. type # UML: TagDefinition Apontador para o v a l o r ma + UML: TaggedValue. datavalue Valor do Valor Marcado ( name) UML: S t r u c t u r a l F e a t u r e. type o UML: DataType Um apontador para um t i p o de dado ( xm o UML: A s s o c i a t i o n L i s t a de a s s o c i a ç õ e s e n t r e c l a s s e s + UML: A s s o c i a t i o n. connection # UML: AssociationEnd Tipo de a s s o c i a ç ã o ( Composição, agregação, heranç # UML: AssociationEnd. p a r t i c i p a n t L i s t a de o b j e t o s p a r t i c i p a n t e s da a s s o c i a ç ã o, par UML: Class Um apontador para a c l a s s e ( xmi. i d r e f ) # UML: AssociationEnd. m u l t i p l i c i t y UML: M u l t i p l i c i t y

26 26 o UML: M u l t i p l i c i t y. range + UML: MultiplicityRange M u l t i p l i c i d a d e da a s s o c i a ç ã o (1 o UML: TagDefinition Nome do Valor Marcado ( name, xmi. i d ) Abaixo um exemplo de código XMI gerado pelo editor UML, nele está modelado o uml da figura 1, 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. Os itens em negrito são os elementos que são utilizados pelo parser: 1 <?xml version = 1.0 encoding = UTF-8?> 2 <XMI xmi.version = 1.2 xmlns:uml = org.omg.xmi.namespace.uml timestamp = Tue Sep 09 13:16:17 BRT 2008 > 3 <XMI.header> <XMI.documentation> 4 <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0)</XMI.exporter> 5 <XMI.exporterVersion>0.24(5) revised on $Date: :55: (Mon, 06 Nov 2006) $ </XMI.exporterVersio 6 </XMI.documentation> 7 <XMI.metamodel xmi.name="uml" xmi.version="1.4"/></xmi.header> 8 <XMI.content> 9 <UML:Model xmi.id = d55673f:11c47d175d4:-8000: B 10 name = untitledmodel isspecification = false isroot = false isleaf = false 11 isabstract = false > 12 <UML:Namespace.ownedElement> 13 <UML:Class xmi.id = d55673f:11c47d175d4:-8000: C 14 name = Cidade visibility = public isspecification = false isroot = false 15 isleaf = false isabstract = false isactive = false > 16 <UML:Classifier.feature> 17 <UML:Attribute xmi.id = d55673f:11c47d175d4:-8000: F 18 name = nome visibility = public isspecification = false ownerscope = instance 19 changeability = changeable targetscope = instance > 20 <UML:StructuralFeature.multiplicity> 21 <UML:Multiplicity xmi.id = d55673f:11c47d175d4:-8000: BF > 22 <UML:Multiplicity.range> 23 <UML:MultiplicityRange xmi.id = d55673f:11c47d175d4:-8000: BE 24 lower = 1 upper = 1 /> 25 </UML:Multiplicity.range> 26 </UML:Multiplicity> 27 </UML:StructuralFeature.multiplicity> 28 <UML:StructuralFeature.type> 29 <UML:DataType xmi.idref = d55673f:11c47d175d4:-8000: /> 30 </UML:StructuralFeature.type> 31 </UML:Attribute> 32 </UML:Classifier.feature> 33 </UML:Class> 34 <UML:DataType xmi.id = d55673f:11c47d175d4:-8000: name = CharField isspecification = false isroot = false isleaf = false 36 isabstract = false /> 37 <UML:DataType xmi.id = d55673f:11c47d175d4:-8000: name = IntegerField isspecification = false isroot = false isleaf = false 39 isabstract = false /> 40 <UML:Class xmi.id = d55673f:11c47d175d4:-8000: name = Estado visibility = public isspecification = false isroot = false 42 isleaf = false isabstract = false isactive = false > 43 <UML:Classifier.feature> 44 <UML:Attribute xmi.id = d55673f:11c47d175d4:-8000: name = nome visibility = public isspecification = false ownerscope = instance

27 27 46 changeability = changeable targetscope = instance > 47 <UML:StructuralFeature.multiplicity> 48 <UML:Multiplicity xmi.id = d55673f:11c47d175d4:-8000: C1 > 49 <UML:Multiplicity.range> 50 <UML:MultiplicityRange xmi.id = d55673f:11c47d175d4:-8000: C0 51 lower = 1 upper = 1 /> 52 </UML:Multiplicity.range> 53 </UML:Multiplicity> 54 </UML:StructuralFeature.multiplicity&amp;gt; 55 &nbsp; <UML:StructuralFeature.type> 56 <UML:DataType xmi.idref = d55673f:11c47d175d4:-8000: /> 57 </UML:StructuralFeature.type> 58 </UML:Attribute> 59 <UML:Attribute xmi.id = d55673f:11c47d175d4:-8000: AF 60 name = zona visibility = public isspecification = false ownerscope = instance 61 changeability = changeable targetscope = instance > 62 <UML:StructuralFeature.multiplicity> 63 <UML:Multiplicity xmi.id = d55673f:11c47d175d4:-8000: BD > 64 <UML:Multiplicity.range> 65 <UML:MultiplicityRange xmi.id = d55673f:11c47d175d4:-8000: BC 66 lower = 1 upper = 1 /> 67 </UML:Multiplicity.range> 68 </UML:Multiplicity> 69 </UML:StructuralFeature.multiplicity> 70 <UML:StructuralFeature.type> 71 <UML:DataType xmi.idref = d55673f:11c47d175d4:-8000: /> 72 </UML:StructuralFeature.type> 73 </UML:Attribute> 74 </UML:Classifier.feature> 75 </UML:Class> 76 <UML:Association xmi.id = d55673f:11c47d175d4:-8000: C2 77 name = isspecification = false isroot = false isleaf = false isabstract = false > 78 <UML:Association.connection> 79 <UML:AssociationEnd xmi.id = d55673f:11c47d175d4:-8000: C3 80 visibility = public isspecification = false isnavigable = true ordering = unordered 81 aggregation = composite targetscope = instance changeability = changeable > 82 <UML:AssociationEnd.multiplicity> 83 <UML:Multiplicity xmi.id = d55673f:11c47d175d4:-8000: C4 > 84 <UML:Multiplicity.range> 85 <UML:MultiplicityRange xmi.id = d55673f:11c47d175d4:-8000: C5 86 lower = 1 upper = 1 /> 87 </UML:Multiplicity.range> 88 </UML:Multiplicity> 89 </UML:AssociationEnd.multiplicity> 90 <UML:AssociationEnd.participant> 91 <UML:Class xmi.idref = d55673f:11c47d175d4:-8000: C /> 92 </UML:AssociationEnd.participant> 93 </UML:AssociationEnd> 94 <UML:AssociationEnd xmi.id = d55673f:11c47d175d4:-8000: C6 95 visibility = public isspecification = false isnavigable = true ordering = unordered 96 aggregation = none targetscope = instance changeability = changeable > 97 <UML:AssociationEnd.multiplicity> 98 <UML:Multiplicity xmi.id = d55673f:11c47d175d4:-8000: CA > 99 <UML:Multiplicity.range> 100 <UML:MultiplicityRange xmi.id = d55673f:11c47d175d4:-8000: C9 101 lower = 1 upper = -1 /> 102 </UML:Multiplicity.range> 103 </UML:Multiplicity> 104 </UML:AssociationEnd.multiplicity>

28 <UML:AssociationEnd.participant> 106 <UML:Class xmi.idref = d55673f:11c47d175d4:-8000: /> 107 </UML:AssociationEnd.participant> 108 </UML:AssociationEnd> 109 </UML:Association.connection> 110 </UML:Association> 111 </UML:Namespace.ownedElement> 112 </UML:Model> 113 </XMI.content> 114 </XMI> 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áriás regras de produção gramaticais aliadas à regras semânticas para geração de código Python. Tag XMI UML:Class UML:Attribute UML:DataType UML:Association, UML:AssociationEnd, UML:AssociationEnd.participant, UML:MultiplicityRange UML:TaggedValue.type, UML:TaggedValue.dataValue Django Classe Django Atributo da Classe Django Tipo do atributo Geração de um atributo da classe UML:TagDefinition, Parametros utilizados nos atributos da classe Tabela 4.1: Mapeamento de objetos XMI - Django Model 4.4 Análise léxico-sintática O parser considerado neste projeto é um top-down descendente para gramáticas do tipo LL( 1 ). Para isto, a gramática livre-de-contexto deve estar livre de recursão a esquerda e deve estar fatorada.. Considerando o escopo delimitado na seção 2.2, a gramática livre-de-contexto (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 que a mesma esteja correta, pois foi gerada através de um sistema já consolidado. 1 Left-to-Right, Leftmost derivation com lookahead

29 29 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" name "=" " " valor " " xmi.id "=" " " val 11 <UML:ModelElement.taggedValue> ::= "UML:TaggedValue" 12 <UML:TaggedValue> :: = "UML:TaggedValue.type" "UML:TaggedValue.dataValue" 13 <UML:TaggedValue.type> ::= "UML:TagDefinition" 14 <UML:TagDefinition> ::= xmi.idref "=" " " valor " " 15 <UML:TaggedValue.dataValue> ::= name "=" " " valor " " 16 <UML:StructuralFeature.type> ::= "UML:DataType" 17 <UML:Association> ::= "UML:Association.connection" 18 <UML:Association.connection> ::= "UML:AssociationEnd" "UML:AssociationEnd.participant" "UML:AssociationEnd.multiplicity" 19 <UML:AssociationEnd> ::= aggregation "=" " " valor " " 20 <UML:AssociationEnd.participant> ::= "UML:Class" 21 <UML:AssociationEnd.multiplicity> ::= "UML:Multiplicity.range" 22 <UML:Multiplicity.range> ::= UML:MultiplicityRange 23 <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 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 manter maior compatibilidade com futuras versões do interpretador Extração do XML Como foi falado anteriormente, a extração dos dados é feita através do pacote xml.dom.minidom. O minidom é uma implementação mais leve da interface 4. É uma implementação masi 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 facil para manipulação dos itens dos arquivos XML. Uma vez tendo o abjeto DOM, é possivel acessar as as partes de seu documento XML através das suas propriedades e métodos. Estas propriedades são definidos na especificação DOM. A principal DOM Document Object Model interface

30 30 propriedade do objeto é a documentelement, é através dela que extraimos uam tag expecífica 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 Busca dos elementos principais do diagrama (classes, tags, tipo de dados e associações) 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 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 ) Extração dos elementos da classe e busca dos atributos da mesma 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 xmi_tipos = finditem(raiz,"uml:datatype") #lista de tipos 6 xmi_tags = finditem(raiz,"uml:tagdefinition") #valores marcados 7 xmi_classes = finditem(raiz,"uml:class") #lista de classes Extrai os atributos de uma classe: 1 def finditem(raiz,item): 2 return [x for x in raiz.childnodes if x.nodename == item] 3 4 xmi_atributos = finditem(container, UML:Attribute ) 5 for att in xmi_atributos: 6 container_tipo = finditem(att, UML:StructuralFeature.type )[0] 7 container_tipo2 = finditem(container_tipo, UML:DataType )[0] 8 nome = att.attributes.get( name ).value 9 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, é baseado em uma abordagem chamada Interlíngua, onde é criada uma estrutura intermediaria de estrutura de dados, utilizando programação orientada a objeto escrita em python, para assim gerar o código Django. A interlíngua (DORR, 1993) é uma estrutura de linguagem intermediária

31 31 baseada na existência de um vocabulário comum compartilhado pelas linguagens que serão traduzidas ou vertidas. O pricipal objetivo da Interlíngua é facilitar o relacionamento entre linguagem algo e destino através de estruturas simples que demonstrem a relação entre as duas. Esta abordagem diminui as decisões de parsing feitas durante a construcão da árvore sintática, já que as diferenças estruturais entre as linguagens são limitadas pela estrutura intermediária. O sistema possui a seguinte estrutura de classes: Figura 4.2: Diagrama de classes do sistema 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 XX. Quando a leitura estive 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 Classes 1 for cl in self.classes.lista: 2 yield class %s(models.model): % cl.nome Atributos da classe 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]) Associações da classe 1 for rel in cl.associacoes: 2 extra = ""

32 32 3 if len(rel.extras): 4 for ex in rel.extras: 5 extra+=", %s= %s " %(ex[ nome ],ex[ valor ]) 6 if rel.cardinalidade[0] == * and rel.cardinalidade[1] == * : 7 yield %s = models.manytomanyfield(%s%s) % \ 8 (str.lower(str(rel.classe)), rel.classe, extra) 9 for rel in cl.associacoes: 10 extra = "" 11 if len(rel.extras): 12 for ex in rel.extras: 13 extra+=", %s= %s " %(ex[ nome ],ex[ valor ]) 14 if rel.cardinalidade[0] == * and rel.cardinalidade[1] == * : 15 yield %s = models.manytomanyfield(%s%s) % \ 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)

33 33 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 apliciados no framework. 5.1 Uma Classe Primeiro teste feito com o Parser, e o mais simples, verifica a classe contida no XML e lista os atributos da classe. Figura 5.1: Uml Representnado uma classe 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, mas com uma classe a mais. 1 # coding: utf-8 2 # Este ~A c um modulo de auto gera~a ~A o de classes django. 3

34 34 Figura 5.2: Uml Representnado duas classes sem relacionamento 4 from django.db import models 5 6 class Pessoa(models.Model): 7 nome = models.charfield(max_length=15) 8 nascimento = models.datefield() 5.3 Teste de Herança O teste abaixo foi realizado para gerar a herança entre classes Figura 5.3: Uml representando herança 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

35 35 9 class Fisica(Pessoa): 10 cpf = models.integerfield() class Juridica(Pessoa): 13 cnpj = models.integerfield() 5.4 duas Classes relacionadas Neste caso foi utilizado um relacionamento 1:n, este relacionamento é representado pelo atributo do tipo ForeignKey da classe Django Figura 5.4: 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 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) 12 cidade = models.foreignkey(cidade) classes com vários tipos de relacionamento Neste exeplo foram criadas várias classes e vários relacionamentos, e o resultado foi satisfatório 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):

36 36 Figura 5.5: Uml representando várias classes 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=35) 20 nascimento = models.datefield() 21 cidade = models.foreignkey(cidade) 22 usuario = models.foreignkey(usuario, unique= True ) 23 fotos = models.manytomanyfield(fotos) class Fotos(models.Model): 26 foto = models.imagefield(upload_to= /upload/teste/ ) 27 data = models.datefield(auto_now=true

37 37 6 CONCLUSÃO 6.1 Validação do projeto O principal objetivo deste trabalho foi alcançado. O objetivo central de geral uma classe Django a partir de um diagrama de classes foi completamente atingido. Praticamente todos es elementos que o Model do Django suporta foram extraidos com sucesso. 6.2 Trabalhos Futuros Há interesse de disponibilizar o parser como software livre, tendo como principal interesse, a evolução do sistema adicionando funções novas, melhorias de performance no código e no gerador, uma atualização do mesmo com possiveis mudanças da estrutura de modelagem do framework Django Atualmente há uma projeto de implementação de maquina de workflow em django chamado GoFlow 1. Uma das possibilidade de trabalho futuro, seria a integração de diagramas de estados com uma maquina de workflow. A proposta seria criar diagramas de classe e da mesma forma que hoje, são geradas classes para o sistema seriam gerados, rotinas de workflow. 1

38 38 REFERÊNCIAS BEZERRA, E. Princípios de Análise e Projeto de Sistemas com Uml. [S.l.]: Campus, DJANGO the web framework for perfectionists with deadlines. DORR, B. J. Interlingual machine translation: a parameterized approach. Artificial Intelligence, v.1, n.63, p , GROUP, O. M. MOF 2.0/XMI Mapping, Version , v.1, n.1, LEFF AVRAHAM; RAYFIELD, J. T. Web-Application Development using the Model/View/Controller Design Pattern., v.1, n.1, MAURER, I. Python Web Frameworks, part 1: Develop for the Web with Django and Python., v.1, n.1, july 2006.