Diagramas UML para GSI: los 14 tipos y las relaciones del diagrama de clases
Este artículo pertenece al Bloque III, tema 9 del temario de las oposiciones GSI: «Análisis y diseño orientado a objetos. Elementos. El proceso unificado de software. El lenguaje de modelado unificado (UML). Patrones de diseño». Nos centramos en un punto que aparece una y otra vez en los tests: qué diagramas tiene UML, cómo se clasifican y qué relaciones se dibujan en un diagrama de clases.
La idea es que, al terminar, puedas responder sin dudar preguntas del tipo «¿cuál de los siguientes NO es un diagrama de comportamiento?» o «¿qué relación implica que la parte no existe sin el todo?».
Qué es UML y por qué cae en el examen
UML (Unified Modeling Language) es un lenguaje gráfico de modelado, no una metodología ni un lenguaje de programación. Lo mantiene el OMG (Object Management Group) y su versión vigente es la serie 2.5. Sirve para especificar, visualizar, construir y documentar los artefactos de un sistema software.
Este matiz es la primera trampa habitual: UML dice cómo dibujar el modelo, pero no en qué orden trabajar. El proceso lo aporta una metodología, como el Proceso Unificado (y su variante comercial más conocida, RUP), que sí está dirigido por casos de uso, centrado en la arquitectura, y es iterativo e incremental.
Los 14 diagramas de UML 2.5
UML 2.5 define 14 tipos de diagrama, repartidos en dos grandes familias: estructura (lo estático: qué piezas hay) y comportamiento (lo dinámico: qué hacen y cuándo). Dentro del comportamiento existe una subfamilia, los diagramas de interacción, que muestran el intercambio de mensajes entre objetos.
| Familia | Diagrama | Para qué sirve |
|---|---|---|
| Estructura | Clases | Clases, atributos, operaciones y relaciones entre ellas |
| Estructura | Objetos | Una «foto» de instancias concretas en un momento dado |
| Estructura | Componentes | Piezas reemplazables del sistema y sus interfaces |
| Estructura | Estructura compuesta | Estructura interna de una clase y sus colaboraciones |
| Estructura | Paquetes | Agrupación lógica de elementos y dependencias entre grupos |
| Estructura | Despliegue | Nodos físicos (servidores, dispositivos) y artefactos instalados |
| Estructura | Perfiles | Extensiones de UML mediante estereotipos |
| Comportamiento | Casos de uso | Funcionalidad vista desde los actores |
| Comportamiento | Actividad | Flujos de trabajo, con decisiones y paralelismo |
| Comportamiento | Máquina de estados | Estados de un objeto y transiciones por eventos |
| Comportamiento (interacción) | Secuencia | Mensajes ordenados en el tiempo (líneas de vida) |
| Comportamiento (interacción) | Comunicación | Mensajes numerados, destacando los enlaces entre objetos |
| Comportamiento (interacción) | Tiempos | Cambios de estado en un eje temporal preciso |
| Comportamiento (interacción) | Visión global de la interacción | Flujo de alto nivel que combina interacciones |
Truco de memoria: siete y siete. Siete de estructura (Clases, Objetos, Componentes, Estructura compuesta, Paquetes, Despliegue, Perfiles) y siete de comportamiento, de los que cuatro son de interacción (Secuencia, Comunicación, Tiempos, Visión global).
Errores típicos al clasificar
- El diagrama de casos de uso es de comportamiento, aunque no muestre secuencia temporal. Es una de las preguntas trampa más repetidas.
- El diagrama de comunicación es el antiguo «diagrama de colaboración» de UML 1.x. Si en una opción aparece el nombre antiguo, piensa en interacción.
- El diagrama de despliegue es estructural: muestra hardware y dónde se instala el software, no cómo se comporta.
- Secuencia y comunicación expresan la misma información; cambian el énfasis (tiempo frente a enlaces).
Relaciones en el diagrama de clases
El diagrama de clases es el más preguntado con diferencia, y dentro de él lo que más cae son las relaciones. Conviene distinguirlas por su notación y por su significado.
| Relación | Notación | Significado | Ejemplo |
|---|---|---|---|
| Asociación | Línea continua (con multiplicidad) | Dos clases se conocen y colaboran | Cliente — Pedido |
| Agregación | Línea con rombo vacío en el todo | Todo-parte débil: la parte puede existir sola | Departamento ◇— Empleado |
| Composición | Línea con rombo relleno en el todo | Todo-parte fuerte: la parte muere con el todo | Factura ◆— LíneaFactura |
| Generalización | Línea continua con triángulo vacío hacia el padre | Herencia («es un») | Funcionario → Persona |
| Realización | Línea discontinua con triángulo vacío | Una clase implementa una interfaz | ServicioPDF ⇢ IExportable |
| Dependencia | Línea discontinua con flecha abierta | Uso puntual: un cambio en una puede afectar a la otra | Informe ⇢ Calendario |
Agregación frente a composición
Es la distinción que más fallos provoca. Hazte una sola pregunta: si borro el todo, ¿desaparecen las partes?
- Si la respuesta es sí, es composición. Una línea de factura no tiene sentido sin la factura; además, una parte pertenece a un único todo a la vez.
- Si la respuesta es no, es agregación. Si se suprime un departamento, sus empleados siguen existiendo y pueden reasignarse.
Multiplicidad
La multiplicidad indica cuántas instancias participan en la asociación. Las más habituales son 1 (exactamente uno), 0..1 (opcional), * o 0..* (cero o muchos) y 1..* (al menos uno). Lee siempre la multiplicidad desde el extremo opuesto: «un cliente tiene 0..* pedidos; un pedido pertenece a 1 cliente».
Visibilidad de atributos y operaciones
+público-privado#protegido~paquete
Relaciones en el diagrama de casos de uso
Otra fuente segura de preguntas. Entre casos de uso hay dos relaciones con estereotipo, y su dirección es contraintuitiva:
- «include»: el caso base siempre ejecuta el caso incluido. La flecha va del caso base al incluido. Ejemplo: «Presentar solicitud» incluye «Identificarse con certificado».
- «extend»: el caso extensor añade comportamiento opcional en un punto de extensión. La flecha va del caso extensor al caso base. Ejemplo: «Adjuntar documentación adicional» extiende «Presentar solicitud».
- Entre actores y entre casos de uso también puede haber generalización (por ejemplo, «Funcionario» y «Ciudadano» heredan de «Usuario»).
Ejemplo práctico: sede electrónica de solicitudes
Imagina que te piden modelar un servicio de presentación de solicitudes en una sede electrónica. Así repartirías el trabajo entre diagramas:
- Casos de uso: actores Ciudadano y Tramitador; casos «Presentar solicitud», «Consultar estado», «Resolver solicitud».
- Clases: Solicitud compuesta por Documentos (composición), asociada a un Interesado (
1a0..*). - Secuencia: el ciudadano envía el formulario, la sede llama al servicio de firma, se registra la entrada y se devuelve el justificante.
- Máquina de estados: la Solicitud pasa por Borrador → Presentada → En trámite → Resuelta.
- Despliegue: servidor web en DMZ, servidor de aplicaciones y servidor de base de datos en la red interna.
Fíjate en que cada diagrama responde a una pregunta distinta: quién usa el sistema, qué datos hay, en qué orden ocurren las cosas, cómo evoluciona un objeto y dónde se ejecuta todo.
Pregunta tipo test de ejemplo
¿Cuál de los siguientes diagramas de UML 2.5 es un diagrama de interacción?
- a) Diagrama de máquina de estados.
- b) Diagrama de despliegue.
- c) Diagrama de tiempos.
- d) Diagrama de casos de uso.
Respuesta correcta: c). El diagrama de tiempos es uno de los cuatro diagramas de interacción, junto con secuencia, comunicación y visión global de la interacción. La a) y la d) son de comportamiento, pero no de interacción; la b) es un diagrama de estructura. El distractor peligroso es la a): al hablar de «estados» y «transiciones» parece temporal, pero se clasifica como comportamiento general.
Resumen para repasar
- UML es un lenguaje de modelado del OMG, no una metodología; el Proceso Unificado sí lo es.
- UML 2.5 tiene 14 diagramas: 7 de estructura y 7 de comportamiento, de los cuales 4 son de interacción.
- Interacción = secuencia, comunicación, tiempos y visión global.
- Casos de uso es de comportamiento; despliegue es de estructura.
- Rombo vacío = agregación (la parte sobrevive); rombo relleno = composición (la parte muere con el todo).
- Triángulo vacío con línea continua = generalización; con línea discontinua = realización.
- «include» es obligatorio y apunta al incluido; «extend» es opcional y apunta al caso base.
Practica UML con tests y flashcards
Clasificar diagramas y reconocer relaciones se aprende repitiendo, no releyendo. En PreparaGSI tienes tests con explicación, flashcards con repetición espaciada y audios de todo el temario. Regístrate gratis y empieza hoy a repasar el Bloque III.