1

Pattern Languages of Program Design 5 (PLoPD5)

Editado por Dragos Manolescu, Markus Voelter e James Noble

Erich Soares Machado 3680544Flavio 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 Arquiteturalpor 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

Sistema de Segurança

CentralDados

DadosDados

Dados

Monitoramento Anti-Aéreo(Plug-in)

Sistema de Detecçãode Intrusos

(Plug-in)

Monitoramento dasAtividades das

Estagiárias(Plug-in)

Sistema “Armageddon”de Detecção de Meteoros

(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

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

ProblemaComo 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

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

ProblemaComo 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 = ContratoAplicação Principal

Imple-mentation

Plug-InDefinition Framework

Interface

Plug-in

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

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

ProblemaComo um plug-in pode adicionar sua funcionalidade?

Também Conhecido ComoAplicação Principal, Contexto do Plug-in

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

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

ProblemaComo as melhorias funcionais podem se estender por múltiplas camadas?

Também Conhecido ComoOne Plug-in per Task

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

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

ProblemaComo 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