©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/65 Padrões de Projeto.

Apresentação em tema: "©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/65 Padrões de Projeto."— Transcrição da apresentação:

1 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/65 Padrões de Projeto

2 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE2/65 Objetivos n 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

3 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE3/65 Motivação n Projetar software OO reusável e de boa qualidade é difícil  Mistura de específico + genérico  Impossível acertar da primeira vez n Projetistas experientes usam soluções com as quais já trabalharam no passado n Padrões de projeto  Uso sistemático de: ènomes, èexplicações, èe avaliações n Durante a última década, uma “comunidade de padrões” foi desenvolvida

4 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE4/65 Algumas definições n “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 n “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 n “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.

5 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE5/65 Características dos Padrões de Projeto de Software n Algo comprovado que captura e comunica os conhecimentos das melhores práticas n Descoberto, não inventado n 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 n 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 n Soluções Compartilhadas  Construídas em grupo  Através do uso de um vocabulário comum

6 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE6/65 Outros Tipos de Padrões n 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 n Padrões de Arquitetura:  Descrevem a estrutura e o relacionamento dos componentes de um sistema de software n Padrões de Processo

7 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE7/65 Catálogos e Linguagens de Padrões n 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 n 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

8 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE8/65 Princípios Presentes nos Padrões n Abstração n Encapsulamento n Proteção de informação n Modularização n Separação de conteúdos n Acoplamento e coesão n Suficiência, completude e primitividade n Separação entre interface e implementação n Único ponto de referência n Dividir para conquistar

9 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE9/65 Anti-Padrões n 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

10 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE10/65 Elementos para Documentação de um Padrão de Projeto 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.

11 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE11/65 Outros Elementos para Documentação n Um exemplo de uso n A razão que justifica a solução escolhida n Padrões relacionados n Uso conhecido do padrão n Lista de outros nomes para o padrão n Amostra de código em uma linguagem de programação

12 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE12/65 Tipos de Padrões de Projeto n Padrões de Projeto foram introduzidos para a comunidade OO através de  Gamma E., et al, Design Patterns, Addison-Wesley, 1994 n Eles categorizaram (23) padrões em três tipos:  Estruturais (7)  Criacionais (5)  Comportamentais (11) n divididos em 2 escopos:  Classe  Objeto

13 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE13/65 Escopo n Classe  Relacionamentos entre classes e suas subclasses  Não é preciso executar nenhum código para determinar o uso dos padrões  Estáticos: fixos em tempo de compilação n Objeto  Confia em ponteiros de objetos  Dinâmicos: relacionamentos entre objetos podem ser alterados em tempo de execução

14 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE14/65 Detalhamento dos Tipos de Padrões n Estruturais  Tratam de compor classes e objetos para formar estruturas grandes e complexas  Associados à maneira como classes e objetos são organizados estruturalmente  Oferecem formas efetivas para usar conceitos OO como herança, agregação e composição  Focam na abstração da estrutura

15 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE15/65 Detalhamento dos Tipos de Padrões n Criacionais  Associados ao processo de criação de objetos  Tornam um sistema independente de como seus objetos são criados, compostos e representados n 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

16 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE16/65 Alguns Exemplos n Padrão Composite (estrutural) n Padrão Singleton (criacional) n Padrão State (comportamental)

17 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE17/65 Padrão Estrutural: Composite n Nome: Composite n Problema:  Se existe um requisito para representar hierarquias todo- parte, então ambos objetos (todo e parte) oferecem a mesma interface para objetos cliente. n 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.

18 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE18/65 Padrão Estrutural: Composite n Forças:  O requisito que os objetos, tanto composto como componente, ofereçam a mesma interface, sugere que eles pertenç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

19 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE19/65 Padrão Estrutural: Composite n Solução : Combinar hierarquias de herança e agregação.

20 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE20/65 Padrão Estrutural: Composite n 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.

21 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE21/65 Exemplo do Padrão Composite: Graphical drawing package Graphic draw getChild removeGraphic addGraphic CompositeGraphic draw getChild removeGraphic addGraphic Line draw Rectangle draw Circle draw Client 0..*

22 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE22/65 Outro Exemplo do Padrão Composite: Campanhas de Midia

23 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE23/65 Padrão Composite: Exemplo de Uso n Diretórios e arquivos em um sistema de arquivos

24 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE24/65 Padrão de Criação: Singleton n Nome: Singleton n 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? n Contexto: Em algumas aplicações, uma classe deve ter exatamente uma instância.

25 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE25/65 Padrão de Criação: Singleton n 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).

26 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE26/65 Padrão de Criação: Singleton n 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.

27 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE27/65 Padrão de Criação: Singleton Singleton static uniqueInstance singletonData getInstance() getSingletonData() singletonOperation() return uniqueInstance

28 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE28/65 Padrão de Criação: Singleton n 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.

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

30 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE30/65 Padrão Singleton: Exemplo

