1. Arquitetura de Software
Compreendendo o livro
Software Architecture in Practice
Len Bass et al., Addison-Wesley, 3rd edition, 2013
Fábio Nogueira de Lucena
Instituto de Informática (UFG)
2017

2. Direitos autorais
Slides produzidos a partir do conteúdo do livro
Software Architecture in Practice
Len Bass, Paul Clements e Rick Kazman
Addion-Wesley, 3rd edition, 2013.

3. Direitos autorais
As imagens contidas nos slides foram obtidas via Google Search, com a opção
avançada de direitos autorais definidas para
noncommercial reuse

4. O que é
arquitetura de software?
Páginas 3-24

5. Sistemas de software são construídos para
satisfazer objetivos de negócio de organizações.

6. Objetivo de negócio
Business goal define o propósito
pelo qual um sistema é construído.
A arquitetura é projetada para
satisfazer esse propósito.

7. Objetivo de negócio fomenta
requisito de qualidade (arquitetural)...
Ampliar a presença no mercado
Software mais “rápido” e “mais eficiente”.

8. Objetivos
(negócio) Software
Arquitetura de
Software

9. Arquitetura de Software é meio
Objetivos do
negócio
Implementação
do software
Arquitetura de Software
Requisitos Projeto Construção

10. Visão funcional
Definir a
Arquitetura
de Software
Requisitos
Conhecimento; Experiência; “Plágio”;
Intuição; Restrições; ...
Representação da
Arquitetura de Software

11. Arquitetura de Software
Requisitos
(entrada)
Projeto arquitetural
(processo)
Documentação da arquitetura
(saída)
Documentação pode ser utilizada para a
implementação ou para a avaliação.

12. Uma arquitetura de software pode ser...
Documentada Projetada Analisada

13. O que é
arquitetura de software?

14. Como “pensar” uma solução de software?

15. Como analisar ou entender uma solução existente?

16. O que é arquitetura de software?
“É o conjunto de estruturas,
compostas de elementos e das
relações entre eles.”

17. Quais são os tipos de estruturas?
Módulos
Componente-e-conector
Alocação

18. Módulos

19. Módulo
Divide o sistema em unidade de implementação
Possui uma responsabilidade computacional
Define a unidade de trabalho de equipes de programação
Unidade estática (ênfase está na divisão da funcionalidade do sistema)
Exemplos
Banco de dados
Regras de negócio
Interface com o usuário, ...

20. Módulo
Registra as decisões acerca de como o sistema será estruturado como um
conjunto de unidades de código e dados.
Um módulo é uma classe, camadas ou simples divisão da funcionalidade, cada
um deles uma unidade de implementação.

21. Questões que são respondidas por módulos
Quais as principais responsabilidades atribuídas a cada módulo?
Qual a relação de uso entre os módulos?
Qual a relação de herança entre os módulos?
Qual a relação de composição entre os módulos?

22. Módulos
(exemplos)
Divisão de responsabilidade, uso, decomposição

23. Módulos (exemplo) (1/18)
HealthDB
(camadas)

24. Módulos (exemplo) (2/18)
HealthDB

25. Módulos (exemplo) (3/18)

26. Módulos (exemplo) (4/18)

27. Módulos (exemplo) (5/18)

28. Módulos (exemplo) (6/18)

29. Módulos (exemplo) (7/18)

30. Módulos (exemplo) (8/18)

31. Módulos (exemplo) (9/18)

32. Módulos (exemplo) (10/18)

33. Módulos (exemplo) (11/18)

34. Módulos (exemplo) (12/18)

35. Módulos (exemplo) (13/18)

36. Módulos (exemplo) (14/18)

37. Módulos (exemplo) (15/18)

38. Módulos (exemplo) (16/18)
Imagem obtida de
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

39. Módulos (exemplo) (17/18)
Imagem obtida de
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

40. Módulos (exemplo) (18/18)

41. Módulos
(exemplos)
Classes (típicas de análise e projeto orientado a objetos)

42. Módulos (exemplo) (1/4)

43. Módulos (exemplo) (2/4)

44. Módulos (exemplo) (3/4)

45. Módulos (exemplo) (4/4)

46. Módulos
(exemplos)
Modelo de dados

47. Módulos (exemplo) (18/18)

48. Módulos (exemplo) (18/18)

49. Módulos (exemplo) (18/18)

50. Módulos (exemplo) (4/4)

51. Módulos
(revisão)

52. Verifique as respostas para as questões abaixo?
Quais as principais responsabilidades atribuídas a cada módulo?
Pode ser necessário um breve texto
Qual a relação de uso entre os módulos?
Provavelmente um diagrama de classes com dependências
Qual a relação de herança entre os módulos?
Um diagrama de classes com as heranças entre os módulos
Qual a relação de composição entre os módulos?
Novamente um diagrama de classes com packages que são refinados
(decompostos) para ilustrar a composição.

53. Componente-e-Conector

54. Componente-e-Conector
Explicita decisões arquiteturais nas quais o
sistema é estruturado como um conjunto de
elementos que possuem comportamento em
tempo de execução (componentes) e interações
(conectores)

55. Componentes (exemplos)
Serviço (pagamento online)
Serviço (verificação de endereço com base em CEP)
Serviço (emissão de nota fiscal eletrônica)
Clientes (interface gráfica em smartphone, em browser, …)
Servidor de arquivos, banco de dados, ...

56. Quais as questões respondidas?
Quais as principais componentes e como eles interagem em tempo de
execução?
Quais são os principais “shared data stores”?
Quais partes do sistema podem ser replicadas?
Quais partes do sistema podem ser executadas em paralelo?

57. Disponível em https://github.com/kyriosdata/bsus

58. Disponível em http://www.uml-diagrams.org/component-diagrams.html

59. Disponível em
http://www.site.uottawa.ca/~tcl/gradtheses/mnojoumian/ThesisFiles/FinalSpec/UML/images/UML_img_167.jpg

60. Disponível em https://distrinet.cs.kuleuven.be/software/digitalpublishing/html/architectureP1.png

61. Táticas
Lidando com requisitos “clássicos”

62. Disponibilidade (availability)
99%, 3 dias e 15.6 horas indisponíveis em um ano
1% de 365 * 24 = 8760 horas é 87,6 horas, 72 horas (3 dias) + 15.6 horas
99.9%, 8 horas, 0 minutos e 46 segundos indisponíveis em um ano
99.99%, 52 minutos, 34 segundos
99.999%, 5 minutos, 15 segundos
99.9999%, 32 segundos indisponíveis por ano

63. Disponibilidade (tática)
Detectar falha
Recuperar (da falha)
Prevenir

64. Disponibilidade (tática “detectar”)
Ping/Echo
Monitor
Heartbeat
Timestamp
Sanity Checking
Condition monitoring
Voting
Exception detection