O documento discute questões sobre arquitetura de software, incluindo definições, representações, estruturas e visões. Aborda a importância da documentação da arquitetura e decisões de projeto. Também apresenta exemplos de arquiteturas de sistemas de banco de dados.

1. Arquitetura de Software
Questões relevantes, geralmente não abordadas
Fábio Nogueira de Lucena
Instituto de Informática (UFG)
XVI Jornada Goiana em Engenharia de Software

2. Direitos autorais
Imagens obtidas da internet
Uso interno apenas

3. Vamos “limpar” nossa mente e
esclarecer algumas questões...
Isso não é uma introdução!

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

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

6. Especificações de Requisitos de Software
Quem lê?

7. Especificações de área, volume, dimensões,...
Pessoas preferem “navegar” pelo domínio da solução

8. Por que usar “documentação executável”?
Estratégia para reduzir riscos.
Requisitos
“compreendidos”
e executáveis!
Arquitetura que admite testes “facilmente”

9. Representação (apresentadas como arquitetura)

10. Mais ilustrações

11. Mais ilustrações

12. Mais ilustrações

13. Outra exemplo

14. Mais uma representação “bonita”

15. “Diagrama conceitual” (antes era “arquitetura”)
Java 8
(JDK 1.8)

16. Contexto (escopo)
Arquitetura Corporativa
Arquitetura de Sistema
Arquitetura
de Software
hardware + software + pessoas
Como software apoia objetivos do negócio?
Sistema. LZFSE
oferece baixo consumo
de energia.
Corporativa.
Departamento ocioso,
que usa Python é
agregado ao projeto.

17. Todo software possui uma arquitetura
Qualquer software pode ser “pensado” pelos seus elementos e relações.
Todo software possui uma arquitetura,
mesmo que seja desconhecida
Documentação
da arquitetura
Arquitetura
de Software
Existe independente da documentação

18. Como registrar a “motivação” de uma decisão?
Documenting Architecture Decisions
Michael Nygard

19. Nem todas arquiteturas são iguais
Arquitetura pode permitir
ou inibir um requisito
Dadas duas arquiteturas, uma pode ser
“melhor” que a outra
Tentativa & Erro Design Avaliação
Inaceitável

20. De fato, uma arquitetura de software pode ser...
Documentada Projetada Analisada

21. "Arquitetos devem tomar decisões, ...
que devem ser documentadas,
revisadas e aprovadas, além de servir
como restrição para a futura construção."

22. On Architecture: The Accidental Architecture
Grady Booch,
IEEE Podcast
“Arquitetura acidental surge como
resultado de numerosas decisões ao
longo do desenvolvimento.”
“Arquitetura intencional é uma arquitetura
explicitamente identificada e só então
implementada.”

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

24. Modelagem da definição de arquitetura

25. Estruturas e visões
Estruturas
Visões
Documentadas por
Visão A Visão B
Representações distintas (por exemplo, stakeholders distintos)

26. ISO/IEC/IEEE
42010:2011
Systems and Software
Engineering --
Architecture Description

27. Categorias de estruturas
(estática) Módulos
Divide o sistema em unidades de implementação, distribui responsabilidades
Base para atribuição de tarefas a equipes de programação
Estrutura estática (classes, camadas, …)
(dinâmica) C&C (component-and-conector)
Componente = entidade que existe apenas em tempo de execução
Estrutura dinâmica
Foco na interação entre os elementos da estrutura

28. Estruturas de módulos (estática)
Qual a principal responsabilidade?
Quais elementos um módulo pode usar?
Quais os módulos usados por um módulo?
Quais os relacionamentos entre módulos? (herança)

29. Exemplo de módulos (SGBD)

30. Outros exemplos (outros SGBDs)

31. Estruturas C&C
Quais os principais
componentes em
execução?
Como interagem em
tempo de execução?
Quais partes do
sistema são
executadas em
paralelo?

