1 PADRÕES POSA Classificação dos Padrões Detalhamento dos Padrões Layers Broker MVC MicroKernel Todo-Parte Mestre-Escravo

1

PADRÕES POSA• Classificação dos Padrões• Detalhamento dos Padrões

•Layers•Broker•MVC•MicroKernel•Todo-Parte•Mestre-Escravo

2

ARQUITETURA DE SOFTWARE

[Thaís Batista]

Ponte entre os Requisitos e sua Implementação

3


[Thaís Batista]

Abstração que ajuda a gerenciar complexidade

Projeto Arquitetural do SoftwareEstrutura modular do softwareComponentesRelacionamento entre

componentes

4


[Thaís Batista]

Formada por várias visões Visão de Caso de Uso: casos de uso com

arquitetura mais significante; Visão Lógica: quantidade de camandas,

plataforma a ser utilizada, tecnologias, conteiners web, serviços.

Visão geral: visão física, banco de dados, servidores.

Visão de implantação: distribuição dos componentes.

5

PADRÕES POSA Os Padrões POSA são provenientes dos três

Livros “Pattern-Oriented Software Archicteture”:

POSA I : A System of Patterns; POSA II: Patterns for Networked and Concurrent

Objects; POSA III: Patterns for Resource Management ;

6

PADRÕES POSA - CLASSIFICAÇÃOOs padrões do POSA são divididos em

três grandes grupos:

Padrões Arquiteturais

Padrões de Projeto Idiomas

7

PADRÕES POSA - CLASSIFICAÇÃOPadrões Arquiteturais Estrutura de Alto-Nível; Contém um conjunto de sub-sistemas

pré-definidos; Define a responsabilidade de cada

sub-sistema;Detalha o relacionamento entre os

sub-sistemas;

8

PADRÕES POSA - CLASSIFICAÇÃOPadrões Arquiteturais Classificação

Da Lama à Estrutura: ajudam a evitar o excesso de componentes ou objetos. Suportam a decomposição de um sistema completo em sub-tarefas desse sistema. Padrão Layers; Padrão Pipes and Filters; Padrão Blackboard

Sistemas Distribuídos Broker

9

PADRÕES POSA - CLASSIFICAÇÃOPadrões Arquiteturais Classificação

Sistemas Interativos: interação homem-máquina. Model – View – Controller Presentation – Abstraction – Control

Sistemas Adaptáveis: suportam a adaptação de tecnologias e mudanças de requisitos funcionais. MicroKernel Reflection

10

PADRÕES POSA - CLASSIFICAÇÃOPadrões de Projeto Estrutura de Médio-Nível; Implementação independente de

linguagem de programação; Projetado para “Micro-Arquiteturas”

(algo entre um sub-systema e um componente individual);

11

PADRÕES POSA - CLASSIFICAÇÃO Padrões de Projeto Classificação Decomposição Estrutural

Whole-Part Organização do Trabalho

Master-Slave Controle de Acesso

Proxy Gerenciamento

Command Processor View Handler

Comunicação Forwarder-Receiver Client-Dispatcher-Server Publisher - Subscriber

12

PADRÕES POSA - CLASSIFICAÇÃOIdiomas Estrutura de Baixo-Nível (em

comparação com os demais);Disponibiliza um guia para

implementação dos componentes e relacionamento dos padrões;

Considera o padrão no nível da linguagem de programação (descreve o padrão usando construções próprias da linguagem de programação);

13

PADRÕES POSA - CLASSIFICAÇÃOIdiomas Estrutura de Baixo-Nível (em comparação

com os demais);Disponibiliza um guia para

implementação dos componentes e relacionamento dos padrões;

Considera o padrão no nível da linguagem de programação (descreve o padrão usando construções próprias da linguagem de programação);

Padrão Counted Pointer

14

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)

Ajuda a estruturar as aplicações que podem ser decompostas em grupos de sub-tarefas, onde cada grupo de sub-tarefas possui um nível de abstração particular;

