Aula 2: Arquitetura em Trˆes Camadas e APIs

Aula 2: Arquitetura em Trˆ es Camadas e APIs

Diego Passos

Universidade Federal Fluminense

T´ecnicas de Projeto e Implementac¸˜ao de Sistemas II

Agenda

1 Arquitetura em Trˆes Camadas

2 Introduc¸˜ao `as APIs para Computac¸˜ao Corporativa

Agenda

1 Arquitetura em Trˆes Camadas

2 Introduc¸˜ao `as APIs para Computac¸˜ao Corporativa

Projeto em Camadas

T´ecnica Muito Usada em Computac¸˜ao e Engenharia Dividir um sistema em camadas.

Cada camada ´e respons´avel por um sub-conjunto de tarefas.

Camada de baixo oferta servic¸os.

I Requisitados pela camada diretamente acima.

Fluxo de execuc¸˜ao do sistema percorre as camadas atrav´es dessa comunicac¸˜ao/requisic¸˜ao de servic¸os.

Exemplo: Pilha de Protocolos TCP/IP

Usado na Internet.

I Sistema extremamente complexo.

N´os implementam uma pilha de protocolos.

I Camadas s˜ao empilhadas.

Cada camada “resolve uma parte do problema”.

Camadas e Funcionalidades

Camada de f´ısica: como representar informac¸˜ao no meio f´ısico.

Camada de enlace: como enviar dados para outro computador.

Camada de rede: como percorrer um caminho at´e o computador de destino.

Camada de transporte: como comunicar processos de m´aquinas distintas.

Camada de aplicac¸˜ao: como representar/manipular dados de alto n´ıvel.

Exemplo: Pilha de Protocolos TCP/IP (II)

Diversos protocolos para cada camada.

I Ex: TCPvs. UDP, 802.11vs. 802.3.

Protocolos de mesma camada podem ser intercambiados de acordo com as necessidades.

I Ofertam a mesma funcionalidade abstrata para as camadas superiores.

I Alterac¸˜ao em uma camada idealmente n˜ao resulta em mudanc¸as nas demais.

Permite a evoluc¸˜ao tecnol´ogica gradativa em cada camada.

I Exemplos:

F IPv4vs. IPv6.

F TCP Tahoe, Reno, Vegas, New Reno. . .

F Ethernet, Fast-Ethernet, Gigabyte-Ethernet. . .

Exemplo II: Arquitetura de Computadores

Primeiros Computadores

Eram programados diretamente em linguagem de m´aquina.

I Cabos epatch panels.

Exigiam grande conhecimento dohardware.

I Uso extensivo de manuais de referˆencia.

Desenvolvimento era dif´ıcil.

I Depurac¸˜ao ainda pior.

Soluc¸˜ao: Sucessivas Camadas de Abstrac¸˜ao Linguagem de alto n´ıvel.

Assembly.

Macro-instruc¸˜oes.

Micro-instruc¸˜oes.

Portas l´ogicas.

Exemplo II: Arquitetura de Computadores

Camadas facilitam o desenvolvimento e depurac¸˜ao.

I C´odigo ´e mais leg´ıvel em alto n´ıvel.

V´arias linguagens diferentes podem ser usadas em um mesmo computador.

Mesmo ohardware pode ser simplificado.

I Muita coisa hoje ´e feita em software.

I Bugs podem ser corrigidos.

F Exemplo: micro-c´odigo em processadores Intel.

Aumenta n´ıvel de portabilidade de software.

Desenvolvimento de Software em Camadas

Vantagens

Entendimento sobre cada camada ´e isolado.

I E poss´ıvel se concentrar em cada camada isoladamente.´ Implementac¸˜oes de camadas podem ser trocadas.

I Por motivos t´ecnicos, financeiros.

V´arios projetos usam camadas iguais/similares.

I Podem ser padronizadas.

I Aumenta potencial de reutilizac¸˜ao de c´odigo.

F C´odigo reutilizado tende a ser melhor e mais confi´avel.

Desvantagens

Nem sempre proveem encapsulamento total.

Podem afetar o desempenho.

Desenvolvimento de Software em Camadas: Hist´ orico

Inicialmente

N˜ao era utilizado.

Programas eram “simples” e manipulavam diretamente arquivos pr´oprios.

In´ıcio da D´ecada de 1990 Modelos de duas camadas.

I Cliente (interface) e servidor (banco de dados).

Componentes de interface cientes de SQL: integrac¸˜ao direta com banco de dados.

Funciona bem se programa basicamente manipula base de dados (cadastro e consulta).

Modelo de Duas Camadas: Problemas

O que fazer quando h´a L´ogica de Dom´ınio?

I Validar dados, implantar regras de neg´ocio, fazer c´alculos. . .

Implementac¸˜ao no Cliente Abordagem mais comum.

C´odigo era complexo por misturar exibic¸˜ao e l´ogica.

