UNISALESIANO

Centro Universitário Católico Salesiano Auxilium

Curso de Tecnologia em Sistemas para Internet

Bruno de Souza Polone

José Roberto Alves de Souza
Luiz Gustavo dos Santos Real

USO DO JSF NA CONSTRUÇÃO DE SOFTWARE

ESTUDO DE CASO – UM SISTEMA PARA
CONSULTA DE NOTAS

LINS – SP
2010
 BRUNO DE SOUZA POLONE

JOSÉ ROBERTO ALVES DE SOUZA

LUIZ GUSTAVO DOS SANTOS REAL

USO DO JSF NA CONSTRUÇÃO DE SOFTWARE

ESTUDO DE CASO – UM SISTEMA PARA CONSULTA DE NOTAS

Trabalho de Conclusão de Curso

apresentado à Banca Examinadora do
Centro Universitário Católico Salesiano
Auxilium, curso de Tecnologia em
Sistemas para Internet, sob a orientação
do Prof. M.Sc. Anderson Pazin.

LINS – SP

2010
 Polone, Bruno de Souza; Souza, José Roberto Alves de; Real, Luiz
P838u
Gustavo dos Santos
Uso do JSF na construção de software: estudo de caso – um
sistema para consulta de notas / Bruno de Souza Polone; José
Roberto Alves de Souza; Luiz Gustavo dos Santos Real. – – Lins,
2010.
62p. il. 31cm.

Monografia apresentada ao Centro Universitário Católico

Salesiano Auxilium – UNISALESIANO, Lins-SP, para graduação em
Tecnologia em Sistemas para Internet, 2010.
Orientador: Anderson Pazin

1. Java. 2. Frameworks. 3. JSF. I - Título

CDU 004
 BRUNO DE SOUZA POLONE

JOSÉ ROBERTO ALVES DE SOUZA

LUIZ GUSTAVO DOS SANTOS REAL

USO DO JSF NA CONSTRUÇÃO DE SOFTWARE

ESTUDO DE CASO – UM SISTEMA PARA CONSULTA DE NOTAS

Monografia apresentada ao Centro Universitário Católico Salesiano Auxilium,

para obtenção do título de Tecnólogo em Sistemas para Internet.

Aprovada em: _____/______/_____

Banca Examinadora:

Prof(a) Orientador(a): ____________________________________________

Titulação: ______________________________________________________
______________________________________________________________
Assinatura: ________________________________

1º Prof(a): _____________________________________________________
Titulação: ______________________________________________________
______________________________________________________________
Assinatura: ________________________________

2º Prof(a): _____________________________________________________
Titulação: ______________________________________________________
______________________________________________________________
Assinatura: ________________________________
 DEDICATÓRIA

À minha família, meu avô Anésio e à Mari que sempre me

apoiaram em minhas decisões e sempre deram forças para que
eu pudesse concluir mais esta etapa em minha vida.

Bruno

À minha família e meu amigo Pablo, pelo apoio que me deram

durante a elaboração do trabalho. À minha namorada, pela
compreensão durante a minha ausência.

José Roberto

A Deus, pelo dom da vida. Aos professores, pelas idéias,

correções e disponibilidade. E ao Rá, pelo apoio e amizade, sem
os quais não teria chegado aqui.

Luiz Gustavo
 AGRADECIMENTOS

Agradeço a Deus pela oportunidade de ser privilegiado em poder

cursar um ensino de nível superior, a meus pais e meu avô
Anésio pelo apoio e ajuda financeira.
Agradeço ao professor Andy por toda orientação do trabalho e
aos meus companheiros que unidos conseguimos concluir esta
etapa.

Bruno

Agradeço a Deus, pelo dom da vida e sabedoria dada aos

homens.
Agradeço a todas as pessoas envolvidas diretamente ou
indiretamente com o trabalho, principalmente às pessoas que me
deram um voto de confiança e acreditaram que eu teria potencial
para realizar meus projetos.
Agradeço a todos os meus amigos, principalmente ao Pablo e ao
Everton, pela amizade sincera, pois acredito que um homem só é
feliz e alcança seus objetivos quando tem bons amigos, como
eles.
Agradeço também às pessoas que desejaram meu fracasso, pois
é esse tipo de pessoa que faz com que os homens sejam mais
perseverantes em alcançar seus objetivos. Hoje olho em volta e
vejo que isso também foi bom para o meu amadurecimento e
minha perseverança em realizar algo de bom.
José Roberto

Agradeço a todos que me apoiaram durante a elaboração deste

trabalho, aos amigos e, principalmente, à minha namorada, por
entender a minha ausência em muitas situações.

Agradeço ao Andy, ótimo professor e orientador, que sempre

esteve presente dando sugestões para a melhoria do trabalho.

Agradeço também ao Eduardo, meu mentor.

Luiz Gustavo
 RESUMO

O objetivo deste trabalho é contribuir para o aumento da produtividade

na construção de software, considerando para tal finalidade a utilização de
tecnologias que tornem mais fácil e mais rápido construir, manter e atualizar
sistemas e aplicações voltadas à web. Para tanto, é feito um estudo da
utilização de frameworks, comparando o desenvolvimento de uma mesma
aplicação - um sistema web de consulta de notas - de duas formas distintas:
inicialmente utilizando a linguagem Java sem o uso de frameworks e,
posteriormente, utilizando o framework JavaServer Faces. A linguagem Java
oferece vários tipos de frameworks para o desenvolvimento de aplicações web
com fins específicos, como o JSF, que é baseado no padrão MVC - model -
view - controller - e possui recursos sofisticados focados no desenvolvimento
para web. JSF foi escolhido para este trabalho por ser um projeto da Sun e
pela sua atuação no mercado. Com o aumento da complexidade no processo
de desenvolvimento de softwares, muitos desenvolvedores buscam utilizar os
frameworks, que são constantemente desenvolvidos e pesquisados, pois sua
implementação permite maior reutilização de código, tornando o
desenvolvimento mais produtivo. Nesse contexto, a execução deste trabalho
visa buscar, na prática, comprovar essa afirmação, apresentando as facilidades
e dificuldades encontradas no desenvolvimento da aplicação, a partir da
análise das duas implementações. Como resultado, espera-se contribuir com
os profissionais e estudantes de tecnologia, envolvidos com a construção de
software, dando subsídio para que outras pessoas possam utilizar essas
ferramentas para facilitar seus projetos, tendo em vista o ganho em
produtividade.

Palavras-chave: Java. Frameworks. JSF.

 ABSTRACT

The objective of this work is contribute to the increase of the productivity

in the software build, considering for such purpose the use of technologies
which become easier and faster to build, keeping and updating systems and
applications turned to the web. Therefore, is done a study of the utilization of
frameworks, comparing the development of the same application - a web
system of consultation notes - in two distinct ways: initially using the Java
language without the use of frameworks and, posteriorly, using the JavaServer
Faces framework. The Java language offers several types of frameworks to the
development of web applications with specifics purposes, as the JSF, that is
based in the MVC standard - model - view - controller - and has sophisticated
resources focused in the development to web. JSF was chosen to this work by
being a Sun’s project and by its performance in the market. With the increasing
complexity in the process of software development, many developers seek to
use frameworks, which are constantly developed and researched, because their
implementation allows for greater reuse of code, making the development more
productive. In this context, the execution this work aims to seek, in the practice,
proving this statement, presenting the facilities and difficulties found in the
application development, from the analysis of the two implementations. As a
result, it is expected to contribute with the professionals and students of
technology involved with the software build, giving subsidy wherefore other
people can use these tools to facilitate their projects, having in mind the gain in
productivity.

Keywords: Java. Frameworks. JSF.

 LISTA DE FIGURAS

Figura 1. Desenvolvimento com: (a) POO e (b) Framework .......................... 20

Figura 2. Ciclo de vida das requisições JSF .................................................. 24
Figura 3. Modelo tradicional e modelo utilizando Ajax. .................................. 26
Figura 4. Diagrama de Caso de Uso - Logar ................................................. 30
Figura 5. Diagrama de Caso de Uso - Atualizar Senha ................................. 31
Figura 6. Diagrama de Caso de Uso - Gerar Boletim .................................... 31
Figura 7. Diagrama de Caso de Uso - Exibir Faltas....................................... 32
Figura 8. Diagrama de Classes e Objetos ..................................................... 32
Figura 9. Diagrama de Sequências - Logar ................................................... 35
Figura 10. Diagrama de Sequências - Atualizar Senha ................................. 35
Figura 11. Diagrama de Sequências - Gerar Boletim .................................... 36
Figura 12. Diagrama de Sequências - Exibir Faltas....................................... 36
Figura 13. Tela de login ................................................................................. 37
Figura 14. Tela de login apresentando nome do aluno.................................. 37
Figura 15. Tela de login apresentando “RA inválido”..................................... 38
Figura 16. Tela de atualização de senha ....................................................... 38
Figura 17. Tela de atualização de senha com mensagem de erro ................ 39
Figura 18. Tela com a lista de boletins .......................................................... 40
Figura 19. Tela com as informações do boletim escolhido ............................ 40
Figura 20. Tela de informações sobre faltas recebidas ................................. 41
Figura 21. Associação de um componente JSF a um objeto Java ................ 42
Figura 22. Representação do arquivo faces-config.xml ................................. 43
Figura 23. Tela de boletins em JSF ............................................................... 44
Figura 24. Trecho de código Java ................................................................. 45
Figura 25. Tela de faltas em JSF................................................................... 45
Figura 26. Comando de recuperação de dados sem o uso de JSF............... 46
Figura 27. Mapeamento da classe Java no arquivo faces-config.xml............ 47
Figura 28. Associação dos atributos utilizando JSF ...................................... 47
Figura 29. Baixando o JSF ............................................................................ 56
Figura 30. Baixando o JSTL .......................................................................... 56
Figura 31. Criando um projeto web no Eclipse .............................................. 57
Figura 32. Definindo o nome do projeto......................................................... 57
Figura 33. Localização do arquivo web.xml ................................................... 58
Figura 34. Trecho do arquivo web.xml........................................................... 58
Figura 35. Criando um arquivo XML .............................................................. 59
Figura 36. Definindo o nome do arquivo XML................................................ 59
Figura 37. Arquivo faces-config.xml............................................................... 60
Figura 38. Arquivos .jar necessários do pacote JSF...................................... 60
Figura 39. Arquivos inseridos na pasta lib ..................................................... 60
Figura 40. Criando um arquivo JSP ............................................................... 61
Figura 41. Definindo o nome do arquivo JSP ................................................ 61
Figura 42. Página JSP para testar a configuração do JSF ............................ 62

