doc

Gestão de Projectos de Software
Licenciatura em Engenharia Informática e Computação
Faculdade de Engenharia da Universidade do Porto
Projecto SAPIENS
Sistema de Avaliação Assistida por Computador
RELATÓRIO DE ESPECIFICAÇÃO DE TRABALHO PARA FORA
2000/11/06
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
GRUPO DE PROJECTO
Chefe (Gestor de Projecto)
Rui Pereira
Secretária
Sandra Oliveira
Controlo da Qualidade/Auditor
Miguel Teixeira
Analistas/Arquitectos
Artur Matos
Nuno Costa
Programadores
João Pires
Luís Almeida
GPS 2000/2001
2
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
ÍNDICE
1.
INTRODUÇÃO
5
2.
O PROJECTO
6
2.1.
Descrição geral
6
2.2.
Tecnologia
7
2.3.
Arquitectura física
8
3.
ESPECIFICAÇÃO
4.
CONCLUSÃO
10
5.
BIBLIOGRAFIA
11
6.
APÊNDICES
12
6.1.
9
Vocabulário do sistema
12
6.2.
Casos de uso relevantes
6.2.1.
Gerir Disciplinas
6.2.2.
Gerir assuntos
14
14
24
6.3.
Modelo de objectos
6.3.1.
Pacote Admin (camada de interface)
6.3.2.
Pacote Docente (camada de interface)
6.3.3.
Pacote Disciplinas (camada de middle-tier)
29
29
32
34
6.4.
Enterprise Java Beans (Exemplo)
6.4.1.
Disciplina.java
6.4.2.
DisciplinaBean.java
6.4.3.
DisciplinaHome.java
6.4.4.
DisciplinaPK.java
6.4.5.
DisciplinaServlet.java
35
36
37
38
39
40
GPS 2000/2001
3
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Resumo
Este relatório contém a expecificação do trabalho a desenvolver do exterior do projecto SAPIENS,
bem como uma apresentação geral do projecto de modo a conseguir enquadrar o grupo responsável pela
implementação. Este implementação consiste no desenvolvimento de parte da camada superior (interface
HTML) para assuntos, utilizadores e disciplinas. Um pequeno conjunto de páginas HTML do que é
pretendido e uma camada middle-tier mínima para testes é fornecida adicionalmente a este relatório. Do
trabalho subcontratado é esperado conformidade com o comportamento dos casos de uso implicados e
estima-se um esforço de implementação na ordem das 25 horas. Fornece-se em apêndice excertos dos
casos de uso, classes e vocabulário relevantes para a implementação, retirados dos relatórios produzidos
anteriormente para o projecto. Um pequeno exemplo de como usar Enterprise Java Beans (exemplo de
disciplinas) também está incluido.
GPS 2000/2001
4
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
1. Introdução
Este relatório corresponde à especificação do trabalho a desenvolver exteriormente ao projecto SAPIENS. O
objectivo geral deste relatório é apresentar de uma forma integral toda a informação necessária a um leitor externo ao
projecto, de modo a permitir a este implementar sem ambiguidades o pretendido. Para isso este relatório contém
partes integrais de outros anteriores, nomeadamente o de especificação de requisitos e o de projecto de alto nível. As
partes relevantes para o trabalho pretendido estão incluídas integralmente neste relatório, no entanto consideram-se
referências obrigatórias em caso de qualquer dúvida de implementação.
Nas secções seguintes irá-se primeiramente detalhar o projecto em causa, de modo a permitir ao leitor ter uma
ideia geral de onde a sua implementação se insere. Considera-se por ordem, a arquitectura lógica, tecnologia usada e
a arquitectura física do projecto. Depois de detalhado o projecto, será considerada a implementação exterior em
causa, e descrita explicitamente o que é pretendido implementar. Em apêndices encontram-se excertos relevantes dos
outros relatórios anteriores, e um pequeno exemplo de como usar Enterprise Java Beans (a tecnologia de
componentes usada neste trabalho).
GPS 2000/2001
5
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
2. O projecto
2.1. DESCRIÇÃO GERAL
O projecto SAPIENS consiste num programa para auto-avaliação assistida por computador através de WWW.
Permite manter questionários com perguntas de vários tipos (escolha múltipla, resposta em campo, etc...), avaliar e
manter históricos de avaliações anteriores. Este projecto é baseado num anterior designado WebQuiz, desenvolvido
em PHP com PostgresSQL como base de dados. No entanto, apenas algum do design anterior é aproveitado, e
nomeadamente nenhuma implementação do projecto anterior é usada.
O sistema está organizado em torno de 3 níveis distintos de utilizadores: alunos, docentes e admnistrador. O
docente está encarregado de inserir questionários e perguntas no sistema, que posteriormente serão respondidas pelos
alunos. O administrador gere o restante do sistema.
Existem vários tipos de questionários e perguntas possíveis no sistema, os quais não iremos detalhar aqui. As
perguntas estão adicionalmente agrupadas em assuntos, que por sua vez estão agrupadas em disciplinas (ver diagrama
de classes referente ao pacote disciplinas, nos apêndices).
2.2. ARQUITECTURA LÓGICA
Este projecto segue uma arquitectura tipicamente denominada three-tier, ou seja organizada em 3 camadas : uma
camada de dados, uma de negócio, e uma camada de apresentação. Todas estas camadas estão construidas baseadas
umas sobre as outras, e cada uma só dialoga com a sua imediatamente anterior.
A camada de dados é responsável por manter a persistência da aplicação e portanto só contém os dados em cru.
Tipicamente, e no nosso caso, essa camada é implementada através de uma base de dados relacional.
A camada de middle-tier funciona como uma ponte entre a camada inferior e a de apresentação. Construída
sobre a a camada de dados, esta camada contém a lógica da aplicação e fornece um meio de acesso à informação
persistente presente na camada anterior, bem como alguma eventual informação transiente.
Por fim a camada de apresentação contém a interface do programa.
GPS 2000/2001
6
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Base de dados
Middle-tier
Interface HTML
2.3. TECNOLOGIA
O projecto está todo assente na linguagem Java para as duas camadas superiores, enquanto, que tal como no
projecto anterior, a persistência da aplicação é obtida através de PostgresSQL.
O comportamento dinâmico da camada de interface é implementado através de servlets. Cada servlet traduz
os pedidos dos utilizadores e comunica com a camada de middle-tier de acordo com a arquitectura.A escolha do
servidor HTTP para correr as servlets recaiu no servidor java Tomcat.
A camada de middle-tier está baseada numa arquitectura de componentes Java, denominada Enterprise Java
Beans (mais vulgarmente conhecida por EJB). Esta arquitectura foi desenvolvida para facilitar o desenvolvimento de
componentes facilmente reutilizáveis e para implementar lógica de aplicações.
A implementação de um bean envolve escrever duas interfaces e uma classe: a interface remota, com a
declaração dos métodos que o bean fornece; a interface Home, com os métodos para criar, remover e encontrar uma
determinada instância do bean; a classe de implementação, onde a lógica é implementada.
Para usar EJBs é necessário um servidor de aplicações que implemente o standard de EJBs. No nosso caso
o servidor usado é um software open-source denominado JBoss.
Nenhum conhecimento para construir EJBs será necessário ao grupo encarregado deste trabalho externo. No
entanto, algum conhecimento para lidar com EJBs será preciso; Em princípio, os exemplos contidos neste relatório
serão suficientes para a realização do trabalho.
GPS 2000/2001
7
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
2.4. ARQUITECTURA FÍSICA
Cliente HTML
Servidor HTTP
Servidor Aplicações
Servidor Base de dados
Dispositivo
WAP
T omcat
JBoss
PostgreSQL
Gateway WAP
A arquitectura apresentada está de acordo com a escolha realizada em termos tecnológicos, e é completamente
suportada pela combinação escolhida:

Cliente HTML: representa um cliente que se liga ao sistema através de uma rede. O cliente HTML é
representado como um processador, visto que lhe é exigida alguma capacidade de execução, por forma a
suportar applets, ou mesmo algumas validações, conforme apresentado na apresentação da tecnologia. De notar
que a ligação do cliente HTML ao sistema é simplesmente ao servidor de HTTP, não interagindo com qualquer
outra camada.

Servidor HTTP: trata-se da máquina onde será executado o servidor Tomcat, para fornecer o serviço HTTP aos
clientes. Em relação ao sistema operativo a utilizar, deixámos grande liberdade ao administrador, visto que se
trata de um servidor inteiramente escrito em Java. No entanto, por motivos de custos, aconselhámos o uso do
Linux. É neste nodo que será colocado o componente sapiens.war, com todas as classes e recursos necessários
ao funcionamento da interface gráfica.

Servidor de Aplicações: máquina onde é executado o servidor jBoss, encarregue de disponibilizar o serviço de
EJB, bem como os componentes com a lógica de negócio do sistema. As mesmas considerações quanto ao
sistema operativo são igualmente válidas, pelo que aconselhámos o Linux pelos mesmo motivo. Neste nodo será
colocado um componente sapiens.jar, com todos os componentes EJB implementando o middle-tier.

Servidor de Base de Dados: máquina onde se executa a base de dados relacional, como o PostgreSQL. Neste
caso, é aconselhável o uso do sistema operativo Linux.
Conforme já indicado, o sistema final é muito flexível. Pode ir de uma configuração tão complexa como a
apresentada, para uma instalação em que todos os processos servidores se encontram configurados na mesma
máquina: esta solução é especialmente indicada por permitir uma redução no custo de hardware necessário, bem
como uma redução nos custos de administração.
GPS 2000/2001
8
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
3. Especificação
Todo o trabalho a ser desenvolvido para o exterior corresponde a componentes da camada superior, isto é, à
interface HTML. Concretamente pretende-se que o grupo responsável implemente as interfaces completas para
manipulação de algumas entidades do sistema, nomeadamente assuntos, disciplinas e utilizadores .
Adicionalmente a este relatório, irá ser fornecido os seguintes auxiliares para o grupo encarregue da implementação:

Um conjunto de componentes EJBs necessários para implementar a interface activa. Estes incluem os
componentes directamente dependentes da implementação exterior, como disciplinas, assuntos e utilizadores,
além de outros componentes eventualmente necessários.

Código adicional utilitário, por exemplo, código para lidar com logins e determinar o utilizador corrente. Este
código pode estar eventualmente vazio, servindo apenas para definir a interface a usar. Independentemente do
contéudo do código, a implementação deve ser rigorosamente testada.

Um conjunto de páginas HTML representando o conteúdo estático da interface. Estas páginas definem
rigorosamente a colocação dos botões, controles, etc.., e contém exemplos do comportamento dinâmico
esperado. Este conteúdo estático deve ser duplicado no código da servlet correspondente.
Este conjunto indicado em cima, aliado a este relatório e definição de casos de uso em apêndice, são suficientes
para definir univocamente o pretendido a implementar. Estima-se o esforço total de implementação em 25 horas,
tempo que incluí a instalação e configuração do testbed (JDK+JBoss+Tomcat+Postgres), programação e teste. Esta
estimativa têm em conta eventuais dificuldades e atrasos de configuração e utilização do testbed, o e uso dos
componentes EJB.
As servlets implementadas devem estar de acordo com os casos de uso em apêndice e devem ser rigorosamente
verificadas contra eles. As servlets devem ser também testadas extensivamente contra erros, quer erros de interface
com os componentes EJB, quer erros de lógica inerentes às próprias.
As servlets devem ser entregadas em código fonte, compilável sem erros e devidamente comentadas e identadas.
GPS 2000/2001
9
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
4. Conclusão
Com este relatório está completamente especificado o trabalho a desenvolver no exterior. Cremos que a parte
mais complexa desta especificação consiste em instalar e configurar a tecnologia necessária para testar a
implementação. Inclusive, essa parte pode exceder em tempo útil o tempo de implementação concreta.
GPS 2000/2001
10
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
5. Bibliografia

“Relatório de análise de requisitos”, Projecto Sapiens, 2000

