Você está na página 1de 59

Equipe abnTEX2

Modelo Cannico de
Trabalho Acadmico com abnTEX2

Brasil
2013, v-1.7.1
Equipe abnTEX2

Modelo Cannico de
Trabalho Acadmico com abnTEX2

Modelo cannico de trabalho monogrfico


acadmico em conformidade com as normas
ABNT apresentado comunidade de usu-
rios LATEX.

Universidade do Brasil UBr


Faculdade de Arquitetura da Informao
Programa de Ps-Graduao

Orientador: Lauro Csar Araujo


Coorientador: Equipe abnTEX2

Brasil
2013, v-1.7.1
Resumo
A maioria dos sistemas computacionais comerciais utilizam algum tipo de
banco de dados para o armazenamento persistente de informaes. Estes sistemas
geralmente possuem operaes de insero, leitura, edio e remoo destas informa-
es e so conhecidos como sistemas CRUD. Scaffolding uma tcnica que utiliza a
camada de modelo do padro MVC para gerar automaticamente as camadas de viso
e controle. Este trabalho prope a implementao de um mdulo para o framework
Play que utiliza a tcnica de scaffolding para automatizar o processo de criao de
sistemas CRUD. Foi criado um mecanismo que utiliza reflexo e anotaes para
extrair os metadados de todas as classes de modelo. Os templates das classes de
viso e controle foram criados seguindo princpios de simplicidade e funcionalidade.
A combinao dos metadados extraidos e dos templates predefinidos resultaram na
gerao dos cdigos-fonte das camadas de viso e controle. As anlises do consumo
de memria e tempo de execuo foram satisfatrias e o mdulo final cumpriu os
objetivos propostos. Um caso de uso foi criado para testar a qualidade do mdulo
implementado.

Palavras-chaves: Scaffolding; Play Framework; CRUD; Metaprogramao


Abstract
Most commercial computer systems use some kind of database for persis-
tent storage of information. These systems usually have operations for insertion,
reading, editing and removal of this information and are known as CRUD systems.
Scaffolding is a technique that uses the model layer of the MVC pattern to auto-
matically generate the view and controller layers. This dissertation proposes the
implementation of a plugin for the Play framework that uses the scaffolding tech-
nique to automate the creation process of CRUD systems. A mechanism that uses
reflection and annotations was created to extract the metadata of all model classes.
The templates of view and controller classes were created following principles of
simplicity and functionality. The combination of the extracted metadata and de-
fault templates resulted in the generation of source code of the view and controller
layers. The analysis of memory consumption and runtime were satisfactory and the
final plugin fulfill those goals. A use case was created to prove the quality of the
implemented plugin.

Key-words: Scaffolding; Play Framework; CRUD; Metaprogramming


Sumrio

1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Organizao do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Fundamentao Terica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Convenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.1 Conveno Sobre Configurao . . . . . . . . . . . . . . . . . . . . 22
2.2 Padres Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Metaprogramao Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 Metadados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2 Metaprogramao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.3 Java Annotations API . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.4 Java Reflections API . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Sistemas CRUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5 Scaffolding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.1 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5.2 Scaffolding no Framework Rails . . . . . . . . . . . . . . . . . . . . 42
2.5.3 Scaffolding no Framework Grails . . . . . . . . . . . . . . . . . . . . 43
2.6 Trabalhos Similares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.7 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3 Scaffolder, Um Gerador de Sistemas CRUD . . . . . . . . . . . . . . . . . . 49

4 Experimentos e Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Lista de ilustraes

Figura 1 Padro Arquitetural MVC . . . . . . . . . . . . . . . . . . . . . . . . . 24


Figura 2 Metaprogramao: caso geral . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 3 Metaprogramao: reflexo . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 4 Estrutura bsica de um Sistema CRUD . . . . . . . . . . . . . . . . . . 34
Figura 5 Scaffolding baseado em Templates . . . . . . . . . . . . . . . . . . . . . 39
Figura 6 Esquema terico da tcnica de scaffolding . . . . . . . . . . . . . . . . 41
Figura 7 Comando generate do frameworks Rails . . . . . . . . . . . . . . . . . 43
Figura 8 Comando generate controller e exemplo de uso . . . . . . . . . . . 44
Figura 9 Comando generate scaffold e arquivos criados . . . . . . . . . . . . 44
Lista de Listagens

Listagem 2.1 Conveno de nome para mtodos e atributos . . . . . . . . . . . . . 21


Listagem 2.2 Classe User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Listagem 2.3 Configurao XML para Hibernate . . . . . . . . . . . . . . . . . . . 23
Listagem 2.4 Comando SQL para criao da tabela . . . . . . . . . . . . . . . . . 23
Listagem 2.5 Uso da anotao @Entidade . . . . . . . . . . . . . . . . . . . . . . . 29
Listagem 2.6 Declarao do tipo-anotao Entidade . . . . . . . . . . . . . . . . . 30
Listagem 2.7 Sintaxes da anotao Entidade . . . . . . . . . . . . . . . . . . . . . 31
Listagem 2.8 Obtendo classes para reflexo . . . . . . . . . . . . . . . . . . . . . . 33
Listagem 2.9 Exemplo de contextos . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Listagem 2.10Exemplo de fragmento de cdigo-fonte . . . . . . . . . . . . . . . . . 39
Listagem 2.11Exemplo de template baseado na Listagem 2.10 . . . . . . . . . . . . 39
Listagem 2.12Exemplo de cdigo gerado . . . . . . . . . . . . . . . . . . . . . . . . 40
Listagem 2.13Scaffolding Dinmico na classe HighScoreController para o modelo
HighScore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Listagem 2.14Scaffolding Dinmico na classe HighScoreController para o modelo
Placar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Listagem 2.15Adicionado e sobrescrevendo mtodos na classe BookController . . 46
Listagem 2.16Comandos para gerao esttica no framework Grails . . . . . . . . 46
Lista de tabelas

Tabela 1 Mtodos de introspeco da classe Class . . . . . . . . . . . . . . . . . 33


Tabela 2 Mtodos de intercesso da API Reflections . . . . . . . . . . . . . . . . 34
Tabela 3 Operaes CRUD em SQL e HTTP . . . . . . . . . . . . . . . . . . . . 35
Tabela 4 Comparao entre os termos de engenharia civil e programao . . . . 36
Tabela 5 Tabela com rotas geradas para o modelo HighScore . . . . . . . . . . 43
Tabela 6 Comparao entre as principais caracteristicas dos trabalhos . . . . . . 48
Lista de abreviaturas e siglas

WWW World Wide Web

W3C World Wide Web Consortium

IBM International Business Machines

HTTP Hypertext Transfer Protocol

HTML HyperText Markup Language

CSS Cascading Style Sheets

CRUD Create Read Update Delete

IDE Integrated Development Environment

MVC Model View Controller

CoC Convention over Configuration

SQL Structured Query Language

XML eXtensible Markup Language

DAL Data Access Layer

JSON JavaScript Object Notation

API Application Programming Interface

FQN Full Qualified Name

NoSQL Not Only SQL

DML Data Manipulation Language

JSP JavaServer Pages

ISBN International Standard Book Number

CPF Cadastro de Pessoa Fsica


1 Introduo

A histria da comunicao foi marcada por diversas invenes que revolucionaram


o modo como a informao transmitida entre as pessoas. A prensa de Gutenberg possi-
bilitou a confeco de livros em larga escala. Com o telefone de Graham Bell duas pessoas
poderiam ter uma conversa a distncia. O rdio tornou-se um meio de comunicao de
massas: a transmisso da informao percorria grandes distncias e alcanava milhares de
pessoas ao mesmo tempo. A televiso ainda uma das principais opes de entreterimento
das famlias contemporneas. Apesar disso, uma inveno em especial pode ser conside-
rada como a que mais influenciou a histria da humanidade recente, tanto na comunicao
quanto em diversas outras reas: a internet.
A internet um mecanismo capaz de disseminar mundialmente informaes e
possibilita a interao e colaborao entre pessoas, independente da localizao geogrfica
(LEINER et al., 2009). A internet causou uma revoluo sem precedentes no mundo
da comunicao e tecnologia. Ela integra todas as funcionalidades das invenes citadas
anteriormente: consegue transmitir texto, udio e vdeo para o mundo todo.
J. C. R. Licklider escreveu em 1962 o primeiro documento relatando interaes
sociais por meio de redes de computadores. Ele imaginava um conjunto de computadores
globalmente interconectados com dados acessveis rapidamente de qualquer site, conceito
muito parecido com a internet dos dias de hoje (LEINER et al., 2009)
Vrios estudos foram realizados em diversas reas da informtica para que os con-
ceitos bsicos da internet se tornassem realidade. Organizaes governamentais, universi-
dades e fabricantes se uniram para solucionar diversos problemas que foram surgindo tais
como interconexo entre redes de diferentes arquiteturas, transmisso eficiente de dados,
infraestrutura operacional, suprir interesses da comunidade cientfica, despertar interesse
da comunidade emergente de usurios domsticos, etc. Diversas tecnologias surgiram dessa
unio e a internet amadureceu muito desde a sua criao, mas o surgimento da tecnolo-
gia Web pode ser considerado como marco inicial de profundas mudanas tecnolgicas,
sociais, polticas e econmicas na humanidade.
Berners-Lee foi o fundador da World Wide Web, tambm conhecida como WWW
ou web (BERNERS-LEE, 1989). Muitas de suas ideias iniciais ainda existem na web
atual: descentralizao da informao, acesso independente de hardware e software, faci-
lidade de criao e compartilhamento de contedo. Berners-Lee tambm foi o fundador
da W3C (World Wide Web Consortium), instituio responsvel por padronizar os pro-
tocolos e tecnologias utilizadas na construo da web, de modo que o seu contedo seja
o mais acessvel possvel. Atualmente a maioria das grandes empresas so membros desse
consrcio: Facebook, Google, Microsoft, IBM, Twitter, Oracle, etc (W3C, 2014). Esta pa-
dronizao e unio contribuiram fortemente para a rpida evoluo e popularizao da
web e da internet em si.
Uma pesquisa realizada pela empresa Internet World Stats revela que o numero
de usurios da internet aumentou quase 7 vezes de 2000 a 2014 e que 40% da populao
mundial utiliza a internet atualmente (IWS, 2014). Esse crescimento sem precedentes
influenciou positivamente a rea de desenvolvimento web. Novas metodologias, tecnologias
e ferramentas foram criadas para que desenvolvedores se tornassem mais produtivos e
dinmicos e pudessem acompanhar as exigncias da web moderna. Os frameworks web
so importantes ferramentas de desenvolvimento. Desenvolvedores conseguem economizar
uma quantidade significativa de tempo na construo de websites quando se utiliza os
frameworks apropriados (SCHWARTZ, 2014).
Segundo Fayad e Schmidt (1997), frameworks orientados a objetos representam
uma aplicao abstrata formada por blocos pr-fabricados de software que os programa-
dores podem usar, estender ou adaptar para uma soluo especfica. Estes blocos normal-
mente representam exigncias bsicas de uma aplicao web, otimizaes para melhoria
de desempenho e automaes de cdigo para aumento de produtividade. Exemplos de
exigncias bsicas: HTTP, HTML, CSS, banco de dados, transaes, servidor web, etc.
Exemplos de otimizaes: memria cache, concorrncia, escalabilidade, etc. Exemplos de
automaes de cdigo: templates HTML, geradores de cdigos-clich transparentes ao
desenvolvedor e de uso especfico do framework, geradores de cdigos-fonte visveis e dis-
ponveis ao desenvolvedor.
Os principais benefcios da utilizao de frameworks orientados a objetos so:
modularidade, reusabilidade e extensibilidade. Frameworks modulares ajudam a localizar
mais rapidamente comportamentos inesperados, provenientes de alteraes em blocos de
software. Interfaces estveis garantem a reusabilidade pois suas implementaes genricas
podem ser usadas em novas aplicaes. As implementaes genricas podem ser extendidas
para casos mais particulares, essencial para adio de novas funcionalidades em aplicaes
existentes (FAYAD; SCHMIDT, 1997).