Exemplo: Protocolos de Redes OSI

15

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)Problema

Imagine que esteja projetando um sistema cuja característica principal é uma mistura de assuntos de alto nível com assuntos de baixo nível, em que os assuntos de alto nível usam os assuntos de baixo nível. A parte de baixo nível está frequentemente perto do

hardware A parte de mais alto nível está frequentemente perto

do usuário O fluxo de comunicação tipicamente consiste de

pedidos fluindo do alto para o baixo níveis As respostas andam na direção contrária

16

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)Problema

Decompor um sistema, aumentar o nível de abstração e diminuir as dependências entre as partes;

17

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)Solução

Decompor em camadas de abstração de forma que uma camada não depende da superior e utiliza serviços apenas da camada imediatamente inferior;

18


1. Defina o critério de abstração para agrupar tarefas em camadas;

2. Determine o número de níveis de abstração (baseado no critério acima) Cada nível de abstração corresponde a uma

camada Às vezes não é simples decidir se deve haver

uma quebra de uma camada em subcamadas ou não Camadas demais podem afetar o overhead Camadas de menos comprometem a estrutura

19


3. Dê um nome e atribua tarefas a cada camada Para a camada de cima, a tarefa é a tarefa global do

sistema, do ponto de vista do usuário 4. Especifique os serviços

O princípio básico é de separar as camadas uma das outras

Nenhum módulo abrange duas camadas Tente manter mais riqueza acima e menos abaixo Isso ajuda a prover bons serviços de alto nível para

o programador "em cima"

20


5. Refine as Camadas 6. Especifique uma interface para

cada camada A camada J nada sabe sobre a camada J-1 e usa

uma interface para acessá-la; Pode usar o padrão Façade para organizar a

interface; 7. Estruture as camadas individuais

Quebre a camada em subsistemas (partições) menores se ela for complexa;

21


8. Especifique a comunicação entre camadas A camada J passa a informação necessária para a camada J-1 ao chamá-la

9. Desacople camadas adjacentes Evite situações em que a camada de baixo sabe algo sobre seus clientes (camada acima)

Acoplamento unidirecional é preferível

22


10. Projete uma estratégia de tratamento de erros O esforço de programação e overhead podem ser

grandes para tratar erros numa arquitetura em camadas

Um erro pode ser tratado na camada onde foi descoberto ou numa camada superior

No segundo caso, deve haver mapeamento para tornar o erro semanticamente reconhecível pela camada de cima;

Tente tratar erros na camada mais baixa possível Isso simplifica todas as camadas superiores que não

sabem nem devem saber do erro;

23

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)Estrutura

24

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)Estrutura

25

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)Exemplo

26

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas) Cada camada individual pode ser uma

entidade complexa consistindo de diferentes componentes

27

PADRÕES POSA – Padrões Arquiteturais Padrão Layers (Camadas) Camadas Implementação

Defina o critério de abstração para agrupar tarefas em camadas Exemplo: a distância do hardware pode formar os níveis

mais baixos e a complexidade conceitual os níveis mais altos

Determine o número de níveis de abstração de acordo com seu critério de abstração

Nomeie as camadas e determine as tarefas de cada uma delas A tarefa da camada mais alta é a percebida pelo cliente As tarefas das demais camadas visam ajudar a

realização da tarefa da camada mais alta

28

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)Camadas Implementação (Cont..)

Especifique os serviços Especifique uma interface para cada camada Refine cada camada:

Estruturação de cada camada individualmente Quando uma camada é complexa ela deve ser

separada em componentes individuais e cada componente pode seguir um padrão ou estilo diferente

29

PADRÕES POSA – Padrões Arquiteturais Padrão Layers (Camadas) Conseqüências

Reuso de Camadas Devido à boa encapsulação provida pelo uso de

interfaces;Suporte a padronização

Permite usar implementações de vários fornecedores;

Dificuldade de estabelecer a correta granularidade das camadas.

Menor eficiência Camadas adicionam overhead;

