Modelos, abstracciones y límites de validez

Una representación útil no es una copia reducida

Un equipo revisa un servicio que recibe órdenes clínicas, consulta un proveedor de identidad, valida reglas de prescripción y entrega la orden a una farmacia. Alguien dibuja cajas y flechas; otra persona escribe una tabla de estados; una tercera calcula cuánto tarda la cola cuando la red se degrada. Los tres artefactos pueden ser técnicamente correctos y, sin embargo, responder preguntas diferentes.

El problema aparece cuando se olvida esa diferencia. El diagrama de flujo se presenta como si describiera también la autorización; el cálculo de latencia se toma como evidencia de que no habrá duplicados; la tabla normativa de estados se lee como prueba de que la implementación nunca toma un atajo. El resultado no es necesariamente un modelo falso. Es una conclusión que ha viajado fuera de las condiciones que la hacían defendible.

Un modelo es una representación deliberada de un sistema, un fenómeno o una decisión para una pregunta concreta. Una abstracción selecciona información pertinente e ignora el resto para ese propósito. El modelo no gana valor por acumular detalles: gana valor cuando conserva las relaciones que pueden cambiar la decisión, declara lo que deja fuera y permite contrastar sus supuestos.

Los capítulos anteriores proporcionaron el vocabulario para esta disciplina. Ya distinguimos activos, propiedades, eventos, vulnerabilidades y riesgo; sabemos que una observación no es una inferencia y que una conclusión tiene alcance; y aprendimos que la ausencia de un hallazgo depende de cobertura y observabilidad. Aquí reunimos esas distinciones en un objeto de trabajo: una representación cuyo uso debe poder justificarse. El siguiente capítulo estudiará causalidad y causa raíz; este capítulo prepara el terreno, pero no sustituye ese análisis ni el threat modeling posterior.

El propósito decide qué merece aparecer

La primera pregunta al construir un modelo no es «¿qué notación usaremos?», sino «¿qué decisión debe informar?». NIST define una abstracción como una vista que enfoca la información relevante para un propósito y omite el resto. Esa definición contiene una advertencia: la suficiencia no es una propiedad absoluta de un dibujo. Una representación adecuada para localizar interfaces puede ser inadecuada para razonar sobre estados o rendimiento.

Supongamos que la pregunta es: «¿Qué componentes y fronteras atraviesa una orden antes de llegar a la farmacia?». Una vista de estructura puede conservar aplicación, proveedor de identidad, API, cola y farmacia, con los flujos y autoridades entre ellos. No necesita mostrar cada función interna de la base de datos. Si la pregunta cambia a «¿puede revocarse una orden después de aprobarla y antes de dispensarla?», la vista de estructura es insuficiente: necesitamos estados, transiciones, actores y eventos. Para «¿qué ocurre si la red duplica solicitudes?», hacen falta parámetros de entrega, reintentos, capacidad y una regla de idempotencia.

Omitir no es ocultar. Es una decisión editorial y técnica que debe quedar registrada. Una omisión es aceptable cuando no altera la respuesta dentro del dominio de uso; si puede alterar el resultado, debe aparecer como límite, variable o prueba pendiente. NIST llama a esto clear abstractions: las abstracciones deben ser simples, bien definidas, exactas, precisas, necesarias y suficientes. «Simple» no significa superficial; significa que el lector puede reconocer qué significa cada elemento y qué relación se afirma.

El nivel de abstracción es la distancia entre el fenómeno y la representación. A nivel de componente podemos preguntar si una función verifica una firma. A nivel de servicio, si el resultado de esa verificación se conserva al pasar por una API, una cola y un operador. A nivel de organización, si la recuperación de cuenta permite cambiar la autoridad que el servicio pretende proteger. Ningún nivel es «el real» por sí mismo. Cada uno conserva unas relaciones y pierde otras.

Una señal práctica ayuda a elegir nivel: si dos situaciones que el modelo trata como iguales llevarían a decisiones distintas, falta una distinción. Si dos situaciones que el modelo separa nunca cambiarían la decisión y complican el análisis, quizá existe detalle accidental. Este criterio no autoriza a borrar casos incómodos; obliga a demostrar que la equivalencia es válida para la pregunta.