1.1 Motivao
Atualmente vrias empresas esto em busca de solues de software que utilizem
tecnologias web ao invs dos tradicionais softwares nativos. O principal motivo dessa
escolha est intimamente relacionado ao crescimento e popularizao da internet: um
nmero cada vez maior de pessoas acessam a internet diariamente, ou seja, maior contato
dessas empresas com possveis clientes. Alm disso, solues web possuem os benefcios
intrinsecos dessa tecnologia: zero atualiaes, zero instalao, alta disponibilidade, alta
acessibilidade, computao na nuvem.
Geralmente estas solues de software empresariais, seja web ou nativo, possuem
algum mecanismo de manipulao e persistncia de dados. Esse mecanismo deve possuir
as 4 funes bsicas de armazenamento persistente: criao, leitura, edio e remoo
(HELLER, 2007). Essas funes so popularmente conhecidas como CRUD (create-read-
update-delete).
O ritmo dinmico e acelerado da internet cria usurios de aplicaes web cada
vez mais exigentes. Ferramentas, princpios, convenes e padres de desenvolvimento
precisam ser utilizados pelos desenvolvedores para aumentar a produtividade, qualidade
final e cumprir prazos cada vez menores. Frameworks, IDEs, bibliotecas e geradores de
cdigo so algumas das ferramentas que programadores utilizam para se tornarem mais
produtivos.
O mercado atual possui diversos frameworks de desenvolvimento web, a maioria
open source. Esses frameworks fornecem ao programador todas as funcionalidades neces-
srias para a criao de aplicaes web modernas. Alm disso, a maioria dos frameworks
web utilizam o padro de arquitetura MVC (model-view-controller). Esse padro separa
uma aplicao em 3 camadas: modelo, viso e controle (REENSKAUG, 1979).
A diviso em camadas possibilita o uso da tcnica de scaffolding: gerao de c-
digo automtico baseado em informaes da camada de modelo. Essa tcnica aumenta a
produtividade e diminui erros e utilizada em vrios frameworks web tais como Ruby on
Rails, Grails, Spring Roo, CakePHP, etc. Apesar dos benefcios o framework Play ainda
no possui essa funcionalidade.
Portanto as principais motivaes para o desenvolvimento deste trabalho so:

Sistemas CRUD so amplamente utilizados por empresas em aplicaes web.

A maioria dos sistemas implementados atualmente so orientados a modelo e utili-


zam MVC.

Cdigo gerado automaticamente aumenta a produtividade e diminui erros.

Os frameworks web mais utilizados atualmente implementam a tcnica de scaffol-


ding.

Apesar de muito utilizado por grandes empresas (TYPESAFE, 2014a), o framework


Play ainda no utiliza a tcnica de scaffolding.
1.2 Objetivos
Este trabalho prope a implementao de uma ferramenta para o framework Play
que, a partir das entidades da camada de modelo, ir gerar todo o cdigo-fonte neces-
srio para a criao de um sistema CRUD simples e funcional. A criao de cdigo ser
automtica e transparente ao desenvolvedor.
Foram utilizados os seguintes mtodos e tecnologias na implementao da ferra-
menta proposta:

Interfaces para garantir que as classes da camada de controle tenham os mtodos


mnimos exigidos por um sistema CRUD.

Conveno e/ou configurao para definir os nomes e locais dos arquivos gerados.

Reflexo e anotaes para encontrar todas as classes anotadas como entidades e seus
respectivos atributos.

Metaprogramao para armazenar em metadados todas as informaes necessrias


sobre as entidades encontradas.

Geradores de templates para criao de cdigo compilvel a partir dos metadados


existentes.

Os objetivos finais desse trabalho so:

Aumento na produtividade: a tcnica de scaffolding ideal para sistemas CRUD


simples, o tempo gasto na codificao das camadas de controle e viso drastica-
mente reduzido. Talvez algumas adequaes sejam necessrias mas com certeza o
desenvolvedor economizar tempo com essa tcnica. Caso a aplicao final seja mais
complexa, o desenvolvedor poder utilizar o sistema CRUD gerado como base para
essa aplicao.

Diminuio de erros: todo bom gerador de cdigo traz consigo o benefcio da dimi-
nuio de erros pois evita que programadores tenham que digitar tudo a mo, ou
seja, a automao reduz o erro humano.

Contribuio para a comunidade Play: a ferramenta final, implementada a partir


dos estudos realizados neste trabalho, ser disponiblizado comunidade Play na
forma de um mdulo.
1.3 Organizao do trabalho
Este trabalho est dividido em captulos, cada um simbolizando uma fase no desen-
volvimento de uma pesquisa cientfica. O Captulo 2 representa a fundamentao terica.
O Captulo 3 aplica os conceitos tericos para o desenvolvimento prtico, ou seja, repre-
senta o trabalho desenvolvido. O Captulo 4 descreve os experimentos e resultados obtidos.
O Captulo 5 apresenta as concluses e trabalhos futuros. A sntese de cada captulo
listada a seguir:

Captulo 2 - Fundamentao Terica: discute sobre alguns conceitos bsicos neces-


srios para o desenvolvimento de um gerador de cdigo. Os mais importantes so
convenes, padres arquiteturais, operaes CRUD, metaprogramao e tcnicas
de gerao de cdigo.

Captulo 3 - Scaffolder, Um Gerador de Sistemas CRUD: descreve o mdulo desen-


volvido para o framework Play, mostrando seu funcionamento e os detalhes mais
relevantes de sua implementao, principalmente as bibliotecas utilizadas.

Captulo 4 - Experimentos e Resultados: explica os experimentos realizados e analisa


os resultados adiquiridos.

Captulo 5 - Concluses: apresenta as concluses obtidas da anlise dos resultados


e sugere melhorias para trabalhos futuros.
2 Fundamentao Terica

Este captulo apresenta a fundamentao terica necessria para o desenvolvimento


deste trabalho. A seo 2.1 enfatiza a importncia de convenes em projetos de softwares.
A seo 2.2 explica o padro arquitetural MVC e os seus benefcios. A seo 2.3 elucida os
conceitos bsicos de metaprogramao e suas principais ferramentas da linguagem Java:
Annotations e Reflections. A seo 2.4 apresenta uma breve descrio sobre o significado
do acrnimo CRUD e sua utilizao no mercado atual. A seo 2.5 descreve a tcnica
de scaffolding e sua utilizao nos frameworks Rails e Grails. Finalmente, a seo 2.6 faz
uma breve comparao entre este trabalho e outros trabalhos similares.

2.1 Convenes
Convenes so regras, normas, critrios ou acordos preestabelecidos e aceitos
pela maioria da sociedade. Esse conceito tambm pode ser aplicado engenharia de
software. Existem vrios tipos de convenes em computao e cada uma delas pode variar
entre si. Por exemplo, um mesmo tipo de conveno pode variar conforme linguagem de
programao ou local de trabalho. No exemplo da Listagem 2.1, a conveno de nome
para mtodos e atributos varia entre as linguanges de programao Java e Ruby.

// Codigo Java
public void exemploDeMetodo () {
int exem ploDe Atribu to = 0;
}

// Codigo Ruby
def exem plo_d e_meto do
e x em p l o_ d e _a t r ib u t o = 0
end
Listagem 2.1 Conveno de nome para mtodos e atributos

Particularmente, convenes com o objetivo de padronizar cdigo so muito im-


portantes em computao. Em ambientes corporativos, a padronizao de cdigo muito
utilizada, pois agrega ao processo de desenvolvimento de software os seguintes benefcios:

Integrao de cdigo: sistemas complexos geralmente possuem multiplas equipes.


Cdigo padronizado possibilita a unio desses cdigos sem maiores problemas de
compatibilidade.
Diminui comunicao: o cdigo padronizado facilita a leitura e entendimento do
mesmo, portanto membros de uma equipe passam menos tempo explicando o cdigo
e mais tempo trabalhando.

Manuteno: o programador responsvel pela manuteno de cdigo pode no ser


o mesmo que o criou mas como o cdigo padronizado isso no tem problema, sua
compreenso ser automtica.

Ferramentas de automao: ferramentas de automao podem utilizar os mesmos


padres de cdigo dos desenvolvedores para gerar cdigo automaticamente. Como
exemplo pode-se citar a gerao automtica de mtodos de acesso a partir dos nomes
de variveis (getters e setters).

2.1.1 Conveno Sobre Configurao

Conveno sobre Configurao (CoC - Convention over Configuration) um pa-


radigma de desenvolvimento de software muito usado em frameworks configurveis. Seu
objetivo simples: evitar configuraes desnecessrias atravs do uso de convenes. Ape-
sar disso, sua adoo no foi imediata pois a rea de metaprogramao ainda no era
muito difundida, e no existia convenes bem definidas na poca.
Frameworks de armazenamento persistente so um bom exemplo da evoluo desse
paradigma ao longo dos anos. Antigamente eles dependiam somente de arquivos de con-
figurao para a criao de suas tabelas relacionais. A Listagem 2.2 mostra uma classe
simples com poucos atributos. O mapeamento era feito manualmente pelos programado-
res (Listagem 2.3). O framework gerava as tabelas atravs de comandos SQL, de acordo
com o contedo do arquivo de configurao (Listagem 2.4). Atualmente, esse cdigo SQL
gerado automaticamente utilizando metaprogramao e conveno de nomes, ou seja,
no depende de configuraes manuais.

