Validación

​

Visión general

Cada vez que cambias un modelo, ProDex vuelve a verificarlo, junto con el calendario que tienes seleccionado, contra un conjunto de reglas de corrección. El resultado se muestra en el botón de reproducir en la parte inferior del lienzo: Mientras un modelo carga por primera vez y se está verificando, el botón está gris (“Validando modelo…”). Si la verificación misma no pudo completarse, el botón se pone rojo con el tooltip “La verificación de validación falló — haga clic para reintentar.” Debido a que la validación se ejecuta en cada cambio, detectas los problemas a medida que los introduces en lugar de descubrirlos cuando una simulación falla.

​

Lectura del popover

Pasa el cursor sobre un botón de reproducir rojo o ámbar para abrir un popover con:

• Un encabezado que cuenta los problemas, como “1 validation error” o “3 validation warnings”. Cuando existen tanto errores como advertencias, el popover lista solo los errores.
• El texto del error o advertencia, nombrando el componente y qué tiene de malo. Una lista larga termina con una línea como ”… and 4 more validation errors omitted.”
• Un botón Fix with Dexter.

Un ejemplo real de un error:

“Component ‘Halo Repress Halo Queue’ (type: BufferDefinition) must have exactly one outgoing standard connection, but has 2. To split flow across multiple destinations (pass/fail, rework, triage), keep a single connection into a Router and branch there — a Router is the only flow component that takes multiple outgoing connections.”

​

Corregir con Dexter

Fix with Dexter abre Dexter y le envía los errores (o advertencias) listados con la solicitud de leerlos y resolverlos. Dexter luego edita el modelo directamente; no hay un paso de aprobación separado para sus cambios, así que revisa el lienzo cuando termine. El botón no está disponible mientras Dexter está ocupado con otra solicitud. Si prefieres corregirlo tú mismo, el mensaje es lo suficientemente específico para señalarte el componente, campo o expresión a editar.

​

Errores vs. advertencias

• Los errores bloquean la simulación. El botón permanece rojo hasta que se resuelva cada error.
• Las advertencias nunca bloquean una ejecución. Señalan modelos que son válidos pero probablemente se comporten mal.

Las advertencias que puedes ver hoy:

• Ciclo de retardo cero: un bucle de enrutamiento sin ningún paso que tome tiempo, lo que puede detener el reloj de simulación si entidades entran en él
• Ciclo de retención y espera (hold-and-wait): entidades reteniendo recursos a través de procesos de una manera que puede causar un interbloqueo
• Un Resource cuya capacidad (o el objetivo de una acción set capacity) supera 10,000, lo que la ejecución rechazará
• Un Router probabilístico cuyos pesos son todos cero o negativos, de modo que cada entidad toma la última opción
• Un calendario que libera ráfagas muy grandes en un solo instante, o cuyas liberaciones y acciones programadas se disparan tan seguido que la ejecución será lenta

​

Qué bloquea una ejecución

Las siguientes reglas producen errores. Cada mensaje de error nombra el componente involucrado.

​

Conexiones

• Source: cero conexiones entrantes, exactamente una saliente
• Sink: cero conexiones salientes
• Router y ModelNode: al menos una conexión saliente
• Process, Buffer, Combiner, Separator, Transformer: exactamente una conexión saliente. Para dividir el flujo, conecta a un Router y ramifica ahí.
• Las conexiones unen componentes, no Stations.

Todo componente también debe ser alcanzable desde una Source a través de alguna cadena de conexiones.

​

Recursos y estaciones sin usar

• Un Resource que ningún componente usa es un error: “Resource ’…’ is defined but never used.” Requiérelo en un Process, o elimínalo.
• Una Station a la que ningún componente está asignado es un error. Asígnala en los componentes que operan ahí, o elimínala.

Todo recurso o estación al que un componente se refiere también debe existir.

​

Flujo de entidades

• Los tipos de entidad de entrada que cada componente espera deben efectivamente llegar desde upstream, y ningún componente puede recibir un tipo que no espera.
• Las Sources, calendarios y otros generadores solo pueden crear tipos de entidad que existen.

​

Asignación de atributos

La Strategy (Estrategia) de cada asignación de atributo debe ser adecuada para el tipo del atributo (por ejemplo, Distribution solo funciona para atributos Number), y los valores fijos o ponderados deben ser válidos para el atributo. Las asignaciones también deben referirse a atributos que existen en el tipo de entidad. Consulta Entidades para saber qué estrategias permite cada tipo.

​

Enrutadores

Un Router condicional necesita una ruta predeterminada para las entidades que no coinciden con ninguna regla, y toda conexión a la que se refieran las reglas o rutas de un Router debe partir de ese Router. Un Router probabilístico necesita al menos una opción, y un Router basado en tipo no puede tener conexiones salientes que ninguna de sus rutas use.

​

Expresiones

El lenguaje de expresiones está tipado estáticamente, así que cada expresión se verifica aquí en lugar de fallar a mitad de la ejecución:

• Las condiciones deben producir booleanos; los campos numéricos deben producir números
• Las agregaciones como SUM o ANY solo funcionan donde hay varias entidades en alcance
• Todo nombre debe resolverse en el contexto de la expresión. Un atributo de entidad usado donde no hay ninguna entidad en alcance, un nombre mal escrito, o una constante que el modelo no ha añadido, todos fallan con “Unknown identifier ’…’”

Consulta Contextos de expresión cuando un identificador que esperabas que funcionara se reporte como desconocido.

​

Nombres

• Los ids de componente deben ser únicos dentro del modelo
• Las constantes y tablas de búsqueda y las variables de estado deben tener nombres en SCREAMING_SNAKE_CASE que no choquen con palabras reservadas ni entre sí
• El valor inicial de una variable de estado debe coincidir con su tipo
• Las entradas de una tabla de búsqueda deben coincidir con sus columnas clave y su tipo de valor

​

Event Hooks y Temas

• Los hooks deben usar eventos que existan para su tipo de componente
• Las acciones deben ser válidas para el componente en el que están
• Todo tema (topic) debe ser tanto emitido como escuchado
• Dos bucles directos están prohibidos: el hook entity created de una Source liberando desde esa misma Source, y el hook entity exited de un Buffer liberando desde ese mismo Buffer

Consulta Sistema de Eventos.

​

Calendario

El calendario seleccionado se verifica junto con el modelo:

• End Time debe ser posterior a Start Time
• Las liberaciones de material deben apuntar a una Source o Buffer que exista y pueda aceptar el tipo de entidad liberado
• Las acciones programadas deben caer entre el inicio y el fin del calendario

Un Start Time sin zona horaria se trata como UTC.

​

Duración de la ejecución

Una ejecución no puede durar más de 2 años, ya sea que la duración provenga de la duración del modelo o de los tiempos Start y End del calendario.

​

Submodelos

La validación también verifica cada submodelo colocado en el lienzo. Un error dentro de uno se reporta con un prefijo que nombra el submodelo y el ModelNode que lo usa, como “Nested model ‘cell_a’ (used by model node ‘fab_cell’): …”

​

Qué NO detecta la validación

La validación detecta problemas estructurales y a nivel de tipo. Algunas cosas se le escapan:

• Corrección semántica. Un modelo que se ejecuta puede aun así codificar suposiciones equivocadas sobre tu operación. La validación no puede decirte que un proceso de 30 segundos en realidad debería ser de 30 minutos.
• Parámetros de distribución. El botón de reproducir no verifica que los parámetros de una distribución sean legales (por ejemplo, una moda Triangular fuera de sus límites). La ejecución corrige esos valores y reporta un aviso de tiempo de ejecución; consulta Distribuciones. Tampoco juzga si una distribución se ajusta a tus datos.
• Aritmética en tiempo de ejecución. Una división entre cero o un valor que no es un número se fija en 0 durante la ejecución y se reporta como un aviso de tiempo de ejecución.
• Inanición de recursos. Un modelo donde un recurso crítico queda retenido para siempre por una entidad atascada valida sin problemas pero produce resultados sin sentido. Lee los resultados de la ejecución para detectar esto.
• Diseño de la comparación. La validación mira un solo modelo; no juzga si estás comparando las ejecuciones correctas.
• Rendimiento. Un modelo válido aún puede tardar mucho tiempo en ejecutarse. Usa duraciones cortas mientras iteras.

Cuando una ejecución termina con avisos de tiempo de ejecución, un toast lo indica (“Ejecución completada con 2 avisos de tiempo de ejecución — los resultados pueden verse afectados”). Revísalos antes de confiar en los resultados.

​

La validación y Dexter

Los cambios que hace Dexter se verifican con las mismas reglas, más algunas verificaciones adicionales del lado de Dexter, como los parámetros de distribución. Dexter ve los errores y advertencias resultantes después de cada edición. Una edición que deja errores pone el botón de reproducir en rojo, igual que una tuya. Si Dexter falla repetidamente al intentar corregir algo, lee los errores tú mismo: a menudo la corrección necesita un dato que Dexter no pudo inferir (una constante faltante, un nombre de atributo que no existe en el tipo de entidad), y decirle ese dato a Dexter lo desbloquea.

​

Consejos

• Corrige primero los errores de conexión. Los errores de componentes desconectados suelen ocultar errores de expresión que no pueden verificarse hasta que la estructura sea sólida.
• Lee las advertencias, no solo los errores. Un botón ámbar aún se ejecuta, pero un ciclo de retardo cero o un ciclo de retención y espera es cómo un modelo termina estancándose en lugar de fallar rápido.
• Los mensajes de error son específicos. Si uno es confuso, busca su frase clave en la documentación: la mayoría de los errores se corresponden directamente con un concepto cubierto en esta referencia.
• Trata el botón rojo como información. Te evita esperar por una simulación que iba a fallar.