UC_13 - antoniodanielbf-isep/LAPR5-2021 GitHub Wiki
=======================================
|| REQUISITOS || ANÁLISE || DESIGN || OBSERVAÇÕES ||
=======================================
No caderno de encargos, é referido o seguinte: "Adicionalmente, um utilizador pode colocar post e comentar esses posts indicando um like ou dislike. Não se prevê a possibilidade de comentar comentários. Um post consiste num texto e num conjunto de tags." A dúvida é que, pelo português, podemos inferir que ao comentar eu poderei estar ou não a escrever um texto de comentário, e depois colocar ou não um like ou dislike?
RESPOSTA:
-----
podem encarar como duas acções distintas:
reagir: fazer like ou dislike
comentar: escrever texto (obrigatório) e tags (opcional)
As tags dos posts e dos comentários obedecem às mesmas regras de negócio das tags presentes nos jogadores e nas ligações? As tags de um post também devem ser opcionais, como é o caso dos comentários?
RESPOSTA:
-----
Sim en ambos os casos
Quais dados num post é que devem ser obrigatórios? Podemos postar, por exemplo, um post sem título?
Para além disso, deve ser possível postar imagens?
RESPOSTA:
-----
ver https://moodle.isep.ipp.pt/mod/forum/discuss.php?d=12553#p16448
não é necessário suportar imagens nem título, mas caso queiram enriquecer o sistema com esses dois aspetos poderão faze-lo. notem no entanto que devem primeiro fazer o âmbito definido e só depois estes aspetos opcionais
Num post que o utilizador cria, o conjunto de tags que o mesmo refere é obrigatório ou o utilizador pode não referir nenhuma tag, sendo apenas o post composto pelo texto?
RESPOSTA:
-----
as regras para um post são as mesmas de um comentário.
texto (obrigatório) e tags (opcional)
Neste UC, pretende-se que um utilizador seja capaz de efetuar um post, sendo o fluxo o seguinte:
Foi criado um MD independente para o MDP (Master Data Post):
Testes de validação do texto e tags.
-
PostTexto => Obrigatório
-
PostTag => Opcional
O padrão de User Interface é usado para fornecer uma interface simples de usar para o Novo Post para que as partes restantes do sistema sejam separadas.
O padrão Controller foi usado para ter um controlador 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 Post.
Normalmente as regras 1 e 2, neste caso de uso, o creator foi usado pelo Post para instanciar um TextoPost, pois um Post tem um TextoPost associado.
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:
Os DTO´S guardam os dados inseridos num objeto intermediário para posteriormente mostrar o Post criado;
O Post é usado para instanciar um TextoPost;
O Repositório é usado para armazenar Post criado.
O Controller 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 PostDTO.
O Repositório ajuda a persistir, armazenar e acessar dados. É usado na camada de Persistência para garantir a instanciação de PostRepository, onde é armazenado e tem acesso aos Post. 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.