Estamos encantados de anunciar el lanzamiento oficial de Visual Paradigm VPasCode, la nueva y unificada diagrama como código plataforma. Ya sea que sea un ingeniero de software, arquitecto de sistemas o analista de negocios, VPasCode está diseñado para optimizar su flujo de trabajo transformando texto en diagramas profesionales y hermosos en cuestión de segundos.
Diga adiós al cambio de contexto entre diferentes herramientas. VPasCode reúne sus lenguajes de texto a diagrama de código abierto favoritos en un único entorno web unificado, fluido y potente.
¿Qué es VPasCode?
VPasCode (Visual Paradigm como Código) es un entorno integrado que combina un editor de código conveniente y gratuito editor de código con un renderizador de diagramas de alto rendimiento. Si ama la velocidad y los beneficios de control de versiones al escribir sus diagramas, VPasCode le ofrece el entorno sandbox definitivo para crear, previsualizar y compartirlos al instante.
Por ser un entorno totalmente integrado, VPasCode teóricamente soporta todaslas reglas de sintaxis de los motores de diagramación más populares del mundo. En el lanzamiento, damos soporte completo a:
- Editor y Renderizador PlantUML: Cree diagramas robustos de arquitectura empresarial y de software.
- Editor y Renderizador Mermaid.js: Renderice gráficos y líneas de tiempo modernos inspirados en Markdown de forma nativa en su navegador.
- Editor y Renderizador Graphviz: Aproveche el poder del lenguaje DOT para estructuras de red y datos complejas.
…¡y esto es solo el comienzo! Continuamente añadiremos más formatos de texto a diagrama en el futuro.

Tipos de Diagramas Soportados de un Vistazo
VPasCode soporta una biblioteca increíblemente vasta de tipos de diagramas. Aquí tiene una instantánea de lo que puede construir ahora mismo:
Integración PlantUML
- Diagramas de Secuencia, Casos de Uso, Clases y Objetos
- Diagramas de Actividad, Componentes, Despliegue y Estado
- Modelos ArchiMate y C4
- Diagramas de Relación de Entidades (ERD) & ERD de Chen
- Diagramas de Red, EAP (Estructura de Desglose de Trabajo) y Diagramas de Cronograma
Integración de Mermaid.js
- Diagramas de Flujo, de Clases y de Secuencia
- Diagramas de Relación de Entidades (ERD) & Diagramas de Estado
- Mapas Mentales, Líneas de Tiempo y Mapas de Viaje del Usuario
- Diagramas de Gantt, Gráficos de Git y Tableros Kanban
- Modelos C4, Gráficos de Cuadrantes y Diagramas de Requisitos
Integración de Graphviz
- Digrafo & Grafo
- Diagramas de Flujo & Diagramas de Flujo de Datos
- Organigramas & Agrupaciones
Funcionalidades & Capacidades
Queremos que VPasCode sea accesible para todos, por eso hemos incluido herramientas esenciales en nuestra versión gratuita, mientras ofrecemos funciones innovadoras asistidas por IA para usuarios premium.
Funcionalidades Gratuitas Disponibles para Todos:
- Soporte Multi-Motor: Acceso completo a PlantUML, Mermaid.js y Graphviz.
- Descripciones Textuales: Crea diagramas complejos únicamente mediante código intuitivo.
- Vista Previa en Tiempo Real: Observa cómo tu diagrama se actualiza al instante en el lateral de tu pantalla mientras escribes.
- Compartición Fácil: Genera una URL única para compartir fácilmente tu diagrama en vivo con compañeros de equipo o clientes.
- Exportaciones Flexibles: Descarga tu trabajo finalizado como imágenes de alta calidad PNG o gráficos vectoriales escalables SVG vectoriales.
Potencia tu Flujo de Trabajo con Funcionalidades de Pago:
- Corrección de errores de código con IA:¿Atascado con un error de sintaxis? Nuestra IA integrada analizará su código PlantUML, Mermaid o Graphviz y corregirá los errores automáticamente.

- Traducción con IA:Traduzca sin problemas el texto y las etiquetas dentro de sus diagramas a varios idiomas con un solo clic.

