[Informe de Clase] Desarrollo de Sistemas (2º año), Semana 34

〜 Diseño UML: dibujar la “Estructura” con Diagramas de Clases y el “Comportamiento” con Diagramas de Secuencia 〜

En la Semana 34 pasamos de la definición de requisitos de la semana pasada a una sesión práctica de diseño usando UML. El objetivo fue “organizar la estructura con diagramas de clases” y “visualizar el comportamiento con diagramas de secuencia”. Fue una sesión muy práctica orientada a impulsar la capacidad de diseño de cada equipo.

■ Introducción del instructor: “Las cosas se aclaran cuando las dibujas”

Sr. Tanaka: “El diseño es difícil de comunicar solo con palabras. Si usas diagramas de clases para mostrar qué existe y diagramas de secuencia para mostrar cómo se mueven las cosas, todos en el equipo compartirán el mismo entendimiento.”

Ilustró el propósito y uso de UML con un ejemplo conciso en la pizarra (clases principales y una secuencia de préstamo para un sistema de biblioteca).

■ Puntos clave de hoy (breve)

• Diagramas de clases: Definir clases (atributos y operaciones), relaciones (asociación / agregación / herencia) y multiplicidad.
• Diagramas de secuencia: Mostrar interacciones a lo largo del tiempo, aclarando el orden de los mensajes y las responsabilidades.
• Los diagramas actúan como un “contrato de diseño”: los equipos deben acordarlos antes de pasar al código.

■ Ejercicio ①: Creación de diagramas de clases (90 minutos)

Procedimiento

1. Revisar los requisitos (historias de usuario y criterios de aceptación).
2. Identificar las entidades necesarias (clases).
3. Definir los atributos (datos) y métodos/operaciones (comportamiento) de cada clase.
4. Especificar relaciones (asociación / dependencia / herencia / agregación) y multiplicidad (1, 0…*, etc.).
5. Revisar los diagramas dentro de cada equipo y corregir según comentarios.

Ejemplo (extracto de un sistema de biblioteca)

• Book (title, author, is_available) + lend(), return_book()
• Member (name, member_id) + borrow(book), give_back(book)
• Library (books:list) + find_book(title), register_book(book)
• Member —(borrows)→ Book (Multiplicidad: Member 1 — 0…* Book)

Opinión del alumnado:
“Separar atributos de operaciones nos aclaró mucho los métodos de implementación.”
“Añadir multiplicidad también nos ayudó a imaginar el comportamiento de la UI.”

■ Ejercicio ②: Visualización de escenarios clave con diagramas de secuencia (80 minutos)

Escenarios (elegidos por equipo)

• Buscar un libro y tomarlo prestado (Search → Borrow)
• Flujo de devolución con verificación de retraso (Return → CheckOverdue)
• Llamar a una API externa (p. ej., clima) y mostrar el resultado

Puntos clave para dibujar

• Alinear lifelines (objetos) y distribuir responsabilidades de izquierda a derecha.
• Usar flechas para los mensajes (sincrónicos / asincrónicos), incluyendo valores de retorno y flujos de excepción.
• Representar condicionales y bucles con marcos alt / loop.

Ejemplo parcial (pseudo)

User -> Library: find_book(title)
Library -> Book: check availability
Book --> Library: available / not available
Library -> User: return list / "No match"

Comentarios del alumnado:
“Dibujar el diagrama de secuencia nos ayudó a organizar de forma natural qué botón de la UI dispara qué proceso.”
“También aclaró temprano el manejo de excepciones (como sin stock), lo que debería reducir errores de implementación.”

■ Revisión y feedback (30 minutos)

Los equipos colocaron sus diagramas de clases y de secuencia en la pizarra para revisión entre pares. Puntos de control clave:

• Alineación entre requisitos y diagramas (sin elementos faltantes)
• Separación adecuada de responsabilidades (Principio de Responsabilidad Única)
• Representación clara de excepciones y flujos anómalos
• Especificidad suficiente del diagrama para implementar código

Comentarios del Sr. Tanaka:
“No lo metan todo en Library.”
“Consideren ubicar el caché de resultados de búsqueda en una clase separada (CacheManager) para límites de responsabilidad más claros.”

■ Palabras de cierre del instructor

“Los diagramas de diseño son herramientas de comunicación. Al acordar ‘¿Esto es correcto?’ antes de escribir código, se reduce drásticamente el tiempo desperdiciado en implementación. Pueden redibujar los diagramas cuantas veces sea necesario—lo importante es el consenso.”

■ Tarea (preparación para la próxima semana)

1. Entregar el diagrama de clases final de su equipo (PNG o PDF) y un diagrama de secuencia representativo.
2. Crear una propuesta de estructura de archivos (desglose de módulos) basada en el diseño de clases (p. ej., models/, services/, ui/).
3. Preparar un borrador de diagrama ER (tablas y claves primarias).

■ Próxima semana: Diseño de base de datos (diagramas ER) y mapeo a persistencia

La próxima semana trasladaremos las estructuras establecidas en UML a diseños de base de datos (diagramas ER). Diseñaremos tablas y un plan simple de migración. Entender cómo persisten los atributos de clase en la base de datos es una habilidad práctica clave. El trabajo de diseño UML de hoy será la base—¡vengan preparados!

En la Semana 34, el estudiantado utilizó UML para visualizar tanto “qué construir” como “cómo se comporta”. A través de los diagramas de diseño, experimentaron la importancia del consenso previo a la implementación y dejaron preparadas bases sólidas para la siguiente etapa: el diseño de datos.