FACULDADE ESTCIO DE BOA VISTA-RR

ATIVIDADE ESTRUTURADA
ESTUDO DE CASO APLICAO DE PADRES
MAYCOL ALEXANDER SILVA




Boa Vista-RR Maro de 2014
MAYCOL ALEXANDER SILVA
ATIVIDADE ESTRUTURADA
ESTUDO DE CASO APLICAO DE PADRES
Atividade Estruturada apresentada ao Prof.
Carlos Bruno Oliveira Lopes, com vistas
avaliao na disciplina de Padres de Projeto
de Software 5 Semestre, Perodo Noturno,
do Curso de Sistemas de Informao da
Faculdade Estcio de Boa Vista-RR.
Boa Vista-RR Maro de 2014

SUMRIO

Introduo _______________________________________________________________ 3
Captulo 1 MODELO PROPOSTO ____________________________________________ 4
1 ESTUDO DE CASO DE USO __________________________________________ 4
2 - MODELO PROPOSTO ________________________________________________ 5
Inteno _____________________________________________________________ 5
Motivao ___________________________________________________________ 5
Aplicabilidade ________________________________________________________ 5
Participantes _________________________________________________________ 6
ANEXO I ____________________________________________________________ 7
INTRODUO

Este trabalho tem como objetivo definir um padro de desenvolvimento de software
que se aplique ao estudo de caso proposto na atividade estruturada. Em anlise de todos os
modelos de criao, bem como dos modelos estruturais, fica fcil observar que os padres
podem ajudar na criao do projeto, mas no podem prever todas as possibilidades.
A livraria em questo tem um ambiente simples de se visualizar para a montagem de
um diagrama de classes, mas quando se trata de fazer algo sob algum dos padres a
abstrao se torna interessante, pois somos chamados a raciocinar um pouco mais e tratar o
assunto com outros critrios.
Espero que a proposta que segue esteja dentro das expectativas para um bom projeto,
visto que ainda encontrei dificuldades em adaptar minha forma de pensar a um padro de
projeto.

CAPTULO 1
MODELO PROPOSTO

1 ESTUDO DE CASO DE USO
O diagrama abaixo foi objeto de estudo:


A partir deste diagrama, identificou-se a necessidade da separao de dois atores para
atuao no sistema:
Ator externo o usurio do sistema que interage com o cliente (internet).
Ator interno o usurio do sistema que interage internamente.


5
Tendo em vista que estes atores operam aes independentes, sentiu-se a necessidade
da criao de classes que tambm tenham este comportamento.
O ator que no diagrama que figura como Equipe Atendente foi totalmente substitudo
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.
2 - MODELO PROPOSTO
O diagrama proposto se encontra no Anexo I.
O padro de projeto proposto, utilizado para a criao do projeto foi o Abstract
Factory.
Inteno
Este padro vai Fornecer uma interface para criao de famlias de objetos
relacionados ou independentes, sem especificar suas classes concretas. As famlias
identificadas foram Atendimento e Compras.
Motivao
Construo de interfaces de usurios que suporte mltiplos estilos de interao.
Atendimento uma interface que trabalha com a criao de pedidos, enquanto Compras
trabalha em sua maior parte com a criao de encomendas e seu gerenciamento. Estas
classes trabalham de forma independente e operam com estilos diferentes, mas que tem um
padrao que pode ser considerado como uma famlia de produtos em cada classe.
Existe uma subclasse concreta para cada uma delas que implementa as operaes para
criao de pedidos ou encomendas.
Aplicabilidade
O sistema se tornou independente de como seus produtos (Pedidos, Encomendas) so
criados, compostos ou representados.
O sistema pode ser configurado como um produto de uma famlia de mltiplos
produtos.


6
A famlia de objetos-produto foi projetada para ser usada em conjunto, garantindo
restrio quanto a modificao fora do contexto.
Pode ser fornecida uma biblioteca de classes de produtos mas foi revelada apenas suas
interfaces, no suas implementaes.
Especificamente no caso estudado, houve a necessidade de se fazer uma conexo entre
as classes ComprasFactory e PedidosFactory por agregao, permitindo que
ComprasFactory implemente o mtodo EnviaPedido ( ) em PedidosFactory. Isso torna
possvel que Compras faa a entrega do pedido ao cliente, conforme o Diagrama de Caso de
Uso.
Participantes
AbstractFactory (AtendimentoFactory e ComprasFactory)
o Interfaces para criao dos objetos-produtos abstratos.
ConcreteFactory (PedidoFactory e EncomendaFactory)
o Implementa as operaes que criam objetos-produtos concretos.
AbstractProduct (Pedido e Encomenda)
o Declara uma interface para um tipo de objeto-produto.
ConcreteProduct (PedidoCria, PedidoEnvia, EncomendaCria,
EncomendaEnvia,EncomendaRecebe.
o Define um objeto-produto a ser criado pela correspondente fbrica
concreta.
o Implementa a interface de Pedido ou Encomenda.
Cliente e Usuario
o Usa somente interfaces declaradas pelas classes AbstractFactory e
AbstractProduct



7
ANEXO I


Pedido
PedidoCria PedidoEnvia

CriaEncomenda ( )
CriaEncomenda ( )
EnviaEncomenda ( )
RecebeEncomenda ( )
EncomendaFactory
Encomenda
EncomendaCria EncomendaEnvia EncomendaRecebe
Usuario
CriaEncomenda ( )
CriaEncomenda ( )
EnviaEncomenda ( )
RecebeEncomenda ( )
EnviaPedido ( )
ComprasFactory
Cliente
CriaPedido ( )
CriaCadastro ( )
ValidaPedido ( )
AtendimentoFactory
CriaPedido ( )
CriaCadastro ( )
ValidaPedido ( )
EnviaPedido ( )

PedidoFactory