uso do jsf na construção de software estudo de
Propaganda
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 P838u Polone, Bruno de Souza; Souza, José Roberto Alves de; Real, Luiz 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). 2 1 3 4 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. a) Ciclo de vida das requisições JSF 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 facesconfig.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ódigofonte 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 02 DadosLogar DadosAluno Logar AtualizarSenha Msg01 Msg02 DadosBoletim GerarBoletim GerarBoletim DadosFaltas ExibirFaltas Msg03 03 04 Aluno solicita Logar Aluno solicita Atualizar senha Aluno solicita Visualizar boletim Aluno solicita Visualizar 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 RAALUNO (FK): (ALUNO.RA), CODCURSO (CURSO.CODIGO), CODDISCIPLINA (DISICPLINA.CODIGO). Nome do Campo Tipo de Dado Tamanho Permite Nulo? RAALUNO CODCURSO CODDISICPLINA ANO SEMESTRE LMTFALTAS NOTA1 NOTA2 EXAME Número Número Número Número Texto Número Número Número Número 10 3 6 4 1 2 3,1 3,1 3,1 NÃO NÃO NÃO NÃO NÃO SIM SIM SIM SIM Fonte: Desenvolvido pelos autores, 2010. Quadro 2. Tabela Boletim Outras regras de validação de campo: Nome do Campo: Restrição: SEMESTRE NOTA1 NOTA2 EXAME Valores permitidos A ou B Valores permitidos entre 0 e 10 Valores permitidos entre 0 e 10 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 SENHA NOME RG Número Texto Texto Texto 10 10 60 9 NÃO SIM NÃO 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 NOME Número Texto 6 60 NÃO 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 NOME Número Texto 3 60 NÃO 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 CODCURSO CODDISICPLINA ANO SEMESTRE DATA QTD Número Número Número Número Texto Texto Texto 10 3 6 4 1 10 3 NÃO NÃO NÃO NÃO NÃO NÃO 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 facesconfig.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. <http://www.perl.org/about.html>. Acesso em: 21 nov. 2009. Disponível em: 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/poolab6.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 <http://java.sun.com/javaee/index.jsp>. Acesso em: 30 set. 2009. em: JAVA ME at a glance. Sun Developer Network. Disponível <http://java.sun.com/javame/index.jsp>. Acesso em: 30 set. 2009. em: JAVA SE at a glance. Sun Developer Network. Disponível <http://java.sun.com/javase/index.jsp>. Acesso em: 30 set. 2009. em: 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, jsfimpl.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 jsfimpl.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.
