1

Revista Eletrônica da Faculdade Metodista Granbery http://re.granbery.edu.br - ISSN 1981 0377

Curso de Sistemas de Informação - N. 5, JUL/DEZ 2008

VISÃO GERAL DE UMA FERRAMENTA PARA GERAÇÃO DE APLICAÇÕES:

O MOLA FRAMEWORK

Gustavo Mendes de Castro1

Elio Lovisi Filho 2

RESUMO

Este artigo apresenta uma visão geral de uma ferramenta para geração de aplicações: o

Mola Framework. Esta ferramenta possibilita a geração de parte do código e do script do

banco de dados a partir do diagrama de classes da aplicação. Apresenta-se aqui a forma de

utilização da ferramenta, bem como um análise do código gerado pela mesma.

PALAVRAS-CHAVE: FRAMEWORK, PERSISTÊNCIA, GERAÇÃO DE CÓDIGO

ABSTRACT

This article presents a general vision of an applications generator tool: the Mola

Framework. This tool makes possible the code and the data base script generation from the

class diagram of an application. The way of use of the tool is presented here, as well as an

analysis of the code generated for the same one.

KEY-WORDS: FRAMEWORK, PERSISTENCE, CODE GENERATOR

1 - Graduando em Sistemas de Informação pela Faculdade Metodista Granbery e

programador da Prefeitura de Juiz de Fora. Email:gustavomanso@gmail.com

2 - Mestre em Informática pelo Instituto Tecnológico de Aeronáutica, Professor do curso de

Sistemas de Informação da Faculdade Metodista Granbery e Analista de Sistemas da

Prefeitura de Juiz de Fora. Email:eliolovisi.professor@gmail.com

2

1. INTRODUÇÃO

Observa-se atualmente que uma série de padrões de projeto e de arquitetura

estão sendo incorporados ao processo de desenvolvimento de um software, principalmente

para Web, como por exemplo, o MVC (Model, View, Controller) e o DAO (Data Access

Object). No entanto, o emprego desses padrões pode incluir várias tarefas repetitivas ao

cotidiano dos desenvolvedores, exigindo um esforço adicional de codificação (FOWLER,

2005).

Sendo assim, o objetivo do Mola Framework é auxiliar o desenvolvedor na

aplicação dos padrões MVC - model 2, MVP (Model, View, Presenter) - passive view,

DAO, Singleton, Factory e DTO (Data Transfer Object) para o desenvolvimento de

aplicações Web na linguagem PHP (PHP Hypertext Preprocessor). Além disso, o Mola

Framework também auxilia o desenvolvedor na criação do banco de dados e das camadas

de visão e persistência da aplicação que se deseja construir (FOWLER, 2008).

O Mola Framework está sendo desenvolvido desde Janeiro de 2008 para o

Trabalho de Conclusão de Curso do discente Gustavo Mendes de Castro da Faculdade

Metodista Granbery - Juiz de Fora - MG sob orientação do docente Elio Lovisi Filho.

Nos próximos itens são apresentadas as características desse framework, sua

aplicação, a análise do código gerado, as conclusões obtidas, e ainda, propostas para

trabalhos futuros.

2. CARACTERÍSTICAS DO MOLA FRAMEWORK

O Mola Framework tem como objetivo principal auxiliar no desenvolvimento

de sistemas Web, além de facilitar o processo de manutenção dos mesmos. Para tanto,

permite que, através do diagrama de classes de entidades de um sistema de informação,

gere-se o código-fonte para o sistema e o script para os SGBD’s (Sistema Gerenciador de

Banco de Dados) MySQL 5 e PostGreSQL 8.

Como o framework encontra-se ainda em desenvolvimento no âmbito

acadêmico, o seu código poderá ser obtido apenas por meio de contato direto com os

autores deste artigo. Pretende-se futuramente disponibilizá-lo para utilização dos docentes

da Faculdade Metodista Granbery.

O framework foi desenvolvido em PHP 5, e encontra-se atualmente na versão

2.4.2, podendo ser executado nos navegadores Internet Explorer 6 ou superior, Mozila

Firefox 1.5 ou superior (PC/Mac), Safari 3 ou superior e Opera 9 ou superior (PC/Mac).

Como pré-requisito para utilização do Mola Framework é necessário conhecer as

seguintes tecnologias e ferramentas:

− Linguagem de programação PHP orientada a objetos;

