|| INICIO || VOLTAR ||

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

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

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

Boa tarde, estimado cliente,

Poder-me-ia esclarecer melhor quais os níveis de dificuldade associados às missões?

Cumprimentos,

o nível de dificuldade de uma missão será a distância que se encontra o utilizador que se pretende relacionar.
ou seja uma missão de nivel 2 consiste em estabelecer ligação com alguém está a 2 graus de distância (ex., A - B - C)
enquanto uma missão de nível 4 corresponde a estabelecer ligação com alguem que está a 4 graus de distância (ex., A - B - C - D - E)

Boa noite,

Considerando os exemplos dados, gostaria de esclarecer uma questão: Assumindo que A é o utilizador em si, e B é um outro utilizador já amigo de A, existe a relação A - B. Se B for amigo de C, haverá então uma relação A - B - C.

A questão então é: Qual o valor de dificuldade n, para C ser sugerido como objetivo para o utilizador A? É contada a ligação direta já existente A - B?

Se a ligação direta não for contada, ou seja, se se partir de B, uma missão de dificuldade 1 alcança a ligação B - C. Se a ligação direta for contada, se se partir de A, teria de ser uma missão de dificuldade 2 para alcançar a ligação B - C. (Neste segundo caso, não poderia haver missões de dificuldade 1, pois por definição são já as ligações entre A e os seus amigos diretos) Numa questão relacionada, se o utilizador escolher, por exemplo, uma missão de dificuldade 10, e já não existirem utilizadores a essa distância, deverá colocar-se como objetivo um utilizador com a maior distância possível?

o nível de dificuldade corresponde aos graus de separação. nesse sentido a ligação direta entre A e B conta e não podem existir missões de nivel 1
se não existirem utilizadores afastados ao nivel de dificuldade introduzida então deve ser sugerido um utilizaodr o mais afastado possivel

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)?

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    

Boa noite caro Cliente,

Relativamente à UC11 - Efetuar pedido de introdução, considerando que X solicita a Y para ser introduzido a Z, pretende que seja apresentada uma lista de elementos aos quais X pode pedir introdução (X terá de ter ligação com pelo menos um elemento que tenha ligação com Z), que seja efetuada a seleção e de seguida seja apresentada uma lista de quem pode efetuar a introdução para ser selecionado o elemento Y? Ou pretende que seja primeiro selecionado o elemento que fará a introdução (Y) e só depois o elemento Z?

Relativamente à UC35 - Listar pedidos de ligação, nesta lista constam os pedidos de introdução já aceites, correto?

UC11: o objectivo do utilizador X é ligar-se ao utilizador Z, nesse sentido X deve em primeiro lugar pesquisar, ou o sistema designar Z. em seguida o sistema deve apoiar o utilizador X indicando-lhe que utilizadores poderão ajudar nessa ligação apresentando uma lista das ligações de X que podem ser usadas para o pedido de introdução. Dessa lista, o utilizador X escolherá o utilizador Y ao qual efetua o pedido de introdução.

UC35: deve ser possivel obter todos os pedidos e permitir filtrar, por exemplo, os que já forma aceites, recusados ou ainda por aceitar

Boa noite,

Em relação à primeira pergunta deste post, será que poderia explicar melhor a parte "ou o sistema designar Z"? Porque daí surgiram duas dúvidas: Se haverá algum critério para ser decidido se é o utilizador X que pesquisa e seleciona Z? Se haverá algum critério para essa designação por parte do sistema e se se pretende que seja responsabilidade da IA efetuar essa designação?

o sistema designará Z quando o utilizador inicia uma missão e indica qual o grau de dificuldade desejado. o sistema irá determinar um utilizador objectivo que esteja a n graus de distância.
Numa primeira implementação poderá ser um algoritmo muito simples e apenas funcionar para nivel 2 ou escolher aleatoriamente um utilizador. em iterações futuras poderá ser refinado o algoritmo.

Boa tarde,

Gostaria de perguntar acerca das características de um pedido de introdução e de um pedido de ligação. Penso que foi discutido com o cliente que um utilizador X, quando quer fazer um pedido de ligação ao utilizador Z, poderia incluir algo como um texto de apresentação e tags.

No entanto, como na realidade o que ocorre é que o utilizador X efetua primeiro um pedido de introdução a Y, e o pedido de ligação ao utilizador Z é gerado automaticamente, parece que esse texto e tags já teriam de ser especificados aquando do pedido de introdução, e incluídos no mesmo? E se assim é, deve-se permitir ao utilizador intermédio Y ver esse texto e tags? De forma a ajudar na decisão de aceitar ou não o pedido de introdução? Ou visualizar estas informações já constituiria algo a analisar futuramente, no âmbito do RGPD?