@Entity
public class User {
@Id
private String id ;
private String password ;
// - - getters e setters - -//
}
Listagem 2.2 Classe User
<hibernate-mapping>
<class name="User" table="USERS">
<id name="id" column="ID" type="string"/>
<property name="password" column="PASSWORD" type="string"/>
</class>
</hibernate-mapping>
Listagem 2.3 Configurao XML para Hibernate

CREATE TABLE USERS (


ID VARCHAR (20) NOT NULL ,
PASSWORD VARCHAR (20) ,
PRIMARY KEY ( ID )
);
Listagem 2.4 Comando SQL para criao da tabela

Esse paradigma herda todas as vantagens de se utilizar convenes: menor curva


de aprendizagem de novas tecnologias, menos linhas de cdigo, menos decises, sistemas
prontos mais rapidamente, equipe mais sincronizada, etc.
Sistemas ainda podem ser personalizados e configurados normalmente caso as con-
venes no satisfaam os requisitos do programador. Apesar disso, importante tentar
evitar configuraes que fujam s convenes predeterminadas, pois sistemas inteiros que
dependam dessas convenes podem falhar (MARTIN; MARTIN, 2006).

2.2 Padres Arquiteturais


Sistemas de software podem ser divididos em subsistemas. Padres arquiteturais
determinam as responsabilidades e relacionamentos de cada subsistema. Esses padres
apresentam esquemas estruturais fundamentais para sistemas de software (BUSCHMANN
et al., 1996).
Padres arquiteturais possuem um nivel maior de abstrao quando comparados
com padres de projeto (KAISLER, 2005; BUSCHMANN et al., 1996). So estratgias
mais sofisticadas que abragem um grande nmero de componentes e propriedades de um
sistema de software. Sua utilizao influencia diretamente a estrutura e organizao geral
desse sistema (KAISLER, 2005).

2.2.1 Model-View-Controller
O padro MVC foi criado por Reenskaug (1979) e divide um sistema em camadas.
Essa diviso faz com que o desenvolvimento do produto final seja mais modular e eficiente.
A abstrao em camadas muito utilizada em frameworks web modernos, pois facilita
Figura 1 Padro Arquitetural MVC

a criao de sistemas cada vez mais coesos e menos acoplados. Alguns dos frameworks
mais famosos que utilizam MVC: Grails (PIVOTAL, 2014), Rails (HANSSON, 2003),
Play (TYPESAFE, 2014b), etc.
A Figura 1 ilustra o padro MVC. A camada de modelo uma aproximao por
software de um determinado processo ou sistema do mundo real. A apresentao, unio das
camadas de viso e controle, a camada acessvel ao usurio. Em um sistema de compras
online, a camada de modelo seria os objetos carrinho, produto e usuario por exemplo.
A camada de viso seria as pginas HTML e os cliques do mouse seriam interpretados
pela camada de controle. A descrio de cada camada feita a seguir.

1. Camada de modelo: representa os dados e funcionalidades de uma determinada


aplicao. Regras de negcio do significado a esses dados e definem como eles
so manipulados. Essa camada tambm atualiza a camada de viso sempre que
houver alteraes no estado dos dados (SOMMERVILLE, 2011; FOWLER, 2002).
Geralmente encapsula uma camada inferior expecfica para a manipulao de dados,
conhecida como DAL (data access layer). Ela apresenta as funcionalidades CRUD
de armazenamento persistente. A camada de modelo totalmente independente das
camadas de viso e controle.

2. Camada de viso: formada por vrias interfaces de viso (views). Cada interface
responsvel por apresentar informaes ao usurio. Um modelo pode ser apresentado
por mltiplas interfaces, ou seja, uma mesma informao pode ser apresentada ao
usurio de diferentes maneiras (BUSCHMANN et al., 1996). Em aplicaes web
modernas os tipos mais populares de apresentao so XML, JSON e HTML e
o reponsvel pera interao entre interface e usurio o navegador (browser). Os
navegadores mais conhecidos so: Firefox, Internet Explorer e Google Chrome.

3. Camada de controle: realiza a mediao entre as camadas de viso e modelo. a


camada responsvel por toda a lgica e comportamento do sistema. Recebe eventos
da camada de viso e os processa. Em aplicaes web esses eventos so normal-
mente solicitaes GET ou POST. Esses eventos so convertidos em aes a serem
realizadas pela camada de modelo (alterao do modelo) e/ou camada de viso
(renderizao de nova view).

A separao da camada de modelo considerado como um dos princpios funda-


mentais de bom desenvolvimento de software. No padro MVC essa separao gera duas
situaes importantes: modelo separado da apresentao e viso separada de controle.
As situaes anteriores resultam nas seguintes vantagens (+) e desvantagens (-):

+ Automao de testes: ferramentas de teste que simulam interaes do usurio na


camada de viso so lentas e complicadas. Testes diretamente nos objetos da camada
de modelo so muito mais eficientes e fceis de serem automatizados (FOWLER,
2002).

+ Desenvolvedores especializados: cada camada utiliza conceitos e tecnologias diferen-


tes em sua implementao. Como as camadas so independentes entre si pode-se
utilizar desenvolvedores com conhecimentos especficos de alguma determinada ca-
mada. Por exemplo, web designers para criao de pginas HTML, desenvolvedores
para programao dos controles e analistas para modelagem do sistema (FOWLER,
2002).

+ Vrias representaes de um modelo: a variedade de representaes de modelos


uma prtica comum em aplicaes web. Um mesmo controller pode ser responsvel
por diferentes views de um mesmo modelo. Essas views podem ser abertas e fechadas
em tempo de execuo para representar esse modelo. Qualquer alterao em uma das
representaes refletida em todas as outras (BUSCHMANN et al., 1996; FOWLER,
2002).

+ Separao de controle e viso: no existia separao entre controle e viso nas primei-
ras verses do padro MVC (REENSKAUG, 1979; FOWLER, 2002). Atualmente
a maioria dos frameworks web separa essas duas camadas pois promove mo de
obra especializada, clareza de cdigo e reusabilidade de um mesmo controller para
diferentes views.

- Interdependncia entre controle e viso: impossibilita reuso de objetos de uma ca-


mada sem utilizar seu objeto correspondente da outra camada. A nica excesso
se alguma view for esttica, ou seja, somente leitura e sem interaes com o usurio
(BUSCHMANN et al., 1996).

- Forte dependncia das camadas de viso e controle: apesar do modelo ser inde-
pendente das outras camadas, o contrrio no verdadeiro. As camadas de viso e
controle so altamente dependentes da camada de modelo. Se o modelo sofrer altera-
o, todas as views e controllers relacionados a esse modelo precisam ser atualizadas
(BUSCHMANN et al., 1996).

2.3 Metaprogramao Java


A linguagem de programao Java uma linguagem de alto-nvel de propsito
geral, compilada, concorrente, baseada em classes, orientada a objetos, fortemente tipada,
influenciada por aspectos de outras linguagens de programao bem sucedidas (GOSLING
et al., 2013).
Metaprogramao um conceito poderoso e utilizado na implementao das
principais bibliotecas e frameworks Java. As Sees a seguir descrevem as principais ca-
racteristicas envolvidas no paradigma de metaprogramao. As ferramentas de metapro-
gramao Java Annotations API e Java Reflections API tambm foram estudadas e sero
utilizadas nesse trabalho.

2.3.1 Metadados
Metadados so informaes bem organizadas que descrevem, explicam, localizam
ou facilitam a obteno, uso ou manipulao de informaes relacionadas as anteriores.
De um modo geral, metadados so dados que descrevem dados (NISO, 2004).
NISO (2004) classifica os metadados em 3 tipos: descritivos, estruturais e admi-
nistrativos.

Metadados descritivos so dados que auxiliam a pesquisa e localizao de um deter-


minado objeto, ou seja, dados que descrevem o prprio objeto. Por exemplo, os
elementos nome e cpf descrevem o objeto pessoa e podem ser utilizados para a sua
localizao. Alguns elementos normalmente utilizados na descrio de objetos: rg,
cpf, nome, titulo, isbn, latitude, longitude, hashs, etc.

Metadados estruturais so dados que indicam como objetos so distribudos ou orga-


nizados. Esses dados especificam a estruturao do objeto. Por exemplo, o catlogo
de uma biblioteca determina como os livros so organizados, as pginas de um li-
vro determinam a ordem dos captulos. Objetos normalmente so estruturados em:
pginas, nmeros, letras, captulos, sees, alneas, catlogos, diagramas, plantas,
blocos, etc.

Metadados administrativos so dados que influenciam decises importantes relacio-


nadas ao tratamento de um objeto. Essas decises normalmente envolvem permis-
ses de acesso, direitos autorais, segurana, controle, etc.

A utilizao de metadados em computao apresenta uma infinidade de aplicaes:


identificao de arquivos de texto, udio e vdeo; marcadores em pginas HTML para
otimizao de engines de busca; arquivos de configurao em frameworks; mapeamento
de classes em tabelas, marcadores de contedo para facilitar a filtragem de determinado
assunto; marcadores de cdigo que influenciam nas decises do compilador; atributos de
leitura e escrita de arquivos, etc.
Os metadados que sero utilizados nesse trabalho so todos os elementos descriti-
vos, estruturais e administrativos de uma classe Java tais como: nome, tipo, atributos e
seus controladores de acesso, atributos herdados, pacote, local em disco, anotaes, etc.

2.3.2 Metaprogramao
Programas de computador analisam e transformam dados de entrada (input) em
dados de saida (output). Metaprogramao quando os dados de entrada e de sada
tambm so programas de computador. De uma maneira anloga a metadados, pode-se
definir metaprogramao como sendo programas que manipulam programas. Anlise e
transformao em tempo de compilao constitui metaprogramao esttica e em tempo
de execuo constitui metaprogramao dinmica (LWE; NOGA, 2002).
Damasevicius e Stuikys (2008) afirmam que vrios conceitos da metaprogramao
esto sendo utilizados sem o devido conhecimento dos seus autores. A justificativa que
esses conceitos no receberam a devida anlise e categorizao. Os conceitos mais comuns
so: metalinguagem, linguagem-objeto, programa-objeto, metasistema e metaprograma.
A metalinguagem qualquer linguagem utilizada para discutir, descrever ou anali-
sar outra linguagem (CZARNECKI; EISENECKER, 2000). Tambm considerada como
sendo a linguagem em que o metaprograma escrito. A linguagem-objeto a linguagem
do programa-objeto. O programa-objeto o programa produzido pelo metaprograma.
Programas-objeto so programas comuns, programados em alguma linguagem de progra-
mao, so o cdigo-fonte do programa. Um metasistema ou sistema de metaprogramao
a unio de metaprograma, programa-objeto e suas respectivas linguagens de programa-
o (Figura 2).
Metaprogramas so programas especialmente projetados para analisar e transfor-
mar outros programas. Um metaprograma um programa que pode construir programas-
Figura 2 Metaprogramao: caso geral

