13 arquitetura de software - estilos arquitetônicos

23/02/2013 1

Arquitetura de Software

Estilos Arquitetônicos

Prof. Rodrigo Fetter Marques

23/02/2013 2

Estilos arquitetônicos

• Alguns estilos arquitetônicos:

– Arquitetura baseada em camadas – os componentes são organizados em camadas;

– Arquitetura baseada em dados – os processos se comunicam por meio de repositórios de dados comum;

– Arquitetura baseada em objetos ou componentes – cada objeto corresponde a um componente. Os componentes são conectados através de chamadas remotas;

– Arquitetura baseada em eventos – processos se comunicam por meio de propagação de eventos que transportam dados.

– Arquitetura baseada em serviço (SOA) - processos se comunicam por meio da prestação de serviços;

– Arquiteturas híbridas – dois ou mais estilos podem ser combinados para representar a arquitetura de um software.

23/02/2013 3


Estilos arquitetônicos - Arquitetura baseada em

camadas


Desenvolvimento em Camadas

• Divisões lógicas de um programa

– Lógica de Apresentação

• Interação usuário x aplicativo

• Apresentação das informações

– Lógica de Negócio

• Regras que governam o processo de negócio

– Lógica de Acesso a Dados

• Funcionalidades de acesso a dados e persistência

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.

Modelo em camadas

• Esse modelo organiza um sistema em camadas, cada uma

fornecendo um conjunto de serviços.

• Cada camada pode ser imaginada como uma máquina abstrata cuja

linguagem de máquina é definida pelos serviços oferecidos pela

camada.

• Apoia o desenvolvimento incremental de sistemas. À medida que

uma camada é desenvolvida, alguns serviços fornecidos por essa

camada pode ser disponibilizados para os usuários.

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.

Exemplos de modelos em camadas

Mais exemplos de camadas

Detalhamento da Interface

entre as Camadas

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

de negócios

Fluxo dos processos Solicitação de

decisões

independentes da

interface de usuário

e dos dados.

Gerenciamento de

banco de dados

Transações e

consultas

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”.

23/02/2013 22

1, 2, 3, N Camadas

Lógica de

Apresentaçã

o

Lógica de

Negócios

Lógica de

Acesso a

Dados

Banco

de

dados

Código Monolítico


1 Camada


1 Camada


2 Camadas

Lógica de

Apresentaçã

o

Lógica de

Negócios

Banco

de

dados

Cenário de 2

camadas físicas

Lógica de

Acesso a

Dados


2 Camadas

• Problemas do modelo

– Cliente com lógica de negócio

– Necessidade do cliente saber detalhes da localização das

fontes de dados

– Clientes gordos

– Atualizações individuais

– Suporte ao desenvolvimento WEB


2 Camadas

•Camada de Apresentação com Regras de Negócio Juntas.

•Camada de Persistência.

Problemas para o usuário, que não tem os programas funcionando

como deveriam; Problemas para a equipe de desenvolvimento que

não tem o seu trabalho reconhecido e, normalmente, tem que

trabalhar apenas "apagando incêndios"; e Problemas para a

Administração/Gerência da rede que não consegue gerar os

resultados esperados pela Administração da empresa, apesar dos

elevados valores já investidos.


2 Camadas

30

Arquitetura em duas camadas


3 Camadas

Banco

de

dados

Cenário de 3

camadas físicas

Lógica de

Acesso a

Dados

Lógica de

Negócio

Lógica de

Apresent

ação


3 Camadas

• Vantagens

– Independência entre camadas

– Divisão de trabalho

– Facilidade na atualização

– Proteção do código

– Transparência no acesso a dados

– Maior portabilidade


3 Camadas

Modelo e códigos construídos para representar as camadas.

Os servidores não precisam estar necessariamente em máquinas diferentes, podem estar na mesma máquina. Porem questões de performance são relevantes.

• Camada de Apresentação

• Camada de Negócios

• Camada de Persistência


3 Camadas

36

Arquitetura em três camadas

37

Arquitetura em três camadas Web


3 Camadas

APRESENTAÇÃO NEGÓCIO OU LÓGICA PERSISTÊNCIA

(INTEGRAÇÃO)

NAVEGADOR WEB SGDB V

C

M

SERVIDOR CLIENTE - SERVIDOR CLIENTE

SERVIDOR WEB

Helper classes


3 Camadas


Multiplas Camadas

42

Arquitetura em camadas

CLIENTE

(APRESENTAÇÃO)

NAVEGADOR WEB