Se havia muitas “telas”, l´ogica era dividida em v´arios pontos do c´odigo.

Implementac¸˜ao no Servidor (Banco de Dados) Stored procedures.

Linguagens propriet´arias.

I Pouca portabilidade.

Linguagens com poucos recursos.

I C´odigo novamente complexo.

Soluc¸˜ ao: Modelo de Trˆ es Camadas

Divide-se oSoftware em:

I Camada de apresentac¸˜ao: interface com o usu´ario.

I Camada de dom´ınio: implantac¸˜ao da l´ogica de dom´ınio.

I Camada de fonte de dados: armazenamento e consulta de dados.

Ganhou popularidade com a Web.

I Conceito dobrowser como interface.

I Se a l´ogica est´a na interface, novas interfaces requerem re-implementac¸˜ao da l´ogica.

F Re-trabalho, bases de c´odigo distintas,. . .

I Soluc¸˜ao: mover l´ogica de dom´ınio para camada que pudesse ser acessada por diversas interfaces.

Camada de Apresentac¸˜ ao

Lida com a interac¸˜ao entre usu´ario e software.

Pode ocorrer de v´arias formas:

I Linha de comando.

I Interface texto.

I GUI paradesktop.

I Web.

E comum um mesmo sistema apresentar mais de uma implementac´ ¸˜ao nesta camada.

Responsabilidades:

I Apresentar informac¸˜ao ao usu´ario.

I Interpretar comandos do usu´ario e traduzi-los em ac¸˜oes para o dom´ınio e fonte de dados.

Camada de Fonte de Dados

De onde o sistema obt´em os dados.

I E para onde os dados v˜ao.

Lida com a comunicac¸˜ao com outros sistemas que fornecem/manipulam dados.

Exemplo mais comum: SGBD.

I Banco de dados armazena os dados relevantes `a aplicac¸˜ao.

I SGBD executa servic¸os de armazenamento, consulta e atualizac¸˜ao.

I Camada de fonte de dados se comunica com o SGBD requisitando servic¸os.

Mas n˜ao precisa envolver um banco de dados.

I Exemplo: gerenciamento de redes via SNMP.

Camada de L´ ogica de Dom´ınio

Tamb´em chamada de L´ogica de Neg´ocio.

Respons´avel por “realizar o trabalho” do sistema.

I Fazer c´alculos.

I Validar dados.

I Escolher entre v´arias fontes de dados.

I . . .

Abordagem Cross-Layer

Idealmente, camada de l´ogica de dom´ınio “esconde” fonte de dados da apresentac¸˜ao.

I Traz v´arios benef´ıcios.

As vezes, no entanto, pode haver quebra nesta hierarquia.`

I Soluc¸˜ao menos “pura”, mas pode ter benef´ıcios pr´aticos.

I Exemplo:

F Apresentac¸˜ao requisita dados diretamente da fonte de dados.

F Parte dos dados (que n˜ao requerem aplicac¸˜ao de l´ogica) s˜ao exibidos.

F Outra parte ´e passada para a l´ogica de dom´ınio para processamento.

I E preciso pesar as vantagens e desvantagens em cada caso.´

Separac¸˜ ao entre Camadas

Separac¸˜ao n˜ao precisa ser f´ısica.

I Camadas n˜ao precisam ser executadas em computadores diferentes.

I i.e., conceito de camadas pode ser simplesmente l´ogico.

Camadas podem ser implementadas como:

I Rotinas diferentes.

I Classes diferentes.

I Pacotes diferentes.

I Execut´aveis diferentes.

I . . .

Forma ideal de implementac¸˜ao:

I Depende da complexidade do projeto.

F Quanto mais complexo, maior deve ser a separac¸˜ao.

Como Identificar a Camada de L´ ogica de Dom´ınio

Separac¸˜ao entre camadas de apresentac¸˜ao e fonte de dados e grande.

I Dada uma funcionalidade, ´e f´acil distinguir a qual das duas camadas pertence.

Mas como saber se uma determinada funcionalidade pertence `a l´ogica de dom´ınio?

Teste simples:

I Suponha que a funcionalidade pertenc¸a `a apresentac¸˜ao (ou fonte de dados).

I Suponha que seja necess´ario implantar uma nova vers˜ao da camada.

F Nova interface, ou dados em arquivo XML.

I A funcionalidade precisar´a ser re-implementada?

