Padrões de desenho

O ciclo de vida do software pode ser dividido em: análise, desenho, implementação, tes- tes e manutenção. Na fase de desenho, é importante focar os problemas possíveis e, numa análise profunda, identificar os padrões de desenho (design patterns) que são possíveis de utilizar. Um sistema de software surge assim com a análise e a utilização de princípios de design no Software. Estes princípios representam as directivas (guidelines) que ajudam a evitar maus desenhos de um sistema, definindo três características importantes a serem evitadas [Mar03]:

Rigidez Um sistema rígido é difícil de alterar porque essas alterações vão afectar outras partes do sistema.

Fragilidade Um sistema com fragilidade resulta em que, ao ser realizada uma alteração, inexplicavelmente o sistema pára.

Imobilidade Um sistema que apresente características de imobilidade tem dificuldade em ser transposto para outros domínios visto que não se consegue adaptar por estar demasiado dependente da aplicação corrente.

Com estas características e com a avaliação de vários sistemas, verificaram-se recor- rências em várias pontos, identificando-se 3 categorias diferentes de padrões: Padrões de desenho de criação; Padrões de desenho de comportamento; e Padrões de desenho de es- truturação. A primeira lida com os mecanismos de criação, a segunda com a identificação de padrões comuns de comunicação entre entidades e a terceira com a estruturação. Estas categorias simplificam o design identificando maneiras eficientes de realizar as relações entre as entidades.

Os padrões têm 4 elementos essenciais na sua representação: Nome (tipicamente des- creve o problema); Problema (quando o padrão deve ser aplicado); Solução (fornece uma descrição abstracta dos problemas e a maneira como geralmente os resolve); Consequên- cias (os resultados e os trade-offs que possam existir ao aplicar o padrão, normalmente em termos de espaço e tempo de execução).

Os padrões de desenho citados no livro [GHJV95], resolvem, de diferentes formas, muitos dos problemas encontrados no desenvolvimento de um programa orientado a objectos: a) encontrar os objectos apropriados para uma dada tarefa b) determinar a gra- nularidade do objecto (isto é, como vai ser construído) c) especificar as interfaces dos objectos d) ajudar a especificar como se vai implementar o objecto em si

Com o objectivo de ilustrar tipos recorrentes no desenvolvimento de sistemas dis- tribuídos, de seguida, serão apresentados alguns exemplos de padrões agrupados por categoria. Cada um é representado pelo nome, solução, problema e consequências:

• Padrões de criação

Singleton - garante que é criada uma instância da classe e fornece um ponto global

de acesso ao objecto. Padrão que deve ser usado quando devemos garantir que só uma instância da classe deve ser criada e quando essa deve ser acedida em todo o código.

Abstract Factory - oferece a interface para criar uma família de objectos relaciona-

dos, sem explicitamente especificar as suas classes. Padrão usado quando só as interfaces do produto (objectivo da classe) devem ser reveladas e a imple- mentação mantém-se escondida aos clientes e os produtos da mesma família devem ser usados todos juntos.

Builder - define uma instância para criar um objecto mas deixa as subclasses de-

cidirem qual a classe que instanciam. Permite um controlo refinado sobre o processo de construção.

Prototype - como o nome indica, específica o tipo dos objectos a criar usando uma

instância de um protótipo. Criam-se novos objectos copiando os protótipos criados através deste método.

Chain of Responsibility - permite um objecto enviar um comando sem saber que

objecto vai interpretar e gerir esse pedido. Existe uma classe que re-encaminha o pedido para o objecto respectivo.

Command - encapsula os pedidos num objecto para mais tarde serem atendidos:

permite chamar os métodos em qualquer altura, não sendo necessário saber que objecto contém o método em questão.

Observer - define a dependência de um-para-muitos entre objectos, de maneira

a que, quando um objecto muda de estado, todos os seus dependentes são notificados e alterados automaticamente.

• Padrões na estruturação

Proxy - O proxy serve como intermediário entre a fonte e as entidades. Fornece

transparência na localização, tolerância a falhas e balanceamento de carga atra- vés de cache dos objectos mais usados.

Facade - Simplifica um sistema com vários subsistemas com uma simples interface.

Este padrão também é útil quando um sistema está dividido em vários sub- sistemas, e tanto o acesso à comunicação como o ponto de entrada do sistema têm de ser restritos.

Para além dos padrões de desenho na construção de um sistema, existem estilos de ar- quitecturas possíveis de aplicar. Estilo, neste contexto, representa a classificação de uma arquitectura de um sistema de acordo com os padrões similares que existam na sua im- plementação. Muitas destas arquitecturas são usadas em sistemas distribuídos (e.g. clien- te/servidor, Peer2Peer). Sendo também, designados por padrões de arquitectura[BMR+_96], sendo estes compostos por vários padrões de desenho. Alguns exemplos possíveis de pa- drões são:

Client/Server - Os clientes fazem pedidos a um servidor o qual tem o papel de enviar a

resposta.

Peer2Peer - Cada peer é visto com um cliente e servidor ao mesmo tempo. Um peer for-

nece e pede serviços a outros peers.

Producer/Consumer - O fluxo de dados é uni-direccional, do produtor ao consumidor. Streaming - Fluxo continuo de dados ente o servidor e o cliente.

Publish/Subscriber - Um ou mais entidades subscrevem um certo interesse num evento.

Quando esse evento ocorre, os subscritores são notificados. Não é necessário estar registado no evento para receber notificação.

Parameter-Sweeper - Repetidas invocações de um componente com um único conjunto

Master-Slave - O mestre distribui tarefas a serem realizadas pelos escravos e agrega os

resultados de cada um.

Layers - ajuda a estruturar aplicações em camadas independentes, de maneira que as

mudanças numa camada não afecte as outras, ajudando assim a extensibilidade.

Pipes & Filters - Permite composição de filtros. Arquitectura ideal se existem muitas

transformações a realizar e é necessário existir flexibilidade. Em tempo real é pos- sível adicionar filtros.

Adicionalmente, a própria interacção entre serviços apresenta características recor- rentes também capturadas através do conceito de padrões.