Arquitetura de Software Estilos Arquitetnicos

Prof. Rodrigo Fetter Marques

23/02/2013

Estilos arquitetnicos
Alguns estilos arquitetnicos: Arquitetura baseada em camadas os componentes so organizados em camadas; Arquitetura baseada em dados os processos se comunicam por meio de repositrios de dados comum; Arquitetura baseada em objetos ou componentes cada objeto corresponde a um componente. Os componentes so conectados atravs de chamadas remotas; Arquitetura baseada em eventos processos se comunicam por meio de propagao de eventos que transportam dados. Arquitetura baseada em servio (SOA) - processos se comunicam por meio da prestao de servios; Arquiteturas hbridas dois ou mais estilos podem ser combinados para representar a arquitetura de um software.

23/02/2013

Arquitetura de Software Estilos arquitetnicos - Arquitetura baseada em camadas

Prof. Rodrigo Fetter Marques

23/02/2013

Desenvolvimento em Camadas
Divises lgicas de um programa Lgica de Apresentao Interao usurio x aplicativo Apresentao das informaes Lgica de Negcio Regras que governam o processo de negcio Lgica de Acesso a Dados Funcionalidades de acesso a dados e persistncia

Arquitetura em Camadas
A arquitetura em camadas lgica e no fsica. Se preocupa com as funes do aplicativo e no com sua implementao. Essa mesma arquitetura pode ser usada para elaborar sistemas distribudos ou centralizados, tradicionais, Cliente/Servidor ou para a Web. Entretanto, a utilizao dessa arquitetura facilita a distribuio dos componentes do aplicativo, quando for preciso por razes de negcios, tecnolgicas ou ambas.

Modelo em camadas
Esse modelo organiza um sistema em camadas, cada uma fornecendo um conjunto de servios. Cada camada pode ser imaginada como uma mquina abstrata cuja linguagem de mquina definida pelos servios oferecidos pela camada. Apoia o desenvolvimento incremental de sistemas. medida que uma camada desenvolvida, alguns servios fornecidos por essa camada pode ser disponibilizados para os usurios.

Benefcios da Arquitetura em Camadas

Estrutura para elaborao de aplicativos flexveis que possam ser alterados com facilidade para atender s necessidades de negcios em constante mudana. Alto nvel de reutilizao de software. Desenvolvimento mais fcil de aplicativos grandes e complexos em ambientes transacionais, Web e de suporte deciso. Desenvolvimento mais fcil de aplicativos distribudos que do suporte ao gerenciamento central, a equipes auto gerenciadas e ao atendimento externo.

Como Desenvolver Sistemas Aplicativos Complexos?

Abstrao: uma tcnica analtica para dividir um sistema em vrios nveis de detalhes (nveis de abstrao) ou camadas. Encapsulamento: um processo de combinar informaes (conjuntos de dados) e comportamentos (funes ou mtodos) em uma nova entidade, chamada componente (ou objeto).

Abstrao

Usando a abstrao, pode-se ocultar uma srie de detalhes dos quais no se necessita num determinado nvel do sistema aplicativo. A reduo da quantidade de detalhes visveis uma parte fundamental da descrio e do projeto de sistemas aplicativos complexos. A principal tcnica para ocultar detalhes definir os nveis de abstrao a serem utilizados.

Arquitetura Baseada em Nveis de Abstrao

Uma arquitetura em camadas, baseadas em nveis abstrao, possui trs caractersticas principais: 1. Camadas claramente definidas; 2. Interfaces formais e explcitas entre as camadas; 3. Detalhes ocultos e protegidos dentro de cada camada.

Benefcios da Abstrao 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 no precisa se preocupar com as outras. Maior segurana e proteo: o desenvolvedor de uma camada no pode controlar fisicamente outra camada em qualquer nvel de detalhe.

Interface entre as Camadas

a superfcie entre os componentes adjacentes de um aplicativo e o dispositivo por meio do qual eles interagem atravs das seguintes funes: 1. Informa o que o outro componente deve fazer; 2. Pergunta o estado atual de outro componente; 3. Recebe os resultados das operaes 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 Aplicativo de usurio (desktop ou browser) Interface GUI ou WEB Foco do Projeto Objetos do aplicativo, independentes de regras. Solicitao de decises independentes da interface de usurio e dos dados. Dados independentes das decises.

Processos de regras Fluxo dos processos de negcios

Gerenciamento de banco de dados

