El diagrama de objetos es un diagrama UML de estructura que muestra instancias concretas de clases y enlaces entre esas instancias en un momento determinado. Mientras el diagrama de clases describe tipos generales, el diagrama de objetos muestra ejemplos específicos.
Este tipo de diagrama es útil para comprobar si un modelo de clases permite representar casos reales. También sirve para explicar situaciones concretas, validar multiplicidades, aclarar relaciones y mostrar valores de atributos sin agregar complejidad al diagrama de clases.
Una clase describe una estructura general. Un objeto es una instancia concreta de esa clase. Por ejemplo, Cliente es una clase; clienteAnaLopez puede ser un objeto concreto con nombre, documento, correo y teléfono. Pedido es una clase; pedido1001 puede ser un objeto particular con fecha, estado e importe total.
La diferencia es similar a la diferencia entre un molde y una pieza creada a partir de ese molde. La clase define qué datos y comportamientos pueden existir; el objeto tiene valores concretos en un momento determinado.
Un objeto se representa con un rectángulo cuyo nombre suele escribirse subrayado. Puede indicarse como nombreObjeto:Clase. Los atributos pueden mostrarse con valores concretos. Los enlaces entre objetos representan instancias de asociaciones definidas en el diagrama de clases.
La notación más común para un objeto es nombreObjeto:Clase. Por ejemplo, cliente1:Cliente, pedido1001:Pedido o turno45:Turno. También se puede omitir el nombre del objeto y dejar solo la clase, como :Cliente, cuando el nombre concreto no importa.
El subrayado permite distinguir objetos de clases. En HTML no siempre se representa visualmente en texto, pero en herramientas UML suele aparecer el encabezado del objeto subrayado.
Un diagrama de objetos puede incluir valores concretos de atributos. Esto ayuda a explicar una situación específica. Por ejemplo, un objeto turno45:Turno puede tener fecha = 2026-06-10, hora = 09:30 y estado = reservado.
No es obligatorio mostrar todos los atributos. Conviene incluir solo los valores relevantes para el ejemplo que se desea comunicar. Si se agregan demasiados datos, el diagrama pierde claridad.
Un enlace es una conexión concreta entre objetos. Si en el diagrama de clases existe una asociación entre Cliente y Pedido, en el diagrama de objetos puede aparecer un enlace entre cliente1:Cliente y pedido1001:Pedido.
Los enlaces muestran una situación real o posible del sistema en un momento determinado. Por eso son útiles para validar si las asociaciones del diagrama de clases tienen sentido.
El diagrama de objetos se entiende mejor cuando existe un diagrama de clases de referencia. Las clases indican qué tipos existen y qué asociaciones son válidas. El diagrama de objetos muestra una configuración concreta compatible con ese modelo.
Si un diagrama de objetos muestra un enlace imposible según el diagrama de clases, hay una inconsistencia. Puede estar mal el ejemplo, puede faltar una relación en el modelo de clases o puede existir una regla no representada todavía.
Una utilidad importante del diagrama de objetos es validar multiplicidades. Si el diagrama de clases dice que un Pedido debe tener una o más LíneasDePedido, un ejemplo de pedido sin líneas no sería válido. Si el ejemplo aparece porque representa una situación real, entonces quizá la multiplicidad del modelo debe revisarse.
Este tipo de validación permite encontrar errores tempranos. Muchas veces, al crear ejemplos concretos, aparecen casos que el modelo general no contemplaba.
Los objetos pueden representar una fotografía del sistema en un momento. Por ejemplo, un pedido puede estar pendiente de pago, otro puede estar confirmado y otro puede estar cancelado. El diagrama de objetos puede mostrar esos valores para explicar situaciones distintas.
Esto no reemplaza al diagrama de estados. El diagrama de objetos muestra una configuración puntual; el diagrama de estados muestra los estados posibles y las transiciones entre ellos.
En un sistema de turnos médicos, un diagrama de objetos puede mostrar una situación concreta: paciente1:Paciente llamado Ana López, profesional1:Profesional llamado Dr. García y turno45:Turno con fecha, hora y estado reservado. Los enlaces indicarían que ese turno pertenece a ese paciente y está asignado a ese profesional.
Este ejemplo permite comprobar si las relaciones definidas en el diagrama de clases son suficientes para representar una reserva real.
En un sistema de ventas, un diagrama de objetos puede mostrar un cliente, un pedido, dos líneas de pedido y dos productos. El pedido tendría un estado, una fecha y un total. Cada línea tendría una cantidad y estaría vinculada a un producto.
Este ejemplo ayuda a validar reglas como: un pedido pertenece a un cliente, un pedido tiene una o más líneas, y cada línea se refiere a un producto.
Conviene usar diagramas de objetos cuando se necesita explicar una situación concreta. También son útiles para validar un modelo de clases, analizar ejemplos de prueba, revisar multiplicidades y mostrar datos de ejemplo durante una discusión de análisis o diseño.
No siempre son necesarios. Si el diagrama de clases es simple y no hay dudas sobre sus relaciones, puede no hacer falta crear un diagrama de objetos. Su valor aparece cuando el ejemplo concreto aclara algo que el modelo general deja ambiguo.
| Aspecto | Diagrama de clases | Diagrama de objetos |
|---|---|---|
| Representa | Tipos generales. | Instancias concretas. |
| Relaciones | Asociaciones entre clases. | Enlaces entre objetos. |
| Atributos | Nombres y tipos. | Valores específicos. |
| Uso principal | Definir estructura general. | Explicar o validar un ejemplo concreto. |
Un objeto anónimo se representa sin nombre, solo con su clase. Por ejemplo, :Producto. Esto se usa cuando no importa identificar al objeto individual, sino mostrar que existe una instancia de cierta clase.
Los objetos anónimos pueden simplificar el diagrama, pero si se necesitan varias instancias de la misma clase, conviene nombrarlas para evitar confusión.
Cuando una relación permite muchos objetos, el diagrama puede mostrar varias instancias concretas. Por ejemplo, un pedido con dos líneas de pedido. No hace falta mostrar todas las instancias posibles; alcanza con las necesarias para explicar el caso.
Si el objetivo es mostrar una colección grande, puede usarse una representación parcial o una nota aclaratoria. Lo importante es no perder legibilidad.
Los diagramas de objetos pueden ayudar a pensar casos de prueba. Una configuración de objetos puede representar el estado inicial necesario para probar una operación. Otra configuración puede representar el resultado esperado después de ejecutarla.
Por ejemplo, antes de cancelar un turno, el objeto Turno puede tener estado reservado. Después de la operación, puede tener estado cancelado. Este razonamiento ayuda a conectar modelo, comportamiento y verificación.
El diagrama de objetos permite bajar un modelo general a ejemplos concretos. Al mostrar instancias, valores y enlaces, ayuda a comprobar si el diagrama de clases representa correctamente situaciones reales o posibles del sistema.
En el próximo tema veremos diagramas de paquetes, que permiten organizar modelos y dependencias entre módulos o grupos de elementos.