Guía completa sobre diagramas de clases UML (Diagrama como código)

💡 Nota: Todos los diagramas se proporcionan en PlantUML formato. Puedes renderizarlos de inmediato usando el Visual Paradigm Diagrama como código.

🔹 Introducción a UML

¿Qué es UML?

“El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual de propósito general que se utiliza para especificar, visualizar, construir y documentar los artefactos de un sistema de software.” — Rumbaugh et al., 1999

Características clave:

• 🎨 Notación visual: Sintaxis gráfica para modelar sistemas

• 📐 Estandarizado: Estándar adoptado por OMG desde 1997

• 🔧 Lenguaje, no un método: Define notación, no proceso

• 🌐 Alcance amplio: Modela procesos de negocio, funciones del sistema, estructuras de código y esquemas de bases de datos

Lo que UML NO ES

🔹 Historia y estandarización

Línea de tiempo de evolución

1965-1970: Simula-67 (primer lenguaje orientado a objetos)
     ↓
Años 70-80: Smalltalk en Xerox PARC
     ↓
1984: C++ presentado por Bjarne Stroustrup
     ↓
1988-1992: Proliferación de métodos orientados a objetos (Booch, OMT, OOSE, etc.)
     ↓
1994: Rumbaugh se une a Booch en Rational → Comienza la unificación
     ↓
1995: Se publica el borrador UML 0.8
     ↓
1996: OMG emite una solicitud de propuesta para un lenguaje estándar de modelado
     ↓
1997: UML 1.1 adoptado por OMG (14 de noviembre)
     ↓
2000: UML 1.3 publicado formalmente
     ↓
2003: UML 1.5 publicado; se acepta la superestructura de UML 2.0

¿Por qué UML ganó la “guerra de métodos”

• Consolidó más de 50 métodos OO competidores en un solo estándar

• Apoyado por grandes actores de la industria (IBM, Microsoft, Oracle, HP)

• Ofreció mecanismos de extensión para personalización

• Se convirtió en el estándar de facto para el modelado orientado a objetos

⚠️ Perspectiva crítica: Algunos argumentan que UML es “un lenguaje monstruoso diseñado por un comité” con semánticas imprecisas en sus primeras versiones.

🔹 Clases y atributos

Estructura de clase

Una clase UML se representa como un rectángulo con hasta tres compartimentos.

@startuml
class Student {
  firstName: String
  lastName: String
  email[0..1]: String
  encryptedPW: String
  + totalPoints(): Integer
  + setPassword(pw: String)
  + checkPW(pw: String): Boolean
}
@enduml

Sintaxis de declaración de atributos

[visibilidad] nombre[multiplicidad]: Tipo [= valorPorDefecto] {propiedades}

Ejemplos de PlantUML:

@startuml
class Student {
  + ProgramOfStudy[0..2]: String = "MIS"
  - encryptedPW: String {frozen}
  # internalID: Integer
  ~ packagePrivateData: String
}
@enduml

Alcance del atributo

• Alcance de instancia (predeterminado): Cada objeto tiene su propio valor

• Alcance de clase (estático): Valor único compartido por todas las instancias

@startuml
class Student {
  name: String
  {static} count: Integer
}
@enduml

Claves en UML ⚠️

Limitación importante: UML no tiene una noción incorporada de claves. Use estereotipos o valores etiquetados como soluciones alternativas.

@startuml
class Student {
  {pk} id: Integer
  {ak1} email: String
  - name: String
}
@enduml

🔹 Asociaciones y relaciones

Asociación básica y multiplicidad

@startuml
class Exercise
class Chapter
Exercise "0..*" -- "1..1" Chapter : PerteneceA
@enduml

Interpretación: Cada ejercicio pertenece a exactamente un capítulo; un capítulo puede contener cero o más ejercicios.

Nombres de rol

En lugar de (o además de) los nombres de asociación, use nombres de rol en los extremos de la asociación:

@startuml
class Person
class Company
Person "0..*" --> "0..1" Company : Empleado/Empleador
@enduml

Implementación: El Persona tabla tendría una clave foránea empleador referenciando Empresa.

Navegabilidad

Especifique la dirección de recorrido con flechas:

@startuml
class Ejercicio
class Capítulo
Ejercicio "0..*" --> "1" Capítulo
@enduml

• La flecha indica la dirección eficiente de recorrido

• En OODBs: se implementa como puntero en una sola dirección

• En RDBMS: las uniones funcionan en ambos sentidos independientemente

Tipos de colección con {ordenado}


@startuml
class Capítulo
class Ejercicio
Capítulo "1" -- "0..*" Ejercicio : {ordenado}
@enduml

• {ordenado}: Mantenga el orden (use una lista, no un conjunto)

• Implementación en RDBMS: Agregar un atributo de número de secuencia

EJERCICIOS (
    id PRIMARY KEY,
    chapter_id REFERENCIA CAPÍTULOS,
    sort_no INTEGER,
    UNIQUE (chapter_id, sort_no)
)

Calificadores

Los calificadores dividen objetos relacionados utilizando un mecanismo similar a una clave:

@startuml
class Chapter
class Exercise
Chapter "1" --> "0..1" Exercise : <<calificador>> no: Integer
@enduml

Significado: Dado un Capítulo y un número de ejercicio, se devuelve como máximo un Ejercicio.

Clases de asociación

Cuando una asociación tiene atributos o operaciones:

@startuml
class Student
class Exercise
class Solution {
  date: Date
  points: Integer
}
Student "0..*" -- "0..*" Exercise : ha resuelto
Solution .. Student
Solution .. Exercise
@enduml

• Uno Solución objeto por par (Estudiante, Ejercicio)