30

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)Exemplo Aplicação

Arquitetura 2 Camadas

31

PADRÕES POSA – Padrões ArquiteturaisPadrão Layers (Camadas)Exemplo Aplicação

Arquitetura 3 Camadas

32

PADRÕES POSA – Padrões ArquiteturaisPadrão Pipes and Filters O padrão arquitetural Pipes and Filters provê uma

estrutura para sistemas que processam um stream de dados. Cada passo do processamento é encapsulado através de “canos” entre “filtros” adjacentes. A recombinação de filtros permite que você construa famílias de sistemas relacionados.

Tipicamente divide a tarefa de um sistema em vários passos de processamento seqüencial.

Componentes: São chamados Filtros Tem um conjunto de entradas e um conjunto de saídas

33

PADRÕES POSA – Padrões ArquiteturaisPadrão Pipes and Filters

Conectores São chamados de Pipes; Servem como condutores, transmitindo a saída

de Filtro a outro;

pipefiltro

34

PADRÕES POSA – Padrões ArquiteturaisPadrão Pipes and FiltersSolução

O Pipes e Filters divide uma tarefa no sistemas em passos de processamento seqüencial. A saída de dados de um passo é a entrada do passo subseqüente.

Cada passo do processamento é implementado através de um componente filtro.

Um filtro consome e entrega dados incrementalmente.

35

PADRÕES POSA – Padrões ArquiteturaisPadrão Pipes and FiltersSolução

A entrada do sistema é realizada através de um Data Source, como um arquivo texto, por exemplo.

A saída é realizada em um Data Sink, tal como um arquivo, programa de animação, etc.

Os filtros, data sources e data sink são conectados sequencialmente através dos pipes.

Cada pipe implementa os fluxos de dados entre os passos adjacentes.

A seqüência de filtros combinadas por pipes é chamada de processamento pipeline.

36


37


38

PADRÕES POSA – Padrões ArquiteturaisPadrão Pipes and FiltersEstrutura

39

PADRÕES POSA – Padrões ArquiteturaisPadrão Pipes and FiltersEstrutura

40

PADRÕES POSA – Padrões ArquiteturaisPadrão Pipes and Filters -

Implementação Divida as tarefas do sistema em uma seqüência

de estágios de processamento: Cada estágio deve depender apenas da saída do seu

predecessor direto Todos os estágios são conectados pelo fluxo de dados

Defina o formato de dados a ser passado ao longo de cada pipe

Decida como implementar cada conexão com pipe Implica em decidir se os filtros são componentes

ativos ou passivos

41

PADRÕES POSA – Padrões ArquiteturaisPadrão Pipes and Filters -

ImplementaçãoConseqüências

Ausência da necessidade de arquivos intermediários.

Flexibilidade de trocar um filtro: filtros possuem interface simples e podem facilmente ser trocados dentro do processamento.

Reuso de componentes Filtros;

42

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard Problema

Transformar dados brutos em estruturas de dados de alto-nível como diagramas, tabelas ou frases em inglês.

Reconhecimento de imagem, reconhecimento de fala são domínios em que o problema ocorre.

São caracterizados por problemas que, quando decompostos em subproblemas, abrange vários campos. As soluções para os problemas parciais requerem diferentes representações e paradigmas.

43

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard Uma coleção de programas independentes que

trabalham cooperativamente em uma estrutura de dados comum (blackboard) Cada subsistema é especialista em resolver

determinada parte da tarefa completa. Todos os subsistemas trabalham juntos para resolver o problema.

Vários subsistemas especializados agregam seu conhecimento para conseguir uma possível solução aproximada para o problema

Os subsistemas especializados são independentes uns dos outros

BlackBoard = repositório de dados compartilhados

44

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard Os subsistemas não se comunicam uns com

os outros e nem seguem uma seqüência pré-determinada. Ao invés disso, o sistema principal é determinado pela progresso do estado corrente de cada subsistema.

