camadas - Erudito FEA-USP

FEA/USP
Faculdade de Economia, Administração e Contabilidade da
Universidade de São Paulo
Tecnologia de Informática
Arquitetura de
Sistemas Aplicativos
Prof.Dr. Antonio Geraldo da Rocha Vidal
Arquitetura de uma Aplicação Web
Funções das Camadas na
Arquitetura do Sistema Aplicativo
Camada
Aplicativo do
usuário
Responsabilidade
Funções
Ferramentas
Prover interface
Apresentação,
Ferramentas
compreensível e
entrada, navegação gráficas, linguagem
eficiente.
e análise de dados. de programação e
componentes.
Tomada de
Linguagem de
Regras de negócio Estabelecer a
política dos
decisões,
programação e
negócios: regras e imposição da
componentes.
heurística.
política, cálculos,
Preparar respostas coordenação de
para o usuário.
recursos.
Manter dados
Manutenção,
Banco de dados,
Banco de dados
consistentes,
atualização,
linguagem de
atualizados e
integridade e
banco de dados e
seguros.
segurança de dados XML.
Arquitetura em Camadas
 A arquitetura em camadas é lógica e não física.
 Se preocupa com as funções do aplicativo e não com
sua implementação.
 Essa mesma arquitetura pode ser usada para elaborar
sistemas distribuídos ou centralizados, tradicionais,
Cliente/Servidor ou para a Web.
 Entretanto, a utilização dessa arquitetura facilita a
distribuição dos componentes do aplicativo, quando
for preciso por razões de negócios, tecnológicas ou
ambas.
Benefícios da
Arquitetura em Camadas
 Estrutura para elaboração de aplicativos flexíveis que
possam ser alterados com facilidade para atender às
necessidades de negócios em constante mudança.
 Alto nível de reutilização de software.
 Desenvolvimento mais fácil de aplicativos grandes e
complexos em ambientes transacionais, Web e de
suporte à decisão.
 Desenvolvimento mais fácil de aplicativos distribuídos
que dão suporte ao gerenciamento central, a equipes
auto gerenciadas e ao atendimento externo.
Como Desenvolver
Sistemas Aplicativos Complexos?
Abstração:
– É uma técnica analítica para dividir um sistema em
vários níveis de detalhes (níveis de abstração) ou
camadas.
Encapsulamento:
– É um processo de combinar informações (conjuntos
de dados) e comportamentos (funções ou métodos)
em uma nova entidade, chamada componente (ou
objeto).
Abstração
Usando a abstração, pode-se ocultar uma série
de detalhes dos quais não se necessita num
determinado nível do sistema aplicativo.
A redução da quantidade de detalhes visíveis é
uma parte fundamental da descrição e do
projeto de sistemas aplicativos complexos.
A principal técnica para ocultar detalhes é
definir os níveis de abstração a serem
utilizados.
Arquitetura Baseada em
Níveis de Abstração
 Uma arquitetura em camadas, baseadas em
níveis abstração, possui três características
principais:
1. Camadas claramente definidas;
2. Interfaces formais e explícitas entre as camadas;
3. Detalhes ocultos e protegidos dentro de cada
camada.
Benefícios da Abstração na
Arquitetura em Camadas
Esconde deliberadamente de cada camada os
detalhes contidos na camada abaixo dela:
– Desenvolvimento simplificado do aplicativo: o
desenvolvedor de uma camada não precisa se
preocupar com as outras.
– Maior segurança e proteção: o desenvolvedor de
uma camada não pode controlar fisicamente outra
camada em qualquer nível de detalhe.
Interface entre as Camadas
 É a superfície entre os componentes
adjacentes de um aplicativo e o
dispositivo por meio do qual eles
interagem através das seguintes funções:
1. Informa o que o outro componente deve
fazer;
2. Pergunta o estado atual de outro componente;
3. Recebe os resultados das operações
solicitadas.
Detalhamento da Interface
entre as Camadas
Interface entre Componentes
para Acesso a Banco de Dados
Implementação das Camadas
com Componentes
Projeto de cada Camada na
Arquitetura em Camadas
Camada
Interface
Foco do Projeto
Aplicativo de usuário
(desktop ou browser)
GUI ou WEB
Objetos do
aplicativo,
independentes de
regras.
Processos de regras Fluxo dos processos
de negócios
Gerenciamento de
banco de dados
Transações e
consultas
Solicitação de
decisões
independentes da
interface de usuário
e dos dados.
Dados
independentes das
decisões.
Nenhuma camada deve realizar funções que sejam de responsabilidade de outra.
Camada de Interface
Apresentação:
– Apresentação de informações
– Metáforas visuais
– Navegação e transição consistente entre
formulários/páginas
Entrada:
– Coleta de informações (conjuntos de dados)
– Coleta de decisões (execução de ações)
– Interação (diálogo) com os usuários
Camada de Interface
Liberdade para os usuários:
– Moldam a interface do sistema aplicativo de acordo com
suas necessidades específicas, sem afetar as regras de
negócios e o banco de dados.
Liberdade para a organização:
– O aplicativo de usuário envia solicitações de processo
formais para executar as regras de negócios e transações e
consultas no banco de dados.
– As regras de negócio e o banco de dados ficam mais isolados
das mudanças na interface do usuário.
– Podem ser facilmente implementadas várias visões para
usuários diferentes, sem afetar as regras e os dados.
Camada de Regras de Negócios
e Lógica do Aplicativo
Interoperabilidade:
– Capacidade de compartilhar trabalho (regras),
compartilhar software (lógica) e fazer “coisas” de
forma consistente por toda a organização.
Reutilização:
– Um dos principais motivos para a impossibilidade
de alta reutilização de código é a falta da separação,
num mesmo sistema aplicativo, entre a interface de
usuário, as regras/lógica do negócio e o
gerenciamento do banco de dados.
Camada de Regras de Negócios
e Lógica do Aplicativo
Um único componente de software trata de uma
tarefa específica.
Este componente deve ser independente do
banco de dados e da interface do usuário.
Todos os aplicativos da organização sempre
utilizam este mesmo componente de software
(classe de objeto) para realizar esta mesma
tarefa.
Camada de Dados
Transações:
– Atualizações de dados consistentes;
– Imposição de regras de negócios básicas;
– Evitar mudanças não-autorizadas ou inválidas.
Consultas:
– Simplificar uniões complexas de tabelas;
– Assegurar consistência de resultados;
– Assegurar direitos de acesso.
Dados proveniente de várias “fontes”.
Aplicativos Complexos Exigem
Divisão do Trabalho
 O desenvolvimento de um sistema aplicativo complexo
