INTRODUCCIÓN A. Autor: José Antonio Glez. Reboredo

Transcripción

1 INTRODUCCIÓN A Autor: José Antonio Glez. Reboredo

2 1. MÉTODOS FORMALES INTRODUCCIÓN ESPECIFICACIÓN VERIFICACIÓN COMPROBACIÓN DE MODELOS PRUEBA DE TEOREMAS TRABAJO FUTURO CONCEPTOS FUNDAMENTALES MÉTODOS Y HERRAMIENTAS INTEGRACIÓN DE MÉTODOS EDUCACIÓN Y TRANSMISIÓN DE LA TECNOLOGÍA SPIN CARACTERÍSTICAS GENERALES INTRODUCCIÓN ESTRUCTURA FUNDAMENTOS REQUERIMIENTOS DE LÓGICA TEMPORAL DOMINIO DE APLICACIÓN ALGORITMOS NESTED DEPTH-FIRST SEARCH PASO DE FÓRMULAS LTL A AUTÓMATAS DE BÜCHI REDUCCIÓN DE ORDEN PARCIAL REQUISITOS DE TIEMPO Y MEMORIA

3 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 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

4 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

5 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 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 Prueba de teoremas 5

6 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

7 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 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 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

8 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 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

9 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 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

10 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 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

11 - 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

12 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 Estructura La estructura básica del comprobador de modelos Spin es la que podemos ver en la siguiente figura: 12

13 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

14 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

15 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 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 Dominio de aplicación 15

16 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

17 2.4. Algoritmos En este apartado comentaremos brevemente los algoritmos utilizados por la herramienta 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 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

18 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 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 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

19 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