objeto, combinar programas-objeto menores em maiores, observar caractersticas de programas-


objeto. Exemplos de metaprogramas: geradores de programas, analizadores, compiladores,
interpretadores (SHEARD, 2000).
Os metaprogramas podem ser classificados como analisadores ou geradores de pro-
gramas (Figura 2). Um analisador de programa extrai as caractersticas descritivas, es-
truturais e administrativas mais relevantes de um programa-objeto e as interpreta em
um determinado contexto. Essa anlise produz resultados que podem auxiliar progra-
madores nas fases da criao de software: mtricas de software, fluxogramas, diagramas,
otimizadores, refatoradores.
Geradores de programas so implementados para solucionar problemas especfi-
cos. Vrios programas-objeto podem ser gerados, um para cada tipo de problema. Os
programas-objeto criados so solues especficas para determinado problema, portanto
so mais eficientes do que suas verses no-geradas (SHEARD, 2000).
Sistemas de metaprogramao que possuem metalinguagem igual a linguagem-
objeto so considerados homogneos (SHEARD, 2000). Somente em metasistemas homo-
gneos existe reflexo, definida como um conjunto de funes da linguagem, capazes de
acessar e alterar informaes de metaprogramas em tempo de execuo. A introspeco
define as funes que acessam o estado de execuo do metaprograma e a intercesso
define as funes que alteram esse estado (OLIVEIRA, 2012).
Forman (2005) define reflexo como sendo a capacidade de um programa analisar
o prprio estado de execuo, e de alterar esse estado de acordo com o que for encontrado
na anlise. A Figura 3 demonstra essa definio: a sada do metaprograma o seu prprio
estado, inspecionado e alterado por mecanismos reflexivos, sendo reutilizado como uma
nova entrada.
Figura 3 Metaprogramao: reflexo

2.3.3 Java Annotations API


Anotao (annotation) um mecanismo genrico que associa informao a ele-
mentos da linguagem Java. Foi criado a partir da especificao JSR175 (ORACLE, 2004).
padro na linguagem desde a verso 5 e se encontra no pacote java.lang.annotation.
Anotaes no influenciam diretamente no comportamento do programa, que somente
pode ser alterado pela ferramenta ou biblioteca responsvel por essas anotaes. Geral-
mente so acessadas em tempo de execuo por mtodos de introspeco e intercesso.
As principais vantagens de annotations so: erros so detectados em tempo de
compilao; amplamente utilizadas por bibliotecas e frameworks; substitui arquivos de
configurao; pode economizar recursos computacionais; sua leitura nativa, ou seja, no
exige bibliotecas externas. A principal desvantagem uma possvel poluio de cdigo
caso as convenes adotadas no sejam suficientes para o desenvolvedor. As anotaes
passariam a ser consideradas como fragmentos do arquivo de configurao anexado ao
cdigo-fonte.
Anotaes so essencialmente metadados, ou seja, elas acrescentam alguma infor-
mao til ao elemento anotado, mas no fazem parte do cdigo do mesmo. Os elementos
Java que podem ser anotados so: pacote (package), classe (class), enumerador (enum),
interface, atributo (field), mtodo (method), parmetro (formal parameter), construtor
(constructor), varivel local (local variable) (GOSLING et al., 2013).
Anotaes so indicadas pela inicial @. Sua sintaxe e utilizao podem ser obser-
vadas na Listagem 2.5. A anotao @Entidade um modificador da classe Usuario (assim
como public), e possui o tipo-anotao (annotation type) Entidade.

@Entidade ( value = " USUARIO " , persistente = true )


public class Usuario {...}
Listagem 2.5 Uso da anotao @Entidade
Toda anotao tem um tipo-anotao associado a ela (ORACLE, 2004). Um tipo-
anotao precisa ser declarado para ser criado. Sua declarao se assemelha declarao
de uma interface tradicional. O smbolo @ precede a palavra-chave interface e indica a
declarao do tipo-anotao (Listagem 2.6).

/*
* --- informacoes para documentacao - - -
*/
@Inherited
@Documented
@Retention ( RetentionPolicy . RUNTIME )
@Target ( ElementType . TYPE )
@interface Entidade {
String value () default " " ;
boolean persistente () default true ;
}
Listagem 2.6 Declarao do tipo-anotao Entidade

Os mtodos de um tipo-anotao tambm so conhecidos como elementos, e guar-


dam informaes relacionadas a anotao, na forma de pares elemento-valor (GOSLING et
al., 2013). No exemplo da Listagem 2.5, a anotao @Entidade possui dois pares elemento-
valor. Essa a sintaxe padro de uma anotao (normal annotation). No primeiro par,
o elemento value recebe o valor "USUARIO". No segundo par, o elemento persistente
recebe o valor true.
Elementos com valores default podem ser omitidos da anotao. A sintaxe de
anotao marcadora (annotation marker) utilizada quando todos os elementos so de-
clarados como default ou quando o tipo-anotaao possui zero elementos. O elemento
value uma conveno de nome para uso da sintaxe de anotao de elemento nico
(single-element annotation) e pode ser omitido da anotao quando for o nico elemento
declarado no seu tipo-anotao correspondente, ou quando todos os outros elementos de-
clarados possuirem valores padro (GOSLING et al., 2013). A (Listagem 2.7) exibe os 3
tipos possveis de sintaxe de anotaes.
@Entidade ( value = " UM_NOME " , persistente = false )
public class SintaxeGeral {...}

// Omissao do elemento value e elementos default


@Entidade ( " UM_NOME " )
public class S i n t a x e S i n g l e E l e m e n t A n n o t a t i o n {...}

// Omissao de elementos default


@Entidade
public class S i n t a x e M a r k e r A n n o t a t i o n {...}
Listagem 2.7 Sintaxes da anotao Entidade

Anotaes que anotam tipo-anotao so conhecidas como meta-anotaes (meta-


annotations). O pacote java.lang.annotation possui as meta-anotaes @Documented, @Inherited,
@Retention e @Target:

@Documented documenta anotaes. Ferramentas de documentao iro criar links


automaticamente para tipos-anotao anotados com @Documented. Por exemplo, se
a classe Usuario (Listagem 2.5) for documentada, um link para a documentao do
tipo-anotao Entidade criado automaticamente, pois a mesma est anotada com
@Documented (Listagem 2.6).

@Inherited indica que um tipo-anotao deve ser herdado automaticamente por sub-
classes da classe anotada. S apresenta funcionalidade quando anotada em tipos-
anotao especificos para classes. Por exemplo, subclasses da classe Usuario (Lis-
tagem 2.5) herdariam a anotao @Entidade, pois a mesma est anotada com
@Inherited (Listagem 2.6).

@Retention determina se a anotao estar disponvel somente no cdigo-fonte, em


tempo de compilao ou em tempo de execuo. Anotaes disponveis em tempo
de execuo so manipulveis por bibliotecas de reflexo.

@Target um tipo-anotao somente ser aplicvel aos tipos de elementos Java restrin-
gidos pela meta-anotao @Target. Por exemplo, o tipo-anotao Entidade (Lista-
gem 2.6) somente ser aplicvel aos elementos dos tipos class, enum, interface,
ou @interface.

2.3.4 Java Reflections API


A API Reflections possui um conjunto de mtodos de instrospeo e intercesso,
capaz de examinar ou modificar o estado de uma aplicao em tempo de execuo (run-
time). Reflections tambm oferece meios para se instanciar objetos, invocar mtodos ou
alterar valores de variveis. (JENKOV, 2008). Essa flexibilidade da API trs diversos be-
nefcios e possibilidades ao programador, mas como qualquer ferramenta mal utilizada,
pode causar srios problemas.
Os principais problemas que desenvolvedores inexperientes podem encontrar so:
falhas e restries de segurana; complexidade de cdigo; problemas de desempenho; que-
bra de portabilidade. A API consegue acessar e alterar atributos privados (private),
ferindo o princpio do encapsulamento. Alm disso, aplicaes podem estar rodando em
ambientes restritivos, quebrando funcionalidades reflexivas que foram implementadas para
ambientes no-controlados. Saber quando e como usar reflexo evita uma complexidade
desnecessria de cdigo. Cdigos reflexivos envolvem resoluo dinmica de tipos, preju-
dicando o desempenho de aplicaes com vrios laos de repetio. Refatorao de cdigo
pode causar quebra de portabilidade em tempo de execuo, com erros imprevisveis e de
difcil localizao (ORACLE, 2011b; FORMAN, 2005).
A classe Class a mais importante para reflexo, pois possui todos os mtodos
que expem o estado da aplicao ao desenvolvedor. A partir deles, pode-se obter infor-
maes importantes sobre os vrios tipos de elementos da linguagem Java, encapsuladas
em diferentes classes e localizados no pacote java.lang.reflect. As principais classes
so Field, Method e Constructor, para os elementos de atributos, mtodos e construto-
res respectivamente. Esses elementos tambm so considerados membros de uma classe,
por implementam a interface Member. Outros tipos de elementos tambm so encapsula-
dos, tais como: modificadores de controle de acesso, parmetros de tipo para elementos
genricos, hierarquia de classes, etc (OLIVEIRA, 2012; ORACLE, 2011a).
A obteno do objeto Class feita de 3 maneiras: herana; nome totalmente
qualificado da classe (fully qualified name ou FQN); literal class. Todos os objetos ins-
tanciados herdam o mtodo getClass() da classe Object, raiz da hierarquia de classes
da linguagem Java. Esse mtodo retorna a classe associada a esse objeto em tempo de
execuo (OLIVEIRA, 2012). O FQN o nome da classe seguido do pacote em que ela
se encontra (JENKOV, 2008). A classe Class fornece o mtodo esttico forName(...)
para invocar, em tempo de execuo, classes a partir do seu FQN. O literal class pode
ser usado em nomes de classes para representar, em tempo de compilao, sua classe
relacionada. A Listagem 2.8 demonstra os 3 casos.
// FQN = mestrado . Exemplo
import mestrado ;
public class Exemplo {...}

// Metodo getClass () herdado de Object


