UC_08 - antoniodanielbf-isep/LAPR5-2021 GitHub Wiki
=======================================
|| REQUISITOS || ANÁLISE || DESIGN || OBSERVAÇÕES ||
=======================================
Bom dia, prezado, cliente, Gostaria de entender o formato de número de telefone do jogador que deseja. Cumprimentos, João Pereira
código do país seguido de um conjunto de digitos de comprimento minimo 4 e máximo 11.
não é necessário fazer validação do formato de cada país
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 Jogador 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 Jogador *.
* 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
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
Bom dia, prezado, cliente, Poder-me-ia providenciar alguns exemplos de tags de jogador que gostaria de ver? Cumprimentos, João Pereira
o Jogador irá introduzir as tags que entender adequadas. alguns exemplos podem ser:
isep
IsepRocks
java
nodejs
IA
AI
jogosdetabuleiro
tbt
yolo
foodlover
drinkbuddy
Boa tarde, No registo de um utilizador no sistema quais os dados que este pode introduzir? E destes quais é que são obrigatórios e opcionais? Cumprimentos.
além do que já foi respondido em https://moodle.isep.ipp.pt/mod/forum/discuss.php?d=10807
email - obrigatório
tags de interesse - obrigatório
cidade e país de residência - opcional
breve descrição - opcional
imagem/avatar - opcional
De forma a registar o Jogador este possui um perfil com o seu nome, data de nascimento, número de telefone, email, perfil Linkedin, perfil facebook e o estado emocional. Quando um Jogador se regista no sistema este deve apresentar sugestões de ligações iniciais com base nas tags em comum, o sistema faz a introdução entre os dois.
De forma a registar o Jogador este possui um perfil com o seu nome, data de nascimento, número de telefone, email, perfil Linkedin, perfil facebook e o estado emocional, possivelmente isto acontecerá de forma incremental e/ ou de forma completa então deve-se adotar um builder. Quando um Jogador se regista no sistema este deve apresentar sugestões de ligações iniciais com base nas tags em comum, o sistema faz a introdução entre os dois, sendo esta funcionalidade implementada à parte.
Foi adicionado a CidadeEPaisResidencia, BreveDescricao, ImagemAvatar ao agregado Utilizador. Criado o agregado Jogador, que terá associado uma Pontuação.
Testes de validação do email, telefone, data de nascimento, nome, descrição breve, tag, cidade e país de residência. Testes de validação da pontuação.
-
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
-
quando o Jogador edita o seu perfil pode introduzir o URL do seu perfil FB ou LKN. estes dados são opcionais.
-
email - obrigatório
-
tags de interesse - obrigatório
-
cidade e país de residência - opcional
-
breve descrição - opcional
-
imagem/avatar - opcional
O padrão de User Interface é usado para fornecer uma interface simples de usar para o Novo Utilizador (neste caso de usar RegistarJogadorUI) para que as partes restantes do sistema sejam separadas.
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 Jogador.
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;
Jogador é usado para instanciar um Jogador;
UserRepository é usado para armazenar Utilizador criado.
RegistarUtilizadorController 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.
Mantém o baixo nível de acoplamento entre os diferentes módulos do sistema. Com este princípio, ao invés de se terem dependências programas nos módulos, elas são configuradas num "container", que é responsável por "injetar" (fornecer) as dependências necessárias a cada componente.
É uma forma específica de desacoplamento de módulos de software. Partem de módulos de alto nível, responsáveis pela coordenação geral e lógica, para os de baixo nível. Assim, os módulos de alto nível tornam-se independentes dos detalhes de implementação dos de baixo nível. Módulos de alto nível não devem incorporar (ou incluir) nada dos módulos de baixo nível. Os dois módulos devem trabalhar apenas com abstrações, ou seja, através do uso de interfaces. Abstrações não devem depender de detalhes de implementação, mas os detalhes é que devem depender de abstrações.
[Test]
public void rejeitarBreveDescricaoNulaOuVazia()
{
Exception exception = null;
try
{
var breveDescricao = new BreveDescricao("");
}
catch (Exception ex)
{
exception = ex;
}
Assert.IsNotNull(exception);
}
[Test]
public void aceitarBreveDescricaoValida()
{
var breveDescricao = new BreveDescricao("Descricao");
Assert.IsNotNull(breveDescricao);
}
[Test]
public void testarRecusaCidadeEPaisResidenciaNuloOuVazio()
{
Exception exception = null;
try
{
var cidadeEPaisResidencia = new CidadeEPaisResidencia(" ");
}
catch (Exception ex)
{
exception = ex;
}
Assert.IsNotNull(exception);
}
[Test]
public void aceitarCidadeEPaisResidenciaValido()
{
var cidadeEPaisResidencia = new CidadeEPaisResidencia("Porto, Portugal");
Assert.IsNotNull(cidadeEPaisResidencia);
}
[Test]
public void aceitarDataValida()
{
Exception aux = null;
DataDeNascimento d = null;
try
{
d = new DataDeNascimento("26/12/2001");
}
catch (Exception ex)
{
aux = ex;
}
Assert.IsNull(aux);
Assert.IsNotNull(d);
}
[Test]
public void recusarDataComFormatoInvalido1()
{
Exception aux = null;
DataDeNascimento d = null;
try
{
d = new DataDeNascimento("");
}
catch (Exception ex)
{
aux = ex;
}
Assert.IsNotNull(aux);
Assert.IsNull(d);
}
[Test]
public void aceitarDataComFormatoSimplificado()
{
Exception aux = null;
DataDeNascimento d = null;
try
{
d = new DataDeNascimento("4/4/2004");
}
catch (Exception ex)
{
aux = ex;
}
Assert.IsNull(aux);
Assert.IsNotNull(d);
}
[Test]
public void recusarDataMenor16()
{
Exception aux = null;
DataDeNascimento d = null;
try
{
d = new DataDeNascimento("14/11/2021");
}
catch (Exception ex)
{
aux = ex;
}
Assert.IsNotNull(aux);
Assert.IsNull(d);
}
[Test]
public void testarRecusaDeEmailInvalido()
{
Exception exception = null;
try
{
var email = new EmailUtilizador("antonio@[email protected]");
}
catch (Exception ex)
{
exception = ex;
}
Assert.IsNotNull(exception);
}
[Test]
public void aceitarMailValido()
{
var email = new EmailUtilizador("[email protected]");
Assert.IsNotNull(email);
Assert.IsTrue(email.GetType() == typeof(EmailUtilizador));
}
[Test]
public void testarRecusaDeNomeIniciadoPorEspaco()
{ Exception exception = null;
try
{
var nome = new Nome(" rosa");
} catch (Exception ex)
{
exception = ex;
}
Assert.IsNotNull(exception);
}
[Test]
public void testarRecusaDeNomeNuloOuVazio()
{
Exception exception = null;
try
{
var nome = new Nome(" ");
}
catch (Exception ex)
{
exception = ex;
}
Assert.IsNotNull(exception);
}
[Test]
public void testaraceitarNomeValido()
{
var nome = new Nome("Rosa");
Assert.IsNotNull(nome);
}
[Test]
public void rejeitarTagNulaOuVazia()
{
Exception exception = null;
try
{
var tag = new Tag(" ");
}
catch (Exception ex)
{
exception = ex;
}
Assert.IsNotNull(exception);
}
[Test]
public void aceitarTagValida()
{
var tag = new Tag("ISEP");
Assert.IsNotNull(tag);
}
O UC está praticamente implementado ficando apenas pendente uma correção de queries.
Demonstração via POSTMAN: