# Diagrama de classes
# Histórico de Versão
| Data | Autor(es) | Descrição | Versão |
|---|---|---|---|
| 18/09/20 |
Lucas Midlhey(Lucas Midlhey),
Fábio Teixeira(fabio1079) | Criação do diagrama | 0.1 |
| 24/09/2020 | Fábio Teixeira(fabio1079) | Adiciona estratégia de pagamento | 0.2 |
| 25/09/2020 | Fábio Teixeira(fabio1079) | Adiciona QRController e QRCodeBuilder | 0.3 |
| 26/09/2020 | Fábio Teixeira(fabio1079) |
1 - Muda linguagem para o inglês 2 - Adiciona EmployeeController e CustomerController 3 - Muda QRController para TableConroller 4 - Adiciona observer design pattern para notificar funcionário quando o cliente está chamando | 0.4 |
| 27/09/2020 | Fábio Teixeira(fabio1079) |
1 - Adiciona observer para notificar mesa em mudanças no status dos pedidos 2 - Adiciona estratégia no sistema de notificações funcionando em conjunto com o observer, facilitando extensão 3 - Adiciona observações | 0.5 |
| 28/09/2020 | Fábio Teixeira(fabio1079) |
1 - Atualiza diagrama para ficar de acordo com feat 04 dos diagramas de sequência: Adiciona MenuController, MenuType, atributo daily em menu. | 0.6 |
| 28/09/2020 | Fábio Teixeira(fabio1079) |
1 - Atualiza diagrama para ficar de acordo com feat 05 dos diagramas de sequência: Adiciona EmployeePool, adiciona método updateAtentionCaller em CustomerController | 0.7 |
# Diagrama
# Introdução
Este diagrama tem como objetivo trazer a estrutura de um sistema ao modelar suas classes, seus atributos, operações e relações entre objetos. Ao criar um diagrama de classes consegue-se ilustrar modelos de dados para sistemas de informação, entender melhor a visão geral dos esquemas de uma aplicação, expressar visualmente as necessidades específicas de um sistema e fornecer uma descrição independente da implementação de tipos utilizados.
# Versão atual
# Observações
- Métodos getters e setters nao estão sendo mostrados no diagrama para evitar poluição visual, mas considera-se que todo atributo privado tem o seu respectivo getter e setter.
- O sistema de notificações foi pensado para ser extensível, bastando implementar uma estratégia sempre que necessário.
- uso de observers:
- Quando um cliente chama por um funcionário, ver feat 05: Customer, calls employee
- Quando um funcionário muda o status de um pedido, ver feat 06: notify request status
- ActionCaller está sendo relacionada como uma agregação, já que considera-se que não há necessidade de sempre instanciala. Ex: Se um cliente nunca chamar por um funcionário, não tem por que sempre instanciar uma ActionCaller na CustomerController.