padrões arquiteturais de sistemas

1

Padrões Arquiteturaisde Sistemas (2011)

Especialização em Projeto e Desenvolvimento de Sistemas

Vagner Figuerêdo de Santana

2

Objetivo da disciplina

Aplicação de padrões no desenvolvimento de software orientado a objetos

Desenvolvimento multicamadas com integração em diferentes processos de software

3

Conteúdo programático

Introdução Padrões Arquiteturais de Sistemas Padrões enterprise multicamadas Oficina de padrões

4

Introdução

Christopher Alexander A Pattern Language: Towns, Buildings, Constrution

(1977) Gamma et al.

Design Patterns: Elements of Reusable Object-Oriented Software (1994)

Buschamann et al. Pattern-Oriented Software Architecture: A System of

Patterns (1996)

5

Introdução

A qualidade dos projetos arquitetônicos é objetiva?

6

Introdução

Um padrão descreve problema que ocorre

repetidamente solução para esse

problema de forma que se possa reutilizar a solução

7

Introdução

Estrutura básica de um padrão Contexto

Situação em que o problema surge Problema

Conjunto de forças que surge no contexto Solução

Configuração que equilibra as forças Estrutura com componentes e relacionamentos Comportamento

8

Introdução

Exemplo na arquitetura: MASP Problema: O terreno para o museu havia

sido doado com a condição de que a vista para o centro da cidade fosse preservada

9

Introdução

Solução: Edifício sustentado por pilares

Inaugurado em 68, o edifício é sustentado

por quatro pilares laterais e conta com

