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
Revision as of 16:44, 24 September 2018 by Root (talk | contribs) (→‎Mostrar pessoa)
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).

Conceitos e Relações do Modelo

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.

Universidade, Cursos, Disciplinas

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

Cada curso tem um nome (ú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. Cada aluno pode inscrever-se, no máximo, em 6 disciplinas.

Cada disciplina tem um nome e apenas pertence a um curso. O nome da disciplina é o identificador único dentro do curso respectivo. Cada disciplina é leccionada por um ou mais docentes e tem 0 ou mais alunos inscritos. Os alunos inscritos numa disciplina têm que pertencer ao curso da disciplina. Existe uma capacidade máxima relativamente aos alunos que se podem inscrever numa disciplina. Um docente pode estar associado a várias disciplinas.

Pessoas

O sistema a desenvolver tem de 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 identificados por um identificador único (inteiro com 6 dígitos). Este identificador é atribuído automaticamente e começa em 100000. Um aluno pode ainda ser delegado 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, sendo preservada a ordem de submissão. Por razões de simplificação a submissão é representada por uma cadeia de caracteres introduzida pelo aluno.

Inquéritos

Cada inquérito tem um identificador único no contexto da disciplina (número inteiro único e sequencial, atribuído automaticamente na altura da criação) e está associado a um projecto dessa disciplina. Só é possível associar um inquérito a um projecto se este não estiver finalizado. Um inquérito 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. A mudança de situação é explícita, excepto quando o projecto associado termina: neste caso, o inquérito do projecto passa automaticamente da situação criado para aberto.

Só os alunos que entregaram o projecto (ou seja, realizaram pelo menos uma submissão) é 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.

Só os delegados de um curso é que podem alterar a situação de um inquérito que diga respeito a um projecto de uma disciplina do curso (com a excepção indicada acima).

É possível realizar várias operações sobre um inquérito: cancelar, abrir, fechar, finalizar, submeter resposta e obter resultados. Cancelar um inquérito criado ou aberto (e sem respostas) corresponde a remover o inquérito. 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 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 nada. 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ções indicadas anteriormente desde que pertençam ao mesmo curso do inquérito. Adicionalmente, o aluno tem ainda de ter entregue o projecto associado ao inquérito.

Notificações

Deve existir um mecanismo de mensagens que permita avisar determinados utilizadores quando determinada informação relacionada com as situações dos inquéritos associados aos projectos de uma dada disciplina:

  • Quando um inquérito de um projecto de uma disciplina abre, quer-se enviar uma mensagem a todos os alunos, delegados e docentes da disciplina.
  • Quando um inquérito de um projecto de uma disciplina finaliza, quer-se enviar uma mensagem a todos os alunos, delegados e docentes da disciplina.

Nota: dado que um aluno pode também ser delegado, o mecanismo de envio de mensagens deve tratar este como se fosse uma única entidade. Assim, um aluno de uma disciplina que seja também delegado deve receber apenas uma mensagem e não duas cada vez que o sistema tem que enviar uma mensagem.

A apresentação das mensagens enviadas para um dado utilizador deve ser feita quando o utilizador faz login no sistema. Após o login ter sido realizado com sucesso devem ser apresentadas todas as mensagens que tenham sido enviadas para o utilizador em causa desde a última vez que se registou no sistema. Após esta visualização considera-se que o utilizador fica sem mensagens. As mensagens devem ser apresentadas pela mesma ordem em que enviadas pelo sistema.

Requisitos de Desenho

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 determinação da descrição de um utilizador deve estar realizada de forma a evitar a duplicação de código comum, facilitando assim a introdução de novos tipos de utilizadores.
  • A concretização da entidade inquérito deve ser feita por forma aumentar a legibilidade do código relacionado com esta entidade por forma a que caso se queira alterar a lógica de cada situação em que o inquérito possa estar, isso possa ser feito facilmente.
  • O mecanismo de envio das mensagens deve ser suficientemente flexível para suportar outras entidades que queiram também receber as mensagens. Deve ainda permitir que os destinatários das mensagens possam dizer se querem ou não ser notificados relativamente a cada disciplina. Por exemplo, um aluno de uma disciplina pode dizer que já não quer receber mensagens relativas a abrir e finalizar um inquérito associado à disciplina.

Quer-se uma solução que permita a diferentes entidades poderem receber uma mensagem quando os resultados de um inquérito ficam disponíveis ou quando um novo aluno responde ao inquérito. No primeiro caso a mensagem deve indicar que o inquérito tem os resultados disponíveis enquanto que o segundo deve indicar que existe uma nova resposta registada no inquérito e o número total de respostas até ao momento.

Funcionalidade da aplicação

A aplicação permite manter informação sobre as entidades do modelo, permitindo, em particular, gerir projectos e inquéritos. 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 adicionar ou remover pessoas durante a execução da aplicação.

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 sth.School e outras fornecidas (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.

Consulta de informação sobre pessoas

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

Gestão de actividades dos alunos

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.

Gestão de actividades dos delegados

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.

Gestão de actividades dos professores

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 sth-app). As mensagens não podem ser usadas no núcleo da aplicação (sth-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 sth.app, sth.app.main, sth.app.person, sth.app.teaching, sth.app.student e sth.app.representative. Estas classes são de uso obrigatório e estão disponíveis no CVS (módulo sth-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 Portal Pessoal, Portal do Docente, Portal do Estudante e Portal do Delegado. Inicialmente, a aplicação apenas tem informação sobre as pessoas e cursos que foram carregados no arranque. Note-se que nem todas as opções do menu estão disponíveis para todos os utilizadores (ver abaixo).

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

Estes comandos já estão implementados nas classes da package sth.app.main (disponível no CVS), respectivamente: DoReset, DoOpen, DoSave, DoOpenPersonalMenu, DoOpenTeachingMenu, DoOpenStudentMenu, DoOpenRepresentativeMenu.

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

  • Portal Pessoal -- Abre o menu de consulta de informações sobre pessoas.
  • Portal do Docente -- Abre o menu de gestão de actividades dos professores (esta opção apenas está disponível para professors).
  • Portal do Estudante -- Abre o menu de gestão de actividades dos estudantes (esta opção apenas está disponível para estudantes).
  • Portal do Delegado -- Abre o menu de gestão de actividades dos delegados (esta opção apenas está disponível para delegados).

Portal Pessoal

Este menu permite efectuar operações sobre a base de dados de pessoal. A lista completa é a seguinte: Mostrar pessoas, Mostrar pessoa, Alterar número de telefone, Procurar pessoa.

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

Sempre que for pedido o identificador de uma pessoa (requestPersonId()) e a pessoa não existir, é lançada a excepção sth.app.NoSuchPersonException.

Estes comandos já estão implementados nas classes da package sth.app.person (disponível no CVS), respectivamente: DoShowAllPersons, DoShowPerson, DoChangePhoneNumber, DoSearchPerson.

Mostrar pessoas

Apresenta informações sobre todas as pessoas conhecidas.

A lista é ordenada pelo identificador da pessoa e o formato é o descrito em Mostrar pessoa.

Mostrar pessoa

Apresenta informações sobre uma pessoa especificada pelo seu identificador.

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

Alterar número de telefone

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.

Procurar pessoa

(que é suposto fazer?)

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

Portal do Docente

Este menu permite efectuar operações sobre um passageiro. A lista completa é a seguinte: Criar projecto, Fechar projecto, Ver submissões de um projecto, Ver alunos de disciplina leccionada, Ver resultados de um inquérito.

As etiquetas das opções deste menu estão definidas na classe sth.app.teaching.Label. Todos os métodos correspondentes às mensagens de diálogo para este menu estão definidos na classe sth.app.teaching.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 sth.app.teaching (disponível no CVS), respectivamente: DoCreateProject, DoCloseProject, ShowProjectSubmissions, DoShowCourseStudents, DoShowSurveyResults.

Criar projecto

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

Fechar projecto

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

Ver submissões de um projecto

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

Ver alunos de disciplina leccionada

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

Ver resultados de um inquérito

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

Portal do Estudante

Este menu permite efectuar operações sobre itinerários. A lista completa é a seguinte: Entregar projecto, Preencher inquérito, Ver resultados de inquérito.

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

Estes comandos já estão parcialmente implementados nas classes da package sth.app.student (disponível no CVS), respectivamente: DoDeliverProject, DoAnswerSurvey, DoShowSurveyResults.

Entregar projecto

Pede identificador da disciplina e do projecto a entregar.

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.

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.

Preencher inquérito

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

Ver resultados de inquérito

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

Portal do Delegado

Este menu permite efectuar operações sobre itinerários. A lista completa é a seguinte: Criar inquérito, Apagar inquérito, Abrir inquérito, Fechar inquérito, Finalizar inquérito, Mostrar inquéritos de uma disciplina, Enviar aviso, Mostrar resultados de inquérito.

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

Estes comandos já estão parcialmente implementados nas classes da package sth.app.representative (disponível no CVS), respectivamente: DoCreateSurvey, DoRemoveSurvey, DoOpenSurvey, DoCloseSurvey, DoFinishSurvey, DoShowSurveys, DoSendReminder, DoShowResults.

Criar inquérito

Apagar inquérito

Abrir inquérito

Fechar inquérito

Finalizar inquérito

Mostrar inquéritos de uma disciplina

Enviar aviso

Enviar aviso a todos os alunos inscritos e que ainda não preencheram inquérito.

Mostrar resultados de inquérito

Ver resultados de um inquérito de uma disciplina.

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.

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

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