Sintaxis de modelado IOSA

La Proposición 10 de la subsección anterior habla de caminos simulados sobre un IOSA finito, el formalismo de modelado que presentamos en la Sección 4.4. No obstante, hasta aquí sólo hemos presentado la teoría desarrollada en [DLM16]. Para elegir a IOSA como el lenguaje en el que expresaremos los modelos de nuestros sistemas, necesitamos una sintaxis concreta cuya gramática produzca autómatas acorde a la Definición 17.

Para ello hemos desarrollado la siguiente sintaxis†, que presentamos informal- mente al igual que hicimos con el lenguaje de entrada de PRISM en la Subsec- ción 3.3.1. Las reglas de derivación de esta sintaxis de modelado IOSA son de hecho bastante parecidas a las de PRISM, con el añadido destacable de variables de tipo reloj, cuyos valores son muestreados de distribuciones estocásticas. A continuación proveemos una lista exhaustiva de las diferencias entre el lenguaje de entrada de PRISMcomo se lo usó en esta tesis, y la sintaxis de modelado IOSA que usaremos en las próximas experimentaciones de la secciones:

• en el entorno global sólo pueden definirse constantes, propiedades, y módulos;

• las constantes deben ser o bien de tipo booleano, o de tipo entero, o sino de tipo de punto flotante;

• las propiedades pueden ser especificadas en un archivo independiente, o sino pueden incluirse en al archivo con el modelo, dentro de un entorno

properties...endproperties;

• las consultas de propiedades deben especificarse una por línea y son

transitorias, siguiendo el formato P( !parar U raro ), o sino estacionarias, siguiendo el formato S( raro ),

donde parar y raro son expresiones de valor booleano que representan respectivamente las condiciones de parada (viz. truncado de simulaciones) y de evento raro;

• las variables sólo pueden aparecer dentro del cuerpo de un módulo, viz. encerradas en un entorno module...endmodule;

†_{Mi amigazo y colega Raúl E. Monti y mi director Pedro R. D’Argenio fueron los principales}

4.5.2 Sintaxis de modeladoIOSA 133

• las variables deben ser o bien de tipo booleano, o de tipo entero (acotado), o sino de tipo reloj;

• cada variable de tipo reloj debe estar mapeada a una función de probabilidad continua, y sólo se le pueden asignar valores aleatoriamente escogidos, que resulten del muestreo de tal función;

• las etiquetas no vacías en las aristas de un módulo deben aparecer decoradas o bien con el símbolo ?para indicar que es una acción de entrada (y por

ende unaarista de entrada), o sino con el símbolo!para indicar que es una acción de salida (resp. una arista de salida);

• una etiqueta vacía simboliza un arista de salida no sincronizante;

• una guarda booleana vacía en una arista es interpretada como true;

• un símbolo -> seguido inmediatamente por un punto y coma se interpreta

como NOP, i.e. la ausencia de acciones;

• además de una guarda booleana, las aristas de salida deben declarar el nombre de un reloj entre el caracter@y el símbolo->, que relaciona a dicha variable de tipo reloj con las transiciones de salida concretas representadas por la arista.

Para darle al lector una idea concisa del aspecto de esta sintaxis, mostramos a continuación el extracto de un modelo descripto con ella. El sistema representado es la cola tándem modularisada que introdujimos originalmente en la Código 3.3. Como todas las variables de tipo reloj del modelo de donde extrajimos el Código 4.3 están mapeadas a la distribución exponencial, el modelo IOSA resultante es equivalente a un CTMC.

Código 4.3: ModeloIOSA para la cola tándem (extracto)

1 const int c = 8; // Capacidad de ambas colas

...

14 module Arribos

15 clk0: clock; // Arribos externos ~ Exponencial(lambda)

16 [P0!] @ clk0 -> (clk0’= exponential(lambda));

17 endmodule

18

19 module Cola1 20 q1: [0..c];

21 clk1: clock; // Procesamiento en la Cola1 ~ Exponencial(mu1)

22 // Arribo de paquete

23 [P0?] q1 == 0 -> (q1’= q1+1) & (clk1’= exponential(mu1));

24 [P0?] q1 > 0 & q1 < c -> (q1’= q1+1);

25 [P0?] q1 == c -> ;

26 // Procesamiento de paquete

27 [P1!] q1 == 1 @ clk1 -> (q1’= q1-1);

28 [P1!] q1 > 1 @ clk1 -> (q1’= q1-1) & (clk1’= exponential(mu1));

...

43 properties

44 P( q2 > 0 U q2 == c) // transitoria

45 S( q2 == c ) // estacionaria

46 endproperties

Nótese que la única arista del móduloArribos en la línea 16 del Código 4.3, es una arista de salida dado que su acción P0 está decorada con ‘!’. Su guarda

booleana (entre los caracteres ‘]’ and ‘@’) está vacía y por ende equivale a true.

A su vez, esta arista de salida está asociada al relojclk0, el cual está mapeado a una función de densidad exponencial con tasa lambda.

La acción de salida P0 del móduloArribos synchronises with the input action P0 from module Cola1, i.e. with any of the edges in lines 23–25. The boolean guards of those edges form a partition of the range of the integral variable q1. Therefore, the output edge of module Arribos is always enabled from a logical point of view, and will synchronise with exactly one of the input edges in lines 23–25. From a temporal point of view and by definition of IOSA, la arista de salida es habilitada cuando el reloj clk0 expira.

Este mecanismo de sincronización es similar al del modelo PRISMpara la cola tándem del Código 3.3. Esto es natural, puesto que la sintaxis de modelado IOSA se inspiró originalmente en el lenguaje de entrada de PRISM.

Nótese que los efectos de una arista, i.e. the consequences of taking the edge which are described after the symbol ->, appear enclosed in parentheses and concatenated with the character &. For instance the input edge in line 23 has two

effects: incrementing by one the value of the integral variable q1, and assigning a fresh random value to the clock variable clk1, muestreado de un función de densidad de probabilidad con distribución exponencial de tasa mu1.

Llamamos la atención a la arista de entrada en la línea 25 del Código 4.3. This edge has an empty effect, viz. a semicolon appears immediately following the symbol ->. This is interpreted as a NOP or SKIP, that is, the absence of an

effect. Semantically that edge represents a packet trying to enter a fully occupied first queue, el cual es inmediatamente descartado.

En el Código 4.3 las consultas de propiedades están en el mismo archivo del mo- delo, y por ende aparecen encerradas en un entorno properties. . .endproperties.

la propiedad de la línea 44 es de tipo transitorio, y pregunta por la probabilidad de observar una segunda cola saturada antes de que dicha cola se vacíe. La propiedad de la línea 45 es de tipo estacionario, y pregunta por la proporción de tiempo que la segunda cola permanece saturada, viz. la probabilidad a largo plazo de observar una saturación en dicha cola.

4.5.3.

Generador de Improbabilidad Finita

Desarrollamos la herramienta de software FIG, que implementa la estrategia composicional para división multinivel que describimos en este capítulo. Está escrita exclusivamente en C++ y es software autónomo. El nombre completo de la herramienta es Generador de Improbabilidad Finita, en honor a la obra