CK147 - Tópicos Avançados em Sistemas de Informação Copyright © 2002-2003 Rossana AndradeSlide 1 Padrões de Software Rossana Andrade [email protected]

Copyright © 2002-2003 Rossana Andrade Slide 1

CK147 - Tópicos Avançados em Sistemas de Informação

Padrões de Software

Rossana [email protected]

Departamento de ComputaçãoUniversidade Federal do Ceará



Objetivos Gerais Oferecer uma visão geral sobre os conceitos

de padrões de software Explicar a terminologia Estimular a escrita de padrões Apresentar exemplos de padrões de software Apresentar exemplos de classificação de

padrões e de reuso de padrões

Não pretende exaurir o assunto



Parte I - Padrões de Software O que são Padrões

– Diferentes Definições– Um pouco da história

Escrevendo Padrões– Componentes de um Padrão– Um Exemplo– Padrões como uma Peça ou Estória– Diferentes Formatos

• GoF• Alexander• Coplien



O que são Padrões O que é?

– Nova categoria de conhecimento• Conhecimento não é novo, mas falar sobre ele é• Objetivo: conhecer o que você já conhece

Como?– Partindo de problemas e soluções

recorrentes em diferentes áreas do conhecimento



O que é um Padrão (Cont.) Aplicação

– Arquitetura– Ciência da Computação

• Engenharia de software– Engenharia Mecânica– Telecomunicações– ...



O que é um Padrão (Cont.) Por que padrões de software?

– engenheiros de software não iniciam o seu projeto do nada

– ao contrário, nós reutilizamos “idéias”que já vimos antes

– as mesmas técnicas são utilizadas repetitivamente

– a indústria de software necessita documentar o que nós fazemos



Diferentes Definições “Um padrão é uma entidade que

descreve um problema que ocorre repetidamente em um ambiente e então descreve a essência da solução para este problema, de tal forma que você use esta solução milhões de vezes, sem nunca utilizá-la do mesmo modo,” Christopher Alexander



Diferentes Definições (Cont.) “Um padrão é um pedaço de literatura

que descreve um problema de projeto e uma solução geral para o problema num contexto particular, ” James Coplien



Diferentes Definições (Cont.) “Um padrão é uma solução provada

para um problema em um contexto, ” Comunidade de Software



Um Pouco da História Object-Oriented (OO)

– Metade do anos 80 Padrões de software emergiram de objetos Ward Cunningham and Kent Beck

– 1987: linguagem de padrões para interface de usuário James Coplien

– 1988: idioms Erich Gamma, Richard Helm, Ralph Johnson, and

John Vlissides– 1990 1995: Padrões de projeto (Design Patterns)



Um Pouco da História Peter Coad

– Desde 1991 explora padrões The Hillside Group

– 1993: tentativa de montar as primeiras bases para padrões de software

– Idéias de Alexander integradas aos padrões de projeto da GoF

1994: The first Pattern Languages of Programming (PLoP) conference

OOPSLA’94: livro da GoF é lançado– Padrões de projeto: foco em OO



Escrevendo Padrões Escritos na forma literária Não apenas documentação Diferentes formatos

– GoF, Alexandrian, Coplien, Cockburn, Portland Componentes essenciais

– nome, contexto, problema, solução e usos conhecidos

Outros componentes importantes– forças, contexto resultante, padrões

relacionados, autor e data



Componentes Essenciais de um Padrão Nome

– Uma palavra ou uma frase curta– É a primeira coisa que o projetista encontra

quando procura uma solução– Nomes de padrões devem se tornar parte do

vocabulário do domínio– Iniciantes procuram nomes que descrevem o

problema ou sua solução– Os nomes do padrões da GoF são analogias

• Bridge, facade, mediator, entre outros



Componentes Essenciais de um Padrão (Cont.) Contexto

– Quando considerar o padrão– Ajuda a ter uma visão abrangente de onde o

problema surge expressando o seu início, a sua essência e o seu corpo

– É difícil escrever um bom contexto– Inclui um histórico dos padrões que têm sido

aplicados antes• aplicável às linguagens de padrões)



Componentes Essenciais de um Padrão (Cont.) Problema

– Quando utilizar o padrão– Problema a ser resolvido descrito claramente– Expresso por uma simples pergunta ou por uma