Una plataforma, tres modelos complementarios

Volvamos al servicio de órdenes clínicas. La afirmación inicial es estrecha: «una orden aprobada sólo llega a la farmacia cuando conserva una autorización clínica vigente y una trazabilidad suficiente para reconstruir quién decidió qué». No es todavía un threat model ni una garantía universal. Es una pregunta sobre propiedad, transición y evidencia.

La vista de estructura

La primera representación muestra elementos e interfaces: prescriptor, aplicación, proveedor de identidad, API de órdenes, motor de validación, cola, farmacia y registros. Distingue sistemas de interés, sistemas que habilitan la operación y sistemas que interoperan con ella. La identidad no desaparece por estar «fuera» del producto: si una respuesta del proveedor concede o conserva autoridad, su interfaz pertenece al argumento.

Esta vista permite localizar dónde cambia el significado de una identidad, dónde se transforma una orden y quién puede aceptar una respuesta. No demuestra que las transiciones sean correctas. Tampoco permite estimar por sí sola qué ocurre si una solicitud se repite durante una interrupción. Su omisión deliberada son los estados internos y el tiempo detallado.

La máquina de estados

La segunda representación conserva los estados relevantes de una orden: borrador, enviada, validada, aprobada, revocada, entregada y dispensada. Cada transición tiene una condición, un principal autorizado y un efecto observable. El estado aprobada no es una etiqueta decorativa: debe decir qué identidad fue verificada, contra qué versión de reglas y hasta cuándo puede usarse.

Este modelo hace visibles errores que el mapa estructural no muestra. Una implementación puede aceptar dispensada después de revocada porque la cola no vuelve a comprobar el estado. Puede permitir que la recuperación de una cuenta cree una nueva credencial sin invalidar una aprobación pendiente. Puede registrar «aprobada» aunque el mensaje que la transporta se duplique. La máquina de estados no resuelve esos problemas, pero convierte una intuición en transiciones que pueden inspeccionarse y probarse.

El modelo de entrega y rendimiento

La tercera representación conserva llegadas, capacidad, tiempo de servicio, reintentos, expiración y pérdida de mensajes. Sus parámetros podrían ser tasa de órdenes por minuto, tamaño máximo de la cola, ventana de reintento e identificador de idempotencia. Sirve para preguntar si la cola se desborda, cuánto tarda una orden o en qué condiciones aparecen duplicados.

No debe confundirse un número de latencia con una propiedad de autorización. Un modelo puede predecir que el 99 % de las órdenes se procesa en menos de un minuto y seguir sin representar que una autorización revocada se rechace. También puede predecir ausencia de duplicados bajo reintentos de una sola solicitud y fallar en una red que entrega la misma petición a dos regiones.

La figura siguiente reúne estas tres vistas: el propósito no es enseñar una notación, sino hacer visible que cambiar la pregunta cambia la información que debe conservarse. Las vistas pueden relacionarse mediante trazabilidad, pero no se sustituyen ni se fusionan en un dibujo que pretenda explicarlo todo.

Estructura, estados y rendimiento conservan relaciones diferentes; ninguna vista acredita por sí sola las propiedades de las otras.

Normativo y descriptivo: lo que debe ocurrir frente a lo que ocurre

Un modelo descriptivo representa estados, relaciones o comportamientos observados o documentados. Puede describir que la aplicación envía un token al API, que la cola reintenta tres veces o que un operador puede reactivar una orden. Su calidad depende de la procedencia, la cobertura y la fecha de los datos. No es «neutral»: toda descripción elige qué observar y cómo codificarlo.

Un modelo normativo representa una regla, requisito o política: una orden revocada no debe dispensarse; toda transición a aprobada requiere una identidad clínica vigente; un mensaje repetido debe producir como máximo una operación efectiva. Su calidad depende de que exprese la necesidad correcta y de que sus términos sean verificables. No es evidencia de cumplimiento.

