O Mapa de Gerenciamento

Relatório

Modelo Domínio

        

SSDs

ORM

Decisões de Implementação

• Ao começar a implementar o projeto, decidimos começar por definir o Modelo Domínio apresentado em cima, facilitando assim algumas decisões importantes. Contudo, á medida que fomos desenvolvendo o projeto, o mesmo sofreu algumas alterações devido a decisões de implementação.

Segue em baixo o primeiro modelo e a versão final.

Primeira versão:

[pic 1]

Versão Final:

• Relativamente aos SSD’s desenvolvidos e apresentados anteriormente, tal como no Modelo Domínio, a sua criação possibilitou uma maior compreensão do que seria necessário implementar, contudo, nem tudo o que foi apresentado foi usado para desenvolver o projeto, tendo assim sofrendo assim algumas alterações.
  

No que toca aos SSD’s em si, os que sofreram mais alterações foram o SSD3 e o SSD4, visto serem aqueles que necessitavam de maior atenção na sua implementação.

Devido a uma definição de modelo de domínio inicial que não levou muito em conta o 4º caso de uso, foi necessária alguma adaptação durante a implementação do mesmo nos handlers, pois não se enquadrava na perfeição no modelo implementado.

Foi adicionado o ENUM ReservationType, que indica se uma reserva está relacionada com uma ativade ocasional ou regular, de forma a determinar o comportamento das reservas pagas e expiradas na próxima fase, apagando as sessões reservadas no caso dos agendamentos ocasionais, e removendo as reservas/particpantes das sessões no caso das atividades regulares."

A fotografia apresentada em baixo, demonstra a nossa estratégia de implementação da Base de Dados.

Dificuldade Encontradas

• Ao desenvolver o Projeto, encontrámos algumas dificuldades, nomeadamente a implementação do caso de uso número 3 (Comprar Participação Mensal em Atividade regular) e 4 (Agendar Atividade Ocasional), tal como descrevemos na secção anterior.

Página