“Relatório de projecto de alto nível”, Projecto Sapiens, 2000
GPS 2000/2001
11
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
6. Apêndices
6.1. VOCABULÁRIO DO SISTEMA
login: Acto de autenticação perante o sistema, onde o utilizador deverá indicar o seu nome e password para ter
acesso às suas funcionalidades inerentes.
assunto: Entidade classificadora de perguntas. Todas as perguntas estão agrupadas por assuntos.
disciplina: Unidade agregadora de assuntos .Uma disciplina pode conter vários assuntos.
utilizador: qualquer entidade que possa utilizar o sistema (aluno, docente ou administrador).
aluno: Utilizador encarregado principalmente de responder a inquéritos.
docente: Utilizador encarregue principalmente de construir questionários para os alunos.
administrador: Entidade com maior poder no sistema. Encarregado de gerir o sistema.
GPS 2000/2001
12
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
questionário: Um conjunto de perguntas para serem respondidas por alunos. Os questionários são construídos
pelos professores.
identificador: Uma cadeia de caracteres alfanumérica que identifica unicamente uma entidade de um tipo
presente no sistema. Normalmente uma pequena descrição que aparece em listas quando é necessário para o
utilizador escolher uma entidade.
pergunta: Unidade básica do sistema, agregados em questionários.
pergunta de escolha múltipla: Pergunta onde existem 2 ou mais escolhas para resposta. Apenas uma delas
está correcta.
pergunta de selecção múltipla: Pergunta onde existem 2 ou mais escolhas para resposta, mais do que uma
eventualmente correcta. É necessário para o aluno indicar todas as que estão correctas.
pergunta com resposta em campo: Pergunta onde é necessário ao aluno responder textualmente numa caixa
de texto.
pergunta com avaliação definida pelo utilizador: Pergunta que contém associada código (um programa) de
avaliação fornecida pelo docente.
grau de dificuldade: Escala numérica usada para classificar as perguntas de acordo com a sua dificuldade
relativa. É uma escala logarítmica, de 1 a 5, onde 5 corresponde à dificuldade mais alta (por exemplo uma pergunta
de dificuldade 2 equivale a 2 de dificuldade 1 para o sistema).
questionário corrido: Questionário onde as perguntas são todas respondidas de seguida, com os resultados
mostrados apenas no fim. Oposto do questionário tipo concurso.
questionário tipo concurso: Questionário onde não é possível passar à próxima pergunta sem ter respondido
correctamente à corrente.
questionário com perguntas fixas: Questionário onde as perguntas são previamente escolhidas pelo docente.
questionário com perguntas aleatórias: Questionário onde as perguntas são escolhidas aleatoriamente pelo
sistema
questionário com perguntas agrupadas por classificação: Questionário onde as perguntas são agrupadas de
acordo com o seu grau de dificuldade, e onde é atribuído uma classificação a cada grau.
GPS 2000/2001
13
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
6.2. CASOS DE USO RELEVANTES
Projecto Sapiens
Gerir
Disciplinas
Gerir Historico
Gerir
Utilizadores
Administrador
Responder a
Questionários
Gerir Assuntos
Aluno
Gerir perguntas
Docente
6 .2 .1 .
Gerir
questionários
GERIR DISCIPLINAS
Optámos por representar a gestão de disciplinas como um pacote em separado dos restantes, por representar
uma unidade funcional distinta. Em geral, todos os módulos envolvendo operações típicas de gestão em torno de uma
entidade (criar, modificar, apagar), receberam o mesmo tratamento, sendo representados por um pacote em separado.
O administrador é o único actor que interage com esta parte do sistema. É da responsabilidade deste indicar quais as
disciplinas a disponibilizar, eliminando-as sempre que não são mais necessárias.
6.2.1.1
Criar Disciplina
Este caso de uso corresponde à criação no sistema de uma disciplina.
A criação da disciplina corresponde a um processo sensivelmente standard: o administrador deve realizar login,
que o sistema irá validar. A partir deste ponto, este deverá apresentar a intenção de criar uma nova disciplina.
GPS 2000/2001
14
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Adicionalmente, introduzirá o nome e o departamento da disciplina. Como resposta, o sistema será actualizado,
sendo apresentada uma confirmação do mesmo ao utilizador.
Nesta situação, deverá ser verificado pelo sistema a existência de uma disciplina com o mesmo nome e o
mesmo departamento, sendo a inserção de duplicados proibida.
Este caso de uso não foi previsto no projecto anterior, por não preverem a existência de administrador e de
funções de administração.
Sistema
: Administrador
Pedido de Login e Password
Inserir Login e Password
Valida Login e
Validar Login e Password
Inserir Nova Disciplina
Inserir Nome
Inserir Departamento
Actualizar
Confirmação da Inserção
6.2.1.2
Apagar Disciplina
No situação de uma disciplina não ser mais necessária, o administrador deverá apagá-la. Este deverá também
inicialmente autenticar-se no sistema, com o recurso ao login e password. Se válidos, o sistema apresentará a
confirmação da validade destas, e o utilizador irá indicar que pretende apagar uma disciplina. Após a apresentação de
uma lista com as disciplinas disponíveis, o administrador seleccionará a disciplina a apagar. Por ser uma operação
sem retorno, o sistema deverá requerer a confirmação; após a mesma ser enviada, a disciplina será eliminada, e o
utilizador será informado deste facto.
No caso da disciplina ter associadas perguntas, estas serão também eliminadas.
Este caso de uso não foi previsto no projecto anterior, por não preverem a existência de administrador e de
funções de administração.
GPS 2000/2001
15
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Sistema
: Administrador
Pedido de Login e Password
Inserir Login e Password
Valida Login e
Validar Login e Password
Apagar Disciplina
Lista de Disciplinas
Seleccionar Disciplina
Pedido Confirmação
Confirmar Eliminação
Actualizar
Confirmação da Eliminação
6.2.1.3
Modificar Disciplina
O caso de uso modificar disciplina permite ao utilizador a modificar a informação introduzida anteriormente.
Conforme iremos apresentar nos requisitos não-funcionais, corresponde à implementação de alguns destes, sobretudo
os relacionados com a usabilidade.
Neste caso de uso, o utilizador, após autenticação e correspondente validação pelo sistema, requer a
modificação de uma disciplina, seleccionando-a a partir de uma lista apresentada pelo sistema. O utilizador deve
depois inserir o nome e o departamento ao qual esta pertence. O sistema deve apenas permitir a alteração se não
existir outra disciplina com o mesmo nome, e pertencendo ao mesmo departamento. Se este conflito não se verificar,
a disciplina será modificada, e o administrador receberá uma confirmação deste facto.
A acção de modificar uma disciplina não deve interferir com a restante informação presente no sistema, isto é,
não deve alterar as perguntas, questionários, professores ou alunos.
Este caso de uso não foi previsto no projecto anterior, por não preverem a existência de administrador e de
funções de administração.
GPS 2000/2001
16
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Sistema
: Administrador
Pedido de Login e Password
Inserir Login e Password
Valida Login e
Validar Login e Password
Modificar Disciplina
Lista de Disciplinas
Seleccionar Disciplina
Inserir Nome
Inserir Departamento
Actualizar
Confirmação da Modificação
6.2.1.4
Gerir Utilizadores
A gestão de utilizadores é uma parte importante de qualquer sistema não trivial. Por constituir um módulo
separado em relação ao restante sistema, optámos por dividi-lo num módulo, à semelhança da gestão de disciplinas.
O projecto Webquiz não tomou conta da necessidade de funções de administração durante a fase de especificação de
requisitos, pelo que, à semelhança da gestão de disciplinas, não apresentarem nada comparável a este pacote de casos
de uso.
Ao contrário da gestão de disciplinas, o administrador não é o único que interage com esta secção do sistema,
sendo alguns casos de uso também utilizados por alunos e professores.
GPS 2000/2001
17
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Apagar Utilizador
Registar Professores
Administrador
(from Use Case View)
Associar Professor a Disciplina
Alterar Password
<<include>>
Registar Aluno
Modificar Informação Utilizador
Aluno
(from Use Case View)
6.2.1.5
Registar Aluno
O caso de uso registar aluno é executado pelos alunos, que pretendem utilizar o sistema. Em geral, qualquer
utilizador que pretenda utilizar o sistema, pode utilizar o registo de alunos, criar um login válido e utilizar o sistema
de seguida. Este caso de uso, ao contrário da totalidade dos anteriores, não necessita de autenticação perante o
sistema. No entanto, visto que apenas os utilizadores registados podem utilizar o sistema, todos terão que recorrer a
esta funcionalidade.
Inicialmente, o utilizador deve indicar ao sistema que pretende registar-se como aluno. O aluno deve depois
introduzir o login, nome, email, password (com confirmação), e departamento. A password não será visível, sendo
este repetida e inserida como confirmação. Após a introdução na totalidade destes campos, o sistema deve verificar se
toda informação foi inserida, se o login ainda não existe, e se as passwords inseridas são idênticas. Na situação de
tudo estar correctamente inserido, é apresentada uma confirmação ao utilizador.
Este caso de uso foi previsto no projecto anterior. É apresentado no diagrama de casos de uso, com o nome
registo de utilizadores. Quanto aos requisitos, foi enumerado como “O sistema deve suportar o registo de
utilizadores”. No entanto, neste ponto apenas é referido a criação de um login e uma password de acesso.
GPS 2000/2001
18
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Sistema
: Aluno
Pedir Registo Sistema
Inserir Login
Inserir Nome
Inserir Email
Inserir Password
Inserir Password Novamente
Inserir Departamento
Actualizar
Confirmação da Inserção
6.2.1.6
Registar Professor
O registo de professores não é executado pelos próprios professores, conforme enunciado na versão inicial da
especificação de requisitos do projecto Webquiz. Em vez disso, o professor deve enviar um email ao administrador,
que procede depois ao registo do professor no sistema. Esta interacção entre actores, sob a forma de email, é externa
ao sistema, pelo que não é por nós considerada enquanto caso de uso. Em vez disso, devemos especificar
correctamente a utilização do registo de professores por parte do administrador.
O registo de professores é semelhante ao registo de alunos. No entanto, porque apenas pode ser realizado pelo
administrador, requer a autenticação prévia deste perante o sistema. Assim, após a inserção do login e password, e
respectiva validação, o administrador deve requerer o registo de um novo professor. Deve depois inserir o login
pretendido, o nome, o email e o departamento ao qual pertence. Após validação desta informação (deve estar
completamente preenchida, e o login não pode já existir), o sistema é actualizado, uma confirmação da operação é
GPS 2000/2001
19
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
apresentada ao administrador, e um email é enviado ao professor, com a informação do seu registo e com a password
gerada automáticamente pelo sistema.
Este caso de uso não foi previsto pelo projecto anterior, na fase de especificação de requisitos inicial, tendo sido
depois apresentado como alteração.
Sistema
: Administrador
: Professor
Pedido de Password
Pedido de Logi n e Password
Inserir Logi n e Password
Valida Login e
Validar Logi n e Password
Inserir Utilizador
Inserir Login
Inserir Nome
Inserir Email
Inserir Departamento
Inserir Tipo Uti lização como Professor
Actualizar
Confirmação da Inserção
Confirmação de Criação por email
6.2.1.7
Modificar Informação Utilizador
Por forma a permitir correcções às informações pessoais inseridas por utilizador, o sistema deve suportar a
modificação das mesmas. Isto é permitido através do caso de uso “Modificar Informação Utilizador”, permitido a
cada um dos utilizadores no sistema (administrador, professor e aluno).
Por se tratar da gestão de informação pessoal, o caso de uso necessita da autenticação inicial do utilizador
perante o sistema, com a introdução do login e da password. Após validação por parte do sistema, o utilizador pede
para modificar a informação associada a si próprio. Como resposta, o sistema apresentará a informação anteriormente
inserida para o utilizador, à excepção da password. O utilizador irá alterar a informação pretendida, à excepção do
login. No caso da informação ser válida (todos os campos preenchidos), o sistema irá ser actualizado.
GPS 2000/2001
20
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Esta situação foi prevista pelo projecto Webquiz, ao enunciar que “um utilizador pode em qualquer altura alterar
os seus dados pessoais na BD”.
Alternativamente, o administrador poderá alterar a informação para um determinado utilizador. Neste caso, há
lugar a uma fase intermédia de selecção do utilizador a modificar. O administrador deverá escolher o utilizador a
modificar a partir de uma lista de todos os utilizadores registados.
Esta situação não foi prevista pelo projecto Webquiz.
Sistema
: Aluno
Pedido de Login e
Inserir Login e
Valida Login e
Validar Login e
Modificar Informação
Informação
Inserir
Inserir
Inserir
Inserir
Inserir Password
Inserir
Inserir
Actualizar
Confirmação da
6.2.1.8
Alterar Password
A alteração de informação pessoal não permite a alteração da password, que optámos por representar como um
caso de uso em separado. Esta foi a opção também tomada pelo projecto Webquiz, sendo a alteração da password um
processo separado da alteração da informação pessoal.
Neste caso, a alteração da password foi representada como sendo um caso de uso incluído na alteração de
informação pessoal.
GPS 2000/2001
21
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Na primeira situação, o utilizador opta por alterar a sua própria palavra chave. Neste caso, deve primeiro
autenticar-se, através do login e password. Após validados, deve indicar a intenção de alterar informação pessoal.
Após este ponto, indica a intenção de alterar a palavra chave, introduzindo depois a nova password juntamente com a
confirmação. Nenhum dos dois campos será visível, e ambos deverão ser idênticos. Caso assim seja, o sistema
confirma a alteração realizada.
Esta situação encontra-se prevista na especificação de requisitos do projecto Webquiz.
De forma alternativa, o administrador pode realizar ele mesmo a alteração da password para um utilizador em
concreto. Esta situação é útil sempre que este perca a password, podendo assim requisitar uma nova para utilização
do sistema. Após a autenticação como administrador, o utilizador deve proceder de forma semelhante à alteração de
informações pessoais: seleccionar o utilizador a partir de uma lista apresentada pelo sistema, introduzir a password e
confirmação. Após a alteração do sistema, o utilizador verá uma confirmação da operação realizada.
Esta situação não foi prevista no projecto Webquiz.
Sistema
: Aluno
Pedido de Login e
Inserir Login e
Valida Login e
Validar Login e
Alterar Informações
Alterar
Nova Password
Confirmação
Actualizar
Confirmação da
GPS 2000/2001
22
Projecto SAPIENS
6.2.1.9
Relatório de Especificação do Trabalho para Fora
Associar Professor a Disciplina
Este caso de uso permite associar professores a disciplinas: desta forma um professor pode estar encarregue de
muitas disciplinas, ao mesmo tempo que uma disciplina pode ser responsabilidade de vários professores. Apenas os
profes sores associados a uma disciplina poderão realizar alterações sobre a mesma.
Após a inserção do login e password, e correspondente validação dos mesmos pelo sistema, o utilizar deve
indicar a atenção de associar um professor a uma disciplina. Após a apresentação de duas listas com as disciplinas e
os professores disponíveis, o administrador deverá seleccionar um elemento de cada uma destas. O sistema irá validar
a informação introduzida, e verificar se é válida: um par (professor, disciplina) idêntico não pode já existir. Assim, ao
professor será apresentado uma confirmação da informação introduzida.
Este caso de uso não foi modelado pelo projecto anterior, pois não reconheciam a necessidade de existência de
um administrador.
GPS 2000/2001
23
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Sistema
: Administrador
Pedido de Login e Password
Inserir Login e Password
Valida Login e
Validar Login e Password
Modificar Utilizador
Lista de Utilizadores
Seleccionar Utilizador a Modificar
Alterar Password
Nova Password
Confirmação
Actualizar
Confirmação da Alteração
6 .2 .2 .
GERIR ASSUNTOS
Os assuntos constituem as entidades organizadoras das perguntas a seguir às disciplinas. Ao contrário destas, os
assuntos podem ser geridos livremente pelos docentes (ver entrada relativa a assunto no glossário). Similarmente ao
que foi feito anteriormente, a sua gestão está contida num pacote separado.
GPS 2000/2001
24
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Gerir assuntos
Criar assunto
Modificar assunto
Docente
(from Use Case View)
Retirar assunto
6.2.2.1
Criar assunto
Insere um novo assunto no sistema. O procedimento é análogo aos outros casos de uso de tipo criar: O
utilizador faz login, indica o nome e a disciplina em que o novo assunto pertence. O sistema fornece o feedback
apropriado de acordo se a inserção foi feita com sucesso ou não. Inserções de assuntos duplicados não são permitidas
pelo sistema.
GPS 2000/2001
25
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Sistema
: Docente
Pedido de Login e Password
Inserir Login e Password
Valida Login e
Validar Login e Password
Inserir novo assunto
Inserir Nome
Escolher disciplina a que pertence
Actualizar
Confirmação da Inserção
6.2.2.2
Modificar assunto
A partir deste caso de uso é possível alterar os parâmetros associados a um dado assunto – o seu nome e
disciplina associada. Inicialmente o utilizador deverá fazer login no sistema, escolher o assunto pretendido (através da
disciplina e do nome). De seguida, o utilizador indica os novos parâmetros e o assunto é modificado após a
confirmação do sistema.
As alterações efectuadas nos assuntos não interferem com qualquer das entidades associadas a esta,
nomeadamente perguntas e disciplinas.
GPS 2000/2001
26
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Sistema
: Administrador
Pedido de Login e Password
Inserir Login e Password
Valida Login e
Validar Login e Password
Modificar Disciplina
Lista de Disciplinas
Seleccionar Disciplina
Inserir Nome
Inserir Departamento
Actualizar
Confirmação da Modificação
6.2.2.3
apagar assunto
Retira um determinado assunto no sistema. O utilizador deve indicar a partir da lista de assuntos, e após o login,
qual o assunto que pretende apagar. No entanto, só o permite retirar se o assunto se encontrar isolado, isto é, se não
existirem perguntas desse assunto nos questionários do sistema. Caso não existam, todas as perguntas associadas a
esse assunto serão também retiradas. O actor será avisado adequadamente em cada caso antes de ser permitido
prosseguir.
GPS 2000/2001
27
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
Sistema
: Docente
Pedido de Login e Password
Inserir Login e Password
Valida Login e Password
Validar Login e Password
Apagar assunto
Lista de assuntos
Seleccionar assunto
Pedido Confirmação
Confirmar Eliminação
Actualizar Sistema
Confirmação da Eliminação
GPS 2000/2001
28
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
6.3. MODELO DE OBJECTOS
6 .3 .1 .
PACOTE ADMIN (CAMADA DE INTERFACE)
O pacote admin é definido dentro de interface, e representa as classes necessárias para a implementação do
serviço de administração. Este pacote irá conter servlets, também organizadas uma por cada serviço de administração
disponiblizado: gestão de disciplinas, de utilizadores e de histórico. Apesar destas classes se encontrarem neste
pacote, serão acedidas por todos os utilizadores, e não apenas pelo administrador. Por exemplo, a servlet
GerirUtilizadores também será acedida pelos alunos e docentes para a modificação dos seus dados pessoais.
6.3.1.1
GerirUtilizador
A servlet GerirUtilizador fornece o serviço de gestão de utilizadores. Em geral, será invocada principamente
como resposta a funções de administração, mas não só, como apresentado na introdução do presente pacote.
6.3.1.1.1

