Você está na página 1de 284

PADRES ARQUITETURAIS E DE

PROJETO PARA DESENVOLVIMENTO DE


SOFTWARE ORIENTADO A OBJETOS

Dr. Gilleanes Thorwald Araujo


Guedes
gtaguedes@gmail.com

Bibliografia Bsica

SOMMERVILLE, Ian. Engenharia de Software


9 Edio. Addison Wesley. 2011.

GAMMA, E.; HELM, R.; JOHNSON, R.;


VLISSIDES, J. Padres de projeto: solues
reutilizveis de software orientado a
objetos. Porto Alegre, RS: Bookman, 2000.

LARMAN, Craig. Utilizando UML e Padres


3. Edio. Porto Alegre: Bookman, 2007.

Bibliografia Complementar

GUEDES, G. UML 2 Uma Abordagem Prtica. 2.ed.


So Paulo: Novatec, 2011.
DEITEL, P. J.; DEITEL, H. M. Java: como programar.
8.ed. So Paulo: Pearson, 2010.
BRAUDE, E. Projeto de Software - Da programao
arquitetura: uma abordagem baseada em java. Porto
Alegre: Bookman, 2005.
MEUNIER, R.; SOMMERLAD, P.; BUSCHMANN, F.; STAL,
M.; ROHNERT, H. Pattern-oriented software
architecture: a system of patterns. Hoboken, NJ: John
Wiley & Sons, 1996.
HORSTMANN, C. Padres de Projeto Orientados a
Objetos. 2.ed. Porto Alegre: Bookman, 2007.

Ementa
Conceitos bsicos e prticos sobre os
seguintes padres mais relevantes:
Arquiteturais; Padres de projeto de
criao; Padres de projeto estruturais;
Padres de projeto comportamentais.

Objetivos
Aprender os conceitos bsicos dos padres
arquiteturais e dos padres relacionados ao
desenvolvimento de software orientado a
objetos.

Projeto de Arquitetura

Preocupa-se com a compreenso de


como um sistema deve ser organizado e
com sua estrutura geral.

No processo de desenvolvimento de
software, o projeto de arquitetura o
primeiro estgio do projeto de software.

Projeto de Arquitetura

Ponto de ligao entre a engenharia de


requisitos e o projeto;

Identifica os componentes estruturais de


um sistema e os relacionamentos entre
eles.

Produz um modelo de arquitetura que


descreve como o sistema est organizado
em um conjunto de componentes
(subsistemas) de comunicao.

Arquitetura de um Sistema de Controle


Robotizado de Empacotamento

Fonte: Sommerville (2011)

Projeto de Arquitetura

Em processos geis, aceito que um estgio


inicial do processo de desenvolvimento se
preocupe com o estabelecimento de uma
arquitetura global do sistema.

O desenvolvimento incremental de
arquiteturas geralmente no bem-sucedido.

A refatorao de uma arquitetura


geralmente cara.

Projeto de Arquitetura

Existe uma considervel sobreposio


entre os processos de engenharia de
requisitos e de projeto de arquitetura.

A decomposio de arquitetura
normalmente necessria para estruturar
e organizar a especificao.

Projeto de Arquitetura

Como parte do processo de engenharia


de requisitos, pode-se propor uma
arquitetura abstrata de sistema em que
sejam associados grupos de funes ou
recursos aos componentes ou
subsistemas.

Pode-se ento usar essa decomposio


para discutir com os stakeholders os
requisitos e recursos do sistema.

Projeto de Arquitetura

O projeto de arquitetura de software pode


ser:

Arquitetura em Pequena Escala:

Onde se projeta a arquitetura de


programas individuais, ou seja, como um
software dividido em componentes.

Projeto de Arquitetura

Arquitetura em Grande Escala:

Enfoca a arquitetura de sistemas


corporativos complexos que incluem
outros sistemas, programas e
componentes de programas.

Distribuem-se por diversos servidores e


podem pertencer e ser geridos por
diferentes empresas.

Projeto de Arquitetura

Os componentes individuais
implementam os requisitos funcionais do
sistema.

Os requisitos no funcionais dependem


da arquitetura do sistema - como os
componentes esto organizados e se
comunicam.

A arquitetura de software afeta o


desempenho, a robustez, a capacidade

Projeto de Arquitetura
Vantagens

H trs vantagens em projetar e


documentar a arquitetura de software:

1.

Comunicao com os Stakeholders:

A arquitetura uma apresentao de alto


nvel do sistema e pode ser usada como
um foco de discusso com os
stakeholders.

Projeto de Arquitetura
Vantagens
2.
.

Anlise de sistema:
Tornar explcita a arquitetura do sistema,
em um estgio inicial, exige que o
sistema seja analisado principalmente em
termos de requisitos no funcionais.
As decises de projeto de arquitetura tm
um efeito profundo sobre a possibilidade
do sistema atender ou no aos requisitos
crticos, como desempenho,
confiabilidade e manutenibilidade.

Projeto de Arquitetura
Vantagens
3.

Reuso em Larga Escala:


Um modelo de uma arquitetura de sistema
uma descrio compacta e gerencivel de
como um sistema organizado e como os
componentes interoperam.
A arquitetura do sistema geralmente a
mesma para sistemas com requisitos
semelhantes e pode apoiar o reuso de
software.

Decises de Projeto de
Arquitetura

O projeto de arquitetura define uma forma


de organizao para satisfazer aos
requisitos funcionais e no funcionais de
um sistema.

O projeto de arquitetura depende:


Do

tipo de sistema a ser desenvolvido;


Da formao e experincia do arquiteto;
Dos requisitos especficos para o sistema.

Decises de Projeto de
Arquitetura

Durante o projeto de arquitetura, os arquitetos


precisam tomar uma srie de decises
estruturais que afetam profundamente o sistema
e seu processo de desenvolvimento.

Com base em seus conhecimentos e


experincia, eles precisam considerar as
seguintes questes fundamentais:

1.

Existe uma arquitetura genrica de aplicao que


pode atuar como um modelo para o sistema?

Decises de Projeto de
Arquitetura
2.
3.

4.

5.

6.

Como o sistema ser distribudo?


Que padres ou estilos de arquitetura podem
ser usados?
Qual ser a abordagem fundamental para se
estruturar o sistema?
Como os componentes estruturais do sistema
sero decompostos em subcomponentes?
Que estratgia ser usada para controlar o
funcionamento dos componentes do sistema?

Decises de Projeto de
Arquitetura
7.

8.

9.

Qual a melhor organizao de arquitetura


para satisfazer os requisitos no
funcionais do sistema?
Como o projeto de arquitetura ser
avaliado?
Como a arquitetura do sistema deve ser
documentada?

Decises de Projeto de
Arquitetura

Para sistemas embarcados e sistemas para


computadores pessoais no necessrio
projetar uma arquitetura distribuda.

No entanto, a maioria dos sistemas de


grande porte so distribudos entre vrios
servidores.

A escolha da arquitetura de distribuio


uma deciso importante que afeta o
desempenho e a confiabilidade do sistema.

Decises de Projeto de
Arquitetura

A arquitetura de um sistema de software


pode se basear em um determinado
padro.

Um padro de arquitetura descreve uma


organizao de sistema, como uma
organizao cliente-servidor ou
arquitetura em camadas.

Os padres de arquitetura capturam a


essncia de uma arquitetura que tem

Decises de Projeto de
Arquitetura

Ao tomar decises sobre a arquitetura de


um sistema, deve-se conhecer:
Os
Em

padres existentes;
que situaes podem ser usados;

Quais

so seus pontos fortes e fracos.

Decises de Projeto de
Arquitetura

Os requisitos no funcionais precisam ser


considerados ao se projetar a arquitetura
do sistema, para que esta possa atendlos.

Alguns desses requisitos so:

Decises de Projeto de
Arquitetura
1.

Desempenho:
A arquitetura deve ser projetada para
inserir as operaes mais importantes
dentro de um pequeno nmero de
componentes, instalados no mesmo
servidor, ao invs de distribudos pela
rede.

Decises de Projeto de
Arquitetura

Estes componentes podem ser


relativamente grandes, em vez de
pequenos de baixa granularidade, o que
reduz o nmero de comunicaes entre
eles.

Tambm pode-se considerar a


organizao do sistema de run-time, que
permite que o sistema seja replicado e
executado em diferentes servidores.

Decises de Projeto de
Arquitetura
2.

Proteo:

Deve ser usada uma estrutura em


camadas para a arquitetura;

Os ativos mais crticos devem estar


localizados nas camadas mais internas,
com alto nvel de validao de proteo
aplicado a elas.

Decises de Projeto de
Arquitetura
3.

Segurana:

As operaes de segurana devem se


localizar em um pequeno nmero de
componentes;
Isso reduz custos e problemas de
validao de segurana;
Fornece sistemas de proteo
relacionados que podem desligar o
sistema de maneira segura em caso de
falha.

Decises de Projeto de
Arquitetura
4.

Disponibilidade:

A arquitetura deve ser projetada para


incluir componentes redundantes, para
que seja possvel substituir e atualizar
componentes sem parar o sistema.

Decises de Projeto de
Arquitetura
5.

Manuteno:

A arquitetura deve ser projetada a partir


de componentes autocontidos de baixa
granularidade que podem ser
rapidamente alterados;

Os produtores de dados devem ser


separados dos consumidores, e estruturas
de dados compartilhadas devem ser
evitadas.

Decises de Projeto de
Arquitetura

H um conflito potencial entre essas


arquiteturas.

O uso de componentes de grande porte


melhora o desempenho enquanto o uso
de componentes pequenos de baixa
granularidade melhora a
manutenibilidade.

Padres de Arquitetura

So descries abstratas, estilizadas, de boas


prticas experimentadas e testadas em
diferentes sistemas e ambientes.

Um padro de arquitetura deve descrever


uma organizao de sistema bem-sucedida
em sistemas anteriores.

Deve incluir informaes de quando o uso


desse padro adequado e seus pontos
fortes e fracos.

Padro MVC
Model-View-Controller

As noes de separao e independncia


so fundamentais para o projeto de
arquitetura, porque permitem que
alteraes sejam localizadas.

O padro MVC separa os elementos de


um sistema, permitindo mud-los de
forma independente.

Padro MVC
Model-View-Controller

O sistema estruturado em trs


componentes lgicos que interagem entre si:
Modelo:

gerencia o sistema de dados e as


operaes associadas a esses dados.
Viso: define e gerencia como os dados
so apresentados ao usurio.
Controlador: gerencia a interao do
usurio e as repassa para a Viso e o
Modelo.

Padro MVC
Model-View-Controller

usado quando existem vrias maneiras


de se visualizar e interagir com os dados.

Tambm utilizado quando so


desconhecidos os futuros requisitos de
interao e apresentao de dados.

Padro MVC
Model-View-Controller

Permite que os dados sejam alterados de


forma independente de sua
representao e vice-versa.

Apoia a apresentao dos mesmos dados


de maneiras diferentes, com as
alteraes feitas em uma representao
aparecendo em todas elas.

Padro MVC
Model-View-Controller

Fonte: Sommerville (2011)

Padro MVC
Model-View-Controller

Fonte: Sommerville (2011)

Padro MVC
Model-View-Controller

Padro MVC
Model-View-Controller

Padro de Arquitetura em
Camadas

O sistema organizado em camadas


separadas.

Cada camada s depende dos recursos e


servios oferecidos pela camada
imediatamente abaixo dela.

Padro de Arquitetura em
Camadas

Essa abordagem permite o


desenvolvimento incremental de
sistemas.

Quando uma camada desenvolvida,


alguns dos servios prestados por ela
podem ser disponibilizados para os
usurios.

Padro de Arquitetura em
Camadas

A arquitetura tambm mutvel e portvel.

Enquanto sua interface for inalterada, uma


camada pode ser substituda por outra
equivalente.

Alm disso, quando a camada de interfaces


muda ou tem novos recursos adicionados,
apenas a camada adjacente afetada.

Padro de Arquitetura em
Camadas

Como sistemas em camadas localizam


dependncias das mquinas em camadas
internas, isso facilita o fornecimento de
implementaes de multiplataformas de
um sistema de aplicao.

Apenas as camadas internas dependentes


da mquina precisam ser reimplementadas
para levar em conta os recursos de um
sistema operacional diferente ou banco de
dados.

Padro de Arquitetura em
Camadas

Vantagens:

Desde que a interface seja mantida,


permite a substituio de camadas
inteiras.

Recursos redundantes podem ser


fornecidos em cada camada para
aumentar a confiana do sistema.

Padro de Arquitetura em
Camadas

Desvantagens:
Pode ser difcil proporcionar uma
separao entre as camadas;
Uma camada de alto nvel pode ter de
interagir diretamente com camadas de
baixo nvel, ao invs da camada abaixo
dela.
O desempenho pode ser afetado devido
aos mltiplos nveis de interpretao de
uma solicitao de servio, uma vez que
so processados em cada camada.

Padro de Arquitetura em
Camadas

Fonte: Sommerville (2011)

Padro de Arquitetura de
Repositrio

A maioria dos sistemas que usam


grandes quantidades de dados
organizada em torno de um banco de
dados ou repositrio compartilhado.

Esse modelo adequado para aplicaes


nas quais os dados so gerados por um
componente e usados por outro.

Padro de Repositrio

Os subsistemas precisam trocar


informaes para que possam trabalhar
em conjunto.

Existem duas maneiras para fazer isto:

1.

Os dados compartilhados so mantidos


em um banco de dados central acessado
pelos subsistemas.
Esse modelo chamado de modelo de
repositrio;

Padro de Repositrio
2.

Cada subsistema mantm seu prprio


banco de dados.
Os dados so intercambiados com outros
subsistemas por meio de mensagens.

Padro de Repositrio

Fonte: Sommerville (2011)

Padro de Repositrio
Vantagens e Desvantagens

uma maneira eficiente de compartilhar


grandes quantidades de dados.

No h necessidade de transmitir os
dados de um componente para outro.

Padro de Repositrio
Vantagens e Desvantagens

Porm, os componentes devem concordar


com o modelo de dados de repositrio.

Pode ser difcil integrar novos


componentes se seus modelos de dados
no se adequarem ao esquema
estabelecido.

Padro de Repositrio
Vantagens e Desvantagens

Os componentes que produzem dados no


precisam saber como esses dados so
utilizados pelos outros componentes.

Alm disso so independentes, eles no


precisam saber da existncia uns dos outros.

A desvantagem maior deste padro, que o


repositrio um ponto nico de falha que
pode afetar todo o sistema.

Padro de Repositrio
Vantagens e Desvantagens

Atividades como backup, segurana,


controle de acesso e recuperao so
centralizadas e de responsabilidade do
gerente de repositrio.

As ferramentas podem focalizar suas


principais funes, sem se preocupar
com essas questes.

Padro de Repositrio
Vantagens e Desvantagens

Porm, diferentes componentes podem


ter diferentes requisitos para polticas de
proteo, recuperao e backup.

O modelo de repositrio impe a mesma


poltica a todos os componentes.

Padro de Repositrio
Vantagens e Desvantagens

simples e direto integrar novas


ferramentas, desde que sejam compatveis
com o modelo de dados estabelecido.

Contudo, pode ser difcil distribuir o


repositrio em uma srie de mquinas.

Embora seja possvel distribuir um repositrio


logicamente centralizado, pode haver
problemas de redundncia e inconsistncia
de dados.

Arquitetura
Cliente-Servidor

organizado como um conjunto de


servios e servidores e clientes que
solicitam os servios.

Este modelo compe-se principalmente


de:

1.

Um conjunto de servidores que oferecem


servios a outros componentes.

Arquitetura
Cliente-Servidor
2.

Um conjunto de clientes que solicitam os


servios oferecidos pelos servidores.

3.

Uma rede que permita aos clientes


acessar esses servios.

A maioria dos sistemas cliente-servidor


implementada como sistemas
distribudos, conectados atravs de
protocolos de internet.

Arquitetura
Cliente-Servidor

A vantagem principal deste modelo que


ele uma arquitetura distribuda,
permitindo o uso efetivo de sistemas de
rede com muitos processadores
distribudos.

fcil incluir um novo servidor e integrlo ao sistema ou fazer a atualizao dos


servidores de modo transparente, sem
afetar outras partes do software.

Arquitetura
Cliente-Servidor

Os clientes podem ter de saber os nomes dos


servidores e os servios que eles fornecem.

No entanto, os servidores no precisam


conhecer a identidade dos clientes ou quantos
clientes esto acessando seus servios.

Os clientes acessam os servios fornecidos por


um servidor por meio de chamadas de
procedimento remoto usando um protocolo de
solicitao-resposta.

Arquitetura
Cliente-Servidor

Fonte: Sommerville (2011)

Arquitetura
Cliente-Servidor

No h nenhum modelo de dados


compartilhado e os componentes
normalmente organizam seus dados de
diferentes modos.

Isso significa que modelos especficos de


dados podem ser estabelecidos para
cada servidor, o que permite otimizar seu
desempenho.

Arquitetura
Cliente-Servidor

Porm a falta de um modelo de referncia


compartilhada para dados pode significar
que difcil prever problemas na integrao
de dados a partir de um novo servidor.

Cada servidor deve assumir a


responsabilidade por atividades de
gerenciamento de dados, como backup e
recuperao.

Sistemas Distribudos
Middleware

Os componentes em um SD podem ser


implementados em diferentes linguagens
e podem ser executados em diferentes
tipos de processador.

Os modelos de dados, representao de


informaes, protocolos para
comunicao podem ser todos diferentes.

Middleware

Um SD requer um software que possa


gerenciar essas diversas partes e assegurar
que elas possam se comunicar e trocar
dados.

Middleware o termo utilizado para se referir


