Arquitetura de Software

Aula 5 - Engenharia de Software Distribuído

Prof. Dr. Bruna C. Rodrigues da Cunha
bruna.rodrigues@ifsp.edu.br
Resolução de Exercício
Considerando os seguintes princípios:
○ Remova os métodos específicos da aplicação, eles devem ser movidos para seu local de
contexto.
○ Altere os nomes de métodos para torná-los gerais.
○ Torne o lançamento e/ou tratamento de exceções consistente.
○ Adicione uma interface de configuração para adaptação de componentes.
○ Integre os componentes necessários para reduzir dependências.
Desenhe diagramas de blocos simples para organizar um sistema de gerência de um
hospital. Pense que o hospital deve ter os seguintes subsistemas: gerência de
funcionários, gerência de pacientes (registros de consultas, internações, cirurgias,
histórico médico), contabilidade, gerência de uso de quartos/salas. Todos esses
sistemas precisam ser integrados e trocar informações entre si (e.g., o paciente precisa
pagar o plano/consulta/internação, médicos precisam tratar pacientes em
determinadas salas).
Resolução
Sistemas Distribuídos
● Atualmente, todos os grandes sistemas baseados em computadores são
sistemas distribuídos.
● Um sistema distribuído é “uma coleção de computadores independentes
que aparece para o usuário como um único sistema coerente.”
● O processamento de informações é distribuído em vários computadores,
em vez de concentrado em uma única máquina.
● A engenharia de software distribuída é, portanto, de grande importância
para os sistemas de computação atuais.
● Os sistemas distribuídos são mais complexos que os sistemas que são
executados em um único processador.
Características de um Sistema Distribuído
● Compartilhamento de recursos
○ Compartilhamento de recursos de hardware e software.
● Abertura
○ Uso de equipamentos e softwares de diferentes fornecedores.
● Concorrência
○ Processamento simultâneo para melhorar o desempenho.
● Escalabilidade
○ Facilidade em aumentar a escalabilidade adicionando novos recursos.
● Tolerância a erros
○ A capacidade de continuar em operação após uma falha ter ocorrido.
Considerações
● Transparência: até que ponto o sistema distribuído deve aparecer para o
usuário como um sistema único?
● Abertura: um sistema deve ser projetado usando protocolos padrão que
suportam a interoperabilidade?
● Escalabilidade: como o sistema pode ser construído de modo escalável?
● Segurança: como as políticas de segurança utilizáveis podem ser
definidas e implementadas?
● Qualidade de Serviço: como deve ser especificada a qualidade do
serviço?
● Gerenciamento de falhas: como as falhas do sistema podem ser
detectadas, contidas e reparadas?
Transparência
● Idealmente, os usuários não devem estar cientes de que um sistema é
distribuído e os serviços devem ser independentes das características de
distribuição.
● Para alcançar transparência, os recursos devem ser abstraídos e tratados
de forma lógica, em vez de física. O middleware mapeia recursos lógico
para recursos físicos.
Abertura
● Sistemas distribuídos abertos são sistemas construídos de acordo com
padrões geralmente aceitos.
● Componentes de qualquer fornecedor podem ser integrados ao sistema
e podem interoperar com os outros componentes do sistema.
● A abertura implica que os componentes do sistema podem ser
desenvolvidos independentemente em qualquer linguagem de
programação e, se estiverem em conformidade com os padrões,
funcionarão com outros componentes.
● Os padrões de serviço da Web para arquiteturas orientadas a serviços
foram desenvolvidos para serem padrões abertos.
Escalabilidade
● A escalabilidade de um sistema reflete sua capacidade de oferecer um
serviço de alta qualidade à medida que as demandas no sistema
aumentam
○ Tamanho: deve ser possível adicionar mais recursos a um sistema para lidar com um
número crescente de usuários.
○ Distribuição: deve ser possível dispersar geograficamente os componentes de um
sistema sem degradar seu desempenho.
○ Gerenciabilidade: deve ser possível gerenciar um sistema à medida que aumenta de
tamanho, mesmo que partes do sistema estejam localizadas em organizações
independentes.
Escalabilidade
● Scale Up: melhoria vertical – trocar por um hardware mais poderoso
● Scale Out: melhoria horizontal – adicionar mais instâncias do sistema
Segurança e Qualidade de Serviço
● Quando um sistema é distribuído, o número de maneiras que o sistema
pode ser atacado é significativamente maior, comparado a sistemas
centralizados.
● A qualidade de serviço (QoS) oferecida por um sistema distribuído reflete
a capacidade do sistema de fornecer seus serviços de forma confiável e
com um tempo de resposta e uma taxa de transferência aceitável para
seus usuários.
● A qualidade do serviço é particularmente crítica quando o sistema lida
com dados de tempo real, como fluxos de som ou vídeo.
○ Se a qualidade do serviço ficar abaixo de um valor limite, a mídia pode ficar tão
degradada que será impossível de entender.
Gerenciamento de Falhas
● Em um sistema distribuído, é inevitável que ocorram falhas, portanto o
sistema deve ser projetado para ser resiliente a essas falhas.
● "Você sabe que possui um sistema distribuído quando a falha de um
sistema que você nunca ouviu falar o impede de realizar qualquer
trabalho".
● Os sistemas distribuídos devem incluir mecanismos para descobrir se um
componente do sistema falhou, continuar a prestar o maior número
possível de serviços, apesar dessa falha e, na medida do possível,
recuperar-se automaticamente da falha.
Interação
A interação entre componentes em um sistema distribuído é classificada em
dois tipos:
● Interação processual, em que um computador chama um serviço
conhecido oferecido por outro computador e aguarda uma resposta
(RPC).
● Interação baseada em mensagens, envolve o computador que requer o
serviço enviar uma requisição com dados para outro computador. Não há
necessidade de esperar por uma resposta.
Arquitetura Cliente-Servidor
● Sistemas distribuídos que são acessados pela Internet são normalmente
organizados como sistemas cliente-servidor.
● Em um sistema cliente-servidor, o usuário interage com um programa em
execução no computador local (por exemplo, um navegador da Web ou
aplicativo móvel). Esse programa interage com outro(s) em execução em
computador(es) remoto(s).
● O computador remoto fornece serviços, como acesso a páginas da Web,
recursos multimídia, dados, softwares, que estão disponíveis para clientes
externos.
Balanceamento Cliente-Servidor
Padrões Arquiteturais para Sistemas Distribuídos
● Arquitetura Mestre-Escravo: usada em sistemas de tempo real nos quais tempos
de resposta de interação garantidos são necessários.
● Arquitetura Cliente-Servidor de Duas Camadas: usada para sistemas cliente-
servidor simples, onde o sistema é centralizado por motivos de segurança ou
simplicidade.
● Arquitetura Cliente-Servidor Multicamadas: usada quando há um alto volume
de transações a serem processadas pelo servidor e/ou cliente.
● Arquitetura de Componentes Distribuídos: usada quando recursos de
diferentes sistemas e bancos de dados precisam ser combinados ou como um
modelo de implementação para sistemas multicamadas.
● Arquitetura Peer-to-Peer: usada quando os clientes trocam informações
armazenadas localmente e a função do servidor é apresentar os clientes uns aos
outros.
Arquitetura Mestre-Escravo
● As arquiteturas Mestre-Escravo são comumente usadas em sistemas de
tempo real, onde podem existir processadores separados associados à
aquisição de dados do ambiente do sistema, processamento e
computação de dados e gerenciamento de atuadores.
● O processo “Mestre" é geralmente responsável pela computação,
coordenação e comunicações e controla os processos "escravos".
● Os processos "Escravo" são dedicados a ações específicas, como a
aquisição de dados de uma série de sensores, processamento de dados,
etc.
Arquitetura Mestre-Escravo
Arquitetura Cliente-Servidor de Duas Camadas
● Em uma arquitetura cliente-servidor de duas camadas, o sistema é
implementado como um servidor lógico único com um número indefinido
de clientes que usam esse servidor.
● Modelo de cliente magro, em que a camada de apresentação é
implementada no cliente e todas as outras camadas (gerenciamento de
dados, processamento de aplicativos e banco de dados) são
implementadas em um servidor.
● Modelo de cliente gordo, em que parte ou todo o processamento do
aplicativo é realizado no cliente. As funções de gerenciamento de dados e
banco de dados são implementadas no servidor.
Arquitetura Cliente-Servidor de Duas Camadas
Arquitetura Cliente-Servidor de Duas Camadas
Modelo de cliente magro:
● Usado quando sistemas legados são migrados para arquiteturas cliente-servidor.
● O sistema legado atua como um servidor de dados e processamento, com uma
interface gráfica implementada em um cliente.
● Uma grande desvantagem é que ele coloca uma carga de processamento pesada
no servidor.
Cliente de cliente gordo:
● Mais processamento é delegado ao cliente, pois o processamento do aplicativo é
executado localmente.
● Mais adequado para novos sistemas, onde as capacidades do sistema do cliente
são conhecidas antecipadamente.
● Mais complexo que um modelo magro, especialmente para gerenciamento. Novas
versões do aplicativo devem ser instaladas em todos os clientes.
Arquitetura Cliente-Servidor de Duas Camadas
● JavaScript permite que o processamento seja realizado localmente em um
navegador, então é possível que o modelo "cliente gordo" seja adotado
sem a preocupação com a instalação e atualização do software cliente.
● Aplicativos móveis realizam processamento local para minimizar as
demandas na rede.
● A atualização automática de aplicativos reduz os problemas de
gerenciamento.
● Agora há poucos sistemas no modelo de cliente magro, em que todo o
processamento é realizado no servidor remoto.
Arquitetura Cliente-Servidor Multicamadas
● Em uma arquitetura de cliente-servidor multicamadas, as diferentes
camadas do sistema, ou seja, apresentação, gerenciamento de dados,
processamento de aplicativos e banco de dados, são processos
separados que podem ser executados em processadores diferentes.
● Isso evita problemas com escalabilidade e desempenho.
Arquitetura Cliente-Servidor Multicamadas
Componentes Distribuídos
● Cada entidade distribuível é um componente que fornece serviços a
outros componentes e recebe serviços de outros componentes.
● Arquiteturas de componentes distribuídos sofrem de duas grandes
desvantagens:
○ Eles são mais complexos para projetar do que sistemas cliente-servidor. Arquiteturas de
componentes distribuídas são difíceis para as pessoas visualizarem e entenderem.
○ O middleware padronizado para sistemas de componentes distribuídos nunca foi aceito
pela comunidade. Diferentes fornecedores, como Microsoft e Sun/Oracle, desenvolveram
middlewares diferentes e incompatíveis.
● Como resultado, as arquiteturas orientadas a serviços estão substituindo
as arquiteturas de componentes distribuídos em muitas situações.
Arquitetura P2P
● Os sistemas Peer-to-Peer (P2P) são sistemas descentralizados em que o
processamento pode ser realizado por qualquer nó da rede.
● O sistema geral é projetado para aproveitar o poder computacional e o
armazenamento de um grande número de computadores em rede.
● A maioria dos sistemas P2P tem sido sistemas pessoais, mas há um
crescente uso comercial dessa tecnologia.
Software as a Sevice (SaaS)
O software como serviço (SaaS) envolve hospedar o software remotamente e
fornecer acesso a ele pela Internet:
● O software é implantado em um servidor (ou, mais comumente, em
vários servidores) e é acessado por meio de um navegador da web. Não é
instalado em um PC local.
● O software é de propriedade e gerenciado por um provedor de software,
em vez das organizações que usam o software.
● Os usuários podem pagar pelo software de acordo com a quantidade de
uso que fazem dele ou por meio de uma assinatura anual ou mensal.
Software as a Sevice (SaaS)
● O Software como Serviço (SaaS) é uma maneira de fornecer
funcionalidade em um servidor remoto com acesso do cliente por meio
de um navegador da web. O servidor mantém os dados e o estado do
usuário durante uma sessão de interação. As transações geralmente são
longas, por exemplo, criar e editar um documento.
● A Arquitetura Orientada a Serviços (SOA) é uma abordagem para
estruturar um sistema de software como um conjunto de serviços
independentes e sem estado. Esses podem ser fornecidos por vários
fornecedores e podem ser distribuídos. Normalmente, as transações são
transações curtas nas quais um serviço é chamado, faz alguma coisa e
retorna um resultado.
Computação na Nuvem
● A computação em nuvem é a disponibilidade sob demanda de recursos
do sistema de computador, especialmente armazenamento de dados,
software e capacidade de computação, sem o gerenciamento ativo direto
do usuário. O termo geralmente é usado para descrever centros de
dados disponíveis para muitos usuários pela Internet.
Computação na Nuvem
Três tipos principais de computação em nuvem:
● SaaS (software como serviço): para aplicativos que usam serviços Web.
● IaaS (infraestrutura como serviço): permite usar a potência de
computação e armazenamento de outras máquinas via Internet;
● PaaS (plataforma como serviço): oferece ferramentas para compilar e
hospedar aplicação na Web.

Será um dos temas dos seminários da disciplina!

Referências
Capítulo 17
SOMMERVILLE, Iam. Engenharia de Software. 10 ed. São Paulo: Pearson,
2019. 768 p.
Exercício
● O que você entende por escalabilidade? Discuta as diferenças entre escalabilidade horizontal e
vertical.
● Qual a diferença fundamental entre a abordagem cliente-gordo e a abordagem cliente-magro
para as arquiteturas cliente-servidor?
● Explique quando uma abordagem multicamadas é mais adequada que a abordagem cliente-
gordo.
● O que é SaaS? Quais a principal vantagem e a principal desvantagem desse modelo?