Pattern-Oriented Software Architecture (POSA)
Padrão orientado para arquitetura de software
O padrão POSA está classificad...
1. Reuso de Camadas
2. Suporte a padronização
3. Dificuldade de estabelecer a correta granularidade das camadas
4. Menor e...
Uma coleção de programas independentes que trabalham cooperativamente em uma
estrutura de dados comum (blackboard) .
Carac...
◦ Localizar o servidor apropriado
◦ Repassar a requisição ao servidor
◦ Transmitir resultados e exceções de volta ao clien...
◦ Presentation-Abstraction-Control
Define uma estrutura para sistemas na forma de uma hierarquia de agentes cooperativos.
...
Aplicação deste padrão
O uso de micronúcleos se aplica a sistemas que precisam ser adaptados para mudanças nos requisitos....
Próximos SlideShares
Carregando em…5
×

Padrões Arquiteturais - POSA

281 visualizações

Publicada em

Resumos dos padrões arquiteurais - POSA

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
281
No SlideShare
0
A partir de incorporações
0
Número de incorporações
7
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Padrões Arquiteturais - POSA

  1. 1. Pattern-Oriented Software Architecture (POSA) Padrão orientado para arquitetura de software O padrão POSA está classificado em três categorias: 1. Padrões Arquiteturais: são estruturas de alto nível, contém um conjunto de subsistemas pré-definidos que se relacionam, onde cada subsistema tem sua responsabilidade. Arquiteturas por tipo de sistema: Estrutura geral Sistemas Distribuídos Sistemas Interativos Sistemas Adaptáveis Layers Broker Model-View-Controller Microkernel Pipes and Filters Presentation-Abstraction- Control Reflection Blackboard 1.1. Estrutura geral o Layers Ajuda a estruturar as aplicações que podem ser decompostas em grupos de subtarefas, onde cada grupo de subtarefas possui um nível de abstração particular; Problema ◦ Decompor um sistema, aumentar o nível de abstração e diminuir as dependências entre as partes 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 Consequências Características: o Forte acoplamento dentro de um subsistema o Fraco acoplamento entre subsistemas o Camadas se comunicam apenas com as camadas "vizinhas" o As camadas mais a cima estão mais próximas do usuário.
  2. 2. 1. Reuso de Camadas 2. Suporte a padronização 3. Dificuldade de estabelecer a correta granularidade das camadas 4. Menor eficiência o Pipes e Filtros Pipes e Filtros é um estilo arquitetural (Engenharia de Software) composto por uma cadeia de elementos de processamento, dispostos de forma tal que a saída de cada elemento é a entrada do próximo. É considerado como uma rede pela qual os dados fluem de uma extremidade (origem) à outra (destino). O fluxo de dados se dá através de pipes (canos) e os dados sofrem transformações quando processados nos filtros. Vantagem Desvantagem o Encapsulamento o Difícil criar aplicações interativas. o Alta coesão o Geralmente filtros exigem que os dados sejam representados no denominador comum mais baixo, tipicamente fluxos de bytes ou caracteres. o Baixo acoplamento. o pode introduzir sobrecarga para analisar o fluxo de dados, podendo haver a exigência de um buffer de tamanho limitado, podendo causar um deadlock. o Facilmente estendido e modificado o Todas essas desvantagens geram uma baixa performance. o Blackboard – Repositório de dados compartilhado Filtro  Obtém dados de entrada.  Executa uma função sobre os dados de entrada.  Fornece dados de saída. Pipe  Transfere dados.  Bufferiza dados.  Sincroniza componentes vizinhos ativos.
  3. 3. Uma coleção de programas independentes que trabalham cooperativamente em uma estrutura de dados comum (blackboard) . Características: 1. Cada subsistema é especialista em resolver determinada parte da tarefa completa. 2. Todos os subsistemas trabalham juntos para resolver o problema. 3. Vários subsistemas especializados agregam seu conhecimento para conseguir uma possível solução aproximada para o problema. 4. Os subsistemas especializ ados são independentes uns dos outros Componentes: 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 Componentes: ◦ O main loop do componente Controle é iniciado ◦ Controle invoca o procedimento ProximaOrigem() para selecionar o componente Origem do Conhecimento ◦ ProximaOrigem() determina quais Origens 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 BlackBoard 1.2. Sistema Distribuído ◦ Padrão Broker Seu ambiente é um sistema distribuído e possivelmente heterogêneo, com componentes independentes que cooperam entre si. Utilize um componente broker (intermediário) para alcançar melhor desacoplamento entre clientes e servidores. As tarefas do broker incluem:
  4. 4. ◦ Localizar o servidor apropriado ◦ Repassar a requisição ao servidor ◦ Transmitir resultados e exceções de volta ao cliente. O padrão arquitetural Broker compreende seis tipos de componentes participantes: 1. clientes, 2. servidores, 3. brokers, 4. bridges (pontes), 5. proxies (representantes) de cliente (client-side proxies) 6. proxies de servidor (server-side proxies). O maior exemplo que podemos citar do uso deste padrão é A WWW, pois é o maior sistema de Broker existente no mundo. 1.3. Sistemas Interativos ◦ MVC (Model-View-Controller) O padrão arquitetural Model-View-Controller (MVC) é uma forma de quebrar uma aplicação,ou até mesmo um pedaço da interface de uma aplicação,em três partes: o modelo, a visão e o controlador. Estrutura Modelo (model): Provê o núcleo funcional da aplicação, registra visões e controladores dependentes e notifica componentes dependentes sobre mudanças de dados. Visão (view): Cria e inicializa seu controlador associado, exibe informações ao usuário, implementa o procedimento de atualização e busca dados do modelo. Controlador (controller): Recebe entrada dos usuários como eventos, traduz eventos em requisições de serviços para o modelo ou requisições de apresentação para a visão e implementa o procedimento de atualização, se solicitado.
  5. 5. ◦ Presentation-Abstraction-Control Define uma estrutura para sistemas na forma de uma hierarquia de agentes cooperativos. Adequado para sistemas interativos, onde cada agente é responsável por um aspecto específico da funcionalidade da aplicação e é composto por três componentes: apresentação, abstração e controle. Presentation: similar ao View do MVC, 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. Estrutura: 1.1. Sistemas Adaptáveis ◦ Microkernel Encapsule os serviços fundamentais da sua plataforma em um componente chamado "micronúcleo". O micronúcleo oferece os seus serviços básicos através de sua interface bem definida. Nele a funcionalidade que não é essenciale que não pode ser implementada sem aumentar a complexidade do micronúcleo deve ser implementada em "servidores internos" que estendem a funcionalidade do micronúcleo. Outros componentes são chamados de "servidores externos" utilizam a interface do micronúcleopara 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.  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 um serviço do sistema
  6. 6. Aplicação deste padrão O uso de micronúcleos se aplica a sistemas que precisam ser adaptados para mudanças nos requisitos. A Premissa básica do bom programador OO: Design for Change. O núcleo da funcionalidade de um 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. Exemplos:  Sistema operacional hipotético Hydra no qual podemos executar aplicações Windows, UNIX System V ou NeXTSTEP simultaneamente em diferentes janelas.  Sistemas operacionais baseados em micronúcleos:  Banco de Dados basedo em micronúcleo:  Middleware de Comunicação:  Servidor de Aplicações:  Plataforma para criação de aplicações locais  Eclipse ◦ Reflection Construção de sistemas que permitem, a priori, a sua própria modificação. 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 Características: ◦ 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. ◦ Um nível-base incluem 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

×