o utilizador A faz o pedido a B para que o apresente a C.
nesse sentido o pedido de introdução deve conter um texto dirigido ao utilizador B - uma mensagem, ex., 
"Olá Marta, podes por favor apresentar-me ao Carlos?
gostava de me candidatar à empresa onde dele trabalha mas queria primeiro saber qual o ambiente. obrigado, beijo"
- esta mensagem será visivel apenas pelo utilizador B
e deve também conter uma mensagem dirigida a C, ex., "Gostaria de o adicionar à minha rede pois
pretendo candidatar-me à sua empresa e gostava de saber mais informações". esta mensagem apenas será visivel pelo utilizador C

Boa noite, Esta segunda mensagem que referiu de A para C, faria sentido esta fazer parte do pedido de ligação que é feito automaticamente quando a introdução é aceite pelo utilizador B? Pessoalmente não vejo muito sentido em ter o utilizador C a aceitar uma introdução com a mensagem que lhe foi dirigida e depois ter novamente de aceitar um pedido de ligação. Muito obrigado,

aconselho a reler as várias mensagens anteriores com maior atenção. existem 3 utilizadores envolvidos neste fluxo

A UC11 (Efetuar pedido de introdução a utilizador objetivo) trata-se de X pedir introdução a Y e deve ser o sistema a indicar quem será esse Y? Não entendi essa questão, porque X pretende ser introduzido a Y, mas vai ser o sistema a designar a quem ele vai ser atribuído? Não deveria ser o sistema a designar apenas o intermediário (que trata da introdução) e quanto ao utilizador Y, esse o utilizador X selecionava de uma lista de utilizadores? Ainda me encontro um pouco confuso relativamente aos passos que se pretendem que sejam seguidos nesta UC.

no pedido de introdução participam 3 utilizadores:
X utilizador autenticado
Z utilizador objectivo
Y utilizador intermediário que conhece X e Z
X pede a Y que o apresente a Z. no caso de estarem numa missão o sistema designa Z e o utilizador escolhe
qual o Y que vai "usar" para pedir a introdução

E no caso de não ser em missão, que é o caso deste Sprint? Em vez de ser o sistema a designar Z, pretende-se que seja o utilizador a escolher também de uma lista de utilizadores o Z?

sim. neste sprint é necessário o serviço de backend que permite "A" efetuar um pedido de introdução a "B" para que lhe apresente "C",
sendo que A tem uma ligação com B e B tem uma ligação com C.
num dos próximos sprints será necessário efetuar a UI para este caso de uso

Existe algum limite de caracteres para o texto inserido aquando dos pedidos de introdução (para o intermediário e para o utilizador ao qual quero ser introduzido) e ligação (para o utilizador ao qual quero efetuar uma ligação)?

10000 caracteres com possibilidade de formatação de texto

->MENU

Modo de Missão

• Para pedir introdução a um utilizador objetivo é necessário, em modo de missão, o sistema pedir o nível de dificuldade da missão.
• Após a indicação, o sistema deve carregar a lista de utilizadores objetivos que se encontram a n graus de distância.
• O utilizador indica qual e o sistema retorna o utilizador que servirá de intermediário.
• O utilizador deve colocar também uma mensagem textual indicativa da introdução em si.

Modo de Rede Social

• Para pedir introdução a um utilizador objetivo é necessário carregar a lista de utilizadores.

• Para efeitos de simplicidade, o sistema primeiro pede para pesquisar por um certo utilizador (UC10)

• O utilizador seleciona um utilizador do qual pretende se conectar.

• Com base na rede do utilizador, caso seja possível, o sistema deve mostrar quais os utilizadores intermediários (utilizador em comum com as duas partes) aos quais o utilizador pode pedir para que o introduzam ao seu utilizador objetivo selecionado.

• Após a seleção, o utilizador deve colocar também uma mensagem textual indicativa da introdução em si.

• O nível de dificuldade da missão deve ser maior que um, e caso não exista determinado grau de dificuldade é sugerido o mais distante possível

• A mensagem de introdução tem no máximo 10000 caracteres com possibilidade de formatação de texto.

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

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

Normalmente as regras 1 e 2, neste caso de uso, o creator foi usado por Relacionamento para instanciar uma IntroducaoPorIntermediario.

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:

UtilizadorDTO salva os dados inseridos num objeto intermediário para posteriormente mostrar ao utilizador o seu utilizador intermediário de introdução;

RedeSocialRepository é usado para armazenar a Rede Social.

PedirIntroducaoController 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 RedeSocialRepository e IntroducaoRepository, onde é armazenado. Abstrai os detalhes dos métodos que modificam o estado deste objeto.

Teste 1: Garantir que a mensagem de descrição da Introdução não tem mais que 1000 caracteres

Teste 2: Garantir que a mensagem de descrição da Introdução não é vazia ou nula

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