formulação resumida do problema– Geralmente a primeira coisa que um procurador-

por-solução observa– Um entendimento do problema vem da análise das

forças



Componentes Essenciais de um Padrão (Cont.) Solução

– O que fazer para resolver o problema• Deve descrever claramente o que é necessário para

resolver o problema

– Três tipos• Uma solução que pode ser usada para todas as

ocorrências do problema• Uma solução que pode ser melhorada• E uma solução que vai ser refinada nos níveis de projeto

e implementação de diferentes formas



Componentes Essenciais de um Padrão (Cont.) Usos Conhecidos

– Exemplos de aplicações do padrão em sistemas reais

– Pelo menos 3 usos conhecidos• Regra de 3



Outros Componentes Importantes de um Padrão Forças

– O padrão é um balanço de forças/conseqüências

– Considerações positivas ou negativas a serem avaliadas a fim de

• mostrar que a solução apresentada é a melhor• mostrar por que a solução mais óbvia é errada• mostrar porque o problema é difícil de se

resolver



Outros Componentes Importantes de um Padrão (Cont.) Contexto Resultante

– É a conclusão do padrão– O estado ou a configuração do sistema

depois da aplicação do padrão, incluindo as consequências (boas e ruins)

– O contexto resultante de um padrão é a entrada para os padrões seguintes

• Aplicável para linguagens de padrões



Outros Componentes Importantes de um Padrão (Cont.) Padrões Relacionados

– Como o padrão está relacionado com outros padrões que se referem ao mesmo problema

– Com que outros padrões este pode ser usado



Um exemplo

Hands in View Contexto

– Para explorar uma montanha inteira, um esquiador deve estar confortável e adaptável a qualquer terreno e a uma rápida mudança de terreno

– Para aproveitar melhor este padrão, o esquiador deve estar esquiando em um nível onde curvas em paralelo possam ser ligadas consistentemente



Hands in View (Cont.) Problema

– O esquiador falha ao tentar a descida na montanha em declínios profundos e irregulares, resultando em escorregões, quedas de costas e “yard sales”

Forças– Medo de cair é a resposta mais básica de todas– Confiança no equipamento é essencial– Movimento contínuo é essencial– Fatiga pode ser um fator em descidas longas– Descida de compromisso com os esquis é essencial para

que os esquis funcionem como projetados



Hands in View (Cont.) Solução

– Concentre-se em manter as mãos no campo de visão – Traga-as para dentro do seu campo de visão imediatamente

depois de cada bastão tocar o chão e de cada curva Contexto resultante

– Ao colocar as mãos à vista, o alinhamento do corpo muda do estado de ficar timidamente para trás e permite que as extremidades do esqui deslizem debaixo do esquiador

– Portanto, o ato de colocar as mãos à vista puxa o corpo para a frente e, conseqüentemente, para baixo da montanha, trazendo o peso do esquiador sobre o esqui montanha abaixo e forçando a extremidade a morder e girar



Hands in View (Cont.) Motivação

– A tendência natural de todo ser humano normal é manter a coluna reta ou em caso de queda eminente, inclinar-se para trás

– Isto provoca quedas e curvas indesejadas quando esquiando– As conseqüências podem ser claramente entendidas, mas o

medo previne que você se incline para frente.– Entretanto, deixando as suas mãos no campo de visão, os esquis

devem deslizar mais facilmente sem que você tenha que confrontar o medo diretamente

Autor– Don Olson 95/07/07

Origem– Instrutor de esqui anônimo em algum lugar de Utah.



Padrões como uma peça ou estória Analogia de Robert Hanmer

– Contexto: o cenário– Problema: o tema– Forças: desenvolvendo o conflito– Solução: catarse, a moral da peça– Contexto Resultante: “eles viveram felizes para

sempre” ou deixando espaço para a seqüência– Motivação: a discussão no bar ou no café depois

da peça



Formato da Gang of Four - GoF Nome do Padrão e Classificação

– Analogias– Padrões de criação, de estrutura e de comportamento

Intenção– Breve descrição do problema e da solução

Também Conhecido Como Motivação

– Exemplo de protótipo Aplicabilidade

– Problema, forças e contexto