LISTA DE QUADROS

Quadro 1. Lista de Casos de Uso.................................................................. 30

Quadro 2. Tabela Boletim .............................................................................. 33
Quadro 3. Tabela Boletim - outras regras...................................................... 33
Quadro 4. Tabela Aluno................................................................................. 33
Quadro 5. Tabela Disciplina........................................................................... 34
Quadro 6. Tabela Curso ................................................................................ 34
Quadro 7. Tabela Faltas ................................................................................ 34

LISTA DE SIGLAS E ABREVIATURAS

AJAX: Asynchronous JavaScript and XML

API: Application Programming Interface
CGI: Common Gateway Interface
CPU: Central Processing Unit
DAO: Data Access Object
ESPN: Entertainment and Sports Programming Network
FK: Foreign Key
HTML: Hypertext Markup Language
HTTP: Hypertext Transfer Protocol
IBM: International Business Machines
IDE: Integrated Development Environment
IP: Internet Protocol
JEE: Java Enterprise Edition
JME: Java Micro Edition
JSE: Java Standard Edition
JSF: JavaServer Faces
JSP: JavaServer Pages
JSR: Java Specification Requests
JSTL: JavaServer Pages Standard Tag Library
JVM: Java Virtual Machine
MVC: Model-View-Controller
NASA: National Aeronautics and Space Administration
PDA: Personal Digital Assistant
PHP: Hypertext Preprocessor
PK: Primary Key
POO: Programação Orientada a Objetos
RA: Registro Acadêmico
SOA: Service-Oriented Architecture
TCP: Transmission Control Protocol
URL: Uniform Resource Locator
WWW: World Wide Web
XML: Extensible Markup Language
 SUMÁRIO

INTRODUÇÃO ................................................................................................. 13

1 FUNDAMENTOS CONCEITUAIS .............................................................. 15

1.1 JAVA .......................................................................................................... 15

1.1.1 VERSÕES................................................................................................ 16
1.1.2 JAVA NA WEB .......................................................................................... 16
1.1.3 SERVLETS .............................................................................................. 17
1.1.4 JSP ....................................................................................................... 18
1.2 FRAMEWORKS............................................................................................. 19
1.2.1 CLASSIFICAÇÃO DE FRAMEWORKS ............................................................ 21
1.3 JSF ........................................................................................................... 22
1.3.1 CICLO DE VIDA DAS APLICAÇÕES JSF........................................................ 23
1.3.2 RICHFACES ............................................................................................ 25
1.4 AJAX .......................................................................................................... 25
1.4.1 COMO O AJAX TRABALHA ......................................................................... 26

2 LEVANTAMENTO DE REQUISITOS ......................................................... 28

2.1 DOCUMENTOS DE REQUISITOS ..................................................................... 28

A - VISÃO GERAL DO SISTEMA.................................................................... 28

B - REQUISITOS FUNCIONAIS ...................................................................... 28

B1 - LANÇAMENTOS DIVERSOS ............................................................................ 28

B2 - RELATÓRIOS E CONSULTAS .......................................................................... 28

C - REQUISITOS NÃO FUNCIONAIS ............................................................. 29

C1 - EFICIÊNCIA ................................................................................................. 29
C2 - PORTABILIDADE .......................................................................................... 29
3 ANÁLISE ORIENTADA A OBJETOS ........................................................ 30

3.1 LISTA DE CASOS DE USO ............................................................................. 30

3.2 DIAGRAMA DE CASOS DE USO ...................................................................... 30
3.2.1 LOGAR ................................................................................................... 30
3.2.2 ATUALIZAR SENHA ................................................................................... 31
3.2.3 GERAR BOLETIM ..................................................................................... 31
3.2.4 EXIBIR FALTAS ........................................................................................ 32
3.3 DIAGRAMA DE CLASSES ............................................................................... 32

4 PROJETO DE BANCO DE DADOS........................................................... 33

4.1 TABELAS .................................................................................................... 33

4.1.1 BOLETIM ................................................................................................. 33
4.1.2 ALUNO ................................................................................................... 33
4.1.3 DISCIPLINA ............................................................................................. 34
4.1.4 CURSO ................................................................................................... 34
4.1.5 FALTAS................................................................................................... 34

5 PROJETO ORIENTADO A OBJETOS....................................................... 35

5.1 DIAGRAMAS DE SEQUÊNCIAS........................................................................ 35

5.1.1 LOGAR ................................................................................................... 35
5.1.2 ATUALIZAR SENHA ................................................................................... 35
5.1.3 GERAR BOLETIM ..................................................................................... 36
5.1.4 EXIBIR FALTAS ........................................................................................ 36

6 IMPLEMENTAÇÃO ORIENTADA A OBJETOS ........................................ 37

6.1 LAYOUT DE TELAS – IMPLEMENTAÇÃO SEM USO DE FRAMEWORKS ................... 37

6.2 LAYOUT DE TELAS – IMPLEMENTAÇÃO UTILIZANDO O FRAMEWORK JSF ........... 41
6.3 COMPARAÇÕES SOBRE O DESENVOLVIMENTO ................................................ 46

CONCLUSÃO .................................................................................................. 48
REFERÊNCIAS................................................................................................ 50

GLOSSÁRIO.................................................................................................... 53

APÊNDICES .................................................................................................... 55
 13

INTRODUÇÃO

O software tornou-se o elemento chave na evolução de sistemas e

produtos baseados em computador, e uma das tecnologias mais importantes
de todo mundo (PRESSMAN, 2006).
À medida que a importância do software cresceu, a comunidade de
programadores tem continuamente tentado desenvolver tecnologias que
tornem mais fácil, mais rápido e menos dispendioso construir e manter
programas de computador de alta qualidade (PRESSMAN, 2006). Uma dessas
alternativas é fazer uso de framework. A partir do conceito de reuso de código,
os frameworks estão sendo desenvolvidos e pesquisados (ASSIS, 2003).
Por definição: “Framework [...] é uma aplicação semi-completa e
reutilizável que, quando especializada, produz aplicações personalizadas”
(SILVA; MOREIRA, 2004, p. 3). Basicamente, proporciona a reutilização de
partes ou todo um sistema e o desenvolvimento de componentes de software
que podem ser utilizados futuramente (CAVALHEIRO, 2007).
A linguagem Java oferece vários tipos de frameworks para
desenvolvimento web com fins específicos, tais como:
a) Struts, que permite que aplicativos web escritos em Java
segmentem códigos (em vez de escrever código HTML em
servlets ou código Java em JavaServer Pages - JSP) e gerenciem
a reutilização e manutenção de código existente (ROUGHLEY,
2008);
b) JavaServer Faces (JSF), que herda das tecnologias JSP e
servlets e estende seus conceitos com um ciclo de vida e um
conjunto de componentes e recursos sofisticados e focados no
desenvolvimento para web (GOMES, 2008);
c) Mentawai, framework brasileiro lançado em 2005 que tem como
principal característica a não utilização de Extensible Markup
Language (XML) e annotations para as configurações (actions,
filtros, validação, listas, pool de conexões, etc.), e sim a utilização
exclusiva de configuração programática - nesse caso, em Java
(MENTAWAI, 2007).
Este trabalho tem por objetivo desenvolver uma aplicação de duas
 14

formas distintas: inicialmente em linguagem Java sem o uso de frameworks e,

posteriormente, utilizando o framework JSF, para que após a análise das duas
implementações seja possível obter informações sobre as facilidades e
dificuldades encontradas no desenvolvimento de cada uma. Para isso é
implementado um sistema que consiste em uma aplicação de consulta de
notas dos alunos pela internet, um boletim virtual. JSF foi escolhido para este
trabalho dentre os frameworks web Java disponíveis, por ser um projeto da
Sun, empresa criadora da tecnologia Java e, também, pela sua atuação no
mercado.
O uso de ferramentas que auxiliam o processo de desenvolvimento,
como os frameworks, permite que soluções previamente testadas sejam
reutilizadas, tornando o sistema mais flexível e de fácil manutenção
(CATARINO; PRADO, 2001). Este trabalho visa comprovar, na prática, essa
afirmação e dar subsídio para que outras pessoas possam utilizar essas
ferramentas para facilitar seus projetos.
 15

1 FUNDAMENTOS CONCEITUAIS

1.1 Java

Java é uma linguagem de programação orientada a objetos (POO) que

