padrÕes posa - padrÕes de projeto

1

PADRÕES POSA - PADRÕES DE PROJETO Padrões de Projeto Classificação Decomposição Estrutural:

decomposição de sistemas e complexos componentes em partes que se cooperam:Whole-Part

Organização do Trabalho: como os componentes colaboram juntos para resolver um problema complexo:Master-Slave

2

PADRÕES POSA - PADRÕES DE PROJETOPadrões de Projeto Classificação Controle de Acesso: guardam e

controlam o acesso a serviços ou componentes:Proxy

Gerenciamento: manuseiam coleções homogêneas de objetos, serviços e componentes em sua totalidade:Command ProcessorView Handler

3

PADRÕES POSA - PADRÕES DE PROJETOPadrões de Projeto ClassificaçãoComunicação: ajudam a organizar a

comunicação entre os componentes: Forwarder-Receiver Client-Dispatcher-Server Publisher - Subscriber

4

PADRÕES POSA - PADRÕES DE PROJETOWhole-Part

5

PADRÕES POSA - PADRÕES DE PROJETOWhole-PartContexto

Implementar objetos agregados

6

PADRÕES POSA - PADRÕES DE PROJETOWhole-PartAjuda na agregação de componentes.

O, Todo (Whole), encapsula seus componentes constituintes, as Partes, (Part). Organiza as colaborações e provê uma interface comum para suas funcionalidades. O acesso direto às partes não é permitido.

7

PADRÕES POSA - PADRÕES DE PROJETOWhole-PartClientes enxergam o objeto agregado

(whole) como um objeto atômico que não permite acesso direto às partes

8

PADRÕES POSA - PADRÕES DE PROJETO Whole-Part

9

PADRÕES POSA - PADRÕES DE PROJETO Whole-Part

10

PADRÕES POSA - PADRÕES DE PROJETOWhole-PartConseqüências

Flexibilidade com as Partes: O Todo encapsula as partes e assim, separa do cliente. Assim, torna as Partes independentes.

Reusabilidade das partes e do todo com as partes.

11

PADRÕES POSA - PADRÕES DE PROJETOMestre-Escravo (Master-Slave)

O padrão de projeto Master-Slave suporta tolerância à falha, computação paralela e precisão computacional. Um componente mestre distribui o trabalho entre componentes escravos idênticos e computa o resultado final dos resultados que esses escravos retornam.

12


Contexto:Para abordar a complexidade de uma

tarefa, o projetista precisa dividir uma tarefa em sub-tarefas menores a serem executadas por diferentes agentes ou processos.

13

PADRÕES POSA - PADRÕES DE PROJETOMestre-Escravo (Master-Slave)Problema:

Como coordenar a realização de uma tarefa complexa?

Dividir e Conquistar é um princípio para resolução de problemas;

O Trabalho é dividido em várias sub-tarefas menores que são processadas independentemente;

Um agente pode dividir uma tarefa e delegar sub-tarefas a outros agentes para melhorar a confiança, desempenho, ou precisão da tarefa que é executada.

14

PADRÕES POSA - PADRÕES DE PROJETOMestre-Escravo (Master-Slave) Solução

Um componente master (mestre) distribui trabalho a componentes slaves (escravos) que realizam a computação;

O componente master divide o trabalho em sub-tarefas iguais e delega as sub-tarefas aos componentes escravos que são semanticamente (sentido) idênticos.

Depois os resultados parciais são enviados dos escravos para o mestre, que tem a responsabilidade de computar o resultado final.

15

PADRÕES POSA - PADRÕES DE PROJETOMestre-Escravo (Master-Slave) Solução

O mestre indica um escravo para cada sub-tarefa, neste caso ele utiliza recruit-all(X) para delegar tarefas para os agentes escravos.

Enquanto o escravo computa o resultado parcial da tarefa que foi nomeada pelo mestre, o mestre pode continuar seu trabalho normalmente. Quando um escravo tiver terminado seu trabalho envia uma resposta, usando reply(X), para o mestre que compila o resultado final e retorna para o cliente.

16


17


18


19

PADRÕES POSA - PADRÕES DE PROJETOMestre-Escravo (Master-Slave)Variantes

20


21

