Arquitetura de Software: A partir do texto da análise de requisitos: ○ Liste: ■ Stakeholders ■ Requisitos funcionais ■ Requisitos não funcionais ○ Criar o diagrama de caso de uso ○ Identifique qual arquitetura utilizaria e justifique a sua escolha ○ Justifique o motivo de não escolher as outras arquiteturas A Padaria 123 é um estabelecimento de bairro que realiza venda de pães, bolos, bebidas e lanches rápidos. Atualmente, o controle de vendas é feito manualmente, utilizando caderno para anotar pedidos e planilhas simples para controle financeiro. A direção da padaria deseja desenvolver um sistema informatizado para melhorar o controle de vendas, estoque e atendimento. O sistema deverá permitir que os atendentes registrem pedidos realizados no balcão, incluindo múltiplos itens por pedido. Cada item possui preço, categoria e quantidade disponível em estoque. O cliente pode pagar em dinheiro, cartão de débito ou crédito. O sistema deve registrar a forma de pagamento e calcular automaticamente o valor total do pedido. Os produtos vendidos devem ter controle de estoque automático, sendo que a cada venda o estoque precisa ser atualizado. O gerente deve conseguir cadastrar novos produtos, alterar preços e consultar relatórios de vendas diárias, semanais e mensais. A padaria também produz alguns itens internamente, como pães e bolos. O sistema deverá permitir registrar a produção diária desses itens para atualização do estoque. O proprietário deseja que o sistema funcione em dois computadores no balcão simultaneamente. No futuro, existe a possibilidade de permitir pedidos online para retirada no local. O sistema deve ser simples de usar, pois alguns funcionários possuem pouca familiaridade com tecnologia. O tempo de registro de um pedido não deve ultrapassar 1 minuto.

1) Stakeholders

• Proprietário/Direção da Padaria: patrocinador, define objetivos e prioridades (melhorar controle de vendas/estoque/atendimento; expansão futura para online).
• Gerente: administra cadastro de produtos, preços, consulta relatórios e acompanha estoque.
• Atendentes (balcão/caixa): registram pedidos, informam itens/quantidades, finalizam venda e registram pagamento.
• Clientes: realizam pedidos e efetuam pagamento (dinheiro/débito/crédito); futuramente poderão fazer pedido online.
• Equipe de TI/Desenvolvedor/Manutenção (stakeholder indireto): implanta, dá suporte e evolui o sistema.

2) Requisitos Funcionais (RF) RF01. Cadastrar pedido no balcão (atendente) com múltiplos itens por pedido. RF02. Selecionar itens do pedido informando produto e quantidade. RF03. Manter cadastro de produtos (gerente): cadastrar novo produto. RF04. Alterar preço de produto (gerente). RF05. Armazenar atributos do produto: preço, categoria, quantidade disponível em estoque. RF06. Calcular automaticamente o total do pedido com base nos itens e quantidades. RF07. Registrar forma de pagamento: dinheiro, cartão de débito ou cartão de crédito. RF08. Atualizar estoque automaticamente a cada venda (baixa de estoque dos itens vendidos). RF09. Registrar produção diária de itens produzidos internamente (ex.: pães e bolos) para incrementar/atualizar estoque. RF10. Consultar relatórios de vendas (gerente): diários, semanais e mensais. RF11. Permitir uso simultâneo em dois computadores no balcão (dois pontos de operação concorrentes). RF12 (Futuro/Backlog). Permitir pedidos online para retirada no local.

3) Requisitos Não Funcionais (RNF) RNF01. Usabilidade: sistema “simples de usar”, adequado a usuários com pouca familiaridade com tecnologia. RNF02. Desempenho: tempo de registro de um pedido ≤ 1 minuto. RNF03. Concorrência/Disponibilidade local: suportar operação simultânea em 2 computadores no balcão (controle de acesso concorrente a pedidos/estoque). RNF04. Evolutividade/Manutenibilidade: deve suportar expansão futura para pedidos online (facilidade de evolução). RNF05. Confiabilidade/Consistência de dados: atualização de estoque e registro de vendas devem ser consistentes (evitar estoque negativo, perdas em caso de falha).

4) Diagrama de Caso de Uso (texto/PlantUML) Você pode representar assim (exemplo em PlantUML):

