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
de seguida deve assegurar-se que o código da segunda parte foi entregue através do ramo second-deliver, mudando para esse ramo
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.