Projecto

Na unidade curricular de Engenharia de Software, iremos estender a aplicação HumanaEthica, um sistema aberto de gestão de voluntariado que permite ligar instituições de apoio social com voluntários. A plataforma permite a membros de instituições proporem atividades às quais voluntários se podem candidatar.


O objectivo é estender a aplicação com as seguintes três funcionalidades: 

  1. Um voluntário pode candidatar-se a uma atividade.

  2. Uma instituição pode selecionar um voluntário para participar numa atividade.

  3. Um voluntário pode avaliar uma instituição.


Para facilitar o desenvolvimento estão disponíveis vídeos sobre a aplicação, sobre algumas das suas funcionalidades, modelos e código. Adicionalmente, todas as funcionalidades podem ser experimentadas usando as interfaces DEMO disponibilizadas.

Estrutura do projeto

O projeto é efetuado em duas partes, com duas entregas. Existirá uma discussão final, onde cada aluno realizará uma tarefa individual sobre o código final da solução fornecido pelo corpo docente. Como resultado da discussão será verificado se a nota atribuída ao seu projeto é adequada.

Na primeira parte implementa-se a parte servidor da aplicação, enquanto que na segunda parte se implementa a parte cliente.

A primeira parte será desenvolvida sobre o código base fornecido pelo corpo docente. A segunda parte será desenvolvida sobre o código da solução da primeira parte, também fornecido pelo corpo docente. Note que o código base da segunda parte pode conter a implementação de funcionalidades adicionais. Além disso, na resolução da segunda parte pode ser necessário fazer alterações ao código do lado do servidor (por exemplo, colocar mais dados nos DTOs ou acrescentar serviços web).

A implementação das funcionalidades associadas à Activity servem de referência para o desenvolvimento a efectuar durante o projecto.

O projeto é realizado por grupos de 6 alunos, subdivididos em grupos de 2 alunos. Cada subgrupo de 2 alunos fica responsável por uma das funcionalidades. Contudo, os alunos devem conhecer a solução para todas as funcionalidades, em particular no código das soluções fornecidas pelos docentes.

Fluxo de Trabalho

Sugestão de fluxo de trabalho:

1 - Ana termina tarefa no ramo tarefa

2 - Ana faz pull do master 
git checkout master
git pull

3 - Ana faz rebase do ramo da tarefa no master (*) 
git checkout tarefa
git rebase master

4 - Ana cria ramo para submissão
git checkout -b submissao

5 - Ana faz push do ramo de submissão para origin
git push --set-upstream origin submissao

6 - Ana apaga o ramo de submissão na sua máquina local
git checkout tarefa
git branch -D submissao

7 - Ana cria Merge Request (MR) no GitLab atribuindo João e Vítor como revisores (cada um deles pertence a um dos outros subgrupos)

8 - O MR tem conflitos?
   a) O MR não tem conflitos: é revisto e aceite (FIM)
   b) O MR tem conflitos: é rejeitado e o ramo de submissão apagado

9 - Ana faz de novo pull do master
git checkout master
git pull

10 - Ana faz novo rebase do ramo da tarefa com o master (note que o ramo da tarefa pode ter novas contribuições) (*) 
git checkout tarefa
git rebase master

11 - Regressa a (4)

(*) Ao fazer rebase a Ana tem de ter em atenção que os commits que estão depois do master podem ser recalculados. 
Ou seja, se Ana partilhou com o Pedro, o colega de subgrupo, essa tarefa todos os commits que foram efetuados depois da submissão podem-se perder. Assim a Ana deve informar o Pedro que vai fazer rebase e, se o Pedro tiver contribuições no ramo, deve fazer push delas para a Ana fazer depois pull e as mesmas serem incluídas no rebase.

Entregas

O projeto tem duas entregas:

  1. (50%) Parte servidor. Entrega a 8 de março de 2024 às 17:00

  2. (50%) Parte cliente. Entrega a 27 de março de 2024 às 17:00

As entregas são efetuadas no GitLab RNL, usando o ramo sprint-1 para a primeira entrega e o ramo sprint-2 para a segunda entrega.

O ramo não pode ser alterada após a data e hora estipulada (isto será verificado pelos docentes).


Exemplo de como criar o ramo da 1ª entrega:

git checkout master
git checkout -b sprint-1
git push origin sprint-1

Repositório código

O projecto será desenvolvido no GitLab da RNL. Para se registarem, basta fazer login via fénix: https://gitlab.rnl.tecnico.ulisboa.pt

O código do vosso grupo está disponível em https://gitlab.rnl.tecnico.ulisboa.pt/es/es24-XX (onde XX é o número do grupo). Se ainda não tinham criado conta no GitLab, pode demorar alguns dias até terem permissões de acesso ao vosso projecto.


NB: devem configurar o cliente de git com o vosso nome e email. Se usarem o git na consola, devem correr estes comandos:

git config --global user.name "Nome Apelido"

git config --global user.email "your.email@tecnico.ulisboa.pt"

O --global altera a configuração para todos os repositórios. Alternativamente, podem correr o comando só no directório do projecto sem --global.


Para interagir com o repositório sem necessitar de autenticar pode-se criar uma chave ssh no computador:

ssh-keygen -t rsa -b 4096 -C "your.email@tecnico.ulisboa.pt"

quando solicitado dar o nome ist_gitlab_rsa e depois fazer 

cat ~/.ssh/ist_gitlab_rsa.pub 

e colocar conteúdo no GitLab em "Edit Profile->SSL Keys"

Finalmente editar/criar ~/.ssh/config adicionando:

Host gitlab.rnl.tecnico.ulisboa.pt
IdentityFile=~/.ssh/ist_gitlab_rsa


Para fazer clone do projeto:

git clone git@gitlab.rnl.tecnico.ulisboa.pt:es/es24-XX.git 

Grupos e Ramos

O projeto é realizado por grupos de 6 alunos, subdivididos em grupos de 2 alunos. Cada subgrupo de 2 alunos fica responsável por uma das funcionalidades.

Filosofia de desenvolvimento obrigatória (os grupos que não a seguirem serão penalizados):

  • No repositório git existirá um ramo (branch) principal denominado master. Este ramo é partilhado por todos os subgrupos. O buildbot do master deve estar sempre verde.

  • O código é desenvolvido seguindo uma política de merge requests (MRs), em que o código tem que ser revisto obrigatoriamente por um elemento de cada um dos outros dois subgrupos.

  • Cada commit implementa uma tarefa e deve ser feito pelo aluno que implementou o código. NB: pair programming é aceite, desde que seja alternado entre os dois alunos quem escreve o código (e faz commit) e quem observa. Uma tarefa pode ter vários commits se a tarefa incluir, p.ex., código e testes.

  • Os MRs devem ser merged no master via rebase e nunca squash (caso contrário perde-se o histórico dos commits). Merge commits não são aceites para manter o histórico linear.

  • Quando o subgrupo decide dividir as tarefas de uma história, cada aluno deve implementar vários tipos de tarefas. Por exemplo, não pode implementar apenas tarefas de teste.

  • As mensagens de commit devem seguir o padrão de https://www.conventionalcommits.org/en/v1.0.0 

  • Todos os commits devem ser feitos utilizando o nome real e o endereço de email do IST.

Modelo de Domínio

Atualmente o sistema possui o seguinte modelo de domínio: