Objetivo

Implementar a camada de serviços, serviços REST, DTOs e testes de serviço.

Instruções

Cada grupo continua a trabalhar no seu repositório privado.


Nota: Podem iniciar este segundo sprint usando uma base fornecida pelos docentes da disciplina. Não é obrigatório fazê-lo, mas pode ser útil para os grupos que não têm uma base funcional. Para a obter, basta:

  1. Fazer download do código da solução (backend.zip)
  2. Substituir a pasta backend do vosso branch master com o conteúdo do ficheiro disponibilizado
  3. Correr testes e verificar que está tudo funcional
  4. Verificar se há ficheiros novos ou com nome diferente que precisem de ser apagados
  5. Fazer commit para o master (podem usar a mensagem "update backend to provided base code")


As principais tarefas desta parte são:

  1. Alterar o TeacherDashboardDto para conter informação relativa às estatísticas
  2. Estender o TeacherDashboardService da seguinte forma:
    • Estender o createTeacherDashboard para que o novo dashboard criado contenha as estatísticas associadas às últimas três execuções de disciplina.

    • Implementar o serviço com assinatura

      public void updateTeacherDashboard(int dashboardId)
      Dado o ID de um dashboard de professor, este serviço actualiza as estatísticas associadas.

    • Implementar o serviço com assinatura

      public void updateAllTeacherDashboards()
      Este serviço actualiza as estatísticas associadas a todos os dashboards de professores disponíveis no Quizzes Tutor.
    • Garantir que, se necessário, o serviço removeTeacherDashboard também apaga os objectos de estatísticas associados ao dashboard que é apagado. Dependendo da implementação desenvolvida no Sprint 1, esta tarefa pode ser feita no TeacherDashboardService ou pode ser implementada no domínio através de anotações JPA (ver, por exemplo, https://docs.jboss.org/hibernate/orm/6.1/userguide/html_single/Hibernate_User_Guide.html#pc-cascade)

  3. Testar os novos serviços e também as alterações aos serviços existentes. Cada grupo deve avaliar e decidir que testes devem ser implementados. Deverão considerar, no mínimo, os seguintes testes:

    • Testar que quando se cria um novo dashboard, as estatísticas das últimas três execuções são as consideradas (os testes devem ter em atenção casos onde não há três execuções, etc.)

    • Testar os dois novos serviços updateTeacherDashboard e updateAllTeacherDashboards

    • Testar a remoção de um dashboard que tem estatísticas associadas

  4. Implementar os serviços REST (controladores):

    • Implementar dois serviços REST update associados aos serviços updateTeacherDashboard (acesso reservado ao docente respectivo) e updateAllTeacherDashboards (acesso reservado a administradores).

    • Implementar um serviço REST delete para apagar um dashboard (associado ao serviço removeTeacherDashboard). Acesso reservado aos docentes respectivos.


Cada subgrupo (de 2 alunos) deverá:

  • Actualizar o TeacherDashboardDto com a parte relativa às estatísticas que implementaram no Sprint 1

  • Implementar/estender pelo menos um dos serviços no TeacherDashboardService

  • Testar os serviços que implementaram/estenderam

  • Implementar um serviço REST


A carga de trabalho (quantidade e complexidade das tarefas) deve ser dividida de forma semelhante entre os membros de cada subgrupo. Isto será verificado pelos commits de cada grupo. A nota 0 (zero) será atribuída a alunos que não apresentem commits.


Sugestões de Planeamento

  1. Tal como sugerido nas aulas, começar com um Sprint Retrospective do sprint anterior. O objectivo é a equipa identificar o que correu bem e o que correu menos bem, de forma a tornar-se mais produtiva neste segundo sprint.

  2. Ler com atenção o enunciado. Caso haja alguma dúvida, procurar esclarecê-la com um dos docentes o mais depressa possível.

  3. Participar nos laboratórios da semana que inicia no dia 6 de Março, onde serão feitas apresentações sobre testes de serviço e serviços REST.

  4. Para os grupos que usarão como base o código disponibilizado, convém analisar bem o código.

  5. Planear a divisão de tarefas o mais cedo possível. Em caso de dúvidas, falar com os docentes. Para o board do sprint, sugere-se a estrutura usada no Sprint 1.

Critérios de Avaliação

Para o critério "Markdown file with submission summary", basta preencher o template P2.md e colocá-lo numa pasta com nome "markdown". Link para template: https://gitlab.rnl.tecnico.ulisboa.pt/-/snippets/3. Versão "raw": https://gitlab.rnl.tecnico.ulisboa.pt/-/snippets/3/raw/master/P2.md


Histórias e Tarefas

Neste segundo sprint, podem usar histórias diferentes daquelas usadas no primeiro sprint. Podem também ter histórias que se aplicam ao grupo completo e outras que se aplicam apenas a sub-grupos. Por exemplo, a implementação dos dois serviços de update pode fazer parte de uma história que é considerada por todo o grupo. Nesta história podem ter as tarefas de implementação e as tarefas de testes destes dois serviços. Como cada subgrupo é avaliado nos testes de todos os serviços, esta história terá pelo menos 3 testes para o updateTeacherDashboard e 3 testes para o updateAllTeacherDashboards (cada sub-grupo implementa pelo menos 1 caso de teste por serviço).

Dando como exemplo uma história aplicada apenas a um sub-grupo, podemos ter uma história que se divide em tarefas de implementação (por exemplo, a implementação das partes relativas à estatística do sub-grupo 1) no DTO, 2) no serviço createTeacherDashboard, 3) no serviço removeTeacherDashboard, e 4) num dos serviços REST) e em tarefas de teste (por exemplo, 1 ou mais casos de teste para o serviço createTeacherDashboard e 1 ou mais casos de teste para o serviço removeTeacherDashboard).

Importante: não existe uma única maneira de planear o trabalho a ser feito e cada grupo deve decidir na reunião de planeamento o que funciona melhor para o seu caso específico. 

Prazo de Entrega

O prazo de entrega é às 17:00 do dia 17 de março. Daremos 30 minutos de tolerância para resolver pequenos percalços de última hora. Às 17:30, os docentes irão executar um script que recolhe informação sobre todos os repositórios (tags, commits, hashes, e outra informação relevante para as correcções). As tags sprint-2 que forem encontradas pelo script serão as entregas finais que irão ser consideradas e corrigidas. Se não existir tag com esse nome, será usado o último commit do master e será aplicado um desconto de 1 valor (por não haver tag). Todos os commits feitos depois da execução deste script não serão tidos em conta.