1 of 119

Engenharia de Software Moderna

Cap. 7 - Arquitetura

Prof. Marco Tulio Valente

https://engsoftmoderna.info

1

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides

2 of 119

Arquitetura

  • Projeto em mais alto nível
  • Foco não são mais unidades pequenas (ex.: classes)
  • Mas sim unidades maiores e mais relevantes
    • Pacotes, módulos, subsistemas, camadas, serviços, ...

2

3 of 119

3

Software Design

Software Architecture

4 of 119

Padrões Arquiteturais

  • Modelos pré-definidos para arquiteturas de software
  • Vamos estudar:
    • Camadas (duas e três camadas)
    • Model-View-Controller (MVC)
    • Microsserviços
    • Orientada a Mensagens
    • Publish/Subscribe

4

5 of 119

Sobre a importância de Arquitetura de Software

5

6 of 119

Debate Linus-Tanenbaum (1992)

6

Criador do sistema

operacional Linux

Autor de livros e do sistema operacional Minix

7 of 119

Início do debate: Mensagem do Tanenbaum (1992)

7

8 of 119

Argumento do Tanenbaum

  • Linux possui uma arquitetura monolítica
    • Sistema operacional é um único arquivo
    • Gerência de processos, memória, arquivos, etc
  • O melhor seria uma arquitetura microkernel
    • Kernel só possui serviços essenciais
    • Demais serviços rodam como processos independentes

8

9 of 119

Resposta do Linus

9

10 of 119

Argumento do Linus

  • Em teoria, arquitetura microkernel é mais interessante
  • Mas existem outros critérios que devem ser considerados
  • Um deles é que o Linux já era uma realidade e não apenas uma promessa

10

11 of 119

Nova mensagem do Tanenbaum

  • "Eu continuo com minha opinião…"
  • "Agradeça por não ser meu aluno. Se fosse, você não iria tirar uma nota alta com essa arquitetura."

11

12 of 119

Comentário do Ken Thompson (Unix)

  • "É mais fácil implementar um SO com um kernel monolítico."
  • "Mas é também mais fácil que ele se transforme em uma bagunça à medida que o kernel é modificado."

12

13 of 119

Ken Thompson previu o futuro:

17 anos depois (2009) veja a declaração de Torvalds em uma conferência de Linux

13

14 of 119

  • "Não somos mais o kernel simples, pequeno e hiper-eficiente que imaginei há 15 anos."
  • "Em vez disso, o kernel está grande e inchado. Quando adicionamos novas funcionalidades, o cenário piora."

14

15 of 119

Moral da história: os custos de uma decisão arquitetural podem levar anos para aparecer …

15

16 of 119

Arquitetura em Camadas

16

17 of 119

Arquitetura em Camadas

  • Sistema é organizado em camadas, de forma hierárquica
  • Camada n somente pode usar serviços da camada n-1
  • Muito usada em redes computadores e sist. distribuídos

17

18 of 119

Vantagens

  • Dividir para conquistar:
    • Quebra complexidade do sistema
    • Facilita entendimento
    • Facilita troca de camadas (ex: TCP, UDP)
    • Facilita reúso de camadas (ex: várias apps usam TCP)

18

19 of 119

Variações para Sistemas de Informações

  • Três camadas
  • Duas camadas

19

20 of 119

Arquitetura em Três Camadas

  • Comum em processos de "downsizing" de aplicações corporativas nas décadas de 80 e 90
  • Downsizing: migração de computadores de mainframes para servidores, rodando Unix

20

21 of 119

Arquitetura em Três Camadas

21

22 of 119

Arquitetura em Duas Camadas

  • Mais simples:
    • Camada 1 (cliente): interface + lógica
    • Camada 2 (servidor de BD): bancos de dados
  • Desvantagem: todo o processamento é feito no cliente

22

23 of 119

Arquitetura Model-View-Controller (MVC)

23

24 of 119

Arquitetura MVC

  • Surgiu na década de 80, com a linguagem Smalltalk
  • Proposta para implementar interfaces gráficas (GUIs)