PADRÕES POSA - PADRÕES DE PROJETOMestre-Escravo (Master-Slave)Conseqüências

Extensibilidade: ao permitir trocar as implementações do escravos ou ainda acrescentar/retirar novos. Os cliente não são afetados com as mudanças.

Separação de camadas: a introdução do mestre, separa o escravo do cliente.

Eficiência: processamento paralelo;

22

PADRÕES POSA - PADRÕES DE PROJETOProxy Em algumas situações um servidor ou mesmo

um sistema inteiro não deve estar acessível diretamente pelos clientes.

Exemplo: nem todos os clientes estão autorizados a usar os serviços de um componente ou recuperar uma informação particular que o componente oferece;

Proxy é um padrão de design que faz com que clientes de um componente comunique-se com um representante ao invés de comunicar-se com o próprio componente.

23

PADRÕES POSA - PADRÕES DE PROJETOProxyContexto

Um cliente necessita acessar um serviço de um outro componente (objetos locais, banco de dados externos, paginas HTML, ou uma imagem em um documento, entre outros)

O acesso direto pode ser tecnicamente possível, mas não é a melhor abordagem.

24

PADRÕES POSA - PADRÕES DE PROJETOProxyProblema

É inapropriado o acesso direto ao componente;

O acesso ao componente tem que ser transparente;

O acesso ao componente tem que ser eficiente.

25

PADRÕES POSA - PADRÕES DE PROJETOProxySolução Introduz um representante (proxy). O cliente se

comunica com o Proxy ao invés de se comunicar com o próprio componente.

O proxy oferece uma interface para acesso ao componente e realiza processamento adicional (p.ex.: verificação de controle de acesso)

Serve para muitos propósitos incluindo facilidade de acesso e proteção contra usuários não autorizados.

26

PADRÕES POSA - PADRÕES DE PROJETOProxyEstrutura

27

PADRÕES POSA - PADRÕES DE PROJETOProxy

Interface Comum do

Proxy e Original

Componente

28

PADRÕES POSA - PADRÕES DE PROJETOProxy

29

PADRÕES POSA – PADRÕES DE PROJETOProxyConseqüências

Separar o cliente da localização dos seus componentes servidores.

Eficiência e baixo-custo de localização.

30

PADRÕES POSA – PADRÕES DE PROJETOPadrão Command Processor

O padrão de projeto Command Processor separa a requisição de um serviço de sua execução.

Um componente command processor gerencia requisições como objetos separados, agendando suas execuções e provendo serviços adicionais.

31

PADRÕES POSA – PADRÕES DE PROJETOPadrão Command ProcessorProblema:

Uma aplicação que possua um grande número de funcionalidades se beneficia de uma solução bem estruturada de mapeamento entre a sua interface e sua funcionalidade interna. Isso permite suportar diferentes modos de interação do usuário, como menus pop-up para usuários iniciantes e atalhos de teclado para usuários experientes, ou mesmo o controle externo da aplicação por linguagem de script.

32

PADRÕES POSA – PADRÕES DE PROJETOPadrão Command ProcessorProblema:

Geralmente é necessário implementar também serviços que vão além da funcionalidade central do sistema para execução de requisições do usuário.

As seguintes forças modelam a solução: Usuários diferentes podem interagir com a aplicação de

diferentes formas; Empreender aperfeiçoamentos na aplicação não pode

quebrar o código existente; Serviços adicionais devem ser implementados de forma

consistente para todos os tipos de requisição.

33

PADRÕES POSA – PADRÕES DE PROJETOPadrão Command ProcessorSolução:

O padrão Command Processor é baseado no padrão Command do GoF. Ambos os padrões seguem a idéia de encapsular requisições em objetos. Quando um usuário chama uma função específica na aplicação, a requisição é transformada num objeto command. O padrão especifica como os objetos command são gerenciados.

34

PADRÕES POSA – PADRÕES DE PROJETOPadrão Command ProcessorSolução:

O componente central do padrão, o command processor, cuida de todos os objetos command. Ele agenda a execução dos commands e pode armazená-los para futuro desfazimento da operação, podendo ainda prover serviços adicionais como logging. Cada objeto command delega a execução de sua tarefa a componentes denominados supplier contidos no núcleo funcional da aplicação.