Atributos
home: referência para a interface Home do componente Utilizador. Serve para evitar uma operação de naming
sempre que seja necessário aceder aos utilizadores.
GPS 2000/2001
29
Projecto SAPIENS
6.3.1.1.2

Relatório de Especificação do Trabalho para Fora
Operações
init(): Inicializa o estado da servlet, obtendo a referência para a interface Home de Utilizador, armazenando a
mesma no atributo home.

doPost(request : HttpServletRequest, response : HttpServletResponse): executa o serviço de gestão de
utilizadores. Trata-se apenas de um ponto de entrada para as diferentes hipóteses. Um parâmetro de HTTP, com
a chave “action”, deverá indicar o tipo de serviço a realizar. Se action for “listar”, será executado o método
listar(). Se for “apagar”, será executado apagar(), com os parâmetros preenchidos pelo correspondentes
parâmetros HTTP. Formas de proceder semelhantes são executadas para os restantes métodos da classe. O
parâmetro writer, presente em todos os métodos deverá ser preenchido com o resultado de response.getWriter():
representa a stream para onde será escrito o HTML gerado automáticamente. O método doPost também tem a
responsabilidade de verificar os níveis de acesso dos utilizadores. Por exemplo, apenas um administrador terá
acesso a listar, apagar e adicionar um professor. O caso de action ser “alterar” ou “alterarPassword” é permitido
apenas para o próprio utilizador (ou no caso de um administrador). “adicionar”, apenas pode adicionar
professores no caso do utilizador actual ser um administrador.