possui recursos para desenvolvimento web. Foi anunciada, em maio de 1995,
pela empresa Sun Microsystems. O que chamou atenção nessa linguagem foi
o fato dela ser portável para outros dispositivos. Além disso, sua fama cresceu
rapidamente porque a web estava em ascensão, e Java possibilitava fazer
diversas coisas, como animações, que até então não eram possíveis em
páginas existentes na World Wide Web (WWW) (GONÇALVES, 2007).
A linguagem Java evoluiu e muitas implementações foram criadas com o
intuito de abranger as mudanças ocorridas no mundo. Hoje é possível utilizá-la
em aplicativos desktop, páginas para a internet ou até mesmo em aplicativos
pequenos para celulares. Essa tecnologia é empregada por grandes empresas
que desejam trafegar uma grande quantidade de dados e necessitam de
segurança, estabilidade e portabilidade entre outras empresas. Lugares como a
NASA, IBM, ESPN entre outros são apenas exemplos da confiabilidade que a
linguagem Java demonstra em seus utilizadores (GONÇALVES, 2007).
Os programas em Java são desenvolvidos em pequenas partes
chamadas de classes. As classes incluem métodos, que realizam tarefas. Os
programadores podem criar quantas classes precisarem para formar
programas. Para auxiliar nesse processo, Java fornece uma rica coleção de
classes, uma biblioteca de classes Java, que também é conhecida como Java
API (Application Programming Interface). Portanto, é possível programar
classes próprias e também utilizar classes prontas (DEITEL; DEITEL, 2005).
Os programas desenvolvidos com a linguagem Java são portáveis, pois
o compilador Java converte seu código-fonte (que representa as tarefas a
serem realizadas durante a execução do programa) em bytecodes, que são
executados pela Máquina Virtual Java (JVM, na sigla em inglês - Java Virtual
Machine). Os bytecodes são instruções independentes de plataforma, ou seja,
esses programas podem ser executados em qualquer plataforma que contenha
uma JVM que entenda a versão do Java em que os bytecodes foram
 16

compilados (DEITEL; DEITEL, 2005).

1.1.1 Versões

A linguagem Java sofre aprimoramentos desde o seu lançamento. O

aumento no número de aplicações desenvolvidas em Java levou à criação de
três divisões na plataforma a partir da segunda versão da linguagem: J2SE,
J2EE e J2ME. Essas divisões são conhecidas por alguns como ambientes de
desenvolvimento. No entanto, outros as denominam como profiles, plataformas,
versões, entre outros. É importante dizer que, a partir de 2006, passou-se a
utilizar uma nova nomenclatura para essas plataformas. O número 2 foi retirado
das siglas que as representam, portanto, essas passaram a ser: JSE, JEE e
JME (ALECRIM, 2007).
Plataforma Java, Standard Edition (JSE) permite desenvolver e implantar
aplicativos Java em desktops e servidores, bem como os mais exigentes
ambientes embarcados e em tempo real (JAVA SE, 2009).
Plataforma Java, Micro Edition (JME) fornece um ambiente robusto e
flexível para aplicativos executados em dispositivos móveis e outros
dispositivos embarcados - telefones celulares, assistentes pessoais digitais
(PDA), decodificadores de sinais de TV e impressoras. Java ME inclui
interfaces de usuário flexíveis, segurança robusta, protocolos de rede interna e
suporte para aplicativos em rede e off-line que podem ser baixados
dinamicamente. Aplicativos baseados em Java ME são portáveis em muitos
dispositivos, e ainda aproveitam os recursos nativos dos mesmos (JAVA ME,
2009).
Plataforma Java, Enterprise Edition (JEE) desenvolve a base sólida do
Java SE e é o padrão para a implementação de classe corporativa, arquitetura
orientada a serviços (SOA) e aplicativos da web de última geração (JAVA EE,
2009).

1.1.2 Java na Web

Aplicativos web são por natureza aplicações distribuídas, ou seja, são

partes de um mesmo programa que, de forma combinada, executam em
 17

diferentes lugares em máquinas separadas denominadas clientes e servidores,

interconectados através de uma rede comum (FRANZINI, 2009).
A internet é uma gigantesca rede que liga vários computadores entre si,
todos esses computadores utilizam-se do protocolo TCP/IP para se
comunicarem. É uma rede heterogênea, já que diversos tipos de computadores
estão ligados a ela, e, por esses serem distintos, é preciso uma linguagem que
não esteja necessariamente amarrada a uma plataforma de hardware /
software específica. Java mostra-se ideal quanto a esse fator (SILVEIRA,
2003).
Para o desenvolvimento de diferentes tipos de aplicativos web, a
tecnologia Java disponibiliza um conjunto extenso de tecnologias e ferramentas
agrupadas em um pacote chamado atualmente de JEE, um conjunto de
ferramentas e padronizações com o objetivo exclusivo de economizar tempo e
dinheiro no ciclo de desenvolvimento (FRANZINI, 2009).
Servlet e JSP são duas tecnologias desenvolvidas pela Sun
Microsystems para desenvolvimento de aplicações web, a partir de
componentes Java, que executam do lado servidor (GONÇALVES, 2007).

1.1.3 Servlets

Segundo Mukhi, Mukhi e Kotecha (2002, p. 105): “servlets são

programas Java residentes na memória, executando dentro de um container de
servlets”. A tecnologia servlet foi introduzida pela Sun Microsystems em 1996.
Quando a internet surgiu, era constituída apenas de conteúdo estático escrito
usando Hypertext Markup Language (HTML). Logo foi possível obter conteúdo
dinâmico da web através da tecnologia Common Gateway Interface (CGI).
A CGI permite que o servidor web chame um programa externo e passe
a solicitação HTTP a esse programa para processar a solicitação. A resposta
do programa externo é então passada de volta para o servidor web, que
encaminha uma página HTML para o navegador do usuário. Programas CGI
podem ser escritos em qualquer linguagem que possa ser chamada pelo
servidor web. Ao longo do tempo, Perl tornou-se a linguagem mais popular
para escrever programas CGI (KURNIAWAN, 2002).
Com a popularização da internet, o número de usuários visitando o
 18

mesmo website aumentou exponencialmente e tornou-se evidente que CGI não

tinha como oferecer aplicações de internet dimensionáveis. A falha no CGI é
que cada solicitação do usuário faz o servidor web gerar um novo processo do
programa CGI solicitado. O processo de criação é uma operação que exige
muito da CPU e da memória do computador (KURNIAWAN, 2002).
Servlets são a linha de frente do desenvolvimento de aplicativos para
web escritos em Java. Eles facilitam a comunicação entre o código instalado no
servidor e os clientes baseados na web (MUKHI; MUKHI; KOTECHA, 2002).
Uma vantagem da tecnologia de servlets e páginas JSP com relações a outras
tecnologias é o fato do servlet permanecer carregado (enquanto o servidor
estiver ativo) permitindo assim com que dados armazenados em variáveis de
classe persistam ao longo dos diversos pedidos recebidos. Assim, é possível
manter um pool de conexões ao banco de dados, por exemplo, de maneira que
não haja necessidade de iniciar e estabelecer uma nova conexão ao banco de
dados a cada novo pedido recebido (GONÇALVES, 2007).

Servlets vivem para servir clientes. A função de um servlet é receber

uma solicitação do cliente e devolver uma resposta. A solicitação
talvez seja simples: "traga-me a página de Boas Vindas". Ou pode ser
complexa: "Finalize o processo do meu carrinho de compras". A
solicitação traz consigo dados cruciais e o código do seu servlet tem
que saber como encontrá-los e utilizá-los. A resposta leva a
informação que o browser precisa para montar uma página (ou baixar
alguns dados) e o código do seu servlet tem que saber como enviá-
los. Ou não... em vez disso, seu servlet pode decidir encaminhar a
solicitação adiante (para outra página, servlet ou JSP) (BASHAM;
SIERRA; BATES, 2005, p. 61).

1.1.4 JSP

O desenvolvimento de servlet é bem complicado, especialmente quando

é preciso escrever, em sua estrutura, uma página HTML longa. A Sun
entendeu esse problema e desenvolveu uma solução: o resultado foi a
tecnologia JavaServer Pages (KURNIAWAN, 2002). JSP é fundamentada na
tecnologia servlet, criada para apoiar a criação de páginas que combinam
HTML ou XML com código Java, produzindo páginas web dinâmicas (MUKHI;
MUKHI; KOTECHA, 2002).
A primeira vez que uma página JSP é carregada por seu container, o
código Java é compilado gerando um servlet que é executado. As chamadas
 19

subsequentes são enviadas diretamente ao servlet, não havendo recompilação

do código Java (GONÇALVES, 2007).
Uma das grandes vantagens de desenvolver em JSP é que não é
preciso compilar seu código. Cria-se a página e a coloca pra rodar no servlet
container. Caso seja preciso fazer alguma alteração, altera-se e pronto
(GONÇALVES, 2007).

A JSP não pretende substituir servlets. Na verdade, é uma extensão da

tecnologia servlet, e é comum usar as duas tecnologias no mesmo aplicativo
web (KURNIAWAN, 2002).

1.2 Frameworks

À medida que a importância do software cresceu, a comunidade de

programadores tem continuamente tentado desenvolver tecnologias que
tornem mais fácil, mais rápido e menos dispendioso construir e manter
programas de computador de alta qualidade (PRESSMAN, 2006). Uma dessas
alternativas é fazer uso de framework. A partir do conceito de reuso de código,
os frameworks estão sendo desenvolvidos e pesquisados (ASSIS, 2003).

Por definição: “Framework [...] é uma aplicação semi-completa e

reutilizável que, quando especializada, produz aplicações personalizadas”
(SILVA; MOREIRA, 2004, p. 3).

Um framework pode ser definido como um conjunto de classes

abstratas, orientadas a objetos, podendo ser particularizado ou customizado de
acordo com a necessidade de cada aplicação, estendendo sua estrutura.
Sendo assim, um framework funciona como um molde ou estrutura para a
construção de aplicações e subsistemas dentro de um mesmo domínio
(BERGAMO, 2000).
A Figura 1 compara o processo de desenvolvimento de software
utilizando POO pura e utilizando frameworks.