− Linguagem de programação JavaScript com o framework JQuery;

− Padrões de arquitetura de software: MVP ou MVC;

− Framework Smarty, caso adote a abordagem MVP; e

− Padrões de projeto DAO, Singleton, Factory.

O Mola Framework é disponibilizado como um arquivo compactado

molaframework2.4.2.zip. Para utilizar os seus serviços, deve-se descompactar este arquivo

numa pasta pública de um servidor Web, como por exemplo, a pasta htdocs do Apache.

Neste servidor deve estar instalado o SGBD que pretende-se utilizar (MySQL /

PostgreSQL), PHP 5 e ter permissão de escrita em sua estrutura. O usuário deve acessar a

raiz da estrutura de pastas do sistema através do arquivo index.html. Na pasta docs do

framework há um exemplo de diagrama de classes desenvolvido na ferramenta StarUML e

o arquivo XMI extraído do próprio exemplo.

Deve-se elaborar um diagrama de classes que modele a aplicação a ser

construída. Este diagrama deverá ser desenvolvido utilizando uma ferramenta CASE

(Computer-Aided Software Engineering) para OO (Orientação a Objetos) que gere um

arquivo XMI (XML Metadata Interchange) válido, segundo o padrão da OMG (Object

Management Group) MOF 2.0 / XMI Mapping Specification, v2.1.1 (OMG 2007). Para a

realização de testes no Mola foi utilizada a ferramenta StarUML 5 no ambiente Design

Model.

O diagrama de classes da aplicação deve seguir alguns padrões, adotados pelo

Mola Framework, citados abaixo:

− Stereotype das classes: o estereotipo de classes é obrigatório. Nele o

interpretador reconhecerá em qual schema de banco de dados será criada

a tabela relativa à classe;

− Stereotype dos atributos: o estereotipo dos atributos não é obrigatório.

Deve-se utilizá-lo para indicar que o referido campo do banco de dados

não poderá ser nulo. Portanto para utilizá-lo, deve-se usar a expressão

reservada "not null";

− Visibility dos atributos: a visibilidade dos atributos é obrigatória. Deve-se

utilizar os padrões da UML (Unified Modeling Language): public,

private ou protected; e

− Type dos atributos: O tipo dos atributos é obrigatório. Deve ser usado

para especificar o tipo dos campos no banco de dados. Caso seja usado

os tipos nativos da UML, o Mola Framework converterá em tipos do

banco de dados conforme a tabela abaixo.

UML Banco de Dados

String varchar(255)

Float float

Boolean bool

Integer int

Tabela 1. Relacionamento entre os tipos da UML e do Banco de dados.

Além disso, outros padrões deverão ser observados para utilização do Mola:

− Não poderá, em um relacionamento, ter cardinalidade mínima

obrigatória dos dois lados;

− Não se deve usar, em nomes de atributos, a palavra reservada “id”, pois

este atributo será gerado automaticamente. O framework gera um

atributo “id” para cada classe, a menos que esta classe tenha “pai”. Neste

caso, as classes filhas herdarão o atributo “id”;

− Não se deve criar métodos para operações CRUD (Create, Read, Update

e Delete). O Mola se encarrega de criar estas operações;

− Nomes de atributos e classes devem ser o mesmo de campos e tabelas no

banco de dados, respectivamente. O Mola Framework gera com este

padrão. Se o usuário precisar modificar algum nome ou acrescentar mais

atributos ou classes, deve-se respeitar este padrão. Isso pelo fato da

camada de modelo ser utilizada também como mapeamento;

− Não poderá haver atributo com os seguintes nomes: orderby, start, limit,

return, required, totalpages, numrows, page, fieldsgrid,

labelassociationgrid, where, stereotype, além de “id” já citado acima; e

− Não poderá haver métodos de acesso - getters e setters.

2. UTILIZAÇÃO DO MOLA FRAMEWORK

Neste item é apresentada a utilização do Mola Framework. As ilustrações a

seguir apresentam as configurações disponíveis para geração da aplicação.

Ilustração 1. UML Options

Nesta opção o usuário define em qual visão UML da ferramenta CASE foi

desenvolvido o diagrama de classes. No diagrama exemplo, localizado na pasta docs do

Mola, foi utilizado no ambiente Design Model.

Ilustração 2. File Browse.

Aqui define-se o arquivo XMI a ser interpretado.

Ilustração 3. Application Options.