a esse software.

Um middleware pode ser visto como uma


camada de software intermediria localizada
entre o sistema operacional e a aplicao

Middleware

O middleware costuma ser implementado


como um conjunto de bibliotecas e um
sistema de tempo de execuo para
gerenciar a comunicao.

O middleware normalmente instalado


em cada computador do sistema
distribudo.

Middleware

Fonte: Sommerville (2011)

Middleware

1.
.
.

O middleware fornece dois tipos de suporte:


Suporte a interao:
Coordena as interaes entre componentes.
Fornece transparncia da localizao os
componentes no precisam saber os locais
fsicos dos outros componentes.
Suporta a converso de parmetros se
diferentes linguagens forem usadas para
implementar componentes.

Middleware
2.

Prestao de servios comuns:

Fornece implementaes reusveis de


servios que podem ser exigidas por
vrios componentes, como servios de
proteo (autenticao e autorizao).

Usando esses servios, os componentes


podem interoperar e prestar servios de
maneira consistente.

Tipos de Middleware
Middlewares Transacionais

Suportam transaes sncronas;

Coordenam requisies entre clientes e servidores.

Vantagens:

Componentes se mantm consistentes;

Bastante confiveis;

Boa performance;

Escalonamento e priorizao de solicitaes.

Tipos de Middleware
Middlewares Transacionais

Desvantagens:

Ausncia de padronizao para descrever


servios;

Executa numa menor quantidade de


plataformas;

Serializao (marshalling) e deserializao


(unmarshalling) precisam ser
implementados manualmente.

Middlewares
Orientados a Mensagens

Message Queuing (Fila de Mensagens)

Comunicao indireta;

Assincrona;

Mensagens enviada para filas;

Message Passing (Passagem de Mensagens)

Comunicao direta;

Sncrona;

Middlewares
Orientados a Mensagens

Vantagens:

Suporta comunicao em grupo;

Confiabilidade;

Amplo suporte a protocolos de rede.

Desvantagens:

Escalabilidade e heterogeneidade limitadas;

Pouca portabilidade por falta de padronizao.

Middlewares
Orientados a Objetos

Evoluo dos middlewares procedurais;

Interao por invocao de mtodos;

Comunicao tipicamente sncrona;

IDLs (Interface Description Language ou


Linguagem de Descrio de Interface)
para descrever servios.

Middlewares
Orientados a Objetos

Vantagens:

Grande suporte a heterogeneidade;

Serializao e deserializao (Marshalling


e unmarshalling) automticos;

Versatilidade.

Desvantagens:

Pouca Escalabilidade.

Middlewares
Exemplos

Transacionais :

Orientados a Mensagens:

Tuxedo (BEA);
CICS (IBM);
Encina (Transarc).
MQSeries (IBM);
JMS (Sun).

Orientados a Objetos:

CORBA (OMG);
COM (Microsoft).

Sistemas
Cliente-Servidor

SDs em geral so cliente-servidor.

necessria uma separao clara entre a


apresentao de informaes e as
computaes que criam e processam essas
informaes.

A arquitetura deve ser projetada de forma a


ser estruturada em vrias camadas lgicas,
com interfaces claras entre essas camadas.

Sistemas
Cliente-Servidor

Camadas:

Uma camada para apresentar informaes


para o usurio e gerenciamento de toda a
interao com o usurio;

Uma camada que gerencia os dados que so


passados de e para o cliente;

Sistemas
Cliente-Servidor

Uma camada de processamento de


aplicao que que implementa a lgica de
aplicao e fornece a funcionalidade
necessria para os usurios;

Uma camada de banco de dados que


armazena os dados e fornece servios de
gerenciamento de transaes etc.

Sistemas
Cliente-Servidor

Fonte: Sommerville (2011)

Arquitetura
Mestre-Escravo

usada em sistemas de tempo real em


que necessria a garantia dos tempos
de resposta de interao.

Costumam haver processadores


separados associados aquisio de
dados do ambiente do sistema,
processamento de dados, de
gerenciamento de atuadores e
computao.

Arquitetura
Mestre-Escravo

O processo 'mestre' geralmente


responsvel pelo processamento,
coordenao e comunicaes e controla
os processos 'escravos'.

Os processos 'escravos' so dedicados a


aes especficas, tais como a aquisio
de dados de um vetor de sensores.

Arquitetura
Mestre-Escravo

usada em situaes em que:


Seja necessrio prever o
processamento distribudo;
O processamento pode ser facilmente
localizado para processadores escravos.
Processadores escravos podem ser
usados para operaes
computacionalmente intensivas como
processamento de sinais e o
gerenciamento de equipamentos
controlados pelo sistema.

Arquitetura
Mestre-Escravo

Fonte: Sommerville (2011)

Arquitetura Cliente-Servidor de
Duas Camadas

a forma mais simples dessa


arquitetura.

O sistema implementado como um


nico servidor lgico e um nmero
indefinido de clientes que usam esse
servidor.

Possui dois modelos:

Arquitetura Cliente-Servidor de
Duas Camadas

Cliente-magro, em que somente a


camada de apresentao
implementada no cliente;

Todas as outras camadas so


implementadas em um servidor:
Gerenciamento

de dados;
Processamento de aplicao;
Banco de dados.

Arquitetura Cliente-Servidor de
Duas Camadas

Cliente-gordo, em que parte ou todo o


processamento da aplicao realizado
no cliente.

As funes de gerenciamento de dados e


banco de dados so implementadas no
servidor.

Arquitetura Cliente-Servidor de
Duas Camadas

Vantagem do cliente-magro:

Simplicidade em gerenciar os clientes;

Podia ser problemtica quando havia um


grande nmero de clientes, sendo difcil e
caro instalar um novo software em todos
eles;

Se um navegador web for usado como


cliente, no necessrio instalar

Arquitetura Cliente-Servidor de
Duas Camadas

Fonte: Sommerville (2011)

Arquitetura Cliente-Servidor de
Duas Camadas

Desvantagem do modelo cliente-magro:

Colocar uma carga pesada de


processamento no servidor e na rede;

Isso pode levar gerao de trfego


significativo entre o cliente e o servidor.

Arquitetura Cliente-Servidor de
Duas Camadas

O modelo cliente-gordo faz uso do poder


de processamento disponvel no
computador que executa o software
cliente;

Distribui parte ou todo o processamento


de aplicao e a apresentao para o
cliente;

O servidor gerencia as transaes do


banco de dados.

Arquitetura Cliente-Servidor de
Duas Camadas

A desvantagem requerer
gerenciamento de sistema adicional para
implantar e manter o software no
computador cliente.

Mais processamento delegado ao


cliente j que o processamento da
aplicao executado localmente.

Arquitetura Cliente-Servidor de
Duas Camadas

Mais complexo do que um modelo


cliente-magro, especialmente no
gerenciamento.

Novas verses da aplicao precisam ser


instaladas em todos os clientes.

Arquitetura cliente-servidor
multicamadas

Nesta arquitetura, as diferentes camadas


do sistema so processos separados que
podem ser executados em diferentes
processadores.

Isso evita problemas com escalabilidade


e desempenho, caso um modelo clientemagro de duas camadas seja escolhido;

Ou problemas de gerenciamento do
sistema caso um modelo cliente-gordo for

Arquitetura cliente-servidor
multicamadas

Fonte: Sommerville (2011)

Arquitetura de Componentes
Distribudos

Em uma arquitetura de componentes


distribudos no existe distino entre
clientes e servidores.

Cada entidade distribuvel um


componente que fornece servios para
outros componentes e recebe servios de
outros componentes.

Arquitetura de Componentes
Distribudos

A comunicao dos componentes se d


por meio de um sistema de middleware.

No entanto, arquiteturas de componentes


distribudos so mais complexas de se
projetar do que sistemas cliente-servidor.

Arquitetura de Componentes
Distribudos

Fonte: Sommerville (2011)

Arquitetura de Componentes
Distribudos

Vantagens:

1.

O projetista pode atrasar decises sobre


onde e como os servios devero ser
prestados.
Os componentes fornecedor de servios
podem executar em qualquer n da rede.
No necessrio decidir previamente se
um servio parte de uma camada de
gerenciamento de dados ou uma camada
de aplicao, por exemplo.

Arquitetura de Componentes
Distribudos
2.

uma arquitetura de sistemas muito


aberta.

Permite a adio de novos recursos


conforme necessrio;

Novos servios de sistema podem ser


adicionados facilmente sem grandes
perturbaes ao sistema existente.

Arquitetura de Componentes
Distribudos
3.

O sistema flexvel e escalvel.

Novos componentes ou componentes


replicados podem ser adicionados
quando a carga sobre o sistema
aumenta, sem interromper as outras
partes do sistema.

4.

possvel reconfigurar o sistema


dinamicamente com componentes
migrando atravs da rede conforme

Arquitetura de Componentes
Distribudos

Desvantagens:

1.

Esta arquitetura mais complexa para


projetar que sistemas cliente-servidor.

