Programação com Objectos/Projecto de Programação com Objectos/Enunciado do Projecto de 2018-2019 (rascunho random)

From Wiki**3

< Programação com Objectos‎ | Projecto de Programação com Objectos
AVISOS - Avaliação em Época Normal

Esclarecimento de dúvidas:

  • Consultar sempre o corpo docente atempadamente: presencialmente ou através do endereço oficial da disciplina [1].
  • Não utilizar fontes de informação não oficialmente associadas ao corpo docente (podem colocar em causa a aprovação à disciplina).
  • Não são aceites justificações para violações destes conselhos: quaisquer consequências nefastas são da responsabilidade do aluno.

Requisitos para desenvolvimento, material de apoio e actualizações do enunciado (ver informação completa em Projecto de Programação com Objectos):

  • O material de apoio é de uso obrigatório e não pode ser alterado.
  • Verificar atempadamente (mínimo de 48 horas antes do final de cada prazo) os requisitos exigidos pelo processo de desenvolvimento.

Processo de avaliação (ver informação completa em Avaliação do Projecto):

  • Datas: 2018/10/19 12:00 (inicial); 2018/11/16 12:00 (intercalar); 2018/12/07 12:00 (final); 2018/12/10-2017/12/14 (teste prático).
  • A entrega inicial, sendo crucial para o projecto, é obrigatória e sua não realização implica a exclusão da avaliação do projecto e, por consequência, da avaliação da disciplina.
  • Verificar atempadamente (até 48 horas antes do final de cada prazo) os requisitos exigidos pelo processo de avaliação, incluindo a capacidade de acesso ao 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.
  • A avaliação do projecto pressupõe o compromisso de honra de que o trabalho correspondente foi realizado pelos alunos correspondentes ao grupo de avaliação.
  • Fraudes na execução do projecto terão como resultado a exclusão dos alunos implicados do processo de avaliação.
Material de Uso Obrigatório
As bibliotecas po-uuilib e o conteúdo inicial do CVS são de uso obrigatório:
  • po-uuilib (classes de base) po-uuilib-201708311009.tar.bz2 (não pode ser alterada) - javadoc
  • sth-core (classes do "core") (via CVS) (deve ser completada -- os nomes das classes fornecidas não podem ser alterados)
  • sth-app (classes de interacção) (via CVS) (deve ser completada -- os nomes das classes fornecidas não podem ser alterados)
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 é criar uma aplicação que gere parte da actividade dos cursos de uma universidade. Em particular, a aplicação faz a gestão de inquéritos aos projectos realizados pelos alunos nas várias disciplinas do curso.

Neste texto, o tipo negrito indica um literal (i.e., é exactamente como apresentado); o símbolo <amsmath>\verb*| |</amsmath> indica um espaço; e o tipo itálico indica uma parte variável (i.e., uma descrição).

Estrutura dos vários conceitos e suas relações

Existem vários conceitos importantes neste contexto: universidade, curso, aluno, professor, funcionário, projecto, inquérito,

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.

Escola

Uma universidade tem um nome e pode ter vários cursos universitários, tendo ainda funcionários, docentes e alunos. Os alunos estão exclusivamente associados a cada curso. Os funcionários e os docentes podem estar associadoss a vários cursos.

Cada curso tem um nome (que deverá ser único no contexto da universidade) e é constituído por várias disciplinas. Cada curso tem ainda um conjunto de alunos que podem inscreverem-se nas várias disciplinas do curso.

Pessoas

O sistema a desenvolver tem que lidar com diferentes tipos de utilizadores: alunos, docentes e funcionários. Alunos, docentes e funcionários têm um nome, número de telefone e são são identificados por um identificador único no sistema. Este identificador é um número inteiro com 6 dígitos. Este identificador é atribuído automaticamente pelo sistema e começa em 100000. Um aluno pode ainda ser delegado de curso do curso em que o aluno está inscrito. O número máximo de delegados de um curso é 7. Em qualquer instante um aluno pode tornar-se delegado ou deixar de ser delegado.

Projectos