24

25 of 119

MVC

  • Visão: classes para implementação de GUIs, como janelas, botões, menus, barras de rolagem, etc
  • Controle: classes que tratam eventos produzidos por dispositivos de entrada, como mouse e teclado
  • Modelo: classes com lógica e dados da aplicação

25

26 of 119

MVC = (Visão + Controladores) + Modelo

= Interface Gráfica + Modelo

26

27 of 119

27

Modelo

Interface Gráfica 1

Interface Gráfica 2

28 of 119

Importante

  • MVC não foi pensado para aplicações distribuídas; mas para aplicações desktop monolíticas
  • Exemplo: Microsoft Word, Calculadora, etc

28

29 of 119

MVC Tradicional (Smalltalk)

29

30 of 119

MVC nos dias de hoje

  • MVC Web
  • Single Page Applications

30

31 of 119

MVC Web

31

32 of 119

MVC Web

  • Adaptação de MVC para Web, ou seja, sistemas distribuídos
  • Usando Ruby on Rails, DJango, Spring, PHP Laravel, etc

32

33 of 119

33

Páginas HTML, CSS, JavaScript (o que o usuário vai ver)

34 of 119

34

Recebem dados de entrada e fornecem informações para páginas de saída

35 of 119

35

Lógica da aplicação (regras de negócio) e fazem a interface com o banco de dados

36 of 119

Exemplo muito simples de um sistema MVC Web

https://github.com/mtov/ESM-ExemplosCodigo/tree/master/cap7/mvc

36

Este exemplo não usa nenhum framework e possui uma interface Web muito simples, tudo por motivos didáticos

37 of 119

Controlador

37

public class ControladorPesquisaLivros {

...

public void start() {

...

get("/", (req, res) -> {

res.redirect("index.html");

return null;

});

...

}

}

38 of 119

Browser (index.html)

38

39 of 119

Controlador

39

public class ControladorPesquisaLivros {

ServicoPesquisaLivros pesq;

PaginaDadosLivro pagina;

...

public void start() {

...

get("/pesquisa", (req, res) -> {

String autor = req.queryParams("autor");

Livro livro = pesq.pesquisaPorAutor(autor);

return pagina.exibeLivro(livro.getTitulo(),

livro.getAutor(), livro.getISBN());

});

...

}

}

40 of 119

Modelo

40

public class ServicoPesquisaLivros {

public Livro pesquisaPorAutor(String autor) {

try(Connection con = DriverManager.getConnection(...)) {

String query = "select * from livros where autor = ?";

PreparedStatement stmt = con.prepareStatement(query);

stmt.setString(1, autor);

ResultSet rs = stmt.executeQuery();

String isbn = rs.getString("isbn");

String titulo = rs.getString("titulo");

return new Livro(isbn, autor, titulo);

} catch (SQLException e) {

System.out.println(e.getMessage());

return null;

}

}

}

41 of 119

Controlador

41

public class ControladorPesquisaLivros {

ServicoPesquisaLivros pesq;

PaginaDadosLivro pagina;

...

public void start() {

...

get("/pesquisa", (req, res) -> {

String autor = req.queryParams("autor");

Livro livro = pesq.pesquisaPorAutor(autor);

return pagina.exibeLivro(livro.getTitulo(),

livro.getAutor(), livro.getISBN());

});

...

}

}

42 of 119

Visão

42

public class PaginaDadosLivro {

public String exibeLivro(String titulo, String autor, String isbn) {

String res = "<h4> Dados do Livro Pesquisado </h4>";

res += "<ul>";

res += "<li> Título: " + titulo + " </li>";

res += "<li> Autor: " + autor + " </li>";

res += "<li> ISBN: " + isbn + " </li>";

res += "</ul>";

return res;

}

}

43 of 119

Browser

43

44 of 119

44

45 of 119

Observação

  • MVC ⇒ Aplicação Monolítica (Monolito)
  • Inclusive, esse monolito possui frontend e backend integrados

45

46 of 119

MVC Frameworks continuam sendo relevantes!

46

47 of 119

Pergunta: Conhece alguma empresa brasileira que usa frameworks MVC?

47

48 of 119

Single Page Applications (SPAs)

48

49 of 119

Aplicações Web Tradicionais

49

Browser

Server

Request

Response (HTML)

Request

Response (HTML)

Request

Response (HTML)

Problema: interface menos responsiva

Exemplo: Toda alteração que faz em um formulário, tem que clicar em “Salvar”

Multiple Page Applications (MPAs)

50 of 119

Single Page Applications

  • Roda no browser; logo, mais independente do servidor
  • "Menos burra": manipula sua interface e armazena dados
  • Acessa o servidor para buscar mais dados
  • Exemplo: GMail, Google Docs, Facebook, Figma, etc
  • Implementadas em JavaScript, usando React, Vue, Svelte, etc

50

51 of 119

Exemplo: Aplicação Simples usando Vue.js

51

52 of 119

52

Interface (Web)

HTML

53 of 119

53

54 of 119

54

Dados

Métodos

Modelo

55 of 119

55

56 of 119

56

57 of 119

57

58 of 119

Resumo

MVC Tradicional (Smalltalk): aplicações gráficas, pré-Web

MVC Web: adaptação de MVC para Web (fullstack)

SPA: adaptação de MVC para uso no front-end

58

59 of 119

Arquiteturas baseadas em Microsserviços

59

60 of 119

Importante: o que vamos estudar no restante do capítulo diz respeito a arquiteturas de backend

60

61 of 119

Monolitos

  • Em tempo de execução, sistema é um único processo (processo aqui é processo de sistema operacional)

61

Módulos (de implementação e compilação)

Mas em tempo de execução, tudo roda em único processo ou serviço

62 of 119

Problema #1: Single Point of Failure

62

  • 2008: grave falha no sistema (BD)
  • Dias sem conseguir alugar DVDs
  • Duas mudanças importantes:
    • AWS
    • Microsserviços

63 of 119

Escalabilidade: Vertical vs Horizontal

63

https://www.section.io/blog/scaling-horizontally-vs-vertically/

64 of 119

Problema #2 com Monolitos: Escalabilidade

  • Escalabilidade horizontal requer escalar o monolito inteiro, mesmo quando o gargalo está em um único módulo

64

65 of 119

Problema #3: Release é mais lento

  • Times não tem poder para colocar módulos em produção
  • Motivo: mudanças em um módulo podem impactar módulos que estão funcionando
  • Acabam existindo:
    • Datas pré-definidas para release
    • Processo de homologação de releases

65

66 of 119

Exemplo

  • Novo releases: sempre no dia 10
    • Último dia para mudanças: dia 1
    • Testes e homologação: dia dias 2 a 9
  • Se implementou uma feature no dia 02/09, mesmo que pequena, ela só entrará em produção no dia 10/10

66

67 of 119

Riscos de adicionar novas features em um código existente (principalmente, se monolítico)

67

68 of 119

Microsserviços

68

69 of 119

Microsserviços

  • Módulos (ou conjuntos de módulos) viram processos em tempo de execução
  • Esses módulos são menores do que de um monolito
  • Daí o nome microsserviço

69

70 of 119

70

Arquitetura Monolítica

71 of 119

71

Arquitetura Monolítica

Arquitetura baseada em Microsserviços

Microsserviço com

1 módulo

Microsserviço com

3 módulos

microsserviço = processo (run-time, sistema operacional)

Microsserviço com

2 módulos

72 of 119

Vantagem #1: Escalabilidade

  • Pode-se escalar apenas o módulo com problema de desempenho

72

Só contém instâncias de M1, pois apenas ele é o gargalo de desempenho

73 of 119

Vantagem #2: Flexibilidade para Releases

  • Times ganham autonomia para colocar microsserviços em produção
  • Processo = espaço de endereçamento próprio
  • Chances de interferências entre processos são menores

73

74 of 119