Cómo acceder a las funciones de pago de VPasCode
Si ya es usuario de Visual Paradigm, ¡es posible que ya tenga acceso a nuestras funciones premium de IA!
Las funciones de pago de VPasCode están incluidas con:
- Edición Combo Online de Visual Paradigm (o superior).
- Edición Profesional de Escritorio de Visual Paradigm (o superior) con un contrato de mantenimiento activo.
Nota para usuarios de escritorio: Los usuarios de Visual Paradigm Professional Edition (o superior) con mantenimiento activo reciben automáticamente acceso completo a las aplicaciones web de VP Online Combo Edition, lo que significa que obtiene acceso instantáneo a las herramientas premium de IA de VPasCode sin coste adicional.
PlantUML y Mermaid en VPasCode – Ejemplos de diagramas
Diagrama de casos de uso de PlantUML: Sistema de comercio electrónico
Este diagrama de casos de uso ilustra las interacciones principales dentro de un sistema de pago de comercio electrónico. Un cliente puede ver su carrito y proceder al pago, donde la autenticación, la aplicación de cupones y el pago con tarjeta de crédito están integrados a través de servicios externos como un proveedor de identidad y un procesador de pagos.

@startuml
dirección de izquierda a derecha
actor "Cliente de comercio electrónico" as cliente
actor "Proveedor de identidad" as authPool
actor "Procesador de pagos" as stripe
rectángulo "Límite del sistema de pago" {
usecase "Autenticar" as UC_Auth
usecase "Ver carrito" as UC_Cart
usecase "Pagar" as UC_Check
usecase "Aplicar cupón" as UC_Promo
usecase "Pagar con tarjeta de crédito" as UC_Pay
}
cliente --> UC_Cart
cliente --> UC_Check
UC_Check ..> UC_Auth : <>
UC_Check <.. UC_Promo : <>
UC_Check ..> UC_Pay : <>
UC_Auth --> authPool
UC_Pay --> stripe
@enduml
Diagrama de clases de PlantUML: Sistema de gestión de biblioteca
Este diagrama de clases modela un sistema de gestión de biblioteca, mostrando las entidades clave involucradas en la gestión del catálogo, los servicios a los miembros y las operaciones de préstamo. El diseño utiliza la herencia para representar diferentes tipos de materiales de biblioteca (como libros, revistas y DVDs), mientras que las asociaciones entre miembros, bibliotecarios, registros de préstamo y multas ilustran cómo se prestan, devuelven y gestionan los elementos a lo largo de su ciclo de vida.

@startuml
class Biblioteca {
- nombre: String
- direccion: String
- telefono: String
+ agregarMiembro(miembro: Miembro): void
+ eliminarMiembro(idMiembro: String): void
+ agregarItem(item: ItemBiblioteca): void
+ eliminarItem(idItem: String): void
+ prestarItem(idMiembro: String, idItem: String): boolean
+ devolverItem(idItem: String): boolean
}
class ItemBiblioteca {
# idItem: String
# titulo: String
# editorial: String
# anioPublicacion: int
# disponible: boolean
+ obtenerDetalles(): String
+ establecerDisponibilidad(estado: boolean): void
}
abstract class Libro {
- isbn: String
- autor: String
- numPaginas: int
+ obtenerAutor(): String
}
class EBook {
- tamanoArchivoMB: double
- formato: String
- urlDescarga: String
+ descargar(): void
}
class LibroImpreso {
- ubicacionEstante: String
- condicion: String
+ obtenerUbicacionEstante(): String
}
class Revista {
- numeroEdicion: int
- numeroVolumen: int
- fechaPortada: Date
}
class DVD {
- duracionMinutos: int
- director: String
- idioma: String
- subtítulosDisponibles: boolean
}
class Miembro {
- idMiembro: String
- nombre: String
- email: String
- telefono: String
- fechaAfiliacion: Date
+ tomarItem(item: ItemBiblioteca): boolean
+ devolverItem(item: ItemBiblioteca): boolean
+ obtenerItemsPrestados(): List
}
class RegistroPrestamo {
- idRegistro: String
- fechaPrestamo: Date
- fechaVencimiento: Date
- fechaDevolucion: Date
- estaVencido(): boolean
- calcularMulta(): double
}
class Multa {
- idMulta: String
- monto: double
- fechaEmision: Date
- pagada: boolean
+ pagarMulta(): void
}
class Bibliotecario {
- idEmpleado: String
- departamento: String
+ procesarPrestamo(miembro: Miembro, item: ItemBiblioteca): void
+ procesarDevolucion(item: ItemBiblioteca): void
+ generarInforme(): void
+ gestionarInventario(): void
}
' Relaciones de herencia
ItemBiblioteca <|-- Libro
ItemBiblioteca <|-- Revista
ItemBiblioteca <|-- DVD
Libro <|-- EBook
Libro <|-- LibroImpreso
' Composición y agregación
Biblioteca "1" -- "muchos" Miembro : tiene >
Biblioteca "1" -- "muchos" ItemBiblioteca : contiene >
Biblioteca "1" -- "muchos" Bibliotecario : emplea >
Miembro "1" -- "muchos" RegistroPrestamo : tiene >
RegistroPrestamo "1" -- "1..*" ItemBiblioteca : referencia >
RegistroPrestamo "1" -- "0..*" Multa : genera >
' Asociación
Bibliotecario --> RegistroPrestamo : gestiona >
Miembro --> RegistroPrestamo : crea >
note top of Biblioteca : Sistema central que gestionanmiembros, items y préstamos
note right of ItemBiblioteca : Clase base abstractanpara todos los materiales bibliotecarios
@enduml
Diagrama de secuencia PlantUML: Retiro de efectivo en cajero automático
Este diagrama de secuencia ilustra las interacciones involucradas en una transacción de retiro de efectivo en un cajero automático, desde la inserción de la tarjeta y la validación del PIN hasta el dispensado de efectivo y la actualización de la cuenta. Destaca la comunicación entre el cliente, el cajero automático, el sistema bancario y la base de datos de cuentas de clientes, mientras también modela flujos alternativos como intentos de PIN inválidos, fondos insuficientes y la impresión opcional de recibo.

