Quiz

Exame de CES-22 - Quiz

Componentes:

  • Anderson Aiziro
  • Diego Alvarez
  • Lívia Palomo
  • Maykon Bergamaschi

Apresentação feita em 05/12/2008.

1- Apresentação

Este relatório apresenta o projeto desenvolvido como exame da disciplina de CES-22, proposto com o objetivo de empregar os conceitos de orientação a objetos vistos no curso.

O projeto consiste em uma página web contendo um quiz, jogo em que os usuários se cadastram e respondem a rodadas de cinco perguntas de múltipla escolha armazenadas em um banco de dados. Essas perguntas não se repetem, para que o jogo seja mais interessante. Os usuários que acertarem maior número de questões são mostrados em um "top 5".

Existe ainda uma página de administração, responsável pelo gerenciamento da aplicação e dos bancos de dados, tanto o de usuários quanto o de questões. Nessa seção, é possível incluir permissões para que usuários possam ser notificados via e-mail em caso de problemas na aplicação, como uma queda do banco de dados.

Feita a concepção do que a aplicação deve conter, inicia-se o desenvolvimento do projeto.

2- Desenvolvimento

O projeto, escrito na linguagem JAVA, foi construído com bom nível de desacoplamento entre a lógica de negócio da aplicação e a interface para o usuário, visando seguir o padrão MVC (Model-View-Controller), conceito visto em Arquitetura de Software.

MVC.jpg
Figura 1: Model-View-Controller

Trata-se de um padrão que consiste em separar a aplicação em model (lógica que interage com a base de dados), view (páginas web vistas pelo usuário) e controller (que regula a passagem de dados entre model e view), permitindo maior facilidade em alterações posteriores que o programa pode sofrer.

Para a implementação do MVC, foi utilizado o framework para aplicações web Apache Struts. O banco de dados foi construído em MySQL, seu modelamento será pormenorizado posteriormente. Os arquivos de interface com o usuário são no formato JSP, que gera o HTML para o browser do usuário. Para testar a aplicação, foi utilizado o servlet Apache Tomcat, que gera um servidor web HTTP em que pode ser executado um código em Java.

No decorrer do desenvolvimento do projeto, percebeu-se que seria interessante desacoplar também a forma de notificação dos usuários. A notificação por e-mail poderia ser substituída pelo envio de um SMS para o celular do observador, por exemplo. Por isso, foi efetuado também esse desacoplamento, totalizando quatro módulos do projeto: email, core, domain e view, sendo que os três últimos são correspondentes ao MVC, nessa ordem.

O controle de versão do projeto foi realizado no Google Code e pode ser visualizado clicando aqui.

2.1- Modelamento do Banco de Dados

O Banco de Dados para esta aplicação foi modelado de forma bastante simples. Havia a necessidade de criar três tabelas: uma com a lista de usuários, outra com as questões e a última com o relacionamento entre usuários e questões. Esse é um relacionamento "Many to Many", em que existe uma informação adicional: se o usuário já respondeu a essa questão (hit). Isso determina se a questão sorteada pela aplicação vai ser mostrada ao usuário ou se será sorteada outra questão.

modelo-bd.jpg
Figura 2: Modelamento do Banco de Dados da aplicação

A senha de cada usuário é criptografada antes de ser armazenada, para aumentar a segurança da aplicação. O que o usuário digita quando efetua login é criptografado, ocorre uma comparação com a senha criptografada armazenada no banco de dados e é permitido o acesso caso as senhas batam.

3- Design Patterns

3.1- Abstract Factory

3.2- Singleton

3.3- Observer

No desenvolvimento deste projeto, foi percebida a necessidade de notificar um certo grupo de usuários sobre possíveis problemas na aplicação, como uma queda no banco de dados. Em boa parte das aplicações existentes, existe um mecanismo de notificação de certo grupo de pessoas, em geral os administradores. Podem haver diferentes níveis de notificação, isto é, grupos de administradores podem ser avisados apenas sobre erros classificados como severos, por exemplo. Ainda, a notificação pode ser diferenciada também de acordo com a parte da aplicação em que houve algum erro.

Com os conhecimentos adquiridos sobre o padrão Observer, o grupo concluiu que ele poderia ser empregado no desenvolvimento desta aplicação.

