Skip to content

Arquitetura do Projeto

Definições

O sistema seguirá uma arquitetura baseada no padrão MVC (Model-View-Controller). Esta escolha foi feita pelo grupo considerando a necessidade de separar claramente a lógica de negócios (Modelo), a interface do usuário (Visão) e o fluxo de aplicação (Controlador). A arquitetura MVC facilita a manutenção, escalabilidade e permite que diferentes componentes do sistema sejam desenvolvidos e atualizados de forma independente.

Justificação sua escolha

A escolha pela arquitetura MVC para o sistema VEGA foi fundamentada em diversos aspectos destacados nos documentos de Visão do Produto e Projeto e Declaração de Escopo do Produto. Seguem as principais justificativas:

Separação de Responsabilidades:

Conforme descrito no documento de Visão do Produto e Projeto, o sistema VEGA necessita de uma abordagem que permita uma clara separação de responsabilidades entre a interface do usuário, a lógica de negócios e o controle do fluxo de aplicação. O padrão MVC atende a essa necessidade ao dividir a aplicação em três componentes distintos, facilitando a manutenção e a evolução do sistema.

2. Facilidade de Manutenção e Escalabilidade

A arquitetura MVC facilita a manutenção do sistema ao permitir que desenvolvedores trabalhem em diferentes partes da aplicação de forma independente. Por exemplo, alterações na interface do usuário (Visão) não afetam diretamente a lógica de negócios (Modelo) e vice-versa. Isso é crucial para um sistema como o VEGA, que deve se adaptar rapidamente às mudanças nas necessidades dos restaurantes, conforme mencionado na seção 1.3 dos documentos fornecidos.

3. Reutilização de Componentes

O uso do padrão MVC permite a reutilização de componentes, o que é particularmente importante para o VEGA, que precisa ser altamente customizável para diferentes tipos de restaurantes. A modularidade do MVC facilita a implementação de novas funcionalidades sem impactar negativamente o restante do sistema.

4.Adaptação a Mudanças:

A metodologia ágil, destacada como parte central do desenvolvimento do VEGA, se beneficia da flexibilidade proporcionada pelo MVC. Alterações e novas funcionalidades podem ser integradas de forma mais eficiente e com menor risco de introduzir erros em outras partes do sistema.

5. Compatibilidade com Tecnologias Utilizadas:

O documento de Declaração de Escopo do Produto indica o uso de tecnologias como HTML, CSS, JavaScript, Python e frameworks como Django, que naturalmente suportam e são otimizados para a implementação do padrão MVC. Isso garante que a equipe de desenvolvimento possa utilizar as melhores práticas e ferramentas disponíveis para construir um sistema robusto e escalável.

Detalhamento

Neste esquema, o usuário faz uma requisição de um dado ou de uma função. Essa requisição vai para o controller, que executa a função e irá até o model, responsável pelo banco de dados, coletar as informações requisitadas. Uma vez coletados os dados, eles são processados pelo controller e enviados para a view para serem apresentados ao usuário. Ou seja:

Sobre

  1. Usuário -> View: Usuário faz uma requisição.
  2. View -> Controller: View envia a requisição para o Controller.
  3. Controller -> Model: Controller solicita dados ao Model.
  4. Model -> Banco de Dados: Model acessa e coleta dados do banco de dados.
  5. Model -> Controller: Model retorna os dados para o Controller
  6. Controller -> View: Controller processa e envia os dados para a View.
  7. View -> Usuário: View apresenta os dados ao usuário.

Metas e restrições arquiteturais

  • Usabilidade, o sistema deve ser agil de ser utilizado
  • Responsabilidade, a cardápio deverá ser responsivo para diferentes tipos de telas
  • Segurança, o sistema deve ser seguro, uma vez que armazena dado confidenciais do funcionários e clientes
  • Escalabilidade, o software de ser fácil processo evolutivo
  • Manutenibilidade, o software deve ter fácil manutenção

Visão de Casos de uso

Sobre

Nosso produto visa facilitar e ajudar a gerenciar esse fluxo de atendimento para o restaurante, e assim melhorando o atendimento do cliente do restaurante, tendo mais agilidade e também mais comodidade para o restaurante poder gerenciar.

Na primeira etapa o cliente faz o pedido para o garçom o garçom anota e comanda o pedido e assim o sistema vai identificar de onde é cada pedido e enviar para os setores corretos, após a confecção dos pedidos e o cumim leva o pedido para o garçom e assim o garçom serve a mesa com os pedido feitos pelos clientes.

Visão lógica

O sistema é subdividido nos seguintes módulos:

  • Módulo de Gerenciamento de Funcionários
  • Módulo de Gerenciamento de Mesas
  • Módulo de Pedidos
  • Módulo de Estoque de Cozinha
  • Módulo de Banco de Dados

