Este documento apresenta um trabalho de conclusão de curso de bacharel em ciência da computação sobre um protótipo de framework para aplicações J2SE e J2EE. O trabalho descreve o framework desenvolvido seguindo padrões de projeto e orientação a objetos para permitir a geração de código a partir de arquivos XML.

1. UNIVERSIDADE COMUNITÁRIA DA REGIÃO DE CHAPECÓ
CENTRO TECNOLÓGICO
CURSO DE BACHAREL EM CIÊNCIA DA COMPUTAÇÃO
Douglas Hiura Longo
FRAMEWORK-Je: UM PROTÓTIPO DE FRAMEWORK PARA APLICAÇÕES J2SE E
J2EE
Chapecó – SC, 2009

2. 2
DOUGLAS HIURA LONGO
FRAMEWORK-Je: UM PROTÓTIPO DE FRAMEWORK PARA APLICAÇÕES J2SE
E J2EE
Trabalho de conclusão de curso apresentado à
UNOCHAPECÓ como parte dos requisitos à
obtenção do grau de Bacharel em Ciência da
Computação. Orientadora: Profª. Sediane Carmem
Lunardi Hernandes
Chapecó – SC, dez. 2009

3. 3
FRAMEWORK-Je: UM PROTÓTIPO DE FRAMEWORK PARA APLICAÇÕES J2SE
E J2EE
DOUGLAS HIURA LONGO
Esta Monografia foi julgada para obtenção do título de Bacharel em Ciência da Computação,
na área de concentração Arquitetura de Sistemas de Computação e aprovada pelo curso de
Ciência da Computação
ORIENTADORA: Profª. Sediane Carmem Lunardi Hernandes
COORDENADOR(A) DO CURSO: Prof. Jorge Antônio Di Domênico
BANCA EXAMINADORA
PRESIDENTE: Profª. Sediane Carmem Lunardi Hernandes
Profª. Elton Luís Minetto
Profª. Denio Duarte

4. 4
Direitos de cópia 2009 de Douglas Hiura Longo (douglashiura@gmail.com)
*É P-E-R-M-I-T-I-D-O (permitido) fazer cópias exatas e
distribuir este documento em qualquer meio, desde que esta nota seja preservada. Pede-se que
correções ou comentários sejam sempre enviados para o autor.
** É P-E-R-M-I-T-I-D-O (permitido) fazer cópias exatas e
distribuir os códigos(quando obtidos) em qualquer meio. Pede-se que correções ou
comentários sejam sempre enviados para o autor.
É P-E-R-M-I-T-I-D-O (permitido) criar e distribuir
trabalhos derivados deste(incluindo o código da aplicação), desde que o trabalho original seja
mencionado sempre que possível e sobre as perceptivas do primeiro(*) e segundo(**)
parágrafos.
É P-E-R-M-I-T-I-D-O (permitido) o uso deste
trabalho(incluindo o código da aplicação) para qualquer outro fim possível mesmo passando
sobre qualquer outra lei, desde que seja garantido ou para garantir o princípio da racionalidade
humana.
A obtenção deste documento pode ser feita pela Internet no endereço:
http://www.inf.ufsc.br/~douglashiura/monografia/DouglasHiuraMonografia.pdf
A obtenção dos códigos do projeto pode ser feita pela Internet no endereço:
http://www.inf.ufsc.br/~douglashiura/monografia/DouglasHiuraMonografia_source.zip

5. 5
AGRADECIMENTOS
Aos meus pais Ari Longo e Mariliene Maria Dalazen Longo, pela educação, apoio e
compreensão.
A meus “dindos” Jacir Dalazen e Sônia Bortolanza.
A minha tia Lorimar Dalazen.
A toda a minha família.
A Universidade Comunitária da Região de Chapecó.
Aos professores Cristiano Agosti e Sediane Carmem Lunardi Hernandes, pela atenção,
responsabilidade, disposição e competência nas orientações, durante o desenvolvimento deste
trabalho.
Aos professores que ministraram as disciplinas que subsidiaram a pesquisa, pelo nível
das contribuições.
Aos colegas de turma.
A todos que contribuíram direta ou indiretamente pela realização desta pesquisa.

6. 6
LISTA DE FIGURAS
Figura 1: Princípios da orientação a objetos (BEZERRA, 2002)...........................................17
Figura 2: Ambiente de estudo caracterizado por pães.............................................................18
Figura 3: Exemplo de herança (MARTIN, ODELL, 1995)......................................................19
Figura 4: Visão detalhada de uma classe (WAMPLER, 2002).................................................22
Figura 5: Objetos interagem através do envio de mensagens. (BEZERRA, 2002)..................23
Figura 6: Modelo de dados, representado por várias telas. (GAMMA et al., 2002) ..............27
Figura 7: Relacionamentos entre padrões de projeto.(GAMMA et al., 2002).........................31
Figura 8: Exemplo de um framework disponibilizando hot spot. (MARKIEWICZ; LUCENA,
2006).........................................................................................................................................35
Figura 9: White Box frameworks vs. black box frameworks. (LUCENA; MARKIEWICZ,
2006).........................................................................................................................................38
Figura 10: Representação Fluxo do Struts. (HUSTED et al., 2004)........................................41
Figura 11: Suíte da Arquitetura de JUnit (JUNIT, 2009) ........................................................46
Figura 12: Arquitetura do protótipo.........................................................................................50
Figura 13: Parte da Suíte de Classe e Padrões de Projeto do Stub.........................................52
Figura 14: Classes e Padrões de Projeto do Core...................................................................64
Figura 15: Cadastro de pessoa para J2SE...............................................................................75
Figura 16: Cadastro de pessoa para J2EE..............................................................................76
Figura 17: Arquitetura e Módulos para implementação da STUB.........................................86

7. 7
LISTA DE QUADROS
Quadro 1: Exemplo de teste utilizando JUnit..........................................................................45
Quadro 2: A Interface Projeto..................................................................................................53
Quadro 3: A Interface Classe...................................................................................................54
Quadro 4: A Interface Atributo.................................................................................................55
Quadro 5: Métodos da interface ClasseDeCamadas..............................................................57
Quadro 6: Fragmento da Classe ProjetoAbs...........................................................................58
Quadro 7: Fragmento de código da Classe ClasseAbs............................................................59
Quadro 8: Fragmento de Código da Classe AtributoAbs........................................................61
Quadro 9: Estrutura de um Documento XML de Descrição de Projetos.................................62
Quadro 10: Interface Configurações........................................................................................65
Quadro 11: Classe Kernel........................................................................................................66
Quadro 12: Fragmento da Classe ProcessadoraDeEspecificacaoDeProjetosPorXMLBuild 67
Quadro 13: Interface FacadeCriadoraDeElementos...............................................................70
Quadro 14: Descrição XML para Classe Pessoa.....................................................................73
Quadro 15: Definição SQL da Tabela Pessoa..........................................................................78
Quadro 16: Entidade Pesssoa..................................................................................................79
Quadro 17: Classe Para Manipulação da Entidade Pessoa....................................................80
Quadro 18: Código de Apresentação da Entidade Pessoa.......................................................81
Quadro 19: Servlet Para Inserir Uma Pessoa..........................................................................83
Quadro 20: Fragmento do código JSP/HTML para o Cadastro de Pessoa.............................84

8. 8
LISTA DE SIGLAS E ABREVIATURAS
J2EE Java 2 Enterprise Edition
J2SE Java 2 Stand edition
JSP JavaServer Pages
WEB World Wide Web – Rede de alcance mundial
XML eXtensible Markup Language
HTML HyperText Markup Language
IDE Integrated Development Environment
API Application Programming Interface
AWT Abstract Window Toolkit
JDBC Java Database Connectivity
SQL Structured Query Language

9. 9
RESUMO
Empresas e desenvolvedores de softwares buscam ferramentas para reduzir tarefas repetitivas,
aumentar a qualidade do software e reusar o código de seus softwares. Frameworks podem ser
utilizados para diminuir tarefas repetitivas e aumentar a produção do software. Desta forma, o
presente trabalho apresenta um protótipo de framework seguindo padrões de projeto e
orientação a objetos para aplicativos de manipulação de dados para as tecnologias J2SE e
J2EE. O protótipo permite adicionar soluções de desenvolvimento para aplicações que
manipulem dados para a tecnologia J2SE e J2EE.. Uma solução para geração de códigos por
meio de uma definição de arquivo XML utilizando o framework implementado é apresentada.
A utilização do framework atingiu os objetivos propostos neste trabalho.
Palavras chave: Frameworks, Orientação a Objetos, Padrões de Projeto, Java.

10. 10
ABSTRACT
Companies and software developers looking for tools to reduce repetitive tasks, improve
software quality and reuse the code of their software. Frameworks can be used to reduce
repetitive tasks and increase the production of software. Thus, this paper presents a prototype
framework following design patterns and object-oriented applications for data manipulation
for the J2SE and J2EE technologies. The prototype allows you to add development solutions
for applications that manipulate data for the J2SE and J2EE technology. A solution for code
generation through a definition of the XML file using the framework implemented is
presented. The use of the framework has reached the objectives proposed in this work.
Keywords: Frameworks, Object Oriented, Design Patterns, Java.

