TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Semana 08 1 14/08/2012 Professor Leomir J. Borba-

Apresentação em tema: "TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Semana 08 1 14/08/2012 Professor Leomir J. Borba-"— Transcrição da apresentação:

1 TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Semana 08 1 14/08/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

2 Agenda Padrões de Projetos (Design Patterns) 2 14/08/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

3 Objetivos Explicar: – O que é um padrão de projeto – Alguns padrões que já foram identificados no desenvolvimento de software – Como aplicar padrões de projeto durante o desenvolvimento de software – Os benefícios e dificuldades que podem surgir quando usamos padrões de projeto

4 Motivação Projetar software OO reusável e de boa qualidade é difícil – Mistura de específico + genérico – Impossível acertar da primeira vez Projetistas experientes usam soluções com as quais já trabalharam no passado Padrões de projeto – Uso sistemático de: nomes, explicações, e avaliações Durante a última década, uma “comunidade de padrões” foi desenvolvida

5 Definições “Cada padrão descreve um problema que ocorre freqüentemente em seu ambiente, e então descreve o núcleo de uma solução para o problema, de maneira que você possa usar esta solução um milhão de vezes, sem fazê-la do mesmo jeito duas vezes.” Christopher Alexander (Arquiteto e Urbanista), 1977 “Um padrão é a abstração de uma forma concreta que ocorre muitas vezes em contextos não arbitrários específicos.” Riehle and Zullighoven, 1996 “Resolve um problema. É um conceito provado. A solução não é óbvia. Descreve um relacionamento. Os padrões têm um componente humano significativo.” Coplien 1996.

6 Características Algo comprovado que captura e comunica os conhecimentos das melhores práticas Descoberto, não inventado Soluções Sucintas e de Fácil Aplicação – Capturam, de forma sucinta e facilmente aplicável, soluções de projeto de programas de computador que foram desenvolvidas e evoluíram com o passar do tempo Soluções Exaustivamente Refinadas – Resultados de um longo processo de projeto, re-projeto, teste e reflexão sobre o que torna um sistema mais flexível, reusável, modular e compreensível Soluções Compartilhadas – Construídas em grupo – Através do uso de um vocabulário comum

7 Outros Tipos de Padrões Padrões de Análise: – Descrevem grupos de conceitos que representam construções comuns na modelagem do domínio. Estes padrões podem ser aplicáveis em um domínio ou em muitos Padrões de Arquitetura: – Descrevem a estrutura e o relacionamento dos componentes de um sistema de software Padrões de Processo

8 Catálogos e Linguagens de Padrões Um catálogo de padrões é um grupo de padrões que estão relacionados de uma certa forma e podem ser usados juntos ou independentemente Os padrões numa linguagem de padrões estão relacionados, e trabalham juntos para solucionar problemas num domínio específico – um conjunto de padrões que trabalham juntos para solucionar um grande problema

9 Princípios Presentes nos Padrões Abstração Encapsulamento Proteção de informação Modularização Separação de conteúdos Acoplamento e coesão Suficiência, completude e primitividade Separação entre interface e implementação Único ponto de referência Dividir para conquistar

10 Anti-Padrões São uma maneira de documentar soluções recorrentes que não tiveram sucesso – Podem também incluir soluções re-trabalhadas que sejam efetivas – “Gambiarras Clássicas”

11 Elementos para Documentação Nome: – Resume em uma ou duas palavras: o problema, as soluções e conseqüências do uso do padrão. – Deve ser facilmente lembrado, reflete o conteúdo do padrão. Problema: – Descreve quando aplicar o padrão. Explica o problema e seu contexto. Sintomas e condições. Solução: – Elementos que constituem o design, seus relacionamentos, responsabilidades e colaboradores. Conseqüências: – Resultados e compromissos decorrentes da aplicação do padrão. – Impactos sobre a flexibilidade, extensibilidade,portabilidade ou desempenho do sistema.

12 Tipos de Padrões de Projeto Padrões de Projeto foram introduzidos para a comunidade OO através de – Gamma E., et al, Design Patterns, Addison-Wesley, 1994 Eles categorizaram (23) padrões em três tipos: – Estruturais (7) – Criacionais (5) – Comportamentais (11) divididos em 2 escopos: – Classe – Objeto

