Pattern Languages of Program Design 5 (PLoPD5) - PowerPoint PPT Presentation

Title: Pattern Languages of Program Design 5 (PLoPD5)


1
Pattern Languages of Program Design 5 (PLoPD5)

• Editado por Dragos Manolescu, Markus Voelter e
  James Noble

Erich Soares Machado 3680544 Flavio da Silva
Mori Junior 3671130
2
Categorias dos Padrões

• Padrões de Projeto
• Padrões de Concorrência, Rede e Tempo-Real
• Sistemas Distribuídos
• Padrões de Domínio Específico
• Padrões Arquiteturais
• Meta-Padrões

3
Patterns for Plug-ins

• Padrão Arquitetural
• por Klaus Marquardt

4
Introdução

• Flexibilidade, adaptabilidade e extensibilidade
  não vem de graça
• Custo para estender softwares é subestimado
• Flexibilidade
• Design cuidadoso
• Configurabilidade
• Componentes

5
Introdução

• Popularidade dos componentes
• Plug-ins X Componentes
• Sistemas quase pelados
• Plug-ins se tornaram populares com a plataforma
  Eclipse

6
O sabor Plug-in de Componentes

• Aplicação em particular X Uso geral
• Preservar utilidade da aplicação
• Componentes possuem funcionalidades completas
• Ex. CORBA Object Services
• Plug-ins são extensões mais específicas

7
Exemplo
Monitoramento das Atividades das Estagiárias (Plug
-in)
Dados
Sistema de Detecção de Intrusos (Plug-in)
Dados
Sistema de Segurança Central
Dados
Dados
?
Sistema Armageddon de Detecção de
Meteoros (Plug-in)
Monitoramento Anti-Aéreo (Plug-in)
8
Usos conhecidos

• Eclipse
• IE, Firefox, Netscape
• Adobe Photoshop, Adobe Acrobat
• Microsoft Word
• Windows, Linux, MacOS X (device drivers)

9
Visão Geral
10
Plug-in

• Contexto
• Uma aplicação que precisa ser adaptável ou ser
  extensível para suportar futuras funcionalidades
  ou módulos

• Problema
• Como adicionar funcionalidade depois?
• Como incrementar a funcionalidade após a
  distribuição?

11
Plug-in - Forças

• Possibilidade de extensão ? ? Equipes diferentes
  estão envolvidas
• Custo da distribuição ? ? Aumento de lucros
• Funcionalidades desconhecidas ? ? Tipo de
  funcionalidade bem definido
• Tipo de funcionalidade bem definido ? ?
  Funcionalidades específicas
• Núcleo da aplicação estático ? ? Evolução da
  tecnologia

12
Plug-in - Solução

• Fatorar a funcionalidade
• Colocá-la em componente separado
• Definir uma interface (Plug-ins Contract)

13
Plug-in - Conseqüências

• Possibilidade de extensão após a distribuição
• Entrar mais cedo no mercado ()
• Extensões são inofensivas
• Mais de uma distribuição pode ser necessária
• Necessidade de prever os tipos de extensões

14
Plug-in - Implementação

• Localizar pontos em aberto nos requerimentos
• Utilização de tecnologia que permita carregamento
  dinâmico (DLL, .NET)
• Separar o projeto físico (execução) e o projeto
  lógico (funcionalidades)

15
Plug-in Contract

• Contexto
• Os projetos da aplicação e de plug-in já foram
  estabelecidos, e o propósito principal dos
  plug-ins é definido

• Problema
• Como a aplicação define e descreve a interface
  para os plug-ins?

16
Plug-in Contract - Forças

• Desenvolvimento disjunto ? ? Integração e look
  and feel
• Diferentes equipes ? ? Padronização
• Acesso a classes e serviços chave da aplicação ?
  ? Portabilidade

17
Plug-in Contract - Solução

• Interface Contrato

18
Plug-in Contract Conseqüências

• Facilita a organização
• Encapsulamento da aplicação e dos plug-ins
• Permite desenvolvimento independente.
• Tratamento idêntico dos plug-ins
• Habilita integração total
• Potencial de evolução limitado pela própria
  interface
• Não é suficiente para integração total e look
  and feel

19
Plug-in Contract - Implementação

• Não depender de plug-ins específicos
• Restrições de conhecimento mútuo
• Estabilidade importante para a aplicação principal