um vão livre de 74m. Foto: Kuca (http://www.flickr.com/photos/kuca/279529473/)

10

Introdução

Por quê usar padrões? Aprender com a experiência dos outros O jargão facilita a comunicação de princípios

complexos Melhora a qualidade do software Descreve abstrações de software Ajuda a documentar a arquitetura Captura as partes essenciais de forma compacta

11

Introdução

No entanto… Não apresentam uma solução exata Não resolvem todos os problemas de design Não é exclusivo de orientação a objetos

12

Introdução

Como selecionar um padrão? Entenda como os padrões ajudam a resolver

problemas Revise as intenções de cada padrão Estude como os padrões se relacionam Estude as similaridades entre os padrões de mesmo

propósito Conheça as principais causas de retrabalho Considere o que você pode querer mudar em seu

projeto no futuro

13

Introdução

Arquitetura de software Resultado do projeto de software Descrição dos subsistemas/componentes e

seus relacionamentos

14

Introdução

Subsistema/componente Bloco básico de construção de sistemas Parte encapsulada de um sistema Possui uma interface Pode ser módulo, classe, objeto ou conjunto

de funções relacionadas

15

Introdução

Padrão Arquitetural Expressa uma estrutura fundamental para

sistemas computacionais Fornece um conjunto de subsistemas

predefinidos Especifica responsabilidades Conta com diretrizes para organizar o

relacionamento entre os subsistemas

16

Padrões Arquiteturaisde Sistemas MVC (Model View Controller)

MVP (Model View Presenter) Pipeline N-tier Arquitetura em camadas

17

MVC (Model View Controller)

Divide aplicação interativa em 3 partes Model: regras de negócio e dados (core) View: apresenta informações ao usuário Controller: trata entrada de usuário e

manipula o modelo A propagação de mudanças é o link entre

model e view e controllers

18


Quando usá-lo? Contexto: Aplicações interativas Problema:

Interfaces de usuário são propícias a mudanças Diferentes visualizações para mesmos dados

Solução: Dividir processamento, entrada e saída

19


View Controller

Model

20


Classe

Model

Colaboradores View ControllerResponsabilidade

Fornecer funcionalidade central da aplicação Registrar views e controllers dependentes Notifica alterações aos dependentes

21


Classe

View

Colaboradores Controller ModelResponsabilidade

Cria e inicializa seu controller Apresenta informações Implementa procedimento de atualização Recupera dados do modelo

22


Classe

Controller

Colaboradores View ModelResponsabilidade

Manipula entrada de usuário Traduz entradas dos usuários ou requisições do view em requisições ao model Implementa o procedimento de atualização

23


View Controller

Model

24


Este é o MVC clássico, mas... É adequado para os sistemas de hoje? Quais são as limitações na Web? Como model pode notificar a view? Quando podemos enfrentar problemas? Como poderíamos melhorá-lo?

25


Separar apresentação (View)dos dados (Model)

View Controller

Model

26



View Controller

Model

27



View

Controller

Model

28


Exemplo: Jogos (Bomberman)

29


30


Como adicionar mais views?

31


View

Controller

Model

View

Controller

View

Controller

Model

View

32

MVP (Model View Presenter)*

Variação do MVC Surgiu em na IBM Ganhou visibilidade nos anos 90** Separa widgets reutilizáveis do código

específico da aplicação

* http://martinfowler.com/eaaDev/uiArchs.html** http://www.wildcrest.com/Potel/Portfolio/mvp.pdf

33

MVP (Model View Presenter)

Divide aplicação interativa em 3 partes Model: regras de negócio e dados (core) View: estrutura de widgets que gerencia

controles e formulários e encaminha eventos ao presenter

Presenter: decide como reagir aos eventos e atualiza model e view

Atualização da view é semelhante ao MVC

34

MVP (Model View Presenter)

Fonte: http://msdn.microsoft.com/en-us/library/ff647543.aspx

35

Especificidades do MVP

Presenter manipula o model e depois atualiza o view

Presenter é como controller mas sem a manipulação de eventos

View despacha eventos para presenter

Fonte: http://martinfowler.com/eaaDev/uiArchs.html

36

Pipeline (Pipes and Filters)

Estrutura para sistemasque processam cadeiasde dados

Processos sãoencapsulados emfiltros

Dados são passadospelos pipes localizadosentre os filtros

Source

Filter 1

Sink

Filter 2

Pipe

Pipe

Pipe

37


Quando usá-lo? Contexto: Sistemas que processam cadeias

de dados Problema: Processa/transforma cadeia de

dados, mas implementá-la de uma só vez é inviável

Solução: Dividir a tarefa em uma sequência de etapas

38


Classe

Filter

Colaboradores Pipe

Responsabilidade Obtém dados de entrada Manipula dados de entrada Fornece dados de saída

39


Classe

Pipe

Colaboradores Data source Data sink Filter

Responsabilidade Transfere os dados Sincroniza vizinhos

40


Classe

Data Source

Colaboradores Pipe

Responsabilidade Entrega dados de entrada para pipeline

41


Classe

Data Sink

Colaboradores Pipe

Responsabilidade Consume os dados de saída

42


Exemplo: Linha de comando

43

N-tier

Padrão geral de distribuição Componentes são separados em

servidores diferentes Comumente, escolhemos um entre os

padrões 2-tier, 3-tier ou 4-tier

44

Tier vs Layer

Layer descreve agrupamento lógico Tiers descreve a distribuição física em diferentes

servidores, computadores, redes, etc. Layers e tiers usam o mesmo conjunto de nomes

(apresentação, negócio, serviços e dados), mas somente tiers implicam separação física

É comum ter mais de um layer no mesmo tier Podemos pensar no termo tier como sendo uma

referência a padrões de distribuição de sistemas computacionais

45

2-tier

Mesmo layout físico que o padrão cliente/servidor

Em alguns casos, todo o código da aplicação é localizado no cliente e o banco de dados é localizado em um servidor separado

Considere este padrão se você está desenvolvendo um cliente que vai acessar um servidor de aplicação um cliente stand-alone que acessa um servidor de

dados separado

46

2-tier

Fonte: http://msdn.microsoft.com/en-us/library/ee658120.aspx

47

3-tier

O cliente acessa o servidor de aplicação, que acessa o servidor de banco de dados; todos em diferentes máquinas

Padrão comum para aplicações Web e Web Services

Pode ser necessário incluir um firewall entre o cliente e o servidor de aplicação e entre o servidor de aplicação e o banco de dados

48

3-tier


49

4-tier

Servidor Web é separado fisicamente do servidor de aplicação

O servidor Web está em uma rede e acessa a aplicação em outra sub-rede

Neste cenário cliente e servidores de aplicação/Web podem ter que ser combinados com um firewall

Considere este padrão se Requisitos de segurança ditam que as regras de negócio sejam

separadas Você deseja dividir/controlar carga nos servidores

50

4-tier


51

Arquitetura em Camadas

Estrutura aplicações decompostas grupos de tarefas em diferentes níveis de abstração

Cliente Camada N

Camada N-1

Camada 1

52


Quando usá-lo? Contexto: Sistema complexo que exige

decomposição Problema:

Sistema manipula questões de baixo nível e deve disponibilizar funcionalidades a usuários

Estrutura horizontal com vertical subdivisão Portabilidade

Solução: Estruturar o sistema em número apropriado de camadas

53


Classe

Camada N

Colaboradores Camada N-1

Responsabilidade Fornecer funcionalidades usadas pela camada N+1 Delega subtarefas à camada N-1

54



Exemplo

55


Exercício: Como definir o número de camadas?

56


Definindo o número de camadas Agrupar componentes que representam

papeis e funcionalidades diferentes Ex.: Apresentação, Negócio e Dados

Delimitar locais onde decisões envolvendo tecnologias ou projeto precisam ser tomadas Ex.: Linguagens, Dispositivos, Banco de dados.

57


Pontos críticos Separar aplicação em muitas camadas pode

Prejudicar o desempenho Complexidade desnecessária

Prezando pela manutenção deve-se Manter encapsulamento nas camadas Baixo acoplamento entre camadas Como verificar?

58


Arquitetura em 3 camadas (Fowler) Apresentação (fornece serviço)

Exibir informações Traduzir comandos do usuário em ações na camada

de domínio Domínio

Regras de negócio Dados (usa serviço)

Apresentação e recuperação de dados

59


Fowler Microsoft J2EE

Apresentação Apresentação Cliente

Apresentação (servidor)

Domínio Negócio Negócio

Fonte de dados Acesso a dados Integração

Recursos

60

Exercício

Em duplas ou trios Projetar o sistema do bilhete único de SP

Definir arquitetura(s) Esboço do projeto (diagrama de classes)

Considerar Sistema central Quiosques de recarga Catracas

61

Arquitetura baseada em serviços

Composto por múltiplos serviços Comunicação via mensagens/protocolos Componentes da solução total Outras aplicações podem usar serviços

sem se precisar se preocupar como eles estão implementados

62


Exemplo


63


Exemplo: Reuso de CMS

64

Padrões enterprise multicamadas*

Padrões de base Padrões de fontes de dados Padrões de lógica de domínio (negócio) Padrões de apresentação Padrões de distribuição

(*) www.martinfowler.com/eaaCatalog

65

Padrões de base Gateway Objeto que encapsula o acesso a um

sistema ou recurso externo

66

Padrões de base Mapper Objeto que inicializa comunicação entre

objetos independentes que não possuem conhecimento um do outro

67

Padrões de base Layer Supertype Atua como supertipo de todos os tipos na

sua camada Pode ser comum ter objetos que

compartilham métodos em uma camada Você pode mover comportamento para

um Layer Supertype

68

Padrões de base Separated Interface Interface em um

pacote diferentedo local de suaimplementação

69

Padrões de base Registry Objeto bem conhecido que outros objetos

pode usar para encontrar objetos ou serviços comuns (ou globais)

70

Padrões de base Value Object Objeto simples que baseia sua igualdade

no valor e não na identidade (e.g., Money, Date, Temperature)

Normalmente são passados por valor Comparações consideram valor em vez

de instância Nota: Remete ao método equals()

71

Padrões de base Money Representa valor monetário

72

Padrões de base Special Case Subclasse com

comportamento especialpara casos particulares

Em vez de retornarnulo ou outra coisaestranha, retorneum Special Case

73

Padrões de base Plugin Conecta classes durante configuração em

vez de tempo de compilação

74

Padrões de base Service Stub Remove dependência de serviços

problemáticos durante testes

75

Padrões de base Record Set Representação em memória de dados

tabulares

76

Padrões de fontes de dadosTable Data Gateway Objetos que atuam como Gateway para

uma tabela de dados Uma instância manipula todas linhas da

tabela

77

Padrões de fontes de dadosRow Data Gateway Objeto que atua como Gateway para um

registro em uma fonte de dados Uma instância por linha

78

Padrões de fontes de dadosActive Record Objeto que envolve uma linha de tabela,

encapsula acesso ao banco de dados e adiciona lógica de domínio nos dados

79

Padrões de fontes de dadosData Mapper Camada de Mappers que move dados

entre objetos e banco de dados mantendo independência

80

Padrões de lógica de domínioTransaction Script Organiza lógica de negócio via

procedimentos em que cada um manipula requisitos vindos da apresentação

81

Padrões de lógica de domínioDomain Model Modelo de objeto do domínio que

incorpora comportamento e dados

82

Padrões de lógica de domínioTable Module Instância única que manipula a lógica de

negócio para todas linhas em uma tabela

83

Padrões de lógica de domínioService Layer Define limites da

aplicação com umacamada de serviçosque estabelecemum conjunto deoperações

84

Padrões de apresentaçãoModel View Controller Divide a interface de usuário em três

papéis distintos

85

Padrões de apresentaçãoPage Controller Objeto que manipula uma requisição por

uma página específica ou ação

86

Padrões de apresentaçãoFront Controller Controller que manipula todas requisições

87

Padrões de apresentaçãoTemplate View Insere informações em HTML colocando

marcadores em uma interface de usuário

88

Padrões de apresentaçãoTransform View View que processa dados de domínio

(elemento a elemento) e transforma em HTML

89

Padrões de apresentaçãoTwo Step View Transforma dados

de domínio emHTML Monta a estrutura

lógica Renderiza a

estruturalógica em HTML.

90

Padrões de apresentaçãoApplication Controller Ponto central para manipular navegação

na tela e o fluxo de uma aplicação

91

Padrões de distribuiçãoRemote Facade Converter objetos de granularidade fina

(ou alta) em objetos compactos tendo como foco eficiência de rede

92

Padrões de distribuiçãoData Transfer Object Objeto que carrega dados entre

processos para reduzir o número de chamadas de métodos

93

Exercício

Continuar o projeto do sistema do bilhete único de SP aplicando, quando aplicável, o máximo de padrões vistos até o momento

94

Formatos de padrões

POSA - Pattern-Oriented Software Architecture

PoEAA - Patterns of Enterprise Application Architecture

GoF - Gang of Four

95

POSA

Nome Contexto Problema Solução

96

GoF

Nome Problema Solução Consequências

Intenção Outros nomes Motivação Aplicação Estrutura Participantes Colaborações Implementação Código de exemplo Usos conhecidos Padrões relacionados

97

PoEAA

Nome Intenção e esboço Problema Como funciona Quando usá-lo Leitura adicional Exemplos

98

POSA PoEAA GoF

Nome Nome Nome e outros nomes

Contexto Intenção Intenção

Esboço Estrutura

Problema Problema Problema e Motivação

Solução Como funciona Solução

Consequências

Quando usá-lo Usos conhecidos eAplicação

Leitura adicional

Exemplos Código de exemplo e Implementação

Participantes

Colaborações

Padrões relacionados

99

Notas finais

Funcionalidades principais de um sistema são significativos para a arquitetura

O que é feito durante a arquitetura visa evitar o risco de um projeto falhar

100

Referências

Buschamann et al.Pattern-Oriented Software Architecture: A System of Patterns (1996)

Gamma et al.Design Patterns: Elements of Reusable Object-Oriented Software (1994)

FowlerPatterns of Enterprise Application Architecture (2007)

101

Referências

http://martinfowler.com/eaaDev/uiArchs.html http://www.martinfowler.com/eaaCatalog http://www.wildcrest.com/Potel/Portfolio/mvp.pdf http://msdn.microsoft.com/en-us/library/ff647543.aspx http://msdn.microsoft.com/en-us/library/ee658120.aspx http://msdn.microsoft.com/en-us/library/ee658109.aspx

padrões arquiteturais de sistemas

Education