Exemplo e = new Exempplo () ;
Class clazz = e . getClass () ;

// Metodo estatico utilitario forName (...)


Class clazz = Class . forName ( " mestrado . Exemplo " ) ;

// Uso do literal class


Class clazz = mestrado . Exemplo . class ;
Listagem 2.8 Obtendo classes para reflexo

Membros de uma classe podem ser considerados pblicos ou declarados. Membros


pblicos so todos os elementos da classe analisada que so acessveis publicamente, in-
clusive os herdados. Membros declarados so todos os elementos codificados diretamente
na classe, com qualquer grau de visibilidade, mas no incluindo elementos herdados.
A instrospeco do estado de uma aplicao realizado a partir da obteno dos
membros de classe. A Tabela 1 exibe os mtodos que expoem ao desenvolvedor o estado dos
elementos Field, Method e Constructor. Esse estado poder ser manipulado de acordo
com a necessidade da aplicao. Objetos Field podem ter seus valores alterados; objetos
Method podem ser invocados passando zero ou mais parmetros; objetos Constructor so
os responsveis por instanciar novos objetos. Ou seja, as tarefas de atribuio de valores,
invocao de mtodos, e criao de objetos, viraram responsabilidade do programa, e no
mais do desenvolvedor. Os principais mtodos responsveis por essa alterao de estado
(intercesso) so mostrados na Tabela 2.

Tabela 1 Mtodos de introspeco da classe Class


Tipo de Membro Descrio Elemento Mtodos de introspeco da API Reflections
getField(String nome)
Field
getFields()
Elementos pblicos da prpria classe e getMethod(String nome, Class<?>parametros)
Pblico Method
elementos pblicos herdados de suas superclasses. getMethods()
getConstructor(Class<?>parametros)
Constructor
getConstructors()
getDeclaredField(String nome)
Field
getDeclaredFields()
Elementos da prpria classe com qualquer grau getDeclaredMethod(String nome, Class<?>parametros)
Declarado Method
de acesso, mas sem herana de outros elementos. getDeclaredMethods()
getDeclaredConstructor(Class<?>parametros)
Constructor
getDeclaredConstructors()
Tabela 2 Mtodos de intercesso da API Reflections
Elemento Mtodo Descrio
set(Object obj, Object v)
setBoolean(Object obj, boolean v)
setByte(Object obj, byte v)
setChar(Object obj, char v) Cada tipo primitivo tem um mtodo especfico para se atribuir valores.
Field setDouble(Object obj, double v) O parmetro obj o objeto que possui o elemento Field no qual o mtodo set invocado.
setFloat(Object obj, float v) O parmetro v o novo valor atribuido a esse elemento.
setInt(Object obj, int v)
setLong(Object obj, long v)
setShort(Object obj, short v)
O parmetro obj o objeto que possui o elemento Method no qual o mtodo invoke invocado.
Method invoke(Object obj, Object... argumentos)
O segundo parmetro corresponde aos mesmos argumentos utilizados na assinatura do mtodo referenciado.
Constructor newInstance(Object... argumentos) Cria uma nova instncia do objeto ao qual o construtor pertence, com os argumentos de inicializao especificados.

2.4 Sistemas CRUD


Atualmente, a maioria dos sistemas comerciais utilizam banco de dados para ma-
nipulao e armazenamento persistente de dados. Para que isso seja possvel necessrio
a utilizao de algumas operaes bsicas, comum a todos esses sistemas e independente
de tecnologia ou meio de armazenamento. So elas: criao, leitura, edio e remoo de
dados. Essas 4 operaes so o ncleo de qualquer estrutura de armazenamento de dados
e ficaram popularmente conhecidas pelo acrnimo CRUD, que se origina das palavras
Create (criar), Read (ler), Update (atualizar) e Delete (deletar).
Sistemas CRUD so sistemas que normalmente seguem um padro estrutural bem
definido: possuem uma base de dados para armazenamento persistente; uma camada de
abstrao com as 4 operaes bscias para a manipulao dos dados, conhecida como
camada de acesso a dados ou DAL; e o sistema propriamente dito, que utiliza esta ca-
mada para implementar suas funcionalidades e usar os dados armazenados. Geralmente a
camada de modelo encapsula a camada de acesso a dados para maior controle do banco
de dados (Figura 4).

Figura 4 Estrutura bsica de um Sistema CRUD

O termo CRUD normalmente associado a sistemas que utilizam alguma base


de dados relacional, ou seja, manipulao por SQL e persistncia em tabelas. Apesar
disso, sistemas com qualquer tipo de camada de persistncia so considerados CRUD,
pois precisam implementar as 4 funcionalidades bsicas para funcionar corretamente.
Bases de dados no-relacionais manipulam seus dados utilizando NoSQL e a persistncia
geralmente orientada a grafos, utilizando arquivos JSON ou XML.
Uma linguagem de manipulao de dados (do ingls Data Manipulation Language
ou DML) possui estruturas (verbos) que implementam as 4 funcionalidades CRUD. A
DML mais conhecida a SQL (Structured Query Language). Apesar de no ser especifi-
camente uma DML, o protocolo HTTP tambm possui verbos para as operaes CRUD.
A Tabela 3 faz uma associao entre o acrnimo CRUD e os seus correspondentes em
SQL e HTTP.

Tabela 3 Operaes CRUD em SQL e HTTP

CRUD SQL HTTP


Create INSERT PUT / POST
Read (Retrieve) SELECT GET
Update UPDATE PUT / PATCH
Delete (Destroy) DELETE DELETE

2.5 Scaffolding
A construo de aplicaes web ganhou grande destaque em engenharia de soft-
ware e por isso surgiram muitos frameworks com vrias ferramentas de automao. As
ferramentas mais significativas so as de mapeamento entre objetos, banco de dados e
interfaces CRUD. Essa tcnica chamada de scaffolding e depende do padro MVC. Ou-
tras ferramentas no relacionadas a scaffolding permitem gerar outros componentes, tais
como: camada de segurana, integrao de sistemas, testes unitrios, etc (ADAMUS et
al., 2010).
A tcnica de scaffolding gera todas as estruturas fundamentais para o funciona-
mento de uma aplicao web. Ela recebeu esse nome pois faz uma aluso tecnica de
cimbramento da engenharia civil (scaffolding em ingls), que representa uma estrutura de
suporte provisrio durante o perodo de construes, normalmente composta por andai-
mes e escoras. Ou seja, ambas as tcnicas so estruturas temporrias que beneficiam os
seus utilizadores. Em engenharia civil, a estrutura de andaimes conhecida como scaffold.
O anlogo em programao o sistema CRUD gerado (Tabela 4).
Geradores de cdigo so ferramentas que aceitam como entrada os requisitos funci-
onais de um sistema, e produzem na saida cdigos-fonte que implementam esses requisitos
(GERACI, 1990).
Neste trabalho, o termo scaffolder atribuido ao programa ou mdulo que utiliza
a tcnica de scaffolding para a gerao automtica de cdigo, ou seja, geradores de cdigo.
Seu anlogo em engenharia civil so os operrios que instalam os andaimes (Tabela 4). O
mecanismo mais comum de gerao de cdigo de um scaffolder o baseado em templates.

Tabela 4 Comparao entre os termos de engenharia civil e programao


Termo Significado em Engenharia Civil Significado em Programao
Aplicao de estruturas de suporte, Gerao de cdigo para um sistema CRUD baseado
Scaffolding
compostas por andaimes e escoras. no padro MVC.
Scaffold Andaimes e escoras. Sistema CRUD.
Scaffolder Operrio que instala os andaimes. Gerador de cdigos do sistema CRUD.

O scaffolder basicamente uma ferramenta para automatizar a programao de


tarefas repetitivas, que do contrrio seriam codificadas a mo. A programao se torna
repetitiva quando a aplicao precisa seguir estruturas e padres de desenvolvimento.
Um sistema CRUD um caso tpico de aplicao que possui tarefas repetitivas, pois
estruturado pela arquitetura MVC. Todo sistema CRUD possui vrias entidades que
modelam a aplicao. Para cada entidade existe mtodos de acesso ao banco de dados,
interfaces com o usurio, mtodos que controlam toda a lgica da aplicao, etc. Codificar
tudo isso a mo gasta mais tempo e possui um risco maior de erros (COHEN-ZARDI,
2013).
Existe uma certa controvrsia entre vrios desenvolvedores experientes sobre os
reais benefcios da utilizao da tcnica de scaffolding. Como qualquer ferramenta, pre-
ciso saber como e quando utiliz-la, para ter o mximo de aproveitamento. necessrio
entender que desenvolvedores podem usar a tcnica quando necessrio, mas no podem
depender exclusivamente dela para a soluo de todos os problemas. O uso do scaffolding
possui algumas observaes importantes:

recomendado utilizar a tcnica apenas uma vez, para gerar a estrutura inicial do
projeto rapidamente. Uma segunda utilizao, resultante de modificaes na camada
de modelo, sobrescreveria as camadas de viso e controle, fazendo com que todo o
cdigo adicionado manualmente seja descartado. Sistemas de controle de verso
podem recuperar os arquivos sobrescritos acidentalmente, evitando esse problema.

Classes utilitrias (helpers) tambm podem ser geradas pela tcnica de scaffolding.
Elas servem para facilitar a implementao da lgica da aplicao gerada e no de-
vem ser alteradas manualmente pelos programadores. Alm disso, outras abstraes
tambm podem ser geradas pelo scaffolder, tais como arquivos XML, CSS, LESS,
etc. O desenvolvedor tem a flexibilidade de excluir trechos de cdigo ou arquivos,
caso julgue necessrio.
Personalizaes no scaffolder devem ser feitas at certo ponto: o desenvolvedor no
deve gastar mais tempo nisso do que resolvendo tarefas da lgica da aplicao.
O ideal seria ter uma equipe responsvel somente pela manuteno do scaffolder,
enquanto outras equipes tratariam dos problemas especficos da lgica da aplicao.

Scaffolding dinmico a gerao e/ou alterao de cdigo-fonte em tempo de exe-


cuo. O uso dessa tcnica no recomendvel, pois pode adicionar dependncias
do scaffolder ao programa gerado; o programador no consegue personalizar o c-
digo, pois sempre sobrescrito; aumenta o consumo de memria da aplicao final.
Essa tcnica til somente em casos bem especficos, como sistemas CRUD pouco
complexos por exemplo. O scaffolding esttico o mais conhecido e indicado: gera
cdigo em tempo de compilao, atravs de comandos no console do framework.

Vrios desenvolvedores argumentam que a utilizao da tcnica de scaffolding no


