Tutoría 2: Estrategias Avanzadas de Modelado de Dominio

⚡ Resumen Ejecutivo

Esta sesión se centró en la resolución práctica de dos ejercicios de modelado de dominio (Biblioteca y Plataforma de Cursos), elevando la complejidad respecto a modelos básicos. El profesor hizo especial énfasis en cómo estructurar el modelo para impedir errores funcionales (arquitectura vs. código) y advirtió sobre el uso ciego de la IA, ya que suele cometer errores sutiles en la lógica de negocio (como modelar el "todo" dentro de las "partes").

🔑 Conceptos Clave y Definiciones

Modelado de la Realidad vs. Sistema: No modelamos la realidad física (ej. si la biblioteca abre o cierra), sino la información que el sistema informático necesita gestionar (ej. turnos y asignaciones).
Principio de Sustitución de Liskov: Una clase hija debe poder sustituir a su clase madre siempre. Si una relación de la madre no aplica a la hija, la herencia está mal planteada.
Herencia vs. Atributo "Tipo": Se usa herencia solo cuando las subclases tienen atributos diferentes o relaciones diferentes. Si solo cambia el nombre del rol, basta con un atributo enum o tipo.
Restricciones Estructurales: Diseñar el diagrama de clases de tal forma que sea imposible cometer un error funcional (ej. que un estudiante reserve un iPad), en lugar de dejar que lo valide el programador con un if.
Composición (Rombo Negro): Implica existencia dependiente y exclusiva. Si el padre muere, los hijos mueren; y el hijo no puede pertenecer a dos padres.

📘 Desarrollo del Temario: Ejercicio 1 (Biblioteca "Campus Saberes")

El objetivo es informatizar la gestión de recursos, personal y eventos.

1. Gestión de Empleados: ¿Cuándo usar Herencia?

El enunciado menciona varios roles: bibliotecarios, responsables de préstamo, técnicos, gestores.

El análisis del Profesor:
Si el enunciado acabara en la lista de roles, no habría herencia, solo un atributo tipoEmpleado.
La Herencia surge porque:
El Personal Técnico tiene un atributo exclusivo: especialización.
El Personal de Atención al Público tiene un comportamiento diferente: trabaja por turnos variables, mientras que los técnicos tienen horario fijo.
Solución: Se crea una clase madre Empleado y subclases específicas (PersonalTécnico, AtenciónPúblico, Gestor) porque difieren en datos o relaciones (como la relación con Turno).

2. Recursos y Dispositivos

La biblioteca tiene libros, revistas, recursos digitales y dispositivos (tablets, portátiles).

Estructura:
Recursos Digitales: Necesitan un atributo extra URL.
Dispositivos: Necesitan número de serie y flag de préstamo externo.
Jerarquía: Se utiliza una clase padre Recurso con datos comunes (ID, estado).

3. ¡OJO AL DATO!: Restricción de Préstamos (Punto Crítico de Examen)

El enunciado dice: "Solo los docentes podrán realizar préstamos de dispositivos tecnológicos".

El Error Común: Relacionar Usuario (padre) con Préstamo y Préstamo con Recurso (padre).
El Problema: Según Liskov, si un Usuario puede reservar un Recurso, un Estudiante podría reservar un Dispositivo. Tendrías que impedirlo por código (funcionalidad).
La Solución Arquitectónica (Recomendada):
Crear una subclase PréstamoDocente.
Relacionar Docente PréstamoDocente Dispositivo.
Los estudiantes no tienen acceso físico en el diagrama a la clase Dispositivo.

Cita del Profesor: "Yo como arquitecto te prohíbo que te equivoques. Si intentas que un estudiante reserve un dispositivo, te dará error de compilación. Es mejor poner una pared que un cartel de 'no pasar'."

4. Sanciones y Redundancia

Si un recurso no se devuelve a tiempo, hay penalización.

