ADVENTURE_2

Para realizar a segunda parte do projeto deve obter a nova versão do código disponibilizada em https://github.com/tecnico-softeng/reference.git. Deve portanto adicionar um novo repositório remoto da seguinte forma:
$ git remote add reference https://github.com/tecnico-softeng/reference.git

De seguida deve-se assegurar que o código da primeira parte foi entregue através do ramo first-deliver, mudando para esse ramo
$ git checkout first-deliver

Pode então apagar a versão atual que possui do ramo master
$ git branch -d master  

e obter a nova versão do master a partir do remoto reference
$ git fetch reference
$ git checkout -b master reference/master

Para que o ramo em origin do master fique igual ao novo deve sobrepor a nova versão
$ git push origin master --force

Deve de seguida criar o ramo develop onde o grupo irá trabalhar na segunda parte e criar esse ramo em origin
$ git checkout -b develop
$ git push origin develop:develop

Deve agora correr os testes existentes 
$ mvn clean test

e abrir o projeto no Eclipse. 

A segunda parte versa sobre uma implementação mais elaborada do método process da classe Adventure, tirando partido do padrão de desenho State, promove o trabalho separado entre módulos, utilizando a tecnologia JMockit, e promove um desenvolvimento em que se testa primeiro. Assim, deve começar por ler a classe Adventure (em pt.ulisboa.tecnico.softeng.borker.domain) do código que acabou de instalar: ela servirá de ponto de partida a todas as alterações a realizar nesta segunda parte. Adicionalmente, foi criada uma nova classe no módulo broker, BulkRoomBooking, que gere uma reserva em grupo. Estas classes possuem indicado como TODO, ou em comentários, o comportamento esperado que deve ser implementado.

As tarefas a realizar são:
  • Refatorizar o código de modo a que cada uma das alternativas associadas aos estado dos objetos da classe Adventure sejam modularizadas na sua própria classe, subclasse de AdventureState. Cada uma destas refatorizações deve corresponder a uma tarefa com o seu respetivo commit. Nota: veja a implementação no código fornecido para o estado CANCELLED.
  • Para cada nova subclasse de AdventureState defina uma classe de testes e implemente o(s) caso(s) de teste de sucesso, usando JMockit sempre que necessário. A concretização de cada uma destas classes de teste deve corresponder a uma tarefa com o seu respetivo commit. O comportamento esperado do método process em cada estado está indicado no código. Nota: veja a implementação da classe CancelledStateProcessMethodTest.
  • Implementar o comportamento, e os restantes casos testes, de cada uma das subclasses de AdventureState, de modo a que os casos de testes passem. Cada implementação de uma subclasse corresponde a uma tarefa com o seu respetivo commit.
  • Implementar as novos métodos nos módulos bank, activity e hotel. Para cada um deles é necessário escrever os testes primeiro, o que corresponde a uma tarefa com o seu commit, seguido a sua implementação, o que corresponde a uma nova tarefa com o seu commit. Note que, se devido às alterações, alguns testes regressivos deixarem de funcionar os deve corrigir. Os métodos a considerar são:
    • Bank.cancelPayment, credita o pagamento através de um depósito, criando uma nova instância de Operation e devolve a sua referência
    • Bank.getOperationData, devolve um objeto BankOperationData
    • ActivityProvider.cancelReservation, cancela uma reserva de atividade, adicionado uma referência de cancelamento ao respetivo objeto Booking, retorna essa referência
    • ActivityProvider.getActivityReservationData, devolve um objeto ActivityReservationData
    • Hotel.cancelBooking, cancela uma reserva de quarto, adicionando uma referência de cancelamento ao respetivo objeto Booking, retorna essa referência
    • Hotel.getRoomBookingData, devolve um objeto RoomBookingData
  • Introduzir o seguinte invariante no módulo hotel: a reserva de um quarto deve ter uma duração igual ou superior a um dia. Todas as alterações nas classes de domínio, e nos seus testes, necessárias para implementar este invariante devem ser associadas a uma única tarefa.
  • Implementar uma classe de teste, AdventureSequenceTest que contém os testes de sequência de métodos da classe Adventure. Utilize JMockit para simular as interações com os módulos externos. Associe duas tarefas a esta atividade, uma que testa as sequências que terminam no estado CONFIRMED e outra que testa as sequências que terminam no estado CANCELLED. Note que todos os testes devem ser implementados na mesma classe, AdventureSequenceTest.
  • Testar e implementar os seguintes métodos da classe BulkRoomBooking do módulo broker. Use JMockit nos testes, sempre que necessário.
    • BulkRoomBooking.processBooking faz um conjunto de reservas de quarto, ignorando se é SINGLE ou DOUBLE, adicionando-as ao conjunto de referências.
    • BulkRoomBooking.getReference retorna uma referência de um quarto, SINGLE ou DOUBLE, do conjunto de reservas em grupo, removendo-a do conjunto de referências. Se não existir retorna null.
    • Hotel.bulkBooking cria um conjunto de instâncias de Booking e retorna as suas referências, sendo irrelevante qual o tipo do quarto. Se não houver disponibilidade para a totalidade do pedido é lançada uma HotelException.