35

PADRÕES POSA – PADRÕES DE PROJETOPadrão Command ProcessorEstrutura:

36


37

PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Estrutura:

Abstract Command: define a interface de todos os objetos command.

Controller: representa a interface da aplicação. Aceita as requisições e cria os correspondentes objetos comandos. Os objetos commands são entregues ao Command Processor (Receptor).

Command Processor: gerencia os objetos command, agendando e iniciando suas execuções (Executor). Efetua logging.

Supplier: provê a funcionalidade núcleo da aplicação. Executa o comando e quando um undo é requerido ele salva e restaura seu estado interno.

38


39

PADRÕES POSA – PADRÕES DE PROJETOPadrão Command ProcessorDinâmica:

40

PADRÕES POSA – PADRÕES DE PROJETOPadrão Command ProcessorDinâmica:

O controller aceita requisições do usuário e cria um comando. Após aceitar uma requisição undo, o controller transfere essa requisição para o command processor. O command processor invoca o procedimento de undo para o último comando realizado.

O comando ‘capitalizar’ restaura o supplier ao seu estado prévio, substituindo o texto salvo em sua posição original.

Se nenhuma atividade adicional é necessária ou possível para o comando, o command processor deleta o objeto command.

41

PADRÕES POSA – PADRÕES DE PROJETOPadrão Command ProcessorConseqüências:

Flexibilidade na forma como as requisições são ativadas;

Flexibilidade no número e funcionalidades das requisições;

Programação de serviços correlatos à execução da funcionalidade;

Testabilidade no nível da funcionalidade da aplicação;

Concorrência;

42

VIEW HANDLER

42

43

PADRÕES POSA – PADRÕES DE PROJETOPadrão View Handler

O padrão de projeto View Handler auxilia a gerenciar todas as visões que um sistema de software disponibiliza. Um componente view handler permite aos clientes abrir, manipular e encerrar as visões. Ele também coordena dependências entre as visões e organiza suas atualizações.

Exemplo: um aplicativo com interface Multiple Document Interface (MDI)

44

PADRÕES POSA – PADRÕES DE PROJETOPadrão View HandlerProblema:

Sistemas que possuem múltiplas visões interativas simultâneas em geral requerem escrita de funcionalidade adicional para gerenciá-las.

Os usuários necessitam abrir, manipular e encerrar as visões, como janelas e seus conteúdos. As visões devem ser coordenadas de modo que a atualização de uma visão seja propagada automaticamente para outras visões relacionadas.

45

PADRÕES POSA – PADRÕES DE PROJETOPadrão View HandlerProblema:

As seguintes forças conduzem à solução do problema: Gerenciar as múltiplas visões deve ser fácil sob a

perspectiva do usuário, e também para os componentes clientes dentro do sistema;

Implementações das visões individuais não devem depender de nenhuma outra ou serem misturadas com código utilizado para gerenciar as visões;

Implementações de visões podem variar, e tipos adicionais de visões podem ser adicionados durante o ciclo de vida do sistema.

46

PADRÕES POSA – PADRÕES DE PROJETOPadrão View HandlerSolução:

Separar o gerenciamento das visões do código requerido para apresentar ou controlar visões específicas.

O componente view handler gerencia todas as visões que o sistema provê. Ele oferece a funcionalidade necessária para abrir, coordenar e fechar visões específicas, e também manipular visões – por exemplo, um comando do tipo ‘tile’ apresentará todas as visões de uma determinada forma padronizada na tela.

O padrão View Handler adapta a idéia de separação entre a apresentação e o núcleo funcional, como proposto pelo MVC;

O componente view handler pode ser considerado como uma composição dos padrões GoF Abstract Factory e Mediator.

47

PADRÕES POSA – PADRÕES DE PROJETOPadrão View HandlerEstrutura:

48


49


View Handler: componente central do padrão. Responsável pela abertura de novas visões e serviços de gerenciamento e coordenação de visões.

Abstract view: interface que é comum a todas as visões.

Specific view: componentes que são derivados de uma abstract view e implementam sua interface.

Supplier: provê os dados que são apresentados pelos componentes das visões.

50


51

