Padrões Arquiteturais de Sistemas

  • 5,228 views
Uploaded on

Slides usados na disciplina do curso de Especialização em Projeto e Desenvolvimento de Sistemas, da Universidade Presbiteriana Mackenzie.

Slides usados na disciplina do curso de Especialização em Projeto e Desenvolvimento de Sistemas, da Universidade Presbiteriana Mackenzie.

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,228
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
159
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 comum 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 Arquiteturaisde 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 ColaboradoresModel  ViewResponsabilidade  Controller Fornecer funcionalidadecentral da aplicação Registrar views e controllersdependentes Notifica alterações aosdependentes 20
  • 21. MVC (Model View Controller)Classe ColaboradoresView  ControllerResponsabilidade  Model Cria e inicializa seu controller Apresenta informações Implementa procedimento deatualização Recupera dados do modelo 21
  • 22. MVC (Model View Controller)Classe ColaboradoresController  ViewResponsabilidade  Model Manipula entrada de usuário Traduz entradas dos usuáriosou requisições do view emrequisições ao model Implementa o procedimentode 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 ColaboradoresFilter  PipeResponsabilidade Obtém dados de entrada Manipula dados de entrada Fornece dados de saída 38
  • 39. Pipeline (Pipes and Filters)Classe ColaboradoresPipe  Data sourceResponsabilidade  Data sink Transfere os dados  Filter Sincroniza vizinhos 39
  • 40. Pipeline (Pipes and Filters)Classe ColaboradoresData Source  PipeResponsabilidade Entrega dados de entradapara pipeline 40
  • 41. Pipeline (Pipes and Filters)Classe ColaboradoresData Sink  PipeResponsabilidade 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 CamadasClasse ColaboradoresCamada N  Camada N-1Responsabilidade Fornecer funcionalidadesusadas pela camada N+1 Delega subtarefas à camadaN-1 53
  • 54. Arquitetura em Camadas  ExemploFonte: 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 CamadasFowler Microsoft J2EEApresentação Apresentação Cliente Apresentação (servidor)Domínio Negócio NegócioFonte 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  ExemploFonte: 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 baseGateway Objeto que encapsula o acesso a um sistema ou recurso externo 65
  • 66. Padrões de baseMapper Objeto que inicializa comunicação entre objetos independentes que não possuem conhecimento um do outro 66
  • 67. Padrões de baseLayer 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 baseSeparated Interface Interface em um pacote diferente do local de sua implementação 68
  • 69. Padrões de baseRegistry Objeto bem conhecido que outros objetos pode usar para encontrar objetos ou serviços comuns (ou globais) 69
  • 70. Padrões de baseValue 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 baseMoney Representa valor monetário 71
  • 72. Padrões de baseSpecial 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 basePlugin Conecta classes durante configuração em vez de tempo de compilação 73
  • 74. Padrões de baseService Stub Remove dependência de serviços problemáticos durante testes 74
  • 75. Padrões de baseRecord Set Representação em memória de dados tabulares 75
  • 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 76
  • 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 77
  • 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 78
  • 79. Padrões de fontes de dadosData 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ínioTransaction 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ínioDomain Model Modelo de objeto do domínio que incorpora comportamento e dados 81
  • 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 82
  • 83. Padrões de lógica de domínioService 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çãoModel View Controller Divide a interface de usuário em três papéis distintos 84
  • 85. Padrões de apresentaçãoPage Controller Objeto que manipula uma requisição por uma página específica ou ação 85
  • 86. Padrões de apresentaçãoFront Controller Controller que manipula todas requisições 86
  • 87. Padrões de apresentaçãoTemplate View Insere informações em HTML colocando marcadores em uma interface de usuário 87
  • 88. Padrões de apresentaçãoTransform View View que processa dados de domínio (elemento a elemento) e transforma em HTML 88
  • 89. Padrões de apresentaçãoTwo 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çãoApplication Controller Ponto central para manipular navegação na tela e o fluxo de uma aplicação 90
  • 91. Padrões de distribuiçãoRemote Facade Converter objetos de granularidade fina (ou alta) em objetos compactos tendo como foco eficiência de rede 91
  • 92. Padrões de distribuiçãoData 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 GoFNome Nome Nome e outros nomesContexto Intenção Intenção Esboço EstruturaProblema Problema Problema e MotivaçãoSoluçã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