Documento de Arquitetura de Software (DAS)

1. Introdução

1.1 Propósito

Este documento fornece uma visão geral abrangente da arquitetura do aplicativo de entregas HungryHub, usando uma série de visualizações arquiteturais diferentes para representar diferentes aspectos do sistema. Ele é destinado a capturar e transmitir as decisões arquiteturais significativas que foram tomadas no sistema. Este documento servirá como um ponto de referência para todos os envolvidos no desenvolvimento do sistema, incluindo desenvolvedores, testadores, gerentes de projeto e outros stakeholders.

1.2 Escopo

O HungryHub é um aplicativo de entregas que conecta restaurantes e entregadores a clientes que desejam receber comida em casa. O aplicativo permite que os usuários façam pedidos de comida de restaurantes locais e que entregadores façam entregas desses pedidos. O aplicativo é composto por um aplicativo móvel para clientes, um aplicativo móvel para entregadores e um aplicativo web para restaurantes. O aplicativo móvel para clientes permite que os usuários visualizem restaurantes próximos, façam pedidos de comida e acompanhem o status de seus pedidos. O aplicativo móvel para entregadores permite que os entregadores visualizem pedidos disponíveis, aceitem pedidos e entreguem pedidos. O aplicativo web para restaurantes permite que os restaurantes gerenciem seus menus, recebam pedidos e gerenciem suas entregas. O aplicativo é desenvolvido usando tecnologias modernas como React Native, Django e PostgreSQL.

A equipe de desenvolvimento é composta por alunos de Engenharia de Software do campus FCTE da Universidade de Brasília (UnB), que estão desenvolvendo o aplicativo como parte de um projeto da disciplina de Arquitetura e Desenho de Software.

1.3 Definições, Acrônimos e Abreviações

Abreviação	Definição
HungryHub	Aplicativo de entregas que conecta restaurantes e entregadores a clientes que desejam receber comida em casa.
Entregador	Pessoa que faz entregas de pedidos de comida.
Cliente	Pessoa que faz pedidos de comida.
Restaurante	Estabelecimento que vende comida.
Pedido	Solicitação de comida feita por um cliente.
Menu	Lista de comidas disponíveis em um restaurante.
React Native	Framework de desenvolvimento de aplicativos móveis.
Django	Framework de desenvolvimento web para APIs.
PostgreSQL	Sistema de gerenciamento de banco de dados relacional.

Outras definições, acrônimos e abreviações podem ser encontrados no documento dos Léxicos.

1.4 Referências