32. Alocação
Em qual processador cada elemento de software é executado?
Em quais diretórios cada elemento é armazenado durante o desenvolvimento?
E durante os testes e building?
Qual equipe desenvolve cada elemento?

33. Exemplo de “alocação”
O que esse
diagrama
diz?

34. Se tivermos “muitos” usuários?
Instalar e configurar
Adobe Flash
=> Suporte

35. Quais são os demais elementos?
1. Web Server
2. Apache
3. Application Server
4. Tomcat
5. Servlet (aplicação)
6. JVM (omitida)
7. JDBC
8. Database Server
9. MySQL

36. Qual é o problema?
Web Server
Apache
Application Server
Tomcat
Servlet (aplicação)
JVM (omitida)
JDBC
Database Server
MySQL
● Configuração complexa
● Monitoramento
● Instalação
● Atualização

37. Resposta para configurar e instalar
Deploy. Manage systems. Crush complexity.
Web Server
Apache
Application Server
Tomcat
Servlet (aplicação)
JVM (omitida)
JDBC
Database Server
MySQL

38. Distribuição (“sem instalação”)
Web Server
Apache
Application Server
Tomcat
Servlet (aplicação)
JVM (omitida)
JDBC
Database Server
MySQL

39. Monitorar (antecipar problemas, manter em operação)
Web Server
Apache
Application Server
Tomcat
Servlet (aplicação)
JVM (omitida)
JDBC
Database Server
MySQL
Pode exigir uso
de JMX

40. Ligação com tecnologia
Por que Tomcat?
● Java
○ Jetty, WebLogic, Glassfish,
JBoss, JOnAS, Resin, WildFly, …
○ GAE (Google)
○ Netty
○ Spray
○ Grizzly
○ Vert.x
○ Mina
● Windows
○ .Net Core (Web API)
○ .Net Framework
● C
○ libmicrohttpd, facil.io, libuv,
nanomsg, lighttpd, ...
Algumas opções:
Arquiteturas
lógicas e físicas.

41. Estrutura “preferida”: decomposição
Tende a “dirigir” a estrutura do projeto por “espelhar” a estrutura de equipes de
desenvolvimento.
“Organizações que projetam sistemas… tendem a produzir projetos que são
cópias das estruturas de comunicação dessas organizações.”
Lei de Conway.
Pesquisadores do MIT e Harvard Business School
“Equipes distribuídas tendem a desenvolver software mais modular”

42. “Uma equipe” vs “Várias” (influência na arquitetura)
Equipes multidisciplinares

43. Requisitos de qualidade (como me orientar?)
34 páginas!

44. Nem todos os requisitos de qualidade são RARs
RAR: Requisito Arquiteturalmente Relevante
Stakeholders distintos, interferências distintas.
Stakeholder “relevante” (SR) r1, r2, …, rn
(definidos pelo SR)
Subconjunto relevante = { si, sj, sk }
(priorizados)

45. “Prática” (SGBD)
Database System Implementation
Molina, Ullman e Widom
Prentice-Hall, 2000
Componentes de um SGBD
(página 7, figura 1.1)

46. SGBD (recorte para análise)
Query compiler
Execution engine
Simplificação?

47. Recorte
Query compiler para query compilation

48. Módulos de um compilador

49. Módulos de um compilador

50. O que o “mundo” está falando sobre o assunto?
DevOps, Entrega Contínua

51. Compreender cenários “complexos”
Menos elementos
Mais elementos, combinação mais
complexa, maiores riscos

52. Visualização (CodeCity) (raio X para software)

53. Seria bom estar lá...
Um dos mini-cursos:
We’ll focus on the eight core principles
stability, reliability, performance,
scalability, fault-tolerance,
catastrophe-preparedness,
monitoring, and documentation.
Susan Fowler
Reliability engineer at Uber

54. Alegrem-se na esperança, sejam
pacientes na tribulação.
Romanos 12:12