recomendada para programadores iniciantes por questes didticas. Apesar disso,
se o cdigo gerado for claro e legvel, tanto programadores iniciantes quanto exepe-
rientes podem tirar proveito dos benefcios de se utilizar a tcnica de scaffolding.

A utilizao da tcnica pode trazer diversos benefcios, caso sejam consideradas as


observaes mencionadas anteriormente. Os principais benefcios so listados a seguir:

Personalizaes: bons geradores de cdigo fornecem opes para refinar o resultado


final. Se o gerador for open-source, programadores podero fazer personalizaes
diretamente na ferramenta, caso sej fcil e no demande muito tempo.

Produtividade: o cdigo gerado economiza horas de cdificao manual, fazendo


com que prottipos funcionais sejam gerados em segundos. Os desenvolvedores fi-
cam livres para focar seu tempo na soluo de problemas relacionados a lgica da
aplicao.

Padro de qualidade: cdigo feito a mo instvel pois no segue padres, varia de


pessoa para pessoa, um mesmo problema utiliza diferentes solues, etc. O cdigo
criado por um gerador mais estvel: erros encontrados no cdigo gerado podem
ser reparados no gerador, assim novos cdigos sero gerados sem os erros anteriores.
Quanto mais utilizado, mais refinado e otimizado ser o scaffolder em futuras ver-
ses. Bons geradores prezam por gerao de cdigos claros e de fcil entendimento.

Consistncia: o cdigo gerado mantm padres estruturais e convenes entre diver-


sos projetos. Programadores tm mais facilidade de entender cdigos gerados para
novos projetos. Dificilmente surgir erros no cdigo criado, pois ele foi usado com
sucesso em projetos anteriores.
Dependncia Zero: scaffolders estticos no agregam nenhuma dependncia externa
ao sistema gerado.

Scaffolding com Templates


Geradores de cdigo baseados em templates transformam dados em cdigo-fonte.
Templates so arquivos de texto, provenientes do cdigo-fonte de projetos de sucesso, com
algumas pequenas modificaes. Todos os trechos do cdigo que podem ser genricos so
substitudos por parmetros, que sero interpretados por um gerador de templates. Os
trechos mais comuns para substituio so: nome de pacote, nome de classe, nome de
projeto, nome de variveis, etc. Templates tambm podem ter mecanismos de controle
de fluxo, que sero analisados e resolvidos pelo gerador de templates. Isso garante mais
flexibilidade ao desenvolvedor de templates (FRANKY; PAVLICH-MARISCAL, 2012).
Contexto a estrutura responsvel por armazenar informaes relativas aos ar-
quivos de template. Todo parmetro presente em um template possui uma referncia no
contexto, para que valores sejam atribuidos e o cdigo-fonte seja gerado. Um contexto
pode ter mais atributos do que o nmero de parmetros de um template. Isso possibilita
que um mesmo contexto seja reaproveitado em diferentes templates. O contexto pode
ser qualquer estrutura que armazene informaes. Por exemplo, instncias de classes ou
arquivos (Listagem 2.9). A informao de um contexto geralmente representada pela
unio entre metadados, convenes e configuraes.

// Instancia da classe Contexto na linguagem Java


Contexto c = new Contexto () ;
c . setClasse ( " Onibus " ) ;
c . setTipoId ( " String " ) ;
c . setObjeto ( " onibus " ) ;

// Arquivo JSON
{
" classe " : " Onibus " ,
" tipoId " : " String " ,
" objeto " : " onibus "
}
Listagem 2.9 Exemplo de contextos

O cdigo-fonte criado pelo gerador de templates o resultado da unio entre


contexto e template: parmetros so substituidos pelos seus valores correspondentes no
contexto. De um modo geral, a tcnica de scaffolding utilizando templates pode ser re-
presentada pela Figura 5.
Como exemplo, a Listagem 2.10 mostra um fragmento de cdigo-fonte de algum
Figura 5 Scaffolding baseado em Templates

projeto bem-sucedido. Esse fragmento usado como base para a criao de um template.
Todas as ocorrncias das palavras Carro e carro so parametrizadas. Alm disso, a pala-
vra Long tambm transformada em parmetro, para maior flexibilidade. O restante do
texto copiado exatamente como o original.

public static Result edit ( Long id ) {


Form < Carro > carroForm =
form ( Carro . class )
. fill ( Carro . find . byId ( id ) ) ;
return ok ( editForm . render ( id , carroForm ) ) ;
}
Listagem 2.10 Exemplo de fragmento de cdigo-fonte

Aps as devidas substituies, o template criado apresentado na Listagem 2.11.


A sintaxe utilizada para a criao dos parmetros varia de acordo com o gerador de
templates. Nesse exemplo foram criados os seguintes parmetros: ${classe}, ${objeto}
e ${tipoId}.

public static Result edit ( $ { tipoId } id ) {


Form < $ { classe } > $ { objeto } Form =
form ( $ { classe }. class )
. fill ( $ { classe }. find . byId ( id ) ) ;
return ok ( editForm . render ( id , $ { objeto } Form ) ) ;
}
Listagem 2.11 Exemplo de template baseado na Listagem 2.10

A Listagem 2.12 mostra o cdigo-fonte criado pelo gerador de templates, utilizando


o template da Listagem 2.11 e o contexto da Listagem 2.9.
public static Result edit ( String id ) {
Form < Onibus > onibusForm =
form ( Onibus . class )
. fill ( Onibus . find . byId ( id ) ) ;
return ok ( editForm . render ( id , onibusForm ) ) ;
}
Listagem 2.12 Exemplo de cdigo gerado

Franky e Pavlich-Mariscal (2012) resumem o ciclo de vida de um gerador de tem-


plates em 4 fases:

1. escolhido algum cdigo-fonte de projetos anteriores bem-sucedidos que imple-


mente a funcionalidade desejada.

2. O cdigo-fonte servir como base para a criao de um template, ou seja, todo


texto genrico (nome de classes, pacotes, variveis, etc) ser parametrizado. Novas
funcionalidades sero adicionadas ao template nessa fase, caso necessrio.

3. Geradores de cdigo so implementados com base no template criado. O primeiro


gerador cria a estrutura bsica de um sistema e novos geradores evoluem a partir
dela.

4. Desenvolvedores podem alterar o cdigo gerado. O gerador no poder ser utilizado


novamente pois as alteraes realizadas sero perdidas.

Apesar de flexveis e de rpido aprendizado, geradores de cdigo baseado em tem-


plates possuem alguns pontos negativos. Novas verses do gerador podem fazer com que
verses anteriores dos sistemas criados se tornem incompatveis com os atuais. Um novo
sistema precisa ser gerado e testado a cada alterao nos templates, para correo de erros
de compilao ou execuo, caso sejam encontrados (FRANKY; PAVLICH-MARISCAL,
2012).

2.5.1 Funcionamento
A teoria presente na tcnica de scaffolding envolve todos as sees anteriores e
alguns conceitos novos, relacionados a geradores de cdigo. A Figura 6 mostra a diviso
terica da tcnica em 3 estruturas principais: entrada, scaffolder e saida. Cada estrutura
subdividida em componentes, representados pelo tracejado azul. Cada componente possui
um ou mais blocos, que so abstraes da teoria envolvida na tcnica. Os nmeros nos
crculos mostram todos os elementos presentes na tcnica, descritos a seguir:
Figura 6 Esquema terico da tcnica de scaffolding

Representaes da camada de modelo

1. O programa scaffolder espera que o desenvolvedor entre com algum tipo de repre-
sentao da camada de modelo, tais como: diagramas UML, arquivos XML, tabelas
relacionais, classes orientadas a objetos, etc. Geralmente a representao final da
camada de modelo no sistema CRUD da saida composta por classes orientadas a
objetos. Portanto, uma converso necessria caso a entrada no seja representada
por classes.

Metaprogramao

2. O bloco de reflexo faz a introspeco da entrada e mapeia todas as caracteristicas


consideradas importantes, tais como: nome do modelo, atributos, herana, chaves
primrias, etc.

3. O bloco dos metadados basicamente a representao computacional das estruturas


mapeadas pelo bloco da reflexo. toda a informao obtida no bloco anterior,
armazenada em classes ou arquivos, por exemplo. usado como entrada para o
ncleo do gerador de cdigo.

Gerador de cdigo

4. Todas as convenes do sistema criado so representadas por este bloco. Geralmente


so utilizadas convenes de nomes de pastas e arquivos, tipos de chaves primrias,
formatao de cdigo, etc.

5. O bloco das configuraes fornece maior flexibilidade ao desenvolvedor, caso ele no


queira seguir as convenes impostas por algum motivo.
6. O ncleo do scaffolder possui toda a lgica para a gerao de cdigo, inclusive
geradores internos para manipulao de templates. As ferramentas transformam
convenes, configuraes e metadados em estruturas de contexto, que so usadas
juntamente com templates predefinidos para a gerao dos cdigos-fonte da arqui-
tetura MVC. O ncleo tambm responsvel por transformar a representao do
modelo em classes orientadas a objetos, caso seja necessrio.

Sistema CRUD: arquitetura MVC

7. Este item representa a estrutura MVC do sistema criado, inclusive as operaes


CRUD que interligam banco de dados e camada de modelo. A estrutura ser utili-
zada pelos desenvolvedores como auxlio para o desenvolvimento de sistemas mais
complexos.

2.5.2 Scaffolding no Framework Rails


Ruby on Rails (tambm conhecido como RoR ou simplesmente Rails) um fra-
mework web completo, de cdigo aberto, grtis, e focado em desenvolvimento produtivo.
Foi projeto especificamente para que programadores tenham facilidade e alegria em pro-
duzir cdigos bonitos e atraentes, pois favorece o uso de conveno sobre configurao.
o framework para desenvolvimento web sem complicaes ou sofrimentos (HANSSON,
2003).
O framework Rails utiliza somente a gerao esttica de cdigo. O comando
generate o responsvel por toda a criao de cdigo do framework e aceita diver-
sos parmetros, cada um representando uma camada de abstrao de uma aplicao web
tpica. A ferramenta consegue gerar os modelos e toda a integrao com o banco de da-
dos, a camada de viso com as pginas HTML e arquivos CSS e javascript, a camada
de controle que interliga modelo e viso, testes de integrao e desempenho, arquivo de
rotas, etc. Alm disso, o desenvolvedor pode adicionar novos geradores ou criar um para
alguma aplicao mais especfica. Os parmetros mais comuns so controller, model e
scaffold (Figura 7).
A conexo entre a camda de viso e a camada de controle feita pelo arquivo de
rotas do framework. As aes padres para uma aplicao CRUD so representadas pelos
mtodos index, new, create, show, edit, update e destroy, localizados na camada de
controle. Dessas 7 aes, 4 so ligadas a pginas HTML da camada de viso. As outras 3
so aes a serem executadas pelo framework (Tabela 5).
O gerador de controllers cria a camada de apresentao da aplicao, com as
classes de controle e suas pginas correspondentes na camada de viso. Cada action
do controlador representa um mtodo associado a uma pgina na camada de viso. O
Tabela 5 Tabela com rotas geradas para o modelo HighScore
Pgina na Ao (mtodo)
Verbo HTTP Caminho Descrio
Camada de Viso no controlador
GET /high_scores index.html.erb index Lista todos os objetos high_score
GET /high_scores new.html.erb new formulrio HTML para criar novos high_score
POST /high_scores create cria novo high_score
GET /high_scores/:id show.html.erb show mostra high_score com o id :id
GET /high_scores/:id/edit edit.html.erb edit formulrio HTML para alterar high_score com id :id
PUT/PATCH /high_scores/:id update altera high_score com id :id
DELETE /high_scores/:id destroy deleta high_score com id :id

