O documento descreve conceitos de padrões arquiteturais de sistemas, incluindo MVC, MVP, Pipeline, N-tier e arquitetura em camadas. O objetivo é aplicar esses padrões no desenvolvimento de software orientado a objetos e desenvolvimento multicamadas.

1. Especialização em Projeto e Desenvolvimento de Sistemas
Padrões Arquiteturais
de Sistemas (2011)
Vagner Figuerêdo de Santana
1

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
2

3. Conteúdo programático
 Introdução
 Padrões Arquiteturais de Sistemas
 Padrões enterprise multicamadas
 Oficina de padrões
3

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)
4

5. Introdução
 A qualidade dos projetos arquitetônicos é
objetiva?
5

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
6

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
7

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
8

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/) 9

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
10

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
11

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
12

13. Introdução
 Arquitetura de software
 Resultado do projeto de software
 Descrição dos subsistemas/componentes e
seus relacionamentos
13

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
14

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
15

16. Padrões Arquiteturais
de Sistemas
 MVC (Model View Controller)
 MVP (Model View Presenter)
 Pipeline
 N-tier
 Arquitetura em camadas
16

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
17

18. MVC (Model View Controller)
 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
18

19. MVC (Model View Controller)
View Controller
Model
19

20. MVC (Model View Controller)
Classe Colaboradores
Model  View
Responsabilidade  Controller
 Fornecer funcionalidade
central da aplicação
 Registrar views e controllers
dependentes
 Notifica alterações aos
dependentes
20

21. MVC (Model View Controller)
Classe Colaboradores
View  Controller
Responsabilidade  Model
 Cria e inicializa seu controller
 Apresenta informações
 Implementa procedimento de
atualização
 Recupera dados do modelo
21

22. MVC (Model View Controller)
Classe Colaboradores
Controller  View
Responsabilidade  Model
 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
22

23. MVC (Model View Controller)
View Controller
Model
23

24. MVC (Model View Controller)
 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?
24

25. MVC (Model View Controller)
 Separar apresentação (View)
dos dados (Model)
View Controller
Model
25

26. MVC (Model View Controller)
 Separar apresentação (View)
dos dados (Model)
View Controller
Model
26

27. MVC (Model View Controller)
 Separar apresentação (View)
dos dados (Model)
View
Controller
Model
27

28. MVC (Model View Controller)
 Exemplo: Jogos (Bomberman)
28

29. MVC (Model View Controller)
29

30. MVC (Model View Controller)
 Como adicionar mais views?
30

31. MVC (Model View Controller)
View View View View
Controller Controller Controller
Model Model
31

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
32

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
33

34. MVP (Model View Presenter)
Fonte: http://msdn.microsoft.com/en-us/library/ff647543.aspx
34

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
35

36. Pipeline (Pipes and Filters)
 Estrutura para sistemas Source
que processam cadeias
de dados Pipe
 Processos são Filter 1
encapsulados em Pipe
filtros
Filter 2
 Dados são passados
pelos pipes localizados Pipe
entre os filtros Sink
36

37. Pipeline (Pipes and Filters)
 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
37

38. Pipeline (Pipes and Filters)
Classe Colaboradores
Filter  Pipe
Responsabilidade
 Obtém dados de entrada
 Manipula dados de entrada
 Fornece dados de saída
38

39. Pipeline (Pipes and Filters)
Classe Colaboradores
Pipe  Data source
Responsabilidade  Data sink
 Transfere os dados  Filter
 Sincroniza vizinhos
39

40. Pipeline (Pipes and Filters)
Classe Colaboradores
Data Source  Pipe
Responsabilidade
 Entrega dados de entrada
para pipeline
40

41. Pipeline (Pipes and Filters)
Classe Colaboradores
Data Sink  Pipe
Responsabilidade
 Consume os dados de saída
41

42. Pipeline (Pipes and Filters)
 Exemplo: Linha de comando
42

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
43

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
44

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
45

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

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
47

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

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
49

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

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
51

52. Arquitetura em Camadas
 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 52

53. Arquitetura em Camadas
Classe Colaboradores
Camada N  Camada N-1
Responsabilidade
 Fornecer funcionalidades
usadas pela camada N+1
 Delega subtarefas à camada
N-1
53

54. Arquitetura em Camadas
 Exemplo
Fonte: http://msdn.microsoft.com/en-us/library/ee658109.aspx 54

55. Arquitetura em Camadas
 Exercício: Como definir o número de
camadas?
55

56. Arquitetura em Camadas
 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.
56

57. Arquitetura em Camadas
 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?
