Carregar apresentação
A apresentação está carregando. Por favor, espere
1
Estilos Arquiteturais
Silvia Regina Vergilio
2
Estilos e padrões arquiteturais
Estilos arquiteturais Definem meios de selecionar e apresentar blocos de construção de arquitetura Padrões arquiteturais Projetos de alto nível, testados e validados, de blocos de construção de arquitetura Shaw, M., Garlan, D. Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1966 F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad e M. Stahl. Pattern-Oriented Software Architecture - A System of Patterns, NY: John Wiley and Sons, Inc. 1996 Shaw, M., Garlan, D. Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1966. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad e M. Stahl. Pattern-Oriented Software Architecture - A System of Patterns, NY: John Wiley and Sons, Inc. 1996
3
Categorias de Estilos de Arquiteturas
Estrutura (“From mud to structure”)- oferecem decomposição controlada das tarefas em sub-tarefas. Consideram requisitos estáveis e bem definidos. Sistemas distribuídos – aplicações distribuídas Sistemas interativos – interação HM. Sistemas adaptáveis – oferecem suporte para extensão e adaptação de aplicações devido a tecnologias e mudança de requisitos. “From mud to structure”: oferece decomposição controlada das tarefas em subtarefas cooperativas. Antes de projetar um sistema, coleta-se os requisitos, transformando-os em especificações. É considerado que os requisitos estão bem definidos e estáveis. Inclui os padrões Camada (Layers), Canos e Filtros (Pipes and Filters) e Blackboard que estão descritos na tabela 3.1. • Sistemas distribuídos: fornece uma completa estrutura para aplicações distribuídas. Inclui o padrão Broker que está descrito na tabela 3.2. • Sistemas interativos: oferece suporte para a estruturação de sistemas que caracterizam-se como interação homem-máquina. Inclui os padrões Model-View- Controller e Presentation-Abstraction-Control que estão descritos na tabela 3.3. • Sistemas adaptáveis: oferece suporte para a extensão e adaptação de aplicações a tecnologias e mudanças de requisitos funcionais. Inclui os padrões Reflexão (Reflection) e Micro-núcleo (Microkernel) que estão descritos na tabela 3.4. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad e M. Stahl. Pattern-Oriented Software Architecture - A System of Patterns, NY: John Wiley and Sons, Inc. 1996 D. Garlan and Mary Shaw. An introduction to software architecture. Technical Report- CMU-CS-94166,Carnegie Mellon University, January 1994.
4
Estilos Arquiteturais: Taxonomia
Sistemas de Fluxo de Dados Sistemas de Chamada e Retorno Componentes Independen-tes Máquinas Virtuais Sistemas Centrados em Dados Seqüenciais Batch Programa Principal e Sub-rotinas Processos Comunican-tes Interpreta-dor Bancos de Dados Pipes & Filters Sistemas OO Invocação Implícita (ou Sistemas Baseados em Eventos) Sistemas Baseados em Regras Sistemas de Hipertexto Camadas Blackboards (Quadro-Negro) Extraído de (SHAW e GARLAN, 1996)
5
Estilos arquiteturais. Fluxo de dados (Data Flow) 1
Estilos arquiteturais Fluxo de dados (Data Flow) Sequenciais Batch 2. Pipes & Filters (Dutos e Filtros)
6
Fluxo de Dados Originário de sistemas operacionais UNIX e do projeto de compiladores Ex. Unix Pipes: condutores da saída de um programa para a entrada de um outro programa. > Who | Sort Transformações funcionais processam entradas para produzir saídas. Componentes são chamados de filtros: recebem (tratam e refinam) entradas especificadas e transformam essas entradas em saídas Conectores são dutos (pipes) - trasmitem saídas de um filtro para serem entradas de outro
7
1. Seqüências (Batch Sequential)
Especialização de pipes &filtros Programas independentes executados em seqüência (pipelines: seqüências linear de filtros) Um após o outro Dado transmitido por completo entre um programa e outro
8
Ex: Arquitetura de Compiladores
Análise léxica Análise sintática Análise semântica Geração de código Otimização Jar Java Javac class{ } Arquivos fonte A$n3* 3N4*# Bytecode 000 1001 Arquivo Jar executando Empacotando Compilando
9
2. Pipes & Filters (Dutos e Filtros)
B D A C E PIPES Tipo mais geral – não precisa ser sequencial Pipes tipados – os tipos passados entre dois filtros tem um tipo bem definido.
10
Ex: Sistema de processamento de faturas
Sommeville.
11
Características: Dutos e Filtros
Vantagens Útil para aplicações de processamento de informação que interagem pouco com usuários Rápida prototipação Apóia reúso de transformações (filtros) É fácil adicionar, recombinar, ou trocar, novas transformações (flexibilidade) É relativamente simples implementar como sistema concorrente (vários filtros em paralelo) ou seqüencial Eficiência em processamento Não são necessários arquivos intermediários.
12
Características: Dutos e Filtros
Desvantagens Requer um formato comum para a transferência de dados ao longo do pipeline Não é apropriado para aplicações interativas Não existe compartilhamento de dados Ausência de gerenciamento de erros.
13
Implementação Divida as tarefas do sistema em uma sequência de estágios de processamento Cada estágio deve depender somente da saída do seu predecessor Todos os estágios são conectados por um fluxo de dados Defina o formato de dados a ser passado ao longo de cada pipe Decida como implementar cada conexão com pipe Se estes serão ativos ou passivos
14
Estilos arquiteturais Chamada (ou invocações) e Retorno. 1
Estilos arquiteturais Chamada (ou invocações) e Retorno Programa Principal e Sub-Rotina 2. Invocação Remota de Procedimento (RPC) 3. Sistema Orientados a Objetos 4. Camadas (Layered)
15
Chamada e Retorno O controle de execução de um componente é realizado por outro componente através de uma invocação, que geralmente produz um retorno. Componentes: módulos, sub-rotinas, funções, objetos, e ou componentes complexos (grupos de componentes) Conectores: chamada de procedimentos, envios de mensagem, protocolos de comunicação, etc.
16
1. Programa principal e Sub-Rotinas (Main Program/Subroutines)
Controle se inicia no topo de uma hierarquia de subrotinas e move-se para baixo na hierarquia. Componentes – subrotinas Conectores – chamadas de procedimento Vantagens: desenvolvimento pode ser independente; Gerenciamento de controle mais fácil de visualizar, na hierarquia de módulos. Desvantagens: o reúso, bem como alterações podem ser difíceis.
17
Exemplo: Sommerville
18
Invocação remota de procedimento (RPC – remote procedure call) - especialização do programa principal e sub-rotinas Programa principal Rede Subrotina 3 Subrotina 1 Subrotina 2
19
Vantagens Rede Ganho de desempenho Programa principal Subrotina 1
Subrotina 1 Subrotina 2 Ganho de desempenho (2 processadores)
20
3. Sistema Orientados a Objetos
Sistema como um conjunto de objetos fracamente acoplados e com interfaces bem definidas Cada objeto oferece um conjunto de serviços Sistemas Orientados a Objetos (OO) podem ser vistos como uma rede ou grafo de objetos comunicantes. Componentes: Objetos. Conectores: envio de mensagem Regras: objetos encapsulam seus dados; um objeto é responsável pela manutenção da integridade de sua representação. Uma implementação OO não implica em uma arquitetura OO
21
Ex: Sistema de processamento de faturas
Sommerville.
22
Características: Sistemas Orientados aObjetos
Vantagens Objetos são fracamente acoplados devido ao uso de interfaces Linguagens de implementação orientada a objeto são amplamente usadas. Desvantagens Mudanças de interface têm alto impacto Não envolve restrições topológicas, o que pode dificultar a manutenção Dependências entre objetos não são limitadas
23
4. Camadas (Layered) Sistema organizado hierarquicamente.
Cada camada oferece o serviço para a camada superior (externa) e utiliza um serviço da camada inferior (interna). Componentes: são camadas, grupo de tarefas em um mesmo nível de abstração Conectores: protocolos que indicam como as camadas irão interagir e limitam as comunicações a camadas adjacentes; permitem comunicação em máquinas diferentes Cada camada está associada a um conjunto de entidades (entidade complexa), constituindo-se de diferentes componentes (por ex.: conjunto de objetos, funções, etc).
24
Exemplos Ex: para um sistema de informação Aplicação Apresentação
Apresentação (GUI) Sessão Negócio Clássica 3 camadas ISO-OSI Transporte Armazenamento (Persistência) A arquitetura de rede é formada através de uma estrutura hierárquica, composta de camadas com interfaces entre elas. Dados = enlace. Rede Dados Ex: para um sistema de informação Física
25
Características Camadas se comunicam apenas com outras adjacentes
Apresentação Negócio Armazenamento
26
Características Alterações locais não são propagadas Apresentação
Negócio Armazenamento
27
Outra maneira de representar
Useful Systems Agregados de Elementos Menores Base Utility Core Level Users
28
Ex: Sistema de gerenciamento de versões
Ex Sommerville
29
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
30
Implementação 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
31
Características: Estilo em Camadas
Vantagens: Facilidade de compreensão: utiliza níveis crescentes de abstração, particionando problemas complexos em sequência de passos incrementais. Suporte a padronização Desenvolvimento independente Facilidade de manutenção, reúso das camadas e suporte à evolução dos sistemas, oferencendo flexibilidade e boa manutenibilidade As dependências tendem a ser locais (dentro da camada)- restrição de comunicação entre camadas adjacentes, mudanças afetam no máximo duas camadas Se interface bem definida, permite uso de diferentes implementações da mesma camada
32
Características: Estilo em Camadas
Desvantagens Às vezes é difícil estruturar um sistema através de camadas. Conseqüências: É comum que a estruturação seja violada Camadas relaxadas são necessárias – todas as camadas podem se comunicar entre si. Mudanças em serviços de uma cada inferior, podem requerer propagação de mudanças até as superiores Pode haver necessidade de duplicação de funcionalidade Overhead (problemas) de implementação, comunicação, e desempenho Complexidade na Implementação e Testes do Sistema Muitas vezes uma má estruturação em camadas, faz com que os serviços fornecidos não sejam bem Estruturados. Variantes: Sistemas de camadas relaxadas:menos restritivos cra a comunicaçao entre camadas, todas podem se Comunicar entre si. Camadas atráves de herança: algumas camadas são implementadas como classes bases, algumas herdam informação das camadas inferiores.
33
Estilos arquiteturais Componentes Independentes 1
Estilos arquiteturais Componentes Independentes Processos comunicantes Cliente-servidor, Peer to peer 2. Baseado em eventos Invocação implícita
34
Componentes Independentes
Processos são independentes Envio de dados entre processos, normalmente sem controlar a execução de cada um deles. O controle geralmente é feito com envio de mensagens ou baseado em eventos. Alto grau de modificabilidade através do desacoplamento de várias porções da computação
35
1. Processos comunicantes
Baseado na comunicação via troca de mensagens entre processos Em geral, via rede Cliente - Servidor Ponto a ponto (Peer to Peer – P2P)
36
Estilo Cliente-Servidor
Mostra como dados e processamento são distribuídos por uma variedade de componentes Servidores independentes que fornecem serviços tais como impressão, transferência de arquivos, gerenciamento de dados, etc. Clientes utilizam esses serviços Clientes e servidores normalmente se comunicam através de uma rede Diversas tecnologias de comunicação são possíveis Baseado em programas servidores e programas clientes Cliente: Estabelece a conexão, envia mensagens para o servidor e aguarda mensagens de resposta. Servidor: Aguarda mensagens, executa serviços e retorna resultados. Os primeiros sistemas cliente-servidor surgiram por causa de limitações nas arquiteturas de compartilhamento de arquivos. Introdução de um banco de dados substituindo o servidor de arquivos Reduziu o tráfego de rede, uma vez que somente as consultas (e suas respostas) trafegavam, ao invés de arquivos.
37
Ex: Aplicação: Internet
Servidor Atualmente muitas aplicações possuem arquitetura Cliente-Servidor Navegador WEB X Servidor WEB Programa JAVA X Gerenciador de Banco de Dados Clientes
38
Ex: Sistema– Cliente-Servidor
39
Ex: Biblioteca de filmes e fotografias
Sommerville
40
Características: Cliente-Servidor
Vantagens Separação de interesses Inerentemente distribuído: pode haver balanceamento de carga, tolerância a falhas É fácil adicionar novos servidores ou atualizar servidores existentes. Utilização dos recursos do servidor Escalabilidade: aumentando a capacidade computacional do servidor
41
Características: Cliente-Servidor
Desvantagens Gerenciamento redundante em cada servidor; Nenhum registro central de nomes e serviços – pode ser difícil descobrir quais servidores e serviços estão disponíveis Requisições e respostas casadas Introduz complexidade Custos de comunicação Falhas no servidor
42
Ponto a Ponto (P2P) Não há distinção entre nós
Cada nó mantém seus próprios dados e endereços conhecidos Cada nó é “cliente e servidor ao mesmo tempo” Vantagem: reduz problemas de falhas Desvantagem: aumenta o tempo de consulta Exemplos de redes P2P: gnutella, freenet Exemplos de aplicação: Kazaa, eMule
43
2. Baseado em eventos Desacoplamento entre consumidores e produtores de eventos Escalabilidade: adição de novos observadores para eventos que já são produzidos Invocação implícita: O produtor de eventos não controla quem será notificado ou quando ele será notificado
44
Exemplo: relatório de impressão
Produtores e consumidores são independentes Execução via procedimentos disparados via mudança de estados Escalabilidade no número de interessados Consumidores se registram nos Produtores Produtores notificam consumidores registrados imprimir() A interessado(“relatorioOK”) B relatorioOK Consumidor Produtor Relatório OK
45
Ex: Interface Gráfica onKeyDown onMouseOver onKeyUp onMouseReleased
onMouseClick menuDown onMousePressed onSelected
46
Sistemas orientados a eventos
Dirigidos por eventos gerados externamente O timing dos eventos está fora do controle dos componentes que os processam Estilo Publisher/Subscriber Eventos são transmitidos a todos os componentes. Qualquer componente interessado pode respondê-los Estilo Orientado a Interrupções Usado em sistemas de tempo real Interrupções são detectadas por tratadores e passadas por outro componente para processamento.
47
Modelo Publisher/Subscriber
É efetivo na integração de componentes em computadores diferentes em uma rede Desacoplamento espacial e temporal Componentes não sabem se um evento será tratado e nem quando será. Alguns componentes (publishers) publicam eventos Componentes (subscribers) registram interesse em eventos específicos e podem tratá-los A política de controle não é embutida no tratador de eventos e mensagens
48
Publisher/Subscriber
Sommerville
49
Estilo Orientado a Interrupções
Usado em sistemas de tempo real onde a resposta rápida para um evento é essencial Existem tipos de interrupções conhecidos Um tratador definido para cada tipo Cada tipo é associado a uma localização da memória Uma chave de hardware causa a transferência de controle para um tratador. Permite respostas rápidas, mas é complexo para programar e difícil de validar.
50
Controle dirigido a interrupções
51
Estilos arquiteturais. Máquina Virtual (Virtual Machine) 1
Estilos arquiteturais Máquina Virtual (Virtual Machine) Interpretador 2. Baseado em Regras
52
Máquina Virtual Uma máquina virtual é produzida no software, geralmente para uma determinada linguagem. Simular funcionalidade não nativa para obter portabilidade Ex: Simuladores de Software (linguagens - Java VM)
53
1. Interpretador (Interpreter)
Esta arquitetura inclui geralmente 4 componentes: - mecanismo de interpretação - uma memória que contém o pseudo-código a ser interpretado - representação do estado do mecanismo de interpretação - representação do estado atual do programa sendo simulado A máquina tenta preencher a lacuna que existe entre o que o programa precisa e o que o hardware disponibiliza
54
Componentes de um Interpretador
entrada Programa sendo interpretado Dados (Estado do programa) Dados de estado dados Atualiza Instruções do programa saída Mecanismo de interpretação Instrução selecionada Estado interno (Instruções + dados) Dados selecionados
55
Ex: Java VM public class Oi{ Compilador Java ... “javac.exe” }
Máquina Virtual INTERPRETA Compilador Java “javac.exe” public class Oi{ ... } Arquivo “Oi.java” Êþº¾ 1 <init> ()V Code LineNumberTable main ([Ljava/lang/String;)... Arquivo “Oi.class” bytecode
56
Características - Interpretador
Desvantagens: Desempenho Vantagens: Portabilidade Algumas pesquisas apontam que algumas das linguagens interpretadas já conseguem ser mais rápidas que C Java, por exemplo Java - Máquina virtual nativa – Intel®
57
2. Baseado em Regras (Rule-Based)
Conjunto de regras sobre um estado Definição do estado atual com base em dados de entrada Regras alteram o estado entrada Memória de trabalho saída Base de Regras Máquina de inferência
58
Ex: Prolog, Sistemas Especialistas
Memória de trabalho HORA=18:00 SE “HORA=21:00” ENTÃO “AÇÃO=LANCHE” SE “HORA=22:00” ENTÃO “AÇÃO=LIBERAR” SE “HORA<19:00” ENTÃO “AÇÃO=ESPERAR” SE “HORA=19:00” ENTÃO “AÇÃO=COMEÇAR” HORA = ? AÇÃO = ? Máquina de inferência Base de Regras
59
Máquina de inferência Memória de trabalho SE “HORA=21:00” HORA = 18:00
ENTÃO “AÇÃO=LANCHE” SE “HORA=22:00” ENTÃO “AÇÃO=LIBERAR” SE “HORA<19:00” ENTÃO “AÇÃO=ESPERAR” SE “HORA=19:00” ENTÃO “AÇÃO=COMEÇAR” HORA = 18:00 AÇÃO = ? Máquina de inferência Base de Regras
60
Máquina de inferência Memória de trabalho SE “HORA=21:00” HORA = 18:00
ENTÃO “AÇÃO=LANCHE” SE “HORA=22:00” ENTÃO “AÇÃO=LIBERAR” SE “HORA<19:00” ENTÃO “AÇÃO=ESPERAR” SE “HORA=19:00” ENTÃO “AÇÃO=COMEÇAR” HORA = 18:00 AÇÃO = ESPERAR Máquina de inferência Base de Regras
61
AÇÃO=ESPERAR Máquina de inferência Memória de trabalho SE “HORA=21:00”
ENTÃO “AÇÃO=LANCHE” SE “HORA=22:00” ENTÃO “AÇÃO=LIBERAR” SE “HORA<19:00” ENTÃO “AÇÃO=ESPERAR” SE “HORA=19:00” ENTÃO “AÇÃO=COMEÇAR” HORA = 18:00 AÇÃO = ESPERAR AÇÃO=ESPERAR Máquina de inferência Base de Regras
62
Estilos arquiteturais Centrado em Dados 1. Repositório 2. Blackboard
63
Centrado em Dados (Data-centered)
A meta é a integração de dados Sistemas cujas partes precisam trocar dados com frequência Descreve o acesso e atualização de repositórios de dados amplamente acessíveis Existe um grande depósito de dados centralizado, manipulado por computações independentes
64
1. Repositório (Repository)
Dados compartilhados podem ser mantidos em um banco de dados central e acessados por todos os subsistemas Cada subsistema mantém seu próprio banco de dados e passa dados para outros subsistemas Podem usar uma abstração de repositório centralizado Implementação distribuída
65
Repositório (Repository)
Integridade, escalabilidade (novos clientes, novos dados) Clientes operam sobre os dados Cliente 2 Cliente 3 Cliente 1 Cliente n Dados compartilhados Estado atual consistente
66
Ex: Banco de dados tradicional
Cliente 2 Cliente 3 Cliente 1 Gatilhos (triggers) Transações Cliente n Dados compartilhados
67
Ex: Arquitetura de uma Ferramenta Case
Sommerville
68
Características: Repositório
Vantagens É uma maneira eficiente de compartilhar grandes quantidades de dados Dados aderem a uma representação comum Simplifica a projeto de aplicações fortemente baseadas em dados Tanto para troca de informações quanto para armazenamento Desvantagens Os subsistemas devem estar de acordo com um modelo de dados padronizado A evolução de dados é difícil e dispendiosa Dificuldade para distribuir de forma eficiente
69
2. Quadro negro (Blackboard)
O sistema é dividido em blackboard: aramazena dados – o vocabulário base de conhecimento: subsistemas independentes, cada qual resolvendo aspectos específicos do problema componente de controle: monitora mudanças no blackboard e decide as ações
70
Quadro negro (Blackboard)
Ap 2 Ap 1 Ap 3 Quadro Negro Controlador Ap 4 Ap n Ap 5
71
Quadro negro (Blackboard)
Controlador x - Fontes de conhecimento Gerência dos dados x2 +
72
Quadro negro (Blackboard)
Sei subtrair! Sei multiplicar! 2 x (3+2) = ? x - Controlador x2 Sei exponencial! Sei somar! +
73
Quadro negro (Blackboard)
2 x (5) = ? 2 x (3+2) = ? x - Controlador x2 +
74
Quadro negro (Blackboard)
2 x (5) = ? 2 x = ? x - Controlador x2 +
75
Quadro negro (Blackboard)
2 x = ? = ? x - Controlador x2 +
76
Quadro negro (Blackboard)
= ? 47 x - Controlador x2 +
77
Características: Blackboard
Usado em: Sistemas que não possuem estratégias de soluções determinísticas conhecidas e são baseados em soluções aproximadas ou parciais. Problemas que podem ser decompostos em sub- problemas e abrangem muitos domínios de conhecimento Sistemas complexos - Resolução Distribuída de Problemas - RDP Paradigma de agentes
78
Características: Blackboard
Vantagens: Ajuda a resolver problemas de experimentação Suporte a mudanças e manutenção Escalabilidade – aplicações independentes Reúso de conhecimentos Suporte: tolerância a falhas e robustez
79
Características: Blackboard
Desvantagens Dificuldades para testar por não usar algoritmos determinísticos Nenhuma boa solução é garantida Dificuldade em estabelecer uma boa estratégia de controle. Baixa eficiência e alto esforço de desenvolvimento Não suporta paralelismo
80
Seleção de Estilos O que considerar? Passos a seguir
81
Fluxo de Dados As interfaces entre os componentes são simples
O sistema produz resultados simples e bem identificáveis que derivam diretamente da transformação seqüencial de uma entrada facilmente identificável A relação entre entrada e saídas é temporalmente independente
82
Fluxo de Dados Sequencial: transformações são seqüenciais
Existe uma única saída, resultante de uma única entrada de dados Fitros e Pipes: A computação envolve transformações sobre uma cadeia de dados contínua As transformações são incrementais. Uma transformação pode executar antes do término do passo anterior
83
Chamada/Retorno A ordem da computação é fixa
Componentes não podem fazer progresso enquanto aguardando o resultado das chamadas
84
Chamada/Retorno Orientação a objetos:
- Ocultamento da Informação: produz módulos similares, que no decorrer do desenvolvimento e teste se beneficiam do uso de herança
85
Chamada/Retorno Camadas:
As tarefas do sistema podem ser particionadas entre: específicas da aplicação, e genéricas a muitas aplicações, mas específicas à plataforma subjacente Portabilidade é importante Pode-se usar uma infra-estrutura de computação pré-existente
86
Componentes Independentes
O sistema executa em uma plataforma multi-processada (ou que pode vir a ser no futuro) O sistema pode ser estruturado como um conjunto de componentes fracamente acoplados, de modo que um componente pode fazer progressos de forma independente dos outros. Ajuste de desempenho é importante, seja através da re-alocação de tarefas a processos,seja através da re-alocação de processos a processadores
87
Componentes Independentes
Processos Comunicantes: Objetos Distribuídos: OO + Componentes Independentes Redes de filtros: Data-Flow + Componentes Independentes Cliente-Servidor: As tarefas podem ser divididas entre geradores de pedidos (ou consumidores de dados) executores de pedidos (ou produtores de dados)
88
Componentes Independentes
Baseada em Evento Quando é necessário desacoplar consumidores e produtores de eventos Quando é necessário escalabilidade, e permitir a adição de novos processos ao sistema, os quais serão integrados a eventos já sinalizados no sistema
89
Centrada em Dados As questões importantes são o armazenamento, representação, gerenciamento e recuperação de uma grande quantidade de dados persistentes
90
Máquina Virtual Não existe uma máquina que execute um
modelo computacional que foi projetado
91
Seleção de estilos –Passos a seguir
1. Identificar os principais elementos da arquitetura 2. Identificar o estilo arquitetural dominante 3. Considerar responsabilidades adicionais associadas com a escolha do estilo 4. Modificar o estilo para atingir objetivos adicionais Fonte: Carnegie Mellon – Software Engineering Institute.
92
1. Identificar os principais elementos da arquitetura
Cada elemento arquitetural tem um estilo arquitetural dominante que reflete as qualidades importantes que devem ser alcançadas no contexto daquele elemento A escolha do estilo arquitetural dominante é baseada nos principais elementos arquiteturais Os atributos de qualidade sobre cada elemento arquitetural podem acarretar a utilização ou não de um estilo
93
2. Identificar o estilo arquitetural dominante
O estilo dominante pode ser modificado para alcançar objetivos particulares Se nenhum estilo conhecido parece ser apropriado, o arquiteto deve projetar e documentar um novo estilo As decisões sobre escolhas baseadas em atributos de qualidade dentro de um estilo devem ser documentadas
94
3. Considerar responsabilidades adicionais associadas com a escolha do estilo
A escolha de um estilo arquitetural introduzirá responsabilidades adicionais Por exemplo: Se o estilo é “Quadro negro”, então devem-se gerenciar os mecanismos para o controle do quadro negro Se o estilo é “cliente-servidor”, devem-se gerenciar os protocolos de interação Responsabilidades adicionais devem ser atribuídas a elementos arquiteturais existentes ou a novos elementos criados para este fim.
95
4. Modificar o estilo para atingir objetivos adicionais
Pode-se alterar o estilo arquitetural caso este necessite ser adaptado devido a atributos de qualidade ou até mesmo funcionalidade
96
Exemplo: Sistema de matrícula
1. Identificar os principais elementos da arquitetura Módulo de acesso do usuário Módulo de armazenamento de dados
97
Exemplo: Sistema de matrícula
2. Identificar o estilo arquitetural dominante Deve executar na Internet Deve ser fino! Não deve requerer instalação! Deve ser possível acessar de qualquer lugar Deve ter alta disponibilidade Módulo de acesso do usuário Acesso à máquina do BD só via rede Utiliza banco de outra aplicação (legada) Não há confiança na disponibilidade da máquina do BD Módulo de armazenamento de dados
98
Exemplo: Sistema de matrícula
3. Considerar responsabilidades adicionais associadas com a escolha do estilo Estilo dominante escolhido: Cliente-servidor Estilo secundário: Repositório Responsabilidades: considerar protocolo de comunicação Cliente Rede/HTTP Servidor
99
Exemplo: Sistema de matrícula
4. Modificar o estilo para atingir objetivos adicionais Cliente servidor de 2 camadas e repositório com backup Cliente/ Servidor Módulo cliente (Acesso do usuário) Repositório Cliente/ Servidor Módulo Backup (Dados) consulta/ atualização leitura sincronização Cliente/ Servidor Módulo Servidor (Web) Módulo Servidor (Dados) leitura/escrita leitura/escrita Aplicação legada
100
Exemplo: Sistema de matrícula
4. Modificar o estilo para atingir objetivos adicionais Objetivos atingidos! Alta disponibilidade Fino Executar na Internet Acesso de qualquer lugar Não requer instalação Módulo cliente (Acesso do usuário) Módulo Backup (Dados) consulta/ atualização leitura sincronização Módulo Servidor (Web) Módulo Servidor (Dados) leitura/escrita Acesso à maquina do BD só via rede Banco de outra aplicação Não há confiança na disponibilidade leitura/escrita Aplicação legada
101
Estilos arquiteturais Estudo de Caso- Garlan e Shaw (1994)
102
Objetivo Ilustrar como princípios de arquitetura podem aumentar o entendimento de sistemas de software. Avaliar diferentes soluções e seus impactos para um mesmo problema
103
1. Palavra-chave em contexto: objetivo
Analisar diferentes arquiteturas com respeito às seguintes considerações de projeto: Mudança no algoritmo de processamento (ex: shifts nas linhas podem ser feitos em cada linha lida, em todas as linhas após terem sido lidas, ou por demanda); Mudança na representação dos dados; Mudança na funcionalidade (extensibilidade); Performance (espaço e tempo); Grau de reuso.
104
Problema exemplo: palavra-chave em contexto
105
Palavra-chave em contexto: entrada e saída produzida
106
Selecione um estilo para o sistema KWIC, e represente os elementos arquiteturais do sistema no estilo escolhido.
107
1. Palavra-chave em contexto: canais e filtros
Input medium Input Circular Shift Alphabetizer Output Output medium Canal (Pipe) I/O
108
1. Palavra-chave em contexto: canais e filtros
Pontos fortes: Suporta reuso já que cada filtro pode funcionar isoladamente desde que receba o “stream” que está esperando. Novas funções podem ser adicionadas inserindo novos filtros no lugar apropriado. O algoritmo de processamento de cada filtro pode ser modificado. Pontos fracos: É impossível modificar o sistema para funcionar interativamente. Os dados têm que ser completamente copiados de um filtro para outro.
109
1. Palavra-chave em contexto: programa principal/subrotinas com dados compartilhados
Master Input Circular Shift Alphabetizer Output Lines Index Alphabetized index Input medium Output medium Acesso direto na memória Chamada de subrotina I/O
110
Pontos fortes: Pontos fracos:
1. Palavra-chave em contexto: programa principal/subrotinas com dados compartilhados Pontos fortes: Dados podem ser representados de forma eficiente (boa performance), pois são compartilhados. A extensibilidade é permitida por meio da adição de um novo componente, acessando os dados compartilhados. Pontos fracos: Uma mudança na estrutura dos dados irá afetar todos os módulos. Mudanças no algoritmo de processamento não são fáceis. Devido à forte dependência dos dados, os módulos não são facilmente reusáveis.
111
1. Palavra-chave em contexto: tipos abstratos de dados
Master Input Output Alphabetizer Circular Shift Lines Input medium Output medium Chamada de subrotina I/O
112
1. Palavra-chave em contexto: tipos abstratos de dados
Pontos fortes: Em cada módulo, tanto o algoritmo como o formato interno dos dados podem ser modificados sem afetar os outros módulos. Reuso é melhor suportado, pois cada módulo não precisa conhecer detalhes internos dos outros módulos. A performance não é tão boa quanto a anterior, pois o fluxo de dados é provavelmente maior. Ponto fraco: A extensibilidade implica modificação dos módulos ou adição de um novo módulo.
113
1. Palavra-chave em contexto: invocação implícita
Master Input Circular Shift Alphabetizer Output I n s e r t I n s e r t Lines Output medium Input medium Lines Invocação implícita Chamada de subrotina I/O
114
1. Palavra-chave em contexto: invocação implícita
Características: Tão logo os dados são modificados, outras computações são invocadas implicitamente. Existe um “line storage” para “input” e outro para “shifts”. Ponto forte: A representação dos dados pode ser modificada sem afetar os módulos. Ponto fraco: É difícil controlar a ordem de processamento dos módulos invocados implicitamente.
115
2. Software para instrumentação (osciloscópio)
Sistema de instrumentação que recebe sinais elétricos e mostra figuras numa tela; Osciloscópio também executa medidas sobre estes sinais e mostra-as numa tela.
116
2. Software para instrumentação (osciloscópio): modelo orientado a objetos
Formato da onda Sinais Medidas ...
117
2. Software para instrumentação (osciloscópio): modelo orientado a objetos
Problema: Confusão sobre o particionamento. Ex: as medidas devem ser associadas com os tipos de dados sendo medidos, ou representadas externamente? Quais são os objetos que a interface com o usuário interage?
118
2. Software para instrumentação (osciloscópio): modelo em camadas
hardware digitalização manipulação visualização Interface com usuário
119
2. Software para instrumentação (osciloscópio): modelo em camadas
Problema: Em osciloscópios reais, os usuários precisam afetar diretamente funções em todos os níveis. Ou seja, a interação não se dá apenas com o último nível.
120
2. Software para instrumentação (osciloscópio): modelo de canais e filtros
Acoplar Adquirir To-X-Y Clip sinal tempo Forma da onda Subsistema de Gatilhos Medir medida
121
2. Software para instrumentação (osciloscópio): modelo de canais e filtros
Problema: Não fica claro como o usuário interage com o sistema.
122
2. Software para instrumentação (osciloscópio): modelo de canais e filtros modificado
acoplamento Tipo, taxa trans tamanho Acoplar Adquirir To-X-Y Mostrar sinal tempo Forma da onda Subsistema de Gatilhos Medir medida
123
2. Software para instrumentação (osciloscópio): modelo de canais e filtros modificado
Problemas: Performance, devido à grande transferência de dados; Filtros lentos podem atrasar o processamento do sistema.
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.