Figura 7 Comando generate do frameworks Rails

exemplo da Figura 8 cria o controlador credit_card_controller.rb com os mtodos


open, debit, credit e close. Cada mtodo associado automaticamente as pginas de
mesmo nome da camada de viso, por meio de um arquivo de rotas, que tambm criado
ou atualizado.
Os argumentos do gerador de modelos (parmetro model) so os atributos da
classe a ser criada. O gerador scaffold tambm espera por argumentos que representem
atributos de uma classe, mas cria toda a aplicao ao invs de gerar somente a camada
de modelo. O programador pode usar o gerador scaffold_controller caso j possua as
classes de modelo. A Figura 9 mostra o uso do gerador scaffold para criao da classe
HighScore com os atributos game e score. Na verdade, todo a computao delegada
aos outros geradores mais especficos (invoke). A linha route resources :high_scores
corresponde conexo entre camada de viso e controle, representada anteriormente pela
Tabela 5. A partir disso, todos os arquivos necessrios so criados (create) para a gerao
de um sistema CRUD simples, porm funcional.

2.5.3 Scaffolding no Framework Grails


Grails um framework completo de desenvolvimento de aplicaes web, com cdigo
aberto e grtis. Foi construido para a Mquina Virtual Java (JVM). Utiliza a linguagem
Figura 8 Comando generate controller e exemplo de uso

Figura 9 Comando generate scaffold e arquivos criados

de programao Groovy e o paradigma de conveno sobre configurao. Programadores


conseguem ser produtivos em um ritmo constante durante o processo de desenvolvimento
de aplicaes web (PIVOTAL, 2014).
A tcnica de scaffolding foi movida para um plugin nas verses mais recentes do
Grails. Desacoplamento de funcionalidades um recurso poderoso dos frameworks e reduz
dependncias desnecessrias. O plugin adicionado por padro mas o programador pode
remov-lo caso decida no utilizar a tcnica.
A documentao da tcnica de scaffolding do framework Grails muito superficial
e no fornece exemplos significativos sobre a utilizao da mesma. Apesar disso, pode-se
afirmar que o framework possui os dois tipos de scaffolding: esttico, utilizando a linha
de comando; e dinmico, utilizando comandos estticos nas prprias classes de controle.
A Listagem 2.13 mostra como realizar o scaffolding do controlador HighScoreController
em tempo de execuo. Utilizando conveno de noomes, o framework realiza o scaffolding
para a classe de modelo HighScore. O comando esttico pode ser configurado, caso o pro-
gramador, por alguma razo desconhecida, queira quebrar a conveno (Listagem 2.14).

// Scaffolding para o modelo HighScore


class H i gh S c or e C on t r ol l e r {
static scaffold = true
}
Listagem 2.13 Scaffolding Dinmico na classe HighScoreController para o modelo HighScore

// Scaffolding para o modelo Placar


class H i gh S c or e C on t r ol l e r {
static scaffold = Placar
}
Listagem 2.14 Scaffolding Dinmico na classe HighScoreController para o modelo Placar

As aes implementadas em tempo de execuo so as seguintes: index, show,


edit, delete, create, save e update. Essas aes representam mtodos na classe de
controle e interfaces CRUD na camada de viso. Novos mtodos podem ser adiciondos ou
sobrescritos (Listagem 2.15).
class BookController {
static scaffold = Placar

def changeAuthor () {
def b = Book . get ( params . id )
b . author = Author . get ( params [ " author . id " ])
b . save ()
}

def show () {
def book = Book . get ( params . id )
log . error ( book )
[ bookInstance : book ]
}

}
Listagem 2.15 Adicionado e sobrescrevendo mtodos na classe BookController

O programador provavelmente ir precisar personalizar a lgica ou aparncia de


uma aplicao. Isso no possvel com scaffolding dinmico. A camada de viso no
gerada. Sobrescrever muitos mtodos acaba tendo o mesmo efeito de codific-los manual-
mente. Com gerao esttica esses problemas so solucionados (ROCHER et al., 2014).
Aps a execuo de um comando, toda a aplicao fica disponvel ao programador em
tempo de compilao. Os comandos so intuitivos, apesar de no existir documentao
sobre parmetros e opes a serem passadas.
Diferente do framework Rails, o Grails no possui um gerador de modelos. Por-
tanto, todos os geradores disponveis dependem da entrada de classes de modelo. A Lista-
gem 2.16 mostra os 3 comandos possveis para gerao esttica das camadas de controle
(generate-controller), viso (generate-views), ou ambas (generate-all). As mes-
mas aes implementadas em tempo de execuo so geradas em tempo de compilao.

// Gerador da camada de controle


grails generate - controller HighScore

// Gerador da camanda de visao


grails generate - views HighScore

// Gerador da camada de apresentacao


grails generate - all HighScore
Listagem 2.16 Comandos para gerao esttica no framework Grails
2.6 Trabalhos Similares

Existem vrios estudos relacionados a gerao automtica de cdigo. Apesar disso,


apenas alguns esto relacionados a tecnologias web. importante ressaltar que a filosofia
bsica do trabalho desenvolvido nesta dissertao independe de tecnologias, e encontrada
em vrios trabalhos correlatos: fornecer um sistema pronto a partir de alguma represen-
tao da camada de modelo. Esta representao pode ser por diagramas UML, classes
Java, arquivos XML, tabelas relacionais, etc (SILVA; PERRI; ALMEIDA, 2011; DAIS-
SAOUI, 2010; MRACK; MOREIRA; PIMENTA, 2006). Alm disso, quase todas as IDEs
mais modernas possuem mecanismos de gerao de cdigo a partir dessas representaes
(NETBEANS, 2010; SANCHEZ, 2008; MALYSHEV, 2006).
O trabalho de Silva, Perri e Almeida (2011) desenvolve uma ferramenta para cria-
o de sistemas web CRUD utilizando as tecnologias Servlets, JSP, Hibernate e jQuery. A
entrada do programa so scripts SQL para criao de tabelas relacionais. A partir dessas
tabelas, o programador deve realizar algumas configuraes antes que os cdigos-fonte
sejam gerados. O gerador cria as classes da camada de modelo baseado no framework
Hibernate, a camada de controle utiliza Servlets e a camada de viso so as pginas JSP
com jQuery. O programador deve criar uma nova aplicao, com pastas apropriadas para
as camadas MVC, e copiar manualmente todos os arquivos gerados pela ferramenta.
O trabalho de Daissaoui (2010) cria um sistema web CRUD a partir de um di-
agrama UML das classes do projeto, independente de linguagens de programao ou
tecnologias. O algoritmo criado no estudo utiliza as tecnologias JSP e Struts como base.
A estrutura do framework Struts foi mapeada em metamodelos. O programa utiliza essa
estrutura para desenvolver o algoritmo de gerao de dados. Esse algoritmo usa uma lista
genrica de mtodos, ou seja, pode ser adaptado conforme casos de uso. A partir disso,
foi gerado cdigo para os 4 mtodos CRUD. As regras desse algoritmo foram mapeadas
pelo framework EMF da IDE Ecplise, gerando um arquivo XML que poder ser utilizado
para implementar o mesmo algoritmo em diferentes linguagens de programao.
O trabalho de Mrack, Moreira e Pimenta (2006) utiliza uma abordagem um pouco
diferente dos citados anteriormente. A entrada do programa so classes Java. A configu-
rao feita utilizando anotaes nas prprias classes. Apesar disso o programa no gera
as camadas de controle e viso, para futuras edies caso o programador julgue necess-
rio. O sistema CRUD gerado precisa ser conectado manualmente a alguma tecnologia de
armazenamento persistente. Por ser baseado em eventos, se o programador quiser novas
funcionalidades (novas anotaes), ter que codificar tudo a mo.
A maioria das IDEs modernas possuem mecanismos de gerao automtica de
sistemas CRUD, mas com algumas restries significativas: suportam somente a tecnologia
JSF; suportam somente a tecnologia JPA; alteraes nos templates, quando possveis, so
custosas e no-documentadas. A IDE Netbeans aceita como entrada tabelas relacionais
ou entidades JPA (NETBEANS, 2010). A IDE IntelliJ IDEA possui essa funcionalidade
mas s utiliza entidades JPA como entrada (MALYSHEV, 2006). A IDE Eclipse no
possui gerao de aplicaes CRUD por padro, mas possui um plugin para esse propsito
(SANCHEZ, 2008). Projetos criados no Play podem ser exportados para o Eclipse ou
Intellij IDEA. Das IDEs citadas, somente a Intellij IDEA suporta o framework Play por
padro.
O trabalho proposto especfico para o framework Play, portanto somente assimila
as idias bsicas dos seus correlatos. A representao da camada de modelo feita so-
mente por classes Java. Isso evita que programadores aprendam algo sem precisar. Toda a
conexo com o banco de dados, inclusive a criao das tabelas, feita automaticamente. O
sistema final gera todos os cdigos das camadas de viso e controle, possibilitando maior
personalizao. A aplicao gerada utiliza tecnologias do mercado atual. A Tabela 6 faz
um resumo comparativo das principais caracteristicas dos trabalhos correlatos.

Tabela 6 Comparao entre as principais caracteristicas dos trabalhos


Trabalho Intellij
Caracteristicas SILVA; PERRI; ALMEIDA DAISSAOUI MRACK; MOREIRA; PIMENTA Netbeans Eclipse
Proposto IDEA
Dependncia da linguagem java x x x x x x
Gerao a partir de classes java x x x x x
Conexo com o banco de dados x x x x
Fornece camadas de viso e controle x x x x x x
Usa tecnologias atuais x x x x
integrao com o framework Play x x x