listar(writer : PrintWriter): gera uma lista dos utilizadores registados, sendo o resultado do HTML enviado
para o stream dado como parâmetro em writer. A lista gerada deverá conter uma tabela com os utilizadores
existentes: hipótese de selecção como uma checkbox; nome do utilizador, sendo este um link para a edição dos
seus dados (link deverá ser para GerirUtilizadores, com o parâmetro action=”ver”); email (com um link para o
envio de email para o utilizador).

apagar(writer : PrintWriter,login : String): elimina um utilizador do sistema, escrevendo uma confirmação
sob a forma de HTML para a stream writer. O utilizador a eliminar tem o login igual ao parâmetro login.

adicionar(writer : PrintWriter, login : String, nome : String, email : String, password : String,
departamento : String, aluno : boolean): cria um utilizador no sistema, sendo este um aluno se o parâmetro
aluno for verdadeiro, ou um professor, na situação contrária. Este método deverá criar uma nova instância de
Utilizador, preenchendo este com os parâmetros. No caso de password ser null, significa que a password não foi
indicada, pelo que deverá ser gerada uma password, e enviada ao utilizador utilizando o endereço de email
indicado.

alterar(writer : PrintWriter, login : String, nome : String, email : String, departamento : String): altera a
informação associada a um utilizador. Só pode ser invocada pelo próprio utilizador, ou no caso deste ser um
administrador. Deve escrever na stream writer uma confirmação da alteração