Nesta opção o usuário define o nome da aplicação a ser gerada. Este campo é

obrigatório, e definirá o nome da pasta onde ficarão os arquivos, além de ser o título padrão

da página inicial.

Ilustração 4. Database Options

Nesta opção define-se qual o SGBD será utilizado na aplicação gerada,

podendo ser MySQL e/ou PostGreSQL. É possível utilizar até os dois SGBD’s ao mesmo

tempo.

Ilustração 5. Development Options

O usuário define qual padrão de arquitetura será utilizada. Pode-se escolher

entre MVC e MVP. A abordagem MVP adota o modelo passive view, já o MVC adota

model 2. No MVP (recomendado) é gerado também a camada visual. Já no MVC não é

gerada a camada visual, apenas é montada a estrutura de diretórios.

Ilustração 6. Definição da linguagem de programação a ser adotada.

NOTA: na versão atual, é possível gerar o código-fonte para aplicações em PHP.

Após a submissão do arquivo XMI, o Mola Framework identifica, na parte

superior do painel à direita, as classes, métodos, atributos e associações encontradas no

diagrama de classes. Para cada componente encontrado são identificadas informações como

visibilidade, tipo, entre outros.

Na parte inferior do painel à direita, o usuário deve informar os componentes

que ele deseja que sejam processados pela ferramenta. Para tanto, ele deverá arrastar os

componentes da parte superior para a parte inferior, confirmando assim quais os

componentes farão parte da aplicação a ser gerada.

As figuras 7 e 8 apresentam, respectivamente, a identificação das classes de

uma aplicação, e as classes selecionadas para geração da aplicação.

Ilustração 7. Identificação das classse da aplicação

Ilustração 8. Componentes escolhidos pelo usuário para geração da

aplicação.

Finalmente, após a seleção dos componentes desejados, o usuário deverá

selecionar a opção 'generate code' para a geração do código das classes selecionadas e do

script do banco de dados. Após o usuário selecionar essa opção, o framework inicia a

execução, mostrando o progresso da operação ao usuário, conforme apresentado na figura a

seguir.

Ilustração 9. Tela de espera enquanto o Mola Framework gera a aplicação. Após isso, o Mola informa que o processo foi encerrado com sucesso.

3. AVALIAÇÃO DA APLICAÇÃO GERADA PELO FRAMEWORK

Conforme citado anteriormente, o Mola Framework gera automaticamente

classes para diferentes funções da aplicação. Estas classes são divididas em camadas de

acordo com a funcionalidade das mesmas.

Deve-se ressaltar que, para possibilitar a transição de dados entre as camadas

são utilizados objetos DTO (Data Transfer Object), permitindo também uma maior

independência entre as mesmas. Os objetos do DTO gerados pelo framework serão

explicados com mais detalhes no item 3.3.4.

3.1. INCLUSÃO DE ARQUIVOS

Para utilizar uma classe (instanciar objeto) as linguagens de programação

exigem que se importe o arquivo onde localiza-se a referida classe. Em Java, por exemplo,

utiliza-se a palavra reservada import. Em PHP utiliza-se normalmente include para incluir o

arquivo desejado. Existe ainda, em PHP, um "método genérico" que recebe como

parâmetro, o nome da classe que deseja-se incluir. Este método é chamado sempre quando

não se inclui o arquivo. Seguindo os padrões do Mola framework, onde o nome de cada

classe exige o sufixo que é nome do pacote onde localiza-se a classe, para incluir um

arquivo basta incluir apenas um arquivo: autoload.php localizado na raiz do sistema. A

vantagem disto é que para incluir um ou mais arquivos dentro de um arquivo é necessário

apenas uma inclusão. Este arquivo citado (autoload.php) se encarrega de fazer todas as

chamadas necessárias.

Nos próximos itens são apresentadas as camadas geradas para a aplicação.

3.2. PERSISTÊNCIA DOS DADOS

O Mola Framework possui sua própria camada de persistência, semelhante ao

hibernate. Abaixo serão descritos métodos públicos desta camada de persistência:

− save: o parâmetro deste método é o objeto DTO a ser persistido. Se o atributo

identificador do objeto (id) estiver preenchido, será feita uma atualização, senão

o sistema fará uma inserção. É comum precisar saber qual foi o “id” do último

registro inserido. Para isso a camada de persistência retorna o “id” toda vez que