De acordo com a Figura 1, a idéia principal de um Framework não é

desenvolver a solução para uma determinada aplicação (1), mas sim definir um
comportamento geral de um domínio de aplicação (2) e criar uma estrutura
para representá-lo (3). A realização de um software para uma implementação
 20

específica consiste em instanciar o referido framework, através da

especialização de seus componentes (4) (CAVALHEIRO, 2007).

1
3

Fonte: Cavalheiro, 2007.

Figura 1. Desenvolvimento com: (a) POO e (b) Framework

Em um framework, a abstração ocorre na parte em que se define quais

funções possíveis podem ser implementadas numa aplicação específica. Uma
de suas características importantes é a confiabilidade, pois boa parte de seu
código já está pronto e testado, o que diminui significativamente a margem de
erros juntamente com os esforços de manutenção (ASSIS, 2003).
Segundo Orfali, Harkey e Edwards (apud BERGAMO, 2000, p. 36): “um
framework corresponde a um projeto de alto nível, consistindo de classes
abstratas e concretas que especificam uma arquitetura para aplicações”.
Os principais benefícios propostos pelos frameworks são (BERGAMO,
2000):

a) Prover uma interface estável, aumentando o reuso de seus

componentes que podem ser reutilizados na criação de uma nova aplicação. O
reuso desses componentes pode também acarretar uma melhor produtividade
do programador, da qualidade do software, de desempenho e de confiança;
b) Frameworks aumentam a modularidade por encapsular detalhes
de implementações através de interfaces estáveis. A modularidade auxilia a
melhorar a qualidade de software por localizar o impacto de alterações de
projeto e implementação. Essa localização reduz o esforço requerido para
entender e manter softwares existentes;
c) A manutenção é reduzida. Os frameworks fornecem a maior parte
do código necessário às aplicações, tornando os custos de manutenção
 21

menores. Devido à herança, quando um erro em um framework é corrigido, ou

uma característica adicionada, os benefícios são imediatamente estendidos às
novas classes;
d) Possibilidade de desenvolvimento de aplicações mais complexas.
A criação de frameworks baseados em outros frameworks permite o
desenvolvimento de aplicações cada vez mais complexas;
e) Inversão de controle faz com que o framework atue como
programa principal, controlando toda execução das aplicações, pois os
métodos que especializam o framework são chamados dentro dele próprio e
não dos códigos de aplicação do usuário (RÉ, 2002).
Pode-se dizer que um framework faz o reuso de análise, código e
projeto. Faz reuso de análise, pois dita quais os componentes necessários para
um domínio de aplicação específico e as regras que se deve seguir para fazer
a implementação. Reusa código, porque é mais fácil desenvolver componentes
que tenham compatibilidade de forma geral, isso é possível, pois, ao
desenvolver novos componentes, grande parte de seu código é herdado das
superclasses abstratas. Reusa projeto, porque contém mecanismos abstratos
que descrevem a interface que o desenvolvedor tende a implementar e as
restrições a serem satisfeitas pela implementação (RÉ, 2002).

1.2.1 Classificação de Frameworks

Segundo Ré (2002, p. 14): “[...] frameworks podem ser classificados

pelas técnicas utilizadas para estendê-los [...]”. Dessa forma temos três grupos:
frameworks caixa branca (whitebox), frameworks caixa preta (blackbox) e
frameworks caixa cinza (graybox).
Os frameworks de caixa branca se baseiam nas características da
orientação a objetos, em particular a herança e a ligação dinâmica, e exigem
dos desenvolvedores um bom conhecimento de sua estrutura (ASSIS, 2003),
pois o usuário deve criar subclasses das classes abstratas contidas no
framework para criar aplicações específicas.
Nos frameworks de caixa preta, o reuso se dá pela associação de
componentes para construção de uma aplicação (CAVALHEIRO, 2007), ou
seja, “[...] eles definem a interface com os componentes de modo que elas
 22

sejam conectadas ao framework por meio da composição de objetos, tendo

maior facilidade de uso e extensão que os de caixa branca” (ASSIS, 2003, p.
8).
Já os frameworks de caixa cinza, são um equilíbrio entre os de caixa
preta e branca, pois provêem tanto flexibilidade quanto capacidade de
extensão, evitando assim as desvantagens dos outros dois tipos (ASSIS,
2003).

1.3 JSF

O JavaServer Faces (JSF) é um framework web baseado no padrão

MVC. Ele é mantido pela Java Community Process JSR-314, que define o
padrão para desenvolvimento de interfaces dentro do modelo orientado a
componentes. Os componentes de JSF são orientados a eventos, ou seja, é
possível processar eventos gerados pelo cliente (GONÇALVES, 2007).
Segundo Gamma et al (2000): o MVC tem como principal objetivo
separar dados ou a lógica de negócios (Model) da interface do usuário (View) e
o fluxo da aplicação (Controller).
O modelo representa a lógica de negócios, mantém o bom
funcionamento da aplicação e fornece ao controlador o acesso aos dados. A
visualização representa a interface com o usuário, define a forma como os
dados serão apresentados e encaminha as ações dos usuários para o
controlador. Já a camada de controle é responsável por ligar o modelo e a
visualização, também interpreta as ações do usuário e as traduz para uma
operação sobre o modelo, onde sofrem mudanças e, então, gera uma
visualização apropriada (GONÇALVES, 2007).
De acordo com Fowler (2003): no JSF, o controle é composto por um
servlet denominado FacesServlet, por arquivos de configuração e por um
conjunto de manipuladores de ações e observadores de eventos. O
FacesServlet recebe requisições da web, redireciona para o modelo e então
remete uma resposta de volta ao FacesServlet. Os arquivos de configuração
(faces-config.xml e web.xml) são responsáveis por realizar associações e
mapeamentos de ações e pela definição de regras de navegação. Os
manipuladores de eventos são responsáveis por receber os dados vindos da
 23

camada de visualização, acessar o modelo, e então devolver o resultado para o

FacesServlet.
Finalmente, a visualização é composta por component trees (hierarquia
de componentes da interface com o usuário), tornando possível unir um
componente ao outro para formar interfaces mais complexas (FOWLER, 2003).
Segundo Marafon (2006), JavaServer Faces oferece ganhos no
desenvolvimento de aplicações web por diversos motivos:
a) Permite que os programadores criem interfaces usando os
componentes do framework ou componentes desenvolvidos por algum
desenvolvedor;
b) Possui inúmeras IDEs e plugins que ajudam no desenvolvimento
de sistemas utilizando esse framework;
c) Possui um modelo de programação orientado a eventos;
d) Oferece facilidade de construção de novos componentes;
e) Fornece um conjunto de tags JSP para acessar os componentes.
JSF foi projetado para ser flexível, sem limitar-se a nenhuma linguagem
de marcação em particular, nem a protocolos ou tipo de clientes.
(GONÇALVES, 2007).
No JSF há dois principais componentes (GEARY; HORSTMANN, 2007):
a) Java APIs que representam componentes de interface com o
usuário e o gerenciamento de seus estados, manipulação / observação de
eventos, validação de entrada, conversão de dados, internacionalização e
acessibilidade.
b) Taglibs JSP que expressam a interface JSF em uma página JSP
e que fazem a conexão dos objetos no lado servidor.

1.3.1 Ciclo de vida das aplicações JSF

Analisar o ciclo de vida do JSF é essencial para desenvolver interfaces

mais complexas e resolver problemas que são comuns durante o
desenvolvimento de uma aplicação. A compreensão desse ciclo vai desde a
requisição até o retorno da respectiva resposta determinada pelo usuário
(GEARY; HORSTMANN, 2007).
A Figura 2 representa o ciclo de vida de uma requisição JavaServer
 24

Faces que pode ser dividido em seis fases: restaurar visão, aplicar valores de
requisição, processar validações, atualizar valores do modelo, invocar
aplicação e renderizar resposta. Cada uma dessas seis fases será brevemente
discutida a seguir.

Fonte: Geary e Horstmann, 2007.

Figura 2. Ciclo de vida das requisições JSF

a) Restaurar visão: essa é a primeira fase do ciclo, iniciada quando o

FacesServlet recebe uma requisição. Após recebê-la, o controle verifica a
requisição e a página que ordenou o serviço. O FacesServlet então verifica se
já possui uma árvore de componentes (View ID) da página solicitante no
FacesContext. Caso ainda não exista, uma nova View ID é criada.

b) Aplicar valores de requisição: o objetivo inicial dessa fase é a

recuperação do estado corrente de cada componente. O JSF faz interações
com esses componentes e verifica quais valores requisitados pertencem ao
objeto em questão e armazena-os, como por exemplo: Integer, Boolean e
String.

c) Processar validações: nessa fase cada componente verifica se os

valores que estão sendo recebidos podem ser aceitos sem que haja nenhum
problema de dados. Por exemplo, um atributo numeral receber um valor
contendo letras. Caso encontre um erro, uma mensagem é adicionada no
 25

FacesContext e o controle da aplicação vai para a última fase do ciclo de vida,

chamada “Renderizar Resposta”, que exibirá a página novamente para que o
usuário possa corrigir as informações.

d) Atualizar valores de modelo: aqui o único objetivo é atualizar os

valores dos backing beans. Como essa fase é sucessora à de validação e esta
somente é chamada caso ocorra sucesso na validação dos dados, pode-se
efetuar a atualização dos valores do modelo com segurança.

e) Invocar aplicação: neste momento, a aplicação tem o estado

necessário para executar todos os eventos e lógicas de negócios da aplicação.
São executados os métodos de ação: listeners, lógica de interface e a lógica de
negócio, respectivamente. Também nessa fase do JSF deve-se definir,
dependendo das respostas das ações acima citadas e do arquivo faces-
config.xml, a página a ser mostrada na sequência ao usuário.