2.

H middlewares diferentes e
incompatveis. Esses middlewares so
complexos e aumentam a complexidade
geral do sistema distribudo.

Arquitetura Ponto-a-ponto
(p2p peer-to-peer)

So sistemas descentralizados em que os


processamentos podem ser realizados
por qualquer n na rede.

O sistema projetado para tirar proveito


do poder computacional e do
armazenamento de um grande nmero
de computadores em rede.

Arquitetura Ponto-a-ponto

Fonte: Sommerville (2011)

Arquitetura Ponto-a-ponto
(p2p peer-to-peer)

Como no possvel que todos os ns


estejam conectados entre si, os ns so
organizados em localidades com alguns
ns atuando como pontes para outras
localidades de ns.

Arquitetura Ponto-a-ponto
(p2p peer-to-peer)

Uma das vantagens dessa arquitetura


que ela altamente redundante e
tolerante a defeitos e desconexo de
ns da rede.

No entanto, as desvantagens so que


muitos ns diferentes podem processar a
mesma pesquisa e ocorrer um overhead
significativo em pontos replicados.

Padres de Projeto

Um padro descreve um problema e o


ncleo da sua soluo, de maneira que se
possa usar essa soluo quantas vezes
for preciso e aplic-la de formas
diferentes.

Costuma conter descries de objetos e


classes que se comunicam e que
precisam ser personalizadas para
resolver um problema geral de projeto
num contexto particular.

Padres de Projeto

1.

2.

.
.

Um padro tem quatro elementos


essenciais:
Nome: Usado para descrever um
problema de projeto, suas solues e
consequncias.
Problema: Descreve em que situao
aplic-lo.
Explica o problema e seu contexto.
Pode incluir uma lista de condies que

Padres de Projeto
3.

Soluo: Descreve os elementos que


compem o padro, seus
relacionamentos, suas responsabilidades
e colaboraes.
No descreve um projeto concreto ou
uma implementao especfica porque
um padro deve poder ser aplicado em
diversas situaes.
Fornece uma descrio abstrata de um
problema de projeto e de como um

Padres de Projeto
4.

Consequncias:

Descrevem as vantagens e desvantagens


da aplicao do padro.

So teis para avaliar alternativas de


projetos e para compreender os custos e
benefcios da aplicao do padro.

Padres de Criao

Abstraem o processo de instanciao.


Ajudam a tornar um sistema
independente de como seus objetos so
criados, compostos e representados.
Um padro de criao de classe usa
herana para variar a classe que
instanciada.
Um padro de criao de objeto delegar
a instanciao para outro objeto.

Factory

Inteno:

Definir uma interface para criar um


objeto, mas deixar as subclasses
decidirem que classe instanciar.

Permite adiar a instanciao para as


subclasses.

Interface

Uma interface como um contrato entre


a classe e o mundo exterior.
Quando uma classe implementa uma
interface, se compromete a fornecer o
comportamento publicado por esta
interface.
As interfaces so formadas pela
declarao de um ou mais mtodos que
no possuem corpo.
As operaes especficas para cada um
desses mtodos so realizadas pela

Factory

Aplicabilidade: Deve-se us-lo quando:

Uma classe no pode antecipar a classe


de objetos que deve criar;

Uma classe quer que suas subclasses


especifiquem os objetos que criam;

Uma classe delega responsabilidade para


uma dentre vrias subclasses auxiliares.

Factory

Participantes:

Product: Define a interface de objetos


que o mtodo Factory cria.

ConcreteProduct: Implementa a interface


de Product.

Factory

Creator: Declara o mtodo Factory, o qual


retorna um objeto do tipo Product.

ConcreteCreator: Redefine o mtodo


Factory para retornar a uma instncia de
um ConcreteProduct.

Factory
Estrutura

Factory

Colaboraes:

Creator depende das suas subclasses


para definir o mtodo fbrica de maneira
que retorne uma instncia do
ConcreteProduct apropriado.

Factory

Consequncias:

1.

Elimina a necessidade de anexar classes


especficas das aplicaes no cdigo. O
cdigo lida somente com a interface de
Product.

2.

Uma possvel desvantagem que os


clientes podem ter que fornecer
subclasses da classe Creator somente
para criar um objeto ConcreteProduct em

Factory
Exemplo Prtico Simples

Deve-se trabalhar com um conjunto de


carros, cada um de uma determinada
fbrica.
Palio

Fiat
Gol Volkswagen
Celta Chevrolet
Fiesta Ford

Ser necessrio manipular este conjunto


de carros em diversas operaes.

Factory

Factory
Exerccio

Aplique o padro Factory de maneira a


criar um pequeno dicionrio em que se
possa traduzir Bom dia em vrios
idiomas:
Ingls

Good Morning;
Francs Bon Jour;
Alemo Guten Tag;
Italiano Buon Giorno;
Espanhol Buenos Dias.

Abstract Factory

Inteno:
Fornecer uma interface para criao de
famlias de objetos relacionados ou
dependentes sem especificar suas
classes concretas.
Aplicabilidade: Deve-se us-lo quando:
Um sistema deve ser independente de
como seus produtos so criados,
compostos ou representados;

Abstract Factory

Um sistema deve ser configurado como


um produto de uma famlia de mltiplos
produtos;

Uma famlia de objetos-produto for


projetada para ser usada em conjunto, e
preciso garantir esta restrio;

Deseja-se fornecer uma biblioteca de


classes de produtos e se quer revelar
somente suas interfaces, no suas

Abstract Factory
Participantes

AbstractFactory: Declara uma interface


para operaes que criam objetosproduto abstratos;
ConcreteFactory: Implementa as
operaes que criam objetos-produtos
concretos;
AbstractProduct: Declara uma interface
para um tipo de objeto-produto;
ConcreteProduct: Define um objetoproduto a ser criado pela fbrica concreta
correspondente Implementa a interface

Abstract Factory
Estrutura

Abstract Factory
Colaboraes

Normalmente uma nica instncia de


uma classe ConcreteFactory criada em
tempo de execuo.

Essa fbrica concreta cria objetosproduto que tm uma implementao


particular.

AbstractFactory adia a criao dos


objetos-produto para as suas subclasses
ConcreteFactory.

Abstract Factory
Exemplo Prtico Simples

Deve-se desenvolver um software que


manipule um conjunto de carros, porm
necessrio agrup-los em conjuntos com
caractersticas semelhantes.
Sedan:
Siena

Fiat
Fiesta Sedan Ford

Popular:
Palio

Fiat
Fiesta Ford

Abstract Factory
Exemplo Prtico Simples

Abstract Factory
Exerccio

Crie um programa que utilize o padro


Abstract Factory para apresentar grupos
de animais:
Carnvoro:
Ona

Mamfero;
Jacar Rptil;

Herbvoro:
Capivara

Mamfero;
Jabuti Rptil;

Abstract Factory
Consequncias
1.

Isola as classes concretas: Ajuda a


controlar as classes de objetos criadas
por uma aplicao.
Isola os clientes das classes de
implementao, j que a fbrica
encapsula a responsabilidade e o
processo de criar objetos-produto;.
Os clientes manipulam as instncias
atravs das suas interfaces abstratas.
Nomes de classes-produto ficam isolados
na implementao da fbrica concreta;

Abstract Factory
Consequncias
2.

Torna fcil a troca de famlias de


produtos:
A classe de uma fbrica concreta aparece
apenas uma vez numa aplicao.
Facilita mudar a fbrica concreta que
uma aplicao usa.
Ela pode usar diferentes configuraes de
produtos trocando a fbrica concreta.
Uma vez que a fbrica abstrata cria uma
famlia completa de produtos, toda a
famlia muda uma s vez.

Abstract Factory
Consequncias
3.

Promove a harmonia entre produtos:


Quando objetos-produto numa famlia so
projetados para trabalharem juntos,
importante que uma aplicao use
objetos de somente uma famlia de cada
vez.

Abstract Factory
Consequncias
4.

difcil suportar novos tipos de


produtos:
Estender fbricas abstratas para produzir
novos tipos de produtos pode no ser
fcil.
Isso se deve ao fato de que a interface de
AbstractFactory fixa o conjunto de
produtos que podem ser criados.
Suportar novos tipos de produto exige
estender a interface da fbrica, o que
envolve mudar a classe AbstractFactory e

Singleton

Inteno:

Garantir que uma classe tenha somente


uma instncia e fornecer um ponto global
de acesso para a mesma.

Singleton

Aplicabilidade:
Usa-se o padro Singleton quando:
For preciso haver apenas uma instncia
de uma classe, e essa instncia tiver que
dar acesso aos clientes atravs de um
ponto bem conhecido.
A nica instncia tiver de ser extensvel
atravs de subclasses, possibilitando aos
clientes usar uma instncia estendida
sem alterar o seu cdigo.

Singleton
Participantes

Singleton: Define uma operao Instance


que permite aos clientes acessarem sua
nica instncia.

Instance uma operao de classe.