Compararlos produce información. Si el modelo normativo excluye la transición revocada → dispensada y el descriptivo la observa en un camino de recuperación, hay una discrepancia que investigar. Si se dibuja sólo el modelo normativo, el sistema puede parecer seguro por definición. Si se dibuja sólo el descriptivo, una práctica habitual puede confundirse con una autorización legítima. Mantener ambos, con nombres y procedencia distintos, evita esa confusión.

La verificación conecta el modelo normativo con artefactos y reglas: ¿la tabla de transición está completa?, ¿las unidades son coherentes?, ¿la implementación rechaza cada transición no permitida?, ¿la ecuación de cola se ejecuta como se especificó? La validación pregunta algo distinto: ¿esta política protege realmente la misión clínica?, ¿la representación incluye recuperación, humanos y conectividad del entorno previsto?, ¿la decisión que tomaremos con la salida es apropiada? Puede verificarse con exactitud un requisito equivocado.

Un modelo formal ayuda a eliminar ambigüedad sintáctica y a mantener trazabilidad. SysML v2, por ejemplo, ofrece una semántica y relaciones para especificar estructura, comportamiento, análisis y verificación. Eso mejora consistencia entre vistas. No convierte sus elementos en observaciones del mundo: la formalidad de la notación no valida que el proveedor de identidad responda así en producción ni que el operador siga la política.

De una frase a una propiedad que pueda refutarse

Una proposición afirma algo que, una vez fijados sus referentes, puede ser verdadero o falso. «La orden 17 está aprobada en este estado» es una proposición; «el sistema es suficientemente seguro» aún necesita precisar qué propiedad y condiciones se juzgan. Un predicado deja argumentos abiertos: Aprobada(o, s) significa que la orden o está aprobada en el estado s. Al elegir una orden y un estado obtenemos una afirmación evaluable.

Los cuantificadores indican a qué conjunto se aplica la afirmación. «Para toda orden» se escribe ∀o; «existe al menos una orden» se escribe ∃o. Siempre hay que declarar el dominio: órdenes de esta versión y entorno, por ejemplo. Una afirmación universal se refuta con un contraejemplo del dominio; muchos ejemplos favorables no bastan por sí solos para demostrarla. La lógica proposicional y de predicados permite expresar estas diferencias sin atribuirles evidencia empírica automática. Lamport, Specifying Systems, §§1.1 y 1.3

Construyamos un ejemplo propio, deliberadamente pequeño. Para cada orden guardamos dos datos: revocada, que comienza en falso, y entregas, que comienza en cero. En este modelo, revocar es irreversible. Una transición Entregar sólo se permite cuando revocada es falso y entregas vale cero; su efecto es incrementar entregas a uno. Una transición Revocar cambia revocada a verdadero y no altera entregas. No modelamos aquí identidades, conectividad ni la dispensación física: este fragmento sólo representa la entrega lógica y su revocación.

Un estado asigna valores a las variables elegidas. Una transición relaciona un estado anterior con uno posterior mediante una condición y un efecto. Una traza es una secuencia de estados y transiciones. La especificación delimita cuáles admite el modelo; una traza registrada pretende describir una ejecución particular. No son el mismo objeto.

Una invariante es una propiedad de estado que se mantiene en todos los estados alcanzables admitidos. En nuestro ejemplo proponemos: para toda orden, entregas ≤ 1. No basta escribir esa desigualdad en un requisito. Para justificarla en el modelo comprobamos el estado inicial y que cada transición permitida la conserva. Este razonamiento sobre invariantes y comportamientos se desarrolla en Lamport, §§2.1 y 5.7; aplicarlo a este pequeño modelo no demuestra que una implementación real respete sus transiciones.

Observemos ahora esta traza sintética de una sola orden:

Desliza horizontalmente para consultar todas las columnas.

