Skip to content

Tutoria 3: Modelado de Dominio Avanzado y Preparación de Examen

📋 Resumen Ejecutivo

Esta sesión tuvo dos objetivos críticos: desglosar la estructura y evaluación del examen final y realizar un ejercicio profundo de modelado de dominio (Diagrama de Clases) sobre un sistema de gestión hotelera complejo. El profesor enfatizó que en problemas de gran envergadura no existe una única solución "perfecta", pero sí soluciones óptimas que deben equilibrar la estructura de datos con la funcionalidad futura.

🗝️ Conceptos Clave

  • Modelo de Dominio: Representación visual de las clases conceptuales, sus atributos y relaciones en un problema real.
  • Cardinalidad/Multiplicidad: Reglas numéricas (ej. 0..1, 1..*) que definen cuántas instancias de una clase se relacionan con otra. Vital para la lógica de negocio.
  • Principio de Sustitución de Liskov: Mencionado para explicar cómo un subtipo (ej. EventoDeportivo) debe poder sustituir a su tipo base (Evento) sin alterar el comportamiento del programa.
  • Enumeraciones (Enums) vs. Herencia: Decisión de diseño para modelar tipos (como tarjetas de fidelización) sin complicar excesivamente la jerarquía de clases.
  • Asociación vs. Agregación: Formas de relacionar objetos (ej. una Reserva "tiene" líneas de reserva o servicios).

🏛️ Parte 1: Estructura del Examen Final

¡OJO AL DATO!: Esta sección es crítica para tu estrategia de aprobado. El examen supone el 60% de la calificación final.

1. Composición del Examen

El examen dura 2 horas y se divide en dos bloques principales, sumando un total de 10 puntos:

A. Preguntas Tipo Test (5,00 puntos)

  • Cantidad: 12 preguntas.

  • Formato: Respuesta única con 4 opciones.

  • Puntuación (Matemática del riesgo):

  • Respuesta correcta: puntos.

  • Respuesta incorrecta: puntos (Penalización del 25%).

  • En blanco: puntos.

B. Supuestos Teórico-Prácticos (5,00 puntos)

Se divide en dos partes:

  1. Diagrama de Clases (2,00 puntos):

  2. Tarea: Te darán un diagrama de clases ya hecho (modelo de dominio).

  3. Tu objetivo: Describir en texto el sistema minuciosamente, explicando relaciones, cardinalidades y atributos. Es ingeniería inversa: del diagrama al texto.

  4. Espacio: Responder en 2 caras.

  5. Preguntas Teórico-Prácticas (3,00 puntos):

  6. Cantidad: 3 preguntas (1 punto cada una).

  7. Tipo: Enfoque abierto ("Diferencias entre...", "Ventajas...", "Razona...").

  8. Consejo del Profesor: Se valora la concisión. No es necesario rellenar todo el espacio (una cara por pregunta).

🏨 Parte 2: Caso Práctico - Ka Hae Hawai'i Grand Resort

Nota de Estudio: El siguiente desglose explica el Diagrama de Clases propuesto en la diapositiva 12, enriquecido con la explicación lógica del profesor.

1. El Núcleo: La Reserva y el Huésped

El sistema no gira en torno al huésped, sino a la Reserva.

  • La relación Cliente vs. Huésped:

  • En el diagrama propuesto, se asume que el cliente que paga es uno de los huéspedes (subset).

  • Discusión de clase: Se debatió si "Cliente" y "Huésped" deberían ser clases separadas (ej. yo reservo y pago para mis padres en Booking). El profesor resolvió esto con asociaciones: una persona puede figurar como cliente (el que paga/reserva) y como huésped (el que se aloja).

  • Reserva: Contiene fechas (fechaInicio, fechaFin), un localizador y un precio total derivado (/precioTotal) que suma habitación y servicios extra.

2. Sistema de Fidelización (Tarjetas y Descuentos)

El hotel tiene tarjetas (Azul, Plata, Oro) que otorgan descuentos jerárquicos.

  • Decisión de Diseño (Enums vs. Herencia):

  • En lugar de crear una clase hija para cada tarjeta (TarjetaOro, TarjetaPlata), el profesor usó un atributo tipo: TipoTarjeta (Enumeración).

  • ¿Por qué? Simplifica el modelo. La lógica compleja (ej. "una tarjeta Oro accede a descuentos Oro y Plata") se delega a la capa funcional/código, no se carga en la estructura de datos.

  • Relación: Una TarjetaFidelización tiene asociados 1..* Descuento.

