Padrões de Projeto - ATIVIDADE ESTRUTURADA

Prévia do material em texto

FACULDADE ESTÁCIO BH-MG
ATIVIDADE ESTRUTURADA
2017.2 - PADRÕES DE PROJETO DE SOFTWARE (CCT0425/2614966) 9001
ESTUDO DE CASO – APLICAÇÃO DE PADRÕES
ALUNO: PABLO CHRISTIAN PEREIRA NAZARETH
201601617887
PROFESSOR: CARLOS ALBERTO DE FARIAS
BH-MG — Outubro de 2017
�
SUMÁRIO
INTRODUÇÃO _______________________________________________________ 3 
 
DESCRIÇÃO DO CENÁRIO_____________________________________________ 3
 DESCRIÇÃO DO ESTUDO DE CASO_____________________________________ 4
5.1 DIAGRAMA DE CASO DE USO_______________________________________ 4
5.2 DIAGRAMA DE CLASSES____________________________________________5
 PADRÕES DE PROJETO ______________________________________________ 5 
CONCLUSÂO_________________________________________________________7
BIBLIOGRAFIA__________________________________________________________7�
INTRODUÇÃO
Este trabalho tem como objetivo definir um padrão de desenvolvimento de software que se aplique ao estudo de caso proposto na atividade estruturada. Em análise de todos os modelos de criação, bem como dos modelos estruturais, irá ser fácil de observar que os padrões podem ajudar na criação do projeto, mas não podem prever todas as possibilidades.
DESCRIÇÃO DO CENÁRIO
Será abordado o conceito de uma empresa de Livraria. 
A livraria em questão tem um ambiente simples de se visualizar para a montagem de um diagrama de classes, e interessante de se utilizar os padrões de projeto.
�
DESCRIÇÃO DO ESTUDO DE CASO
5.1 – DIAGRAMA DE CASO DE USO
A partir deste diagrama, identificou-se a necessidade da separação de dois atores para atuação no sistema:
Ator externo – o usuário do sistema que interage com o cliente (internet). 
Ator interno – o usuário do sistema que interage internamente.
Tendo em vista que estes atores operam ações independentes, sentiu -se a necessidade da criação de classes que também tenham este comportamento.
O ator que no diagrama que figura como Equipe Atendente foi totalmente substituído pela Interface Atendimento, uma classe abstrata que é acionada pela internet, ou seja, pelo cliente que efetua o pedido.
Já o ator que figura como Depto. de Compras deve acionar o sistema via classe Compras para poder manter o sistema e processar os pedidos na sexta -feira.
– DIAGRAMA DE CLASSE
PADRÕES DE PROJETO
O padrão de projeto proposto, utilizado para a criação do projeto foi o Abstract Factory
Intenção:
Este padrão irá fornecer uma interface para criação de famílias de objetos relacionados ou independentes, sem especificar suas classes concretas.‖ As famílias identificadas foram Atendimento e Compras.
Motivação:
Construção de interfaces de usuários que suporte múltiplos estilos de interação‖. Atendimento é uma interface que trabalha com a criação de pedidos, enquanto Compras trabalha em sua maior parte com a criação de encomendas e seu gerenciamento. Estas classes trabalham de forma independente e operam com estilos diferentes, mas que tem um padrão que pode ser considerado como uma família de produtos em cada classe.
Existe uma subclasse concreta para cada uma delas que implementa as operações para criação de pedidos ou encomendas.
Aplicabilidade:
O sistema se tornou independente de como seus produtos (Pedidos, Encomendas) são criados, compostos ou representados.
O sistema pode ser configurado como um produto de uma família de múltiplos produtos.
A família de objetos-produto foi projetada para ser usada em conjunto, garantindo restrição quanto a modificação fora do contexto.
Pode ser fornecida uma biblioteca de classes de produtos mas foi revelada apenas suas interfaces, não suas implementações.
Especificamente no caso estudado, houve a necessidade de se fazer uma conexão entre as classes ComprasFactory e PedidosFactory por agregação, permitindo que ComprasFactory implemente o método EnviaPedido ( ) em PedidosFactory. Isso torna possível que Compras faça a entrega do pedido ao cliente, conforme o Diagrama de Caso de Uso.
Participantes:
AbstractFactory (AtendimentoFactory e ComprasFactory) 
Interfaces para criação dos objetos-produtos abstratos.
ConcreteFactory (PedidoFactory e EncomendaFactory)
Implementa as operações que criam objetos-produtos concretos.
AbstractProduct (Pedido e Encomenda)
Declara uma interface para um tipo de objeto-produto. 
ConcreteProduct (PedidoCria, PedidoEnvia, EncomendaCria,
EncomendaEnvia,EncomendaRecebe.
Define um objeto-produto a ser criado pela correspondente fábrica concreta.
Implementa a interface de Pedido ou Encomenda.
Cliente e Usuário
Usa somente interfaces declaradas pelas classes AbstractFactory e AbstractProduct
�
CONCLUSÃO
Através da análise desse material, podemos concluir que os padrões de projetos são utilizados como uma solução geral para um problema que ocorre com frequência dentro de um determinado contexto no projeto de software. 
Um padrão de projeto não é um projeto finalizado que pode ser diretamente transformado em código fonte ou de máquina, ele é uma descrição ou modelo (template) de como resolver um problema que pode ser usado em muitas situações diferentes. 
Esses Padrões são melhores práticas formalizadas que o programador pode usar para resolver problemas comuns quando projetar uma aplicação ou sistema. 
BIBLIOGRAFIA
https://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software
https://www.treinaweb.com.br/blog/padroes-de-projeto-o-que-sao-e-o-que-resolvem/
http://www.nusseagora.blog.br/padroes-de-projeto-o-que-sao-e-pra-que-servem