En s2 no se viola «como máximo una entrega». Tampoco se deshace la entrega anterior: revocar ahora no cambia el pasado. s3, en cambio, es un contraejemplo a esa invariante y no es una transición permitida: falla tanto la condición de no revocación como la de no entrega previa. Si la traza procede de observaciones fiables del sistema, demuestra una discrepancia con la especificación para esa ejecución. Todavía no identifica su causa interna; podría haber un defecto de coordinación, una ruta distinta o un registro incorrecto que deba descartarse.

Hay una diferencia adicional. «No entregar después de revocar» relaciona pasos de una ejecución; no equivale a exigir que una orden revocada tenga siempre cero entregas. Esta última formulación rechazaría erróneamente s2, donde la entrega ocurrió antes. Para expresar propiedades históricas mediante estados podemos añadir memoria del pasado, pero esa decisión aumenta el modelo y debe justificarse. Elegir mal las variables puede hacer que una regla correcta parezca imposible o que una regla incompleta parezca suficiente.

La comprobación deja dos conclusiones distintas: la especificación propuesta conserva el límite de una entrega bajo sus reglas; la traza s0–s3 no pertenece a sus ejecuciones permitidas. No podemos concluir que todas las ejecuciones reales sean conformes porque las primeras tres filas lo sean, ni que el dominio completo sea incorrecto porque una ejecución lo contradiga. El valor profesional está en precisar qué se afirma y qué observación podría refutarlo.

s2 conserva una entrega anterior a la revocación; s3 aumenta entregas a dos y viola la invariante y las condiciones de transición.

Parámetros y assumptions no son decoración

Un parámetro es una entrada con semántica definida: tasa de llegada, tiempo de expiración, número de reintentos, versión de la política o población de usuarios. Una variable cambia durante el fenómeno: la longitud de la cola, el estado de una orden o la conectividad de un cliente. Confundir ambas cosas produce modelos difíciles de recalibrar y conclusiones que parecen más estables de lo que son.

Una assumption es una condición que el modelo acepta para poder operar. «Los relojes están sincronizados», «la respuesta del proveedor de identidad no se retrasa más de cinco segundos», «cada orden tiene un identificador único» y «la distribución de llegadas de hoy representa el próximo mes» son assumptions, no hechos por aparecer en el archivo de configuración. Cada una debe tener fuente, fecha, responsable y una forma de comprobarse o de analizarse por sensibilidad.

Conviene distinguir cuatro clases de límite:

• Frontera: qué elementos, interfaces, personas y dependencias pertenecen al sistema de interés.
• Estado y tiempo: qué modos, transiciones, ventanas y fases del ciclo de vida se representan.
• Datos y población: de qué versión, región, usuarios, carga y observaciones proceden las entradas.
• Semántica y objetivo: qué significa cada campo, qué propiedad se decide y qué umbral importa.

La frontera no es una línea de propiedad legal. Un proveedor externo puede quedar fuera del control directo y dentro del entorno que condiciona la seguridad. El tiempo tampoco es un detalle de consulta: una política puede ser válida en una versión y no en la siguiente; una cola puede comportarse de forma diferente en horario normal y en recuperación. Declarar «producción» no basta si se excluyen los cambios de configuración, el soporte y la restauración.

Un modelo debería conservar un dominio de validez: el conjunto de versiones, estados, entornos, poblaciones, rangos de parámetros y usos para los que existe evidencia suficiente. «Válido» aquí significa adecuado para una pregunta en esas condiciones; no significa verdadero para todo contexto. El dominio puede representarse como una tabla de inclusión y exclusión o como un argumento explícito. Si se cambia una condición material, la conclusión pasa a ser una hipótesis pendiente de revalidación.

Validar no es comparar un número atractivo

La evaluación de modelos tiene dos errores simétricos. El primero es verificar la implementación de un modelo y llamarlo validado. El segundo es observar que su salida «parece razonable» y omitir las reglas, estados y transformaciones que la producen.

Para verificar el modelo de órdenes clínicas, podemos revisar que cada transición tenga una condición, que los estados sean alcanzables o explícitamente terminales, que el cálculo de latencia use unidades coherentes y que la implementación respete los límites declarados. También podemos comparar una ejecución del modelo con resultados conocidos cuando la respuesta sea derivable.

