¿Qué es un diagrama de clases?
Un diagrama de clases es un diagrama estructural diagrama UML que visualiza la arquitectura estática de un sistema de software orientado a objetos. Como un tipo de diagrama UML indispensable, tipo de diagrama UML representa las clases individuales, interfaces y modelos de datos dentro de su aplicación, documentando explícitamente sus campos internos (atributos), funciones operativas (métodos) y las relaciones estructurales que los unen. Este plano es fundamental para los ingenieros de software que necesitan traducir diseños de dominio de alto nivel en estructuras de objetos limpias y mantenibles.
Con Mermaid.js, puedes bosquejar tus modelos de datos y servicios del sistema utilizando definiciones intuitivas basadas en texto. El motor de diseño calcula automáticamente los tamaños de los cuadros, estructura los compartimentos estándar de datos UML y alinea las flechas relacionales en todo tu lienzo sin ninguna sobrecarga de formato manual.
Guía de sintaxis básica: elementos y construcciones
Para diseñar un diagrama de clases UML preciso y conforme a las normas en Mermaid, debes dominar las declaraciones de miembros, los modificadores de acceso y las flechas de relaciones estructurales.
1. Declaración de clases y compartimentos de clases
Puedes definir una clase utilizando dos formatos válidos. Para una clase simple, utiliza la palabra clave classseguida del nombre de la clase. Si deseas incluir campos y métodos de inmediato, utiliza llaves al final para crear un bloque de cuerpo claro:
classDiagram
class UserProfile {
+String username
+String email
+updateEmail(newEmail) void
}
2. Agregar modificadores de visibilidad / acceso
Para documentar las reglas estándar de encapsulación UML, coloca un símbolo específico directamente antes del nombre de tu atributo o método para definir su nivel de visibilidad:
+**Público:** Accesible desde cualquier otra clase.-**Privado:** Accesible solo dentro de la clase que lo declara.#**Protegido:** Accesible dentro de la clase y sus subclases.~**Paquete / Interno:** Accesible dentro de los límites del mismo paquete.
classDiagram
class CuentaBancaria {
-double saldo
#String titularCuenta
+getSaldo() double
}
3. Dominar las flechas de relación y los enlaces de herencia
Para mostrar cómo interactúan las clases dentro de tu modelo de diagrama UML, conecta sus identificadores utilizando cadenas de relación especializadas. En Mermaid, la dirección de la línea importa: la punta de la flecha apunta hacia la clase padre o contenedora.
- Herencia / Generalización (flecha punteada o sólida):
Hijo --|> Padre(Representa una relación de “es-un”). - Realización / Implementación:
Clase ..|> Interfaz(Representa una clase que cumple un contrato de interfaz). - Composición (diamante sólido):
Hijo --* Padre(Representa una propiedad estricta; si el padre muere, el hijo muere). - Agregación (diamante claro):
Hijo --o Padre(Representa una relación de colección suelta; el hijo puede existir de forma independiente). - Dependencia:
ClaseA ..> ClaseB(Representa una referencia temporal en tiempo de ejecución).
classDiagram
Auto --|> Vehículo : "Hereda de"
Motor --* Auto : "Es parte de"
Mejores prácticas para diseños de arquitectura de clases limpias
- Agrupar miembros de clase visualmente:Siempre agrupa tus variables de clase en la parte superior del bloque de cuerpo y tus funciones en la parte inferior. Esta disposición coincide con las estructuras de clases estándar de los IDE y hace que tus diagramas sean inmediatamente legibles.
- Especifique los tipos de retorno: Al declarar métodos, agregue el tipo de retorno al final de la línea del método (por ejemplo,
+fetchData() DataSet). Esto proporciona a tu equipo de ingeniería un contexto de implementación preciso. - Mantenga clara la multiplicidad: Para indicar recuentos de arreglos o tamaños de colecciones, agregue cadenas de texto de multiplicidad directamente al contenedor de la línea de relación (por ejemplo,
Customer "1" --o "many" Order).
Ejemplos reales de diagramas de clases Mermaid.js
Ejemplo 1: Subsistema de dominio de pasarela de pago (Encapsulamiento e Interfaces)
Este plano funcional modela un servicio de dominio de pago en línea. Muestra cómo utilizar modificadores de acceso, agrupar miembros de clase e implementar relaciones de interfaz de forma limpia.
classDiagram
class PaymentProcessor {
<<interface>>
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
class StripeGateway {
-String apiKey
-String endpointUrl
+processPayment(amount) boolean
+refundPayment(txnId) boolean
-logTransaction(status) void
}
class PayPalGateway {
-String merchantId
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
StripeGateway ..|> PaymentProcessor : "Implementa"
PayPalGateway ..|> PaymentProcessor : "Implementa"
Desglose de sintaxis: El <<interface>> etiqueta marca claramente `PaymentProcessor` como un contrato arquitectónico de alto nivel. Las dos clases concretas de implementación de pasarela utilizan campos privados (-apiKey) para credenciales sensibles, mientras expone rutinas de pago públicas (+processPayment) vinculadas mediante la flecha de realización (..|>).
Ejemplo 2: Motor de procesamiento de pedidos empresarial (Composición y multiplicidad)
Este plano avanzado del sistema representa un esquema complejo de gestión de pedidos de comercio electrónico, demostrando cómo documentar la propiedad estructural y los conteos de objetos entre múltiples clases interconectadas.
classDiagram
class Customer {
+int customerId
+String name
+placeOrder() Order
}
class Order {
+int orderId
+Date dateCreated
-String internalStatus
+calculateTotal() double
}
class OrderItem {
+int itemId
+int quantity
+double pricePerUnit
}
class Address {
+String street
+String city
+String postalCode
}
Customer "1" --o "many" Order : "posee"
OrderItem "1..*" --* "1" Order : "compone"
Address "1" --> Order : "envía a"
Desglose de sintaxis: Este ejemplo ilustra la diferencia entre agregación y composición. La flecha de diamante sólido (--*) muestra que un `OrderItem` está fuertemente vinculado a un `Order` (si se elimina un pedido, sus artículos individuales también se destruyen). Por el contrario, la flecha de diamante clara (--o) indica que un `Customer` posee múltiples pedidos, pero ambas entidades pueden existir de forma independiente. Las cadenas de multiplicidad (como "1..*") definen los requisitos relacionales del sistema.