Um controle de acesso central avalia o estado corrente do processamento e coordena os subsistemas especializados.

45

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard Justificativa da denominação BlackBoard

Herda da idéia de pessoas que trabalham juntas na frente de um quadro (blackboard) para resolver uma tarefa.

46

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard

47

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard Componentes:

Origem do Conhecimento: elementos independentes que resolvem aspectos específicos do problema. Juntos modelam o domínio do problema. Nenhum pode resolver a tarefa do sistema sozinho;

Blackboard: elemento central de armazenamento. Armazena dados para resolver o problema que são modificados pelos componentes origens do conhecimento;

Controle: executa um loop que monitora o estado do blackboard e decide qual a próxima ação que tipicamente é o escalonamento de algum elemento origem do conhecimento;

48

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoardComponentes:

O main loop do componente Controle é iniciado;

Controle invoca o procedimento ProximaOrigem() para selecionar o componente Origem do Conhecimento;

ProximaOrigem() determina quais Origem do Conhecimento são potenciais candidatos para encontrar a solução;

Origem do Conhecimento invoca Inspect() para verificar as soluções correntes no blackboard e Update() para realizar mudanças nos dados do BlackBoad;

49

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard

50

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard Tem sido utilizado em aplicações que

necessitam de complexas interpretações de reconhecimento de sinais como reconhecimento de fala, de padrões, de imagem;

51

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard – Implementação Defina o problema:

Especifique o domínio do problema e os campos de conhecimento necessários para encontrar uma solução

Defina a entrada e saída desejável do sistema Defina o espaço de solução para o problema Divida o processo da solução em passos:

Especifique os tipos de conhecimento que podem ser usados para excluir partes do espaço de solução

Divida o conhecimento em origens de conhecimento especializadas

52

PADRÕES POSA – Padrões ArquiteturaisPadrão BlackBoard –

Implementação Especifique o controle do sistema

Determine quais origens do conhecimento tem permissão para realizar mudanças no blackboard

Associe as categorias de mudanças no blackboard com um conjunto de possíveis origens do conhecimento

Implemente as origens do conhecimento Divida-os em partes de condição e partes de

ação

53

PADRÕES POSA – Padrões ArquiteturaisPadrão Broker O Padrão Broker é utilizado para estruturar

sistemas distribuídos separando componentes que interagem através de chamadas remota de serviços. O broker é responsável por coordenar a

comunicação, encaminhado as solicitações e transmitido os resultados ou exceções.

54

PADRÕES POSA – Padrões ArquiteturaisPadrão Broker Contexto:

Construção de um sistema complexo como um conjunto de componentes distribuídos que necessitam comunicar-se. São necessários serviços para adicionar,remover, trocar, ativar e localizar componentes.

Os componentes devem ser capazes de acessar serviços oferecidos por outros através de invocações remotas e transparentes realizadas via um componente Broker que desacopla servidores de clientes.

55

PADRÕES POSA – Padrões ArquiteturaisPadrão Broker Usado para estruturar sistemas distribuídos com

componentes desacoplados que interagem por invocações remotas ao serviço

O componente Broker é responsável por coordenar a comunicação entre os componentes distribuídos, possibilitando assim, maior desacoplamento entre clientes e servidores e independência de plataforma (sistemas heterogêneos).

Os servidores se registram no broker, assim, seus serviços ficam disponíveis para os clientes através de interfaces.

56

PADRÕES POSA – Padrões ArquiteturaisPadrão Broker Os servidores se registram no broker, assim,

seus serviços ficam disponíveis para os clientes através de interfaces.

Os clientes acessam as funcionalidades dos servidores através do envio de requisição ao Broker.

Entre as tarefas do Broker estão: localizar o servidor apropriado, encaminhar as requisições para o servidor e transmitir os resultados de volta a cliente.

57

PADRÕES POSA – Padrões ArquiteturaisPadrão BrokerEstrutura

58

PADRÕES POSA – Padrões ArquiteturaisPadrão Broker

59

