Skip to content

Arquitetura de Software

Este documento descreve a arquitetura do sistema Drink Mixer, um dispositivo de preparo de bebidas controlado por uma aplicação web. O sistema permite que usuários façam pedidos de bebidas personalizadas, enquanto uma API gerencia a comunicação com o dispositivo embarcado (ESP32) por meio do protocolo MQTT, garantindo um fluxo contínuo de informações e comandos.
Esta sessão elenca todos os itens de arquitetura de software, como os componentes utilizados, sua comunicação e as tecnologias utilizadas.

Componentes

Aplicação Web (Frontend)

  • Descrição: Interface de usuário acessível via navegador, voltada para dispositivos móveis.
  • Responsabilidades:
  • Interface para escolher bebida e realizar pedido.
  • Exibição do histórico de pedidos e status de preparo.
  • Envio de solicitações HTTP para a API para gerenciar pedidos e atualizar o status dos compartimentos.

API (Backend)

  • Descrição: API desenvolvida com Next.js, que oferece endpoints para gerenciar os pedidos, realizar operações no banco de dados e gerenciar a comunicação com o broker MQTT.
  • Responsabilidades:
  • Receber e processar as requisições HTTP vindas do frontend.
  • Gerenciar os pedidos e seus respectivos status.
  • Publicar mensagens no broker MQTT para controlar o dispositivo ESP32.
  • Receber mensagens de status e alertas do ESP32 e atualizar os dados no PostgreSQL.

### Drink API

  • Descrição: API desenvolvida para receber ingredientes disponíveis e retornar uma lista de possíveis drinks que podem ser preparados.
  • Responsabilidades:
  • Receber e processar requisições HTTP contendo os ingredientes disponíveis.
  • Consultar o banco de dados de receitas para identificar drinks compatíveis.
  • Retornar uma lista com os dados dos drinks, incluindo métricas de quantidades.
  • Gerenciar dados relacionados a ingredientes e receitas no banco de dados PostgreSQL.

Banco de Dados

  • Descrição: Armazena dados de usuários, pedidos, configurações de bebidas e histórico.
  • Responsabilidades:
  • Persistir dados de usuários e administradores.
  • Registrar pedidos e status para fins de histórico e monitoramento.
  • Armazenar configurações de bebidas e disponibilidade de ingredientes.

Message Broker (Rabbit MQ)

  • Descrição: Responsável por gerenciar a comunicação entre a API e o ESP32 utilizando o protocolo MQTT.
  • Responsabilidades:
  • Receber mensagens da API e repassá-las ao ESP32.
  • Receber mensagens do ESP32 sobre o status dos pedidos e notificá-las à API.
  • Facilitar a comunicação assíncrona entre o sistema e o dispositivo embarcado.
  • Gerenciar filas de mensagens para garantir o envio e recebimento confiáveis e ordenados entre os componentes do sistema.

Dispositivo Embarcado (ESP32)

  • Descrição: Controla a execução física do preparo das bebidas.
  • Responsabilidades:
  • Receber comandos MQTT do broker para preparar as bebidas conforme o pedido.
  • Monitorar e reportar o status dos compartimentos e da máquina ao broker MQTT.
  • Notificar a API em caso de erros ou status críticos.

Metas e Restrições Arquiteturais

Metas

  • Experiência do Usuário Intuitiva e Responsiva: Oferecer uma interface web amigável e adaptada para dispositivos móveis, que facilite a interação dos usuários e administradores com o sistema.
  • Comunicação em Tempo Real: Assegurar que os comandos para o ESP32 e as notificações de status sejam transmitidos instantaneamente, proporcionando uma experiência de resposta rápida e contínua.
  • Segurança e Privacidade dos Dados: Implementar autenticação segura para usuários e administradores.
  • Facilidade de Manutenção e Expansibilidade: Estruturar o sistema de forma modular, permitindo futuras melhorias e a adição de novas funcionalidades com o mínimo de impacto na estrutura existente.
  • Alta Disponibilidade: Minimizar tempo de inatividade, garantindo que o sistema funcione de forma confiável, especialmente durante o processo de preparo das bebidas.

