INTRODUCCIÓN A José Antonio Glez. Reboredo

INTRODUCCIÓN A
Autor: José Antonio Glez. Reboredo
Jose Antonio Glez. Reboredo
Introducción a SPIN
1. MÉTODOS FORMALES .......................................................................................... 3
1.1. INTRODUCCIÓN .......................................................................................................... 3
1.2. ESPECIFICACIÓN ........................................................................................................ 4
1.3. VERIFICACIÓN ........................................................................................................... 5
1.3.1. COMPROBACIÓN DE MODELOS.................................................................................. 5
1.3.2. PRUEBA DE TEOREMAS ............................................................................................. 5
1.4. TRABAJO FUTURO ...................................................................................................... 7
1.4.1. CONCEPTOS FUNDAMENTALES ................................................................................. 7
1.4.2. MÉTODOS Y HERRAMIENTAS .................................................................................... 7
1.4.3. INTEGRACIÓN DE MÉTODOS ...................................................................................... 8
1.4.4. EDUCACIÓN Y TRANSMISIÓN DE LA TECNOLOGÍA ..................................................... 9
2. SPIN ........................................................................................................................... 10
2.1. CARACTERÍSTICAS GENERALES .............................................................................. 10
2.2. INTRODUCCIÓN ........................................................................................................ 12
2.2.1. ESTRUCTURA ......................................................................................................... 12
2.3. FUNDAMENTOS ........................................................................................................ 14
2.3.1. REQUERIMIENTOS DE LÓGICA TEMPORAL ............................................................... 15
2.3.2. DOMINIO DE APLICACIÓN ....................................................................................... 15
2.4. ALGORITMOS ........................................................................................................... 17
2.4.1. NESTED DEPTH-FIRST SEARCH ................................................................................ 17
2.4.2. PASO DE FÓRMULAS LTL A AUTÓMATAS DE BÜCHI ............................................... 17
2.4.3. REDUCCIÓN DE ORDEN PARCIAL............................................................................. 18
2.5. REQUISITOS DE TIEMPO Y MEMORIA .......................................................................... 18
2
Jose Antonio Glez. Reboredo
Introducción a SPIN
1. Métodos formales
Antes de abordar el estudio de la verificación formal de sistemas distribuidos,
realizaremos una breve introducción acerca de la aplicación de métodos formales a los
ámbitos computacionales.
1.1. Introducción
Actualmente estamos asistiendo a una mejora de los métodos matemáticos para la
verificación y especificación de sistemas hardware y software de elevada complejidad;
de hecho, muchos de estos métodos ya son capaces de afrontar ejemplos reales del
mundo industrial. Esta mejora en los métodos se debe principalmente al desarrollo de
nuevas metodologías y de nuevas y más potentes herramientas (como pueden ser
mejores probadores de teoremas). Es difícil predecir, aún así, cual será el alcance, en el
futuro, de estas técnicas; pero la situación permite un cierto optimismo que debería ser
acompasado de un trabajo en investigación que permita que estas técnicas ayuden en
mayor medida al mundo industrial.
Las técnicas formales son uno de los métodos existentes en la ingeniería del software
para ayudar a la creación de sistemas de elevada complejidad y que, sin embargo,
alcancen los parámetros de eficiencia y eficacia deseados. El uso de métodos formales
no nos garantiza, a priori, la corrección del software, pero es una buena práctica que
permite alcanzar mejores resultados en la construcción de sistemas complejos, ya que
nos permite revelar inconsistencias, ambigüedades, etc.
En el pasado el uso de estas técnicas no fue muy utilizado debido a los problemas que
llevaban asociados, como la dificultad de los métodos, su baja capacidad para escalar,
etc. Actualmente estas técnicas están aumentando su grado de aceptación y mejorando
su capacidad de éxito lo que convierte a los métodos formales en una técnica que no
debemos dejar de tener en cuenta a la hora de buscar métodos para la creación de
sistemas computacionales de calidad. La evolución de estos métodos y los frutos de la
investigación que en ellos se está llevando a cabo nos dirán cual será el papel de estos
métodos en la informática del futuro.
A continuación repasaremos los dos campos de principal aplicación de los métodos
formales: la especificación y la verificación.
3
Jose Antonio Glez. Reboredo
Introducción a SPIN
1.2. Especificación
La especificación es el proceso de describir un sistema y las propiedades que se desea
que tenga. Es de sentido común la afirmación de que, de la correcta especificación de un
sistema, depende en gran medida el éxito o el fracaso en su desarrollo.
La especificación formal se basa en un lenguaje con una sintaxis y un semántica
matemáticamente definidas. En estos métodos es común la utilización de los conceptos
matemáticos de abstracción y composición.
Actualmente, uno de los hitos en la investigación de la especificación formal estriba en
cómo integrar diferentes lenguajes de especificación, cada uno de los cuales sea capaz
de afrontar distintos aspectos de un sistema. Otro punto importante es cómo manejar los
aspectos de un sistema que no se refieren a su comportamiento, como puede ser el
rendimiento, limitaciones de tiempo real, políticas de seguridad o diseño arquitectural.
Los métodos de especificación formal han sido utilizados con éxito en áreas tan diversas
como pueden ser: bases de datos, dispositivos, hardware, medicina, tecnología nuclear,
seguridad, comunicaciones y transporte.
4
Jose Antonio Glez. Reboredo
Introducción a SPIN
1.3. Verificación
La verificación es el proceso que permite comprobar, en mayor o menor medida, si un
sistema cumple las propiedades deseadas en él. En la verificación formal nos
encontramos con dos aproximaciones: comprobación de modelos y prueba de teoremas.
1.3.1. Comprobación de modelos
La comprobación de modelos es una técnica que consiste en construir un modelo finito
de un sistema y comprobar si una determinada propiedad deseada en el sistema se
cumple en el modelo.
Esta comprobación se realiza mediante una búsqueda exhaustiva en todo el conjunto de
estados posibles en el modelo. La finalización de esta comprobación está garantizada ya
que el modelo será finito. El objetivo para la mejora de esta técnica sería encontrar
algoritmos y estructuras de datos que nos permitan manejar grandes espacios de
búsqueda.
Esta técnica se ha utilizado principalmente en sistemas hardware y en la verificación de
protocolos, aunque el objetivo actual es su utilización en el análisis del cumplimiento de
las especificaciones en sistemas software.
Existes dos vertientes de la comprobación de modelos en las prácticas de hoy:
La primera es la comprobación temporal de modelos. En esta aproximación, las
especificaciones son expresadas mediante lógica temporal y los sistemas se modelan
mediante sistemas de transiciones de estado finito. Se utiliza un procedimiento de
búsqueda para comprobar si éste modelo cumple la especificación.
En la segunda aproximación, la especificación se da en forma de autómata. Luego el
sistema, también modelado como un autómata, se compara con la especificación para
determinar si su comportamiento es congruente con la misma.
En comparación con la prueba de teoremas, la comprobación de modelos es totalmente
automática y rápida, pudiendo llegar a dar una respuesta en cuestión de minutos, pero
presenta la desventaja de que se puede enfrentar a una explosión combinatoria que haga
inmanejable el problema.
La comprobación de modelos puede ser utilizada para comprobar especificaciones
parciales, en cuyo caso nos proporciona una valiosa información sobre la corrección de
un sistema, aun cuando éste no esté completamente especificado. Por otro lado cabe
destacar que la comprobación de modelos produce contraejemplos a partir de los cuales
podríamos analizar posibles errores subyacentes en el diseño. Es por este que puede ser
un asistente al debugging.
1.3.2. Prueba de teoremas
5
Jose Antonio Glez. Reboredo
Introducción a SPIN
La prueba de teoremas es una técnica en la que, tanto el sistema, como las propiedades
en él deseadas, se expresan mediante fórmulas en algún tipo de lógica matemática.
Esta lógica viene dada por un sistema formal, el cual define una serie de axiomas y un
conjunto de reglas de inferencia. La prueba de teoremas es el proceso de encontrar la
prueba de una propiedad a partir de los axiomas del sistema. Los resultados que se
vayan consiguiendo en ese proceso de prueba se denominan lemas intermedios.
Estas pruebas pueden ser obtenidas a mano, pero la idea es utilizar una máquina como
asistente en ese proceso de prueba. Hoy en día se está viendo incrementada la
utilización de los probadores de teoremas, para la verificación mecánica de propiedades
críticas en diseños tanto hardware como software. Estos probadores de teoremas pueden
ser clasificados según su grado de automatismo, desde probadores totalmente
automáticos a probadores interactivos. Estos últimos, requieren la interacción con una
persona, lo que, por un lado, los hace más susceptibles a la aparición de errores en la
prueba, pero, por otro lado aumenta enormemente la potencia de los mismos gracias a la
aportación que puede hacer la inteligencia del ser humano.
En contraste con la comprobación de modelos, los probadores de modelos son capaces
de manejar espacios de estados infinitos, esto lo manejan mediante técnicas como la
inducción.
6
Jose Antonio Glez. Reboredo
Introducción a SPIN
1.4. Trabajo futuro
Como se ha visto, el objetivo global de los métodos formales es ayudar a los ingenieros
a construir sistemas con un mayor grado de corrección y, por tanto, mejores. Los
métodos formales son una parte de la computación que se relaciona con prácticamente
todas las demás partes de la Informática, ya que se pretende que sea útil tanto en
sistemas software como hardware y, sus usuarios potenciales, serían todos aquellos
desarrolladores involucrados en procesos de ingeniería de sistemas.
El avance en esta área depende de múltiples factores como son: la investigación en la
misma, inventar nuevos métodos, implementar nuevas herramientas, integrar distintos
métodos para que trabajen juntos y la transmisión de estos conocimientos a las personas
susceptibles de utilizarlos.
1.4.1. Conceptos fundamentales
El trabajo para el avance en este campo debe ser enfocado en las siguientes áreas:
•
•
•
•
•
•
Composición: necesitamos saber cómo componer métodos, especificaciones,
modelos, teorías y pruebas.
Descomposición: necesitamos desarrollar métodos más eficientes propiedades
computacionales de carácter global en una serie de propiedades más simples cuyo
tratamiento sea más asequible.
Abstracción: es difícil especificar y verificar los sistemas reales sin el uso de la
abstracción; por lo tanto, necesitamos identificar diversos tipos de abstracciones y
desarrollar métodos que nos permitan justificarlas formalmente (quizá asistidos por
métodos automáticos).
Modelos y teorías reutilizables: la utilización de modelos y teorías reutilizables
facilitaría la construcción de otros nuevos y reduciría el número de errores que se
cometieran.
Combinaciones de teorías matemáticas: muchos sistemas presenta la mezcla de
tecnologías digitales y analógicas, lo que haría necesario la utilización de, tanto las
matemáticas discretas, como del cálculo con variables continuas. En muchas
ocasiones es necesario mezclar diversas partes de las matemáticas para un mismo
problema, pudiendo necesitar, por ejemplo, de la estadística o de la teoría de colas.
Estructuras de datos y algoritmos: el desarrollo de estructuras de datos adecuadas
y algoritmos más eficientes, nos permitiría manejar sistemas y espacios de búsqueda
mayores.
1.4.2. Métodos y herramientas
Ningún método es útil para todos los problemas, por lo que es necesario soportar
distintos tipos de métodos. Para que los métodos y de las herramientas que se
desarrollen a este respecto, tengan éxito entre sus posibles usuarios deben tenerse en
cuenta los siguientes aspectos:
7
Jose Antonio Glez. Reboredo
•
•
•
•
•
•
•
•
•
•
Introducción a SPIN
Rápido retorno de la inversión: estos métodos deben dar beneficios a las personas
que los utilicen desde el primer momento.
Los beneficios deben incrementarse con el esfuerzo: los beneficios aportados por
estas técnicas deben hacerse mayores según los desarrolladores aumenten sus
esfuerzos en escribir especificaciones o utilizar las herramientas.
Múltiple uso: la amortización de un método o herramienta es mayor si esta tiene
varios usos.
Uso integrado: los métodos y herramientas deben integrarse perfectamente con las
técnicas y lenguajes comunes de programación, de forma que los desarrolladores no
tengan que adaptarse totalmente a una nueva tecnología para sacar partido de estos
métodos.
Facilidad de uso: la facilidad de uso aumenta el atractivo de una herramienta y
reduce el tiempo en el que su utilización empieza a ser rentable.
Eficiencia: una herramienta debe ser eficiente para que su utilización no suponga
una pérdida de tiempo. Aún así, el tiempo de proceso de la herramienta podrá ser
mayor cuanto mayores sean los beneficios que se obtengan de este proceso.
Fácil de aprender: el tiempo necesario para aprender el manejo de los métodos o
herramientas debe ser el menor posible, con lo que se ganará una mayor aceptación
de los mismos por parte de los desarrolladores y un retorno de la inversión más
rápido.
Orientación a la detección de errores: los métodos y las herramientas deben estar
orientados, más a la detección de errores, que a la certificación de la corrección de
un sistema. Es muy deseable que sean capaces de encontrar contraejemplos.
Análisis focalizado: los métodos y herramientas deben ser buenos analizando al
menos uno de los aspectos del sistema.
Desarrollo evolutivo: los métodos y las herramientas deben estar pensados para la
evolución de los sistemas cuyo desarrollo se asista de los mismos. Un ejemplo de
esto es que deben permitir especificaciones parciales o análisis de aspectos
concretos de un sistema.
Más ambicioso que la creación de herramientas, sería el desarrollo de “metaherramientas” que nos permitieran crear herramientas específicas para cada caso.
1.4.3. Integración de métodos
Ya que ningún método formal es adecuado para describir y analizar todos los aspectos
de un sistema complejo, debemos trabajar en la integración de distintos métodos para
que puedan trabajar juntos en pos de un objetivo común.
En la combinación de métodos debemos considerar dos aspectos:
-
Encontrar un estilo adecuado para la utilización de distintos métodos juntos.
Encontrar una semántica adecuada para la utilización de distintos métodos
juntos.
Una de las integraciones más prometedoras de métodos formales sería la integración de
la comprobación de modelos con la prueba de teoremas. La combinación de estos
8
Jose Antonio Glez. Reboredo
Introducción a SPIN
métodos podría darnos un método que redujera las desventajas de los mismos
aportándonos sus mayores beneficios.
Otro punto de integración de elevada importancia es la integración con el proceso de
desarrollo, sobre todo en las partes de análisis, refinamiento y pruebas del sistema.
1.4.4. Educación y transmisión de la tecnología
Un punto crucial para el éxito de una tecnología y, por tanto, de la utilización de los
métodos formales en el desarrollo de sistemas es la transmisión de estos conocimientos
a las distintas audiencias. Las audiencias destino serían las siguientes:
-
Otros investigadores
Desarrolladores
Estudiantes
9
Jose Antonio Glez. Reboredo
Introducción a SPIN
2. SPIN
2.1. Características generales
Antes de abordar el estudio de la herramienta en más profundidad daremos una lista de
características generales de la misma.
Spin es un paquete software que permite la verificación formal de sistemas distribuidos.
Este software fue desarrollado por el grupo de métodos formales y verificación de los
Laboratorios Bell, dando comienzo su desarrollo en 1980. El sistema presenta las
siguientes características:
•
•
•
•
•
•
•
•
•
Spin es un producto para la verificación de software, no pensado para la verificación
de hardware. Para llevar a cabo este proceso utiliza un lenguaje propio para
especificar descripciones de sistemas. Este lenguaje se denomina PROMELA
(PROcess MEta LANguage) y es un lenguaje no determinístico.
Spin ha sido utilizado para encontrar errores en el diseño lógico de sistemas
distribuidos (ej.: sistemas operativos, protocolos de comunicaciones, sistemas
concentradores, algoritmos concurrentes, etc.). La herramienta comprueba la
consistencia lógica de una especificación informando de: interbloqueo, recepciones
no especificadas, flags incompletos, race conditions y afirmaciones no garantizadas
acerca de las velocidades relativas de los procesos.
Spin trabaja on-the-fly, lo que quiere decir que evita tener que construir un grafo de
estados global o una estructura Kripke, como preresquisito para la verificación de
algunas de las propiedades del sistema.
Spin puede ser utilizado como comprobador de modelos LTL (linear line temporal),
permitiendo manejar todos los requisitos correctamente expresados en lógica LTL.
Aún así, puede ser utilizado como un eficiente verificador on-the-fly para muchas
propiedades (muchas de las propiedades de un sistema pueden ser especificadas y
verificadas sin utilizar LTL.
Spn soporta que el número de procesos aumente o mengüe dinámicamente, para lo
que utiliza una técnica rubber state vector.
Spin soporta tanto redezvous, como el pase de mensajes en buffers. Soporta
comunicaciones a través de memoria compartida. Por otro lado, admite tanto,
comunicaciones síncronas, como asíncronas.
Soporta simulación aleatoria, interactiva y guiada, así como técnicas de prueba
exhaustivas y parciales.
La herramienta está pensada para enfrentarse a problemas de gran tamaño.
Para optimizar la verificación, la herramienta utiliza técnicas de reducción de orden
parcial y (opcionalmente) técnicas de almacenamiento BDD.
Spin puede ser utilizado en 3 modos básicos:
-
Como simulador, permitiendo un prototipado rápido mediante una simulación
aleatoria, guiada o interactiva.
10
Jose Antonio Glez. Reboredo
-
-
Introducción a SPIN
Como un analizador exhaustivo del espacio de estados, capaz de demostrar de
forma rigurosa la validez de los requerimientos de corrección. Aquí utiliza la
teoría de las reducciones de orden parcial para optimizar la búsqueda.
Como un analizador de un espacio de estados-bit puede validar, incluso sistemas
de protocolos de gran tamaño, con la máxima cobertura del espacio de estados.
(Es una técnica de prueba aproximada).
El software de Spin está escrito en el estándar ANSI C, pudiendo ser portado a todas las
versiones de Linux, a Windows 95/98 y a Windows NT.
A partir de aquí y, tras describir someramente las principales características del sistema,
pasaremos a describirlo en mayor profundidad a lo largo de los próximos apartados.
11
Jose Antonio Glez. Reboredo
Introducción a SPIN
2.2. Introducción
Spin es un sistema genérico de verificación que soporta el diseño y la verificación de
sistemas de procesos asíncronos. Los modelos de verificación de Spin están enfocados
en probar la corrección de las interacciones de los procesos, abstrayéndose lo más
posible de secuencia de computaciones interna.
La interacción entre procesos se indica a través de primitivas rendezvous, con pase
asíncrono de mensajes a través de canales con buffer, acceso a variables compartidas o
con una combinación de estos.
Como herramienta para la puesta en práctica de métodos formales, SPIN intenta
proporcionar:
1) Una intuitiva notación (similar a la de un lenguaje de programación) que nos
permite especificar detalles del diseño sin ambigüedades y sin llegar a nivel
de implementación.
2) Una notación concisa para expresar requerimientos genéricos de corrección
3) Una metodología para establecer la consistencia lógica de los detalles de
diseño de 1) y comprobar los requerimientos de corrección de 2).
Spin acepta especificaciones de diseño por medio del lenguaje PROMELA (PROcess
MEta LAnguage), que, a su vez, acepta especificaciones de corrección en la sintaxis del
estándar LTL (Linear Temporal Logic). Las notaciones en Spin se han escogido de tal
forma que la consistencia lógica de un diseño pueda ser demostrada por la herramienta.
2.2.1. Estructura
La estructura básica del comprobador de modelos Spin es la que podemos ver en la
siguiente figura:
12
Jose Antonio Glez. Reboredo
Introducción a SPIN
Figura 1: Estructura de la simulación y la verificación en SPIN
La forma típica de trabajar es comenzando con la especificación de un modelo de alto
nivel de un sistema concurrente (o algoritmo distribuido), normalmente utilizando el
front-end gráfico XSpin. Tras arreglar los errores sintácticos, se ejecuta una simulación
interactiva hasta que se tenga la suficiente confianza de que, el comportamiento del
sistema, es el esperado. En un tercer paso, Spin es utilizado para generar un programa
de verificación on-the-fly optimizado, a partir del la especificación de alto nivel. Este
verificador es compilado (aquí se pueden utilizar diversas opciones de compilación para
escoger el tipo de algoritmo de reducción) y ejecutado. Si se encontrase algún
contraejemplo para las especificaciones de corrección, éste puede ser probado en el
simulador, con el objeto de buscar la causa del mismo y eliminarla.
13
Jose Antonio Glez. Reboredo
Introducción a SPIN
2.3. Fundamentos
Spin tiene sus orígenes en los primeros sistemas de verificación de protocolos de
principios de los 80. Estos primeros verificadores se basaban en un análisis on-the-fly
del alcance y, su objetivo, era proporcionar una herramienta efectiva que pudiera
resolver problemas con un alcance práctico. La complejidad computacional del
problema, obliga a uno a escoger cuidadosamente que características soportará el
sistema, llegando a un compromiso entre utilidad y complejidad. Así, los predecesores
de Spin proporcionaban un rango de características mucho menor que el alcanzado con
éste. A partir de este punto nos centraremos en Spin:
En lo referente a la descripción de un sistema concurrente en PROMELA, ésta está
formada por: una o más plantillas de procesos definidas por el usuario o definiciones de
tipos de procesos, y, al menos una instanciación de procesos. Las plantillas definen el
comportamiento de los distintos tipos de procesos. Cualquier proceso puede instanciar
otros procesos asíncronos usando las plantillas de procesos.
Spin traduce cada plantilla de procesos en un autómata finito. El comportamiento global
del sistema concurrente se obtiene al computar un producto entrelazado y asíncrono de
autómatas (un autómata por cada comportamiento asíncrono de proceso). El resultado
global, con el comportamiento del sistema, es representado, a su vez, mediante un
autómata. Este producto entrelazado es conocido, normalmente, como el espacio de
estados del sistema y puede ser representado fácilmente como un grafo, que se conoce,
a su vez, como el grafo global de alcance.
Antes de explicar el proceso de verificación diremos que, un autómata de Büchi es un
autómata definido sobre infinitas secuencias de entrada, en vez de sobre un conjunto
finito como en la teoría estándar de máquinas de estado finito.
Para realizar la verificación, Spin coge un requerimiento de corrección expresado como
una fórmula de lógica temporal, la convierte en un autómata de Büchi y computa el
producto síncrono de ese requerimiento con el atómata que representa el estado de
espacios global; siendo, el resultado, nuevo autómata de Büchi. Si el lenguaje aceptado
por ese autómata es vacío, significará que el requerimiento original no se satisface para
el sistema dado. Si el lenguaje no es vacío, contendrá exactamente los comportamientos
que satisfacen la fórmula original. En Spin, se utilizan los requerimientos de corrección
para formalizar los comportamientos erróneos en los sistemas (comportamientos no
deseados), de forma que el proceso de verificación demuestra que esos
comportamientos no son posibles en el sistema o, en su defecto, nos indicará en que
casos se dan esos comportamientos.
En el peor caso, el grafo de alcance global tendrá el tamaño del producto cartesiano de
todos los componentes del sistema. La especificación del lenguaje PROMELA está
definida de tal modo que , cada componente siempre tiene un rango finito. Esto se
aplica a los procesos (que sólo podrán tener un conjunto finito de estados) y a todos los
canales de mensajes (todos con una capacidad limitada según lo que indique el usuario.
Nota: Las variables y los canales de mensajes también tienen un estado que se
seleccionará a partir de un dominio finito. Estos componentes pasivos pueden cambiar
de estado sólo como un efecto lateral síncrono, de las transiciones que se hacen en los
14
Jose Antonio Glez. Reboredo
Introducción a SPIN
componentes activos del modelo de verificación, es decir, en los procesos instanciados).
De todos modos, en la práctica, el tamaño del alcance global, nunca se aproxima al del
peor caso, ya que el tamaño del producto cartesiano podría hacer prohibitivos los
procesos computacionales exhaustivos. Con objeto de evitar este problema, se han
desarrollado varias técnicas para el manejo de la complejidad.
2.3.1. Requerimientos de lógica temporal
Spin acepta propiedades de corrección expresadas en lógica lineal temporal (LTL).
Vardi y Wolper demostraron en 1983 que cualquier fórmulal LTL puede ser traducida a
un autómata de Büchi. Spin implementa la conversión a un autómata de Büchi basada
en una simple construcción on-the-fly. El autómata generado sólo acepta las ejecuciones
que satisfacen la correspondiente fórmula LTL (existen infinitas).
Como se ha explicado anteriormente, se utilizan requerimientos de corrección que
expresan comportamientos indeseados del sistema (con el objeto de demostrar que no se
pueden producir).
Cada posible fórmula LTL puede ser transformada en su negación y viceversa, mediante
la adicción del operador de negación al principio de la misma. En principio puede
parecer que es indiferente cuál de las dos formas se escoja, pero hay una diferencia: Una
cláusula positiva requiere la demostración de que el lenguaje del sistema (es decir, todas
sus ejecuciones) está incluido en el lenguaje de la cláusula. Una cláusula negativa
requiere la demostración de que la intersección de los lenguajes es vacía. El tamaño del
espacio de estados para la demostración de una inclusión de lenguajes, en el peor caso
es el producto cartesiano de los autómatas del sistema y la restricción y, como mínimo,
su suma. El peor caso para la demostración de que la intersección de dos lenguajes es
vacía, también es el producto cartesiano del sistema y la restricción, pero, en el mejor
caso, es cero. (Si la parte inicial del comportamiento inválido representado en la
restricción, no aparece en el sistema, la intersección no contendrá ningún estado). Por
todo lo relatado, Spin trabaja con cláusulas negativas y resuelve el problema de la
verificación mediante intersección de lenguajes.
Un autómata de Büchi acepta una ejecución del sistema si, y sólo si, la ejecución fuerza
el paso por uno o más de sus estados de aceptación infinitas veces. Este comportamiento
es llamado ciclos de aceptación (una ejecución infinita en un sistema finito supone la
existencia de un ciclo). Para demostrar que no existe un a secuencia de aceptación que
cumpla el requisito de aceptación negativo, es suficiente probar que no existen ciclos de
aceptación en la ejecución combinada del sistema y el autómata de Büchi que representa
el requisito. Esta ejecución combinada se define formalmente por el producto síncrono
del sistema y el requisito.
La computación realizada por Spin para llevar a cabo esta demostración se basa en un
algoritmo de búsqueda en profundidad anidado (nested depth-first search algorithm).
Esta búsqueda terminará cuando se encuentre un contraejemplo (se encuentra un ciclo
de aceptación) o si se recorre todo el producto sin encontrar ciclos.
2.3.2. Dominio de aplicación
15
Jose Antonio Glez. Reboredo
Introducción a SPIN
Es diseño de Spin está enfocado a la verificación eficiente de sistemas software
asíncronos. Esto afecta a varias características de la herramienta, como el diseño del
lenguaje de especificación, la lógica, el procedimiento de verificación, las técnicas de
reducción y los métodos de codificación de estados.
16
Jose Antonio Glez. Reboredo
Introducción a SPIN
2.4. Algoritmos
En este apartado comentaremos brevemente los algoritmos utilizados por la
herramienta.
2.4.1. Nested depth-first search
El método para la detección de ciclos utilizado por Spin es de vital importancia para la
herramienta. Este método debe ser compatible con todos los modos de verificación,
incluyendo la búsqueda exhaustiva, bit-state hashing y las técnicas de reducción de
orden parcial.
El algoritmo clásico para encontrar un ciclo en un grafo es el algoritmo depth-first seach
de Tarjan, que construye los elementos fuertemente conectados en tiempo lineal,
mediante la adicción de dos enteros a cada estado alcanzado. Debido a que el espacio de
estados susceptible de ser generado por Spin, podría tener miles de millones de estados
alcanzables, estos dos números enteros deberían ser de 32 bits cada uno. Este algoritmo
no es compatible con las técnicas de bit-state hashing, también presentes en Spin, lo que
nos hace buscar una alternativa más eficiente en cuanto a espacio. Una nested depth-fist
search puede visitar cada estado dos veces, pero puede almacenar cada estado con sólo
2 bits a mayores (utilizando un método de codificación simple), en lugar de los 64 bits
del método de Tarjan.
El principio de esta búsqueda es el siguiente: para encontrar un ciclo de aceptación en el
grafo de alcance debe haber un estado de aceptación que sea, a la vez, alcanzable desde
el inicio y desde el propio nodo de aceptación. La primera búsqueda en profundidad
realizada, nos dice que estados de aceptación son alcanzables desde el inicio. La
búsqueda en profundidad anidada comprueba si son alcanzables desde sí mismos. Si se
llega a completar una ejecución tendremos el ciclo de aceptación, que será la
concatenación de la lista de estados recorridos en las dos búsquedas. Este ciclo será un
contraejemplo del requerimiento de corrección y podrá ser mostrado como prueba de
que éste no se cumple.
Este algoritmo no garantiza que encontremos todos los ciclos de aceptación, pero nos
garantiza encontrar al menos uno si alguno existe. Esto supone encontrar un
contraejemplo del requisito y, por tanto, cumplir los propósitos mínimos para realizar la
verificación.
Este algoritmo cuenta también con una restricción propia para evitar el cómputo de
caminos infinitos que no nos lleven a una solución.
2.4.2. Paso de fórmulas LTL a autómatas de Büchi
Las fórmulas LTL pueden ser utilizadas para expresar distintas propiedades en el
sistema. Una fórmula LTL f, puede contener varios símbolos proposicionales p (en
minúsculas), combinados con operadores, unarios o binarios, boléanos o temporales.
17
Jose Antonio Glez. Reboredo
Introducción a SPIN
El algoritmo de traducción, computa los estados de un autómata de Büchi, mediante el
cómputo del conjunto de subfórmulas que deben permanecer en cada estado alcanzable
y en cada uno de sus estados sucesores. En primer lugar, se pasa la fórmula a la forma
normal, con negaciones sólo adyacentes a proposiciones atómicas. Se crea un estado
inicial, marcado con la fórmula que va a ser macheada y un falso estado “de borde”. El
resto del autómata se calcula recursivamente. En cada estado, se coge una subfórmula
que espera ser satisfecha y, de acuerdo con su operador principal, el estado actual podría
ser dividido en dos estados con distintas partes de la subfórmula. Finalmente se detectan
los estados de aceptación en base a la fórmula que contengan.
2.4.3. Reducción de orden parcial
Spin usa un método de reducción de orden parcial para reducir el número de estados
alcanzables que deben ser explorados para completar una verificación. La reducción
está basada en la observación de que, la validez de una fórmula LTL, suele ser
insensible al orden de ejecución de eventos independientes en la depth-fist search. Así,
en lugar de generar un espacio de estados exhaustivo, que incluya todas las secuencias
de ejecución, éste se reduce a clases representativas de ejecución, que sean
indistinguibles para una propiedad de corrección dada.
La implementación de este método de reducción, se basa en una técnica estática de
reducción, que, antes de que la verificación real de comienzo, identifica casos en que
una regla de reducción de orden parcial pueda ser aplicada, de modo que no afecte al
proceso de verificación. Este método estático de reducción evita la sobrecarga del
tiempo de ejecución del que, otras estrategias de reducción adolecían.
Una característica importante del método estático de reducción de Spin es que no
conlleva un importante aumento del uso de la memoria, con respecto a una búsqueda
exhaustiva. Además, este método de reducción no se muestra sensible a decisiones
acerca del orden de los procesos o de las variables. Lo métodos alternativos de
reducción, basados en diagramas de decisión binarios, presentan problemas en los dos
aspectos antes mencionados.
2.5. Requisitos de tiempo y memoria
El tamaño del producto entrelazado que Spin puede computar, en el peor caso, crece
exponencialmente con el número de procesos. Dado el tamaño del producto, expresado
como el número de estados alcanzables R, podemos establecer una cota superior del la
cantidad de memoria y tiempo que serían necesarios para completar varios tipos de
tareas de verificación.
Probar propiedades de seguridad, tales como la ausencia de interbloqueo o condiciones
del usuario, supone un coste computacional que es lineal en el número de estados
alcanzables R, tanto en tiempo de CPU como en requisitos de memoria. Para probar
otras propiedades simples, tales como la ausencia de inanición o de ciclos de
aceptación, se requiere el doble de tiempo, aunque la memoria no se ve incrementada
significativamente. Para probar propiedades LTL, los requerimientos de tiempo crecen
en un factor, que, en el peor caso, puede ser el exponente del número de operadores
18
Jose Antonio Glez. Reboredo
Introducción a SPIN
utilizados en la fórmula. Los requisitos de memoria, sin embargo, permanecen largo
tiempo inalterados. Las propiedades LTL usadas en la práctica, rara vez tiene más de
dos o tres operadores, así que, el aumento en la complejidad es relativamente pequeño
comparado con la potencia que se le da al sistema.
La memoria es un recurso limitado en cualquier sistema. No es difícil construir un
comprobador de modelos que use tan sólo una pequeña cantidad de memoria, pero esto
sólo se puede hacer a expensas de un aumento en el tiempo utilizado inaceptable. Para
alcanzar este propósito Spin utiliza principalmente dos técnicas: compresión de los
estados y técnicas de bit-state hashing (gracias a la cual sólo dos bits son necesarios
para el almacenamiento de un estado alcanzable).
19