20
Framework-Providing Application

• Também Conhecido Como
• Aplicação Principal, Contexto do Plug-in

• Contexto
• Uma aplicação teve suas funcionalidades
  fatoradas, de forma a permitir sua implementação
  através de plug-ins

• Problema
• Como um plug-in pode adicionar sua
  funcionalidade?

21
Framework-Providing Application - Forças

• Domínio definido pela aplicação ? ? Independência
  do plug-in com a aplicação
• Infra-estrutura da aplicação ? ? Necessidades do
  plug-in
• Iniciar logo as vendas () ? ? Integração entre
  os plug-ins

22
Framework-Providing Application - Solução

• Aplicação oferece um arcabouço caixa-preta
• Oferece oportunidades para herança e
  parametrização
• Carregamento e ativação dos plug-ins e outros
  serviços técnicos

23
Framework-Providing Application - Conseqüências

• Propósito principal é a integração
• Mesma infra-estrutura para todos os plug-ins
• Reuso de plug-ins por aplicações com mesmo
  arcabouço
• Independência da implementação da aplicação
• Combinações entre plug-ins requerem medidas
  especiais
• Aumento do custo do desenvolvimento

24
Framework-Providing Application - Implementação

• Parametrização X Herança
• Controle do acesso a partir do plug-in por meio
  de Façades

25
Framework-Providing Application - Usos Conhecidos

• Sistemas operacionais não definem aplicações, mas
  oferecem um contexto técnico
• Eclipse oferece uma infra-estrutura, mas inclui
  somente uma aplicação mínima
• Microsoft Word e navegadores definem um domínio
  de aplicação e oferecem uma funcionalidade central

26
Plug-in Registration

• Contexto
• A aplicação principal definiu o Framework
  Interfaces e o Plug-in Definitions. O usuário ou
  a aplicação decide quais plug-ins ativar.

• Problema
• Como os plug-ins serão ativados de forma que
  sejam reconhecidos pela aplicação?

27
Plug-in Registration - Forças

• Aplicação não conhece os plug-ins ? ? Plug-ins
  precisam se anunciar antes de uso
• Inicialização pelo usuário chata ? ? Instalação
  automática
• Aplicação conhece os gatilhos ? ? Os plug-ins
  conhecem os seus gatilhos

28
Plug-in Registration - Solução

• Aplicação define onde os plug-ins se registram
• Plug-in se instala e define seu gatilho de
  invocação
• Plug-in é inicializado quando a aplicação recebe
  o gatilho

29
Plug-in Registration - Conseqüências

• Tempo de inicialização independe dos plug-ins
• Interação do usuário não necessária
• Instalação a qualquer hora
• Instalação automatizada e inicializada
  remotamente
• Programa de instalação diferente
• Conflitos de versões

30
Plug-in Registration - Implementação

• Registro passivo
• Por extensão do arquivo
• Plug-ins definem os seus pontos de gatilho
• Registro ativo
• Plug-ins contatam a aplicação em execução
• Aumenta Plug-in Contract e maior custo
• Integração mais acoplada e invocação mais rápida
• Registro baseado em gatilhos
• Gatilhos desconhecidos com link para o programa
  de instalação

31
Plug-in Registration - Usos Conhecidos

• Registro de device drivers em tempo de execução
  (Windows XP)
• Registro ativo bem evasivo com recompilação do
  kernel (Unix/Linux)

32
Plug-in Lifecycle

• Contexto
• Um Plug-in Contract foi definido. Agora a
  aplicação precisa utilizar Plug-ins.

• Problema
• Como a aplicação poderá invocar e controlar os
  plug-ins?

33
Plug-in Lifecycle - Forças

• Dinâmica em tempo de execução ? ? Cada fase exige
  medidas especiais
• Invocação não depende do plug-in ? ? Aplicação
  controla os plug-ins

34
Plug-in Lifecycle - Solução

• Ciclo de vida do plug-in definido pela aplicação
• Instância - (des)carregamento, (des)ativação
• Tipo de plug-in - registro
• Uma função para cada transição
• Ciclos de vida para instâncias e para tipos de
  plug-in

35
Plug-in Lifecycle - Conseqüências

• Ciclo de vida definido e controlável
• Ação e reação
• Permite verificação

36
Plug-in Lifecycle - Implementação