@startuml
left to right direction

actor "Atendente" as At
actor "Gerente" as Ge
actor "Cliente" as Cl

rectangle "Sistema Padaria 123" {
  usecase "Registrar Pedido" as UC1
  usecase "Adicionar/Remover Itens do Pedido" as UC2
  usecase "Calcular Total" as UC3
  usecase "Registrar Pagamento" as UC4
  usecase "Atualizar Estoque (Venda)" as UC5

  usecase "Cadastrar Produto" as UC6
  usecase "Alterar Preço" as UC7
  usecase "Consultar Relatórios de Vendas\n(diário/semanal/mensal)" as UC8
  usecase "Registrar Produção Diária" as UC9

  usecase "Realizar Pedido Online (Futuro)" as UC10
}

At --> UC1
At --> UC4

UC1 .> UC2 : <<include>>
UC1 .> UC3 : <<include>>
UC4 .> UC5 : <<include>>

Ge --> UC6
Ge --> UC7
Ge --> UC8
Ge --> UC9

Cl --> UC10
@enduml

Observações:

• <<include>> faz sentido quando o comportamento sempre ocorre (ex.: calcular total sempre que registra pedido; atualizar estoque sempre que finaliza venda).
• O caso “Pedido Online” foi marcado como futuro, mas já previsto para orientar a arquitetura.

5) Arquitetura recomendada e justificativa Arquitetura escolhida: Cliente-Servidor em 3 camadas (apresentação + lógica de negócio + dados), com banco de dados central (on-premises na padaria) e aplicação cliente (web ou desktop).

Justificativa (por que essa é a melhor aqui):

• Dois computadores simultâneos: com um banco central (servidor local), ambos os caixas veem o mesmo estoque/pedidos em tempo real, evitando divergências.
• Consistência e transações: a lógica de negócio no servidor facilita garantir regras como “dar baixa no estoque ao finalizar venda” e manter integridade.
• Evolução para pedidos online: uma base cliente-servidor com camada de serviços (API) facilita adicionar futuramente um front-end online consumindo os mesmos serviços.
• Manutenibilidade: separar UI, regras e dados reduz acoplamento e facilita alterações (ex.: novos relatórios, novas formas de pagamento).
• Usabilidade e desempenho: interface pode ser bem simples e otimizada para fluxo rápido de balcão, enquanto regras ficam centralizadas.

6) Por que NÃO escolher outras arquiteturas (principais alternativas)

1. Monolítica “tudo em um PC” (single-tier / standalone)

• Problema: não atende bem ao requisito de 2 computadores simultaneamente (ou vira “gambiarra” com arquivos compartilhados).
• Risco: inconsistência de estoque (cada máquina com base própria) ou conflitos se usar planilhas/arquivos.
• Escalabilidade: dificulta muito adicionar pedidos online depois.

2. P2P (peer-to-peer) entre os dois computadores

• Problema: sincronização de dados é complexa; aumenta chance de conflitos (estoque) e falhas.
• Manutenção: difícil garantir consistência e fazer backup/recuperação.
• Evolução: para online, ainda seria necessário centralizar ou expor serviços.

3. Microserviços

• Overkill: para uma padaria de bairro, a complexidade operacional (deploy, observabilidade, comunicação, consistência distribuída) não se justifica.
• Custo e risco: maior custo de desenvolvimento/infra e mais pontos de falha.
• Equipe pequena: normalmente microserviços fazem sentido com times maiores e necessidades de escala muito altas.

4. Arquitetura totalmente Serverless/Cloud-first

• Dependência de internet: balcão pode sofrer com instabilidade; vendas/atendimento são críticos.
• Custo/complexidade: autenticação, latência e operação podem ser desnecessários para o cenário inicial.
• Atenuação: poderia ser considerada no futuro, mas inicialmente um servidor local (ou híbrido) tende a ser mais robusto.

---

Se você quiser, posso também:

• detalhar modelo de dados (tabelas: Produto, Categoria, Pedido, ItemPedido, Pagamento, Producao, Usuario),
• listar regras de negócio (ex.: impedir venda com estoque insuficiente),
• ou ajustar o diagrama para incluir autenticação/perfis (atendente vs gerente).