normalmente exige especialização em:
–
–
–
–
–
–
–
–
–
Arquitetura de sistemas
Desenvolvimento de interface e design gráfico
Programação de negócios
Administração de dados
Administração de banco de dados
Programação componentes
Distribuição de aplicações e componentes
Administração de redes de comunicação
Gerenciamento de segurança
 Formação de pequenas equipes, em geral de 3 a 6 pessoas por
tipo de especialização.
Sistemas Distribuídos
Complexos
Servidor do
Distribuidor
Cliente em
casa
Internet
Internet
Servidor do
Fornecedor
Rede do Distribuidor
Servidor da Loja
Rede do Banco
Cliente em
casa
Servidor do
Fornecedor
Mainframe Regional
do Banco
Terminais de Caixa do Supermercado
Mainframe Principal
do Banco
Empresas Digitais
Empresa A
Mobile
Employees
Consumers, Partners
Empresa B
Mobile
Employees
Consumers, Partners
Customers
Partners
Suppliers
Modelo para o Planejamento,
Projeto e Desenvolvimento
Conceitual
Lógico
Físico
Aplicativos de
usuário
Fluxo de
Trabalho
Seqüências de
páginas e
formulários
Páginas e
Formulários
Regras de
Negócios
Fluxo de
processos de
negócio
Modelo de
processos e
regras
Programas e
Componentes
Banco de dados Modelo de dados Esquema de
banco de dados
Tabelas, índices
e Procedimentos
Pontos
vulneráveis e
tipos de ataque
Firewall, controle
de acesso e
disciplina
Segurança
Esquemas de
defesa e
autenticação
Do Modelo Conceitual ao
Modelo Físico
Conceitual
Modelo de
Negócios
Fluxo de
Processos
Fluxo de
Trabalho
Domínio do Problema: modelo do negócio (REGRAS)
Lógico
Modelo de
Dados
Interação de
Processos
Seqüência de
Formulários
Domínio da Solução: modelo do software (DESEMPENHO)
Físico
Banco de
Dados
Programas e
Componentes
Formulários
e Páginas
Problema versus Solução
 Quando a NASA iniciou o lançamento de astronautas,
descobriram que as canetas não funcionariam com
gravidade zero. Para resolver este problema,
contrataram a Andersen Consulting (hoje Accenture).
 Empregaram uma década e 12 milhões de dólares
desenvolvendo uma caneta que escrevesse com
gravidade zero, ao contrário, de ponta cabeça, debaixo
d'água, em praticamente qualquer superfície (incluindo
cristal) e suportando variações de temperatura de
abaixo de 0 até mais de 300 Celsius...
 Qual foi a solução dos Russos para esse problema?
Evolução do
Desenvolvimento de Aplicativos
Anterior
Arquitetura
Monolítica
Aplicativos do
usuário
Telas, teclas e
relatórios
Processos,
comportamentos
Modelo funcional
Banco de dados
Modelo de dados
Atual
Distribuída
Modelo de interação
de objetos e
componentes.
Interatividade,
documentos, objetos e
protótipos
Objetos e
componentes
Modelo de classes
Modelo de dados
Modelo de documentos
Estrutura de Projeto de um
Sistema Aplicativo
Interface Web
Regras de
Negócios
Lógica do
Aplicativo
Fonte de
Dados
Estrutura x Modelos
UML (Unified Modeling Language)
Modelos estáticos (definição de objetos)
– Diagramas de Processos de Negócio
– Diagramas de Dados (DER)
– Diagrama de Classes de Objetos
Modelos dinâmicos (interação de objetos)
–
–
–
–
Diagramas de fluxos de trabalho ou rotas de navegação
Diagramas de respostas a eventos e mensagens.
Diagramas de estados (regras de negócios)
Diagramas de atividades (transações e consultas)
Protótipos
– Interface do usuário
Modelo para Desenvolvimento de
Sistemas Aplicativos para a Web
Serviços de Usuário (interface): páginas Web
com formulários no navegador.
Serviços de Negócios (regras): serviços de
acesso em Servidores Web e serviços de regras
e lógica do negócio em Servidores de
Aplicativos.
Serviços de Dados (informações): serviços de
Servidores de Banco de Dados.
O Modelo de Serviços
Aplicativo com Uma Camada
Física
Aplicativo com Duas Camadas
Físicas
Aplicativo com Três Camadas
Físicas
Aplicativos com Múltiplas
Camadas
Funcionamento de Aplicativos
Web
Ciclo de Vida de Aplicativos
para a Web