Por qué UML es el plano maestro
El comercio electrónico de 2025 no es solo inventario, pagos y envíos. Los consumidores esperan ver productos presentados en escenarios específicos, adaptados a sus historiales de navegación y preferencias, y el vídeo se ha convertido en el formato dominante para conseguirlo. Detrás de esa experiencia hay una complejidad técnica considerable: pipelines de generación de vídeo con IA, colas de tareas, control de coherencia de personajes y servicios externos de modelos. Cuando un sistema crece hasta ese punto, construir sin un plano es una receta para el caos.
El Lenguaje Unificado de Modelado (UML) es ese plano. Los diagramas UML permiten visualizar la arquitectura antes de escribir código, comunicar decisiones entre equipos y detectar problemas de diseño cuando todavía son baratos de corregir. En este artículo verás, con ejemplos prácticos, cómo diseñar los diagramas esenciales para un e-commerce que integra vídeo generado por IA: casos de uso, clases, componentes, actividades, secuencia, estados, despliegue, paquetes y perfiles.
Casos de uso: quién interactúa con el sistema
Los diagramas de casos de uso establecen los límites del sistema y capturan los requisitos funcionales desde la perspectiva de los actores. En un e-commerce con vídeo por IA, los actores van más allá del cliente que navega:
- El cliente: explora productos, ve vídeos, personaliza la presentación, compra.
- El administrador de catálogo: sube productos, configura las plantillas de vídeo, aprueba los activos generados.
- El sistema de generación de IA: un actor sistémico que recibe peticiones, genera vídeos y devuelve resultados.
- El servicio de pagos: procesa transacciones y confirma el estado de los pedidos.
Un caso de uso central es "generar vídeo de producto personalizado": el cliente indica sus preferencias, el sistema construye el prompt, encola la tarea de generación y notifica al cliente cuando el vídeo está listo. Dibujar estos flujos primero evita el error clásico de diseñar el sistema sin acordar quién hace qué.
Diagramas de clases: datos y lógica de negocio
Los diagramas de clases definen la estructura estática del sistema: las entidades clave y sus relaciones. En nuestro e-commerce, las clases esenciales incluyen:
- Producto: identificador, nombre, categoría, atributos, imágenes base.
- VideoActivo: URL del vídeo, estado de generación, modelo utilizado, prompt, parámetros.
- TareaGeneracion: identificador de la tarea, tipo, estado, prioridad, fecha de creación.
- PlantillaVideo: la definición de cómo se genera un vídeo para un tipo de producto.
- Prompt: el texto y las referencias visuales asociadas a una generación.
- Pedido: la transacción comercial, relacionada con productos y vídeos visualizados.
La relación más importante es la que une Producto con VideoActivo a través de TareaGeneracion: un producto puede tener muchos vídeos, y cada vídeo nace de una tarea de generación con su propio estado. Modelar esta relación con claridad es lo que permite después implementar la lógica de negocio sin ambigüedades.
Diagramas de componentes: modularidad y desacoplamiento
La generación de vídeo consume muchos recursos. Si el sistema de generación está acoplado al catálogo, una ráfaga de peticiones puede tumbar toda la tienda. Los diagramas de componentes ayudan a diseñar los límites:
- Módulo de catálogo: gestiona productos e inventario.
- Módulo de generación de vídeo: recibe peticiones, construye prompts, encola tareas.
- Cola de tareas: el intermediario desacoplado entre la tienda y los servicios de generación.
- Módulo de almacenamiento: guarda los vídeos generados y los sirve a través de una red de distribución.
- Módulo de pagos: procesa transacciones de forma independiente.
La regla de oro es el desacoplamiento: el catálogo no llama directamente al generador de vídeo, sino que publica una tarea en la cola. Esto permite escalar cada módulo por separado y sustituir el proveedor de modelos sin tocar la tienda.
Diagramas de actividades: el flujo de generación de vídeo
El diagrama de actividades describe el flujo de trabajo. Para la generación de vídeo con IA, el flujo típico es:
- El cliente solicita un vídeo de producto.
- El sistema comprueba si existe una plantilla aplicable.
- Si no existe, la crea con los atributos del producto.
- El sistema construye el prompt y encola la tarea.
- Un worker recoge la tarea y llama al modelo de generación.
- El vídeo se genera y se almacena.
- El sistema verifica la calidad (dimensiones, duración, coherencia).
- Si falla, la tarea se reintenta o se marca para revisión.
- El cliente recibe la notificación con el vídeo listo.
Dibujar este flujo revela las decisiones de negocio escondidas: ¿qué pasa si el modelo falla? ¿cuántos reintentos se permiten? ¿quién revisa los vídeos defectuosos? Son preguntas que conviene responder en el diagrama, no en producción.
Diagramas de secuencia: interacciones con servicios de IA
Los diagramas de secuencia muestran las interacciones detalladas entre objetos a lo largo del tiempo. En la generación de vídeo, la secuencia típica involucra al cliente, al controlador de la tienda, al servicio de tareas, a la cola y al servicio externo de generación:
- El cliente envía la solicitud.
- El controlador valida los datos y crea la tarea.
- El servicio de tareas encola el trabajo.
- El worker procesa la tarea y llama al servicio externo con el prompt.
- El servicio externo devuelve el vídeo o un error.
- El worker actualiza el estado y notifica al cliente.
Estos diagramas son especialmente valiosos para acordar contratos con servicios externos: qué se envía, qué se recibe, qué se considera error y cómo se recupera.
Diagramas de máquina de estados: el ciclo de vida de la tarea AIGC
Una tarea de generación no es un simple "pendiente o completada". Su ciclo de vida merece un diagrama de estados:
- CREADA: la tarea se ha registrado.
- EN_COLA: esperando recursos.
- GENERANDO: un worker la está procesando.
- COMPLETADA: el vídeo está listo y almacenado.
- FALLIDA: el proceso terminó con error.
- REINTENTANDO: se intenta de nuevo tras un fallo recuperable.
- REVISION: el vídeo se generó pero requiere revisión manual.
Las transiciones entre estados definen el comportamiento del sistema: qué provoca un reintento, cuántos reintentos se permiten, quién decide pasar a REVISION. Modelar esto evita que las tareas queden atrapadas en estados intermedios sin supervisión.
Diagramas de despliegue: infraestructura
El diagrama de despliegue muestra dónde corre cada componente: servidores, contenedores, servicios gestionados. Para nuestro e-commerce, la vista de despliegue incluye:
- El frontend de la tienda, servido desde una red de distribución global.
- Los servicios de aplicación en contenedores escalables.
- La base de datos relacional con los datos del catálogo y los pedidos.
- El servicio de almacenamiento de objetos para los vídeos.
- Los workers de generación, que pueden escalar de forma independiente según la carga.
- El servicio externo de modelos de IA, al que se accede por API.
El despliegue correcto es el que permite escalar el punto más débil: si la generación es el cuello de botella, los workers deben escalar sin tocar la tienda.
Diagramas de paquetes: backend modular
Los diagramas de paquetes organizan el código en módulos lógicos. Un backend bien estructurado para este sistema tiene paquetes separados para catálogo, pedidos, generación de vídeo, gestión de tareas, pagos y notificaciones. La regla de dependencia es simple: los paquetes de bajo nivel no dependen de los de alto nivel, y las dependencias entre módulos siguen los contratos definidos en los diagramas de componentes. Esto mantiene el código compilable, testeable y sustituible.
Diagramas de perfil: tipos de datos de IA específicos
UML es extensible mediante perfiles. En un sistema de e-commerce con IA, conviene definir estereotipos propios: Prompt (con atributos de texto y referencias), ModeloVideo (con capacidades y costes relativos), ParametrosGeneracion (resolución, duración, estilo). Un perfil bien definido hace que el vocabulario del dominio aparezca directamente en los diagramas, en lugar de esconderse en el código.
Impacto empresarial y operativo
El esfuerzo de modelado se paga solo. Con un buen conjunto de diagramas UML, los equipos pueden:
- Estimar el coste de cada flujo antes de implementarlo.
- Detectar cuellos de botella de diseño en fases tempranas.
- Incorporar nuevos desarrolladores más rápido.
- Negociar contratos con proveedores de IA con claridad.
- Mantener la coherencia cuando el sistema crece.
En la práctica, las tiendas que modelan su arquitectura antes de construir la generación de vídeo llegan a producción con menos retrabajo y con una base más sólida para escalar.
Un ejemplo completo: el vídeo de producto
Para ver cómo encajan todos los diagramas, recorramos un caso concreto: un e-commerce de muebles que quiere generar un vídeo personalizado de cada sofá que vende.
El diagrama de casos de uso captura la petición del cliente: "ver el sofá en mi salón". El sistema consulta la paleta de colores del salón del cliente y construye la escena. El diagrama de clases modela las entidades: Sofa (atributos de producto), PlantillaVideo (escenario del salón), TareaGeneracion (el trabajo encolado) y VideoActivo (el resultado final). El diagrama de componentes separa el catálogo de muebles del motor de generación: el catálogo publica la tarea en la cola, y un worker del motor la consume.
El diagrama de actividades describe el flujo completo: el cliente solicita el vídeo, el sistema construye el prompt con la plantilla y los atributos del sofá, encola la tarea, el worker genera el vídeo con el modelo elegido, el resultado se almacena y el cliente recibe la notificación. El diagrama de secuencia detalla la llamada al servicio externo de generación: qué parámetros se envían, cómo se devuelve el vídeo, qué ocurre si el modelo responde con un error. El diagrama de estados define el ciclo de vida de la tarea: creada, en cola, generando, completada o fallida, con reintentos limitados.
El diagrama de despliegue muestra la infraestructura: el frontend de la tienda, los servicios de aplicación, la base de datos del catálogo, el almacenamiento de vídeos y los workers escalables. El diagrama de paquetes organiza el backend en módulos: catalogo, pedidos, generacion, tareas, pagos, notificaciones. Y el perfil UML define los estereotipos del dominio: Sofa, PlantillaVideo, ParametrosGeneracion.
El resultado es un plano completo y comunicable: cualquier desarrollador nuevo puede leerlo y saber qué construir, cualquier proveedor de IA puede entender qué contrato debe cumplir, y el equipo comercial puede estimar el coste de cada flujo.
Herramientas para modelar UML
No necesitas herramientas caras para empezar. Las opciones van desde la pizarra digital en sesiones de diseño hasta herramientas de modelado dedicadas que generan código a partir de los diagramas. La elección depende del equipo: si el modelado es una herramienta de comunicación, basta una herramienta sencilla y compartida; si los diagramas deben mantenerse sincronizados con el código, vale la pena invertir en una herramienta con generación de código y validación. Lo importante no es la herramienta, sino la disciplina de mantener los diagramas actualizados.
FAQ
¿Necesito todos los diagramas UML para empezar? No. Empieza con casos de uso, clases y actividades. Añade secuencia y estados cuando integres servicios externos o flujos críticos. El resto se incorpora cuando el sistema crezca.
¿Quién debe dibujar los diagramas? Idealmente, el equipo completo en sesiones cortas de diseño. Los diagramas son herramientas de comunicación, no un artefacto de un único arquitecto.
¿Se quedan obsoletos los diagramas? Los diagramas se quedan obsoletos si se tratan como documentación estática. Si se actualizan en cada cambio relevante y se revisan en las retrospectivas, siguen siendo el plano vivo del sistema.
¿UML es útil si uso microservicios y servicios gestionados? Sí, incluso más. Los microservicios convierten los límites entre componentes en contratos de red, y los diagramas de componentes y secuencia son la mejor forma de acordarlos.
Conclusión
Integrar vídeo generado por IA en un e-commerce es un proyecto de arquitectura, no solo de integración. Los diagramas UML proporcionan el lenguaje común para diseñar, comunicar y mantener un sistema que combina catálogo, generación, colas, almacenamiento y pagos. Empieza pequeño, modela los flujos críticos y deja que los diagramas evolucionen con el sistema. El plano no es un gasto; es la inversión que evita que la complejidad se convierta en caos.