Pode ser responsvel pela criao da sua


prpria instncia nica.

Singleton
Estrutura

Singleton
Exemplo Prtico Simples

Tomemos novamente o exemplo da


fbrica de carros do padroFactory
Method.
A classe fbrica centraliza a criao de
objetos carro.
Vamos utilizar o padro Singleton de
forma a apresentar um contador que
armazene a quantidade de carros de uma
determinada marca que foram vendidos,
porm deve haver somente uma
instncia da classe Fbrica para impedir
que os contadores sejam zerados.

Singleton
Exerccio

Mescle o exemplo do padro Factory com


o padro Singleton de maneira que seja
dada opo ao usurio para escolher qual
modelo deseja fabricar e que oferea a
opo de relatrio que apresente a
quantidade de total de cada modelo
fabricado.

Singleton
Consequncias
1.

Acesso controlado instncia nica:


Como a classe Singleton encapsula a sua
nica instncia, possui controle total
sobre como e quando os clientes a
acessam.

2.

Espao de nomes reduzido: Este padro


representa uma melhoria em relao ao
uso de variveis globais que armazenam
instncias nicas.

Singleton
Consequncias
3.

Permite um refinamento de operaes e


da representao:

A classe Singleton pode ter subclasses e


fcil configurar uma aplicao com uma
instncia dessa classe estendida.

Builder

Inteno:

Separar a construo de um objeto


complexo da sua representao de modo
que o mesmo processo de construo
possa criar diferentes representaes.

Builder
Aplicabilidade

Deve-se us-lo quando:

O algoritmo para criao de um objeto


complexo deve ser independente das
partes que compem o objeto e de como
elas so montadas.

O projeto de construo deve permitir


diferentes representaes para o objeto
que construdo.

Builder
Participantes

Builder: Especifica uma interface abstrata


para criao de partes de um objetoproduto;

ConcreteBuilder:
Constri e monta partes do produto pela
implementao da interface de Builder;
Define e mantm a representao que cria;
Fornece uma interface para recuperao do
produto.

Builder
Participantes

Director: Constri um objeto usando a


interface builder.

Product:
Representa o objeto complexo em construo.
ConcreteBuilder constri a representao
interna do produto e define o processo pelo
qual ele montado;
Inclui classes que definem as partes
constituintes, inclusive as interfaces para a
montagem das partes no resultado final.

Builder

Builder
Colaboraes

O cliente cria o objeto Director e o


configura com o objeto Builder desejado.

Director notifica o construtor sempre que


uma parte do produto deve ser
construda.

Builder trata solicitaes do diretor e


acrescenta partes ao produto.

O cliente recupera o produto do

Builder
Exemplo Prtico Simples

Sistema de Venda de Carros:

necessrio modelar um sistema de


venda de carros para uma
concessionria.

Deseja-se que o sistema seja flexvel,


para adio de novos carros, e de fcil
manuteno.

Exemplo Prtico Simples

Builder
Consequncias
1.

Permite variar a representao interna de


um produto:
O objeto Builder fornece ao diretor uma
interface abstrata para a construo do
produto.
A interface permite ao construtor ocultar a
representao e a estrutura interna do
produto.
Tambm oculta como o produto
montado.
J que o produto construdo atravs de
uma interface abstrata, s preciso definir

Builder
Consequncias
2.

Isola o cdigo para construo e


representao:

O padro Builder melhora a modularidade


pelo encapsulamento da forma como um
objeto complexo construdo e
representado.

Os clientes nada necessitam saber sobre


as classes que definem a estrutura interna
do produto; tais classes no aparecem na
interface do Builder.

Builder
Consequncias

Cada ConcreteBuilder contm todo o


cdigo para criar e montar um tipo de
produto especfico.

O cdigo escrito somente uma vez;


ento, diferentes Directors podem
reutiliz-lo para construir variantes de
Product com o mesmo conjunto de partes.

Builder
Consequncias
3.

Oferece um controle mais fino sobre o


processo de construo:
Ao contrrio de padres de criao que
constroem produtos de uma s vez, o
Builder constri o produto passo a passo
sob o controle do diretor.

Builder
Consequncias

Somente quando o produto est terminado


o diretor o recupera do construtor.

Da a interface de Builder refletir o


processo de construo do produto mais
explicitamente do que outros padres de
criao.

Isso d um controle mais fino sobre o


processo de construo e,
consequentemente, da estrutura interna
do produto resultante.

Prototype

Inteno:

Especificar os tipos de objetos a serem


criados usando uma instncia-prottipo e
criar novos objetos pela cpia desse
prottipo.

Prototype
Aplicabilidade

Quando um sistema precisar ser


independente de como os seus produtos
so criados, compostos e representados;

Quando as classes a instanciar forem


especificadas em tempo de execuo;

Prototype
Aplicabilidade

Para evitar a construo de uma


hierarquia de classes de fbricas
paralelas hierarquia de classes de
produto;

Quando as instncias de uma classe


puderem ter uma dentre poucas
combinaes diferentes de estados.

Prototype
Participantes

Prototype: Declara uma interface para


clonar a si prprio;
ConcretePrototype: Implementa uma
operao para clonar a si prprio;
Client: Cria um novo objeto solicitando a
um prottipo que clone a si prprio.
Colaboraes:
Um cliente solicita a um prottipo que
este clone a si prprio.

Prototype
Estrutura

Prototype
Exemplo Prtico Simples

O programa deve permitir instanciar uma


lista de carros que o cliente precisa
utilizar, mas que s sero conhecidos em
tempo de execuo.

Apresentaremos a seguir como solucionar


esse problema aplicando o padro
Prototype.

Prototype

Prototype
Exerccio

Crie um programa utilizando o padro


Prototype para instanciar espcies de
animais.
Deve ser possvel instanciar mamferos e
rpteis tanto carnvoros como herbvoros.
Mamferos
Ona

Carnvoros;
Capivara Herbvoros;

Rpteis:
Jacar

Carnvoros;
Jabuti Herbvoros.

Prototype
Consequncias
1.

Oculta as classes de produtos concretas


do cliente, reduzindo o nmero de
nomes que os clientes necessitam saber;

2.

Permite a um cliente trabalhar com


classes especficas de uma aplicao
sem necessidade de modificao.

Prototype
Consequncias
3.

Acrescenta e remove produtos em tempo


de execuo permite incorporar uma
nova classe concreta de produto a um
sistema, registrando uma instncia
prottipo com o cliente.

Isso um pouco mais flexvel do que


outros padres de criao, porque o
cliente pode instalar e remover prottipos
em tempo de execuo.

Prototype
Consequncias
4.

Especifica novos objetos pela variao


de valores.
Sistemas altamente dinmicos permitem
definir novos comportamentos atravs da
composio de objetos pela
especificao de valores para as
variveis de um objeto e no pela
definio de novas classes.

Prototype
Consequncias

Esse tipo de projeto permite aos usurios


definir novas classes sem ter que
programar.

Clonar um prottipo semelhante a


instanciar uma classe.

O padro Prototype pode reduzir


grandemente o nmero de classes que
um sistema necessita.

Prototype
Consequncias
5.

6.
.

Especifica novos objetos pela variao


da estrutura:
O padro Prototype permite a construo
de objetos com partes e subpartes.
Reduz o nmero de sub-classes:
Permite clonar um prottipo em vez de
pedir a um mtodo fbrica para construir
um novo objeto. Assim no necessrio
uma hierarquia de classes Creator.

Padres Estruturais

Preocupam-se com a forma como classes


e objetos so compostos para formar
estruturas maiores.

Os padres estruturais de classes


utilizam a herana para compor
interfaces ou implementaes.

Descrevem maneiras de compor objetos


para obter novas funcionalidades.

Adapter

Inteno:

Converter a interface de uma classe em


outra interface, esperada pelos clientes.

Permite que classes com interfaces


incompatveis trabalhem em conjunto, o
que, de outra forma, seria impossvel.

Adapter
Aplicabilidade

Quando se quiser usar uma classe


existente, mas sua interface no
corresponde interface de que se
necessita.
Deseja-se criar uma classe reutilizvel
que coopere com classes norelacionadas ou no-previstas classes
que no necessariamente tenham
interfaces compatveis.
For preciso usar vrias subclasses
existentes, porm for impraticvel
adaptar essas interfaces criando

Adapter
Participantes

Target: Define a interface especfica do


domnio que Client usa.
Client: Colabora com objetos compatveis
com a interface de Target.
Adaptee: Define uma interface existente
que necessita ser adaptada.
Adapter: Adapta a interface do Adaptee
interface de Target.

Adapter
Estrutura (a nvel de classe)

Adapter
Estrutura (a nvel de objeto)

Adapter

Colaboraes:

Os clientes chamam operaes em uma


instncia de Adapter.

Por sua vez, o adapter chama operaes


de Adaptee que executam a solicitao.

Adapter
Exemplo Prtico Simples

Apresentaremos a seguir um pequeno