Formato da Gang of Four – GoF (Cont.)

Estrutura Participantes Colaborações Conseqüências

– forças Implementação Código Exemplo Usos Conhecidos Padrões relacionados

Solução

Solução



Formato Alexandrian As seções não são fortemente

delimitadas– Podemos identificar determinados

componentes em todos os padrões Uma figura no início Um parágrafo introdutório

– contexto



Formato Alexandrian (Cont.) 3 diamantes no início e no fim da explicação

do problema e da solução– a palavra “therefore:”, imediatamente depois a

solução– Uma sentença clara do problema, uma discussão

de forças, a solução e a motivação– Um diagrama mostrando a solução

No final, um parágrafo relacionando o padrão dentro da linguagem



Formato do Coplien Nome Contexto Problema Forças Solução Sketch

– Desenhos ou Diagramas Contexto Resultante Rationale

– Mostra por que o padrão é útil– Mostra a importância dos princípios atrás dos padrões



Parte II: Como Escrever um Padrão

O Processo de Escrita Padrões Padrões trabalhando em Conjunto

– O que são Linguagens de Padrões– Exemplos de Linguagens de Padrões

• Artigo do Gerard Meszaros e do Jim Doble

– “A Pattern Language for Pattern Writing”



Próximos Slides O Processo de Escrita de Padrões

– Características de um bom Padrão– Um Exemplo de um bom Padrão– Padrões bem Escritos– O que não é um Padrão

• Exemplo• Dicas

– Padrões trabalhando em conjunto • O que são Linguagem de Padrões• Um exemplo

– Guia para Escrita de Padrões• Sete Hábitos para Escritores Efetivos de Padrões• Mais Dicas para Escrever Padrões



Características de um bom padrão Deve ser uma solução para um problema em um

contexto Você deve ser capaz de dizer ao solucionador do

problema o que fazer e como resolver o problema Deve ser maduro, uma solução provada (regra de

três) A solução deve ser construída dentro da ótica do

solucionador do problema e pode ser implementada milhões de vezes sem se repetir

Deve ser capaz de se reproduzir (padrões que constroem)



Um Exemplo de um bom PadrãoNome: Half-Object + Protocol (HOPP)Problema: Às vezes um objeto deve aparecer

em mais de um espaço de endereçamento. Como nós podemos fazer a diferença entre um espaço e múltiplos espaços de endereçamento de forma transparente?

Forças: Complexidade, Distribuição, Disponibilidade de Informação, Custo e Performance



Um Exemplo de um bom Padrão (Cont.)Solução

– Divida o objeto em dois objetos-metade, um em cada espaço de endereçamento, com um protocolo entre eles

– Em cada espaço de endereçamento, implemente a funcionalidade para interagir eficientemente com os outros objetos naquele espaço de endereçamento (isto pode resultar em funcionalidade duplicada, ou seja, funções implementadas em ambos espaços de endereçamento)



Um Exemplo de um bom Padrão (Cont.)Solução (Cont.)

– Defina o protocolo entre os dois objetos-metade de tal forma que ele coordene as atividades dos dois objetos-metade e carregue a informação essencial que necessita ser passada entre os espaços de endereçamento



Um Exemplo de um bom Padrão (Cont.)

Diagrama UML para uma aplicação de FTP

Sketch



Um Exemplo de um bom Padrão (Cont.)

Diagrama FTP com a aplicação do HOPP

Sketch



Um Exemplo de um bom Padrão (Cont.)Usos Conhecidos

– Sistemas de Telefonia: half-call– IBM’s VisualAge Ultra Light Client

• http://www.software.ibm.com/ad/smalltalk/about/ulcfact.html

Padrões Relacionados – padrões para o projeto de protocolos

• Message as Object, Message Parameter as Object• Mecanismos para tratar a criação e recepção da

mensagem– Information collection e Formatting– Parsing e Handling

http://www.software.ibm.com/ad/smalltalk/about/ulcfact.html











Padrões bem Escritos Pequenos Contam uma história Um processo e uma coisa Levam em consideração a estética Têm um elemento humano explícito Uma sentença em uma linguagem de

padrões



O que não é um padrão: Exemplo Contexto

– Um grande sistema OO em um computador com memória virtual

