Padroes de projeto

Ementa

Aula 1 Ementa e Disicusses iniciais. Reviso (classes, objetos, Diagrama de classes, doagrama de

sequencias).

Aula 2 Estilos arquiteturais. Fluxo de dados (sequencial e batch), call/return (camadas/mvc,

bibliotecas, frameworks e componentes), processos de comunicao (cliente-servidor, P2P), repositorio

de dados (black board e SGBD) e mquinas virtuais (interpretadores e sistemas baseados em regras)

Aula 3 Introduo aos Padres de projeto. Importncia. Viso particular a manifestao dos catlogos

diversos. Introduo ao padro GOF.

Aula 4 Padres de Criao (Abstract Factory, Builder, Factory Method).

Aula 5 Padres de Criao (Protoype, Singleton). Padres estruturais (Adapter, Brigde e Composite).

Aula 6 Padres Estruturais (Decorator, Facade, Flyweight, Proxy).

Aula 7 Padres Comportamentais (Chain of Responsibility, Command). Reviso.

AV1 (8 pts). Entrega da lista de exerccios 1 (2 pts).

Aula 8 Correo da AV1.

Aula 9 Padres Comportamentais (Interpreter, iterator e mediator).

Aula 10 Padres Comportamentais (Memento, Observer, State)

Aula 11 Padres Comportamentais (Strategy, template method e visitor)

Aula 12 Introduo aos Padres Grasp.

Aula 13 Padro Criador, controlador, acoplamento fraco e coeso alta.

Aula 14 Polimorfismo, Inverso pura.

Aula 15 Indireo, varies protegidas.

AV2 (8 pts). Entrega da atividade estruturada (2 pts - individual)

Aula 16 Correo da AV2

AV3 (10 pts)

Bibliografia Padres de projeto Erich gamma et al.

31/07/2013

Reviso O.O.

Os sistemas de implementao atuais procuram seguir um paradigma de implementao que d nfase

ao encapsulamento de atributos e operaes. Tais propriedades so consubstanciadas em um objeto,

descritor de uma instncia de uma classe e suas associaes.

A principal ferramenta para representao das classes e objetos se d atravs da UML. A Unified

Modeling Language (UML) permite no s a modelagem de aspectos do domnio do sistema, mas

tambm de mapear um projeto sob o ponto de vista computacional. Na UML, representamos uma

classe da seguinte maneira:

Os atributos e operaes privadas indicam que no possvel o acesso aos valores por parte de outros

objetos. Os atributos e operaes protegidas permitem o acesso aos valores se e somente se os objetos

forem de Classes Filhas*. Por fim, os atributos e operaes pblicos podem ser acessados por quaisquer

objetos.

As classes podem ser abstratas (), o que indicam que no podem ser instanciadas. So

geralmente utilizadas em taxonomias (Heranas).

Por vezes a herana restringe o uso de aplicaes devido a sua necessidade de criar vnculos fortes entre

as classes. Em uma gama de sistemas precisamos especificar contratos, consubstanciados atravs de

nome da classe

nom

- atributo privado # atributo protegido + atributo pblico - operao privada # operao protegida + operao pblica

Classe Pai

Classe Filho

opcional

interfaces. As interfaces so um conjuntos de operaes (mtodos) necessrios para adequao ou

fornecimento de um servio. Na UML assim que se representa uma interface:

Uma classe deve implementar uma interface.

Aula 2 07/08/2013

Continuao: Reviso O.O.

Na aula passada revemos o uso de classes e interfaces, alpem de truqies estritamente ligados

Linguagem de Programao. Revemos as idias de instncias de interfaces. Faamos, agora, mais alguns

experimentos.

Nome da interface

+ op 1

+ op 2

+ op 3

A

I

Op1

Nome da interface

A

+op1()

B -b1

+op2()

C -c1

+op3()

+op

Introduo s Arquiteturas de Software

Muitos profissionais da rea de T.I. rcebem o ttulo de arquiteto. Eles geralmente so profissionais com

larga experincia e se utilizam de um conjunto de solues e filosofias para construo de um projeto de

software.

Afinal, o que uma arquitetura de software? Segundo Mendes, uma arquitetura de software detimida

como um:

Conjunto de componentes de sistema, seus inter-relacionamentos, princpios e diretrizes guiando o

projeto ao longo do tempo.

Os benefcios de uma arquitetura de software est amplamente difundida sobre os elementos bsicos

de um ciclo de desenvolviment. O primeiro benefcio se refere ao controle da complexidade, pois a

decomposio em componentes permeite a atribuio de responsabilidades clares e simplificao no

reuso.

As responsabilidades e a possibilidade de reuso em arquiteturas normalmente se consubstancia em

componentes que so nomeados de acordo com a sua granularidade (Frameworks, bibliotecas,

subsistemas, etc.). Alm disso, do ponto de vista de gerncia de projetos, a decomposio decorrente

permiteuma estrutura organizacional matricial.

Aula 3 14/08/13

Estilos Arquiteturais de Software