alterarPassword(writer : PrintStream, String login, String password): altera a password para um
determinado utilizador. Só pode ser invocada pelo próprio utilizador, ou no caso deste ser um administrador.
Deve escrever na stream writer uma confirmação da alteração.

ver(writer : PrintWriter, login : String): gera um documento HTML para alterar a informação de um
utilizador. Este deve ser enviado para a stream writer. O documento a gerar contem um form com a informação
do utilizador, previamente preenchida com os valores actuais. No caso de login ser null, a referida form deve ser
preenchida a branco, representado a inserção de um utilizador.
GPS 2000/2001
30
Projecto SAPIENS
6.3.1.2
Relatório de Especificação do Trabalho para Fora
GerirDisciplina
A servlet GerirDisciplina corresponde à implementação do módulo de gestão de disciplinas. Apenas os
administradores deverão utilizar a gestão de disciplinas, pelo que todos os restantes utilizadores estarão à partida
proibidos da sua utilização.
6.3.1.2.1

Atributos
home: referência para a interface Home do componente Disciplina. Serve para evitar uma operação de naming
sempre que seja necessário aceder às disciplinas.
6.3.1.2.2

Operações
doPost(request : HttpServletRequest, response : HttpServletResponse): executa o serviço da servlet,
separando convenientemente os parâmetros HTTP, e direccionando a execução para os restantes métodos. O
parâmetro que indica o serviço a executar será “action”, à semelhança do que já sucedia com a servlet
GerirUtilizadores. Ao contrário desta, apenas o administrador terá acesso a partir deste método.

