Rossana Andrade Departamento de Computação Universidade Federal do Ceará. O que é? Como?

(1)

Rossana Andrade

rossana@lia.ufc.br

Departamento de Computação

Universidade Federal do Ceará

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

Padrões de Software Diferentes Definições Um pouco da história Componentes

– Padrões como uma Peça ou Estória – Diferentes Formatos • GoF • Coplien Exemplos Classificação Comunidade e Ética Reuso

O que é?

– Nova categoria de conhecimento

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

Como?

(2)

Aplicação

– Arquitetura

– Ciência da Computação

• Engenharia de software

– Engenharia Mecânica

– Telecomunicações

– ...

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

!

"

“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

!

"

(3)

!

"

“Um padrão é uma solução provada

para um problema em um contexto, ”

Comunidade de Software

# $

%&

'

(

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)

# $

%&

'

(

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

$ )

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)

$ )

&

%$

*

Nome

– Uma palavra ou uma frase curta

– É a primeira coisa que o projetista9 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

$ )

&

%$

*

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)

$ )

&

%$

*

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

$ )

&

%$

*

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)

$ )

&

%$

*

Usos Conhecidos

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

sistemas reais

– Pelo menos 3 usos conhecidos

• Regra de 3

%

$ )

+$ )

%$

*

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

%

$ )

+$ )

%$

*

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

%

$ )

+$ )

%$

*

Padrões Relacionados

– Como o padrão está relacionado com

outros padrões que se referem ao mesmo

problema

(6)

& $ %$ ) "

%

(

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

, $

, % -

,

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

, $

, %

,

Estrutura

Participantes

Colaborações

Conseqüências

– forças

Implementação

Código Exemplo

Usos Conhecidos

Padrões relacionados

Solução

, $

).

Nome Contexto Problema Forças Solução Sketch – Desenhos ou Diagramas Contexto Resultante Rationale

– Mostra por que o padrão é útil

(7)

# $

/ $ ).

%$

$

*

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?

Forças

: Complexidade, Distribuição,

Disponibilidade de Informação, Custo e

Performance

# $

/ $ ).

%$

$

*

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)

# $

/ $ ).

%$

$

*

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

# $

/ $ ).

%$

$

*

Diagrama UML para uma aplicação de FTP

(8)

# $

/ $ ).

%$

$

*

Diagrama FTP com a aplicação do HOPP

Sketch

# $

/ $ ).

%$

$

*

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

/ $ ).

Web Handlers

(9)

.

& "*

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

0 1%

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

0 1%

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

2. 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

(10)

2. 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

“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 Arquitetônicos e Meta-Padrões podem ser considerados Padrões de Projeto.

+

$

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

+

$

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

(11)

$ %

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

3 &

4 ..

EuroPLoP

™

2002

EuroPLoP

™

2002

5 &

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

0 %

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

(12)

0 %

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)

, !

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

6 7

.

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 Composite Entity

&

& % .

From Mud to Structure

Layers

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

(13)

).&

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

8 0 %

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

8 +

$ "

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 – GREaT Patterns • padroes.lia.ufc.br

$

%$

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

(14)

$

%$

Vocabulário Comum

Padrões dão uma competência

arquitetural de organização

Você deve reutilizar padrões

– Em busca de uma melhoria no

desenvolvimento de software

0 3 &

[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.

0 3 &

[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.