Optimización: Aunque el enunciado pide registrar el usuario sancionado, no es necesario una relación directa Sanción Usuario.
¿Por qué? Porque Sanción está unida a Préstamo, y Préstamo ya está unido a Usuario. Agregar la relación directa sería redundante y costoso de mantener.

5. Eventos y la Clase "Persona"

Los eventos pueden tener asistentes que son usuarios de la biblioteca o personas ajenas.

Modelado: Surge la necesidad de una superclase Persona (con nombre y apellidos) de la cual hereden tanto Usuario (interno) como AsistenteExterno. Así, el Evento se relaciona con Persona.

📙 Desarrollo del Temario: Ejercicio 2 (Plataforma "ProLearn")

Plataforma de cursos online para profesionales y formadores.

1. Composición de Cursos

Enunciado: "Cada unidad didáctica pertenece exclusivamente a un curso".
Traducción UML: Esto es una Composición (rombo negro) entre Curso y UnidadDidáctica. Si borras el curso, las unidades dejan de tener sentido.

2. Inscripciones y Clases de Asociación

Los profesionales se inscriben a cursos y se guardan datos de esa inscripción (fecha, nota, coste).

Debate: ¿Usar una "Clase de Asociación" en la línea Profesion Curso o una clase intermedia Inscripcion?
Preferencia del Profesor: Evitar Clases de Asociación si es posible. Mejor promover Inscripcion a una clase completa (Profesional Inscripcion Curso).
Motivo: Permite historicos (ej. si un usuario se inscribe dos veces al mismo curso en fechas distintas). Una clase de asociación estándar suele permitir solo un enlace único entre dos instancias.

3. Tipos de Cursos y Tutorización

Existen cursos "Autoevaluables" y "Tutorizados".

Criterio de Herencia:
Solo los cursos tutorizados tienen relación con un Formador.
Solo los cursos tutorizados tienen relación con Comunicaciones (Mensajes/Videollamadas).
Conclusión: Se necesita herencia (CursoTutorizado hereda de Curso) para alojar estas relaciones exclusivas.

4. Comunicaciones (Seguimiento)

Existen tutorías Estándar (mensajes) y Premium (mensajes + videollamadas).

Modelado:
InscripcionPremium se relaciona con Comunicacion (padre de Mensaje y Videollamada).
InscripcionEstandar se relaciona solo con Mensaje.
Nuevamente, se usa la estructura para limitar privilegios.

⚠️ Errores Frecuentes a Evitar (Tips para el Examen)

Modelar lo modelado: No crees una clase llamada "Biblioteca" o "Sistema". Eso es el contenedor, no una pieza del dominó.
Funcionalidad vs. Datos: Si el enunciado dice "el sistema calcula la nota", eso es un método/función, no una clase nueva. Si dice "se guardan dos copias físicas del contrato", eso es burocracia física, no modelo de datos (a menos que necesites gestionar las copias digitales).
Fechas y Históricos: Si necesitas guardar un histórico (ej. reservas pasadas), una simple clase de asociación o un atributo en el usuario no basta; necesitas una clase intermedia (como Reserva o Inscripcion) que actúe como una tabla transaccional.
Redundancia: No conectes todo con todo. Si puedes llegar de A a C pasando por B (), no dibujes una línea directa de A a C a menos que sea estrictamente necesario por rendimiento (muy raro en modelado conceptual).

🧠 Preguntas de Autoevaluación

¿Por qué el profesor decidió crear una clase PrestamoDocente separada en lugar de usar una sola clase Prestamo con un atributo tipoUsuario?
En el ejercicio de ProLearn, ¿qué frase del enunciado justifica el uso de un rombo negro (composición) en lugar de uno blanco (agregación) para las Unidades Didácticas?
Si un usuario externo (no registrado) asiste a una charla en la biblioteca, ¿cómo se representa en el diagrama de clases para no duplicar atributos de nombre y apellidos con los usuarios registrados?
Verdadero o Falso: Según el profesor, las clases de asociación son preferibles cuando se necesita permitir múltiples inscripciones de un mismo usuario al mismo curso en diferentes fechas. (Justifica tu respuesta).