TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS ANLISE

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

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

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

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

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.

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

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

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

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

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”

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.

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

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

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

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

Padrão Estrutural: Composite • Nome: – Composite • Problema: – Se existe um requisito para representar hierarquias todoparte, 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.

Padrão Estrutural: Composite • Forças: – O requisito que os objetos, tanto composto 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 todoparte indica a necessidade de uma estrutura de agregação

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

Padrão Estrutural: Composite • Solução: – Ambas subclasses, Leaf e Composite, têm uma operação redefinida usando polimorfismo an. Operation(). • 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.

Exemplo: Campanhas de Midia

Exemplo: Sistema de Arquivos

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.

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

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

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.

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 get. Company. Instance() e receber o identificador do objeto na resposta. • O objeto cliente pode então enviar uma mensagem get. Companydetails() para o objeto Company

Padrão Singleton: Exemplo

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

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

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.

Padrão Comportamental: State

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

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.

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.

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

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? • •

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

Perigos do Uso de Padrões • O uso de padrões de uma maneira descontrolada pode originar projetos sobrecarregados. • 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

Refabricação ou Re-factoring • Consiste em uma técnica de de reorganização que simplifica o projeto (ou código) de um componente sem mudar sua função ou comportamento • Fowler [FOW 99] define como o processo de modificar um sistema de software de tal modo que ele não altere o comportamento externo do código (ou projeto) mas melhore sua estrutura interna.

Refabricação ou Re-factoring • Elimina redundancia de elementos não usados no projeto ou desnecessarios • Verifica estrutura de dados impróprias ou construidas inadequadamente • Identifica falhas no projeto que possam ser eliminadas para sua melhoria.

Refabricação ou Re-factoring • Exemplo: – Uma primeira iteração no projeto pode produzir um componente com baixa coesão (executa três funções que tem apenas relacionamentos limitados entre si). – O projetista decide que o componente deve ser refabricado em três componentes separados, cada um exibindo alta coesão, resultando num software mais integravel, facil de testar e manter.

Bibliografia 1 LARMAN, Craig. Utilizando UML e Padrões. 3ª Edição. Porto Alegre: Bookman, 2007. SO TEM 2 E DE 2004 2 MELO, Ana Cristina. Desenvolvendo Aplicações com UML 2. 2. 1ª Edição. São Paulo: Brasport, 2011. So tem 2010 BIBLIOGRAFIA COMPLEMENTAR 1 2 PAULA FILHO, W. P. Engenharia de Software. Rio de Janeiro: LTC. 2009. TONSIG. S. L. Engenharia de Software – Análise e Projeto de Sistemas. 2ª Edição. Rio de Janeiro: Ciência Moderna, 2008. 21/08/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 42