2.7 Consideraes Finais


Este Captulo apresentou os conceitos, ferramentas, convenes, padres arquite-
turais de projeto e tcnicas utilizados como fundamentao terica para o desenvolvimento
de um metaprograma gerador de cdigo. Todos os tpicos apresentados neste Captulo so
utilizados na implementao desse metaprograma ou no entendimento do sistema CRUD
(programa-objeto) gerado pelo mesmo.
Os conceitos de metadados e reflexo so a base das APIs Annotation e Reflexion,
ferramentas responsveis pela metaprogramao na linguagem Java. Metaprogramas ge-
radores de cdigo precisam necessariamente utilizar essas ferramentas, direta (Java APIs)
ou indiretamente (bibliotecas de terceiros que implementam as Java APIs). Convenes
precisam ser adotadas para minimizar configuraes desnecessrias. O padro MVC a
estrutura bsica do framework web utilizado e do programa-objeto gerado. A tcnica de
scaffolding utiliza convenes, padres arquiteturais e metaprogramas bem definidos para
gerar programas-objeto, que neste trabalho ser um sistema CRUD bsico.
3 Scaffolder, Um Gerador de Sistemas CRUD
4 Experimentos e Resultados
5 Concluses
Referncias

ADAMUS, R. et al. Tools supporting generation of"data-intensive"applications for a


web environment. Automatyka/Akademia Grniczo-Hutnicza im. Stanisawa Staszica w
Krakowie, v. 14, p. 951960, 2010. Citado na pgina 35.

BERNERS-LEE, T. Information Management: A Proposal. Genf, 1989. Disponvel em:


<http://www.w3c.org/History/1989/proposal.html>. Citado na pgina 15.

BUSCHMANN, F. et al. Pattern-oriented Software Architecture: A System of Patterns.


New York, NY, US: John Wiley & Sons, Inc., 1996. ISBN 0-471-95869-7. Citado 4 vezes
nas pginas 23, 24, 25 e 26.

COHEN-ZARDI, D. Code Generation: good or evil? [S.l.], 2013. Disponvel em:


<http://blog.softfluent.com/2013/03/07/code-generation-good-or-evil/>. Acesso em:
2014.11.21. Citado na pgina 36.

CZARNECKI, K.; EISENECKER, U. W. Generative Programming: Methods, Tools, and


Applications. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co., 2000.
ISBN 0-201-30977-7. Citado na pgina 27.

DAISSAOUI, A. Applying the mda approach for the automatic generation of an mvc2
web application. In: LOUCOPOULOS, P.; CAVARERO, J.-L. (Ed.). RCIS. [S.l.]: IEEE,
2010. p. 681688. Citado 2 vezes nas pginas 47 e 48.

DAMASEVICIUS, R.; STUIKYS, V. Taxonomy of the fundamental concepts of


metaprogramming. 124X Information Tecnhology and Control, v. 27, p. 124132, 2008.
Citado na pgina 27.

FAYAD, M.; SCHMIDT, D. C. Object-oriented application frameworks. Commun. ACM,


ACM, New York, NY, US, v. 40, n. 10, p. 3238, out. 1997. ISSN 0001-0782. Disponvel
em: <http://doi.acm.org/10.1145/262793.262798>. Citado na pgina 16.

FORMAN, I. Java reflection in action. Greenwich, CT: Manning Pearson Education,


2005. ISBN 1-932394-18-4. Citado 2 vezes nas pginas 28 e 32.

FOWLER, M. Patterns of enterprise application architecture. 1. ed. Boston: Addison-


Wesley Professional, 2002. 560 p. ISBN 0-321-12742-0. Citado 2 vezes nas pginas 24
e 25.

FRANKY, M.; PAVLICH-MARISCAL, J. Improving implementation of code generators:


A regular-expression approach. In: Informatica (CLEI), 2012 XXXVIII Conferencia
Latinoamericana En. [S.l.: s.n.], 2012. p. 110. Citado 2 vezes nas pginas 38 e 40.

GERACI, A. Ieee standard glossary of software engineering terminology. IEEE Std


610.12-1990, p. 184, Dec 1990. Citado na pgina 35.

GOSLING, J. et al. The Java Language Specification, Java SE 7 Edition. 1st. ed. [S.l.]:
Addison-Wesley Professional, 2013. ISBN 0133260224, 9780133260229. Citado 3 vezes
nas pginas 26, 29 e 30.
HANSSON, D. H. Ruby on Rails Framework. [S.l.], 2003. Disponvel em: <http:-
//rubyonrails.org/>. Acesso em: 2014.11.11. Citado 2 vezes nas pginas 24
e 42.

HELLER, M. REST and CRUD: the Impedance MismatchWeb application framework.


Framingham, MA, US, 2007. Citado na pgina 17.

IWS. World Internet Users Statistics and 2014 World Population Stats. Bogota,
Colombia, 2014. Disponvel em: <http://www.internetworldstats.com/stats.htm>.
Acesso em: 2014.11.03. Citado na pgina 16.

JENKOV, J. Java Reflection Tutorial. [S.l.], 2008. Disponvel em: <http://tutorials-


.jenkov.com/java-reflection/index.html>. Acesso em: 2014.11.11. Citado na pgina
32.

KAISLER, S. Software paradigms. Hoboken, N.J: Wiley-Interscience, 2005. ISBN


0-471-48347-8. Citado na pgina 23.

LEINER, B. M. et al. A brief history of the internet. SIGCOMM Comput. Commun.


Rev., ACM, New York, NY, US, v. 39, n. 5, p. 2231, out. 2009. ISSN 0146-4833.
Disponvel em: <http://doi.acm.org/10.1145/1629607.1629613>. Citado na pgina 15.

LWE, W.; NOGA, M. L. Metaprogramming applied to web component deployment.


Electr. Notes Theor. Comput. Sci., v. 65, n. 4, p. 106116, 2002. Citado na pgina 27.

MALYSHEV, E. JSF Application in Just Two Clicks. [S.l.], 2006. Disponvel em:
<http://blog.jetbrains.com/idea/2006/11/jsf-application-in-just-two-clicks/>. Acesso
em: 2014.11.21. Citado 2 vezes nas pginas 47 e 48.

MARTIN, M.; MARTIN, R. Agile Principles, Patterns, and Practices in C#. Pearson
Education, 2006. ISBN 9780132797146. Disponvel em: <http://books.google.com.br-
/books?id=hckt7v6g09oC>. Citado na pgina 23.

MRACK, M.; MOREIRA lvaro de F.; PIMENTA, M. Merlin: Interfaces crud em tempo
de execuo. XIII Sesso de Ferramentas do SBES, Florianpolis, SC, p. 7984, 2006.
Citado 2 vezes nas pginas 47 e 48.

NETBEANS. Generating a JavaServer Faces 2.x CRUD Application from a Database.


[S.l.], 2010. Disponvel em: <https://netbeans.org/kb/docs/web/jsf20-crud pt BR-
.html>. Acesso em: 2014.11.21. Citado 2 vezes nas pginas 47 e 48.

NISO. Understanding metadata. Bethesda, MD, 2004. ISBN 1-880124-62-9. Citado na


pgina 26.

OLIVEIRA, M. F. de. Metaprogramao e Metadados de Persistncia e Indexao para o


Framework Object-Injection. Dissertao (Mestrado) Universidade Federal de Itajub,
Itajub, MG, 2012. Citado 2 vezes nas pginas 28 e 32.

ORACLE. A Metadata Facility for the Java Programming Language. [S.l.], 2004.
Disponvel em: <https://jcp.org/en/jsr/detail?id=175>. Acesso em: 2014.11.08. Citado
2 vezes nas pginas 29 e 30.
ORACLE. Package java.lang.reflect. [S.l.], 2011. Disponvel em: <https://docs-
.oracle.com/javase/7/docs/api/java/lang/reflect/package-summary.html>. Acesso em:
2014.11.11. Citado na pgina 32.

ORACLE. Trail: The Reflection API. [S.l.], 2011. Disponvel em: <https://docs-
.oracle.com/javase/tutorial/reflect/>. Acesso em: 2014.11.11. Citado na pgina
32.

PIVOTAL. Grails Framework. [S.l.], 2014. Disponvel em: <https://grails.org/>. Acesso


em: 2014.11.11. Citado 2 vezes nas pginas 24 e 44.

REENSKAUG, T. M. H. Models-Views-Controllers. [S.l.], 1979. Disponvel em: <http:-


//heim.ifi.uio.no/trygver/1979/mvc-2/1979-12-MVC.pdf>. Acesso em: 2014.11.03.
Citado 3 vezes nas pginas 17, 23 e 25.

ROCHER, G. et al. Grails Scaffolding. [S.l.], 2014. Disponvel em: <http://grails-


.org/doc/latest/guide/scaffolding.html>. Acesso em: 2014.11.11. Citado na pgina
46.

SANCHEZ, J. Crudo Plugin. [S.l.], 2008. Disponvel em: <http://crudo.sourceforge.net-


/>. Acesso em: 2014.11.21. Citado 2 vezes nas pginas 47 e 48.

SCHWARTZ, M. Web application framework. [S.l.], 2014. Disponvel em: <http:/-


/docforge.com/wiki/Web application framework>. Acesso em: 2014.11.03. Citado na
pgina 16.

SHEARD, T. Accomplishments and research challenges in meta-programming. In: In 2nd


Int. Workshop on Semantics, Applications, and Implementation of Program Generation,
LNCS 2196. [S.l.]: Springer-Verlag, 2000. p. 244. Citado na pgina 28.

SILVA, F.; PERRI, C.; ALMEIDA, L. Desenvolvimento de uma ferramenta assistente


para criao de aplicaes crud em java na web. Colloquium Exactarum, v. 2, n. 2, 2011.
ISSN 2178-8332. Disponvel em: <http://revistas.unoeste.br/revistas/ojs/index.php/ce-
/article/view/460>. Citado 2 vezes nas pginas 47 e 48.

SOMMERVILLE, I. Software Engineering. Boston: Pearson, 2011. ISBN 978-0-13-


703515-1. Citado na pgina 24.

TYPESAFE. Case Studies & Stories. San Francisco, US, 2014. Citado na pgina 17.

TYPESAFE. Play Framework Documentation. [S.l.], 2014. Disponvel em: <https:/-


/www.playframework.com/>. Acesso em: 2014.11.11. Citado na pgina 24.

W3C. Current Members - W3C. [S.l.], 2014. Disponvel em: <http://www.w3.org-


/Consortium/Member/List>. Acesso em: 2014.11.03. Citado na pgina 16.