Histórico de edição

Autor	Data
Fabíola Fleury	26/04
Fabíola Fleury	28/04
Pablo Diego	30/04
Pablo Diego	03/05
Josué Nascimento	13/05

Introdução

Os padrões do grupo representados pela sigla GRASP (General Responsability Assignment Software Patterns) são utilizados para auxiliar na decisão de qual responsabilidade deve ser atribuída para qual classe ou objeto. Além de identificarem objetos e responsabilidades no domínio do problema, também identificam como os objetos interagem entre si. Dado que o projeto desenvolvido neste repositório está dentro do contexto da disciplina Desenho e Arquitetura de Software, vê-se como necessário explicitar quais padrões encontram-se implementados e como.

Visão Geral

Criador

A noção de que quem contém cria o que está contido é mantida na aplicação. Os repositories são responsáveis por instanciar objetos por meio da conversão dos objetos json enviados do frontend para o backend do projeto, adiando também a criação o máximo o possível. Logo, as classes modelo para usuários, banda, música, são criados apenas nas suas respectivas classes repositório.

Especialista na Informação

A responsabilidade do conhecimento de informações são contidas em especialistas. Um exemplo é, a setlist de uma banda é armazenada pela banda, mesmo que os músicos que fazem parte dela também tenham acesso, ela fica responsável por manipula-lá.

Baixo Acoplamento

Priorizou-se baixo acoplamento, cada classe é responsável por uma tarefa específica, não sobrecarregando com várias funcionalidades, o que facilita o entendimento do código e seu reuso. Cada classe de domínio está bem delimitada, e seguir o padrão arquitetural do Spring REST facilita o baixo acoplamento que é favorecido através da forma como este injeta as dependências que são instancias únicas entre as classes e repositórios.

Alta coesão

Em definições de seguimento de padrões de projeto GoF e hierarquias dentro das classes de domínio houve-se o cuidado para que a complexidade fosse controlada em código. As classes definidas no projeto realizam apenas pequenas tarefas específicas de acordo com o seu funcionamento dentro do Spring, como controllers, repositórios, modelos,classes de configuração da aplicação, handlers e controllers.

Controladora

O Sistema está separado em backend e frontend como pode ser observado no documento de arquitetura, além disso segue o REST, os eventos que ocorrem no sistema são controlados via camadas específicas, sendo estas principalmente: as Handlers, Controllers e Repositórios.

• Handlers são responsáveis por executar eventos pré e pós alguma requisição de criação, leitura, remoção ou atualização (CRUD) de uma modelo vinda do frontend. Permitindo por exemplo, que se crie notificações aos usuários após salvar uma nova banda.

• Controllers são responsáveis por mapear URLs a métodos específicos para realizar tarefas que não sejam as básicas de CRUD, pois estas já são fornecidas para o frontend através dos Repositórios.

• Repositórios são os responsáveis por oferecer URLs com ações de CRUD ao frontend, sendo o acesso da aplicação para as classes modelo.

Fabricação Pura

A forma como o Framework Spring trabalha trás uma separação interna clara da camada de Controladoras para aumentar a coesão e diminuir a complexidade da interface frontend-backend. A divisão das tarefas CRUD para os repositório, métodos específicos nas controllers e gestão de eventos nos handlers é uma fabricação pura, onde normalmente em outros frameworks temos grandes fachadas que controlam todo o fluxo entre visualização do usuário e os dados no banco.

Polimorfismo

Na aplicação temos dois grandes usos de Polimorfismo, utilizando as generalizações de User como um Observador de banda, e de música e medley como componentes de músicais. A chamada genérica ao invés de ramificações específicas permite a construção de novas hierarquias e classes para observadores e tipos de música sem grandes impactos no software.

Variações Protegidas

Com a arquitetura de micro serviços implementada no projeto torna-se viável a separação de front-end , back-end e a camada de persistência, onde permite que exista um maior encapsulamento entre esse elementos, evitando que impactamos ou mudanças em um desses elementos impacte de forma pequena ou quase não existentes nos demais módulos.