SERRANO, Milene. Estilos e Padrões Arquiteturais I. UnB, 2025. Disponível em: https://aprender3.unb.br/pluginfile.php/2928962/mod_page/content/1/Arquitetura%20e%20Desenho%20de%20Software%20-%20Aula%20Estilos%20e%20Padr%C3%B5es%20Arquiteturais%20I%20-%20Profa.%20Milene.pdf
Fulltureschool. Tudo sobre a Arquitetura em Camadas | Arquitetura de Soluções. Youtube, 2022. Disponível em: https://www.youtube.com/watch?v=doAQjr0mwdg
Tribunal Regional do Trabalho do Paraná (TRT-PR). Diretriz: Descrever a Arquitetura. TRT-PR, 2025. Disponível em: https://www.trt9.jus.br/pds/pdstrt9/guidances/guidelines/outline_the_architecture_35F1530A.html#:~:text=Identifique%20as%20metas%20arquiteturais.%20As%20metas%20arquiteturais,est%C3%A3o%20evidentes%20somente%20nos%20casos%20de%20uso
SERRANO, Milene. 05b - VideoAula - DSW-Modelagem - Diagrama de Classe - View-only. UnB, 2025. Disponível em: https://unbbr-my.sharepoint.com/personal/mileneserrano_unb_br/_layouts/15/stream.aspx?id=%2Fpersonal%2Fmileneserrano%5Funb%5Fbr%2FDocuments%2FArqDSW%20%2D%20V%C3%ADdeosOriginais%2F05h%20%2D%20VideoAula%20%2D%20DSW%2DModelagem%20%2D%20Componentes%2Emp4&ga=1&referrer=StreamWebApp%2EWeb&referrerScenario=AddressBarCopied%2Eview%2Eee59e527%2D0649%2D48e1%2D9f8b%2D49e43aec547c
SERRANO, Milene. 05b - VideoAula - DSW-Modelagem - Diagrama de Classe - View-only. UnB, 2025. Disponível em: https://unbbr-my.sharepoint.com/personal/mileneserrano_unb_br/_layouts/15/stream.aspx?id=%2Fpersonal%2Fmileneserrano%5Funb%5Fbr%2FDocuments%2FArqDSW%20%2D%20V%C3%ADdeosOriginais%2F05b%20%2D%20VideoAula%20%2D%20DSW%2DModelagem%20%2D%20Diagrama%20de%20Classe%2Emp4&ga=1&referrer=StreamWebApp%2EWeb&referrerScenario=AddressBarCopied%2Eview%2E6c0ba26e%2Dfd12%2D451b%2Da5f6%2D9f15f468f0fd
Tribunal Regional do Trabalho do Paraná (TRT-PR). Diretriz: Visão Arquitetural. TRT-PR, 2025. Disponível em: https://www.trt9.jus.br/pds/pdstrt9/guidances/guidelines/architectural_view_FF6EDA37.html#:~:text=Vis%C3%A3o%20de%20Implementa%C3%A7%C3%A3o:%20Descreve%20como,uso%20das%20Vis%C3%B5es%204+1.
Instituto Infnet. Principais visões em arquitetura de software. Infnet, 2017. Disponível em: https://blog.infnet.com.br/arquitetura_software/principais-visoes-em-arquitetura-de-software/#:~:text=3.,conformidade%20com%20as%20regulamenta%C3%A7%C3%B5es%20vigentes

1.5 Visão Geral

O restante deste documento está organizado da seguinte forma, buscando conter os detalhes sobre as características arquiteturais escolhidas pela equipe de desenvolvimento:

Representação Arquitetural: Descreve a arquitetura do sistema e como ela é representada.
Metas e Restrições de Arquitetura: Descreve as metas e restrições arquiteturais do sistema.
Visão Lógica: Descreve a decomposição do sistema em subsistemas e pacotes.
Visão de Casos de Uso: Descreve a decomposição do sistema em processos.
Visão de Processo: Descreve a arquitetura de implantação do sistema.
Visão de Implementação: Descreve a estrutura de implementação do sistema.
Visão de Dados: Descreve a perspectiva de armazenamento de dados do sistema.

2. Representação Arquitetural

A arquitetura lógica do aplicativo segue uma abordagem modular e em camadas, com o objetivo de separar as responsabilidades e facilitar a manutenção e evolução do sistema. A arquitetura é baseada no padrão de arquitetura de software MVC (Model-View-Controller), que é um padrão de projeto de software que separa a representação da informação da interação do usuário com ela. O Django, framework web utilizado no projeto, segue esse padrão, facilitando a implementação e manutenção do sistema.

2.1 Arquitetura em Camadas

A arquitetura em camadas divide o sistema em camadas lógicas que são responsáveis por diferentes aspectos do sistema. Cada camada tem um propósito específico e responsabilidades bem definidas, garantindo a separação de interesses e facilitando a manutenção e evolução do sistema. A arquitetura em camadas é uma abordagem comum em sistemas web, pois permite a escalabilidade, reutilização de código e facilidade de manutenção. [SERRANO, Milene, 2024]

arq-camadas

Figura 01 - Representação da arquitetura em camadas. [Fulltureschool, 2022]

2.2 Arquitetura MVC

O Model-View-Controller (MVC) é um padrão de arquitetura de software que separa a representação da informação da interação do usuário com ela. O Model é a representação dos dados e a lógica de negócios do sistema, o View é a camada de apresentação, responsável por exibir os dados ao usuário, e o Controller é a camada de controle, responsável por receber as requisições do usuário, processar as informações e retornar a resposta adequada. [SERRANO, Milene, 2025]

