Padroes de Projeto 1
-
Upload
jose-carlos-almeida -
Category
Documents
-
view
10 -
download
0
description
Transcript of Padroes de Projeto 1
-
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()