Os docentes podem criar projectos associados às disciplinas que leccionam. Quando o projecto é criado fica automaticamente aberto. Cada projecto tem um nome e descrição. O nome deve ser único no contexto da disciplina. Os alunos da mesma disciplina que o projecto podem submeter a sua versão do projecto desde que o projecto ainda não esteja fechado. Os alunos podem realizar várias submissões no mesmo projecto mas apenas é guardada a última submissão. Por razões de simplificação a submissão é representada por uma cadeia de caracteres introduzida pelo aluno. A ordem de submissão deve ser preservada pelo sistema.

Inquéritos

Cada inquérito está associado a um projecto de uma dada disciplina. Só é possível associar um inquérito a um projecto caso o projecto não esteja finalizado. Cada inquérito tem um identificador único no contexto da disciplina. Este identificador é atribuído automaticamente pelo sistema, começa em 1 e é incrementado em uma unidade cada vez que um projecto é criado. Só os alunos que entregaram o projecto é que podem responder ao inquérito. Cada aluno só pode responder uma única vez. As respostas devem ser anónimas, ou seja, o sistema não deve guardar informação que permita saber qual a resposta de um dado aluno a um inquérito.

A gestão interna de um inquérito é da responsabilidade de um delegado do curso. Um inquétido pode estar em várias situações: criado, aberto, fechado e finalizado. O comportamento do inquérito dependa da situação em que ele esteja. Só um delegado do curso é que pode alterara situação de um inquérito. A única excepção é quando um projecto com um inquérito termina, o inquérito do projecto passa automaticamente da situação criado para aberto. Quando se cria um projecto é necessário indicar um projecto que ainda não esteja terminado.

É possível realizar várias operações sobre um inquérito: cancelar, abrir, fechar, finalizar, submeter resposta e obter resultados. Um delegado pode cancelar um inquérito. Cancelar um inquérito criado ou aberto (e sem respostas) corresponde a remover o inquérito do sistema. Se o inquérito estiver aberto mas já tiver pelo menos uma resposta, então não pode ser removido e deve dar erro. Cancelar um inquérito fechado corresponde a abri-lo outra vez. Finalmente, cancelar um inquérito finalizado é impossível pelo que deverá dar erro.

Um delegado pode só pode abrir um inquérito que esteja criado. Em qualquer outra situação deve dar um erro a não ser que o inquérito esteja aberto. Neste caso, a operação não faz anda. Um delegado pode fechar um inquérito que esteja aberto. Se estiver fechado, a operação não faz nada. Em qualquer outra situação deve dar um erro. Finalmente, um delegado pode finalizar um inquérito que esteja fechado . Se o inquérito já estiver finalizado, a operação não faz nada. Nas restantes situações dará um erro.

Os alunos podem submeter uma resposta a um inquérito aberto. Em qualquer outra situação, esta operação deverá dar um erro. Alunos, docentes e delegados podem obter o resultado de um inquérito que esteja finalizado. Adicionalmente, um delegado pode obter os resultados de um inquérito que esteja aberto ou fechado. Esta operação deverá dar um erro em qualquer outra situação.

Note-se que tanto um delegado, como um aluno ou um docente podem realizar as operaçãoes indicas anteriormente desde que pertençam ao mesmo curso do inquérito. Adicionalmente, o aluno tem ainda que te entregue o projecto associado ao inquérito.

Funcionalidade da aplicação

A aplicação permite manter informação sobre serviços. Permite ainda registar e gerir passageiros e criar novos itinerários para eles. 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 de serviços é carregada no início da aplicação. Não é possível adicionar ou remover serviços durante a execução da aplicação.

Todos os cálculos são realizados e os resultados armazenados sem arrendondamentos. Apenas na apresentação de resultados (e.g., preços) se apresentam valores com um número limitado de casas decimais (onde indicado).

Note-se que não é necessário implementar de raiz a aplicação: já existem classes que representam e definem a interface geral da funcionalidade do core da aplicação, tal como é visível pelos comandos da aplicação.
A interface geral do core já está parcialmente implementada na classe mmt.TicketOffice e outras fornecdidas (cujos nomes devem ser mantidos), devendo ser adaptadas onde necessário. É ainda necessário criar e implementar as restantes classes que suportam a operação da aplicação.

Consultas de Serviços

É possível fazer várias consultas sobre serviços (ver também abaixo). É possível ver todos os serviços, inspeccionar um serviço particular e inspeccionar serviços com base na especificação de estações. Podem ser definidas, no futuro, outras formas de pesquisa e de apresentação de serviços.

Manipulação de Passageiros

