XVI Simpósio Brasileiro de Engenharia de Software

(1)

Clique para editar o estilo do subtítulo mestre

Padrões de Software

(2)

 Esta apresentação é baseada no artigo:

“Suporte a Padrões no Projeto de Software “

 De autoria de :

◦ Alexandre Dantas, Gustavo Veronese, Alexandre Correa, José Ricardo

Xavier, Cláudia Werner.

◦ COPPE/UFRJ – Programa de Engenharia de Sistemas e Computação,

Universidade Federal do Rio de Janeiro



Apresentado no:

◦ XVI Simpósio Brasileiro de Engenharia de Software

Michel Fernando Reis 2

(3)

1. Objetivo

 O objetivo é abordar os principais três pontos abordados nesse artigo

através de um maior aprofundamento desses pontos:

◦ Anti-padrões;

◦ Heurísticas;

◦ Padrões.

(4)

2. Definição dos Termos

 _{Segundo Ferreira 2008, os termos Heurística, Padrão podem ser definidos}

da seguinte maneira:

◦ Heurística: “Conjunto de regras e métodos que visam à descoberta, à invenção ou à

resolução de problemas.”;

◦ Padrão: “2. Aquilo que serve de base ou norma para a avaliação; medida. 3. Objeto que serve

de modelo a feitura de outro.”;

(5)

3. O que é Heurística de Projeto?

 Diretriz resultante de conhecimento e experiência;

 _{Serve como um conselho para tomada de decisões de projeto;}

 Guiar o projetista na elaboração de boas soluções ao longo do

desenvolvimento;

 _{Não deve ser vista como uma regra inviolável;}

 Violações devem ser consideradas como avisos ou indicadores de que

alguma decisão de projeto pode ter sido tomada incorretamente;

(6)

3. O que é Heurística de Projeto?

 Exemplos de heurísticas podem incluir:

◦ Todo módulo deve se comunicar com o mínimo possível de outros módulos;

◦ Toda informação a respeito de um módulo deve ser privativa do mesmo;

◦ Classes derivadas devem conhecer as suas classes base, por definição, mas classes

base não devem ter qualquer tipo de conhecimento a respeito de suas classes derivadas.

(7)

3. O que é Heurística de Projeto?

 Uma representação para uma heurística pode conter:

◦ Título da heurística;

◦ Sua descrição;

◦ Motivação;

◦ Fontes bibliográficas;

◦ Padrões e anti-padrões relacionados a ela.

(8)

4. Padrão de Projeto - Origem

 Arquiteto Christopher Alexander publica no final dos anos 70 os livros:

◦ “A Pattern Language” ;

◦ “A Timeless Way of Building”;

 Exemplos e descrições de seu método para documentação de padrões;

 Embora voltado para a arquitetura, possui uma fundamentação básica

que permitiu ser abstraída para a área de software.

(9)

4. Padrão de Projeto - Origem

 Conferência sobre programação orientada a objetos (OOPSLA) de

1987,no “Workshop sobre Especificação e Projeto para Programação Orientada a Objetos “, Beck e Cunningham falam sobre uma

linguagem de padrões para projetar janelas em Smalltalk.

 Em 1993, Gamma e outros introduzem os primeiros de seus vinte e

três padrões de projeto, que seriam publicados em 1995.

 Esses foram os trabalhos pioneiros na área de padrões, seguidos por

muitos outros nos anos seguintes.

(10)

4.1 O que é um Padrão?

 Conjunto de informações instrutivas;

 Capta a estrutura essencial e o raciocínio de soluções

comprovadamente bem sucedidas para um problema repetido;

 Ocorre sob um determinado contexto e um conjunto de repercussões;

 Solução para um problema que ocorre com freqüência;

 Podem ser aplicados imediatamente a problemas de projeto;

(11)

4.1 O que é um Padrão?

 Podem se referir a diferentes níveis de abstração;

 Existem padrões:

◦ Arquiteturais;

◦ Padrões de análise;

◦ Padrões de projeto;

◦ Padrões de código;

◦ ETC. Michel Fernando Reis 11

(12)

4.2 Componentes de um Padrão

 Nome: deve ter um nome significativo, pode ser uma única palavra ou