11. 11
SUMÁRIO
AGRADECIMENTOS ...............................................................................................................5
LISTA DE FIGURAS.................................................................................................................6
LISTA DE QUADROS...............................................................................................................7
LISTA DE SIGLAS E ABREVIATURAS..................................................................................8
RESUMO....................................................................................................................................9
ABSTRACT..............................................................................................................................10
1 INTRODUÇÃO.....................................................................................................................14
2 PROGRAMAÇÃO ORIENTADA A OBJETOS...................................................................16
2.1 ORIENTAÇÃO A OBJETOS.........................................................................................16
2.2 ABSTRAÇÃO................................................................................................................17
2.3 HERANÇA.....................................................................................................................18
2.4 ENCAPSULAMENTO..................................................................................................20
2.5 POLIMORFISMO..........................................................................................................20
2.6 CLASSES.......................................................................................................................21
2.7 OBJETOS.......................................................................................................................22
2.8 MENSAGENS................................................................................................................23
2.9 CONSIDERAÇÕES SOBRE O CAPÍTULO................................................................24
3 INTRODUÇÃO A PADRÕES DE PROJETO.......................................................................25
3.1 MODEL VIEW CONTROLLER – MODELO DE CAMADAS MVC.........................26
3.2 CATÁLOGO DE PADRÕES DE PROJETO PARA SOFTWARE ORIENTADO A
OBJETOS.............................................................................................................................28
3.3 CONSIDERAÇÕES SOBRE O CAPÍTULO................................................................32

12. 12
4 FRAMEWORKS ..................................................................................................................33
4.1 CLASSIFICAÇÃO DOS FRAMEWORKS..................................................................36
4.2 FRAMEWORKS E PADRÕES DE PROJETO.............................................................39
4.3 STRUTS.........................................................................................................................40
4.3.1 STRUTS E PADRÕES DE PROJETO...................................................................42
4.4 JUNIT.............................................................................................................................44
4.4.1 JUNIT E PADRÕES DE PROJETOS....................................................................46
4.5 CONSIDERAÇÕES SOBRE O CAPÍTULO................................................................48
5 IMPLEMENTAÇÃO DO PROTÓTIPO DE FRAMEWORK..............................................49
5.1 INTRODUÇÃO..............................................................................................................49
5.2 STUB..............................................................................................................................51
5.2.1 A INTERFACE PROJETO.....................................................................................53
5.2.2 A INTERFACE CLASSE ......................................................................................54
5.2.3 A INTERFACE ATRIBUTO...................................................................................55
5.2.4 O PACOTE EXTENSÃO.......................................................................................55
i) PACOTES CAMADAS.......................................................................................56
ii) TRÊS INTERFACES..........................................................................................57
iii) TRÊS CLASSES ABSTRATAS PARA EXTENSÃO.......................................58
5.3 CORE DO PROTÓTIPO................................................................................................62
5.3.1 DOCUMENTO XML PARA DEFINIÇÃO DE APLICAÇÕES............................62
5.3.2 AS CLASSES DO CORE.......................................................................................64
5.3.2.1 A INTERFACE CONFIGURAÇÕES.........................................................65
5.3.2.2 A CLASSE KERNEL..................................................................................65
5.3.2.3 A CLASSE ProcessadoraDeEspecificacaoDeProjetosPorXMLBuild........67
5.3.2.4 INSTÂNCIA DE OBJETOS NO PROCESSAMENTO DO XML DE

13. 13
DESCRIÇÃO..........................................................................................................69
6 IMPLEMENTANDO O DOMÍNIO CONCRETO PARA UM CADASTRO DE PESSOA.72
6.1 DEFININDO O PROJETO CADASTRO DE PESSOA...............................................72
6.2 PERSPECTIVAS NA IMPLEMENTAÇÃO DO DOMÍNIO CONCRETO..................74
6.2.1 OBJETIVOS NA IMPLEMENTAÇÃO DO DOMÍNIO CONCRETO.................75
6.2.2 DEFINIÇÃO DAS CAMADAS NO DOMÍNIO CONCRETO.............................77
6.2.2.1 CAMADA SQL...........................................................................................77
6.2.2.2 CAMADA ENTIDADE..............................................................................78
6.2.2.3 CAMADA DAO..........................................................................................79
6.2.2.4 CAMADA VISÃO PARA J2SE..................................................................81
6.2.2.5 CAMADA VISÃO PARA J2EE..................................................................82
6.3 O DOMÍNIO CONCRETO............................................................................................85
7 CONCLUSÃO E TRABALHOS FUTUROS........................................................................87
7.1 CONCLUSÃO...............................................................................................................87
7.2 TRABALHOS FUTUROS.............................................................................................89
8 REFERÊNCIAS.....................................................................................................................90

14. 14
1 INTRODUÇÃO
Empresas e desenvolvedores de softwares buscam ferramentas para reduzir tarefas
repetitivas, aumentar a qualidade do software e reusar o código de seus softwares. Essas
ferramentas podem ser empregadas no processo de desenvolvimento de software, bem como
na codificação da aplicação.
A tecnologia Java possui inúmeras ferramentas que podem auxiliar o desenvolvimento
de software, como por exemplo Struts (HUSTED etal., 2004). Contudo, o uso das ferramentas
nem sempre é trivial, estas possuem limitações ou são projetadas para resolver problemas
muito complexos. De qualquer forma, para construir um software, os desenvolvedores
precisarão conhecer as ferramentas, sejam elas APIs ou ambientes de programação, além de
como fazer para inserir os dados de um objeto em um banco de dados, entre outros. Também,
para produzir um software os desenvolvedores aplicam seus conhecimentos, isso de maneira
repetitiva. Como consequência, muito tempo é necessário, além da tarefa repetitiva “cansar” o
desenvolvedor.
Desta forma, frameworks podem ser utilizados para diminuir tarefas repetitivas e
aumentar a produção do software. Este trabalho se propôs a fazer um protótipo de framework
onde seja possível implementar aplicações J2SE e J2EE e sendo possível implementar com o

15. 15
protótipo as melhores práticas de desenvolvimento. Cabe salientar que a tecnologia Java é
segmenta para vários ambientes específicos. Porém, há divergências entre cada ambiente.
Uma aplicação projetada para edição Java 2 Stand Edition (J2SE) não funciona nativamente
para a edição Java 2 Enterprise Edition (J2EE). Isso faz com que para tornar a aplicação
disponível para as duas edições seja implementada uma estrutura para uma edição e para a
outra edição seja refeito todo o trabalho com base na tecnologia desta edição; entretanto,
grande parte da lógica continuando similar. Assim, o protótipo de framework implementado
apresenta uma versão para cada uma dessas tecnologias.
O trabalho é dividido como segue. No capítulo 2 são apresentados os conceitos de
programação orientada a objetos. No capítulo 3, conteúdos referentes a padrões de projeto são
descritos. Enquanto que no capítulo 4 explica-se frameworks, mais especificamente os
frameworks Struts e JUnit. O protótipo do framework é apresentado no capítulo 5, bem como
as formas de descrever uma aplicação que manipule dados, os pontos de inserir os padrões,
modelos de projetos e soluções que se pretende alcançar. Por fim, é apresentado uma solução
de geração de códigos no capítulo 6 para as tecnologias J2EE e J2SE - uma das soluções que
podem ser aplicadas com o protótipo para aplicações que manipulem dados nas tecnologias
propostas. Algumas considerações finais e sugestões futuras de expansão do protótipo do
framework é apresentada no último capítulo do trabalho.

16. 16
2 PROGRAMAÇÃO ORIENTADA A OBJETOS
A programação orientada a objeto é um modo de implementação, no qual os
programas são organizados como coleções de objetos cooperando entre si, cada um dos quais
representa uma instância de alguma classe, e cujas classes são todas membros da hierarquia de
classes unidas através de relações de herança (BOOCH, 1997). Assim este capítulo aborda
conceitos introdutórios programação orientada objetos: orientação a objetos, abstração,
herança, encapsulamento, polimorfismo, classes, objetos e mensagens.
2.1 ORIENTAÇÃO A OBJETOS
A orientação a objetos é (RUMBAUGH et al., 1994, p.1) "um novo modelo de estudar
os problemas com utilização de modelos fundamentados em conceitos do mundo real". Assim,
pode-se determinar que a orientação a objetos mapeia as similaridades de um ambiente
contido no mundo real ou mesmo abstrato em um molde abstrato onde possa ser fabricado
objetos.

17. 17
A relação entre abstração e orientação a objetos é formada pelas características de
encapsulamento, polimorfismo e herança (BEZERRA, 2002). A abstração é uma descrição
feita a partir da observação de herança, polimorfismo e encapsulamento dos objetos contidos
em um ambiente de estudo, descrevendo os detalhes dos objetos. A Figura 1, representa essa
relação.
ORIENTAÇÃO A OBJETOS
ENCAPSULAMENTO POLIMORFISMO HERANÇA
ABSTRAÇÃO
Figura 1: Princípios da orientação a objetos (BEZERRA, 2002)
Os assuntos: Abstração, Herança, Encapsulamento e Polimorfismo são descritos nas
seções 2, 3, 4 e 5 respectivamente deste capítulo.
2.2 ABSTRAÇÃO
A abstração segundo Wampler (2002, p.10, Tradução Nossa) “é o mecanismo que
permite que uma situação complexa do mundo real, seja representada utilizando um modelo
simplificado”. Ou seja, baseado no ambiente em estudo, definir as características relevantes
que fazem parte do problema, sem considerar detalhes específicos, criando assim um molde.
Um exemplo de representação do mundo real pode ser visto na Figura 2.