f) Renderizar resposta: última fase do ciclo de vida do framework

JavaServer Faces, que tem como objetivo principal o de reconstruir a página
que deve ser exibida ao usuário.

1.3.2 RichFaces

RichFaces é uma biblioteca de componentes JSF e um framework

avançado para integrar recursos de Ajax facilmente em aplicativos de negócios
(RICHFACES, [200 _ ]b).
RichFaces também pode ser definido como um framework de código-
fonte aberto que adiciona recursos de Ajax em aplicativos JSF sem recorrer ao
JavaScript (RICHFACES, [200 _ ]a).
RichFaces utiliza o framework JavaServer Faces, incluindo o ciclo de
vida, validação, etc. Seus componentes com suporte interno a Ajax e alta
personalização podem ser incorporados facilmente em aplicativos JSF
(RICHFACES, [200 _ ]a).

1.4 Ajax

Ajax é um termo criado por Jesse James Garrett que significa

 26

“Asynchronous JavaScript and XML” (CRANE; PASCARELLO; JAMES, 2007).

Consiste no uso conjunto de tecnologias, sendo JavaScript e XML as
principais, que torna possível uma maior interatividade entre os usuários e
páginas da web através de solicitações assíncronas de informações
(GONÇALVES, 2006).
Segundo Olson (2007, p. 5): “O Ajax está centrado no uso inteligente de
JavaScript [...] para interagir, diretamente, com o servidor da web”. Uma
aplicação Ajax é, então, uma parte de código que se comunica de maneira
eficiente com o servidor enquanto o usuário prossegue com seu trabalho
(CRANE; PASCARELLO; JAMES, 2007).

1.4.1 Como o Ajax trabalha

Em vez de o próprio navegador de internet ser responsável por iniciar e

processar os pedidos do servidor, o modelo Ajax fornece uma camada
intermediária para controlar essa comunicação, como pode ser visto na Figura
3. Essa camada, na verdade, é um conjunto de funções JavaScript que são
executadas sempre que há necessidade de se pedir ou enviar informações ao
servidor (GONÇALVES, 2006).

Fonte: Gonçalves, 2006.

Figura 3. Modelo tradicional e modelo utilizando Ajax.

A Figura 3 ilustra a comunicação tradicional entre o navegador e o

servidor e também a comunicação utilizando Ajax. Com a utilização do Ajax, a
 27

comunicação com o servidor é mais eficiente, pois, ao contrário do modelo

tradicional, que envia outro documento ao navegador toda vez que o usuário
interage com o site, no modelo utilizando Ajax parte da lógica é movida para o
navegador. Na prática, a maior parte das informações é carregada no primeiro
acesso à aplicação, por exemplo, não sendo mais necessário carregar menus e
cabeçalhos. (GONÇALVES, 2006).
As tecnologias apresentadas neste capítulo são de grande relevância
para a compreensão da proposta deste trabalho, sendo utilizadas como base
para o desenvolvimento do mesmo.
 28

2 LEVANTAMENTO DE REQUISITOS

2.1 Documentos de Requisitos

A - VISÃO GERAL DO SISTEMA

O sistema de boletim escolar online tem como objetivo possibilitar a

consulta das informações dos alunos relacionadas ao curso em que estão
matriculados, como o nome do curso, disciplinas que frequentam, notas,
médias, faltas, entre outras informações. O sistema disponibilizará ao aluno a
opção de visualizar as faltas dadas ordenadas por data, para que ele possa ter
maior controle. O sistema não terá funções de cadastro, exceto pela tela de
“Atualizar Senha”, onde o aluno que ainda não possuir uma senha de acesso
pode executar um procedimento para cadastrá-la (ou, em alguns casos, alterá-
la). Por se tratar de uma aplicação cujos dados são obtidos (duplicados) de
uma base de dados em produção, sua estrutura de armazenamento de dados
deve ser simplificada.

B - REQUISITOS FUNCIONAIS

B1 - Lançamentos diversos

a) O sistema deve permitir o cadastro (ou alteração) de uma senha

para que o aluno possa acessar seu boletim.
b) O sistema deve permitir que o aluno faça um login, informando
seu RA e sua senha, onde o sistema verificará se esses dados condizem com
os que estão cadastrados, retornando o acesso ou a negação.

B2 - Relatórios e consultas

a) O sistema deve permitir que o aluno faça a consulta de suas

notas, com as seguintes informações: RA, nome, ano, semestre e curso;
disciplinas, limite de faltas da mesma, faltas dadas, primeira nota, segunda
 29

nota, nota do exame, média e resultado (estado do aluno em relação à

disciplina).
b) O sistema deve permitir que o aluno consulte as informações de
cada falta dada a ele em determinada disciplina ao clicar sobre o número de
faltas: dia e quantidade de faltas daquele dia.

C - REQUISITOS NÃO FUNCIONAIS

C1 - Eficiência

a) O sistema deve garantir que o aluno acesse apenas as

informações acadêmicas referentes a ele próprio.

C2 - Portabilidade

a) O sistema deve ser compatível com os navegadores mais

populares do mercado. Segundo a Folha Online (INTERNET, 2010), são:
Internet Explorer, Firefox, Chrome, Safari e Opera, nessa sequência.
b) O sistema deve permitir o seu uso sem a necessidade de
instalação pelo cliente.
 30

3 ANÁLISE ORIENTADA A OBJETOS

3.1 Lista de Casos de Uso

Nº Descrição do Evento Evento Use Case Resposta

01 Aluno solicita Logar DadosLogar Logar Msg01
02 Aluno solicita Atualizar DadosAluno AtualizarSenha Msg02
senha
03 Aluno solicita Visualizar DadosBoletim GerarBoletim GerarBoletim
boletim
04 Aluno solicita Visualizar DadosFaltas ExibirFaltas Msg03
faltas
Fonte: Desenvolvido pelos autores, 2010.
Quadro 1. Lista de Casos de Uso

3.2 Diagrama de Casos de Uso

3.2.1 Logar

Fonte: Desenvolvido pelos autores, 2010.

Figura 4. Diagrama de Caso de Uso - Logar
 31

3.2.2 Atualizar Senha

Fonte: Desenvolvido pelos autores, 2010.

Figura 5. Diagrama de Caso de Uso - Atualizar Senha

3.2.3 Gerar Boletim

Fonte: Desenvolvido pelos autores, 2010.

Figura 6. Diagrama de Caso de Uso - Gerar Boletim
 32

3.2.4 Exibir Faltas

Fonte: Desenvolvido pelos autores, 2010.

Figura 7. Diagrama de Caso de Uso - Exibir Faltas

3.3 Diagrama de Classes

Fonte: Desenvolvido pelos autores, 2010.

Figura 8. Diagrama de Classes e Objetos
 33

4 PROJETO DE BANCO DE DADOS

4.1 Tabelas

4.1.1 Boletim

Chave-Primária (PK): (RAALUNO, CODCURSO, CODDISCIPLINA, ANO,

SEMESTRE).
Chave-Estrangeira (FK): RAALUNO (ALUNO.RA), CODCURSO
(CURSO.CODIGO), CODDISCIPLINA (DISICPLINA.CODIGO).

Nome do Campo Tipo de Dado Tamanho Permite Nulo?

RAALUNO Número 10 NÃO
CODCURSO Número 3 NÃO
CODDISICPLINA Número 6 NÃO
ANO Número 4 NÃO
SEMESTRE Texto 1 NÃO
LMTFALTAS Número 2 SIM
NOTA1 Número 3,1 SIM
NOTA2 Número 3,1 SIM
EXAME Número 3,1 SIM
Fonte: Desenvolvido pelos autores, 2010.
Quadro 2. Tabela Boletim

Outras regras de validação de campo:

Nome do Campo: Restrição:
SEMESTRE Valores permitidos A ou B
NOTA1 Valores permitidos entre 0 e 10
NOTA2 Valores permitidos entre 0 e 10
EXAME Valores permitidos entre 0 e 10
Fonte: Desenvolvido pelos autores, 2010.
Quadro 3. Tabela Boletim - outras regras

4.1.2 Aluno

Chave-Primária (PK): (RA)

Nome do Campo Tipo de Dado Tamanho Permite Nulo?
RA Número 10 NÃO
SENHA Texto 10 SIM
NOME Texto 60 NÃO
RG Texto 9 NÃO
Fonte: Desenvolvido pelos autores, 2010.
Quadro 4. Tabela Aluno
 34

4.1.3 Disciplina

Chave-Primária (PK): (CODIGO)

Nome do Campo Tipo de Dado Tamanho Permite Nulo?
CODIGO Número 6 NÃO
NOME Texto 60 NÃO
Fonte: Desenvolvido pelos autores, 2010.
Quadro 5. Tabela Disciplina

4.1.4 Curso

Chave-Primária (PK): (CODIGO)

Nome do Campo Tipo de Dado Tamanho Permite Nulo?
CODIGO Número 3 NÃO
NOME Texto 60 NÃO
Fonte: Desenvolvido pelos autores, 2010.
Quadro 6. Tabela Curso

4.1.5 Faltas

Chave-Primária (PK): (RAALUNO, CODCURSO, CODDISCIPLINA, ANO,

SEMESTRE, DATA).
Chave-Estrangeira (FK): RAALUNO, CODCURSO, CODDISCIPLINA, ANO,
SEMESTRE (BOLETIM.RAALUNO, BOLETIM.CODCURSO,
BOLETIM.CODDISCIPLINA, BOLETIM.ANO, BOLETIM.SEMESTRE).
Nome do Campo Tipo de Dado Tamanho Permite Nulo?
RAALUNO Número 10 NÃO
CODCURSO Número 3 NÃO
CODDISICPLINA Número 6 NÃO
ANO Número 4 NÃO
SEMESTRE Texto 1 NÃO
DATA Texto 10 NÃO
QTD Texto 3 NÃO
Fonte: Desenvolvido pelos autores, 2010.
Quadro 7. Tabela Faltas
 35