@startuml
' Título
title Retiro de efectivo en cajero automático - Diagrama de secuencia
' Actores y participantes
actor Cliente como C
participante "Cajero Automático" como ATM
participante "Sistema Bancario" como BS
database "Cuenta del Cliente" como DB
' Secuencia
C -> ATM : Insertar Tarjeta
ATM -> ATM : Leer detalles de la tarjeta
ATM -> C : Solicitar PIN
C -> ATM : Ingresar PIN
ATM -> BS : Validar tarjeta y PIN
BS -> DB : Verificar credenciales
DB --> BS : Resultado de validación
alt PIN inválido
BS --> ATM : PIN inválido
ATM -> C : PIN inválido, intente de nuevo
note right: Después de 3 intentos fallidos,nla tarjeta se retiene
else PIN válido
BS --> ATM : PIN válido
ATM -> C : Mostrar menú principal
C -> ATM : Seleccionar retiro
ATM -> C : Solicitar monto
C -> ATM : Ingresar monto
ATM -> BS : Verificar saldo y límite
BS -> DB : Consultar saldo
DB --> BS : Saldo actual
alt Fondos insuficientes
BS --> ATM : Saldo insuficiente
ATM -> C : Transacción rechazadan(Mostrar saldo)
C -> ATM : Cancelar transacción
ATM -> C : Devolver tarjeta
else Fondos suficientes
BS --> ATM : Aprobado
ATM -> ATM : Dispensar efectivo
ATM -> C : Dispensar efectivo
C -> ATM : Recoger efectivo
ATM -> BS : Confirmar dispensación de efectivo
BS -> DB : Descontar cuenta y registrar transacción
DB --> BS : Actualización completa
BS --> ATM : Transacción completada
ATM -> C : Imprimir recibo
alt Recibo solicitado
C -> ATM : Recoger recibo
else Sin recibo
C -> ATM : Rechazar recibo
end
ATM -> C : Devolver tarjeta
C -> ATM : Recoger tarjeta
end
end
ATM -> C : Gracias / Fin de la transacción
@enduml
Diagrama de actividad PlantUML: Sistema de reclamaciones de seguros
Este diagrama de actividad modela el flujo de trabajo de extremo a extremo de un sistema de procesamiento de reclamaciones de seguros, desde la presentación de la reclamación hasta la validación, investigación y liquidación. Captura puntos de decisión clave como la elegibilidad de la póliza, la integridad de los documentos, la validez de la reclamación y la aceptación de la liquidación, mientras ilustra tanto las rutas exitosas como las de manejo de excepciones, incluyendo el rechazo de la reclamación y la resolución de disputas.