Para validarlo, necesitamos preguntar si esas representaciones sirven al uso previsto. ¿Incluyen el proveedor de identidad y recuperación? ¿Representan la conectividad y el trabajo humano de la farmacia? ¿La carga y población de prueba se parecen al entorno que motivará la decisión? ¿El criterio «trazabilidad suficiente» está operacionalizado? La validación puede usar análisis, inspección, demostración o pruebas; el método debe producir evidencia pertinente, no simplemente más datos.

NASA formula la distinción de forma útil: la validación muestra que el producto cumple su propósito en el entorno previsto, mientras que la verificación muestra conformidad con requisitos especificados. NIST, en su proceso de validación, incluye la selección de acciones según alcance, restricciones, datos de amenaza, tamaño y complejidad. La pregunta adecuada no es «¿está validado?», sino «¿validado para qué uso, con qué evidencia y bajo qué restricciones?».

La validación tampoco es una ceremonia final. Se actualiza cuando cambian versión, arquitectura, población, proceso de recuperación o dependencia. NIST SP 800-160 pide mantener la base de evidencia frente a variaciones relevantes del ciclo de vida. El modelo forma parte de esa base: si una modificación cambia una interfaz o un supuesto, no basta conservar el sello de la evaluación anterior.

Sensibilidad: descubrir qué sostiene la conclusión

El análisis de sensibilidad estudia cómo cambia la salida cuando se varían entradas, parámetros, supuestos o decisiones estructurales. No es una predicción de probabilidad ni un sustituto de la evidencia. Su función es localizar dependencias críticas.

En el caso conductor podemos variar la ventana de expiración de una aprobación, la tasa de reintentos, el retraso del proveedor de identidad y la capacidad de la cola. Si la conclusión «no hay duplicados» cambia sólo cuando aparece un reintento, la idempotencia y la semántica de entrega merecen una prueba prioritaria. Si cambia al pasar de cinco a treinta segundos de retraso, la política de expiración y el reloj distribuido son puntos de fragilidad. Si no cambia en un rango amplio, existe una región de estabilidad que conviene documentar, sin convertirla en garantía fuera de ese rango.

También se puede variar la estructura. Eliminar la etapa de revocación, tratar la farmacia como actor sin estado o asumir que el proveedor de identidad es instantáneo no son pequeños ajustes numéricos: son cambios de modelo. Una conclusión robusta debe indicar qué relaciones son invariantes y cuáles dependen de esas elecciones.

La sensibilidad tiene dos resultados prácticos. Primero, orienta la recolección: medir un parámetro de alto impacto puede valer más que aumentar la precisión de uno irrelevante. Segundo, calibra el lenguaje: «la conclusión se mantiene entre 1 y 3 reintentos bajo pérdida inferior al 0,1 %» es informativo; «el modelo demuestra fiabilidad» borra la condición. NASA recomienda registrar incertidumbre y sensibilidad para que quien decide entienda la credibilidad del resultado y sus límites.

No hay que confundir sensibilidad con severidad. Que un resultado sea sensible a la disponibilidad de la cola no dice que el incidente sea frecuente ni que su impacto sea máximo. Une el resultado a una entrada; la evaluación de riesgo posterior debe interpretar esa dependencia con activos, amenazas, impacto y horizonte.

La composición puede crear propiedades nuevas

Cada modelo puede ser adecuado para su pregunta y aun así fallar al combinarse. El mapa de estructura puede decir que la API consulta identidad; la máquina de estados puede asumir que esa consulta es siempre reciente; el modelo de entrega puede asumir que el mismo mensaje se procesa una sola vez. La composición completa hereda el peor supuesto o crea un comportamiento que ningún modelo aislado mostró.

NIST describe la compositional trustworthiness como una propiedad emergente: la confianza en el agregado no se sigue automáticamente de la confianza declarada para cada elemento. Hay que tratar la composición como una unidad, inspeccionar interfaces y comprobar que las semánticas se conservan. En el caso clínico, identidad, autorización y entrega deben referirse al mismo sujeto, versión y orden. De lo contrario, cada modelo puede ser correcto en su propio vocabulario y el flujo completo aceptar una orden obsoleta o duplicada.