mvc

Figura 02 - Visualização do Padrão Arquitetural - MVC. [SERRANO, Milene, 2025]

No contexto do projeto, as camadas Model e Controller serão implementadas no backend do sistema, utilizando o Django, enquanto a View será implementada utilizando o React Native no frontend do sistema. Assim como representado na tabela a seguir:

Tabela - Representação da Arquitetura MVC

Camada	Tecnologia	Descrição
Model	Django	Representação dos dados e lógica de negócios do sistema
View	React Native	Camada de apresentação, responsável por exibir os dados ao usuário
Controller	Django	Camada de controle, responsável por receber as requisições do usuário, processar as informações e retornar a resposta adequada

2.3 Representação Visual

A arquitetura do sistema é representada visualmente pelas seguintes visualizações arquiteturais:

Visão Lógica: Representação da estrutura lógica do sistema, incluindo a decomposição em subsistemas e pacotes, contendo os diagramas de componentes, classes e componentes do front-end.
Visão de Casos de Uso: Representação dos casos de uso do sistema, incluindo a decomposição em processos, contendo os diagramas de casos de uso gerais, casos de uso do cliente, entregador e restaurante.
Visão de Processo: Representação da arquitetura de implantação do sistema, incluindo a mapeamento de processos em processadores, threads e sincronização, e os diagramas de atividades, estados e sequência.
Visão de Implementação: Representação da estrutura de implementação do sistema, incluindo a decomposição em camadas e subsistemas, contendo os diagramas de implementação, estrutura modular do código, dependências, padrões de design e configuração de ambiente.
Visão de Dados: Representação da estrutura de dados do sistema, incluindo o modelo relacional e o repositório de dados.

3. Metas e Restrições de Arquitetura

As metas e restricões de arquitetura são fundamentais para o projeto, pois definem os objetivos que a arquitetura do sistema deve atender e as restrições que devem ser consideradas durante o desenvolvimento do sistema. As metas de arquitetura ajudam a garantir que a arquitetura do sistema atenda aos requisitos de negócios e de qualidade, enquanto as restrições de arquitetura ajudam a garantir que a arquitetura do sistema seja consistente e viável. Portanto, é importante identificar e documentar as metas e restrições de arquitetura para orientar o desenvolvimento do sistema e garantir que a arquitetura atenda aos requisitos e expectativas dos stakeholders. [TRTPR, 2025]

3.1 Metas de Arquitetura

As metas de arquitetura definem os objetivos que a arquitetura do sistema deve atender. Um documento Especificação Suplementar foi criado para detalhar algumas das principais metas, requisitos não-funcionais e outros aspectos críticos do sistema, utilizando o modelo FURPS+. O documento com suas respectivas rastreabilidades pode ser encontrado aqui.

3.2 Restrições de Arquitetura

Meta/Restrição	Descrição	Ferramenta	Rastreabilidade
Linguagens	A restrição de linguagem define quais linguagens deverão ser utilizadas no desenvolvimento do sistema.	Python, TypeScript	R58, R59
Frameworks	A restrição de frameworks define quais frameworks serão utilizados no desenvolvimento do sistema de acordo com as linguagens escolhidas.	Django, React Native	R58, R59
Banco de Dados	A restrição de banco de dados define qual banco de dados será utilizado para armazenar os dados do sistema e implementar a camada de persistência.	PostgreSQL, SQLite	R57
Plataformas	Define as plataformas nas quais o sistema terá suporte.	Android, iOS, Web	R54
Segurança	Define as medidas de segurança que devem ser implementadas no sistema.	Autenticação, Autorização, Criptografia	Especificação Suplementar - CR01, CR02, CR06
Padrões de Comunicação	Define os padrões de comunicação que devem ser utilizados no sistema.	REST API, JSON	Especificação Suplementar - RD04

Autores: Felipe Amorim de Araújo

4. Visão Lógica

4.1 Diagrama de Componentes

