Arquitetura Geral da Solução

Introdução

O projeto WeDrink surge como uma resposta à crescente demanda por soluções inovadoras que ofereçam conveniência e personalização na preparação de bebidas. Este documento apresenta a arquitetura geral do sistema, proporcionando uma visão de alto nível da solução e detalhando suas principais funcionalidades e componentes.

Definição do Produto

O WeDrink é composto por dois componentes principais: uma máquina inteligente de preparo de drinks e um aplicativo web para controle e personalização dos pedidos. A máquina utiliza um ESP32 e diversos sensores para capturar dados e regular as dosagens das bebidas. O aplicativo web permite que os usuários façam pedidos personalizados, acompanhem o preparo das bebidas e interajam com o sistema de forma intuitiva.

O foco central do projeto é oferecer uma solução prática e automatizada para a preparação de drinks, permitindo que o usuário selecione, personalize e receba sua bebida de maneira eficiente e precisa.

Arquitetura Geral da Solução

A arquitetura do WeDrink é dividida em três componentes essenciais: a interface do usuário, o subsistema de controle eletrônico e o subsistema de comunicação. Esses componentes estão integrados para garantir a operação eficiente e contínua do sistema.

Interface do Usuário

Função: Proporciona uma interface intuitiva para que o usuário inicie o processo de pedido, personalize bebidas e acompanhe o progresso do preparo.

Design: A interface gráfica é desenvolvida em uma aplicação web responsiva, oferecendo feedback em tempo real sobre o status do pedido.

Subsistema de Controle Eletrônico

Função: Gerencia a lógica de controle das bombas, válvulas e sensores, regulando as dosagens das bebidas conforme o pedido realizado.

Design: Utiliza um ESP32 como controlador principal, que interage com sensores de fluxo e nível, além de controlar as válvulas e bombas peristálticas para dispensar as bebidas corretamente.

Subsistema de Comunicação

Função: Facilita a comunicação entre o sistema WeDrink (backend) e a máquina de drinks, assegurando que os comandos de preparo sejam executados corretamente e em tempo real.

Design: O subsistema é baseado no protocolo MQTT, onde a API (backend) envia comandos ao dispositivo ESP32 e recebe o status do preparo das bebidas, atualizando o sistema e o usuário conforme necessário.

Componentes Principais

Aplicação Web (Frontend)

• Descrição: Interface de usuário acessível via navegador, otimizada para dispositivos móveis.

• Responsabilidades:

• Permitir ao usuário fazer pedidos e personalizar bebidas.
• Exibir o status do pedido e o histórico de bebidas.
• Enviar comandos HTTP para a API para controlar o preparo e o status das bebidas.

API (Backend)

• Descrição: API desenvolvida para gerenciar os pedidos de bebidas, controlar o fluxo de dados e comunicar-se com o dispositivo embarcado.
• Responsabilidades:
• Processar as requisições HTTP vindas do frontend.
• Gerenciar pedidos e status.
• Controlar a comunicação com o broker MQTT para acionar o dispositivo ESP32 e receber atualizações de status.

Banco de Dados

• Descrição: Armazena informações sobre usuários, pedidos, configurações de bebidas e histórico de transações.
• Responsabilidades:
• Persistir dados de usuários e pedidos.
• Gerenciar configurações de bebidas e status.

Broker MQTT (Rabbit MQ)

• Descrição: Facilita a comunicação entre a API e o ESP32.
• Responsabilidades:
• Gerenciar o envio e recebimento de mensagens de status e comandos entre o sistema backend e o dispositivo embarcado.

Dispositivo Embarcado (ESP32)

• Descrição: Controla a execução física do preparo das bebidas.
• Responsabilidades:
• Receber comandos MQTT do broker e acionar as bombas e válvulas.
• Monitorar o status dos compartimentos e sensores, enviando informações sobre os níveis e fluxo de bebidas ao broker.

Metas e Restrições Arquiteturais

Metas

• Experiência do Usuário Intuitiva: Interface amigável, com feedback em tempo real e fácil personalização de bebidas.
• Comunicação em Tempo Real: Garantir que as solicitações e respostas sejam transmitidas instantaneamente, proporcionando uma experiência fluida.
• Escalabilidade: Estruturar a arquitetura de forma modular, permitindo a expansão do sistema no futuro com o mínimo impacto nas operações existentes.

Restrições

• Dependência de Conectividade: O sistema depende de uma conexão estável de internet para comunicação entre o frontend, a API e o dispositivo ESP32.

• Limitações de Hardware: O ESP32 possui restrições em termos de processamento e memória, o que pode impactar a complexidade de algumas operações e a quantidade de dados que pode ser processada simultaneamente.

• Capacidade do Broker MQTT: O Rabbit MQ deve ser escalado para suportar um grande número de conexões simultâneas e um alto tráfego de mensagens, garantindo que a comunicação entre os componentes do sistema permaneça eficiente.

Diagramas

Diagrama de Arquitetura Geral

Conclusão

Essa documentação da arquitetura do WeDrink oferece uma visão clara e integrada dos principais componentes e funcionalidades do sistema. Com uma interface de usuário intuitiva, um subsistema eletrônico robusto e um sistema de comunicação eficiente, o projeto visa fornecer uma solução prática e personalizada para a preparação de bebidas.

Este documento fornece uma visão abrangente do sistema, destacando suas principais funcionalidades, metas e restrições, e está alinhado com os objetivos de criar uma solução inovadora e escalável.

Referências

Aqui estão as referências organizadas sem os links, apenas com os nomes dos livros e autores:

Referências

1. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

2. Ippolito, J. (2018). Getting Started with ESP32 Development. Packt Publishing.

3. Banks, A., & Gupta, R. (2018). MQTT Essentials: A Lightweight IoT Protocol. O'Reilly Media.

4. Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books.

5. Fowler, M. (2004). Patterns of Enterprise Application Architecture. Addison-Wesley.

6. Sommerville, I. (2011). Software Engineering. Addison-Wesley.

7. Bass, L., Clements, P., & Kazman, R. (2012). Software Architecture in Practice. Addison-Wesley.

8. Pressman, R. S. (2014). Software Engineering: A Practitioner's Approach. McGraw-Hill.

9. Parnas, D. L. (1972). On the Criteria to Be Used in Decomposing Systems into Modules. Communications of the ACM.

10. Booch, G. (2007). Object-Oriented Analysis and Design with Applications. Addison-Wesley.

Tabela de Versionamento