frase curta que se refira ao padrão e ao conhecimento ou estrutura descritos por ele;

 Problema: estabelece o que será resolvido, descrevendo intenção e

objetivos no contexto;

(13)

4.2 Componentes de um Padrão

 Contexto: pré-condições onde o problema e sua solução costumam

ocorrer e para as quais a solução é desejável;

 Forças: descrição dos impactos, influências e restrições relevantes

para o problema e de como eles interagem ou são conflitantes entre si e com os objetivos a alcançar.

(14)

4.2 Componentes de um Padrão

 Solução: descrevem como obter o resultado desejado com instruções

que descrevem como o problema é resolvido, podendo para isso utilizar texto, diagramas e figuras. Podem conter as subseções:

 Estrutura: revelando a forma e organização estática do padrão;

 Participantes: descrevendo cada um desses componentes;

 Dinâmicas: exibindo o comportamento dinâmico do padrão;

 Implementação: mostrando detalhes de implementação do padrão;

 Variantes: discutindo possíveis variações e especializações da solução.

(15)

4.2 Componentes de um Padrão

 Exemplos: uma ou mais aplicações do padrão que ilustram, num

contexto inicial específico, como o padrão é aplicado e transforma aquele contexto em um contexto final.

 Contexto Resultante: o estado ou configuração do sistema após a

aplicação do padrão, pode ter uma subseção:

◦ Conseqüências: tanto boas quanto ruins, descrevendo as pós-condições e efeitos

colaterais do padrão;

(16)

4.2 Componentes de um Padrão

 “Rationale”: explicação das regras ou passos do padrão que explicam

como e porque ele trata suas influências contrárias, definidas em 'Forces', para alcançar os objetivos, princípios e filosofia propostos. Isso nos diz realmente como o padrão funciona, porque funciona e porque ele é bom.

(17)

4.2 Componentes de um Padrão

 Padrões Relacionados: Os relacionamentos estáticos e dinâmicos

desse padrão com outros dentro da mesma linguagem ou sistema de padrões. Padrões relacionados geralmente compartilham as mesmas influências. São possíveis os seguintes tipos de padrões relacionados:

◦ Padrões predecessores: aplicação conduz a esse padrão;

◦ Padrões sucessores: aplicados após esse;

◦ Padrões alternativos: solução diferente para o mesmo problema mas diante de

influências e restrições diferentes;

◦ Padrões codependentes: que podem (ou devem) ser aplicados simultaneamente com

esse padrão. _{Michel Fernando Reis} ₁₇

(18)

4.2 Componentes de um Padrão

 Casos Conhecidos: Descreve ocorrências conhecidas do padrão e sua

aplicação em sistemas existentes. Isso ajuda a validar o padrão,

verificando se ele é realmente uma solução provada para um problema recorrente.

(19)

4.3 Classificação de Padrões



Padrões de processo: definem soluções para os problemas

encontrados nos processos envolvidos na engenharia de

software: desenvolvimento, controle de configuração, testes, e

etc.;



Padrões arquiteturais: expressam o esquema ou organização

estrutural fundamental de sistemas de software ou hardware.

(20)

4.3 Classificação de Padrões



Padrões de padrão: são padrões descrevendo como um padrão

deve ser escrito, ou seja, que padronizam a forma com que os

padrões são apresentados aos seus usuários;



Padrões de análise: descrevem soluções para problemas de

análise de sistemas, embutindo conhecimento sobre o domínio

de aplicação específico.

(21)

4.3 Classificação de Padrões



Padrões de projeto: definem soluções para problemas de projeto

de software;



Padrões de interface: definem soluções para problemas comuns

no projeto da interface de sistemas;



Padrões de programação: descrevem soluções de programação

particulares de uma determinada linguagem ou regras gerais de

estilo de programação.

(22)

4.3 Classificação de Padrões



Padrões de Persistência: descrevem soluções para problemas

de armazenamento de informações em arquivos ou bancos de

dados.

(23)

4.4 Sistemas de padrões



Conjunto coeso de padrões co-relacionados que trabalham

juntos para apoiar a construção e evolução de arquiteturas