O diagrama de componentes é uma representação visual da arquitetura de software que mostra a estrutura e as dependências entre os componentes do sistema. [SERRANO, Milene, 2025]

diagrama-componentes

Figura 03 - Diagrama de Componentes do HungryHub (Versão simplificada)

Autores: Felipe Amorim de Araújo

O diagrama representa os principais componentes do sistema, incluindo a separação dos aplicativos HungryHub, HungryHub Delivery e HungryHub Business.

4.1.1 Tabela de Elementos

Elemento	Tipo	Descrição
HungryHub	Pacote	Aplicativo principal do HungryHub dedicado aos usuários interessados em encontrar restaurantes e realizar pedidos
HungryHub Delivery	Pacote	Aplicativo do HungryHub dedicado aos entregadores que realizam a entrega dos pedidos
HungryHub Business	Pacote	Aplicativo do HungryHub dedicado aos restaurantes e estabelecimentos que desejam gerenciar seus pedidos e cardápios
Backend (Django)	Pacote	Camada de controle do sistema, responsável por receber as requisições do usuário, processar as informações e retornar a resposta adequada
Database (PostgreSQL)	Pacote	Banco de dados relacional utilizado para armazenar e gerenciar os dados do sistema
External Services	Pacote	Serviços externos utilizados pelo sistema, como serviços de geolocalização e pagamento
User Interface (UI)	Componente	Interface do usuário, responsável por exibir as informações ao usuário e receber as interações do usuário do aplicativo específico
API Client	Componente	Interface utilizada pela camada da interface do usuário para se comunicar com a camada de controle do sistema
API Gateway	Componente	Interface disponibilizada pela camada de controle do sistema para se comunicar com a camada de interface do usuário
Authentication Service	Componente	Serviço de autenticação utilizado para autenticar usuários e garantir a segurança do sistema
Order Service	Componente	Serviço de pedidos utilizado para gerenciar os pedidos realizados pelos usuários
Notification Service	Componente	Serviço de notificação utilizado para enviar notificações aos usuários sobre o status dos pedidos
Delivery Service	Componente	Serviço de entrega utilizado para gerenciar as entregas dos pedidos realizados pelos usuários
Database	Componente	Banco de dados relacional utilizado para armazenar e gerenciar os dados do sistema
Payment Gateway	Componente	Serviço de pagamento utilizado para processar os pagamentos dos pedidos realizados pelos usuários
Map Service	Componente	Serviço de geolocalização utilizado para exibir a localização dos restaurantes e entregadores aos usuários

Autores: Felipe Amorim de Araújo

4.1.2 Tabela de Relacionamentos

Relacionamento	Descrição
User Interface (UI) -> API Client	A interface do usuário se comunica com a camada de controle do sistema por meio de uma API Client
API Client -> API Gateway	A API Client se comunica com a API Gateway para acessar os serviços disponibilizados pela camada de controle do sistema
API Gateway -> Authentication Service	A API Gateway se comunica com o serviço de autenticação para autenticar os usuários e garantir a segurança do sistema
API Gateway -> Order Service	A API Gateway se comunica com o serviço de pedidos para gerenciar os pedidos realizados pelos usuários
API Gateway -> Notification Service	A API Gateway se comunica com o serviço de notificação para enviar notificações aos usuários sobre o status dos pedidos
API Gateway -> Delivery Service	A API Gateway se comunica com o serviço de entrega para gerenciar as entregas dos pedidos realizados pelos usuários
Authentication Service -> Database	O serviço de autenticação acessa o banco de dados para autenticar os usuários
Order Service -> Database	O serviço de pedidos acessa o banco de dados para gerenciar os pedidos realizados pelos usuários
Notification Service -> Database	O serviço de notificação acessa o banco de dados para enviar notificações aos usuários
Delivery Service -> Database	O serviço de entrega acessa o banco de dados para gerenciar as entregas dos pedidos realizados pelos usuários
Order Service -> Payment Gateway	O serviço de pedidos se comunica com o serviço de pagamento para processar os pagamentos dos pedidos realizados pelos usuários
Delivery Service -> Map Service	O serviço de entrega se comunica com o serviço de geolocalização para exibir a localização dos restaurantes e entregadores aos usuários

