APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE

428 visualizações

Publicada em

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
428
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE

  1. 1. Profa. Tarciane Andrade
  2. 2. Agenda Quem é o arquiteto? Padrões Arquiteturais - Motivação Definição ClassificaçãoClassificação Descrevendo Padrões Padrão Camadas
  3. 3. Quem é o Arquiteto? 3 “O Arquiteto” - The Matrix
  4. 4. O Arquiteto... ... é um Líder Técnico! Possui conhecimento técnico e qualidades de um líder Tem autonomia para tomar decisões técnicas no projeto Diferente do Gerente de Projetos 4 Diferente do Gerente de Projetos Gerencia o projeto em termos de alocação de recursos, cronograma e custos GP = Produtor garantir que as coisas sejam feitas Arquiteto = Diretor garantir que as coisas sejam feitas da maneira correta
  5. 5. O Arquiteto... ... é um Líder Técnico! Contribui ativamente para o planejamento de atividades do projeto Interage bastante com os outros membros da equipe (Analistas, Desenvolvedores, etc.) 5 (Analistas, Desenvolvedores, etc.) É orientado a pessoas atua como mentor de outros membros da equipe É focado na entrega de resultados força motriz do lado técnico do projeto
  6. 6. O Arquiteto... ... conhece o Processo de Desenvolvimento! O processo assegura que os membros da equipe trabalhem de forma coordenada 6 O processo define os papéis envolvidos, as atividades a serem desempenhadas e os produtos de trabalho gerados Deve conhecer os demais papéis e suas responsabilidades
  7. 7. O Arquiteto... ... conhece o Domínio do Negócio! Ajuda a melhor entender e contribuir para que os requisitos sejam devidamente capturados Equilíbrio entre conhecimento Técnico e conhecimento do 7 Equilíbrio entre conhecimento Técnico e conhecimento do Negócio O domínio tem impacto na arquitetura Caso contrário, a solução pode não atender ao problema
  8. 8. O Arquiteto... ... tem conhecimento Técnico! Não é necessariamente um expert Tende a ser generalista, em vez de especialista 8 Tende a ser generalista, em vez de especialista Possui certo nível de conhecimento técnico Conhece muitas tecnologias em um nível superior, em vez de algumas tecnologias no nível de detalhe
  9. 9. O Arquiteto... ... tem conhecimento em Design de sistemas! Arquitetura envolve decisões importantes de design 9 Deve ditar os vários tipos de padrões, incluindo padrões de código, ferramentas e plataformas que serão utilizadas
  10. 10. O Arquiteto... ... tem conhecimento em Programação! Desenvolvedores é um dos grupos mais importantes com o qual o arquiteto interage 10 Favorece a comunicação efetiva Abstrair conceitos em linguagens e aprendê-las na profundidade necessária
  11. 11. O Arquiteto... ... é um Bom Comunicador! Falar bem e escrever bem Ser um bom observador e saber ouvir 11 Ser um bom observador e saber ouvir Comunicar de forma clara e garantir o entendimento Conquistar o respeito da equipe Motivar a equipe
  12. 12. O Arquiteto... ... toma Decisões! Toma decisões críticas sob pressão e deve fazer com que essas decisões sejam cumpridas à risca É importante ter experiência 12 É importante ter experiência A inabilidade de tomar decisões vai prejudicando o projeto O time perde confiança no arquiteto Decisões passam a ser tomadas por cada um
  13. 13. O Arquiteto... ... deve estar ciente da Política Organizacional! Não deve estar apenas preocupado com tecnologia 13 Sabe onde o poder reside e busca utilizá-lo em favor do projeto
  14. 14. O Arquiteto... ... é um Negociador! Interage com as diversas partes interessadas do projeto Requistos podem possuir riscos associados 14 Requistos podem possuir riscos associados Riscos devem ser tratados Requisitos podem ser diminuidos para eliminar riscos
  15. 15. O Arquiteto evita Problemas... “Uma equipe teve que refazer parte da implementação de JavaScripts da camada de apresentação de um sistema ao perceber, já em produção, que o sistema não atendia o navegador Firefox.”navegador Firefox.” “Em um outro projeto descobriu-se, já em produção, que o tempo médio dos casos de uso era de 40 segundos.”
  16. 16. Motivações para o estudo de Arquitetura de Software Sistemas cada vez maiores; Sistemas cada vez mais complexos; Mais requisitos em termos de confiabilidade; Mais requisitos em termos de desempenho;Mais requisitos em termos de desempenho; Mais requisitos em termos de economia; Mais requisitos em termos de integração; Necessidade de manutenibilidade – facilidade de reparo e evolução; Tendência à componentização; Busca pela reusabilidade.
  17. 17. Definição “A arquitetura de um software é a estrutura do sistema, compreendendo componentes de software, propriedades desses componentes que são visíveis externamente e oque são visíveis externamente e o relacionamento entre eles”. Paul Clements, SEI.
  18. 18. Definição “A Arquitetura de Software inclui o conjunto de decisões significantes sobre a organização de um software tais como a seleção dos elementos estruturais e suas interfaces; oelementos estruturais e suas interfaces; o comportamento entre esses elementos; a composição destes elementos estruturais e de comportamento em subsistemas maiores e o estilo arquitetural que guia esta organização.”, Booch, Kruchten, Reitman, Bittner, and Shaw.
  19. 19. Ponte entre os Requisitos e sua Implementação. Arquitetura de Software
  20. 20. Abstração que ajuda a gerenciar a complexidade Projeto Arquitetural do Software envolve: Estrutura modular do software Arquitetura de Software Componentes Relacionamento entre componentes
  21. 21. Formada por diferentes visões (4 + 1): Arquitetura de Software Visão Lógica Visão de Implementação Visão de Casos de Uso Visão de ImplantaçãoVisão de Processos
  22. 22. Visão de Casos de Uso: Compreende as situações de uso do sistema que descrevem o comportamento do sistema conforme é visto pelo seus usuários finais. Casos de uso com impacto mais significativo na arquitetura. Arquitetura de Software - Visão Casos de uso com impacto mais significativo na arquitetura. Visão Lógica: Abrange as classes, interfaces e colaborações que formam o vocabulário do problema e de sua solução. Preocupação com quantidade de camadas, plataforma a ser utilizada, tecnologias, componentes, diagrama de classes
  23. 23. Visão de Processos Abrange os processamentos paralelos, visualizando cooperação entre componentes e sincronização. Questões como concorrência, distribuição, integração, performance e escalabilidade. Arquitetura de Software - Visão performance e escalabilidade.
  24. 24. Arquitetura de Software - Visão Visão de Implementação Cobre os arquivos utilizados para a montagem e fornecimento do sistema físico. 24 Visão de Implantação Compreende os nós em que os componentes do sistema são executados.
  25. 25. Questões estruturais da Arquitetura de Software Seleção de alternativas de projeto; Escalabilidade (crescimento) e desempenho; Organização e estrutura geral do software; Protocolos de comunicação; Atribuição de funcionalidade a componentes de projeto.
  26. 26. Principais Padrões Arquiteturais Padroes do livro:(*) Buschmann, Frank; Meunier Regine; Rohnert, Hans; Sommerlad, Peter; Stal, Michael. Pattern- Oriented Software Architecture: A System of Patterns. Wiley.1998. Estruturais – padrões nesta categoria ajudam você a evitarEstruturais – padrões nesta categoria ajudam você a evitar um “mar” de componentes ou objetos. Em particular, eles suportam uma decomposição controlada de uma tarefa global do sistema em subtarefas cooperativas. A categoria inclui os seguintes padrões: Camadas Pipes e Filtros
  27. 27. Principais Padrões Arquiteturais Sistemas Distribuídos – esta categoria compreende macro soluções para sistemas baseados em distribuição. O padrão abaixo se enquadra nessa categoria: Broker
  28. 28. Principais Padrões Arquiteturais Sistemas Interativos – os padroes desta categoria suportam a estruturação de sistemas de software. O padrão abaixo se enquadra: Model-View-Controller (MVC)
  29. 29. Descrevendo Padrões Arquiteturais Nome O nome e um curto resumo do padrão. Exemplo Um exemplo do mundo real demonstrando a existência do problema e a necessidade do padrão.problema e a necessidade do padrão. Contexto As situações nas quais o padrão se aplica. Problema Descreve o problema que o padrão soluciona, incluindo uma sobre restrições, imposições e demais questões associadas ao problema.
  30. 30. Descrevendo Padrões Arquiteturais Solução O princípio básico da solução associado ao padrão. Estrutura Uma especificação detalhada dos aspectosUma especificação detalhada dos aspectos estruturais do padrão. Usos conhecidos Fornece exemplos de aplicação do padrão encontrados em sistemas reais.
  31. 31. Padrão Camadas Padrão Camadas
  32. 32. Padrão de Camadas Contexto Um grande sistema que requer decomposição. Problema Imagine que esteja projetando um sistema cuja característica principal é uma mistura de assuntos de altocaracterística principal é uma mistura de assuntos de alto nível com assuntos de baixo nível, em que os assuntos de alto nível usam os assuntos de baixo nível. A parte de baixo nível está frequentemente perto do hardware A parte de mais alto nível está frequentemente perto do usuário O fluxo de comunicação tipicamente consiste de pedidos fluindo do alto para o baixo nível As respostas andam na direção contrária
  33. 33. Padrão de Camadas Problema (cont.) Portabilidade para outras plataformas é desejada. O trabalho tem que ser subdividido em equipes com especificidades distintas.com especificidades distintas.
  34. 34. Padrão de Camadas Solução Decompor em camadas de abstração de forma que uma camada não depende da superior e utiliza serviços apenas da camadasuperior e utiliza serviços apenas da camada imediatamente inferior.
  35. 35. Padrão de Camadas Solução De um ponto de vista de alto nível, a solução é extremamente simples. O sistema deve ser estruturado em um número apropriado de camadas, colocadas umas sobre as outras.de camadas, colocadas umas sobre as outras. Inicie no nível mais baixo de abstração – chame-a de “Camada 1”. Esta é a base de seu sistema. Trabalhe seguindo para cima no nível de abstração colocando a Camada J sobre a Camada J-1 até alcançar o nível mais elevado de funcionalidade – chame-a de “Camada N”. Os serviços da Camada J são usados somente pela Camada J+1.
  36. 36. Padrão de Camadas
  37. 37. Padrão de Camadas Solução 1. Defina o critério de abstração para agrupar tarefas em camadas 2. Determine o número de níveis de abstração (baseado no critério acima)critério acima) Cada nível de abstração corresponde a uma camada Às vezes não é simples decidir se deve haver uma quebra de uma camada em subcamadas ou não Camadas demais podem gerar overhead Camadas de menos podem comprometer a estrutura
  38. 38. Padrão de Camadas Solução 3. Dê um nome e atribua tarefas a cada camada Para a camada de cima, a tarefa é a tarefa global do sistema, do ponto de vista do usuário 4. Especifique os serviços O princípio básico é de separar as camadas uma das outras Nenhum módulo abrange duas camadas Tente manter mais riqueza acima e menos abaixo Isso ajuda a prover bons serviços de alto nível para o programador "em cima"
  39. 39. Padrão de Camadas Solução 5. Refine as Camadas 6. Especifique uma interface para cada camada A camada J nada sabe sobre a camada J-1 e usa umaA camada J nada sabe sobre a camada J-1 e usa uma interface para acessá-la; O padrão Facade é bastante útil para organizar a interface da camada; 7. Estruture as camadas individualmente Quebre a camada em subsistemas (partições) menores se ela for complexa;
  40. 40. Padrão de Camadas Solução 8. Especifique a comunicação entre camadas A camada J passa a informação necessária para a camada J-1 ao chamá-la 9. Desacople camadas adjacentes Evite situações em que a camada de baixo sabe algo sobre seus clientes (camadas acima) Acoplamento unidirecional é preferível
  41. 41. Padrão de Camadas Solução 10. Projete uma estratégia de tratamento de erros O esforço de programação e overhead podem ser grandes para tratar erros numa arquitetura em camadas Um erro pode ser tratado na camada onde foiUm erro pode ser tratado na camada onde foi descoberto ou numa camada superior No segundo caso, deve haver mapeamento para tornar o erro semanticamente reconhecível pela camada de cima; Tente tratar erros na camada mais baixa possível Isso simplifica todas as camadas superiores que não sabem nem devem saber do erro.
  42. 42. Padrão de Camadas Estrutura
  43. 43. Padrão de Camadas Estrutura (cont.)
  44. 44. Padrão de Camadas Estrutura
  45. 45. Padrão de Camadas Estrutura
  46. 46. Padrão de Camadas Usos Conhecidos Sistemas de Informação em geral: Apresentação, Lógica da Aplicação, Camada de Persistência. Sistemas Operacionais: Serviços de Sistema,Sistemas Operacionais: Serviços de Sistema, Camada de Gerenciamento de Recursos, Kernel, Camada de Abstração do Hardware e o próprio Hardware.
  47. 47. Aplicações em duas camadas Cliente-Servidor Necessidade de compartilhar a lógica de acesso a dados entre vários usuários simultâneos Nesta estrutura a base de dados foi colocada em uma máquina específica, separada das máquinas que executam as aplicações.executam as aplicações. Aplicativos instalados em estações clientes contendo toda a lógica da aplicação (clientes ricos ou gordos). Um grande problema neste modelo é o gerenciamento de versões pois para cada alteração os aplicativos precisam ser atualizados em todas as máquinas clientes.
  48. 48. Aplicações em três camadas (Modelo em três camadas) Impulsionadas pela internet. Movimento no sentido de separar a lógica de negócio da interface com o usuário. Usuários da WEB possam acessar as mesmas aplicaçõesUsuários da WEB possam acessar as mesmas aplicações sem ter que instalar estas aplicações em suas máquinas locais. Como a lógica do aplicativo, inicialmente contida no cliente rico, não reside mais na máquina do usuário, este tipo de cliente passou a ser chamado de cliente pobre ou magro (Thin Client).
  49. 49. Aplicações em três camadas (Modelo em três camadas) Neste modelo o aplicativo é movido para o Servidor e um navegador Web é usado como um cliente magro. O aplicativo é executado em servidores Web com os quais o navegador Web se comunica e gera o códigoquais o navegador Web se comunica e gera o código HTML para ser exibido no cliente.
  50. 50. Aplicações em três camadas (Modelo em três camadas) Camada de apresentação Camada que interage diretamente com o usuário e onde são feitas as requisições ao sistema. Camada de negócioCamada de negócio Camada que contempla as funções e regras de todo o negócio. Não faz interface com o usuário e seus dados são voláteis. Camada de persistência Repositório das informações e as classes que a manipulam. Recebe as requisições da camada de negócios e executa essas requisições em um banco de dados.

×