PADRÕES POSA – PADRÕES DE PROJETOPadrão View HandlerDinâmica:

52


Um cliente aciona um view handler para abrir uma determinada visão;

O view handler instancia e inicia a visão desejada. A visão registra-se no mecanismo de propagação de mudança de seu supplier.

53


O view handler adiciona a nova visão à sua lista interna de visão abertas.

O view handler aciona a visão para exibir a si própria. A visão abre uma nova janela, recupera os dados do supplier, prepara os dados para exibição e apresenta ao usuário.

54

PADRÕES POSA – PADRÕES DE PROJETOPadrão View HandlerConseqüências:

Tratamento uniforme das visões;Extensibilidade e mutabilidade das visõesCoordenação das visões por especificidade

de aplicação

55

FORWARD-RECEIVER

55

56

PADRÕES POSA – PADRÕES DE PROJETOPadrão Forward-Receiver O padrão de projeto Forwarder-Receiver

provê comunicação inter-processo transparente para sistemas de software com um modelo interativo peer-to-peer. Ele introduz forwarders e receivers para desacoplar os peers dos mecanismos internos de comunicação.

57

PADRÕES POSA – PADRÕES DE PROJETOPadrão Forward-ReceiverContexto:

Comunicação peer-to-peer

58

PADRÕES POSA – PADRÕES DE PROJETOPadrão Forward-ReceiverProblema:

Uma forma de construção de aplicações distribuídas é através de mecanismos de baixo-nível, comunicação entre inter-processos, como protocolos, filas de mensagens.

O problema é que muitas vezes eles dependem de Sistema Operacionais e protocolos de rede.

59

PADRÕES POSA – PADRÕES DE PROJETO Padrão Forward-ReceiverSolução:

Comunicação peer-to-peer. Peers distribuídos colaboram para resolver um problema particular.

Um peer pode atuar como um cliente, requisitando serviços, com um servidor, provendo serviços, ou ambos.

60

PADRÕES POSA – PADRÕES DE PROJETOPadrão Forward-ReceiverSolução:

Os detalhes do mecanismo de comunicação inter-processos para o envio e recebimento de mensagens são escondidos dos peers através de encapsulamento.

61

PADRÕES POSA – PADRÕES DE PROJETOPadrão Forward-Receiver

62

PADRÕES POSA – PADRÕES DE PROJETOPadrão

Forward-Receiver

63

PADRÕES POSA – PADRÕES DE PROJETOPadrão Forward-Receiver Peer: Cada peer conhece o nome dos outros

peers remotos com os quais ele precisa de comunicar. Usa o Forward para enviar mensagens para os outros peers e Receiver para receber mensagens.

Forward: envia as mensagens para os peers. Ele contém um mapeamento de nomes para o endereço físico dos receptores. Quando um forward envia uma mensagem para um peer remoto, ele determina sua localização física através do mapeamento.

Receiver: recebe as mensagens.

64

PADRÕES POSA – PADRÕES DE PROJETOPadrão Forward-Receiver

65

PADRÕES POSA – PADRÕES DE PROJETOPadrão Forward-ReceiverConseqüênciasEficiência na comunicação inter-processos;Encapsula as facilidades da comunicação

inter-processos.

66

CLIENT-DISPATCHER-SERVER

66

67

PADRÕES POSA – PADRÕES DE PROJETOPadrão Client-Dispatcher-Server

O padrão de projeto Client-Dispatcher-Server introduz uma camada intermediária entre clientes e servidores, o componente dispatcher. Esse componente oferece transparência de localização por meio de um serviço de nomes e esconde os detalhes do estabelecimento da conexão de comunicação entre clientes e servidores.

68

PADRÕES POSA – PADRÕES DE PROJETO Padrão Client-Dispatcher-Server Problema:

Quando um sistema utiliza servidores distribuídos ao longo de uma rede ele deve prover meios para comunicação entre eles. Em muitos casos uma conexão entre os componentes deve ser estabelecida antes da comunicação ocorrer, dependendo dos recursos de comunicação disponíveis.

No entanto, a funcionalidade central dos componentes deve ser separada dos detalhes de mecanismos de comunicação. Clientes não devem conhecer onde os servidores estão localizados. Isso permite mudar a localização dos servidores dinamicamente e assegurar estabilidade do sistema contra falhas na rede ou nos servidores.

