Estilos Arquiteturais

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Estilos Arquiteturais
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Qual o papel da arquitetura?
Leaning tower image from Gary Feuerstein.
Other images from The Big Ball of Mud, by Yoder and Foote.
?
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Ciclo de vida do desenvolvimento
A arquitetura desempenha um papel vital na definição da estrutura do sistema, desde cedo no ciclo de vida do desenvolvimento
“The evolutionary delivery lifecycle model”
(Rapid Development, Steve McConnell)
Arquitetura define a estrutura do sistema
Primeira release libera o core do sistema
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Vida útil do sistema
A arquitetura antecipa decisões que afetam toda vida útil do sistema
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Definições…
Um sistema é um conjunto de partes
…e formam um todo que atendem a expectativas
As partes se relacionam entre si…
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Arquitetura
Arquitetura é a organização fundamental de um sistema incorporada em seus componentes, seus relacionamentos com o ambiente, e os princípios que conduzem seu design e evolução.
Evolução de software é o fenômeno de mudança que ocorre no software ao longo dos anos e das múltiplas versões, desde seu início até o completo abandono do sistema. 
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Arquitetura
Essa mudança não está só relacionada com a adição e remoção de funcionalidades, mas também está relacionada com a manutenção do código ao longo do ciclo de vida do software. 
Essa manutenção pode melhorar ou deteriorar tanto atributos externos de qualidade do software, os quais são percebidos pelos usuários (e.g., desempenho, tolerância a falhas, disponibilidade), quanto atributos internos de qualidade do software, os quais são percebidos pelos envolvidos no desenvolvimento (e.g., testabilidade, legibilidade, reusabilidade).
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Arquitetura
Um dos principais objetivos de se projetar uma arquitetura é o de atingir a qualidade desejada pelos interessados no sistema:
o papel da arquitetura em conduzir a evolução do software, uma vez que ela conterá decisões que contribuirão para a preservação da qualidade do sistema durante seu ciclo de vida.
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Decompondo a definição de Arquitetura de Software
A arquitetura de software é mais bem entendida através de suas partes. 
Podemos ressaltar seus dois principais aspectos, que serão os meios para alcançar os atributos de qualidade: elementos e decisões arquiteturais. 
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Elementos arquiteturais
A arquitetura de um sistema deve definir os elementos que formarão o software. 
Tais elementos definem como o software é particionado em pedaços menores e, assim, definem como o software é entendido. 
Elementos arquiteturais são divididos em dois tipos: elementos estáticos e elementos dinâmicos.
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Elementos arquiteturais:
Elementos estáticos
Os elementos estáticos de um sistema de software definem as partes do sistema e qual sua organização. 
Esse tipo de elemento reflete o sistema durante o design e é constituído de:
elementos de software (e.g., módulos, classes, pacotes, procedimentos, ou ainda serviços autocontidos), 
elementos de dados (e.g., entidades e tabelas de bancos de dados, arquivos de dados, ou classes de dados), 
e elementos de hardware (e.g., computadores em que o sistema vai executar, ou outros tipos de hardware que o sistema usará: roteadores, cabos, ou impressoras).
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Elementos arquiteturais:
Elementos dinâmicos
Elementos dinâmicos definem o comportamento do sistema. 
Esse tipo de elemento reflete o sistema durante a execução e nele estão incluídos processos, módulos, protocolos, ou classes que realizam comportamento. 
Elementos dinâmicos também descrevem como o sistema reage a estímulos internos e externos.
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Elementos Arquiteturais e Atributos do Sistema
Ao examinamos os elementos arquiteturais de um sistema, tanto os estáticos quanto os dinâmicos, devemos também prestar atenção nas relações que os ligam. 
Essas relações são importantes, pois especificam a comunicação e o controle da informação e do comportamento que formam o sistema. 
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Elementos Arquiteturais e Atributos do Sistema
Tais elações definem diversos aspectos do sistema, por exemplo, quais dados do objeto da classe A são visíveis pelos objetos da classe B; 
ou quantas leituras concorrentes são feitas no elemento C; 
ou ainda como o elemento D é autorizado a escrever dados no elemento E. 
Essas relações têm efeito sobre atributos de qualidade do sistema, sejam os percebidos pelos usuários, ou os percebidos pelos desenvolvedores. 
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Estilos Arquiteturais
A arquitetura de um sistema pode aderir a um ou mais estilos arquiteturais
Um estilo define os tipos de elementos que podem aparecer em uma arquitetura e as regras que regem a sua interconexão
Esses estilos pode simplificar o problema de definição de arquiteturas de sistema.
A maioria dos sistemas de grande porte adere a vários estilos
Estilos arquiteturais = “modelos arquiteturais”
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Exemplos de Estilos Arquiteturais
Cliente-Servidor
“Em camadas”
Filtros e dutos (pipes and filters)
Baseado em repositório
Orientado a eventos (publisher/subscriber)
Transferência Representacional de Estado (REST)
Objetos distribuídos
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Estilos Arquiteturais e Escolhas de Projeto
Um estilo arquitetural representa um conjunto de escolhas de projeto
Conjunto de características comuns a diversos sistemas nos quais as mesmas escolhas foram feitas
Padrões arquiteturais 
Um sistema aderente a determinado estilo “ganha" as características inerentes a ele
Estilos podem ser usados para descrever uma determinada arquitetura
Foco nas soluções de projeto e não em sua documentação
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Organização
de sistema
Reflete a estratégia básica que é usada para estruturar um sistema
Exemplos:
O estilo de repositório de dados compartilhados
Estilo de serviços e servidores compartilhados
Estilo de máquina abstrata ou em camadas
Orientado a objetos (ou Objetos Distribuídos)
Pipes and Filters ou Pipelining
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Estilo de repositório
Sistemas cujas partes precisam trocar dados com frequência:
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
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Arquitetura de conjunto de ferramentas CASE
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Características do Estilo Arquitetural de 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 info. 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
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
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
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Biblioteca de filmes e fotografias
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Características do Estilo Cliente-Servidor
Vantagens 
Separação de interesses
Inerentemente distribuído
Balanceamento de carga, tolerância a falhas
É fácil adicionar novos servidores ou atualizar servidores existentes.
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
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Modelo de Máquina Abstrata 
(Em Camadas)
Organiza o sistema em um conjunto de camadas (ou máquinas abstratas)
Cada uma fornece um conjunto de serviços
Cada camada é cliente da camada subjacente
Generalização do estilo Cliente-Servidor
Não precisa ser distribuído
Apóia o desenvolvimento incremental dos subsistemas em camadas diferentes. 
Ex. Se mudarmos a camada de negócios, só as camadas acima precisam ser modificadas
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Sistema de gerenciamento de versões
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Características do Estilo em Camadas
Vantagens 
Facilidade de compreensão
Facilidade de manutenção
Desenvolvimento independente
Desvantagens 
Duplicação de funcionalidade
Às vezes é difícil estruturar um sistema através de camadas
É comum que a estruturação seja violada
Camadas relaxadas são necessárias
Overhead de implementação e desempenho
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Estilo Arquitetural de Objetos
Sistema como um conjunto de objetos fracamente acoplados e com interfaces bem definidas
Cada objeto oferece um conjunto de serviços
No nível arquitetural, é frequentemente empregado na construção de sistemas distribuídos	
Objetos distribuídos
Uma implementação OO não implica em uma arquitetura OO
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Sistema de processamento de faturas
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Características do Estilo Arquitetural de Objetos
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
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Estilo Dutos e Filtros (Pipelining)
Originário de sistemas operacionais UNIX e do projeto de compiladores
Transformações funcionais processam entradas para produzir saídas.
Componentes são chamados de filtros
Conectores são dutos (pipes) 
Útil para aplicações de processamento de informação que interagem pouco com usuários 
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Sistema de processamento de faturas
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Características do Estilo
Dutos e Filtros
Vantagens
Apóia reuso de transformações.
É fácil adicionar novas transformações.
É relativamente simples implementar como sistema concorrente ou seqüencial.
Desvantagens
Requer um formato comum para a transferência de dados ao longo do pipeline
Não é apropriado para aplicações interativas
Mais especificamente: só é apropriado para realizar processamento sequencial
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Fluxo de Controle
Estilos arquiteturais relacionados com o fluxo de controle entre os componentes arquiteturais
Controle centralizado
Um subsistema tem responsabilidade global pelo controle e inicia e para outros sistemas
Controle baseado em eventos
Cada componente responde a eventos gerados por outros subsistemas
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Controle centralizado
Um componente é responsável pelo gerenciamento da execução de outros componente.
Decisões de controle são determinadas pelos valores de algumas variáveis de estado do sistema.
O estilo Chamada-Retorno
Controle se inicia no topo de uma hierarquia de subrotinas e move-se para baixo na hierarquia. 
Pode ser sequencial
O estilo de Gerenciador
Aplicável a sistemas concorrentes e de tempo real
Um componente controla a parada, o início e a coordenação de outros processos de sistema
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Chamada-Retorno
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Gerenciador
para um
Sistema Tempo Real
Comunicação entre o Controlador e os outros componentes pode ser 
baseada em eventos, chamadas de procedimentos, etc. 
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Gerenciador para um
Sistema Tempo Real
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Sistemas orientados a eventos
Um evento é diferente de uma entrada simples de dados:
A ocorrência do evento está for a do controle do processo que manipula este evento.
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.
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Modelo Publisher/Subscriber (Broadcast)
É 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
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Modelo Publisher/Subscriber (Broadcast)
Vantagem
Evolução simples – Um novo subsistema pode tratar classes específicas de eventos pode ser integrado por meio do registro de seus eventos de interesse, no tratador de eventos.
Qualquer subsistema pode ativar outro substema sem saber seu nome ou localização
Pode ser distribuído
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Modelo Publisher/Subscriber (Broadcast)
Desvantagem
Subsistemas não sabem SE ou QUANDO os eventos serão manipulados.
Quando um subsistema gera um evento, ele não sabe quais outros registraram interesse neste evento.
Dessa forma vários subsistemas podem se “candidatar” a tratar o evento, causando conflito.
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Publisher/Subscriber
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Publisher/Subscriber
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Publisher/Subscriber
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
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.
Pode ser difícil alterar sistemas desenvolvidos neste modelo se o número de inter. for limitado pelo hardware.
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Controle dirigido a interrupções
© 2007 by Pearson Education
©Ian Sommerville 2006	 Engenharia de Software, 8ª. edição. Capítulo 11 Slide *
Referências
G, F. Arquiteturas de Software, Projeto I, 2008.2
J. R. F. Lima,;R. A. M. Valentim, B. G. Araújo;J. M. T. Lacerda;D. R. Carvalho;R. M. Medeiros. XRTPS – EXTENSIBLE REAL-TIME PUBLISH-SUBSCRIBE: MIDDLEWARE MULTICAST PARA TROCA DE DADOS BASEADO EM XML PARA REDES DE TEMPO REAL. http://www2.ifrn.edu.br/ojs/index.php/HOLOS/article/viewFile/585/458
Software Paradigms (Lesson 8), Introduction to Software Architecture
*
*
*
*