57

58. Arquitetura em Camadas
 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
58

59. Arquitetura em Camadas
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
59

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
60

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
61

62. Arquitetura baseada em serviços
 Exemplo
Fonte: http://msdn.microsoft.com/en-us/library/ee658109.aspx 62

63. Arquitetura baseada em serviços
 Exemplo: Reuso de CMS
63

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
64

65. Padrões de base
Gateway
 Objeto que encapsula o acesso a um
sistema ou recurso externo
65

66. Padrões de base
Mapper
 Objeto que inicializa comunicação entre
objetos independentes que não possuem
conhecimento um do outro
66

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
67

68. Padrões de base
Separated Interface
 Interface em um
pacote diferente
do local de sua
implementação
68

69. Padrões de base
Registry
 Objeto bem conhecido que outros objetos
pode usar para encontrar objetos ou
serviços comuns (ou globais)
69

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()
70

71. Padrões de base
Money
 Representa valor monetário
71

72. Padrões de base
Special Case
 Subclasse com
comportamento especial
para casos particulares
 Em vez de retornar
nulo ou outra coisa
estranha, retorne
um Special Case
72

73. Padrões de base
Plugin
 Conecta classes durante configuração em
vez de tempo de compilação
73

74. Padrões de base
Service Stub
 Remove dependência de serviços
problemáticos durante testes
74

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

76. Padrões de fontes de dados
Table Data Gateway
 Objetos que atuam como Gateway para
uma tabela de dados
 Uma instância manipula todas linhas da
tabela
76

77. Padrões de fontes de dados
Row Data Gateway
 Objeto que atua como Gateway para um
registro em uma fonte de dados
 Uma instância por linha
77

78. Padrões de fontes de dados
Active Record
 Objeto que envolve uma linha de tabela,
encapsula acesso ao banco de dados e
adiciona lógica de domínio nos dados
78

79. Padrões de fontes de dados
Data Mapper
 Camada de Mappers que move dados
entre objetos e banco de dados
mantendo independência
79

80. Padrões de lógica de domínio
Transaction Script
 Organiza lógica de negócio via
procedimentos em que cada um manipula
requisitos vindos da apresentação
80

81. Padrões de lógica de domínio
Domain Model
 Modelo de objeto do domínio que
incorpora comportamento e dados
81

82. Padrões de lógica de domínio
Table Module
 Instância única que manipula a lógica de
negócio para todas linhas em uma tabela
82

83. Padrões de lógica de domínio
Service Layer
 Define limites da
aplicação com uma
camada de serviços
que estabelecem
um conjunto de
operações
83

84. Padrões de apresentação
Model View Controller
 Divide a interface de usuário em três
papéis distintos
84

85. Padrões de apresentação
Page Controller
 Objeto que manipula uma requisição por
uma página específica ou ação
85

86. Padrões de apresentação
Front Controller
 Controller que manipula todas requisições
86

87. Padrões de apresentação
Template View
 Insere informações em HTML colocando
marcadores em uma interface de usuário
87

88. Padrões de apresentação
Transform View
 View que processa dados de domínio
(elemento a elemento) e transforma em
HTML
88

89. Padrões de apresentação
Two Step View
 Transforma dados
de domínio em
HTML
 Monta a estrutura
lógica
 Renderiza a
estrutura
lógica em HTML.
89

90. Padrões de apresentação
Application Controller
 Ponto central para manipular navegação
na tela e o fluxo de uma aplicação
90

91. Padrões de distribuição
Remote Facade
 Converter objetos de granularidade fina
(ou alta) em objetos compactos tendo
como foco eficiência de rede
91

92. Padrões de distribuição
Data Transfer Object
 Objeto que carrega dados entre
processos para reduzir o número de
chamadas de métodos
92

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
93

94. Formatos de padrões
 POSA - Pattern-Oriented Software
Architecture
 PoEAA - Patterns of Enterprise
Application Architecture
 GoF - Gang of Four
94

95. POSA
 Nome
 Contexto
 Problema
 Solução
95

96. GoF
 Intenção
 Nome  Outros nomes
 Problema  Motivação
 Aplicação
 Solução
 Estrutura
 Consequências  Participantes
 Colaborações
 Implementação
 Código de exemplo
 Usos conhecidos
 Padrões relacionados 96

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

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 e
Aplicação
Leitura adicional
Exemplos Código de exemplo e
Implementação
Participantes
Colaborações
Padrões relacionados
98

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
99

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)
 Fowler
Patterns of Enterprise Application Architecture (2007)
100

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
101