UC_33 - antoniodanielbf-isep/LAPR5-2021 GitHub Wiki
=======================================
|| REQUISITOS || ANÁLISE || DESIGN || OBSERVAÇÕES ||
=======================================
Boa tarde caro cliente, Relativamente ás UCs 12 e 33, qual é a diferença entre "aprovar um pedido de introdução" e "aceitar uma introdução"? Muito obrigado, Luís Correia.
os UC 11, 12 e 33 estão interligados e funcionam da seguinte forma:
1. O utilizador A pretende ligar-se ao utilizador C
2. O utilizador A está ligado ao utilizador B que por sua vez está ligado a C
3. O utilizador A faz um pedido a B para que o introduza a C (UC 11)
4. O utilizador B recebe o pedido de introdução e aceita ou rejeita (UC 12)
5. Se o pedido de introdução foi aceite B, o utilizador C recebe esse pedido e aceita ou rejeita (UC 33) ligar-se a A
Boa noite, estimado, cliente, Gostaríamos de saber se nesta funcionalidade o Utilizador recebe primeiro a lista de pedidos de ligação pendentes (UC-35), e caso aceite a introdução, deva estabelecer os parâmetros (tags e força de ligação) dessa relação (UC-03)? Cumprimentos, Grupo 61
o utilizador deve poder consultar os pedidos pendentes e actuar sobre cada um (aceitar/rejeitar)
ao aceitar o pedido de ligação deverá indicar a força da relação e quais as tags que a caracterizam.
O jogador pode consultar a lista de introduções pendentes. Uma introdução pendente entre A e C implica que um jogador B tenha aceite o pedido de introdução entre ambos. O pedido de introdução neste caso teria sido efetuado por A ou por C. No caso de a introdução ser aceite, o jogador que aceitou deve introduzir a tag e força de relação para o relacioanemnto/ligação entre ambos se relacionar A força de ligação é numérica, de 1 a 100 e as tags são palavras curtas alfanuméricas, identificadoras de uma relação.
Até ao momento não são necessárias alterações no MD.
Testar possibilidade de um jogador não ter introduções pendentes Testes de validação das tags e força de ligação no caso da introdução ser aceite
- tags - unidirecionais , obrigatório pelo menos uma
- força de ligação - unidirecional, numérico, varia entre 1 e 100, obrigatório
Nesta secção deve apresentar e descrever as principais classes envolvidas na realização da funcionalidade.
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 IntroducoesPendentesUI
O padrão Controller foi usado para ter um controlador (neste caso de uso IntroducoesPendentesController) 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 Relacionamento, ForcaDeLigacao e Tag.
Normalmente as regras 1 e 2, neste caso de uso, o creator foi usado para instanciar uma ForcaDeLigacao, uma Tag e um Relacionamento.
Padrão usado para diminuir o acoplamento entre classes e, ao mesmo tempo, 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:
IntroducoesPendentesDTO salva os dados relativos às introducoes pendentes num objeto intermediário para posteriormente mostrar o utilizador e ele selecionar um;
Relacao é usado para instanciar um Relacao;
RelacaoRepository é usado para armazenar as relacoes existentes na rede social.
IntroducoesPendentesController 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 IntroducoesPendentesDTO.
O Repositório ajuda a persistir, armazenar e acessar dados. É usado na camada de Persistência para garantir a instanciação de RedeSocialRepository, onde é armazenado. Abstrai os detalhes dos métodos que modificam o estado deste objeto.
Nesta secção deve sistematizar como os testes foram concebidos para permitir uma correta aferição da satisfação dos requisitos.
Teste 1: Efetuar operação quando o jogador não tem qualquer introdução por aceitar/rejeitar. Teste 2: Introduzir um valor de força de ligação alfanumérico Teste 2 Introduzir um valor de força de ligação menor do que 1 ou maior do que 100 Teste 4: Introduzir um valor nulo na força de ligação ou na tag
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. Para 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 critica sobre o trabalho desenvolvido apontando, por exemplo, outras alternativas e ou trabalhos futuros relacionados.