programa que representar uma tomada
de dois pinos e uma tomada de trs
pinos, usando a classe adaptadora para
inserir a tomada de dois pinos na de trs
pinos.

Adapter
Exemplo Prtico Simples

Adapter
Exerccio

H uma interfaceMediaPlayere uma


classe concreta,
AudioPlayerimplementando a
MediaPlayer.AudioPlayertoca arquivos
mp3.
H outra interface,AdvancedMediaPlayer,
e duas classes concretas, VlcPlayer e
Mp4Player implementando a interface.
Deseja-se que AudioPlayertoque outros
formatos. Para isso necessrio criar um
adaptador que implemente a interface
MediaPlayer e utilize objetos

Adapter
Exerccio

Adapter
Consequncias

Os adaptadores de classes e de objetos


tm diferentes solues de compromisso.

Um adaptador de classe:

Adapta Adaptee a Target atravs do uso


efetivo de uma classe Adapter concreta.
Permite a Adapter substituir algum
comportamento do Adaptee, uma vez
que Adapter uma subclasse de
Adaptee;

Adapter
Consequncias

Um adaptador de objeto:
Permite a um nico Adapter trabalhar
com muitos Adaptees. O Adapter tambm
pode acrescentar funcionalidade a todos
os Adaptees de uma s vez;
Torna mais difcil redefinir um
comportamento de Adaptee. Ele exigir a
criao de subclasses de Adaptee e far
com que Adapter referencie a subclasse
ao invs do Adaptee em si.

Adapter
Consequncias

Um adaptador de objeto:
Permite a um nico Adapter trabalhar
com muitos Adaptees. O Adapter tambm
pode acrescentar funcionalidade a todos
os Adaptees de uma s vez;
Torna mais difcil redefinir um
comportamento de Adaptee. Ele exigir a
criao de subclasses de Adaptee e far
com que Adapter referencie a subclasse
ao invs do Adaptee em si.

Bridge

Inteno:

Desacoplar uma abstrao da sua


implementao, de modo que as duas
possam variar independentemente.

Bridge
Aplicabilidade

Quando deseja-se evitar um vnculo


permanente entre uma abstrao e sua
implementao. Isso pode ocorrer
quando a implementao deve ser
selecionada ou alterada em tempo de
execuo;
Tanto as abstraes como suas
implementaes tiverem de ser
extensveis por meio de subclasses.
Neste caso, o padro Bridge permite
combinar as diferentes abstraes e
implementaes e estend-las

Bridge
Aplicabilidade

Mudanas na implementao de uma


abstrao no puderem ter impacto
sobre os clientes, ou seja, quando o
cdigo dos mesmos no puder ser
recompilado.
Tiver uma proliferao de classes e
subclasses. Essa hierarquia de classes
indica necessidade de separar um objeto
em duas partes.
Desejar compartilhar uma
implementao entre mltiplos objetos e
este fato deve estar oculto do cliente.

Bridge
Participantes

Abstraction: define a interface da


abstrao e mantm uma referncia para
um objeto do tipo Implementor;
RedefinedAbstraction: estende a
interface definida por Abstraction;
Implementor: define a interface para as
classes de implementao;
ConcreteImplementor: implementa a
interface de Implementor e define sua
implementao concreta.

Bridge
Estrutura

Bridge

Colaboraes:

Abstraction repassa as solicitaes dos


clientes para o seu objeto Implementor.

Bridge
Exemplo

necessrio fazer um programa que v


funcionar em vrias plataformas, como
Windows, Linux, Mac, etc.

O programa far uso de diversas


abstraes de janelas grficas, por
exemplo, janela de dilogo, janela de
aviso, janela de erro, etc.

Bridge
Exemplo

Bridge
Exerccio

Desenvolva um programa usando o


padro Bridge que permita produzir em
uma oficina tanto carros como
motocicletas.

Bridge
Exerccio

Bridge
Consequncias
1.

2.

3.

Desacopla a interface da
implementao: uma implementao
no fica permanentemente presa a uma
interface. A implementao de uma
abstrao pode ser configurada em
tempo de execuo.
Extensibilidade melhorada: pode-se
estender as hierarquias de Abstraction e
Implementor independentemente.
Ocultao de detalhes de
implementao dos clientes, como o
compartilhamento de objetos

Composite

Inteno:

Compor objetos em estruturas de rvore


para representarem hierarquias partestodo.

Permite aos clientes tratarem de maneira


uniforme objetos individuais e
composies de objetos.

Composite
Aplicabilidade

Use o padro Composite quando:

Quiser representar hierarquias partestodo de objetos;

Quiser que os clientes sejam capazes de


ignorar a diferena entre composies de
objetos e objetos individuais. Os clientes
trataro todos os objetos na estrutura
composta de maneira uniforme.

Composite
Participantes

Component:
Declara a interface para os objetos na
composio;
Implementa comportamento-padro para
a interface comum a todas as classes;
Declara uma interface para acessar e
gerenciar os seus componentes-filhos;
Opcionalmente define uma interface para
acessar o pai de um componente na
estrutura recursiva e a implementa.

Composite
Participantes

Leaf:

Representa objetos-folha na composio.


Uma folha no tem filhos;

Define comportamento para objetos


primitivos na composio.

Composite
Participantes

Composite:
Define comportamento para
componentes que tm filhos;
Armazena os componentes-filho;
Implementa as operaes relacionadas
com os filhos presentes na interface de
Component.
Client:
Manipula objetos na composio atravs
da interface de Component.

Composite
Estrutura

Composite
Colaboraes

Os clientes usam a interface da classe


Component para interagir com os objetos
na estrutura composta.
Se o receptor uma Leaf, ento a
solicitao tratada diretamente.
Se o receptor um Composite, ele
normalmente repassa as solicitaes
para os seus componentes-filhos,
executando operaes adicionais antes
e/ou depois do repasse.

Composite
Exemplo Prtico Simples

Apresentaremos a seguir um programa


de gerenciamento de arquivos, como
vdeos, textos e imagens e arquivos do
tipo pasta, que armazenam outros
arquivos utilizando o padro Composite.

Composite
Exemplo Prtico Simples

Composite
Exerccio

Desenvolva um programa utilizando o


padro Composite, onde haja uma
interface geral contendo os mtodos de
saudao e despedida, uma classe que
implemente esta interface chamada
Folha e que contenha um atributo nome,
e uma classe chamada Composio que
tambm implemente a interface e possa
ser composta por muitas folhas. Os
objetos desta ltima classe devem ser
capazes de adicionar ou remover folhas,
listar todas as folhas que os compem ou

Composite
Exerccio

Composite
Consequncias

Define hierarquias de classe que


consistem de objetos primitivos e objetos
compostos. Os objetos primitivos podem
compor objetos mais complexos. Sempre
que o cdigo do cliente esperar um
objeto primitivo, ele tambm poder
aceitar um objeto composto.
Torna o cliente simples. Os clientes
podem tratar estruturas compostas e
objetos individuais de maneira uniforme.
Os clientes no sabem se esto tratando
com uma folha ou um componente

Composite
Consequncias

Torna mais fcil acrescentar novas


espcies de componentes. Novas
estruturas existentes, Composite ou Leaf
funcionam com as estruturas existentes e
o cdigo do cliente. Os clientes no
precisam ser alterados para tratar novas
classes Component.
Pode tornar o projeto excessivamente
genrico. A desvantagem de facilitar o
acrscimo de novos componentes que
isso torna mais difcil restringir os
componentes de uma composio.

Decorator

Inteno:

Dinamicamente, agregar
responsabilidades adicionais a um objeto.

Os Decorators fornecem uma alternativa


flexvel ao uso de subclasses para
extenso de funcionalidades.

Decorator
Participantes

Component: Define a interface para


objetos que podem ter responsabilidades
acrescentadas aos mesmos
dinamicamente.
ConcreteComponent: Define um objeto
para o qual responsabilidades adicionais
podem ser atribudas.
Decorator: Mantm uma referncia para
um objeto Component e define uma
interface que segue a interface de
Component.

Decorator
Estrutura

Decorator
Colaboraes

Decorator repassa solicitaes para o seu


objeto Component.

Opcionalmente, ele pode executar


operaes adicionais antes e depois de
repassar a solicitao.

Decorator
Exemplo bsico simples

Iremos apresentar um pequeno programa


utilizando o padro Decorator, que
permite decorar um sorvete simples
com nozes e confeitos de chocolate.

Decorator
Exemplo bsico simples

Decorator
Aplicabilidade

Usa-se quando:
Para acrescentar responsabilidades a
objetos individuais de forma dinmica e
transparente, ou seja, sem afetar outros
objetos;
Para responsabilidades que podem ser
removidas;
Quando a extenso atravs do uso de
subclasses no prtica (exploso de
subclasses).

Decorator
Exerccio

Desenvolvar um programa utilizando o


padro Decorator que permite montar
carros bsicos, mas que tambm permita
decor-los com caractersticas de
carros esporte ou carros de luxo.

Decorator
Exerccio

