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

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

ARQUITETURA DE SOFTWARE
Ponte entre os Requisitos e sua Implementação [Thaís Batista]

Abstração que ajuda a gerenciar complexidade Projeto Arquitetural do Software Estrutura modular do software Componentes Relacionamento entre componentes [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. [Thaís Batista]

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 ;

PADRÕES POSA - CLASSIFICAÇÃO
Os padrões do POSA são divididos em três grandes grupos: Padrões Arquiteturais Padrões de Projeto Idiomas

Padrões Arquiteturais Estrutura de Alto-Nível; Contém um conjunto de sub-sistemas pré- definidos; Define a responsabilidade de cada subsistema; Detalha o relacionamento entre os subsistemas;

Padrõ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

Padrõ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

Padrõ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);

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

Idiomas 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);

Idiomas 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

PADRÕES POSA – Padrões Arquiteturais
Padrã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

Padrã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

Padrão Layers (Camadas) Problema Decompor um sistema, aumentar o nível de abstração e diminuir as dependências entre as partes;

Padrã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;

Padrão Layers (Camadas) Solução 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

Padrão Layers (Camadas) Solução 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"

Padrão Layers (Camadas) Solução 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;

Padrão Layers (Camadas) Solução 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

Padrão Layers (Camadas) Solução 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;

Padrão Layers (Camadas) Estrutura

Padrão Layers (Camadas) Exemplo

Padrão Layers (Camadas) Cada camada individual pode ser uma entidade complexa consistindo de diferentes componentes

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

Padrã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

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;

Padrão Layers (Camadas) Exemplo Aplicação Arquitetura 2 Camadas

Padrão Layers (Camadas) Exemplo Aplicação Arquitetura 3 Camadas

Padrã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

Padrão Pipes and Filters Conectores São chamados de Pipes; Servem como condutores, transmitindo a saída de Filtro a outro; pipe filtro

Padrão Pipes and Filters Soluçã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.

Padrão Pipes and Filters Soluçã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.

Padrão Pipes and Filters

Padrão Pipes and Filters Estrutura

Padrã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

Padrão Pipes and Filters - Implementação Conseqüê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;

Padrã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.

Padrã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

Padrã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.

Padrã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.

Padrão BlackBoard

Padrã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;

Padrão BlackBoard Componentes: 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;

Padrão BlackBoard

Padrã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;

Padrã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

Padrã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

Padrã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.

Padrã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.

Padrã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.

Padrã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.

Padrão Broker Estrutura

Padrão Broker

Padrão Broker – Implementação Defina um modelo de objetos ou use um modelo existente; 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

Padrã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

Padrão Model-View-Control Contexto: 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.

Padrão Model-View-Control Soluçã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).

Padrão Model-View-Control O 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.

Padrão Model-View-Control O 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.

Padrão Model-View-Control

Padrão Model-View-Control View - Não esta preocupada em como a informação foi obtida ou onde ela foi obtida apenas exibe a informação Inclui 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

Padrã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ócios se preocupa apenas com o armazenamento , manipulação e geração de dados É um encapsulamento de dados e de comportamento independente da apresentação.

Padrão Model-View-Control Camada 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.

Padrão Model-View-Control [ - Referência

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.

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.

Padrão Presentation-Abstraction- Control Cada componente PAC é constituído de três items: Presentation Abstraction Control

Padrão Presentation-Abstraction- 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.

Padrão Presentation-Abstraction-Control O PAC agrupa os componentes Controlador e Visão dentro de um único componente chamado Apresentação

Padrão Presentation-Abstraction-Control Comparação: O MVC é assim....

Padrão Presentation-Abstraction- Control

Padrão Presentation-Abstraction- Control Nível Intermediário Alto-Nível

Padrão Presentation-Abstraction- 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).

Padrão Presentation-Abstraction- 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

Padrão Presentation-Abstraction- Control Presentation -Visualização e interação com o usuário; Control Interação com o componente de nível Intermediário; Abstraction -Mantém informações sobre os dados a serem exibidos;

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; [

Padrão MicroKernel O 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 ;

Padrão MicroKernel Contexto: Desenvolvimento de várias aplicações que utilizam interfaces similares baseadas numa mesma funcionalidade;

Padrão MicroKernel Problema: 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.

Padrão MicroKernel Problema: 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;

Padrão MicroKernel Soluçã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

Padrão MicroKernel Soluçã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”;

Padrão MicroKernel

Padrã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.

Padrão MicroKernel Participantes 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.

Padrã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.

Padrão MicroKernel Participantes 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.

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.

Padrão MicroKernel Conseqüê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.

Padrão Reflection Permite 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;

Padrã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.

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

Padrão Reflection Problema

Padrã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.

Padrã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.

Padrão Reflection A 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.

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.

Padrão Reflection Uma 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.

Padrão Reflection Class Colaboradores Base Level Meta Level Responsability Implementa a lógica da aplicação; Usa informações provenientes do meta level; Class Colaboradores Meta Level Base Level Responsability Encapsula sistemas internos que podem mudar; Provê uma interface para facilitar as modificações do meta level Class Colaboradores Metaobjetc Protocol Meta Level / Base Level Responsability Oferece uma interface para especificar as mudanças do meta level; Executa mudanças especificadas

Padrão Reflection Conseqüê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.

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

Apresentações semelhantes

Apresentação em tema: "PADRÕES POSA Classificação dos Padrões Detalhamento dos Padrões Layers"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

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

Apresentações semelhantes

Apresentação em tema: "PADRÕES POSA Classificação dos Padrões Detalhamento dos Padrões Layers"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback