1 Sergio Mera 1 1 FormaLex, Departamento de Computación, FCEyN, Universidad de Buenos Aires, Buenos Aires, Argentina Introducción al Análisis Formal de Normas Legales, segundo cuatrimestre de 2014
(2) Diferentes herramientas de verificación Vamos a hablar de tres familias de herramientas exitosas : Model checkers LTL. SAT solvers SMT solvers Por qué tres? Diferente poder expresivo: SAT < LTL < PO + teorías interpretadas Diferente complejidad: SAT solving: NP (completo). LTL model checking: PSPACE. PO: indecidible (SMT solving es incompleto).
(3) Model checkers Si bien hay varios tipos de model checkers, vamos a concentrarnos en una clase que es la de model checkers LTL. Son de los más usados y tienen varios casos de éxito. Algunas herramientas famosas son SPIN, NuSMV, DiVINE.
(4) LTL model checking Input: un autómata A que describe el comportamiento de un sistema, una fórmula PLTL ϕ. Output: true, si τ L(A), τ = ϕ (false, τ), si τ L(A) pero τ = ϕ Se basa en autómatas de Büchi, que son parecidos a los autómatas clásicos pero que aceptan palabras infinitas.
(5) Autómatas de Büchi Un autómata de Büchi A es una tupla Q, Σ, δ, q 0, F donde Q es un conjunto finito de estados. Σ es un conjunto finito de símbolos (el alfabeto de A). δ : Q Σ Q es la función de transición. q 0 Q es el estado inicial. F es un conjunto finito de estados llamado la condición de aceptación. El lenguaje de A (L(A)) son todas aquellas secuencias de caracteres de Σ que comenzando desde q 0 pasan inifinitamente seguido por estados en F. Estos lenguajes se llaman ω-regulares.
(6) Ejemplo A acepta las palabras (0 1) 0 ω
(7) Volviendo a LTL model checking Tenemos A y ϕ. Queremos ver si todas las palabras de L(A) satisfacen ϕ. Toda fórmula LTL puede transformarse en un autómata de Büchi que satisfacen dicha fórmula (Vardi y Wolper, 1983). Entonces podríamos hacer B = buchi(ϕ) Nuestro problema se reduciría a ver si L(A) L(B). Pero eso no es tan fácil. Entonces, en realidad vamos a hacer B = buchi( ϕ). Así, lo que tenemos que ver es si L(A) L(B) =. Es decir, si ninguna de las palabras del sistema A coincide con las palabras que acepta la negación de la fórmula ϕ.
(8) LTL model checking Cómo funciona el model checker? Realiza la composición sincrónica de A con B. Recorre todo el autómata combinado para asegurar la inexistencia de ciclos de aceptación sobre F. Es decir, loops que pasen por los estados de F. Si termina de recorrer y no encuentra ninguno, entonces la intersección es vacía. Si encuentra uno, entonces acaba de encontrar una palabra τ que es aceptada por A y por B, es decir, que satisface ϕ y por ende no satisface ϕ.
(9) Optimizaciones Algunas optimizaciones que se han hecho a lo largo de los años. Composición on-the-fly. Bitstate hashing y más en general, estructuras de datos de búsqueda. Reducción de simetrías. Representación simbólica. Algoritmos de detección de loops. Etc.
(10) SAT solving El nombre verdadero es boolean satisfiability problem, también conocido como satisfiability o SAT. Recordemos que SAT es NP-complete. Se trata de que tenemos un conjunto de variables proposicionales y una fórmula que las combina. Por ejemplo: (1) ((x 1 x 2 ) (x 1 x 3 )) x 2 (2) (x 1 x 2 ) (x 1 x 2 ) Se trata de ver si existe una asignación de valores de verdad a las variables proposicionales que satisfaga las fórmulas. En el ejemplo, (1) es satisfacible con x 1 = true, x 2 = false, x 3 = true, mientras que (2) no es satisfacible.
(11) SAT solving (cont.) Una variable (positiva o negativa) se llama literal. Una cláusula es una disyunción de literales. Una fórmula está en conjunctive normal form (CNF) si es una conjunción de cláusulas. Es decir, una conjunción de disyunciones de literales. Toda fórmula se puede llevar a CNF, aunque eso puede hacer que crezca su longitud. Recordemos que la complejidad es O(2 n ) con n la cantidad de variables.
(12) SAT solving (cont.) Todo problema es un SAT-problema... Bueno, no todo, pero sí muchos.
(13) Algunas heurísticas Si x 1 y x 2 sólo aparecen juntas (x 1 x 2 ) se las puede reemplazar por un nuevo literal y así tener una variable menos. Deducción: si tengo x 1 x 2 y estoy por la rama x 1 = true, no tiene sentido ir por la rama x 2 = false. En lugar de hacer backtracking de todas las combinaciones puedo fijar al azar algunos de los valores y ver si con eso puedo llegar a una solución. Paralelización. Y un largo etcétera... Que hizo que en los últimos diez años creciera el interés por los SAT solvers......generando muchas herramientas (zchaff, minisat, GRASP, etc.)......que soportan decenas de miles de variables y millones de cláusulas.
(14) SMT SMT: Satisfiability Modulo Theories La idea es que SAT puede ser eficiente pero requiere codificar en variables proposicionales. Y hay cosas para las que tal vez podemos hacer un mejor trabajo. En particular, podemos usar cosas más eficientes para ciertas teorías de primer orden con igualdad. Algunas muy comunes son desigualdades lineales, arreglos, listas, vectores de bits y funciones no interpretadas. Incluso soportan algunas formas de cuantificación.
(15) SMT (cont.) La idea es no perder la semántica de alto nivel y saber cosas como x + y = y + x head[a.x] = a x + y < z x < z y La idea es utilizar procedimientos de decisión para distintas teorías. Parecido a cuando Prolog usa una calculadora para expresiones aritméticas, en lugar de resolverlas mediante el motor de inferencia lógica.
(16) SMT (cont.) El siguiente ejemplo es de Bjorner (Z3). x 0, y = x + 1, (y > 2 y < 1). Paso 1, abstracción proposicional: p 1 x 0 p 2 y = x + 1 p 3 y > 2 p 4 y < 1 Paso 2, SAT solving de p 1, p 2, (p 3 p 4 ). El SAT solver devuelve una asignación que satisface las ecuaciones: p 1, p 2, p 3, p 4.
(17) SMT (cont.) Paso 3, se lo pasamos a un theory solver: (1) x 0 (2) y = x + 1 (3) (y > 2) (4) y < 1 El solver nos dice que (1), (2) y (4) son insatisfacibles. Paso 4, volvemos a llamar al SAT solver agregando el lema p 1 p 2 p 4. El SAT solver toma p 1, p 2, (p 3 p 4 ) y junto con el lema encuentra p 1, p 2, p 3, p 4.
(18) Implementación de FL FL está implementado sobre el model checker NuSMV. Vamos a ver cómo se codifica FL sobre LTL.
(19) Ejemplo acciones: publicar y vender intervalo: en venta VAR publicar : {HAPPENING, NOT_HAPPENING, JUST_HAPPENED}; vender: {HAPPENING, NOT_HAPPENING, JUST_HAPPENED}; en_venta: {ACTIVE, INACTIVE}; INIT publicar = NOT_HAPPENING & vender = NOT_HAPPENING & en_venta = INACTIVE; TRANS TRUE
(20) Codificación de acciones start NOT HAPPENING HAPPENING JUST HAPPENED
(21) Codificación de acciones (cont.) start NOT HAPPENING HAPPENING JUST HAPPENED (1) vender = NOT_HAPPENING -> next(vender)!= JUST_HAPPENED (2) vender = JUST_HAPPENED -> next(vender) = NOT_HAPPENING
(22) Codificación de intervalos interval en_venta defined by actions publicar - vender IA / IA: H JH start INACTIVE ACTIVE FA / FA: H JH
(23) Codificación de intervalos (cont.) interval en_venta defined by actions publicar - vender IA / IA: H JH start INACTIVE ACTIVE FA / FA: H JH ( (publicar = NOT_HAPPENING & next(publicar) = HAPPENING) -> en_venta = INACTIVE ) & ( (en_venta = INACTIVE & next(en_venta) = ACTIVE) <-> (publicar = HAPPENING & next(publicar) = JUST_HAPPENED) )
(24) Algunas fórmulas en FL O( en venta (precio visible)) (en venta=active precio visible=happening U en venta=inactive) O( periodo escolar (rendir examen)) (periodo escolar=active periodo escolar=active U rendir examen=just HAPPENED)