La composición también puede romper independencia. Dos controles que aparecen en cajas separadas pueden compartir la misma credencial de administración o la misma fuente de reloj. Un proveedor de identidad y la aplicación pueden estar disponibles, pero depender de la misma región. La vista estructural debe conservar esas dependencias si pueden cambiar la conclusión; el modelo de rendimiento debe reflejar la capacidad compartida; el modelo de estados debe mostrar el modo degradado.

Este análisis no pretende anticipar todos los ataques. Enseña una precaución más básica: una propiedad sólo viaja entre abstracciones cuando la interfaz preserva su significado y sus supuestos. El threat modeling que vendrá después podrá usar estas vistas para estudiar adversarios y fronteras; no debe aceptar sus nombres como evidencia de que las vistas son completas.

Cuando trasladar el modelo cambia el problema

Un modelo validado en la clínica central se propone para una unidad móvil. La aplicación móvil pierde conectividad, almacena temporalmente órdenes, usa otra versión del cliente y reintenta solicitudes al recuperar señal. El proveedor de identidad puede tardar más; los relojes pueden divergir; el operador puede trabajar en un modo degradado. No es lícito conservar automáticamente la misma conclusión porque «la API es la misma».

La transferencia debe comenzar con una comparación de invariantes. ¿Sigue siendo único el identificador? ¿La identidad puede verificarse con las mismas garantías? ¿Se preserva el orden de estados? ¿La política de revocación alcanza una orden almacenada? ¿La cola conoce que un reintento es la misma operación? ¿La población, región y versión están dentro del dominio documentado? Las diferencias que no cambian la propiedad pueden aceptarse con evidencia; las demás exigen recalibrar o construir un modelo nuevo.

Los modelos fallan al trasladarse por varios mecanismos: cambios de escala que vuelven dominantes las colas; cambios de tiempo que invalidan expiraciones; cambios de población que alteran la distribución de uso; cambios de autoridad que introducen otro operador; cambios de implementación que rompen una interfaz; y cambios de propósito que convierten una métrica auxiliar en decisión principal. A veces falla la estructura; a veces sólo fallan parámetros. Distinguir ambos casos evita tanto la confianza heredada como la reconstrucción innecesaria.

El lenguaje de la conclusión debe seguir esa distinción. «El modelo representa el flujo de aprobación para la versión 4.2 en la clínica central, con sincronización inferior a cinco segundos y recuperación manual» es transferible sólo en la medida en que esas condiciones se mantengan o se vuelva a validar la representación. «El sistema de órdenes es seguro» no es una transferencia: es una afirmación sin dominio.

El paso de un entorno conectado a un cliente móvil cambia los supuestos de entrega y revocación y exige revalidar o restringir la conclusión.

Un registro mínimo para trabajar con modelos

Antes de usar una representación para una decisión, conviene poder responder:

1. ¿Qué pregunta y qué decisión motivaron el modelo?
2. ¿Cuál es el sistema de interés, su frontera y su versión?
3. ¿Qué elementos, relaciones, estados y métricas conserva?
4. ¿Qué omite y por qué esa omisión no cambia la decisión en el uso declarado?
5. ¿Qué parámetros, variables y supuestos tiene cada entrada?
6. ¿Qué evidencia verifica reglas, cálculos, trazabilidad y correspondencia con el artefacto?
7. ¿Qué contraste valida la representación para el entorno y uso previstos?
8. ¿Qué variación de contexto, parámetro o interfaz obligaría a recalibrar o descartar la conclusión?

Este registro puede ser una tabla, una página de un repositorio o parte de un caso de assurance. No es burocracia independiente de la ingeniería: permite que otra persona entienda por qué el modelo existe, reproduzca la evaluación y detecte cuándo dejó de ser aplicable. La precisión útil está en los referentes y las condiciones, no en llenar campos por costumbre.

Síntesis: una conclusión vive dentro de su modelo