CLIENTE

PERSISTÊNCIA

SGDB

SERVIDOR

GERENCIA DE

APRESENTAÇÃO

NEGÓCIO

SERVIDOR WEB

CLIENTE - SERVIDOR CLIENTE - SERVIDOR

SERVIDOR

APLICAÇÃO

EJB in

MVC

V

C

M


Multiplas Camadas


Multiplas Camadas - JEE

MVC Desenvolvimento em Camadas

Multiplas Camadas - JEE

23/02/2013 47



dados


Modelo baseado em dados

• Os subsistemas que constituem um sistema devem trocar

informações de modo que possam trabalhar juntos eficientemente.

• Existem duas maneiras:

1. Todos os dados compartilhados são mantidos em um banco

de dados.

2. Cada subsistema mantém seu próprio banco de dados e

disponibiliza-os aos outros subsistemas.

• A maioria dos sistemas que usam grandes quantidade de dados

usam o primeiro modelo, ou seja, modelo repositório compartilhado.


1º - Dados compartilhados 2º - Subsistemas controladores

Diagrama de Fluxo de Dados


• O foco da arquitetura é nos dados.

• Algumas organizações mantém o controle e a gestão da arquitetura

de dados centralizada (estratégica).

• Maneira eficiente de compartilhas dados.

• Maneira eficiente de manter a integridade dos dados.

• Maneira eficiente de controlar o acesso aos dados.

• Os subsistemas que produzem dados não precisam saber como

esses dados serão usados por outros subsistemas.

– Os subsistemas foca na integridade de domínio e integridade

referencial dos dados.

– Os subsistemas mantém as regras de persistências dos dados.

– Alguns subsistemas mantém e controlam as regras de negócio

aplicáveis aos dados.

23/02/2013 52



componentes


23/02/2013 53

Estilos arquitetônicos

• É formulado em termos de componentes:

– Como estão conectados;

– Como os dados são trocados;

– Maneira como os componentes são configurados.

• Um componente é uma unidade modular com interfaces requeridas

e bem definidas, que é substituível dentro de seu ambiente.

• Um conector é descrito como um mecanismo que serve de

mediador da comunicação ou da cooperação entre componentes.

Modelos Orientados a Objetos

Diagramas da UML

Correspondência clara entre os modelos dos domínios do problema,

do projeto e da implementação

Class Name

attribute:Type = initialValue



operation(arg list):return type

Class Name





0..1 1...*

Class Name





Class Name



Desenvolvimento de Sistemas Orientados a Objetos

•Necessita ambientes de desenvolvimento extremamente

rigorosos e formais, com pessoal altamente treinados

•Nos grandes projetos abstrações corretas são difíceis de

realizar

•Modelos de objeto mal realizados criam mais problemas do

que soluções

•O nível de granularidade dos objetos é muito baixo, o que

torna complexo o controle da dependência entre eles

Componentes

Definição: Um pequeno grupo de objetos trabalhando

agrupados a fim de prover uma função do sistema

Os objetos dentro do componente não são

conhecidos por outra parte do sistema, exceto pelo

próprio componente

Características dos Componentes

•Tem todas as características de um objeto

•Tem limites impostos pela plataforma para a qual foi projetado

•Podem existir independentes dos outros componentes, exceto

daqueles que usa na mesma plataforma

•Tem uma interface fixa e comum a todos os demais

componentes do sistema

•São auto descritos ( os seus clientes sabem como usá-los )

Componentes de Software

•Conjunto discreto, administrável de lógica

•Código que implementa um conjunto pré-definido de

interfaces

•Não são aplicações inteiras

•Não rodam sozinhos

•São usados como peças de quebra-cabeça para

resolver um problema maior

•Um componente que resolve um determinado problema

pode ser comprado e combinado com outros para

resolver um problema maior

Componente de Software: Exemplo

Componente Cálculo de Preço Final

Manuseia informações sobre o preço de um conjunto de

produtos, fornecendo o preço total da compra

Baseado num conjunto de Regras de Definição de Preços

•Preços unitários dos produtos

•Quantidade de itens de produto comprados

•Desconto de quantidade/ cliente / região

•Sobretaxas ( impostos, transporte )

Pode ser Usado:

•Serviço de Correio para definir o preço de remessa de pacotes

•Fabricante de automóveis para descriminar o preço do automóvel vendido

Separação da Interface e da sua Implementação

Interface do Componente

•Define o contrato do componente com o código do outro

componente que o chama

•Esconde de seus clientes os detalhes de sua construção

•Permite que seus clientes somente tratem com os resultados finais

de suas próprias operações

Implementação do Componente

•Lógica da programação interna, escondida de seus clientes

•Pode ser mudada sem alterar do código de seus clientes

Desenvolvimento Baseado em Componentes

•Um sistema complexo pode ser considerado como um conjunto

composto de um número arbitrário de pequenos sistemas coesivos (

componentes )

•Cada componente é construído para implementar um conjunto

definido de responsabilidades

•Cada componente é auto contido e acoplado a outros

componentes

•Componentes são projetados para serem utilizados dentro de uma

plataforma que integra todos os componentes numa aplicação

Compone nt

Compone nt

Compone nt

Plataforma baseada em Componentes

•Facilita a construção, administração e manutenção de

componentes

•Deve ser padronizada

Deve conter:

•Ferramentas para desenvolver componentes

•Um Container para gerenciar os componentes utilizados:

Ambiente runtime para executar os componentes

Inclui conjunto de serviços que os componentes

necessitam

•Ferramentas para implementação e manutenção

Customização de componentes para ambientes

específicos

Plataforma baseada em Componentes

•Permite o desenvolvimento e a utilização de sistemas baseado

em componentes

•Cria instâncias runtime de componentes

•Permite a componentes descobrir e se comunicar com outros

componentes

•Provê serviços comuns adicionais, como:

Persistência

Transações

Independência de localização

Segurança

Monitoramento

Uso de Componentes: Vantagens

Técnicas

•A complexidade é melhor administrada, permitindo melhor qualidade

nas soluções

•Funcionalidade técnicas ( não de negócios ) é concentrada na

plataforma

Negócios

•Produtos de melhor qualidade

•Tempo menor para desenvolvimento de sistemas

•Melhor utilização de recursos humanos

•Habilidade de resposta a mudanças

•Custo reduzido

•Alto reuso para projetos futuros

Uso de Componentes: Desvantagens

•Os componentes são fortemente acoplados uns aos outros: uma

mudança no código de um deles pode levar a mudanças nos

demais

•A administração da complexidade da dependência entre os

componentes em grandes sistemas é difícil: um componente

ainda tem que saber muito sobre os demais ( aos quais se acopla

)

•As soluções proprietárias:

( DCOM – MS, CORBA )

23/02/2013 66



serviço


SOA

• Arquitetura que tem tido destaque na integra-ção de negócios

atualmente.

• SOA segundo a Accenture:

“Uma arquitetura que define como funções de negócios dinstintas,

implementadas por siste-mas autônomos, devem operar

conjuntamen-te para executar um processo de negócio.”

SOA

• Cada função de negócio (componente) é im-plementada como um

serviço.

• Esses serviços ficam disponíveis em uma re-de para que as

aplicações possam utilizá-los. Em geral, esta rede é a internet e os

serviços são chamados de web services.

Características da arquitetura

• As partes (serviços) são bastante indepen-dentes entre si.

• Não há limitações em relação à plataforma ou à linguagem utilizada

para implementar um serviço, apenas em relação a como eles

comunicam-se.

• Um serviço encapsula uma lógica de negó-cio. Assim, temos um

alto índice de reapro-veitamento.

Um exemplo

Benefícios

• Tempo e custo de desenvolvimento serão re-duzidos ao

reutilizarmos um serviço em uma parte diferente do sistema.

• A aplicação final é mais facilmente extensí-vel.

• Uma aplicação diferente poderá se beneficiar dos serviços

implementados anteriormente.

Padrões utilizados

• XML (Linguagem de Marcação Extensível)

• SOAP (Protocolo de Acesso a Objetos Simples)

• WSDL (Linguagem de Descrição de Serviços Web)

• UDDI (Descrição, Descoberta e Integração Universais)

Lógica de Negócios

Dados Apresentação

Publicação Arquitetura

Orientada a

Serviços

- SOA -

SOA - Características Arquiteturais

•Distribuída: os elementos funcionais da aplicação são utilizados

em múltiplos sistemas ( provedor, consumidor, publicador ),

localizados em pontos diferentes

•Acoplamento Fraco: as ligações entre os elementos funcionais

não são fixas ou rígidas, podendo ser assíncronas

•Escalável: novos elementos podem ser agregados, um serviço

pode ser composto de outros serviços, sistemas legados,

sistemas de pacotes

•Baseada em Padrões: independente de vendedores específicos

13 arquitetura de software - estilos arquitetônicos

Documents