MAC 413/5715 - Tópicos de Programação
Orientada a
Objetos
Aula 23 - 14/06/2004
Padrões Arquiteturais (POSA I, II e III)
Pattern-Oriented Software Architecture
POSA I: A System of Patterns
POSA II: Patterns for Networked and Concurrent Objects
POSA III: Patterns for
Resource Management
Padrões Alexandrinos:
Nome
Discussão técnica: quais as
questões/forças envolvidas
PORTANTO: uma solução comum para estas
questões/forças
C. Alexander et al. A Pattern Language -
Towns.Buildings.Construction . Oxford University Press, 1977.
Exemplo: Window Place
Contexto: todos nós adoramos nos sentar
próximos a uma janela e apreciar a paisagem. Uma sala sem
janelas que podem ser apreciadas raramente nos faz sentir
confortáveis.
Problema: se uma sala contém uma janela perto da qual
não podemos sentar, uma pessoa nessa sala vai ser puxada por
duas forças antagônicas:
ela quer sentar e se sentir confortável
ela é atraída para perto da janela
Solução: obviamente, se não há um
lugar próximo à janela onde se pode sentar
confortavelmente, não há como resolver este conflito.
PORTANTO: em qualquer sala na qual as pessoas passam um certo tempo
durante o dia, faça com que pelo menos uma janela seja um lugar
para se sentar.
Diagrama.
Ao escrever um padrão, veja se você tem bem claro 3
coisas que devem estar contidas na descrição do
padrão:
Contexto: uma situação que leva a um problema
Problema: um problema recorrente que acontece em determinada
situação
Design Patterns
(Padrões de Projeto - nível médio)
Decomposição Estrutural
Whole-Part
Organização de Trabalho
Master-Slave
Controle de Acesso
Proxy
Gerenciamento
Command Processor
View Handler
Comunicação
Forward-Receiver
Client-Dispatch-Server
Publisher-Subscriber
Idioms
(Expressões idiomáticas - baixo nível)
Counted Pointer
Cartões CRC (Class, Responsibility, Collaborator)
Exemplo, padrão Camadas:
Class
Camada J
Responsibility
Provê serviços usados pela camada
J+1
Delega subtarefas para a camada J-1
Collaborator
Camada J-1
Exemplo concreto de uso do padrão:
FTP em cima de TCP em cima de IP em
cima de Ethernet em cima de cabo de par trançado.
Padrão Arquitetural para Sistemas Interativos: Model-View-Controller
Um dos primeiros padrões identificados; surgiu na
comunidade
de Smalltalk
Exemplo: eleição proporcional para deputado federal
(desenhar figura)
modelo: resultado parcial da apuração dos votos
por partido até o momento
visões: gráfico de torta, gráfico de
barras, divisão do parlamento (por partidos ou por blocos ou por
oposição/situação), tabela com
número
de deputados, tabela com número de votos
controlador: permite mudar, por exemplo, o número de
votos na tabela com o número de votos
Contexto: aplicações interativas que requerem
interfaces humano-computador flexíveis
Problema:
interfaces com o usuário são particularmente
sensíveis a mudanças (o cliente solicita
modificações com
freqüência e se o sistema não comporta as
mudanças podemos ter muita dor de cabeça).
a aplicação pode ter que ser implementada em
outra
plataforma ou ter que utilizar outra aparência (look and feel
)
a mesma aplicação possui diferentes requisitos
dependendo do usuário.
um digitador prefere uma interface onde tudo pode ser feito
através do teclado e visualizado como texto
um gerente prefere uma interface através do mouse e de
menus com visualização gráfica
neste contexto, se o código para a interface
gráfica é muito acoplado ao código da
aplicação, o desenvolvimento pode se tornar muito caro e
difícil
Solução: MVC
proposta inicialmente no Smalltalk-80, divide a
aplicação interativa em três partes:
processamento
saída
entrada
O modelo encapsula os dados e a funcionalidade principais da
aplicação.
A saída é feita através das visões.
A entrada é feita através dos controladores
Estrutura:
Diagrama de classes englobando Model, View,
Controller e Observer
FIGURA (pag. 129)
Dinâmica:
Cenário 1: mostra como a entrada de dados do
usuário altera o modelo e as visões
Cenário 2: mostra como a aplicação
é
inicializada
Implementação:
em C++, uma superclasse Observer para definir a
interface de atualização é uma boa.
em Smalltalk isso não é necessário pois,
como vimos, a
classe raiz Object já define isso (addDependent:, update:, notify:).
discute implementações mais sofisticadas, por
exemplo, usando Composite nos Views e Controllers.
Variação: Document-View
é uma degeneração do padrão onde
cada par (visão, controlador) é unido em um único
componente, a visão.
o modelo é chamado de documento.
Usos Conhecidos
Smalltalk
MFC da Microsoft do Visual C++ usa o padrão Document-View
Desacopla as visões do modelo permitindo que
múltiplas visões sejam acrescentadas e removidas em tempo
de execução
Permite a sincronização das múltiplas
visões.
Permite a mudança de aparência (look and feel
) da aplicação com pouco esforço
Pode-se implementar um arcabouço implementando este
padrão e daí o mesmo código é reaproveitado
por várias aplicações
Malefícios:
Aumento na complexidade do código da
aplicação
Pode ocorrer um número excessivo de
atualizações e, portanto, carga no sistema se tivermos
muitas visões. Se o padrão não é
implementado com cuidado podemos ter coisas como envio de
atualizações para visões que estão
minimizadas ou fora do campo de visão do usuário (por
estarem sobrepostas por outras janelas).
Dificuldade de desacoplar visão e controlador e
re-utilização independente
Tanto as visões quanto os controladores chamam o
modelo diretamente.
Mudanças na interface do modelo podem quebrar todas as
visões
e controladores. Isso pode ser solucionado usando o padrão POSA
Command
Processor (277).
Ineficiência: dependendo da interface do modelo, uma
visão pode ter que fazer inúmeras chamadas ao modelo para
mostrar os dados.
Alguns ambientes para construção de interfaces
já misturam a visão com o controlador e fazem si mesmos a
troca de mensagens entre o controlador e a visão (p.ex. pop-down-menu)
dificultando a utilização do MVC.
Referência
F. Buschmann, R. Meunier, H. Rohnert, P.Sommerlad, M. Stal Pattern-Oriented
Software Architecture - A System of Patterns. John Wiley and Sons
Ltd, Chichester, UK, 1996