ACS03 - Arquiteturas de Aplicação

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

Arquitetura Cliente/Servidor
Parte 03
Arquiteturas de Aplicação
Eduardo Xavier
– * –
Aplicação
Definição
Uma aplicação é um conjunto de componentes que permite ao usuário realizar acesso e manipulação de dados obedecendo a parâmetros de controle pré-estabelecidos pela lógica do usuário
Uma aplicação deve ser capaz de realizar as seguintes funções:
Lógica de interface do usuário
Lógica de negócios
Lógica de manipulação de dados
– * –
Aplicação
Lógica de interface do usuário
Apresentação dos dados, isto é, as atividades de aceitação (entrada) de exibição de dados para o usuário final no formato apropriado para ele – o que inclui a formação da tela (ou front-end) e, a leitura de dados;  
Análise dos dados fornecidos pelo usuário, incluindo, por exemplo, a validação de valores, e a verificação dos tipos de dados; 
Fornecimento de ajuda sensível ao contexto ao usuário final; 
Prover recursos de navegabilidade na aplicação ao usuário final; 	
– * –
Aplicação
Lógica de negócios
Implementar as regras de negócio específicas do escopo do sistema de informação e que correspondem às práticas administrativas da organização.
Lógica de manipulação de dados
Funções de manipulação dos dados e seu repositório – isto é, funções responsáveis pelo armazenamento e recuperação em um meio persistente (bancos de dados);
Funções de acesso aos dados – responsáveis por prover o acesso físico a dados tais como: índices, segurança de acesso, funções de pesquisa etc., e são providas pelos SGBD (Sistema de Gerenciamento do Banco de Dados).
– * –
Porque utilizar arquitetura multicamadas
1) Desacoplamento
Nas aplicações de 1 só camada, a lógica de negócios, apresentação e controle estão normalmente interligadas, apresentando um alto acoplamento. Isto normalmente se torna um problema desde que alterações em um componente impactam em muitos outros, necessitando que sejam feitas validações de grandes partes do sistema mesmo para pequenas alterações.
Outro efeito desse alto acoplamento é a dificuldade de se reutilizar o código.
Nas aplicações implementadas em camadas, os diferentes aspectos são implementados separadamente, forçando o desacoplamento e permitindo a reusabilidade dos vários componentes.
– * –
Porque utilizar arquitetura multicamadas
2) Distribuição do processamento
As aplicações empresariais normalmente necessitam ter seu processamento distribuído entre vários hardwares, seja por necessidade de escalonar o processamento ou pela distribuição geográfica.
O ponto de atenção diz respeito à complexidade no desenvolvimento de sistemas que funcionam através de processamento distribuído.
Os middlewares permitem que os sistemas sejam desenvolvidos sem que o desenvolvedor necessite se preocupar com os detalhes como localização e sincronização do se preocupar com os detalhes como localização e sincronização do acesso aos recursos, comunicação, protocolos envolvidos, etc.
– * –
Porque utilizar arquitetura multicamadas
3) Componentização
O desenvolvimento em multicamadas é feito pela construção de componentes de software.
Um componente consiste de uma porção de software com uma interface (forma de se comunicar com o mesmo) bem definida, e com funcionalidade pré-definida.
Componentes podem ser utilizados para compor componentes maiores. São como peças que podem ser combinadas para formar componentes maiores.
Essas peças podem ser reutilizadas ou substituídas por outras equivalentes conforme a necessidade de desenvolvimento.
– * –
Escolha de Componentes
Desde a fase de projeto de uma aplicação é preciso levar em consideração diversos fatores que influenciam no bom funcionamento e desempenho satisfatório da mesma
Estes fatores sevem como indicadores para decidir:
Como será a interação com o usuário
Qual a disponibilidade da aplicação
A que restrições estará sujeita a aplicação
Como estes componentes serão configurados
De que forma estes componentes se comunicam
Qual o custo da aplicação
– * –
Escolha de Componentes
Alguns fatores relevantes para escolha de componentes:
Volume de tráfego
Qual o volume de dados e controles que irá trafegar pela rede? 
Capacidade de rede disponível
A rede atual suporta o volume previsto ou será expandida para suportar?
Taxa de ocupação nas máquinas
As máquinas (cliente e servidor) possuem espaço para hospedar a nova aplicação?
Capacidade de processamento nos servidores
Os servidores que irão hospedar a nova aplicação suportam o aumento de processamento que a mesma trará?
– * –
Escolha de Componentes 
Mais alguns fatores:
Utilização dos servidores por outras aplicações
Os servidores serão compartilhados? Com quem?
Capacidade de processamento nos clientes
As máquinas clientes suportam a carga de processamento prevista?
Recursos de segurança
Qual o nível de exposição dos dados? 
Que medidas devem ser tomadas para manutenção de privacidade e e integridade?
Sazonalidade
A aplicação terá um comportamento constante ou se modifica no tempo?
Quais os limites tolerados de desempenho diante destas variações?
– * –
Escolha de Componentes
E ainda:
Expansões futuras
A aplicação possui uma curva de crescimento?
Volume de dados, quantidade de usuários, aumento de demanda, ...
Haverão novos módulos a serem acrescentados?
Está previsto algum tipo de atualização nos componentes?
Tendências de mercado
Qual a vida útil prevista para a aplicação?
A solução adotada para desenvolver a aplicação segue a tendência de mercado? Ou se antecipa?
Existem profissionais capacitados disponíveis no mercado?
Como os planos da organização influenciam na vida útil da aplicação?
Colaboração externa (outras organizações) é prevista ou desejada?
– * –
Questionamentos sobre a arquitetura multicamadas
3 camadas x 4 camadas (web básica)
A ideia básica do modelo de quatro camadas é retirar a apresentação do Cliente e centralizá-las em um determinado ponto, o qual na maioria dos casos é um servidor Web. 
Com isso, o próprio Cliente deixa de existir como um programa que precisa ser instalado em cada computador da rede. O acesso à aplicação é feito através de um navegador.
Camadas x Servidores 
Particionamento Lógico não é a mesma coisa que Ambiente Físico
– * –
Componentes de Aplicação
Gartner Group
Entidade especializada em análise de tendencias de tecnologia
Proposta do Gartner Group:
Organizar as aplicações cliente/servidor em camadas de funcionalidades, isolando os componentes de software de acordo coma função desempenhada na aplicação
Desenvolver estas aplicações seguindo modelos padronizados que definem como será feita a distribuição de cada camada
As camadas:
Funções de processamento da lógica de interface do usuário
Funções de processamento da lógica de negócio
Funções de gerencia de dados
– * –
Componentes de Aplicação
CAMADA: Funções de processamento da lógica de interface do usuário
São funções relacionadas às atividades de entrada e saída do usuário final, onde se concentra a formatação da informação como o usuário a percebe
Alguns exemplos:
Layouts de telas e obtenção de dados
Análise preliminar de dados fornecidos pelo usuário (validação de valores básicos / verificação de tipos de dados)‏
Fornecimento de ajuda sensível ao contexto
O Gartner Group propõe a divisão destas funções em duas camadas:
Gerenciamento de apresentação
Lógica de apresentação (que não necessariamente precisa estar ligada diretamente ao usuário)‏
– * –
Componentes de Aplicação
CAMADA: Funções de processamento da lógica de negócio
São as funções que implementam regras e processos de negócio de uma organização
Regras de negócio
São definições de funcionamento de algum tema específico, delimitando escopos, políticas de tratamento, objetivos e compromissos, entre outras atribuições
Processos de negócio
São atividades encadeadas que, ao serem executadas de forma correta, geram determinado produto ou serviço.
Tanto regras quanto processos
de negócio variam de uma organização para outra e até mesmo entre setores de uma mesma organização
– * –
Componentes de Aplicação
CAMADA: Funções de gerencia de dados
Funções de manipulação dos dados
São responsáveis pelo armazenamento e manipulação dos dados existentes no banco de dados
Exemplo: inserção, alteração e exclusão de determinada informação
Funções de acesso a dados
Prover o acesso físico a dados
Exemplos: índices, funções de pesquisa, etc.
A estratégia de dados que será adotada pela aplicação deve definir não só a forma como o dado será armazenado, mas como ele será manipulado
Outro aspecto relevante é o compartilhamento da informação. Existem duas opções de implementação:
Centralizar os dados e gerenciar o acesso remoto
Dividir ou replicar os dados
– * –
Modelos de Distribuição do 
Gartner Group
A proposta do Gartner Group consiste em distribuir os componentes de uma aplicação cliente/servidor em cinco modelos possíveis:
Apresentação Distribuída (Distributed Presentation / Interface)‏
Apresentação Remota (Remote Presentation / Interface)‏
Lógica Distribuída (Distributed Logic)‏
Gerenciamento Remoto de Dados (Remote Data Management)‏
Gerenciamento Distribuído de Dados (Distributed Data Management)‏
Estes cinco modelos assumem que a aplicação é implementada em dois “ambientes” (ou máquinas): um front-end cliente e um back-end servidor, onde as quatro camadas de componentes de aplicação já vistas se distribuem
– * –
Modelo: 
Apresentação Distribuída
Apenas as funções de apresentação (lógica de interface de usuário) são compartilhadas entre o cliente e o servidor.
As funções de aplicação e gerencia de dados ficam no servidor, o que permite seu compartilhamento com outras aplicações
As funções que interagem com os dispositivos físicos são alocadas no cliente (exemplo: controle do mouse)‏
Normalmente este modelo aplica a técnica conhecida como “screen-scraping”, onde uma interface gráfica (GUI) é colocada em frente a uma outra interface baseada em caracter pré-existente, visando migrar para um ambiente gráfico mais moderno uma aplicação-lagado mais antiga (geralmente baseada em mainframe)‏
A aplicação está completamente hospedada no mainframe, mas a interface com o usuário final está em uma plataforma baixa (ex: microcomputador usando Windows ou Linux);
– * –
Modelo: 
Apresentação Distribuída
Lógica de IU
Aplicação
Cliente
Lógica de IU
Aplicação
Servidor
Lógica de Negócio
Gerência de Dados
BD
– * –
Modelo: 
Apresentação Remota
As funções relacionadas com a lógica de interface do usuários são consideradas remotas em relação ao restante da aplicação (daí o nome do modelo) 
Características:
Funções interface são alocadas integralmente no cliente enquanto que os demais componentes (lógica de negócio e gerência de dados) ficam hospedados no servidor
Este tipo de abordagem é considerada aconselhável para aplicações onde a interação do servidor com o usuário é mínima
– * –
Modelo: 
Apresentação Remota
Aplicação
Cliente
Aplicação
Servidor
Lógica de Negócio
Gerência de Dados
BD
Lógica de IU
– * –
Modelo: 
Lógica Distribuída
Também conhecido como Função Distribuída
Neste modelo as camadas se distribuem da seguinte forma:
A interface de usuário (lógica de IU) fica totalmente no cliente
A distribuição atinge a lógica de negócio, que matém parte de suas funções no cliente e parte no servidor
A gerência de dados fica totalmente no servidor
– * –
Modelo: 
Lógica Distribuída
Aplicação
Cliente
Aplicação
Servidor
Lógica de Negócio
Gerência de Dados
BD
Lógica de IU
Lógica de Negócio
– * –
Modelo: 
Lógica Distribuída
Cenários de distribuição para o conjunto de funções da lógica de negócio
O conjunto contém funções corpartilhadas com outras aplicações (rotinas em comum)?
Considerar a possibilidade de se adotar um servidor de aplicações
O conjunto contém funções que exigem uma capacidade de processamento maior do que a capacidade do cliente?
Considerar a possibilidade de se adotar um servidor de cálculos em outra estação
A lógica de negócio possui um alto grau de interação com o cliente?
Considerar a possibilidade de adotar outro modelo (gerenciamento remoto ou distribuído de dados) para minimizar o tráfego da rede
O volume de dados manipulado pelo conjunto é elevado?
Alocar as funções relacionadas a dados no SGBD (minimiza o tráfego)‏
– * –
Modelo: 
Gerenciamento Remoto de Dados
As funções relacionadas com a lógica de interface e lógica de negócio ficam hospedadas no cliente
As funções de gerenciamento de dados (manipulação e acesso) ficam hospedadas no servidor (remota em relação ao cliente)‏
Este modelo é comum em redes departamentais hospedando aplicações cliente/servidor
– * –
Modelo: 
Gerenciamento Remoto de Dados
Lógica de IU
Aplicação
Cliente
Lógica de Negócio
Aplicação
Servidor
Gerência de Dados
BD
– * –
Modelo: 
Gerenciamento Distribuído de Dados
As funções relacionadas com a lógica de interface e lógica de negócio ficam hospedadas no cliente
As funções de gerenciamento de dados são distribuídas entre cliente e servidor
No cliente ficam as funções de manipulação de dados
No servidor ficam as funções de acesso a dados
Os dados estão divididos entre cliente e servidor
– * –
Modelo: 
Gerenciamento Distribuído de Dados
Lógica de IU
Aplicação
Cliente
Lógica de Negócio
Aplicação
Servidor
Gerência de Dados
BD
Servidor
Gerência de Dados
BD
Cliente
– * –
Críticas aos Modelos de 
Distribuição do Gartner Group
Embora adotado como padrão de mercado e aclamados pela sua simetria e simplicidade, estes modelos sofrem críticas(*) por desconsiderarem os seguintes aspectos:
Distribuição do processamento e distribuição dos dados são duas coisas distintas
As soluções de distribuição de dados podem ser gerenciadas por um SGBD, o que as torna transparentes para o desenvolvedor, ferindo a definição de alguns dos modelos propostos
Dependendo do tamanho das aplicações e da complexidade do ambiente, pode haver necessidade de se inserir uma ou mais camadas a mais entre cliente e servidor
Isso abre espaço para outras configurações de distribuição eficientes
(*) A primeira crítica formal ao modelo surgiu em “Database Programming & Design” - Artigo publicado por Paul Winsberg em 1993
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*