Problema– Como você aloca objetos na memória?

Solução– Execute alguns problemas típicos e descubra

quais objetos comunicam-se freqüentemente em um determinado tempo local e coloque-os na mesma página



O que não é um Padrão: Dicas Um regra simples Uma receita Um algoritmo Uma estrutura de dados Uma solução isolada para um problema

em um contexto



Grande Círculo



Próximos Slides Padrões trabalhando em Conjunto

– O que são Linguagens de Padrões– Exemplos de Linguagens de Padrões

• Linguagem de Padrões by C. Alexander Guia para a escrita de padrões

– Exemplo deLinguagem de Padrões • Linguagem de Padrões para Escrita de

Padrões por Gerard Meszaros e Jim Doble



Padrões Trabalhando em Conjunto Padrões freqüentemente compartilham o

mesmo contexto Problemas produzidos por um padrão são

algumas vezes resolvidos por outros Um projeto complexo consiste de muitos

padrões– Catálogo de padrões– Linguagens de Padrões



O que são Linguagens de Padrões “Uma coleção de padrões que

trabalham juntos para resolver problemas num domínio específico”, Linda Rising

“Uma linguagem de padrões é uma coleção de padrões que ampliam-se para gerar um sistema”



O que são Linguagens de Padrões? (Cont.) Cada padrão é uma seqüência dentro da

linguagem de padrões O formato dos padrões formam um grafo Cada padrão produz um contexto para

aqueles que o seguem Cada padrão deve construir sobre o contexto

daqueles que vêm antes dele Existem muitos caminhos válidos dentro de

uma linguagem de padrões



Um Exemplo de uma Linguagem de Padrões

Half-Hidden Garden

Garden growing wild Courtyards which live

Entrance TransitionTree Places

Terraced Slope

Fruit Tree

Building Edge

Private Terrace on the Street

By C. Alexander



Guia para Escrita de Padrões Decisão

– De colocar no papel um problema recorrente e sua respectiva solução em um determinado domínio

Captura– Do problema e da solução dentro do domínio

Busca– Entre padrões existentes para determinar se o padrão é

novo ou pode ser uma melhoria de um padrão existente Escrita

– De um novo padrão ou re-escrita de um padrão já existente



Guia para Escrita de Padrões (Cont.)

Sete Hábitos para Escritores Efetivos de Padrões – Hábito 1: Deixe um tempo para refletir– Hábito 2: Escolha uma estrutura/formato– Hábito 3: Seja concreto desde cedo– Hábito 4: Tente escrever padrões distintos e

complementares– Hábito 5: Apresente os padrões efetivamente– Hábito 6: Prossiga em uma iteração incansável– Hábito 7: Colecione e Incorpore Feedback



Decisão e Captura Alternativa 1: Hábitos 1 e 3

– Como específicos problemas foram resolvidos durante a construção de um sistema

• O projetista deve gravar essas experiências e o modo como as resolveu

• O projetista deve investigar como outros sistemas semelhantes foram construídos por outros projetistas

• O projetista deve tentar encontrar pelo menos 2 exemplos dos mesmos problemas e soluções antes de tentar escrever o padrão



Decisão e Captura (Cont.) Alternativa 2

– Investigação de problemas de projeto em sistemas de um domínio específico que não foram desenvolvidos pelo escritor de padrões

• Procedimento de captura• Regra de 3 dos usos conhecidos



Busca Exaustiva em uma grande quantidade de

padrões já disponíveis eletronicamente e/ou em livros– The Pattern Almanac 2000

Padrões relacionados se o padrão é novo Modificação em padrão existente

– Antes o escritor de padrões deve saber a razão para reescrevê-lo e o que deve ser alterado



Escrita e Reescrita de padrões Uma linguagem de padrões para a

escrita de padrões– Estabelecendo o Contexto

• Estrutura do Padrão• Legibilidade• Estrutura da Linguagem de Padrão



Context Setting Patterns

Pattern Pattern Language

PatternLanguageSummary

CommonProblemsHighlighted

RunningExample

DistinctiveHeadingsConveyStructure

Glossary

Pattern Language Structure

UnderstoodNotations

ClearTargetAudience

TerminologyTailored toAudience

(External)PatternThumbnail

ReadableReferencesto Patterns