5 PROJETO ORIENTADO A OBJETOS

5.1 Diagramas de Sequências

5.1.1 Logar

Fonte: Desenvolvido pelos autores, 2010.

Figura 9. Diagrama de Sequências - Logar

5.1.2 Atualizar Senha

Fonte: Desenvolvido pelos autores, 2010.

Figura 10. Diagrama de Sequências - Atualizar Senha
 36

5.1.3 Gerar Boletim

Fonte: Desenvolvido pelos autores, 2010.

Figura 11. Diagrama de Sequências - Gerar Boletim

5.1.4 Exibir Faltas

Fonte: Desenvolvido pelos autores, 2010.

Figura 12. Diagrama de Sequências - Exibir Faltas
 37

6 IMPLEMENTAÇÃO ORIENTADA A OBJETOS

6.1 Layout de Telas – Implementação sem uso de frameworks

O layout de telas foi desenvolvido para proporcionar uma visão limpa e

objetiva, facilitando a utilização do sistema.
A tela de login, na Figura 13, possui campos para informar o RA do aluno
e sua senha, bem como os botões para atualizar senha e “logar”.

Fonte: Desenvolvido pelos autores, 2010.

Figura 13. Tela de login

Após digitar um RA, ao sair do campo, é chamado um método, por meio

de uma solicitação assíncrona utilizando a tecnologia Ajax, que recupera o RA
do aluno digitado na tela e passa para um método Java. Esse método, por sua
vez, busca o nome do aluno relacionado ao RA no banco de dados e o retorna
para o método Ajax, que apresenta esse nome na tela, conforme a Figura 14.

Fonte: Desenvolvido pelos autores, 2010.

Figura 14. Tela de login apresentando nome do aluno
 38

Caso o RA informado seja inválido, o mesmo método utilizado para

buscar o nome do aluno informa na tela a situação do RA, conforme
apresentado na Figura 15.

Fonte: Desenvolvido pelos autores, 2010.

Figura 15. Tela de login apresentando “RA inválido”

Caso queira cadastrar ou alterar a senha, o aluno deve clicar no botão

“Atualizar Senha”, que abre uma div até então oculta. Essa div possui um
formulário para tal finalidade, apresentado na Figura 16.
Para evitar que um desconhecido cadastre / altere a senha de um aluno
real, deve ser informado o RG correspondente com o RA.

Fonte: Desenvolvido pelos autores, 2010.

Figura 16. Tela de atualização de senha
 39

Por segurança, também é solicitado que o aluno confirme a nova senha.

Um método JavaScript valida as senhas e, no caso de divergência entre elas,
emite uma mensagem informando o problema, como na Figura 17.

Fonte: Desenvolvido pelos autores, 2010.

Figura 17. Tela de atualização de senha com mensagem de erro

Após a digitação dos dados no formulário, ao clicar no botão de

confirmar / login, o formulário é submetido ao servidor, que redireciona as
informações a um método Java que busca o aluno pelo RA e confirma o RG
informado. Se tudo estiver correto, relaciona a senha ao aluno, chamando um
método que grava o objeto Aluno no banco de dados e exibe a lista de boletins
disponíveis.
Para quem já possui uma senha cadastrada, basta informar o RA e a
referida senha na primeira tela e clicar em “Login”. O formulário é submetido ao
servidor e direcionado a um método de validação das informações, esse
método instancia um objeto do tipo Aluno que é comparado com as
informações do banco de dados. Se estiver correto, o objeto Aluno é colocado
na sessão e o aluno é redirecionado à tela de boletins.
Na tela de boletins é acionado um método que verifica na sessão se
existe um objeto aluno; caso exista, é gerada uma lista de boletins e exibida na
tela para o aluno, como na Figura 18.
 40

Fonte: Desenvolvido pelos autores, 2010.

Figura 18. Tela com a lista de boletins

Para visualizar as informações, é necessário clicar no título do boletim

desejado. Essa ação chama um método assíncrono Ajax, que recupera as
informações através do link clicado e passa ao servidor por um método
responsável por gerar o boletim selecionado. Esse método recupera as
informações e instancia um objeto do tipo DAO, que vai ao banco buscar as
informações; por último, pega as informações vindas do banco, grava no objeto
Aluno, cria a estrutura HTML com essas informações e as apresenta na tela,
como na Figura 19.

Fonte: Desenvolvido pelos autores, 2010.

Figura 19. Tela com as informações do boletim escolhido
 41

Também há a possibilidade de visualizar as informações das faltas

dadas em determinada disciplina, clicando sobre a quantidade de faltas, que
fará um processo praticamente idêntico à geração do boletim. Uma div oculta
apresenta essas informações, conforme a Figura 20.

Fonte: Desenvolvido pelos autores, 2010.

Figura 20. Tela de informações sobre faltas recebidas

6.2 Layout de Telas – Implementação utilizando o framework JSF

Utilizando componentes visuais do JSF é possível fazer um

mapeamento direto dos campos da tela com variáveis da classe controladora
Java, atribuindo valores a essas variáveis apenas com a submissão do
formulário. Essa submissão acontece toda vez que uma action (mapeamento
de um método Java) é acionada. Ao digitar o RA do aluno e sair do campo, o
evento aciona uma action que tem por objetivo buscar o aluno no banco de
dados pelo RA informado e atribuí-lo ao objeto Aluno na classe Java. Ao final
do processamento desse método é renderizado apenas o componente que
deve exibir o nome do aluno, como mostra a Figura 14 (exibida anteriormente).
Isso é possível, pois existe um componente do JSF na tela, representado na
linha 24 da Figura 21, que está associado com o nome do objeto aluno na
classe Java, fazendo tudo de forma assíncrona por meio de um componente
Ajax, bem como na linha 34 da mesma figura.
 42

Fonte: Desenvolvido pelos autores, 2010.

Figura 21. Associação de um componente JSF a um objeto Java

Caso o aluno digite um RA que não exista é exibido uma mensagem de

RA inválido, como apresentado na Figura 15.
Ao digitar a senha e clicar no botão “Login” é acionada outra action que
verifica se a senha corresponde com o RA informado. Caso os dados estejam
corretos, é feita uma pesquisa no banco de dados de todos os boletins que
aquele RA possui, atribuindo-os a uma lista de boletins na classe Java. Após a
lista de boletins ser preenchida, outra pesquisa é executada trazendo todas as
faltas daquele aluno e atribuindo-as numa lista de faltas em cada objeto
Boletim encontrado.
Caso o aluno não tenha uma senha para acesso ou deseja alterá-la, ele
pode fazer isto clicando no botão “Atualizar Senha” na tela de Login, como
mostra a Figura 13. Para realizar a alteração ou cadastro da senha, o aluno
precisa informar o RA, o RG, a nova senha e repetir a nova senha no campo de
confirmação. Ao sair do campo de confirmação é acionado um método
JavaScript igual ao desenvolvido em JSP, que faz a verificação das senhas
digitadas e, em caso de divergência, exibe uma mensagem informando que as
senha não conferem, como na Figura 17.
Preenchido o formulário, apresentado na Figura 15, ao clicar em
“Confirmar/Login” é acionada uma action que verifica se o RG confere com o
RA informado e, se os dados estiverem corretos, o procedimento será o
mesmo do Login, que ao final exibe a página de boletins gerados.
No JSF existe um arquivo que funciona como um servlet chamado faces-
config.xml, como pode ser visto na Figura 22. Esse arquivo tem a finalidade de
realizar mapeamentos entre visão e classes Java, bem como configurar as
 43

regras de navegação.
É possível ver um exemplo de mapeamento na linha 8, onde se encontra
a tag <managed-bean-name>, nela é dado um nome para o mapeamento
indicado na linha 9, que será acessado por componentes na tela; e, na linha
10, onde está a tag <manage-bean-scope>, é indicado o tempo de duração de
execução daquela classe, onde, se for session, quer dizer que o tempo de
execução daquela classe irá durar o tempo de uma sessão, se for request irá
durar uma requisição, e assim por diante.

Fonte: Desenvolvido pelos autores, 2010.

Figura 22. Representação do arquivo faces-config.xml

Outra funcionalidade é a de tratar as respostas de métodos, como pode

ser observado entre as linhas 24 e 31 da Figura 22. Caso o método retorne a
String “false”, por exemplo, o arquivo de configuração redireciona para a página
 44

que foi determinada, que nesse projeto retorna para a página de Login. Se o
método retornar “sucess”, esse arquivo de configuração faz um
redirecionamento para a página que deverá mostrar o resultado daquele
método, que nesse caso é a página com os boletins gerados, como está
exibido na Figura 23. Nessa tela, todas as informações já estão montadas,
sendo apenas preciso que o aluno clique sobre o título do boletim desejado
para que o painel expanda, exibindo seu conteúdo.

Fonte: Desenvolvido pelos autores.

Figura 23. Tela de boletins em JSF

Para a montagem dos boletins foram utilizados, além da linguagem JSP,

componentes JSF e RichFaces, que estão mapeados na classe Java onde
recebem as listas de boletins e faltas. Também foi necessário o uso de laços e
comparações para poder organizar as informações. O componente RichFaces
é o responsável pela criação dos painéis. A Figura 24 apresenta um trecho de
código Java onde está configurada a resposta do método que é acionado pela
action. Se a condição for verdadeira o método retorna “sucess”, caso não for
ele retorna “false”.
 45

Fonte: Desenvolvido pelos autores, 2010.

Figura 24. Trecho de código Java