69

PADRÕES POSA – PADRÕES DE PROJETOPadrão Client-Dispatcher-ServerProblema:

As seguintes forças devem ser ponderadas: Um componente deve ser capaz de usar um serviço

independente da localização do provedor do serviço; O código da implementação no núcleo funcional do

consumidor do serviço deve ser separado do código utilizado para estabelecer conexão com provedores de serviço.

70

PADRÕES POSA – PADRÕES DE PROJETOPadrão Client-Dispatcher-ServerSolução:

Disponibilizar um componente dispatcher para agir como uma camada intermediária entre clientes e servidores. O dispatcher implementa um serviço de nomes que permite aos clientes fazer referência aos servidores utilizando nomes ao invés de localizações físicas.

71

PADRÕES POSA – PADRÕES DE PROJETOPadrão Client-Dispatcher-ServerSolução:

Isso possibilita transparência de localização. Adicionalmente o dispatcher também é responsável por estabelecer o canal de comunicação entre um cliente e um servidor.

Os papéis de cliente e de servidor podem mudar dinamicamente ao contrário da abordagem cliente-servidor tradicional.

72

PADRÕES POSA – PADRÕES DE PROJETOPadrão Client-Dispatcher-ServerEstrutura:

73


74


Client: responsável por realizar tarefas específicas associadas ao certo domínio de aplicação.

Server: disponibiliza um conjunto de operações para os clientes. Ele registra-se ou é registrado no dispatcher pelo seu nome e endereço.

Dispatcher:disponibiliza a funcionalidade de estabelecimento de canais de comunicação entre clientes e servidores.

75


76

PADRÕES POSA – PADRÕES DE PROJETOPadrão Client-Dispatcher-ServerDinâmica:

77

PADRÕES POSA – PADRÕES DE PROJETOPadrão Client-Dispatcher-ServerDinâmica:

O server registra a si próprio no componente dispatcher. Num momento posterior, um client solicita ao dispatcher

um canal de comunicação para um servidor específico. O dispatcher procura o servidor que associado ao nome

especificado pelo cliente no seu registro. O dispatcher estabelece um canal de comunicação com o

server. Se for possível iniciar a conexão com sucesso, ele retorna o canal de comunicação para o client. Caso contrário, ele envia ao client uma mensagem de erro.

78

PADRÕES POSA – PADRÕES DE PROJETOPadrão Client-Dispatcher-ServerConseqüências:

Benefícios: Permutabilidade de servidores; Transparência de localização e migração; Re-configuração; Tolerância a falhas;

Limitações: Perda de eficiência devido ao overhead gerado pelo dispatcher;

Sensibilidade às mudanças nas interfaces do dispatcher;

79

PUBLISHER-SUBSCRIBER

79

80

PADRÕES POSA – PADRÕES DE PROJETOPadrão Publisher-Subscriber Ajuda a manter o estado dos componentes

sincronizados. Também conhecido como Observer.

81

PADRÕES POSA – PADRÕES DE PROJETO Padrão Publisher-Subscriber Problema Em alguns sistemas, os dados mudam em um certo

lugar e vários objetos em outras partes do sistema dependem daqueles dados;

É necessário então, utilizar algum mecanismo para informar os dependentes das mudanças;

Poder-se-ia introduzir chamadas explícitas do objeto cujo estado mudou para os seus dependentes, mas esta solução não é flexível nem reutilizável;

Precisamos de um mecanismo de propagação de mudanças que possa ser aplicado em vários contextos;

82

PADRÕES POSA – PADRÕES DE PROJETOPadrão Publisher-SubscriberA solução tem que equilibrar as seguintes

forças: Um ou mais objetos tem que ser notificados sobre

mudanças em um objeto; O número de dependentes não é conhecido a

priori e pode até mudar dinamicamente;Fazer com que os dependentes peguem o estado

de tempos em tempos (polling) é muito caro; O objeto que provê o dado e aqueles que o

consomem não devem ser fortemente acoplados;

83