IntentCatalog

Making Patterns Understandable

VisibleForces

MandatoryElementsPresent

Optional ElementsWhen Helpful

EvocativePatternName

Relationship toOther Patterns

NounPhraseName

Pattern Structure

MeaningfulMetaphorName

Single-PassReadable

SkippableSections

FindableSections

CodeSamples

CodeSamples asBonus

A

B

C

D

E

B

E

Problem/SolutionSummary

Uma Linguagem de Padrões para Escrever Padrões



Estalecendo o Contexto: Padrões Estrutura

– Hábito 2• Componentes essenciais e opcionais

– Descrição dos itens do template escolhido• Forças Visíveis• Nome

– Nome composto– Metáfora significativa– Nome evocativo– Padrões relacionados– Código exemplo



Estalecendo o Contexto: Padrões (Cont.) Legibilidade

– Tornando os padrões fáceis de entender– Hábito 5

• Apresentando o padrão efetivamente– Hábito 6

• Iteração “eterna”– Hábito 7

• Coleta e incorporação de feedback



Estrutura da Linguagem de Padrões Problemas comuns entre os padrões

devem ser destacados Exemplos executáveis Resumo problema/solução Hábito 4

– Padrões distintos e complementares



Mais Dicas para Escrever Padrões Adote um formato conhecido

– Procedimentos de escrita variam de acordo com o formato escolhido

Inicie com os componentes essenciais, por exemplo: – Forças – Solução– Conexões com outros padrões no contexto e no

contexto resultante Considere sempre o seu leitor



Mais Dicas para Escrever Padrões (Cont.)

Desenvolva seus próprios rituais e procedimentos

Cite todas as fontes Dê créditos ao criador, aos editores, ao

primeiro que escreveu alguma coisa a respeito

Construa sobre outros padrões onde for possível e cite as fontes



Meios de Publicação Padrões necessitam de um meio não-

linear Publicação Web é o meio preferido Pode virar uma publicação linear se for