Autores: Felipe Amorim de Araújo

4.2 Diagrama de Classes

O diagrama de classes é uma representação visual da estrutura e das relações entre as classes do sistema. Ele mostra as classes do sistema, seus atributos, métodos e as relações entre elas. O diagrama de classes é uma ferramenta importante para a modelagem de sistemas orientados a objetos, pois permite visualizar a estrutura do sistema e identificar as classes e suas relações. [SERRANO, Milene, 2025]

diagrama-classes

Figura 04 - Diagrama de Classes

Autores: Bruno Cunha Vasconcelos de Araújo, Davi Gonçalves Akegawa Pierre, Gabryel Nicolas Soares de Sousa, Júlio Roberto da Silva Neto, Lucas Martins Gabriel, Raquel Ferreira Andrade e Wolfgang Friedrich Stein

O documento completo do diagrama de classes pode ser encontrado na documentação da entrega 02 do projeto aqui.

4.3 Diagrama de Componentes (FRONT-END)

O diagrama de componentes do front-end é uma representação visual da arquitetura de software do front-end do sistema, mostrando os principais componentes e suas interações. Ele é útil para entender a estrutura do front-end, identificar os componentes principais e suas dependências. Ele foi criado como uma adaptação de um diagrama de componentes comum, para representar a arquitetura do React Native, que é a tecnologia utilizada no front-end do HungryHub.

diagrama-componentes

Figura 05 - Diagrama de Classes

Autores: Felipe Amorim de Araújo, Leonardo Sobrinho de Aguiar, Guilherme Westphall de Queiroz, Guilherme Silva Dutra, Kallyne Macedo Passos, Kauan de Torres Eiras

O documento completo do diagrama de componentes do front-end com mais detalhes sobre metodologia, abordagem e tecnologias utilizadas pode ser encontrado na documentação da entrega 02 do projeto aqui.

5. Visão de Casos de Uso

Diagrama de Casos de Uso - Geral

O diagrama de casos de uso geral representa uma visão mais abragente do sistema destacando os principais atores (Cliente, Entregador, Loja, Serviço de Pagamentos) e suas interações com as funcionalidades oferecidas que pode ser visualizado na imagem a seguir

casos-de-uso-geral

Figura 06 - Diagrama de Casos de Uso Geral

Segue Link da Entrega anterior, onde é possivel ver os detalhes do diagrama de casos de uso
Casos de uso geral

Diagrama de Casos de Uso - Cliente

O diagrama de casos de uso do Cliente representa uma visão mais focada nas interações do Cliente com o sistem, este diagrama detalha as funcionalidades disponíveis para o usuário final que pode ser visualizado na imagem a seguir

casos-de-uso-cliente

Figura 07 - Diagrama de Casos de Uso Geral

Segue Link da Entrega anterior, onde é possivel ver os detalhes do diagrama de casos de uso
Casos de uso cliente

Diagrama de Casos de Uso - Entregador

O diagrama de casos de uso do Entregador representa uma visão mais focada nas interações do Cliente com o sistema que pode ser visualizado na imagem a seguir

casos-de-uso-entregador

Figura 08 - Diagrama de Casos de Uso do Entregador

Segue Link da Entrega anterior, onde é possivel ver os detalhes do diagrama de casos de uso
Casos de uso entregador

Diagrama de Casos de Uso - Restaurante

O diagrama de casos de uso do Cliente representa uma visão mais focada nas interações do Cliente dentro do sistema. este diagrama deetalha as funcionalidades e pode ser visualizado na imagem a seguir

casos-de-uso-restaurante

Figura 09 - Diagrama de Casos de Uso do Restaurante

Segue Link da Entrega anterior, onde é possivel ver os detalhes do diagrama de casos de uso
Casos de uso restaurante

6. Visão de Processo

6.1 Diagrama de Atividades

