Diagrama de Classes - Software-Design-2017/SSMais GitHub Wiki

Histórico de Revisão

Data	Versão	Descrição	Autor(es)
23/10/2017	1.0	Versão inicial do diagrama de classes	Ronyell Henrique
23/10/2017	2.0	Versão proposta do diagrama de classes	Allan Nobre
23/10/2017	3.0	Padrões de Projeto	Ronyell Henrique
27/10/2017	4.0	Segunda versão do Diagrama de Classes	João Paulo e Ronyell Henrique

O padrão de projeto Decorator é um padrão que visa a personalização ou a adição de funcionalidades em tempo de execução, dessa maneira, ele permite adicionar comportamentos a diferentes objetos em tempo de execução. O decorator será utilizado para busca de serviços que serão feitas pelo cliente.

Onde foi encontrado:

O Decorator foi encontrado no framework como ponto de extensão necessário, onde o caso base é acoplado da melhor forma para o cliente. Por exemplo, a pesquisa base poderia ser o nome do produto, os decorators são anexados ao SearchDecorator para anexar funcionalidades em tempo de execução, como anexação de uma pesquisa baseada no tamanho. No framework esse padrão representa pontos de extensão (hotspot) para a adição de pesquisas personalizadas.

O Strategy é um padrão de projeto utilizado para intercambiar algoritmos, independentemente dos clientes que os utilizam. A utilização do Strategy se deu a partir da necessidade de estratégias diferentes para execução de uma determinada tarefa, que são baseadas em elementos distintos, mas que no geral fazem o mesmo trabalho, claro que com resultados, geralmente, diferentes.

Frameworks caixa-preta são baseados em componentes de software. A extensão da arquitetura é feita a partir de interfaces definidas para componentes. Os recursos existentes são reutilizados e estendidos por meio de: definição de um componente adequado a uma interface específica e integração de componentes em um framework que utiliza padrões de projeto como o Strategy (Gamma 94).

Onde foi encontrado:

O Strategy foi identificado na parte core do projeto (frozen spot), onde as implementações das estratégias de escalonamento dos serviços providos por um determinado fornecedor podem ser feitas de forma geral, não especificando o tempo alocado por um determinado recurso, ou de forma específica, utilizando um determinado recurso e escalonando a reserva em um tempo específico.

Assim como no projeto I existiu a necessidade da utilização do composite no projeto de framework também observou-se a necessidade. Como o framework Django tem sua implementação de models, mapeando-as para tabelas relacionais no banco de dados, não foi possível utilizar o purismo do composite. Além disso, existem alguns métodos padrões já implementados pelas models no Django, como o save, o updade e o delete, é possível sobrescrevê-las, e em alguns casos isso foi necessário, mas no composite não se fez necessário.

Onde foi encontrado:

A implementação está relacionada as models de Serviços. Observou-se a necessidade de um hierarquia de serviços onde um desses detém uma coleção de outros serviços. Dessa forma foram criadas as models Service e o serviço Combo, onde este contém uma coleção dos outros serviços e, também, é extensão de Service . Portanto, a partir desse contexto foi usado o composite. No framework esse padrão representa pontos de extensão(hotspot) para a adição de serviços específicos.

UniCamp. Framework Baseado em Componentes. Disponível em:< http://www.dca.fee.unicamp.br/projects/sapiens/Reports/ExplorAnot2/componentFramework.htm > Acesso em: 29 de Outubro de 2017