ADVENTURE_3

Setup

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 os seguintes comandos (o primeiro comando só é necessário se ainda não tiver o reference na lista de repositórios remotos). Para que os comandos funcionem, devem retirar, temporariamente, as limitações de só aceitar pushes no ramo developer e master através de pull requests. 

$ git remote add reference https://github.com/tecnico-softeng/reference.git
$ git fetch --all
$ git checkout master
$ git reset --hard reference/master
$ git push origin master --force

De seguida deve mudar para o ramo second-deliver, utilizado para a segunda entrega

$ 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

Verifique que consegue correr os testes existentes:

$ mvn clean test

Enunciado

O terceiro sprint do projeto corresponde a alterar o código para suportar os seguintes requisitos:

  • [Refactorização] Altere o código para utilizar o tipo long para representar moeda (Nota: porque não usar floats para moedas; outro link interessante). A utilização de long deve ocorrer em todo o código dos módulos, exceto nas classes pt.ulisboa.tecnico.softeng.<module>.services.local.dataobjects. em que se deve proceder às conversões long <-> float para apresentação na interface. Utilize também uma escala de 1000, ou seja, 1 euro é representado num long pelo valor de 1000.
  • [Refactorização] Uma consequência das alterações no sprint anterior, nomeadamente a remoção dos métodos estáticos das interfaces remotas, é que objetos persistentes passaram a ter atributos transientes (nomeadamente as interfances). Desse modo, quando o objeto é materializado a partir da base de dados esses atributos não serão inicializados. Devem garantir que os objetos persistentes com atributos estáticos sejam resilientes a este facto. 
  • [Refactorização] A reserva de um quarto está hard-coded para reservar SINGLE. Deve alterar para que o utilizador possa indicar o tipo de quarto que pretende reservar. Para além disso, deverá ser possível não reservar nenhum quarto mesmo quando a aventura é superior a 1 dia, mantendo-se a restrição de não ser possível reservar quarto para aventuras com duração de um dia.
  • [Refactorização] A reserva de um veículo está hard-coded para reservar CAR. Deve alterar para que o utilizador possa indicar o tipo de veículo que pretende reservar.
  • [Refactorização] Altere para que o Tax passe a permitir que um TaxPayer seja simultaneamente Seller e Buyer, e, por isso, o Broker passar a ter a apenas um NIF, em vez de dois.
  • [Funcionalidade] Forneça uma nova operação processPayment em bank.BankInterface em que BankOperationData possui um sourceIban e um targetIban, e passa a existir um novo tipo de Operation, transfer. Crie uma hierarquia de classes associada a Operation, removendo a informação persistente associada ao tipo da operação. 
    • No caso da transferência ser entre contas de bancos diferentes, a operação de transferência é registada apenas no banco origem da transferência. 
    • É possível reverter uma operação de transferência. O revert de uma transferência tem como transactionSource "REVERT" e como transactionReference a referência do transfer que reverte. Uma REVERTED transfer não pode ser REVERTED, lançando uma exceção.
    • Dicas:
      • Introduza em RestBankOperationData um sourceIban (substituindo iban) e targetIban
      • Adicione ao booking um atributo providerIban. Persista e teste a persistência desse atributo.

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 concluida. 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-requests. No â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, serão bonificados os alunos que tenham implementado metade das funcionalidades que lhe estão atribuídas ao fim de uma semana, ou seja até ao dia 16 de abril. 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 third-deliver
$ git tag ADVENTURE_3
$ git push origin --tags third-deliver:third-deliver

Esta tag colocada deve ter uma data anterior à data limite de entrega, dia 22 de Abril 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 Three. 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.