O Diagrama de Atividades representa o fluxo de atividades dentro do sistema, focando nos processos e regras de negócio que pode ser visualizado a seguir

Cadastro de Usuário

diagrama-de-atividades

Figura 10 - Diagrama de Atividades - Cadastro de Usuário

Loja cadastra cardápio

diagrama-de-atividades

Figura 11 - Diagrama de Atividades - Loja cadastra cardápio

Cliente realiza pedido

diagrama-de-atividades

Figura 12 - Diagrama de Atividades - Cliente realiza pedido

Loja recebe pedido

diagrama-de-atividades

Figura 13 - Diagrama de Atividades - Loja recebe pedido

Entregador recebe solicitação de entrega

diagrama-de-atividades

Figura 14 - Diagrama de Atividades - Entregador recebe solicitação de entrega

Cliente avalia Entregador e Loja

diagrama-de-atividades

Figura 15 - Diagrama de Atividades - Cliente avalia Entregador e Loja

Cliente inicia suporte via chat

diagrama-de-atividades

Figura 16 - Diagrama de Atividades - Cliente inicia suporte via chat

Segue Link da Entrega anterior, onde é possivel ver os detalhes dos diagramas de atividades
Diagrama de atividades

6.2 Diagrama de Estados

O Diagrama de Estados representa os diferentes estados de um objeto dentro do sistema e as transições entre eles. Ele é útil para modelar o comportamento dinâmico de um objeto ao longo de seu ciclo de vida que pode ser visualizado a seguir

Diagrama de Estados - Visão Geral

diagrama-de-estados

Figura 16 - Diagrama de Estados - Visão Geral

Autores: Bruno Araújo, Wolfgang Friedrich Stein

Segue Link da Entrega anterior, onde é possivel ver os detalhes dos diagramas de estados
Diagrama de estados

Diagrama de Sequencias

O Diagrama de Sequência modela a interação entre objetos ao longo do tempo, detalhando a troca de mensagens entre eles que pode ser visualizado a seguir

Solicitação de Pedido

diagrama-de-sequencias

Figura 17 - Diagrama de Sequência - Solicitação de Pedido

Cadastro de Usuário

diagrama-de-sequencias

Figura 18 - Diagrama de Sequência - Cadastro de Usuário

diagrama-de-sequencias

Figura 19 - Diagrama de Sequência - Login

Logout

diagrama-de-sequencias

Figura 20 - Diagrama de Sequência - Logout

Editar conta

diagrama-de-sequencias

Figura 21 - Diagrama de Sequência - Editar conta

Cadastro método de pagamento

diagrama-de-sequencias

Figura 22 - Diagrama de Sequência - Cadastro método de pagamento

Segue Link da Entrega anterior, onde é possivel ver os detalhes dos diagramas de sequencias
Diagrama de sequencias

7. Visão de Implementação

A visão de implementação detalha a estrutura de implementação do sistema, incluindo a decomposição em camadas e subsistemas, os padrões de design utilizados, a estrutura modular do código, as dependências entre os componentes e a configuração do ambiente de desenvolvimento. A visão de implementação é essencial para garantir que a arquitetura do sistema seja implementada de acordo com as decisões arquiteturais tomadas e que o código seja organizado, modular e reutilizável. [TRTPR, 2025]

7.1 Estrutura do Código Fonte

A estrutura do código fonte é a organização dos arquivos e diretórios do sistema, que reflete a arquitetura do sistema e facilita a manutenção e evolução do código. O nosso repositório do projeto está estruturado da seguinte forma:

📂 docs/                               # Documentação do projeto
📂 src/                             # Código fonte do projeto
  📂 HungryHub.2024.2-Back/         # Backend do sistema (Django)
    📂app/
      __init__.py
      asgi.py
      settings.py
      urls.py
      wsgi.py
    📂 hungryhub/
      📂 migrations/
      📂 views/
      __init__.py
      admin.py
      apps.py
      models.py
      tests.py
      signals.py
      permissions.py
    manage.py
    requirements.txt
  📂 HungryHub.2024.2-Front            # Frontend do sistema (React Native)
    📂 hungryhub/                   # Aplicativo principal
      📂 assets/                    
      📂 src/                       # Diretório principal
        📂 api/                     # Serviços da API
        📂 components/              # Componentes reutilizáveis
        📂 app/                     # Páginas e navegação
        📂 context/                 # Estados globais e contextos
        📂 interfaces/              # Interfaces do Typescript
        📂 utils/                   # Funções auxiliares
      app.json
      index.js
      package.json
      tsconfig.json