se chama o método save. Caso ocorra algum erro, é gerada uma exceção na

camada de persistência e esta exceção é repassada as demais camadas até chegar

à visão e fazer com que o desenvolvedor tenha acesso ao erro exato na hora de

fazer alguma chamada ao banco de dados;

− delete: o parâmetro deste método é o objeto DTO a ser apagado. Deve-se estar

com o “id” do objeto preenchido;

− getnumrows: o parâmetro deste método é o objeto DTO relativo à tabela que

deseja-se saber o número de registros. Retorna um inteiro representando o

número de registros em uma determinada tabela do banco de dados;

− selectbyquery: o parâmetro deste método é um comando SQL (Strutured Query

Language) válido. É retornado o resultado da query;

− select: este método realiza consultas personalizadas. O parâmetro deste método

é o objeto DTO a ser buscado. É possível executar diversas consultas com este

método. Para realizar as consultas deve-se atribuir valores ao objeto.

NOTA: Caso o usuário escolha MySQL ou PostgreSQL o retorno será um array com o

resultado. Se o usuário escolher utilizar os dois SGBD’s ao mesmo tempo, retornará um

array associativo com duas posições (['mysql'] e ['postgresql']). Em cada uma destas duas

posições pode-se escolher entre array de objetos, array de arrays, notação JSON

(JavaScript Object Notation), além de array montado para facillitar a transição de dados

para o Smarty. Para esolher entre esses tipos de retorno é necessário atribuir os valores

'object', 'array', 'json', 'smarty' (configura um array associativo) ao atributo return existente

em cada classe DTO.

A tabela abaixo mostra como utilizar os comandos através do exemplo de uma

classe chamada "pessoa" com os atributos "id" e "nomepessoa".

Comando SQL Utilização (com MVP troca-se controller por presenter)

INSERT INTO pessoa (id,nomepessoa) values ('1','Gustavo')

$pessoacontroller = new pessoacontroller(); $pessoadto = new pessoadto (); $pessoadto->setnomepessoa('Gustavo'); $pessoacontroller->save($pessoadto);

DELETE FROM pessoa WHERE id = '1'

$pessoacontroller = new pessoacontroller(); $pessoadto = new pessoadto();

$pessoadto->setid('1'); $pessoacontroller->delete($pessoadto);

UPDATE pessoa SET nomepessoa = 'Gustavo Mendes' WHERE id = '1'

$pessoacontroller = new pessoacontroller(); $pessoadto = new pessoadto (); $pessoadto->setid('1'); $pessoadto->setnomepessoa('Gustavo Mendes'); $pessoacontroller->save($pessoadto);

SELECT * FROM pessoa $pessoacontroller = new pessoacontroller(); $pessoadto = new pessoadto(); $pessoacontroller->read($pessoadto);

SELECT * FROM pessoa WHERE id = '1'

$pessoacontroller = new pessoacontroller(); $pessoadto = new pessoadto(); $pessoadto->setid('1'); $pessoacontroller->read($pessoadto);

SELECT * FROM pessoa WHERE id = '1' AND nomepessoa = 'Gustavo'

$pessoacontroller = new pessoacontroller(); $pessoadto = new pessoadto(); $pessoadto->setid('1'); $pessoadto->setnomepessoa('Gustavo'); $pessoacontroller->read($pessoadto);

SELECT * FROM pessoa ORDER BY nomepessoa ASC

$pessoacontroller = new pessoacontroller(); $pessoadto = new pessoadto(); $pessoadto->orderby(array('nomepessoa'=>'ASC')); $pessoacontroller->read($pessoadto);

SELECT * FROM pessoa START 1 LIMIT 10

$pessoacontroller = new pessoacontroller(); $pessoadto = new pessoadto(); $pessoadto->setstart('1'); $pessoadto->setlimit('10'); $pessoacontroller->read($pessoadto);

Tabela 2. Utilização dos comandos de persistência.

Deve-se ressaltar que, se houverem relacionamentos n para n no diagrama de

classes da aplicação, por padrão, o framework cria classes e tabelas intermediárias.

Além disso, o Mola Framework adota uma estratégia denominada lazy load

(carregamento retardado) para carregamento dos objetos relacionados que torna-o capaz de

obter navegabillidade entre objetos. Esta estratégia consiste em carregar os objetos apenas

no momento em que eles forem necessários. Para tanto é criado um método

“getnomeobjeto” que faz a busca no banco de acordo com o objeto solicitado.