Releases de microsserviços

  • Não existe mais uma homologação centralizada
  • Cada time homologa seus microsserviços
  • Se implementou uma feature no dia 02/09, ela pode entrar em produção imediatamente

74

75 of 119

Outras vantagens

  • Tecnologias diferentes
  • Falhas parciais

75

76 of 119

Quem usa microsserviços?

  • Grandes empresas como Netflix, Amazon, Google, etc

76

Cada nodo é um microsserviço

77 of 119

Uber (~2018)

77

https://eng.uber.com/microservice-architecture/

78 of 119

Mercado Livre (maio 2025)

78

79 of 119

Pergunta: Conhece alguma empresa brasileira que usa microsserviços?

79

80 of 119

Exemplo de uma aplicação de ecommerce baseada em microsserviços

80

81 of 119

81

82 of 119

Gerenciamento de Dados com Microsserviços

82

Arquitetura que não é recomendada. Motivo: aumenta acoplamento entre M1 e M2

83 of 119

Gerenciamento de Dados com Microsserviços

83

84 of 119

Quando não usar microsserviços?

  • Arquitetura com microsserviços é mais complexa
    • Sistema distribuído (monitorar centenas de processos)
    • Latência (comunicação via rede)
    • Transações distribuídas
    • Monitoramento e observabilidade

84

85 of 119

Recomendação: começar com monolitos

  • E migrar para microsserviços se:
    • Monolito apresentar problemas de desempenho
    • Monolito estiver atrasando as releases
  • Migração pode ser gradativa…

85

86 of 119

Mas existem exceções

86

https://building.nubank.com/pt-br/microsservicos-no-nubank-uma-visao-geral/

"começamos com microsserviços desde o primeiro dia, desafiando o conselho padrão de começar com um monólito."

87 of 119

Roteiro prático sobre microsserviços

https://github.com/aserg-ufmg/micro-livraria

87

88 of 119

88

89 of 119

gRPC

  • Sistema que viabiliza comunicação entre aplicações
  • Baseado em Chamada Remota de Procedimentos
  • Inclui um protocolo binário para comunicação distribuída
  • E também uma linguagem para definição de interfaces
    • Clientes: chamam métodos dessa interface
    • Servidores: implementam métodos

89

90 of 119

gRPC: Linguagem para definição de interfaces

90

91 of 119

91