Restrições

  • Conectividade com a Internet: A operação do sistema depende de uma conexão de internet estável, tanto para o frontend quanto para a comunicação com o broker MQTT.
  • Compatibilidade com Dispositivos Móveis: O design da aplicação web deve ser otimizado para dispositivos móveis, garantindo usabilidade em telas pequenas.
  • Capacidade do Hardware (ESP32): A capacidade de processamento e memória do ESP32 limita a complexidade das operações que ele pode realizar. Isso impacta a escolha e a frequência das mensagens enviadas para o dispositivo.
  • Escalabilidade do Broker MQTT: Rabbit MQ deve ser dimensionado de forma a suportar o número de mensagens e conexões simultâneas esperadas, especialmente se o sistema crescer em escala.
  • Limitação de Acesso ao Banco de Dados: O PostgreSQL, sendo um banco de dados centralizado, pode ser um ponto de gargalo. A arquitetura deve garantir que as operações de leitura/escrita estejam otimizadas e que a segurança no acesso ao banco de dados seja mantida.

Diagrama de arquitetura de software

A figura abaixo apresenta a arquitetura do sistema Drink Mixer, com os componentes principais listados acima e suas interações.

3

Fonte: Diagrama de Arquitetura de Software.

Tecnologias

Aplicação Web (Frontend)

  • Next.js, com suporte para geração de páginas estáticas e rotas de API.

API (Backend)

  • Next.js (API Routes), Prisma (ORM), AMPQ (para comunicação com o broker).

Banco de Dados

  • PostgreSQL, acessado via Prisma.

Message Broker

  • Rabbit MQ com plugin para suporte MQTT

Dispositivo Embarcado

  • ESP32 com suporte ao protocolo MQTT.

Visão de caso de uso

Visão Lógica

Visão Geral

O diagrama abaixo ilustra as interações entre os atores e o sistema, destacando os principais casos de uso e as funcionalidades oferecidas. Ele demonstra como o Consumidor e o Administrador interagem com o sistema Drink Mixer, evidenciando os principais fluxos de ação, como realizar pedidos de bebidas ou gerenciar a máquina. Esse diagrama é essencial para compreender de forma visual os requisitos do sistema e sua funcionalidade central.

Diagrama de Casos de Uso

image

Atores no sistema Drink Mixer

  • Consumidor: Usuário que solicita bebidas, navega pelas opções, personaliza e confirma pedidos.
  • Administrador: Gerencia a máquina, reabastece ingredientes, resolve problemas e configura receitas.

Diagrama de Atividades

O diagrama abaixo representa os fluxos de trabalho no sistema Drink Mixer, destacando a sequência de ações realizadas pelos usuários e pelo sistema. Ele é particularmente útil para entender os passos necessários para atender a um pedido ou realizar a manutenção da máquina, além de identificar decisões críticas que afetam o comportamento do sistema.

5

Diagrama de Pacotes

No diagrama a seguir, a estrutura modular do sistema Drink Mixer é apresentada. Ele organiza os componentes do sistema em pacotes de forma hierárquica e mostra como esses pacotes relacionam entre si. Essa visão ajuda a gerenciar a complexidade do sistema e a identificar dependências entre os módulos.

image

Diagrama de Fluxo de Erros

Este diagrama descreve como o sistema Drink Mixer lida com falhas e condições inesperadas, mapeando os caminhos alternativos e as ações corretivas necessárias. Ele é crucial para entender os pontos críticos do sistema e garantir a robustez e a continuidade das operações, mesmo em cenários de falha.

image

Diagrama de Mapeamento Broker

O diagrama abaixo representa a arquitetura de comunicação utilizando o RabbitMQ como broker de mensagens, integrando o Software (Backend) e o dispositivo embarcado (ESP32) via o protocolo MQTT. Ele descreve o fluxo de mensagens entre publishers (produtores) e consumers (consumidores) por meio de filas organizadas e uma exchange central.