3.3. CAMADAS COMUNS - INDEPENDENTES DA ARQUITETURA

3.3.1. CAMADA UTILS

Na camada utils estão localizadas as funcionalidades de emprego genérico da

aplicação. Os seguintes arquivos compõem esta camada:

− _connectionutils.php – nesta classe estão as informações referentes à conexão

com o banco de dados. Os atributos usemysql e usepostgresql recebem os

valores true ou false indicando qual(is) SGBD(s) será(ão) utilizado(s) na

aplicação;

− _allutils.php – nesta classe estão as validações e máscaras de CPF, CNPJ, email

e datas;

− _databaseutils.php – interface que será implementada pela camada de

persistência;

− _jsonutils.php – codificador e decodificador do formato JSON para array PHP e

vice-versa; e

− _persistenceutils.php – classe de persistência semelhante ao hibernate.

3.3.2. CAMADA PERSISTENCE

Além dos arquivos _genericpersistence.php e _interfacepersistence.php

comuns à todas aplicações, há também os arquivos de persistência referentes à cada classe

de modelo que deverão herdar de _genericpersistence.php, listados a seguir:

− _genericpersistence.php - classe onde são implementados os métodos de operações

CRUD, o método getnumrows, responsável por recuperar o número de registros de uma

tabela referente à classe e o método readbyquery onde poderá ser executado qualquer

comando SQL válido; e

− _interfacepersistence.php - interface responsável por determinar quais métodos deverão

ser implementados na classe _genericpersistence.

3.3.3. CAMADA MODEL

Camada onde estão localizadas as classes de modelo da aplicação. As classes

desta camada possuem apenas atributos privados e métodos de acesso (getters e setters)

públicos. Optou-se por esta abordagem para que a camada de modelo encapsule os objetos

de modelo da aplicação. Esta camada é utilizada também, como mapeamento objeto-

relacional para a classe de persistência gerada pelo o Mola Framework.

O tratamento de herança é uma parte complexa para o mapeamento objeto-

relacional. Herança é uma funcionalidade da orientação a objetos que os SGBD's

relacionais não implementam completamente. Sendo assim, existem algumas soluções

possíveis para esta limitação. Na primeira, todos atributos de classes que tenham filho(s)

são replicados para as classes filhas, com isso, as "classes pai" não teriam tabelas referentes

à elas no banco de dados. Replicariam-se assim todos atributos do pai para cada filho. Essa

estratégia, além de fazer com que várias tabelas contenham atributos repetidos, é

praticamente certo de que aconteceria algum problema com campos que não aceitam valor

nulo.

Na tentativa de buscar uma solução mais próxima da OO, criou-se para cada

classe uma tabela no banco de dados correspondente. Para que a classe filha (por exemplo

tendo a tabela correspondente A) acesse atributos do pai (tabela B) a camada de peristência

cria o comando SELECT com junção entre as tabelas A e B.

Além disso, o Mola Framework auxilia também na geração de uma

funcionalidade bastante comum nos sistemas de informação: a necessidade de registro (log)

de alterações e acessos aos dados do sistema. O desenvolvedor não tem que se preocupar

como será feito o log, pois o Mola Framework gera automaticamente uma forma de

controle para tanto. Essa funcionalidade é realizada por meio de uma coluna existente em

cada tabela do banco de dados onde registra-se a data e hora do dado inserido. Todas as

vezes que algum registro de alguma tabela for alterado, o Mola grava em uma tabela a

parte, todas as atualizações dos registros das tabelas. Essa tabela chama-se updatedat.

3.3.4. OBJETOS DTO

Os objetos DTO gerados pelo framework herdam dos objetos da camada model,

e, conforme citado anteriomente, permitem a transição de dados entre as camadas de visão

e controle. As classes DTO têm alguns atributos de configuração vistos a seguir:

− stereotype: guarda o schema do banco de dados relacionado a tal classe;

− return: seu valor pode ser ”array”, “object”, “json” ou “smarty”. Indica qual o formato

de dados do retorno de uma consulta SQL.

Os demais atributos (orderby, start, limit) são utilizados para montar consultas

SQL.

3.3.5. CAMADA CONTROLLER

Na camada controller estão os arquivos _factorycontroller.php,

_genericcontroller.php, _interfacecontroller.php que são comuns à todas aplicações e os

