1 pattern languages of program design 5 (plopd5) editado por dragos manolescu, markus voelter e...
TRANSCRIPT
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