13 Detalhamento dos Tipos de Padrões Estruturais – Tratam de compor classes e objetos para formar estruturas grandes e complexas – Associados à maneira como classes e objetos sãoorganizados estruturalmente – Oferecem formas efetivas para usar conceitos OO comoherança, agregação e composição – Focam na abstração da estrutura

14 Detalhamento dos Tipos de Padrões Criacionais – Associados ao processo de criação de objetos – Tornam um sistema independente de como seus objetos são criados, compostos e representados Comportamentais – Tratam de algoritmos e como atribuir responsabilidades entre objetos – Associados à maneira que objetos e classes distribuem suas responsabilidades para realizar uma tarefa – Focam na abstração do comportamento

15 Alguns Exemplos Padrão Composite (estrutural) Padrão Singleton (criacional) Padrão State (comportamental)

16 Padrão Estrutural: Composite Nome: – Composite Problema: – Se existe um requisito para representar hierarquias todo- parte, então ambos objetos (todo e parte) oferecem a mesma interface para objetos cliente. Contexto: – Numa aplicação tanto o objeto que contém quanto o que é componente devem oferecer o mesmo comportamento. – Objetos cliente devem ser capazes de tratar objetos compostos ou componentes do mesmo jeito.

17 Padrão Estrutural: Composite Forças: – O requisito que os objetos, tanto composto como componente, ofereçam a mesma interface, sugere que elespertençam à mesma hierarquia de herança. Isto permite que operações sejam herdadas e redefinidas com a mesma assinatura (polimorfismo). – A necessidade de representar hierarquias todo- parte indica a necessidade de uma estrutura de agregação

18 Padrão Estrutural: Composite Solução : Combinar hierarquias de herança e agregação.

19 Padrão Estrutural: Composite Solução: – Ambas subclasses, Leaf e Composite, têm uma operação redefinida usando polimorfismo anOperation(). Na classe Composite esta operação redefinida invoca a operação relevante a partir de seus componentes usando um loop. – A subclasse Composite também tem operações adicionais para gerenciar a hierarquia de agregação, então os componentes podem ser adicionados ou removidos.

20 Exemplo: Campanhas de Midia

21 Exemplo: Sistema de Arquivos

22 Padrão de Criação: Singleton Nome: – Singleton Problema: – Como pode ser construída uma classe que só pode ter uma única instância e que pode ser acessada globalmente dentro da aplicação? Contexto: – Em algumas aplicações, uma classe deve ter exatamente uma instância.

23 Padrão de Criação: Singleton Forças: – Uma abordagem para tornar um objeto acessível globalmente é colocá-lo como uma variável global. – Outra abordagem é não criar uma instância de objeto em nenhum lugar, mas usar operações e atributos de classe (chamados ‘static’ em C++ e Java).

24 Padrão de Criação: Singleton Solução: – Criar uma classe com uma operação de classe (ou estática, ex: Java, C++) getInstance(), que: Quando a classe é acessada pela primeira vez, a instância do objeto é criada e retornada para o cliente. Nos acessos subseqüentes a getInstance() nenhuma instância adicional é criada, mas a identidade do objeto existente é retornada.

25 Padrão de Criação: Singleton Vantagens: – Oferece acesso controlado à única instância do objeto, pois a classe Singleton encapsula a instância. – A classe Singleton pode ter subclasses. Pode-se determinar que subclasses são instanciadas quando a classe Singleton é acessada pela primeira vez. – Uma variação do padrão pode ser usada para criar um número específico de instâncias, se for requerido.

26 Padrão Singleton: Um Exemplo de Uso O sistema de gerenciamento de campanhas de uma empresa precisa guardar informações a respeito da empresa. Estas informações só devem ser guardadas em um único lugar dentro da aplicação, mas serão usadas por diferentes objetos. Quando um objeto cliente precisa acessar o objeto Company, pode enviar a mensagem getCompanyInstance() e receber o identificador do objeto na resposta. O objeto cliente pode então enviar uma mensagem getCompanydetails() para o objeto Company

27 Padrão Singleton: Exemplo

28 Padrão Comportamental: State Nome: – State Problema: – Um objeto exibe um comportamento diferente quando seu estado interno muda, fazendo o objeto parecer ter mudado a classe em tempo de execução. Contexto: – Ema algumas aplicações um objeto pode ter o comportamento complexo que seja dependente do seu estado. A resposta para uma mensagem