@startuml InsuranceClaimSystem
inicio
:El asegurado presenta la reclamación;
:La reclamación se registra en el sistema;
if (¿La póliza está activa y válida?) then (sí)
:Asignar reclamación al ajustador;
:Notificar al ajustador sobre la nueva reclamación;
else (no)
:Enviar notificación de rechazo al asegurado;
:Registrar motivo: Póliza inactiva/inválida;
fin
endif
:El ajustador revisa los documentos presentados;
if (¿Están presentes todos los documentos requeridos?) then (sí)
:El ajustador inicia la validación de la reclamación;
else (no)
:Solicitar documentos faltantes al asegurado;
:Esperar documentos adicionales;
:Revisar nuevamente los documentos;
note right
El sistema espera
la respuesta del asegurado
end note
-> volver a "El ajustador revisa los documentos presentados";
endif
:El ajustador investiga la reclamación;
:Contactar testigos/expertos si es necesario;
:Estimar monto de daños/pérdidas;
if (¿La reclamación es válida según los términos de la póliza?) then (sí)
:Calcular monto aprobado;
:Aplicar deducible si corresponde;
else (no)
:Enviar notificación de rechazo con motivo;
:Registrar decisión en el sistema;
fin
endif
:Generar oferta de liquidación;
:Enviar oferta de liquidación al asegurado;
:El asegurado revisa la oferta;
if (¿El asegurado acepta la oferta?) then (sí)
:Procesar el pago;
:Actualizar estado de la reclamación a "Liquidado";
:Enviar confirmación al asegurado;
:Registrar detalles de cierre;
else (no)
:Escalar a resolución de disputas;
:Negociar liquidación;
:Actualizar oferta;
-> volver a "Enviar oferta de liquidación al asegurado";
endif
fin
@enduml
Diagrama de estado PlantUML: Sistema de detección de humo
Este diagrama de estado ilustra el comportamiento de un sistema de detección de humo mientras transita entre estados operativos como espera, monitoreo, detección de humo, activación de alarma y manejo de errores. Muestra cómo el sistema responde a eventos como cambios de energía, resultados de autocomprobación, detección de humo, condiciones de batería baja y reinicios iniciados por el usuario para garantizar un monitoreo y alerta de incendios confiables.

@startuml SmokeDetectionSystem
title Diagrama de estado - Sistema de detección de humo
[*] --> Apagado
state Apagado {
[*] --> SinEnergia
SinEnergia : El dispositivo está apagado
SinEnergia --> Encendido : Botón de encendido presionado
}
state Encendido {
[*] --> Espera
Espera : Sistema listo
Espera --> Autocomprobacion : Autocomprobación periódica (cada 24h)
Espera --> Monitoreo : Iniciar monitoreo (sensor activo)
state Autocomprobacion {
[*] --> ProbandoSensores
ProbandoSensores --> PruebaAprobada : Todos los sensores OK
ProbandoSensores --> PruebaFallida : Error de sensor detectado
PruebaAprobada --> Espera : Volver a espera
PruebaFallida --> EstadoError : Reportar error
}
state Monitoreo {
[*] --> SinHumo
SinHumo : Operación normal
SinHumo --> HumoDetectado : Nivel de humo > umbral
SinHumo --> BajaBateria : Batería baja (inalámbrico)
BajaBateria --> SinHumo : Batería reemplazada
state HumoDetectado {
[*] --> AlertaInicial
AlertaInicial --> HumoConfirmado : Humo persiste > 5 seg
AlertaInicial --> FalsaAlarma : Humo se disipa < 5 seg FalsaAlarma --> SinHumo : Reiniciar
HumoConfirmado --> AlarmaActiva
}
state AlarmaActiva {
[*] --> SonarAlarma : Activar sirena y luces
SonarAlarma --> EnviarNotificacion : Notificar panel de control / app
EnviarNotificacion --> EsperarReinicio
EsperarReinicio --> AlarmaActiva : Humo aún presente
EsperarReinicio --> ReiniciarSistema : Botón de reinicio presionado
ReiniciarSistema --> SinHumo : Sistema reiniciado
}
}
}
state EstadoError {
[*] --> IndicadorFalla : Parpadeo LED de error
IndicadorFalla --> Apagado : Ciclo de energía manual requerido
}
Encendido --> EstadoError : Fallo de autocomprobación
EstadoError --> Apagado : Ciclo de energía
Apagado --> [*] : Sistema desconectado / batería retirada
@enduml
Diagrama de componentes PlantUML: Sistema de mensajería
Este diagrama de componentes presenta la arquitectura de alto nivel de un sistema de gestión de mensajería, mostrando cómo interactúan las aplicaciones cliente, servicios backend, infraestructura de mensajería, cachés y bases de datos para apoyar las operaciones de entrega de paquetes. Ilustra la separación de responsabilidades entre servicios como la gestión de pedidos, distribución, seguimiento, pagos, notificaciones y gestión de usuarios, destacando tanto la comunicación síncrona de API como el procesamiento asíncrono basado en eventos.