PADRÕES POSA – PADRÕES DE PROJETOPadrão Publisher-SubscriberSolução O objeto que contém o dado que interessa é

chamado de Publisher (subject no GoF) Os objetos dependentes são chamados de

Subscribers (observers no GoF) O publisher mantém uma lista dos objetos

registrados que são aqueles interessados em receber notificações sobre as mudanças.

84

PADRÕES POSA – PADRÕES DE PROJETOPadrão Publisher-SubscriberSolução O publisher oferece uma interface para

manifestação de interesse (subscribe interface) Quando o estado do publisher muda, ele envia

uma notificação para todos os objetos que manifestaram interesse.

Ao receber uma notificação, o subscriber decide se solicita a informação ao publisher ou não.

85

PADRÕES POSA – PADRÕES DE PROJETO

Publisher Subscriber

86

PADRÕES POSA – IDIOMAS IDIOMASSão padrões de baixo-nível

específicos para uma linguagem de programação.

Um idioma descreve como implementar aspectos de um componente ou o relacionamento entre as características de uma linguagem.

87

PADRÕES POSA – IDIOMASPadrão Counted Pointer Problema:

Alocação dinâmica de objetos em C++ causa muitos problemas de memória;

Objetos tem que ser destruídos explicitamente e muitas vezes não sabemos o lugar apropriado para destruí-lo.

88

PADRÕES POSA – IDIOMASPadrão Counted Pointer

89

PADRÕES POSA – IDIOMASPadrão Counted Pointer Problema: Forças:

Passar objetos sempre por valor não é apropriado; Vários clientes precisam compartilhar um mesmo

objeto não podemos permitir referências para objetos que já foram destruídos (dangling references)

Se um objeto não é mais utilizado, ele deve ser destruído para liberar os recursos a solução não deve exigir muito código adicional e deve ser leve computacionalmente;

90

PADRÕES POSA – IDIOMASPadrão Counted Pointer Solução: Introduza contagem de referências

utilizando um "apontador contador" Adicione um contador de referências na

classe original Crie uma classe Handle que servirá de

"apontador inteligente" para o objeto original

91

PADRÕES POSA – IDIOMASPadrão Counted Pointer

92

REFERÊNCIAS

93

REFERÊNCIASAlexander, C., Ishikawa, S., Silverstein, M., Angel, S. and Abrams, D. (1975) “The

Oregon Experiment”, Oxford University Press.Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I. and Angel, S.

(1977) “A Pattern Language: Towns, Buildings, Construction”, Oxford University Press, New York, NY.

Alexander, C. (1979) “The Timeless Way of Building”, Oxford University Press, New York.

Almeida, S., Alvaro, A., Lucrédio, D., Garcia, C. and Piveta, K. (2004) “Student's PLoP Guide: A Pattern Family to Guide Computer Science Students during PLoP Conferences”, In the 4th Latin American Conference on Pattern Languages of Programming (SugarLoafPLoP), Writers' Workshop, Porto das Dunas-CE, Brazil.

Alur, D., Crupi, J. and Malks, D. (2003) “Core J2EE Patterns: Best Practices and Design Strategies”, Prentice Hall.

Ambler, S. (1998) “Process Patterns: Building Large-Scale Systems Using Object Technology”, Cambridge University Press.

Andrade, R., Marinho, F., Santos, M. e Nogueira, R. (2003) “Uma Proposta de um Repositório de Padrões Integrado ao RUP”, Session Pattern Application (SPA), SugarLoafPLoP 2003, The Third Latin American Conference on Pattern Languages of Programming, Porto de Galinhas, PE.

93

94

REFERÊNCIAS (CONT.)Appleton, B. (1997) “Patterns and Software: Essential Concepts and Terminology”,

http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html, Junho.Argonavis. Http://www.argonavis.com.brBeck, K. and Cunningham, W. (1987) “Using Pattern Languages for Object-Oriented

Programs”, Technical Report nº CR-87-43, http://c2.com/doc/oopsla87.html, Junho.

Booch, G., Rumbaugh, J. and Jacobson, I. (2000) “UML, Guia do Usuário: tradução”, Campus, Rio de Janeiro;