Foi decidido que os administradores não são os únicos a serem notificados, ou seja, administrador e observador são classificações diferentes. Por isso, foi incluída no banco de dados de usuários uma coluna "observador".

Além disso, para esta aplicação, julgou-se que não era necessário criar diferentes níveis de notificação, nem do nível de gravidade do erro, nem da parte da aplicação em que o erro ocorreu. Devido a esse fato, a aplicação se diferenciou um pouco do padrão Observer como consta no GoF. Lá, cada classe observada possui uma classe observadora. Nesta aplicação, a classe observadora verifica a aplicação como um todo.

A notificação acontece por envio de e-mail ao endereço informado no cadastro. Apenas usuários listados como "observadores" no banco de dados são avisados: eles são incluídos em um Array de usuários da classe ObserverManager. A mensagem enviada contém a exceção ocorrida, para que possa haver uma busca mais rápida ao motivo da falha. Abaixo, um screenshot de notificações de erro enviadas.

notificacao_erros.JPG
Figura 3: Notificação de erros

Vale ressaltar a diferença entre as duas classificações: administradores podem adicionar (ou remover) permissões de observadores aos usuários que desejar; observadores apenas são notificados de falhas no programa. Um administrador não necessariamente é um observador e vice-versa.

4- Guia para o usuário

4.1- Instalação

Para rodar a aplicação em sua máquina, o usuário deverá ter instalados Apache Tomcat (ou algum outro aplicativo que gera um servidor HTTP) e MySQL, além de um browser (é recomendado o Microsoft Internet Explorer).

As configurações para utilização são as seguintes:

4.1.1- Acesso ao banco de dados:

A configuração default é o acesso à porta 3306 do host chamado localhost. O nome da base de dados é "quiz". Usuário e senha são root e admin, respectivamente.

Essas configurações podem ser alteradas no arquivo chamado connection.properties, na pasta quiz-core/resources. Para isso, editores simples de texto podem ser utilizados, como o Notepad. Não deve ser alterado o modo de acessar o banco de dados, já que a implementação por JPA não obteve o sucesso esperado.

A seguir, um screenshot dessa alteração. Neste caso, ela foi feita no ambiente de desenvolvimento do programa, no Eclipse:
userguide_01.JPG
Figura 4: Alteração nas configurações para conexão ao banco de dados

Os scripts database.sql e load.sql devem ser nessa ordem rodados (no MySQL Browser, por exemplo), para criar as tabelas da aplicação e popular bancos de dados de perguntas do quiz. Veja abaixo um screenshot para ilustrar o que deve ser feito.
userguide_02.JPG
Figura 5: Criação de tabelas e população de bancos de dados para a aplicação

4.1.2- Utilização de um servidor para a aplicação:

Em Apache Tomcat, foi habilitado o servidor. A porta utilizada foi a 8080. Assim, no Internet Explorer, deve ser digitado na barra de endereços o seguinte caminho: http://localhost:8080/quiz. Se a porta utilizada for outra, basta trocar o número 8080 do caminho pela porta utilizada.

Estão mostrados abaixo dois screenshots feitos no ambiente de desenvolvimento. O primeiro mostra como é feito o redeployment do projeto, isto é, a passagem de um estado "encapsulado" para um estado operante. Em seguida, o servidor é habilitado.
userguide_03.JPG
Figura 6: Redeployment do projeto

userguide_04.JPG
Figura 7: Habilitação do servidor

Quando a aplicação for terminada, é recomendável desabilitar o servidor.

4.2- Utilização

4.2.1- Para o jogador

As instruções para o jogador utilizar a aplicação estão descritas de modo pormenorizado na seção de Testes deste relatório.

4.2.2- Para o administrador

Após a instalação da aplicação, o administrador deverá fazer o seu registro na aplicação como um usuário comum. Manualmente, ele deve alterar o banco de dados de usuários da aplicação (usando MySQL Browser, por exemplo) colocando o valor 1 em substituição ao valor 0 na coluna "admin" de seu cadastro. Não foi criada uma interface para um usuário se registrar como administrador, já que isso, além de reduzir a segurança da aplicação, seria utilizado poucas vezes por um baixo número de usuários.

5- Testes

Inicialmente, a intenção do grupo era desenvolver testes unitários para verificar o bom funcionamento da aplicação. Entretanto, foi percebido que a maior parte dos problemas do programa aconteciam na estrutura de JSPs e XMLs, e não na estrutura das classes. Com isso, a idéia de testes unitários foi deixada de lado.