Cada aluno deve resolver um dos seguintes grupos de tarefas e indicar essa atribuição no README.md:
  • Grupo 1 - tarefas associadas à subclasse ProcessPaymentState de AdventureState, o que inclui a refatorização, o teste com JMockit, e a implementação. Inclui também o teste e a implementação de Hotel.getRoomBookingData.
  • Grupo 2 - tarefas associadas à subclasse ReserveActivityState de AdventureState, o que inclui a refatorização, o teste com JMockit, e a implementação. Inclui também o teste e a implementação de Bank.getOperationData.
  • Grupo 3 - tarefas associadas à subclasse BookRoomState de AdventureState, o que inclui a refatorização, o teste com JMockit, e a implementação. Inclui também o teste e a implementação de Bank.cancelPayment.
  • Grupo 4 - tarefas associadas à subclasse ConfirmedState de AdventureState, o que inclui a refatorização, o teste com JMockit, e a implementação. Inclui também o teste e a implementação de Hotel.bulkBooking.
  • Grupo 5 - tarefas associadas à subclasse UndoState de AdventureState, o que inclui a refatorização, o teste com JMockit, e a implementação.
  • Grupo 6 - tarefas associadas à classe AdventureSequenceTest, para as sequências que terminam no estado CONFIRMED e à implementação de Hotel.cancelBooking.
  • Grupo 7 - tarefas associadas à classe AdventureSequenceTest, para as sequências que terminam no estado CANCELLED e à implementação de ActivityProvider.cancelReservation.
  • Grupo 8 - tarefas associadas à implementação e teste de BulkRoomBooking.processBooking e de ActivityProvider.getActivityReservationData.
  • Grupo 9 - tarefas associadas à implementação do novo invariante no módulo hotel e ao teste e implementação de BulkRoomBooking.getReference.

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. Por exemplo, durante a primeira semana é necessário que esteja terminada a refatorização da classe Adventure. Grupos com menos de 9 elementos devem realizar as primeiras tarefas.

IMPORTANTE: Nesta parte a coordenação entre os membros do grupo é crucial. Tire partido dos issues, milestones e projects do GitHub.
Teste argumentos inválidos apenas nas interfaces dos módulos, tipicamente métodos estáticos. Para verificar a cobertura dos testes execute
$ mvn clean cobertura:cobertura

e analize os resultados para cada um dos módulos em target/site/cobertura.

Para a entrega deverão fazer:
$ git checkout develop
$ git checkout -b second-deliver
$ git tag ADVENTURE_2
$ git push origin --tags second-deliver:second-deliver

A tag deve ter uma data anterior à data limite de entrega, dia 2 de Abril pelas 20:00.