Padrões de Software. Objetivos Gerais. O que são Padrões

(1)

Padrões de Software

Rossana M. C. Andrade

rossana@lia.ufc.br

Departamento de Computação

Universidade Federal do Ceará

Objetivos Gerais

Oferecer uma visão geral sobre os conceitos

de padrões de software

Explicar a terminologia

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

CK119 – Engenharia de Software

Conteúdo

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?

(2)

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

(3)

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

(4)

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

problemaou 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

problemasurge 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

(5)

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çãoapresentada é a melhor • mostrar por que a soluçãomais ó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

(6)

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

(7)

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

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

(8)

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

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ão

Nome

: 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?

(9)

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

(10)

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

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

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

(11)

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

(12)

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)

Conferências PLoP

www.hillside.net

EuroPLoP

™

2002

EuroPLoP

™

2002

Próximos slides

Mais exemplos de linguagens de

Padrões

Classificação dos Padrões de Software

Workshop de Escritores

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

(13)

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-system Handoff Execution _Handoff Failure Actions Radio Resource Management Anchor Mobile Switching Center Releasing Resources Handoff Decision Authentication Location Registration Mobility Management Home and Visitor Databases Temporary Identification Ciphering Security Database Paging

Outgoing Call Incoming Call

Roaming

By 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

Outros tipos: padrões de processo, padrões de

testes, anti-padrões

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

Requisitos Análise Projeto _{Implementação}

(14)

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

(15)

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

(16)

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)

GoF Design Patterns

Creational patterns Abstract factory Builder Factory method Prototype Singleton Behavioral Patterns Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Structural patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy CK119 – Engenharia de Software

Core J2EE Pattern Catalog

Presentation Tier Intercepting Filter Front Controller View Helper Composite View Service to Worker Dispatcher View Integration Tier

Data Access Object Service Activator Business Tier Business Delegate Service Locator Session facade Transfer Object Transfer Object Assembler

Value List Handler

(17)

Architectural Patterns

From Mud to Structure

Layers

Pipes and Filters Blackboard Adaptable Systems Reflection Microkernel Interactive Systems Model-View-Controller Presentation- Abstraction-Control Distributed Systems Broker

Pipes and Filters Microkernel

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.

(18)

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.

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

– Gang-of-4-patterns-request@cs.uiuc.edu – Patterns-request@cs.uiuc.edu

– Patterns-discussion-request@cs.uiuc.edu

Repositório de Padrões Portland

– 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

(19)