Engenharia de Software Padrões de Projeto Aspectos Avançados em Engenharia de Software Fernanda Campos UFJF/DCC Aula 8

O problema Software: Hardware: 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: Um software 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 complexa É insensível à temperatura e à umidade É independente do sistema de fixação Esteticamente mais bonita É uma solução mais simples É fraca Não é aparente

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?” Christopher Alexander Alexander investigou: “A qualidade é objetiva?” “Como reconhecer e diferenciar um projeto de boa qualidade em relação a um de baixa qualidade?”

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 Projetos Contexto 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 Projetos Problema 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 Projetos Soluçã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.

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ção Padrõ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: Escopo: 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 Projeto Tipos (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 Projeto Tipos (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 Projeto Tipos (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"> <param name="alg" value="BidirBubbleSort"> <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 method public 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 ); }

Observer public 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. Fórmula cálculo taxas Gráfico de Barras Gráfico de Fatias Conjunto de Dados

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:

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