29 Padrão Comportamental: State Forças: – O objeto tem comportamento complexo que deve ser dividido em elementos menos complexos. Uma ou mais operações têm comportamento que variam de acordo com o estado do objeto. – Tipicamente a operação teria muitas sentenças condicionais dependentes do estado. – Uma abordagem é ter operações públicas diferentes para cada estado, mas objetos cliente precisariam saber o estado do objeto para poderem chamar a operação adequada

30 Padrão Comportamental: State Solução: – Separar o estado dependente do comportamento do objeto original e alocar este comportamento para um série deoutros objetos, um para cada estado. – Estes objetos estado têm apenas responsabilidade relacionadas ao comportamento do respectivo estado.

31 Padrão Comportamental: State

32 Participantes do Padrão State Context – define a interface de interesse para clientes. – Mantém uma instância de uma subclasse ConcreteState que define o estado corrente State – define uma interface para encapsulamento do comportamento associado com um estado específico do Contexto Subclasses ConcreteState – cada subclasse implementa um comportamento associadocom um estado do Contexto

33 Padrão Comportamental: State Vantagens: – O comportamento do estado é localizado e o comportamento para diferentes sub-estados é separado. – Isto facilita qualquer modificação do comportamento do estado, em particular a adição de estados extra. – Transições de estado são explícitas. O objeto estado, queestá ativo, indica o estado atual do objeto Contexto.

34 Padrão Comportamental: State Desvantagens: – O objeto Estado pode ser criado ou removido quando o objeto Context muda o estado, introduzindo assim um overhead no processamento. – O uso do padrão State introduz pelo menos uma mensagem extra, a mensagem da classe Context para classe State, adicionando assim mais overhead no processamento.

35 Padrão State: Um Sistema de Biblioteca As subclasses concretas definem o método de acordo com o estado que elas representam

36 Questões Relativas ao Uso de Padrões Existe algum padrão que trata um problema similar? O contexto do padrão é consistente com o problema real? As conseqüências do uso de padrão são aceitáveis? O padrão tem uma solução alternativa que pode ser mais aceitável? Existe uma solução mais simples? Existem algumas restrições que sejam impostas pelo ambiente de software que está sendo usado?

37 Problemas com o Catálogo de Padrões Armazenamento, busca e manutenção da documentação de padrões Padrões colecionados num catálogo precisam ser agrupados Projetistas descobrindo novos padrões precisam considerar onde o seu novo padrão se encaixa no catálogo Publicação de padrões disponíveis Todos os usuários precisam ser atualizados sobre o conteúdo do catálogo

38 Perigos do Uso de Padrões O uso de padrões de uma maneira descontrolada pode originar projetos sobre- carregados. Desenvolvedores: Precisam de tempo para entender os catálogos de padrões relevantes – Precisam de fácil acesso a catálogos relevantes – Precisam ser treinados no uso de padrões

39 Bibliografia 21/08/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com 39 BIBLIOGRAFIA BÁSICA 1 ARAUJO, L. LIMA. C. A. UML Aplicada – Da teoria à implementação. 1ª Ed. Rio de Janeiro: Ciência Moderna, 2007. 2 LARMAN, Craig. Utilizando UML e Padrões. 3ª Edição. Porto Alegre: Bookman, 2007. 3 MELO, Ana Cristina. Desenvolvendo Aplicações com UML 2.2. 1ª Edição. São Paulo: Brasport, 2011. BIBLIOGRAFIA COMPLEMENTAR 1 PAULA FILHO, W. P. Engenharia de Software. Rio de Janeiro: LTC. 2009. 2 TONSIG. S. L. Engenharia de Software – Análise e Projeto de Sistemas. 2ª Edição. Rio de Janeiro: Ciência Moderna, 2008. 3 Mike Cohn. Desenvolvimento de software com Scrum - Aplicando métodos ágeis com sucesso. 1 Bookman 2011 ISBN 9788577808076 / Eudes Diônatas Silva Souza(11720) 4 Pressman, Roger S., Engenharia de Software: Uma Abordagem Profissional ”, 7ª edição, Ed. McGraw-Hill, ISBN 9788563308337, 2011. 5 Martin Fowler. Refatoração - Aperfeiçoando o Projeto de Código Existente, Bookman Companhia Ed 2004 - ISBN 9798536303955. 6 Gamma; Helm; Johson; Vlissides. Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos. Bookman, 2004. ISBN: 9788573076103.