bem indexada e com referência cruzada Cultura WikiWiki (http://c2.com/cgi/wiki)

Copyright © 2002-2003 Rossana Andrade


Conferências PLoP www.hillside.net

EuroPLoP™ 2002

http://www.mcs.vuw.ac.nz/~kplop/



Workshop de Escritores Excelente modo de conseguir um feedback

sobre um padrão Grupo deve ler o artigo antes Autor permanece em silêncio enquanto os

outros discutem o padrão Grupo faz de conta que o autor não está lá Moderador assegura que a discussão é

positiva



Workshop de Escritores (Cont.) Cada membro do grupo

– Diz o que gosta antes do que não gosta– Discute tanto a forma quanto o conteúdo

Seqüência– Boas vindas ao autor – Autor lê uma seleção– Sumário– Feedback positivo primeiro– Sugestões para melhoria– Fechamento positivo– Autor pede esclarecimentos– Agradecimentos ao autor



Exercício: escrita de um padrão Escrever um padrão Sugestões

– Organização de Conferências– Processo de software

• Um arquiteto (engenheiro de software) também implementa

– Como criar clientes em um modelo cliente/servidor– Organização e Processo– Desenvolvimento de Site Web– Segurança



Discussão Cada grupo tem que ter um nome Cada grupo elege um líder para explicar

o padrão Outros grupos discutem o padrão



Parte III: Exemplos de Padrões Exemplos de Padrões Mais exemplos de linguagens de

Padrões Classificação dos Padrões de Software Workshop de Escritores



Exemplos de Padrões Web Handlers Padrões de Interface Gráfica



Mais Exemplos de Linguagens de Padrões

Generative Pattern Language for Distributed Processing– Estratégias para decompor sistemas de

software complexos através de nós de processamento

By DeBruler



Mais exemplos de Linguagens de Padrões (Cont.) Padrões

– Define The Data Structure – Identify The Nouns – Factor Out Common Attributes – Normalize the Roles – Identify Problem Domain Relationships – Introduce Virtual Attributes – Animate the Data – Time Thread Analysis – Determine The Actors



Mais exemplos de Linguagens de Padrões (Cont.)

Inter-systemHandoff

Execution HandoffFailureActions

Radio Resource Management

AnchorMobile

Switching Center

ReleasingResources

HandoffDecision

Authentication

LocationRegistration

Mobility Management

Home andVisitor

Databases

TemporaryIdentification

Ciphering

SecurityDatabase

Paging

Outgoing Call Incoming CallRoamingBy R. Andrade



Classificação dos Padrões de Software Padrões de Requisitos Padrões de Análise Padrões de Projeto

– Meta-Patterns– Padrões Arquiteturais

Idiomas



Classificação dos Padrões de Software (Cont.)

Requisitos Análise Projeto Implementação

Padrões de Requisitos

Padrões de Análise

Padrões de Projeto

Meta-Padrões

Padrões Arquiteturais

Idiomas



Padrões de Requisitos Documentam as necessidades do

usuário e o comportamento genérico do sistema em um alto nível de abstração

Ações que os desenvolvedores de software podem tomar para melhorar os requisitos não-funcionais

Mostram os relacionamentos entre o usuário ou o operador e o sistema



Padrões de Requisitos (Cont.)

Fault-tolerant telecommunication patterns – Visa a manutenção dos sistemas de comutação– Medidas apropriadas para serem tomadas no

estágio de desenvolvimento de requisitos• Padrões relacionados a confiabilidade (mensagens do

sistema e falhas do sistema) – Five minutes of no escalation messages

• Padrões relacionados aos fatores humanos



Padrões de Análise Inicialmente apresentados como

complementos aos padrões de projeto Um passo antes do projeto

– Modelo de análise que focaliza nas estruturas conceituais

Padrões de análise do Martin Fowler– Domínio de conhecimento de software de

negócios– Party, quantity, subtype state machines, entre

outros



Padrões de Análise (Cont.) Party Problema: pessoas e organizações têm

responsabilidades semelhantes Solução: Crie um tipo party como um

supertype de uma pessoa ou organização



Padrões de Projeto Estrutura repetida de elementos de projeto “Um esquema para o refinamento de subsistemas ou

de componentes de sistemas ou as relações entre eles.”

“...resolvem um problema geral de projeto num contexto particular.”, GoF

Padrões de projeto que incluem detalhes de código de baixo nível

Aplicados a diferentes tipos de problemas Padrões Arquiteturais e Meta-Padrões podem ser

considerados Padrões de Projeto.



Idiomas Relacionados com a implementação de

características de projeto específicas Padrão de baixo nível específico para

uma linguagem de programação– Idiomas em C++

• C++ Programming Styles and Idioms, James Coplien, 1991



Idiomas (Cont.) Nome: Counted Body Contexto: A interface de uma classe é separada de

sua implementação (respectivamente, classes handle e body)

Problema: atribuição em C++ é definida recursivamente como membro-por-membro com cópia quando a recursão termina

Solução: Um contador de referência é adicionado à classe body para facilitar o gerenciamento de memória

Autor e data: James Coplien, 1994



Parte IV: Reuso de Padrões A Comunidade de Padrões Ética de Padrões Reuso Meios de Publicação Workshop de Escritores Referências Em resumo ... (Conclusões)



A Comunidade de Padrões Uma hierarquia de workshops de

escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferência Conferências PLoP ao redor do mundo



Ética de Padrões Regra de Buschmann: nunca capture suas próprias

idéias em um padrão Não pense que padrões resolvem tudo Tente sempre encorajar as pessoas a repassar os

conhecimentos Sempre reconheça aqueles que criaram as técnicas

ou que primeiro se empenharam a escrever sobre elas

Não fique tão excitado! Padrões são apenas mais uma técnica para ajudá-lo no desenvolvimento de software



Reuso Conheça os padrões estão disponíveis

– Catálogo de padrões de 2000– Escolha aquele que satisfaz as suas

necessidades• Um padrão é difícil de entender se você não necessita

dele• Apenas tenha uma visão geral

Utilize o vocabulário dos padrões em revisões e sessões de projeto



Reuso (Cont.) GoF

– Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog

– http://java.sun.com/blueprints/corej2eepatterns/ Padrões Arquiteturais

– Frank Bushmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal (Gang of Five)

http://java.sun.com/blueprints/corej2eepatterns/



GoF Design PatternsCreational patterns

Abstract factory BuilderFactory method Prototype Singleton

Behavioral PatternsChain of

Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor

Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy



Core J2EE Pattern CatalogPresentation Tier

Intercepting Filter Front ControllerView Helper Composite View

Service to WorkerDispatcher View

Integration TierData Access Object Service Activator

Business TierBusiness Delegate

Service LocatorSession facadeTransfer Object Transfer Object

Assembler

Value List HandlerComposite Entity



Architectural PatternsFrom Mud to Structure

Layers Pipes and FiltersBlackboard

Adaptable SystemsReflection Microkernel

Interactive SystemsModel-View-

Controller Presentation-

Abstraction-Control

Distributed SystemsBroker Pipes and FiltersMicrokernel



Aplicando Padrões Empresas

– IBM, John Vlissides e Erich Gamma• Design Patterns

– Lucent, Jim Coplien e Linda Rising• Organizational Patterns

– Nortel, Greg Utas• Sistemas de Telefonia

– Carleton University • Teaching Patterns



Mais sobre Reuso de Padrões SugarloafPLoP’2002

– Airline Computer Reservation Systems– Engenharia Reversa de Demeyer– Uma ferramenta para Reuso: AGAP– Análise do Reuso de Padrões

Captura de Padrões



Referências[1] Andrade, R.M.C, “Capture, Reuse, and Validation of Requirements

and Analysis Patterns for Mobile Systems”, Ph.D. Thesis, University of Ottawa, Ottawa, 2001.

[2] Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., and Angel, S., A Pattern Language: Towns, Buildings, Construction, Oxford University Press, New York, NY, 1977.

[3] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Pattern-Oriented Software Architecture, John Wiley and Sons, New York, NY, 1996.

[4] Coplien, J. O., Software Patterns, SIGS books and Multimedia, June 1996.

[5] Fowler, M., Analysis Patterns: Reusable Object Models, Addison-Wesley, Reading, MA, 1997.



Referências (Cont.)[6] Gamma E., Helm R., Johnson R., Vlissides J., “Design Patterns:

Element of Reusable Object-Oriented Software”, 1995.[7] Pattern Languages of Program Design I, II, III & IV; Patterns from the

PLoP Conference at Allerton Park in Illinois, US and EuroPLoP in Europe; Addison-Wesley, 1994-95-96-98.

[8] Rising, Linda, “Patterns: A Way to Reuse Expertise,” IEEE Communications Magazine, Vol. 37, No. 4, April 1999.

[9] Rising, Linda, The Pattern Almanac 2000, Software Pattern Series, Addison-Wesley, 2000. ISBN 0-201-61567-3.

[10] Schmidt, D., “Tutorial about Design Patterns,” Available at http://www.cs.wustl.edu/~schmidt/patterns.html

[11] Yoder, Joseph, Tutorial “Software Patterns”, SugarloafPLoP’2002, Itaipava, Rio de Janeiro, RJ.

http://www.cs.wustl.edu/~schmidt/patterns.html















Maiores Informações Página de Padrões do Grupo Hillside

– http://hillside.net– Apontadores para listas, livros, arquivos ftp, padrões on-

line, conferências, entre outros

Listas– [email protected]– [email protected]– [email protected]

Repositório de Padrões Portland– http://c2.com/ppr/index.html

http://hillside.net/

mailto:[email protected]



http://c2.com/ppr/index.html



Em resumo ... Arquitetos experientes não têm consciência

que utilizam padrões– Bons para compartilhar informação e capturar

conhecimento Padrões funcionam como uma porta para

troca de experiências– Pode ajudar novos desenvolvedores a aprenderem

com os mais experientes Vocabulário Comum Padrões dão uma competência arquitetural de

organização



Em resumo ... (Cont.) Você deve escrever padrões para

– Aprender mais sobre padrões– Compartilhar conhecimento

• Provavelmente você usa alguma coisa que não foi documentada ainda

– Tarefa difícil e nem todos tem tempo ou vontade Você deve reutilizar padrões

– Em busca de uma melhoria no desenvolvimento de software



Por enquanto é só, Pessoal!

Documents

CK147 - Tópicos Avançados em Sistemas de Informação Copyright © 2002-2003 Rossana AndradeSlide 1 Padrões de Software Rossana Andrade [email protected]