@startuml CourierSystem
title Sistema de mensajería - Diagrama de componentes
' === Componentes ===
component "Aplicación del cliente" as CustomerApp
component "Aplicación móvil del mensajero" as CourierApp
component "Panel web de administración" as AdminWeb
component "Puerta de enlace API" as ApiGateway
component "Servicio de pedidos" as OrderService
component "Servicio de distribución" as DispatchService
component "Servicio de seguimiento" as TrackingService
component "Servicio de pagos" as PaymentService
component "Servicio de notificaciones" as NotificationService
component "Servicio de usuarios" as UserService
component "Cola de mensajesn(RabbitMQ/Kafka)" as MessageQueue
component "Caché Redis" as RedisCache
database "Base de datos PostgreSQL" as SQLDB
database "MongoDBn(Logs/Historial de seguimiento)" as MongoLogs
' === Interfaces / Puertos ===
CustomerApp --> ApiGateway : "REST / WebSocket"
CourierApp --> ApiGateway : "REST / WebSocket"
AdminWeb --> ApiGateway : "REST"
ApiGateway --> OrderService
ApiGateway --> TrackingService
ApiGateway --> PaymentService
ApiGateway --> UserService
' === Dependencias de servicios ===
OrderService --> DispatchService : "gRPC / REST"
OrderService --> PaymentService
OrderService --> NotificationService
OrderService --> SQLDB : "JDBC"
OrderService --> RedisCache : "Caché"
DispatchService --> MessageQueue : "Publicar eventos"
DispatchService --> CourierApp : "Empujar a través de la puerta de enlace API"
DispatchService --> SQLDB
TrackingService --> MessageQueue : "Suscribirse a actualizaciones de ubicación"
TrackingService --> MongoLogs : "Escribir historial de seguimiento"
TrackingService --> RedisCache : "Caché de ubicación actual"
PaymentService --> SQLDB
PaymentService --> NotificationService
NotificationService --> MessageQueue : "Consumir notificaciones"
NotificationService --> CustomerApp : "Empujar a través de la puerta de enlace API"
UserService --> SQLDB
UserService --> RedisCache
' === Notas ===
note right of OrderService
Maneja la creación de paquetes,
precios y estado del pedido
end note
note right of DispatchService
Empareja pedidos con mensajeros,
optimiza rutas
end note
note bottom of MessageQueue
Eventos asíncronos: pedido_creado,
ubicación_actualizada,
estado_de_entrega_cambiado
end note
@enduml
Diagrama de despliegue PlantUML: Arquitectura de ejemplo

@startuml
node "AWS Cloud Route53" as DNS
node "VPC (10.0.0.0/16)" {
node "Subred pública" {
artifact "Balanceador de carga NGINX" as ALB
}
node "Cluster de subred privada" {
node "Instancia EC2 1" {
component "API Node.js [Pod 1]" as Pod1
}
node "Instancia EC2 2" {
component "API Node.js [Pod 2]" as Pod2
}
}
node "Subred de base de datos" {
database "Amazon RDS (Aurora Multi-AZ)" as Aurora
}
}
DNS --> ALB : Resuelve el tráfico
ALB --> Pod1 : Balanceo round-robin
ALB --> Pod2
Pod1 --> Aurora : Pool de conexiones
Pod2 --> Aurora
@enduml
Ejemplo de ArchiMate PlantUML: Navegador de Internet
Este diagrama de ArchiMate ilustra cómo interactúan las capas de negocio, aplicación y tecnología para apoyar la funcionalidad empresarial basada en la web a través de un navegador de Internet. Demuestra las relaciones entre procesos de negocio, componentes y datos de páginas web generados dinámicamente, servicios y complementos del navegador, y la infraestructura subyacente del servidor web que entrega y soporta la experiencia de la aplicación.