3. Gestión de Servicios (Comida y Facturación)

El modelo debe soportar tanto buffet como pedidos a la carta, y la opción de pagar al momento o cargar a la habitación.

  • Clase ItemComida: Abstrae tanto un "Menú Buffet" como un "Sándwich Mixto". Ambos tienen nombre y precio.

  • Clase ServicioComida: Registra el pedido.

  • El detalle del pago (0..1 Factura):

  • Esta cardinalidad es clave. Un servicio de comida puede generar una factura (si se paga en cafetería al momento) o cero facturas en ese instante (si se carga a la cuenta de la Reserva para pagar al final de la estancia).

  • Relación atiende {xor}: Un pedido es atendido por un Camarero O por ServicioHabitaciones, pero no ambos a la vez (restricción XOR).

4. Tumbonas y Hamacas

No basta con saber que se reservan tumbonas; se necesita gestionar ubicación y tiempo.

  • Clase ReservaTumbonaHamaca: Es una clase intermedia necesaria porque la reserva de una tumbona tiene atributos propios: fechaInicio, fechaFin y localización (relación con Instalación).

  • Restricción: Se debe controlar el stock disponible considerando que los clientes VIP (Suites/Oro) tienen prioridad o bloqueo de unidades.

5. Eventos y Entretenimiento

El modelo distingue entre eventos organizados por el hotel y eventos deportivos solicitados por huéspedes.

  • Principio de Sustitución: EventoDeportivo es un tipo de Evento.

  • Flujo de Creación:

  • Un huésped puede solicitar unirse a un evento existente.
  • Un huésped puede crear un evento deportivo (ej. partido de pádel con amigos). Al hacerlo, el sistema debe registrar el evento y automáticamente generar una "solicitud" de participación para el creador.
  • Relación: SolicitudEvento conecta la Reserva con el Evento.

6. Empleados y Turnos

  • Se utiliza herencia para los tipos de empleados (EmpleadoRestauración, EmpleadoEntretenimiento heredan de Empleado).

  • Todos los empleados tienen Turnos (fechaInicio, fechaFin) para gestionar el calendario laboral.

❓ Preguntas de Autoevaluación

Usa estas preguntas para comprobar si has entendido la lógica del diagrama.

  1. En el diagrama, la relación entre ServicioComida y Factura es 0..1. ¿Por qué no es 1 obligatorio?

  2. Respuesta: Porque el cliente puede decidir no pagar en el momento y cargar el coste a la cuenta general de la habitación/reserva. Si fuera 1, obligaríamos a emitir y pagar una factura individual por cada café o sándwich al instante.

  3. Explica la diferencia entre modelar las tarjetas de fidelización con Herencia vs. Enumeraciones (Enums) en este caso.

  4. Respuesta: Con herencia tendríamos clases TarjetaOro, TarjetaPlata, etc. Con Enums, tenemos una sola clase Tarjeta con un atributo tipo. El profesor eligió Enums para no complicar el diagrama estructuralmente, dejando la lógica de qué descuento aplica a qué tarjeta para la programación funcional.

  5. ¿Qué implica la restricción {xor} entre Camarero y ServicioHabitaciones al atender un ServicioComida?

  6. Respuesta: Implica exclusividad mutua. Un servicio de comida específico es atendido o por un camarero (en el restaurante/cafetería) o por el servicio de habitaciones, pero nunca por ambos simultáneamente.

  7. ¿Por qué ReservaTumbonaHamaca es una clase y no simplemente una relación directa entre Reserva y Tumbona?

  8. Respuesta: Porque la acción de reservar la tumbona tiene atributos propios de información (fecha, hora inicio, hora fin) que no pertenecen ni a la reserva general ni a la tumbona física.

  9. En el examen práctico, si te piden describir el diagrama, ¿qué elementos debes mencionar obligatoriamente?

  10. Respuesta: Debes describir las Clases (conceptos), sus Atributos (datos), las Relaciones (líneas), y muy importante, las Cardinalidades (cuántos con cuántos) y el significado de las mismas en el contexto del negocio.