image

  1. Publisher (Produtores):
  2. O Software (Backend) e o dispositivo embarcado atuam como produtores de mensagens, publicando informações relevantes para a exchange do RabbitMQ.

  3. Mensagens são publicadas nos seguintes tópicos:

    • .order: Para registrar um novo pedido.
    • .ready: Indica que o embarcado está pronto para receber o próximo pedido.
    • .device: Registrar execuções do embarcado .
    • .completed: Marca a conclusão de um processo.

  4. Broker (RabbitMQ):

  5. A exchange MQTT é responsável por roteamento de mensagens para as filas apropriadas com base nas regras de roteamento definidas (bindings). As filas disponíveis são:
    • Order: Armazena novos pedidos gerados pelo Software.
    • Ready: Indica que o próximo pedido da fila Order está pronto para ser processado.
    • Device: Envia mensagens ao dispositivo embarcado para execução.
    • Completed: Armazena mensagens que indicam que o pedido foi processado e seu status(Sucesso/Falha).

  6. O RabbitMQ gerencia o roteamento e a entrega confiável das mensagens publicadas.

  7. Consumer (Consumidores):

  8. Software (Backend):
    • Subscreve às filas Order e Ready para acompanhar novos pedidos e a preparação de itens para o dispositivo.
  9. Dispositivo embarcado (ESP32):
    • Subscreve às filas Device e Completed para processar os pedidos recebidos e informar o status final ao sistema.

Diagrama de Relações filas

O diagrama apresenta a comunicação e o fluxo de mensagens entre o Software (Backend), o dispositivo embarcado (ESP32) e as filas no RabbitMQ. Cada componente interage com filas específicas para garantir que os pedidos sejam enviados, processados e os resultados retornados de maneira organizada e confiável.

image

  1. Software (Backend) → Order (Fila):

  2. O Backend publica mensagens na fila Order para registrar novos pedidos.

    • Esta fila funciona como o ponto inicial do fluxo, armazenando os pedidos ordenados até serem processados.

  3. Ready (Fila) → Software (Backend):

  4. O Backend consome mensagens da fila Ready para saber quais pedidos estão prontos para serem transferidos para a fila Device.

  5. Order (Fila) → Device (Fila):

  6. Quando o Backend recebe a confimação do Embarcado, o próximo pedido é consumido da fila Order e enviado para a fila Device.

  7. A fila Device é responsável por encaminhar os pedidos ao dispositivo embarcado para processamento.

  8. Device (Fila) → Dispositivo Embarcado (ESP32):

  9. O Embarcado consome mensagens da fila Device para processar os pedidos enviados pelo sistema.

  10. Esta comunicação assegura que o dispositivo tenha acesso apenas a pedidos que estão prontos para serem executados.

  11. Dispositivo Embarcado (ESP32) → Completed (Fila):

  12. Após processar um pedido, o Embarcado publica uma mensagem na fila Completed, indicando que o processamento foi concluído.

  13. Completed (Fila) → Software (Backend):

  14. O Backend consome mensagens da fila Completed para registrar os resultados do processamento e finalizar o ciclo.

Referências

[1]Diagrama de caso de uso UML: O que é, como fazer e exemplos: por que usar um diagrama uml? Acesso em 12 de novembro de 2024.
[2]Tudo sobre diagramas de pacotes UML Acesso em 12 de novembro de 2024.
[3]Diagrama de Pacotes: Definição, Componentes e Exemplos. Acesso em 22 de novembro de 2024
[4]O que é UML e Diagramas de Caso de Uso: Introdução Prática à UML. Acesso em 22 de novembro de 2024
[5]Error Flow Chart acesso em 24 de novembro de 2024
[6]Documentação RabbitMQ acesso em 13 de janeiro de 2025

Tabela de versionamento

Versão Data Descrição Responsável
1.0 08/11/2024 Criação do documento João Victor e Mateus Caltabiano
1.1 12/11/2024 Elaboração e Adição dos diagramas João Victor e Mateus Caltabiano
1.2 22/11/2024 Correção casos de uso e digrama de pacotes João Victor e Mateus Caltabiano
1.3 24/11/2024 Adição do diagrama de fluxo de erros João Victor e Mateus Caltabiano
1.4 25/11/2024 Refatoração textos introdutórios João Victor e Mateus Caltabiano
1.5 13/01/2024 Atualização Broker Rabbit Mq e Diagramas de fila João Victor