A aplicação permite realizar várias operações sobre passageiros. É possível obter a lista completa de passageiros conhecidos, assim como informação detalhada sobre passageiros individuais. É ainda possível registar novos passageiros e alterar o nome dos passageiros.

Manipulação de Itinerários

A aplicação permite obter informações sobre todos os itinerários já comprados ou, em pormenor, sobre os itinerários de passageiros específicos. Permite ainda criar novos itinerários.

Os passageiros são creditados com o valor monetário de cada itinerário comprado e com o tempo decorrido nesses itinerários (medido entre os pontos extremos).

Serialização

É possível reiniciar (ou seja, mantendo a informação sobre serviços, eliminar a informação sobre passageiros e itinerários), guardar e recuperar o estado actual da aplicação, preservando todos a informação sobre serviços, passageiros e itinerários.

Interacção com o utilizador

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 mmt-app). As mensagens não podem ser usadas no núcleo da aplicação (mmt-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.

Note-se que o programa principal e os comandos e menus, a seguir descritos, já estão parcialmente implementados nas packages mmt.app, mmt.app.main, mmt.app.service, mmt.app.passenger e mmt.app.itinerary. Estas classes são de uso obrigatório e estão disponíveis no CVS (módulo mmt-app).

Menu Principal

As acções do menu permitem gerir a salvaguarda do estado da aplicação e abrir submenus. A lista completa é a seguinte: Reiniciar, Abrir, Guardar e Consulta de Serviços, Manipulação de Passageiros e Manipulação de Itinerários. Inicialmente, a aplicação apenas tem informação sobre os serviços que foram carregados no arranque.

As etiquetas das opções deste menu estão definidas na classe mmt.app.main.Label. Todos os métodos correspondentes às mensagens de diálogo para este menu estão definidos na classe mmt.app.main.Message.

Estes comandos já estão implementados nas classes da package mmt.app.main (disponível no CVS), respectivamente: DoReset, DoOpen, DoSave, DoOpenServicesMenu, DoOpenPassengersMenu, DoOpenItinerariesMenu.

Salvaguarda do estado actual da aplicação

O conteúdo da aplicação (inclui todos os serviços, passageiros e itinerários 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:

  • Reiniciar -- Reinicia a aplicação: destrói toda a informação sobre passageiros e itinerários; mantém toda a informação sobre serviços. Destrói ainda a associação a ficheiro de salvaguarda.
  • Abrir -- Carrega os dados de uma sessão anterior a partir de um ficheiro (ficando associado à aplicação). A informação a carregar compreende serviços, passageiros e itinerários. Pede-se o nome do ficheiro a abrir (openFile()). Caso o ficheiro não exista, é apresentada a mensagem fileNotFound().
  • Guardar -- Guarda o estado actual da aplicação (serviços, passageiros e itinerários) no ficheiro associado. Se não existir associação, pede-se o nome do ficheiro a utilizar, ficando a ele associado. Esta interacção realiza-se através do método newSaveAs(). Não é executada nenhuma acção se não existirem alterações desde a última salvaguarda.

As opções Reiniciar e Abrir substituem a informação na aplicação nas condições indicadas acima.

A opção Sair nunca guarda o estado da aplicação, mesmo que existam alterações.

Gestão e consulta de dados da aplicação

  • Consulta de Serviços -- Abre o menu de consulta de serviços (se existirem serviços registados).
  • Gestão de Passageiros -- Abre o menu de gestão de passageiros (se existirem passageiros registados).
  • Gestão de Itinerários -- Abre o menu de gestão de itinerários (se existirem itinerários registados).

Menu de Consulta de Serviços

Este menu permite efectuar consultas sobre a base de dados de serviços. A lista completa é a seguinte: Mostrar todos os serviços, Mostrar serviço com um dado número, Mostrar serviços com origem numa estação dada, Mostrar serviços com término numa estação dada.

As etiquetas das opções deste menu estão definidas na classe mmt.app.service.Label. Todos os métodos correspondentes às mensagens de diálogo para este menu estão definidos na classe mmt.app.service.Message.

Sempre que for pedido o identificador de um serviço (requestServiceId()) e o serviço não existir, é lançada a excepção mmt.app.NoSuchServiceException. Sempre que for pedido o nome de uma estção (requestStationName()) e a estação não existir, é lançada a excepção mmt.app.NoSuchStationException.

Estes comandos já estão implementados nas classes da package mmt.app.service (disponível no CVS), respectivamente: DoShowAllServices, DoShowServiceByNumber, DoShowServicesDepartingFromStation, DoShowServicesArrivingAtStation.

Mostrar todos os serviços

Apresenta informações sobre todos os serviços conhecidos. A lista é ordenada pelo identificador do serviço e o formato é o descrito em Mostrar serviço com um dado número.

Mostrar serviço com um dado número

Apresenta informações sobre um serviço. Depois de pedir o identificador do serviço (requestServiceId()), apresenta a informação sobre o serviço, tal como indicado no formato seguinte, para um serviço com N paragens (HH;MM representa o tempo em horas e minutos). O preço deve ser apresentado com duas casas decimais.

Serviço #número-do-serviço @ preço
HH:MM nome-de-estação-1
...
HH:MM nome-de-estação-N
Exemplo de apresentação de serviço: Serviço 180: Porto >> Faro

<text> Serviço #180 @ 51.50 05:47 Porto - Campanhã 05:52 Vila Nova de Gaia-Devesas 06:21 Aveiro 06:46 Coimbra-B 08:23 Lisboa - Oriente 08:31 Lisboa - Entrecampos 09:06 Pinhal Novo 10:54 Tunes 11:01 Albufeira - Ferreiras 11:13 Loulé 11:23 Faro </text>

Mostrar serviços com origem numa estação dada

Apresenta os números e estações terminais dos serviços com origem na estação indicada como resposta a requestStationName(), ordenado por hora de partida do serviço.

O formato de apresentação é o descrito em Mostrar serviço com um dado número.

Mostrar serviços com término numa estação dada

Apresenta os números e estações de origem dos serviços com término na estação indicada como resposta a requestStationName(), ordenado por hora de chegada do serviço.

O formato de apresentação é o descrito em Mostrar serviço com um dado número.

Menu de Gestão de Passageiros

Este menu permite efectuar operações sobre um passageiro. A lista completa é a seguinte: Mostrar passageiros, Mostrar passageiro, Registar passageiro, Alterar nome de passageiro.

As etiquetas das opções deste menu estão definidas na classe mmt.app.passenger.Label. Todos os métodos correspondentes às mensagens de diálogo para este menu estão definidos na classe mmt.app.passenger.Message.

Sempre que for pedido o identificador de um passageiro (requestPassengerId()) e o passageiro não existir, é lançada a excepção mmt.app.NoSuchPassengerException.

Estes comandos já estão implementados nas classes da package mmt.app.passenger (disponível no CVS), respectivamente: DoShowAllPassengers, DoShowPassengerById, DoRegisterPassenger, DoChangePassengerName.

Mostrar passageiros

Apresenta informações sobre todos os passageiros conhecidos. A lista é ordenada pelo identificador e o formato é o descrito em Mostrar passageiro.

Mostrar passageiro

Apresenta informações sobre um passageiro. Depois de pedir o identificador do passageiro (requestPassengerId()), apresenta o nome, a categoria do passageiro (NORMAL, FREQUENTE, ESPECIAL), o número de itinerários adquiridos, o tempo acumulado (formato HH:MM) correspondente aos itinerários adquiridos e o valor pago por esses itinerários (o valor pago deve ser apresentado com duas casas decimais).

Formato:

id | nome | categoria | número-de-itinerários | valor-pago | tempo-acumulado

Exemplo:

1234|John Doe|NORMAL|123|9876.54|123:45

Registar passageiro

Permite registar um passageiro no sistema. É pedido o nome do passageiro (requestPassengerName()). O novo passageiro é categorizado como NORMAL.

Alterar nome de passageiro

Permite alterar o nome do passageiro. Para tal, pede-se o identificador do passageiro cujo nome deve ser alterado (requestPassengerId()) e o novo nome (requestPassengerName()).

Menu de Gestão de Itinerários

Este menu permite efectuar operações sobre itinerários. A lista completa é a seguinte: Mostrar todos os itinerários, Mostrar itinerários associados a um passageiro, Registar itinerário para um passageiro.

As etiquetas das opções deste menu estão definidas na classe mmt.app.itinerary.Label. Todos os métodos correspondentes às mensagens de diálogo para este menu estão definidos na classe mmt.app.itinerary.Message.

Estes comandos já estão parcialmente implementados nas classes da package mmt.app.itinerary (disponível no CVS), respectivamente: DoShowAllItineraries, DoShowPassengerItineraries, DoRegisterItinerary.

Mostrar todos os itinerários

Apresenta todos os itinerários registados para todos os passageiros. O formato de apresentação é como para os serviços, mas apenas se apresenta o segmento percorrido e o respectivo custo. A informação é apresentada para cada passageiro, sendo os passageiros apresentados por ordem crescente do seu número de identificação.

O formato de apresentação é como definido para a apresentação dos itinerários de um passageiro, mas apresenta-se a informação relativamente a todos os passageiros.

Note-se que a apresentação de itinerários apenas tem significado quando existem itinerários para mostrar, i.e., não se devem apresentar passageiros que não têm itinerários.

Mostrar itinerários associados a um passageiro

Apresenta os itinerários do passageiro cujo identificador é pedido através de requestPassengerId(). A lista é ordenada pela data dos itinerários.

Se o passageiro não tiver itinerários, deve ser apresentada a mensagem noItineraries().

O formato de apresentação é análogo ao dos serviços, iniciado com uma linha com o identificador do passageiro, à qual se segue a lista de itinerários, cada um precedido da linha com o número de ordem do itinerário (no contexto de cada passageiro) e da data correspondente:

 == Passageiro identificador-do-passageiro: nome-do-passageiro ==
 Itinerário número-de-ordem-do-itinerário para data @ preço-total-do-itinerário

O preço associado a cada serviço no itinerário é o da fracção do tempo do serviço nesse itinerário, com duas casas decimais. O preço do itinerário é a soma (sem arredondamentos) dos preços dos segmentos que o formam, apresentado com duas casas decimais.

Exemplo de apresentação de itinerários para um passageiro

<text>

Passageiro 2: José Simão

Itinerário 1 para 2017-10-18 @ 20.03 Serviço #692 @ 6.37 09:06 Évora 09:17 Casa Branca 09:31 Vendas Novas 09:53 Pinhal Novo Serviço #570 @ 13.66 10:48 Pinhal Novo 11:19 Grândola 11:33 Ermidas-Sado 11:55 Funcheira 12:24 Santa Clara-Sabóia 12:52 Messines-Alte 13:02 Tunes

Itinerário 2 para 2017-10-25 @ 22.57 Serviço #184 @ 16.41 15:35 Tunes 17:23 Pinhal Novo Serviço #596 @ 6.17 17:48 Pinhal Novo 18:10 Vendas Novas 18:24 Casa Branca 18:35 Évora </text>

Leitura de Dados a Partir de Ficheiros Textuais

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.

Exemplo de ficheiro a importar

Cada utilizador tem uma descrição distinta mas que segue o seguinte formato.

TIPO | identificador | telefone | nome

Dependendo do tipo de pessoa, TIPO pode tomar os valores FUNCIONÁRIO, DOCENTE, ALUNO e DELEGADO (para alunos que são delegados).

A seguir à linha da descrição, podem seguir-se outras que acrescentam informação adicional para o utilizador em causa. A informação adicional para os alunos (delegados ou não) e para os docentes é uma lista de disciplinas (uma por linha): para os alunos, são as disciplinas que frequentam; para os docentes, são as disciplinas que leccionam. Para os funcionários, não há informação adicional a processar.

<text> EXEMPLO.... </text>

A codificação dos ficheiros a ler é garantidamente UTF-8.

Considerações sobre Flexibilidade e Eficiência

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:

  • A aplicação deve permitir a adição de novas categorias de passageiro sem alterações no código já realizado.
  • A aplicação deve permitir a adição de novas procuras de serviços com baixo impacto no código já realizado (em termos do código para suportar a nova procura).

Execução dos Programas e Testes Automáticos

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 (mmt.app.App.main). As propriedades são tratadas automaticamente pelo código de apoio.

       java -Dimport=test.import -Din=test.in -Dout=test.outhyp mmt.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.

Notas de Implementação

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).

A representação e manipulação de datas e tempos deve ser realizada através das classes da package java.time, em particular, através das classes java.time.LocalDate e java.time.LocalTime. Diferenças entre tempos são representadas pela classe java.time.Duration.