ADVENTURE_3

Para realizar a terceira parte do projeto deve começar por resolver na totalidade o exercício prático da aula-dml.

Uma vez que domine os conceitos de Fénix Framework e DML pode iniciar a resolução do projeto, obtendo a nova versão do código disponibilizada em https://github.com/tecnico-softeng/reference.git. Para isso faça
$ git fetch reference
$ get checkout master
$ git merge reference/master
de seguida deve assegurar-se que o código da segunda parte foi entregue através do ramo second-deliver, mudando para esse ramo
$ git checkout second-deliver
pode então apagar o ramo develop, 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 correr os testes existentes 
$ mvn clean test
e abrir o projeto no Eclipse. 

A terceira parte do projeto corresponde a introduzir suporte persistente no domínio dos 4 módulos utilizando a FénixFramework e efetuando tarefas de refatorização do código, em que é usada apenas uma base de dados e a domain root  possui os conjuntos de instâncias de Hotel, de ActivityProvider, de Bank e de Broker. Nos módulos broker e bank já existem implementações iniciais que podem ser usadas como referência.

As tarefas básicas de refatorização de código são:
  • Tornar persistente uma classe
  • Tornar persistente a associação entre duas classes
  • Tornar persistente os atributos de uma classe
Ao iniciar as tarefas (para cada uma delas compile e corra os testes) de um módulo, por exemplo para o módulo hotel, deve começar por:
  • Definir a classe abstrata RollbackTestAbstractClass
  • Alterar todos os testes para subclasses de RollbackTestAbstractClass de forma a garantir que a execução dos testes não altera a base de dados
  • Tornar persistente a classe de topo do módulo, Hotel
  • Associar a classe de topo do módulo à DomainRoot
  • Definir classe HotelPersistenceTest para testar a persistência da criação de objetos Hotel
  • Remover a variável estática Hotel.hotels
  • Adicionar as variáveis code e name na DML

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 disponível. Note que as tarefas associadas a um módulo dificilmente serão paralelizáveis, pelo deve haver uma sincronização explícita entre as tarefas dos membro do subgrupo.

Cada grupo deve-se dividir em sub-grupos de 3 alunos, em que cada um deles, trabalha num módulo. O sub-grupo que trabalhar no módulo hotel deverá também trabalhar no módulo broker. É obrigatório indicar no README.md quais os elementos que trabalham em cada um dos módulos, indicando o número de aluno, o nome e o username no GitHub. 

IMPORTANTE: Os subgrupos não podem ter os mesmos elementos da primeira parte do projeto. Em cada subgrupo, pelo menos 2 dos elementos não podem ter trabalhado no mesmo módulo em que trabalharam na primeira parte do projeto.

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

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