31 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE31/65 Padrão Singleton: Exemplo n Mas a companhia opera como uma empresa separada em cada país  diferentes detalhes registrados da empresa para cada país n A classe Company só é instanciada uma vez. Ela é acessível globalmente. n Diferentes subclasses de Company são instanciadas quando necessário, dependendo das circunstâncias em tempo de execução.

32 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE32/65 Padrão Singleton: Exemplo

33 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE33/65 Padrão Comportamental: State n Nome: State n 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. n Contexto: Ema algumas aplicações um objeto pode ter o comportamento complexo que seja dependente do seu estado. A resposta para uma mensagem específica varia de acordo com o estado do objeto.

34 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE34/65 Padrão Comportamental: State n 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

35 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE35/65 Padrão Comportamental: State n Solução:  Separar o estado dependente do comportamento do objeto original e alocar este comportamento para um série de outros objetos, um para cada estado.  Estes objetos estado têm apenas responsabilidade relacionadas ao comportamento do respectivo estado.

36 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE36/65 Padrão Comportamental: State Context operation( ) State {abstract} operation( ) ConcreteStateA ConcreteStateB operation( )

37 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE37/65 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 associado com um estado do Contexto

38 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE38/65 Padrão Comportamental: State n 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, que está ativo, indica o estado atual do objeto Contexto.

39 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE39/65 Padrão Comportamental: State n 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.

40 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE40/65 Padrão State: Um Sistema de Biblioteca LoanStatus {abstract} CheckOut Available OnLoan CheckOut Copy CheckOut Available:: CheckOut (book; user) //Check out book to a user OnLoan:: CheckOut (book; user) //Error: ‘Book already out’ As subclasses concretas definem o método de acordo com o estado que elas representam

41 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE41/65 Padrão State: Exemplo de Campanhas

42 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE42/65 Questões Relativas ao Uso de Padrões n Existe algum padrão que trata um problema similar? n O contexto do padrão é consistente com o problema real? n As conseqüências do uso de padrão são aceitáveis? n O padrão tem uma solução alternativa que pode ser mais aceitável? n Existe uma solução mais simples? n Existem algumas restrições que sejam impostas pelo ambiente de software que está sendo usado?

43 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE43/65 Problemas com o Catálogo de Padrões n Armazenamento, busca e manutenção da documentação de padrões n Padrões colecionados num catálogo precisam ser agrupados n Projetistas descobrindo novos padrões precisam considerar onde o seu novo padrão se encaixa no catálogo n Publicação de padrões disponíveis  Todos os usuários precisam ser atualizados sobre o conteúdo do catálogo

44 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE44/65 Perigos do Uso de Padrões n O uso de padrões de uma maneira descontrolada pode originar projetos sobre-carregados. n 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

45 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE45/65 O Catálogo de Padrões de Gamma

46 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE46/65 Padrões de Criação: Objeto n Singleton  Garante que uma classe tenha apenas uma única instância, e oferece um ponto global para acessá-la. n Fábrica Abstrata (Abstract Factory)  Oferece uma interface para criar famílias de objetos relacionados sem especificar suas classes concretas. n Construtor (Builder)  Separa a construção de um objeto complexo de sua representação, então o mesmo processo de construção pode criar diferentes representações. n Protótipo (Prototype)  Especifica os tipos de objetos para criar usando uma instância prototípica, e cria novos objetos copiando deste protótipo.

47 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE47/65 Padrões de Criação: Classe n Método Factory  Define uma interface para criação de um objeto, mas deixa a subclasse decidir que classe instanciar.  Permite a classe retardar a instanciação da subclasse.

48 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE48/65 Padrões Estruturais: Objeto n Adaptador (Adapter)  Converte a interface de uma classe em outra interface que os clientes esperam. n Ponte (Bridge)  Desacopla uma abstração da sua implementação, as duas podem variar independentemente (herança em tempo de execução) n Composite  Compõe objetos em estruturas para representar hierarquias todo-parte. Permite que clientes tratem tanto os objetos individuais quanto as composições de objetos uniformemente.

49 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE49/65 Padrões Estruturais: Objeto n Decorador (Decorator)  Anexa responsabilidades adicionais para um objeto dinamicamente. n Fachada (Façade)  Oferece uma interface unificada para um conjunto de interfaces de um subsistema. n Peso Mosca (Flyweight)  Usa compartilhamento para apoiar eficientemente um grande número de objetos de fina granularidade. n Proxy  Oferece um ponto de acesso para outro objeto controlar o acesso.

50 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE50/65 Padrões Estruturais: Classe n Adaptador (Adapter)  Converte a interface de uma classe para outra interface que os clientes esperam. n Base de Template (Template Base)  Usa classes base do template para especificar associações.

51 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE51/65 Padrões Comportamentais: Objeto n Cadeia de Responsabilidade (Chain of Responsability)  Evita o acoplamento do emissor de um pedido ao seu receptor n Observador (Observer)  Quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente.