F Se sim, deveria pertencer `a l´ogica de dom´ınio.

Como Identificar a Camada de L´ ogica de Dom´ınio (II)

Exemplo de Sistema de Vendas

Funcionalidade: itens cujas vendas aumentaram 10% ou mais no ´ultimo mˆes coloridos em vermelho.

Supor implementac¸˜ao na camada de apresentac¸˜ao:

I Interface obt´em os dados de vendas dos dois ´ultimos meses.

I Calcula percentual de aumento.

I Se maior que 10%, colore item.

Se adicionarmos uma nova interface, funcionalidade deve ser reimplementada.

Soluc¸˜ao mais correta:

I Criar m´etodo na camada de l´ogica de dom´ınio que retorna um booleano se item deve ser colorido.

I Camada de apresentac¸˜ao chama o m´etodo e s´o se preocupa em gerar o c´odigo para fazer a colorac¸˜ao.

Em ´ultima an´alise, ´e uma regi˜ao nebulosa.

Onde Executar Cada Camada?

Lembre-se: camadas s˜ao conceitos l´ogicos e separac¸˜ao pode n˜ao ser f´ısica.

Mas v´arios sistemas fazem a separac¸˜ao f´ısica das camadas.

I Exemplo: sistemas web.

Neste caso, onde cada camada deve ser executada?

I Decis˜ao de projeto.

I Projetos diferentes podem ter requisitos diferentes.

I E preciso analisar caso a caso.´

F Mas h´a casos t´ıpicos.

Onde Executar a Camada de Fonte de Dados

Quase sempre no servidor.

I Em geral, deseja-se que o sistema seja acess´ıvel de v´arios lugares diferentes.

I Dados tˆem que estar dispon´ıveis em todos estes acessos.

I Um servidor acessado via rede pode disponibilizar os dados.

Excec¸˜ao:

I Quando deseja-se permitir operac¸˜aooffline.

I Exemplo: GoogleDocs.

F Abordagem mista: dados ficam no servidor, mas m´aquina cliente guarda c´opias.

Onde Executar a Camada de Apresentac¸˜ ao

Dois casos t´ıpicos:

Interface tipo GUI (Desktop)

Quase exclusivamente, ´e executada no computador cliente.

Excec¸˜ao: desktop remoto.

Interface Web

Frequentemente no servidor.

I HTML renderizado no cliente, mas gerado no servidor.

Tecnologias como Javascript e Flash tˆem alterado esta tendˆencia.

Onde Executar a Camada de L´ ogica de Dom´ınio

Camada mais flex´ıvel em relac¸˜ao neste quesito.

Pode rodar:

I No cliente.

I No servidor.

I Em ambos.

F Novamente, conceito de divis˜ao em camadas ´e l´ogico e n˜ao f´ısico.

Agenda

1 Arquitetura em Trˆes Camadas

2 Introduc¸˜ao `as APIs para Computac¸˜ao Corporativa

Computac¸˜ ao Corporativa: Relembrando. . .

Integrac¸˜ao com outras aplicac¸˜oes corporativas.

L´ogica de neg´ocio tende a mudar/aumentar.

E preciso simplificar a manutenc´ ¸˜ao do c´odigo.

Mais:

I Robustez.

I Escalabilidade.

I Seguranc¸a.

Computac¸˜ ao Corporativa: Primeira Abordagem

Implementar tudo “do zero”.

I Implementar a interface (protocolo) para comunicac¸˜ao com cada aplicativo.

I Implementar c´odigo espec´ıfico para acessar cada diferente banco de dados envolvido.

I Implementar cada diferente interface com usu´arios poss´ıvel.

I . . .

Problemas

Requer grande tempo de desenvolvimento.

Requer grande tempo de teste.

Se uma nova tecnologia surge, ´e preciso repetir o trabalho de implementac¸˜ao.

C´odigo ´e muito mais complexo.

Mais propenso a erros e vulnerabilidades.

Computac¸˜ ao Corporativa: Abordagem Baseada em APIs

Operac¸˜oes de baixo n´ıvel s˜ao escondidas por uma biblioteca/pacote.

C´odigo a ser implementado inclui apenas chamadas de mais alto n´ıvel.

I Mais gen´ericas.

I Resiste melhor a alterac¸˜oes nas tecnologias usadas.

Parte mais complexa do c´odigo ´e feita pela API.

I C´odigo geralmente bem utilizado e testado.

APIs Corporativas

Conceito de uso de APIs j´a ´e conhecido, mesmo para aplicac¸˜oes “n˜ao-corporativas”.

Qual a diferenc¸a?

Express˜ao ´e usada em dois contextos:

I APIs disponibilizadas para o uso de servic¸os de determinadas empresas.

F Exemplos: GoogleMaps, BingMaps, Facebook, . . .

I APIs que servem para desenvolvimento de aplicac¸˜oes corporativas.

F Exemplo: JDBC.

APIs para Aplicac¸˜ oes Corporativas

S˜ao geralmente APIs de n´ıvel mais alto.

Geralmente, agn´osticas em relac¸˜ao a tecnologia.

Exemplo (novamente): JDBC.

I Pode acessar BDs Oracle, DB2, Postgres, MySQL,. . .

I Cada um destes SGBDs tem suas pr´oprias APIs para diversas linguagens.

I Migrar de um SGBD para outro, exigiria adaptar c´odigo a nova API.

I JDBC provˆe acesso uniforme a todas.