Autores: Felipe Amorim de Araújo

A estrutura pode ser visualizada de forma mais detalhada no repositório do projeto aqui

7.2 Dependências

As dependências do sistema são as bibliotecas, frameworks e ferramentas utilizadas no desenvolvimento do sistema. As dependências são essenciais para o funcionamento do sistema e devem ser gerenciadas de forma eficiente para garantir a compatibilidade e a estabilidade do sistema. As principais dependências em termos de frameworks do sistema são:

Django: Framework web utilizado no backend do sistema para desenvolver APIs RESTful.
React Native: Framework de desenvolvimento de aplicativos móveis utilizado no frontend do sistema para desenvolver aplicativos móveis multiplataforma.
PostgreSQL: Sistema de gerenciamento de banco de dados relacional utilizado para armazenar e gerenciar os dados do sistema.

Além disso, o sistema utiliza outras dependências, como bibliotecas de terceiros, ferramentas de desenvolvimento e serviços externos. Alguns diagramas foram criados utilizando o Graphviz para visualizar as dependências do sistema:

django-dependencias

Figura 23 - Diagrama de Dependências do Backend do HungryHub

Autores: Felipe Amorim de Araújo

react-native-dependencias

Figura 24 - Diagrama de Dependências do Backend do HungryHub

Autores: Felipe Amorim de Araújo

Observação: Abra as imagens em uma nova aba para visualizar em tamanho completo, o formato atual dificulta a visualização por conta forma que a ferramenta gera elas

É possível encontrar mais informações sobre as dependências do projeto no arquivo no Insight de Dependencies Graph no GitHub do projeto aqui

7.3 Padrões de Design

Os padrões de design são soluções reutilizáveis para problemas comuns de design de software. Eles ajudam a organizar o código, torná-lo mais legível e manutenível, e promover a reutilização de código. Os padrões de design são uma parte importante da arquitetura de software, pois ajudam a garantir que o código seja organizado, modular e reutilizável. Alguns dos padrões de design utilizados no sistema podem ser encontrados nos documentos da entrega 03 aqui.

7.4 Configuração de Ambiente

A configuração de ambiente é a preparação do ambiente de desenvolvimento para o desenvolvimento, teste e implantação do sistema. A configuração do ambiente inclui a instalação de ferramentas, bibliotecas e dependências necessárias, a configuração de variáveis de ambiente e a configuração de serviços externos. A configuração do ambiente é essencial para garantir que o sistema seja desenvolvido e implantado de forma eficiente e consistente.

O documento markdown com a configuração do ambiente pode ser encontrado na documentação da entrega 03 do projeto aqui

Ele detalha a configuração do ambiente virtual do Python, a instalação das dependências do projeto, a configuração do ambiente de desenvolvimento do React Native e do Expo (biblioteca).

8. Visão de Dados

A visão de dados é uma visão arquitetural que descreve a estrutura dos dados que são utilizados pelo sistema, bem como a forma como esses dados são armazedos, acessados, modificados, transferidos e gerenciados atendendo os requisitos funcionais e não funcionais do sistema. É essencial para a compreensão da arquitetura do sistema garantindo consistência, integridade, segurança e desempenho das operações de manipulação de dados. [Instituto Infnet 2025]

8.1 Diagrama de Modelo Relacional