18. 18
Figura 2: Ambiente de estudo caracterizado por pães.
O ambiente real caracterizado pela Figura 2 é composto por três tipos de pães, sendo
que cada pão têm características própria. O Pão de Raspas de Limão têm cheiro de limão. O
Pão Integral têm gosto de grão de trigo. O Pão Italiano têm casca crocante. Porém, todos
possuem características comuns, são feitos com massa de farinha, possui aspecto dimensional
cúbico, mas com deformações, a cor é típica de produtos assados, entre outras características
similares entre eles. Todas essas características similares faz com que cada um de nós possa
determinar o que é um pão, ou o molde Pão, contido no ambiente de estudo. O molde é
representado na programação orientada a objetos através de classes(Seção 6).
2.3 HERANÇA
Para Bezerra (2002, p.10), “a herança é outra forma de abstração utilizada na
orientação a objetos”. Desta maneira, é uma uma forma de agrupar objetos com semelhanças.
Ainda para Martin e Odell (1995, p.26) “[...] há uma hierarquia de tipos de objetos, tipos e
sub-tipos e assim por diante”, ou seja, é formar uma estrutura de camadas de classes, uma

19. 19
sobre a outra. A nomenclatura utilizada para classes mais interna é super-classe ou classe pai,
e pra classe mais externas é sub-classe ou classe filha. As características de uma sub-classe
relacionada através de herança, é representada pela Figura 3.
A
74.3
B CLASSE
-+3
3@42
C
HERANÇA
A
74.3
B -+3 4-3 H SUB-CLASSE
3@42 5%4
C
Figura 3: Exemplo de herança (MARTIN, ODELL, 1995)
Uma sub-classe herda todos os atributos e métodos da classe que esta relacionada
através de herança. A sub-classe pode ainda adicionar mais métodos e atributos ou ainda
modifica-los, afim de especificar melhor a sub-classe de acordo com o ambiente de estudo. A
super-classe ou classe pai apenas fornece seus recursos. As relações de agregação e
composição também fazem parte do paradigma de programação orientada objetos, mas não
será estudado neste trabalho.

20. 20
2.4 ENCAPSULAMENTO
Segundo Martin e Odell (1995, p.21), "encapsulamento é o resultado (ou ato) de
ocultar do usuário os detalhes da implementação de um objeto". Assim, para detalhes
específicos da implementação de cada objeto é determinado níveis de acesso que permitem a
manipulação por outras classes e objetos. Com a técnica de encapsulamento pode ser mantido
confiança nos dados dos objetos, pois, a alteração dos dados ou acesso de métodos é
determinada com modificadores que nivelam o acesso externo.
O uso do encapsulamento na abstração é esconder os detalhes de funcionamento
interno do objeto. Por exemplo, um aparelho de DVD, tem vários botões que são responsáveis
por funções específicas do aparelho. O botão PLAY é responsável reproduzir. Dentro do
aparelho ao ser acionado esse botão é implementado vários circuítos elétricos e mecanismos
que acionam o disco para reproduzir, mas para o usuário como tudo isso é implementado não
é relevante, sendo que o botão fica encapsulado pela carcaça. O usuário apenas conhece a
interface, no caso o botão e o que ele faz.
2.5 POLIMORFISMO
Polimorfismo é a última característica fundamental da orientado a objetos. Quando a
herança é utilizada para estender uma classe generalizada a uma classe mais especializada, ela
costuma incluir os comportamentos da classe generalizada. A classe especializada
frequentemente implementa os comportamentos um pouco diferente da classe generalizada,

21. 21
mas o nome usado para definir o comportamento será sempre o mesmo (WAMPLER, 2002).
As classes generalizadas são as formas que um objeto pode assumir, são consideradas
como os adjetivos do objeto. Por exemplo, o Ser Humano(classe especializada) tem algumas
características que pode exercer, como andar, correr, esses são comportamentos da classe
Movimentar (Classe generalizada). O Cachorro (Classe especializada) também implementa
a classe Movimentar, porém, a forma lógica que o Cachorro realiza é diferente do Ser
Humano. Vendo assim, as classes especializadas Cachorro e Ser Humano implementam a
classe Movimentar, porém, a forma lógica de implementação é distinta entre as duas classes
especializadas.
2.6 CLASSES
Uma classe é segundo Bezerra (2002, p.7) “uma descrição dos atributos e serviços
comuns a um grupo de objetos. Sendo assim, pode-se entender uma classe com sendo um
molde a partir do qual objetos são construídos”. Logo, uma classe deve ser uma representação
genérica, caracterizada pela abstração parcial ou integral do ambiente de estudo. No caso da
Figura 2, onde encontram-se três tipos de pães, o molde abstrato pode ser representado pela
classe Pão. A classe Pão é relativa ao contexto, mas para descrevê-la é observado
características de herança, polimorfismo e encapsulamento contidas no ambiente em estudo.
Em programação orientada a objetos, as classes são formadas por nome, métodos e
atributos. Ainda pode ser encontrados modificadores relacionados a estrutura da classe. Os
modificares configuram o acesso de atributos, métodos e a própria classe. Esses elementos
que compõe uma classe e sua estrutura pode ser verificado na Figura 4.