@startuml Internet Browser Sample
!include <archimate/Archimate>
title Muestra de Archimate - Navegador de Internet
'LAYOUT_AS_SKETCH()
'LAYOUT_LEFT_RIGHT()
'LAYOUT_TOP_DOWN()
Grouping(business, "Negocio"){
Business_Object(businessObject, "Un objeto de negocio")
Business_Process(someBusinessProcess,"Alguno proceso de negocio")
Business_Service(itSupportService, "Soporte de TI para el negocio (Servicio de aplicación)")
}
Grouping(application, "Aplicación"){
Application_DataObject(dataObject, "Datos de página web n 'en tiempo real'")
Application_Function(webpageBehaviour, "Comportamiento de página web")
Application_Component(ActivePartWebPage, "Parte activa de la página web n 'en tiempo real'")
}
Grouping(technology, "Tecnología"){
Technology_Artifact(inMemoryItem,"en memoria / 'en tiempo real' html/javascript")
Technology_Service(internetBrowser, "Navegador de Internet Genérico y Complemento")
Technology_Service(internetBrowserPlugin, "Alguno complemento de navegador de Internet")
Technology_Service(webServer, "Alguno servidor web")
}
Rel_Flow_Left(someBusinessProcess, businessObject, "")
Rel_Serving_Up(itSupportService, someBusinessProcess, "")
Rel_Specialization_Up(webpageBehaviour, itSupportService, "")
Rel_Flow_Right(dataObject, webpageBehaviour, "")
Rel_Specialization_Up(dataObject, businessObject, "")
Rel_Assignment_Left(ActivePartWebPage, webpageBehaviour, "")
Rel_Specialization_Up(inMemoryItem, dataObject, "")
Rel_Realization_Up(inMemoryItem, ActivePartWebPage, "")
Rel_Specialization_Right(inMemoryItem,internetBrowser, "")
Rel_Serving_Up(internetBrowser, webpageBehaviour, "")
Rel_Serving_Up(internetBrowserPlugin, webpageBehaviour, "")
Rel_Aggregation_Right(internetBrowser, internetBrowserPlugin, "")
Rel_Access_Up(webServer, inMemoryItem, "")
Rel_Serving_Up(webServer, internetBrowser, "")
@enduml
Ejemplo de diagrama de entidad-relación (ERD) PlantUML: Sistema de entradas de cine