completas;



Descreve as diversas inter-relações entre os padrões e como

eles podem ser combinados e compostos para resolver

problemas mais complexos;



Devem ser descritos num estilo consistente e uniforme e

precisam cobrir uma base de problemas e soluções

suficientemente abrangente para permitir a construção de

parcelas significativas de arquiteturas completas.

_{Michel Fernando Reis} ₂₃

(24)

5. Anti-Padrões



Representam uma “lição aprendida”;

◦ Podem ser de dois tipos:

 Descrevem uma solução ruim para um problema que resultou em uma situação

ruim;

 Descrevem como escapar de uma situação ruim e como proceder para atingir uma

boa solução;



São necessários porque é tão importante ver e entender

soluções ruins como soluções boas.

(25)

5. Anti-Padrões



São aplicáveis em diferentes etapas de processos de

desenvolvimento:

◦ Anti-padrões de desenvolvimento de software;

◦ Anti-padrões de arquitetura de software;

◦ Anti-padrões de gerência de projetos de software.

(26)

5.1 Exemplos de Anti-Padrões



Bolha: A classe dominante e opressora;



Fluxo de lava: Os resquícios de erupções passadas;



Poltergeists: Cadê o objeto que estava aqui?;



Martelo dourado: Para qualquer necessidade, um prego;

(27)

5.1.1 Bolha



Classe concentra responsabilidades e monopoliza

processamento;



Outros objetos de outras classes podem existir, mas tipicamente

apenas atuam como encapsuladores de dados, sem ter

responsabilidades atribuídas;

(28)

5.1.1 Bolha

(29)

5.1. 2 Fluxo de lava



“

Eu não sei bem o que essa classe faz, ela foi escrita antes de

eu chegar aqui. . .”;



Comum em sistemas de ambientes de pesquisa;



Diversas contribuições ao longo de um grande período de

Tempo;

(30)

5.1.3 Poltergeists



Objetos com ciclo de vida muito curto;



Associados a classes com responsabilidades muito

limitadas no sistema;



Modelo do sistema desnecessariamente complexo e difícil

de entender;

(31)

5.1.3 Poltergeists

(32)

5.1.4 Martelo Dourado



A solução padrão para todos os problemas;



Tipicamente, presente em organizações que adotam produtos

de um fornecedor para desenvolver suas soluções de software;



Alto custo de investimento que deve ser justiﬁcado;



Desenvolvedores confortáveis com desenvolvimento usando

aqueles produtos e não questionam se há soluções mais

adequadas.

(33)

6. Conclusões



O uso de padrões proporciona um vocabulário comum para a

comunicação entre projetistas;



Garantindo uniformidade na estrutura do Software;



Atuam como blocos construtivos a partir dos quais projetos mais

complexos podem ser construídos;



Padrões emergem de soluções, não são impostos.

(34)

6. Conclusões



Anti-padrões também são padrões que ocorrem comumente no

desenvolvimento de software;



Como padrões, são organizados em catálogos;



Ao contrário dos padrões, geram conseqüências negativas;



Associado a cada anti-padrão, há uma estratégia de

reconstrução da solução,que obedece aos bons preceitos da

orientação a objetos.

(35)

7. Referencias Bibliográficas

 http://www.icmc.usp.br/~rtvb/apostila.pdf. Acessado em: 01/04/2010;

 http://www.lbd.dcc.ufmg.br:8080/colecoes/sbes/2002/038.pdf.

Acessado em: 01/04/2010;

 http://www.niee.ufrgs.br/eventos/CBCOMP/2004/html/pdf/Engenharia_S

oftware/t170100200_3.pdf. Acessado em: 01/04/2010;

Michel Fernando Reis

35

(36)

7. Referencias Bibliográficas

 http://www.ufpa.br/cdesouza/teaching/labes/padroes-de-software.pdf .

Acessado em: 28/03/2010

 http://calhau.dca.fee.unicamp.br/wiki/images/8/87/IA843_Padroes.pdf .

Acessado em: 28/03/2010

 http://calhau.dca.fee.unicamp.br/wiki/images/8/8e/Antipadroes.pdf dia

28/03/2010

36

(37)