arquivos de controller referentes à cada arquivo de modelo criado. Deve-se ressaltar que no

padrão arquitetural MVP esta camada se chama service. As seguintes classes estão

localizadas nesta camada:

− _factorycontroller.php - é a classe responsável por instanciar a referente classe

persistence;

− _genericcontroller.php - é a classe onde são implementados os métodos controladores.

Todas as classes de controller deverão herdar desta; e

− _interfacecontroller.php - é a interface responsável por determinar quais métodos

deverão ser implementados nos controllers.

3.3.6. DOCS

Pasta onde estão localizados os scripts para os SGBD’s MySQL e PostGreSQl.

Independentemente da escolha do SGBD por parte do usuário, o script dos dois SGBD’s

serão criados.

3.4. ARQUITETURA DA APLICAÇÃO GERADA

O Mola Framework permite aos usuários selecionar o padrão de arquitetura do

software gerado entre duas opções: MVC - model 2 (Model, View, Controller) e MVP –

passive view (Model, View, Presenter).

3.4.1. MVC - MODEL 2

Esta arquitetura é gerada somente se a opção MVC - model 2 for selecionada.

Deve-se ressaltar que a diferença básica para entre o MVC tradicional e o padrão

arquitetural model 2 é que na primeira abordagem os objetos de modelo não são

instanciados na camada de visão. A camada de visão "enxerga" apenas a camada de

controller e objetos DTO. Neste modelo não é gerada a camada view.

3.4.2 MVP - PASSIVE VIEW

De forma análoga ao item anterior, esta arquitetura é gerada somente para a

opção MVP. Neste padrão arquitetural o Mola Framework utiliza em sua estrutura o

framework Smarty para separar a lógica da camada view. A camada presenter é responsável

por administrar os eventos da view.

3.5. SGBD

É possível usar dois SGBD’s ao mesmo tempo – MySQL e PostGreSQL. O

script é gerado juntamente com a aplicação e estará disponível na pasta docs da aplicação –

mesmo que o usuário não utilize os dois SGBD’s.

4. CONCLUSÃO

O Mola Framework foi concebido inicialmente para ser uma camada de

persistência para abstrair alguns comandos SQL de aplicações desenvolvidas em PHP.

Visando produtividade com qualidade foram sendo implementadas funcionalidades para

facilitar e padronizar o processo de desenvolvimento de um software comercial. Hoje, o

Mola Framework é capaz de gerar a aplicação com operações CRUD propondo

metodologias que já foram empregadas com sucesso em vários segmentos da engenharia de

software. Portanto o Mola não é apenas um gerador que toma como base algum modelo. É,

além disto, um interpretador de diagrama que se propõe a apresentar uma metodologia de

desenvolvimento.

Pretende-se dar continuidade no projeto após a apresentação do Trabalho de

Conclusão de Curso. Para tanto, os itens listados abaixo fazem parte das principais

funcionalidades a serem implementadas:

− aperfeiçoamento da documentação, manual, guia rápido e help;

− testes unitários automatizados;

− geração de aplicativo para as linguagens Java e .NET; e

− interpretação de diagrama de sequência.

5. REFERÊNCIAS

Fowler, Martin, UML essencial: um breve guia para a linguagem-padrão de

modelagem de objetos, 3. ed. – Porto Alegre: Bookman, 2005.

Kruchten, Philippe, Introdução ao RUP – Rational Unified Process, 3. ed. – Rio de

Janeiro: Ciência Moderna, 2003.

Pressman, Roger S., Engenharia de Software, 5. ed. - Rio de Janeiro: McGraw-Hill, 2002.

Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John. Padrões de projeto:

soluções reutilizáveis de software orientado a objetos, Porto Alegre: Bookman, 2000.

Sommerville, Ian, Engenharia de software, 8. ed. – São Paulo: Pearson Addison –

Wesley, 2007.

Laureano, Jeziel, Construção de um componente para geração de código a partir de

diagramas UML, 2002, 61 p.:il. Trabalho de Conclusão de Curso (Graduação em Ciência

da Computação). Universidade Luterana do Brasil, Gravataí, 2002.

OMG. MOF 2.0 / XMI Mapping Specification, v2.1.1. Disponível em:

<www.omg.org/technology/documents/formal/xmi.htm>. Acesso em 15 mai. 2008.

Fowler, Martin, Disponível em: <http://www.martinfowler.com/>. Acesso em jul. 2008.