ArquiteturaSoftware

3.948 visualizações

Publicada em

0 comentários
8 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

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

Nenhuma nota no slide

ArquiteturaSoftware

  1. 1. Arquitetura de Software Uma Introdução Copyright © 2017 Fábio Nogueira de Lucena fabio@inf.ufg.br
  2. 2. Conteúdo • Contexto, História • Definição • Processo • Documentação (registro) • Considerações finais
  3. 3. Contexto
  4. 4. Desejo (idéia) Requisitos (idéia em papel) Análise e Projeto (como tornar real?) Implementação Tempo PROCESSO Produto Visão de desenvolvimento de software Arquitetura de Software desempenha papel relevante neste processo
  5. 5. História
  6. 6. Fontes The Golden Age of Software Architecture, Mary Shaw e Paul Clements, IEEE Software, 2006, p. 31-39 The Past, Present, and Future of Software Architecture, Philippe Kruchten et al, IEEE Software, 2006, p. 22-30
  7. 7. Outras fontes • Podcasts https://www.computer.org/portal/web/computingnow/onarchitecture • Handbook of Software Architecture http://handbookofsoftwarearchitecture.com/ • Documenting software architecture (system contexto diagram) http://www.ibm.com/developerworks/library/ar-archdoc2/ • Documenting software architecture http://www.sei.cmu.edu/architecture/tools/document/viewsandbeyond.cfm
  8. 8. Evolução • 1969: primeira referência a Arquitetura de Software (AS) • Praticamente todos os trabalhos que citam “arquitetura de software” são de 1990 ou mais recentes (CiteSeer) • 20 referências mais citadas • Publicadas de 1991 a 2000 • 5 livros, 4 artigos (surveys), ...
  9. 9. 1985-1993 • Documentação de uma AS usando box-and-line e explanações informais • Estruturas específicas de software foram definidas para domínios específicos (controle de mísseis, ...)
  10. 10. 1992-1996 • ADLs (Architectural Description Languages) Alguns não consideram UML uma ADL • Formalização (análise formal de um modelo de arquitetura) • Workshops e congressos pelo mundo • Padrões arquiteturais são catalogados Pattern-Oriented Software Architecture---A System of Patterns, John Wiley & Sons, 1996 (POSA 1)
  11. 11. 1995-2000 • IEEE Transactions on Software Engineering dedica toda uma edição a AS em 1995. • IEEE/IFIP Conference on Software Architecture (www.wicsa.net) • Grupo de trabalho (IFIP) http://www.softwarearchitectureportal.org/
  12. 12. 1996-2003 • Análise e avaliação de arquiteturas de software “crescem” • Livros acerca de avaliação e documentação de ASs são publicados • A importância de atributos qualitativos é ressaltada junto com o papel da AS para satisfazê-los • ArchE (auxiliar de arquiteto)
  13. 13. 1998-até hoje • UML torna-se a ADL padrão da indústria • Arquiteturas n-tier client/server • Arquiteturas orientadas a serviço (SOA) • OMG inicia Model Driven Architecture (MDA): “separar negócio e lógica da aplicação da plataforma tecnológica” • Currículo ACM/IEEE: 20% de projeto de software é dedicado a AS
  14. 14. 1998-até hoje (continuação) • Surge o papel “arquiteto de software” • Worldwide Institute of Software Architects (http://www.wwisa.org/) • International Association of Software Architects (http://www.iasahome.org/) • Grady Booch Handbook on Software Architecture (catalogados 1929 padrões) (http://www.booch.com/architecture)
  15. 15. Algumas referências úteis • SEI http://www.sei.cmu.edu/architecture • Gaudí System Architecting http://www.gaudisite.nl/ • Software Architecture (Bredemeyer) http://www.bredemeyer.com/ • Software Product Lines http://softwareproductlines.com/ • Software Architectures http://www.softwarearchitectures.com/ • Grady Booch (Handbook of SA) http://www.booch.com/architecture • Pesquisas e ensino http://sunset.usc.edu/research/software_architecture/
  16. 16. Definição
  17. 17. O que é complexo, partimos...
  18. 18. Em geral, decompomos ...
  19. 19. A parte é gerenciável, tratável, ...
  20. 20. Então surgem conexões, interações,...
  21. 21. Na presença do “complexo” • Decompomos porque • A parte é gerenciável, tratável, ... • Consegue-se lidar com o todo pelas partes • “Ninguém consegue gerenciar um projeto, mas os pacotes de trabalho deste” (Rita Mulcahy) • Efeito colateral • O todo é mais do que a união das partes • Quando se parte, surgem conexões, interações...
  22. 22. Qual a relação com AS? Arquitetura de Software faz uso de Decomposição de software
  23. 23. Software Engineering, 8th edition, Ian Sommerville, Addison-Wesley, 2007 • Sistemas são decompostos em subsistemas • A identificação dos subsistemas e da estrutura empregada para controle e comunicação destes subsistemas é chamado de projeto arquitetural • A saída produzida deste processo de projeto é uma descrição da AS Estrutura que identifica os principais componentes de um sistema e as comunicações entre eles. Interações Partes
  24. 24. Software Architecture in Practice, 2nd Edition, Bass, Clements, Kazman, Addison-Wesley, 2003 “A arquitetura de software de um programa é a estrutura do sistema que compreende elementos de software, as propriedades visíveis externamente destes elementos e os relacionamentos entre eles.” Propriedades: serviços oferecidos, desempenho,...
  25. 25. Outras definições • “AS é o conjunto de decisões de projeto que, se realizadas incorretamente, podem acarretar o cancelamento do projeto.” Eoin Woods, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, Addison-Wesley, 2005. • Outras dezenas de definições http://www.sei.cmu.edu/architecture/definitions.html
  26. 26. Qual a diferença de AS e projeto? • Arquitetura é projeto • Nem tudo que é projeto é arquitetura • Projeto de granulosidade mais fina e código devem ser produzidos em conformidade com a AS Se a propriedade de um elemento da arquitetura não é visível a outros, então este não é um elemento da arquitetura. Requisitos Projeto Codificação A S
  27. 27. Diretriz As questões estruturais são o foco. São questões de projeto mais abstratas que algoritmos e estruturas de dados. Software Architecture: An Executive Overview Clements & Northrop, CMU/SEI-96-TR-003
  28. 28. Perspectivas de uma AS • Uma arquitetura de software • define a estrutura • estabelece a comunicação entre componentes • está voltada para requisitos não funcionais • é uma abstração (não é preciso consultar código) Essential Software Architecture, Ian Gorton, Springer-Verlag, 2006
  29. 29. Importante “Arquitetura de software é parte da qualidade do produto e não está ligada a um processo, tecnologia, cultura ou ferramenta particular.” Software Architecture-Centric Methods and Agile Development, Nord & Tomayko, IEEE Software, april/2006
  30. 30. Processo
  31. 31. Software Engineering, 8th edition, Ian Sommerville, Addison-Wesley, 2007 (página 240, segundo parágrafo) “Projeto é um processo criativo. Não há meio certo ou errado. Ninguém pode fornecer uma 'receita' para projeto de software. Aprende-se observando exemplos e discutindo seu projeto com outros.” Não há método amplamente aceito acerca de “como” decompor um software
  32. 32. Software Architecture Review and Assessment (SARA) Report Philippe Kruchten et al, 2001 http://philippe.kruchten.com/architecture/SARAv1.pdf Modelo do contexto de projeto de arquitetura (universo de discurso)
  33. 33. Modelo do contexto de projeto de arquitetura (universo de discurso) Exemplo Disponibilidade (PDV) Para 100 reqs, 1 poderá não ser concluída
  34. 34. Exemplo de interesse nacional • Sistemas de controle de tráfego aéreo • Qualidade (concern) • Alta disponibilidade • Requisito (versão mais objetiva) • Indisponibilidade (downtime) inferior a cinco (5) minutos por ano
  35. 35. The Visual Architecting ProcessTM The Visual Architecting Process (VAP) http://www.bredemeyer.com Subconjunto dos requisitos de um sistema (requisitos não funcionais ou arquiteturalmente relevantes) Quando parar? Exige avaliação!
  36. 36. Architecture Expert (ArchE) Tool • Criar especificação mensurável de requisitos não funcionais • Avaliar se a arquitetura corrente satisfaz os requisitos • Não: fazer mudanças e repetir o passo acima. • Sim: processo é terminado. PROBLEMA: o número de possíveis soluções é “grande”, mesmo para um simples problema.
  37. 37. Documentação
  38. 38. Problema • Uma arquitetura de software precisa ser: • comunicada • compreendida • analisada • Ou seja, precisa ser registrada
  39. 39. Noção comum • Arquitetura de Software é composição de: • Diagramas contendo caixas e linhas • Juntamente com explanações informais Componentes operam sob o controle do Frontend, responsável pela interface gráfica ... Legenda: seta tracejada significa ...
  40. 40. Arquiteto de Software baixo custo, equiparação com concorrentes, facilidade de mudança, usabilidade, confiabilidade, desempenho, ... Perspectiva de documentação Insumos de stakeholders Arquitetura de Software Decisões
  41. 41. Software Architecture Review and Assessment (SARA) Report Philippe Kruchten et al, 2001 http://philippe.kruchten.com/architecture/SARAv1.pdf Modelo do contexto de projeto de arquitetura (universo de discurso) Como registrar? Insumos de stakeholders
  42. 42. Alguns atributos qualitativos • Desempenho • Escalabilidade (requisições, conexões...) • Quão fácil é alterar o software? • Segurança • Disponibilidade • Quão fácil é a integração? • Portabilidade, testabilidade, ... Essential Software Architecture, Ian Gorton, Springer-Verlag, 2006
  43. 43. Disponibilidade • Nenhum sistema será executado sem interrupções para sempre • Situações inesperadas e indesejáveis ocorrem • O sistema será paralisado • Manutenção será realizada • Disponibilidade Quanto do tempo o sistema estará disponível?
  44. 44. Desempenho • Quando se requisita um serviço, o usuário espera por resposta rápida • Desempenho Habilidade de produzir a resposta no tempo apropriado
  45. 45. Escalabilidade • Desempenho para um usuário: ótimo • Desempenho para 1K usuários: OK • EXEMPLO QuickSort recursivo (pode causar stack overflow) • Escalabilidade Desempenho não cai de forma significativa à medida que o número de requisições aumenta
  46. 46. Segurança • Nenhum sistema é 100% seguro • Nenhum sistema é totalmente aberto • Segurança Criar “barreiras” para assegurar privacidade e acesso controlado à funcionalidade
  47. 47. Gerenciabilidade • É preciso monitorar para verificar se está tudo ok • É preciso alterar em tempo de execução para corrigir rota • Gerenciabilidade Capacidade de monitorar e alterar o funcionamento do sistema em tempo de execução
  48. 48. Manutenibilidade • Todo sistema precisa de atualização • Todo sistema será corrigido • Manutenibilidade Quão fácil é corrigir/atualizar um sistema?
  49. 49. Flexibilidade • Sistemas passarão por mudanças ao longo do tempo • Flexibilidade Quão fácil é produzir novas versões?
  50. 50. Portabilidade • Todo sistema é executado em um ambiente • Ambientes alteram-se com o tempo • Portabilidade Quão fácil é migrar para um outro ambiente?
  51. 51. Como registrá-los? • Cenário de atributo de qualidade • Fonte de estímulo • Estímulo • Ambiente • Artefato • Resposta • Medida da resposta • Exemplo Desenvolvedor deve alterar a interface para contemplar novo atributo de entidade. Deverá consumir menos de 3 horas para produzir e testar sem efeitos colaterais. Software Architecture in Practice, 2nd Edition, Bass, Clements, Kazman, Addison-Wesley, 2003
  52. 52. Software Architecture Review and Assessment (SARA) Report Philippe Kruchten et al, 2001 http://philippe.kruchten.com/architecture/SARAv1.pdf Modelo do contexto de projeto de arquitetura (universo de discurso) Atributos qualitativos O que registrar? Como registrar? Arquitetura de Software
  53. 53. O que registrar? Ontologia para arquitetura de software Arquitetura de Software
  54. 54. Como registrar uma AS? • Box-and line (registro informal) • IEEE Recommended Practice for Architectural Description of Software-Intensive Systems IEEE Std 1471-2000 • The 4+1 View Model of Software Architecture, Phillip Kruchten, IEEE Software, vol. 12, no. 6, 1995 • Templates, apresentação, ... How to Represent the Architecture of Your Enterprise Application Usin UML 2.0 and More Paulo Merson http://www.sei.cmu.edu/architecture/arch_doc.html Arquitetura de Software
  55. 55. Informal Box-and-line (representação) Mecanismo mais comum acompanhado de explicações
  56. 56. Representação usando box-and-line Arquitetura de software cliente/servidor (three-tier) http://en.wikipedia.org/wiki/Multitier_architecture
  57. 57. Mobile and Wireless Design Essentials, Martyn Mallick, Wiley, 2003
  58. 58. Arquitetura Web usando Ajax (MSDN) http://msdn.microsoft.com/msdnmag/issues/07/09/CuttingEdge/default.aspx?loc=pt
  59. 59. The Java EE 5 Tutorial http://java.sun.com/javaee/5/docs/tutorial/doc/p1.html
  60. 60. Mais um exemplo... Essential Software Architecture, Ian Gorton, Springer-Verlag, 2006
  61. 61. Qual o problema com box-and-line? • Em geral não seguem com “legenda” daí • Não se sabe o que significa uma caixa • Processo, thread, ... • Código fonte, compilado, DLL, Jar file, ... • Contêiner, biblioteca, ... • Não se sabe a semântica de uma linha • Fluxo de controle (em que sentido?) • Fluxo de dados, dependência (temporal, ...)
  62. 62. Cenário atual • Software compreende várias estruturas • Código, decomposição deste, dependências,... • Processos e como estes interagem • A implantação (distribuição) em hardware • E outras... • Visão: representação de uma estrutura • Ou seja, precisamos de várias visões
  63. 63. The 4+1 View Model of Software Architecture, Phillip Kruchten, IEEE Software, vol. 12, no. 6, 1995 • Lógica • Objetos relevantes (quando se usa OO) • Processo • Aspectos de concorrência e sincronização • Física • Mapeamento de software em hardware • Desenvolvimento • Identifica módulos, subsistemas, camadas • Cenários (integra as visões)
  64. 64. Exemplos de Documentos de Arquiteturas de Software (múltiplas visões) • Toy Air Traffic System (TATS) Philippe Kruchten http://philippe.kruchten.com/architecture/SADexample.doc • Exemplo (documentação de uma AS) http://la.sei.cmu.edu/sad-wiki/index.php/The_Java_Pet_Store_SAD
  65. 65. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std 1471-2000 • Sugere o emprego de visões • Não informa, contudo, quais as visões?
  66. 66. “Aquela que melhora a compreensão do sistema e seus atributos” Software Architecture in Practice, 2nd Edition, Bass, Clements, Kazman, Addison-Wesley, 2003 Que visão é relevante?
  67. 67. Quando?
  68. 68. The Visual Architecting ProcessTM The Visual Architecting Process (VAP) http://www.bredemeyer.com
  69. 69. Considerações finais
  70. 70. Uma perspectiva adicional... • Arquitetura é o conjunto de decisões de projeto que devem ser feitas no começo de um projeto. • Arquitetura faz referência ao que é importante. O que quer que seja este importante. • A compreensão comum do projeto de um sistema é a arquitetura deste sistema. • Decisões de arquitetura são difíceis de serem alteradas. Who needs na Architect? Martin Fowler, IEEE Software, sept/oct, 2003, 11-13. http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
  71. 71. Arquiteto de Software (papel) O arquiteto ideal deveria ser uma pessoa de artes, um matemático familiar com estudos históricos, um estudante diligente de filosofia, conhecedor da música, não ignorante em medicina, capaz de compreender juristas, familiar com a astronomia e cálculos astronômicos. Vitruvius, 25 AC A “visão” do arquiteto de software deve ser HORIZONTAL, AMPLA, em vez daquela vertical, necessária em projetistas de software.
  72. 72. Projeto de arquitetura é um processo criativo Grady Booch Handbook on Software Architecture (catalogados 1929 padrões) (http://www.booch.com/architecture) O que influi neste processo? • A experiência do arquiteto
  73. 73. Organização de um sistema • Modelo cliente/servidor • Clientes usufruem de serviços oferecidos por servidores • Modelo repositório • Sub-sistemas compartilham dados em repositório compartilhado • Modelo em camadas • Camadas oferecem serviços definidos em termos de serviços oferecidos pelas camadas inferiores
  74. 74. Outras questões • Arquiteturas para sistemas distribuídos • Arquiteturas cliente/servidor • Objetos distribuídos (CORBA, ...) • Service-Oriented Architecture (SOA) • Mensagens + Interface pública • Model-Driven Architecture (MDA) • Separa aplicação de plataformas e tecnologias
  75. 75. Sucesso a todos! fabio@inf.ufg.br

×