Transaes e consultas

Nenhuma camada deve realizar funes que sejam de responsabilidade de outra.

Camada de Interface

Apresentao: Apresentao de informaes Metforas visuais Navegao e transio consistente entre formulrios/pginas Entrada: Coleta de informaes (conjuntos de dados) Coleta de decises (execuo de aes) Interao (dilogo) com os usurios

Camada de Interface

Liberdade para os usurios:

Moldam a interface do sistema aplicativo de acordo com suas necessidades especficas, sem afetar as regras de negcios e o banco de dados.

Liberdade para a organizao:

O aplicativo de usurio envia solicitaes de processo formais para executar as regras de negcios e transaes e consultas no banco de dados. As regras de negcio e o banco de dados ficam mais isolados das mudanas na interface do usurio. Podem ser facilmente implementadas vrias vises para usurios diferentes, sem afetar as regras e os dados.

Camada de Regras de Negcios e Lgica do Aplicativo

Interoperabilidade: Capacidade de compartilhar trabalho (regras), compartilhar software (lgica) e fazer coisas de forma consistente por toda a organizao. Reutilizao: Um dos principais motivos para a impossibilidade de alta reutilizao de cdigo a falta da separao, num mesmo sistema aplicativo, entre a interface de usurio, as regras/lgica do negcio e o gerenciamento do banco de dados.

Camada de Regras de Negcios e Lgica do Aplicativo

Um nico componente de software trata de uma tarefa especfica. Este componente deve ser independente do banco de dados e da interface do usurio. Todos os aplicativos da organizao sempre utilizam este mesmo componente de software (classe de objeto) para realizar esta mesma tarefa.

Camada de Dados

Transaes: Atualizaes de dados consistentes; Imposio de regras de negcios bsicas; Evitar mudanas no-autorizadas ou invlidas. Consultas: Simplificar unies complexas de tabelas; Assegurar consistncia de resultados; Assegurar direitos de acesso. Dados proveniente de vrias fontes.

1, 2, 3, N Camadas

23/02/2013

22

Desenvolvimento em Camadas 1 Camada

Cdigo Monoltico

Lgica de Lgica de Apresenta Negcios o Lgica de

Acesso a Dados

Banco de dados

Desenvolvimento em Camadas 1 Camada

Desenvolvimento em Camadas 2 Camadas

Cenrio de 2 camadas fsicas Lgica de Apresenta o Lgica de Negcios

Lgica de Acesso a Dados

Banco de dados

Desenvolvimento em Camadas 2 Camadas

Problemas do modelo Cliente com lgica de negcio

Necessidade do cliente saber detalhes da localizao das fontes de dados Clientes gordos Atualizaes individuais Suporte ao desenvolvimento WEB

Desenvolvimento em Camadas 2 Camadas

Desenvolvimento em Camadas 2 Camadas

Desenvolvimento em Camadas 2 Camadas

Camada de Apresentao com Regras de Negcio Juntas.

Camada de Persistncia.
Problemas para o usurio, que no tem os programas funcionando como deveriam; Problemas para a equipe de desenvolvimento que no tem o seu trabalho reconhecido e, normalmente, tem que trabalhar apenas "apagando incndios"; e Problemas para a Administrao/Gerncia da rede que no consegue gerar os resultados esperados pela Administrao da empresa, apesar dos elevados valores j investidos.

Arquitetura em duas camadas

30

Desenvolvimento em Camadas 3 Camadas

Cenrio de 3 camadas fsicas

Lgica de Apresent ao

Lgica de Negcio

Lgica de Acesso a Dados

Banco de dados

Desenvolvimento em Camadas 3 Camadas

Vantagens Independncia entre camadas

Diviso de trabalho Facilidade na atualizao Proteo do cdigo Transparncia no acesso a dados Maior portabilidade

Desenvolvimento em Camadas 3 Camadas

Desenvolvimento em Camadas 3 Camadas

Desenvolvimento em Camadas 3 Camadas

Modelo e cdigos construdos para representar as camadas.

Os servidores no precisam estar necessariamente em mquinas diferentes, podem estar na mesma mquina. Porem questes de performance so relevantes.
Camada de Apresentao Camada de Negcios Camada de Persistncia

Arquitetura em trs camadas

36

Arquitetura em trs camadas Web

37

Desenvolvimento em Camadas 3 Camadas

Desenvolvimento em Camadas 3 Camadas

