Los patrones de diseño se comunican con diagramas: la sección "Estructura" de cualquier catálogo es un diagrama de clases, y las colaboraciones entre objetos se muestran con diagramas de secuencia. Si no lees estos diagramas con fluidez, cada patrón te costará el doble. La buena noticia: no necesitas dominar UML entero (que tiene 14 tipos de diagramas); para este curso bastan dos —clases y secuencia— y un puñado de relaciones. En esta lección aprenderás exactamente ese subconjunto, verás cómo lo dibujaremos con mermaid en el resto del curso, y practicarás con las clases de PideYa que ya conoces. No es un curso de UML: es tu kit de supervivencia para leer patrones.

1. Qué es UML y qué parte necesitamos
2. El diagrama de clases: clases, atributos y métodos
3. Interfaces y clases abstractas
4. Las seis relaciones que debes reconocer
5. El diagrama de secuencia básico
6. Cómo dibujaremos todo esto en el curso: mermaid

UML (Unified Modeling Language) es la notación estándar (desde 1997) para dibujar sistemas orientados a objetos. Es enorme, pero los catálogos de patrones usan una fracción mínima:

Todo lo demás (casos de uso, actividades, estados, despliegue...) queda fuera de este curso. Regla de oro al leer diagramas de patrones: son esquemáticos, no planos de construcción. Muestran los participantes y relaciones esenciales, omitiendo getters, constructores y detalles accesorios.

Una clase se dibuja como una caja con tres compartimentos: nombre, atributos y métodos.

Cómo se lee cada línea:

• Visibilidad (el símbolo inicial): + público, - privado, # protegido, ~ de paquete. En los diagramas de patrones casi siempre verás + en métodos y - en atributos: la encapsulación estándar.
• Atributos: -Long id significa "atributo privado id de tipo Long". En mermaid los genéricos se escriben con ~: List~LineaPedido~ es List<LineaPedido>.
• Métodos: +calcularTotal() double es un método público sin parámetros que devuelve double. El tipo de retorno va al final (en UML clásico se escribe : double; mermaid lo admite sin los dos puntos).
• Un miembro subrayado es estático; en mermaid se marca con $ al final: +getInstancia()$ Pedido. Uno en cursiva es abstracto; en mermaid, con *: +cocinar()*.

En Java, esa caja corresponde a:

Los patrones viven de las abstracciones ("programa contra una interfaz", como vimos en la lección anterior), así que distinguirlas en un diagrama es vital:

• Una interfaz se marca con el estereotipo <<interface>> sobre el nombre.
• Una clase abstracta se marca con <<abstract>> (o el nombre en cursiva, en UML clásico).

Diferencia práctica al leer un patrón: una interfaz solo declara contrato; una clase abstracta puede además aportar código común a sus hijas (como registrarIntento() arriba) dejando abstracto lo variable (procesar, marcado con *). Muchos patrones se apoyan justo en esa combinación.

Aquí está el 80% del valor de esta lección. Toda la "gramática" de los diagramas de patrones son estas seis flechas:

Y así se ven todas juntas sobre clases de PideYa:

Claves para no confundirlas:

• El triángulo siempre apunta a la abstracción (padre o interfaz). Línea continua = herencia de clase; discontinua = implementación de interfaz.
• El rombo va en el lado del "todo", no de la parte. Para distinguir agregación de composición pregúntate: si borro el todo, ¿tiene sentido que la parte siga existiendo? Si el pedido se cancela y borra, sus líneas no significan nada sueltas → composición (rombo relleno). Si el repartidor se da de baja, la moto sigue existiendo en la flota → agregación (rombo vacío).
• Asociación frente a dependencia: asociación es un atributo (referencia que se conserva); dependencia es un uso puntual (parámetro o variable local). En Java: private Cliente cliente; es asociación; generarPdf(Pedido p) es dependencia.
• Las asociaciones pueden llevar multiplicidad: "1" --> "0..*" se lee "un pedido tiene de cero a muchas líneas". En mermaid: Pedido "1" *-- "1..*" LineaPedido.

La correspondencia en Java de las tres relaciones "de tener":

Matiz honesto: en Java la diferencia agregación/composición no la impone el lenguaje (ambas son referencias); es una intención de diseño sobre ciclo de vida y propiedad. En los diagramas de patrones no suele ser crítica: si dudas, léela como "tiene un".

El diagrama de clases dice quién es quién; el de secuencia dice qué pasa cuando el sistema se ejecuta: qué objetos participan, qué mensajes (llamadas a métodos) se envían y en qué orden temporal (el tiempo fluye hacia abajo).

Escenario PideYa: un cliente confirma su carrito y el sistema cobra y notifica.

Elementos que debes reconocer:

