Faça um diagrama de caso de uso e de classes para cada um dos casos abaixo:
Uma agência de viagens vende passagens, estadias em hotéis. Passeios e pacotes que podem agregar todos os anteriores. Os hotéis podem ter 3 categorias diferentes, o que define o preço de sua diária. Os hotéis e as passagens precisam de reservas. Todos os preços são dependentes da época da viagem e as passagens aéreas podem ser pagas a prazo. Defina um sistema capaz de montar pacotes e gerar relatórios de preços.
Uma agência de viagens vende passagens, estadias em hotéis. Passeios e pacotes que podem agregar todos os anteriores. Os hotéis podem ter 3 categorias diferentes, o que define o preço de sua diária. Os hotéis e as passagens precisam de reservas. Todos os preços são dependentes da época da viagem e as passagens aéreas podem ser pagas a prazo. Defina um sistema capaz de montar pacotes e gerar relatórios de preços.
Passo 1
O enunciado pede que eu faça um diagrama de caso de uso e um diagrama de classes para o sistema descrito. Vou listar claramente o que o enunciado dá e o que é solicitado, sem resolver nada ainda:
-
O que o enunciado dá (informações relevantes):
- A agência vende: passagens, estadias em hotéis, passeios e pacotes que podem agregar os itens anteriores.
- Hotéis podem ter três categorias diferentes, e a categoria define o preço da diária.
- Hotéis e passagens precisam de reservas.
- Todos os preços dependem da época da viagem (sazonalidade).
- Passagens aéreas podem ser pagas a prazo (parcelamento).
- O sistema deve ser capaz de montar pacotes e gerar relatórios de preços.
-
O que o enunciado pede:
- Um diagrama de caso de uso que represente os atores e as funcionalidades (casos de uso) principais do sistema.
- Um diagrama de classes que modele as entidades, atributos, operações e relações necessárias para implementar o sistema descrito.
- Não há restrição adicional; devo decidir modelagem detalhada para suportar reservas, sazonalidade de preços, parcelamento, montagem de pacotes e relatórios.
Passo 2
Rápida explicação didática sobre o diagrama de caso de uso (o que é e por que usar):
- Um diagrama de caso de uso mostra quem usa o sistema (atores) e o que o sistema oferece (casos de uso).
- Ator é qualquer entidade externa ao sistema que interage com ele (por exemplo: cliente, atendente/agente, sistemas externos).
- Caso de uso é uma funcionalidade observável pelo ator (por exemplo: “Reservar passagem”, “Montar pacote”).
- Relacionamentos importantes:
- Associação: ligação ator ↔ caso de uso.
- Include: quando um caso de uso sempre chama outro (reutilização).
- Extend: quando um caso de uso opcional/condicional estende outro.
- Por que aqui: o diagrama ajuda a visualizar requisitos funcionais essenciais (reservas, pagamentos, montagem de pacotes, relatórios).
Passo 3
Definição dos atores relevantes para o problema (lista e justificativa curta para cada um):
-
— usuário final que compra passagens, hotéis, passeios e pacotes. -
— funcionário da agência que pode montar pacotes, confirmar reservas e emitir relatórios. -
— sistema da companhia aérea para verificar disponibilidade e confirmar reserva de voo. -
— sistema do hotel (ou central de reservas) para verificar disponibilidade e confirmar reserva de quarto. -
— serviço externo para processar pagamentos e parcelamentos. -
— usuário que ajusta políticas (sazonalidade, preços base, categorias de hotel) e visualiza relatórios administrativos.
Passo 4
Lista de casos de uso principais (com pequena descrição de cada um):
-
: cliente/agent pesquisa passagens, hotéis, passeios. -
: obter preço de um produto numa data/época (considera sazonalidade e categoria de hotel). -
: reservar voo (integra com ). -
: reservar diária de hotel (integra com ). -
: reservar passeio/tour local. -
: combinar passagens + hotel + passeios em um pacote. -
: sumarizar preços dos itens e aplicar descontos/políticas. -
: pagar serviço (suporta pagamento à vista e parcelado via ). -
: gerar confirmações e documentos de reserva. -
: relatórios de preços históricos/projeções por época e produto. -
: administrador define sazonalidade, multiplicadores de preço por categoria de hotel, regras de desconto.
Passo 5
Relacionamentos importantes entre casos de uso (decisões de modelagem):
-
é usado por e por . Como o cálculo de preço é um passo comum e sempre executado, usamos Include: -
include . -
include e este include para cada item.
-
-
include quando a política exige pagamento imediato; mas como o pagamento pode ser opcional/adiado (por ex. pagamento posterior), modelamos como extend em cenários alternativos de pagamento imediato. -
include dependendo da política do fornecedor — modelagem análoga. -
inclui integração com . -
é acionado por e por .
Passo 6
Como representar textualmente o diagrama de caso de uso (instruções práticas para desenhar):
- Desenhe um retângulo com a borda do sistema: “Sistema de Agência de Viagens”.
- Posicione atores fora do retângulo:
, , , , , . - Liste os casos de uso dentro do retângulo e ligue atores aos casos apropriados com linhas simples.
- Representar include com seta tracejada e label «include», extend com label «extend».
- Se quiser, agrupe casos de uso relacionados (pesquisa/consulta, reserva/pagamento, administração/relatórios).
Passo 7
Agora vamos à parte prática: teoria didática sobre diagrama de classes (o que é e conceitos que vou usar):
- Classe: definição de um conjunto de objetos com atributos (estado) e operações (comportamento).
- Atributo: campo com tipo (ex.:
, ). - Método/Operação: ação que a classe pode executar (ex.:
). - Associação: ligação entre classes; costuma ter multiplicidades (ex.:
, ). - Agregação vs Composição:
- Agregação (loose): todo-parte fraco (ex.: pacote agrega produtos).
- Composição (forte): parte não existe sem o todo (ex.: itens de reserva podem ser composição do booking).
- Herança: generalização/especialização (ex.:
genérico, , , especializações). - Interfaces: contratos (ex.:
com operação ).
Passo 8
Escolha das classes principais do modelo (lista inicial com justificativa sucinta):
-
— representa usuário comprador. -
e — podem ser subtipos de ou papéis distintos; vou modelar uma classe com atributo . -
(abstrato) — representa qualquer item comercializável; subclasses: , (ou ), , . -
(abstrato) — especializações: , , . Reserva tem vínculo com correspondente. -
— agrega vários ou referências a reservas/propostas. -
ou — encapsula regras de precificação por época. -
— enumeração ou classe com multiplicador de preço. -
— registra pagamentos; suporta parcelamento com subtipo ou atributos . -
ou — representa sistemas externos e . -
— classe/facade para gerar relatórios de preços. -
— entidade que representa o processo de venda/compra que pode conter uma ou mais reservas e pagamentos.
Passo 9
Detalhamento das classes com atributos e métodos (textual; cada nome/atributo em TeX conforme regra). Vai ser didático: explicar o que cada atributo significa e exemplos simples.
-
Classe
- Atributos:
-
— identificador único. -
-
-
— ex.: , , .
-
- Métodos:
-
- Atributos:
-
Classe
(pode herdar de ou ser usuário com ; escolha prática: usar com atributo para simplicidade). -
Classe
(abstrata) - Atributos:
-
-
-
— preço base sem sazonalidade.
-
- Métodos (abstratos):
-
— cada subclasse implementa. -
-
- Atributos:
-
Classe
(herda ) - Atributos:
-
-
— ex.: Econômica, Executiva. -
-
-
- Métodos:
-
— aplica sazonalidade, tarifas, taxas. -
— indica se pode ser parcelado.
-
- Atributos:
-
Classe
ou (herda ) - Atributos:
-
- Métodos:
-
— aplica multiplicador de categoria e sazonalidade. -
-
- Atributos:
-
Enumeração
- Valores:
(ou nomes significativos). - Cada valor associado a um
que ajusta .
- Valores:
-
Classe
(herda ) - Atributos:
-
(horas) -
-
-
- Métodos:
-
- Atributos:
-
Classe
(herda ou é uma agregação de ) - Atributos:
-
-
— desconto aplicado ao pacote.
-
- Métodos:
-
- Implementação: soma preços dos itens (chamando
de cada item), aplica desconto de pacote e regras de sazonalidade combinadas.
- Implementação: soma preços dos itens (chamando
-
- Atributos:
-
Classe
(abstrata) - Atributos:
-
-
-
-
— ex.: , , . -
-
- Métodos:
-
- Atributos:
-
Classe
(herda ) - Atributos:
-
- Métodos:
-
— integra com .
-
- Atributos:
-
Classe
(herda ) - Atributos:
-
- Métodos:
-
— integra com .
-
- Atributos:
-
Classe
- Atributos:
-
- Métodos:
-
-
— soma de reservas/pacotes. -
— orquestra , confirma reservas.
-
- Atributos:
-
Classe
- Atributos:
-
-
-
-
— para à vista. -
-
- Métodos:
-
— integra com . -
— envia valores de cada parcela (aplica juros se necessário).
-
- Atributos:
-
Classe
(ou ) - Atributos:
-
-
-
-
— ex.: para alta temporada.
-
- Métodos:
-
- Atributos:
-
Classe
- Métodos:
-
- Métodos:
-
Classes de integração:
-
- Métodos:
,
- Métodos:
-
- Métodos análogas.
-
Passo 10
Associações e multiplicidades (explicitação clara, usando TeX para multiplicidades):
-
— : um usuário pode ter vários bookings. -
— : um booking agrega uma ou mais reservas. -
— : cada reserva refere-se a um produto específico (passagem/hotel/passeio). -
— (agregação) : pacote agrega vários produtos. -
— : hotel pode ter várias reservas. -
é representado pela classe que chama métodos de integração externa. -
associada a ou ao sistema de preços — as regras são consultadas no cálculo de preço.
Explicação didática das multiplicidades:
-
significa exatamente um. -
significa zero ou mais. -
significa um ou mais. - Em composição (Booking → Reserva), se o booking for cancelado, as reservas associadas podem ser canceladas automaticamente (composição forte).
Passo 11
Como calcular preço na prática (passo a passo que você pode colocar na prova ou implementar):
- Obter
do produto: - Para
: usar . - Para
: usar .
- Para
- Aplicar multiplicador de categoria do hotel (se aplicável):
-
.
-
- Aplicar regra de sazonalidade (buscar
cujo ): -
.
-
- Para pacotes: somar preços dos itens (cada item calculado como acima) e aplicar
: -
.
-
- Para parcelamento (passagem):
- Se
e houver juros, calcular usando fórmula de amortização simples ou juros simples: - Exemplo de juros simples:
.
- Exemplo de juros simples:
- Guardar no registro
as parcelas geradas.
- Se
Observações didáticas:
- Sempre trate moeda com tipo
que garante precisão (evitar float). - A sazonalidade pode ter múltiplas regras sobrepostas; escolha política (maior multiplicador aplicável, acumulativo, etc.) — documente essa regra.
Passo 12
Decisões de projeto e justificativas (por que modelar assim):
- Usar
abstrato permite adicionar novos tipos (ex.: seguro viagem) sem quebrar modelo. - Separar
e facilita diferentes fluxos (reserva sem pagamento imediato). - Encapsular sazonalidade em
torna fácil alterar regras sem tocar classes de produto. - Modelar
como agregação de produtos permite reutilizar lógica de preço e disponibilidade. - Representar integrações externas como classes específicas evidencia dependências e facilita teste/mocking.
Passo 13
Orientação prática para implementação / diagrama físico:
- No UML visual:
- Coloque classes em caixas com três seções: nome, atributos, métodos.
- Desenhe setas de herança (linha com triângulo fechado) de
, , , para . - Use linha com losango preenchido para composição
→ . - Use linhas simples com multiplicidades para associar
a , a . - Mostre
ligada ao componente de precificação (pode ser uma dependência do sistema ou associação com ).
Resposta
Diagrama de caso de uso (representação textual):
-
Atores:
-
-
Casos de uso (dentro do sistema “Sistema de Agência de Viagens”):
-
- «include»
- «include»
-
-
- «include»
- «extend»
(quando pagamento imediato) - integra com
- «include»
-
- «include»
- «extend»
(quando pagamento imediato) - integra com
- «include»
-
- «include»
- «include»
-
- «include»
- «include»
-
- «include»
(para cada item)
- «include»
-
- integra com
- suporta
- integra com
-
-
(acessível por e ) -
(por : sazonalidade, multiplicadores por categoria de hotel, regras de desconto)
-
-
Ligações principais (resumo):
-
— associa com , , , . -
— associa com , , . -
— associa com , . - Integrações externas vinculadas aos casos de reserva e pagamento conforme indicado.
-
Diagrama de classes (representação textual detalhada):
-
- Atributos:
, , , - Métodos:
,
- Atributos:
-
(abstrato) - Atributos:
, , - Métodos:
,
- Atributos:
-
: - Atributos:
, , , - Métodos:
,
- Atributos:
-
: - Atributos:
, , , - Métodos:
,
- Atributos:
-
: - Atributos:
, , - Métodos:
- Atributos:
-
: (agregação) - Atributos:
, - Métodos:
- Atributos:
-
(abstrata) - Atributos:
, , , , - Métodos:
,
- Atributos:
-
: - Atributos:
, - Métodos:
— integra com
- Atributos:
-
: - Atributos:
, , , - Métodos:
— integra com
- Atributos:
-
- Atributos:
, , , - Métodos:
, ,
- Atributos:
-
- Atributos:
, , , , - Métodos:
,
- Atributos:
-
- Atributos:
, , , - Métodos:
- Atributos:
-
(enum) - Valores:
(cada um com )
- Valores:
-
- Métodos:
,
- Métodos:
-
Integração:
-
: , -
: , -
:
-
Associações e multiplicidades principais (resumo em TeX):
-
— -
— (composição) -
— -
— (agregação) -
— -
associada ao mecanismo de cálculo de preço
Resumo prático do fluxo essencial (para implementar):
- Usuário pesquisa → sistema chama
(consulta e multiplicadores de ) → usuário monta pacote/reserva → cria com s → na finalização chama (parcelado se aplicável) → se pagamento confirmado, orquestra confirmações via / → gera confirmações e relatórios.
Observação final de incentivo: com esse modelo você tem uma estrutura flexível (produtos extensíveis, regras de preço desacopladas e reservas/pagamentos separados) que cobre todos os pontos do enunciado (categorias de hotel, sazonalidade, reservas, parcelamento, montagem de pacotes e geração de relatórios). Se quiser, eu transformo essa descrição textual em um diagrama UML no formato PlantUML ou desenho pronto para impressão.