Brown, W., Malveau, R., McCormick, H. and Mowbray, T. (1995) “AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis”, Wiley.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M. (1996) “Pattern-Oriented Software Architecture Volume 1: A System of Patterns”, Wiley.

Coad, P. (1992) “Object-Oriented Patterns”, Communications of the ACM, V. 35, nº9, pages 152-159.

Coplien, J. (1991) “Advanced C++ Programming Styles and Idioms”, Reading-MA, Addison-Wesley.

Coplien, J. (1994) “A Development Process Generative Pattern Language”, Pattern Languages of Programs, Monticello, EUA.

Coplien, J. (1994) “Generative pattern languages: An emerging direction of software design”, C++ Report, pages 18-22, 66-67.

94

95

REFERÊNCIAS (CONT.)Coplien, J. and Schmidt, D. (1995) “Pattern Language of Program Design”,

Addison-Wesley.Coplien, J. (1996) “Software Patterns: A White Paper”, SIGS Publication.Coplien, J. and Harrison, N. (2004) “Organizational Patterns of Agile Software

Development”, Prentice Hall.Fowler, M. (1997) “Analysis Patterns: Reusable Object Models”, Addison-Wesley.Freeman, E., Freeman, E., Sierra, K. and Bates, B. (2004) “Head First: Design

Patterns”, O’Reilly.Gabriel, R. (2002) "Writers' Workshops & the Work of Making Things: Patterns,

Poetry...", Pearson Education.Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1993) “Design Patterns -

Abstraction and Reuse of Object-Oriented Design”, LNCS, nº 707, pages 406-431.

Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995) “Design Patterns - Elements of Reusable Object-Oriented Software”, Addison-Wesley.

Harrison, B. (2000) “The Language of Shepherding: A Pattern Language for Shepherds and Sheep”, 7th. Pattern Languages of Programs Conference, August, Allerton Park, Monticello, Illinois. 95

96

REFERÊNCIAS (CONT.)Johnson, R. (1992) “Documenting Frameworks Using Patterns”, OOPSLA '92, pages 63-76.Jorge H. C. Fernandes (1999-2003) “Padrões de Design Orientados a Objetos”Meszaros, G. and Doble, J. (1996) “MetaPatterns: A Pattern Language for Pattern Writing”,

Patterns Languages of Program Design, PLoP.Rising, L. (1998) “The Patterns Handbook: Techniques, Strategies, and Applications”, Sigs.Sane, A. (1995) “The elements of pattern style”, Proceedings of the Second Pattern

Languages of Programs Conference, Addison-Wesley, Menlo Park, California.Shalloway, A. and Trott, J. (2001) “Design Pattern Explained – A New Perspective on

Object Oriented Design”, Pearson.Schmidt, D., Stal, M., Rohnert, H. and Buschmann, F. (2000) “Pattern-Oriented Software

Architecture Volume 2: Patterns for Concurrent and Networked Objects”, Wiley.Tháis Batista, “Arquitetura de Software”, disponível em

http://www.dimap.ufrn.br/~thais/MES20061/aulaEstilos.pdf.Vlissides, J. (1990) “Patterns: The Top Ten Misconceptions,” Object Magazine,

http://hillside.net/patterns/papersbibliographys.htm, Junho.Vlissides, J., Coplien, J. and Kerth, N. (1996) “Pattern Languages of Program Design 2”,

Addison-Wesley.Vlissides, J. (1996) “Pattern Hatching: Seven Habits of Successful Pattern Writers”, C++

Report, http://hillside.net/patterns/papers/7habits.html, November. 96

97

OPORTUNIDADES

98

OPORTUNIDADES1. Especialização em Engenharia de Software

com Ênfase em Padrões de Software da UECE/FJN

Vagas para alunos especiais (formandos)

98

99

OPORTUNIDADES3. Mestrado Acadêmico em Ciência da

Computação da UECE (MACC) Turma 3 - início de 2009

4. Grupo de Padrões de Software da UECE (GPS.UECE)

Vagas para voluntários5. Mestrado Integrado Profissional em

Computação Aplicada UECE/CEFET-CE (MPCOMP)

99

100

CONTATOS

100

101

CONTATOS

101

Tarciane de Castro [email protected]

mailto:[email protected]

padrÕes posa - padrÕes de projeto

Documents