Escola Superior de Tecnologia de Setúbal. Projecto Final

Tamanho: px

Começar a partir da página:

Download "Escola Superior de Tecnologia de Setúbal. Projecto Final"

Evelyn Corte-Real Neves
8 Há anos
Visualizações:

1 Instituto Politécnico de Setúbal Escola Superior de Tecnologia de Setúbal Departamento de Sistemas e Informática Projecto Final Computação na Internet Ano Lectivo 2002/2003 Portal de Jogos Executado por: João Magalhães João Ascenso António Gonçalves

Final Computação na Internet Ano Lectivo 2002/2003 Portal de

2 Introdução O objectivo do projecto é a realização de um portal de jogos (PJ). O PJ é um repositório de jogos organizados por categorias 1. Pretende-se que, com o sistema a desenvolver, se possam executar um conjunto abrangente de operações de gestão e utilização de um PJ através de um sítio web. Os alunos deverão utilizar os conhecimentos adquiridos ao longo do semestre: HTML; CSS; Java; Applets; JSP; Servlets; JDBC. Arquitectura A arquitectura geral do sistema consiste numa arquitectura cliente/servidor web. O servidor web deve conter um container para execução das servlets ou Java Server Pages. O Apache Tomcat pode ser utilizado para este efeito. Os dados persistentes do sistema devem ser mantidos em ficheiros ou numa base de dados relacional. A aplicação deverá ter duas zonas distintas: Zona de Administração O portal de jogos deverá ter uma área de administração que contenha as seguintes funcionalidades: Adicionar jogos. Cada jogo deve pertencer a uma categoria, e deve ter mais informação associada, p.e. uma breve descrição do jogo, o nome do autor, o e- mail, uma imagem etc. Realizar toda a gestão das várias funcionalidades do portal, p.e. apagar um jogo que tenha sido anteriormente adicionado, alterar informação relativa a um jogo, etc. Todas as interacções entre o administrador e o servidor devem ser, preferencialmente, autenticada com palavras-passe. Para simplificar, considere que o sistema será executado num ambiente sem restrições impostas por firewalls. Portal de Jogos O acesso é feito pelos utilizadores normais e é constituído por quatro níveis distintos: Entrada do portal. Consiste na primeira página que o utilizador vizualiza quando acede ao site. Deve permitir que o utilizador aceda às categorias dos jogos. Também pode conter os últimos jogos adicionados, um top de downloads, etc. O login/password deve estar presente nesta página. Categorias de jogos. Deve conter todas as categorias de jogos que foram criadas na zona de administração. 1 É desejável utilizar a estrutura realizada no 1º Trabalho da disciplina 2/

Os alunos deverão utilizar os conhecimentos adquiridos ao longo do semestre: HTML; CSS; Java; Applets; JSP; Servlets; JDBC.

3 Zona de jogos. Deve permitir que o utilizador vizualize toda a informação associada aos jogos que pertençam a uma dada categoria. Zona de compras. Deve existir um carrinho de compras associado ao cliente. O carrinho permite as seguintes operações: o Inserir e remover itens do carrinho; o Listagem do conteúdo com os custos parciais e total. Zonas adicionais com funcionalidades extras ficam ao critério dos alunos. As operações realizadas pelos utilizadores normais são feitas através da navegação do sítio web. 3/

O carrinho permite as seguintes operações: o Inserir e remover itens do carrinho; o Listagem do conteúdo com os custos parciais

