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:[email protected]
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:[email protected]
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.