PADRÕES POSA – Padrões ArquiteturaisPadrão Broker

60

PADRÕES POSA – Padrões ArquiteturaisPadrão Broker – Implementação Defina um modelo de objetos ou use um

modeloexistente; Defina qual tipo de interoperabilidade entre

componentes o sistema deve oferecer Em geral usa-se uma Linguagem de Definição de

Interfaces Especifique a API que o componente Broker

oferece para interagir com clientes e servidores

61

PADRÕES POSA – Padrões ArquiteturaisPadrão Broker – Implementação Projete o componente Broker

Especifique detalhes da interação do cliente com o servidor

Especifique o comportamento do sistema em caso de falhas

62

PADRÕES POSA – Padrões Arquiteturais Padrão Model-View-ControlContexto: Aplicações interativas com

interfaces de usuário gráficas flexíveis e controladas pelo usuários.

Problema: Estender a funcionalidade de uma aplicação através apenas da modificação dos menus, da visão do usuário.

63

PADRÕES POSA – Padrões Arquiteturais Padrão Model-View-ControlSolução: O padrão MVC divide a

aplicação em três camadas: Entrada (View), Processamento (Controller) e Saída (Model).

Utilizar o padrão Observer e estendê-lo para permitir o controle das janelas baseado-em-eventos. O Padrão MVC estende o Observer incorporando um elemento controlador (Controller).

64

PADRÕES POSA – Padrões Arquiteturais Padrão Model-View-ControlO Modelo diz respeito ao

gerenciamento da informação e ao comportamento da aplicação. O Modelo seria uma mera representação do conteúdo do banco de dados ou entidades de domínio e pelas regras de negócio intrínsecas a essas entidades.

A Visão é responsável por apresentar as entidades de domínio ao usuário, constituindo a parte visível do sistema.

65

PADRÕES POSA – Padrões Arquiteturais Padrão Model-View-ControlO Controle garante o total

desacoplamento entre essas duas partes principais da aplicação. O Controle interpreta as ações do usuário provenientes da Visão e comanda a execução das regras de negócio contidas no Modelo, além disso, comanda a Visão para que ela apresente adequadamente a informação ao usuário.

66

PADRÕES POSA – Padrões ArquiteturaisPadrão Model-View-Control

67

PADRÕES POSA – Padrões ArquiteturaisPadrão Model-View-ControlView - Não esta preocupada em como

a informação foi obtida ou onde ela foi obtida apenas exibe a informaçãoInclui os elementos de exibição no

cliente : HTML , XML , ASP , Applets .É a camada de interface com o usuário.É usada para receber a entrada de

dados e apresentar o resultado

68

PADRÕES POSA – Padrões ArquiteturaisPadrão Model-View-Control Model - É o coração da aplicação .

Responsável por tudo que a aplicação vai fazer.modela os dados e o comportamento por

atrás do processo de negóciosse preocupa apenas com o armazenamento

, manipulação e geração de dadosÉ um encapsulamento de dados e de

comportamento independente da apresentação.

69

PADRÕES POSA – Padrões ArquiteturaisPadrão Model-View-ControlCamada de Controle - determina

o fluxo da apresentação servindo como uma camada intermediária entre a camada de apresentação e a lógica.controla e mapeia as ações.

70


71

PADRÕES POSA – Padrões Arquiteturais Padrão Model-View-Control

