|| INICIO || VOLTAR ||

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

|| 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:
O utilizador A pretende ligar-se ao utilizador C
O utilizador A está ligado ao utilizador B que por sua vez está ligado a C
O utilizador A faz um pedido a B para que o introduza a C (UC 11)
O utilizador B recebe o pedido de introdução e aceita ou rejeita (UC 12)
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 tarde caro cliente, A resposta que mencionou refere-se, particularmente, aos pedidos de ligação. A minha questão incidia nos pedidos de introdução, que, a meu ver e tendo em conta esclarecimentos previamente prestados, se trata dum conceito diferente de ligação. É correto assumir, então, que o funcionamento é equivalente para ambos? Obrigado.

ambas as situações devem apresentar os pedidos pendentes e deixar o utilizador actuar sobre o pedido

->MENU

O jogador pode consultar a lista de pedidos de introduções pendentes. Uma introdução pendente entre A e C implica que um jogador B, intermediário, tenha de aceitar o pedido de introdução entre ambos. No caso do pedido ser aceite, o jogador C deve receber um pedido de introdução do jogador A.

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

Testar possibilidade de um jogador não ter pedidos de introduções pendentes. Testar possibilidade de um jogador ter vários pedidos de introduções pendentes. Testar se o pedido chega ao destino correto.

• pedidos pendentes → os utilizadores terão uma lista com os pedidos pendentes, e terão a opção de aceitar ou recusar os mesmos.

->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 AceitarPedidoIntroducaoUI

O padrão Controller foi usado para ter um controlador (neste caso de uso AceitarPedidoIntroducaoController) 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 Introdução ou Pedido de Introdução

Normalmente as regras 1 e 2, neste caso de uso, o creator foi usado para instanciar uma Introdução.

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:

IntroducaoDTO salva os dados relativos aos pedidos de introducao pendentes de um determinado utilizador num objeto intermediário para posteriormente mostrar o utilizador e ele selecionar um;

Introducao é usado para instanciar um Introducao;

IntroducaoRepository é usado para armazenar todos os pedidos de introducao.

AceitarPedidoIntroducaoController 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 IntroducaoDTO.

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

->MENU

Teste 1: Verificar que não é possível criar uma instância da classe Exemplo com valores nulos.

@Test(expected = IllegalArgumentException.class)
	public void ensureNullIsNotAllowed() {
	Exemplo instance = new Exemplo(null, null);
}

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.

->MENU