O browser utilizado nos testes, como logo será visto, foi o Internet Explorer.

A seguir, a página inicial do Quiz:
teste_01.JPG
Figura 8: Tela inicial do Quiz no browser

Aqui pode ser feito tanto o login de usuários já cadastrados quanto o registro de novos usuários.

Fazendo login com um usuário registrado como administrador, a janela que aparece é esta:
teste_02.JPG
Figura 9: Página do administrador - gerenciamento de observadores

Nessa janela, que lembra um pouco a de bloqueio/desbloqueio de contatos do Windows Live Messenger, podem ser adicionadas (ou removidas) as permissões para observadores. Basta inserir em um dos campos o nome do usuário a ser adicionado/removido.

Logando com usuário não-administrador, a tela inicial é esta:
teste_03.JPG
Figura 10: Página inicial do jogador

O usuário pode iniciar uma nova rodada de perguntas clicando em "Novo Quiz". À esquerda, pode ser visto o "top 5", ranking com as maiores pontuações do jogo. Esse ranking é atualizado por sessão, isto é, após o usuário fazer logout.

Prosseguindo com os testes, foi iniciado um novo quiz:
teste_04.JPG
Figura 11: Início de um novo quiz

O usuário deve escolher a alternativa que julga ser a correta e clicar em "Seguir". Após passar pela rodada de cinco perguntas, o quiz é finalizado. O usuário é informado de sua quantidade de acertos naquela rodada, como se vê no screenshot abaixo.
teste_05.JPG
Figura 12: Fim do quiz

Nessa tela, o usuário pode escolher responder a uma nova rodada de perguntas ou sair da aplicação.

Foi criada também uma tela para qual é direcionado o usuário em caso de exceções geradas na aplicação (por exemplo, o usuário, ao receber uma pergunta do quiz, tentar prosseguir sem selecionar uma das alternativas). Essa tela está mostrada a seguir.
teste_06.JPG
Figura 13: Página para a qual o usuário é redirecionado em caso de exceções

Quando ocorre uma exceção na aplicação, o quiz é reiniciado. O usuário pode então retornar à página inicial e recomeçar uma sessão.

A aplicação foi testada com dois usuários diferentes simultaneamente conectados. O resultado foi bom, já que o acesso de um usuário em nada interferiu no do outro.

6- Estatísticas do projeto

Para servir como referência, os arquivos de extensão .java e .jsp têm cerca de 2.000 linhas. Foram retiradas dessa contagem as linhas em branco e as com comentários. Foram declaradas aproximadamente 40 classes nos arquivos contidos no projeto.

Curiosamente, foi utilizado um pequeno programa em Ruby para fazer essas contagens. Tal programa foi colocado na pasta do projeto.

7- Conclusão

Este projeto foi bastante importante para consolidar os conhecimentos relacionados à orientação a objetos adquiridos na disciplina CES-22.

Foi também uma boa oportunidade de aprendizado, uma vez que o grupo, devido às necessidades impostas pelas especificações do projeto, teve que buscar por recursos que dessem suporte ao código gerado.

A utilização de frameworks facilitou a implementação do programa, apesar de, após o fechamento do projeto e uma reflexão sobre ele, o grupo ter percebido que outros frameworks para a plataforma Java serem mais adequados ao porte da aplicação. Além disso, se o programa tivesse sido escrito em Ruby, por exemplo, Ruby on Rails seria ainda mais interessante.

O programa poderia ter outras funcionalidades, como um ranking contendo os melhores jogadores do mês ou uma separação das perguntas do quiz por tema. No entanto, o pouco tempo disponível para os alunos poderem se dedicar ao projeto não permitiu que tais melhorias pudessem ser feitas.

Vale ressaltar ainda que o uso de um controle de versão foi um ponto positivo para o projeto, já que, dessa forma, foi possível que vários membros do grupo trabalhassem simultaneamente em diferentes partes do projeto. Isso também gerou um bom encapsulamento do que era feito, visto que algumas classes desenvolvidas por uma pessoa foram utilizadas por outra que não conhecia detalhadamente o código todo, mas sabia como utilizá-la. Isso é amplamente utilizado em programação, não somente na faculdade, mas também em empresas de software de um modo geral.

Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License