Diagramas de clases UML para modelado de datos con PlantUML

Un diagrama de clases UML describe la estructura de un sistema: las cosas que modela, sus propiedades y cómo se relacionan. Para el modelado de datos, puede capturar conceptos y restricciones del dominio antes de comprometerse con tablas o código de aplicación.

PlantUML hace que el diagrama sea reproducible: escribes texto, lo renderizas, revisas los cambios en el control de versiones y lo actualizas a medida que evoluciona el modelo. Complementa, no reemplaza, los esquemas de base de datos, las migraciones y las reglas de negocio detalladas.

1. Elige el nivel de modelado

Un diagrama de modelado de datos útil generalmente se centra en un nivel a la vez:

• Conceptual: conceptos y relaciones de negocio, con un mínimo de detalle técnico. Ejemplo: Cliente realiza Pedido.

• Lógico: atributos, identificadores, multiplicidades y reglas, sin vincular el modelo a una base de datos específica.

• Físico: detalles de implementación como tipos de columnas SQL, índices y restricciones específicas de la base de datos.

El ejemplo a continuación es un modelo de dominio lógico. Tipos como UUID, Money, y DateTime son ilustrativos; decide sus representaciones concretas al elegir una tecnología.

2. Fundamentos de PlantUML

Una clase tiene un nombre y puede listar atributos y operaciones:

@startuml
class Customer {
  -id: UUID
  +name: String
  +email: String
  +changeEmail(newEmail: String): void
}
@enduml

Los marcadores de visibilidad son sugerencias de modelado opcionales:

• + público

• - privado

• # protegido

• ~ visibilidad de paquete

Para un diagrama de dominio o de datos, los atributos son lo más importante. Incluya operaciones solo cuando aclaren comportamientos importantes; evite convertir el diagrama en una lista completa de código.

3. Relaciones y multiplicidad

Las notaciones de relación más útiles para el modelado de datos son:

Las etiquetas de multiplicidad se sitúan cerca de los extremos de la asociación:

• 1 — exactamente uno

• 0..1 — opcional, como máximo uno

• * o 0..* — cero o más

• 1..* — uno o más

• 2..5 — un rango acotado

Por ejemplo:

Cliente "1" -- "0..*" Pedido : coloca

Lea cuidadosamente las etiquetas en cada extremo: un cliente puede realizar cero o más pedidos; cada pedido está asociado con exactamente un cliente. Las etiquetas describen la relación, no necesariamente la implementación de clave foránea de una base de datos en particular.

4. Ejemplo resuelto: tienda en línea

Este modelo incluye clientes, pedidos, líneas de pedido, productos y registros de pago. Demuestra identificadores, tipos similares a valores, un enumerado, composición y multiplicidades.

@startuml ShopDomain
skinparam classAttributeIconSize 0
skinparam shadowing false

hide methods

class Customer {
  +customerId: UUID
  +email: EmailAddress
  +displayName: String
}

class Order {
  +orderId: UUID
  +placedAt: DateTime
  +status: OrderStatus
  +total: Money
}

class OrderLine {
  +lineNumber: Integer
  +quantity: PositiveInteger
  +unitPrice: Money
}

class Product {
  +productId: UUID
  +sku: SKU
  +name: String
  +currentPrice: Money
}

class Payment {
  +paymentId: UUID
  +amount: Money
  +status: PaymentStatus
  +paidAt: DateTime [0..1]
}

class Money <<value object>> {
  +amount: Decimal
  +currency: CurrencyCode
}

enum OrderStatus {
  DRAFT
  PLACED
  PAID
  FULFILLED
  CANCELLED
}

enum PaymentStatus {
  PENDING
  AUTHORIZED
  CAPTURED
  FAILED
  REFUNDED
}

Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "0..*" --> "1" Product : refers to
Order "1" -- "0..*" Payment : payment attempts
Order --> OrderStatus
Payment --> PaymentStatus
OrderLine --> Money : unit price
Payment --> Money : amount

note right of OrderLine
  quantity must be greater than zero
  unitPrice is the price captured
  when the order is placed
end note

note right of Product
  Product.currentPrice may change.
  It does not replace OrderLine.unitPrice.
end note
@enduml

¿Por qué modelar OrderLine explícitamente? La relación entre un pedido y un producto tiene sus propios datos: cantidad y el precio en el momento de la compra. Esto lo convierte en un concepto de dominio, no solo en un enlace simple.

¿Por qué composición desde Order a OrderLine? El ejemplo asume que una línea de pedido pertenece a un pedido y no tiene significado independiente. Utilice la composición solo cuando esa regla de propiedad y ciclo de vida sea cierta en su dominio; la notación UML no la impone en la base de datos.

¿Por qué distinguir entre precios actuales e históricos? El precio de un producto puede cambiar después de que se realiza un pedido. Mantener el precio del momento de la compra en la línea de pedido conserva el monto histórico.

5. Decisiones de modelado que importan

Identificadores: Marque los identificadores de manera consistente, como customerId o orderId. UML no define una notación universal única para claves primarias, por lo que elige una convención y documentala. Un estereotipo o una nota pueden hacerlo explícito:

class Customer {
  +customerId: UUID <<PK>>
  +email: EmailAddress
}

Valores opcionales: Usa [0..1] para un atributo opcional cuando esto sea claro para tus lectores, o anota la regla. Por ejemplo, un pago puede no tener paidAt marca de tiempo hasta que tenga éxito.

Objetos de valor: Un tipo como Money o EmailAddress puede representar un concepto con validación o semántica propia. Decide si debe aparecer como una clase separada, un tipo de atributo o una estructura de base de datos según la audiencia y el nivel de detalle.

Enumeraciones y valores controlados: Usa una enumeración cuando el conjunto permitido sea pequeño y relativamente estable. Si los valores necesitan descripciones independientes, ciclo de vida o administración, modelalos como una clase en su lugar.

Normalización e implementación: Un diagrama de clases comunica conceptos y reglas; no resuelve cada detalle relacional. Por ejemplo, si Money se convierte en dos columnas, una tabla separada o un tipo específico de base de datos es una decisión de implementación.

Mantén los diagramas legibles: Divide un dominio grande en diagramas enfocados—como pedidos, inventario e identidad—y usa paquetes para agrupar clases relacionadas. Muestra solo los atributos relevantes para la pregunta que el diagrama debe responder.

6. Construye un modelo a partir de los requisitos

1. Extrae conceptos candidatos del lenguaje del dominio: los sustantivos a menudo sugieren clases; los verbos a menudo sugieren relaciones o comportamiento.

2. Aclarar reglas con preguntas concretas: ¿Puede existir un pedido sin un cliente? ¿Puede tener cero líneas? ¿Puede reintentarse un pago?

3. Elegir un nivel de modelado y mantener las decisiones técnicas de base de datos fuera de un diagrama conceptual.

4. Agregar atributos e identificadores solo cuando ayudan a explicar el modelo.

5. Establecer multiplicidades de las reglas de negocio, verificando ambos extremos de cada relación.

6. Revisar casos extremos: eliminación, registros históricos, campos opcionales, intentos repetidos y valores cambiantes.

7. Renderizar y revisar el diagrama con expertos del dominio e implementadores. Trátelo como un modelo para validar, no simplemente como una imagen para aprobar.

7. Usar VPasCode y Visual Paradigm

VPasCode es un editor de de texto a diagrama basado en navegador con soporte para PlantUML y una vista previa en vivo. Su descripción de características también incluye la generación y modificación de código de diagramas mediante IA, así como asistencia de sintaxis. Un flujo de trabajo práctico es:

1. Abra VPasCode y seleccione o ingrese PlantUML.

2. Pegue el ejemplo anterior e inspeccione el diagrama renderizado.

3. Itere sobre el código fuente de PlantUML; mantenga el texto como el artefacto versionable.

4. Use el asistente de IA, si está disponible en su espacio de trabajo, para redactar o revisar un primer borrador.

5. Verifique usted mismo cada clase, relación, multiplicidad y regla de negocio generada.

Las herramientas de diagramación asistidas por IA de Visual Paradigm pueden generar diagramas editables a partir de descripciones en lenguaje natural. Su flujo de trabajo publicado describe generar un diagrama de clases a partir de una indicación y luego refinar sus elementos y relaciones. Trate la salida de la IA como unborrador: puede inferir propiedad incorrecta, restricciones faltantes o clases injustificadas. La corrección del modelo aún depende de validarlo contra los requisitos.

Por ejemplo, formule una indicación a un asistente de IA con:

Cree un diagrama de clases UML lógico para una tienda en línea. Los clientes realizan pedidos. Cada pedido contiene una o más líneas de pedido. Cada línea de pedido se refiere a un producto y almacena la cantidad y el precio unitario en el momento de la compra. Los pedidos pueden tener múltiples intentos de pago. Incluya identificadores, multiplicidades y enumeraciones de estado de pedido y pago. Genere solo código PlantUML.

Luego, revise la salida contra los requisitos antes de aceptarla. Para obtener mejores resultados, especifique explícitamente las suposiciones, por ejemplo, si los pedidos pueden ser borradores sin líneas y si los pagos pueden ser reembolsados.

Visual Paradigm describeVPasCode como un editor con capacidad para PlantUML con renderizado en vivo y generación o modificación asistida por IA. Las herramientas y la disponibilidad pueden variar según la versión del producto o el espacio de trabajo.

8. Una lista de verificación de revisión compacta

Antes de compartir o implementar un diagrama de clases, verifique:

• ¿Representa cada clase un concepto de dominio significativo?

• ¿Son claros los identificadores y los atributos importantes?

• ¿Son correctas las etiquetas de relación y las multiplicidades en ambos extremos?

• ¿Refleja la composición una dependencia real del ciclo de vida?

• ¿Se conservan los hechos históricos donde los valores actuales pueden cambiar?

• ¿Son visibles los valores opcionales y las restricciones empresariales?

• ¿Es el diagrama lo suficientemente enfocado para su audiencia?

• ¿Se ha verificado el contenido generado contra los requisitos reales?

El mejor flujo de trabajo de diagramas como código es IA para un borrador inicial, PlantUML para ediciones precisas e historial de versiones, y revisión humana para la corrección del dominio.