|| INICIO || VOLTAR ||

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

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

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

Boa tarde, Perante o seguinte excerto do caderno de encargos: “Ou seja, o sistema sugere alguns “utilizadores objetivo” e o utilizador/jogador recém registado escolhe quais gostaria de ter na sua rede. O sistema faz a introdução entre os dois. Caberá ao utilizador que recebe o pedido de introdução aceitar ou não tal como nos casos de introdução por um utilizador. Também é possível o utilizador recém registado pesquisar utilizadores que conheça na rede e fazer o pedido de ligação. Depois dessas ligações iniciais para criar uma nova ligação, um jogador deverá “deslocar-se” (navegar pelo grafo seguindo as ligações) para um nó correspondente a alguém da sua rede social e que seja parte da rede social de quem se quer ser “amigo” e pedir uma “introdução” a esse amigo.” E usando como exemplo: Uma Rede 1 que inclui utilizadores A e B, e uma Rede 2 que inclui utilizadores B e C. Tínhamos pensado que o procedimento para criar uma ligação seria: Utilizador A envia um pedido de introdução ao utilizador B e, caso seja aceite, o utilizador A pode enviar um pedido de ligação ao utilizador C, que teria também ser aprovado ou rejeitado. Depois do pedido de ligação ser aprovado, ambos utilizadores introduzem a força de ligação e tags pretendidas. No caso da introdução ser feita pelo sistema seria também necessário um posterior pedido de ligação. Pergunta 1 – Esta interpretação é correta/representa o pretendido? Pergunta 2 - Podem existir relações num só sentido? Seria possível, por exemplo, criar uma ligação de utilizador A para utilizador C, sem existir uma ligação de C para A (algo análogo a um sistema de seguidores)? Com os melhores cumprimentos, Grupo 80

Resposta 1 - sim, genericamente está correta. quando o jogador está a executar uma missão navegará de nó em nó fazendo esses pedidos de introdução
Resposta 2 - não. a relação é unidirecional no que toca à força de relação mas se B aceita pedido de introdução/ligação de A, então é estabelecida uma ligação entre A e B e simultaneamente entre B e A

Prezado Cliente, no caderno de encargos afirm "Quando um utilizador se regista no sistema, são apresentadas sugestões de ligações iniciais com base nas tags em comum. " Estamos a considerar que no momento em que faz o seu registo, o utilizador deve introduzir tags que o caracterizem. Corresponde este raciocínio à estrutura esperada do protótipo? Cordialmente, Carlos Barbosa _3NA_076

Sim. No registo o utilizador deve indicadar tags que o caracterizem.

Boa tarde caro cliente, Os pedidos de ligação, realizados para a construção inicial da rede de um utilizador (baseados em relações que existam fora da rede social) devem ser aceites pelo outro utilizador, ou devem ser automaticamente aceites? Muito obrigado, Luís Correia.

Os pedidos devem sempre ser aceites ou rejeitados pelo utilizador destinatário do pedido. nunca são aceites automaticamente

Boa Tarde, Quais são os critérios do sistema para sugerir utilizadores?

"Quando um utilizador se regista no sistema são apresentadas sugestões de ligações iniciais com base
nas tags em comum." (Caderno de encargos pag.3).

->MENU

Para que o sistema sugira "utilizadores objetivos", o utilizador deve indicar no momento do seu registo, algumas tags com que se identifique. Assim, com base nestas tags, são apresentados utilizadores que com elas se identifiquem, permitindo ao utilizador em questão, realizar pedidos de introdução aos mesmos sugeridos pelo sistema. Após serem feitos os pedidos de introdução, o sistema gera automaticamente um pedido de ligação.

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

Testes de comparação de tags entre utiizadores.

• tags - unidirecionais , obrigatorio

• pedido de ligação - unidirecional, (se um utilizador B aceita pedido de introdução/ligação de A, então é estabelecida uma ligação entre A e B e simultaneamente entre B e A.)

->MENU

O padrão de User Interface é usado para fornecer uma interface simples de visualizar utilizadores objetivo (neste caso de usar EscolherUtilizadoresObjetivoUI) para que as partes restantes do sistema sejam separadas.

O padrão Controller foi usado para ter um controlador (neste caso de uso EscolherUtilizadoresObjetivoController) 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.

Normalmente as regras 1 e 2, neste caso de uso, o creator foi usado pelo Builder para instanciar um Jogador, pois um Utilizador tem um Jogador associado.

Padrão usado para diminuir o acoplamento entre classes e, ao mesmo tempo, apenas atribuir a elas 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:

UtilizadorDTO salva os dados inseridos num objeto intermediário para posteriormente mostrar o Utilizador criado;

Utilizador é usado para instanciar um Utilizador;

UserRepository é usado para armazenar Utilizador criado.

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

O padrão builder serve para criar o objeto Jogador que representa o system user permitindo assim já que este é um objeto complexo a construção de diferentes representações, foi também usado para construir o Utilizador.

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 UserRepository, onde é armazenado e tem acesso aos utilizadores. 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: 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);
}

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