+----------------------+ +-----------------------+ | Cliente | | SistemaDeReservas | +----------------------+ +-----------------------+ | | | 1. Faz pedido de reserva | |------------------------------------------->| | | | 2. Solicita informações de caminhão | |-------------------------------------------->| | | | 3. Envia informações do caminhão disponível | |<--------------------------------------------| | | | 4. Confirma reserva | |-------------------------------------------->| | | | 5. Cria reserva | |<--------------------------------------------| | | | 6. Calcula tarifa de aluguel | |-------------------------------------------->| | | | 7. Informa tarifa de aluguel | |<--------------------------------------------| | | | 8. Finaliza reserva | |-------------------------------------------->| | | | 9. Envia informações de entrega e devolução | |<--------------------------------------------| | | | 10. Informa entrega de caminhão | |-------------------------------------------->| | | | 11. Recebe caminhão devolvido | |<--------------------------------------------| | | | 12. Encerra reserva | |-------------------------------------------->| | | +----------------------+ +-----------------------+ | Cliente | | Caminhão | +----------------------+ +-----------------------+

Os padrões GRASP para definir as responsabilidades aos objetos são: 2.1 Controller: O padrão Controller pode ser aplicado para os objetos que manipulam as requisições dos usuários e orquestram as operações do sistema. Nesse caso, a classe SistemaDeReservas pode atuar como um Controller, responsável por gerenciar o processo de reserva de caminhões ; 2.2 Expert: O padrão Expert pode ser aplicado para os objetos que possuem as informações necessárias para executar uma operação específica. Nesse caso, a classe Caminhão pode ser responsável por manter as informações sobre o veículo, como modelo, ano, tamanho, e etc ; 2.3 Creator: O padrão Creator pode ser aplicado para os objetos que têm a responsabilidade de criar novos objetos. Nesse caso, a classe SistemaDeReservas pode criar uma nova instância de Reserva quando uma solicitação de reserva for feita; 2.4 High Cohesion: O princípio de alta coesão pode ser aplicado para garantir que cada objeto tenha uma única responsabilidade bem definida. Por exemplo, a classe Reserva deve ser responsável por manter informações sobre a reserva, como a data de início, data de término e informações de cobrança; 2.5 Low Coupling: O princípio de baixo acoplamento pode ser aplicado para garantir que os objetos sejam independentes e possam ser modificados sem afetar outros objetos do sistema. Por exemplo, a classe SistemaDeReservas deve depender apenas das interfaces de outros objetos, como Caminhão e Reserva, e não de suas implementações específicas e 2.6 Polymorphism: O polimorfismo pode ser aplicado para permitir que objetos de diferentes classes possam ser tratados de forma uniforme. Por exemplo, a classe Reserva pode ter um método calcularValor() que pode ser implementado de forma diferente em classes filhas, como ReservaPorHora ou ReservaPorKm.