Na página de boletim, o aluno tem a possibilidade de visualizar detalhes

sobre as faltas de cada disciplina. Clicando sobre a quantidade de faltas dadas
é exibida uma div com as respectivas informações, lembrando que essas
informações também foram montadas no momento da geração dos boletins,
onde, para serem exibidas, é feita apenas a troca do estado da div que está
oculta, como apresentado na Figura 25.

Fonte: Desenvolvido pelos autores.

Figura 25. Tela de faltas em JSF
 46

6.3 Comparações sobre o desenvolvimento

Comparando o desenvolvimento sem o uso de framework e com o uso

do JSF, nota-se que é possível realizar tarefas com menos esforços,
diminuindo significativamente o número de linhas e não há necessidade de
criar inúmeras funções para que o mesmo objetivo seja alcançado.
O exemplo prático a ser considerado é a busca do nome do aluno
quando é informado o RA no campo correspondente. No JSP, para buscar o
nome, foram criados alguns métodos - um deles é a função Ajax que, de forma
assíncrona, passa o RA do aluno como parâmetro para pesquisa a um servlet,
que faz a busca do objeto Aluno no banco de dados e retorna o método que se
encarrega de exibir o nome do aluno na tela.
O servlet trabalha através de requisições HTTP que enviam informações
através do navegador para esse servlet. No projeto sem uso de framework, os
dados devem ser recuperados através de requisições para que se façam as
devidas atribuições. Essas requisições são feitas manualmente através de
comandos de recuperação, como é exemplificado na linha 52, na Figura 26.

Fonte: Desenvolvido pelos autores.

Figura 26. Comando de recuperação de dados sem o uso de JSF

Já no desenvolvimento utilizando JSF, atingimos o mesmo objetivo com

mais facilidade, proporcionada pelo uso do framework. Foi criado um método
 47

de busca no controlador Java que é acessado através de um componente

RichFaces. Esse componente contém apenas uma linha de código para
acionar o método no servlet, diferentemente do método criado no outro projeto,
que utiliza várias linhas de código para poder enviar o parâmetro de pesquisa
assincronamente ao servlet.
Com JSF não é necessário escrever linhas de código para recuperar os
parâmetros, isso é possível através do mapeamento da classe Java com a tela,
feito através do arquivo faces-config.xml, como é possível notar na Figura 27.

Fonte: Desenvolvido pelos autores, 2010.

Figura 27. Mapeamento da classe Java no arquivo faces-config.xml

Na tela é necessário apenas referenciar os componentes JSF a um

atributo na classe controladora, e, ao enviar as informações para o servlet,
esse se encarrega de fazer o mapeamento para a classe onde será alimentado
automaticamente o atributo dos objetos, como pode ser visualizado nas linhas
35 e 46 na Figura 28.

Fonte: Desenvolvido pelos autores, 2010.

Figura 28. Associação dos atributos utilizando JSF
 48

CONCLUSÃO

O processo de construção de softwares, atualmente, conta com o auxílio

de ferramentas que facilitam o trabalho dos desenvolvedores, como os
frameworks. A partir do conceito de reuso de código, eles oferecem recursos
que facilitam a criação, manutenção e atualização de softwares.
O aumento da importância do software trouxe também o aumento de sua
complexidade, o que torna o uso desse tipo de ferramenta necessário.
Utilizando tecnologias atuais, este trabalho apresentou uma comparação entre
duas formas de desenvolvimento de aplicativos para web: em Java, sem o uso
de frameworks, e utilizando o framework JSF.
Durante a pesquisa e desenvolvimento, dificuldades e facilidades
surgiram nas duas implementações. Apesar de ser mais fácil de entender
inicialmente, a implementação sem uso de frameworks se mostrou menos
eficaz, principalmente devido à maior quantidade de código. Já a
implementação utilizando JSF, mesmo exigindo maior dedicação ao estudo da
ferramenta, se tornou um bom exemplo para quem deseja facilitar o
desenvolvimento de sistemas flexíveis e seguros.
Uma das grandes dificuldades foi encontrar documentos que
mostrassem um processo de instalação do framework JSF, pois o processo
descrito nos tutoriais disponíveis não funcionava, fato que motivou a criação de
um apêndice ensinando como realizar essa instalação.
Comparando as duas implementações, conclui-se que a utilização do
framework JSF, na construção de aplicações Java voltadas à web, facilita o
trabalho dos programadores. Devido ao JSF trabalhar com o padrão MVC, há
uma maior facilidade na comunicação entre as camadas da aplicação. Todo o
mapeamento que garante essa comunicação deve ser feita em um único
arquivo de configuração. Outra facilidade percebida é a construção das páginas
que, através de componentes prontos, nativos do framework ou adaptáveis,
tornam o processo de construção mais ágil, diminuindo o tempo de
desenvolvimento.
A importância deste trabalho se dá a partir do fato de conseguir
comprovar, na prática, o que a teoria afirma: o uso de framework oferece uma
forma mais fácil, mais rápida e menos dispendiosa de construir e manter
 49

programas de computador. E, também, por dar subsídio para que outras

pessoas passem a utilizar essa tecnologia.
Existem diversos frameworks Java voltados ao desenvolvimento web.
Dessa forma, é indicada para projetos futuros a utilização do Struts 2 e do
Mentawai, por exemplo, sendo o segundo um projeto brasileiro.
 50

REFERÊNCIAS

ABOUT perl. The Perl Programming Language. Disponível em:

<http://www.perl.org/about.html>. Acesso em: 21 nov. 2009.

ALECRIM, E. JSE, JEE e JME: uma breve explicação. InfoWester, São Paulo,
02 set. 2007. Disponível em: <http://www.infowester.com/versoesjava.php>.
Acesso em: 03 out. 2009.

ASSIS, S. R. Frameworks: Conceitos e Aplicações. CienteFico. Salvador, v. 3,

n. 2, jul. - dez. 2003.

BASHAM, B.; SIERRA, K.; BATES, B. Use a Cabeça! Servlets e JSP.

Tradução: Marcelo Soares e Weuler Gonçalves. Rio de Janeiro: Alta Books,
2005.

BERGAMO, L. E. C. Um Framework de Acompanhamento para Aplicações

Multimídia Distribuídas de Ensino a Distância Utilizando a Plataforma
JAMP. 2000. Dissertação (Mestrado em Ciência da Computação, área de
concentração em Sistemas Distribuídos e Redes de Computadores) -
Departamento de Computação, Universidade Federal de São Carlos, São
Carlos.

CATARINO, I. C. S.; PRADO, A. F. Framework Orientado a Componentes

Distribuídos, para Aplicações de Ensino a Distância. In: CONFERÊNCIA
LATINO-AMERICANA DE INFORMÁTICA, 27., 2001, Mérida - México.

CAVALHEIRO, G. G. H. Material de Apoio 14 - Framework. [2007?], 4p.

Apostila da disciplina de Programação Orientada a Objetos. Universidade
Federal de Pelotas.

CRANE, D.; PASCARELLO, E.; JAMES, D. Ajax em ação. Tradução: Edson

Furmankiewicz e Carlos Schafranski. São Paulo: Pearson Prentice Hall, 2007.

DEITEL, H. M.; DEITEL, P. J. Java: como programar. Tradução: Edson

Furmankiewicz. 6. ed. São Paulo: Pearson Prentice Hall, 2005.

FACESCONTEXT. Sun Microsystems, [2004?]. Disponível em:

<http://developers.sun.com/docs/jscreator/apis/jsf/javax/faces/context/FacesCo
ntext.html>. Acesso em: 21 nov. 2009.

FOWLER, M. Patterns of Enterprise Application Architecture. 2. ed. Boston:

Pearson Education, 2003.

FRANZINI, F. A. X. Aplicações Web com Java. iMasters, Vitória, 9 jul. 2009.

Disponível em: <http://imasters.uol.com.br/artigo/13463>. Acesso em: 20 out.
2009.

GAMMA, E. et al. Padrões de Projeto: Soluções reutilizáveis de software

orientado a objeto. Porto Alegre: Bookman, 2000.
 51

GEARY, D.; HORSTMANN, C. Core JavaServer TM Faces. 2. ed. Rio de

Janeiro: Alta Books, 2007.

GOMES, Y. M. P. Java na Web com JSF, Spring, Hibernate e Netbeans 6.

Rio de Janeiro: Ciência Moderna, 2008.

GONÇALVES, E. Desenvolvendo aplicações Web com JSP, Servlets,

JavaServer Faces, Hibernate, EJB 3 Persistence e Ajax. Rio de Janeiro:
Ciência Moderna, 2007.

_______. Dominando AJAX: as melhores práticas ligadas a aplicações web

escritas tanto em Java como em PHP 5 utilizando AJAX. Rio de Janeiro:
Ciência Moderna, 2006.

HUGO, M.; HUBNER, J. F. Objetos do domínio da aplicação. [s.d.], 7p. Apostila

da disciplina de Programação II: Orientação a Objetos. Universidade Regional
de Blumenau. Disponível em: <http://www.inf.furb.br/~poo/tutoriais/poo-
lab6.html>. Acesso em: 17 out. 2009.

INTERNET explorer 8 lidera uso de navegadores em janeiro. Folha Online,

São Paulo, 04 fev. 2010. Disponível em:
<http://www1.folha.uol.com.br/folha/informatica/ult124u689034.shtml>. Acesso
em: 20 ago. 2010.

JAVA EE at a glance. Sun Developer Network. Disponível em:

<http://java.sun.com/javaee/index.jsp>. Acesso em: 30 set. 2009.

JAVA ME at a glance. Sun Developer Network. Disponível em:

<http://java.sun.com/javame/index.jsp>. Acesso em: 30 set. 2009.