init(): inicializa a servlet. Obtem uma referência para a interface Home de Disciplina, e armazena essa referência
em home. Desta forma, evitam-se operações de naming demasiado frequentes.

listar(writer : PrintWriter): lista as disciplinas existentes no sistema, para a stream de output definida pelo
parâmetro writer. As disciplinas deverão ser apresentadas como uma tabela, com uma coluna com uma checkbox
para selecção, uma coluna com o código como um link (este deverá estar ligado à edição da respectiva
disciplina), e uma coluna com o nome da disciplina.

apagar(writer : PrintWriter, codigo : String): elimina a disciplina com o código indicado do sistema. Para a
stream writer deve ser escrita uma confirmação sob a forma de um documento HTML.

adicionar(writer : PrintWriter, codigo : String, nome : String): adiciona uma disciplina ao sistema, com o
código e nome indicados pelo parâmetros respectivos. Deve escrever uma confirmação na stream writer.

alterar(writer : PrintWriter, codigo : String, nome : String): altera o nome definido para disciplina. Uma
conversão deverá ser escrita na stream writer, sob o formato HTML.

ver(writer : PrintWriter, codigo : String): escreve uma representação HTML para a stream writer com a
informação da disciplina. Este deve ser um form, com os campos preenchidos com os valores actuais. No caso
de codigo ser null, apresenta um documento para a inserção de uma nova disciplina, com os campos vazios.
6.3.1.3
GerirProfessorDisciplina
Esta classe é uma servlet que fornece o serviço de associação de professores a disciplinas. Apenas os professores
associados a uma determinada disciplina podem editar a informação relativa a essa disciplina: criar questionários,
lançar perguntas, etc.
GPS 2000/2001
31
Projecto SAPIENS
6.3.1.3.1

Relatório de Especificação do Trabalho para Fora
Atributos
home: referência para a interface Home do componente disciplina. Destina-se a evitar a realização de
operações naming sempre que é necessário utilizar as disciplinas.
6.3.1.3.2

Operações
doPost(request : HttpServletRequest, response : HttpServletResponse): executa o serviço da servlet,
realizando a separação do serviço a executar pelos restantes métodos da servlet. A separação é realizada através
do parâmetro “action”, que deverá ter uma string idêntica ao método a invocar. Por outro lado, todos os
parâmetros para a respectiva operação vão ser também obtidos a partir dos parâmetros de HTTP. Apenas ao
administrador deverá ser permitido o acesso a esta servlet.

init(): inicializa a referência remota para o a interface Home do componente Disciplina.

associar(writer : PrintWriter , loginProfessor : String , codigoDisciplina : String): associa o professor à
disciplina. Inicialmente, obtém a disciplina para codigoDisciplina. Seguidamente, deve associar a esta o
professor correspondente a loginProfessor.
6 .3 .2 .
PACOTE DOCENTE (CAMADA DE INTERFACE)
O pacote docente, integrado na interface, agrupa as funções que um professor executa perante um sistema.
Assim, é da sua responsabilidade a criação de assuntos, perguntas e de questionários, tudo sempre relativamente a
uma pergunta em concreto.
GPS 2000/2001
32
Projecto SAPIENS
6.3.2.1
Relatório de Especificação do Trabalho para Fora
GerirAssuntos
A servlet GerirAssuntos permite a gestão dos assuntos definidos no sistema. Os assuntos serão uma divisão
atribuída às perguntas, de acordo com a disciplina a que pertencem.
6.3.2.1.1

Atributos
home: referência para a interface Home do componente Assunto. Serve para evitar uma operação de naming
sempre que seja necessário aceder aos Assuntos.
6.3.2.1.2

Operações
doPost(request : HttpServletRequest, response : HttpServletResponse): executa o serviço da servlet,
separando convenientemente os parâmetros HTTP, e redireccionando a execução para os restantes métodos. O
parâmetro indicador do serviço a executar será “action”, à semelhança das anteriores servlets. Apenas os
professores terão acesso à servlet.

init(): inicializa a servlet. Obtem uma referência para a interface Home de Assunto, e armazena essa referência
em home. Desta forma, evitam-se operações de naming demasiado frequentes.

listar(writer : PrintWriter, codigoDisciplina : String): lista os assuntos existentes no sistema, para a stream
de output definida pelo parâmetro writer. Os assuntos deverão ser apresentados como uma tabela, com uma
coluna com uma checkbox para selecção, uma coluna com o código como um link (este deverá estar ligado à
edição da respectiva disciplina), e uma coluna com o nome.

apagar(writer : PrintWriter, codigo : String): elimina o assunto com o respectivo código do sistema. Para a
stream writer deve ser escrita uma confirmação sob a forma de um documento HTML.

adicionar(writer : PrintWriter, codigo : String, nome : String, codigoDisciplina : String): adiciona um
assunto ao sistema, com o código e nome indicados pelo parâmetros respectivos, e associado à disciplina
indicada. Deve escrever uma confirmação na stream writer.

alterar(writer : PrintWriter, codigo : String, nome : String): altera o nome definido para o assunto. Uma
confirmação deverá ser escrita na stream writer, sob o formato HTML.