Decorator
Consequncias
1.

Maior flexibilidade do que a herana


esttica: fornece uma maneira mais
flexvel de acrescentar responsabilidades
a objetos do que pode ser feito com
herana.
Responsabilidades podem ser
acrescentadas e removidas em tempo de
execuo associando-as e disassociandoas de um objeto.
Tambm torna fcil acrescentar uma

Decorator
Consequncias
2.

Evita classes sobrecarregadas de


caractersticas na parte superior da
hierarquia: oferece uma abordagem do
tipo use quando for necessrio para
adio de responsabilidades.
Ao invs de tentar suportar todas as
caractersticas previsveis em uma classe
complexa e customizada, pode-se definir
uma classe simples e acrescentar
funcionalidade de modo incremental com
objetos Decorator. A funcionalidade
necessria pode ser composta a partir de

Decorator
Consequncias
3.

Um decorador e o seu componente no


so idnticos: um decorador funciona
como um envoltrio transparente.
Porm, do ponto de vista da identidade
de um objeto, um componente decorado
no idntico ao prprio componente.
Da no poder depender da identidade de
objetos quando voc utiliza decoradores.

Decorator
Consequncias
4.

Grande quantidade de pequenos objetos:


um projeto que usa o Decorator
frequentemente resulta em sistemas
compostos por uma grande quantidade
de pequenos objetos parecidos.
Os objetos diferem somente na maneira
como so interconectados, e no nas
suas classes ou no valor de suas
variveis.
Embora esses sistemas sejam fceis de
customizar por quem os compreende,
podem ser difceis de aprender e depurar.

Faade
Inteno

Fornecer uma interface unificada para um


conjunto de interfaces em um
subsistema.

Define uma interface de nvel mais alto


que torna o subsistema mais fcil de ser
usado.

Faade
Participantes

Faade:
Conhece quais classes do subsistema so
responsveis pelo atendimento de uma
solicitao.
Delega solicitaes de clientes a objetos
apropriados do subsistema.
Classes de subsistema:
Implementam a funcionalidade do
subsistema;
Encarregam-se do trabalho atribudo a
elas pelo objeto Faade.

Faade
Estrutura

Faade
Aplicabilidade

Usa-se quando:
Deseja-se fornecer uma interface simples
para um subsistema complexo. Uma
fachada pode fornecer uma viso simples
do sistema, que boa o suficiente para a
maioria dos clientes.
Existirem muitas dependncias entre
clientes e classes de implementao de
uma abstrao.
Se desejar estruturar seus subsistemas
em camadas. Usa-se uma fachada para

Faade
Colaboraes

Os clientes se comunicam com um


subsistema atravs do envio de
solicitaes para Faade, que as repassa
para o(s) objeto(s) apropriado(s) do
subsistema.
Embora os objetos do subsistema
executem o trabalho real, a faade pode
precisar efetuar trabalho prprio para
traduzir a sua interface para as interfaces
de subsistemas.
Os clientes que usam a faade no
acessam os objetos do subsistema

Faade
Exemplo Prtico Simples

Apresentaremos um programa utilizando


o padro Faade que realize ajustes em
todos os subsistemas que sero
utilizados por um jogo de computador, ou
seja, subsistema de video, subsistema
de udio e subsistema de entrada.

Faade
Exerccio

Desenvolva um programa utilizando o


padro Faade que permita desenhar
diversas formas, tais como crculos,
quadrados e retngulos.

Faade
Consequncias
1.

2.

3.

Isola os clientes dos componentes do


subsistema, reduzindo o nmero de
objetos com que os clientes tm de lidar
e tornando o subsistema mais fcil de
usar.
Promove um acoplamento fraco entre o
subsistema e seus clientes, permitindo
variar os componentes do subsistema
sem afetar seus clientes.
No impede as aplicaes de utilizarem
as classes do subsistema caso
necessitem.

Flyweight

Inteno:

Usar compartilhamento para suportar


eficientemente grandes quantidades de
objetos de granularidade fina.

Flyweight
Participantes

Flyweight: Declara uma interface atravs


da qual flyweights podem receber e atuar
sobre estados extrnsecos.
ConcreteFlyweight: Implementa a
interface de Flyweight e acrescenta
armazenamento para estados intrnsecos,
se houver. Um objeto desse tipo deve ser
compartilhvel. Qualquer estado que ele
armazene deve ser intrnseco, ou seja,
independente do contexto do objeto
ConcreteFlyweight.

Flyweight
Participantes

UnsharedConcreteFlyweight: Nem todas


as subclasses de Flyweight necessitam
ser compartilhadas.
A interface de Flyweight habilita o
compartilhamento; ela no o fora ou o
garante.
comum para objetos desse tipo no
compartilhar objetos ConcreteFlyweight
como filhos em algum nvel da estrutura
de objetos de Flyweight.

Flyweight
Participantes

FlyweightFactory: Cria e gerencia objetos


flyweight;
Garante que os flyweights sejam
compartilhados apropriadamente.
Quando um cliente solicita um flyweight,
um objeto FlyweightFactory fornece uma
instncia existente ou cria uma, se
nenhuma existir.
Client: Mantm uma referncia para
flyweight(s); Computa ou armazena o
estado extrnseco do flyweight(s).

Flyweight
Estrutura

Flyweight
Aplicabilidade

Aplica-se quando estas condies forem


verdadeiras:

Uma aplicao utiliza um grande nmero


de objetos;
Os custos de armazenamento so altos
devido grande quantidade de objetos;
A maioria dos estados de objetos pode
ser tornada extrnseca;

Flyweight
Aplicabilidade

Muitos grupos de objetos podem ser


substitudos por relativamente poucos
objetos compartilhados, uma vez que
estados extrnsecos so removidos;
A aplicao no depende da identidade
dos objetos. Uma vez que objetos
Flyweights podem ser compartilhados,
testes de identidade produziro o valor
verdadeiro para objetos conceitualmente
distintos.

Flyweight
Colaboraes

O estado que um flyweight necessita


para funcionar deve ser caracterizado
como intrnseco ou como extrnseco.
Um estado intrnseco armazenado no
objeto ConcreteFlyweight;
Um estado extrnseco armazenado ou
computado por objetos Client.
Os clientes passam este estado para o
Flyweight quando invocam suas
operaes.

Flyweight
Colaboraes

Os clientes no deveriam instanciar


ConcreteFlyweights diretamente.

Eles devem obter objetos


ConcreteFlyweight exclusivamente do
objeto FlyweightFactory para garantir que
sejam compartilhados de forma
apropriada.

Flyweight
Exemplo

No desenvolvimento de jogos so
utilizadas vrias imagens. Elas
representam as entidades que compe o
jogo, por exemplo, cenrios, jogadores,
inimigos, entre outros.
Ao criar classes que representam estas
entidades, necessrio vincular a elas
um conjunto de imagens, que
representam as animaes.
Para evitar duplicao de informao
vamos aplicar o padro Flyweight nesse
problema.

Flyweight
Exemplo

Flyweight
Exerccio

Desenvolva um programa onde seja


aplicado o padro Flyweight em uma
casa de chs, onde os clientes de cada
mesa solicitam chs de determinados
sabores. Ao final apresentar todos os
pedidos de ch por cada mesa e o total
geral de sabores pedidos.

Flyweight
Exerccio

Flyweight
Consequncias

Pode introduzir custos de tempo de


execuo associados com a
transferncia, procura e/ou computao
de estados extrnsecos.

Tais custos so compensados pelas


economias de espao, as quais
aumentam medida que mais flyweights
so compartilhados.

Flyweight
Consequncias

As economias de armazenamento so
uma funo de vrios fatores:

A reduo do nmero total de instncias


obtida com o compartilhamento;
A quantidade de estados intrnsecos por
objeto;
Se o estado extrnseco computado ou
armazenado.

Flyweight
Consequncias

Quanto mais flyweights so


compartilhados, maior a economia de
armazenagem. A economia aumenta com
a quantidade de estados compartilhados.

As maiores economias ocorrem quando


os objetos usam quantidades
substanciais tanto de estados intrnsecos
como de estados extrnsecos, e os
estados extrnsecos podem ser melhor
computados do que armazenados.

Flyweight
Consequncias

O compartilhamento reduz o custo dos


estados intrnsecos e se troca estados
extrnsecos por tempo de computao.

Proxy

Inteno:

Fornece um substituto ou marcador da


localizao de outro objeto para controlar
o acesso a esse objeto.

Proxy
Participantes

Proxy:
Mantm uma referncia que permite ao
proxy acessar o objeto real (real subject).
O proxy pode referenciar um Subject se
as interfaces de RealSubject e Subject
forem as mesmas.
Fornece uma interface idntica a de
Subject, de modo que o proxy possa
substituir o objeto real.
Controla o acesso ao objeto real e pode
ser responsvel pela sua criao e

Proxy
Participantes

Outras responsabilidades dependem do