52 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE52/65 Padrões Comportamentais: Objeto (cont.) n Iteração (Iterator)  Oferece uma maneira para acessar os elementos de um objeto agregado seqüencialmente sem expor a sua representação. n Mediador (Mediator)  Define um objeto que encapsula a forma como um conjunto de objetos interagem entre si.

53 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE53/65 Padrões Comportamentais: Objeto (cont.) n Comando  Encapsula a requisição como um objeto. n “Memento”  Captura e externaliza um estado interno do objeto para que este estado possa ser recuperado depois. n Estado (State)  Permite que um objeto altere seu comportamento quando seu estado interno muda.

54 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE54/65 Padrões Comportamentais: Objeto (cont.) n Estratégia  Define uma família de algoritmos, encapsula cada um, e torna-os inter-cambiáveis. n Visitante  Representa uma operação a ser realizada para os elementos da estrutura de um objeto.

55 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE55/65 Padrões Comportamentais: Classe n Interpretador  Dada uma linguagem, define uma representação para sua gramática com um interpretador que usa a representação para interpretar sentenças na linguagem. n Template de método  Permite que subclasses redefinam certos passos de um algoritmo sem alterar a estrutura do algoritmo.

56 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE56/65 Padrões de Projeto para Arquitetura em Camadas

57 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE57/65 Padrão Façade n Intenção  Prover uma interface unificada para o conjunto de interfaces de um subsistema. Define uma interface de alto nível que faz um subsistema mais fácil de usar. n Motivação  Estruturar um sistema em subsistemas contribui para reduzir sua complexidade. A dependência entre subsistemas pode ser minimizada através do uso de um objeto Fachada, o qual provê uma interface única e uniforme para as diversas funcionalidades de um subsistema.

58 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE58/65 Padrão Façade: Estrutura e Participantes Façade subsystem classes Client

59 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE59/65 Padrão Façade: Aplicabilidade n Use o Padrão Façade quando:  Você quer prover uma interface simplificada para um subsistema complexo. Um Façade pode prover uma visão simples do subsistema, suficiente para a maioria dos clientes  Existem muitas dependências entre clientes e classes da implementação. O Façade reduz esta dependência e promove independência e portabilidade  Você quer criar sistemas em camadas. Um Façade provê o ponto de entrada para cada camada (nível) do subsistema.

60 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE60/65 Padrão Façade: Conseqüências n Promove acoplamento fraco entre o subsistema e seus clientes n No entanto, não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem.

61 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE61/65 Padrão Persistent Data Collections (PDC) n Nome: PDC n Problema: Como melhorar os níveis de manutenção e reuso quando usando mecanismos de persistência em aplicações orientadas a objeto? n Contexto: Durante o desenvolvimento de aplicações orientadas a objeto que utilizam mecanismos de persistência, através de APIs (Application Programming Interfaces) específicas, é possível que o código gerado misture a lógica da aplicação com os mecanismos de persistência, dificultando assim a manutenção e o reuso.

62 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE62/65 Padrão PDC n Forças:  Desenvolvedores devem poder endereçar os aspectos de negócio de uma organização independente das operações de persistência.  O mecanismos de persistência podem mudar durante o período de vida da aplicação.  Classes de negócio podem ser usadas por outras aplicações.  O mecanismo de persistência deve lidar de forma eficiente com a habilitação de conexões com o banco de dados e com o gerenciamento de transações.  A performance do sistema não deve ser afetada.

63 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE63/65 Padrão PDC n Solução:  Separar as classes de análise em duas categorias: èClasses descrevendo os objetos de negócio. èClasses para a manipulação e armazenamento de dados, com código específico para o tratamento de persistência.

64 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE64/65 Padrão PDC BusinessCollection specificSystemService() > IBusinessData insert() remove() update() search() Façade PersistentDataCollection insert() remove() update() search() BusinessBasic > IPersistenceMechanism beginTransaction() connect() commit() PersistenceMechanism beginTransaction() connect() commit() 1..* 0..*

65 ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE65/65 Leituras Adicionais n Gamma E, Helm R, Johnson R and Vlissides J. Design Patterns: Elements of Reusable Object- Oriented Software. Addison-Wesley 1994. n http://gee.cs.oswego.edu/dl/cpj/ifc.html http://gee.cs.oswego.edu/dl/cpj/ifc.html n http://st-www.cs.uiuc.edu/cgi- bin/wikic/wikic?JavaAWT http://st-www.cs.uiuc.edu/cgi- bin/wikic/wikic?JavaAWT n http://mordor.cs.hut.fi/tik-76.278/group6/awtpat.html http://mordor.cs.hut.fi/tik-76.278/group6/awtpat.html n http://jurema.cin.ufpe.br:8080/twiki/pub/Main/GenteAr eaPublications/PersistentDataCollectionsPLOP2001. pdf http://jurema.cin.ufpe.br:8080/twiki/pub/Main/GenteAr eaPublications/PersistentDataCollectionsPLOP2001. pdf