*Grupo: Fluxo de Dados

O grupo de fluxo de dados consiste em um conjunto de estilos que determinam de forma de

sequencialmente dos dados no sistema.

-Batch

Neste estilo, os passos do processamento so independentes logicamente, mas possuem uma ordem

explcita. Cada passo roda um por vez, de modo que a sada de uma seja a entrada para outro processo,

exceto pelo 1 e o ltimo passo.

- Pipes and Filters

VALIDAR ORDERNAR ATUALIZAR

Fluxo de

dados

Pipes

Processa

Filter

Neste estil, o fluxo linear de dados passa pela entrada do componente filter, submete-se ao

processamento e enciado para sada. Esta, por sua vez, envia o resultado por meio de uma tubulao

(Pipe) para outro n.

*Grupo: Call/Return

-MVC (Model/ View/ Controller) (ou camadas)

Muitas aplicaes necessitam que haja uma separao entre o modelo de negcio e as funes de

interesse e de controle.

Neste estilo, as camadas so necessariamente obrigadas a manter qualquer tipo de interface apenas

com as suas vizinhas mais prximas. Genericamente, so chamadas de arquiteturas de camadas, mas

tiveram seu conceito atrelado ultimamente aplicaes comerciais voltadas para internet.

Camada 1

Camada 2

Camada 3

Camada N

No mbito da internet, a idia da separao de camadas relativa ao baixo acoplamento entre a

interface de visualizalao (view), as classes de controle (controller) e as classes de domnio (Model).

De certa forma, o MVC est presente em outros estilos arquiteturais, causando uma certa discordncia

entre a literatura.

O estilo em camadas um dos mais utilizados atualmente, estando presente em aplicaes de diversos

tipos, tal qual o conhecido TCP/IP.

- Frameworks/Componentes/Bibliotecas

Uma das grandes metas a serem alcanadas no desenvolvimento de um sistema a REUSABILIDADE. O

agrupamento de uma parte do software como uma caixa que possui uma entrada e uma sida tem sido

a maneira como elementos comuns do sustema so reaproveitados.

As caixas que estses estilos arquiteturais se referem esto classificadas quanto ao nvel de detalhamento

que elas oferecem.

- Caixa Branca: todo cdigo a ser reutilizado est disponvel para visualizao. Geralmente necessita que

o desenvolvedor tenha algum domnio do cdigo a ser reutilizado.

- Caixa Preta: todo cdigo est oculto para o desenvolvedor. Existe apenas um conjunto de operaes a

serem realizadas dada as respostas esperadas.

- Caixa Cinza: Exige algum conhecimento do desenvolvedor, mas pode ser usado de uma forma

degradada caso necessrio.

Caixa Branca

Cdigo

particular

E Caixa Preta

S S E

Caixa Cinza S

Cdigo

particular

E

E

As bibliotecas so geralmente produzidas como uma caixa preta, de modo que as operaes comuns

possam ser importadas em qualquer instante por programas distintos. Os componentes diferem das

bibliotecas em suas granularidade. Geralmente esto associados requisitos e possuem uma ou mais

bibliotecas inter-conectadas. Alguns componentes, principalmente os softwares-livres, so caixas

brancas em funo de seus objetivos. Os frameworks so caixas cinzas. Constituem um arcabouo bsico

para construo de sistemas, fornecendo os cdigos bases que precisam de ajustes para o domnio de

trabalho.

Grupo: Comunicao

- Sistema cliente-servidor

Este estilo arquitetural define papeis de comunicao entre processos (programas).

Se diz que um processo cliente se este for requisies a um servidor.

Na arquitetura cliente-servidor estabelecido um protocolo de comunicao. Se diz que o cliente

gordo e um servidor magro quando a maioria do processamento reside no cliente. No contrrio, se diz

que um servidor gordo e o cliente magro.

Uma das vantagens associadas a este estilo est ao baixo acoplamento de processamento. Em contra-

partido, os gargalos decorrentes de um possvel nmero maior de clientes incorre em falhas estruturais

e problemas de escalabilidade.

-P2P (peer-to-peer)

Neste estilo cada participante possui autonomia de processamento, ** uma clara independncia. Os

servios e requisio podem continuar operando, mesmo com uma baixa:

O principal ponto negativo desta abordagem reside na manuteno de possveis conseqncias entre os

ns.

Estilos Arquiteturais (continuao)

Grupo: Mquinas Virtuais

- Interpretadores: os interpretadores consistem em uma camada de abstrao independente. So muito

comuns em mquinas virtuais. Nesse contexto, os softwares compilados executam por meio de

chamadas a interfaces. A camada de abstrao funciona como um meio de campo entre o hospedeiro

e o cliente.

Cliente Servidor

N N

N N

- Sistemas baseados em regras: Estilo arquitetural que determina um conjunto de regras, geralmente

em uma lgica proposicional, objetivando a inferncia sobre um determinado conjunto de fatos. So

consideradas mquinas virtuais uma vez que as regras sao independentes do software, cdigo ou

sistema hospedeiro.

