Skip to content

Tutoría 1: Corrección de Modelado de Dominio y Metodologías Ágiles

Resumen Ejecutivo

Esta sesión se centró en la corrección de la primera actividad práctica, diferenciando entre los grados de Ingeniería Informática y Matemática Computacional. Se abordó cómo justificar el cambio de una metodología tradicional a una Ágil utilizando el Manifiesto Ágil y se resolvieron dos casos prácticos de Modelado de Dominio (Biblioteca y Ensayos Clínicos), haciendo énfasis en la diferencia estructural entre Clases y Clases de Asociación para gestionar históricos.

Conceptos Clave

  • Manifiesto Ágil: Conjunto de 4 valores y 12 principios que guían el desarrollo de software adaptativo.
  • Modelado de Dominio: Representación de datos a nivel de aplicación (estructural), no funcional. Es el "cimiento" de la casa.
  • Clase vs. Clase de Asociación: Distinción crítica basada en la multiplicidad y la necesidad de mantener un histórico de eventos entre dos entidades.
  • Herencia (Generalización): Mecanismo para agrupar atributos comunes (ej. Persona) y especializar atributos específicos (ej. Profesor vs. Alumno).
  • Atributo Derivado: Información que se puede calcular a partir de otros datos (ej. Inventario) y que a menudo no requiere una clase propia en el modelo de dominio.

1. Transición a Metodologías Ágiles (Común a todos)

El objetivo era explicar cómo pasar de un modelo en cascada a uno ágil. La clave no es inventar, sino aplicar los valores del Manifiesto Ágil a la situación de la empresa.

Aplicación de los 4 Valores Ágiles

El profesor recomienda justificar los cambios basándose en los valores fundamentales:

  1. Individuos e interacciones sobre procesos y herramientas:
    • Acción: Cambios en Recursos Humanos, métricas de clima social y mejora de la satisfacción del equipo.
  2. Software funcionando sobre documentación extensiva:
    • Acción: Negociar con el cliente qué documentación es realmente útil.

    • Argumento para el cliente: "La documentación cuesta dinero (horas facturables). Vamos a optimizar el esfuerzo y eliminar lo que no aporte valor real."

  3. Colaboración con el cliente sobre negociación contractual:
    • Acción: Integrar al cliente (o un representante) dentro del equipo de desarrollo.
    • Problema común: Si el cliente no está disponible, el equipo "inventa" requisitos, lo cual genera errores.
  4. Respuesta ante el cambio sobre seguir un plan:
    • Acción: Adaptabilidad en la planificación.

Aplicación de Principios Ágiles (Ejemplos prácticos)

  • Equipos auto-organizados: Dividir tareas en unidades pequeñas.
  • Entregas frecuentes: Sprints de 2 semanas (demo de resultados + priorización).
  • Comunicación diaria: Daily Stand-ups (presencial o escrito) para sincronización.
  • Herramientas: Uso de Redmine o Jira para gestión de tareas.
  • Técnicas: Integración Continua/Despliegue Continuo (CI/CD), DevOps, revisión por pares (Peer Review).

2. Modelado de Dominio: Gestión de Biblioteca

(Caso específico para Grado en Ingeniería Informática)

Contexto: Sistema para reservar puestos/salas y préstamo de libros (algunos solo para sala).

Estructura de Clases y Herencia

El enunciado menciona Profesores y Alumnos. ¿Son lo mismo? * Decisión: Crear una herencia de Usuario. * Usuario (Padre): Nombre, Apellidos. * Profesor (Hijo): NIF, NUS, Fecha Nacimiento. * Alumno (Hijo): Número de estudiante. * Decisión: Crear herencia de Lugar. * Lugar (Padre): ID, planta. * PuestoLectura (Hijo): Número de mesa. * Sala (Hijo): Aforo máximo.

El Reto de las Reservas: ¿Clase o Asociación?

¡OJO AL DATO! Este fue el punto crítico de la corrección.

  • Planteamiento inicial: Relacionar Usuario con Lugar. De esa relación cuelga una "Clase de Asociación" con la fecha.
  • El Error: Una clase de asociación implica que un par único de objetos (Usuario X + Lugar Y) solo tiene una instancia de asociación activa.
    • Pregunta: ¿Puede Jesús reservar el puesto 14 hoy, mañana y pasado? SÍ.
    • Consecuencia: Si usas clase de asociación, no puedes guardar el histórico de esas 3 reservas distintas (mismo usuario, mismo lugar).
  • Solución Correcta: Promocionar la reserva a CLASE (Reserva).
    • Un Usuario hace muchas Reservas.
    • Una Reserva corresponde a un único Usuario.
    • Una Reserva se refiere a un único Lugar.
    • Un Lugar tiene muchas Reservas (histórico).

Gestión de Préstamos y Libros

Problema: Algunos libros son solo para sala (requieren reservar un lugar) y otros son para llevar a casa.

  • Solución del Profesor:
    • Préstamo tiene una relación de 0..1 con Lugar.
    • Si es 0: Préstamo a domicilio.
    • Si es 1: Préstamo en sala.
  • Solución Alternativa (José Luis - Validada): Herencia en Préstamo.
    • Préstamo (Padre).
    • PréstamoExterno (Hijo): Con fecha devolución.
    • PréstamoSala (Hijo): Con relación obligatoria a Lugar.
  • Solución Alternativa (Cassandra - Validada pero "sucie"): Usar un flag booleano esParaSala. (Funciona, pero a nivel de código acabarás necesitando un objeto lugar que será nulo si el flag es falso).

3. Modelado de Dominio: Ensayos Clínicos

(Caso específico para Grado en Matemática Computacional)

Contexto: Gestión de investigadores, ensayos y medicamentos.

Errores Comunes a Evitar

  1. Inventario como Clase:
    • No crear una clase "Inventario" si solo es un conteo de medicamentos. El inventario es un cálculo funcional (recorrer stock), no una estructura de datos necesaria en el dominio.
  2. Restricciones Funcionales en el Diagrama:
    • Requisito: "Un investigador no puede participar en más de 3 ensayos".
    • ¡OJO AL DATO!: No pongas un "3" en la cardinalidad. En el diagrama es * (muchos).
    • Razón: La restricción es "simultáneamente". A lo largo de su vida, un investigador estará en 50 ensayos. La regla del "máximo 3" se programa con un if (lógica de negocio), no en la estructura de la base de datos.

Estructura Correcta

  • Medicamentos: Diferenciar entre la InfoMedicamento (genérico, principio activo) y el Lote o administración concreta en un ensayo.
  • Ensayos y Visitas:
    • Relación Ensayo - Instalación.
    • ¿Puede ir varias veces a la misma instalación para el mismo ensayo? SÍ.
    • Conclusión: Igual que en la biblioteca, la Visita debe ser una CLASE, no una clase de asociación, para permitir múltiples visitas (histórico) del mismo ensayo en la misma instalación.

Preguntas de Autoevaluación

  1. En un diagrama de clases, si un Usuario puede reservar el mismo Libro múltiples veces en fechas distintas, ¿debo usar una Clase de Asociación o una Clase intermedia? ¿Por qué?
  2. Si un requisito dice "Un alumno solo puede sacar 2 libros a la vez", ¿se debe poner un "2" en la cardinalidad de la relación Alumno-Libro?
  3. Según el Manifiesto Ágil discutido, ¿qué argumento utilizarías para reducir la cantidad de documentación entregada a un cliente?
  4. ¿Es correcto modelar una clase "Inventario" que contiene una lista de todos los productos?