[http://www.inf.ufes.br/~vsouza/files/DesignPatterns05.pdf] - Referência

72


73


74

PADRÕES POSA – Padrões Arquiteturais Padrão Model-View-Control Conseqüências Como o modelo MVC gerencia múltiplos

visualizadores usando o mesmo modelo é fácil manter , testar e atualizar sistemas múltiplos.

É muito simples incluir novos clientes apenas incluindo seus visualizadores e controles.

Torna a aplicação escalável. É possível ter desenvolvimento em paralelo

para o modelo , visão e controle pois são independentes.

75

PADRÕES POSA – Padrões Arquiteturais Padrão Presentation-Abstraction-

Control O PAC possui uma arquitetura que vai além da

arquitetura do MVC. O MVC é restrito a GUI’s com uma ou mais

visões em cima do mesmo modelo. Se o modelo consistir de subestruturas que

todas requerem uma forma especial de interação, então é necessário uma estrutura de GUI’s mais complexa.

O PAC não tem o modelo como um componente principal.

Para isso, possui uma estrutura hierárquica de componentes PAC.

76


Control Cada componente PAC é constituído

de três items: Presentation Abstraction Control

77


Control Presentation: é similar ao View do

MVC. Ele mostra as informações provenientes da camada Abstraction.

Abstraction: contém dados como o Model do MVC. Entretanto, é parte de uma estrutura de dados maior, mais completa.

Control: é um pouco similar ao Control do MVC. Processa eventos externos e atualiza o modelo. A diferença pro MVC é que no PAC o Control passa as requisições para o seu PAC pai.

78

PADRÕES POSA – Padrões ArquiteturaisPadrão Presentation-Abstraction-

Control O PAC agrupa os componentes Controlador e

Visão dentro de um único componente chamado Apresentação

79

PADRÕES POSA – Padrões ArquiteturaisPadrão Presentation-Abstraction-

Control Comparação: O MVC é assim....

80


Control

81


Control

82


Control

Alto-Nível

Nível Intermediário

83


Control A camada Control do pai cria os PAC

filhos quando o programa é iniciado. Quando o Control recebe um evento de

um usuário (1), ele pode atualizar a Presentation (2a) e/ou Abstraction (2b).

Então o Control envia o envio de mudança para seu PAC pai (3).

O Pai atualiza seus filhos (5) e atualiza a Presentation (6a) e/ou Abstraction (6b).

Depois da atualização de todos os filhos, os pais são atualizados (7).

84


Control PAC nível-topo:

Prover a funcionalidade principal Controlar a hierarquia dos PAC

PAC nível intermediário Coordenar os PACs nível base Compor PACs bases em uma única

unidade mais abstrata PAC nível base

Prover uma visão específica Prover uma serviço do sistema

85


Control• Presentation

-Visualização e interação com o usuário;

• Control-Interação com o componente de nívelIntermediário;

• Abstraction-Mantém informaçõessobre os dados a serem exibidos;

86

PADRÕES POSA – Padrões Arquiteturais Padrão MicroKernel Se aplicam a sistemas de software que

devem estar aptos a se adaptarem a mudanças nos requisitos do sistema.

Separam um núcleo funcional mínimo das funcionalidades estendidas e das partes específicas do cliente;

[http://disciplinas.lia.ufc.br/tasi061/arquivos/POSA.ppt]

87

PADRÕES POSA – Padrões ArquiteturaisPadrão MicroKernelO uso de micro-núcleos se aplica a

sistemas que precisam ser adaptados para mudanças nos requisitos.

Premissa básica do bom programador OO: Design for Change;Exemplo: Sistema operacional

hipotético Hydra no qual podemos executar aplicação Windows ou UNIX Systen ;

88

PADRÕES POSA – Padrões ArquiteturaisPadrão MicroKernelContexto: Desenvolvimento de

várias aplicações que utilizam interfaces similares baseadas numa mesma funcionalidade;

89

PADRÕES POSA – Padrões Arquiteturais Padrão MicroKernelProblema:

A necessidade de adaptação contínua à evolução de hardwares e softwares;

A necessidade de ser portável, extensível e adaptável para permitir a integração com novas tecnologias.

90

PADRÕES POSA – Padrões Arquiteturais Padrão MicroKernelProblema:

Software básico é utilizado ao longo de muitos anos, às vezes décadas. Ao longo da sua vida, acontecem muitas mudanças no hardware, nos modelos de programação, nos tipos de bibliotecas utilizadas, e nos requisitos das aplicações;

O núcleo da funcionalidade do software básico deve ser encapsulado em um componente que seja o menor possível e que consuma o mínimo possível de recursos computacionais para não prejudicar as aplicações para as quais ele oferece suporte;

91

PADRÕES POSA – Padrões Arquiteturais Padrão MicroKernelSolução:

Encapsule os serviços fundamentais da sua plataforma em um componente chamado de “micronúcleo”;

O micronúcleo oferece os seus serviços básicos através de sua interface bem definida;

“Servidores Internos”: funcionalidade estendida do micronúcleo, que não é essencial e que não pode ser implementada sem aumentar a complexidade do micronúcleo

92

PADRÕES POSA – Padrões ArquiteturaisPadrão MicroKernelSolução:

Outros componentes chamados de “servidores externos” utilizam a interface do micronúcleo para prover outros tipos de interfaces baseadas na funcionalidade exportada pelo micronúcleo.

Os clientes (aplicações) interagem com o sistema através dos “servidores externos”;

93

PADRÕES POSA – Padrões ArquiteturaisPadrão MicroKernel

94

PADRÕES POSA – Padrões ArquiteturaisPadrão MicroKernel Participantes

MicroKernel: encapsula as diversas dependências do sistema, externalizando uma interface para prover acesso aos seus serviços. Ele implementa os serviços fundamentais do sistema que não podem ser exportados para outros componentes. Assim, cabe a este componente o controle e a coordenação do acesso aos recursos do sistema.

95

PADRÕES POSA – Padrões ArquiteturaisPadrão MicroKernelParticipantes

Servidor Interno:Quando certa funcionalidade não tem como ser implementada em seu componente microkernel sem resultar em um aumento da complexidade e do tamanho deste, então ela deve ser exportada para um servidor interno(internal server) que proverá tal serviço ao componente. Só pode ser acessado pelo microkernel.

96

PADRÕES POSA – Padrões ArquiteturaisPadrão

MicroKernel Participantes

Servidor Externo: Os servidores externos usam interfaces para expor determinados serviços do núcleo funcional mínimo. Eles trabalham recebendo requisições do cliente, invocando serviço pedido ao microkernel e retornando os resultados para o cliente.

97

PADRÕES POSA – Padrões ArquiteturaisPadrão MicroKernelParticipantes

Cliente: são as aplicações em si que se associam com um – e apenas um – servidor externo, acessando a sua interface, a fim de usufruir dos serviços providos pelo microkernel.

Um cliente que necessita acessar um serviço do microkernel deve faze-lo por meio de um acesso a um servidor externo. Este servidor externo encaminhará a requisição para o microkernel, que em seguida retornará o serviço ao cliente.

98

PADRÕES POSA – Padrões Arquiteturais Padrão MicroKernel Participantes

Adaptador: Para evitar que os clientes tenham que conhecer a interface dos servidores externos e sejam obrigados a implementá-la diretamente, uma classe auxiliar chamada de Adaptador é utilizada a fim de esconder estas peculiaridades do cliente.

Assim, quando um cliente faz uma requisição de serviço do microkernel, é responsabilidade do adaptador tratar e encaminhar esta chamada de forma adequada ao servidor apropriado.

99

PADRÕES POSA – Padrões ArquiteturaisPadrão MicroKernelConseqüências: Portabilidade; Flexibilidade e extensibilidade através da

implementação de um novo servidor externo;

Separação de regras e mecanismos. Escalabilidade; Confiança; Transparência.

100

PADRÕES POSA – Padrões ArquiteturaisPadrão ReflectionPermite mudar as estruturas e o

comportamento de um sistema de software dinamicamente;

Suporta a modificação dos aspectos funcionais, tais como estruturas de tipos e mecanismos de chamada de função;

101

PADRÕES POSA – Padrões ArquiteturaisPadrão Reflection Exemplo:

Considere um sistema em C++ que necessita que seus objetos sejam guardados no disco de forma persistente.

Poderíamos implementar um método para ler e escrever objetos do disco para cada tipo de objeto: obviamente ruim.

Poderíamos oferecer uma superclasse básica para objetos persistentes da qual todos os objetos persistentes deveriam herdar. As subclasses deveriam sobrecarregar os métodos para leitura e escrita do disco. Problema: mudanças nas classes nos forçariam a atualizar estes métodos manualmente, ou seja, persistência e a funcionalidade básica da aplicação estão fortemente acopladas/misturadas.

Queremos desenvolver um mecanismo de persistência desacoplado da funcionalidade das aplicações.

Este mecanismo deveria ser capaz de enxergar em tempo de execução a estrutura interna dos objetos e decidir o que deve ser armazenado em disco.

102

PADRÕES POSA – Padrões ArquiteturaisPadrão Reflection Contexto

Construção de sistemas que permitem, a priori, a sua própria modificação.

103

PADRÕES POSA – Padrões ArquiteturaisPadrão Reflection Problema

104

PADRÕES POSA – Padrões ArquiteturaisPadrão Reflection Problema: Os requisitos para uma dada aplicação evoluem ao longo do tempo. Forças:

Mudar software convencional (que não está preparado para mudanças) é muito difícil e sujeito a erros;

Sistemas de software adaptáveis em geral tem uma estrutura interna complexa;

Quanto maior o número de mecanismos diferentes que aplicamos em um sistema para torná-lo mais adaptável, mais complexo ele fica;

As mudanças exigidas podem ser de muitos tipos; desde adicionar um pequeno atalho a uma seqüência de comandos até mudar completamente uma aplicação para adaptá-la a um cliente específico.

105

PADRÕES POSA – Padrões ArquiteturaisPadrão Reflection Solução: Faça com que o software seja ciente de si mesmo

(self-aware), que ele conheça a sua própria estrutura e que seja possível inspecionar e modificar a sua estrutura interna e comportamento.

106

PADRÕES POSA – Padrões ArquiteturaisPadrão ReflectionA aplicação é dividida em duas partes:

Um meta-nível fornece informações a respeito das propriedades selecionadas do sistema e torna o software consciente disso;

Oferece uma auto-representação do software para que ele tenha conhecimento da sua própria estrutura e comportamento. Ele é composto de meta-objetos.

107

PADRÕES POSA – Padrões Arquiteturais Padrão Reflection

Um nível-base inclui a lógica da aplicação. A implementação é feita sobre o meta-nível; define a lógica da aplicação e é composto pelos objetos da aplicação (por exemplo, os componentes). Os objetos utilizam os meta-objetos para os aspectos não-funcionais.

108

PADRÕES POSA – Padrões ArquiteturaisPadrão ReflectionUma interface é especificada para

manipulação dos meta-objetos do meta-nível através de um protocolo de meta-objetos;

Guardam informações sobre os tipos utilizados, os algoritmos utilizados, os mecanismos de comunicação utilizados, os mecanismos de persistência utilizados, etc.

109

PADRÕES POSA – Padrões ArquiteturaisPadrão Reflection

Class ColaboradoresBase Level Meta Level

Responsability

Implementa a lógica da aplicação;

Usa informações provenientes do meta level;

Class ColaboradoresMeta Level Base Level

ResponsabilityEncapsula sistemas internos

que podem mudar;

Provê uma interface para facilitar as modificações do meta level

Class ColaboradoresMetaobjetc Protocol Meta Level / Base Level

ResponsabilityOferece uma interface para especificar as mudanças do meta level;

Executa mudanças especificadas

110

PADRÕES POSA – Padrões ArquiteturaisPadrão ReflectionConseqüências

Nenhuma modificação de código explícita: ao extender o software, passe o novo código para o meta-nível como um parâmetro do meta-objeto. O meta-objeto é responsável por entregar as mudanças.

Facilidade ao mudar o software: o meta-objeto encapsula de forma segura as mudanças.

Documents

1 PADRÕES POSA Classificação dos Padrões Detalhamento dos Padrões Layers Broker MVC MicroKernel Todo-Parte Mestre-Escravo