Para a representação do modelo relacional, foi utilizado o diagrama de entidade-relacionamento (DER) que é uma técnica para modelar dados em um sistema de banco de dados. O DER é uma coleção de entidades e relacionamentos entre entidades. Uma entidade é uma classe de objetos. Normalmente, uma entidade corresponde a uma tabela em um banco de dados, e um objeto corresponde a uma linha na tabela. [[Lucidchart 2025]](https://www.lucidchart.com/pages/pt/o-que-e-diagrama-entidade-relacionamento#:~:text=Um%20diagrama%20entidade%20relacionamento%20(ER,si%20dentro%20de%20um%20sistema.)

diagrama-entidade-relacionamento

Figura 25 - Diagrama de Modelo Relacional ou Diagrama de Entidade-Relacionamento (DER) do HungryHub

Autores: Júlio Roberto da Silva Neto, Kallyne Macedo Passos, Wolfgang Friedrich Stein

Este artefato também pode ser encontrado na documentação da entrega 02 do projeto com mais detalhes aqui.

8.2 Repositório de Dados

O HungryHub armazena e gerencia os dados do sistema em um banco de dados relacional PostgreSQL, garantindo a integridade, segurança e desempenho das operações de manipulação de dados. O banco PostgreSQL é utilizado em produção, devido a sua robustez, confiabilidade e suporte a transações ACID e a escalabilidade para lidar com grandes volumes de dados.

Para o ambiente de desenvolvimento local, é utilizado o banco de dados SQLite, que é um banco de dados relacional embutido, leve e de fácil configuração, permitindo a criação de um banco de dados local para testes e desenvolvimento sem necessidade de uma infraestrutura complexa. Essa abordagem facilita a iteração rápida no desenvolvimento, garantindo que os dados sejam compatíveis entre os dois ambientes. O próprio Django, framework utilizado no projeto, possui suporte nativo ao SQLite.

repositorio-dados

Figura 26 - Ambientes de repositório de dados

Autores: Felipe Amorim de Araújo

Tabela X - Repositório de Dados

Tecnologia	Contexto de Uso	Rastrabilidade
PostgreSQL	Banco de Dados Relacional utilizado em ambiente de produção	Baseline - R57, Brainstorming - RNF24, Documento de Brainstorming
SQLite	Banco de Dados Relacional nativo do Django utilizado para ambiente de desenvolvimento, permitindo a execução de testes e verificações locais	Baseline - R58, Brainstorming - RNF23, Documento de Brainstorming

Histórico de Versões

Versão	Data da alteração	Comentário	Autor(es)	Revisor(es)	Data de revisão
1.0	23/01/2025	Criação do documento	Felipe Amorim de Araújo	Gabryel Nicolas S de Sousa	03/02/2025
1.1	28/01/2025	Tópicos 1.1, 1.2 e 1.3	Felipe Amorim de Araújo	Gabryel Nicolas S de Sousa	03/02/2025
1.2	31/01/2025	Adição dos diagramas de caso de uso	Felipe Amorim de Araújo	Gabryel Nicolas S de Sousa	03/02/2025
1.3	31/01/2025	Adição do diagrama de modelo relacional	Felipe Amorim de Araújo	Gabryel Nicolas S de Sousa	03/02/2025
1.4	02/02/2025	Adição da seção de repositório de dados	Felipe Amorim de Araújo	Gabryel Nicolas S de Sousa	03/02/2025
1.5	02/02/2025	Adição da visão lógica	Felipe Amorim de Araújo	Gabryel Nicolas S de Sousa	03/02/2025
1.6	02/02/2025	Criando seção de metas e restrições arquiteturais	Felipe Amorim de Araújo	Gabryel Nicolas S de Sousa	03/02/2025
1.7	03/02/2025	Finalizando introdução	Felipe Amorim de Araújo	Gabryel Nicolas S de Sousa	03/02/2025
1.8	03/02/2025	Adiciona Visao de Processos (diagramas, textos e links)	Gabryel Nicolas S de Sousa	Felipe Amorim de Araújo	03/02/2025
1.9	03/02/2025	Adição dos textos dos diagramas de caso de uso e links da entrega anteior	Gabryel Nicolas S de Sousa	Felipe Amorim de Araújo	03/02/2025