ADVENTURE_4

Setup

Para realizar a quarta parte do projeto deve começar por resolver na totalidade os exercícios práticos das aula-spring e aula-jmeter.

Para ser efetuado por um único elemento do grupo

Obtenha a nova versão do código disponibilizada em https://github.com/tecnico-softeng/reference.git. Instale essa versão no ramo master e crie uma cópia para o ramo develop onde o grupo irá realizar as suas atividades de desenvolvimento. Para isso faça

$ git fetch reference
$ git checkout master
$ git merge reference/master
$ git push origin master
de seguida deve assegurar-se que o código da segunda parte foi entregue através do ramo third-deliver, mudando para esse ramo
$ git checkout third-deliver

pode então apagar o ramo develop, para isso tem que ser colocar remover a branch protection rules associadas ao ramo develop e colocar o master como ramo default (em settings no GitHub), e então mudar para o ramo master, criar um novo ramo develop a partir do master e colocar a nova versão do develop em origin

$ git branch -d develop
$ git checkout master
$ git checkout -b develop
$ git push origin develop --force

deve agora votar aos settings do GithHub para colocar develop como default e definir a regra de proteção do ramo que impede push e obriga a dois reviews para cada pull-request.

Pode agora correr os testes existentes

$ mvn clean test

Os restantes elementos do grupo, após a nova versão do código estar no GitHub do projeto devem actualizar os ramos locais:

$ git fetch --all
$ git checkout master
$ git pull
$ git branch -d develop
$ git checkout -b develop origin/develop

deve agora correr os testes existentes

$ mvn clean test

e abrir o projeto no Eclipse/IntelliJ.

Enunciado

A quarta parte do projeto tem duas partes: (1) resolver todas as partes que deixaram de funcionar depois das alterações efetuadas no terceiro sprint; (2) definição de novas funcionalidades nas interfaces utilizador e testes de JMeter.

(1) Relativamente à primeira parte, após as alterações efetuadas no terceiro sprint, houve interfaces do utilizador que deixaram de funcionar assim como testes de JMeter. Por outro lado, devido a não existirem testes para essas partes, poderá ser necessário corrigir o código associado aos controladores, WEB e REST, e aos DTOs (Data Transfer Objects), remotos e locais. Assim, devem ser identificadas as partes que não funcionam e definidas tarefas para a sua correção.

(2) No que diz respeito à segunda parte, devem ser efetuadas as seguintes tarefas:

  • Interface utilizador do activity
    • adicionar a idade ao form de reserva de uma atividade
    • adicionar à lista de reservas de atividade a informação relevante, que é específica da reserva
    • possibilitar o cancelamento de uma reserva de atividade
    • indicar o número de vagas disponíveis associadas a uma oferta, deve não considerar as canceladas
  • Interface utilizador do bank
    • efetuar uma transferência entre duas contas
    • enriquecer a lista de operações com a operação de transferência
    • possibilitar efetuar o desfazer de uma operação (UNDO)
  • Interface utilizador do boker
    • mostrar a informação associada a uma reserva de quarto obtida por um bulkbooking
    • cancelar uma reserva de quarto obtida por um bulkbooking
  • Interface utilizador do car
    • mostrar a lista de pedidos pendentes no Processor
    • apresentar a informação associada a cada um dos pedidos pendentes 
    • mostrar o número de pedidos pendentes
  • Interface utilizador do hotel
    • adicionar à lista de reservas de quarto a informação relevante, que é específica da reserva
    • possibilitar o cancelamento de uma reserva de quarto
  • Interface utilizador do tax
    • mostrar a lista do total de impostos pagos e do total de imposto devolvido para cada ano
  • Teste JMeter de integração em que se usa uma reserva de quarto obtida através de bulkbooking. Este é um teste de sucesso e não necessita de efetuar reserva de veículo.

Note que, sempre que durante a execução de uma operação na interface utilizador for lançada uma excepção, deve ser apresentada uma mensagem de erro indicando que não foi possível efetuar a operação.

A submissão dos commits ao repositório do grupo deve ser feita usando pull-requests sobre o ramo develop, e cada submissão deve ser revista e aprovada por dois (2) colegas de grupo. Devem apenas ter um pull-request por tarefa, de modo que só devem fazer o pull-request quando a tarefa estiver concluída. Informação complementar para configurar os repositórios para forçar essa metodologia de desenvolvimento pode ser obtida do seguinte link https://help.github.com/en/articles/enabling-required-reviews-for-pull-requestsNo âmbito do projeto, devem proteger contra pushes directos no ramo develop, e configurar develop como o ramo default (https://help.github.com/en/articles/setting-the-default-branch).

Os grupos devem começar por reunir para identificar as tarefas, associá-las ao backlog, e definir dependências de precedência entre elas, de forma a calendarizá-las no período de 2 semanas disponíveis.

Cada elemento do grupo deve migrar um número idêntico de tarefas, e que correspondam a uma quantidade de trabalho semelhante. É obrigatório indicar no README.md uma tabela com as tarefas, quem fez, data da conclusão da tarefa e links para PRs que resolvem as tarefas.

Considerando uma duração de duas semanas para a solução do projeto, haverá bonificação sempre que tenham implementado metade das funcionalidades que estão atribuídas ao fim de uma semana, ou seja até ao dia 3 de maio (AoE). Note que deve ser associada uma issue do github por cada tarefa a desenvolver. O commit final deve fechar essa tarefa (closes #n).

Para a entrega deverão fazer:

$ git checkout develop
$ git checkout -b fourth-deliver
$ git tag ADVENTURE_4
$ git push origin --tags fourth-deliver:fourth-deliver
Esta tag colocada deve ter uma data anterior à data limite de entrega, dia 10 de Maio pelas 17:00.

Durante os laboratórios, os alunos dos grupos serão avaliados com base no trabalho desenvolvido durante cada uma das semanas. Para isso é necessária a criação de um sprint no GitHub, usando a interface de Project, em que cada tarefa deve ser representada por um Note. Neste caso o projeto a criar deve-se chamar Sprint Fourth. Uma vez criado o projeto, escolhendo como template pré-definido "Kanban (automatic)", deve ser alterado o nome da coluna To Do para Backlog,. Nesta coluna serão colocadas todas as tarefas a realizar, as quais serão definidas durante a reunião do grupo. Cada tarefa é criada como uma Note, contendo a descrição da tarefa a realizar, e deve ser convertida num Issue, por forma a que os commits possam ser-lhe associados. Cada aluno que vá realizar uma tarefa move o respetivo note da coluna de Backlog para a coluna In progress, e atribui-se essa tarefa no Issue respetivo. Quando a tarefa é terminada, o commit deve ser associado ao respetivo Issue, passando este para o estado fechado. Para se associar um commit a um Issue deve colocar-se na mensagem de commit close #n, em que n é o número do Issue. Quando o Issue é fechado o respetivo Note é automaticamente passado da coluna In progress para a coluna Done. Cada commit deve estar associado a uma única tarefa.