Modelar es decidir qué relaciones deben permanecer visibles para una pregunta. Abstraer permite controlar complejidad, pero sólo si la selección, las omisiones y el nivel de detalle son explícitos. Una vista estructural localiza elementos e interfaces; una máquina de estados explica transiciones; un modelo de rendimiento estudia capacidad y tiempo. Pueden cooperar, pero no se convierten mágicamente en una sola garantía.

Los modelos descriptivos muestran lo que ocurre; los normativos expresan lo que debería ocurrir. Verificar comprueba reglas y requisitos de la representación. Validar comprueba que la representación sirve al uso y entorno que motivan la decisión. Parámetros y assumptions deben tener semántica, procedencia y rango. La sensibilidad encuentra qué sostiene una conclusión; la composición revela supuestos compartidos y propiedades emergentes.

Un resultado bien escrito incluye su dominio de validez y las condiciones de transferencia. Cuando cambia una versión, una frontera, un estado, una población, un parámetro crítico o el propósito, la conclusión no se conserva por inercia. Se revalida, se restringe o se abandona. Esta disciplina no debilita el conocimiento: permite saber exactamente qué parte merece confianza y qué pregunta nueva debe formularse.

Comprobación de comprensión

1. ¿Por qué un modelo no debe juzgarse por la cantidad total de detalles que contiene?
2. Distingue una vista de estructura, una máquina de estados y un modelo de rendimiento para el caso de órdenes clínicas.
3. Un diagrama conecta el estado «aprobada» directamente con «dispensada». ¿Qué preguntarías antes de aceptar esa transición?
4. ¿Qué diferencia hay entre un modelo descriptivo y uno normativo cuando ambos muestran la misma autorización?
5. Enumera tres assumptions que podrían limitar un modelo de cola de validación.
6. Un modelo calcula correctamente la latencia de una cola sintética, pero la clínica móvil pierde conectividad. ¿Está verificado, validado, ambas cosas o ninguna?
7. Si variar la tasa de reintentos cambia de «sin duplicados» a «duplicación probable», ¿qué enseña la sensibilidad?
8. ¿Qué tendría que cambiar para transferir un modelo validado en la clínica central a una unidad móvil?
9. En la traza s0–s3, identifica el primer estado que viola entregas ≤ 1 y las condiciones de transición incumplidas. ¿Por qué s2 no demuestra una entrega posterior a la revocación?
10. Formula con «para toda» y «existe» la propiedad de una entrega máxima y su negación. Explica qué demostraría una traza adversa fiable y qué no permiten concluir cien trazas favorables.

Problema de transferencia

Una organización modela su API de prescripción con un DFD que excluye al proveedor de identidad porque lo considera «externo». El modelo se valida con tráfico normal en producción y se concluye que ninguna orden no autorizada puede llegar a la farmacia. Después se añade recuperación de cuenta por soporte y una aplicación móvil que reintenta solicitudes sin un identificador de idempotencia.

Rehaz el argumento. Elige las vistas necesarias; separa modelos descriptivos y normativos; enumera assumptions; propone pruebas de verificación y validación; y explica qué parte de la conclusión deja de ser válida. Una respuesta sólida debe ampliar la frontera para incluir interfaces y autoridad, representar transiciones y reintentos, y demostrar qué invariantes sobreviven al entorno móvil. No basta con añadir una caja al DFD: hay que justificar la semántica de la interfaz, recalibrar parámetros y declarar la nueva conclusión con un dominio de validez.

Fuentes principales

• Ron Ross, Mark Winstead y Michael McEvilley. NIST SP 800-160 Vol. 1 Rev. 1: Engineering Trustworthy Secure Systems.
• Conrad E. Bock et al. Conceptual Modeling: Research Challenges in Modeling and Simulation for Engineering Complex Systems. NIST, 2017.
• NASA. 2.0 Fundamentals of Systems Engineering.
• NASA. SWE-070: Models, Simulations, Tools.
• Object Management Group. OMG Systems Modeling Language v2.0.
• NIST. SP 1030: Evaluation of Fire Models.