• Participantes (arriba): los objetos involucrados. De cada uno cuelga su línea de vida vertical.
• Mensaje síncrono (->>, flecha continua): una llamada a método; el emisor espera la respuesta.
• Respuesta (-->>, flecha discontinua): el valor devuelto.
• Barra de activación (el rectángulo sobre la línea de vida, activate/deactivate): el intervalo en que ese objeto está ejecutando algo.
• Automensaje (SP->>SP): el objeto llama a un método propio.

En los patrones, el diagrama de secuencia responde a la pregunta que el de clases no puede responder: "vale, estas son las clases... pero ¿quién llama a quién y cuándo?". Verás que en varios patrones la estructura de clases es casi idéntica y lo que los distingue es la secuencia; por eso conviene leer ambos siempre.

En este curso todos los diagramas están escritos en mermaid, una notación de texto que se renderiza como diagrama. Ventaja para ti: puedes copiar cualquier diagrama del curso, pegarlo en mermaid.live y modificarlo para experimentar. La chuleta completa de lo que usaremos:

Con esta chuleta puedes leer el 100% de los diagramas de los módulos 2 a 6. Cuando en el módulo 2 veas la estructura de un patrón, ya no estarás descifrando flechas: estarás leyendo diseño.

• Confundir el sentido del triángulo de herencia. El triángulo toca a la abstracción (padre/interfaz). En mermaid, MetodoPagoBase <|-- PagoTarjeta se lee "PagoTarjeta hereda de MetodoPagoBase". Si lo lees al revés, entenderás todos los patrones del revés.
• Confundir el lado del rombo. El rombo va pegado al todo (el contenedor), no a la parte. Pedido *-- LineaPedido: el rombo está en Pedido.
• Intentar que el diagrama lo diga todo. Un diagrama de patrón es un esquema: si no aparecen los getters o el constructor, no es que no existan; es que no importan para entender el patrón. No los añadas al dibujar los tuyos.
• Ignorar la diferencia entre línea continua y discontinua. Continua = relación fuerte y estructural (herencia, asociación); discontinua = relación más débil o de contrato (implementación, dependencia). Este matiz cambia el significado del diagrama.
• Leer solo el diagrama de clases y saltarse el de secuencia. Varios patrones comparten estructura estática casi idéntica; la diferencia está en la dinámica. Acostúmbrate desde ya a leer los dos.
• Consejo: practica el camino inverso. Toma una clase pequeña de un proyecto tuyo y dibújala en mermaid con sus relaciones reales. Dibujar es lo que fija la notación; leer solo, no.

Traduce este diagrama a esqueletos de clases Java (sin implementar los cuerpos):

Dibuja en mermaid (classDiagram) las clases y relaciones de este código, eligiendo bien entre asociación, agregación, composición y dependencia:

Observa el diagrama de secuencia de la sección 5 y responde: (a) ¿qué objeto orquesta el proceso?, (b) ¿en qué momento está activo MetodoPago y qué devuelve?, (c) ¿el mensaje a Notificador espera respuesta según el diagrama? ¿Qué mensaje es un automensaje?

Solución 1:

Solución 2:

Razonamiento: la Carta la crea y posee el restaurante (muere con él) → composición. Los repartidores existen fuera del restaurante y solo se le asocian como favoritos → agregación (una asociación simple --> también sería defendible; lo importante es descartar la composición). GeneradorFacturas y Factura solo aparecen como parámetro y valor de retorno de un método → dependencias.

Solución 3: (a) ServicioPedidos: recibe la petición del cliente y llama a todos los demás. (b) MetodoPago está activo solo entre la llamada procesar(importe) y su respuesta; devuelve un ResultadoPago. (c) Tal como está dibujado, a notificar(...) no se le dibuja flecha de retorno: el diagrama no muestra respuesta (se lee como llamada cuyo resultado no interesa en este escenario). El automensaje es SP->>SP: crearPedido(carrito): ServicioPedidos invocando un método propio.

Ya tienes el kit de lectura de diagramas que usarás en todo el curso: la caja de clase con visibilidades, los estereotipos <<interface>> y <<abstract>>, las seis relaciones (herencia, implementación, asociación, agregación, composición y dependencia, con sus flechas y rombos bien orientados) y el diagrama de secuencia para la dinámica. Además conoces la sintaxis mermaid exacta con la que están escritos todos los diagramas del curso, lista para copiar y experimentar.

Con las herramientas de lectura en la mano, toca desplegar el mapa: ¿cuántos patrones hay, cómo se organizan y qué hace cada familia? Ese mapa —que es también el itinerario de los módulos 2, 3 y 4— es la próxima lección: Clasificación de los Patrones de Diseño.