|| INICIO || VOLTAR ||

=======================================

|| REQUISITOS || ANÁLISE || DESIGN || OBSERVAÇÕES ||

=======================================

Bom dia, prezado, cliente, Poder-me-ia esclarecer se nesta funcionalidade o utilizador simplesmente coloca de novo o seu estado de humor por cima do anterior ou pretende algo mais? Humildes Cumprimentos, Grupo 61

nesta iteração pretende-se que o utilizador simplesmente possa indicar qual o seu estado de humor atual de uma lista pré-definida.
quando o estado de humor é visualizado no perfil deve ter indicação de há quanto tempo é o utilizador está com aquele estado de humor (considerar a data/hora em que o estado de humor foi indicado e a data/hora atual)
a lista de estados de humor possiveis (derivado da lista de emoções do modelo OCC):
- Joyful
- Distressed
- Hopeful
- Fearful
- Relieve
- Disappointed
- Proud
- Remorseful
- Grateful
- Angry

->MENU

De forma a editar o estado emocional (estado de humor) do jogador o mesmo regista-se no sistema e escolhe posteriormente a opção de mudar o estado emocional, é-lhe apresentado uma lista de estados emocionais disponíveis pedindo que escolha uma das opções. Após a escolha do jogador, o estado emocional fica registado no seu perfil, assim como a data/hora em que foi indicado.

Até ao momento não são necessárias alterações no MD.

Não são necessários testes, pois os estados emocionais serão selecionados a partir de uma lista predefinida.

• estado emocional → terá uma lista com os estados disponíveis conforme o modelo OCC.

->MENU

O padrão de User Interface é usado para fornecer uma ‘interface’ simples de usar para o utilizador e servir de intermediário entre o utilizador e as partes funcionais so sistema. Neste caso é utilizada a classe EditarEstadoHumorUI

O padrão Controller foi usado para ter um controlador (neste caso de uso EditarEstadoHumorController) que pode atuar como um organizador da lógica do caso de uso.

Esse padrão atribui responsabilidades às classes para o domínio de negócios que ele representa, como é o caso do Utilizador.

Padrão usado para diminuir o acoplamento entre classes e, em simultâneo, apenas atribuir-lhes associações que sejam realmente coesas com o seu propósito. Em todo esse caso de uso, tentamos restringir as responsabilidades próprias de cada classe e, assim, minimizar as associações apenas ao necessário. Como pode ser visto neste caso de uso:

Utilizador é usado para instanciar o utilizador do caso de uso;

UserRepository é usado para armazenar e aceder ao utilizador.

EditarEstadoHumorController trata de toda a lógica de atualização de um evento delegando etapas intermediárias às outras classes.

O padrão DTO fornece um objeto intermediário para transferência de dados, reduzindo o acoplamento entre o domínio e as camadas do aplicativo, permitindo o carregamento rápido do aplicativo e garantindo mais segurança. Nesse caso de uso, temos a sua implementação na classe UtilizadorDTO.

O Repositório ajuda a persistir, armazenar e acessar dados. É usado na camada de Persistência para garantir a instanciação de UtilizadorRepository, onde é armazenado. Abstrai os detalhes dos métodos que modificam o estado deste objeto.

Não serão necessários testes.

->MENU

Nesta secção a equipa deve providenciar, se necessário, algumas evidências de que a implementação está em conformidade com o design efetuado. Além disso, deve mencionar/descrever a existência de outros ficheiros (e.g. de configuração) relevantes e destacar commits relevantes;

Recomenda-se que organize este conteúdo por subsecções.

Nesta secção a equipa deve descrever os esforços realizados no sentido de integrar a funcionalidade desenvolvida com as restantes funcionalidades do sistema.

Nesta secção sugere-se que a equipa apresente uma perspetiva crítica sobre o trabalho desenvolvido apontando, por exemplo, outras alternativas e/ou trabalhos futuros relacionados.

->MENU