22. 22
ClassName
Attributes
- privateAttr : type
# protectedAttr : type
+ publicAttr : type
Methods
+ methodA(argList): returnType
+ methodB(argList): returnType
Figura 4: Visão detalhada de uma classe (WAMPLER, 2002)
A identificação da classe(ClassName) é definida por um nome, onde serão feitas
também referências a classe. Os atributos (attributes) são responsáveis pelas características
dos objetos. Os métodos (Methods) representam as funcionalidades e ações. O modificador
público(+) permite o acesso de qualquer local. Modificador protegido(#) restringe o acesso
para dentro de um pacote. Modificador privado(-) restringe o acesso para dentro da classe.
2.7 OBJETOS
Segundo Bezerra (2002, p.7), “um objeto é uma instância de uma classe”. Assim, pode
ser associado como a forma “viva” representada pela classe. Os objetos podem estar contidos
no ambiente de estudo ou ser as instâncias das classes. Aqui será mais considerado os objetos
como instâncias das classes (moldes).
Durante o período de existência de um objeto, ele sofre ações como troca de valores
dos atributos e execução dos métodos. Neste período os métodos também são utilizados como

23. 23
canal de troca de mensagens, sendo que o conteúdo das mensagens é relevante ao estado do
objeto. Há ações ou chamadas de métodos e atributos dos objetos depende dos modificadores
e da lógica aplicada na estrutura das classes(estratégia do algoritmo).
2.8 MENSAGENS
As mensagens são como os objetos comunicam-se entre si (Wampler, 2002). Ainda
para Bezerra (2002), as operações de mensagens só são executadas quando existir um
estímulo enviado a um objeto. Quando um estímulo ocorre, diz-se que o objeto em questão
está recebendo uma mensagem requisitando que ele realize alguma operação.
Os objetos podem estabelecer várias ligações uns aos outros. Na orientação a objetos,
segundo Bezerra (2002, p.8) “quando os objetos de um sistema estão trocando mensagens
significa que esses objetos estão enviando mensagens uns aos outros com o objetivo de
realizar alguma tarefa dentro do sistema no qual eles estão inseridos”. Assim, para associar
um sistema abstrato onde objetos trocam mensagens entre si é apresentada a Figura 5.
objeto
objeto objeto
objeto objeto objeto
Figura 5: Objetos interagem através do envio de mensagens. (BEZERRA,
2002)
Em um conjunto de objetos rodando em uma aplicações os objetos trocam as

24. 24
mensagens por meio de métodos. Por exemplo: um objeto soma responsável por efetuar uma
operação de soma entre dois números, e outro objeto saída responsável por mostrar valores na
tela. O objeto soma quando realizar uma operação pode estimular(chamar um método) o
objeto saída para mostrar um resultado. Para fazer isso esses trocam mensagens.
2.9 CONSIDERAÇÕES SOBRE O CAPÍTULO
Neste capítulo foram apresentados os principais conceitos de programação orientada a
objetos. Esses conceitos são as ferramentas base para a implementação da proposta deste
trabalho. A programação orientada a objetos ajuda de maneira não tão complexa observar e
implementar sistemas complexos. Há inúmeras referências sobre o assunto disponível, sendo
que poderiam ser apresentados até mais conceitos, porém não há necessidade, sendo que o
foco principal foi apresentar conceitos básicos para utilização do protótipo implementado.

25. 25
3 INTRODUÇÃO A PADRÕES DE PROJETO
Muitos dos problemas encontrados por desenvolvedores de software, já foram
estudados e resolvidos, assim, documentado as melhores soluções. Essas soluções
documentadas são úteis em outros projetos, evitando o desgaste dos desenvolvedores a recria-
las, usufruindo essas soluções muitas vezes.
Inicialmente, no contexto de edificações de cidades, Christopher Alexander
(ALEXANDER,77, apud GAMMA et al., 2002, p.19) afirma: " cada padrão descreve um
problema no nosso ambiente e o cerne da sua solução, de tal forma que você possa usar essa
solução por mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira".
No contexto de software orientado a objetos, Gamma et al. (2002) determina que
essencialmente um padrão de projeto:
[...] nomeia, abstraí e identifica os aspectos-chave de uma estrutura
de projeto comum para torná-la útil para a criação de um projeto
orientado a objetos reutilizável. O padrão de projeto identifica as
classes e instâncias participantes, e seus papéis, colaborações e a
distribuição de responsabilidades. Cada padrão de projeto focaliza um
problema ou tópico particular de projeto orientado a objetos. Ele
descreve quando pode ser aplicado, se pode ser aplicado em função
de outras restrições de projeto e as consequências, custos e
benefícios de sua utilização.[...] (GAMMA et al., 2002, p.20).
Numa visão geral no desenvolvimento de aplicações, Minetto (2007, p.19) afirma que:

26. 26
“Padrões de Projetos[...]são formas já testadas e documentadas de se resolver certo tipo de
problema. Essas soluções ou metodologias podem ser aplicadas a vários problemas
encontrados no desenvolvimento de aplicações”. De modo geral, os padrões de projeto de
software mapeiam um problema e determinam uma solução genérica para o mesmo.
Para desenvolvimento de software, encontram-se vários padrões de projeto para
software orientados a objetos, já especificados e documentados; porém, nem todos são
aplicados em um projeto só, por restrições de ambiente de desenvolvimento, de linguagens, de
características de projeto, entre outras. Neste capítulo se pretende apresentar, principalmente,
o modelo de camadas MVC e alguns padrões de projetos para software orientado a objetos.
3.1 MODEL VIEW CONTROLLER – MODELO DE CAMADAS MVC
A partir das primeiras aplicações gráficas, os arquitetos de software observaram que as
aplicações estruturavam-se em três partes maiores (HUSTED et al., 2004): uma camada de
gerencia de dados, uma camada que apresentava as telas e relatórios, e uma camada que
tratavam interações com usuário e subsistemas. Tão logo, nos anos 80 a linguagem Smalltalk,
adotou essa estrutura, como tecnologia no desenvolvimento de aplicações, sendo que para
(HUSTED et al., 2004):
• Model - sistema de dados;
• View - sistema de apresentação;
• Controller - sistema de interação.
A lógica da aplicação é distribuída nas três camadas e para Gamma et al (2002)
caracteriza a implementação utilizando MVC como:

27. 27
[..] separa Vistas e Modelos pelos estabelecimento de um protocolo
inserção/notificação(subscribe/notify) entre eles. Uma vista deve
garantir que a sua aparência reflita o estado do modelo. Sempre que
os dados do modelo mudam, o modelo notifica as vistas que
dependem dele. Em resposta, cada vista tem a oportunidade de
atualizar-se. Esta abordagem permite ligar múltiplas vistas a um
modelo para fornecer diferentes apresentações.[...] (GAMMA et al.,
2002, p.21)
A divisão do modelo e vista é caracterizada pela Figura 6.
Figura 6: Modelo de dados, representado por várias telas. (GAMMA et al.,
2002)
Conforme pode ser observado na Figura 6. O objeto modelo contém os dados que são
mostrados de diferentes formas ou em telas distintas. De modo amplo é visto um problema
geral, sendo que quando dados do modelo forem alterados, então deve ser implementado um
mecanismo de atualização nas telas. Esse problema de projeto mais geral descrito pode ser
implementado com o padrão de projeto para software orientado a objetos Observer(Seção 2).
Para implementação da camada visão, pode-se requerer vários elementos gráficos. Por
exemplo: compor uma tela para apresentar um gráfico com um menu e um rodapé. Essa

28. 28
abordagem de compor uma tela pode ser implementada com o padrão de projeto Composite
view(Seção 2).
Para implementação do modelo MVC, podem serem utilizados não um, mas vários
padrões de projetos para softwares orientados a objetos. O que deve ser levado em
consideração na escolha dos padrões a serem adotados é apenas o problema e a forma geral da
solução. Ainda, durante a implementação de aplicações utilizando MVC, existe vantagens na
separação de camadas, onde pode existir equipes especificas para cada camada, fortalecendo
assim o trabalho em equipe (MINETTO, 2007).
3.2 CATÁLOGO DE PADRÕES DE PROJETO PARA SOFTWARE ORIENTADO
A OBJETOS
O catálogo de 23 (vinte três) padrões de projeto para software orientado a objetos
apresenta o nome e uma visão geral de cada padrão (Gamma et al., 2002):
ABSTRACT FACTORY: Fornece uma interface para criação de
famílias de objetos relacionados ou dependentes sem especificar
suas classes concretas.
ADAPTER: Converte a interface de uma classe em outra interface
esperada pelos clientes. O Adapter permite que certas classes
trabalhem em conjunto, pois de outra forma seria impossível por
causa de suas interfaces incompatíveis.
BRIDGE: Separa uma abstração da sua implementação, de modo
que as duas possam variar independentemente.
BUILDER: Separa a construção de um objeto complexo da sua
representação, de modo que o mesmo processo de construção possa
criar diferentes representações.
CHAIN OF RESPONSIBILITY: Evita o acoplamento do remetente de

29. 29
uma solicitação ao seu destinatário, dando a mais de um objeto a
chance de tratar a solicitação. Encadeia os objetos receptores e
passa a solicitar ao longo da cadeia até que um objeto a trate.
COMMAND: Encapsula uma solicitação como um objeto, desta forma
permitindo que você parametrize clientes com diferentes solicitações,
enfileire ou registre (log) solicitações e suporte operações que podem
serem desfeitas.
COMPOSITE: Compõe objetos em estruturas de árvore para
representar hierarquias do tipo parte-todo. O composite permite que
os clientes tratem objetos individuais e composições de objetos de
maneira uniforme.
DECORATOR: Atribui responsabilidades adicionais a um objeto
dinamicamente. Os decorators fornecem uma alternativa flexível a
subclasses para extensão da funcionalidade.
FAÇADE: Fornece uma interface unificada para um conjunto de
interfaces em um subsistema. o Façade define uma interface de nível
mais alto que torna o subsistema mais fácil de usar.
FACTORY METHOD : Define uma interface para criar um objeto, mas
deixa as subclasses decidirem qual classe a ser instanciada. O
Factory Method permite a uma classe postergar (defer) a instanciação
às subclasses.
FLYWEIGTH: Usa compartilhamento para suportar grandes
quantidades de objetos, de granularidade fina, de manira eficiente.
INTERPRETER: Dada uma linguagem, define uma representação
para interpretar sentenças nessa linguagem.
INTERATOR: Fornece uma maneira de acessar sequencialmente os
elementos de uma agregação de objetos sem expor sua
representação subjacente.
MEDIATOR: Define um objeto que encapsula a forma como um
conjunto de objetos interage. O Mediator promove o acoplamento
fraco ao evitar que os objetos se refiram explicitamente uns aos
outros, permitindo que você varie suas interações
independentemente.
MEMENTO: Sem violar o encapsulamento, captura e externalismo um
estado interno de um objeto, de modo que o mesmo possa
posteriormente ser restaurado para este estado.
OBSERVER: Define uma dependência um-para-muitos entre objetos,
de modo que, quando um objeto muda de estado, todos os seus
dependentes são automaticamente notificados e atualizados.
PROTOTYPE: Especifica os tipos de objetos a serem criados usando

30. 30
uma instância prototípica e criar novos objetos copiando esse
protótipo.
PROXY: Fornece um objeto representante (surrogate), ou um
marcador de outros objetos, para controlar o acesso ao mesmo.
SINGLETON: Garante que uma classe tenha somente uma instância
e fornece um ponto global de acesso para ela.
STATE: Permite que um objeto altere seu comportamento quando seu
estado interno muda. O Objeto parecerá ter mudado de classe.
STRATEGY: Define uma família de algoritmos, encapsula cada um
deles e os torna intercambiáveis. O Strategy permite que o algoritmo
varie independentemente dos clientes que o utilizam.
TEMPLATE METHOD: Define o esqueleto de um algorítimo em uma
operação, Method permite que as subclasses redefinam certos
passos de um algorítimo sem mudar sua estrutura.
VISITOR: Representa uma operação a ser executada sobre os
elementos da estrutura de um objeto. O Visitor permite que você
defina uma nova operação sem mudar as classes dos elementos
sobre os quais opera.
O catálogo é útil para selecionar padrões mais adequados no desenvolvimento de
aplicações orientadas a objetos. Esse catálogo abrange as soluções abstratas possíveis em um
grande número de aplicações. Os padrões de projeto são organizados de diversas maneiras
diferentes, sendo que existem "Padrões Relacionados". As formas de relacionamentos
depende do contexto de implementação (GAMMA et al., 2002). Umas das formas de
organizar e relacionar os padrões pode ser visualizada pela Figura 7.

31. 31
Figura 7: Relacionamentos entre padrões de projeto.(GAMMA et al., 2002).
Ainda, no desenvolvimento do catálogo J2EE, Alur et al. (2002, p.8) relata:
Cada padrão foi nomeado e renomeado várias vezes. Além disso,
cada um deles foi reescrito diversas vezes, com base no feedback da
comunidade. Nem é preciso dizer que esses padrões, assim como

32. 32
todos os padrões, estão sujeitos a um contínuo aprimoramento e
certamente evoluirão à medida que a tecnologia e as especificações
mudarem.(ALUR et al., 2002, p.8)
Para compreensão total destes padrões de projeto (GAMMA et al., 2002) descreve:
nome e classificação do padrão, intenção e objetivo, motivação, aplicabilidade, estrutura,
participantes, colaboração, consequências, implementação, exemplo de código, usos
conhecidos, e padrões relacionados. Cabe ressaltar que também existam muitas outras
referências especificas, como o catálogo para desenvolvimento de aplicações J2EE - Core
J2EE (tm) PATTERNS (ALUR et al., 2002).
3.3 CONSIDERAÇÕES SOBRE O CAPÍTULO
Neste capítulo foi apresentado o modelo de camadas MVC e introduzidos alguns
padrões de projeto. O modelo MVC permite a divisão do trabalho e também pode ser
projetado juntamente com as camadas os de padrões de projeto. Um dos grandes fatores
percebidos é que os padrões de projeto comutados com programação orientadas a objetos são
úteis para o desenvolvimento de aplicações como frameworks.

33. 33
4 FRAMEWORKS
Wirfs e Brock (apud SILVA, 2000, p.31), propõem a seguinte definição para
framework:
[..] um esqueleto de implementação de uma aplicação ou de um
subsistema de aplicação, em um domínio de problema particular. É
composto de classes abstratas e concretas e provê um modelo de
interação ou colaboração entre as instâncias de classes definidas
pelo framework. Um framework é utilizado através de configuração ou
conexão de classes concretas e derivação de novas classes
concretas a partir das classes abstratas do framework. (WIRFS e
BROCK apud SILVA, 2000, p.31)
Ainda, Johnson (apud OLIVEIRA, 2008, p.34), afirma: “um framework é um
esqueleto de uma aplicação que deve ser parametrizado pelo desenvolvedor da aplicação” e
“um framework é um conjunto de classes que representa um design abstrato para soluções em
uma família de aplicações”. Na primeira afirmação, um framework é um software ajustável
que pode ser utilizado em outra aplicação. Já na segunda afirmação, sugere que, framework é
uma implementação que contem a solução de um problema e pode ser aplicado em problemas
similares.
Pode ser induzido que os frameworks estão dentro do conceito de abstração,

34. 34
encapsulamento, herança e polimorfismo correspondente ao paradigma de programação
orientado a objetos. Existe uma estrutura que abstraí e implementa um problema num
determinado domínio. Esta estrutura é composta por classes e objetos prestando colaboração
entre si. Ainda a estrutura possui pontos de entrada e saída, constituídos por classes abstratas e
interfaces do framework, que podem ser estendidas para solucionar outros problemas.
A abstração do framework ocorre no momento da construção, onde são definidas as
funcionalidades, as possíveis funções a ser implementadas na determinada solução de um
problema específico. A herança ocorre quando as características abstratas do framework são
utilizadas.
O polimorfismo, segundo Assis (2003, p.3) “se faz presente a partir do momento em
que classes existentes no projeto do framework são sobrescritas para atender as
especificidades da aplicação em desenvolvimento”, assim, é uma das técnicas que permite a
extensão do framework.
As classes que utilizam os códigos especiais para solucionar outros problemas, são
chamadas de hot spots. Hot spots são classes abstratas ou métodos abstratos, através dos quais
implementam-se soluções externas. O kernel (núcleo) formado por engines ou frozen spots do
framework são classes ou objetos, através do qual é implementada parte da solução de um
problema. As classes ou objetos que compõe o kernel são responsáveis pela instanciação das
classes e a execução de métodos que foram implementados pelo desenvolvedor a partir de um
hot spot.

35. 35
Figura 8: Exemplo de um framework disponibilizando hot spot. (MARKIEWICZ;
LUCENA, 2006).
A Figura 8 ilustra a implementação (“Implementation of Hot-Spot #1”) de código
especifico, onde, seu código adapta-se com a interface (“Hot-Spot #1”) disponibilizado pelo
framework. O código específico é controlado pelo Kernel e permite implementações a partir
dos pontos "Hot-Spot #1”, "Hot-Spot #2” e "Hot-Spot #3”. Esses pontos podem ser
reutilizados indefinitivamente por aplicações em outros problemas possíveis.
Tendo em vista que a partir do Kernel é executado o código específico implementado
sobre os hot-spot, então, dependendo da implementação do framework, precisa-se de arquivos
para configuração. Estes arquivos contém as informações necessárias para o funcionamento
do kernel junto com a aplicação. Os arquivos de configuração geralmente são no formado
XML, pois são bem estruturados e relativamente fácil escreve-los.
Existem meios como reflexão que também pode ser utilizado para configuração de
algoritmos específicos. A reflexão é o meio de descobrir informações ou meta informações de
classes sem provocar a execução da mesma.

36. 36
Muito além de saber quais algoritmos executar, o kernel também deve inverter o
controle do código específico para o código do framework, o qual se denomina inversão de
controle. Essa alternação é diferente de quando o programador utiliza bibliotecas e tem de
tomar o controle de execução. (GAMMA et al., 2002)
4.1 CLASSIFICAÇÃO DOS FRAMEWORKS
Cada framework pode ser construído para um fim específico. Porém, sua classificação
segundo Assis ( 2003, p.5) “se dá a partir do modo de como ele será empregado, que pode ser
voltado para dados ou para a arquitetura”. Os frameworks voltados para dados podem
combinar as várias instâncias de dados montando a aplicação. Enquanto os voltados para a
arquitetura possuem subclasses construídas tendo como base às classes pré-existentes do
framework. A determinação da classificação se faz no processo de desenvolvimento através
de: análise do domínio, sua aplicabilidade, requisitos necessários, entre outros.
Os frameworks podem ser classificados pelo escopo (ASSIS, 2003):
•System Infrastructure frameworks: são os frameworks utilizados na
construção de sistemas operacionais e interfase com usuário, por
exemplo. Sua função é simplificar a construção da infra-estrutura
destes tipos de sistemas, buscando a portabilidade e eficiência dos
mesmos.
•Middleware Integration Frameworks: são os frameworks
responsáveis por a comunicação em ambientes e aplicações
distribuídas. Projetados para melhorar a habilidade de
desenvolvedores em modularizar, reutilizar e estender sua infra-

37. 37
estrutura de software para funcionar em um ambiente distribuído.
•Enterprise Application Frameworks: são os frameworks voltados
para aplicações comerciais e para a área dos negócios. Ainda, para
Husted et al. ( 2004) são conhecidos por funcionarem bem em outras
aplicações; Estão prontos para serem utilizados com o próximo
projeto; podem também ser utilizados por outras equipes na
organização facilmente.
A classificação dos frameworks ainda pode ser definida em mais um nível relativo à
sua extensibilidade ou instanciação.(LUCENA; MARKIEWICZ, 2006):
•Os White Box frameworks, também chamados de frameworks
orientados a arquitetura, a instanciação só é possível através da criação
de novas classes. Estas classes e código podem ser introduzidos no
framework por herança ou composição. Um usuário deve conhecer
muito bem o framework para poder produzir uma instância ou utilizá-
lo.
•Os Black Box frameworks, produz instâncias usando scripts de
configurações. Após a configuração, uma instância da ferramenta de
automação cria as classes e código fonte. Por exemplo, é possível
utilizar um ambiente gráfico que oriente o usuário passo a passo
através de etapas do processo de instância do framework. Esse tipo
não exige do usuário saber detalhes internos do framework.
Consequentemente, esses frameworks são chamados de frameworks
orientados a dados e são e geralmente são mais fáceis de utilizar.
•Gray Box frameworks, são frameworks que contém características de
White Box frameworks e Black Box frameworks.

38. 38
A Figura 9 ilustra as ideias de white box frameworks e black box frameworks.
Figura 9: White Box frameworks vs. black box frameworks. (LUCENA;
MARKIEWICZ, 2006)
A Figura 9 representa a maneira que a aplicação pode ser associada aos frameworks.
A representação White-box framework, sugere que a interação da aplicação com o framework
seja feita a partir de pontos abertos por herança ou composição. Já Black-Box framework, o
kernel não está aberto e se faz necessário para a interação com o mesmo o uso de ferramentas
externas através do qual pode ser utilizado um arquivo de configuração.
Essas classificação de frameworks faz com que desenvolvedores possam escolher os
mais adequados para seus projetos, bem como, quando implementar um, determinar as
características gerais e as formas básicas para o uso.

39. 39
4.2 FRAMEWORKS E PADRÕES DE PROJETO
Os padrões de projeto são incorporados aos frameworks servindo como uma
linguagem abstrata, ajudando com que os desenvolvedores os criem e utilizem. Os aspectos de
similaridade e diferenças entre os padrões e os frameworks são (GAMMA et al., 2002, p.43):
• Padrões de projeto são mais abstratos que frameworks. Os
frameworks podem ser materializados em código, mas
somente exemplos de padrões é que podem ser materializados
em códigos. Um ponto forte dos frameworks é que podem ser
escritos em uma linguagem de programação, sendo não
apenas estudados, mas executados e reutilizados diretamente.
• Padrões de projeto são elementos de arquitetura menores
que frameworks. Um framework típico contém vários padrões,
mas a recíproca nunca é verdadeira.
• Padrões de projeto são menos especializados que
frameworks. Os frameworks sempre têm um particular domínio
de aplicação. Os padrões de projetos podem ser utilizados em
qualquer domínio de aplicação.
Uma maneira de resolver problemas pode ser utilizando padrões de projetos, mas,
implementando os padrões de projeto em um framework específico é a maneira de
materializar a solução e poder reutiliza-la.

40. 40
4.3 STRUTS
O Struts é um framework de aplicação, mantido pela Apache Software Foundation
(ASF) desde 2000, sob a licença Apache Software License [ASF, License] (Fonte aberta)
(STRUTS, 2008). Esse framework implementa modelo de camadas (MVC), incorporando
padrões nessas camadas. Sugestivo quanto o nome, o Struts é uma estrutura para desenvolver
especialmente aplicações WEB.
As classes básicas do modelo MVC implementadas no Struts são (HUSTED et al.,
2004):
• ActionForward – É o gestor do usuário ou faz a seleção da exibição;
• ActionForm – Os dados para uma alteração de estado;
• ActionMapping – O evento de alteração de estado;
• ActionServlet – A parte do Controller que recebe as entradas do
usuário, as alterações de estados e envia as seleções de exibição;
• Classes Action – A parte do Controller que interage com o modelo
para executar uma alteração do estado ou consulta e passa para o
ActionServlet o destino a ser exibido.
• GenericDataSource – Controla o acesso as dados, pode ser banco de
dados ou APIs que fornecem o acesso a dados.
• ActionErrors – Controla as saídas de erros.

41. 41
Figura 10: Representação Fluxo do Struts. (HUSTED et al., 2004)
A Figura 10 representa o funcionamento geral do Struts. As solicitações das páginas
HTML ou JSP são enviadas para o Action Servlet, onde é processada a lógica de negócio. O
Struts fornece a classe ActionForward para armazenar o caminho de uma página sob o nome
lógico, quando tiver completado a lógica de negócio, o objeto Action selecionará e retornará
um objeto ActionForward para o Servlet*. Então o Servlet completará a resposta utilizando o
objeto ActionForward para chamar uma página e realizar a resposta.
Um objeto Action pode validar a entrada e acessar a camada de negócios para
recuperar as informações nos serviços de dados, mas o mesmo precisa saber os valores
enviado a ele, assim o ActionServlet encapsula os valores de entrada em um JavaBean. O
ActionServlet seleciona o ActionForm que será enviado a solicitação. Os detalhes de caminhos
estão associados a um objeto ActionMapping, que o Servlet pode recuperar quando
necessário. O mapeamento informa ao Servlet quais Actions, ActionForms e ActionForwards
usar. Todos os detalhes dos Actions, ActionForms, ActionForwards, ActionMappings e
*Um Servlet é uma classe Java que implementa uma interface específica, com um método que é
chamado quando uma requisição é recebida. As servlets são executadas por um servidor da Web
compatível com Java.

42. 42
algumas outras coisas são declarados em um arquivo de configuração XML. Esse arquivo
serve para configurar o funcionamento aplicação no Struts.
4.3.1 STRUTS E PADRÕES DE PROJETO
Alguns padrões de software são incorporados no Struts, a seguir cada padrão e como
ele interage com o Struts (HUSTED et al., 2004):
• O Padrão Service to Worker é como um “super” padrão que
incorpora o Front Controller e View Helper.
• O Padrão Front Controller recebe as ações do usuário. É
implementado pelo ActionServlet, que concentra um ponto de acesso
para o tratamento da solicitação, onde pode ser implementado: o
serviço do sistema; o sistema de segurança; a recuperação de
conteúdo; o gerenciamento da exibição; e a navegação.
• O padrão View Helper é implementado para que quando os dados
sofrem alterações de estado as telas gráficas sejam atualizadas. Os
dados fornecidos por um JavaBean são fornecidos para o framework e
exibidos utilizando padrão View Helper.
• Os padrões Command/Command and Controller são implementados
no Struts como um componente emissor (classe Action), o qual cuida
da recuperação de conteúdo e gerenciamento de exibição. O
ActionServlet através da chamada do método Action transmite detalhes
de uma solicitação onde será incorporada uma resposta. As classes
Struts Action gerenciam a exibição.

43. 43
• O Padrão Service Locator é responsável pelo serviço de persistência
de dados, é implementado sobre as classes do pacote
java.sql.DataSource, que fornece o acesso ao armazenamento
adjacente.
• O padrão Singleton é implementado em diversas classes, para
garantir a instância de apenas um objeto. Um exemplo é para lidar
com qualquer quantidade de solicitações, os Servlets geram apenas um
objeto que cuida de todas as solicitações.
• O padrão Session Facade é para implementação de interação entre o
modelo e aplicação, onde pode conter muitos detalhes. O Struts
encapsula estes detalhes em suas classes Action. As classes Action
abstraem a interação do objeto de negócios subjacente e fornece
serviço que exibe apenas as interfaces requeridas. Ainda é
implementado o padrão Session Facade dentro do Struts para
componentes de recursos de mensagens. Os componentes solicitam
uma mensagem e o Struts fornece-a para o local do usuário.
• Padrão Composite View é uma tela de apresentação que pode ser
construída por vários elementos de exibição. Como por exemplo, em
varias telas para fins diferentes pode ser incorporado um mesmo
menu.

44. 44
4.4 JUNIT
JUnit é um framework de código aberto para testes automatizados. É um exemplo da
arquitetura XUnit para framework de teste de unidade. A arquitetura inicial, originalmente foi
desenvolvida por Kent Beck e Erich Gamma. Os testes automatizados para JUnit são classes
Java, cada classe é conhecida também como unidades unidade de teste. Na versão 3.4 é
utilizada a reflexão* para executar as classes de teste. (JUNIT, 2009)
As classes são orientadas ao objetos de um ambiente, sendo que descreve esse
ambiente a fim de poder testar o código fonte que vai sendo produzido. Nos métodos dos
testes podem ser utilizados as anotações:
•@Before é uma anotação utilizada em métodos que devem serem executados
antes, como para carregar as pré-condições ou criar objetos.
•@Test é uma anotação utilizada em métodos cujo os fins sejam testar valores de
objetos, dentro destes métodos são utilizadas normalmente asserções.
•@After é uma anotação utilizada em métodos executados no final, como para
liberar recursos.
Quando uma classe de Teste é executada, os métodos anotados com @Test podem
apresentar dois estados, um simboliza que as asserções foram garantidas (verde) e outro falha
(vermelho). Os métodos assinados com @Before são combinados entre si, e executados um a
um desta combinação com os métodos assinados com @Test.
Um caso de uso desse framework é obter qualquer número de 1(um) a 5(cinco) por
* Reflexão : é o mecanismo de conseguir dados de um programa em tempo de execução.

45. 45
extenso. Inicialmente escreve-se os testes tentando descrever o ambiente. Após é executado os
testes, onde vai sendo produzido o código da aplicação até as asserções serem garantidas. Um
exemplo de código de teste para esse caso de uso é descrito no Quadro 1.
Quadro 1: Exemplo de teste utilizando JUnit
1 import junit.framework.Assert;
2 import org.junit.Before;
3 import org.junit.Test;
4 public class TestarNumerosPorExtensoDe0A3 {
5 private Numero n0, n1, n2, n3;
6 @Before
7 public void criarOsNumeroDe0Até3() {
8 n0 = new Numero(0);
9 n1 = new Numero(1);
10 n2 = new Numero(2);
11 n3 = new Numero(3);
12 }
13 @Test
14 public void porExtenso0éZero() {
15 Assert.assertEquals("Zero" , n0.obterExtenso());
16 }
17 @Test
18 public void porExtenso1éUm() {
19 Assert.assertEquals("Um" , n1.obterExtenso() );
20 }
21 @Test
22 public void porExtenso2éDois() {
23 Assert.assertEquals("Dois" , n2.obterExtenso());
24 }
25 @Test
26 public void porExtenso3éTrês() {
27 Assert.assertEquals("Três", n3.obterExtenso());
28 }
29 }
Os atributos n0, n1, n2, n3 (linha 6) da classe Numero são criados inicialmente pelo
método criarOsNumeroDe0Até3 (linha 7), onde pode ser verificada a anotação @Before.
Depois de criados os objetos, então nas linhas 14 (quatorze), 18 (dezoito), 22 (vinte dois) e 26

46. 46
(vinte seis) são executados os métodos de testes, sendo anotados com @Test. Dentro destes
testes é usado o método assertEqual, da classe Assert, para comparar os valores. Em todos
esses testes é verificado o número extenso com o valor por extenso obtido de seu atributo,
como exemplo: “Zero” com o valor por extenso obtido do atributo n0 (linha 16).
4.4.1 JUNIT E PADRÕES DE PROJETOS
Nesse framework vários padrões de projeto são aplicados na sua implementação, onde
esse padrões também são relacionados. A implementação de JUnit 4.x possui diferenças com
JUnit 3.x, mas devido dificuldade de encontrar documentação para versão 4.x sobre os
padrões de projeto, será apenas apresentados alguns dos padrões de projetos encontrados para
versão 3.x. A suíte da arquitetura JUnit é representada na Figura 11.
Figura 11: Suíte da Arquitetura de JUnit (JUNIT, 2009)

47. 47
Esse framework é muito fácil de utilizar, mas sua implementação é difícil de entender,
devido a sua generalidade e padrões de projeto complexos. Alguns de seus padrões de projeto
são:
•Command - esse padrão encapsula na classe Test o método run, e é sobrescrito
nas classes TestCase e TestSuite. Independente se for um objeto do tipo TestCase
ou TestSuite pode ser executado o método run apenas conhecendo como Test.
•Template Method – O método run da classe Test, recebe como argumento um
template do tipo TestResult. Esse template encapsula parte da lógica que executa
um teste e guarda seus resultados.
•Collecting Parameter – coleta os parâmetros durante a execução do método run
de uma classe Test. Se os testes sempre funcionarem corretamente, então não teria
que escrevê-los.
•Composite – executar todos os testes um a um é trabalhoso, então JUnit
possibilita compor todos em uma suíte. Os objetos das classes TestCase e
TestSuite não precisam da distinção para executar os testes.
•Pluggable Selector – é um adaptador que permite ligar um TestCase com a API
reflexão de código, permitindo executar os métodos de teste.
•Adapter – a partir de uma sub-classe, permite executar os vários métodos testes
contidos em um TestCase, utilizando o método runTest.

48. 48
4.5 CONSIDERAÇÕES SOBRE O CAPÍTULO
Neste capítulo foram apresentados definições de frameworks afim de obter
contextualidade para a implementação do protótipo proposto. Além disso, também foram
apresentadas classificações, arquiteturas e outros conceitos visando conhecer mais sobre
frameworks para implementar um protótipo com base nos objetivos do trabalho.
Paralelamente ao estudo, também deu-se enfoque de como é utilizada a orientação a
objetos e padrões de projeto nos frameworks. Apesar de não encontrar uma receita pronta de
como construir um framework o estudo dos frameworks Struts e JUnit foi valioso. O fato dos
dois frameworks apresentados serem de código fonte aberto é como um “oásis” de exemplos.

49. 49
5 IMPLEMENTAÇÃO DO PROTÓTIPO DE FRAMEWORK
5.1 INTRODUÇÃO
O presente trabalho propõe a construção de um protótipo de framework para auxiliar
no desenvolvimento de aplicações que manipulem dados para as tecnologias J2SE e J2EE,
como por exemplo uma simples aplicação de cadastro de clientes ou os dados de um jogo de
cartas. O que pretende-se com esse protótipo é oferecer um "arcabouço" de software, onde
cada equipe de desenvolvimento define suas linhas de desenvolvimento (ferramentas,
modelos ou padrões de projeto para o desenvolvimento que a equipe utiliza ou pretende
utilizar), compatíveis com seus projetos. Após esse processo, pode-se inserir ao núcleo do
protótipo a descrição de cada aplicação que manipule dados, tornando possível assim, a
geração da aplicação.
Para implementação, foi utilizado a IDE de desenvolvimento Eclipse (a partir da
versão 3.2) para a edição de código e o framework JUnit1, na versão 3.4, juntamente com o
1 Página do projeto: http://www.junit.org/

50. 50
Eclipse. JUnit auxiliou o processo de desenvolvimento da aplicação. O kit de
desenvolvimento Sun Java(TM) Development Kit (JDK)2, na versão 6, permitiu compilar e
executar o protótipo e a IDE de desenvolvimento. Para manipulação de dados em XML é
utilizado a biblioteca JDOM3.
A implementação do protótipo, segue o conceito da programação orientada a objetos
juntamente com padrões de projeto. O protótipo não é totalmente um framework de domínio
ou um framework de aplicação (Seção 2 e 3), sendo um misto dos dois. A Figura 12 ilustra a
arquitetura do protótipo do framework proposto.
Figura 12: Arquitetura do protótipo.
O framework se classifica como White Box frameworks e Black Box frameworks,
tornando-se assim um Gray Box frameworks. O White Box frameworks é nomeado de stub e
fica localizado dentro do pacote framework. Com exceção do pacote core, todo o resto de
classes e pacotes Java faz parte da composição do stub. O stub pode ser considerado como um
2 Página do projeto: http://java.sun.com/javase/
3 Página do projeto: http://www.jdom.org/

51. 51
framework de domínio, através do qual é previsto a implementação específica por herança nos
hot-spot.
O Black Box frameworks é nomeado de core. Ele é implementado dentro do pacote
framework.core. A utilização é feita com um arquivo XML (descrição de uma aplicação),
inserido na classe Kernel, que compõe o core. Entretanto, antes faz-se necessário a
implementação concreta do domínio, nos hot-spots, do stub. A implementação concreta do
domínio pode ter como objetivo a geração de código, tendo isso como resultado, do arquivo
XML aplicado ao core.
Assim, neste capítulo, será descrito o protótipo em detalhes. As próximas seções
descrevem o framework proposto em detalhes.
5.2 STUB
O stub do framework é uma estrutura abstrata do domínio, sendo composto pelas
interfaces: Projeto, Classe, Atributo e o pacote extensão. Essas interfaces e o pacote estão
dentro de outro pacote chamado framework. As interfaces seguem o padrão de projeto
chamado façade, e possuem algumas relações entre elas.
O pacote extensão, localizado dentro do pacote framework, também faz parte do stub,
e é por meio do qual estende-se o domínio para a implementação concreta. O pacote extensão
é composto por três interfaces (ProjetoDeCamadas, ClasseDeCamadas e
AtributoDeCamadas), e por três classes abstrata (ProjetoAbs, ClasseAbs e AtributoAbs). As
classes que pertencentes ao pacote extensão seguem o padrão de projeto prototype. O objetivo
deste padrão de projetos para o protótipo de framework é deixar aberta para futuras definição

52. 52
de ferramentas, modelos, padrões de projeto, entre outros. Cada equipe então implementa essa
definição a seu gosto, e o protótipo passa a aplicar. A definição implementada é apresentada
na Figura 13. Está figura será detalhada nas próximas seções.
Façade Projeto
ProjetoDeCamadas
String pegarNome()
String pegarSArg(nome)
void desligar()
void rodar()
void adcionar(Classe)
List pegarClasses() ClasseDeCamadas
Classe pegarClasse(nome, iden)
Factory SQL pegarDDLSQL()
Method ENTIDADE pegarEntidade()
DAO pegarDAO()
Classe
Façade VISAO pegarVisao()
ProjetoAbs
String pegarNome()
List pegarAtributos()
String pegarNome()
adcionar(Atributo)
String pegarSArg(nome)
Atributo pegarAtr(nome, iden)
...
String pegarSArg(String nome)
Prototype
Façade Atributo
String pegarNome()
Prototype ClasseAbs
String pegarSArg(nome)
String pegarNome()
String pegarSArg(nome)
...
AtributoAbs
AtributoDeCamdas
String pegarNome() Prototype
String pegarSArg(nome)
Figura 13: Parte da Suíte de Classe e Padrões de Projeto do Stub

53. 53
5.2.1 A INTERFACE PROJETO
A interface Projeto é a fachada de um projeto qualquer; porém, construída
especificamente para o desenvolvimento de projetos que envolvam manipulação de dados
com as tecnologias J2SE ou J2EE.
Quadro 2: A Interface Projeto
1 public interface Projeto<XClasse extends Classe> {
2 public void desligar();
3 public void rodar() throws Exception;
4 public void adcionar(XClasse classe);
5 public List<XClasse> pegarClasses();
6 public <X extends XClasse> X pegarClasse(String nomeDaClasse,
Object... identificadores);
7 public String pegarNome();
8 public String pegarStringArgumento(String nome) throws Exception;
9 }
O código fonte da interface Projeto é apresentado no Quadro 2. O método desligar,
correspondente a linha 2 (dois), descreve a desativação de um projeto, caso esteja em
execução. O método rodar, correspondente a linha 3 (três), descreve a ativação de um
projeto. O método adicionar, correspondente a linha 4 (quatro), e tendo como argumento uma
classe com sub-tipo de Classe, é responsável pelo armazenamento do argumento no projeto.
O método pegarClasses, encontrado na linha 5 (cinco), é responsável por devolver todas as
Classes já adicionadas ao projeto. O método pegarClasse, correspondente a linha 6 (seis),
devolve uma única Classe, seguindo seu nome ou identificadores. O método pegarNome
(linha 7), devolve o nome do projeto. Finalmente, a linha 8 (oito) descreve o método
pegarStringArgumento, através do nome de um argumento, devolve o argumento. Os
argumentos são responsáveis pela parametrização do projeto.

54. 54
5.2.2 A INTERFACE CLASSE
Através da interface Classe é possível ser implementada uma pequena solução para
um projeto. Pensando-se em algum projeto de banco de dados, a Classe é equivalente a uma
tabela; mas, no contexto do protótipo, é a divisão do pequeno domínio que agrupado compõe
um Projeto. O objetivo é que uma implementação específica desta interface possa ser
utilizada muitas vezes, reutilizando sua solução.
Quadro 3: A Interface Classe
1 public interface Classe<XAtributo extends Atributo> {
2 public String pegarNome();
3 public List<XAtributo> pegarAtributos();
4 public void adicionar(XAtributo atributo);
5 public XAtributo pegarAtributo(String nomeDoAtributo,
Object... identificadores);
6 public String pegarStringArgumento(String nome) throws Exception;
7 }
O código fonte da interface Classe é apresentada no Quadro 3. O método
pegarNome, correspondente à linha 2 (dois) é responsável pela recuperação do nome de uma
Classe. O método pegarAtributos, correspondente à linha 3 (três), devolve a lista de
Atributos de uma Classe. O método adicionar, correspondente a linha 4 (quatro), recebe e
guarda Atributo para a Classe. O método pegarAtributo, correspondente a linha 5 (cinco),
deve retorna um Atributo da Classe seguindo os parâmetros, nome do atributo ou
identificadores. O método pegarStringArgumento, correspondente a linha 6 (seis), retorna
através do nome de um argumento, o seu valor como uma String, útil para a configuração da
classe.

55. 55
5.2.3 A INTERFACE ATRIBUTO
A interface Atributo, tem como objetivo compor uma Classe, essa interface busca
determinar pequenos modelos, padrões, restritos principalmente ao Atributo e a Classe. Cada
implementação desta interface é um tipo de Atributo. Por exemplo, pode-se criar um atributo
para manipular String.
Quadro 4: A Interface Atributo
1 public interface Atributo {
2 public String pegarNome();
3 public String pegarStringArgumento(String nome) throws Exception;
4 }
A interface Atributo é apresentada no Quadro 4. O método pegarNome,
correspondente a linha 2 (dois), retorna apenas o nome deste atributo. O método
pegarStringArgumento, correspondente a linha 3 (três), retorna através do nome de um
argumento, o seu valor como uma String, útil para a configuração do atributo. Também em
contextos gerais, pode ser aplicado a uma configuração de Atributo na Classe para determinar
modelos ou padrões a serem adotados, afim de determinar uma característica na Classe, ou da
Classe no Projeto através do Atributo.
5.2.4 O PACOTE EXTENSÃO
O pacote framework.extensao é determinado como parte do domínio abstrato de uma
aplicação J2SE e J2EE. É através dele que o protótipo de framework pode se estendido. O

56. 56
domínio abstrato é apenas uma determinação e está relacionado com uma estrutura em
camadas. O pacote é composto por: (i) um pacote chamado camadas; (ii) 3 (três) interfaces e
(iii) 3 (três) classes abstratas.
i) PACOTES CAMADAS
O pacote camadas contém as definições abstratas das camadas de uma Classe, Projeto
e Atributo. Mas somente na Classe é definido camadas, sendo que o Atributo e o Projeto
somente seguem a lógica definidas nas camadas da Classe. O tipo destas camadas é
estabelecido no pacote framework.extensao.camadas e é feito através de interfaces. Para
cada camada é apenas estabelecido o nome da interface como tipo. Espera-se que quando o
desenvolvedor faça sua aplicação, ele determine o domínio concreto de seu projeto
implementando as camadas. As interfaces que determinam cada camada são:
•SQL: é a camada responsável pela definição e manipulação dos
dados;
•Entidade: é a camada que define as classes ou objetos relacionados
com a definição de SQL;
•DAO: é a camada responsável para mapear as Entidades e SQL, onde
será definida as operações de inserção, atualização, exclusão e seleção
das entidades na unidade de persistência;
•Visão: é a camada que define telas de consulta e manipulação dos
dados relacionados com o modelo de entidades.

57. 57
ii) TRÊS INTERFACES
As três interfaces do pacote framework.extensao.camadas são:
AtributoDeCamadas; ClasseDeCamadas; e ProjetoDeCamadas. Essas três interfaces são
sub-classes das interfaces do pacote framework, sendo as interfaces respectivas, Atributo,
Classe e Projeto.
As interfaces AtributoDeCamada e ProjetoDeCamadas não possuem métodos ou
atributos adicionais. Porém, na interface ClasseDeCamadas são adicionados métodos para
criação abstrata das camadas - SQL, Entidade, DAO, Visão, conforme fragmento de código
apresentado no Quadro 5.
Quadro 5: Métodos da interface ClasseDeCamadas
1 /*...*/
2 abstract public XSQL pegarDDLSQL() throws Exception;
3 abstract public XENTIDADE pegarEntidade() throws Exception;
4 abstract public XDAO pegarDAO() throws Exception;
5 abstract public XVISAO pegarVisao() throws Exception;
6 /*...*/
Os quatro métodos que criam as camadas para o framework são ainda abstratos e
apenas serão determinadas suas lógicas quando o desenvolvedor implementar o domínio
concreto. O método pegarSQL, encontrado na linha 2 (dois), retorna um objeto, onde poderá
conter uma String de definição SQL de uma tabela ou possíveis implementações desejadas
pelo desenvolvedor. O método pegarEntidade, encontrado na linha 3 (três), retorna um
objeto contendo a estrutura da classe para guardar os dados temporariamente. O método
pegarDAO, encontrado na linha 4 (quatro), retorna um objeto responsável por a manipulação
dos dados entre as entidades temporária e a unidade de persistência. O método pegarVisao,
encontrado na linha 5 (cinco), retorna um objeto que contêm principalmente os componentes

58. 58
gráficos para interação e manipulação dos dados.
iii) TRÊS CLASSES ABSTRATAS PARA EXTENSÃO
As três classes abstratas do pacote framework.extensão são os hot spots que devem
ser estendidos pelos desenvolvedores para implementação do domínio concreto, sendo elas:
ProjetoAbs; ClasseAbs; AtributoAbs. Essas três classes implementam as interfaces
ProjetoDeCamadas, ClasseDeCamadas e AtributoDeCamadas respectivamente. Contudo,
nem todos os métodos das interfaces são implementados pelas três classes, pois são classes
abstratas e formam apenas um protótipo.
Quadro 6: Fragmento da Classe ProjetoAbs.
1 /*...*/
2 abstract class ProjetoAbs<XClasse extends ClasseDeCamadas<?, ?, ?, ?,? >>
implements Projeto<XClasse>, ProjetoDeCamadas<XClasse>{
3 ProjetoAbs(String nome, HashMap<String, String> args) {
4 this.nome = nome;
5 this.args = args;
6 }
7 public XClasse pegarClasse(String nomeDaClasse, Object...
identificadores) {
8 return classes.get(nomeDaClasse);
9 }
10 public List<XClasse> pegarClasses() {
11 return new ArrayList<XClasse>(classes.values());
12 }
13 public void adcionar(XClasse classe) {
14 classes.put(classe.pegarNome(), classe);
15 }
16 public String pegarNome() {
17 return this.nome;

59. 59
18 }
19 public String pegarStringArgumento(String nome) throws Exception {
20 String valor = args.get(nome);
21 return valor == null ? lancrarErro() : valor;
22 }
23 /*...*/
24 }
O código do Quadro 6 é um fragmento da classe abstrata ProjetoAbs. Essa classe
herda as interfaces Projeto e ProjetoDeCamadas(linha 2), os templates são definidos para
manipulação dos tipos das Classes. O construtor, localizado na linha 3(três), tem como
argumentos o nome do projeto e um mapa de configurações. São implementados os métodos
pegarClasse, pegarClasses, adicionar, pegarNome e pegarStringArgumento localizados
respectivamente nas linhas 7(sete), 10(dez), 13(treze), 16(dezesseis) e 19(dezenove). Esses
métodos pertencem à interface Projeto e os objetivos são apresentados na Seção 2.1 deste
capítulo. Já os outros métodos não implementados que pertencem à interface Projeto ou
ProjetoDeCamadas devem serem implementados nas sub-classes desta classe.
Quadro 7: Fragmento de código da Classe ClasseAbs.
1 /*...*/
2 abstract class ClasseAbs<XVISAO extends VISAO, XDAO extends DAO, XENTIDADE
extends ENTIDADE, XSQL extends SQL, XAtributo extends AtributoDeCamadas>
implements Classe<XAtributo>, ClasseDeCamadas<XVISAO, XDAO, XENTIDADE, XSQL,
XAtributo> {
3 ClasseAbs(String nome, HashMap<String, String> argumentos) {
4 this.nome = nome;
5 this.argumentos = argumentos;
6 }
7 public String pegarNome() {

60. 60
8 return nome;
9 }
10 public List<XAtributo> pegarAtributos() {
11 return new ArrayList<XAtributo>(atributos.values());
12 }
13 public XAtributo pegarAtributo(String nomeDoAtributo,
14 Object... identificadores) {
15 return atributos.get(nomeDoAtributo);
16 }
17 public void adcionar(XAtributo umAtributo) {
18 atributos.put(umAtributo.pegarNome(), umAtributo);
19 }
20 public String pegarStringArgumento(String nome) throws Exception {
21 String valor = argumentos.get(nome);
22 return valor == null ? lancrarErro() : valor;
23 }
24 /*...*/
25 }
O código fonte apresentado no Quadro 7 é um fragmento da classe abstrata
ClasseAbs. Essa classe herda as interfaces Classe e ClasseDeCamadas (linha 2), onde são
definidos os templates, dos tipos das camadas e do tipo de Atributo. O construtor encontrado
na linha 2 (dois), recebe como parâmetros o nome da classe e um mapa de argumentos de
configurações. Nesta classe são implementados os métodos pegarNome, pegarAtributos,
pegarAtributo, adcionar e pegarStringArgumentos encontrados respectivamente nas
linhas 7 (sete), 10 (dez), 13 (treze), 17 (dezessete) e 20 (vinte). Esses métodos pertencem a
interface Classe descrita na Seção 2.2 deste capítulo. A interface ClasseDeCamadas
apresenta os métodos responsáveis por cada camada, os quais devem ser implementados por
suas sub-classes.

61. 61
Quadro 8: Fragmento de Código da Classe AtributoAbs.
1 /*...*/
2 abstract class AtributoAbs implements Atributo, AtributoDeCamadas {
3 AtributoAbs(String nome, HashMap<String, String> args) {
4 this.nome = nome;
5 this.argumentos = args;
6 }
7 public String pegarNome() {
8 return this.nome;
9 }
11 public String pegarStringArgumento(String nome) throws Exception {
12 String valor = argumentos.get(nome);
13 return valor == null ? lancrarErro() : valor;
15 }
16 /*...*/
17 }
O código fonte apresentado no Quadro 8 é um fragmento da classe abstrata
AtributoAbs. Essa classe herda as interfaces Atributo e AtributoDeCamadas (linha 2). O
construtor encontrado na linha 3 (três), recebe como parâmetros o nome do atributo e um
mapa de argumentos de configurações. Os métodos implementados, pegarNome (linha 7) e
pegarStringArgumentos (linha 11), pertencem a interface Atributo e são apresentados na
Seção 2.3 deste capítulo. Embora não existam mais métodos a ser implementados das
interfaces que essa classe herda, é necessário que quando for implementado um Atributo
concreto, sejam criados métodos que apliquem a lógica adequada para funcionar em
conformidade com a Classe.

