|| INICIO || VOLTAR ||

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

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

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

Bom dia, prezado, cliente, Poder-me-ia esclarecer se pretende que os perfis, quer do LinkedIn, quer do Facebook do jogador, serão disponíveis através do link de cada um? Cumprimentos, João Pereira

Quando o utilizador edita o seu perfil pode introduzir o URL do seu perfil FB ou LKN. estes dados são opcionais.
numa primeira iteração apenas é necessário guardar o URL
numa iteração posterior deverá haver uma verdadeira ligação com a platforma FB e LKN associando a conta de utilizador *.
* nota: sugere-se que sigam uma abordagem iterativa e que apenas façam o necessário para o âmbito definido em cada iteração sem cairem no erro de fazer "over engineering" para suportar requisitos que ainda não forma confirmados em que sprint serão necessários e se serão necessários - como sabem um dos príncipios ageis é "embrace change"; é perfeitamente natural as prioridades do cliente mudarem ao longo dos sprints de execução do projeto

Boa tarde, Sempre que se refere ao perfil do utilizador, é sempre em referência ao perfil público do utilizador, e não a uma conta de utilizador, correto? Ou seja, todos os dados que pertencem ao perfil serão públicos? Assumindo que os posts serão publicados no perfil, é possível publicar um post num perfil de alguém da nossa rede? Ou só podemos comentar e reagir com like/dislike? O “estado emocional” refletido no perfil é equivalente ao “estado de humor” referido na pag5. do caderno de encargos (modulo de visualização), ou serão categorias diferentes? Com os melhores cumprimentos, Grupo 80

1. sim, perfil público. corresponderá ao nome, tags e feed de posts desse utilizador
2. apenas o utilizador faz posts no seu feed. outros utilizaodres poderão comentar esses posts e/ou reagir com like/dislike
3. voltaremos a este tópico após a palestra deste sábado sobre o modelo OCC

Boa tarde, No seguinte post do forum o cliente referiu que o nome do utilizador deve ser alfanumérico: https://moodle.isep.ipp.pt/mod/forum/discuss.php?d=10807. Isto refere-se ao nome próprio do utilizador ou apenas ao seu username/email? Obrigado, Tiago Loureiro

Ao nome do utilizador.
O email deve seguir as regras de sintaxe normal de um endereço de email.

Bom dia, prezado, cliente, Gostaria de saber algumas regras de negócio relativamente ao nome do jogador e à data de nascimento. Cumprimentos, João Pereira

Nome - alfanumérico, opcional, não pode conter espaços no ínicio
Data de nascimento - data, opcional, idade minima para usar o sistema: 16 anos

Boa tarde professor, Como é que a data de nascimento é opcional se existe uma idade mínima para usar o sistema? Obrigado, Tiago Loureiro

Tem razão. tratou-se de um lapso. a data de nascimento é obrigatória.
Tenham em atenção os aspetos de privacidade e dados sensiveis.

Boa tarde professor, No caso de uso de editar perfil próprio, quais são os atributos que se podem considerar mutáveis? Considera-se os atributos do perfil próprio os mesmo que o "perfil público"? Obrigado. Cumprimentos, Guilherme Daniel

Exceptuando o email que será considerado como username, todos os dados são passiveis de alteração

Bom dia Professor, Por exemplo Ana_gt e Nick_98, indicados no grafo do enunciado são nomes e não usernames ? Mt Obrigado, Grupo 15 - 3DA

Na imagem, por questão de espaço, estão representados a parte inicial do endereço de email

->MENU

De maneira a atualizar o perfil do utilizador, este pode alterar atributos como: tags, avatar/imagem, breve descrição, cidade e pais de residência, links do perfil do Facebook/LinkedIn e número de telemóvel. Quando o utilizador pretende alterar o seu perfil, é-lhe apresentado o seu perfil com todos os atributos e é-lhe dada a liberdade de alterar todos os atributos que este desejar (dos referidos anteriormente), simultâneamente.

Foi adicionado a CidadeEPaisResidencia, BreveDescricao, ImagemAvatar ao agregado Jogador.

Testes de validação tags, telefone, cidade e pais de residência, descrição, imagem.

• Quando o Jogador edita o seu perfil pode introduzir o URL do seu perfil FB ou LKN. Estes dados são opcionais e podem ser alterados.

• nome (alfanumérico) - pode ser alterado

• email (alfanumérico) - não pode ser alterado

• data de nascimento (data) - não pode ser alterado

• tags de interesse (alfanumérico) - pode ser alterado

• cidade e país de residência (alfanumérico) - pode ser alterado

• breve descrição (alfanumérico) - pode ser alterado

• imagem/avatar (icone) - pode ser alterado

• telefone (numérico) - pode ser alterado

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

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

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

UserRepository é usado para armazenar o perfil do utilizador

RegistarUtilizadorController 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 UserRepository, 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: 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