- Blackboard: este estilo arquitetural consiste em um repositrio para gravao e consulta por software

clientes. No h, nesta abordagem, um sequenciamento relativo ao uso do repositrio.

- Banco de Dados: Tambm consiste em um repositrio compartilhado, mas pode eventualmente

possuir um grau de distribuio. Difere do BlackBoard pois necessita de sincronizao explcita.

Introduo aos Padres de Projeto

Padres de projeto nada mais so que uma coletnia de solues propostas e utilizadas por diversos

profissionais desde a dcada de 60.

Os padres de projeto resolvem problemas especficos, tornando, tambm, o projeto orientado objeto

mais flexvel, reutilizvel e escalvel.

Para Alexander, cada padro descreve um problema no nosso ambiente e o cerne da sua soluo, de

tal forma que voc possa usar essa soluo mais de um milho de vezes, sem nunca faz-lo da mesma

maneira.

Entrada Sada

Software 1

interpretador

Software N

hospedeiro

Regra 1

Regra 2

Regra 3

Menria de

trabalho

Mquina de

inferncia

Ap4 Ap1

Ap2 Ap3

Cliente 1 Cliente N

Base de Dados

importante ressaltar que os Padres GOF (Gang of Four) dos autores Gamma et al., principal objeto de

nosso estudo, do diretrizes de como solucionar o problema, mas no consistem em uma receita de

bolo imutvel. Em geral, um padro de projeto tem os seguintes aspectos: nome, problema, soluo e

conseqncias.

Apesar de adotarmos a Orientao Objeto como mecanismo de explicitao dos padres, no h nada

que impea o uso em linguagens aderentes a outros paradigmas.

Gamma et al. define que a melhor poltica de programao para consubstanciao dos Padres reside

no que ele chama de Programao para interfaces

Existe um benefcio claro:

*Os clientes (objetos) no conhecem tipos especficos, apenas interfaces e classes abstratas.

Como selecionar um padro?

Depois de entendido e modelado o domnio, procure destacar que arquitetura voc julga ser

pertinentes para o domnio da aplicao.

O projetista de sistema deve estudar como os padres se relacionam. importante que os padres

sejam consideradas quanto as suas afividades.

-Padro Abstract Factory (Fbrica Abstrata)

A inteno deste padro fornecer uma fbrica de objetos sem que os clientes conheam

efetivamente as classes concretas.

Considere aplicar o padro Abstract Factory quando um sistema deve ser independente de como os seus

produtos so criados ou representados. especialmente vlido quando se deseja criar uma famlia de

produtos.

*void meramente ilustrativo.

Conseqncias do Abstract Factory

- isola classes concretas;

- troca de famlia de produtos;

- Promove harmonia entre produtos;

- difcil suportar novos tipos;

Padro de Projeto Builder

O objetivo do padro de projeto builder promover o desacoplamento durante a construo de objetos

complexos.

O padro builder utilizado quando desejamos especificar um algoritmo para criao de um objeto

complexo de forma independentes das partes que o compe.

Director: para todos os objetos buildPart()

Conseqncias

- Permite variar a representao interna de um produto;

- isola o cdigo para construo e representao;

- Oferece um controle mais fina sobre a construo de um produto;

Padro de Projeto Factory Method

O principal objetivo do padro factory method est relacionado ao fornecimento de um guia para

postergao da criao de objetos por parte das classes filhas.

O padro Factory Method comumente usado para definirmos um Framework. Desejamos que os

clientes do Framework decidam a melhor maneira de us-lo. Este padro geralmente utilizado quando

uma classe no pode antecipar quais os objetos devem ser criados.

As classes filhas de um cliente devero armazenar o conhecimento sobre a construo do objeto.

Conseqncias

Fornece ganchos para subclasses;

Conecta hierarquias de classes paralelas;

Exemplo:

Padro de Projeto Prototype

O objetivo do padro Prototype estabelecer uma maneira de produzir cpias fiis de objetos. O

Prototype deve ser independente de como os produtos so criados , compostos e representados.

tambm utilizado quando as classes a instanciar forem especificadas em tempo de execuo.

Conseqncias

- Adiciona e remove produtos em tempo de execuo;

- Especifica novos objetos pela variao de valores;

- Difcil implementao do clone().

Padro de Projeto Singleton

O conceito por trs do padro de projeto Singleton reside na necessidade de se garantir a penas uma

nica instncia de uma classe. Ou seja, no permitir mais de um objeto.

A soluo reside em tornar a classe responsvel por manter esta unicidade.

Exemplo:

- Consequncias:

* Acesso controlado a instncia nica.

* Espao de nomes reduzidos.

* Variantes para controle de vrios objetivos.

Padro de Projeto Adapter

A inteno de iso do padro de projeto Adapter reside na compatibilidade de uso de frameworks e

bibliotecas com interfaces priori conflitantes ou mesmo imutveis para determinados clientes.

- Consequncias:

* Permite o Adapter substituir algum comportamento de adaptee

Singleton

Static instance()