ver(writer : PrintWriter, codigo : String): escreve uma representação HTML para a stream writer com a
informação da disciplina. Este deve ser um form, com os campos preenchidos com os valores actuais. No caso
de codigo ser null, apresenta um documento para a inserção de uma nova disciplina, com os campos vazios.
GPS 2000/2001
33
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
6.3.3. PACOTE DISCIPLINAS (CAMADA DE MIDDLE-TIER)
O pacote disciplinas contém as classes ligadas disciplinas, assuntos e utilizadores. Cada uma destas entidades é
demasiado simples para estar organizada em pacotes separados, por isso estão todas contidas neste pacote. Qualquer
uma destas estruturas é de fácil compreensão mediante o diagrama apresentado.
GPS 2000/2001
34
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
6.4. ENTERPRISE JAVA BEANS (EXEMPLO)
Esta secção contém um pequeno exemplo de definição e uso de EJBs, para o caso das disciplinas. O
código é praticamente autoexplicativo por si, por isso só iremos descrever o exemplo em geral.
DisciplinaHome.java contém a interface home para o componente Disciplina, enquanto que a remote está
definida em Disciplina.java. O exemplo essencial do uso destas duas interfaces está contido em
DisciplinaServlet.java. Em princípio, as classes a implementar seguem uma estrutura semelhante a esse
exemplo para aceder ao componente.
GPS 2000/2001
35
Projecto SAPIENS
6 .4 .1 .
Relatório de Especificação do Trabalho para Fora
DISCIPLINA.JAVA
import javax.ejb.EJBObject;
import java.rmi.RemoteException;
public interface Disciplina extends EJBObject {
public String getCodigo() throws RemoteException;
public String getNome() throws RemoteException;
public void setNome(String newValue) throws RemoteException;
}
GPS 2000/2001
36
Projecto SAPIENS
6 .4 .2 .
import
import
import
import
Relatório de Especificação do Trabalho para Fora
DISCIPLINABEAN.JAVA
javax.ejb.*;
java.rmi.RemoteException;
javax.naming.Context;
javax.rmi.PortableRemoteObject;
public class DisciplinaBean implements EntityBean {
public String codigo;
public String nome;
public DisciplinaPK ejbCreate(String newCodigo) {
codigo=newCodigo;
return null;
}
public void ejbPostCreate(String CodigoMoeda) throws CreateException {
}
// Keep the reference on the EntityContext
protected EntityContext entityContext;
protected Context namingContext=null;
public void ejbActivate() {
// Nothing to be done for this simple example.
}
public void ejbLoad() {
// Nothing to be done for this simple example, in implicit persistance.
}
public void ejbPassivate() {
// Nothing to be done for this simple example.
}
public void ejbRemove() throws RemoveException {
// Nothing to be done for this simple example, in implicit persistance.
}
public void ejbStore() {
// Nothing to be done for this simple example, in implicit persistance.
}
public void setEntityContext(EntityContext ctx) {
// Keep the entity context in object
entityContext = ctx;
}
public void unsetEntityContext() {
entityContext = null;
}
public String getCodigo() {
return codigo;
}
public void setCodigo(String newValue) {
codigo=newValue;
}
public String getNome() {
return nome;
}
public void setNome(String newValue) {
nome=newValue;
}
}
GPS 2000/2001
37
Projecto SAPIENS
6 .4 .3 .
import
import
import
import
Relatório de Especificação do Trabalho para Fora
DISCIPLINAHOME.JAVA
javax.ejb.*;
java.rmi.RemoteException;
javax.ejb.FinderException;
javax.ejb.CreateException;
public interface DisciplinaHome extends EJBHome {
public Disciplina
RemoteException;
create(String
codigo)
throws
CreateException,
public
Disciplina
findByPrimaryKey(DisciplinaPK
FinderException, RemoteException;
public
java.util.Enumeration
javax.ejb.FinderException, RemoteException;
}
GPS 2000/2001
findAll()
key)
throws
throws
38
Projecto SAPIENS
6 .4 .4 .
Relatório de Especificação do Trabalho para Fora
DISCIPLINAPK.JAVA
public class DisciplinaPK implements java.io.Serializable {
public DisciplinaPK() {
}
public DisciplinaPK(String codigo) {
this.codigo=codigo;
}
public String codigo;
public int hashCode() {
return codigo.hashCode();
}
//Metodo equals
public boolean equals(Object obj) {
DisciplinaPK other=(DisciplinaPK)obj;
return other.codigo.equals(codigo);
}
}
GPS 2000/2001
39
Projecto SAPIENS
6 .4 .5 .
import
import
import
import
import
import
import
import
import
Relatório de Especificação do Trabalho para Fora
DISCIPLINASERVLET.JAVA
java.io.IOException;
java.io.PrintWriter;
java.util.Enumeration;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
javax.naming.*;
javax.rmi.*;
/**
* Simple servlet to validate that the Hello, World example can
* execute servlets. In the web application deployment descriptor,
* this servlet must be mapped to correspond to the link in the
* "index.html" file.
*
* @author Craig R. McClanahan <[email protected]>
*/
public final class DisciplinaServlet extends HttpServlet {
DisciplinaHome home;
public void init() {
try {
System.setProperty("java.naming.factory.initial",
"org.jnp.interfaces.NamingContextFactory");
System.setProperty("java.naming.provider.url",
"localhost:1099");
InitialContext initial=new InitialContext();
home=(DisciplinaHome)PortableRemoteObject.narrow(initial.lookup("DisciplinaHome"),Discip
linaHome.class);
} catch (Exception e) {
e.printStackTrace();
}
}
protected void ver(PrintWriter writer) {
writer.println("<html>");
writer.println("<head>");
writer.println("<title>Sample Application Servlet Page</title>");
writer.println("</head>");
writer.println("<body bgcolor=white>");
writer.println("<table border=\"0\">");
writer.println("<tr>");
writer.println("<td>");
writer.println("<img src=\"images/tomcat.gif\">");
writer.println("</td>");
writer.println("<td>");
writer.println("<h1>Lista de disciplinas</h1>");
writer.println("</td>");
writer.println("</tr>");
writer.println("</table>");
writer.println("<table border=\"0\" width=\"100%\">");
try {
Enumeration discs = home.findAll();
while (discs.hasMoreElements()) {
Disciplina d = (Disciplina) discs.nextElement();
writer.println("<tr>");
writer.println(" <th align=\"right\">" + d.getCodigo() + ":</th>");
writer.println(" <td>" + d.getNome() + "</td>");
writer.println("</tr>");
}
GPS 2000/2001
40
Projecto SAPIENS
Relatório de Especificação do Trabalho para Fora
writer.println("</table>");
} catch (Exception e) {
e.printStackTrace(writer);
}
writer.println("</body>");
writer.println("</html>");
}
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
response.setContentType("text/html");
PrintWriter writer = response.getWriter();
String action=request.getParameter("action");
if (action==null || action.equals("ver")) {
ver(writer);
}
}
}
GPS 2000/2001
41