62. 62
5.3 CORE DO PROTÓTIPO
O Core é composto principalmente por classes concretas. Seu objetivo é a partir de um
documento XML de definição produzir uma aplicação que manipule dados. Além disso, fazer
a instanciação das classes do domínio concreto que o desenvolvedor estabelecer, gerando
assim uma aplicação ou parte dela também são objetivos do core do protótipo.
5.3.1 DOCUMENTO XML PARA DEFINIÇÃO DE APLICAÇÕES
A definição de uma aplicação para manipulação de dados é feita através de um
documento XML. Esse documento possui uma estrutura concreta definida pelos
elementos(tags), projeto, classe e atributo. O elemento projeto pode conter vários elementos
classe e cada classe pode conter vários elementos atributo. Ainda, dentro desses elementos,
existem o elemento argumentos. Essa estrutura de projeto, classe, atributo e argumentos
deve ser mantida para qualquer descrição de aplicação usada no protótipo, mas podem ser
inseridos novos elementos em cada um desse elementos descritos. A estrutura de um
documento de definição pode ser observada no Quadro 9.
Quadro 9: Estrutura de um Documento XML de Descrição de Projetos
1 <projeto nome="UmNomeParaOProjeto" tipo="ProjetoXAdaptadorEstendido">
2 <argumentos>
3 <argumento nome="implementacao" valor="meus.padroes.implementacao"
/>
4 </argumentos>
5 <classe nome="UmaClasse" tipo="ClasseAdaptadorEstendidaParaProjetosX">