UC_18 - antoniodanielbf-isep/LAPR5-2021 GitHub Wiki
=======================================
|| REQUISITOS || ANÁLISE || DESIGN || OBSERVAÇÕES ||
=======================================
Até ao momento não são necessárias alterações no modelo de domínio.
Testes a nível da rede social.
- A rede social é um grafo, que contém como nó central o utilizador com sessão iniciada.
- Os restantes nós da rede social serão os restantes utilizadores que sejam amigos diretos ou indiretos do utilizador.
- As ligações entre nós serão ambivalentes, isto é, de A para B e de B para A, com valores de ligação entre 1 e 100.
- Um caminho na rede social será um trajeto desde o utilizador inicial até ao utilizador pretendido, podendo passar por intermediários.
- O caminho mais curto é aquele que minimiza o número de ligações para o utilizador destino.
O padrão UserInterface é utilizado para fornecer ao utilizador uma interface simples de usar, neste caso de uso (RedeSocialPerspetivaUserUI).
O padrão Controller foi usado para ter um controlador (neste caso de uso RedeSocialPerspetivaUserController), 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 CaminhoMaisCurto.
Normalmente as regras 1 e 2, neste caso de uso, o creator foi usado por CaminhoMaisCurto para construir um CaminhoMaisCurto.
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:
CaminhoMaisCurto é usado para instanciar um CaminhoMaisCurto;
RedeSocialPerspetivaUserController trata de toda a lógica de atualização de um evento delegando etapas intermediárias às outras classes.
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.