Razão Lógica de Cada Módulo:

  1. Módulo de Gerenciamento de Funcionários
    • Propósito: Gerenciar informações e funções dos funcionários (gerentes, garçons, cozinheiros).
    • Funções: Cadastro de funcionários, atualização de informações, controle de acesso
  2. Módulo de Gerenciamento de Mesas
    • Propósito: Gerenciar a alocação e estado das mesas do restaurante
    • Funções: Reserva de mesas, atualização de estado (disponível, ocupada, reservada).
  3. Módulo de Pedidos
    • Propósito: Gerenciar os pedidos realizados pelos clientes
    • Funções: Criação de pedidos, atualização de status, associação com mesas
  4. Módulo de Estoque de Cozinha
    • Propósito: Gerenciar o estoque de ingredientes e materiais necessários para a cozinha
    • Funções: Cadastro de itens, controle de quantidades, atualização de estoqu
  5. Módulo de Banco de Dados
    • Propósito: Persistência e recuperação de dados para todos os outros módulos.
    • Funções: Operações de CRUD (Create, Read, Update, Delete) para funcionários, mesas, pedidos, e estoque.

Comunicação entre os Módulos - Interfaces:

  • API de Funcionários: Interface para operações de gerenciamento de funcionários.
  • API de Mesas: Interface para operações de gerenciamento de mesas.
  • API de Pedidos: Interface para operações de gerenciamento de pedidos.
  • API de Estoque: Interface para operações de gerenciamento de estoque.
  • API de Banco de Dados: Interface para persistência e recuperação de dados

Diagrama de Estados da Aplicação

  • O diagrama de estados mostra os diferentes estados pelos quais um pedido pode passar durante seu ciclo de vida no sistema. Este diagrama é essencial para entender as transições de estado e como os pedidos são processados.

    • Exemplificando:

    • Novo Pedido: Estado inicial quando um pedido é criado.
    • Em Preparação: O pedido está sendo preparado pelo cozinheiro
    • Pronto para Servir: O pedido está pronto e aguardando ser servido.
    • Aguardando Servir: O pedido está pronto e aguardando o garçom para ser levado à mesa.
    • Servido: O pedido foi servido ao cliente.
    • Concluído: O pedido foi consumido e o processo está encerrado.

    Sobre

    diagrama de atividades da aplicação

    Diagrama de Classes

    Sobre

  • Nesse diagrama de classes, é possível ver três classes: cozinheiro, gerente e garçom. Essas classes se relacionam através da herança com a classe abstrata pai chamada Funcionário. Essa classe abstrata se relaciona com a classe BancoDeDados, que, por sua vez, salva todas as informações dos funcionários e da classe Estoque. Além disso, a classe Garçom se relaciona com a classe Mesa, que é relacionada a um cliente e guarda uma lista de pedidos feitos. Por fim, essa classe se relaciona com a classe Pedidos

    • Sobre

    Visão de Implantação

    Para a implementação não será necessário um hardware muito potente já que o sistema irá funcionar basicamente no servidor, que será feito a requisição e voltará os dados necessários para que o usuário consiga utilizar a interface para o usuários, sendo ele o garçom, gerente ou o local que será feito o preparo dos pratos.

    o sistema irá precisar basicamente de um terminal onde se possa ser feito a requisição e logo o poderá ser acessado com o mouse e teclado e ver tudo através do monitor, como banco de será utilizado o MySQL á que mais simples para fazer a integração de maneira mais viável, será utilizado também Python já possui diversas bibliotecas que podem ser implementadas e assim ajudando melhor no funcionamento do sistema no geral, isso no back-end, á para o front end será utilizado HTML, Flutter, CSS e JavaScript já que são linguagem já conhecidas pelos integrantes do grupo e também possui bibliotecas com diversas funcionalidades.

    Restrições adicionais

    Para garantir que o sistema funcione de maneira eficiente e atenda às necessidades do negócio e dos usuários, algumas restrições adicionais são necessárias. Estas restrições estão relacionadas a aspectos negociais e de qualidade de software.São elas:

    • Autenticação de Usuário:
      • Descrição: Todos os usuários devem se autenticar utilizando um login e uma senha antes de acessar o sistema.
      • Justificativa: A autenticação garante que somente usuários autorizados, como gerentes, garçons e cozinheiros, possam acessar e modificar informações relevantes. Isso evita acessos não autorizados e protege os dados.
    • Suporte para Múltiplos Usuários Concomitantemente:
      • Descrição: O sistema deve suportar até múltiplos usuários logados ao mesmo tempo
      • Justificativa: Restaurantes podem ter vários funcionários trabalhando simultaneamente e vários clientes acessando o cardápio e realizando o pedido, e o sistema deve ser capaz de suportar essa carga para garantir a eficiência das operações
    • Usabilidade
      • Descrição: O software deve ser intuitivo e fácil de usar para todos os funcionários e clientes, independentemente de seu nível de habilidade técnica.
      • Justificativa: Uma interface amigável e fácil de usar minimiza erros de operação e reduz o tempo de treinamento necessário para os novos funcionários.