4 Requisitos Tecnológicos da aplicação a desenvolver A aplicação deverá ser implementada segundo uma arquitectura multi-camada com a interface com o utilizador na Web, lógica de negócio numa camada intermédia e o suporte para dados persistentes num Sistema de Informação (ficheiros; BD relacional). Armazenamento de dados O armazenamento de dados da aplicação poderá ser efectuado de dois modos: Em ficheiro Em base de dados (neste caso deve ser usada a base de dados relacional ACCESS). Fica ao critério dos alunos utilizar um ou outro modo de armazenamento. O armazenamento de dados, caso seja uma SGBD, deverá ser acedida, directa ou indirectamente, através de uma ligação JDBC. Lógica de Negócio A lógica de negócio pode ser suportada em Beans, invocados pelas páginas JSP da interface, através de da acção <usebean...>. Podem existir servlets de controlo no caso de ser adoptado o Modelo 2 (MVC) para arquitectura da aplicação, ou para outros fins. Um Bean pode usar outros Beans para realizar uma dada função; por exemplo, um Bean centraliza a ligação à Base de Dados através de JDBC. Informação de estado deve ser passada entre páginas JSP ou Beans através da utilização de sessões. Por exemplo, uma vez introduzido o userid e validado o utilizador todas as verificações de acesso deverão ser feitas com recurso à sessão. Um outro exemplo de utilização de sessões é o da ligação JDBC à Base de Dados que, uma vez estabelecida, será usada por todos os pedidos posteriores, do mesmo cliente, para aceder à Base de Dados. Interface com o Utilizador A aplicação deve utilizar o html criado no primeiro projecto. A interface com o utilizador deverá ser conseguida com recurso a páginas estáticas em HTML ou a páginas JSP com conteúdo gerado dinamicamente. Admite-se que, nos casos em que é necessária interactividade, sejam incluídos Applets. Os dados introduzidos em formulários poderão ser validados, no cliente (Navegador), através da utilização de Javascript. De forma a manter um estilo consistente em toda a aplicação e para este ser facilmente alterável, deverão ser usadas folhas de estilo CSS (Cascading Style Sheets). As folhas de estilo devem ser externas. Deve ser considerado a possibilidade do administrador poder seleccionar a folha de estilo activa. Deve ser disponibilizada pelo menos duas folhas de estilo. As páginas JSP devem lidar exclusivamente com a interface e delegam em Beans a realização de todas as operações, nomeadamente o acesso ao armazenamento de dados para procura ou actualização de informação. As páginas Web desenvolvidas devem seguir boas práticas de desenvolvimento de forma a respeitar os princípios sobre "Acessibilidade e Facilidade de Utilização". 4/

Armazenamento de dados O armazenamento de dados da aplicação poderá ser efectuado de dois modos: Em ficheiro Em base de dados (neste caso deve ser usada a base de dados relacional ACCESS).

5 Avaliação Realização e Entrega O trabalho final deve ser efectuado pelos grupos já constituídos. O trabalho deverá ser entregue até ao dia 17 de Janeiro 2, durante as horas de expediente. Deve ser entregue um envelope, indicando a Turma, o número dos elementos do grupo, contendo uma diskette ou CD com uma versão electrónica e outra em papel dos documentos a entregar. Deve ser entregue todo o código devidamente comentado. O código deve ser entregue em dois formatos: Numa estrutura de directório, pronta a ser executada no servidor Tomcat e que inclua o ficheiro web.xml, e num ficheiro WAR. Caso seja utilizado uma base de dados relacional, ela deve ser incluída. Visualização O projecto será visualizado exclusivamente em PC, usando o navegador WWW Microsoft Internet Explorer executando-se sobre o sistema operativo Microsoft Windows XP e com o servidor Tomcat e base de dados relacional Access. Critérios de Avaliação 3 1. Armazenamento de dados 4 valores 2. Lógica de negócio 5 valores 3. Interface com o utilizador 4 valores 4. Administração 2 valores 5. Criatividade 2 valores 6. Defesa do Projecto 3 valores 2 A entregue do projecto deve ser feito no secretariado do DSI. 3 Apesar de o trabalho ser de grupo, cada aluno, a título individual, tem a responsabilidade de responder por todo o trabalho. Assim é indispensável que todos os membros de cada grupo programem efectivamente. 5/

Deve ser entregue todo o código devidamente comentado. O código deve ser entregue em dois formatos: Numa estrutura de directório, pronta a ser executada no servidor Tomcat e que inclua o ficheiro web.

6 Estrutura do relatório Relatório de Requisitos 1. Introdução 2. Objectivos 3. Requisitos Funcionais a. Mínimos b. Não Mínimos 4. Requisitos não funcionais a. Usabilidade b. Fiabilidade c. Desempenho d. Manutenção 5. Modelo de Casos de Uso a. Diagrama de Casos de Uso b. Actores c. Casos de Uso 6. Modelo de Objectos do Domínio a. Diagrama b. Descrição 2) Relatório de Implementação 1. Arquitectura lógica 2. Arquitectura física 3. Modelo de Objectos 4. Modelo Dinâmico 5. Escolha da Tecnologia 6/

Modelo de Casos de Uso a. Diagrama de Casos de Uso b. Actores c. Casos de Uso 6. Modelo de Objectos do Domínio a.

Documentos relacionados

Desenvolvimento de uma Aplicação WEB para monitorização de BD Oracle

Desenvolvimento de uma Aplicação WEB para monitorização de BD Oracle Luís Filipe Borges Pinto Resumo: Este projecto consiste na implementação de uma aplicação WEB para monitorização