@startuml
entity "Cliente" as cliente {
* cliente_id : UUID <>
--
* nombre : VARCHAR(50)
* apellido : VARCHAR(50)
* email : VARCHAR(100) <>
* telefono : VARCHAR(20)
* puntos_fidelidad : INT
* fecha_registro : TIMESTAMP
}
entity "Película" as pelicula {
* pelicula_id : UUID <>
--
* titulo : VARCHAR(200)
* descripcion : TEXT
* duracion_minutos : INT
* genero : VARCHAR(50)
* fecha_lanzamiento : DATE
* calificacion : VARCHAR(10)
}
entity "Cine" as cine {
* cine_id : UUID <>
--
* nombre_cine : VARCHAR(100)
* asientos_totales : INT
* disposicion_asientos : JSON
}
entity "Función" as funcion {
* funcion_id : UUID <>
--
* pelicula_id : UUID <>
* cine_id : UUID <>
* hora_funcion : TIMESTAMP
* hora_fin : TIMESTAMP
* idioma : VARCHAR(50)
* subtitulos : BOOLEAN
* precio_regular : DECIMAL(10,2)
* precio_vip : DECIMAL(10,2)
}
entity "Asiento" as asiento {
* asiento_id : UUID <>
--
* cine_id : UUID <>
* etiqueta_fila : CHAR(2)
* numero_asiento : INT
* tipo_asiento : VARCHAR(20)
* es_accesible : BOOLEAN
}
entity "Reserva" as reserva {
* reserva_id : UUID <>
--
* cliente_id : UUID <>
* funcion_id : UUID <>
* hora_reserva : TIMESTAMP
* monto_total : DECIMAL(10,2)
* estado : VARCHAR(20)
* metodo_pago : VARCHAR(30)
* id_transaccion : VARCHAR(100)
}
entity "ReservaAsiento" as reserva_asiento {
* reserva_id : UUID <<FK,PK>>
* asiento_id : UUID <<FK,PK>>
--
* precio_boleto : DECIMAL(10,2)
* descuento_aplicado : DECIMAL(10,2)
}
entity "Pago" as pago {
* pago_id : UUID <>
--
* reserva_id : UUID <>
* monto : DECIMAL(10,2)
* fecha_pago : TIMESTAMP
* estado_pago : VARCHAR(20)
* pasarela_pago : VARCHAR(30)
* referencia_pasarela : VARCHAR(200)
}
entity "Reseña" as resena {
* resena_id : UUID <>
--
* cliente_id : UUID <>
* pelicula_id : UUID <>
* calificacion : INT
* comentario : TEXT
* fecha_resena : TIMESTAMP
}
' Relaciones
cliente ||--o{ reserva : "realiza"
pelicula ||--o{ funcion : "programada como"
cine ||--o{ funcion : "aloja"
funcion ||--o{ reserva : "tiene"
reserva ||--|{ reserva_asiento : "contiene"
asiento ||--o{ reserva_asiento : "asignado a"
reserva ||--|| pago : "tiene"
cliente ||--o{ resena : "escribe"
pelicula ||--o{ resena : "recibe"
nota derecha de reserva : Estado: PENDIENTE, CONFIRMADO, CANCELADO, EXPIRADO
nota izquierda de asiento : tipo_asiento: REGULAR, VIP, PAREJA
nota derecha de pago : estado_pago: PENDIENTE, EXITOSO, FALLIDO, REEMBOLSADO
@enduml
Diagrama de flujo Mermaid: Ver al médico
Este diagrama de flujo ilustra un proceso típico de toma de decisiones en el ámbito de la salud, guiando a los pacientes desde el reconocimiento inicial de los síntomas hasta el diagnóstico, las pruebas, el tratamiento y la recuperación. Destaca puntos clave de decisión, como la evaluación de emergencias, la evaluación diagnóstica y la eficacia del tratamiento, al tiempo que muestra cómo los síntomas no resueltos pueden requerir una consulta médica adicional y una reevaluación.

flowchart TD
A[Sentirse mal o necesitar consejo médico] --> B{¿Es una emergencia?}
B -->|Sí| C[Llamar a servicios de emergencia o ir a urgencias]
B -->|No| D[Programar cita con el médico]
D --> E[Asistir a la cita]
E --> F[Evaluación del médico]
F --> G{¿Se ha hecho el diagnóstico?}
G -->|Sí| H[Plan de tratamiento]
G -->|No| I[Ordenar pruebas]
I --> J[Recibir resultados de las pruebas]
J --> F
H --> K[Seguir el tratamiento]
K --> L{¿Mejoraron los síntomas?}
L -->|Sí| M[Recuperación / Seguimiento rutinario]
L -->|No| N[Volver al médico]
N --> F
Grafo de Graphviz
Este diagrama representa una topología de red de centro de datos simplificada, ilustrando cómo los hosts están conectados a través de una columna vertebral de conmutadores interconectados. Destaca las rutas de comunicación principales entre los dispositivos de red, incluyendo un enlace troncal entre conmutadores y una conexión secundaria de conmutación por error que proporciona redundancia y resiliencia en caso de interrupciones de la red.

graph UndirectedSpanningTree {
fontname="Helvetica,Arial,sans-serif"
label="Infraestructura de columna vertebral de topología de red de malla de centro de datos"
labelloc="b"
fontsize=14
node [fontname="Helvetica,Arial,sans-serif", shape=circle, style=filled, color="#475569", fillcolor="#f1f5f9", width=0.8, fixedsize=true]
edge [color="#94a3b8", penwidth=2.5]
SwitchAlpha [label="SW_A", fillcolor="#cbd5e1"]
SwitchBeta [label="SW_B", fillcolor="#cbd5e1"]
Node1 [label="Host_01"]
Node2 [label="Host_02"]
Node3 [label="Host_03"]
Node4 [label="Host_04"]
SwitchAlpha -- SwitchBeta [label=" Enlace troncal", weight=5]
SwitchAlpha -- Node1
SwitchAlpha -- Node2
SwitchBeta -- Node3
SwitchBeta -- Node4
Node1 -- Node2 [style=dashed, color="#cbd5e1", label=" Interconexión de conmutación por error"]
}
Comienza hoy
¿Listo para experimentar la velocidad del diagrama como código? Ya sea que necesite un confiable editor de PlantUML, un rápido editor de Mermaid, o un potente compilador de Graphviz, VPasCode está listo para usted.
Vaya a nuestra plataforma ahora en:
¡Pruebe el editor en tiempo real y revolucione la forma en que diseña software y sistemas!