• Verificação de plug-ins registrados
• Usuário seleciona plug-ins
• Carregamento na inicialização ou primeira
  invocação
• Escolha do uso feita pelo Plug-in Based
  Application
• Invocação agendada
• Invocação automática
• Invocação orientada a eventos

37
Plug-in Lifecycle Usos Conhecidos

• Eclipse, Adobe Photoshop e Microsoft Word
  demanda do usuário
• Sistemas operacionais na inicialização ou
  eventos externos
• Protetores de tela agendados (timer)
• Navegadores conteúdo da página

38
Plug-in Package

• Contexto
• Funcionalidades da aplicação foram fatoradas em
  plug-ins e o Plug-in Contract está disponível.

• Problema
• Como estender um plug-in para torná-lo um
  componente distribuível?

39
Plug-in Package - Forças

• Interfaces personalizadas ? ? Curva de
  aprendizado e menor estabilidade
• Separação diminui coesão ? ? Desenvolvimento em
  paralelo

40
Plug-in Package - Solução

• Extensão funcional como um pacote
• Interface do plug-in - classes de definição e
  arquivos adicionais
• Pacote plug-in central, plug-ins cooperativos,
  arquivos de recursos, helpers
• Identifique as funções do ciclo de vida e ache as
  interfaces técnicas
• Usar definições do Plug-in Contract personalizadas

41
Plug-in Package - Conseqüências

• Aumento da estabilidade da interface
• Interfaces padrões podem ser adicionadas
• Desenvolvimento em paralelo
• Coesão de plug-ins relacionados
• Conforto e conveniência para usuários
• Tamanho no lugar de complexidade
• Política para as versões dos pacotes
• Partes das interfaces não são controladas pela
  aplicação

42
Cooperating Plug-ins

• Também Conhecido Como
• One Plug-in per Task

• Contexto
• Uma aplicação definiu um Plug-in Contract. A
  integração total requer melhorias específicas
  além do modelo de extensão do plug-in, como visão
  e controle específicos, e possivelmente troca de
  dados.

• Problema
• Como as melhorias funcionais podem se estender
  por múltiplas camadas?

43
Cooperating Plug-ins - Forças

• Definição concisa e completa ? ? Interpretação e
  visão específicas
• Utilidade ? ? Dificuldade

44
Cooperating Plug-ins - Solução

• Criar uma definição para cada tarefa ou domínio
• Identificadores para plug-ins com o mesmo
  propósito

45
Cooperating Plug-ins - Conseqüências

• Limitar domínios técnicos
• Comunicação em camadas
• Níveis extras de empacotamento
• Necessidade de identificação
• Soluções muito específicas podem precisar do
  Plug-in Based Product

46
Cooperating Plug-ins - Implementação

• Aplicação deve definir divisão entre plug-ins
• Plug-ins de mesma interface seguem o mesmo
  Plug-in Contract
• Todos os plug-ins seguem o mesmo Framework
  Interface - Plug-in Definitions que muda
• Dividir o Framework Interface em seções

47
Cooperating Plug-ins Usos conhecidos

• LSM e Zeus definem plug-ins distintos com o mesmo
  propósito de comunicação e visualização, que são
  empacotados e atualizados em conjunto

48
Plug-in Based Product

• Contexto
• Define-se um Framework Providing Application, e
  diversos plug-ins ou Plug-in Packages estão
  disponíveis.

• Problema
• Como juntar as peças de forma a aumentar a
  satisfação do usuário final?

49
Plug-in Based Product - Forças

• Funcionalidade ? ? Simplicidade
• Aplicação não conhece plug-ins disponíveis ? ?
  Valor agregado
• Separação ? ? Valor funcional

50
Plug-in Based Product Solução

• Empacotar um produto incluindo o Framework
  Providing Application e diversos Plug-in Packages
• Criar uma suíte funcional homogênea
• Estabelecer um modelo de preços
• Atualizações

51
Plug-in Based Product - Conseqüências

• Definição sem código
• Responsabilidade do produto
• Modelo de negócios
• Foco no valor para o usuário final
• Estratégia de atualização
• Obsolescência

52
Plug-in Based Product - Implementação

• Criar um propósito para a aplicação principal
• Definir mais de uma interface de plug-in se
  necessário
• Definir responsabilidade de integração como uma
  variedade de plug-in

53
Plug-in Based Product

• Usos conhecidos
• Eclipse
• Zeus