• No se han encontrado resultados

Lenguajes para la descripción de Modelos de Comporta-

2.3. Modelos de Comportamiento

2.3.2. Lenguajes para la descripción de Modelos de Comporta-

El modelado de sistemas reactivos mediante la manipulación directa de máquinas de estados, como los LTSs, se vuelve poco práctico a medida que el número de estados y transiciones de los componentes crece (como muestra la Figura8). Surgieron así numerosos lenguajes para la especificación de sistemas reactivos, que cuentan con una sintaxis simple e intuitiva, además de una semántica formal, lo que los hace adecuados para el análisis automático. Muchas de la metodologías de ingeniería de requisitos (como KAOS y SCR, las utilizadas en esta tesis) adoptaron estos lenguajes para evaluar y mejorar la calidad de sus especificaciones.

En esta sección presentaremos tres lenguajes muy utilizados para modelar y analizar el comportamiento de sistemas reactivos, que además servirán de soporte para muchas de las técnicas desarrolladas en este trabajo: FSP, Promelay Action Language.

FSP: Procesos de Estados Finitos

Particularmente, los lenguajes basados enálgebras de procesos (o cálculos de procesos) han mostrado ser un formalismo adecuado para la descripción de sistemas que involucran interacción y sincronización de varios procesos. Entre los más destacados podemos mencionar al lenguaje CCSintroducido por Robin

2.3 modelos de comportamiento 30

Milner [Milner, 1980] y CSP introducido por C. A. R. Hoare [Hoare, 1985], siendo éstos los que sentaron las bases de las álgebras de procesos.

En este trabajo utilizaremosFSP (Finite State Processes) [Magee and Kra- mer, 2006], un lenguaje introducido por Jeff Kramer y Jeff Magee, ampliamente adoptado en los últimos años para el análisis y diseño de sistemas concurrentes. Tál como lo explican sus creadores, la semántica de FSP se basa en la semántica de CCS, mientras que la sintáxis es muy similar a la del lenguaje CSP. Un punto muy importante es que toda expresión FSP puede ser automáticamente mapeada a un LTS finito y viceversa.

Una especificación FSP contiene básicamente un conjunto de definiciones de procesosprimitivosy procesoscompuestos. Los procesos son definidos utilizando las siguientes construcciones: -> denota un prefijo de acción, | denota una elección, y elecciones condicionales son expresadas por medio de clausulas when. Además, los procesos pueden ser indexados y parametrizados, y pueden ser compuestos de forma secuencial (;) o en paralelo (||). En la Figura 9 se puede observar la especificación FSP del sistema que describe el comportamiento de la bomba en la mina.

range R = 0..2

WaterLevel = WaterLevel[0],

WaterLevel[i:R] = (when (i==0) aboveLow ->WaterLevel[1] | when (i==1) belowLow ->WaterLevel[0] | when (i==1) aboveHigh ->WaterLevel[2] | when (i==2) belowHigh ->WaterLevel[1]).

Pump = (belowLow -> switchPumpOff ->Pump | aboveHigh -> switchPumpOn ->Pump).

||SYS = (WaterLevel || Pump).

Figura 9: Especificación FSP de la bomba en la mina.

Un prefijo de acción x -> P describe un proceso que ejecuta la acción xy luego pasa a comportarse como el proceso P. Por ejemplo,aboveHigh -> switchPumpOn -> Pump de la Figura 9, indica que al detectar que el nivel del agua es alto (aboveHigh), luego se prende la bomba ejecutando la acción switchPumpOn, y el proceso pasa a comportarse como Pump. Además, puede observarse que en la definición del procesoPumpse utiliza el operador de elección (|). Por otra parte, vemos que en la definición del procesoWaterLevel tenemos elecciones condicionales utilizando la guarda when. Más aún, utilizamos elección no determinista en el nivel medio de agua (condiciónwhen (i==1)) para modelar

2.3 modelos de comportamiento 31

que el nivel puede volverse bajo o alto de manera no determinista. SYS es el proceso paralelo que compone los procesos WaterLevel y Pump, mostrado en la Figura 8.

Labeled Transition System Analyzer (LTSA) es la herramienta presentada en [Magee and Kramer, 2006] que permite construir automáticamente LTSs a partir de especificaciones FSP. Además,LTSA facilita el análisis de propiedades que suelen ser de interés verificar sobre sistemas reactivos, como ausencia de deadlocks (el sistema no alcanza un estado de bloqueo) y progreso de ciertos eventos del sistema. En el Capítulo4veremos como podemos utilizarLTSApara analizar especificaciones de requisitos.

Promela

En este trabajo también haremos uso del lenguaje de especificaciónPromela (Protocol/Process Meta Language) [Holzmann, 1991], introducido por Gerard Holzmann. Promela provee una sintaxis simple para la descripción de procesos, muy similar a la sintaxis del lenguaje de programación C, por lo que en sus orígines fué rapidamente adoptado como lenguaje de modelado. En particular, Promela fue muy utilizado como una abstracción para el diseño de protocolos de red. Además, su adopción como lenguaje de especificación esta fuertemente asociado al éxito de Spin [Holzmann, 2004], el model checker utilizado para análizar este tipo de especificaciones (presentado a continuación en Sección 2.5).

Una especificación Promela consiste de declaraciones de tipos, canales, varia- bles y procesos. Esta especificación se corresponde a un sistema de transiciones, usualmente muy grande, pero finito. Los procesos pueden crearse de manera dinámica, pueden comunicarse de manera síncrona o asíncrona, utilizando me- moria compartida o por pasaje de mensajes. En la Figura 10puede encontrar una simple especificación en Promela del sistema que controla la bomba en la mina. Puede observar que el proceso WaterLevelmodela el ambiente y cómo el nivel del agua dentro de la mina se modifica de manera no determinista. El proceso Pump monitorea ese nivel de agua y controla el estado de la bomba: la prende cuando (water > High) y la apaga cuando (water < Low). init es el proceso principal del sistema: a partir de él se pueden generar el resto de los procesos que van a ejecutarse de manera concurrente con la sentenciarun. Puede encontrar una descripción detallada de la sintaxis Promela en [Holzmann, 1991]. En el Capítulo5 veremos como es posible codificar una especificación de requisitos SCR en Promela, para luego poder analizarlas utilizando el model checker Spin.

2.3 modelos de comportamiento 32 #define Low 5 #define High 10 #define true 1 #define false 0 short water; bool PumpOn; proctype WaterLevel() { do :: water++; :: water--; :: skip; od } proctype Pump(){ do

:: (water < Low) -> PumpOn = false; :: (water > High) -> PumpOn = true; :: else -> skip; od } init{ water = 0; run WaterLevel(); run Pump(); }

Figura 10: Especificación Promela del comportamiento de la bomba en la mina.

Documento similar