Padrões de Projeto Aspectos Avançados em Engenharia de Software Fernanda Campos UFJF/DCC Aula 8.
95
Padrões de Projeto Aspectos Avançados em Engenharia de Software Fernanda Campos UFJF/DCC Aula 8
Transcript of Padrões de Projeto Aspectos Avançados em Engenharia de Software Fernanda Campos UFJF/DCC Aula 8.
Padrões de Projeto
Aspectos Avançados emEngenharia de Software
Fernanda CamposUFJF/DCC
Aula 8
O problema
Software:• Os custos de projeto
estão crescendo
• O prazo está se tornando mais curto
• Custo de manutenção é maior
Hardware:• Os custos, relativos,
estão diminuindo
• O tempo de desenvolvimento está encurtando
O problema
Custos em projeto de software por fase de desenvolvimento:
Etapa de Trabalho %
Análise de requisitos 3
Projeto 8
Programação 7
Testes 15
Manutenção 67
Fonte: Butler Bloor
Introdução
problemas de software +
crescente taxa de mudanças nos requisitos
Introdução
Categorias básicas de projeto:
• Bem-sucedidos: resultam em funcionalidade plena no prazo adequado (16,2%);
• Contestados: requerem tempo e orçamento maiores do que o proposto (52,7%);
• Refutados: são cancelados durante a fase de desenvolvimento (31,1%).
O que o cliente deseja Uma solução que:
• Atenda as necessidades funcionais;• Adapte-se ao ambiente de rápidas mudanças dos
negócios;• Enquadre-se às limitações de run-time [tempo /
espaço].
Um software que:• Seja de fácil manutenção;• Seja desenvolvido dentro dos recursos propostos;• Tenha uma longevidade apropriada.
Motivação
Vamos observar dois profissionais de marcenaria: construir gavetas.
Motivação
Carpinteiro 1:
• Como você acha que deveríamos construir essas gavetas?
Motivação Carpinteiro 2:
• “Bem, acho que devemos fazer o canto cortado reto a madeira e então cortando-a de volta em 45 graus...
• ...indo depois reto de volta para baixo e aí de volta para cima, no outro sentido, em 45 graus; depois, indo reto de volta para baixo e, então,...
• ..até que você termina com uma junta encaixada.
Motivação
Carpiteiro 1:• Devo usar uma junta encaixada ou uma de
meia esquadria?
É uma solução mais simplesÉ fraca
Não é aparente
É uma solução mais complexaÉ insensível à temperatura e à umidadeÉ independente do sistema de fixação
Esteticamente mais bonita
Motivação
Vantagens:
• Reutilizar soluções;
• Estabelecer terminologia comum;
• Ter uma perspectiva de mais alto nível acerca dos problemas e do processo de projeto: abstração.
Motivação
Alexander investigou:
• “A qualidade é objetiva?”
• “Como reconhecer e diferenciar um projeto de boa qualidade em relação a um de baixa qualidade?”
Christopher Alexander
Motivação
Alexander descobriu:
• As estruturas estão diretamente ligadas com o problema que tentam resolver;
• Padrões: similaridades entre projetos de alta qualidade.
Definição
1979 por Alexander: “Cada padrão descreve um problema que ocorre repetidamente no nosso ambiente e, portanto, descreve o cerne da solução desse problema, de tal forma que você pode utilizar essa solução um milhão de vezes repetidas, sem nunca fazê-la de duas vezes do mesmo modo.”
Definição
Padrão: “descreve uma solução para um problema em um determinado contexto”.
Descrição
De acordo com Alexander:
• O nome do padrão;
• O propósito do padrão;
• Como podemos utilizar o padrão;
• Restrições e motivos a serem considerados.
O início
1990 – Desenvolvedores imaginavam:
• Existem problemas em software que poderiam ser resolvidos da mesma maneira?
• Seria possível projetar software em termos de padrões?
O início
A GOF publicou o livro de maior influência:
• Design Patterns: Elements of Reusable Object-Oriented Software
O início Os propósitos do livro eram:
• Aplicar a idéia de padrões de projeto a projeto de software;
• Descrever uma estrutura para catalogar e descrever padrões de projeto;
• Identificar e catalogar estes padrões (23);
• Postular estratégias e enfoques orientados a objetos baseados nesses padrões de projeto.
Padrões para Projetos Quando especialistas trabalham na solução de um
problema é raro criarem soluções totalmente novas, em geral buscam problemas similares que já tenham sido resolvidos e reutilizam a essência da resolução na solução do novo problema (Budchman et al, 1996).
“Um padrão é uma idéia que foi utilizada num contexto prático e que provavelmente será utilizada por outros” (Fowler, 1997).
Desta forma muitas experiências em criação de modelos para projetos e a repetição contínua desses problemas apresentados levam à especificação dos padrões.
Padrões para Projetos
Padrões documentam experiências de projetos e não são inventados ou criados artificialmente.
Uma característica importante dos padrões é disponibilizar para muitos um conhecimento adquirido.
O esquema da solução é especificado pela descrição dos componentes, suas funções e relacionamentos e as formas de colaboração entre eles (Budchman et al., 1996).
Padrões para Projetos A construção de padrões é um processo social interativo
de coleta, compartilhamento e amplificação de experiência e conhecimento distribuídos (Lea 1994 in Vasconcelos Junior, 1997).
Os padrões ajudam na redução da complexidade de muitas situações na vida real e podem fornecer combinações de ações que levam à solução de problemas (Pree, 1995).
Para Buschmann et al. (1996), os padrões demonstram as prováveis soluções de uma forma facilmente disponível e se possível, bem escrita.
Padrões para Projetos “O emprego de padrões tem sido, portanto, no sentido de
disseminar soluções incorporando, além de soluções, informações tais como descrições do problema e contexto de aplicação” (Vasconcelos Junior, 1997).
O formato dos padrões é, a partir desta conceituação, uma técnica de representação do conhecimento sobre problemas e suas soluções.
A inovação que esta técnica introduz é a forma sistemática de documentar e descrever os padrões de forma a facilitar a sua aplicação e uso.
Padrões para Projetos Segundo Fowler (1997) padrões conceituais, incluídos os
design patterns, são aqueles que representam a maneira como as pessoas pensam, mais do que a maneira como um sistema é planejado. O modelo conceitual é um privilégio humano de modo que o que buscamos é a sua aplicabilidade.
Design Patterns complementam métodos existentes e buscam soluções para os problemas recorrentes num alto nível de abstração. Podem envolver desde um conjunto simples de regras e relações até elaboradas guidelines, envolvendo complexas relações daí derivadas (Lyardet et al., 1998).
Padrões para Projetos Existem alguns elementos que são considerados essenciais
para um padrão, entre eles podemos citar (Gamma et al., 1995):
O nome: usado para descrever o problema, sua solução e conseqüências em uma ou duas palavras;
O problema: descreve quando usar o padrão, explica o problema e o seu contexto. Algumas vezes inclui uma lista de condições que devem ser satisfeitas antes da aplicação do padrão;
A solução: descreve os elementos que compõem o projeto, seus relacionamentos, responsabilidades e colaborações. É uma descrição abstrata do design do projeto e como um conjunto de elementos o resolve;
As conseqüências: são os resultados e comprometimentos da aplicação do padrão. As conseqüências são críticas para avaliar as alternativas e para entender custos e benefícios para aplicação de padrões.
Padrões para Projetos Considerando a literatura sobre padrões, Vasconcellos Junior (1997)
apresentou um conjunto básico de informações importantes para registrar padrões de forma a facilitar a consulta:
Identificação: um nome, ou frase, descritivo, curto e familiar, normalmente sendo mais indicativo da solução do que do problema ou contexto;
Exemplo: um ou mais casos ilustrando o emprego de padrões; Contexto: delineamento de situações em que os padrões são aplicáveis (geralmente inclui
informações de suporte, discussões sobre a necessidade de existência do padrão e evidências de sua generalidade);
Problema: uma descrição das forças e restrições relevantes e como interagem; Solução: uma representação da solução do problema, descrita de forma a ser útil, já que esta é a
parte reutilizável. Soluções podem se referenciar e se relacionar com outros padrões de maior ou menor nível;
Conseqüência: uma descrição das implicações da aplicação do padrão, como restrições e comprometimentos;
Padrões relacionados: outros padrões que tem alguma relação com este. Por, exemplo, aqueles que podem ser usados em conjunto ou que são semelhantes.
Padrões para Projetos Fowler (1997), entretanto, descreve quatro partes
essenciais que os padrões devem ter, ressaltando a forma como muitos autores vem descrevendo seus padrões. Para o autor esta forma é importante porque ela sustenta a definição de um padrão como a solução de um problema num contexto. São elas:
uma afirmação do contexto onde o padrão é utilizado; o problema que ele busca solucionar; as forças que atuam na formação da solução;
e a solução que resolve as forças.
Padrões para Projetos
Buschmann et al. (1996) adotam um esquema de três partes para documentar padrões:
Contexto: a situação que originou o problema;
Problema: o problema que se originou do contexto;
Solução: uma resolução comprovada do problema.
Padrões para ProjetosContexto
O contexto estende a dicotomia problema-solução descrevendo a situação na qual o problema ocorre.
Especificar um contexto é uma tarefa difícil e é praticamente impossível prever todas as situações onde um padrão pode ser utilizado.
Uma solução apresentada é listar todas as situações conhecidas onde a utilização do padrão pode ser relevante.
Padrões para ProjetosProblema
O problema é a descrição dos problemas que se originam repetitivamente do contexto. Inicia-se com uma especificação geral do problema, capturando a sua essência, que é completada por um conjunto de forças.
A idéia de “forças” é introduzida pela lógica fuzzy onde deve-se determinar quais fatores são cruciais para a solução de seu problemas, quais os aspectos relevantes ou não, a indicação da solução de seu problema será fornecida a partir do total de condições, fatores e/ou “forças” cruciais que constam no problema apresentado.
O termo “forças” é usado para especificar aspectos do problema que devem ser considerados quando da resolução do problema, tais como: requisitos que a solução deve abordar, obrigações que devem ser consideradas e propriedades que a solução deve ter.
Padrões para ProjetosSolução
Muitos problemas podem ter mais de uma solução, e a adequação da solução ao problema está relacionada ao contexto em que o problema ocorre. Cada solução leva em consideração algumas forças e soluciona umas em detrimento de outras, ou pode mesmo ignorá-las. A solução mais apropriada é a que melhor resolve as forças de mais alta prioridade para o contexto em questão (Meszaros et al., 1998).
Padrões para Projetos
Os usuários dos padrões esperam que os mesmos contenham determinadas informações que os diferenciem da descrição problema/solução.
Meszaros et al. (1998) demonstram o relacionamento entre os elementos de um padrão na figura, destacando os elementos mandatórios que os mesmos deverão conter.
USUÁRIOSDE PADRÕES CONTEXTO
FORÇA
SOLUÇÃOPROBLEMA
TEM
OPERA EM
PRIORIZA
RESOLVE
SOLUCIONA
Sistemas de Padrões Os padrões não existem isoladamente, pois existem muitas
interdependências entre eles. Um sistema de padrões agrupa padrões individuais e descreve como eles se conectam e como eles se complementam. Um sistema é mais do que uma coleção de padrões e deve ser organizado de uma forma que facilite a sua utilização e que guie os usuários na seleção dos padrões. Sendo assim, o modelo de descrição dos padrões, para contemplar um sistema, deve evidenciar como o padrão se conecta com os outros padrões, com quais outros padrões ele pode ser conectado, com quais outros padrões ele pode ser refinado e combinado, quais variáveis ele supõe e quais outros padrões resolvem o mesmo problema de maneira diversa da apresentada (Budchman et al, 1996).
Sistemas de Padrões
Um sistema de padrões deve assegurar a sua evolução uma vez que nem mesmo os sistemas mais maduros permanecerão estáticos (Budchman et al, 1996). Novos padrões devem ser incorporados ao sistema e padrões obsoletos devem ser retirados e, em qualquer caso, os relacionamentos devem ser atualizados
DescriçãoPadrões de Projeto OO Nome:
• todos os padrões tem um nome único que os identifica; Intenção:
• o propósito do padrão; Problema:
• o problema que o padrão está tentando resolver; Solução:
• como o padrão provê uma solução para o problema no contexto em que ele aparece; Participantes e colaboradores:
• as entidades envolvidas no padrão; Conseqüências:
• investiga as forças que nele agem; Implementação:
• como o padrão pode ser implementado; Estrutura de design:
• Meta-modelo.
Classificação Propósito:
• De criação: criação de objetos;• Estrutural: composição de classes ou objetos;• Comportamental: maneira pelas quais classes ou
objetos interagem e distribuem responsabilidades. Escopo:
• Classe: relacionamento entre classes e sub-classes (estático);
• Objeto: relacionamento de objetos que podem ser mudados em tempo de execução (dinâmico).
Padrões no ProjetoTipos (Pressman)
Padrões arquiteturais – definem uma estrutura global o software, indicam oi relacionamento entre subsistemas e componentes do software e definem as regras para especificar relacionamentos entre os elementos (classes, pacotes, componentes, subsistemas ) da arquitetura.
Padrões no ProjetoTipos (Pressman)
Padrões de projeto – atendem a um elemento específico do projeto tal como uma agregação de componentes para resolver algum problema de projeto, relacionamentos entre componentes ou os mecanismos para efetuar a comunicação componente a componente.
Padrões no ProjetoTipos (Pressman)
Padrões de código – são padrões específicos da linguagem e geralmente implementam um elemento algorítmico de um componente, um protocolo epecífico de interface, ou um mecanismo para comunicação entre omponentes.
Strategy
Strategy
Strategy
Intenção: permitir utilizar diferentes algoritmos, dependendo do contexto em que eles ocorrem;
Problema: a seleção de um algoritmo depende do cliente ou dos dados;
Solução: separar a seleção de algoritmos da implementação destes.
Strategy
Conseqüências:• Defini uma família de algoritmos;
• Comandos como switch e condicionais podem ser eliminados;
• Invoca-se todos os algoritmos da mesma maneira.
Implementação: utilizar uma interface e instanciar a derivação especifica para o contexto.
Strategy
Estrutura:
Strategy
Exemplo:
Applet Estratégia ordena vetor
Bubble sort Bidirecional bubble sort Quick sort
Strategy Código:
context(...) {if(alg == BUBBLE) {
b.sort(vec);} else if(alg == BIBUBBLE) {
bb.sort(vec);} else { // Q
q.sort(vec);}
}
Strategy
Exemplo:
algorithm
Strategy
Código:
class SortAlgorithm {...void sort(int a[]) ... {}...
}
Strategy Código:
public class QSortAlgorithm extends SortAlgorithm {...void sort(int a[]) ... {
...}...
}
Strategy Código:
public class SortItem extends ... implements ... {...SortAlgorithm algorithm;...public void init() {
String at = getParameter("alg");...algName = at + "Algorithm"; ...
}...public void run() {
...algorithm = (SortAlgorithm)Class.forName(algName).newInstance(); ...algorithm.sort(arr);
}...
}
Strategy Código:
<html>...<applet code=SortItem.class …><param name="alg" value="BubbleSort">...<applet code=SortItem.class …><param name="alg" value="BidirBubbleSort">...<applet code=SortItem.class …><param name="alg" value="QSort">...</html>
Strategy
Applet:
• SortDemo/example1.html
Abstract Factory
Abstract Factory
Abstract Factory
Intenção: ter conjuntos de objetos para casos particulares;
Problema: objetos relacionados precisam ser instanciados;
Solução: coordenar a criação de famílias de objetos.
Abstract Factory
Conseqüências: isola as regras referentes sobre como utilizar os objetos;
Implementação: definir uma classe abstrata que especifica quais objetos devem ser implementados, e a seguir, implementar uma classe concreta para cada família.
Abstract Factory
Estrutura:
Abstract Factory
Exemplo:
Uma solução alternativa
Facade
Facade
Intenção: simplificar o uso de um sistema através de uma única interface;
Facade
Facade
Estrutura:
Facade
Exemplo:
Composite Intenção:Geralmente temos a necessidade de manipular
objetos compostos (composites) exatamente da mesma forma que manipulamos objetos primitivos;
Problema:Se precisássemos distinguir entre objetos primitivos e objetos compostos para realizarmos operações nestes dois tipos de objetos, nosso código tornaria-se mais complexo e difícil de implementar, manter e estender;
Composite Solução:Compor objetos em uma estrutura de árvore
para representar hierarquias parte-todo. Composite permite que os clientes tratem objetos individuais e composições de objetos uniformemente;
Conseqüências:Composite é composto de uma coleção de outros componentes abstratos, que podem ser qualquer outro tipo de componente concreto, incluindo o próprio Composite. Todos eles são componentes abstratos e quando um método é invocado de um objeto Composite, ele simplesmente manda requisições seqüencialmente para todos seus componentes “filhos”;
Composite Implementação:
// This method is a Composite methodpublic void draw() {
// Iterate over the components for(int i=0; i < getComponentCount(); ++i) {
// Obtain a reference to the component and invoke its draw method Component component = getComponent(i); component.draw(); }}
Composite
Estrutura:
f.operacao();
Composite
Exemplo:
Observer Intenção: definir uma dependência um-para-muitos entre
os objetos, para quando um deles mudar de estado todos os seus dependentes sejam notificados e atualizados automaticamente;
Problema: precisa-se notificar uma lista variável de objetos de que um evento ocorreu;
Solução: Fazer com que os observadores deleguem a responsabilidade de monitoração de um evento a um objeto central: o sujeito.
Observer
Conseqüências: sujeitos podem informar à observadores sobre eventos;
Implementação: anexar objetos que queiram saber sobre a ocorrência de um evento em um objeto que faz a monitoração do evento.
Observer
Implementação:public interface Subject { public void addObserver( Observer o ); public void removeObserver( Observer o );}
public interface Observer { public void update( Subject o );}
Observerpublic class IntegerDataBag implements Subject {
private ArrayList list = new ArrayList(); private ArrayList observers = new ArrayList();
public void add( Integer i ) { list.add( i ); notifyObservers(); }
public Integer remove( int index ) { if( index < list.size() ) { Integer i = (Integer) list.remove( index ); notifyObservers(); return i; } return null; }
Observer
private void notifyObservers() { // loop through and notify each observer Iterator i = observers.iterator(); while( i.hasNext() ) { Observer o = ( Observer ) i.next(); o.update( this ); } }}
Observer Estrutura:
Observer Exemplo:
Sujeito: O conjunto de dados envia notificações a todos aqueles que o estão observando cada vez que seu conteúdo mudar.
Observadores: Cada observador envia uma requisição para os dados atualizados.
Conjunto de Dados
Fórmula cálculotaxas
Gráfico de Fatias
Gráfico de Barras
Mediator Intenção: definir um objeto que encapsula
como um conjunto de objetos interagem;
Problema: projetos orientados a objetos encorajam a distribuição de comportamentos entre os objetos;
Solução: encapsular o comportamento coletivo em um objeto separado, que é responsável por controlar e coordenar a interação do grupo de objetos.
Mediator
Conseqüências: limita subclasses, simplifica protocolos de objetos, abstrai como os objetos cooperam e centraliza o controle;
Implementação: os colaboradores tem que comunicar o mediador quando um evento de interesse ocorre. Uma aproximação é uma implementação usando Observer.
Mediator
Estrutura:
Mediator
Exemplo:
Bridge Intenção: separar abstração da
implementação;
Problema: as derivações de uma classe abstrata devem usar múltiplas implementações sem causar uma explosão no número de classes;
Solução: definir uma interface para todas as implementações a serem usadas e fazer com que as derivações da classe abstrata a usem.
Bridge
Conseqüências: O desacoplamento entre as implementações e os objetos que as usam aumenta a capacidade de extensão;
Implementação:• Encapsular as implementações em uma classe
abstrata;
• Incluir um apontador para ela na classe-base de abstração.
Bridge Estrutura:
Bridge
Exemplo:
Decorator Intenção: anexar, dinamicamente,
responsabilidades adicionais a um objeto;
Problema: necessidade de acrescentar funcionalidades adicionais à um objeto, antes ou depois da funcionalidade básica;
Solução: estender a funcionalidade de um objeto de forma encadeada, sem recorrer à subclassificação.
Decorator Conseqüências: a funcionalidade que deve ser
adicionada reside em pequenos objetos. A vantagem está na capacidade de adicionar dinamicamente essa função antes ou depois da funcionalidade básica;
Implementação: criar uma classe abstrata que represente tanto a classe original como as novas funções a serem adicionadas a ela. Nos decoradores, colocar as novas chamas de função antes ou depois das novas chamadas encadeadas, a fim de obter a ordem correta.
Decorator
Estrutura:
Decorator
Exemplo:VisualComponent
Draw()
TextView
Draw()
Decator
Draw()
ScrollDecorator
ScrollPosition
Draw()ScrollTo()
BorderDecorator
borderWidth
Draw()DrawBorder()
MVC
Intenção: Uma maneira de quebrar uma aplicação, ou apenas parte dela, em partes, com uma clara separação dos objetos de cada parte;
Problema: Aplicações que necessitem a capacidade de manter múltiplas views dos mesmos dados;
Solução: Encapsular os dados junto com seu processamento (o modelo), isolando de sua manipulação (o controlador) e apresentação (view);
MVC
Conseqüências: O desacoplamento modifica desde como os dados são manipulados até como são apresentados ou armazenados, enquanto unifica o código em cada componente. Por causa desta separação, múltiplas views e controladores podem “interfacear” com ou mesmo modelo;
MVC
Implementação:O MVC é um padrão composto de vários outros
padrões, como exemplo:
• As views formam um árvores usando Composite;
• A relação entre views e modelos é feita via Observer;
• Os controladores são estratégias de views (Strategy).
MVC
Estrutura:
Padrões de Projeto
• utilizar padrões é:• reutilizar soluções;
• produzir código flexível.
• documentar em +alto nível o sistema;
• “Os padrões fornecem a você uma perspectiva de mais alto nível acerca dos problemas e do processo de orientação a objetos...”
UML & Padrões de Projeto
• UML sem Padrões
• Padrões sem UML• Não obtemos um ferramental completo
• UML com Padrões• Atingimos o máximo do potencial que podemos em
um desenvolvimento
Referências
FOWLER, Martin; SCOTT, Kendall. UML Essencial. Bookman, 2000.
LARMAN, Craig. Utilizando UML e Padrões. Bookman, 2000.
LEE, Richard C.; TEPFENHART, William M. UML e C++. Makron Books, 2002.
SHALLOWAY, Alan; TROTT James R. Explicando Padrões de Projeto. Bookman, 2004.
Sun Microsystems. Core J2EE Patterns. Campus, 2002
http://inf.unisinos.br/~crespo
http://dei.unicap.br/~sergio
http://www.netobjectives.com/design.htm#Design_patterns_are
http://www.cmcrossroads.com/bradapp/docs/patterns-nutshell.html