APRESENTAO NEGCIO OU LGICA PERSISTNCIA (INTEGRAO)

Helper classes

C
M
SGDB

NAVEGADOR WEB

V
CLIENTE - SERVIDOR

CLIENTE

SERVIDOR

SERVIDOR WEB

Desenvolvimento em Camadas Multiplas Camadas

Desenvolvimento em Camadas Multiplas Camadas

Arquitetura em camadas

42

Desenvolvimento em Camadas Multiplas Camadas

CLIENTE (APRESENTAO) GERENCIA DE APRESENTAO NEGCIO PERSISTNCIA

SERVIDOR APLICAO NAVEGADOR WEB SERVIDOR WEB EJB in MVC C V

CLIENTE CLIENTE - SERVIDOR

SGDB

M
SERVIDOR

CLIENTE - SERVIDOR

Desenvolvimento em Camadas Multiplas Camadas - JEE

Desenvolvimento em Camadas MVC Multiplas Camadas - JEE

Arquitetura de Software Estilos arquitetnicos - Arquitetura baseada em dados

Prof. Rodrigo Fetter Marques

23/02/2013

47

Modelo baseado em dados

Os subsistemas que constituem um sistema devem trocar informaes de modo que possam trabalhar juntos eficientemente. Existem duas maneiras: 1. Todos os dados compartilhados so mantidos em um banco de dados. 2. Cada subsistema mantm seu prprio 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 repositrio compartilhado.

Modelo baseado em dados

1 - Dados compartilhados 2 - Subsistemas controladores

Diagrama de Fluxo de Dados

Modelo baseado em dados

O foco da arquitetura nos dados. Algumas organizaes mantm o controle e a gesto da arquitetura de dados centralizada (estratgica). 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 no precisam saber como esses dados sero usados por outros subsistemas. Os subsistemas foca na integridade de domnio e integridade referencial dos dados. Os subsistemas mantm as regras de persistncias dos dados. Alguns subsistemas mantm e controlam as regras de negcio aplicveis aos dados.

Arquitetura de Software Estilos arquitetnicos - Arquitetura baseada em componentes

Prof. Rodrigo Fetter Marques

23/02/2013

52

Estilos arquitetnicos
formulado em termos de componentes: Como esto conectados; Como os dados so trocados; Maneira como os componentes so configurados.
Um componente uma unidade modular com interfaces requeridas e bem definidas, que substituvel dentro de seu ambiente. Um conector descrito como um mecanismo que serve de mediador da comunicao ou da cooperao entre componentes.

23/02/2013

53

Modelos Orientados a Objetos

Correspondncia clara entre os modelos dos domnios do problema, do projeto e da implementao

Class Name
attribute:Type = initialValue attribute:Type = initialValue attribute:Type = initialValue operation(arg list):return type

Class Name 0..1 1...* attribute:Type = initialValue

attribute:Type = initialValue attribute:Type = initialValue operation(arg list):return type

Class Name

Diagramas da UML

attribute:Type = initialValue attribute:Type = initialValue attribute:Type = initialValue operation(arg list):return type

Class Name
attribute:Type = initialValue operation(arg list):return type

Desenvolvimento de Sistemas Orientados a Objetos

Necessita ambientes de desenvolvimento extremamente rigorosos e formais, com pessoal altamente treinados
Nos grandes projetos abstraes corretas so difceis de realizar Modelos de objeto mal realizados criam mais problemas do que solues O nvel de granularidade dos objetos muito baixo, o que torna complexo o controle da dependncia entre eles

Componentes

Definio: Um pequeno grupo de objetos trabalhando agrupados a fim de prover uma funo do sistema Os objetos dentro do componente no so conhecidos por outra parte do sistema, exceto pelo prprio componente

Caractersticas dos Componentes

Tem todas as caractersticas 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 So auto descritos ( os seus clientes sabem como us-los )

Componentes de Software

Conjunto discreto, administrvel de lgica

Cdigo que implementa um conjunto pr-definido de interfaces No so aplicaes inteiras No rodam sozinhos

So usados como peas de quebra-cabea 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 Clculo de Preo Final

Manuseia informaes sobre o preo de um conjunto de produtos, fornecendo o preo total da compra Baseado num conjunto de Regras de Definio de Preos Preos unitrios dos produtos Quantidade de itens de produto comprados Desconto de quantidade/ cliente / regio Sobretaxas ( impostos, transporte ) Pode ser Usado:
Servio de Correio para definir o preo de remessa de pacotes Fabricante de automveis para descriminar o preo do automvel vendido