• Impone: el mismo estudiante no puede enviar dos soluciones para el mismo ejercicio

Composición frente a agregación

@startuml
class Capítulo
class Ejercicio
Capítulo *-- "0..*" Ejercicio : Composición
Capítulo o-- "0..*" Ejercicio : Agrupación
@enduml

🔹 Operaciones y métodos

Sintaxis de declaración de operación

@startuml
class Calculadora {
  + getTotal(idEstudiante: Integer, inclExtra: Boolean = true): Float {isQuery=true}
  + {static} getInstance(): Calculadora
  + {constructor} Calculadora(valorInicial: Float)
  - recalculate(): void
}
@enduml

Especificación de parámetros:

[dirección] nombre: Tipo [= valorPorDefecto]

• Direcciones: entrada (predeterminado), salida, entrada/salida

• Los valores predeterminados permiten parámetros opcionales

Estereotipos especiales de operación

Operaciones en contexto de base de datos

El choque cultural: La programación orientada a objetos enfatiza la encapsulación; el modelo relacional enfatiza el acceso directo a los datos.

Estrategias de implementación:

🔹 Generalización e herencia

Generalización básica

@startuml
class Persona
class Estudiante
class Profesor
Persona <|-- Estudiante
Persona <|-- Profesor
@enduml

Clases abstractas y operaciones

@startuml
clase abstracta Cuenta {
  - saldo: Float
  + depositar(cantidad: Float): void
  + {abstracto} retirar(cantidad: Float): void
}
@enduml

Restricciones de generalización

@startuml
class Persona
class Estudiante
class Profesor
class OtraPersona
Persona <|-- Estudiante : <<{disjunta, completa}>>
Persona <|-- Profesor : <<{disjunta, completa}>>
Persona <|-- OtraPersona : <<{disjunta, completa}>>
@enduml

Clasificación múltiple / Discriminadores

@startuml
class Empleado
class Personal
class Facultad
class HMO
class NoHMO
Empleado <|-- Personal : <<tipo>>
Empleado <|-- Facultad : <<tipo>>
Empleado <|-- HMO : <<seguro>>
Empleado <|-- NoHMO : <<seguro>>
@enduml

• Los discriminadores agrupan especializaciones mutuamente excluyentes

• Los objetos pueden tener un valor por dimensión de discriminador

🔹 Mecanismos de extensión

UML proporciona tres mecanismos de extensibilidad:

1. Estereotipos<< >>

Extiende la semántica de UML creando nuevos «subtipos» de elementos del metamodelo.

@startuml
class Cliente <<entidad>> {
  - id: Integer
  - nombre: String
}
class BibliotecaMatemática <<utilidad>> {
  + sin(x: Float): Float
  + cos(x: Float): Float
}
@enduml

2. Valores etiquetados{clave=valor}

Agrega propiedades personalizadas a los elementos del modelo.

@startuml
class Student {
  {author=sb, version=1.0, persistence=persistent}
  - id: Integer
}
@enduml

3. Restricciones {...}

Agregue restricciones semánticas usando texto libre, OCL o abreviaturas predefinidas.

@startuml
class Exercise {
  - no: Integer
  - points: Integer {value >= 0}
  {points <= maxPoints}
}
@enduml

🔹 UML para el diseño de bases de datos: Consideraciones clave

Traducción de UML a esquema relacional

Diferencias críticas: Orientado a objetos vs. Relacional

Recomendaciones prácticas para diseñadores de bases de datos

1. Modelar explícitamente las claves: Usa {pk}, {ak1} esteriotipos ya que UML no tiene soporte nativo para claves

2. Marca persistencia: Usa {persistent} valor etiquetado para distinguir las clases de base de datos de las clases de aplicación transitorias

3. Simplifica operaciones: Mapea operaciones de consulta a vistas; operaciones complejas a procedimientos almacenados

4. Maneja la herencia con cuidado: Elige la estrategia de mapeo según los patrones de consulta

5. Documenta restricciones: Usa OCL o restricciones en texto claro para reglas de negocio

6. Usa clases de asociación con juicio: Solo cuando la relación tiene atributos significativos

🎯 Hoja de referencia rápida

Resumen de la notación de diagramas de clases de PlantUML

@startuml
class <<esteriotipo>> NombreClase {
  {etiquetado=valor}
  [+/-/#/~] nombre[mult]: Tipo [= val] {props}
  [+/-/#/~] nombre(params): Ret {props}
}
@enduml

Notación de asociación

@startuml
ClaseA "multA" -- "multB" ClaseB : NombreAsociacion
ClaseA *-- ClaseB  ' Composición
ClaseA o-- ClaseB  ' Agregación
ClaseA --> ClaseB  ' Navegable
@enduml

Símbolos de visibilidad

• + Público

• - Privado

• # Protegido

• ~ Paquete

Propiedades y restricciones comunes

• {estático} / {esConsulta=true} / {abstracto}

• {valor >= 0} / {xor} / {ordenado} / {clave primaria}

💡 Pensamiento final: Los diagramas de clases UML son potentes para el modelado conceptual, pero recuerda que fueron diseñados principalmente para la ingeniería de software. Al utilizar UML para el diseño de bases de datos, prepárate para ampliar la notación (con estereotipos, valores etiquetados, restricciones) para capturar conceptos relacionales como claves, normalización y restricciones declarativas que no son nativas en la fundación orientada a objetos de UML.

Guía compilada a partir de «Parte 6: Diagramas de clases UML» por Stefan Brass, Universidad de Halle, 2003. Todos los diagramas formateados en sintaxis PlantUML para compatibilidad con herramientas modernas.