JAVA SE at a glance. Sun Developer Network. Disponível em:

<http://java.sun.com/javase/index.jsp>. Acesso em: 30 set. 2009.

KURNIAWAN, B. Java for the Web with Servlets, JSP, and EJB: a
developer's guide to J2EE solutions. Indianapolis - EUA: New Riders, 2002.

MACORATTI, J. C. Usando Connection Pooling. iMasters, Vitória, 02 mar.

2005. Disponível em:
<http://imasters.uol.com.br/artigo/3033/dotnet/usando_connection_pooling>.
Acesso em: 21 out. 2009.

MARAFON, L. D. Integração JavaServer Faces e Ajax. 2006. Monografia

(Graduação em Ciências da Computação) - Universidade Federal de Santa
Catarina, Santa Catarina.

MENTAWAI overview. Mentawai web framework, [s.l.], 21 abr. 2007.

Disponível em: <http://www.mentaframework.org/>. Acesso em: 21 mai. 2010.

MUKHI, V.; MUKHI, S.; KOTECHA, N. Java Servlets JSP. Tradução: Ariovaldo
Griesi. São Paulo: Makron Books, 2002.
 52

OLSON, S. D. Ajax com Java. Tradução: Daniela Botelho. Rio de Janeiro: Alta
Books, 2007.

PRESSMAN, R. S. Engenharia de Software. Tradução: Rosângela Delloso

Penteado. 6. ed. São Paulo: McGraw-Hill, 2006.

RÉ, R. Um processo para construção de frameworks a partir da

engenharia reversa de sistemas de informação baseados na web:
aplicação ao domínio dos leilões virtuais. 2002. Dissertação (Mestrado em
Ciências da Computação e Matemática Computacional) - Instituto de Ciências
Matemáticas e de Computação, Universidade de São Paulo, São Paulo.

RICHFACES developer guide. JBoss Community, [s.l.], [200 _ ]. Disponível

em: <http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html_single/>.
Acesso em: 02 jun. 2010.

RICHFACES project page. JBoss Community, [s.l.], [200 _ ]. Disponível em:

<http://www.jboss.org/RichFaces>. Acesso em: 30 mai. 2010.

ROUGHLEY, I. Practical Apache Struts 2 Web 2.0 Projects. Tradução: José

Rodolfo de Souza. Rio de Janeiro: Ciência Moderna, 2008.

SILVA, E. Q.; MOREIRA, D. A. Um Framework de Componentes para o

Desenvolvimento de Aplicações Web Robustas de Apoio à Educação. In:
SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 15., 2004,
Manaus. Manaus: UFAM, 2004, p. 158-167.

SILVEIRA, I. F. Linguagem Java. InfoWester, São Paulo, 30 jun. 2003.

Disponível em: <http://www.infowester.com/lingjava.php>. Acesso em: 05 out.
2009.

SOUSA, M. Desenvolvendo com JavaServer Faces - Parte 1. Java Magazine.

Rio de Janeiro, n. 72, p. 8-18, set. 2009.
 53

GLOSSÁRIO

Termo Descrição

Backing O termo “Backing Beans” é usado frequentemente para fazer

beans referências às classes controladoras de uma aplicação JSF
(SOUZA, 2009). Página 25.
DAO DAO (Data Access Object) é um padrão de persistência de
dados que consiste em abstrair o mecanismo de persistência
utilizado na aplicação. Ele permite separar as regras de negócio
das regras de acesso a banco de dados. Página 40.
Div Elemento de HTML. Definidor genérico de bloco para especificar
idioma ou formatação associada ao estilo. Página 38.
Domínio de Segundo Hugo e Hubner [s.d.]: “A camada de domínio da
aplicação aplicação, também conhecida como camada de negócio [...], é
aquela onde estão localizadas as [...] classes correspondentes a
objetos que fazem parte da descrição do problema.” Página 19.
Faces FacesContext contém todas as informações por solicitação do
Context estado relacionadas com o processamento de um único pedido
JSF, e o processamento da resposta correspondente. Ele é
modificado por cada fase do ciclo de processamento da
solicitação (FACESCONTEXT, 2004). Página 24.
JSR-314 URL do projeto Java Community Process JSR-314:
http://jcp.org/en/jsr/detail?id=314. Página 22.
MVC Model-view-controller (MVC): Conceito de desenvolvimento e
projeto que tenta separar uma aplicação em três partes
distinstas. Model (modelo), que está relacionada ao trabalho
atual que a aplicação administra, View (visão), que está
relacionada à exibição dos dados ou informações dessa
aplicação e Controller (controlador), que coordena os dois
anteriores exibindo a interface correta ou executando algum
trabalho que a aplicação precisa completar (GONÇALVES,
2007). Página 22.
Perl Perl é uma linguagem de programação com mais de 20 anos de
desenvolvimento. A versão atual, Perl 5, é executada em
 54

diversas plataformas, de portáteis a mainframes. Suporta POO,

processual e funcional (ABOUT, 2009). Página 17.
POO Para saber sobre Programação Orientada a Objetos, consulte:
LEITE, M.; RAHAL, N. A. S. Jr. Programação Orientada ao
Objeto: uma abordagem didática. Revista de Informação e
Tecnologia, Campinas, ago. 2002. Disponível em:
<http://www.ccuec.unicamp.br/revista/infotec/artigos/leite_rahal.h
tml>. Acesso em: 24 abr. 2010. Página 15.
Pool de Permite a uma aplicação reusar conexões existentes ao invés
conexões de repetidamente fechar e criar novas conexões. A idéia por trás
de um pool de conexões é otimizar o acesso aos dados através
de uma utilização racional das conexões feitas com uma fonte
de dados (MACORATTI, 2005). Página 13.
 55

APÊNDICES
 56

APÊNDICE A – Configurando um projeto web no Eclipse com JSF

Objetivo: Preparar o ambiente Eclipse para o desenvolvimento com o

framework JavaServer Faces.
Arquivos utilizados: JSTL (jstl-api-1.2.jar) e JSF 1.2_14 (jsf-api.jar, jsf-
impl.jar)
Primeiro é preciso baixar a API do JavaServer Faces. Para isso, deve-se
acessar o site <https://javaserverfaces.dev.java.net/download.html> e clicar na
opção desejada para fazer o download - no exemplo foi escolhida a opção
“1.2_14 binary”, conforme a Figura 29.

Fonte: Desenvolvido pelos autores, 2010.

Figura 29. Baixando o JSF

Logo após, para baixar a API JSTL, deve-se entrar no site

<https://jstl.dev.java.net/download.html> e clicar no link “JSTL API”, conforme
Figura 30, salvando o arquivo no computador.

Fonte: Desenvolvido pelos autores, 2010.

Figura 30. Baixando o JSTL
 57

Abra o eclipse e crie um projeto web (Dynamic Web Project), como na

Figura 31.

Fonte: Desenvolvido pelos autores, 2010.

Figura 31. Criando um projeto web no Eclipse

Defina o nome do projeto como “ProjetoJSF”, de acordo com a Figura

32.

Fonte: Desenvolvido pelos autores, 2010.

Figura 32. Definindo o nome do projeto

Agora é preciso mapear o FacesServlet no arquivo web.xml da

aplicação, que se encontra na pasta WEB-INF, apresentado na Figura 33.
 58

Fonte: Desenvolvido pelos autores, 2010.

Figura 33. Localização do arquivo web.xml

Para fazer o mapeamento do FacesServlet, é necessário abrir a

perspectiva “source” e adicionar as linhas a seguir dentro do web.xml, como a
Figura 34.

Fonte: Desenvolvido pelos autores, 2010.

Figura 34. Trecho do arquivo web.xml
 59

Por fim, salve o arquivo web.xml.

Crie agora, dentro da pasta WebContent/WEB-INF, um arquivo de
configuração faces-config.xml, responsável por fazer o mapeamento das
classes Java com a tela propriamente dita, de acordo com a Figura 35 e 36.

Fonte: Desenvolvido pelos autores, 2010.

Figura 35. Criando um arquivo XML

Fonte: Desenvolvido pelos autores, 2010.

Figura 36. Definindo o nome do arquivo XML
 60

Após a criação do arquivo, inicialmente insira as linhas a seguir,

conforme Figura 37.

Fonte: Desenvolvido pelos autores, 2010.

Figura 37. Arquivo faces-config.xml

Salve o arquivo.
Agora é preciso extrair do pacote JSF os arquivos .jar (jsf-api.jar e jsf-
impl.jar), conforme Figura 38.

Fonte: Desenvolvido pelos autores, 2010.

Figura 38. Arquivos .jar necessários do pacote JSF

Copie os arquivos do pacote JSF e o arquivo jstl-api-1.2.jar baixado para

a pasta lib. O resultado deve ser como mostrado na Figura 39.

Fonte: Desenvolvido pelos autores, 2010.

Figura 39. Arquivos inseridos na pasta lib
 61

Crie, no WebContent, uma página JSP, como na Figura 40.

Fonte: Desenvolvido pelos autores, 2010.

Figura 40. Criando um arquivo JSP

Defina o nome da página JSP como index.jsp, conforme a Figura 41.

Fonte: Desenvolvido pelos autores, 2010.

Figura 41. Definindo o nome do arquivo JSP
 62

Insira o mapeamento dos arquivos .jar para a implementação do JSF,

deixando o conteúdo do arquivo JSP igual ao da Figura 42, onde nas linhas 3 e
4 foram adicionados as taglibs e nas linhas 15 a 17, a mensagem exibida em
JSF.

Fonte: Desenvolvido pelos autores, 2010.

Figura 42. Página JSP para testar a configuração do JSF

Execute o projeto. Se aparecer a mensagem “Configuração efetuada

com Sucesso!!!”, o JSF foi instalado corretamente.