UC_14 - antoniodanielbf-isep/LAPR5-2021 GitHub Wiki

|| INICIO || VOLTAR ||

UC_14 -> Comentar Post

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

MENU

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

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

1. Requisitos

Esclarecimento de dúvidas pelo cliente

Wednesday, 27 de October de 2021 às 23:00

Gostaria de saber quais são as regras de negócio relativas ao Post e aos comentários realizados ao mesmo.

RESPOSTA:
-----

ambos são textos livres que devem suportar formatação do seu conteudo

ACEDER


Thursday, 28 de October de 2021 às 09:51

Será possível, para um utilizador, mudar o seu comentário num post?

RESPOSTA:
-----

de momento não faz parte do âmbito. poderá vir a fazer em sprints futuros

Nota: evitem overengineering de requisitos que o cliente não confirmou serem parte do âmbito

ACEDER


Monday, 6 de December de 2021 às 15:06

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)

ACEDER


Friday, 10 de December de 2021 às 23:45

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

ACEDER


Friday, 10 de December de 2021 às 00:15

Boa noite,

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

ACEDER


Friday, 10 de December de 2021 às 22:54

Não sendo amigo de um utilizador, podemos visualizar e comentar os seus posts?

RESPOSTA:
-----
Sim. Is post são públicos

ACEDER


Monday, 13 de December de 2021 às 09:58

Desta forma, um utilizador pode reagir a um post de um outro com o qual não tem conexão? Se sim, se a conexão entre estes dois chegar a existir, a força de relação deve ter em conta os likes e dislikes existentes ou esta é iniciada a 0?

RESPOSTA:
-----

a força de relação tem sempre em conta os like e dislikes. a tua questão parece-me indicar mais para a maneira como decidiram implementar essa funcionalidade do que para o requisito em si quando referes "iniciada a 0". se sempre que for pedida a força de relação efetuarem o calculo na hora essa questão não se coloca. se por outro lado decidiram ter um "acumulador" que é atualizado quando alguem faz um like ou dislike terão que ter em conta os likes/dislikes já existentes entre esses utilizadores.

ACEDER


Tuesday, 14 de December de 2021 às 11:07

O conteúdo de cada post deve ter algum valor mínimo e máximo de caracteres? Visto que os posts são públicos, podemos reagir/comentar um post que foi criado por alguém que não é nosso amigo (com quem não temos uma ligação)? Se sim, como é que isso afetaria a força de relação (visto que a ligação não existe)?

RESPOSTA:
-----
Min: 1

max: 10000

a outra parte das questões já foi respondida https://moodle.isep.ipp.pt/mod/forum/discuss.php?d=12668#p16706

ACEDER


->MENU


2. Análise

Neste UC, pretende-se que um utilizador seja capaz de comentar um post, sendo o fluxo o seguinte:

SSD

Alterações ao MD

Foi criado um MD independente para o MDP (Master Data Post):

MD MDP

Testes a Implementar

Testes de validação do texto e tags relativos ao comentario.

Regras de Negócio

  • Texto Comentario => Obrigatório

  • Tags Comentario => Opcional

->MENU


3. Design

NÍVEL 1

SSD

NÍVEL 2

SSD NÍVEL 2

3.1. Realização da Funcionalidade

NÍVEL 3

SD

3.2. Padrões Aplicados

User Interface

O padrão de User Interface é usado para fornecer uma interface simples de usar para o Novo Comentario para que as partes restantes do sistema sejam separadas.

Controller

O padrão Controller foi usado para ter um controlador que pode atuar como um organizador da lógica do caso de uso.

Information Expert

Esse padrão atribui responsabilidades às classes para o domínio de negócios que ele representa, como é o caso do Comentario.

Creator

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

High Cohesion, Low Coupling

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:

Os DTO´S guardam os dados inseridos num objeto intermediário para posteriormente mostrar o Comentário criado;

O Comentario é usado para instanciar um Texto Comentario;

O Repositório é usado para armazenar Comentario criado.

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

DTO

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

Repository

O Repositório ajuda a persistir, armazenar e acessar dados. É usado na camada de Persistência para garantir a instanciação de ComentarioRepository, onde é armazenado e tem acesso aos Comentarios. Abstrai os detalhes dos métodos que modificam o estado deste objeto.

Dependency Injection

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.

Inversion of Dependencies

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

->MENU


4. Observações

->MENU


⚠️ **GitHub.com Fallback** ⚠️