Separao da Interface e da sua Implementao

Interface do Componente
Define o contrato do componente com o cdigo do outro componente que o chama

Esconde de seus clientes os detalhes de sua construo

Permite que seus clientes somente tratem com os resultados finais de suas prprias operaes Implementao do Componente

Lgica da programao interna, escondida de seus clientes

Pode ser mudada sem alterar do cdigo de seus clientes

Desenvolvimento Baseado em Componentes

Compone nt Compone nt

Compone nt

Um sistema complexo pode ser considerado como um conjunto composto de um nmero arbitrrio de pequenos sistemas coesivos ( componentes ) Cada componente construdo para implementar um conjunto definido de responsabilidades

Cada componente auto contido e acoplado a outros componentes

Componentes so projetados para serem utilizados dentro de uma plataforma que integra todos os componentes numa aplicao

Plataforma baseada em Componentes

Facilita a construo, administrao e manuteno 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 servios que os componentes necessitam

Ferramentas para implementao e manuteno

Customizao de componentes para ambientes especficos

Plataforma baseada em Componentes

Permite o desenvolvimento e a utilizao de sistemas baseado em componentes Cria instncias runtime de componentes Permite a componentes descobrir e se comunicar com outros componentes Prov servios comuns adicionais, como: Persistncia

Transaes
Independncia de localizao Segurana

Monitoramento

Uso de Componentes: Vantagens

Tcnicas A complexidade melhor administrada, permitindo melhor qualidade nas solues Funcionalidade tcnicas ( no de negcios ) concentrada na plataforma Negcios Produtos de melhor qualidade

Tempo menor para desenvolvimento de sistemas

Melhor utilizao de recursos humanos Habilidade de resposta a mudanas

Custo reduzido
Alto reuso para projetos futuros

Uso de Componentes: Desvantagens

Os componentes so fortemente acoplados uns aos outros: uma mudana no cdigo de um deles pode levar a mudanas nos demais A administrao da complexidade da dependncia entre os componentes em grandes sistemas difcil: um componente ainda tem que saber muito sobre os demais ( aos quais se acopla ) As solues proprietrias: ( DCOM MS, CORBA )

Arquitetura de Software Estilos arquitetnicos - Arquitetura baseada em servio

Prof. Rodrigo Fetter Marques

23/02/2013

66

SOA
Arquitetura que tem tido destaque na integra-o de negcios atualmente.
SOA segundo a Accenture: Uma arquitetura que define como funes de negcios dinstintas, implementadas por siste-mas autnomos, devem operar conjuntamen-te para executar um processo de negcio.

SOA
Cada funo de negcio (componente) im-plementada como um servio.
Esses servios ficam disponveis em uma re-de para que as aplicaes possam utiliz-los. Em geral, esta rede a internet e os servios so chamados de web services.

Caractersticas da arquitetura
As partes (servios) so bastante indepen-dentes entre si. No h limitaes em relao plataforma ou linguagem utilizada para implementar um servio, apenas em relao a como eles comunicam-se. Um servio encapsula uma lgica de neg-cio. Assim, temos um alto ndice de reapro-veitamento.

Um exemplo

Benefcios
Tempo e custo de desenvolvimento sero re-duzidos ao reutilizarmos um servio em uma parte diferente do sistema. A aplicao final mais facilmente extens-vel. Uma aplicao diferente poder se beneficiar dos servios implementados anteriormente.

Padres utilizados
XML (Linguagem de Marcao Extensvel) SOAP (Protocolo de Acesso a Objetos Simples) WSDL (Linguagem de Descrio de Servios Web) UDDI (Descrio, Descoberta e Integrao Universais)

Arquitetura
Orientada a Servios

Publicao

- SOA -

Apresentao

Lgica de Negcios Dados

SOA - Caractersticas Arquiteturais

Distribuda: os elementos funcionais da aplicao so utilizados em mltiplos sistemas ( provedor, consumidor, publicador ), localizados em pontos diferentes
Acoplamento Fraco: as ligaes entre os elementos funcionais no so fixas ou rgidas, podendo ser assncronas Escalvel: novos elementos podem ser agregados, um servio pode ser composto de outros servios, sistemas legados, sistemas de pacotes Baseada em Padres: independente de vendedores especficos