tipo de Proxy:
Remote proxies so responsveis pela
codificao de uma solicitao e de seus
argumentos, bem como pelo envio da
solicitao codificada para o objeto real
num espao de endereamento diferente;
Virtual proxies podem manter
informaes adicionais sobre o objeto
real, de maneira que possam postergar o
acesso ao mesmo.

Proxy
Participantes

Protection proxies verificam se quem


chama tem as permisses de acesso
requeridas para executar uma consulta.
Subject:
Define uma interface comum para
RealSubject e Proxy, de maneira que um
Proxy possa ser usado em qualquer lugar
em que um RealSubject esperado.
RealSubject:
Define o objeto real que o proxy
representa.

Proxy
Estrutura

Proxy
Colaboraes

Dependendo do seu tipo, Proxy repassa


solicitaes para RealSubject quando
apropriado.

Proxy
Aplicabilidade

aplicvel sempre que h necessidade


de uma referncia mais verstil ou
sofisticada, do que um simples apontador
para um objeto.

Proxy
Exemplo Prtico

Apresentaremos um programa para um


banco que faz uma conexo com o banco
de dados para pegar algumas
informaes relativas aos usurios do
sistema.
Deseja-se verificar se um usurio possui
ou no permisso para visualizar as
informaes do banco.
Iremos utilizar uma classe para verificar
se o usurio possui permisso de acesso
e s ento exibir as informaes do
banco. Vamos mostrar esta soluo

Proxy
Exemplo Prtico

Proxy
Exerccio

Desenvolva um programa utilizando o


padro Proxy, onde haja uma pasta em
que se possa realizar operaes como ler,
alterar e excluir arquivos.

Porm somente usurios autorizados


podem realizar essas operaes.

Proxy
Exerccio

Proxy
Consequncias

1.

2.

3.

Introduz um nvelde referncia indireta no


acesso a um objeto. A referncia indireta
adicional tem muitos usos, dependendo
do tipo
Um proxy remoto pode ocultar o fato de
que um objeto reside num espao de
endereamento diferente.
Um proxy virtual pode executar
otimizaes, como a criao de um
objeto sob demanda.
Proxies de proteo permitem tarefas

Padres
Comportamentais

Preocupam-se com algoritmos e a


atribuio de responsabilidades entre
objetos.
No descrevem apenas padres de
objetos ou classes, mas tambm os
padres de comunicao entre eles.
Caracterizam fluxos de controle difceis
de seguir em tempo de execuo.
Afastam o foco do fluxo de controle para
permitir que se concentre somente na
maneira como os objetos so

Padres
Comportamentais

Os padres comportamentais de classe


utilizam a herana para distribuir o
comportamento entre classes.

Os padres comportamentais de objetos


utilizam a composio de objetos em vez
da herana.

Chain of Responsability

Inteno:

Evitar o acoplamento do remetente de


uma solicitao ao seu receptor, ao dar a
mais de um objeto a oportunidade de
tratar a solicitao.

Encadear os objetos receptores,


passando a solicitao ao longo da
cadeia at que um objeto a trate.

Chain of Responsability
Aplicabilidade

Utiliza-se quando:
Mais de um objeto pode tratar uma
solicitao e o objeto que a tratar no
for conhecido antes. O objeto que trata a
solicitao deve ser escolhido
automaticamente;
Se deseja emitir uma solicitao para um
dentre vrios objetos, sem especificar
explicitamente o receptor.
O conjunto de objetos que pode tratar
uma solicitao deveria ser especificado

Chain of Responsability
Participantes

Handler:
Define uma interface para tratar
solicitaes.
Implementa o link ao sucessor (opcional).
ConcreteHandler:
Trata de solicitaes pelas quais
responsvel.
Pode acessar seu sucessor.
O ConcreteHandler trata a solicitao se
puder, caso contrrio, a repassa para o
sucessor.

Chain of Responsability
Estrutura

Chain of Responsability
Colaboraes

Quando um cliente emite uma


solicitao, esta se propaga ao longo da
cadeia at que um objeto
ConcreteHandler assume a
responsabilidade de trat-la.

Chain of Responsability
Exemplo Prtico

Vamos aplicar o padro Chain of


Responsability em uma aplicao de ecommerce que precisa se comunicar com
vrios bancos diferentes para fornecer
aos seus usurios mais possibilidades de
pagamentos, atingindo assim um nmero
maior de usurios e facilitando suas
vidas.

Chain of Responsability
Exemplo Prtico

Chain of Responsability
Exerccio

Desenvolva um programa de caixa


eletrnico usando o padro Chain of
Responsability que possua trs cofres,
um para notas de 50, outro para notas de
20 e um para notas de 10.
O programa deve solicitar a quantidade a
sacar ao usurio, que deve ser mltipla
de 10. Se o usurio digitar 0, o programa
encerra.
O programa deve ficar em um lao,
sacando o valor em notas de 50, at isso
no ser mais possvel, passando para as

Chain of Responsability
Exerccio

Chain of Responsability
Consequncias
1.

Acoplamento reduzido: Libera um objeto


de saber qual objeto trata de uma
solicitao. Um objeto s precisa saber
que uma solicitao ser tratada
apropriadamente. O receptor e o
remetente no tm conhecimento um do
outro, e um objeto que est na cadeia
no necessita conhecer a estrutura da
mesma.
Pode simplificar as interconexes de
objetos. Ao invs de manterem
referncias para todos os receptores-

Chain of Responsability
Consequncias
2.

Flexibilidade adicional na atribuio de


responsabilidades a objetos: possvel
acrescentar ou mudar responsabilidades
para o tratamento de uma solicitao
pelo acrscimo ou mudana da cadeia
para o tratamento de uma solicitao
pelo acrscimo ou mudana da cadeia
em tempo de execuo.
Pode-se combinar isto com subclasses
para especializar estaticamente os
manipuladores (handlers).

Chain of Responsability
Consequncias
3.

A recepo no garantida: Uma vez


que uma solicitao no tem um
receptor explcito, no h garantia de
que ela ser tratada a solicitao pode
sair pelo final da cadeia sem ter sido
tratada.
Uma solicitao tambm pode no ser
tratada quando a cadeia no est
configurada apropriadamente.

Command

Inteno:

Encapsular uma solicitao, como um


objeto, desta forma permitindo
parametrizar clientes com diferentes
solicitaes, enfileirar ou fazer o registro
(log) de solicitaes e suportar operaes
que podem ser desfeitas.

Command
Participantes

Command: Declara uma interface para a


execuo de uma operao.
ConcreteCommand:
Define uma vinculao entre um objeto
Receiver e uma ao;
Implementa Execute atravs da
invocao da(s) operao(es)
correspondente(s) no Receiver.
Client: Cria um objeto ConcreteCommand
e estabelece o seu receptor.

Command
Participantes

Invoker:
Solicita ao Command a execuo da
solicitao.
Receiver:
Sabe como executar as operaes
associadas a uma solicitao. Qualquer
classe pode funcionar como um Receiver.

Command
Estrutura

Command
Colaboraes

O cliente cria um objeto


ConcreteCommand e especifica o seu
receptor.
Um objeto Invoker armazena o objeto
ConcreteCommand.
O Invoker emite uma solicitao
chamando Execute no Command.
Quando se deseja que os comandos
possam ser desfeitos, ConcreteCommand
armazena estados para desfazer o
comando antes de invocar Execute.

Aplicabilidade
Usa-se quando se deseja:

Parametrizar objetos por uma ao a ser


executada.
Especificar, enfileirar e executar
solicitaes em tempos diferentes. Um
objeto Command pode ter um tempo de
vida independente da solicitao original.
Se o receptor de uma solicitao pode ser
representado de uma maneira
independente do espao de
endereamento, ento pode-se transferir
um objeto command para um processo
diferente e l atender a solicitao.

Aplicabilidade
Usa-se quando se deseja:

Suportar desfazer operaes:

A operao Execute, de Command, pode


armazenar estados para reverter seus
efeitos no prprio comando. A interface
de Command deve ter acrescentada uma
operao Unexecute, que reverte os
efeitos de uma chamada anterior de
Execute.

Command
Consequncias

Desacopla o objeto que invoca a


operao daquele que sabe como
execut-la.
Commands so objetos de primeira
classe, ou seja, podem ser manipulados e
estendidos como qualquer outro objeto.
Pode-se montar comandos para formar
um comando composto.
fcil acrescentar novos Commands
porque no preciso mudar as classes
existentes.

Command
Exemplo

Uma loja oferece vrias formas de


pagamento.

Ao executar uma compra o sistema deve


registrar o valor total e, dada uma forma
de pagamento, por exemplo, carto de
crdito, emitir o valor total da compra
para o carto de crdito do cliente.

Iremos implementar este programa por


meio do padro Command.

Command
Exemplo

Command
Exerccio

Implemente um programa que simule um


sistema de arquivo com os mtodos
abrir, gravar e fechar arquivos. O
programa deve suportar mltiplos
sistemas operacionais, como Windows e
Unix.

Command
Exerccio

Você também pode gostar