app.get('/shipping/:cep', (req,res,next) => {

shipping.GetShippingRate( {

cep: req.params.cep,

},

(err, data) => { …

server.addService(shippingProto.ShippingService.service, {

GetShippingRate: (_, callback) => {

const shippingValue = Math.random() * 100 + 1;

callback(null, {

value: shippingValue,

});

},

});

92 of 119

Arquitetura Orientada a Mensagens

92

93 of 119

Modelo de comunicação até agora: síncrono, request-response (REST, gRPC, GraphQL, etc)

93

Microsserviço

Micro

serviço

Micro

serviço

Micro

serviço

Micro

serviço

Problema?

request

response

response

response

request

request

response

request

94 of 119

Arquitetura orientada a Mensagens

  • Clientes não se comunicam diretamente com servidores
  • Mas com um intermediário: fila de mensagens (ou broker de mensagens)

94

Exemplo: RabbitMQ

95 of 119

Vantagem #1: Tolerância a Falhas

  • Não existe mais mensagem: "servidor fora do ar"
  • Assumindo que a fila de mensagens roda em um servidor bastante robusto e confiável

95

96 of 119

Vantagem #2: Escalabilidade

  • Mais fácil acrescentar novos servidores

96

97 of 119

Comunicação Assíncrona

  • Comunicação entre clientes e servidores é assíncrona
  • Cria um acoplamento fraco entre clientes e servidores

97

98 of 119

Arquitetura Publish/Subscribe

98

99 of 119

Publish/Subscribe

  • "Aperfeiçoamento" de fila de mensagens
  • Mensagens são chamadas de eventos

99

100 of 119

Publish/Subscribe

  • Sistemas podem: (1) assinar eventos; (2) publicar eventos; (3) serem notificados sobre a ocorrência de eventos

100

2

1

3

Exemplo: Kafka

101 of 119

Exemplo: Sistema de Companhia Aérea

  • Evento: venda de passagem (com dados da venda)

101

Comunicação em grupo: um sistema publica eventos, n sistemas assinam e são notificados da publicação

102 of 119

Roteiro prático sobre Publish/Subscribe

https://github.com/aserg-ufmg/pub-sub-store

102

103 of 119

Outros Padrões Arquiteturais

103

104 of 119

  1. Pipes e Filtros
  • Programas são chamados de filtros e se comunicam por meio de pipes (que agem como buffers)
  • Arquitetura bastante flexível. Usada por comandos Unix.
  • Exemplo: ls | grep csv | sort

104

Filtro

Pipe

105 of 119

(2) Cliente/Servidor

  • Muito comum em serviços básicos de redes
  • Exemplos:
    • Serviço de impressão
    • Serviço de arquivos
    • Serviço Web

105

106 of 119

(3) Peer-to-Peer

  • Todo nodo pode ser cliente e/ou servidor
  • Isto é, pode ser consumidor e/ou provedor de recursos
  • Exemplo: sistemas para compartilhamento de arquivos (usando BitTorrent); Blockchain

106

107 of 119

Anti-padrões Arquiteturais

107

108 of 119

Anti-padrão

  • Modelo que não deve ser seguido
  • Revela um sistema com sérios problemas arquiteturais

108

109 of 119

Big Ball of Mud

  • Um módulo pode usar praticamente qualquer outro módulo do sistema; ou seja, sistema é uma "bagunça"

109

110 of 119

Exemplo de Remodularização

  • AntennaPod: sistema open-source para tocar podcasts
  • Android e Java

110

111 of 119

Novembro, 2020 - Big Ball of Mud (com diversas dependências circulares)

111

112 of 119

Comentários dos desenvolvedores

  • "To test the database, for example, one normally wouldn’t have to launch the full app. However, because the database basically depended on everything else, most of our tests required starting up a full Android device."

112

113 of 119

Maio, 2024

113

https://antennapod.org/blog/2024/05/modernizing-the-code-structure

114 of 119

Exercícios

114

115 of 119

  1. Qual a provável arquitetura dos seguintes sistemas? Justifique brevemente sua resposta.

(a) Microsoft Excel (versão para desktop)

(b) Nubank App (mobile)

(c) Twitter Web (front-end)

(d) Google Slides (front-end)

(e) Twitter (backend)

(f) Moodle

115

116 of 119

2. Responda sobre microsserviços:

(a) Por que uma arquitetura baseada em microsserviços oferece flexibilidade para os times colocarem seu código em produção de forma independente?

(b) Por que isso é menos viável em uma arquitetura monolítica? Ou seja, por que não é recomendável que um time, ao fazer uma modificação em um monolito, coloque-a em produção imediatamente?

(c) Por que microsserviços não devem compartilhar o mesmo BD?

116

117 of 119

3. Suponha uma empresa de streaming que deseja implementar um sistema detector de problemas de qualidade em seus vídeos (por exemplo, problemas nas legendas, no áudio, congelamento de imagens, etc). Os vídeos estão todos armazenados em um sistema de storage, isto é, em memória secundária. A empresa está avaliando duas arquiteturas:

Arquitetura #1: cada detector é um microsserviço, que recebe o nome do vídeo como parâmetro, carrega o mesmo do storage e executa um algoritmo de detecção de problemas de qualidade nesse vídeo.

Arquitetura #2: os detectores são módulos de um monolito. Então, o vídeo é carregado uma única vez do storage para a memória principal e compartilhado por todos os detectores de qualidade.

117

118 of 119

Supondo que a empresa de streaming tem milhões de clientes (ou seja, é uma empresa do porte da Amazon Prime Video) qual arquitetura você considera mais escalável? Justifique.

Observação: este exercício é baseado em um artigo do blog da Amazon Prime Video

118

119 of 119

Fim

119