(→Utentes) |
(→Obras e Categorias) |
||
| Line 15: | Line 15: | ||
== Obras e Categorias == | == Obras e Categorias == | ||
| + | |||
| + | Cada obra é identificada por um número de obra. O identificador é atribuído automaticamente e incrementalmente (a partir de 0 ou do último valor atribuído, caso o estado do sistema tenha sido recuperado). | ||
As obras a considerar inicialmente são livros e DVDs. A mediateca pode manter vários exemplares de cada obra. A cada obra está associado um identificador único dentro do sistema, bem como o número de exemplares existentes no acervo. | As obras a considerar inicialmente são livros e DVDs. A mediateca pode manter vários exemplares de cada obra. A cada obra está associado um identificador único dentro do sistema, bem como o número de exemplares existentes no acervo. | ||
| AVISOS - Avaliação em Época Normal |
|---|
|
Esclarecimento de dúvidas:
|
|
Requisitos para desenvolvimento, material de apoio e actualizações do enunciado (ver informação completa em Projecto de Programação com Objectos):
|
|
Processo de avaliação (ver informação completa em Avaliação do Projecto):
|
| Material de Uso Obrigatório |
|---|
| As bibliotecas po-uuilib e o conteúdo inicial do CVS são de uso obrigatório: |
|
| A máquina virtual, fornecida para desenvolvimento do projecto, já contém todo o material de apoio. |
| Uso Obrigatório: Repositório CVS |
| Apenas se consideram para avaliação os projectos existentes no repositório CVS oficial.
Trabalhos não presentes no repositório no final do prazo têm classificação 0 (zero) (não são aceites outras formas de entrega). Não são admitidas justificações para atrasos em sincronizações do repositório. A indisponibilidade temporária do repositório, desde que inferior a 24 horas, não justifica atrasos na submissão de um trabalho. |
O objectivo do projecto é desenvolver um sistema para gerir o acervo de uma mediateca. O sistema deverá permitir, entre outras operações, (i) fazer pesquisas de obras; (ii) registar dados de utentes; (iii) registar dados de obras; e (iv) registar requisições de obras para consulta domiciliária.
Neste texto, o tipo negrito indica um literal (i.e., é exactamente como apresentado); o símbolo ␣ indica um espaço; e o tipo itálico indica uma parte variável (i.e., uma descrição).
Existem vários conceitos importantes neste contexto: obras e suas categorias, utentes, requisições e tempo.
Os conceitos listados não são os únicos possíveis no modelo e as suas relações (assim como relações com outros conceitos não mencionados) podem depender das escolhas do projecto.
Cada obra é identificada por um número de obra. O identificador é atribuído automaticamente e incrementalmente (a partir de 0 ou do último valor atribuído, caso o estado do sistema tenha sido recuperado).
As obras a considerar inicialmente são livros e DVDs. A mediateca pode manter vários exemplares de cada obra. A cada obra está associado um identificador único dentro do sistema, bem como o número de exemplares existentes no acervo.
Cada obra tem uma categoria, de acordo com o assunto nela tratado. Inicialmente, consideram-se as seguintes categorias: (i) obras de referência: onde se incluem dicionários, gramáticas, enciclopédias e documentários; (ii) obras de ficção; e (iii) obras técnicas e científicas. Deve ser possível criar novas categorias, com um impacto mínimo sobre o sistema desenvolvido.
O sistema mantém um registo de utentes da mediateca. Cada utente é identificado por um número de utente. O identificador é atribuído automaticamente e incrementalmente (a partir de 0 ou do último valor atribuído, caso o estado do sistema tenha sido recuperado).
O sistema mantém ainda, para cada utente, o seu nome, endereço de correio electrónico e informação sobre a situação do utente perante a mediateca: (i) activo, i.e., o utente pode fazer requisições; (ii) suspenso, i.e., o utente não pode fazer novas requisições.
Um utente é suspenso se não devolver uma obra requisitada dentro do prazo estipulado; permanece suspenso até devolver a obra e pagar a multa referente ao atraso na entrega.
A mediateca distingue entre utentes que cumprem as regras de funcionamento e utentes que violam sistematicamente os compromissos. Existe ainda uma classificação intermédia para novos utentes ou para utentes com comportamento misto.
Um utente que nas últimas 3 requisições não tenha cumprido os prazos de devolução, é classificado como faltoso. Um utente faltoso que proceda a 3 devoluções consecutivas dentro do prazo é considerado normal. Um cliente que tenha cumprido rigorosamente os prazos de entrega nas últimas 5 requisições é classificado como cumpridor. Em todos os outros casos, o utente não tem classificação especial e é considerado normal. Como se verá adiante, a classificação influencia a capacidade de requisição do utente.
O comportamento (no que diz respeito a entrega, dentro ou fora do prazo, de obras requisitadas antes da suspensão) de um utente suspenso influencia a sua classificação após o pagamento da multa. Por exemplo, se, antes de pagar a multa, o utente entregar 3 obras dentro do prazo e regularizar a sua situação, então passará a ser um utente que pode efectuar requisições com a classificação de normal. Deve ser possível discriminar os utentes quanto à sua conduta, considerando outros critérios ou novas classificações, com um impacto mínimo na implementação desenvolvida.
O sistema garante o cumprimento de regras para a requisição de obras. As regras dependem das características da obra que se pretende requisitar e da conduta passada do utente. Utentes cumpridores estão sujeitos a regras permissivas enquanto que a utentes faltosos são aplicadas regras restritivas. Os restantes utentes seguem um conjunto de regras de base. As regras gerais a respeitar pelos utentes são:
No caso de violação da regra 1, o utente pode pedir para ser notificado assim que algum exemplar seja devolvido. A notificação consiste, por omissão, no envio de uma mensagem por correio electrónico ao utente, indicando que a obra já se encontra disponível.
Ao requisitar uma obra, o utente deve ser informado da data limite para a devolução. O tempo de requisição permitido para cada obra depende do número total de exemplares que constem do acervo da mediateca e da conduta do utente. Os prazos, em dias, são os seguintes:
Se o utente não entregar as obras requisitadas no prazo devido, fica imediatamente suspenso, não podendo requisitar mais obras até regularizar a situação. Por cada dia de atraso, o utente fica sujeito ao pagamento de uma multa de €5,00 (cinco euros). A situação só se considera regularizada após a devolução das obras em atraso e o pagamento da multa. Para efeitos de pagamento de multas, fracções de dia contam como um dia (a unidade de tempo do sistema é o dia).
Deve ser possível alterar ou acrescentar regras para a requisição de obras, bem como fazer alterações aos tempos de requisição permitidos. As alterações devem ter impacto mínimo na implementação desenvolvida.
Para permitir que o sistema ajude os utentes a determinar a existência de uma obra, deverá ser possível efectuar pesquisas. As pesquisas consideram os campos relevantes das várias obras. Deve ser possível introduzir novos métodos de pesquisa de uma obra com um impacto mínimo na implementação desenvolvida.
A unidade de tempo do sistema é o dia. A data do sistema começa no dia 0 (zero) e faz parte do estado persistente. Sempre que a data é alterada, deve ser verificada a situação dos utentes.
Deve existir um mecanismo de mensagens que permita avisar eventuais interessados quando as obras ficam em determinadas situações:
A apresentação das mensagens enviadas para um dado utilizador deve ser feita quando se visualiza o utilizador (ver abaixo). Quando se faz a visualização, são anexadas à descrição do utilizador (no final) todas as notificações recebidas. Após esta visualização, considera-se que o utilizador fica sem mensagens. As mensagens devem ser apresentadas pela mesma ordem em que foram enviadas pelo sistema.
Devem ser possíveis extensões ou alterações de funcionalidade com impacto mínimo no código já produzido para a aplicação. O objectivo é aumentar a flexibilidade da aplicação relativamente ao suporte de novas funções. Assim, deve ser possível:
A aplicação permite manter informação sobre as entidades do modelo, permitindo, em particular, gerir utentes, obras e empréstimos. Possui ainda a capacidade de preservar o seu estado (não é possível manter várias versões do estado da aplicação em simultâneo).
A base de dados com os conceitos pré-definidos é carregada no início da aplicação. Não é possível remover utentes ou obras durante a execução da aplicação.
Um utilizador registado pode ver todos os utilizadores ou só um dado utilizador, procurar um utilizador e actualizar o seu número de telefone.
Um utilizador registado que seja aluno pode realizar as seguintes tarefas: entregar um projecto, preencher um inquérito e ver resultados de um inquérito.
Um utilizador registado que seja delegado tem à sua disposição as seguinte funcionalidade: criar inquéritos, apagar inquéritos, abrir inquéritos, fechar inquéritos, finalizar inquéritos e ver os resultados de inquéritos.
Um utilizador registado que seja um docente pode realizar as seguintes actividades: criar projectos, fechar projectos, ver as submissões de um projecto, ver os alunos de uma disciplina leccionada e ver resultados de inquéritos.
É possível guardar e recuperar o estado actual da aplicação, preservando toda a informação relacionada com a mediateca e que foi descrita acima.
Descreve-se nesta secção a funcionalidade máxima da interface com o utilizador. Em geral, os comandos pedem toda a informação antes de proceder à sua validação (excepto onde indicado). Todos os menus têm automaticamente a opção Sair (fecha o menu).
As operações de pedido e apresentação de informação ao utilizador devem realizar-se através dos objectos form e display, respectivamente, presentes em cada comando. As mensagens são produzidas pelos métodos das bibliotecas de suporte (po-uuilib e m19-app). As mensagens não podem ser usadas no núcleo da aplicação (m19-core). Além disso, não podem ser definidas novas. Potenciais omissões devem ser esclarecidas antes de qualquer implementação.
As excepções usadas na interacção, excepto se indicado, são subclasses de pt.tecnico.po.ui.DialogException, são lançadas pelos comandos e tratadas por pt.tecnico.po.ui.Menu. Outras excepções não devem substituir as fornecidas nos casos descritos.
As acções deste menu permitem gerir a salvaguarda do estado da aplicação e abrir submenus. A lista completa é a seguinte: Abrir, Guardar, Mostrar data actual, Avançar data actual, Menu de Gestão de Utentes, Menu de Gestão de Obras e Menu de Gestão de Requisições. Inicialmente, a aplicação apenas tem informação sobre as entidades que foram carregados no arranque.
As etiquetas das opções deste menu estão definidas na classe m19.app.main.Label. Todos os métodos correspondentes às mensagens de diálogo para este menu estão definidos na classe m19.app.main.Message.
O conteúdo da aplicação (toda a informação detida pela mediateca actualmente em memória) pode ser guardado para posterior recuperação (via serialização Java: java.io.Serializable). Na leitura e escrita do estado da aplicação, devem ser tratadas as excepções associadas. A funcionalidade é a seguinte:
Note-se que a opção Abrir não permite a leitura de ficheiros de texto (estes apenas são utilizados na inicialização da aplicação).
A opção Sair nunca guarda o estado da aplicação, mesmo que existam alterações.
A data actual do sistema é apresentada através da mensagem currentDate().
O número de dias a avançar é pedido através de requestDaysToAdvance(). O valor indicado deve ser positivo. Caso contrário, a operação não tem efeito.
Além da data, o sistema deve actualizar, caso seja necessário, outros aspectos que dela dependam, designadamente, a situação dos utentes relativa a prazos.
Este menu permite efectuar operações sobre a base de dados de utentes da biblioteca. A lista completa é a seguinte: Registar utente, Mostrar utente, Mostrar utentes, Pagar multa.
As etiquetas das opções deste menu estão definidas na classe m19.app.users.Label. Todos os métodos correspondentes às mensagens de diálogo para este menu estão definidos na classe m19.app.users.Message.
Sempre que for pedido o identificador de um utente (requestUserId()) e o utente não existir, é lançada a excepção NoSuchUserException.
Pede o nome (requestUserName()) e o endereço de correio electrónico (requestUserEMail()). O nome e o endereço de correio electrónico não podem ser vazios. Se isto se verificar, o registo deve falhar.
O registo bem sucedido é assinalado através da mensagem userRegistrationSuccessful(); caso contrário, é apresentada a mensagem userRegistrationFailed().
Note-se que a atribuição do identificador do utente é automática e que utentes diferentes são registados em cada operação de registo.
É pedido o identificador do utente, sendo apresentadas as informações sobre esse utente, de acordo com o seguinte formato (e variações descritas abaixo). A multa a apresentar, para utentes suspensos, é um valor inteiro.
| Formatos de apresentação de um utente (activos e suspensos) |
|---|
id - nome - email - ACTIVO id - nome - email - SUSPENSO - EUR multa |
| Exemplos de apresentação de utentes |
|---|
2 - Alberto Meireles - ameireles@mymail.com - ACTIVO 1 - Fernando Meireles - fmeireles@mymail.com - SUSPENSO - EUR 10 3 - Fernando Meireles - ffm@mymail.com - ACTIVO |
Apresenta informações sobre todas os utentes, ordenando-os lexicograficamente pelo nome. Caso existam utentes com o mesmo nome, devem ser ordenados por ordem crescente dos seus identificadores. O formato é o descrito em Mostrar utente.
Pede o identificador do utente cuja multa deve ser paga. Se o utente estiver suspenso, a multa é saldada e o utente passa a poder requisitar obras, de acordo com as regras gerais. Se o utente não estiver suspenso, i.e., não tem multas por saldar, deve lançar-se uma excepção UserIsActiveException.
Este menu apresenta as operações disponíveis sobre obras. A lista completa é a seguinte: Mostrar obra, Mostrar obras e Efectuar pesquisa.
As etiquetas das opções deste menu estão definidas na classe m19.app.works.Label. Todos os métodos correspondentes às mensagens de diálogo para este menu estão definidos na classe m19.app.works.Message.
Sempre que é pedido o identificador da obra (requestWorkId()), é lançada a excepção NoSuchWorkException, se a obra indicada não existir.
É pedido o identificador da obra (requestWorkId()). Se a obra existir, é apresentada de acordo com os seguintes formatos (para livros e DVDs).
| Formatos de apresentação de obras |
|---|
id - Livro - título - autor - preço - categoria - isbn id - DVD - título - realizador - preço - categoria - númeroigac |
| Exemplos de apresentação de obras |
|---|
3 - Livro - Casa Azul - João Fonseca - 15 - Ficção - 1234567891 4 - DVD - Casamento Real - António Fonseca - 8 - Ficção - 200400500 5 - Livro - Dicionário - Pedro Casanova - 45 - Referência - 1234567893 6 - Livro - Enciclopédia - Zé Fonseca - 100 - Técnica e Científica - 1234567894 |
Apresenta informações sobre todas as obras, ordenando-as pelos seus identificadores. O formato de apresentação é como descrito em Mostrar obra.
Esta opção realiza uma procura por termo (cadeia de caracteres), pedido através de requestSearchTerm(). Como resultado, deve ser apresentada uma lista das obras encontradas pela pesquisa, ordenadas por ordem crescente do seu identificador, utilizando o formato descrito para Mostrar obra.
O termo de pesquisa deve ser comparado (sem distinçãoo entre letras maiúsculas e minúsculas) com os campos relevantes de cada obra: para DVDs, o realizador e o título; para livros, o autor e o título. Só devem ser apresentadas obras que contenham o termo de pesquisa num dos campos relevantes.
Assim, considerando as quatro obras abaixo, uma pesquisa pelo termo casa retornaria as obras com os identificadores 3, 4 e 5.
| Resultados de pesquisa pelo termo "casa" |
|---|
3 - Livro - Casa Azul - João Fonseca - 15 - Ficção - 1234567891
4 - DVD - Casamento Real - António Fonseca - 8 - Ficção - 200400500
5 - Livro - Dicionário - Pedro Casanova - 45 - Referência - 1234567893
6 - Livro - Enciclopédia - Zé Fonseca - 100 - Técnica e Científica - 1234567894
|
Caso não sejam encontradas obras, não deve ser produzido qualquer resultado.
Este menu apresenta as operações relacionadas com requisições de obras. A lista completa é a seguinte: Requisitar obra, Devolver obra.
As etiquetas das opções deste menu estão definidas na classe m19.app.requests.Label. Todos os métodos correspondentes às mensagens de diálogo para este menu estão definidos na classe m19.app.requests.Message.
Sempre que é pedido o identificador do utente (requestUserId()), é lançada a excepção NoSuchUserException, se o utente indicado não existir. Sempre que é pedido o identificador da obra (requestWorkId()), é lançada a excepção NoSuchWorkException, se a obra indicada não existir.
No processo de requisição de uma obra, o sistema pede, primeiro, a identificação do utente e, de seguida, o identificador da obra a requisitar. Se o utente não puder requisitar a obra (considerando-se as regras definidas acima), deve ser lançada a excepção RuleFailedException.
Se a requisição não for possível por falta de exemplares (violação da regra 1), deve-se perguntar ao utente, utilizando a mensagem desejaAvisoDevolucao(), se deseja ser notificado acerca da devolução. Utiliza-se a mensagem devolucaoDia() para comunicar o prazo de devolução, em caso de requisição bem sucedida.
No processo de devolução de uma obra, o sistema pede, primeiro, o identificador do utente e, de seguida, o da obra a devolver. Se a obra não tiver sido requisitada pelo utente indicado, deve-se lançaar uma excepção WorkNotBorrowedByUserException. Caso contrário, o sistema processa a entrega e, caso haja lugar ao pagamento de multa, é apresentada a mensagem apresentarMulta().
O utente pode entregar uma obra sem pagar a multa, continuando suspenso até regularizar a situação, sem prejuízo da obra ser assinalada como entregue. Antes de liquidar a multa, o sistema interroga o utente sobre o desejo de pagamento, através da mensagem desejaPagarMulta(). Se a resposta for positiva, a multa é liquidada e o utente fica activo.
Além das opções de manipulação de ficheiros descritas no menu principal, é possível iniciar a aplicação com um ficheiro de texto especificado pela propriedade Java import.
As obras da mediateca têm o formato descrito abaixo, respectivamente, para DVDs e livros (a categoria de uma obra é um número, tal como descrito acima). Assume-se que os títulos das obras não podem conter o carácter : e que o preço é um número inteiro (sugere-se a utilização do método String.split para o processamento preliminar destas linhas). Não existem entradas mal-formadas e entradas repetidas (linhas iguais) ao longo do ficheiro (independentemente de serem consecutivas ou não) correspondem a múltiplos exemplares da mesma obra.
Cada linha tem tem uma descrição distinta mas que segue o seguinte formato geral.
DVD:tituloDVD:realizadorDVD:preco:categoria:numeroIGAC Livro:tituloLivro:autorLivro:preco:categoria:ISBN
Um exemplo de conteúdo do ficheiro inicial é como se segue:
| Exemplo de ficheiro de entrada textual |
|---|
DVD:Era uma vez na Amadora:Fernando Fonseca:20:2:200505550
DVD:Lumiar Selvagem:Pedro Fonseca:20:2:200505551
Livro:A arte de sobreviver no 36:Joao Fonseca:20:2:1234567892
Livro:Bairro Alto e o Budismo Zen:Zun Tse Fonseca:20:2:1234567891
DVD:48 Horas para o Exame:Orlando Fonseca:12:2:200505553
Livro:Analise Matematica sem Mestre:Carlos Fonseca:20:2:1234567890
DVD:Lumiar Selvagem:Pedro Fonseca:20:2:200505551
DVD:Lumiar Selvagem:Pedro Fonseca:20:2:200505551
|
A codificação dos ficheiros a ler é garantidamente UTF-8.
Usando os ficheiros test.import, test.in e test.out, é possível verificar automaticamente o resultado correcto do programa. Note-se que é necessária a definição apropriada da variável CLASSPATH (ou da opção equivalente -cp do comando java), para localizar as classes do programa, incluindo a que contém o método correspondente ao ponto de entrada da aplicação (m19.app.App.main). As propriedades são tratadas automaticamente pelo código de apoio.
java -Dimport=test.import -Din=test.in -Dout=test.outhyp m19.app.App
Assumindo que aqueles ficheiros estão no directório onde é dado o comando de execução, o programa produz o ficheiro de saída test.outhyp. Em caso de sucesso, os ficheiros das saídas esperada (test.out) e obtida (test.outhyp) devem ser iguais. A comparação pode ser feita com o comando:
diff -b test.out test.outhyp
Este comando não deve produzir qualquer resultado quando os ficheiros são iguais. Note-se, contudo, que este teste não garante o correcto funcionamento do código desenvolvido, apenas verificando alguns aspectos da sua funcionalidade.
Tal como indicado acima, algumas classes fornecidas como material de apoio, são de uso obrigatório e não podem ser alteradas. Outras dessas classes são de uso obrigatório e têm de ser alteradas.
A serialização Java usa as classes da package java.io, em particular, a interface java.io.Serializable e as classes de leitura java.io.ObjectInputStream e escrita java.io.ObjectOutputStream (entre outras).