y V Taller de Programación Funcional (TPF)

313
XII Jornadas sobre Programación y Lenguajes (PROLE) y V Taller de Programación Funcional (TPF) Madrid, 17 al 20 de Septiembre de 2013 Editores: Lars-Åke Fredlund Laura M. Castro

Transcript of y V Taller de Programación Funcional (TPF)

Page 1: y V Taller de Programación Funcional (TPF)

XII Jornadas sobre Programación y Lenguajes (PROLE)y

V Taller de Programación Funcional (TPF)

Madrid, 17 al 20 de Septiembre de 2013

Editores:Lars-Åke FredlundLaura M. Castro

Page 2: y V Taller de Programación Funcional (TPF)

Actas deXIII Jornadas sobre Programación y Lenguajes (PROLE)y V Taller de Programación Funcional (TPF)

Madrid, 17–20 de Septiembre de 2013

Editores:

Lars-Åke Fredlund | Laura M. Castro

Page 3: y V Taller de Programación Funcional (TPF)

XIII Jornadas sobre Programación y LenguajesV Taller de Programación Funcional

Editores: Lars-Åke Fredlund, Laura M. CastroMadrid, 2013ISBN: 978-84-695-8331-9

Edición: 1a

Número de páginas: 313Materia CDU: 004 Informática. 004.4: Software

© Reservados todos los derechos. Ni la totalidad ni parte de este documento puede ser repro-ducirda o transmitirda por ningún procedimiento electrónico o mecánico, incluyendo fotocopia,grabación magnética o cualquier almacenamiento de información y sistema de recuperación,sin el permiso previo y por escrito de las personas titulares del copyright.

Page 4: y V Taller de Programación Funcional (TPF)

Prólogo

Las Jornadas de PROgramación y LEnguajes (PROLE) se han convertidoen los últimos años en un marco propicio de reunión, debate y divulgación paralos grupos españoles que investigan en temas relacionados con la programacióny los lenguajes de programación.

La XIII edición de estas Jornadas (PROLE’13) tiene lugar en Madrid del18 al 20 de septiembre de 2013, en el seno del IV congreso trianual CEDI(Congreso Español de Informática) auspiciado por la Sociedad de Ingenieríadel Software y Tecnologías de Desarrollo de Software (SISTEDES). Continuaasí la tradición de las ediciones anteriores celebradas en Almagro (2001), ElEscorial (2002), Alicante (2003), Málaga (2004), Granada (2005), Sitges (2006),Zaragoza (2007), Gijón (2008), San Sebastián (2009), Valencia (2010), A Coruña(2011) y Almería (2012).

Queremos agradecer tanto a los organizadores de CEDI como a SISTEDESel soporte, infraestructura y apoyo prestados. Estas actas recopilan un totalde 28 trabajos aceptados que fueron rigurosamente revisados por, al menos,3 miembros de los respectivos comités de programa de PROLE/TPF, a loscuales agradecemos su colaboración, esfuerzo y constructivas sugerencias parala mejora de los trabajos.

Para PROLE’13 se han seleccionado 22 trabajos que cubren aspectos teó-ricos y prácticos relativos a la especificación, diseño, implementación, análisis,verificación, validación y aplicación de programas y lenguajes de programación.Por su parte, TPF’13 ha seleccionado 6 trabajos directamente relacionados conel paradigma de programación funcional.

Además de todas las actividades vinculadas al evento, PROLE’13 cuentacon una conferencia invitada que, bajo el título “Typed Lazy Contracts” seráimpartida por Olaf Chitil, del Computing Laboratory, School of Computing dela University of Kent (Canterbury, UK). Por su parte, el programa de TPF’13cuenta este año con un taller sobre pruebas software automáticas. Queremosdesde aquí agradecer a todos los autores de los artículos recibidos el habercontribuido con interesantes contenidos a una nueva edición de PROLE/TPF.

Por último, queremos agradecer al comité permanente de PROLE la con-fianza depositada tanto en PROLE’13 como en TPF’13.

Madrid, septiembre de 2013.

Lars-Åke FredlundLaura M. Castro

Page 5: y V Taller de Programación Funcional (TPF)

Comité Científico del PROLE’2013Presidente del Comité:Lars-Åke Fredlund, U. Politécnica de Madrid

Miembros:Jesús Almendros, U. de AlmeríaMaría Alpuente, U. Politécnica de ValenciaAnindya Banerjee, IMDEAMiquel Bofill, U. de GironaManuel Carro, IMDEA/U. Politécnica de MadridLaura Castro, U. de A CoruñaMaría del Mar Gallardo, U. de MálagaFrancisco Duran, U. de MálagaSamir Genaim, U. Complutense de MadridPaqui Lucio, U. del País VascoJulio Mariño, U. Politécnica de MadridGinés Moreno, U. de Castilla-La ManchaMarisa Navarro, U. del País VascoAlbert Oliveras, U. Politécnica de CataluñaFernando Orejas, U. Politécnica de CataluñaYolanda Ortega, U. Complutense de MadridFrancisco Ortín, U. de OviedoRicardo Peña, U. Complutense de MadridFernando Rosa Velardo, U. Complutense de MadridJulio Rubio, U. de La RiojaFernando Sáenz Pérez, U. Complutense de MadridJosep Silva, U. Politécnica de ValenciaAlicia Villanueva, U. Politécnica de Valencia

Comité Científico de TPF’2013Presidente del Comité:Laura M. Castro, U. de A Coruña

Miembros:Raúl Gutiérrez, U. Politécnica de ValenciaSalvador Lucas, U. Politécnica de ValenciaPablo Nogueira, U. Politécnica de MadridRicardo Peña, U. Complutense de MadridJulio Rubio, U. de La RiojaJosep Silva, U. Politécnica de ValenciaMateu Villaret,U. de Girona

5

Page 6: y V Taller de Programación Funcional (TPF)

Revisores externosFrancisco Alvarez-MonteroJavier ÁlvezGiovanni BacciAntonio Becerra-TerónClara Benac EarleJavier EspertLuis GarmendiaRémy HaemmerléMontserrat HermoDavid InsaMaría Martos-SalgadoJose F. MoralesAdrian RiescoRicardo J. RodríguezIlya SergeySalvador TamaritLuca TorellaCarlos Vázquez

6

Page 7: y V Taller de Programación Funcional (TPF)

Índice de Contenidos de TPF’2013

Septiembre 17

Sesión 1: Algorithms and High-order Methods

10.00–10.30 Ricardo Peña: Una librería en Haskell para manipularlenguajes regulares

10.30–11.00 Julio Mariño: A Course in Algorithm Design based onHigher-order Patterns

11.00–11.30 Álvaro García-Pérez, Ilya Sergey, and Pablo Nogueira:Derivación de Intérpretes del Cálculo Lambda con TiposGraduales

Sesión 2: Verification and Testing

12.00–12.30 Jesús Aransay and Jose Divasón: Performance Analysis ofa Verified Linear Algebra Program in SML

12.30–13.00 Julio Mariño: Euclidean Interpolation: from MathematicalStructures to Types and Back

13.00–13.30 Miguel Ángel Francisco Fernández and Laura M. Castro:Uso de propiedades y modelos para las pruebas de sistemasdistribuidos basados en la integración de componentes het-erogéneos

7

Page 8: y V Taller de Programación Funcional (TPF)

Índice de Contenidos del PROLE’2013

Septiembre 18

Sesión 1: Typing

9.30–10.00 Francisco J. López-Fraguas and Enrique Martin-Martin:Typing as Functional-Logic Evaluation

10.00–10.30 Miguel Garcia and Francisco Ortin: Optimización deLenguajes con Comprobación Estática y Dinámica de Tipos

Sesión 2: Testing

11.00–11.30 Macías López, Henrique Ferreiro, Miguel Á. Francisco, andLaura M. Castro: Automatización de Pruebas para Servi-cios Web: Generación de Propiedades y Modelos

11.30–12.00 Pedro Delgado-Pérez, Inmaculada Medina-Bulo, Juan JoséDomínguez-Jiménez, and Antonio García-Domínguez: Op-eradores de Mutación a Nivel de Clase para el LenguajeC++

12.00–12.30 Clara Benac Earle and Lars-Åke Fredlund: Testing Javawith QuickCheck

Sesión 3: Abstraction and Analysis

12.45–13.15 Manuel Montenegro, Ricardo Peña, and Clara Segura:Shape Analysis in a Functional Language by Using Reg-ular Languages

13.15–13.45 Elvira Albert, Jesús Correas Fernández, Germán Puebla,and Guillermo Román-Díez: Quantified Abstractions ofDistributed Systems

8

Page 9: y V Taller de Programación Funcional (TPF)

Sesión 4: Fuzzy Logic

16.00–16.30 Patrik Eklund, M. Ángeles Galán, Robert Helgesson, JariKortelainen, Ginés Moreno, and Carlos Vázquez: Towardsa Categorical Description of Fuzzy Logic Programming

16.30–17.00 Jesús M. Almendros-Jiménez, Alejandro Luna, GinésMoreno, and Carlos Vázquez: Analyzing Fuzzy Logic Com-putations with Fuzzy XPath

17.00–17.30 Miquel Bofill, Ginés Moreno, Carlos Vázquez, and MateuVillaret: Automatic Proving of Fuzzy Formulae with FuzzyLogic Programming and SMT

9

Page 10: y V Taller de Programación Funcional (TPF)

Septiembre 19

Sesión 5: Logic and Theory

9.00–9.30 Javier Álvez, Paqui Lucio, and German Rigau: Adimen-SUMO: Reengineering an Ontology for First-Order Rea-soning

9.30–10.00 Francisco J. Galán and Ahmed Riveras: Semantic Web Ser-vices in a Transactional Context

10.00–10.30 María Alpuente, Santiago Escobar, and Javier Espert: De-tecting Modular ACU Structural Symmetries

Sesión 6: Invited Talk

11.00-12.30 Olaf Chitil: Typed Lazy Contracts

Sesión 7: Model and Bisimilarity Checking

16.00–16.30 María Martos-Salgado and Fernando Rosa-Velardo: On theDecidability of Model Checking LTL Fragments in Mono-tonic Extensions of Petri Nets

16.30–17.00 Laura Panizo and María-del-Mar Gallardo: Verifying Hy-brid Systems with Explicit Model Checkers

17.00–17.30 Fernando Orejas, Artur Boronat, Ulrike Golas, and NikosMylonakis: Checking Bisimilarity for Attributed GraphTransformation

10

Page 11: y V Taller de Programación Funcional (TPF)

Septiembre 20

Sesión 8: Database Theory

9.00–9.30 Fernando Sáenz-Pérez: Towards Bridging the Expressive-ness Gap Between Relational and Deductive Databases

9.30–10.00 Gabriel Aranda, Susana Nieva, Fernando Sáenz-Pérez, andJaime Sánchez-Hernández: R-SQL: An SQL Database Sys-tem with Extended Recursion

10.00–10.30 Rafael Caballero, Yolanda García-Ruiz, and FernandoSáenz-Pérez: Declarative Debugging of Wrong and Miss-ing Answers for SQL Views

Sesión 9: Languages and Systems

11.00–11.30 Ignacio Castiñeiras and Fernando Sáenz-Pérez: Improvingthe Search Capabilities of a CFLP(FD) System

11.30–12.00 Ricardo J. Rodríguez, Lars-Åke Fredlund, and Ángel Her-ranz: From UML State-Machine Diagrams to Erlang

12.00–12.30 Ana-Rosario Espada, María-del-Mar Gallardo, and DamiánAdalid: DRAGONFLY: Encapsulating Android for Instru-mentation

11

Page 12: y V Taller de Programación Funcional (TPF)

V Taller de Programación Funcional (TPF)

12

Page 13: y V Taller de Programación Funcional (TPF)

Sesión 1: Algorithms and High-order Methods

13

Page 14: y V Taller de Programación Funcional (TPF)

Sesión 1: Algorithms and High-order Methods

10.00–10.30 Ricardo Peña: Una librería en Haskell para manipularlenguajes regulares

10.30–11.00 Julio Mariño: Euclidean Interpolation: from MathematicalStructures to Types and Back

11.00–11.30 Álvaro García-Pérez, Ilya Sergey, and Pablo Nogueira:Derivación de Intérpretes del Cálculo Lambda con TiposGraduales

14

Page 15: y V Taller de Programación Funcional (TPF)

Una librería en Haskell para manipular lenguajes regulares

Ricardo Peña1

1 [email protected] de Sistemas Informáticos y Computación

Universidad Complutense de Madrid, Spain *

Abstract: HaLeX es una librería escrita en el lenguaje funcional Haskell, desarro-llada como parte de un proyecto docente por el Departamento de Informática de laUniversidad do Minho (Braga, Portugal), para manipular y animar lenguajes regu-lares. Suministra expresiones regulares, autómatas finitos deterministas y no deter-ministas, funciones para convertir unas representaciones en otras y para minimizarautómatas, y una herramienta para visualizar autómatas gráficamente.

Como parte de un análisis estático, tuvimos necesidad de decidir problemas sobrelenguajes regulares y encontramos HaLeX. Rehicimos parte de sus algoritmos, nomuy eficientes en algunos casos, e incorporamos varias extensiones. En particular,añadimos autómatas no deterministas sin transiciones vacías y algoritmos para cal-cular la intersección y la concatenación de lenguajes, la derivación de un lenguajeregular con respecto a otro, y para decidir la igualdad y la inclusión de lenguajesregulares. Las extensiones utilizan intensivamente el orden superior y estructurasdatos con bajos coste de acceso. El resultado es una librería razonablemente eficien-te, que puede ser usada tanto con fines docentes como investigadores.

Este trabajo presenta dicha librería, sus representaciones de datos, y algunos de susalgoritmos más interesantes.

Keywords: Haskell, regular languages, algorithms

1. HaLeX

HaLeX [Sar02] es una librería escrita en el lenguaje funcional Haskell, desarrollada comoparte de un proyecto docente por el Departamento de Informática de la Universidad do Minho(Braga, Portugal), para manipular y animar lenguajes regulares. Suministra tipos de datos paradefinir lenguajes regulares según diferentes formalismos.

En primer lugar, el tipo —polimórfico en los símbolos del alfabeto— que define expresionesregulares:

data RegExp sy = Empty -- Empty Language| Epsilon -- Empty String| Literal sy -- Literals| Or (RegExp sy) (RegExp sy) -- Disjuncion| Then (RegExp sy) (RegExp sy) -- Sequence| Star (RegExp sy) -- Repetition, possibly zero times| OneOrMore (RegExp sy) -- One or more times| Optional (RegExp sy) -- Optional

∗ Work partially funded by the project S2009/TIC-1465 (PROMETIDOS).

Librería para lenguajes regulares 1 / 8

Page 16: y V Taller de Programación Funcional (TPF)

En segundo lugar, el tipo de los autómatas finitos deterministas (DFA), que es polimórficotanto en el tipo de los estados como en el de los símbolos del alfabeto:

data Dfa st sy = Dfa [sy] -- Vocabulary[st] -- Finite set of statesst -- The start state[st] -- The set of final states(st -> sy -> st) -- Transition Function

Nótese que los conjuntos de estados o de símbolos se modelizan mediante listas. Por último,el tipo de los autómatas finitos no deterministas (NDFA-ε) con transiciones vacías, tambiénllamadas ε-transiciones:

data Ndfa st sy = Ndfa [sy] -- Vocabulary[st] -- Finite set of states[st] -- The set of start states[st] -- The set of final states(st -> Maybe sy -> [st]) -- Transition function

Nótese la generalización de considerar un conjunto de estados iniciales. La función delta detransición, dado un estado s y un símbolo a, conduce en general a un conjunto de estados, quepuede ser vacío. La transición se modeliza en Haskell mediante la aplicación delta s (Just a). Sila transición es vacía, se modeliza mediante la aplicación delta s Nothing.

La librería proporciona funciones para convertir unas representaciones en otras. Las conver-siones directas suministradas, a partir de las cuales y mediante combinación de las mismas sedefinen otras derivadas, son:

De expresion regular a NDFA-ε

De NDFA-ε a DFA

De DFA a expresión regular

La segunda de ellas es sabido que tiene coste exponencial en el caso peor debido a la formaciónde clases con los estados del NDFA-ε , pero la implementación es aún más costosa. Dado unconjunto de estados en el NDFA-ε , para calcular el conjunto de estados alcanzables mediantecero o más ε-transiciones, utiliza la función:

epsilon_closure :: (st -> Maybe sy -> [st]) -> [st] -> [st]

que itera hasta alcanzar un punto fijo. La conversión construye una tabla en la que desde cadadesde clase de estados del NDFA-ε se evoluciona a otra clase según el símbolo de entrada.Esta construcción utiliza repetidamente epsilon_closure y también itera hasta alcanzar unpunto fijo. La tabla resultante se convierte después en un DFA. La tercera conversión, de DFA aexpresión regular, tiene también un coste exponencial en el número de estados del DFA.

La librería también permite calcular los autómatas concatenación y unión de dos DFA’s, asícomo la iteración de un DFA cero o más veces. Las mismas operaciones están disponibles paraNDFA-ε .

Finalmente, hay también una operación que minimiza un DFA y otra que compara dos DFA’spor igualdad, es decir decide si reconocen o no el mismo lenguaje. Para la primera, se dan dosversiones, una estándar que implementa el algoritmo del “llenado-de-tabla” [HMU01], y otra

Librería para lenguajes regulares 2 / 8

Page 17: y V Taller de Programación Funcional (TPF)

que implementa el algoritmo de Brzozowski [Brz62]. El de llenado de tabla podría tener uncoste O(n2) si se utilizaran estructuras adecuadas, pero la implementación alcanza al menosO(n4) debido al uso reiterado de listas intensionales y algoritmos de punto fijo. El de Brzozowskise expresa en una simple línea, pero tiene coste exponencial debido a las dos conversiones deNDFA-ε a DFA:

minimizeDfa = ndfa2dfa . reverseDfa . ndfa2dfa . reverseDfa

La función reverseDfa simplemente invierte el sentido de las transiciones de un DFA, produ-ciendo en general un NDFA.

La comparación por igualdad es también innecesariamente costosa, ya que puede hacerse co-mo veremos en un tiempo O(n2). Minimiza los dos autómatas, renombra sus estados, construyesus tablas de transición, las normaliza y finalmente compara ambas tablas por igualdad.

2. Nuestras extensiones

Como parte de un análisis estático para estudiar relaciones de compartición entre estructurasde datos dinámicas [MPS13], tuvimos necesidad de decidir problemas que involucran lenguajesregulares. Dado que nuestro compilador está escrito en Haskell, HaLeX nos pareció una buenaopción de partida, aunque enseguida vimos que hacía falta extenderla y en lo posible mejorar sueficiencia.

Si L, L1 y L2 denotan lenguajes regulares, las operaciones que el análisis necesita son:

La concatenación L1 .L2, la unión L1∪L2 y la intersección L1∩L2.

La derivación L1|L2, definida como el lenguaje w3 | w2.w3 ∈ L1,w2 ∈ L2, que es regular.

Detectar si L = .

Detectar si L1 ⊆ L2, que es equivalente a ver si L1 = L1∩L2.

Decidimos que ninguna de las tres representaciones de HaLeX nos servía, e introdujimos unamás: los autómatas no deterministas sin transiciones vacías (en adelante PNDFA, de Pure Non-Deterministic Finite Automaton), cuyo tipo es:

data PNdfa st sy = PNdfa [sy] -- Vocabulary[st] -- Finite set of states[st] -- The set of start states[st] -- The set of final states(st -> sy -> [st]) -- Transition function

La razón principal fue evitar el costoso cierre-ε , junto con el convencimiento de que la mayoríade los algoritmos necesarios se podían implementar eficientemente sobre esta representación.

Implementamos conversiones de PNDFA a y desde NDFA-ε para poder aprovecharnos dealgunas implementaciones y así ganar tiempo de desarrollo. Por ejemplo, la concatenación y launión de PNDFAs están implementadas provisionalmente convirtiendo a NDFA-ε , realizandoallí las operaciones y volviendo a convertir a PNDFA. Estos sobrecostes serán evitados en unfuturo implementándolas directamente sobre PNDFAs.

Librería para lenguajes regulares 3 / 8

Page 18: y V Taller de Programación Funcional (TPF)

En cambio, la detección del lenguaje vacío y la intersección, no soportadas por HaLeX, se hanimplementado sobre PNDFA. Si n es el número de estados de los PNDFA’s, y a el tamaño desus alfabetos, los costes son respectivamente O(an2) y O(an4). El primer problema se reduce alde alcanzabilidad de grafos y consiste en ver si en los estados alcanzables hay alguno final. Laprimera fase del segundo algoritmo crea el producto cartesiano de estados con un coste O(n2),pero tiene una fase final de “limpieza” de estados inalcanzables, que utiliza de nuevo el algoritmode alcanzabilidad, pero ahora sobre un conjunto de tamaño n2.

3. El operador de igualdad

La igualdad de lenguajes regulares no es decidible directamente sobre autómatas no determi-nistas. El algoritmo de llenado de tabla puede aplicarse a estos, pero tan solo da una condiciónsuficiente de igualdad. Aplicado a DFAs, la condición es necesaria y suficiente. Dados dos DFAsA1 y A2 no necesariamente mínimos y de idéntico alfabeto Σ, la descripción del algoritmo paradecidir si L(A1) = L(A2) (véase [HMU01]) es la siguiente:

1. Se construye el DFA A = (Σ,Q, i,F,δ ), donde Q es la unión disjunta de los estados de A1y A2, F la unión disjunta de sus estados finales, δ la unión disjunta de sus transiciones, e iel estado inicial de cualquiera de ellos.

2. Inicialmente se marcan como distinguibles las parejas de estados (q, f ) con f ∈ F y q ∈Q−F . El resto de pares se consideran indistinguibles.

3. Para cada par indistinguible (p,q), se estudian las transiciones p a−→ p′ y q a−→ q′ paratodo símbolo a ∈ Σ. Si alguno de los pares (p′,q′) es distinguible, se marca también comotal el par (p,q). Si todos los pares (p′,q′) son indistinguibles, se anota en cada uno deellos que la indistinguibilidad del par (p,q) depende de él. Si alguno de esos pares sehace distinguible más adelante, esa condición de propaga al par (p,q) y a cualquier otroque dependiera de aquel, y de forma recursiva, a todos los pares que dependan directa oindirectamente de estos últimos.

4. Al terminar de procesar todos los pares, los que conserven la condición de indistinguiblesse agrupan en clases de equivalencia. Por ejemplo, si (p,q) y (q,r) son indistinguibles, lostres estados p,q,r han de estar en la misma clase.

5. Los estados iniciales de A1 y A2 acaban en la misma clase de equivalencia si y solo si A1 yA2 reconocen el mismo lenguaje.

La tabla de pares se ha implementado con la tabla clave-valor Data.Map de la librería Haskell(en el código que sigue, abreviada como M), cuyo coste de acceso y modificación es logarítmico.Las claves son los pares (p,q) y el valor asociado, la marca de si el par es distinguible o no,y la lista de sus pares dependientes. La función principal, dado un DFA, calcula las clases deequivalencia de sus estados:

groupUndistinguishable :: (Ord st, Show st) => Dfa st sy -> [[st]]groupUndistinguishable (Dfa v qs s z d) = collapse qs undist1

Librería para lenguajes regulares 4 / 8

Page 19: y V Taller de Programación Funcional (TPF)

where pairs = [((p,q),(mark p q,[])) | p <- qs, q <- qs, p < q]where mark p q = p ‘elem‘ z && q ‘notElem‘ z ||

q ‘elem‘ z && p ‘notElem‘ zundist0 = [(p,q) | ((p,q),(False,_)) <- pairs]table0 = M.fromList pairstable1 = foldl (checkOnePair v d) table0 undist0

-- We keep the pairs with a mark = False, i.e. undistinguishableundist1 = map fst . filter (\(_,(b,_)) -> not b) $ M.toList table1

A los pares (p,q) se les impone la condición p < q para considerar cada pareja una sola vez,undist0 es la lista de los inicialmente indistinguibles, table0 la tabla al comienzo del algorit-mo, table1 la tabla final y undist1 los pares finalmente indistinguibles.

La función que procesa un par (p,q) lo marca como distinguible si alguna de las transicionesposibles conduce a un par distinguible. En otro caso, añade este par a la lista de dependencia decada uno de los pares destino de las transiciónes:

checkOnePair :: (Show st, Ord st) =>[sy] -> -- the alphabet(st -> sy -> st) -> -- the transition functionM.Map (st,st) (Bool,[(st,st)]) -> -- the initial table(st,st) -> -- the pair to be checkedM.Map (st,st) (Bool,[(st,st)]) -- the resulting table

checkOnePair vs d t (p,q) | or marks = markDistinguisable t (p,q)| otherwise = updateDependent (p,q) t destSt

where destSt = filter (\(r,s)-> r /= s) . map (\(r,s)-> if r<s then (r,s) else (s,r))$ [(d p v, d q v) | v <- vs]

-- list of marks. True = distinguishable, False = undistinguishablemarks = map (fst . (t M.!)) destSt

Mostramos la función que marca en la tabla un par como distinguible y recursivamente a susdependientes, como ejemplo de la concisión que es posible alcanzar con un uso juicioso delorden superior:

markDistinguisable t (p,q) =foldl markDistinguisable (M.adjust (const (True,[])) (p,q) t) depswhere (_,deps) = t M.! (p,q)

El operador M.! consulta el valor asociado a una clave y la función M.adjust modifica dichovalor. Los casos base de esta recursión son los pares cuya lista deps de dependencia es vacía.

Por último, la función collapse recibe el conjunto de estados del autómata y la lista depares finalmente indistinguibles y produce la lista de clases de equivalencia. Para ello, crea unaestructura de partición (véase [HSM97]) utilizando de nuevo la librería Data.Map. Ahora laclave es cada estado, y el valor asociado es otro estado de su misma clase y un entero h. Sih≥ 0, el estado asociado es el representante canónico de la clase. En otro caso, el representantecanónico se encuentra iterando la búsqueda sobre este estado. Dos estados están en la mismaclase, si tras iterar las búsquedas a partir de cada uno, se llega al mismo representante canónico.La operación findClass encuentra el representante canónico de un estado en una partición. Elvalor de h asociado al representante canónico conservará la longitud de la cadena más larga delas iteraciones que conducen a él.

collapse qs pairs = map (map fst) $ groupBy (\(_,p)(_,q)-> p==q) sortedListwhere partitionI = M.fromList [(q,(q,0)) | q <- qs]

partitionF = foldl processOnePair partitionI pairs

Librería para lenguajes regulares 5 / 8

Page 20: y V Taller de Programación Funcional (TPF)

pairList = zip qs (map (findClass partitionF) qs)sortedList = sortBy (\(_,p)(_,q)-> if p < q then LT

else if p==q then EQelse GT) pairList

Inicialmente se crea la partición partitionI en la que cada estado forma una clase unitaria.Tras procesar todos los pares se llega a la partición final partitionF que se convierte fácilmentea una lista de clases de equivalencia de estados. Procesar un par indistinguible consiste en unirsus respectivas clases de equivalencia:

processOnePair part (p,q) = joinClasses part p’ q’where p’ = findClass part p

q’ = findClass part q

La operación joinClasses funde en una dos clases denotadas por sus respectivos represen-tantes canónicos. Para ello se elige como canónico el que tenga mayor altura h y se hace queel otro apunte a él. Se demuestra que findClass tiene coste logarítmico y por tanto tambiénjoinClasses.

Gracias al bajo coste de la librería Data.Map, el coste total de la operación de igualdad está enO(n2 logn), siendo n la suma del número de estados de los dos DFA a comparar. Si se utilizaranmatrices y vectores imperativos, el coste podría bajar a O(n2).

4. El operador de derivación

Dados dos PNDFA A1 = (Σ1,Q1, i1,F1,δ1) y A2 = (Σ2,Q2, i2,F2,δ2), no hemos encontrado enla literatura un algoritmo para calcular el PNDFA que reconoce L(A1)|L(A2), y en consecuenciahemos ideado (y demostrado que es correcto) el siguiente:

1. Calcular el PNDFA A′2 añadiendo a A2 una transición con cada símbolo de Σ = Σ1 ∪Σ2desde cada estado final de A2 a sí mismo. Es obvio que A′2 reconoce L(A2) .Σ

∗.

2. Calcular A3 = A1 ∩ A′2, el cual reconoce las palabras de L(A1) que comienzan por unapalabra de L(A2). La construcción implica que los estados de A3 son los pares de Q1×Q2.

3. Construir A4 añadiendo a A3 un estado fresco q0 como nuevo estado inicial. Si L(A1)∩L(A2) = , entonces se añaden ε-transiciones desde q0 a todo estado (qi, p j) ∈ A3 talque qi es un estado no-final de A1 y p j es un estado final de A′2. Si L(A1)∩L(A2) 6= ,entonces qi en (qi, p j) puede ser cualquier estado de A1.

4. Eliminar de A4 todos los estados no alcanzables desde q0. El autómata resultante reconoceexactamente L(A1)|L(A2).

El código Haskell que implementa este algoritmo es casi auto-explicativo, y es el siguiente:

pndfaDerivation :: (Eq sy, Show sy, Show st1, Show st2, Eq st1, Eq st2) =>PNdfa st1 sy -> PNdfa st2 sy -> PNdfa Int sy

pndfaDerivation a1Ini a2Ini = renamePNdfa a4 1where vs = v1 ‘union‘ v2

a1@(PNdfa v1 q1 s1 z1 _) = renamePNdfa a1Ini 1

Librería para lenguajes regulares 6 / 8

Page 21: y V Taller de Programación Funcional (TPF)

a2@(PNdfa v2 q2 s2 z2 _) = renamePNdfa a2Ini 1tt2 = transitionTablePNdfa a2

-- a2’ recognizes L2.Sigma*tt2’ = tt2 ‘union‘ [(q,v,q) | q <- z2, v <- vs]a2’ = ttPNdfa2PNdfa (vs,q2,s2,z2,tt2’)

-- a3 recognizes words w1=w2.w, w1 in L1, w2 in L2a3@(PNdfa _ q3 s3 z3 _) = a1 ‘pndfaIntersect‘ a2’tt3 = map (\(p,v,q) -> (p,Just v,q))

(transitionTablePNdfa a3)tt4 = tt3 ++

if pndfaIsEmpty $ a1 ‘pndfaIntersect‘ a2then [((0,0),Nothing,(p,q))

| p <- q1 \\ z1, q <- z2, (p,q) ‘elem‘ q3]else [((0,0),Nothing,(p,q))

| p <- q1, q <- z2, (p,q) ‘elem‘ q3]-- a4 recognizes L1|L2

stReach = ttReachedFrom [(0,0)] tt4tt4clean = pndfaCleantt stReach tt4a4 = ndfa2pndfa $ ttNdfa2Ndfa $

(vs,(0,0):(q3 ‘intersect‘ stReach),[(0,0)],z3 ‘intersect‘ stReach,tt4clean)

Los estados se renombran para que sean enteros a partir de 1. El estado fresco está representadoen la implementación por el par (0,0). Las últimas líneas se dedican a eliminar los estadosinalcanzables y muertos. Un estado se dice muerto si no existe una secuencia de transicionesdesde él a un estado final. Los costes dominantes son precisamente esta parte del algoritmo, quehacen que el coste total esté en O(an4), siendo a el tamaño del alfabeto unión Σ.

5. Conclusiones

Los lenguajes regulares constituyen un ámbito de la informática en el que la mayoría de pro-piedades son decidibles. Por tanto constituyen un dominio interesante para formar parte de losanálisis estáticos, cuyo principal requisito es que los algoritmos siempre terminen, aunque lohagan con una respuesta imprecisa. En nuestro caso, las palabras de los lenguajes regulares queutilizamos representan caminos de punteros dentro del montón o memoria dinámica, y nos in-forman de las posibles relaciones de compartición entre las variables del programa analizado.

Contar con una librería razonablemente eficiente para decidir propiedades sobre los lenguajesregulares, dentro de que algunos de los problemas que resuelve son NP-completos, era por tantouna necesidad imperiosa. Téngase en cuenta que las operaciones aquí descritas se utilizan cientosde veces en el análisis de un programa que tenga apenas dos decenas de variables. La libreríaHaLeX, creada con fines didácticos, supuso para nosotros tan solo un punto de partida, ya que susalgoritmos están concebidos con un espíritu más de simplicidad que de eficiencia. Por otra parte,le faltaban operaciones necesarias en nuestro análisis tales como la intersección y la derivación.

La extensiones que hemos realizado, convierten HaLeX en una herramienta útil para la inves-tigación, sin perder por ello su carácter didáctico. Sus algoritmos podrían servir de complementoideal a un curso sobre teoría de autómatas. Por otra parte HaLeX cuenta con una herramientagráfica que permite visualizar los autómatas en la forma en que tradicionalmente aparecen en loslibros de texto, lo que añade aún más valor didáctico a la herramienta.

Librería para lenguajes regulares 7 / 8

Page 22: y V Taller de Programación Funcional (TPF)

Referencias

[Brz62] J. A. Brzozowski. Canonical regular expressions and minimal state graphs for definiteevents. Mathematical Theory of Automata 12:529–561, 1962.

[HMU01] J. E. Hopcroft, R. Motwani, J. D. Ullman. Introduction to Automata Theory, Langua-ges and Computation. Addison Wesley, 2nd edition, 2001.

[HSM97] E. Horowitz, S. Sahni, D. Mehta. Fundamentals of Data Structures in C++. Compu-ter Science Press, 4th edition, 1997.

[MPS13] M. Montenegro, R. Peña, C. Segura. Shape Analysis in a Functional Language byUsing Regular Languages. In 15th International Symposium on Principles and Prac-tice of Declarative Programming, PPDP 2013. Pp. 1–12. ACM Press, 2013.

[Sar02] J. Saraiva. Halex: A Haskell library to model, manipulate and animate regular langua-ges. In Proceedings of the ACM Workshop on Functional and Declarative Program-ming in Education (FDPE/PLI 02), Pittsburgh, USA. ACM Press, 2002. See also:http://www3.di.uminho.pt/˜jas/Research/HaLeX/HaLeX.html.

Librería para lenguajes regulares 8 / 8

Page 23: y V Taller de Programación Funcional (TPF)

Euclidean Interpolation: from Mathematical Structures to Typesand Back

Julio Marino

Universidad Politecnica de Madrid

Abstract: Many, many, many eons ago, in some six-year engineering degree, veryfar away, I used to teach one semester of functional programming to third-yearstudents. Of course, higher-order techniques were one of the key contents, and Iused to spend several sessions showing their power. One of my favourite exampleswas euclidean interpolation, as it applied several abstraction features – parametricpolymorphism, and higher-orderness, in many dimensions – to model a techniqueubiquitous in the numerical methods course, also in the third year. The languageused was CaML; later, the introduction of type classes in Haskell paved the wayto a more natural encoding of mathematical structures in code, via multi-parametertype classes. Abstracting away from that specific example, the main challenge inrepresenting mathematical structures in a functional programming language is tomaximize the adequacy of that encoding, i.e. to minimize spurious inhabitants oftypes. This can be achieved in various ways: by using a more constraining type sys-tem – e.g. using dependent types – or ensuring correctness by construction – e.g. viasets of combinators. The talk will provide examples of both approaches in orderto discuss their respective strengths. Comparison with the modelling capabilities ofcommonly used mathematical software is also an interesting exercise.

Keywords: Higher-Order Methods, Functional Programming, Algebra, Interpola-tion, Mathematical Modelling, Parametric Polymorphism.

Euclidean Interpolation: from Mathematical Structures to Types and Back 1 / 1

Page 24: y V Taller de Programación Funcional (TPF)

ECEASST

Derivacion de Interpretes delCalculo Lambda con Tipos Graduales

Alvaro Garcıa-Perez1*, Ilya Sergey2 and Pablo Nogueira3**

1 [email protected] Software Institute

Universidad Politecnica de Madrid, Spain

2 [email protected] Software Institute

3 [email protected] Politecnica de Madrid, Spain, Spain

Abstract: Los tipos graduales tienen como objetivo combinar la comprobacion detipos estatica con la dinamica, introduciendo un tipo ‘dinamico’ y expresiones concoerciones (casts). El tipo dinamico se asigna a aquellas expresiones para las cualeses imposible conocer su tipo en tiempo de compilacion. Una coercion basada entipos, 〈S⇐ T 〉`e, especifica que la expresion e debe ser moldeada en tiempo de eje-cucion para que su tipo pase de T a S. Si dicha operacion no puede llevarse a cabo, lacoercion falla asignando la responsabilidad a la ubicacion del programa `. Los tra-bajos recientes en el area se centran en la semantica dinamica de los tipos graduales.La eleccion de la polıtica de deteccion de errores—deteccion impaciente (eager) operezosa (lazy)—y de la estrategia de asignacion de responsabilidades—asignaciondescendente (downcast) o ascendente-descendente (upcast-downcast)—, ası comoalgunas consideraciones acerca de la eficiencia espacial, configuran un espacio dediseno muy rico para la semantica dinamica de los calculos con coerciones de ordensuperior [SGT09].

El calculo lambda con tipos graduales es una version del calculo lambda con tipossimples al que se le anaden coerciones de orden superior y etiquetas de asignacionde responsabilidad (blame labels). Las coerciones de orden superior se sustentan enel calculo de coerciones, introducido por Hengelein [Hen94]. A diferencia de lascoerciones basadas en tipos, el calculo de coerciones considera operaciones atomi-cas de coercion, que pueden ser combinadas en secuencias (composicion sucesivade coerciones) o en coerciones funcionales (pares de coerciones que se aplican aun tipo funcional, donde el primer elemento del par se aplica al argumento de lafuncion y el segundo elemento se aplica al resultado). Las reglas de contracciondel calculo especifican como reducir una coercion, obteniendo lo que se denominacomo coercion normal.

∗ Autor con beca CAM CPI/0622/2008.∗∗ Trabajo con financiacion parcial de proyectos MINECO TIN2009-14599-C03-00 (DESAFIOS10) y CAMP2009/TIC-1465 (PROMETIDOS).

1 / 2 Volume ()

Page 25: y V Taller de Programación Funcional (TPF)

Interpretes para tipos graduales

En [SG12], Siek y Garcia introducen un interprete definicional generico del calcu-lo lambda con tipos graduales. El interprete se puede instanciar implementando lasdistintas semanticas dinamicas del calculo de coerciones. La correccion del interpre-te no esta demostrada, sino conjeturada [SG12]. En este trabajo, utilizamos lastecnicas de transformacion de programas para derivar semanticas operacionales[ABDM03, Dan05, BD07, DM08, DJZ11] y ası establecer la correspondencia entreel calculo lambda con tipos graduales y los interpretes definicionales introducidosen [SG12]. De esta manera, demostramos las conjeturas en [SG12], enunciando lacorreccion de sus implementaciones con respecto al calculo. En nuestra demostra-cion, fijamos la semantica dinamica eligiendo la polıtica de deteccion de erroresimpaciente y la estrategia de asignacion de responsabilidad descendente (eager-downcast, que abreviamos con las iniciales ED). Nuestra demostracion se gene-raliza de forma inmediata para otras semanticas dinamicas modificando el conjuntode reglas de contraccion de coerciones al comienzo de la transformacion.

Keywords: Semantica operacional, transformacion de programas, tipos graduales,contratos de orden superior, coerciones, estilo de paso por continuaciones, maquinasabstractas.

Referencias

[ABDM03] M. S. Ager, D. Biernacki, O. Danvy, J. Midtgaard. A functional correspondence bet-ween evaluators and abstract machines. In Proceedings of International Conferenceon Principles and Practice of Declarative Programming. Pp. 8–19. 2003.

[BD07] M. Biernacka, O. Danvy. A concrete framework for environment machines. ACMTrans. Comput. Log 9(1):6:1–6:29, Dec. 2007.

[Dan05] O. Danvy. From Reduction-based to Reduction-free Normalization. Electr. Notes.Theor. Comput. Sci 124(2):79–100, 2005.

[DJZ11] O. Danvy, J. Johannsen, I. Zerny. A walk in the semantic park. In Proceedings ofWorkshop on Partial Evaluation and Program Manipulation. Pp. 1–12. 2011.

[DM08] O. Danvy, K. Millikin. On the equivalence between small-step and big-step abs-tract machines: a simple application of lightweight fusion. Information ProcessingLetters 106(3):100–109, 2008.

[Hen94] F. Henglein. Dynamic Typing: Syntax and Proof Theory. Science of Computer Pro-gramming 22(2):197–230, 1994.

[SG12] J. G. Siek, R. Garcia. Interpretations of the Gradually-Typed Lambda Calculus. InProceedings, Scheme and Functional Programming Workshop. 2012.

[SGT09] J. G. Siek, R. Garcia, W. Taha. Exploring the Design Space of Higher-Order Casts.In Proceedings of the 18th European Symposium on Programming Languages andSystems. 2009.

Proc. TPF’13 2 / 2

Page 26: y V Taller de Programación Funcional (TPF)

Sesión 2: Verification and Testing

26

Page 27: y V Taller de Programación Funcional (TPF)

Sesión 2: Verification and Testing

12.00–12.30 Jesús Aransay and Jose Divasón: Performance Analysis ofa Verified Linear Algebra Program in SML

12.30–13.00 Julio Mariño: A Course in Algorithm Design based onHigher-order Patterns

13.00–13.30 Miguel Ángel Francisco Fernández and Laura M. Castro:Uso de propiedades y modelos para las pruebas de sistemasdistribuidos basados en la integración de componentes het-erogéneos

27

Page 28: y V Taller de Programación Funcional (TPF)

Performance Analysis of a Verified Linear Algebra Program in SML

Jesus Aransay1∗, Jose Divason2†

1 [email protected], 2 [email protected] de Matematicas y Computacion

Universidad de La Rioja, Logrono, Spain

Abstract: In this paper we describe the performance results that have been obtainedafter executing a verified Linear Algebra SML program automatically generatedfrom an Isabelle/HOL formalization. This SML program computes the reduced rowechelon form of a matrix, using the well-known Gauss-Jordan algorithm. We explainhow the code generator of Isabelle has been configured to obtain the SML program,the data structures involved, the accuracy of computations and the performance testscarried out over Z2, Q and R matrices with the SML implementation Poly/ML andthe optimizing compiler MLton.

Keywords: Gauss-Jordan algorithm, Verified code, Computer Algebra, Isabelle

Introduction

Isabelle [NPW02] is a generic theorem prover (in the sense that different logics can be im-plemented on top of it). One of those logics is HOL (acronym for Higher-Order Logic) andIsabelle/HOL is the specialization of Isabelle for it. HOL is the most widely used logical settingby the Isabelle community, so that usually Isabelle/HOL is commonly referred to as Isabelle.Its expressiveness has been helpful to formalize relevant results in diverse fields, from softwareand hardware verification (for instance, the seL4 project on the formal verification of an operat-ing system kernel [K+09]) to mathematical foundations (as, for instance, the Basic PerturbationLemma, an intricate result in Homological Algebra [ABR08]).

Thanks to the facilities presented in the code generator of Isabelle, one can obtain certifiedexecutable programs in languages such as SML (abbreviation of Standard ML), OCaml, Haskelland Scala from a suitable subset of HOL specifications. This way, verified code is generatedin those languages (in the sense that one can be sure that the output of the generated code willsatisfy the properties proved in its Isabelle/HOL specification).

Isabelle is programmed in SML [Pau96], a well-known functional programming language.Features of SML include, among others, first-class functions, automatic memory management,parametric polymorphism, static typing, type inference, algebraic data types and pattern match-ing. Some SML compilers are Poly/ML [POL] and SML/NJ [NJ]. In addition, an optimizingSML compiler is MLton [MLT] which enables faster computations at the expense of greatercompilation times.

∗ This work has been supported by the Spanish Government (project MTM2009-13842-C02-01 of MEC) and byFORMATH project, nr. 243847, of the FET program within the FP7 European Commission.† This author is sponsored by the Universidad de La Rioja under a research grant FPI-UR-12.

Performance Analysis of a Verified Linear Algebra Program in SML 1 / 8

Page 29: y V Taller de Programación Funcional (TPF)

The main objective of this paper is to present the results obtained in the execution of a verifiedSML program generated from the formalization in Isabelle/HOL of a well-known Linear Algebraalgorithm: the Gauss-Jordan elimination. In order to do that, we present the specific setupthat we have configured on top of the standard Isabelle code generator trying to obtain betterperformance. This article is divided as follows: in Section 1 we introduce the Gauss-Jordanalgorithm whose properties we have formalized in Isabelle/HOL. Then, in Section 2 we presenthow the code generator of Isabelle has been configured in order to obtain an SML program.In Section 3 the experimental results obtained from the benchmarks are shown and explained,together with some conclusions and further work.

1 The Gauss-Jordan Algorithm

The Gauss-Jordan algorithm is a well-known and useful Linear Algebra algorithm. It is a methodwith several applications; for instance, it is used to solve systems of linear equations, computethe rank of matrices and calculate the inverse or the determinant of a matrix. Given any matrixover a field, the algorithm returns its reduced row echelon form. The reduced row echelon formof a matrix (hereafter, rref) is another matrix that satisfies several properties (see [Rom08] fora complete definition). The Gauss-Jordan algorithm and its properties have been formalizedin Isabelle/HOL (see [ADb]); a technical report which shows how this formalization has beencarried out is presented in [ADa].

2 Setting Up the Code Generator of Isabelle

Once we have formalized in Isabelle/HOL the Gauss-Jordan algorithm and its properties, we aimat generating a verified SML version from it. In order to do that, we have to suitably configurethe code generator of Isabelle to obtain an efficient implementation in SML.

2.1 Mapping Matrices from Isabelle to SML

The data types used both in Isabelle/HOL and SML are crucial, because of their influence in theformalization and the performance tests. In Isabelle/HOL, two representations have been used.In the first one the correctness of the algorithm is proved. The second one is introduced to obtaina better performance, preserving the correctness since the equivalence between operations in bothrepresentations is formally proved inside Isabelle/HOL. The idea is that formalizations have tobe carried out over an abstract representation (the first one) which facilitates this work, whereasan efficient concrete representation (the second one) is only used during the code generationprocess.

The first representation defines matrices as functions over finite domains. The idea of havingunderlying finite types for the indices of matrices has great advantages, from the formalizationpoint of view. For instance, the type system enforces that matrix operations (such as addition orsubstraction) are only performed on matrices of equal dimensions (this would not be the case ifwe were to use, for instance, a list of lists to represent matrices). The algorithm can be executedusing this representation, but it offers very poor performance.

Performance Analysis of a Verified Linear Algebra Program in SML 2 / 8

Page 30: y V Taller de Programación Funcional (TPF)

The second representation is introduced to solve this performance problem. We have chosennested iarrays (iarray stands in the Isabelle library for inmmutable arrays, which are representedin the SML Library by the structure Vector) to represent matrices. As we will show in Section 3,this representation offers a better performance; additionally, it preserves the functional style ofoperations. This means that the definitions of operations over both representations are rathersimilar and this makes easier proving the equivalence between an operation in the functionalrepresentation of matrices and the corresponding one in the representation with iarrays. As wehave already said, the Isabelle type iarray is implemented by the Vector structure of the SMLLibrary. The Vector structure defines polymorphic vectors, immutable sequences with constant-time access (a priori, more efficient and faster than, for instance, lists of lists).

2.2 Mapping Matrices Elements from Isabelle to SML

The Gauss-Jordan algorithm is designed to be carried out over matrices whose elements belong toa field. Now we show how the code generator of Isabelle has been configured to obtain efficientcode for executing this algorithm over matrices with elements in Z2, Q or R.

2.2.1 The Z2 Implementation

To represent Z2 in Isabelle, we have made use of the bit type provided in the Isabelle library. Wehave considered three different alternatives to implement the Isabelle type bit in SML:

1. Using the Bool SML structure (mapping 0 of Isabelle type bit to the false boolean value ofSML and 1 of Isabelle type bit to the true boolean value of SML).

2. Using the IntInf SML structure (mapping the bit values to the corresponding ones ofIntInf ) implementing the arithmetic operations by extensional definitions (by a table).

3. Using the IntInf SML structure implementing the arithmetic making use of integer opera-tions modulo 2.

We have decided to use the third option. Experimentally, we have checked that a better per-formance is achieved using the IntInf structure than using the Bool one (in our case, allocatingIntInf.int elements in memory is faster). Regarding the implementation of operations, betterresults have been obtained mapping the Isabelle bit operations to IntInf operations modulo 2 (a15% reduction in the execution time compared to using an implementation by a table). Therefore,the code generator of Isabelle has been configured as follows to obtain an efficient representationof Z2 and its arithmetic in SML:

code_datatype "0::bit" "(1::bit)"code_type bit (SML "IntInf.int")code_const "0::bit" (SML "0")code_const "1::bit" (SML "1")code_const "op + :: bit => bit => bit"

(SML "IntInf.rem ((IntInf.+ ((_), (_))), 2)")code_const "op * :: bit => bit => bit" (SML "IntInf.* ((_), (_))")code_const "op / :: bit => bit => bit" (SML "IntInf.* ((_), (_))")

Then, in SML a Z2 matrix is a nested vector of elements of type IntInf.int.

Performance Analysis of a Verified Linear Algebra Program in SML 3 / 8

Page 31: y V Taller de Programación Funcional (TPF)

2.2.2 The Q Implementation

Q is representated in Isabelle by fractions of elements of type int. Without doing any modifica-tion in the code generator of Isabelle, a similar data type in SML is obtained (this representationallows to exploit the full arithmetic power of the IntInf SML structure, obtaining arbitrary preci-sion):

data type rat = Frct of (IntInf.int * IntInf.int);

2.2.3 The R Implementation

To implement the Isabelle real type (R), the Isabelle code generator offers two alternatives: usingfractions of integers1 (obtaining the same performance and precision than in Q because it is thesame representation) or serialising it to machine reals in SML (type Real.real). This last oneis formally inconsistent, but convenient from a performance point of view; as far as one onlypretends to carry out computations in the target language (and not bringing them back to Isabellefor proving purposes), the formalization will preserve its soundness.

2.3 The Generated Code

Once the data type refinements for both matrices and matrices elements have been formalizedin Isabelle, an efficient and certified program can be obtained. We must remark that the codegenerator of Isabelle allows us to generate stand-alone verified SML programs. In our case, fromthe Isabelle formalization presented in [ADb] we have generated a verified SML program whichcomputes the rank and the rref of a matrix using the Gauss-Jordan algorithm. The exported codetakes up 1743 lines (65’8 kb) and it can be downloaded from [ADb].

3 Time Comparisons

3.1 The Benchmarks

The tests have been run on an Intel Core i3-370M Processor (2 cores of 2.4 GHz) with 4GBof RAM and Ubuntu GNU/Linux 11.10. The SML compilers that have been used are Poly/ML(versions 5.2 and 5.5) and MLton 20100608; the benchmarks consisted in computing the rref ofrandomly generated matrices of different sizes. To enrich the comparison, we will make use ofsome matrices obtained from neuronal digital images. The total elapsed time in computations isdivided into two columns:

• Processing Time: This is the time that the compilers take up to read and process the filewith the input matrix.

• Execution time: This is the time that the SML program spends on applying the Gauss-Jordan algorithm and printing the result.

1 By default the code generator of Isabelle will make the implementation this way.

Performance Analysis of a Verified Linear Algebra Program in SML 4 / 8

Page 32: y V Taller de Programación Funcional (TPF)

3.2 Results Obtained with Z2 Matrices

Table 1 shows that a remarkable performance is achieved in Z2 by using Poly/ML. MLton isslower: it increases the processing time without reducing the execution one. Both the processingand the execution times grow following a linear pattern with respect to the number of elementsof each matrix using Poly/ML. Moreover, the randomness of the matrices has an influence inthe time. For instance, for a 1024×1024 Z2 matrix generated from a digital image of a neuron(Figure 3.2), the execution time is reduced to half (to 21 seconds, whereas a randomly generatedmatrix of a similar size takes up 45.1 seconds). This is caused by the presence of numerouszero columns (the SML program is faster because the Gauss-Jordan algorithm doesn’t processthese zero columns). Thus, it is reasonable to think that if the algorithm is applied to matricesobtained from the real world2, the execution time (the processing one did not) could be reducedsignificantly.

3.3 Results Obtained with QMatrices

Figure 1: Digital image(1024×1024 px.) of a neu-ron.

Table 2 shows the results obtained for matrices whose elements be-long to Q. In this case MLton is faster than Poly/ML: it reducesthe execution time with a moderate increment of the processing time.Times also grow in the same linear pattern with respect to the numberof elements of each matrix in both SML compilers.

The implementation for Q matrices explained in Section 2.2.2 al-lows arbitrary precision, at the expense of a slower performance. Itcan be noted that most of the computing time of Q matrices is spenton the integer arithmetic. Profiling the computation of the rref of a70×70 rational matrix, one can see that the algorithm spends most ofthe time on performing integer divisions (functions bigRem, bigQuotand bigDivMod), related to the concrete representation of elementsof Q, whereas matrices operations (plus iarray, mult iarray) take upminor times.

18.39 seconds of CPU time (0.54 seconds GC)function cur raw

-------------------------------- ----- -------Primitive.IntInf.bigRem 29.6% (5.61s)Primitive.IntInf.bigQuot 24.9% (4.71s)Primitive.IntInf.bigDivMod 13.0% (2.47s)Primitive.IntInf.make 9.0% (1.71s)GJ_GENERATED_CODE.plus_iarray.fn 0.1% (0.01s)GJ_GENERATED_CODE.mult_iarray.fn 0.1% (0.01s)

3.4 Results Obtained with RMatrices

In Section 2.2.3 we have presented two possible implementations for the Isabelle type real: usingfractions of integers or using machine numbers (type Real.real in SML). The first representation

2 Real world matrices usually present repetitions or patterns which increase the computing performance.

Performance Analysis of a Verified Linear Algebra Program in SML 5 / 8

Page 33: y V Taller de Programación Funcional (TPF)

Z2 matrices

Size(n)

Poly/ML MLtonProcessing

Time (seconds)Execution

Time (seconds)Processing

Time (seconds)Execution

Time (seconds)50 0.0 0.0 0.8 0.0

100 0.3 0.0 4.0 0.1150 0.6 0.1 16.3 0.3200 1.0 0.3 54.6 0.6250 1.6 0.7 124.7 1.3300 2.2 1.2 262.9 2.2350 3.0 1.9 480.4 3.5400 4.6 2.9 809.2 5.2500 7.3 6.1 - -600 10.6 9.8 - -800 19.8 24.1 - -1000 31.8 45.1 - -1200 53.7 79.7 - -1400 65.6 143.0 - -1600 107.0 200.5 - -

Table 1: Elapsed time (in seconds) to process randomly generated (Z2)n×n matrices and computing their

corresponding rrefs using the Gauss-Jordan algorithm with Poly/ML 5.5 and MLton 20100608.

is the same as the one chosen for Q matrices, so the results are the same as the ones presented inTable 2. The results for the second representation are presented in Table 3.

MLton is faster than Poly/ML executing the program, although at the expense of a huge in-crement in the processing time. In addition, it is easy to see that R matrices implemented usingmachine numbers have a better performance than Q ones (or R matrices whose elements havebeen implemented as fractions of integers). For instance, for the same 100× 100 matrix, in Qtakes up 200.9 seconds using Poly/ML and 84.1 using MLton, whereas inR is almost immediateusing Poly/ML. Nevertheless, operations involving Q matrices have arbitrary precision (becauseinteger arithmetic is used) and, on the contrary, some precision errors could appear working withR matrices due to the implementation of floating-point numbers. The user can decide whichserialisation of the Isabelle real type fits better for matrices elements in each use case, accordingto the size of the input matrix and the required precision.

3.5 Conclusions and Further Work

We have presented the results obtained in the execution of a verified SML program generatedfrom the formalization in Isabelle/HOL of a well-known Linear Algebra algorithm. We mustremark that the main objective of this work is to experiment in order to get better performance.In our opinion, we have achieved a verified SML code to compute the rref of matrices usingthe Gauss-Jordan algorithm with a remarkable performance. Taking a quick look at Tables 1, 2and 3, it can be checked that the processing and execution times grow following a linear patternwith respect to the number of elements of each matrix. In general, the execution limits will bedetermined by the memory and not by the time (as it can be seen in Table 3). Another remarkablefact is that MLton, despide being an “optimized SML compiler”, does not outperform Poly/ML

Performance Analysis of a Verified Linear Algebra Program in SML 6 / 8

Page 34: y V Taller de Programación Funcional (TPF)

Rational matrices

Size(n)

Poly/ML MLtonProcessing

Time (seconds)Execution

Time (seconds)Processing

Time (seconds)Execution

Time (seconds)10 0.0 0.0 0.2 0.020 0.0 0.2 0.3 0.030 0.0 1.0 0.6 0.540 0.1 3.7 0.9 1.550 0.1 10.2 1.4 4.560 0.2 22.7 1.9 9.670 0.3 43.0 2.7 18.480 0.5 77.0 3.5 32.790 0.6 126.9 4.5 54.1

100 0.7 200.9 6.0 84.1

Table 2: Elapsed time (in seconds) to process randomQn×n matrices (with elements between -10 and 10)and computing their rrefs using the Gauss-Jordan algorithm with Poly/ML 5.5 and MLton 20100608.

Real matrices

Size(n)

Poly/ML MLtonProcessing Time

(seconds)Execution

Time (seconds)Processing

Time (seconds)Execution

Time (seconds)10 0.0 0.0 0.8 0.020 0.0 0.0 2.5 0.030 0.0 0.0 6.4 0.040 0.1 0.0 13.8 0.060 0.2 0.0 56.9 0.080 0.3 0.0 164.3 0.0

100 0.6 0.2 361.6 0.1200 3.7 0.7 9145.4 0.5300 9.6 2.4 - -400 20.3 5.9 - -500 37.3 10.2 - -600 65.8 20.5 - -700 98.6 44.4 - -800 Segmentation Fault - - -

Table 3: Elapsed time (in seconds) to process randomRn×n matrices (with elements between -10 and 10)and computing their rrefs using the Gauss-Jordan algorithm with Poly/ML 5.2 and MLton 20100608.

significantly; the experimental results show that Poly/ML works quite well computing the rref ofZ2 and R matrices. In fact, MLton needs a lot of time to process those matrices and it doesn’tachieve a reduction of the execution times that Poly/ML take up (see Table 1 and Table 3). Nev-ertheless, an improvement on the performance is obtained working in MLton with Q matrices:the time is reduced to half (see Table 2). As it was expected, scientific computational commercialsoftware obtains better performance than our SML program. For instance, Mathematica 7 takesup 0.25 seconds in computing the rref of a 100×100 matrix with rational elements between -10and 10, whereas our SML program takes up 84.1 seconds using MLton (both of them with exactarithmetic, see Table 2). Moreover, Mathematica 7 takes up 109.14 seconds for a 500× 500

Performance Analysis of a Verified Linear Algebra Program in SML 7 / 8

Page 35: y V Taller de Programación Funcional (TPF)

rational matrix. From our point of view, the SML program performs quite remarkably, takinginto account that it was designed for being formalized and not for computational performance.

As further work, our SML program could be optimized to achieve better performance. The firstway for doing that is to make new refinements on the formalized algorithm in Isabelle/HOL. OurSML program has been automatically generated from an Isabelle/HOL development, so if weoptimize the algorithm in Isabelle/HOL we will obtain more efficient SML code. The second wayis to parallelize it. MLton allows us to export SML functions to C, where we could explore howto parallelize the generated C code. A different possibility would be to use MultiMLton [MUL],a compiler that targets scalable multicore platforms and provides a sophisticated runtime systemtuned to efficiently handle large numbers of lightweight threads.

Bibliography

[ABR08] J. Aransay, C. Ballarin, J. Rubio. A mechanized proof of the Basic PerturbationLemma. Journal of Automated Reasoning 40(4):271–292, 2008.

[ADa] J. Aransay, J. Divason. Formalization and execution of Linear Algebra: from theo-rems to algorithms. Technical report.http://wiki.portal.chalmers.se/cse/uploads/ForMath/felafte

[ADb] J. Aransay, J. Divason. Formalization of the Gauss-Jordan algorithm in Isabelle/HOL.Formal development.http://www.unirioja.es/cu/jodivaso/Isabelle/Gauss-Jordan/

[K+09] G. Klein et al. seL4: Formal Verification of an OS Kernel. In ACM Symposium onOperating Systems Principles. Pp. 207–220. ACM, 2009.

[MLT] The MLton Home Page.http://mlton.org/

[MUL] The MultiMLton Home Page.http://multimlton.cs.purdue.edu/mML/Welcome.html

[NJ] The Standard ML of New Jersey Home Page.http://www.smlnj.org/

[NPW02] T. Nipkow, L. Paulson, M. Wenzel. Isabelle/HOL: A proof assistant for Higher-OrderLogic. Springer, 2002.

[Pau96] L. C. Paulson. ML for the working programmer (2nd ed.). Cambridge UniversityPress, New York, NY, USA, 1996.

[POL] The Poly/ML Home Page.http://www.polyml.org/

[Rom08] S. Roman. Advanced Linear Algebra. Graduate Texts in Mathematics. Springer, 2008.

Performance Analysis of a Verified Linear Algebra Program in SML 8 / 8

Page 36: y V Taller de Programación Funcional (TPF)

A Course in Algorithm Design Based on Higher-Order Patterns

Julio Marino

Universidad Politecnica de Madrid

Abstract: Many years ago, I taught a course on algorithm design that covered thetypical design strategies using Haskell as vehicle and higher order schemes as a wayof capturing the common behaviour in algorithm families. Now, the course is gone,functional programming is no longer in the core curriculum of our undergraduatestudents and algorithm design itself is reduced to a minimum, given the shortage ofcredits available for programming courses. However, I feel that many of the tech-niques we applied in that course – quite successfully, in my opinion – can be usefulfor other courses or even professional practice. In this talk I will show the main tech-niques taught – such as divide-and-conquer, greedy algorithms, guided search, etc. –which will be illustrated with simple and not-so-simple examples. Also, special at-tention will be payed to the issue of ensuring that patterns are instantiated properly.Ideally, understanding the types of the functions involved helps students avoidingmistakes in the application of the schemes. However, one often needs stronger guar-antees than those offered by types alone. I will show a novel approach based onproperty-based testing that avoids the need for involved mathematical proofs.

Keywords: Design Patterns, Higher-Order Programming, Generic Programming,Algorithm Design, Property-Based Testing

A Course in Algorithm Design Based on Higher-Order Patterns 1 / 1

Page 37: y V Taller de Programación Funcional (TPF)

USO DE PROPIEDADES Y MODELOS PARA LAS PRUEBAS DESISTEMAS DISTRIBUIDOS BASADOS EN LA INTEGRACION

DE COMPONENTES HETEROGENEOS

Miguel A.Francisco2, Laura M. Castro1

MADS Group, University of A Coruna (Spain)1, Interoud Innovation S.L. (Spain)2

Abstract: Las pruebas son una de las actividades clave en el desarrollo software,puesto que ayudan a detectar errores que de otro modo pasarıan desapercibidos has-ta la puesta en produccion. Sin embargo, al contrario que en otras fases del ciclo dedesarrollo, como son el analisis, diseno o la codificacion, en las que existen procesosy tecnicas bien definidas, junto con herramientas que permiten llevar a cabo dichosprocedimientos de una manera unificada, hay una carencia de herramientas o meto-dologıas que permiten realizar las pruebas de una manera comoda, lo cual implicaque muchas veces sean omitidas.

Este trabajo presenta una aproximacion a seguir para las pruebas del software, cen-trandose en sistemas distribuidos, compuestos por varios componentes heterogeneos(implementados en diferentes lenguajes de programacion) que se integran entre sı.Este tipo de sistemas distribuidos son muy comunes en la industria y, por tanto, lasbases y conceptos presentados en este trabajo se fundamentan a traves de su apli-cacion practica en un sistema real. En concreto, todas las tecnicas descritas estansiendo usadas y evaluadas en el desarrollo de un sistema llamado VoDKATV y desa-rrollado por Interoud Innovation, el cual es un middleware de IPTV que permite a losusuarios acceder a diferentes servicios multimedia a traves de su television, telefonomovil, tablet, ordenador, etc. VoDKATV esta compuesto por multiples subsistemas,tanto del lado servidor como cliente, y estan desarrollados con diferentes tecnologıas(Java, Erlang, C, etc).

Keywords: Pruebas, verificacion, validacion, propiedades, integracion

Probar un sistema distribuido consiste en validar el comportamiento de cada uno de los com-ponentes individuales, ademas de que la integracion entre cada uno de ellos sea correcta. Existenmultiples tecnicas para realizar las tareas de pruebas, pero aquı se presenta una propuesta basadaen la definicion de propiedades o modelos de pruebas que describen de una manera funcionalel comportamiento del software, siguiendo una aproximacion de pruebas basada en propiedades(Property Based Testing [4]). De esta forma, a partir de estas propiedades y modelos pueden ge-nerararse automaticamente casos de prueba sin necesidad de especificarlos uno a uno de formamanual. Esta aproximacion, puramente funcional, presenta ventajas sobre otras aproximacionescomo es la generacion automatica de casos de prueba a partir de una descripcion funcional delsistema a probar, lo cual permite realizar mas pruebas con menos codigo. En este trabajo se usala version Erlang de QuickCheck [3, 1] como herramienta basica para la especificacion funcionaldel software, ası como la generacion y ejecucion de casos de prueba a partir de dicha especifica-cion.

1 / 3

Page 38: y V Taller de Programación Funcional (TPF)

Uno de los objetivos principales es usar esta aproximacion, basada en propiedades y usan-do la version Erlang de QuickCheck, para probar software escrito en diferentes lenguajes deprogramacion, como Java, Erlang o JavaScript. Ademas, la idea de este trabajo es usar esta apro-ximacion en todas las fases del desarrollo del producto software, pudiendo ser utilizada tantopara las pruebas unitarias, las pruebas de componente, las pruebas de integracion y las pruebasde sistema.

Durante la implementacion de cada componente individual, despues de las fases de analisisy diseno del sistema en las que se define la arquitectura global del mismo con los componentesque forman parte de la solucion y la comunicacion entre ellos, las pruebas son basicas para ga-rantizar que este funciona correctamente. La metodologıa elegida para probar cada componentees Test Driven Development, la cual se basa en escribir la prueba antes que la propia implemen-tacion. Nuestra propuesta consiste en combinar esta metodologıa con Property Based Testing,es decir, las pruebas basadas en propiedades. De esta forma, cada vez que se implementa unanueva funcionalidad, se escriben las propiedades que debe cumplir dicha funcionalidad, comen-zando por las mas basicas, y se va completando la implementacion para que dichas propiedadesse cumplan [7].

Al tratarse de un sistema distribuido, los componentes se deben integrar entre sı. En nuestrocaso de estudio, el uso de servicios web es la forma mas comun para que varios componentes secomuniquen entre sı. En cualquier caso, cada componente debe ofrecer una API de integracionque permita a otros componentes interactuar con el. Esta API de integracion tambien debe serprobada. En nuestro caso, hemos adoptado el uso de modelos de prueba, basados en la defini-cion de una maquina de estados QuickCheck, que describen de manera abstracta (sin dependerde la implementacion) como debe funcionar la API de integracion para que automaticamentese generen los casos de prueba que son ejecutados contra el sistema real gracias al uso de unadaptador [6]. Por otro lado, hemos estado investigando el uso de lenguajes de especificacion,como UML, OCL o WSDL, para describir el comportamiento de la API de integracion a pro-bar, y generar propiedades o modelos de prueba QuickCheck a partir de dicha especificacion.De esta forma, es posible facilitar la labor de especificacion del comportamiento del sistema sinnecesidad de conocer un lenguaje de programacion especıfico para la especificacion de propie-dades [5].

Por ultimo, la integracion de componentes tambien puede ser realizada con esta misma apro-ximacion funcional. El uso de mocks y stubs puede combinarse con las pruebas basadas en pro-piedades para especificar con que componentes debe interactuar un subsistema concreto y comodebe realizar cada una de las llamadas a su API de integracion [2].

En resumen, la idea de este trabajo es la definicion de una metodologıa de pruebas, basadaen propiedades, que pueda ser utilizada a lo largo de todo el ciclo de desarrollo de un sistemasoftware. Para ello, se esta usando un caso de estudio real en la industria que permite utilizar yevaluar cada una de las aproximaciones propuestas.

Referencias

[1] T. Arts, J. Hughes, J. Johansson, and U. Wiger. Testing telecoms software with Quviq Quick-Check. In 5th ACM SIGPLAN Workshop on Erlang (Erlang’06), Portland, Oregon, USA,

2 / 3

Page 39: y V Taller de Programación Funcional (TPF)

September 18-20, 2006, pages 2–10, New York, USA, 2006. ACM.

[2] L. M. Castro, M. A. Francisco, and V. M. Gulıas. A Practical Methodology for IntegrationTesting. In 12th International Conference on Computer Aided Systems Theory (EURO-CAST’09), Las Palmas de Gran Canaria, Spain, February 15-20, 2009. Revised SelectedPapers, volume 5717 of Lecture Notes in Computer Science, pages 881–888, Berlin, Heidel-berg, 2009. Springer-Verlag.

[3] K. Claessen and J. Hughes. QuickCheck: a lightweight tool for random testing of Haskellprograms. In 5th ACM SIGPLAN International Conference on Functional programming(ICFP’00), Montreal, Canada, September 18-21, 2000, pages 268–279, New York, USA,2000. ACM.

[4] J. Derrick, N. Walkinshaw, T. Arts, C. B. Earle, F. Cesarini, L.-A. Fredlund, V. Gulıas,J. Hughes, and S. Thompson. Property-based testing - the protest project. Lecture Notesin Computer Science, 6286 LNCS:250–271, 2010.

[5] M. A. Francisco and L. M. Castro. Automatic Generation of Test Models and Propertiesfrom UML Models with OCL Constraints. In 12th Workshop on OCL and Textual Modelling(OCL’12, co-located with MODELS’12), Innsbruck, Austria, October 1-5, 2012, pages 49–54, New York, USA, 2012. ACM.

[6] V. M. G. Laura M. Castro, Miguel A. Francisco. Uso de propiedades abstractas para es-pecificacion de pruebas funcionales de caja negra. In XI Jornadas sobre PROgramacion yLEnguajes (PROLE 2011), A Coruna, Spain, September 5-7, 2011, Lecture Notes in Com-puter Science, pages 81–95. Springer-Verlag, 2011.

[7] S. Rivas, M. A. Francisco, and V. M. Gulıas. Property Driven Development in Erlang, byExample. In 5th Workshop on Automation of Software Test (ASE ’10), Cape Town, SouthAfrica, May 1-8, 2010, pages 75–78, New York, USA, 2010. ACM.

3 / 3

Page 40: y V Taller de Programación Funcional (TPF)

XII Jornadas sobre Programación y Lenguajes (PROLE)

40

Page 41: y V Taller de Programación Funcional (TPF)

Sesión 1: Typing

41

Page 42: y V Taller de Programación Funcional (TPF)

Sesión 1: Typing

9.30–10.00 Francisco J. López-Fraguas and Enrique Martin-Martin:Typing as Functional-Logic Evaluation

10.00–10.30 Miguel Garcia and Francisco Ortin: Optimización deLenguajes con Comprobación Estática y Dinámica de Tipos

42

Page 43: y V Taller de Programación Funcional (TPF)

Typing as Functional-Logic Evaluation∗

Francisco J. Lopez-Fraguas and Enrique Martin-Martin

[email protected], [email protected]. de Sistemas Informaticos y Computacion,

Universidad Complutense de Madrid, Spain

Abstract: We present a transformational approach to type inference for functionallogic programs. More concretely, we give a broad set of examples showing how,given a functional logic program P, we can synthesize a remarkably simple and nat-ural functional logic program P’ such that the evaluation of expressions with respectto P’ corresponds to typing the expressions in the original P. We start developingthose ideas for the case of type inference with standard Hindley-Milner types, andafter that we consider some variations, like local definitions with different degrees ofpolymorphism, existential types and type checking in the presence of polymorphicrecursion. For the basic case of Hindley-Milner types we provide also a formaliza-tion of the transformation and proofs of its correctness. Besides its potential appli-cability to the implementation of different type systems, or to the educational use ofthe synthesized typing programs to explain different type inference/checking pro-cesses, the paper demonstrates vividly the expressive power of functional logic lan-guages, as well as some of their limitations for metaprogramming purposes, that wehave overcome by providing a suitable set of metalogical functions to inspect, clas-sify and manipulate expressions according to their structure, similar to well knownProlog metapredicates for such purposes.

Keywords: Type inference, type checking, functional logic programming

∗ Appeared in the Proceedings of the ACM SIGPLAN 2013 Workshop on Partial Evaluation and Program Manipula-tion (PEPM ’13). ACM, New York, NY, USA, pp. 23-32. http://dx.doi.org/10.1145/2426890.2426896

Typing as Functional-Logic Evaluation 1 / 1

Page 44: y V Taller de Programación Funcional (TPF)

1 / 15 2013

Optimización de Lenguajes con Comprobación Estática y Dinámica de Tipos*

Miguel Garcia1 y Francisco Ortin2

1 [email protected]

2 [email protected] Departamento de Informática, Universidad de Oviedo

Resumen: Los lenguajes con comprobación dinámica de tipos son utilizados comúnmente en diversos escenarios del desarrollo de software, como el desarrollo rápido de prototipos o aplicaciones con requisitos de alta adaptabilidad dinámica. Por otro lado, los lenguajes con comprobación estática de tipos ofrecen innegables ventajas como la detección tem-prana de errores y un mayor número de optimizaciones por parte del compilador. Dado que ambos enfoques ofrecen diferentes beneficios, en los últimos años han surgido len-guajes de programación con sistemas de tipos híbridos (estáticos y dinámicos). Del mismo modo, algunos lenguajes con comprobación estática de tipos también han incorporado la posibilidad de incluir tipos dinámicos en su sistema de tipos. Sin embargo, estos lenguajes no realizan inferencia de tipos alguna en tiempo de compilación de código con comproba-ción dinámica de tipos, perdiendo así parte de su robustez y rendimiento. StaDyn es una extensión de C# con comprobación de tipos híbrida, que realiza inferencia de tipos tanto en código declarado estático como dinámico. La información inferida por el compilador es usada para optimizar el código generado, obteniendo un mejor rendimiento sin repre-sentar ningún coste de memoria en tiempo de ejecución. Este trabajo evalúa la optimiza-ción obtenida en el lenguaje StaDyn, comparando el rendimiento en tiempo de ejecución y el consumo de memoria con otros lenguajes híbridos existentes sobre el .NET Framework. La utilización de la información de tipos inferida ha implicado una mejora de rendimiento en todos los benchmarks utilizados, siendo 1,5 veces más rápido ejecutando código diná-mico y 5 veces con código híbrido. Palabras clave: Sistemas de tipos híbridos, comprobación estática y dinámica de tipos, lenguajes dinámicos, rendimiento, StaDyn, C#, .NET

1 Introducción Los lenguajes con comprobación dinámica de tipos son ampliamente utilizados en escenarios específicos como la ingeniería Web, el prototipado rápido de aplicaciones, la programación orientada a aspectos dinámica y, en general, cualquier tipo de desarrollo que requiera una alta adaptabilidad en tiempo de ejecución. La principal ventaja de estos lenguajes es la simplicidad que ofrecen para desarrollar y mantener software altamente dependiente del contexto en el que

* Este trabajo ha sido parcialmente financiado por Microsoft Research, dentro del proyecto titulado

Extending dynamic features of the SSCLI, obtenido en el Phoenix and SSCLI, Compilation and Mana-gement Execution Request for Proposals. También ha sido financiado por el Ministerio de Ciencia e Innovación mediante el proyecto TIN2011-25978, Obtención de Software Adaptable, Robusto y Eficien-te añadiendo Reflexión Estructural a Lenguajes con Comprobación Estática de Tipos.

Page 45: y V Taller de Programación Funcional (TPF)

ECEASST

2 / 15 2013

es ejecutado. Las principales características de los lenguajes dinámicos son la meta-programación, la reflexión, la movilidad y la reconfiguración dinámica. Tomando la ingeniería Web como ejemplo, el lenguaje Ruby junto con el framework Ruby On Rails ha tenido un ele-vado éxito en el desarrollo de aplicaciones Web, confirmando la simplicidad de estos lenguajes para implementar los principios DRY (Don't Repeat Yourself) [HT99] y Convention over Con-figuration [THS+05]. Actualmente, JavaScript esta siendo utilizado para el desarrollo de apli-caciones Web interactivas mediante AJAX (Asynchronous JavaScript And XML). PHP (PHP Hypertext Preprocessor) es uno de los lenguajes más populares para el desarrollo web de con-tenido dinámico. Python es utilizado para diferentes propósitos, siendo dos ejemplos conoci-dos el servidor de aplicaciones Zope y el framework de desarrollo de aplicaciones Web Djan-go.

Los beneficios ofrecidos por los lenguajes dinámicos han hecho que algunos lenguajes con comprobación estática de tipos hayan añadido comprobación dinámica de tipos. Un claro ejemplo de esta tendencia es el nuevo tipo dynamic añadido al lenguaje C# 4.0 [CT]. Con este nuevo tipo, el compilador pospone todas las verificaciones estáticas hasta la ejecución, lo que permite el desarrollo de código más flexible. Mediante el uso del DLR (Dynamic Langua-ge Runtime), es posible acceder directamente a programas escritos en IronPython, IronRuby y el código JavaScript usado en Silverlight.

Java también ha seguido esta tendencia. Recientemente la JSR 292 (Java Specification Re-quest) [Sun] ha sido incorporada a la versión Java 1.7 SE, añadiendo la instrucción invoke-dynamic a la JVM (Java Virtual Machine), y el paquete java.lang.invoke a la plata-forma. De este modo resulta más sencillo implementar lenguajes con comprobación dinámica de tipos para la máquina virtual de Java. La principal ventaja es que ofrece un mecanismo para posponer la resolución de las llamadas a métodos hasta el tiempo de ejecución.

La gran flexibilidad de los lenguajes con comprobación dinámica de tipos contrasta con las limitaciones derivadas de la falta de comprobación estática. La comprobación estática permite la detección temprana de errores, mejor documentación, mayor número de optimizaciones por parte del compilador y mejor rendimiento. Sin embargo, la comprobación dinámica de tipos proporciona una solución a almacenamiento de datos persistentes, comunicación entre proce-sos, personalización del comportamiento de programas o generación dinámica de programas [ACPP91]. Por ello, existen situaciones en las que se precisa el uso de tipos dinámicos, incluso cuando se utilizan sistemas de tipos avanzados con comprobación estática de tipos [MD04].

Debido a que ambas aproximaciones poseen diferentes beneficios, ha habido trabajos que permiten ofrecer ambas aproximaciones en el mismo lenguaje. Uno de los primeros trabajos en esta línea es de Meijer y Drayton, donde se proponen sistemas de tipos híbridos, en lugar de obligar a los programadores a elegir exclusivamente entre comprobación estática y dinámica [MD04].

Nuestro trabajo rompe la elección exclusiva entre comprobación dinámica o estática de ti-pos. Hemos diseñado un lenguaje de programación, denominado StaDyn [OZGPSG10], que ofrece tanto comprobación estática como dinámica en el mismo lenguaje de programación –puede consultarse una descripción informal del lenguaje en [Ort]. Este lenguaje de programa-ción combina la robustez y eficiencia de los lenguajes con comprobación estática de tipos con la flexibilidad y adaptabilidad de los lenguajes con comprobación dinámica. El programador indica cuándo requiere alta flexibilidad (tipado dinámico) o la robustez de un sistema de tipos estático. También es posible combinar ambos enfoques, haciendo partes de la aplicación más flexibles, mientras que el resto del programa mantiene su robustez y rendimiento en tiempo de

Page 46: y V Taller de Programación Funcional (TPF)

Optimización de Lenguajes con Comprobación Estática y Dinámica de Tipos

Proc. PROLE 2013 3 / 15

ejecución. La mayor contribución de nuestro lenguaje, comparado con otros existentes que poseen comprobación híbrida, es que el compilador continúa obteniendo información de tipos del código declarado como dinámico. Esta información es usada para detectar errores de tipo en tiempo de compilación y optimizar significativamente el código generado, sin implicar por ello un mayor coste de memoria en tiempo de ejecución.

El resto de este artículo se estructura de la siguiente forma. En la siguiente sección, descri-bimos someramente el lenguaje de programación StaDyn. En la Sección 3 presentamos una evaluación detallada del rendimiento en tiempo de ejecución, comparando los resultados de diferentes lenguajes. Finalmente, comentamos el trabajo relacionado en la Sección 4 y las con-clusiones y trabajo futuro en la Sección 5.

2 El Lenguaje de Programación StaDyn Esta sección presenta una visión general del lenguaje de programación StaDyn, las técnicas empleadas para su implementación se detallan en [OZGPSG10] y la descripción formal del sistema de tipos en [Ort11b]. El lenguaje de programación StaDyn es una extensión de C# 3.0 [Cor], aunque las técnicas utilizadas para la implementación de su compilador podrían ser aplicadas a cualquier lenguaje de programación orientado a objetos con comprobación estática de tipos [Ort11b]. El principal cambio es la extensión del comportamiento del tipado implícito de variables locales de C# 3.0. En StaDyn, el tipo de las referencias puede ser declarado de manera explícita, pero también puede ser establecido implícitamente mediante el uso de la pa-labra reservada var. StaDyn permite el uso de var como cualquier otro tipo, mientras que C# 3.0 solamente lo permite en la inicialización de referencias locales. StaDyn no ofrece la pala-bra reservada dynamic de C# 4.0. En su lugar permite el uso de referencias var estáticas y dinámicas. La implementación actual del compilador de StaDyn genera código IL (antes de la construcción de los ficheros ejecutable) compatible con el .NET Framework 3.0. Por lo tanto, no ha sido necesario el desarrollo o modificación de ninguna plataforma de ejecución, pudien-do utilizarse cualquiera de las disponibles (CLR, Mono, DotGNU Portable.NET o SSCLI). A continuación se identifican de un modo somero las principales características del lenguaje StaDyn.

Los lenguajes con comprobación estática de tipos existentes obligan a una variable declara-da con un tipo T a tener el mismo tipo T dentro de su ámbito. No obstante, los lenguajes diná-micos permiten albergar diferentes tipos en el mismo ámbito. StaDyn ofrece esta característica mediante la comprobación estática de tipos, considerando el tipo concreto de cada referencia. En la Figura 1, figura tiene más de un tipo en el método f. La inferencia de tipo de las va-riables var, se ha implementado mediante una modificación [OZGPSG10] del algoritmo de Hindley-Milner [Mil78].

Este algoritmo obliga a las referencias a tener el mismo tipo estático en el ámbito en el cual se ha declarado. Para poder superar esta limitación, se ha implementado una versión del algo-ritmo SSA (Single Static Assignment), el cual garantiza que cada referencia es asignada una sola vez mediante el uso de variables temporales. En el ejemplo de la Figura 1, internamente se utilizan 3 nuevas variables temporales var (líneas 15, 17 y 19) antes de realizar la inferencia de tipos.

Page 47: y V Taller de Programación Funcional (TPF)

ECEASST

4 / 15 2013

1: using System; 2: class Circunferencia 3: public var x, y, radio; 4: 5: class Rectangulo 6: public var x, y, ancho, alto; 7:

8: class Triangulo 9: public var x1, y1, x2, y2, x3, y3; 10:

11: class Programa 12: public static int f() 13: var figura; 14: if (Random.Next() % 2 == 0) 15: figura = new Circunferencia(); 16: else 17: figura = new Rectangulo(); 18: // static duck typing 19: return figura.x; // Se infiere int

20: 21: public static var getX(var figura) 22: return figura.x; 23: 24:

Figura 1: Ejemplo de programa en StaDyn.

El Duck Typing es una propiedad de los lenguajes dinámicos que significa que un objeto es intercambiable por cualquier otro objeto que implemente la misma interfaz dinámica, indepen-dientemente de si tienen una relación de herencia o no. StaDyn ofrece duck typing, pero con comprobación estática de tipos. El sistema de tipos de StaDyn es sensible al flujo de ejecución del programa, es decir, tiene en cuenta el flujo de cada referencia var. El compilador infiere la unión de todos los posibles tipos concretos a los que puede referenciar una variable, teniendo en cuenta que dependiendo del flujo de ejecución, una misma variable puede tener tipos dife-rentes. Si una referencia var apunta a un conjunto de objetos que implementan un método publico m, el mensaje m puede ser pasado de forma segura, aunque estos objetos no implemen-ten una interfaz común o una clase (abstracta) con el método m. Esta propiedad se obtiene a través de la inferencia de tipos unión [Pie92]. Un ejemplo de esta propiedad es la línea 19 de la Figura 1, donde el compilador infiere que el tipo de figura es el tipo unión Circunfe-rencia ˅ Rectangulo. En este caso, se puede pasar el mensaje x a figura por que todos los tipos pertenecientes al tipo unión poseen un atributo x. En caso contrario se produci-ría un error de compilación [Ort11a].

StaDyn permite el uso de referencias var tanto estáticas como dinámicas. Dependiendo de su dinamismo, la comprobación e inferencia de tipos puede ser pesimista (estática) u optimista (dinámica), sin alterar el significado dinámico del lenguaje de programación. Se ha dado una nueva interpretación (más optimista) a los tipos unión cuando se utilizan variables dinámicas [Ort11a]. Por ejemplo, si la referencia figura fuese dinámica, se le podría pasar el mensaje radio en la línea 20, debido a que al menos un tipo perteneciente al tipo unión posee radio (el tipo Circunferencia). En caso de que ninguno de los tipos aceptara el mensaje pasado, se produciría un error de compilación [Ort11a].

El dinamismo de las referencias var es manejado por el IDE, ubicándolo en un fichero se-parado (un documento XML) [OM11]. Dado que el dinamismo no está declarado explícita-mente en el código fuente, StaDyn facilita la conversión de referencias dinámicas en estáticas y viceversa. Esta separación permite cambiar de prototipos desarrollados rápidamente a aplica-ciones finales robustas y eficientes. También es posible realizar partes de una aplicación más adaptables, manteniendo la robustez del resto del programa.

La reconstrucción de tipos concretos no se limita solamente a las variables locales. StaDyn realiza una análisis global sensible al flujo de ejecución de todas las referencias var implíci-

Page 48: y V Taller de Programación Funcional (TPF)

Optimización de Lenguajes con Comprobación Estática y Dinámica de Tipos

Proc. PROLE 2013 5 / 15

tas. Esto implica que es posible declarar tanto atributos (campos) como parámetros var. Tal y como se aprecia en la Figura 1, los atributos de Circunferencia y Rectangulo pueden tener cualquier tipo (son var).

Para implementar esta característica, se ha ampliado el sistema de tipos, haciendo que sea basado en restricciones [OSW97]. Cuando la declaración de un método contiene parámetros de tipo var, se establecen una serie de condiciones que deben de cumplir éstos. Estas restriccio-nes se crean analizando el cuerpo del método. Un ejemplo es el método getX de la ¡Error! No se encuentra el origen de la referencia.1, donde la instrucción de la línea 22 obliga a que el parámetro figura tenga un atributo x. Además, se establece que el tipo de retorno del mé-todo getX sea el tipo de figura.x. En cada punto de la aplicación donde se realiza una in-vocación a un método, el compilador comprueba que los objetos pasados como parámetro cumplan las restricciones establecidas. De no ser así, se produce un error de compilación (por ejemplo si se pasa una instancia de Triangulo al método getX).

3 Evaluación del rendimiento en tiempo de ejecución Hemos evaluado el rendimiento y consumo de memoria de StaDyn, comparándola con otros lenguajes. El principal objetivo de esta evaluación es conocer la mejora obtenida en el rendi-miento gracias a la inferencia estática de tipos. En esta evaluación, se han empleado un con-junto de benchmarks existentes, contrastando los resultados previamente obtenidos en la eva-luación de un micro-benchmark sintético [Ort11b].

3.1. Metodología Para realizar la evaluación del lenguaje de programación StaDyn descrito en este trabajo, he-mos comparado su rendimiento y consumo de memoria con los lenguajes de programación con comprobación de tipos hibrida existentes para el Framework .NET, todos ellos compilados con sus máximo nivel de optimización. Nos centramos en lenguajes .NET para evitar la introduc-ción de variaciones causadas por el uso de diferentes plataformas (por ejemplo Java, Python, Ruby o aplicaciones nativas). Los lenguajes que hemos usado para la evaluación son:

• C# 4.0. La última versión de C# que combina comprobación de tipos estática y diná-mica con el tipo dynamic. Hace uso del DLR, la capa sobre el CLR que ofrece un conjunto de servicios que facilita la implementación de lenguajes dinámicos [CT].

• IronPython 2.7.3. Es una implementación de software libre del lenguaje de programa-ción Python integrado con el Framework .NET 4.0, que utiliza el DLR. Compila pro-gramas Python a código ejecutable .NET [Iro].

• Visual Basic (VB) 10: También ofrece comprobación híbrida. Las referencias dinámi-cas se declaran con la palabra reservada Dim, sin establecer un tipo. Con esta sintaxis, el compilador no obtiene información de tipos estática y la comprobación de tipos se realiza dinámicamente [Vic07].

• Boo 0.9.4.9: Lenguaje de programación para el CLI con una sintaxis inspirada en Python. Tiene comprobación estática y dinámica de tipos, permitiendo el uso de duck typing mediante el tipo especial duck [Oli]. Boo ha sido utilizado en distintos escena-rios de desarrollo de software real como la implementación de vista para el framework MonoRail [Cas], la creación de DSLs (Domain-Specific Languages) para la platafor-

Page 49: y V Taller de Programación Funcional (TPF)

ECEASST

6 / 15 2013

ma .NET [Rah10] o el desarrollo de video juegos y aplicaciones de escritorio y móvi-les mediante Unity [Uni].

• Cobra 0.9.1: Se trata de un lenguaje de programación orientado a objetos con compro-bación dinámica y estática de tipos, que posee inferencia de tipos en tiempo de compi-lación. Al igual que C#, utiliza el tipo especial dynamic para la comprobación diná-mica de tipos [SFM+96].

• Fantom 1.0.63: Es un lenguaje de programación orientado a objetos que genera código para la maquina virtual de Java (JVM), la plataforma .NET y JavaScript. Tiene com-probación estática de tipos, pero permite la invocación dinámica de métodos con un operador específico de paso de mensajes [FF12].

• StaDyn. Los mismos programas codificados en C# 4.0 se trasforman en StaDyn sim-plemente sustituyendo la palabra reservada dynamic por var especificando estas va-riables como dinámicas.

Todos estos lenguajes compilan código para la plataforma .NET, facilitando la comparación de los resultados del rendimiento. Para cada lenguaje hemos evaluado una versión de las si-guientes aplicaciones:

• Pybench. Es un benchmark diseñado para medir el rendimiento de implementaciones estándar de Python. Está compuesto por una colección de 52 test que evalúan diferen-tes aspectos del lenguaje de programación Python. Hemos suprimido aquellos test que hacen uso de características específicas del lenguaje Python (por ejemplo tuplas o eva-luación dinámica de código), no soportadas por los otros lenguajes utilizados en esta evaluación. Se han realizado un total de 31 test que incluyen operaciones aritméticas y de comparación (con enteros, reales y cadenas), llamadas a métodos y constructores, acceso a atributos, manejo de diccionarios y listas, creación de instancias y manejo de excepciones.

• Pystone. Se trata de la versión Python del benchmark Dhrystone. Está compuesto de operaciones aritméticas, asignaciones, llamadas a funciones, comparaciones y bucles. Para realizar los cálculos maneja estructuras de datos compuestas por números enteros, matrices de enteros, cadenas y valores booleanos.

• Un subconjunto de aplicaciones del benchmark Java Grande [Kri12]: o Section 2 (Kernels). FFT, algoritmo de transformación de N números comple-

jos; Heapsort, el algoritmo de ordenación heap sort con arrays de números en-teros; y SparseMatmult, manejo de matrices dispersas no estructuradas. Todos estos algoritmos utilizan arrays de números enteros y reales para la realización de los cálculos.

o Section 3 (Large Scale Applications). RayTracer, trazador de rayos de escenas 3D que contienen 64 esferas renderizadas a una resolución de 25x25 pixeles.

• Points. Se trata de una aplicación diseñada para evaluar el rendimiento de lenguajes con comprobación estática y dinámica de tipos. Utiliza una aproximación similar a ti-pos dependientes, en las que realiza distintas operaciones sobre objetos 2D y 3D, de-pendiendo de su tipo dinámico [Ort11b].

Respecto al análisis de los datos, hemos seguido la metodología propuesta en [GBE07] para la evaluación del rendimiento de maquinas virtuales que poseen compilación JIT. La metodo-logía define dos pasos para evaluar aplicaciones no servidoras:

Page 50: y V Taller de Programación Funcional (TPF)

Optimización de Lenguajes con Comprobación Estática y Dinámica de Tipos

Proc. PROLE 2013 7 / 15

1. Medimos el tiempo de ejecución resultante de ejecutar múltiples veces el mismo pro-grama. El resultado son p (tomamos p = 30) mediciones xi con 1 ≤ i ≤ p.

2. Se calcula el intervalo de confianza para un nivel de confianza dado (95%) para elimi-nar los errores de medición que pueden introducir una variación en la evaluación. El intervalo de confianza se calcula usando la distribución t de Student [Lilja2005]. Cal-culamos el intervalo de confianza [c1,c2] como:

1 ⁄ ;

√2

⁄ ;√

Siendo la media aritmética de las mediciones xi, α = 0.05 (95%), s la desviación típica de

las mediciones xi y t1-α/2;p-1 se define de tal forma que una variable aleatoria T, que sigue la dis-tribución t de Student con p -1 grados de libertad, cumple que Pr[T ≤ t1-α/2;p-1] = 1 – α / 2. El dato obtenido de cada medición es la media del intervalo de confianza y un porcentaje indi-cando la amplitud del intervalo de confianza relativo a la media.

Para cada benchmark hemos medido la diferencia entre el comienzo y el final de cada invo-cación, para obtener el tiempo de ejecución de cada benchmark. El consumo de memoria sigue la misma metodología, midiendo la memoria usada por todo el proceso (propiedad PeakWor-kingSet). Todos los test han sido ejecutados en un sistema Intel Core 2 Duo P7450 a 2,13Ghz con 4GB de memoria RAM ejecutando una versión actualizada de Windows 7 Home Premium Sp1.

3.2. Comprobación dinámica de tipos Hemos evaluado diferentes benchmarks con tipado dinámico, haciendo que todas las refe-

rencias del código fuente sean declaradas como dinámicas, sin usar ninguna declaración explí-cita de tipo. En las siguientes secciones utilizaremos código fuente con comprobación de tipos hibrida y declaración explícita de tipos, con el fin de medir y comparar distintos escenarios.

La Figura 2 muestra el tiempo medio de ejecución relativo a StaDyn de cada uno de los benchmarks evaluados. StaDyn presenta el mejor rendimiento en todos los test. Ejecutando el Pybench StaDyn es 4, 4, 12, 14, 45 y 74 veces más rápido que IronPython, C#, Boo, VB, Fan-tom y Cobra, respectivamente. La diferencia entre StaDyn y los demás lenguajes es debida a que en este benchmark se prueban características específicas de los lenguajes (como las opera-ciones aritméticas, invocación a métodos, manejo de listas, acceso a atributos, etc.) utilizando en todos los casos variables dinámicas. Mientras que StaDyn es capaz de inferir los tipos de la mayoría de las variables dinámicas en tiempo de compilación, los demás lenguajes utilizan reflexión para ejecutar las distintas operaciones. La diferencia entre C# y IronPython y el resto de lenguajes (Boo, VB, Fantom y Cobra) se debe a las optimizaciones implementadas por el DLR (empleado por estos dos lenguajes), que utiliza una caché para reducir la penalización del uso de reflexión.

Page 51: y V Taller de Programación Funcional (TPF)

ECEASST

8 / 15 2013

Figura 2: Tiempo de ejecución de los benchmarks con comprobación dinámica de tipos.

La ejecución de los test de JG.Section2 muestra importantes diferencias de rendimiento. StaDyn es 1,57 veces más rápido que el segundo que mejor rendimiento tiene (C#) y llega a ser 2,18 ordenes de magnitud más rápido que el peor de todos (Cobra). Todos los algoritmos de esta sección, a pesar de ser diferentes, utilizan las mismas características del lenguaje: gran cantidad de operaciones aritméticas y múltiples accesos a arrays usando variables declaradas como dinámicas. StaDyn infiere el tipo de casi todas las variables dinámicas y puede utilizar instrucciones específicas, por ejemplo, para acceder a los elementos de los arrays. No obstante, StaDyn no infiere información de tipos de los parámetros declarados como dinámicos [OZGPSG10]. En esos casos, al igual que los demás, usa reflexión en tiempo de ejecución. El resto de lenguajes usan reflexión en todos los casos, conllevando una importante penalización en el rendimiento.

En el caso de la aplicación JG.RayTracer (JG.Section3), las diferencias en el rendimiento son significativamente menores que en las otras aplicaciones. StaDyn es un 8%, 58%, 87%, 547%, 909% y 1.055% más rápido que Boo, C#, IronPython, Fantom, VB y Cobra, respecti-vamente. A lo largo de todo el código, hay múltiples invocaciones a métodos con parámetros declarados como dinámicos. Dado que en estos casos StaDyn no posee información de tipos para optimizar el código, el uso de reflexión causa un menor rendimiento. Sin embargo, StaDyn continúa siendo la implementación más rápida, debido al beneficio obtenido de la re-copilación de información de tipos de otras expresiones en el código. Los resultados obtenidos en la evaluación de esta aplicación real confirman los obtenidos en las evaluaciones prelimina-res [OZGPSG10], donde StaDyn presentaba el mejor rendimiento cuando no se infería ninguna información de tipos. El resultado del benchmark Pystone es similar al del JG.RayTracer, puesto que también utiliza gran cantidad de parámetros declarados como dinámicos. También se ha incluido en la Figura 2 la evaluación de una versión modificada de la aplicación Points [Ort11b]. Este código, originalmente hibrido, ha sido modificado en esta sección para que sea completamente dinámico. El resultado obtenido es similar al de los benchmarks JG.RayTracer y Pystone.

0

2

4

6

8

10

12

14

16

Pybench JG.Section2 JG.Section3 Pystone Points

Ex

ecu

tio

n T

ime

Re

lati

ve

to

Sta

Dy

n

StaDyn BOO Cobra C# Fantom IronPython VisualBasic

74

45 153 70 22

Page 52: y V Taller de Programación Funcional (TPF)

Optimización de Lenguajes con Comprobación Estática y Dinámica de Tipos

Proc. PROLE 2013 9 / 15

En cuanto al consumo de memoria, StaDyn presenta el menor consumo de memoria en to-das las pruebas. VB, Cobra, Boo, Fantom, C# y IronPython requieren 16%, 32%, 34%, 64%, 82% y 303% más memoria que StaDyn, respectivamente. Los lenguajes que mayor consumo de memoria presentan son los que hacen uso del DLR (C# y IronPython). Vemos pues cómo la mejora en el rendimiento ofrecida por el DLR también implica un mayor consumo de memo-ria. StaDyn, no obstante, ofrece un beneficio de rendimiento sin penalizar el consumo de me-moria.

3.3. Comprobación estática y dinámica de tipos Hemos modificado el código fuente de los benchmarks anteriores, declarado explícitamente el tipo de los atributos y los parámetros de los métodos. En el resto de los casos hemos usado tipado dinámico. Dado que el benchmark Pybench no tiene ni parámetros ni atributos de clase, no se ha incluido en esta evaluación. Tampoco hemos incluido IronPython, puesto que carece de comprobación estática de tipos.

La Figura 3 muestra los resultados de la evaluación de estos benchmarks, donde StaDyn presenta el mejor rendimiento en todos los programas. En la ejecución de los programas de JG.Section2, StaDyn es 3,3 veces más rápido que el segundo lenguaje con mejor rendimiento (C#) y 2,35 órdenes de magnitud que el que peor rendimiento presenta (Cobra). Esto es debido a que StaDyn infiere el tipo de las variables declaradas como dinámicas, y por lo tanto, genera código optimizado con la información estática de tipos inferida. En el caso de los arrays decla-rados como dinámicos, Boo y VB poseen operaciones especiales para su acceso (SetSlice y LateIndexSet respectivamente) incurriendo en una penalización menor que C#, Fantom y Cobra, que usan reflexión.

Figura 3: Tiempo de ejecución de los benchmarks con comprobación estática y dinámica de tipos.

Comparando estos resultados con los obtenidos utilizando solamente comprobación diná-mica de tipos (Figura 2), tanto Boo como VB reducen el tiempo de ejecución relativo a StaDyn (Boo pasa de 1.200% a 1.050% y VB de 2.200% a 1.000%), al contrario que C#, Fantom y Cobra cuya diferencia respecto a StaDyn es mayor con comprobación estática y dinámica de tipos (C# pasa de 150% a 325%, Fantom de 700% a 930% y Cobra de 1.530% a 2.260%). Es-

0

2

4

6

8

10

12

14

JG.Section2 JG.Section3 Pystone Points

Ex

ecu

tio

n T

ime

Re

lati

ve

to

Sta

Dy

n

StaDyn BOO Cobra C# Fantom VisualBasic

93 226 364 22 126 15 22 132 43 69

Page 53: y V Taller de Programación Funcional (TPF)

ECEASST

10 / 15 2013

tas diferencias se deben a que, usando comprobación híbrida, por un lado, StaDyn mejora su rendimiento dado que los tipos de los parámetros de los métodos son explícitamente declara-dos; pero, por otro lado, la declaración explícita de los tipos de los atributos no implica un be-neficio para StaDyn, ya que usando comprobación dinámica de tipos ya infería estos tipos. Pa-ra el resto de lenguajes, la declaración explícita de los tipos de los parámetros y atributos de clase implica una mejora en el rendimiento, que es más significativa para Boo y VB que para C#, Fantom y Cobra, debido a la forma que utilizan para acceder a los arrays declarados diná-micamente.

En la aplicación JG.RayTracer StaDyn presenta la mayor diferencia de rendimiento compa-rado con el resto de lenguajes, siendo 15, 21, 21, 126 y 364 veces más rápido que C#, Boo, VB, Fantom y Cobra, respectivamente. Esto se debe a que, al contrario que los demás lengua-jes, en StaDyn infiere el tipo de todas las variables var. Comparando estos datos con su ver-sión exclusivamente dinámica, el tiempo de ejecución de StaDyn es 128 veces más rápido, mientras que los demás mejoran entre 4 (Cobra) y 50 (VB) veces. Esto es debido a que la ver-sión dinámica presenta el peor escenario para StaDyn (gran cantidad de parámetros declarados como dinámicos), mientras que para la versión híbrida infiere el tipo de todas las variables var.

El resultado del benchmark Pystone es similar al de JG.Section2. StaDyn es aproximada-mente 7 veces más rápido que C# (el segundo mejor) y 2,1 órdenes de magnitud que Fantom (el de peor rendimiento). La comparación con la versión 100% dinámica de Pystone es similar al caso de JG.RayTracer: StaDyn infiere el tipo de todas las variables declaradas como dinámi-cas y su rendimiento mejora 20 veces, mientras que los demás lenguajes mejoran aproxima-damente 2.

En cuanto a la aplicación Points, a pesar de que StaDyn es el lenguaje con mejor rendimien-to, la diferencia con los demás lenguajes es mucho menor que en las otras pruebas presentadas en esta sección. El tiempo de ejecución de StaDyn es un 7% y 58% mejor que el de Boo y C# (segundos lenguajes con mejor rendimiento), respectivamente. Esto es debido a que en este programa, la mayoría de las variables declaradas como dinámicas son parámetros de métodos para los que StaDyn utiliza reflexión. Comparado con la versión dinámica, esta versión es un 15% más rápida.

En términos de consumo de memoria, StaDyn vuelve a ser el lenguaje que menos recursos consume, siendo un 21%, 43%, 48%, 93% y 93% menor que VB, Boo, Cobra, Fantom y C#, respectivamente.

Page 54: y V Taller de Programación Funcional (TPF)

Optimización de Lenguajes con Comprobación Estática y Dinámica de Tipos

Proc. PROLE 2013 11 / 15

3.4. Declaración explícita de tipos

Figura 4: Tiempo de ejecución de los benchmarks con declaración explícita de tipos.

En esta sección hemos evaluado código que únicamente posee declaración explícita, y por tan-to estática, de tipos. El principal objetivo de esta evaluación es comparar las optimizaciones que realiza cada compilador cuando no se usa ninguna declaración dinámica de tipos. Hemos modificado los benchmarks de tal forma que el tipo de todas las variables sea declara explíci-tamente. La aplicación Points no ha sido incluida en esta sección, dado que se diseñó para que no fuese posible implementarla sin usar variables dinámicas [Ort11b].

La Figura 4 muestra el tiempo medio de ejecución relativo a StaDyn de los benchmarks Ja-va Grande y Pystone. C# es el lenguaje más rápido en todas las pruebas, siendo un 2,5% más rápido que StaDyn, que es el segundo con mejor rendimiento. Este contraste muestra las dife-rencias entre las optimizaciones hechas por el compilador comercial de C# y StaDyn. Compa-rándolo con los otros lenguajes, StaDyn es, de media, un 24%, 48%, 243% y 335% más rápido que Cobra, VB, Boo y Fantom, respectivamente. Estos resultados son similares a los obtenidos en las evaluaciones preliminares previas [OZGPSG10].

En las aplicaciones de Java Grande, el rendimiento de Boo y Fantom es significativamente peor que el resto de lenguajes; de media requieren un 414% y 735% más de tiempo de ejecu-ción que StaDyn. Esta diferencia se debe a que tanto Boo como Fantom utilizan operaciones con tipos dinámicos, incluso cuando se utiliza declaración explícita de tipos.

El benchmark Pystone presenta una situación diferente, siendo el rendimiento de todos los lenguajes muy similar. Fantom, Cobra, VB, y Boo requieren un 13%, 25%, 27% y 53% más de tiempo de ejecución que StaDyn para ejecutar el Pystone. En esta aplicación, apenas se reali-zan accesos a arrays u otras operaciones que hagan que alguno de los lenguajes utilice sus pro-pias operaciones para ejecutarlas. De esta forma, todos utilizan las instrucciones IL estática-mente tipadas, y las diferencias de rendimiento se reducen considerablemente.

StaDyn y C# son los lenguajes con menor consumo de memoria en este tipo de programas, siendo prácticamente iguales (la diferencia es menor que el intervalo de error). VB, Boo, Co-bra y Fantom requieren un 17%, 43%, 59% y 95% más memoria que StaDyn.

0

2

4

6

8

10

JG.Section2 JG.Section3 Pystone

Ex

ecu

tio

n T

ime

Re

lati

ve

to

Sta

Dy

n

StaDyn BOO Cobra C# Fantom VisualBasic

Page 55: y V Taller de Programación Funcional (TPF)

ECEASST

12 / 15 2013

3.5. Influencia del tipado en el rendimiento La Figura 5 muestra la influencia de la comprobación dinámica, híbrida y estática en el tiempo de ejecución de cada uno de los lenguajes. Los valores en la Figura 4 son relativos al tiempo de ejecución de cada lenguaje para la declaración explícita (estática) de tipos. Por tanto, la fi-gura representa el coste de utilizar comprobación dinámica e híbrida de tipos, para cada len-guaje.

Figura 5: Influencia en el rendimiento de la comprobación dinámica de tipos.

StaDyn es el lenguaje que introduce la menor penalización en el rendimiento, al usar tanto comprobación dinámica como híbrida frente a la estática. Comparando la declaración explícita con la comprobación híbrida, el coste en StaDyn supone dos factores. En Boo, C#, VB, Fan-tom y Cobra este coste es de 7, 18, 36, 41 y 571 veces. La diferencia con StaDyn es que estos lenguajes no infieren información de tipos de las variables declaradas como dinámicas durante la compilación.

Por último, con StaDyn los programas con declaración explícita de tipos son 1.4 órdenes de magnitud más rápidos que con comprobación dinámica. Este valor es 1,5; 1,9; 2,2; 2,5 y 3,3 órdenes de magnitud para Boo, C#, Fantom, VB y Cobra, respectivamente.

4 Trabajo Relacionado Dado que tanto la comprobación dinámica como estática de tipos ofrecen distintos benefi-

cios, existen diversos trabajos enfocados a obtener las ventajas de ambos. Uno de los primeros trabajos en este campo fue Soft Typing [CF91], que propone añadir comprobación estática de tipos a un lenguaje dinámico como Scheme. La aproximación propuesta en [ACPP91] añade un tipo Dynamic al cálculo lambda, incluyendo dos operaciones de conversión (dynamic and typecase), generando un código prolijo y altamente dependiente de su dinamismo.

Los trabajos presentados en Quasi-Static Typing [Tha90], Hybrid Typing [FFT06] and Gradual Typing [ST07] realizan la conversión implícita entre código dinámico y estático, em-pleando relaciones de subtipado en los dos primeros, y una relación de consistencia en el últi-

0

20

40

60

80

100

StaDyn Boo Cobra C# Fantom VisualBasic

Ex

ecu

tio

n T

ime

Re

lati

ve

to

Sta

tic

Ty

pin

g

Static Hybrid Dynamic

2147 572 339 175

Page 56: y V Taller de Programación Funcional (TPF)

Optimización de Lenguajes con Comprobación Estática y Dinámica de Tipos

Proc. PROLE 2013 13 / 15

mo. El trabajo Gradual Typing propone, al igual que StaDyn, la resolución de restricciones mediante unificación para integrar la comprobación estática y dinámica de tipos [SV08].

Las implementaciones de lenguajes de programación como Boo, Visual Basic (VB) .NET, Cobra, Dylan, Strongtalk, y C# 4.0 han incluido parte de trabajos teóricos que combinan com-probación de tipos estática y dinámica [BMT10]. Algunos lenguajes de programación han se-guido el enfoque de añadir un nuevo tipo dinámico [ACPP91] (dynamic en C# y Cobra, y duck en Boo), mientras que otros representan los tipos dinámicos eliminando los tipos en la declaración de las variables (VB y Dylan) [Vic07]. Strongtalk sigue un enfoque completamente diferente basado en el concepto de sistema de tipos intercambiable (pluggable) [Bra04]. En este lenguaje, los tipos dinámicos son implícitamente forzados a tipos estáticos siguiendo el enfoque descrito en [Tha90] y [ST07], contrariamente al uso de una instrucción explícita para la conversión como se propone en [ACPP91]. Dado que estas conversiones implícitas pueden fallar en tiempo de ejecución, se introduce una verificación dinámica de tipo en el código ge-nerado [FFT06].

También existen trabajos enfocados a realizar inferencia de tipos estática en lenguajes con comprobación dinámica, descubriendo errores de tipo antes de la ejecución de un programa. Diamondback Ruby (DRuby) es una herramienta que combina el sistema de tipos dinámico de Ruby con un método de comprobación estática de tipos [FAFH09]. Anderson, Giannini y Drossopoulou formalizaron un subconjunto de JavaScript (JS0), definiendo un algoritmo de inferencia de tipos que es parecido a un sistema de tipos [AGD05]. Ninguno de estos trabajos (DRuby and JS0) usa la información de tipos estática inferida para generar código optimizado.

5 Conclusiones El lenguaje de programación StaDyn muestra cómo la obtención de información de tipos en lenguajes con comprobación híbrida puede ser utilizada para realizar importantes optimizacio-nes de rendimiento sin incurrir en un consumo adicional de memoria. StaDyn realiza la infe-rencia y comprobación de tipos incluso sobre referencias declaradas como dinámicas, ofre-ciendo el nivel de flexibilidad de los lenguajes dinámicos, y manteniendo la eficiencia y robus-tez de los lenguajes con comprobación estática de tipos.

Hemos comparado el rendimiento y consumo de memoria de StaDyn con los lenguajes hí-bridos existentes sobre el .NET Framework, utilizando un amplio conjunto de benchmarks. StaDyn ha mostrado el mejor rendimiento en todos los programas que usan alguna referencia dinámica, siendo al menos 1,2 veces más rápido ejecutando código dinámico y 5 veces con código hibrido.

El trabajo futuro más inmediato es realizar especialización de funciones con la información de tipos de los parámetros. Los resultados obtenidos de esta evaluación indican que esta mejo-ra podría significar mayores optimizaciones en el rendimiento del lenguaje. La versión actual del lenguaje de programación StaDyn y su código fuente está disponible en: http://www.reflection.uniovi.es/stadyn

Bibliografía [ACPP91] M. Abadi, L. Cardelli, B. C. Pierce, G. Plotkin. Dynamic typing in a statically

typed language. ACM Transactions on Programming Languages and Systems, 13(2):237–268, 1991.

Page 57: y V Taller de Programación Funcional (TPF)

ECEASST

14 / 15 2013

[AGD05] C. Anderson, P. Giannini, S. Drossopoulou. Towards type inference for JavaS-cript. In Proceedings of the European Conference on Object-Oriented Pro-gramming (ECOOP), pages 428–452, Glasgow, UK, 9-11. Springer, June 2005.

[BMT10] G. Bierman, E. Meijer, M. Torgersen. Adding dynamic types to C#. In Pro-ceedings of the 24th European Conference on Object-Oriented Programming (ECOOP), pages 76–100, Maribor, Slovenia, 21-25. Springer-Verlag, June 2010.

[Bra04] G. Bracha. Pluggable Type Systems. In Proceedings of the OOPSLA 2004 Workshop on Revival of Dynamic Languages, Vancouver, Canada, October. ACM, 2004.

[Cas] Castle Project. Brail View Engine. http://old.castleproject.org/monorail/documentation/trunk/viewengines/brail/index.html

[CF91] R. Cartwright, M. Fagan. Soft Typing. In Proceedings of the Conference on Programming Language Design and Implementation (PLDI), pages 278–292, Toronto, Canada, 26-28. ACM, June 1991.

[Cor] Microsoft Corporation. The C# Programming Language. http://download.microsoft.com/download/3/8/8/388e7205-bc10-4226-b2a8-75351c669b09/csharp%20language%20specification.doc.

[CT] B. Chiles, A. Turner. Dynamic Language Runtime. http://www.codeplex.com/Download?ProjectName=dlr&DownloadId=127512

[FAFH09] M. Furr, J. D. An, J. S. Foster, M. Hicks. Static type inference for Ruby. In Proceedings of the ACM symposium on Applied Computing (SAC), pages 1859–1866, Honolulu, Hawaii, 9-12. ACM, March 2009.

[FF12] B. Frank, A. Frank. Fantom, the language formerly known as Fan. http://fantom.org, 2012.

[FFT06] C. Flanagan, S. N. Freund, A. Tomb. Hybrid types, invariants, and refinements for imperative objects. In Proceedings of the International Workshop on Foundations and Developments of Object-Oriented Languages (FOOL), San Antonio, Texas. ACM, January 2006.

[GBE07] A. Georges, D. Buytaert, L. Eeckhout. Statistically rigorous java performance evaluation. ACM SIGPLAN Notices, 42(10):57–76, 2007.

[HT99] A. Hunt, D. Thomas. The pragmatic programmer: from journeyman to master. Addison-Wesley Longman Publishing Co., Inc., Boston, Massachusetts, 1999.

[Iro] IronPython. The IronPython programming language. http://ironpython.net/. [Kri12] C. Krintz. A collection of phoenix-compatible C# benchmarks.

http://www.cs.ucsb.edu/~ckrintz/racelab/PhxCSBenchmarks, 2012. [MD04] E. Meijer, P. Drayton. Static typing where possible dynamic typing when

needed: The end of the cold war between programming languages. In Proceed-ings of the OOPSLA Workshop on Revival of Dynamic Languages, Vancouver, Canada, 24-28. ACM, October 2004.

[Mil78] R. Milner. A theory of type polymorphism in programming. Journal of Com-puter and System Sciences, 17:348–375, 1978.

[Mon] MonoDevelop. http://monodevelop.com/ [Oli] R. B. De Oliveira. The Boo programming language. http://boo.codehaus.org.

Page 58: y V Taller de Programación Funcional (TPF)

Optimización de Lenguajes con Comprobación Estática y Dinámica de Tipos

Proc. PROLE 2013 15 / 15

[OM11] F. Ortin, A. Morant. Ide support to facilitate the transition from rapid prototyp-ing to robust software production. In Proceedings of the 1st Workshop on De-veloping Tools as Plug-ins, TOPI ’11, pages 40–43, New York, NY, USA. ACM, 2011.

[OMGDG12] F. Ortin, S. Mendez, V. Garcia-Diaz, M. Garcia. On the suitability of dynamic languages for hot-reprogramming a robotics framework: a python case study. Software Practice and Experience, To be published; accepted on October, 2012.

[Ort] F. Ortin. The StaDyn programming language. http://www.reflection.uniovi.es/-stadyn.

[Ort11a] F. Ortin, M. Garcia. Union and intersection types to support both dynamic and static typing. Information Processing Letters, 111(6):278–286, 2011.

[Ort11b] F. Ortin. Type inference to optimize a hybrid statically and dynamically typed language. Computer Journal, 54(11):1901–1924, November 2011.

[OSW97] M. Odersky, M. Sulzmann, M. Wehr. Type inference with constrained types. In Fourth International Workshop on Foundations of Object-Oriented Pro-gramming (FOOL), 1997.

[OZGPSG10] F. Ortin, D. Zapico, J. B. Garcia Perez-Schofield, M. Garcia. Including both static and dynamic typing in the same programming language. IET Software, 4(4):268–282, 2010.

[Pie92] B. C. Pierce. Programming with intersection types and bounded polymor-phism. Technical Report CMU-CS-91-106, School of Computer Science, Pittsburgh, PA, USA, 1992.

[Rah10] A. Rahien. DSLs in Boo: Domain Specific Languages in. NET. Manning Pub-lications Co, 2010.

[SFM+96] J. Siegel, D. Frantz, H. Mirsky, R. Hudli, P. de Jong, A. Klein, B. Wilkins, A. Thomas, W. Coles, S. Baker, M. Balick. COBRA fundamentals and program-ming. John Wiley & Sons, Inc., New York, NY, USA, 1996.

[ST07] J. G. Siek, W. Taha. Gradual typing for objects. In Proceedings of the 21st European Conference on Object-Oriented Programming (ECOOP), pages 2–27, Berlin, Germany. Springer-Verlag, 30 July - 3 August 2007.

[Sun] Sun Microsystems. JSR 292, supporting dynamically typed languages on the java platform. http://www.jcp.org/en/jsr/detail?id=292.

[SV08] J. G. Siek, M. Vachharajani. Gradual typing with unification-based inference. In Proceedings of the Dynamic Languages Symposium, pages 7:1–7:12, Pa-phos, Cyprus. ACM, 25 July 2008.

[Tha90] S. Thatte. Quasi-static typing. In Proceedings of the 17th symposium on Prin-ciples of programming languages (POPL), pages 367–381, San Francisco, California, United States. ACM, January 1990.

[THS+05] D. Thomas, D. H. Hansson, A. Schwarz, T. Fuchs, L. Breedt, M. Clark. Agile Web Development with Rails. A Pragmatic Guide. Pragmatic Bookshelf, Ra-leigh, North Carolina, 2005.

[Uni] Unity Technologies. Unity3D. http://unity3d.com/ [Vic07] P. Vick. The Microsoft Visual Basic Language Specification. Microsoft Corpo-

ration, Redmond, Washington, 2007.

Page 59: y V Taller de Programación Funcional (TPF)

Sesión 2: Testing

59

Page 60: y V Taller de Programación Funcional (TPF)

Sesión 2: Testing

11.00–11.30 Macías López, Henrique Ferreiro, Miguel Á. Francisco, andLaura M. Castro: Automatización de Pruebas para Servi-cios Web: Generación de Propiedades y Modelos

11.30–12.00 Pedro Delgado-Pérez, Inmaculada Medina-Bulo, Juan JoséDomínguez-Jiménez, and Antonio García-Domínguez: Op-eradores de Mutación a Nivel de Clase para el LenguajeC++

12.00–12.30 Clara Benac Earle and Lars-Åke Fredlund: Testing Javawith QuickCheck

60

Page 61: y V Taller de Programación Funcional (TPF)

Automatizacion de Pruebas para Servicios Web: Generacion dePropiedades y Modelos*

Macıas Lopez1, Henrique Ferreiro1, Miguel A. Francisco2, Laura M. Castro1

MADS Group, University of A Coruna (Spain)1, Interoud Innovation S.L. (Spain)2

Abstract: Los servicios web son una solucion muy extendida a la hora de integrarcomponentes durante la construccion de una aplicacion o sistema software, ası comopara facilitar la comunicacion entre diferentes sistemas, ya que proporcionan unmecanismo para acceder a sus funcionalidades suficientemente flexible como parafavorecer la maxima reutilizacion.

Para que dicha integracion tenga exito, son esenciales las tareas de prueba, algo alo que los servicios web no son ajenos: al igual que en cualquier otro desarrollode software, es imperativo validar su comportamiento y garantizar su calidad tantocomo sea posible, de la manera mas eficiente posible. En la practica, el compromisoentre el esfuerzo y el costo conduce con demasiada frecuencia al desarrollo de suitesde prueba de menor tamano y menor alcance de lo que serıa deseable.

En este trabajo presentamos un framework para la realizacion de pruebas a serviciosweb a partir de su especificacion escrita en WSDL y sus restricciones de negocioescritas en OCL, que sigue un enfoque de caja negra y utiliza pruebas basadas enpropiedades. Esta combinacion de estrategias nos permite afrontar el problema dela generacion de suites de prueba y casos de prueba de mejor calidad mediante suderivacion automatica a partir de la descripcion formal de los servicios web.

Para ilustrar las ventajas de nuestro framework, presentamos un caso de estudio real:un servidor de contenidos multimedia distribuido.

Keywords: pruebas basadas en propiedades, servicios web, WSDL, OCL

1. Introduccion

A medida que Internet crece en importancia en nuestra sociedad, la necesidad de facilitar el ac-ceso a diferentes tipos de sistemas a traves de la web se ha vuelto mas importante que nunca. Laforma habitual de hacerlo es a traves de servicios web, cuyo objetivo es proporcionar un mediopara interaccion entre componenes software o sistemas, o entre sistemas y usuarios finales. Haymultiples maneras de describir estas interacciones, siendo una de las mas comunmente utilizadasWSDL (Web Services Description Language) [W3C01], un lenguaje basado en XML para es-pecificar las operaciones que ofrece un servicio web. El estandar WSDL opera a nivel sintacticoy no hay una manera de representar los requisitos o condiciones de funcionamiento del servicioweb simplemente utilizando la informacion en WSDL. Por lo tanto, con el fin de anadir infor-macion semantica a la descripcion del servicio web, la descripcion WSDL debe completarse con

∗ Trabajo parcialmente financiado gracias a FP7-ICT-2011-8 Ref. 317820.

Automatizacion de Pruebas para Servicios Web 1 / 15

Page 62: y V Taller de Programación Funcional (TPF)

anotaciones semanticas que expresan condiciones previas, postcondiciones y los efectos de ca-da invocacion de servicio. Se han propuesto una serie de opciones para hacer esto, tales comoWSDL-S (Web Services Semantics) [W3C05], SWRL (Semantic Web Rule Language) [W3Cb],u OCL (Object Constraint Language) [OMG12].

Para garantizar la calidad de un servicio web [Emm06], es necesario garantizar que las opera-ciones funcionan tal y como indica su especificacion, esto es, que la informacion semantica no seviola. Basandonos en trabajos previos [FC12], que utilizan descripciones UML junto con restric-ciones OCL para realizar pruebas automaticas de componentes de software, proponemos aplicarpruebas basadas en propiedades (PBT) [DWA+10] para pruebas automaticas de servicios web.PBT se basa en la utilizacion de propiedades que el sistema a probar (SUT) necesita satisfacer, enlugar de casos de prueba individuales. A partir de propiedades, diferentes herramientas puedengenerar esos casos de prueba especıficos automaticamente. Usando la tecnica que proponemos,es posible utilizar una aproximacion de caja negra para describir el comportamiento funcionaldel SUT y utilizar esta especificacion para generar propiedades para la realizacion de pruebas. Enparticular, dada una descripcion WSDL de un servicio web y su definicion semantica en OCL,podemos generar esas propiedades en lugar de escribirlas manualmente.

En este artıculo explicamos como se ha desarrollado esta propuesta. Como caso de estudio,hemos utilizado VoDKATV, un middleware IPTV/OTT que proporciona una experiencia multi-media avanzada a los usuarios finales, como es el acceso a vıdeo bajo demanda, o servicios denavegacion por Internet. La seccion 2 describe el estado del arte, introduciendo los conceptos enlos que se fundamenta nuestro trabajo y un analisis de diferentes enfoques que podrıan utilizarsepara probar servicios web. La seccion 3 explica la arquitectura de nuestro framework, describesus componentes y como interactuan. La seccion 4 presenta informacion detallada sobre VoD-KATV, sus principales componentes y el servicio web especıfico que hemos seleccionado comoterreno de prueba. Por ultimo, en la seccion 5 se presentan las conclusiones y trabajos futuros.

2. Background

2.1. WSDL WSDL-S y OCL

Un servicio web es un componente software modular y bien definido que ofrece una APIque se accede a traves de la red, tıpicamente, Internet. Las aplicaciones utilizan los serviciosweb mediante el envıo y recepcion de mensajes escritos en un formato estandarizado, comoXML [W3Ca] o JSON [Cro06]. Gracias a la utilizacion de formatos estandar y comunicacionesHTTP, los servicios web permiten la cooperacion de sistemas independientemente de sus carac-terısticas tecnologicas especıficas, ası como la integracion de componentes en sistemas grandes.

WSDL es un lenguaje basado en XML para la definicion de servicios web en terminos deoperaciones, entradas, salidas, mensajes, tipos de datos, ası como protocolos especıficos parael acceso a los servicios. Con poco esfuerzo podemos transformar las especificaciones WSDLen implementaciones en casi cualquier lenguaje de programacion para realizar llamadas a di-cho servicio web. Algunas de las herramientas de transformacion mas utilizadas son ApacheCXF [Apab] o Apache Axis2 [Apaa] para Java, y podemos encontrarlas incluso integradas enconocidos IDEs, como Eclipse [Ecl]. WSDL se considera, pues, ampliamente aceptado en laindustria como estandar para la descripcion de servicios web.

Automatizacion de Pruebas para Servicios Web 2 / 15

Page 63: y V Taller de Programación Funcional (TPF)

Los servicios web semanticos pueden enriquecerse con la descripcion semantica de su com-portamiento. Las descripciones semanticas se expresan con ontologıas, una conceptualizacionformal de un dominio particular. La descripcion se crea usando componentes de ese dominioy expresando sus relaciones. WSDL-S tiene como objetivo anadir este tipo de informacion alos servicios web, extiendendo el lenguaje de especificacion WSDL y permitiendo busquedaautomatica, descubrimiento, seleccion, composicion e integracion entre servicios de dominiosheterogeneos. En nuestra propuesta, utilizamos el atributo modelReference que WSDL-Sagrega a efectos de anotacion; este atributo define la asociacion entre una entidad WSDL y unconcepto (externo) que describe su semantica. Gracias a este atributo, mantendremos la descrip-cion WSDL y OCL por separado, por lo que cambios en una no afectaran a la otra.

Utilizaremos OCL para expresar estos conceptos. OCL es un lenguaje formal usado para larepresentacion de condiciones en modelos UML. Estas condiciones pueden ser invariantes delsistema que se esta modelando, o consultas sobre los objetos descritos en el modelo. Un aspectoimportante de restricciones OCL es que no tienen efectos secundarios: la evaluacion de una ex-presion OCL no cambia el estado del modelo. Utilizaremos OCL para describir precondicionesy postcondiciones de las operaciones incluidas en la especificacion WSDL de un servicio web.

2.2. Pruebas de servicios web

La mayor parte de los trabajos publicados sobre pruebas de servicios web presentan meto-dos para crear buenos conjuntos de pruebas, desde una perspectiva de caja negra. Ejemplos deesto son [AAM10], donde los autores utilizan la tecnica de matriz ortogonal (OAT), el meto-do de pares definido por [NS09], y la tecnica de particion de [BLTC08]. Algunas propuestasconstruyen artefactos intermedios para ayudar en el proceso, como por ejemplo [ZZK07], queconstruye un automata finito usando BPEL, o [TG07] que combina UML y OCL.

En [BBMP09] se presenta un marco completo para realizar pruebas a partir de una especifi-cacion WSDL, donde los casos de prueba se generan utilizando un criterio de cobertura y algunasheurısticas. Esta solucion tambien se utiliza en [BIPT09], donde la informacion acerca de comolos clientes deben interactuar con el servicio web se infiere. El trabajo previo mas proximo anuestra propuesta, en la que la informacion semantica se suministra en SWRL [W3Cb] en lugarde OCL, es [NS08]. En todos estos enfoques, no obstante, hay una manifiesta falta de automati-zacion en diferentes momentos del proceso de prueba.

Por ultimo, [Lam12] presenta uno de los pocos enfoques totalmente automaticos, en el que seutiliza una herramienta de PBT, pero no se utiliza informacion semantica, por lo que las pruebasse mantienen en el nivel sintactico.

2.3. Pruebas basadas en propiedades usando QuickCheck

Como alternativa a la produccion de las pruebas de forma manual a partir de una especificacionde alto nivel en lenguaje natural, o para escribir un modelo formal para describir un sistemao componente, la PBT utiliza sentencias declarativas para especificar las propiedades que elsoftware debe satisfacer de acuerdo con su especificacion. Con este enfoque, los casos de pruebapueden entonces ser generados a partir de las propiedades, un proceso que se puede automatizar,lo que permite ejecutar un gran numero pruebas para cada propiedad, aumentando la eficacia delproceso de prueba.

Automatizacion de Pruebas para Servicios Web 3 / 15

Page 64: y V Taller de Programación Funcional (TPF)

En nuestro trabajo, hemos utilizado QuickCheck, una herramienta de PBT que automatizala generacion, ejecucion y evaluacion de casos de prueba. QuickCheck originalmente fue de-sarrollada por Claessen y Hughes para el lenguaje Haskell [CH00] y re-disenado, mejorado ycomercializado por Quviq AB para Erlang [AH03]. Quviq QuickCheck1 proporciona generaciony ejecucion de casos de prueba, permitiendo ejecutar una gran cantidad de pruebas con muy pocoesfuerzo, para comprobar si los componentes cumplen dichas propiedades.

Para probar sistemas complejos, sin embargo, las propiedades aisladas no son suficientementeexpresivas. Para este tipo de situaciones, en lugar de secuencias de casos de prueba independien-tes, necesitamos secuencias de llamadas que modifican el estado del servicio, y comprobacionesde que las condiciones se cumplen antes y despues de cada interaccion, ası como que el estadoglobal del servicio sigue siendo coherente con su comportamiento esperado despues de cadallamada. Sistemas de almacenamiento en la nube a los que se accede a traves de servicios webson ejemplos de este tipo de sistemas.

En este trabajo se generaran de forma automatica, a partir de WSDL y OCL, tanto propiedadesaisladas como modelos de maquinas de estado, en funcion de si el SUT es un sistema sin estadoo un sistema con estado.

3. Transformando WSDL + OCL en propiedades

Los requisitos de un sistema representan las necesidades que debe cubrir, que son, por lo gene-ral, especificadas de manera abstracta, sin entrar en detalles de implementacion. El uso de PBTpara probar los servicios web que puedan implementar una especificacion WSDL dada, requieredescribir esos requisitos en forma de propiedades que describan los requisitos del SUT. Paraello, se obtiene informacion tanto del WSDL como de las restricciones en OCL (precondicionesy postcondiciones de cada operacion), y la combinacion de ambos nos permite construir nuestromodelo de prueba, compuesto por un conjunto de propiedades. Dependiendo de las necesidadesdel servicio web, el modelo de prueba puede ser diferente: para los servicios web sin estado, segeneran propiedades universalmente cuantificadas; para los servicios web con estado, los requi-sitos se modelan utilizando una maquina de estados.

Tanto a partir de las propiedades como del modelo de maquina de estados del servico web,QuickCheck es capaz de generar casos de prueba concretos y, a continuacion, nuestro frameworkutiliza un adaptador HTTP (generado tambien a partir de la especificacion WSDL) para ejecu-tarlos directamente contra el SUT. Por lo tanto, para emplear este framework no necesitamosconocer los detalles tecnicos del lenguaje de implementacion de un servicio web determinado.Ademas, si se conserva la misma API, distintas implementaciones de un servicio web se puedeprobar con las mismas propiedades y/o modelo.

La arquitectura general de nuestro framework se muestra en la figura 1. En primer lugar,utilizamos la informacion del archivo WSDL, extraıda a traves de un parser WSDL. Por ejem-plo, a continuacion se muestra un extracto de un archivo WSDL que describe un servicio webque proporciona una operacion pow (wsdl:interface) que recibe como parametros GET(wsdl:binding) un entero a y un entero positivo b (pow de wsdl:types), y devuelve otroentero como resultado (powResponse de wsdl:types):

1 De ahora en adelante, nos referiremos a Quviq QuickCheck simplemente como ‘QuickCheck’.

Automatizacion de Pruebas para Servicios Web 4 / 15

Page 65: y V Taller de Programación Funcional (TPF)

WSDLparser

WSDLfile

OCLconstraints

Type information(data + services)

OCLparser

QuickCheckproperties/model

Semantic information(services)

SUT

testcases adapter

Figura 1: Arquitectura de prueba propuesta

<wsdl:types><xs:schema ...><xs:element name="pow">

<xs:complexType><xs:sequence><xs:element minOcurs="0" name="a" type="xs:int" /><xs:element minOcurs="0" name="b" type="xs:positiveInteger" />

</xs:sequence></xs:complexType>

</xs:element><xs:element name="powResponse"><xs:complexType><xs:sequence><xs:element minOccurs="0" name="return" type="xs:int" />

</xs:sequence></xs:complexType>

</xs:element>...

</xs:schema></wsdl:types>

<wsdl:interface name="MathUtilsInterface"><wsdl:operation name="pow">

<wsdl:input element="msg:powParams"/><wsdl:output element="msg:powResponse"/><wssem:modelReference="powConstraints"/>

</wsdl:operation></wsdl:interface>

Automatizacion de Pruebas para Servicios Web 5 / 15

Page 66: y V Taller de Programación Funcional (TPF)

<wsdl:binding name="MathUtilsHTTPBinding"type="http://www.w3.org/ns/wsdl/http"interface="tns:MathUtilsInterface"><wsdl:operation ref="tns:pow" whttp:method="GET" whttp:location="pow" />

</wsdl:binding>

<wsdl:service name="MathUtils" interface="tns:MathUtilsInterface"><wsdl:endpoint name="MathUtilsHTTPEndpoint"binding="tns:MathUtilsHTTPBinding"address="http://localhost:8080/mathUtils/">

</wsdl:endpoint></wsdl:service>

A partir de este ejemplo, nuestro parser debe analizar diferentes etiquetas como el nombre delservicio (etiqueta service), el atributo WSDL-S modelReference que apunta al archivoOCL, la URL (address) de cada operacion (operation) del servicio (binding), etc.

En el ejemplo anterior, el WSDL hace referencia a un archivo powConstraints que des-cribe la semantica de las operaciones descritas en el WSDL, expresando las precondiciones ypostcondiciones de cada operacion. Por ejemplo, dicha especificacion podrıa indicar que el re-sultado de la operacion pow se obtiene multiplicando el entero a por sı mismo b veces. Estopuede ser expresado en OCL con el siguiente codigo, el cual describe una postcondicion (post)en donde se usa la operacion iterate que se encarga de iterar a traves de todos los elementosde una lista, en este caso una secuencia de b elementos (Sequence1..b), y comprueba queel resultado final sea igual a la multiplicacion del elemento a por sı mismo tantas veces comoelementos tenga dicha secuencia, es decir, b veces:

context MathUtils::pow(a: Integer, b: UnlimitedNatural): Integerpost: result = Sequence1..b->iterate(i : Integer; acc : Integer = 1 | acc*a)

Este archivo OCL tambien es analizado por nuestra herramienta, comprobando si hay infor-macion semantica asociada a cualquiera de las operaciones recuperadas en el paso anterior. Porultimo, recuperada la informacion requerida de los archivos WSDL y OCL, es el momento deconstruir las propiedades a partir de las que QuickCheck va a generar los casos de prueba.

Con respecto a los parsers de WSDL y OCL, hemos preferido hacer nuestras propias imple-mentaciones. Decidimos implementar nuestro propio parser de WSDL porque necesitamos inte-grar el resultado con la informacion semantica proporcionada en forma de restricciones OCL,como paso previo a la generacion de propiedades. Por otro lado, tambien existen diferentesherramientas para tratar ficheros OCL, pero en la practica totalidad de los casos, su analisistiene que ser realizado asociado a un modelo UML. Esto nos ha llevado nuevamente a desarrol-lar nuestro propio parser OCL, aprovechando parcialmente el trabajo realizado por el proyectoOCLNL [ocl]: una gramatica BNF etiquetada [FR03] para OCL. Utilizamos esta gramatica jun-to con una herramienta de generacion de compiladores (BNFC) [bnf] para construir el arbol desintaxis abstracta, el analizador lexico y el parser.

3.1. Servicios web sin estado

Los servicios o sistemas sin estado no tienen un estado interno que se vea afectado por elresultado de una secuencia de llamadas a su API, por lo que la respuesta devuelta por una llamada

Automatizacion de Pruebas para Servicios Web 6 / 15

Page 67: y V Taller de Programación Funcional (TPF)

especıfica es independiente del momento concreto en que se ejecuta. En este caso, el nombre dela operacion que se quiere probar y el tipo de su resultado y los argumentos que se recuperan delarchivo WSDL son suficientes para construir las pruebas, siendo las restricciones especificadasen el archivo OCL utilizadas como oraculo de dichas pruebas.

El ejemplo WSDL del apartado anterior describe el servicio web MathUtils, que ofrece laoperacion pow con una postcondicion especificada en el archivo de OCL. Con esa informacion,nuestra herramienta genera automaticamente la siguiente propiedad:

prop_pow() ->?FORALL(A, B, ocl_gen:int(), ocl_gen:nat(),

beginmathUtils:pow(A, B) == ocl_seq:iterate(fun(I, Acc) -> Acc * A end,

1, ocl_seq:new(1, B))end).

Esta propiedad es utilizada por QuickCheck para generar casos de prueba especıficos. Ası,cada par de numero entero (ocl gen:int()) y numero natural (ocl gen:nat()) que segenera (A, B), se utiliza como parametros para la funcion mathUtils:pow/2, la cualrealiza la llamada a la operacion pow proporcionada por el SUT, gracias al adaptador HTTP:

pow(Arg1, Arg2) ->inets:start(),Req = httpc:request("http://localhost:8080/mathUtils/pow?a=" ++ Arg1 ++ "&b=" ++ Arg2),case Req of

ok, Version, 200, Reason, Headers, Result -> list_to_float(Result);Other -> "Unknown error"

end.

Este adaptador realiza la peticion a la URL concreta utilizando la funcion httpc:request/1,donde la URL del servicio web se obtiene del archivo WSDL, y devuelve el resultado obtenido.El valor devuelto por el servicio web es finalmente contrastado, como parte de la propiedad, conrespecto a la postcondicion especificada en el archivo OCL. Para ello, se han creado modulosErlang, como ocl_seq, que implementan cada una de las operaciones disponibles en OCL,como iterate, los cuales se usan en la propiedad generada prop_pow.

En general, la propiedad generada que pruebe que una operacion f que recibe unos parametrosP, y que lleva asociada una precondicion pre, cumple una postcondicion post, es la siguiente:

?FORALL(P, ?SUCHTHAT(P, G(), pre(P)), begin R = f(P), post(P, R) end).

la cual sera usada por QuickCheck para generar datos aleatorios que cumplan las precondiciones,se ejecute la funcion a probar (usando el adaptador HTTP), y se compruebe si la postcondicionespecificada se cumple.

La mayor diferencia entre PBT y los metodos de prueba en los que los datos de entrada seespecifican manualmente es el uso de generadores. QuickCheck incorpora una biblioteca degeneradores de datos basicos (enteros, strings, listas, etc.) a partir de los cuales pueden cons-truirse otros mas complejos. Utilizando esta librerıa basica de QuickCheck, nuestro frameworkproporciona generadores para todos los tipos soportados por OCL, y usa esos generadores paraconstruir generadores de tipos complejos en caso de ser necesario [FC12]. Este enfoque conducea una mejora significativa respecto a las pruebas tradicionales [Pet07] y respecto a la mayorıa

Automatizacion de Pruebas para Servicios Web 7 / 15

Page 68: y V Taller de Programación Funcional (TPF)

de los trabajos mencionados en la seccion 2.2, ya que en lugar de valores concretos, definimostipos, rangos, y condiciones que los datos de entrada tienen que cumplir, y que son ası generadosautomaticamente en lugar de escritos manualmente.

QuickCheck no solo puede generar una gran cantidad de pruebas concretas derivadas de laspropiedades, y ejecutarlas contra el SUT. Otra caracterıstica clave de QuickCheck es su capaci-dad de, cuando se encuentra un caso de prueba que falla, reducirlo de forma automatica a uncontraejemplo equivalente mas pequeno, de manera que resulte mas facil de depurar la razon delfallo. Siguiendo con el ejemplo anterior, se ejecuta la propiedad prop pow, obtenemos:> Testing property: pow...................................................Failed! After 52 tests.-13,16Shrinking..(2 times)13,15

que representa la ejecucion de 52 pruebas hasta que se revela una incoherencia entre la propiedady el comportamiento real del servicio web, en concreto, cuando el parametro a es 13, y b es 16(1316). En este caso, el fallo es el conocido error de redondeo de los flotantes, como apareceexplicado en [ACH08]. Ante un error, debemos determinar si es necesario ajustar la propiedad,o bien corregir el SUT.

3.2. Servicios web con estado

En contraposicion a los componentes sin estado donde cada accion es independiente entre sı,muchos sistemas tienen un comportamiento que depende de las acciones anteriores.

Con el fin de probar estos sistemas, el estado interno tiene que ser tomado en cuenta en el pro-ceso de prueba. QuickCheck tiene soporte para pruebas de este tipo de sistemas mediante el usode maquinas de estados. En lugar de especificar propiedades generales, se especifica una unicapropiedad concreta: dada cualquier secuencia de comandos invocados sobre el servicio web,siempre que satisfagan las precondiciones indicadas, sus resultados conformaran las respectivaspostcondiciones (figura 2):

?FORALL(Commands, commands(StatemModel),ok = run_commands(StatemModel, Commands)).

donde StatemModel se construye en QuickCheck mediante la implementacion de una serie decallbacks que permiten especificar la lista de comandos de interes (funcionalidades del servicioweb a probar), las precondiciones y postcondiciones para verificar el estado del sistema tras cadainteraccion, y la informacion que se necesita mantener en el estado interno de la prueba.

Las pruebas consisten entonces en secuencias generadas al azar a partir de las posibles tran-siciones definidas para cada estado [AHJW06]. Nuestro caso de estudio, que procedemos a ex-plicar en la siguiente seccion, entra en esta segunda categorıa de servicios web con estado.

4. Caso de estudio: VoDKATV

4.1. Arquitectura de VoDKATV

VoDKATV es un middleware IPTV/OTT que proporciona a los usuarios finales acceso a dife-rentes servicios en una pantalla de TV, tablet, smartphone, PC, etc., lo que permite un avanzada

Automatizacion de Pruebas para Servicios Web 8 / 15

Page 69: y V Taller de Programación Funcional (TPF)

Figura 2: Pruebas con estado

experiencia multimedia multi-pantalla. VoDKATV es un sistema distribuido compuesto por va-rios componentes, que se integran a traves de servicios web (figura 3).

La parte principal del sistema de VoDKATV es el paquete core, que contiene los compo-nentes clave del sistema. Los componentes basicos usan los componentes del backend paraobtener informacion de sistemas externos, por ejemplo, la EPG de canales IPTV (proporciona-do por el componente EPGServer) o los contenidos multimedia en alquiler de un catalogo devıdeo bajo demanda (proporcionado por el componente AssetManager). Por otro lado, loscomponentes basicos son utilizados por los clientes (clients), es decir, las aplicaciones quelos usuarios finales utilizan para acceder al sistema en una pantalla de TV, telefono inteligente ocualquier otro dispositivo compatible. Finalmente, la arquitectura tambien incluye aplicacionesde administracion para gestionar y configurar el sistema (paquete admin).

Hemos utilizado VoDKATV como caso de estudio para nuestro framework. En concreto,hemos utilizado el servicio web proporcionado por el componente VoDKATV-server, quedevuelve datos en formato XML.

4.2. Aplicacion de la propuesta al caso de estudio

VoDKATV almacena informacion sobre los usuarios y los dispositivos que pueden accederal sistema. Los dispositivos se identifican mediante una direccion MAC, y estan asociados a unhogar (o room, en nomenclatura VoDKATV). Cuando un nuevo usuario se registra en el sistemaVoDKATV, se crea un nuevo hogar y se registran los dispositivos de ese usuario para ese hogar. El

Automatizacion de Pruebas para Servicios Web 9 / 15

Page 70: y V Taller de Programación Funcional (TPF)

Figura 3: Arquitectura de VoDKATV

servicio web elegido como caso de estudio ofrece, entre otras, operaciones para crear, modificar,actualizar y eliminar hogares y dispositivos. Por ejemplo, el WSDL para crear un nuevo hogar:

<wsdl:operation name="CreateRoom"pattern="http://www.w3.org/ns/wsdl/in-out"style="http://www.w3.org/ns/wsdl/style/iri" wsdlx:safe="true"><wsdl:input element="msg:createRoomParams"/><wsdl:output element="msg:createRoomResponse"/>

</wsdl:operation>

donde createRoomParams especifica los parametros del servicio web:

<xsd:element name="createRoomParams"><xsd:complexType>

<xsd:sequence><xsd:element name="roomId" type="xsd:string" /><xsd:element name="description" type="xsd:string"

minOccurs="0" maxOccurs="1" /></xsd:sequence>

</xsd:complexType></xsd:element>

y createRoomResponse es la respuesta devuelta por el servicio web:

<xsd:element name="createRoomResponse"><xsd:complexType>

<xsd:sequence><xsd:element name="roomId" type="xsd:string" /><xsd:element name="description" type="xsd:string"

minOccurs="0" maxOccurs="1" /><xsd:element name="error" type="tns:error"

minOccurs="0" maxOccurs="1" /></xsd:sequence>

</xsd:complexType></xsd:element>

Automatizacion de Pruebas para Servicios Web 10 / 15

Page 71: y V Taller de Programación Funcional (TPF)

<xsd:complexType name="error"><xsd:sequence>

<xsd:element name="code" type="xsd:string" /><xsd:element name="params" type="tns:errorParams"

minOccurs="0" maxOccurs="1"/><xsd:element name="description" type="xsd:string" />

</xsd:sequence></xsd:complexType>

<xsd:complexType name="errorParams"><xsd:sequence>

<xsd:element name="param" type="tns:errorParam"minOccurs="1" maxOccurs="unbounded"/>

</xsd:sequence></xsd:complexType>

<xsd:complexType name="errorParam"><xsd:attribute name="name" type="xsd:string" /><xsd:attribute name="value" type="xsd:string" />

</xsd:complexType>

Nuestro enfoque requiere especificar el comportamiento del servicio web de modo que loscasos de prueba puedan generarse automaticamente. La especificacion de CreateRoom sera:

si el identificador de hogar esta vacıo, el servicio web debe devolver un error required;

si ya existe el identificador de hogar, debe devolverse un error duplicated;

en otro caso, el hogar debe crearse, y el servicio web debe devolver su identificador(roomId) y descripcion (description).

Esta especificacion se escribe con precondiciones y postcondiciones OCL. A diferencia delejemplo MathUtils (seccion 3), que es un componente sin estado, aquı tenemos que saberque hogares se crearon previamente para poder evaluar si el sistema VoDKATV debe devolverun error o no, esto es, se trata de un servicio web con estado. Para ello, escribimos las post-condiciones OCL usando state_rooms como parte del estado interno del modelo de prueba.Dicha variable de estado contendra los hogares que deben ser creados correctamente en sistema,es decir, cuando no se obtiene un error required o duplicated. Con este enfoque, la es-pecificacion para la operacion CreateRoom se puede escribir en OCL, usando la operacionincluding de OCL para anadir los hogares al estado, de la siguiente manera:

context VoDKATVInterface::CreateRoom(roomId:String, description:String): CreateRoomResponse

post CreateRoom:if ((roomId = ’’) or (roomId = null)) then(self.state_rooms = self.state_rooms@pre and

result.errors->size() = 1 and result.errors->at(0).code = ’required’)elseif (self.state_rooms->select(

room | room.roomId = roomId)->notEmpty()) then(self.state_rooms = self.state_rooms@pre and

result.errors->size() = 1 and result.errors->at(0).code = ’duplicated’)else

self.state_rooms = self.state_rooms@pre->including(

Automatizacion de Pruebas para Servicios Web 11 / 15

Page 72: y V Taller de Programación Funcional (TPF)

Tuple roomId:String = roomId, description:String = description

) and result.roomId = roomId and result.description = descriptionendif

endif

Esta especificacion de OCL, junto con el WSDL, es transformada por nuestro framework paragenerar propiedades QuickCheck. Para ello, se utiliza el mismo metodo descrito en [FC12].En este caso, al emplear una variable de estado (state_rooms) y el operador OCL @pre,se generara una representacion de maquina de estado. Las maquinas de estados QuickCheckrequieren la especificacion de los siguientes elementos (figura 2):

los comandos a ejecutar (es decir, las operaciones del servicio web a probar);

las precondiciones para cada operacion (definidas en el fichero OCL);

las postcondiciones para cada operacion (definidas en el fichero OCL);

la informacion almacenada en el estado interno y su valor inicial;

la actualizacion del estado interno tras la ejecucion de cada operacion.

Como ya hemos mencionado, el modelo QuickCheck se conecta a un adaptador HTTP (sec-cion 3) generado por nuestra herramienta a partir del WSDL. Por lo tanto, cuando se prueba unaoperacion, se invocara la correspondiente operacion del servicio web y el resultado se contrastacon la correspondiente postcondicion. El siguiente es el codigo generado para comprobar que sedevuelve un error required cuando el identificador de hogar esta vacıo:

postcondition(PreState, AfterState,call, ?MODULE, createRoom, [RoomId, Description], Result) ->

case RoomId of"" ->

Error = ocl_datatypes:get_property(errors, Result),ocl_seq:eq(AfterState#ts.rooms, PreState#ts.rooms)

andalso ocl_string:eq(ocl_datatypes:get_property(code, Error))),"required")end;

...

Ası, nuestra herramienta es capaz de crear automaticamente un modelo de prueba QuickCheckejecutable a partir de las descripciones WSDL y OCL, capaz de realizar pruebas automatica-mente para comprobar la conformidad del servicio web descrito por el WSDL con las restric-ciones semanticas expresadas en OCL.

4.3. Analisis de resultados

QuickCheck genera casos de prueba concretos a partir del modelo de prueba generado, es de-cir, secuencias aleatorias de comandos con valores aleatorios para los parametros (de acuerdo conlas posibles precondiciones). Ademas, estas secuencias son ejecutadas, invocando las correspon-dientes operaciones del servicio web, y determinando si el SUT cumple con las postcondiciones.

En el caso de VoDKATV, pueden generarse y ejecutarse cientos de miles de casos de pruebaen cuestion de segundos. Dichos casos de prueba han incluıdo 29 operaciones diferentes de

Automatizacion de Pruebas para Servicios Web 12 / 15

Page 73: y V Taller de Programación Funcional (TPF)

gestion (creacion, actualizacion, borrado) de hogares, dispositivos, cuentas y sesiones. El hechode que la generacion de secuencias de estos comandos se haya realizado de manera automaticanos da confianza en que no solo se han probado las secuencias mas habituales, sino tambiensecuencias mas atıpicas (pero posibles desde el punto de vista de la especificacion), que con todaprobabilidad una persona no harıa el esfuerzo de crear manualmente.

Aunque no hemos encontrado ningun error en el servicio web utilizado como caso de estudio,hemos introducido errores manualmente para determinar la efectividad del framework desarro-llado. Por ejemplo, hemos modificado el codigo fuente del servicio web para que se permitiesecrear hogares con identificadores duplicados. Cuando ejecutamos las pruebas, QuickCheck en-cuentra un error en una de las postcondiciones, el cual es reducido a la siguiente secuencia deoperaciones:

Shrinking..........(10 times)[set,var,3, call,test_sut,createRoom,["A",""],set,var,4, call,test_sut,createRoom,["A",""]]

donde podemos ver como QuickCheck encuentra un contraejemplo mınimo que ilustra la vio-lacion de la restriccion: una secuencia que inserta dos hogares con el mismo identificador ("A").

5. Conclusiones y trabajo futuro

Este artıculo presenta un marco de pruebas para construir automaticamente modelos de pruebabasados en propiedades (PBT) que permiten probar servicios web. Para ello, se utilizan restric-ciones OCL que especifican la semantica del servicio web a probar descrito a traves de un WSDL.De esta forma, se generan propiedades que son utilizadas por la herramienta QuickCheck paragenerar y ejecutar casos de prueba concretos. Nuestro framework puede generar propiedadestanto para servicios web sin estado como con estado, mediante sentencias declarativas en elprimer caso y maquinas de estados en el segundo. Estos modelos generados pueden considerarseespecificaciones ejecutables.

Nuestro enfoque se basa en el uso de una herramienta de PBT como QuickCheck para generary ejecutar los casos de prueba a partir de las propiedades y modelos. Esto supone una granventaja, puesto que permite la generacion automatica de secuencias de prueba complejas paraestresar el sistema real de una manera mas objetiva y eficiente [FB97, MBLD11, P. 08]. Otroaspecto importante del uso de QuickCheck son sus capacidades de reduccion de contraejemplos,proporcionando informacion muy valiosa para la depuracion de fallos.

Hemos utilizado un lenguaje de especificacion estandar, OCL, para la descripcion semantica,por lo que no es necesario que los probadores aprendan un nuevo lenguaje de especificacion(en este caso Erlang) para poder escribir propiedades y modelos de prueba utilizando nuestroframework, sino que estos se generan automaticamente a partir de la especificacion OCL. Estaaproximacion permite que el probador trabaje a un nivel mas alto de abstraccion, mas cerca delnivel de especificacion: no hay necesidad de pensar en los casos de prueba concretos, sino dedeterminar un modelo de comportamiento general. Ademas, los probadores se abstraen de losdetalles de implementacion del SUT. Esto significa que un mismo conjunto de propiedades omodelo puede utilizarse para validar diferentes implementaciones, y tambien que las modifica-

Automatizacion de Pruebas para Servicios Web 13 / 15

Page 74: y V Taller de Programación Funcional (TPF)

ciones en la implementacion no requieren de la reescritura de los casos de prueba, puesto queestos se derivan dinamicamente del modelo en el momento de su ejecucion.

Actualmente, nuestro framework soporta completamente la version 2 de WSDL, ası comoparte de la especificacion de OCL 2.3.1. Como trabajo futuro, por tanto, anadiremos a nuestroframework aquellas partes de OCL no soportadas actualmente tales como algunos tipos de datoso algunas operaciones especıficas. Tambien como trabajo futuro, nos planteamos ser capacesde identificar las condiciones concretas que han fallado cuando QuickCheck genera un contrae-jemplo a un determinado caso de prueba, de manera que se muestre la parte especıfica de laespecificacion OCL que ha producido el error. Por otra parte, tenemos la intencion de ampli-ar nuestro marco para adaptarlo especıficamente a las propiedades intrınsecas de los serviciosREST, los cuales son un tipo de servicio web particular especialmente popular a dıa de hoy. Porultimo, pero no menos importante, tenemos la intencion de utilizar este mismo framework parasoportar la definicion de propiedades que representen los requisitos no funcionales (tales comodisponibilidad, capacidad de respuesta...), que por lo general se describen en documentos EULA(End-User Licence Agreement) y SLA (Service Level Agreement), y que son especialmente rel-evantes en el terreno de los servicios web.

Ademas, buscando un mayor impacto de nuestro trabajo en la industria, donde el uso de re-stricciones OCL es limitado, una de nuestras lıneas de investigacion actuales se centra en lageneracion automatica de propiedades y modelos para servicios web en los que el modelo decomportamiento se construye y refina de manera interactiva.

Referencias[AAM10] A test case reduction method for semantic based web services. 2010.

[ACH08] T. Arts, L. M. Castro, J. Hughes. Testing Erlang data types with quviq quickcheck. In Proceed-ings of the 7th ACM SIGPLAN workshop on ERLANG. ERLANG ’08, pp. 1–8. ACM, NewYork, NY, USA, 2008.

[AH03] T. Arts, J. Hughes. Erlang/quickcheck. Ninth International Erlang/OTP User Conference,2003.

[AHJW06] T. Arts, J. Hughes, J. Johansson, U. Wiger. Testing telecoms software with quviqQuickCheck. In Proceedings of the 2006 ACM SIGPLAN workshop on Erlang. ERLANG ’06,pp. 2–10. ACM, New York, NY, USA, 2006.doi:10.1145/1159789.1159792http://doi.acm.org/10.1145/1159789.1159792

[Apaa] Apache. Apache Axis2. http://axis.apache.org/.

[Apab] Apache. Apache CXF. http://cxf.apache.org/.

[BBMP09] WS-TAXI: A WSDL-based testing tool for web services. 2009.

[BIPT09] Automatic synthesis of behavior protocols for composable web-services. 2009.

[BLTC08] Ontology-based test modeling and partition testing of web services. 2008.

[bnf] BNFC. http://bnfc.digitalgrammars.com/.

[CH00] K. Claessen, J. Hughes. Quickcheck: a lightweight tool for random testing of haskell programs.ICFP, pp. 268–279, 2000.

Automatizacion de Pruebas para Servicios Web 14 / 15

Page 75: y V Taller de Programación Funcional (TPF)

[Cro06] D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON). http://www.ietf.org/rfc/rfc4627, 2006.

[DWA+10] J. Derrick, N. Walkinshaw, T. Arts, C. B. Earle, F. Cesarini, L.-A. Fredlund, V. Gulias,J. Hughes, S. Thompson. Property-based testing: the ProTest project. In Proceedings of the 8thinternational conference on Formal methods for components and objects. FMCO’09, pp. 250–271. Springer-Verlag, Berlin, Heidelberg, 2010.

[Ecl] Eclipse. Eclipse. http://www.eclipse.org/.

[Emm06] W. Emmerich. Managing web service quality. In Proceedings of the 6th international work-shop on Software engineering and middleware. SEM ’06, pp. 1–1. ACM, New York, NY, USA,2006.

[FB97] G. Fink, M. Bishop. Property-based testing: a new approach to testing for assurance. SIGSOFTSoftw. Eng. Notes 22(4):74–80, July 1997.doi:10.1145/263244.263267http://doi.acm.org/10.1145/263244.263267

[FC12] M. A. Francisco, L. M. Castro. Automatic generation of test models and properties from UMLmodels with OCL constraints. In Proceedings of the 12th Workshop on OCL and Textual Mod-elling. OCL ’12, pp. 49–54. ACM, New York, NY, USA, 2012.

[FR03] M. Forsberg, A. Ranta. Labelled BNF: a highlevel formalism for defining well-behaved pro-gramming languages. In Proceedings of the Estonian Academy of Sciences: Physics and Math-ematics, 52:356–377. 2003.

[Lam12] Automatic WSDL-guided Test Case Generation for PropEr Testing of Web Services. 2012.

[MBLD11] S. Mouchawrab, L. C. Briand, Y. Labiche, M. Di Penta. Assessing, Comparing, and Com-bining State Machine-Based Testing and Structural Testing: A Series of Experiments. IEEETrans. Softw. Eng. 37(2):161–187, Mar. 2011.doi:10.1109/TSE.2010.32http://dx.doi.org/10.1109/TSE.2010.32

[NS08] An approach for web service test case generation based on web service semantics. 2008.

[NS09] An improved test case generation method for web service testing from WSDL-S and OCL withpair-wise testing technique. Volume 1. 2009.

[ocl] OCLNL. http://www.key-project.org/oclnl/.

[OMG12] OMG. Object Constraint Language (OCL). http://www.omg.org/spec/OCL/2.3.1/, 2012.

[P. 08] P. Farrell-Vinay. Managing Software Testing. Auerbach Publishers, 2008.

[Pet07] A. Petrenko. Why automata models are sexy for testers? (invited talk). Lecture Notes in Com-puter Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notesin Bioinformatics), 2007.

[TG07] Specifying semantic web service compositions using UML and OCL. 2007.

[W3Ca] W3C. eXtensible Markup Language (XML). http://www.w3.org/XML/.

[W3Cb] W3C. Semantic Web Rule Language (SWRL). http://www.w3.org/Submission/SWRL/.

[W3C01] W3C. Web Services Description Language (WSDL). http://www.w3.org/TR/wsdl, 2001.

[W3C05] W3C. Web Services Semantics (WSDL-S). http://www.w3.org/Submission/WSDL-S/, 2005.

[ZZK07] Y. Zheng, J. Zhou, P. Krause. An automatic test case generation framework for web services.Journal of Software 2(3):64–77, 2007.

Automatizacion de Pruebas para Servicios Web 15 / 15

Page 76: y V Taller de Programación Funcional (TPF)

Operadores de Mutación a Nivel de Clase para el Lenguaje C++

Pedro Delgado-Pérez, Inmaculada Medina-Bulo, Juan José Domínguez-Jiménez yAntonio García-Domínguez

Grupo UCASE de Ingeniería del Software, Departamento de Ingeniería Informática,Universidad de Cádiz, Cádiz, España

pedro.delgado, inmaculada.medina, juanjose.dominguez,[email protected]

Abstract: La prueba de mutaciones es una técnica basada en fallos alrededor dela cual existe una gran variedad de estudios de investigación y se han elaboradoherramientas para un amplio abanico de lenguajes de programación. Sin embargo, eldesarrollo respecto a C++, uno de los lenguajes orientados a objetos más popularesy usados, es escaso. Este trabajo aborda esta cuestión presentando un conjunto deoperadores de mutación de acuerdo a las propiedades de la orientación a objetos (anivel de clase) y a las características propias del lenguaje C++. También se ofreceuna primera visión general del uso de esos operadores para analizar programas eneste lenguaje, a partir de un experimento reducido con los operadores.

Keywords: Prueba de mutaciones, operadores de mutación, C++, programaciónorientada a objetos

1 Introducción

La prueba de mutaciones busca evaluar, para los conjuntos de casos de prueba creados para unprograma software, la robustez que tienen en la detección de los fallos que pudiesen estar pre-sentes en el código [OU01]. Tal y como se expone en [KCM00], es una técnica que evalúala calidad de los casos de prueba examinando si pueden distinguir un conjunto de programasalternativos (representando tipos específicos de fallos) del programa que está siendo probado.Esos tipos de fallos específicos son representados por los operadores de mutación, que introdu-cen simples cambios sintácticos en el programa. Cada uno de estos cambios genera un nuevoprograma al que se le conoce como mutante. Por ejemplo, un fragmento de código como x + 1puede ser mutado por un operador que cambie el operador aritmético a x - 1.

Como se dice en [MKO02], un caso de prueba que distinga el programa de su mutante esconsiderado efectivo en la búsqueda de fallos en el programa. Los casos de prueba se ejecutancon la intención de detectar los errores que representan los mutantes. Esa detección que revela elfallo significa que el mutante produce un resultado distinto a la ejecución del programa original.En ese caso decimos que el mutante está muerto y, en el caso contrario, que el mutante sigue vi-vo. Cuando ninguno de los casos de prueba es capaz de detectar el cambio introducido porque enrealidad no se modifica el significado del programa, se dice que el mutante es equivalente. Final-mente, un mutante puede ser clasificado como erróneo cuando el cambio produce un programaque presenta un error, de manera que es invalidado por el compilador.

Los operadores de mutación se obtienen del análisis de los errores más habituales que losprogramadores suelen cometer al programar y están específicamente diseñados de acuerdo a las

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 1 / 15

Page 77: y V Taller de Programación Funcional (TPF)

características de cada lenguaje de programación. Esa es la razón por la que una correcta eleccióndel conjunto de operadores de mutación es una de las claves para el éxito en el uso de la técnica.

En la actualidad existe una gran variedad de herramientas que emplean esta técnica con éxitopara diferentes lenguajes [JH11] como MuJava para Java, Proteum/IM 2.0 para C o SQLMuta-tion para SQL. No obstante, el desarrollo con respecto a C++, a pesar de ser uno de los lenguajesorientados a objetos más conocidos y empleados, es realmente escaso. En [JH11] se puede obser-var que la prueba de mutaciones para C++ está muy por debajo de la representación que tienenotros lenguajes, tanto en investigación como en práctica. Así, en cuanto a estudios sobre losoperadores de mutación, solo en [Der03] se puede encontrar una enumeración de varios errorescomunes que pueden cometer los programadores respecto a la orientación a objetos, pero no sedetallan los operadores concretos.

El objetivo a largo plazo es desarrollar un framework, como los antes nombrados, que nospermita aplicar la prueba de mutaciones a programas escritos en lenguaje C++. El primer paso,y quizás el más importante en el desarrollo de la herramienta, es la obtención de un conjuntode operadores de mutación, ya que son los que representan los errores que serán tratados porla técnica. En este artículo nos centraremos en los operadores a nivel de clase, es decir, en losoperadores relacionados con las características de la orientación a objetos (OO), por ser C++muy utilizado por la inclusión de este paradigma [Str97, HB09]

Al no haber un trabajo previo en cuanto a la exposición de un conjunto de operadores demutación a este nivel, se ha llevado a cabo un estudio en profundidad para definir el conjuntode operadores de mutación para C++, que será mostrado en las siguientes secciones del artículo.En primer lugar, se profundizará en los operadores de mutación disponibles para C++ según lascaracterísticas del lenguaje y como se ha llevado a cabo el proceso de obtención de operadores.Tras esto, se describirán los operadores de mutación definidos y se harán algunas consideracionesrespecto a este conjunto. Además, se mostrará el resultado de un primer experimento de análisisde programas escritos en C++ empleando los operadores de mutación obtenidos. Finalmente, seexpondrán las conclusiones y se sentarán las bases para el trabajo en el futuro.

2 Obtención de los Operadores de Mutación a Nivel de Clase

Los operadores de mutación se extraen de los fallos que los programadores suelen cometer alprogramar, por lo que podemos decir que los operadores de mutación se asocian a categorías deerror típicas que se cometen en programas de un determinado lenguaje. Varias de esas categoríasde error son comunes a muchos lenguajes, pero cada uno posee ciertas propiedades que hacennecesario un estudio particularizado de los operadores para cada lenguaje.

La prueba de mutaciones se centró en sus inicios en la programación estructurada, por lo quela mayoría de operadores de mutación fueron desarrollados para esta clase de lenguajes, comoC o Fortran. Sin embargo, estos operadores pueden no ser suficientes para analizar programascon características de OO, tales como la encapsulación, herencia o polimorfismo, las cualesproporcionan un nuevo ámbito de errores potenciales. Además, los operadores de mutación con-vencionales no cambian las declaraciones de entidades definidas en un lenguaje, como los tiposincluidos en él. Sin embargo, con las nuevas características, un usuario puede definir sus propiasclases, lo que puede introducir fallos y lleva irremediablemente a la necesidad de diseñar nuevos

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 2 / 15

Page 78: y V Taller de Programación Funcional (TPF)

operadores a nivel de clase.El paradigma de la OO está muy presente en la industria y, por esa razón, también ha ido

creciendo el interés en cuanto a la investigación de la prueba de mutaciones respecto a esteparadigma. La mayoría de los estudios en este sentido se han realizado en torno al lenguajeJava y, en una proporción menor, alrededor de C#. Sin embargo, para C++, tan solo podemosencontrar una lista de errores que conciernen a ciertas propiedades de la OO [Der03].

Se pueden definir diferentes niveles dependiendo de las características del programa y del tipode prueba que se realiza [RPO13, JH11]. En este artículo nos centraremos en los operadores anivel de clase explicando sus características específicas.

Para la obtención del conjunto de operadores de mutación, se han estudiado las propiedadesmás usadas y los errores de programación más comunes en C++ [HB09, Str97], siendo impor-tante destacar que se ha tomado el estándar C++03 como referencia. Aún es pronto para definiroperadores relativos al nuevo estándar C++11, teniendo en cuenta que no hay gran cantidad deinformación sobre las características que añade y su empleo no está muy extendido, por lo queno se pueden establecer las fuentes de error más comunes referente a este estándar.

Por otra parte, se han analizado las contribuciones en otros lenguajes, lo cual es importante yaque nos ofrecen una visión de los errores que los programadores cometen con más frecuencia,además de que es necesario que el desarrollo de la prueba de mutaciones siga el mismo caminopara que puedan ser comparables las distintas aportaciones para los diversos lenguajes. Así lascosas, para la obtención de un conjunto de operadores de mutación a este nivel se han analizadoprincipalmente las contribuciones para Java [KCM00, MKO02, OMK06, Che01], pues los es-tudios con respecto a este lenguaje son los más completos, y C# [Der06]. Estos lenguajes sonsimilares, tomando Java gran parte de la sintaxis de C++ pero eliminando muchas de las facili-dades de bajo nivel (se puede encontrar una lista de diferencias entre ambos en [HB09]). Por suparte, gran parte de las características de C# vienen influidas de C/C++ en su sintaxis básica yde Java en su modelo de objetos.

Por lo tanto, el conjunto final está compuesto de operadores similares en otros lenguajes, asícomo de nuevos operadores relativos a las características propias de C++.

3 Descripción de los Operadores de Mutación Propuestos

3.1 Categorías de operadores

Los operadores de mutación han sido englobados en varias categorías según las característicasprincipales de la orientación a objetos con las que los operadores están relacionadas. Cada una deestas categorías es identificada por una letra mayúscula. En total, se han tomado siete categoríasque se enumeran a continuación:

Control de acceso (A)

Herencia (I)

Polimorfismo y enlace dinámico (P)

Sobrecarga de método (O)

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 3 / 15

Page 79: y V Taller de Programación Funcional (TPF)

Excepciones (E)

Cambio de objetos y miembros (M)

Miscelánea (C)

Esta última categoría contiene aquellos operadores cuyos elementos sintácticos son únicos yno pueden relacionarse con otros operadores. En la siguiente subsección se irán mostrando losoperadores que pertenecen a esos grupos (ver Tabla 1). Cada uno de estos operadores es identifi-cado por tres letras mayúsculas: la primera relativa a la categoría en la que se clasifican y las dossiguientes identificativas del operador. Por restricciones de espacio, solo se ampliarán algunosoperadores explicando sus peculiaridades respecto a C++, pudiendo obtener el resto de mane-ra análoga apoyándose en las referencias que se indican para cada operador. Como se comentóanteriormente, para la obtención del conjunto de operadores de mutación a este nivel se han con-siderado los conjuntos definidos alrededor de las características principales de la programaciónOO en otros lenguajes [Che01, Der03, Der06, KCM00, MKO02, OMK06].

3.2 Definición de operadores de mutación

Control de acceso

AMC o Cambio de modificador de acceso: Este operador trata de asegurar que la acce-sibilidad de variables y métodos es la correcta [OMK06]. En C++ se especifica el nivel deacceso de los miembros por secciones, pudiéndose añadir tantas secciones de cada nivelcomo se desee. Este operador pasará por tanto de cambiar el modificador de acceso a trans-ferir un miembro de un bloque a otro con un modificador de acceso diferente. En caso deno existir un tipo de acceso concreto, se incluirá un bloque para añadir el miembro al quese muta su acceso y, en caso de que un bloque tenga un único elemento, éste se eliminaráal quedarse sin miembros.

Ejemplo: Mutante 1: Mutante 2: Mutante 3:p u b l i c : i n t a ; p u b l i c : i n t a ; p r o t e c t e d : i n t a ; p u b l i c : i n t a ; . . .p r i v a t e : f l o a t b ; s t r i n g c ; p r i v a t e : f l o a t b ; p r i v a t e : s t r i n g c ;

s t r i n g c ; p r i v a t e : f l o a t b ; s t r i n g c ; p r o t e c t e d : f l o a t b ;

AAC o Cambio del modificador de acceso en la herencia: En C++ la herencia puederealizarse de una manera pública, protegida o privada para determinar los privilegios deacceso que va a tener la clase derivada sobre los miembros de la clase base. Este operadorcambia la accesibilidad a la hora de heredar para comprobar si el acceso que se especificaes el debido.

Ejemplo: Mutante 1: Mutante 2:c l a s s A c l a s s B : p u b l i c A c l a s s B : p r o t e c t e d A c l a s s B : p r i v a t e A

. . . . . . . . . . . . . . . . . . . . . . . . ; ; ; ;

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 4 / 15

Page 80: y V Taller de Programación Funcional (TPF)

Tabla 1: Resumen de bloques de operadores a nivel de clase

Bloque Operador Descripción

Control de accesoAMC * Cambio de modificador de acceso

AAC * Cambio de modificador de herencia

Herencia

IHI Inserción de variable oculta

IHD Borrado de variable oculta

IOD Borrado de método sobrescrito

IOR * Renombrado de método sobrescrito

ISI * Inserción de referencia a clase base

ISD * Borrado de referencia a clase base

IPC * Borrado de llamada explícita de constructor de la clase base

IOP * Cambio de posición en la llamada al método sobrescrito

IMR * Reemplazo de clase en herencia múltiple

Polimorfismo y

enlace dinámico

PNC * Llamada al método new con tipo de clase hija

PMD * Declaración de variable miembro con tipo de clase base

PPD * Declaración de una variable parámetro con tipo de clase hija

PCI * Inserción de un operador de tipo cast

PCD * Borrado de un operador de tipo cast

PCC * Cambio de un operador de tipo cast

PRV * Asignación de una referencia con otro tipo compatible

PVI * Inserción de la palabra reservada virtual

Sobrecarga de

método

OMR Cambio de contenido de método sobrecargado

OMD Borrado de método sobrecargado

OAO Cambio de orden de argumentos

OAN * Cambio de número de argumentos

OPO Cambio del orden de parámetros

Excepciones

EHR Borrado del manejador de la excepción

EHC * Cambio del manejador de la excepción

EXS Absorción de la excepción

Cambio de objetos y

miembros

MCO * Llamada a un miembro de una clase desde otro objeto

MCI * Llamada a miembro de una clase desde otra clase que hereda

MBC Cambio de acceso a variable miembro

MNC Cambio de nombre de método

Miscelánea

CTI Inserción de la palabra reservada this

CTD Borrado de la palabra reservada this

CID * Borrado de la inicialización de una variable miembro

CDC Creación de constructor por defecto

CDD * Borrado del método destructor

CCA *Borrado del constructor de copia y de la sobrecarga de

operación de asignaciónNota: Los operadores marcados con * son de nueva definición o bien cambian respecto a la definición/implementación donde

originalmente fueron expuestos.

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 5 / 15

Page 81: y V Taller de Programación Funcional (TPF)

Herencia

Los operadores aplicados a la herencia de clases, principalmente en presencia de miembros so-brescritos, están incluidos en este grupo de operadores. Los operadores son: IHI, IHD, IOD, IOR,ISI, ISD, IPC, IOP [OMK06, KCM00, Der06, Che01] y IMR.

IOP o Cambio de posición en la llamada al método sobrescrito: Este operador simulael error que se suele producir al llamar a un método de la clase base, que está sobrescritoen la clase hija, en el momento incorrecto, lo cual produce un estado no deseado. Como sepuede observar en el ejemplo, se hace referencia directa a la clase base con el operador deresolución de ámbito (::). Los operadores ISI, ISD y IPC también están relacionados conla resolución de ámbito, propia de C++ por la existencia de herencia múltiple.

Ejemplo: Mutante:c l a s s A c l a s s A

. . . . . . . . . . . .vo id metodo ( ) a = 0 ; . . . . . . v o i d metodo ( ) a = 0 ; . . . . . .

; ;c l a s s B : p u b l i c A c l a s s B : p u b l i c A

. . . . . . . . . . . .vo id metodo ( ) vo id metodo ( )

A : : metodo ( ) ; a = 1 ;a = 1 ; A : : metodo ( ) ;

; ;

IOR o Renombrado de método sobrescrito: Este operador modela la situación dondeun método sobrescrito interacciona o afecta a la versión del método en la clase base. Estecaso en C++ puede únicamente ocurrir cuando el método está declarado como virtual. Deesta forma, un método sobrescrito en una clase hija sí puede ser llamado desde un métododeclarado en la clase base si el método se enlaza de manera dinámica.

Ejemplo: Mutante:c l a s s A c l a s s A

. . . . . . . . . . . .v i r t u a l vo id m1 ( ) . . . . . . v i r t u a l vo id m3 ( ) . . . . . . vo id m2 ( ) . . . m1 ( ) ; . . . v o i d m2 ( ) . . . m3 ( ) ; . . .

; ;c l a s s B : p u b l i c A c l a s s B : p u b l i c A

. . . . . . . . . . . .vo id m1 ( ) . . . . . . v o i d m1 ( ) . . . . . .

; ;

IMR o Cambio de clase en herencia múltiple: La existencia de herencia múltiple en ellenguaje C++ permite que podamos hacer referencia a miembros de más de una clase desdela clase que hereda. Cuando dos o más de las clases de las que se hereda tienen definidouna variable con el mismo nombre o un método con la misma signatura, es posible que

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 6 / 15

Page 82: y V Taller de Programación Funcional (TPF)

se referencie el miembro de la clase equivocada a través del operador de resolución deámbito, y este caso es el que trata de modelar este operador.

Ejemplo: Mutante:c l a s s A c l a s s B c l a s s C : p u b l i c A, c l a s s C : p u b l i c A,

. . . . . . . . . . . . p u b l i c B p u b l i c Bi n t a ; i n t a ; . . . . . . . . . . . .

; ; v o id m ( ) vo i d m ( ) . . . . . . . . . . . .b = A : : a + 1 ; b = B : : a + 1 ;

; ;

Polimorfismo y enlace dinámico

Este bloque está compuesto por operadores que aseguran que el mecanismo polimórfico estásiendo empleado de forma correcta. Este mecanismo es particular en C++ por el manejo depunteros y referencias. Se pueden definir los siguientes ocho operadores para esta categoría:PNC, PMD, PRV, PCC, PCI, PCD, PPD [OMK06] y PVI.

PCI o Inserción de un operador de tipo cast: El cometido de este operador es cambiarel tipo real de una referencia a objeto, por el tipo del padre/hijo con el que se declaróoriginalmente. Los mutantes resultantes mostrarán un comportamiento diferente si, en larelación entre clases, existen variables ocultas y/o métodos sobrescritos de forma que sereferencia o invoca a esas nuevas versiones. En el ejemplo se puede apreciar el manejode referencias y conversión de objetos. Además, el método referido puede no ser virtual,aunque la clase base deberá ser polimórfica para permitir el downcasting:

c l a s s A Ejemplo: Mutante:vo id metodo ( ) . . . B b ; B b ;. . . . . . A ∗pa = &b ; A ∗pa = &b ;

pa−>metodo ( ) ; (*) ( dynamic_cas t <B∗>( pa ))−> metodo ( ) ; (**)c l a s s B : p u b l i c A

vo id metodo ( ) . . . (*) Se i n v o c a a A : : metodo ( ) (**) Se i n v o c a a B : : metodo ( )

PVI o Inserción de la palabra reservada virtual: Cuando se necesita que un método ten-ga un comportamiento polimórfico, se debe indicar añadiendo el modificador virtual. Esteoperador propone la posibilidad de que el programador olvidase incluirla en la declaraciónde un método que debería ser virtual. Para que este operador pueda tener efecto es necesa-rio que existan métodos que sobrescriban el comportamiento del método virtual en clasesderivadas e invocaciones al método cuya selección se realice en tiempo de ejecución.

Ejemplo: Mutante:c l a s s A c l a s s A

. . . . . . . . . . . .i n t metodo ( ) . . . . . . v i r t u a l i n t metodo ( ) . . . . . . ;

; ;c l a s s B : p u b l i c A c l a s s B : p u b l i c A

. . . . . . . . . . . .i n t metodo ( ) . . . . . . i n t metodo ( ) . . . . . .

; ;

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 7 / 15

Page 83: y V Taller de Programación Funcional (TPF)

Sobrecarga de método

La sobrecarga de métodos implica que dos o más métodos con el mismo nombre pueden coexistirsiempre que tengan diferentes argumentos en su signatura. OMR, OMD, OAO, OAN [MKO02] yOPO [KCM00] tratan de asegurar que se invoca al método correcto en este caso.

OAN o Cambio de número de argumentos: En este operador, que muta el número deargumentos en una llamada, hay que tener en cuenta la posibilidad de utilizar parámetrospredeterminados de C++. Los parámetros predeterminados o por omisión son aquellosque se declaran en el prototipo del método con un valor prefijado, pudiendo omitir eseparámetro en su invocación (tomando el valor predeterminado de forma automática). Si unmétodo está sobrecargado como en el ejemplo de abajo, solo se podrá generar un mutante.No obstante, si el método sobrecargado tiene además un párametro por omisión, uno máspodrá ser creado (los argumentos añadidos en la llamada provienen de los constructorespor defecto para objetos y valores constantes para los tipos primitivos del lenguaje).

Ejemplo sin parámetro por omisión: Ejemplo con parámetro por omisión:c l a s s A c l a s s A

. . . . . . . . . . . .vo id metodo ( ) ; vo id metodo ( ) ;vo id metodo ( i n t a , f l o a t b ) ; vo id metodo ( i n t a , f l o a t b = 2 ) ;

; ;Ejemplo de uso: Mutante: Ejemplo de uso: Mutante:

a . metodo ( ) ; a . metodo ( 0 , 0 ) ; a . metodo ( ) ; a . metodo ( 0 , 0 ) ;a . metodo ( 0 ) ; (*)

(*) En este caso, la llamada real sería a.metodo(0,2);

Excepciones

Aunque el manejo de excepciones no es propio del paradigma de orientación a objetos, lo inclui-mos por su estrecha relación con los lenguajes de este tipo. EHR, EHC [KCM00] y EXS [Der06]nos permiten detectar un empleo inapropiado de las excepciones.

EHC o Cambio del manejador de la excepción: El operador EHC cambia una sentenciade manejo de excepción por una sentencia de propagación de la excepción y viceversa.En el lenguaje C++ esto se puede lograr a través de un relanzamiento de la excepción demanera que ésta sea capturada y tratada, con suerte, en un nivel superior hasta llegar almétodo main.

Ejemplo: Mutante:i n t metodo ( ) i n t metodo ( )

t r y t r y . . . . . . . . . . . .

c a t c h ( ManejadorTipo1 ) c a t c h ( ManejadorTipo1 ) . . . . . . th row ;

; ;

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 8 / 15

Page 84: y V Taller de Programación Funcional (TPF)

Cambio de objetos y miembros

El reemplazo del objeto que invoca a un miembro, o el cambio del miembro invocado por unobjeto, por un objeto o miembro compatible respectivamente, es a lo que los operadores en estebloque se dedican. Así las cosas, se han definido cuatro operadores: MNC [Che01], MCO, MCIy MBC [Der06, Der03].

MCO o Llamada a un miembro de una clase desde otro objeto: El error que trata demodelar este operador es el hecho de utilizar un objeto de una clase en lugar del objetoque se debería haber usado en realidad, también de la misma clase.

Ejemplo: Mutante:A a1 , a2 ; A a1 , a2 ;a1 . metodo ( ) ; a2 . metodo ( ) ;

MCI o Llamada a un miembro de una clase desde otra clase que hereda: Este operadores similar al anterior, pero en esta ocasión el objeto se cambia por otro de una clase distinta,pero ambas heredan de la misma clase (por tanto, que son hermanas).

Ejemplo: Mutante:A1 a1 ; A1 a1 ;A2 a2 ; A2 a2 ; donde A1 y A2 h e r e d a n de l a misma c l a s e b a se Aa1 . metodo ( ) ; a2 . metodo ( ) ;

MNC o Cambio de nombre de método : Este operador modela el error de invocar a unmétodo de la clase cuando se quería acceder a otro compatible (mismos parámetros y tipode retorno).

MBC o Cambio de acceso a variable miembro: Este operador es parecido al MNC peroen cuanto a las variables miembros en vez de en cuanto a los métodos.

Miscelánea

Los operadores que conforman este bloque son: CTI, CTD, CDC, CID (basados en los operadoresdel bloque “específicos de Java” en [MKO02]), CCA y CDD.

CID o Borrado de la inicialización de una variable miembro: Este operador compruebasi el valor inicial dado a una variable miembro es correcto, eliminando su inicialización.En C++, dicha inicialización se realiza en los constructores de las clases, bien con asigna-ciones en su cuerpo o mediante las listas de inicialización. Se propone por ello que, si lainicialización está en el cuerpo del constructor, se elimine la sentencia de asignación y, sila inicialización está dentro de la lista de inicialización, se elimine de la lista.

Ejemplo: A : : A ( ) : a ( 0 ) b = 1 ; Mutante 1: A : : A( ) : a ( 0 ) Mutante 2: A : : A( ) b = 1 ;

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 9 / 15

Page 85: y V Taller de Programación Funcional (TPF)

CDD o Borrado del método destructor: La definición del método destructor en unaclase de C++ nos da la posibilidad de definir la forma en que se hace la limpieza de losobjetos de la misma. En el caso de que no se defina, el compilador proporciona uno demanera automática. El operador propuesto elimina el destructor de la clase con la idea decomprobar si el destructor que ha definido el programador es correcto.

Ejemplo: Mutante:c l a s s A c l a s s A

. . . . . . . . . . . .~A ( ) . . . . . . ; / / ~A ( ) . . . . . . ;

; ;

CCA o Borrado del constructor de copia y de la sobrecarga del operador de asigna-ción: En la programación OO, es frecuente la necesidad de copiar objetos (como en lasinicializaciones a partir de otro objeto o las copias por valor en los métodos o funciones).En C++ la asignación de contenido de un objeto a otro se realiza mediante la definiciónde un constructor de copia y la sobrecarga del operador de asignación. Este operador pa-saría a suprimir la definición de dicho constructor y de la sobrecarga de la asignación paracomprobar que éstos están implementados apropiadamente. Cuando se eliminan, el com-pilador se encarga de proporcionar un constructor de copia automáticamente que copie yasigne miembro a miembro.

Ejemplo: Mutante 1:c l a s s A c l a s s A

. . . . . . . . . . . .A( c o n s t A& c o p i a ) . . . . . . / / A( c o n s t A& c o p i a ) . . . . . . A& o p e r a t o r =( c o n s t A& c o p i a ) A& o p e r a t o r =( c o n s t A& c o p i a ) . . . . . .

. . . . . . ; Mutante 2:

; c l a s s A. . . . . .

A( c o n s t A& c o p i a ) . . . . . . / / A& o p e r a t o r =( c o n s t A& c o p i a ) . . . . . .

;

3.3 Resumen y algunas consideraciones

Resumiendo lo mostrado arriba, se han conformado 7 categorías de operadores de mutación anivel de clase, definiendo un conjunto de 37 operadores de mutación. Este número de operadoreses superior al obtenido en [OMK06] para Java (29 operadores) y similar al mostrado en [Der06]para C# (37 operadores eliminando los que invalida).

En lo que respecta a operadores expuestos para los lenguajes tomados de referencia, el bloquede errores comunes de programación que está incluido en [MKO02] no puede ser consideradopara crear una categoría análoga en C++. Esto es debido a que los operadores de mutación in-cluidos en este bloque, que están relacionados con errores típicos que se cometen al programary suponen un mal uso del lenguaje, se refieren a métodos para los que existe una convención enJava pero no en C++, por lo que no se ajusta a nuestro lenguaje. Por su parte, para los miembros

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 10 / 15

Page 86: y V Taller de Programación Funcional (TPF)

estáticos no se han creado operadores similares a JSI y JSD del bloque de operadores “espe-cíficos de Java”, a pesar de que los miembros estáticos tienen el mismo significado en amboslenguajes; en C++ sería necesario añadir/eliminar la inicialización de la variable y eso supondríaun segundo cambio en el código. Por último, los operadores propios de C# son específicos delas características de ese lenguaje, por lo que tampoco pueden ser sopesados para operadoressemejantes en C++.

4 Análisis de los Operadores de Mutación Definidos

Para tener una primera visión general del proceso de uso de los operadores obtenidos y del com-portamiento que muestran, se ha confeccionado un experimento en el que se analizan diversosprogramas de C++ aplicándose los operadores de mutación a nivel de clase arriba presentados.

4.1 Confección de las pruebas

Para la realización de las pruebas, se han tomado tres programas del LLVM test-suite [Tes], elcual contiene piezas de código en este lenguaje para probar las modificaciones realizadas en esecompilador, la mayoría de los cuales son tomados de ejemplos de libros dedicados a explicarlas características de C++. Concretamente, se han tomado los programas garage, family y simulde la ruta “test-suite/MultiSource/Benchmarks/Prolangs-C++”. Garage está compuesto por unaclase que simula un parking donde dos clases que representan a vehículos pueden ser aparcadosy desaparcados. Family también está compuesto por tres clases que simulan una jerarquía deabuelo-padre-hijo, los cuales comparten ciertos atributos comunes por pertenecer a la mismafamilia. Por su parte, simul es algo más compleja y simula la función de un cursor sobre unapantalla. Este programa ha sido ligeramente modificado para poder probar los operadores delbloque de manejo de excepciones sin cambio de funcionalidad y solo las clases cursor_controllery screen_controller han sido usadas para reducir el número de mutantes.

Se han insertado en el código los fallos que los operadores de mutación simulan y, tras esto, losprogramas mutados se han compilado con Clang y ejecutados frente a casos de prueba diseñadospara estos programas. En este proceso se ha aplicado mutación de primer orden, es decir, cadamutante solo contiene un único cambio. Para determinar los mutantes que eran equivalentes,se examinó visualmente cada mutante que no era matado para comprobar que efectivamente elerror introducido no suponía un cambio en el programa. Cuando un mutante se observa que noes equivalente, esto significa que el conjunto de casos de prueba es insuficiente para detectarla modificación que incluye, siendo necesario añadir casos de prueba que vengan a mejorar eseconjunto. Se comenzó con casos de prueba básicos de las principales funcionalidades de lasclases, aportando nuevos escenarios concretos para aquellos mutantes que no eran en realidadequivalentes sino que carecían del caso de prueba necesario para detectar el cambio. Por otraparte, se consideraron erróneos los mutantes cuyo cambio provocaba un fallo de compilación.

Los resultados obtenidos de la ejecución se pueden ver en el Tabla 2, donde las filas represen-tan los programas que están siendo probados y las columnas indican los mutantes que murieron,los que resultaron ser equivalentes y los que fueron erróneos. Además, se muestra entre paréntesisel número de mutantes obtenidos para cada operador, totalizando el número de mutantes gene-

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 11 / 15

Page 87: y V Taller de Programación Funcional (TPF)

Tabla 2: Resultados de los experimentos para operadores de mutación de clase

Muertos Equivalentes Erróneos ∑

GarageIHI(2), IPC(2), CID(3), IOD(2) AMC(15) CDD(2) CID(2) AMC(3) AAC(2)

339 19 5

Family

IOD(2) IPC(2) ISD(2) IOP(2) AMC(14) IHI(3) AMC(6) AAC(4)

61MBC(10) MNC(2) CID(5) CCA(2) MBC(3) CDD(3) PPD(1)

27 23 11

Simul

IOD(1) ISI(1) ISD(1) IOP(2) AMC(45) ISD(1) ISI(4) AMC(1)

OAN(6) EHR(2) EHC(2) MBC(12) EHR(8) EHC(8) EXS(5)144

MNC(38) CID(2) PVI(1) CDD(1) MBC(1) AAC(2)

69 74 1

∑ 105 116 17

rados por cada programa en la última columna y el número de mutantes que resultaron muertos,equivalentes o erróneos en la última fila. Debido a que muchos de los operadores podían crearmás de un mutante al ser aplicados en distintas partes del código, algunos de ellos aparecen enmás de una columna para un mismo programa al dar un resultado diferente cada uno de ellos(por ejemplo, algunos de los mutantes originados con MBC fueron matados, mientras otros eranequivalentes).

Respecto a los casos de prueba, tras estudiar los resultados, se puede obtener un conjunto decasos de prueba mínimo con el cual se maten todos los mutantes mostrados. Para la aplicacióngarage, un escenario que intenta añadir un vehículo al aparcamiento cuando está completo fuesuficiente. Por su parte en family, además de un escenario simple de uso del programa, uno másfue incluido en el que se realizaba una copia de objetos para matar mutantes de CCA, MBC yMNC. Por último, cuatro casos de prueba que simulaban diferentes funcionalidades del uso deuna pantalla en simul mataban casi todos los mutantes, pero uno más fue necesario para variosmutantes de OAN y otro para el de PVI.

4.2 Análisis de los resultados y evaluación de los operadores

Con esta primera aproximación del uso de la técnica con operadores a nivel de clase para C++,se pueden obtener ya algunas conclusiones. En primer lugar, se puede observar qué operadoresparecen los más probables de aparecer en cualquier aplicación. Por ejemplo, los operadores delbloque de herencia o relacionados con el control de acceso son frecuentes. En contraste, losoperadores del grupo de polimorfismo no son tan usuales. También los operadores de manejode excepciones y sobrecarga de método necesitan el uso específico de esas características parapoder generar mutantes. En la misma línea, algunos operadores, debido a sus características, amenudo generan un mayor número de mutantes que otros. Es el caso de AMC o MBC, que comose puede ver en el Tabla 2, crearon muchos mutantes, mientras que operadores como PVI o PPDtan solo generaron uno.

Además, se puede hacer un análisis de la relación de mutantes muertos y equivalentes que hansurgido en los programas. En dos de ellos el número de mutantes equivalentes fue mayor al de

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 12 / 15

Page 88: y V Taller de Programación Funcional (TPF)

matados (garage y simul), mientras que en family fue mayor el de mutantes muertos. Esto haceque en la suma total se obtengan más equivalentes (116) que muertos (105), lo que supone másdel 52% de equivalentes en promedio (eliminando del cálculo los erróneos). En [OMK06] paraJava, también se refrenda que el porcentaje de equivalencia es muy elevado (mayor del 70%). Elnúmero de mutantes erróneos es menor que el de muertos y equivalentes en todos los casos.

Por último, algunos operadores pueden ser evaluados respecto a sus resultados. Operadorescomo OAN y PVI parecen interesantes, ya que necesitaron de un nuevo escenario para ser de-tectados, lo cual es importante en esta técnica ya que es lo que permite mejorar el conjuntode casos de prueba. Para probar el operador PVI en simul, fue creado un caso de prueba con-creto en el que se utilizaba una referencia de la clase cursor_controller que apuntaba al objetode screen_controller. Así, con la mutación introducida, se invocaba al método move de la clasederivada en lugar del de la clase base.

Para probar el operador CCA en family, también se hizo necesaria la inclusión de un caso deprueba, en el que se realizaba una copia de objetos que también permitió matar mutantes de MBCy MNC. Sin embargo, el cambio en el mutante de CCA es captado más adelante cuando el métododestructor es llamado. En este punto, cuando un objeto es destruido, el bloque de memoria al queapunta el objeto es liberado. La copia del objeto realizada también apunta al mismo bloque dememoria por lo que, cuando se ejecuta la destrucción del objeto, se produce un error al tratar deliberar la misma zona de memoria.

Por otra parte, parece que AMC y AAC, que son relativos al control de acceso, casi siemprecrean mutantes que no útiles para las pruebas, ya que o son equivalentes o erróneos. Este hechoha sido discutido para AMC en [OMK06] y parece muy paralelo a AAC, siendo muy probablepor ello que ambos sean excluidos del conjunto final.

Los mutantes derivados de CDD normalmente son equivalentes debido a que el método des-tructor suele solo ser invocado a la finalización del programa, simplemente para liberar la me-moria. En el caso del programa simul, se imprime un mensaje cuando la pantalla es destruida,constituyendo esto una diferencia entre el programa original y el mutante que origina. No obs-tante, si el uso de la memoria es un recurso importante, este operador puede ser útil recurriendoa una aplicación auxiliar como valgrind a fin de observar como se gestiona la memoria.

5 Conclusiones y Trabajo Futuro

El propósito de este artículo es el de mostrar un conjunto de operadores de mutación para ellenguaje C++ relativo a las propiedades del paradigma de orientación a objetos. La prueba demutaciones es una técnica dependiente del lenguaje, al menos, en cuanto a los operadores demutación se refiere. En ese sentido, el estudio que se ha llevado a cabo supone una importantecontribución respecto al desarrollo alrededor de la técnica, así como a la representación de unlenguaje destacado como es C++, ya que no hay ningún artículo que se centre específicamenteen mostrar un conjunto de operadores de mutación para este lenguaje. Además, estos operadoreshan sido analizados a través de un experimento realizado con algunos programas, con el objetivode obtener una idea general del comportamiento que muestran los operadores antes de automati-zarlos en el framework de prueba de mutaciones para C++. Este análisis nos ha servido tambiénpara completar la definición de algunos operadores al observar ciertas características del lenguaje

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 13 / 15

Page 89: y V Taller de Programación Funcional (TPF)

que les afectaban.Como conclusiones de este análisis, podemos citar la tendencia de algunos operadores a ge-

nerar un gran número de mutantes no útiles para asegurar la calidad de un conjunto de casosde prueba ya que, o bien crean una gran cantidad de mutantes equivalentes o erróneos, o biengeneran mutantes que son matados con facilidad, lo cual tampoco es bueno en esta técnica. Engeneral, serán necesarios unos experimentos más amplios para verificar el comportamiento detodos los operadores y la técnica en la composición de un conjunto de pruebas de calidad.

Como trabajo futuro, dividiremos nuestros esfuerzos en varias ramas. En primer lugar, con-tinuaremos con el refinamiento de nuestro conjunto de operadores de mutación y se estudiarála posibilidad de introducir nuevos operadores de acuerdo a propiedades que aún no han sidocubiertas (como la revisión del nuevo estándar C++11). También es posible obtener un conjuntode operadores con el estudio de un nivel diferente al de la orientación a objetos.

En segundo lugar, ya se ha comenzado a desarrollar el framework que nos permita aplicar laprueba de mutaciones a código C++, en la que se implementarán los operadores aquí mostrados.Por otra parte, en las pruebas realizadas, sin haber considerado una gran cantidad de clases, elnúmero de mutantes es alto si tenemos en cuenta además que cada uno de ellos tendrá que sercompilado, enlazado y ejecutado frente al conjunto de casos de prueba. El gran coste en compu-tación es una de las grandes dificultades de la prueba de mutaciones. Es por ello por lo que, unavez obtenido ese framework, también se desea evaluar la técnica de prueba de mutación evoluti-va [DEGM11] en un entorno de orientación a objetos, como técnica que nos permite reducir elcoste computacional sin pérdida significativa de la efectividad en la prueba de mutaciones.

Referencias

[Che01] P. Chevalley. Applying mutation analysis for object-oriented programs using a re-flective approach. In Software Engineering Conference, 2001. APSEC 2001. EighthAsia-Pacific. Pp. 267 – 270. dec. 2001.doi:10.1109/APSEC.2001.991487

[DEGM11] J. Domínguez-Jiménez, A. Estero-Botaro, A. García-Domínguez, I. Medina-Bulo.Evolutionary Mutation Testing. Information and Software Technology 53(10):1108–1123, Oct. 2011.doi:10.1016/j.infsof.2011.03.008

[Der03] A. Derezinska. Object-Oriented Mutation to Asses the Quality of Tests. In Pro-ceedings of the 29th Conference on EUROMICRO. Pp. 417–420. IEEE ComputerSociety, Belek, Turkey, 2003.

[Der06] A. Derezinska. Quality Assessment of Mutation Operators Dedicated for C# Pro-grams. In Kellenberger (ed.), Proceedings of VI International Conference on Qua-lity Software. Pp. 227–234. IEEE Computer Society, Beijing (China), Oct. 2006.ISSN 1550-6002.doi:10.1109/QSIC.2006.51

[HB09] C. Horstmann, T. Budd. Big C++. Wiley, 2nd edition, 2009.

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 14 / 15

Page 90: y V Taller de Programación Funcional (TPF)

[JH11] Y. Jia, M. Harman. An Analysis and Survey of the Development of Mutation Tes-ting. Software Engineering, IEEE Transactions on 37(5):649–678, Oct. 2011.doi:10.1109/TSE.2010.62

[KCM00] S. Kim, J. Clark, J. McDermid. Class mutation: Mutation testing for object-orientedprograms. In Proc. Net. ObjectDays. Pp. 9–12. 2000.

[MKO02] Y. S. Ma, Y. R. Kwon, J. Offutt. Inter-Class Mutation Operators for Java. In Ka-wada (ed.), Proceedings of XIII International Symposium on Software ReliabilityEngineering. Pp. 352–363. IEEE Computer Society, Annapolis (Maryland), Nov.2002. ISSRE 2002.

[OMK06] J. Offutt, Y. S. Ma, Y. R. Kwon. The class-level mutants of MuJava. In Anderson(ed.), Proceedings of the 2006 International Workshop on Automation of SoftwareTest. Pp. 78–84. ACM, Shanghai (China), May 2006.doi:http://dx.doi.org/10.1145/1138929.1138945

[OU01] A. J. Offutt, R. H. Untch. Mutation testing for the new century. In Wong (ed.). Chap-ter Mutation 2000: uniting the orthogonal, pp. 34–44. Kluwer Academic Publishers,Norwell, MA, USA, 2001.

[RPO13] P. Reales Mateo, M. Polo Usaola, J. Offutt. Mutation at the multi-class and systemlevels. Science of Computer Programming 78(4):364 – 387, 2013. Special sectionon Mutation Testing and Analysis (Mutation 2010) and Special section on the Pro-gramming Languages track at the 25th ACM Symposium on Applied Computing.doi:10.1016/j.scico.2012.02.005

[Str97] B. Stroustrup. The C++ Programming Language, Third Edition. Addison-WesleyLongman Publishing Co., Inc., Boston, MA, USA, 3rd edition, 1997.

[Tes] LLVM Testing Infrastructure: test suite. Último acceso: 01/03/2013.http://llvm.org/docs/TestingGuide.html

Operadores de Mutación a Nivel de Clase para el Lenguaje C++ 15 / 15

Page 91: y V Taller de Programación Funcional (TPF)

Testing Java with QuickCheck

Clara Benac Earle1, Lars-Ake Fredlund1

1Facultad de Informatica, Universidad Politecnica de Madrid, Spain

Abstract: The paper describes an approach to testing Java code which uses theQuviq QuickCheck tool. As the QuickCheck tool is written in the Erlang program-ming language, a library written by us is used to interface Erlang and Java withoutthe need to write boilerplate code. The resulting testing methodology has been ap-plied to evaluate student Java exercises at the Facultad de Informatica of UniversidadPolitecnica de Madrid.

Keywords: Software Testing, Java, Erlang

Acknowledgements: The authors were supported by the DESAFIOS 10 project (TIN2009-14599-C03-O3) financed by the (former) Spanish Ministry of Education and Science, and theEU FP7 project PROWESS (317820).

1 Introduction

This paper describes a methodology for testing Java code which uses the property-based randomtesting Quviq QuickCheck tool [AHJW06], in the following often abbreviated as QuickCheck.Rather than writing individual “low-level” test cases, a QuickCheck user writes “high-level”properties, which are parametric on test data generators.

As a concrete example, to test a sorting function sort in Erlang using “normal” testing wewould sort a few representative lists and compare the result with the expected answer:

sort([]) == [], sort([3,1,2]) == [1,2,3], sort([5,5]) == [5,5]

A QuickCheck user would instead specify a property:

∀L : list(integer) . isSorted(sort(L),L)

or in concrete QuickCheck syntax:

?FORALL(L,list(int()),isSorted(sort(L),L))

The expression list(int()) is a generator of (Erlang) integer lists, that is, a recipe understoodby QuickCheck for generating a random integer list. The Erlang function isSorted is a userprovided predicate which checks that its first parameter is the second parameter sorted.

When testing such a test property, QuickCheck generates, randomly, a large number of integerlists, and checks that the isSorted predicate when invoked on each list returns true.

To ease the task of developing test properties, QuickCheck includes a number of libraries. Inthis work the eqc statem state machine library is used extensively. It is a library which easesthe task of checking stateful code – a good fit since almost all of Java code is stateful.

Testing Java with QuickCheck 1 / 15

Page 92: y V Taller de Programación Funcional (TPF)

As Quviq QuickCheck provides no special facilities for testing Java code, and there are ver-sions of QuickCheck adapted for Java (Java QuickCheck1 and ScalaCheck2), it might seem sur-prising that we choose to use Quviq QuickCheck which uses Erlang as its basis. The reasons aretwofold: Quviq QuickCheck is a mature tool, especially compared with Java QuickCheck, andwe consider Erlang to be a better modelling language than Java and Scala.

Using Quviq QuickCheck to check Java code is in practice not very difficult but rather tedious.The Erlang standard library Jinterface permits communication between Erlang and Java,unfortunately requiring us to write a lot of Java boilerplate code for each Java program tested. Toeliminate this source of testing inefficiency we designed a new Erlang library JavaErlang3

on top of Jinterface, which removes the need to write boilerplate code.In the following we assume a basic knowledge of the Erlang programming language. In Sec-

tion 2 we briefly describe Quviq QuickCheck and the eqc statem state machine library, thenin Section 3 we describe the new Java interface library. Section 4 contains a small case studyillustrating the whole approach, and Section 5 summarizes our experiences with using the result-ing testing methodology for evaluating student Java exercises at the Facultad de Informatica atthe Universidad Politecnica de Madrid. Finally Section 6 draws some preliminary conclusions.

2 Quviq QuickCheck

The basic functionality of Quviq QuickCheck is simple: when supplied with an Erlang data termthat encodes a boolean property, which may contain universally quantified variables, QuickCheckgenerates a random instantiation of the variables, and checks that the resulting boolean propertyis true. This procedure is by default repeated at most 100 times. If for some instantiation theproperty returns false, or a runtime exception occurs, an error has been found and testing termi-nates.

A few examples will serve to make this more concrete. QuickCheck contains a definitionof a function nat which returns a generator of natural numbers, that is, a recipe executable byQuickCheck for generating a random natural number.

The Erlang function definition below

prop1() -> ?FORALL(X,nat(),?FORALL(Y,nat(),X==Y)).

binds the Erlang function prop1 to a QuickCheck property that checks whether two (macro)variables X and Y bound to natural numbers are equal.

Since two randomly selected numbers will with low probability be equal QuickCheck rapidlyfinds an error (we assume that prop1 is defined in a module test, and use the Erlang shell):

> eqc:quickcheck(test:prop1())....Failed! After 4 tests.01

The natural numbers 0 and 1 are the witnesses found for which the property fails.

1 https://bitbucket.org/blob79/quickcheck2 http://code.google.com/p/scalacheck/3 [email protected]:fredlund/JavaErlang.git

Testing Java with QuickCheck 2 / 15

Page 93: y V Taller de Programación Funcional (TPF)

Functions for test generation:

initial_state() returns the initial test generation statecommand(State) generates a symbolic call on the format

call, Module, Function, Argsprecondition(State,Call) returns true if the symbolic call Call is sen-

sible given the current test generation statenext_state(State,Var,Call) returns the next test generation state after a

call

Functions for test execution:

initial_state() returns the initial test execution statepostcondition(State,Call,Result) returns true if the result of a call matches the

expected valuenext_state(State,Result,Call) returns the next test execution state

Figure 1: eqc_statem callback functions

More complex data generators can be built by referring to simpler ones – list(nat()) gen-erates lists of natural numbers – or by using recursion. We can for instance check that the lengthof a randomly generated list is always less than 10: ?FORALL(L,list(nat()),length(L)<10).

For checking stateful code, i.e., in the case of Erlang functions that have side effects, QuickCheckprovides the eqc_statem library. Here the tested “object” is not a simple boolean property, butrather a sequence of function calls each with an associated post condition that determines whetherthe execution of a call was successful or not. The data generator for the state machine librarygenerates sequences of (symbolic) function calls.

Concretely to use the eqc_statem library, a user has to supply a “callback” module with a setof functions with predefined names. The functions defined in the callback module are called byQuickcheck during test generation (constructing a sequence of calls) and test execution (checkingthat the execution of the sequence of calls succeeds); Figure 1 contains the list of functions.

During test generation a test generation state is used, which can be used to determine the nextgenerated call based on the history of calls generated so far. Similarly during test execution atest execution state is used, which can be used to check that a call returns the expected resultconsidering the history of calls executed so far (and their results).

Note that the initial_state and next_state functions are reused both during test gener-ation and test execution.

As an example, suppose we have implemented a stateful list in Erlang using the func-tions stateful:add and stateful:is_member, then the last function call in the sequencestateful:add(1), stateful:add(2), stateful:is_member(1) should return true.To test and check the above API the callback module in Figure 2 is used.

In the callback module, oneof is a QuickCheck predefined generator that randomly uses oneof the generators in its parameter list, call, stateful, add, [nat()] is a symboliccall to stateful:add with a random natural number parameter, [Value|State] is Erlang list

Testing Java with QuickCheck 3 / 15

Page 94: y V Taller de Programación Funcional (TPF)

-module(stateful_sm).

-include_lib("eqc/include/eqc.hrl").-compile(export_all).

initial_state() -> [].

command(State) ->oneof([call, stateful, add, [nat()],

call, stateful, is_member, [nat()]]).

precondition(State,Call) -> true.

next_state(State,_,Call) ->case Call of

call, stateful, add, [Value] -> [Value|State];_ -> State

end.

postcondition(State,Call,Result) ->case Call of

call, stateful, is_member, [Value] ->Result==lists:member(Value,State);

_ ->true

end.

Figure 2: A eqc_statem callback module for checking the stateful API

Testing Java with QuickCheck 4 / 15

Page 95: y V Taller de Programación Funcional (TPF)

concatenation, and lists:member(Value,State) is a built-in Erlang function for checkingthat Value is a member of the list State. Note that we update the state only when add iscalled as it is the only function that modifies the state. The only postcondition checked is foris_member, where the real value returned by the function call – Result – is compared to thevalue predicted by the model state – lists:member(Value,State).

3 The JavaErlang Library

Erlang already provides support for permitting Erlang and Java code to communicate via theJinterface library included in Erlang/OTP. The library in essence provides the following func-tionality:

• support for implementing a Java node which can connect with Erlang (distributed) nodes,permitting Erlang processes to send messages to the Java node.

• a facility for encoding Erlang data terms as Java objects.

To enable communication between an Erlang process and a Java node the Erlang processshould send a normal Erlang term, which Jinterface presents to the Java node as a Javaobject having the same term structure as the sent Erlang term. That is, Jinterface providesJava classes corresponding to Erlang atoms (e.g., the Java class OtpErlangAtom), integers,lists, tuples (the class OtpErlangTuple), etc. A Java node that wishes to send a message to anErlang process should encode the message using the above Java classes for Erlang data types.Thus the Erlang processes communicate using normal Erlang terms while the Java node workswith Erlang terms encoded as Java objects.

As an example, if an Erlang process wants the Java node to invoke a static method m(10), wecould let Erlang send a message call_m, 10, and have the Java node execute the followingcode to interpret and execute the request:

OtpErlangObject msg = msgs.receive();if (msg instanceof OtpErlangTuple)

OtpErlangTuple t = (OtpErlangTuple) msg;if (t.arity() == 2 && t.elementAt(0) instanceof OtpErlangAtom)

String tag = ((OtpErlangAtom) t.elementAt(0)).atomValue();if (tag.equals("call_m"))

int i = ((OtpErlangInt) t.elementAt(1)).intValue();// Finally time to do the Java callm(i);

else ... else ...

else ...

Clearly there are a number of obvious disadvantages to this approach. First, there has to bea prior agreement between Java and Erlang on a shared vocabulary (typically communicated astuples as seen in the example above). This typically causes a Jinterface user to write a lotof boiler-plate Java code. Secondly, while it is clear how to communicate primitive Java values(and arrays) to and from Erlang, how are Java object references communicated?

Testing Java with QuickCheck 5 / 15

Page 96: y V Taller de Programación Funcional (TPF)

The JavaErlang library4 was born to address these limitations. JavaErlang is build on topof Jinterface, but provides more convenient mechanisms for enabling Erlang processes tointeract with Java. The principal advantages of JavaErlang are:

• All public Java methods and fields of classes and objects are callable without prior agree-ment between Java and Erlang

• No Java coding needed at all

• Java references can be communicated freely with Erlang

As a small example, the following is a simple usage of the library (using the Erlang shell):

1 > ok,Node = java:start_node().2 ok,1003 > Int10a = java:new(Node,’java.lang.Integer’,[10]).4 object,0,1005 > Int10b = java:new(Node,’java.lang.Integer’,[10]).6 object,1,1007 > java:call(Int10a,equals,[Int10b]).8 true9 > java:call(Int10a,equals,[java:new(Node,’java.lang.Integer’,[7])]).

10 false

In the example we first start a new Java node, and let Erlang connect to that node. Then,two Java Integer objects are created on the Java node, both initialized to the value 10 (lines3 and 5). Internally this corresponds to calling the Integer(int value) constructor of theInteger class. The first call to java:new returns a tuple object,0,100 corresponding tothe representation in Erlang of a Java object. The library ensures that the same object always hasthe same Erlang representation, thus it is possible to test two object representations for equalityusing normal Erlang term equality. Next, we check using the Integer class instance methodequals that the first integer is equal to the second. Finally we create a third integer, initializedto 7, and check that it does not compare equal to the first.

Note that the example is entirely self-contained. There is for instance no need to analyze orcompile the Java libraries before they become usable from Erlang. Neither does the exampleassume that a Java interpreter has already been started; the Java runtime is started using the calljava:start_node(). Third-party libraries are automatically made available too (as long asErlang is informed of the location of these libraries). Moreover the entire Java API is supported,with a few exceptions regarding class creation noted in the future work section below.

Below we summarize the java module API, assuming that Node is a Java node identifier,Class is the Erlang atom corresponding to a Java class, Method is an Erlang atom naming amethod, and Field is an atom naming an field:

4 [email protected]:fredlund/JavaErlang.git

Testing Java with QuickCheck 6 / 15

Page 97: y V Taller de Programación Funcional (TPF)

new(Node,Class,[Arg1,...,Argn]) create objectcall(Object,Method,[Arg1,...,Argn]) invoke instance methodcall_static(Class,Method,[Arg1,...,Argn]) invoke class methodget(Object,Field) access an instance fieldset(Object,Field,Value) modifies an instance field

A number of function variants are omitted, e.g., functions for getting and setting class fields,and several functions which explicitly specify the type of a method invocation. For further detailsconsult the library API documentation.

3.1 Internal Design

Internally the library makes heavy use of the Java reflection capability, as provided by the pack-age java.lang.reflect. Below we sketch the major steps in the implementation of thejava:new function.

1. When the new function is invoked, the Erlang part of the library sends a message to theJava node with the name of the class and the actual parameters.

2. Upon receiving such a message the Java portion of the library then searches for a matchingclass.

3. Given a class, the library attempts to find a particular class constructor whose type matchesthe derived type of the actual parameters. As an option, a user can explicitly specify thedesired constructor by supplying an extra parameter to the new function.

4. If a constructor is found, the Java side then invokes the constructor using reflection.

5. If invocation is successful Java records an association between the new Java object ref-erence and a fresh Erlang object tuple “object,Node,ObjectId” (an Erlang objectreference), where the ObjectId is simply an integer counter. This association is used tomarshall the results of method calls. That is, it is used for translating Java object referencesto Erlang object references consistently in Java-to-Erlang communications.

If the invocation is unsuccessful the Java side instead associates the resulting exceptionobject with a fresh Erlang object reference.

6. Next the resulting value, a new object reference, or an exception, is returned to the Erlangside using message passing.

7. The Erlang side examines the result and either simply returns it to the caller, or, if theresult was an exception, raises an Erlang exception.

The inverse object mapping, from an Erlang object reference to a Java object reference, is kepttoo, and is used for Erlang-to-Java (un)marshalling. It is used, for example, at the Java side tolookup the real Java object when an instance method is invoked.

Testing Java with QuickCheck 7 / 15

Page 98: y V Taller de Programación Funcional (TPF)

3.2 Java Threads

By default there is a 1-1 mapping between Erlang processes and Java threads. That is, an Erlangprocess making a Java call will not block because another Erlang process is making a Java call.

3.3 Java Values in Erlang

To ease the task of working with Java in Erlang the library duplicates a number of tasks of aJava runtime, e.g., providing boxing and unboxing of primitive values and objects, providingfunctions for convenient access and creation of Java arrays, and also mapping Java primitivevalues to suitable Erlang primitive values.

As an example, the Java null value is represented as the Erlang atom null, and the Javaboolean values true and false are represented as the corresponding atoms true and false,and integer-like types and floating-point-like types are represented as normal Erlang integersand floats. When our heuristic type conversions fail, values can be explicitly type cast usingthe notation Type,Value. Java arrays can be constructed using the normal Erlang syntaxfor lists and strings. Some data construction examples using explicit type casts: a Java shortinteger short,5, a Java character char,$a, and a one-dimensional Java character arrayarray,char,1,"Hello World".

3.4 Limitations and Future Work

The library has a number of practical limitations. The most severe is the inability to automaticallygarbage collect a Java object that has been communicated to Erlang, as the Java side cannot tellwhen the Erlang side stops referring to it. This limitation is perhaps not critical for testingpurposes, but it is a severe limitation that should be addressed in future work.

Another rather severe limitation is speed – every communication between Erlang and Javaentails a (currently rather inefficient) encoding of the data being interchanged.

On a more fundamental level, the Java reflection facilities does not provide ade-quate support for creating new classes. Java does contain support for creating class in-stances with a tailored implementation (e.g., implementable in Erlang) using Java “proxies”(java.lang.reflect.Proxy) , and the JavaErlang library could be extended to use this fea-ture. However, in a few cases the Java API mandates5 creating a new class. A JavaErlang usercould of course write such a new class in Java, but it would be preferable if no Java code had tobe written at all. To enable such a class creation feature the library could probably use one of thebyte code instrumentation packages available for Java.

4 A Case Study – Testing the Java HashSet Class

As an example, this section illustrates how (a small part of) the Java java.util.HashSet

standard class6 can be tested using a combination of QuickCheck and JavaErlang.

5 One such example are the event listeners of the Swing API which are defined using an abstract class which createsproblems for the Java proxy API6 documented in e.g. http://docs.oracle.com/javase/6/docs/api/java/util/HashSet.html

Testing Java with QuickCheck 8 / 15

Page 99: y V Taller de Programación Funcional (TPF)

Figure 3 contains the source code for the Erlang state machine model. To reduce the size ofthe example we restrict attention to one constructor HashSet() and three instance methods ofthe HashSet class: add(E e) which adds an element to the set, contains(Object e) whichchecks if the object parameter contains the specified element, and remove(Object e) whichremoves the element argument from the set.

The eqc_statem state maps the state identity (during test execution the actual HashSetobject reference) to an Erlang set containing the elements of the set, represented as a list oftuples [Object1,SetContents1,...,ObjectN,SetContentsN].

The command(State) function generates randomly either a set constructor, or, for each setthat has been created, adds a random natural number, removes a random natural number, orchecks whether a random natural number is a member of the set. For example, the symboliccall call,java,new,[call,erlang,get,[node],’java.util.HashSet’,[]]creates a new HashSet by executing java:new(get(node),’java.util.HashSet’,[]),where we assume that get(node) retrieves a Java node identi-fier stored in the Erlang process registry. As a second example,[call,java,call,[Set,add,[nat()]]|| Set,_<- State] is the list of symbolicfunction calls java:call(Set,add,[N]) where Set is a Java HashSet and N is a randomnatural number.

The precondition function only checks that each call to a HashSet method is performedwith a valid set object. This is in fact already guaranteed by the command function, but QuickCheckmay during an attempt to reduce the size of the counterexample presented (the reduction orshrinking functionality is not further discussed in this paper) violate this precondition.

As commented earlier, the function next_state is executed both during test case generation(to update the test generation state), and during test case execution (to update the test executionstate). The next_state function should returns the new state after the execution (or generation)of the symbolic call Call, in the current state State, and where the result of the call is boundto Var. Both the test generation and test execution states have the same type, a map fromobject identifier to an Erlang set, except that the object identifier is symbolic (e.g., on the formvar,10 during test generation). Clearly we have to update the state for the operations thatcreate a new set, or change the contents of a set, that is, the constructor, and the instance methodsadd and remove.

Finally, the postcondition function checks that the return value of a call is the right one,considering the current test execution state. Here we care only for the return value of contains,which should return true if and only if the test execution state contains the object parameter.

Next, in Figure 4 we show the actual function used to invoke QuickCheck. Basically,first a list of commands is generated ?FORALL(Cmds,eqc_statem:commands(hashset),repeatedly calls the function hashset:command(...) to generate a single command.Next, a new Java node is spawned, and its identity is stored in the Erlang process reg-istry put(node,Node). Then the generated list of commands is run, using the func-tion eqc_statem:run_commands(hashset,Cmds), which executes the commands se-quentially. During the execution the test execution state is updated by calling thehashset:next_state function after each command, and command postconditions arechecked using the hashset:postcondition function.

Testing the HashSet implementation using the QuickCheck state machine model in Figure 3

Testing Java with QuickCheck 9 / 15

Page 100: y V Taller de Programación Funcional (TPF)

1 -module(hashset).23 -include_lib("eqc/include/eqc.hrl").4 -compile(export_all).56 initial_state() -> [].78 command(State) ->9 eqc_gen:oneof

10 ([call,java,new,[call,erlang,get,[node],’java.util.HashSet’,[]]] ++11 [call,java,call,[Set,add,[nat()]] || Set,_ <- State] ++12 [call,java,call,[Set,contains,[nat()]] || Set,_ <- State] ++13 [call,java,call,[Set,remove,[nat()]] || Set,_ <- State]).1415 precondition(State,Call) ->16 case Call of17 _,_,call,[Set,_SetOperation,_] ->18 lists:keymember(Set, 1, State);19 _ ->20 true21 end.2223 next_state(State,Var,Call) ->24 case Call of25 _,_,new,_ ->26 [Var,sets:new()|State];27 _,_,call,[Set,add,Elem] ->28 _,ESet = lists:keyfind(Set, 1, State),29 NewESet = sets:add_element(Elem,ESet),30 lists:keyreplace(Set, 1, State, Set,NewESet);31 _,_,call,[Set,remove,Elem] ->32 _,ESet = lists:keyfind(Set, 1, State),33 NewESet = sets:del_element(Elem,ESet),34 lists:keyreplace(Set, 1, State, Set,NewESet);35 _ ->36 State37 end.3839 postcondition(State,Call,Result) ->40 case Call of41 _,_,_,[Set,contains,Elem] ->42 _,ESet = lists:keyfind(Set,1,State),43 Result==sets:is_element(Elem,ESet);44 _ ->45 true46 end.

Figure 3: Erlang State Machine model for Java HashSet’s

Testing Java with QuickCheck 10 / 15

Page 101: y V Taller de Programación Funcional (TPF)

-module(hashset_test).

-include_lib("eqc/include/eqc.hrl").-compile(export_all).

test() ->eqc:quickcheck

(?FORALL(Cmds,eqc_statem:commands(hashset),begin

ok,Node = java:start_node(),put(node,Node),H,DS,Res = eqc_statem:run_commands(hashset,Cmds),java:terminate(get(node)),Res==ok

end)).

Figure 4: QuickCheck code for executing tests

does not reveal any bug, as expected. However, we can simulate a bug by changing the testmodel. By removing the clause at lines 31–34 in Figure 3 – the handling of remove in thefunction next_state we are effectively stating that removing an element has no effect on thetest state. Rerunning QuickCheck now results in the error report shown in Figure 5.

The symbolic test case indicates that a postcondition failed if we first create a new HashSet,then add the natural number 0, then remove 0, and check whether the set contains 0. Here, sincewe stated that removal of elements has no effect on the state, the test execution state still contains0, and thus in the model contains returns true, whereas in the actual Java execution of coursefalse is returned.

5 Experiences in Teaching

The methodology of using QuickCheck and JavaErlang to check Java code has been applied inthe course “Algoritmos y Estructuras de Datos” at the Facultad de Informatica of UniversidadPolitecnica de Madrid, to evaluate student Java exercises.

The students in this course both submit larger works (e.g., a finite-state automaton library) andmodify and complete smaller exercises (e.g., sorting a list). For both types of exercises we haveused the proposed framework to evaluate the resulting Java programs.

Fully automated evaluation or ranking of exercises is a difficult task, and one that is not pri-marily addressed by this paper. There are many metrics possible, e.g., percentage of test casesexecuted successfully, and more advanced approaches that try to directly compare the test fail-ures of students [CHP+10]. It is clear however that we should not rely solely on test satisfactionmeasures for ranking, but should rather use a combined approach measuring also aspects suchas e.g. source code complexity, and moreover should try to estimate computation complexitybounds.

Apart from using property-based testing for ranking, it has been an advantage to be able to

Testing Java with QuickCheck 11 / 15

Page 102: y V Taller de Programación Funcional (TPF)

$ erl -sname tstErlang R16B (erts-5.10.1) [source] [64-bit] [smp:4:4] ...

Eshell V5.10.1 (abort with ˆG)> hashset_test:test().(tst@sadrach)2> hashset_test:test().Starting Quviq QuickCheck version 1.28.1

(compiled at 2013,3,11,18,45,35)Licence for University UPM Madrid reserved until 2013,5,28,13,12,17......Failed! After 6 tests.[set,var,1,

call,java,new,[call,erlang,get,[node],’java.util.HashSet’,[]],set,var,2,call,java,call,[var,1,add,[0]],set,var,3,call,java,call,[var,1,remove,[0]],set,var,6,call,java,call,[var,1,contains,[0]]]

false

Figure 5: A Failing Testing Run

show students individualised exact (and short) error traces. Moreover, having to write an inde-pendent model of a problem, in a different language, clearly also has improved the quality ofthe proposed exercises. Finally, by observing the errors the students make, we gain insights intowhat the difficult parts of Java are, and can thus focus attention on these difficulties. This is inparticular the case for some types of errors found, which are even unlikely to have been spottedduring a manual inspection of the code (unless realised by a Java expert).

While no scientific effort has been made to quantify the time and resources required to createthese models the effort in our opinion has not been excessive. Creating state machine models isa learned skill, and since Java is a rather regular language, much model reuse is possible. Onesuch example of model reuse is the handling of Java iterators which can be treated in a genericfashion.

Models for smaller exercises can be built in a couple of hours by reusing earlier models, whileconstructing models for larger libraries such as e.g. the finite-state automaton library requiremore time. Since writing properties is similar to programming, of course we make mistakes alsowhen writing properties. Folklore7 states that when a program fails a test property the cause isin roughly 50% of the cases a real bug in the program tested, and in 50% of the cases the causeis a bug in the test property itself.

Below we discuss briefly some different types of bugs, or anti-patterns, encountered by theproposed framework when testing around a hundred student solutions to the assignment of im-plementing a finite automaton library. The assignment was to implement the basic functional-ity of deterministic and nondeterministic automata (storing states and transitions, implementingtransitive transition functions, finding accepting strings, etc), to more complex operations suchas e.g. determinizing a nondeterministic automaton, minimizing a deterministic automaton, andconverting a regular expression to a nondeterministic automaton, etc.

7 Reported by John Hughes

Testing Java with QuickCheck 12 / 15

Page 103: y V Taller de Programación Funcional (TPF)

• Boundary condition checking. Most errors encountered clearly concerned incorrectlytreated boundary conditions, such as e.g. failing to correctly minimize empty automatons,lending credit to the idea of focusing testing attention especially on these cases.

• Using “==” instead of “equals”. Many students used the “==” operator exclusively tocheck for equality, even though the objects compared were not created by them. A cor-rect solution would have been to use the equals method instead. Using “==” failed forinstance when comparing transition labels that were semantically equal but were createdat different times.

• Using iterators I. Most students used a Java HashSet to store for instance the states inan automaton. Unfortunately using this data structure correctly in Java is rather difficult.

Typical student code did the following:

HashSet<State> states = ...;for (State st : states)

states.addAll(epsilonClosure(st));

That is, the code iterated over the states of an automaton, and for each state, added alsothe states reached by a closure operation.

However, nondeterministically, such code failed with an exceptionjava.util.ConcurrentModificationException. This was rather surprisingto the students, as all student programs were single threaded. The Java documentation forthat exception states:

For example, it is not generally permissible for one thread to modify a Col-lection while another thread is iterating over it. In general, the results of theiteration are undefined under these circumstances. Some Iterator implemen-tations (including those of all the general purpose collection implementationsprovided by the JRE) may choose to throw this exception if this behavior is de-tected. Iterators that do this are known as fail-fast iterators, as they fail quicklyand cleanly, rather that risking arbitrary, non-deterministic behavior at an un-determined time in the future.Note that this exception does not always indicate that an object has been con-currently modified by a different thread. If a single thread issues a sequence ofmethod invocations that violates the contract of an object, the object may throwthis exception. For example, if a thread modifies a collection directly while it isiterating over the collection with a fail-fast iterator, the iterator will throw thisexception.

Clearly there was no attempt to access the same collection from different threads. How-ever, as the second paragraph states, this exception can also be raised by a single threaditerating over a collection, which during the iteration modifies the data structure.

In our opinion raising this exception is a rather unfortunate state-of-affairs, as it preventssome natural programming patterns. Solutions advocated range from adding elements to

Testing Java with QuickCheck 13 / 15

Page 104: y V Taller de Programación Funcional (TPF)

temporary data structures, or making a copy of the data structure before iterating, to usingthe add/remove operations supplied by iterators.

To improve the detection rate for this type of errors each test case was repeated a numberof times using the QuickCheck macro ?ALWAYS(N,Prop), which is equivalent to theproperty Prop except that it is tested N times (or until it fails). This is similar to howconcurrent programs are tested under QuickCheck.

• Modifying elements stored in a hashtable.

It was quite common student practice to first store an element (a state) in a hashtable, andthen modify it, and finally do a lookup in the hashtable using the object. The followingcode is an example:

HashSet<State> states = ...;State st = new State();st.accepting = false;states.add(st);// ...st.accepting = true;// ...if (states.contains(st)) ... // wrong

The final statement typically fails to locate the state in the hash table, as its hash code iscomputed with the help of the field accepting which was false at the time of storage,but true when the hash table is searched.

• Non-deterministic data structures are difficult (iterators II).

Surprisingly even though the student solutions were thought to be totally deterministic,and generated test cases certainly are8, running the same test case on the same studentsolution sometimes failed and sometimes succeeded.

The reason turned out to be related to the implementation of the HashTable data structureagain. The failing students used code similar to the following:

boolean found = false;State selected;

for (State st : states)if (!found && someConditionOnState(st))

found = true;selected = st;

// ...here selected was used to compute some result...

8 The test cases QuickCheck generated from the state-machine description were randomly generated, but once gen-erated, are deterministic.

Testing Java with QuickCheck 14 / 15

Page 105: y V Taller de Programación Funcional (TPF)

It turned out that the state table contained a number of states meeting the conditionsomeConditionOnState, but the condition was not sufficiently strict, leading to po-tentially selecting a bad state (later causing test failure).

For the HashTable data structure the order of elements returned by an iterator depends onthe hash code of an element. In this case the hash code of a state object was computedusing the default method, which uses an integer related to the location of the object in theheap. As the heap location is not stable from one machine to another, in practice it turnedout that ordering of elements returned by the iterator varied from one machine to another.

So, in some runs, an incorrect element was selected first, leading to a test failure, and inother runs, a correct element was selected first, leading to test success.

Fixing this type of (testing) problem is nontrivial, as we cannot really hope to changethe organization of the heap by e.g. repeated testing using the QuickCheck macro?ALWAYS(N,Prop), as we normally use a new Java runtime system for each new test.A solution would be to introduce an operation to randomize the heap somewhat beforerunning each test case, and then repeating each test case a number of times.

6 Conclusions

We have presented a methodology for testing Java code, using Quviq QuickCheck, and a libraryJavaErlang for easing the task of Erlang to Java communication. This methodology has beenused to evaluate student exercises in Java, and has proven successful at its task.

Apart from proving feedback regarding the relative quality of exercise solutions, it has alsoprovided us with valuable feedback regarding the trouble spots of Java. That is, those parts of thelanguage that are relatively poorly understood by novice practitioners, and where as teachers weshould focus attention. The experiment highlighted in particular the difficulty students have inusing hashing, clearly failing to understand how a hash code is computed, and what operationson an object are admissible when it is stored in a hash table.

Moreover, iterators over collections is another troublespot. The students regularly write codethat violates the restrictions regarding modifying a collection while simultaneously iterating overit. This is not surprising, as the restriction, from a functional programming point-of-view, is noteasy to comprehend.

Bibliography

[AHJW06] T. Arts, J. Hughes, J. Johansson, U. Wiger. Testing telecoms software with QuviqQuickCheck. In Proceedings of the 2006 ACM SIGPLAN workshop on Erlang. ER-LANG ’06, pp. 2–10. ACM, New York, NY, USA, 2006.

[CHP+10] K. Claessen, J. Hughes, M. Palka, N. Smallbone, H. Svensson. Ranking programsusing black box testing. In Proceedings of the 5th Workshop on Automation of Soft-ware Test. AST ’10, pp. 103–110. ACM, New York, NY, USA, 2010.

Testing Java with QuickCheck 15 / 15

Page 106: y V Taller de Programación Funcional (TPF)

Sesión 3: Abstraction and Analysis

106

Page 107: y V Taller de Programación Funcional (TPF)

Sesión 3: Abstraction and Analysis

12.45–13.15 Manuel Montenegro, Ricardo Peña, and Clara Segura:Shape Analysis in a Functional Language by Using Reg-ular Languages

13.15–13.45 Elvira Albert, Jesús Correas Fernández, Germán Puebla,and Guillermo Román-Díez: Quantified Abstractions ofDistributed Systems

107

Page 108: y V Taller de Programación Funcional (TPF)

Shape Analysis in a Functional Language by Using RegularLanguages

Manuel Montenegro1, Ricardo Pena2 and Clara Segura3

1 [email protected] [email protected] [email protected]

Departamento de Sistemas Informaticos y ComputacionUniversidad Complutense de Madrid, Spain ∗

Abstract: Shape analysis is concerned with the compile-time determination of the‘shape’ the heap may take at runtime, meaning by this the pointer chains that mayhappen within, and between, the data structures built by the program. This includesdetecting aliasing and sharing between the program variables.

Functional languages facilitates somehow this task due to the absence of variableupdating. Even though, sharing and aliasing are still possible. We present an abstractinterpretation-based analysis computing precise information about these relations.In fact, the analyis gives an information more precise than just the existence ofsharing. It informs about the path through which this sharing takes place. Thisinformation is critical in order to get a modular analysis and not to lose precisionwhen calling an already analysed function.

The main innovation with respect to the literature is the use of regular languages tospecify the possible pointer paths from a variable to its descendants. This additionalinformation makes the analysis much more precise while still being affordable interms of efficiency. We have implemented it and give convincing examples of itsprecision.

Keywords: functional languages, abstract interpretation, shape analysis, points-toanalysis, regular languages

1 Motivation

Shape analysis is concerned with statically determining the connections between program vari-ables through pointers in the heap that may occur at runtime. As particular cases it includes shar-ing and aliasing between variables. The computation of the shape of the heap for every possibleprogram execution is undecidable in general, but the analysis computes an over-approximationof this shape. This means that it may include relations that will never happen at runtime.

Much work has been done in imperative languages (see Sec. 6), specially for C. The sharingdetection is aggravated by the fact that variables are mutable, and they may point to differentplaces at different times. Also, for the sake of scalability, it is important for the analysis to be

∗ Work partially funded by the project S2009/TIC-1465 (PROMETIDOS).

Shape Analysis 1 / 15

Page 109: y V Taller de Programación Funcional (TPF)

modular. The results obtained for a function should summarize the shape information so that theuser functions should be able to compute all the sharing produced when calling it.

We have addressed the problem for a first order functional language. This simplifies some ofthe difficulties since variables do not mutate. A consequence is that the heap is never updated.It can only be increased with new data structures, or decreased by the garbage collector. But thelatter cannot produce effects in its live part. Our analysis puts the emphasis on three properties:(1) scalability; (2) precision; and (3) efficiency. Looked at from outside, a function may onlycreate sharing between its result and its arguments, or between the results themselves, but itcan never create new sharing between the arguments. The internal variables become dead afterthe call, so the result of analysing a function only contains its input-output sharing behaviour.Differently to previous works, we compute the paths through which this sharing may occur in aprecise way. This information is used to propagate to the caller the sharing created by a call. Inthis way, big programs can be analysed with a cost linear in the number of functions.

The motivation for our analysis is a type system we have developed for a functional languagewith explicit memory disposal [MPS08, MPS09]. This feature may create dangling pointersat runtime. The language also provides automatically allocated and deallocated heap regions,instead of having a runtime garbage collector. This feature can never create dangling pointers,so it plays no role in the current work and we will not mention it anymore. We have provedthat passing successfully the type inference phase gives total guarantee that there will not besuch dangling pointers. For typechecking a function, it is critical to know at compile time whichvariables may point to the disposed data structures, and for this a precise sharing analysis wasneeded. Nevertheless, we believe that the sharing analysis presented here could be equally usefulfor other purposes, since it provides precise information about the heap shape.

Our prior propotype shape analysis done in [PSM07] tracked those variables which may sharea common descendant, with no additional information. This was correct but imprecise, especiallyin function applications and case expressions, whose interpretation gave rise to some spuriousrelations. In order to avoid them, we should collect the paths through which this sharing occurs.

The main contribution of this paper with respect to [PSM07] is the incorporation of regularlanguages to our abstract domain. Each word of the language defines a pointer path within adata structure. Having regular languages introduces additional problems such as how to combinethem during the analysis, how to compare them, and specially how to guarantee that a fixpointwill be reached after a finite number of iterations. We show that we have increased the precisionof our prior analysis, and that the new problems can be tackled with a reasonable efficiency.

The plan of the paper is as follows: Sec. 2 provides a mild introduction to the analysis via asmall example. Then, secs. 3 and 4 contain all the technical material about the abstract domain,abstract interpretation rules, widening, decidability, and cost of the operations done on regu-lar expressions. Sec. 5 presents our implementation and gives more examples. Finally, Sec. 6concludes and discuss some related work.

2 Shape Analysis by Example

Our reference language Safe is a first-order eager language with a syntax similar to Haskell’s.Fig. 1 shows a mergesort algorithm written in Full-Safe. The compiler’s front-end processes

Shape Analysis 2 / 15

Page 110: y V Taller de Programación Funcional (TPF)

unshuffle [] = ([],[])unshuffle (x:xs) = (x:ys2, ys1)

where (ys1,ys2) = unshuffle xsmerge [] ys = ysmerge (x:xs) [] = x:xsmerge (x:xs) (y:ys) | x <= y = x : merge xs (y:ys)

| otherwise = y : merge (x:xs) ysmsort [] = []msort [x] = [x]msort xs = merge (msort xs1) (msort xs2)

where (xs1, xs2) = unshuffle xs

Figure 1: mergesort algorithm in Full-Safe

prog → datai;dec j;e Core-Safe programdec → f xi = e recursive, polymorphice → c literal of a basic type

| x variable| f ai function application|C ai constructor application| let x1 = e1 in e2 non-rec., monomorphic| case x of alti case expression

alt → C xi→ e case alternative

Figure 2: Simplified Core-Safe syntax

Full-Safe and produces a bare-bones functional language called Core-Safe. This transformationdesugars pattern matching into case expressions, transforms where clauses into let expressions,collapses several function-defining equations into a single one, and ensures unique names for thevariables. In Fig. 2 we show a simplified Core-Safe’s syntax. A program prog is a sequence ofpossibly recursive polymorphic data and function definitions followed by a main expression ewhose value is the program result. The abbreviation xi stands for x1 · · ·xn, for some n. In Fig. 3we show the translation to Core-Safe of the msort function of Fig. 1.

Our shape analysis infers the following sharing information for the functions unshuffle andmerge:

Σ(unshuffle) = res 12∗1+22∗1−→ • 2∗1←− xsΣ(merge) = res 2∗1−→ • 2∗1←− xs, res 2∗1−→ • 2∗1←− ys, res 2∗−→ • 2∗←− xs, res 2∗−→ • 2∗←− ys

The meaning for unshuffle is the following: the resulting tuple res of calling the function withan input list xs, may share the elements of this list. Moreover, the path reaching a common de-scendant, in the case of res, begins either with a 1 or a 2 (this should be understood as descendingto the left or to the right element of the tuple), and then follows by the path 2∗1, by this meaningthat we should take the tail of the (left or right) list a number of times, and then take the head.From xs’s point of view of, the common descendant can be reached by a similar path 2∗1.

The meaning for merge is quite precise: the resulting list res may share its elements with anyof the input lists xs and ys, and additionally one or more tails of res may be shared with one ormore tails of both xs and ys. This is what the path 2∗ means.

Shape Analysis 3 / 15

Page 111: y V Taller de Programación Funcional (TPF)

msort xs = case xs of[] -> []x:xx -> case xx of [] -> x:[]

_:_ -> let p = unshuffle xs inlet y1 = case p of (s1,s2) -> s1 inlet y2 = case p of (w1,w2) -> w2 inlet z1 = msort y1 inlet z2 = msort y2 inmerge z1 z2

Figure 3: Function msort in Core-Safe

When analysing msort’s code of Fig. 3, we have the information about unshuffle andmerge available. By substituting the actual arguments for the formal ones, we get the followingrelations:

R1 = p 12∗1+22∗1−→ • 2∗1←− xsR2 = res 2∗1−→ • 2∗1←− z1, res 2∗1−→ • 2∗1←− z2, res 2∗−→ • 2∗←− z1, res 2∗−→ • 2∗←− z2

The case and let expressions in msort introduce more relations:

R3 = xε−→• 1←− xs, y1

ε−→• 1←− p, y2ε−→• 2←− p

From these relations, we can derive other by reflexivity, symmetry and transitivity, such as:

R4 = y12∗1−→• 2∗1←− xs, y2

2∗1−→• 2∗1←− xs, y12∗1−→• 2∗1←− y2

In the first iteration of msort’s analysis, the only relation that can be inferred between its resultand its argument is xs 1−→ • 1←− res. This is due to the third line. The rest of the code givesus sharing information between the internal variables, but this cannot be propagated to the ar-guments, because in the internal recursive calls to msort we have nothing to start with. But,by interpreting the internal calls with the sharing information Σ1(msort) = xs 1−→ • 1←− res,we get the following bigger result: Σ2(msort) = xs 2∗1+1−→ • 2∗1+1←− res. If we interpret the code athird time by using this information when interpreting the internal calls, we get again the sameresult. So, a fixed point has been reached, and we consider this result as a correct approximationof the sharing created by msort.

It is worthwhile to remark that our prior analysis [PSM07] of the same program gave us theadditional spurious sharing information z2 −→ • ←− z1, meaning that a descendant of z2 isshared by z1 (the regular languages were absent in that analysis). Having spurious relations is notincorrect, but just imprecise. Since we used this analysis to type a destructive version of msort,using in turn a destructive version of merge, our type system rejected the function because ofthis additional sharing. The cause of this imprecision was a worse analysis of case expressionsand function applications due to the absence of the paths represented by the regular languages.

3 The Analysis

We formally define here the analysis approximating the runtime sharing relations between theprogram variables. At this point, types have already been inferred, so the analysis can ask for

Shape Analysis 4 / 15

Page 112: y V Taller de Programación Funcional (TPF)

type-related issues, such as the positions of constructor descendants, their types, and the like.

3.1 Sharing relation

In order to capture sharing, we define a binary relation between variables:

Definition 1 Given two variables x and y, in scope in an expression, a sharing relation is a setof two pairs (x, p1),(y, p2) specifying that x and y share a common descendant. Moreover, theregular languages denoted by p1 and p2 respectively define the possible pointer chains throughwhich x and y reach their common descendant. We shall such denote this sharing relation eitherby x

p1−→ • p2←− y or yp2−→ • p1←− x.

For the sake of readability, we shall assume p1 and p2 to be regular expressions that denoteregular languages, although the actual implementation works at the level of NFAs. Notice that,if p1 = ε , then x is a descendant of y, and symmetrically for p2.

The regular languages have pairs iC as alphabet symbols, where i is a natural number startingat 1, and C is a data constructor. The symbol iC denotes a singleton pointer path in the heap

passing through the i-th argument of constructor C. For instance, x2∗:−→ •

1(,)←− y indicates that atail of the list x is pointed-to by the first element of the tuple y. In the examples, we shall usuallyomit the constructor.

The relationp1−→ • p2←− is symmetrical by definition, reflexive by writing p1 = p2 = ε , but the

transitivity does not hold in general, i.e. xp1−→ • p2←− y and y

p3−→ • p4←− z, with p2 6= ε , does notnecessarily imply x

p1−→ • p4←− z. However, sometimes the transitivity holds, in particular when yreaches its common descendant with x through the same path as it reaches its common descen-dant with z. To be on the safe side of the analysis, we should then include x

p1−→• p4←− z wheneverwe have x

p1−→ • p2←− y and yp3−→ • p4←− z. This may introduce more sharing relations than those

occurring at runtime, and this was the main reason why our prior analysis was imprecise. Therules computing the sharing derived by transitivity are explained in detail in Section 3.3.

Now we can investigate the languages denoted by p2 and p3, and decide whether a path inp2 coincides with, or it is a prefix of, a path in p3, or the other way around. In these cases,there may exist a sharing path through y between x and z. Notice that both p2 and p3 are upperapproximations to the actual runtime paths, so the risk of imprecision is still there, but if thereare no such paths we are certain that there will not be paths at runtime either, and we can safelyomit a tuple relating x and z from the sharing relation.

3.2 The analysis rules

Based on the above considerations, we define an abstract interpretation S (meaning sharing)which, given an expression e and a set R containing an upper approximation to the sharingrelations between the variables in scope in e, delivers another set Rres (res stands for result)containing (an upper approximation to) all the relations between the result of evaluating e, namedres, and its variables in scope. To be precise, R and Rres will only record the minimum informationneeded in order to compute all possible sharing, i.e. if we have x

p1−→ • p2←− y in R or Rres, andp3 denotes all possible paths inside the data structure pointed-to by x and y, then we understand

Shape Analysis 5 / 15

Page 113: y V Taller de Programación Funcional (TPF)

S [[c]] R Σ = R

S [[x]] R Σ = R ]∗res res ε−→ • ε←− x

S [[C aim]] R Σ = R ]∗res res

jC−→ • ε←− a j | j ∈ 1..m, var(a j)

S [[g aim]] R Σ = R ]∗res Σ(g)[a j/x j

m]

S [[let x1 = e1 in e2]] R Σ = (S [[e2]] R1 Σ)\x1where R1 = (S[[e1]] R Σ)[x1/res]

S [[case x ofCi xi jni → ei]] R Σ =

⋃i(S [[ei]] Ri Σ)\xi j

ni

where Ri = R ]∗xijx

jCi−→ • ε←− xi j | j ∈ 1..ni

Figure 4: Definition of the abstract interpretation S

that xp1·p3−→ • p2·p3←− y is implicitly included in the relation. If e f is the body expression of a function

definition f x1 · · ·xn = e f , then S[[e f ]] R0, for an appropriate R0, contains all the sharing relationsbetween the result of calling f and its arguments x1, . . . ,xn.

In order to achieve a modular analysis, it is very important to reflect the result of the analysisof a function f in a function signature environment, so that when the analysis finds calls to fin the body of another function g, it uses this knowledge to compute the sharing relations for g.We keep function signatures in a global environment Σ, so that Σ( f ) is a set Rres containing thesharing relations between the result of calling f and its arguments. The interpretation S[[e]] R Σ

gives us the relations between (the normal form of) e and its variables in scope, provided Σ givesus correct approximations to the sharing relations of the functions called from e.

The interpretation defined in Figure 4 does a top-down traversal of a function definition, accu-mulating these relations as soon as bound variables become free variables. The notation R[y/x]means the substitution of the variable y for the variable x in the relation R. In order to avoidname capture, y must be fresh in R. The operator R\x removes from R any tuple containingthe variable x. The union operator ∪ is the usual set union. The closure operation R1]∗x R2 takesa relation R1 and completes it by adding R2 and the tuples involving x that can be derived bytransitivity. This operation also generates the reflexive relation x ε−→ • ε←− x.

The rules for expressions are explained in Sec. 3.4. The interpretation Sd of a function defi-nition f x1 . . .xn = e f begins with the interpretation of its body. It is straightforward to extractthe signature of the function, which just describes the relations between the result of e f and itsformal arguments x j

n, which are the only variables in scope. In case f is recursive, the interpre-tation is run several times, by starting with an empty signature for f and then computing the leastfixpoint. Each iteration updates the f ’s signature in the signature environment:

Sd [[ f x1 . . .xn = e f ]] Σ = fix (λΣ .Σ[ f → S[[e]] R0 Σ]) Σ0where Σ0 = Σ[ f → /0]

R0 = xiε−→ • ε←− xi | i ∈ 1..n

where Σ[ f → R] either adds signature R for f or replaces it in case there was already one for it.Notice that the right hand sides of the function definition is analysed starting with a neutral initial

Shape Analysis 6 / 15

Page 114: y V Taller de Programación Funcional (TPF)

R]x xp1−→ • p2←− y def

= y6=x R∪x p1−→ • p2←− y∪x ε−→ • ε←− x

∪xp1·p3|p2−→ • p4←− z | y p3−→ • p4←− z ∈ R

∪x p1−→ •p4·p2|p3←− z | y p3−→ • p4←− z ∈ R

∪xp1·p3|p2−→ •

p1·p4|p2←− x | y p3−→ • p4←− y ∈ R

R]∗x R′ def= R ]xx

p1−→ • p2←− y | x p1−→ • p2←− y ∈ R′,y 6= x∪x p1−→ • p2←− x | x p1−→ • p2←− x ∈ R′∪z p1−→ • p2←− u | z p1−→ • p2←− u ∈ R′,z 6= x,u 6= x

Figure 5: Definition of the closure operation

relation R0 in which each argument is only related to itself. This means that the signatures arecomputed assuming that all the parameters are disjoint and they do not present internal sharingin addition to the trivial sharing relation given by R0. When they are not, the function callerknows the additional sharing of the actual arguments. As function S is monotonic over a lattice,the least fixpoint exists and could be computed using Kleene’s ascending chain if the chain isfinite. We come back to this issue below.

3.3 The closure of a relation

The closure operation ]∗x is defined in terms of the simpler one ]x, which completes a relation setR with a new relation x

p1−→ • p2←− y by adding the relations that bind x to the variables containedin R, and are derived by transitivity. Both operators are defined in Figure 5.

The inclusion of R and the relations xp1−→ • p2←− y, x ε−→ • ε←− x is self-explanatory. We

shall concentrate on the remaining relations shown in the last two lines of the definition. Theserelations involve the derivative operator | [Brz64] whose meaning is:

p1|p2 = w3 | ∃w2 ∈ L(p2).w2w3 ∈ L(p1)

If p1 and p2 denote regular languages so do p1|p2 , and in Section 4 we explain how to computeit1. In the second line of the definition of ]x the language describing p1 · p3|p2 might be empty.In this case we can discard the corresponding sharing relation from the result of the closureoperation. If it is not empty then there exists a word w2 ∈ L(p2) such that it its a prefix ofanother word w3 ∈ L(p3), so we can start from x, follow a path from p1, and then follow thepath w2 without the prefix w3 (which results in a path of L(p3|p2)) in order to reach the commondescendant of x and z. The third line of ]x is applicable when a path of p3 is a prefix of a path ofp2, and works similarly. The fourth line deals with a particular case and is self-explanatory.

It is important to see whether the relations inferred by the analysis are well-typed. For instance,we could have a relation x

px−→•py←− y in which the descendant reached from x and px had a type

1 When p2 = a, the language p1|a is sometimes called the derivative of L(p1) with respect to a, and it is denoteda\L, being L = L(p1).

Shape Analysis 7 / 15

Page 115: y V Taller de Programación Funcional (TPF)

t, while the descendant reached from y and py had a different type t ′. This would obviously be aspurious relation since in well-typed programs, it may not occur an ill-typed sharing at runtime.

The expression type(t, p) returns the type computed starting at the type t, and then descendingthrough the constructors of the words in p according to its type and to the child chosen at eachstep. It is obvious that this type can be statically computed. Let tx be the type computed by thecompiler for the variable x.

Definition 2 We say that the relation xpx−→ •

py←− y is well-typed if type(tx, px) = type(ty, py).

Lemma 1 If the relations in R and Σ are well-typed, then for every expression e, the relationsin S[[e]] R Σ are well-typed.

3.4 Interpretation of expressions

An important invariant of the rules presented in Figure 4 is that, in each occurrence of S [[e]] R Σ,the set R contains an upper approximation of all the sharing relations that at runtime may happenbetween the variables in scope in e. Also, the set Rres returned by S [[e]] R Σ enjoys the sameproperty. It is easy to check that if the invariant holds for the original call S [[e f ]] R0 Σ, then therules preserve it.

The rule for a constant c introduces no new sharing. The rule of a variable x specifies that theresult is an alias of x, and ]∗res propagates to the result the variables to which x is related.

When a constructor application C aim is returned as a result, parent-child sharing relations are

created with the constructor’s children. These are added to the current set R, and then the closurecomputes all the derived sharing.

When a function application g aim is returned as a result, first we get from g’s signature the

sharing relations between g’s result and its formal arguments. These are copied by replacing theformal arguments by the actual ones, and then added to the current set. As before, the closurecomputation does the rest.

The let rule is almost self-explanatory: first e1 is analysed and the sharing computed for e1’sresult is assigned to the new variable in scope x1. Using this enriched set R1 as assumption, themain expression e2 is analysed, and its result is the result of the whole let expression.

Finally, a case expression introduces the pattern variables xi jni in the scope of a branch ei.

Their sharing relations are derived from the parent x’s ones by first adding the child-parent rela-tion between each xi j and x, and then computing the closure. After analising the branches, theleast upper bound of all the analyses must be computed, expressing the fact that at compile timeit is not known which branch will be taken at runtime.

4 Decidability Issues and Cost

The analysis presented in the previous section contains some tests and operations that deserve adetailed comment in order to see whether all of them are decidable, and which are their costs.

Since the number of bound variables in a function definition is finite, so is it the number oftuples in R. A relation x

p1−→ • p2←− y may ocur multiple times in R with different p1 and p2 but,as we will see, always with different types. Then, all the set union operations are decidable.

Shape Analysis 8 / 15

Page 116: y V Taller de Programación Funcional (TPF)

In the implementation, we represent regular languages by non-deterministic finite automata(NFA). We will denote them by A = (Σ,Q, i,F,δ ). This facilitates some of the operations neededon regular languages. These are the following:

1. To test whether a regular language L is empty, i.e. L = .

2. Given regular languages L1 and L2, to compute its concatenation L1.L2.

3. Given regular languages L1 and L2, to compute L1|L2 .

4. Given regular languages L1 and L2, to test whether L1 ⊆ L2.

The emptyness test can be achieved [HMU01] by looking for a final state in the states reachedfrom the initial one. If n =|Q| is the number of states of A, the algorithm costs O(n2).

Given NFA automata A1 and A2, the automaton recognizing L(A1).L(A2) can be constructedwith a cost O(n), just by connecting with ε-transitions the final states of A1 to the initial one ofA2.

Given NFA automata A1 = (Σ1,Q1, i1,F1,δ1) and A2 = (Σ2,Q2, i2,F2,δ2), the automaton rec-ognizing L(A1)|L(A2) is more involved. In fact, we have not found in the literature an algorithmto compute it, and have invented our own:

1. Compute the automaton A′2 by adding to A2 transitions with every symbol in Σ = Σ1∪Σ2,from every final state of A2 to itself. It is clear that A′2 recognizes L(A2).Σ

∗.

2. Compute A3 = A1∩A′2. It recognizes the words of L(A1) begining with a word of L(A2).The construction implies that the states of A3 are the tuples of Q1×Q2.

3. Build an automaton A4 with a fresh state q0 as the initial one. If L(A1)∩L(A2) is empty,then add ε-transitions from q0 to every state (qi, p j) ∈ A3 such that qi is a non-final stateof A1 and p j is a final state of A′2. If L(A1)∩L(A2) is not empty, then qi can be any stateof A1.

4. Remove from A4 all the states non-reachable from q0. The resulting automaton exactlyrecognizes L(A1)|L(A2).

The dominant costs of the algorithm are the cartesian product and the state reachability com-putation, both in O(n2).

Given NFA automata A1 and A2, L(A1) ⊆ L(A2) if and only if L(A1)∩ L(A2) = L(A1), soinclusion is a particular case of equality. Unfortunately, equality is not directly decidable withNFA’s. They must be converted to deterministic finite automata (DFA), and then their equalitytested with the well-known table-filling algorithm [HMU01], which has a cost O(n2). But theconversion from NFA to DFA has a worst-case cost in O(n32n). This is because the number ofstates of the DFA are subsets of the NFA set of states, and can in theory be up to 2n. As we willsee, the equality of languages must be tested once every fixpoint iteration.

When interpreting the body of a recursive function f , we start by setting an empty signaturefor f , i.e. Σ( f ) = /0. It is easy to show that the interpretation is monotonic in the lattice:

〈M (Var f ×P(Σ∗)×P(Σ∗)×Var f ), /0,>,v,∪,∩〉

Shape Analysis 9 / 15

Page 117: y V Taller de Programación Funcional (TPF)

where M stands for ‘multiset of’, Var f are the bound variables of f , Σ∗ is the top regular lan-guage, and> is the maximum relation. We need to ensure that not two tuples with the same typeexist relating the same variables. So, at the end of each iteration, the following collapsing rule isused:

xp1−→ • p2←− y ∈ R∗ x

p3−→ • p4←− y ∈ R∗ type(x, p1) = type(y, p4)

replace in R∗ the two tuples by xp1+p3−→ • p2+p4←− y

Should not we use this rule, we might have an infinite amount of sharing relations betweenprogram variables. The order relation between two tuples relating the same pair of variables, andhaving the same type, is as follows:

xp1−→ • p2←− yv x

p′1−→ •p′2←− y if L(p1)⊆ L(p′1)∧L(p2)⊆ L(p′2)

Let us call I f Σ to the interpretation of e f with current signature environment Σ, returning Σ

with f ’s signature updated. By monotonicity, we have:

/0vI f /0vI f (I f /0)v . . .v (I f )i /0v . . .

Disregarding the regular languages, this chain is finite because so it is Var f , and the number ofdifferent types of the program. Then, the least fixpoint can be reached after a finite number ofiterations. If n is the number of f ’s formal arguments, then at most n iterations are needed. Thisis because funcional languages have no variable updates, and then there never may arise sharingrelations between the formal arguments as a consequence of the function body actions. The onlypossible relations will be between the function’s result and its arguments.

Considering now the regular languages, infinite ascending chains are possible, i.e. one canobtain infinite chains L1 ⊆ L2 ⊆ L3 ⊆ . . ..

The least upper bound of such a sequence of regular languages needs not to be a regular one.But, at least, there always exists the regular language Σ∗ greater than any other one. In orderto ensure termination of the fixpoint computation, we use the following widening technique:[CC77]:

1. Based on the form of the automata denoting the increasing language sequence, and by us-ing the heuristic explained below, we guess an automaton A such that

⋃i Li v L(A). Then,

we iterate the interpretation by using this automaton as an assumption in f ’s signature.

2. If A is a fixpoint or a post-fixpoint, then we are done. Otherwise, we use Σ∗ as the upperbound of the sequence. In terms of precision, x Σ∗−→ • Σ∗←− y is completely uninformativeabout the paths through which x and y share their common descendant.

The heuristic consists of comparing the automata sequence obtained for a given relation xp1−→

• p2←− y in the successive iterations, and discovering growing sequences reaching three or morestates related by the same alphabet symbol. For example q1,q2,q3, with (q1,a,q2),(q2,a,q3) ∈δ . These sequences are collapsed into a single state class q, with a single iterative transition(q,a,q) ∈ δ . The resulting automata is compared with the non-widended one, to ensure that

Shape Analysis 10 / 15

Page 118: y V Taller de Programación Funcional (TPF)

last xs = case xs ofx:xx -> case xx of

[] -> * R1 * xy:yy -> * R2 * last xx

Figure 6: Definition of the function last

they are equivalent regarding the remaining transitions. In all the examples we have tried, thisheuristic appears to be enough to reach a fixed point.

We pay now attention to the asymptotic cost of the whole interpretation. We choose the sizen of a function to be its number of bound variables. This figure is linearly related to the size ofits abstract syntax tree, and to the number of lines of its source code. How is n related to the sizeof the inferred automata in terms of their number of states? It is easy to check that every bound

variable y introduces a relation xjC−→ • ε←− y with a prior bound variable x. This increases by

one the number of states of the y relations with respect to those of the x relations. So, the statesof the automata grows from one to the abstract syntax tree height, when going from the initialexpression to the deepest ones. Assuming a reasonably balanced syntax tree, we consider lognto be an accurate bound to the automata size.

If a function definition has n bound variables, and considering as a constant the number ofdifferent types, in the worst case there can be up to O(n2) tuples in the current relation R. Thecomputation of a single closure operation R]x x

p1−→ • p2←− y (see Fig. 5) introduces as manyrelations x

px−→ • pz←− z as prior relations ypy−→ • pz←− z are there in R, i.e. O(n) in the worst

case. A single iteration of the abstract interpretation will compute one such closure for everybound variable, giving an upper bound of O(n2) new relations per iteration. For each one, twolanguages A1|A2 .A3 must be computed, giving a total cost of O(n2 log2 n) per iteration.

It has been said that the number of iterations is at most the function’s number of arguments,which is usually small. Even if it is not, in practice it suffices to perform only three iterationsof the analysis before applying the widening, and then an additional iteration in order to tocheck that the fixpoint has been reached. This checking is the more expensive operation of theanalysis. A maximum of O(n2) languages are tested for equality, giving a total theoretical costof O(n22logn log3 n) in the worst case, i.e. O(n3 log3 n).

A worst-case cost of O(n3 log3 n) is by no means a low one, but we consider it to be ratherpessimistic. We remark that we are assuming each variable to be related to each other, andall conversions from NFA to DFA to produce an exponential blow-up of states. This leads usto think that this theoretical cost is almost never reached. Also, in functional programming it iscommon to write small functions. So, the number n of bound variables can be expected to remainbelow 20 for most of the functions (the reader is invited to check this assertion for the functionspresented in this paper).

In practice our analysis is affordable for medium-size functions. More importantly, it is mod-ular, because once a function definition is analysed, all its relevant information is recorded in thesignature environment. Hence, the compilation of a big program is still linear in the programsize, even if analysing each individual function of size n takes a time in O(n3 log3 n).

In order to illustrate the analysis, we present in Fig. 6 the code of a function last computingthe last element of a non-empty list. By iterating once the interpretation, and in the places marked

Shape Analysis 11 / 15

Page 119: y V Taller de Programación Funcional (TPF)

in the text, we get the following two sets:

R1 = xs ε−→ • ε←− xs]x xs 1−→ • ε←− x]xx xs 2−→ • ε←− xxR2 = R1]y xx 1−→ • ε←− y]yy xx 2−→ • ε←− yy

Then Σ1 = Ilast last 7→ /0 = res ε−→ • 1←− xs, where we omit the reflexive relations. Byapplying again the interpretation, we get:

Σ2 = Ilast last 7→ Σ1 = res ε−→ • 21←− xs ∪ res ε−→ • 1←− xs= res ε−→ • 21+1←− xs

The language 21 is obtained by the closure res ε−→ • 1←− xx]res xs 2−→ • ε←− xx. In the

next round, we get Σ3 = res ε−→ • 2(21+1)+1←− xs Applying now the widening step, we get Σ3 =

res ε−→ • 2∗1+21+1←− xs, and by applying the interpretation once more:

Ilast last 7→ Σ3 = res ε−→ • 2(2∗1+21+1)←− xs ∪ res ε−→ • 1←− xs= res ε−→ • 2(2∗1+21+1)+1←− xs

The final test is 2(2∗1+ 21+ 1)+ 1 ⊆ 2∗1+ 21+ 1 which returns true because all the wordsin the left language are also in the right one. Notice that the right expression could be furthersimplified to 2∗1. This language clearly expresses that the result of last is a descendant of theargument list that can be reached by taking the tail of the list a number of times and then bytaking the head.

5 Implementation and Case Studies

We have implementated the analysis presented here, which has been integrated into our Safecompiler, written in Haskell. We have extended the HaLeX library [Sar02], which manipulatesregular languages, with new operations such as language intersection, derivation and equality.While the implementation of the abstract interpretation rules of Fig. 4 is straightforward, theclosure operation defined in Fig. 5 is much more involved.

Besides the examples already shown in the paper, we have applied our analysis to some addi-tional ones involving list and binary tree manipulations. The following functions show how ouranalysis can also detect internal sharing in the data structure given as a result. This is useful toknow whether a given data structure is laid out in memory without overlapping.

buildTree x 0 = EmptybuildTree x n = Node (buildTree x (n-1)) x (buildTree x (n-1))

buildTreeSh x 0 = EmptybuildTreeSh x n = let t = buildTree x (n-1) in Node t x t

The shape analysis yields the results given below. We also include the inferred sharing rela-tions of the append, partition and qsort functions that make up a typical Quicksort imple-

Shape Analysis 12 / 15

Page 120: y V Taller de Programación Funcional (TPF)

mentation:

buildTree x n : res(1+3)∗2−→ • ε←− x, res

(1+3)∗2−→ • (1+3)∗2←− resbuildTreeSh x n : res

(1+3)∗2−→ • ε←− x, res(1+3)∗2−→ • (1+3)∗2←− res, res

(1+3)∗−→ • (1+3)∗←− resappend xs ys : res 2∗1−→ • 2∗1←− xs, res 2∗−→ • ε←− yspartition p xs : res 12∗1+22∗1−→ • 2∗1←− xs

qsort xs : res 2∗1−→ • 2∗1←− xs

6 Related Work and Conclusions

There exist many different analyses dedicated to extracting information about the heap, mainlyin imperative languages where pointers are explicitly used and may be reassigned. Alias analysisis one of the most studied. It tries to detect program variables that point to the same memorylocation. Pointer analysis aims at determining the storage locations a pointer can point to, soit may be also used to detect aliases in a program. These analyses are used in many differentapplications such as live variable analysis for register allocation and constant propagation. In[Ram04, Hin01, Ray05] we can find surveys about pointer analysis applied to imperative lan-guages from the 80’s. Shape analysis [Rey68, JM79, Rep95] tries to approximate the ‘shape’of the heap-allocated structures. That information has been used, for example, for binding timeoptimizations.

The level of detail of all these analyses mainly depends on the user of the analysis. Ouranalysis tries to capture a kind of sharing information more refined than alias and pointer analysismay provide, and in fact both are subsumed in our relations: if x ε−→ • ε←− y, then, x and y are

aliases; if xj−→ • ε←− y, then x points to y (i.e. y is the j-th child of the data structure x). Shape

analysis is nearer to our needs.Jones and Muchnick [JM79] associate sets of k-limited graphs to each program point in order

to approximate the sharing relations between variables. The k limits the length of the paths inthe graphs modeling the heap in order to make the domain finite and obtain the minimal fixpointby iteration. The graphs obtained after the abstract execution of a program instruction must betransformed in order to maintain themselves k-limited. Our widening operator ressembles thisoperation. Our path relations are in general uncomparable in precision to these sets of limitedgraphs. First, having sets of graphs may provide more precision because our union operationloses information: adding x

p1+p3−→ • p2+p4←− y introduces combinations of paths xp1−→ • p4←− y and

xp3−→ • p2←− y which did not exist previously. Second, paths longer than k may be more precise

that k-limited graphs: x 2221−→ • ε←− y indicating that y is the fifth element of the list x is moreprecise than saying in a 2-limited graph that y shares in an unknown way with x after the path 22.Additionally, the cost of having sets of graphs is doubly exponential in the number of variables.

In order to reduce the cost to polinomial, Reps [Rep95] formulated the analysis as a graph-reachability problem over the dependence graph generated from the program. The reachabilityis defined in terms of those (context-free) paths one is interested in. The fixpoint calculation inthis case is also finite because he just records the information about the variables, not the exactpaths. We need the paths in order to make the analysis more precise as shown in the mergesort

Shape Analysis 13 / 15

Page 121: y V Taller de Programación Funcional (TPF)

example, that is why we need the widening. The use of context-free paths in our frameworkwould make undecidable most of our tests.

Other related works are those devoted to compile-time garbage collection, such as [Hud86,JM90]. The first one tries to save creating a new array when updating an array that is onlyreferenced once. The second one provides an analysis also detecting when a cell is referenced atmost once by the subsequent computation. Its aim is to destroy the cell after its last use so thatit can be reused by the runtime system. Both analyses are done on a first-order eager functionallanguage. After these ones, there have been many similar analyses, usually known as usageanalyses (e.g. [TWM95, BS96, WJ99, GS01]) whose aim is to detect when a cell is used atmost once and then, either to recover or to avoid to update it, when the language is lazy. Theseanalyses do not try to know which other data structures points to a particular cell, but rather howmany of them do it, and in this sense they are simpler. The nearer to our problem is [JM90] sinceit pursues an aim similar to that of Safe: to save memory. The main difference is that, in ourcase, it is the programmer who decides to destroy a cell and the compiler just analyses whetherdoing this is safe or not. So, the programmer may have destructive and non-destructive versionsof the same function and uses the first one in contexts where it is safe to do it. In [JM90] it isthe compiler who decides to destroy the cell, when it is safe to do it in all the contexts in whichthe function is called. A single unsafe context will avoid to recover the cell in all the safe ones.Another important difference is that our analysis is modular, while theirs need to analyse theprogram as a whole. This makes it unpractical for big programs.

Bibliography

[Brz64] J. A. Brzozowski. Derivatives of Regular Expressions. Journal of the ACM11(4):481–494, 1964.

[BS96] E. Barendsen, S. Smetsers. Uniqueness typing for functional languages with graphrewriting semantics. Mathematical Structures in Computer Science 6(6):579–612,Dec. 1996.

[CC77] P. Cousot, R. Cousot. Abstract Interpretation: A Unified Lattice Model for StaticAnalysis of Programs by Construction of Approximation of Fixed Points. In Proc.4th ACM Symp. on Principles of Prog. Languages. Pp. 238–252. ACM, 1977.

[GS01] J. Gustavsson, J. Sveningsson. A Usage Analysis with Bounded Usage Polymor-phism and Subtyping. In Selected Papers of the 12th International Workshop on Im-plementation of Functional Languages, IFL’00. LNCS 2011, pp. 140–157. Springer-Verlag, 2001.

[Hin01] M. Hind. Pointer analysis: Havent we solved this problem yet? In Proceedings of the2001 ACM SIGPLAN-SIGSOFT Workshop on Program Analysis For Software Toolsand Engineering, PASTE’01. Pp. 54–61. ACM Press, 2001.

[HMU01] J. E. Hopcroft, R. Motwani, J. D. Ullman. Introduction to Automata Theory, Lan-guages and Computation. Addison Wesley, 2nd edition, 2001.

Shape Analysis 14 / 15

Page 122: y V Taller de Programación Funcional (TPF)

[Hud86] P. Hudak. A Semantic Model of Reference Counting and its Abstraction (DetailedSummary). In ACM Symposium on Lisp and Functional Programming. Pp. 351–363.ACM, 1986.

[JM79] N. D. Jones, S. S. Muchnick. Flow analysis and optimization of LISP-like structures.In Proceedings of the 6th ACM SIGACT-SIGPLAN symposium on Principles of pro-gramming languages. POPL ’79, pp. 244–256. ACM, 1979.

[JM90] T. P. Jensen, T. A. Mogensen. A Backwards Analysis for Compile-Time GarbageCollection. In European Symposium on Programming. Pp. 227–239. LNCS 432,Springer, 1990.

[MPS08] M. Montenegro, R. Pena, C. Segura. A Type System for Safe Memory Managementand its Proof of Correctness. In ACM Principles and Practice of Declarative Pro-gramming, PPDP’08, Valencia, Spain, July. 2008. Pp. 152–162. 2008.

[MPS09] M. Montenegro, R. Pena, C. Segura. An Inference Algorithm for Guaranteeing SafeDestruction. In Selected papers of Logic-Based Program Synthesis and Transforma-tion, LOPSTR’08, LNCS 5438, Springer. Pp. 135–151. 2009.

[PSM07] R. Pena, C. Segura, M. Montenegro. A Sharing Analysis for SAFE. In Selected Pa-pers Trends in Functional Programming, TFP’06. Pp. 109–128. Intellect, 2007.

[Ram04] V. Raman. Pointer Analysis – A Survey. CS203 UC Santa Cruzhttp://www.soe. ucsc.edu/˜vishwa/publications/Pointers.pdf.2004.

[Ray05] D. Rayside. Points–To Analysis. http://www.cs.utexas.edu/˜pingali/CS395T/2012sp/lectures/points-to.pdf. 2005.

[Rep95] T. Reps. Shape analysis as a generalized path problem. In Proceedings of the 1995ACM SIGPLAN symposium on Partial evaluation and semantics-based program ma-nipulation. PEPM ’95, pp. 1–11. ACM, 1995.

[Rey68] J. C. Reynolds. Automatic computation of data set definitions. In IFIP Congress (1).Pp. 456–461. 1968.

[Sar02] J. Saraiva. HaLeX: A Haskell Library to Model, Manipulate and Animate RegularLanguages. In Proc. ACM Workshop on Functional and Declarative Programming inEducation. University of Kiel. Tech. Report 0210, pp. 133–140. 2002.

[TWM95] D. N. Turner, P. L. Wadler, C. Mossin. Once upon a type. In 7’th International Con-ference on Functional Programming and Computer Architecture. Pp. 1–11. ACMPress, La Jolla, California, June 1995.

[WJ99] K. Wansbrough, S. L. P. Jones. Once upon a polymorphic type. In The Twenty-sixthACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages. SanAntonio, Texas, January 1999.

Shape Analysis 15 / 15

Page 123: y V Taller de Programación Funcional (TPF)

Quantified Abstractions of Distributed Systems

Elvira Albert1, Jesus Correas1, German Puebla2 and Guillermo Roman-Dıez2

1 DSIC, Complutense University of Madrid (UCM), Spain2 DLSIIS, Technical University of Madrid (UPM), Spain

Abstract. When reasoning about distributed systems, it is essential to have infor-mation about the different kinds of nodes which compose the system, how manyinstances of each kind exist, and how nodes communicate with other nodes. Inthis paper we present a static-analysis-based approach which is able to provide in-formation about the questions above. In order to cope with an unbounded numberof nodes and an unbounded number of calls among them, the analysis performsan abstraction of the system producing a graph whose nodes may represent (in-finitely) many concrete nodes and arcs represent any number of (infinitely) manycalls among nodes. The crux of our approach is that the abstraction is enrichedwith upper bounds inferred by a resource analysis which limit the number ofconcrete instances which the nodes and arcs represent. The combined informa-tion provided by our approach has interesting applications such as debugging,optimizing and dimensioning distributed systems.

Acknolegments: This work was funded partially by the projects FP7-ICT-610582,TIN2008-05624, TIN2012-38137, PRI-AIBDE-2011-0900 and S2009TIC-1465.

Page 124: y V Taller de Programación Funcional (TPF)

Sesión 4: Fuzzy Logic

124

Page 125: y V Taller de Programación Funcional (TPF)

Sesión 4: Fuzzy Logic

16.00–16.30 Patrik Eklund, M. Ángeles Galán, Robert Helgesson, JariKortelainen, Ginés Moreno, and Carlos Vázquez: Towardsa Categorical Description of Fuzzy Logic Programming

16.30–17.00 Jesús M. Almendros-Jiménez, Alejandro Luna, GinésMoreno, and Carlos Vázquez: Analyzing Fuzzy Logic Com-putations with Fuzzy XPath

17.00–17.30 Miquel Bofill, Ginés Moreno, Carlos Vázquez, and MateuVillaret: Automatic Proving of Fuzzy Formulae with FuzzyLogic Programming and SMT

125

Page 126: y V Taller de Programación Funcional (TPF)

Towards a Categorical Description of Fuzzy Logic Programming

Patrik Eklund1, M.Angeles Galan2, Robert Helgesson1, Jari Kortelainen3, GinesMoreno4, Carlos Vazquez4

1 Department of Computing ScienceUmea University

SE-90187 Umea, [email protected]

[email protected] Department of Applied Mathematics

University of MalagaE-29071, Malaga, [email protected]

3 Department of Electrical Engineering and Information TechnologyMikkeli University of Applied Sciences

FIN-50100, Mikkeli, [email protected]

4 Department of Computing SystemsUniversity of Castilla-La Mancha

E-02071, Albacete, [email protected]@uclm.es

Abstract: In this paper we present different variants of the logic programmingparadigm under a general framework based on category theory. Even just on a purelysyntactic level, our scheme distinguishes between unsorted and many-sorted, propo-sition and predicate, as well as crisp and fuzzy cases. Moreover, apart for showingthat now it is possible to speak about “fuzzy logic programming” and “logic pro-gramming with fuzzy”, the categorical language easily covers not only fuzzy sen-tences, as usual in most modern fuzzy logic systems, but also fuzzy Σ-terms.

Keywords: Fuzzy logic programming, fuzzy terms, fuzzy sentences

1 Introduction

Intuitively speaking, terms are produced by functors that are extendible to monads [10, 7],whereas sentences are produced by functors that remain as functors only [6].

In logic programming, informal production of sets of terms and well-formed formulas some-times leads to confusion concerning the borderline between terms and sentences. In [18], nota-tion and concepts mention ‘signature’, ‘functions’ (operators of formal universal algebra basedsignatures), and ‘predicates’. In this conventional view, predicates are typically seen as differentfrom operators in some underlying signature, and such treatments are also ‘unsorted’, or in factone-sorted concerning the underlying set of terms.

Towards a Categorical Description of Fuzzy Logic Programming 1 / 10

Page 127: y V Taller de Programación Funcional (TPF)

In this paper we will have predicates as operators, so atoms are terms, but program clausesbecome sentences. We will categorically aim at being precise so that notions like ‘ground terms’,‘well-formed formulas’ in predicate logic, ‘predicates’ or ‘predicate symbols’, and ‘atoms’ canbe explained more strictly in the categorical machinery.

There are a number of independently developed approaches to fuzzy logic programming,where there are less considerations involving first-order aspects, and more papers covering truthvalue considerations only. For the first-order aspects see [22, 15] for some historically importantcontributions. Categories for logic programming enters the scene in [24] with co-equalizers seento be most general unifiers.

The resolution principle as an algorithm has also been subject of fuzzification [16, 11, 17, 14,1, 20, 23, 13, 2, 21]. This mostly focuses on truth values more than extending the underlyinglanguage. Similarly for fixpoint considerations, interpretations are considered mostly as pointsin sets, and uncertainties are added [27]. The fixpoint semantics framework has been enrichedwith a declarative semantics based on model-theory as described in [12].

In [3] the equivalence between the declarative, least model, fixpoint and procedural semanticsfor fuzzy logic programs is proved. In particular, there is the notion of logical consequenceand justification of the existence of a fuzzy Herbrand model, and its fixpoint characterization.Further, in [25], the notion of fuzzy least Herbrand model is also introduced and proven tobe equivalent with the fixpoint semantics of logic programs with similarity. In [26] there isan approach for generalizing the Tarskian semantics of Horn clause rules to justify a form ofquantitative deduction.

In this paper the framework is indeed categorical and our term monad constructions [7] areimportant building blocks. These monads make use of constructions in categorical algebra morebroadly, which goes back to the study of natural equivalences [5]. Monoidal closed categoriesemerges more or less in [4], and attained its simple and clean formulation in [19]. This is thecategorical realm of this paper, and the categorical notation adopted in this paper is the same asin [7].

2 Signatures, terms and sentences

In this section we will view sets and fuzzy sets basically in the sense of the category of setsand the Goguen category, so we may adopt the more simple computer science notation of signa-tures as compared to the approach in [7], where the term monad was constructed over arbitrarymonoidal biclosed categories. This requires a distinction between the object of sorts and the sortsthemselves appearing as elements in a homset.

In this section we will also be many-sorted, and provide remarks about one-sorted only whennecessary and of particular interest.

We start off using Set as our underlying category. Let then Σ0 = (S0,Ω0) be a signature overSet, and TΣ0 be the term monad over SetS0 . For the variables in XS0 , the set of terms TΣ0XS0 ,as an object of SetS0 , then correspond to the ‘terms’, and similarly TΣ0∅S0 will be the set of socalled ‘ground terms’ in the sense of [18].

In order to introduce predicates as operators in a separate signature, and then composing thatresulting ‘predicate’ functor with the term functor, we assume that Σ contains a sort bool, which

Towards a Categorical Description of Fuzzy Logic Programming 2 / 10

Page 128: y V Taller de Programación Funcional (TPF)

does not appear in connection with any operator in Ω, i.e., we set S = S0∪bool, bool ∕∈ S0,and Ω = Ω0. This means that TΣ,boolXS = Xbool, and for any substitution σS : XS //TΣXS,we have σbool(x) = x for all x ∈ Xbool. The composition of the ‘predicate’ functor with TΣ isintuitively expected to be the desired ‘predicates as terms’ functor.

We can now also separate propositional logic from predicate logic, and also decide whetheror not to include negation. The key effect in doing this arrangement is that implication becomes‘sentential’ where as conjunction (and negation, if included) produces terms from terms.

To proceed towards this goal, let ΣPL = (SPL,ΩPL) be the underlying two-valued propositionallogic signature, where SPL = S, and ΩPL = F,T :→ bool,& : bool×bool→ bool,¬ : bool→bool∪Pi : si1 ×⋅⋅ ⋅×sin → bool ∣ i ∈ I,si j ∈ S. Similarly as bool leading to no additionalterms, except for additional variables being terms when using Σ, the sorts in SPL, other thanbool, will lead to no additional terms except variables. Adding predicates as operators evenif they produce no terms seems superfluous at first sight, but the justification is seen when wecompose these term functors with TΣ.

In the two-valued case, A(bool) is often f alse, true, so that A(F) = f alse and A(T) = true.Further, A(&) : A(bool)×A(bool) //A(bool), is expected to be defined by the usual ‘truthtable’. Further A(s0) is usually denoted by D so that the semantics for a (syntactic) n-aryoperator ω : s0× ⋅⋅ ⋅ × s0 → s0 is an n-ary operation (function) A(ω) : Dn // D. Generallyspeaking, a many-sorted algebra is not a traditional algebra, not even a tuple of traditional al-gebras, since an operator ω may touch many sorts and then the semantics of ω is not an n-ary function on some set. For example, we may assign for a signature ΣPL = (SPL,ΩPL) apair, the ‘many-sorted algebra’, (TΣPLXS,(A(ω))ω∈ΩPL), where Xs = ∅ if s ∕= bool. Then,(∪s∈S(arg

s ∘TΣPL)XS,(F,T,&,¬)) serves as a traditional Boolean algebra, when certain equa-tional laws are given.

In the many-valued case we would have some sort lat, so that A(lat) = L, the underlying setof a complete lattice L. Now, L could more specifically be a residuated lattice, when conjunctionis desired to be residuated with the implication operator (in the lattice), or a quantale, justifyingthe use of monoidal closed subcategories. The choice of the lattice or quantale is typicallyjustified by the application context.

In the many-valued propositional logic signature ΣmvPL = (Smv

PL,ΩmvPL) we may then desire to

include constant operators ai, i = 1, . . . ,n, of sort lat such that A(ai) = αi, αi ∈ L. All latticevalues can be rediscovered in the signature, but does not necessarily all have to be discovered.This is a matter related to an application context. Note also that there are many optional choicesfor logical connectives, and e.g. for the conjunction, several algebraic interpretations are possible.

In what follows we will not explicitly distinguish between Σmv and Σ, so whenever we writeΣ, the underlying lattice representing the algebra may be two-valued or many-valued. In order tocover the case including ‘Horn clauses’ and also separating the form of the ‘head’ and ‘body’ inthose clauses, we introduce the notation ΣPL∖¬ for the signature where the operator ¬ is removed,and ΣPL∖¬,& for the signature where both ¬ and & are removed.

It is convenient also to use set functors disabling the use of variables of particular sort. For Sbeing the set of sorts with bool, as a distinguished sort in S, we write φ S∖bool : SetS //SetS forthe functors defined as φ S∖boolXS = X ′S, where for all s ∈ S0 we have X ′s = Xs, and X ′bool = ∅.Similarly we define the functor φbool : SetS //SetS as φboolXS = X ′S, where for all s ∈ S0 wehave X ′s =∅, and X ′bool = Xbool.

Towards a Categorical Description of Fuzzy Logic Programming 3 / 10

Page 129: y V Taller de Programación Funcional (TPF)

The ZFC-set of ‘terms’ over Σ may now be given by∪s∈S

(TΣ,s ∘φS∖bool)XS,

and now the ZFC-set of propositional logic formulas are∪s∈S

(args ∘TΣPL∘φ

bool)XS = (argbool ∘TΣPL∘φ

bool)XS.

We use the expression args ∘TΣPL instead of TΣPL,s for convenience. Note how

(argbool ∘TΣPL∖¬,&∘φ

bool)XS = F,T.

Sentences, i.e., formulas in propositional logic are now obviously given by the functor

SenPL = argbool ∘TΣPL∘φ

bool,

and sentences in ‘Horn clause logic’ can now be given by the functor

SenHCL = (argbool)2 ∘ (((TΣPL∖¬,&∘TΣ)× (TΣPL∖¬

∘TΣ)) ∘φS∖bool)

= (argbool)2 ∘ ((TΣPL∖¬,&×TΣPL∖¬) ∘TΣ ∘φS∖bool)

Note that SenHCLXS is an object in Set, and therefore (h,b) ∈ SenHCLXS means that h is an‘atom’ and b is a conjunction of ‘atoms’. Further, (h,T) is a ‘fact’, (F,b) is a ‘goal clause’, and(F,T) is a ‘failure’.

Note that in these notations, this specific Horn clause sentence functor is a Sen : SetS //Set,but we may under some circumstances also want to consider sentence functors from SetS toSetS [6].

We are now in a position to introduce variable substitutions. Indeed, because we have a monadTΣ = (TΣ,η ,µ), we may now perform a variable substitution σS : φ S∖boolXS //TΣφ S∖boolYS,that is, variables φ S∖boolXS are subsituted by terms TΣφ S∖boolYS. The substitution is definedsortwise σS = (σs)s∈S such that σs : args(φ S∖boolXS) //TΣ,sφ S∖boolYS. We have the following:

µ ∘TΣσS : TΣφS∖boolXS //TΣφ

S∖boolYS

σheadS = TΣPL∖¬,&(µ ∘TΣσS) : (TΣPL∖¬,&

∘TΣ)φS∖boolXS // (TΣPL∖¬,&

∘TΣ)φS∖boolYS

σbodyS = TΣPL∖¬(µ ∘TΣσS) : (TΣPL∖¬

∘TΣ)φS∖boolXS // (TΣPL∖¬

∘TΣ)φS∖boolYS

(σheadS ,σbody

S ) = (TΣPL∖¬,&×TΣPL∖¬)(µ ∘TΣσS) :

((TΣPL∖¬,& ×TΣPL∖¬) ∘TΣ)φS∖boolXS // ((TΣPL∖¬,& ×TΣPL∖¬) ∘TΣ)φ

S∖boolYS

Towards a Categorical Description of Fuzzy Logic Programming 4 / 10

Page 130: y V Taller de Programación Funcional (TPF)

Finally,

σHC = (σhead

bool,σbodybool) : SenHCLXS //SenHCLYS

Notice that σheadS , σ

bodyS and (σhead

S , σbodyS ) are morphisms in SetS but σHC is a morphism in

Set.

3 Algebras, models and fixpoints

In [18], the operator ω is called a ‘function symbol’, and the operator P is called a ‘predicatesymbol’. Note indeed, that in our framework, both ω and P are operators, and therefore treatedsemantically in the same fashion, like also in [18], even if the algebra for a ‘predicate symbol’ isnoted to be equivalent to a relation. The use of ‘function’ in this context is obviously misleadingas ω is not a function (in the sense of ZFC), but A(ω) is a function, which in [18] is called a‘mapping’.

Intuitively, a program consists of a finite set (h1,b1), . . . ,(hn,bn) of program clauses, sortsand operators appearing in each bi and hi. Thus, a finite set of program clauses Γ = (h1,b1), . . . ,(hn,bn) ‘determines’ the Σ and ΣPL. For a program Γ⊆ SenHCLXS we assign a SetS object

(UΓ)S = TΣ∅S = (TΣ,s∅S)s∈S

where TΣ,s∅S is the set of all ground terms of type s, and indeed TΣ,bool∅S = ∅. Note that∪s∈S(UΓ)s corresponds to the traditional and unsorted view of the Herbrand universe as a ZFC-

set. In this section we are also interested in the Set-object

BΓ = (argbool ∘TΣPL∖¬,&∘TΣ) ∅S

corresponding to the Herbrand base in the traditional sense [18]. Herbrand interpretations of aprogram Γ are subsets I ⊆ BΓ, that is, I ∈ PBΓ.

For sake of convenience when dealing with the immediate consequences operator for the fix-point considerations, we will need the Herbrand expression base

B&Γ = (argbool ∘TΣPL∖¬

∘TΣ) ∅S.

Note that a Herbrand interpretation I canonically extends to a Herbrand expression interpreta-tion I & ⊆ B&

Γ. Similarly, when I ∈ LBΓ, one might extend I to Herbrand fuzzy expression

interpretation I & (semantically) as follows: for an element b ∈ B&Γ

of the form b = b1& ⋅ ⋅ ⋅&bn

we have I &(b) =⋀I (b1), . . . ,I (bn) and for an atom element b ∈ B&

Γ, I &(b) = I (b).

However, it is questionable to call I ∈ LBΓ to an interpretation.The extension to the many-valued case is now a question about composing with the many-

valued powerset functor L with term functors, producing a style of “logic with fuzzy” or havingthe term functors work over the Goguen category, producing a style of “fuzzy logic”. It shouldtherefore not be looked at simply from the viewpoint of replacing the functor P to L with L asthe underlying complete lattice, and extending the Herbrand interpretations to Herbrand fuzzyinterpretations of a program Γ by I ∈ LBΓ. We will here look more into the first situation, as

Towards a Categorical Description of Fuzzy Logic Programming 5 / 10

Page 131: y V Taller de Programación Funcional (TPF)

the “squeezing in” of L can indeed be done in two ways. Either we annotate it “outside”, as men-tioned above, with sentences in such a ‘annotated fuzzy Horn clause logic’ can be given by thesentence functor LS ∘SenHCL (for all s ∈ S, Ls = L) and then proceed to produce interpretationsfor fuzzy sets of predicates

LBΓ = (L ∘argbool ∘TΣPL∖¬,&∘TΣ) ∅S.

A fuzzy interpretation in this case is then just a mapping I : BΓ// L, and uncertainties arising

from terms and substitutions remain unaffected. On the other hand, we may go “inside” toproduce the substitution fuzzy Horn clause logic with the sentence functor

SenSFHCL = (argbool)2 ∘ ((TΣPL∖¬,&×TΣPL∖¬) ∘LS ∘TΣ ∘φS∖bool)

so that ground predicates over fuzzy sets of terms is the set

BLΓ = (argbool ∘TΣPL∖¬,&

∘LS ∘TΣ) ∅S

with the corresponding extension BL,&Γ

being defined in the obvious way. The resulting fuzzysets of ground predicates then comes about from considering the swapper

ς : TΣPL∖¬,&∘LS //LS ∘TΣPL∖¬,&

which is given in [8] for the many-sorted case, and in [9] for the one-sorted case. Indeed we canuse argboolςTΣ∅S : BL

Γ//LBΓ. Note also how LBL

Γwould correspond to a Herbrand base like the

set with uncertainty considerations both for the sets of clauses, as well as sets of terms.Moving to fixpoints, we first consider crisp ground term substitution, that is, a SetS-morphism

σS : XS //TΣ∅S. By the previous discussion, this induces a morphism with the following shapeσHC : SenHCLXS // SenHCL∅S. We can now define a mapping ϖ : LBΓ

// LBΓ, where theunderlying lattice L for the many-valued powerset functor L is a complete lattice, by for allI ∈ LBΓ,

ϖ(I )(σheadbool(h)) =

⋁(h,b)∈Γ

I &(σbodybool(b))

When k ∈ BΓ is such that k ∕∈ Rσheadbool

(the range of σheadbool), then ϖ(I )(k) = I (k).

Proposition 3.1 ϖ is monotonic.

Proof. Let (h,b) ∈ Γ and I ,J ∈ LBΓ. If I ≤J , then by the definition of Herbrand fuzzyexpression interpretations we have I &(σbody

bool(b))≤J &(σbodybool(b)), for all (h,b)∈ Γ. So, for all

(h,b) ∈ Γ we have ϖ(I )(σheadbool(h))≤ ϖ(J )(σhead

bool(h)). By definition of ϖ we have ϖ(I )≤ϖ(J ).

It is now well-known that ϖ has the least and greatest fixpoints.In the previous simpler approach to fuzzy models, substitutions indeed remain crisp. For fuzzy

ground term substitution, that is, a SetS-morphism of the form σLS : XS //LSTΣ∅S, correspond-

ing σL,headS and σ

L,bodyS mappings can be provided with LS “inside”.

A mapping ϖL : LBLΓ

//LBLΓ, considering the effect of substitutions with fuzzy sets of terms,

can now, using argboolςTΣ∅S : BLΓ

//LBΓ, be considered in various forms, but this treatment fallsoutside the scope of this paper.

Towards a Categorical Description of Fuzzy Logic Programming 6 / 10

Page 132: y V Taller de Programación Funcional (TPF)

4 Conclusions

In this paper we investigate the shift from two-valued to many-valued logic programming. Wewill show that assigning uncertainty is far from trivial, and the place where uncertainty should beused is also not always clear. This is seen e.g. concerning terms and sentences, as classic logicprogramming, and also predicate logic for that matter, is not all that clear about the distinctivecharacters of terms and sentences. Naive set-theoretic approaches when dealing e.g. with ‘sets ofsentences’ and ‘sets of ground atoms’ may easily lead to confusion and undesirable constructionsif generalizations are performed only as a shift from ‘set’ to ‘fuzzy set’. We show how adaptationof a strictly categorical framework enables us to be very precise about the distinction betweenterms and sentences, where predicates symbols become part of a signature which is kept apartfrom the signature for terms. Implication will not be included in signatures, but appears inte-grated into our sentence functors. Doing so we are able to relate propositional logic to predicatelogic in a more natural way. Invoking uncertainty then becomes much more transparent.

In order to summarize we remember that our categorical framework covers different kinds oflogic programming styles according to the following criteria:

∙ We can act on the set of sorts S0 (remember that S = S0∪bool= SPL) in signatures Σ0,Σ and ΣPL, as well as on the set of operators (remember too that Ω0 = fi : si1×⋅⋅ ⋅× sin →sV= Ω, whereas ΩPL = F,T :→ bool,& : bool×bool→ bool,¬ : bool→ bool∪Pi : si1×⋅⋅ ⋅×sin → bool ∣ i ∈ I,si j ∈ S) in order to distinguish between

O : one-sorted case when S0 = s0, and S = s0,bool= SPL.

S : many-sorted case when S0 = s0, . . . ,sn, and S = s0, . . . ,sn,bool= SPL.

∙ We can act on TΣ for distinguishing between

P : we have propositional case when we avoid using of TΣ.

F : we have first order case when we use TΣ for generating terms.

∙ We assume that A(bool) will be the classical Boolean lattice for the bi-valued crisp case,whereas A(lat) will be a many-valued complete lattice with a wide repertoire of (mono-tone) connectives.

B : bi-valued or “crisp” case, where we make use of φbool and argbool.

M : many-valued or “fuzzy” case, where where we make use of φlat and arglat.

S R V Herbrand UniverseO P B ∅O P M ∅O F B TΣ∅s0,boolO F M TΣ∅s0,latS P B ∅S P M ∅S F B TΣ∅s0,...,sn,boolS F M TΣ∅s0,...,sn,lat

Towards a Categorical Description of Fuzzy Logic Programming 7 / 10

Page 133: y V Taller de Programación Funcional (TPF)

S R V Herbrand BaseO P B F,T= (argbool ∘TΣPL∖¬,&)∅s0,boolO P M a1, . . . ,an= (arglat ∘TΣPL∖¬,&)∅s0,latO F B (argbool ∘TΣPL∖¬,&

∘TΣ)∅s0,boolO F M (arglat ∘TΣPL∖¬,&

∘TΣ)∅s0,latS P B F,T= (argbool ∘TΣPL∖¬,&)∅s0,...,sn,boolS P M a1, . . . ,an= (arglat ∘TΣPL∖¬,&)∅s0,...,sn,latS F B (argbool ∘TΣPL∖¬,&

∘TΣ)∅s0,...,sn,boolS F M (arglat ∘TΣPL∖¬,&

∘TΣ)∅s0,...,sn,lat

S R V SentencesO P B (argbool)2 ∘ (TΣPL∖¬,&×TΣPL∖¬) ∘φboolXs0,boolO P M (arglat)2 ∘ (TΣPL∖¬,&×TΣPL∖¬) ∘φlatXs0,latO F B (argbool)2 ∘ (TΣPL∖¬,&×TΣPL∖¬) ∘TΣ ∘φ S∖boolXS, where S = s0,boolO F M (arglat)2 ∘ (TΣPL∖¬,&×TΣPL∖¬) ∘TΣ ∘φ S∖latXS, where S = s0,latS P B (argbool)2 ∘ (TΣPL∖¬,&×TΣPL∖¬) ∘φboolXs0,...,sn,boolS P M (arglat)2 ∘ (TΣPL∖¬,&×TΣPL∖¬) ∘φlatXs0,...,sn,latS F B (argbool)2 ∘ (TΣPL∖¬,&×TΣPL∖¬) ∘TΣ ∘φ S∖boolXS, where S = s0, . . . ,sn,boolS F M (arglat)2 ∘ (TΣPL∖¬,&×TΣPL∖¬) ∘TΣ ∘φ S∖latXS, where S = s0, . . . ,sn,lat

Acknowledgements: Carlos Vazquez and Gines Moreno received grants for International mo-bility from the University of Castilla-La Mancha (CYTEMA project and “Vicerrectorado deProfesorado”).

Bibliography

[1] J. F. Baldwin, T. P. Martin, and B. W. Pilsworth. Fril- Fuzzy and Evidential Reasoning inArtificial Intelligence. John Wiley & Sons, Inc., 1995.

[2] R. Caballero, M. Rodrıguez, and C. A. Romero. A transformation-based implementationfor clp with qualification and proximity. CoRR, abs/1009.1976, 2010.

[3] R. Ebrahim. Fuzzy logic programming. Fuzzy Sets and Systems, 117(2):215–230, 2001.

[4] Samuel Eilenberg and G. Max Kelly. Closed categories. In Samuel Eilenberg et al., editor,Proceedings of the Conference on Categorical Algebra, La Jolla 1965, pages 421–562.Springer-Verlag, 1966.

[5] Samuel Eilenberg and Saunders MacLane. General theory of natural equivalences. Trans-actions of the American Mathematical Society, 58(2):231–294, 1945.

[6] P. Eklund, M.A. Galan, R. Helgesson, and J. Kortelainen. Fuzzy sentences. in progress.

Towards a Categorical Description of Fuzzy Logic Programming 8 / 10

Page 134: y V Taller de Programación Funcional (TPF)

[7] P. Eklund, M.A. Galan, R. Helgesson, and J. Kortelainen. Fuzzy terms. Fuzzy Sets andSystems. in press.

[8] P. Eklund, M.A. Galan, R. Helgesson, and J. Kortelainen. Paradigms for many-sorted non-classical substitutions. In 2011 41st IEEE International Symposium on Multiple-ValuedLogic (ISMVL 2011), pages 318–321, 2011.

[9] Patrik Eklund, Maria Angeles Galan, Manuel Ojeda-Aciego, and Agustin Valverde. Setfunctors and generalised terms. Proc. IPMU 2000, 8th Information Processing and Man-agement of Uncertainty in Knowledge-Based Systems Conference, III:1595–1599, 2000.

[10] Robert Helgesson. Generalized General Logics. PhD thesis, Umea University, Departmentof Computing Science, 2013.

[11] M. Ishizuka and N. Kanai. Prolog-ELF Incorporating Fuzzy Logic. In Aravind K. Joshi,editor, Proc. of the 9th International Joint Conference on Artificial Intelligence (IJCAI’85).Los Angeles, CA, August 1985., pages 701–703. Morgan Kaufmann, 1985.

[12] P. Julian, G. Moreno, and J. Penabad. On the declarative semantics of multi-adjoint logicprograms. In Proc. of the 10th International Work-Conference on Artificial Neural Net-works, IWANN’09, pages 253–260. Springer, Lecture Notes in Computer Science 5517,2009.

[13] P. Julian and C. Rubio-Manzano. A declarative semantics for bousi prolog. In Proc. of the11th ACM SIGPLAN conference on Principles and practice of declarative programming,PPDP’09, pages 149–160, New York, USA, 2009. ACM.

[14] M. Kifer and V.S. Subrahmanian. Theory of generalized annotated logic programming andits applications. Journal of Logic Programming, 12:335–367, 1992.

[15] Frank Klawonn and Rudolf Kruse. A lukasiewicz logic based prolog. Mathware and SoftComputing, 1:5–29, 1994.

[16] R. C. T. Lee. Fuzzy Logic and the Resolution Principle. Journal of the ACM, 19(1):119–129, 1972.

[17] Deyi Li and Dongbo Liu. A fuzzy Prolog database system. John Wiley & Sons, Inc., 1990.

[18] J. W. Lloyd. Foundations of logic programming. Springer-Verlag, 1984.

[19] Saunders MacLane. Categories for the working mathematician. Springer-Verlag, 1971.

[20] J. Medina, M. Ojeda-Aciego, and P. Vojtas. Similarity-based Unification: a multi-adjointapproach. Fuzzy Sets and Systems, 146:43–62, 2004.

[21] Susana Munoz-Hernandez, Vıctor Pablos Ceruelo, and Hannes Strass. RFuzzy: Syntax,semantics and implementation details of a simple and expressive fuzzy tool over Prolog.Information Sciences, 181(10):1951–1970, 2011.

Towards a Categorical Description of Fuzzy Logic Programming 9 / 10

Page 135: y V Taller de Programación Funcional (TPF)

[22] J. Pavelka. On fuzzy logic i, ii, iii. Zeitschrift fur Math. Logik und Grundlagen der Math,25:4552, 119134, 447464, 1979.

[23] M. Rodrıguez-Artalejo and C. A. Romero-Dıaz. Quantitative logic programming revis-ited. In J. Garrigue and M. Hermenegildo, editors, Functional and Logic Programming(FLOPS’08), pages 272–288. Springer LNCS 4989, 2008.

[24] David E. Rydeheard and Rod M. Burstall. A categorical unification algorithm. In David H.Pitt, Samson Abramsky, Axel Poigne, and David E. Rydeheard, editors, CTCS, volume 240of Lecture Notes in Computer Science, pages 493–505. Springer, 1985.

[25] M. I. Sessa. Approximate reasoning by similarity-based SLD resolution. Fuzzy Sets andSystems, 275:389–426, 2002.

[26] M. H. van Emden. Quantitative deduction and its fixpoint theory. Journal of Logic Pro-gramming, 3(1):37–53, 1986.

[27] P. Vojtas. Fuzzy Logic Programming. Fuzzy Sets and Systems, Elsevier, 124(1):361–370,2001.

Towards a Categorical Description of Fuzzy Logic Programming 10 / 10

Page 136: y V Taller de Programación Funcional (TPF)

Analyzing Fuzzy Logic Computations with Fuzzy XPath

Jesús M. Almendros-Jiménez1, Alejandro Luna 2, Ginés Moreno3 and CarlosVázquez4

1 [email protected]. de Lenguajes y Computación

Universidad de Almería04120 Almería (Spain)

2 [email protected] [email protected]

4 [email protected]. of Computing Systems

University of Castilla-La Mancha02071 Albacete (Spain)

Abstract: Implemented with a fuzzy logic language by using the FLOPER tooldeveloped in our research group, we have recently designed afuzzy dialect of thepopular XPath language for the flexible manipulation of XML documents. In thispaper we focus on the ability ofFuzzy XPathfor exploring derivation trees generatedby FLOPER once they are exported in XML format, which somehowserves as adebugging/analizing tool for discovering the set of fuzzy computed answers for agiven goal, performing depth/breadth-first traversals of its associated derivation tree,finding non fully evaluated branches, etc., thus reinforcing the bi-lateral synergiesbetweenFuzzy XPathand FLOPER.

Keywords: XPath; Fuzzy (Multi-adjoint) Logic Programming; Debugging

1 Introduction

Logic Programming(LP) [Llo87] is being widely used from several decades ago for problemsolving and knowledge representation, thus providing a great amount of foundations and tech-niques devoted to produce real world applications. Some steps beyond, during the last yearsimportant research efforts have been performed for introducing inside the LP paradigm sometechniques/constructs based on fuzzy logic in order to explicitly treat with uncertainty and ap-proximated reasoning in a natural way. Following this trail, several fuzzy logic programmingsystems have been developed [KS92, BMP95, Voj01, GMV04, MCS11], where the classical in-ference mechanism of SLD–Resolution has been replaced by a fuzzy variant which is able tohandle partial truth in a comfortable way.

This is the case too ofMulti-Adjoint Logic Programming[MOV04], MALP in brief, where afuzzy program can be seen as a set of rules each one annotated with its own truth degree (a valueof a complete lattice, for instance, the real interval[0,1]). Goals are evaluated in two separatecomputational phases. During theoperationalphase,admissible steps(a generalization of the

Analyzing Fuzzy Logic Computations with Fuzzy XPath 1 / 15

Page 137: y V Taller de Programación Funcional (TPF)

classicalmodus ponensinference rule) are systematically applied by a backward reasoning pro-cedure in a similar way to classical resolution steps in purelogic programming. More precisely,in an admissible step, for a selected atomA in a goal and a rule⟨H←B;v⟩ of the program, if thereis a most general unifierθ of A andH, then atomA is substituted by the expression(v&B)θ ,where “&” is an adjoint conjunction evaluatingmodus ponens. Finally, the operational phase re-turns a computed substitution together with an expression where all atoms have been exploited.This last expression is then interpreted under a given lattice during what we call theinterpretivephase, hence returning a pair⟨truth degree;substitution⟩ which is the fuzzy counterpart of theclassical notion of computed answer traditionally used in pure logic programming.

On the other hand, the eXtensible Markup Language (XML) is widely used in many areas ofcomputer software to represent machine readable data. XML provides a very simple language torepresent the structure of data, using tags to label pieces of textual content, and a tree structure todescribe the hierarchical content. XML emerged as a solution to data exchange between appli-cations where tags permit to locate the content. XML documents are mainly used in databases.The XPath language [BBC+07] was designed as a query language for XML in which the path ofthe tree is used to describe the query. XPath expressions canbe adorned with boolean conditionson nodes and leaves to restrict the number of answers of the query. XPath is the basis of a morepowerful query language (called XQuery) designed to join multiple XML documents and to giveformat to the answer. In [ALM11, ALM12a] we have presented an XPath interpreter (togetherwith a debugger, as documented in [ALM12b, ALM13]) extended with fuzzy commands whichsomehow rely on the implementation based on fuzzy logic programming by using FLOPER.

Whereas in Sections2 and 3 we summarize the main features of both thefuzzy XPathin-terpreter and the fuzzy logic programming environment FLOPER, respectively, in Section4we go deeper on the feedbacks between both tools. More exactly we show that, even whenFLOPER was used for implementingfuzzy XPath, now this last language is very useful forformulating queries to be executed againts XML documents representing derivation trees de-picted by FLOPER, thus becoming into a “debugging” technique which can be embedded intothe programming environment for analyzing some interesting details (fuzzy computed answers,tree traversals, partial branches, etc.) about fuzzy logiccomputations. Finally, in Section5 weconclude and present future work.

2 Fuzzy XPath

In this section we will summarize the main elements of our proposed fuzzy XPath language de-scribed in [ALM12a, ALM11] (the tool can be freely downloaded and tested on-line inhttp://dectau.uclm.es/fuzzyXPath/). On this flexible dialect of XPath, we haveincorporated two structural constraints calledDOWN andDEEP to which a certain degree of rele-vance is associated. So, whereasDOWN provides a ranked set of answers depending on the paththey are found from “top to down” in the XML document,DEEP provides a ranked set of answersdepending on the path they are found from “left to right” in the XML document. Both structuralconstraints can be used together, assigning degree of importance with respect to the distance tothe root XML element. Secondly, our fuzzy XPath incorporates fuzzy variants ofand andorfor XPath conditions. Crispandandor operators are used in standard XPath over boolean con-

Analyzing Fuzzy Logic Computations with Fuzzy XPath 2 / 15

Page 138: y V Taller de Programación Funcional (TPF)

ditions, and enable to impose boolean requirements on the answers. XPath boolean conditionscan be referred to attribute values and node content, in the form of equality and range of literalvalues, among others. However, theandandor operators applied to two boolean conditions arenot precise enough when the programmer does not give the samevalue to both conditions. Forinstance, some answers can be discarded when they could be ofinterest by the programmer, andaccepted when they are not of interest. Besides, programmers would need to know in whichsense a solution is better than another. When several boolean conditions are imposed on a query,each one contributes to satisfy the programmer’s preferences in a different way and perhaps, theprogrammer’s satisfaction is distinct for each solution.

We have enriched the arsenal of operators of XPath with fuzzyvariants ofandandor. Partic-ularly, we have considered three versions ofand: and+, and, and- (and the same foror : or+ ,or, or-) which make more flexible the composition of fuzzy conditions. Three versions for eachoperator that come for free from our adaptation of fuzzy logic to the XPath paradigm. One ofthe most known elements of fuzzy logic is the introduction offuzzy versions of classical booleanoperators.Product, ŁukasiewiczandGödel fuzzy logics are considered as the most prominentlogics and give a suitable semantics to fuzzy operators. Ourcontribution is now to give senseto fuzzy operators into the XPath paradigm, and particularly in programmer’s preferences. Weclaim that in our work the fuzzy versions provide a mechanismto force (and debilitate) condi-tions in the sense that stronger (and weaker) programmer preferences can be modeled with theuse of stronger (and weaker) fuzzy conditions. The combination of fuzzy operators in queriespermits to specify a ranked set of fuzzy conditions according to programmer’s requirements.

Furthermore, we have equipped XPath with an additional operator that is also traditional infuzzy logic: the average operatoravg. This operator offers the possibility to explicitly giveweight to fuzzy conditions. Rating such conditions byavg, solutions increase its weight in aproportional way. However, from the point view of the programmer’s preferences, it forces theprogrammer to quantify his(er) wishes which, in some occasions, can be difficult to measure.For this reason, fuzzy versions ofandandor are better choices in some circumstances.

Finally, we have equipped our XPath based query language with a mechanism for thresholdingprogrammer’s preferences, in such a way that programmer canrequest that requirements aresatisfied over a certain percentage.

The proposed fuzzy XPath is described by the following syntax:

xpath := [‘[’deep-down‘]’ ]pathpath := literal | text() | node |@att | node/path | node//pathnode := QName | QName[cond]cond := xpath op xpath | xpath num-op numberdeep := DEEP=number

down := DOWN=numberdeep-down := deep | down | deep ‘;’ down

num-op := > | = | < | <>fuzzy-op := and | and+ | and- | or | or+ | or- | avg | avgnumber,number

op := num-op | fuzzy-op

Basically, our proposal extends XPath as follows:

Analyzing Fuzzy Logic Computations with Fuzzy XPath 3 / 15

Page 139: y V Taller de Programación Funcional (TPF)

Figure 1: Fuzzy Logical Operators

&P(x,y) = x∗y ∣P(x,y) = x+y−x∗y Product: and/or&G(x,y) = min(x,y) ∣G(x,y) = max(x,y) Gödel: and+/or-&L(x,y) = max(x+y−1,0) ∣L(x,y) = min(x+y,1) Łuka.: and-/or+

– Structural constraints. A given XPath expression can be adorned with «[DEEP = r1; DOWN= r2]» which means that thedeepnessof elements is penalized byr1 and that theorder ofelements is penalized byr2, and such penalization is proportional to the distance (i.e., thelength of the branch and the weight of the tree, respectively). In particular, «[DEEP = 1;DOWN = r2]» can be used for penalizing only w.r.t. document order.DEEP works for//, thatis, the deepness in the XML tree is only computed when descendant nodes are explored,while DOWN works for both/ and//. Let us remark thatDEEP andDOWN can be used severaltimes on the mainpathexpression and/or any othersub-pathincluded in conditions.

– Flexible operators in conditions. We consider three fuzzy versions for each one ofthe classical conjunction and disjunction operators (t-norms and t-conorms, respectively[SS83, KMP00]), also called connectives or aggregators, describingpessimistic, realisticand optimistic scenarios, see Figure1. In XPath expressions the fuzzy versions of theconnectives make harder to hold boolean conditions, and therefore can be used to debil-itate/force boolean conditions. Furthermore, assuming two givenRSV’s (Retrieval StatusValues) r1 andr2, theavgoperator is obviously defined with a fuzzy taste as(r1+ r2)/2,whereas itspriority-basedvariant, i.e.avgp1, p2, acts as(p1∗ r1+ p2∗ r2)/(p1+ p2).

Figure 2: Input XML document in our examples

<bib><name>Classic Literature</name><book year="2001" price="45.95">

<title>Don Quijote de la Mancha</title><author>Miguel de Cervantes Saavedra</author><references>

<novel year="1997" price="35.99"><name>La Galatea</name><author>Miguel de Cervantes Saavedra</author><references>

<book year="1994" price="25.99"><title>Los trabajos de Persiles y Sigismunda</title><author>Miguel de Cervantes Saavedra</author>

</book></references>

</novel></references>

</book><novel year="1999" price="25.65">

<title>La Celestina</title><author>Fernando de Rojas</author>

</novel></bib>

Analyzing Fuzzy Logic Computations with Fuzzy XPath 4 / 15

Page 140: y V Taller de Programación Funcional (TPF)

Figure 3: Execution of query «/bib[DEEP=0.8;DOWN=0.9]//title»

Document RSV computation

<result><title rsv="0.8000">Don Quijote de la Mancha</title><title rsv="0.7200">La Celestina</title><title rsv="0.2949">Los trabajos de Persiles...</title>

</result>

0.8000= 0.80.7200= 0.8∗0.90.2949= 0.85 ∗0.9

Figure 4: Execution of query «//book[@year<2000 avg3,1 @price<50]/title»

Document RSV computation

<result><title rsv="1.00">Los trabajos de Persiles...</title><title rsv="0.25">Don Quijote de la Mancha</title>

</result>

1.00= (3∗1+1∗1)/(3+1)0.25= (3∗0+1∗1)/(3+1)

Figure 5: Execution of query «/bib[DEEP=0.5]//book[@year<2000 avg3,1 @price<50]/title»

Document RSV computation

<result><title rsv="0.25">Don Quijote de la Mancha</title><title rsv="0.0625">Los trabajos de Persiles...</title>

</result>

0.25= (3∗0+1∗1)/(3+1)0.0625= 0.54 ∗ (3∗1+1∗1)/(3+1)

In general, a fuzzy XPath expression defines, w.r.t. an XML document, a sequence of subtreesof the XML document where each subtree has an associated RSV.XPath conditions, which aredefined as fuzzy operators applied to XPath expressions, compute a new RSV from the RSVs ofthe involved XPath expressions, which at the same time, provides a RSV to the node. In order toillustrate these explanations, let us see some examples of our proposed fuzzy version of XPathaccording to the XML document shown of Figure2.

Example1 Let us consider the fuzzy XPath query of Figure3 requestingtitle’s penalizing theoccurrences from the document root by a proportion of0.8 and 0.9 by nesting and ordering,respectively, and for which we obtain the file listed in Figure 3. In such document we haveincluded as attribute of each subtree, its corresponding RSV. The highest RSVs correspond tothe mainbooksof the document, and the lowest RSVs represent thebooksoccurring in nestedpositions (those annotated as relatedreferences).

Example2 Figure 4 shows the answer associated to a search of books, possibly referenceddirectly or indirectlyfrom other books, whose publishing year and price are relevant but the yearis three times more important than the price. Finally, in Figure 5 we combine both kinds of(structural/conditional) operators, and the ranked list of solutions is reversed.

Finally, we can use command «[FILTER = r]» at the beginning of a query for filtering its final setof solutions in the sense that only those ones with RSV not lower thanr will conform the output.

Analyzing Fuzzy Logic Computations with Fuzzy XPath 5 / 15

Page 141: y V Taller de Programación Funcional (TPF)

3 Fuzzy Logic Programming with MALP and FLOPER

Multi-Adjoint Logic Programming[MOV04], MALP in brief, can be thought as a fuzzy ex-tension of Prolog and it is based on a first order language,L , containing variables, func-tion/constant symbols, predicate symbols, and several arbitrary connectives such as implica-tions (←1,←2, . . . ,←m), conjunctions (&1,&2, . . . ,& k), disjunctions (∨1,∨2, . . . ,∨l ), and gen-eral hybrid operators (“aggregators” @1,@2, . . . ,@n), used for combining/propagating truth val-ues through the rules, and thus increasing the language expressiveness. Additionally, our lan-guageL contains the values of amulti-adjoint latticein the form⟨L,⪯,←1,&1, . . . ,←n,&n⟩,equipped with a collection ofadjoint pairs⟨←i ,& i⟩ where each &i is a conjunctor intended tothe evaluation ofmodus ponens[SS83, KMP00, MOV04]. A rule is a formula “A←i B with α”,whereA is an atomic formula (usually called thehead), B (which is called thebody) is a formulabuilt from atomic formulasB1, . . . ,Bn (n≥ 0 ), truth values ofL and conjunctions, disjunctionsand general aggregations, and finallyα ∈ L is the “weight” ortruth degreeof the rule. The setof truth valuesL may be the carrier of any complete bounded lattice, as for instance occurs withthe set of real numbers in the interval[0,1] with their corresponding ordering⪯R. Consider,for instance, the following program,P, with associated multi-adjoint lattice⟨[0,1],⪯R,←P,&P⟩(where labelP means forProduct logicwith the following connective definitions for implicationand conjunction symbols, respectively: “←P (x,y) = min(1,x/y)”, “& P(x,y) = x∗y”, as well as“@aver(x,y) = (x+y)/2”):

R1 : oc(X) <- s(X) & prod ( f (X) @aver w(X)) with 1.R2 : s(madrid) with 0.8. R5 : s(tokyo) with 0.9.R3 : f (madrid) with 0.8. R6 : f (tokyo) with 0.7.R4 : w(madrid) with 0.9. R7 : w(tokyo) with 0.6.R8 : s(istambul) with 0.3. R11 : s(baku) with 0.3.R9 : f (istambul) with 0.4. R12 : f (baku) with 0.2.R10 : w(istambul) with 0.8. R13 : w(baku) with 0.5.

This program models, through predicateoc/1, the chances of a city for being an “olympic city”(i.e., for hosting olympic games). Predicateoc/1 is defined in ruleR1, whose body collects theinformation from three other predicates,s/1, f/1 andw/1, modeling, respectively, thesecuritylevel, thef acilities and the goodweather of a certain city. These predicates are defined in rulesR2 to R13 for four cities (Madrid, Istambul, TokyoandBaku), in such a way that, for each city,the characteristic modeled by each predicate is better the greater the truth value of the rule.

In order to run and manage MALP programs, during the last years we have designed theFLOPER system [MM08, MMPV10, MMPV11], which is freely accessible from the Web sitehttp://dectau.uclm.es/floper/. The parser of our tool has been implemented by using the classicalDCG’s (Definite Clause Grammars) resource of the Prolog language, since it is a convenientnotation for expressing grammar rules. Once the application is loaded inside a Prolog interpreter,it shows a menu which includes options for loading/compiling, parsing, listing and saving fuzzyprograms, as well as for executing/debugging fuzzy goals. All these actions are based on thecompilationof the fuzzy code into standard Prolog code.

The FLOPER system is able to manage programs with very different lattices. In order toassociate a certain lattice with its corresponding program, such lattice must be loaded into the

Analyzing Fuzzy Logic Computations with Fuzzy XPath 6 / 15

Page 142: y V Taller de Programación Funcional (TPF)

Figure 6: Execution tree for programP and goaloc(X)

tool as a pure Prolog program. As an example, the following clauses show the program modelingthe lattice of the real interval[0,1] with the usual ordering relation and connectives (where themeaning of the mandatory predicatesmember, top, bot andleq is obvious):

member(X):- number(X), 0=<X, X=<1. bot(0).leq(X,Y):- X=<Y. top(1).and_prod(X,Y,Z):- pri_prod(X,Y,Z). pri_prod(X,Y,Z):- Z is X * Y.or_prod(X,Y,Z):- pri_prod(X,Y,U1),pri_add(X,Y,U2),pri_sub(U2,U1,Z).pri_add(X,Y,Z):- Z is X+Y. pri_sub(X,Y,Z):- Z is X-Y.

FLOPER includes two main ways for evaluating a goal, given a MALP program and its cor-responding lattice. Option “run” translates the whole program into a pure Prolog program andevaluates the (also translated) goal, thus obtaining a set of fuzzy computed answers, whereas, onthe other hand, option “tree” displays the execution (or derivation) tree for the intended goal1.For the purpose of this paper, we will focus on this last option in order to obtain a tree (detailingthe whole computational behaviour) for being afterwards analyzed with fuzzy XPath.

1 Users can select the deepest level to be built, which is obviously mandatory when trees are infinite.

Analyzing Fuzzy Logic Computations with Fuzzy XPath 7 / 15

Page 143: y V Taller de Programación Funcional (TPF)

Let us consider the previously described programP, and goal “oc(X)”, that asks for theeligibility of each one of the four cities inP as “Olympic City”. We use option “tree” toobtain the execution tree, which is generated by FLOPER in three different formats. Firstly thetree is displayed in graphical mode, as a PNG file, as shown in Figure6. The tree is composedby two kinds of nodes. Yellow nodes represent states reachedby FLOPER following the statetransition system that describes the operational semantics of MALP [MOV04]. The up-mostnode represents the first state (that is, the goal and the identity substitution), and subsequentlower nodes are its children states (that is, states reachedfrom the goal). A state contains aformula in the upper side and a substitution (the record of substitutions applied from the originalgoal to reach that state) at the bottom. A final state, if reached, is a fuzzy computed answer, thatis, its formula is an element of the lattice. Blue rounded nodes that intermediate between a pairof yellow nodes (a pair of states) represent program rules; specifically, the program rule that isexploited in order to go from one state (the upper state) to another (the lower one). These rulesare named with letter “R” plus its position in the program. For example, observe thatfrom theinitial state to the next state, ruleR1 of the program has been exploited, as shown in the blueintermediate node. As an exception, when all atoms have beenexploited in (the formula of)a certain state, the following blue node indicates “result”, informing that the next state is afuzzy computed answer.

FLOPER can also generate the execution tree in two textual formats. The first one containsa plain description of the tree, while the second one provides an XML structure to that descrip-tion, therefore becoming the focus of interest of this paper. In this XML format we define thetag “node” to contain all the information of a node, such as the rule performed to reach thatstate (that is “R0” in the case of the first state), the formula of the state, the accumulated sub-stitution and the children nodes, given by the tags “rule”, “ goal”, “ substitution” and“children”, respectively. The content of tags “rule”, “ goal” and “substitution” is astring, while the content of the tag “children” is a set of tags “node”, as seen in the followinglines, corresponding to the XML file associated to the the tree depicted in Figure6.

<node><rule>R0</rule><goal>oc(X)</goal><substitution></substitution><children>

<node><rule>R1</rule><goal>and_prod(s(X),agr_aver(f(X),w(X)))</goal><substitution>X1/X</substitution><children>

<node><rule>R2</rule><goal>and_prod(0.8,agr_aver(f(madrid),w(madrid)))</goal><substitution>X/madrid,X1/madrid</substitution><children>

<node><rule>R3</rule><goal>and_prod(0.8,agr_aver(0.8,w(madrid)))</goal><substitution>X/madrid,X1/madrid</substitution><children>

<node><rule>R4</rule><goal>and_prod(0.8,agr_aver(0.8,0.9))</goal>

Analyzing Fuzzy Logic Computations with Fuzzy XPath 8 / 15

Page 144: y V Taller de Programación Funcional (TPF)

<substitution>X/madrid,X1/madrid</subtitution><children>

<node><rule>result</rule><goal>0.6800000000000002</goal><substitution>X/madrid,X1/madrid

</substitution><children></children>

</node></children>

</node></children>

</node></children>

</node>...

<node><rule>result</rule><goal>0.585</goal><substitution>X/tokyo,X1/tokyo

</substitution><children></children>

</node>...

</node></children>

</node>

4 Exploring Derivation Trees with Fuzzy XPath

In this section we present a very powerful method to automatically exploring the behaviour ofa MALP program using thefuzzy XPathtool described in Section2. The idea is to usefuzzyXPathover the execution tree generated by FLOPER for a certain program and goal. That treeis obtained through option “tree” using the XML format just explained before in Section3.For instance, an easy but interesting XPath query should be “//node/rule” which lists allthe rules exploited along the execution of a goal (in the caseof the tree depicted in Figure6, wewould obtain the whole set of rules defined in the programP of our running example).

Assume now that we plan to obtain the whole set of fuzzy computed answers for a given goaland program. This information, always collected in the leaves of execution trees (even whenthere exists the possibility of finding leaves non containing fuzzy computed answers, as we willsee afterwards) as illustrated in Figure7, can be retrieved by means of thefuzzy XPathquery“//node[/rule/text()=result]”, meaning that, return eachnodesuch that the contentof its rule tag is “result”. The XML text shown below Figure7 represents the output of ourfuzzyXPath interpreter for that query, where the selected nodes have been highlighted inside a bluecloud into the drawn tree above. Note that the resuting XML file contains four solutions (one foreach city), where attribute “rsv” indicates how much each city fulfills the original query (inthisexample, this value is the same in all cases, that is, just themaximum one 1).

Strongly related with the previous experiment, but not directly focusing now on fuzzy com-puted answers, query “//node[children[not(text())]]” returns the leaves of the tree.

Analyzing Fuzzy Logic Computations with Fuzzy XPath 9 / 15

Page 145: y V Taller de Programación Funcional (TPF)

Figure 7: Executing queries «//node[/rule/text()=result]» and «//node[children[not(text())]]»

<result><node rsv="1.0">

<rule>result</rule><goal>0.6800000000000002</goal><substitution>X/madrid, X1/madrid</substitution><children></children>

</node><node rsv="1.0">

<rule>result</rule><goal>0.585</goal><substitution>X/tokyo, X1/tokyo</substitution><children></children>

</node><node rsv="1.0">

<rule>result</rule><goal>0.18000000000000002</goal><substitution>X/istambul, X1/istambul</substitution><children></children>

</node><node rsv="1.0">

<rule>result</rule><goal>0.105</goal><substitution>X/baku, X1/baku</substitution><children></children>

</node></result>

Note that, in the case of our current programP and goal “oc(X)”, the corresponding outputfor this query is, once again, the same than the one reported previously in Figure7 but, as saidin the previous paragraph, this is not the general case. In fact, we can formulate a query like

Analyzing Fuzzy Logic Computations with Fuzzy XPath 10 / 15

Page 146: y V Taller de Programación Funcional (TPF)

Figure 8: Executing query «[FILTER=0.5][DEEP=0.9]//node/goal»

<result><goal rsv="1.0">oc(X)</goal><goal rsv="0.81">and_prod(s(X),agr_aver(f(X),w(X)))</goal><goal rsv="0.6561">and_prod(0.8,agr_aver(f(madrid),w(madrid)))</goal><goal rsv="0.6561">and_prod(0.9,agr_aver(f(tokyo),w(tokyo)))</goal><goal rsv="0.6561">and_prod(0.3,agr_aver(f(istambul),w(istambul)))</goal><goal rsv="0.6561">and_prod(0.3,agr_aver(f(baku),w(baku)))</goal><goal rsv="0.531441">and_prod(0.8,agr_aver(0.8,w(madrid)))</goal><goal rsv="0.531441">and_prod(0.9,agr_aver(0.7,w(tokyo)))</goal><goal rsv="0.531441">and_prod(0.3,agr_aver(0.4,w(istambul)))</goal><goal rsv="0.531441">and_prod(0.3,agr_aver(0.2,w(baku)))</goal>

</result>

“//node[children[not(text())] and rule/text()<>"result"]/goal”, helping usto know whether the tree has any partially evaluated leaf (i.e., non reporting a fuzzy computedanswer) since it returns nodes at the end of a branch that are not labeled with therule tag con-taining “result”. The important meaning of this query resides on its capability for findingpossible sources of infinite loops. For instance, if we work with a program containing a rule like“p <- p”, when using FLOPER for generating an execution tree for “p” with any depth level,it will always contain at least a leaf reported by the previous fuzzy XPathquery.

In order to take advantage of the enrichments introduced in the fuzzy XPathlanguage, thefollowing query makes use of “DEEP” and “FILTER” commands in order to perform apartialbreadth-first traversalon execution trees as shown in Figure8. In the resulting XML output,10 nodes have been selected from the execution tree with different “rsv” values, varying from1 in the case of the original goal (that has not been penalized) till 0 .531441 for the fourth row,representing nodes whose depth (“DEEP-level”) remains above the filter. Note that the use of

Analyzing Fuzzy Logic Computations with Fuzzy XPath 11 / 15

Page 147: y V Taller de Programación Funcional (TPF)

the directive “DEEP” segregates the nodes of the tree from top to bottom, since lower nodes inthe tree are represented deeper in the input XML file.

Analogously, in Figure9 we use “DOWN” instead of “DEEP” for producingpartial depht-firsttraversalson execution trees. In this case, our query segregates the nodes from left to right incolumns, since the more left the node appears in the tree, theupper is it in the XML outputand, thus, the less penalized by “DOWN”. As previously, 10 nodes have been selected again with“rsv” ranging from 1 -upper nodes in the XM file- in the left column,till 0 .7, as shown in thesecond column.

Figure 9: Executing query «[FILTER=0.5][DOWN=0.7]//node/goal»

<result><goal rsv="1.0">oc(X)</goal><goal rsv="1.0">and_prod(s(X),agr_aver(f(X),w(X)))</goal><goal rsv="1.0">and_prod(0.8,agr_aver(f(madrid),w(madrid)))</goal><goal rsv="1.0">and_prod(0.8,agr_aver(0.8,w(madrid)))</goal><goal rsv="1.0">and_prod(0.8,agr_aver(0.8,0.9))</goal><goal rsv="1.0">0.6800000000000002</goal><goal rsv="0.7">and_prod(0.9,agr_aver(f(tokyo),w(tokyo)))</goal><goal rsv="0.7">and_prod(0.9,agr_aver(0.7,w(tokyo)))</goal><goal rsv="0.7">and_prod(0.9,agr_aver(0.7,0.6))</goal><goal rsv="0.7">0.585</goal>

</result>

In order to illustrate the high expressive power of thefuzzy XPathlanguage, in the following wetry to model queries joining several concepts (for instance, the topics of “weather” and “Istam-bul” modeled inP as predicate “w” and constant “istambul”, respectively). Assume that we arefirstly interested on nodes informing about “weather”, i.e., focusing on the fourth rows of ourexecution tree, thus meaning that sub-string “w(” must appear in tag “goal”, while our second

Analyzing Fuzzy Logic Computations with Fuzzy XPath 12 / 15

Page 148: y V Taller de Programación Funcional (TPF)

preference asks for nodes in the branch containing the word “istambul” in tag “substitution”.In order to join these two constraints, instead of using crisp “or/and” operators (or even differ-ent fuzzy variants of such connectives already implementedin fuzzy XPath), we prefer to use anarithmetical average giving twice importance to the secondrequirement than to the first one. Thefuzzy XPathformulation of our query entitles Figure10, where we graphically show the set ofsolutions as well as the output in the resulting XML file.

Figure 10:«node[/goal[contains(text(),“w(”)]aver1,2 substitution[contains(text(),“istambul”)]]//goal»

<result><goal rsv="1.0">and_prod(0.3,agr_aver(f(istambul),w(istambul)))</goal><goal rsv="1.0">and_prod(0.3,agr_aver(0.4,w(istambul)))</goal><goal rsv="0.6667">and_prod(0.3,agr_aver(0.4,0.8))</goal><goal rsv="0.6667">0.18000000000000002</goal><goal rsv="0.3333">and_prod(s(X),agr_aver(f(X),w(X)))</goal><goal rsv="0.3333">and_prod(0.8,agr_aver(f(madrid),w(madrid)))</goal><goal rsv="0.3333">and_prod(0.9,agr_aver(f(tokyo),w(tokyo)))</goal><goal rsv="0.3333">and_prod(0.3,agr_aver(f(baku),w(baku)))</goal><goal rsv="0.3333">and_prod(0.8,agr_aver(0.8,w(madrid)))</goal><goal rsv="0.3333">and_prod(0.9,agr_aver(0.7,w(tokyo)))</goal><goal rsv="0.3333">and_prod(0.3,agr_aver(0.2,w(baku)))</goal>

</result>

5 Conclusions and Future Work

In this paper we have shown the mutual benefits between two different fuzzy tools developedin our research group, that is, the FLOPER programming environment and thefuzzy XPathinterpreter. Initially FLOPER was conceived as a tool for implementing flexible software ap-

Analyzing Fuzzy Logic Computations with Fuzzy XPath 13 / 15

Page 149: y V Taller de Programación Funcional (TPF)

plications -as it is the case offuzzy XPath- coded with the fuzzy logic language MALP andoffering options for compiling fuzzy rules to standard Prolog clauses, running goals and drawingexecution trees. Such trees, once modeled in XML format inside the proper FLOPER tool, canbe then analyzed by thefuzzy XPathinterpreter -by means of simple XPath queries augmentedwith fuzzy commands- in order to discover details (such as fuzzy computed answers, possibleinfinite branches and so on) of the computational behaviour of MALP programs after being exe-cuted into FLOPER. In this sense, we plan to integrate an option inside the FLOPER menu forallowing the possibility of performing debugging tasks based onfuzzy XPath.

On the other hand, in [ALM12b, ALM13] we have recently presented afuzzy XPathdebugger(beyond thefuzzy XPathinterpreter) that, for a given XPath expression, the tool offers a setof alternative queries, each one associated to a chance degree indicating the deviations of eachproposal w.r.t. the original query (we useJUMP, DELETE andSWAP operators for covering the maincases of programming errors when describing a path about an XML document). Thus, our tool isfocused on providing the programmer a repertoire of paths that (s)he can use to retrieve answers.Since in this paper we have seen that thefuzzy XPathinterpreter might act as a debugger of fuzzycomputations developed with FLOPER, for the near future we plan too to study the role thatthe properfuzzy XPathdebugger should play for helping the development of applications usingFLOPER.

Acknowledgements: This work has been partially supported by the EU, under FEDER, andthe Spanish Science and Innovation Ministry (MICINN) undergrant TIN2008-06622-C03-03,as well as by Ingenieros Alborada IDI under grant TRA2009-0309, and the JUNTA ANDALU-CIA administration under grant TIC-6114 (proyecto de excelencia). Carlos Vázquez and GinésMoreno received grants for International mobility from theUniversity of Castilla-La Mancha(CYTEMA project and “Vicerrectorado de Profesorado”).

Bibliography

[ALM11] J. Almendros-Jiménez, A. Luna, G. Moreno. A Flexible XPath-based Query Lan-guage Implemented with Fuzzy Logic Programming. InProc. of 5th InternationalSymposium on Rules: Research Based, Industry Focused, RuleML’11. Barcelona,Spain, July 19–21. Pp. 186–193. Springer Verlag, LNCS 6826, 2011.

[ALM12a] J. M. Almendros-Jiménez, A. Luna, G. Moreno. FuzzyLogic Programming for Im-plementing a Flexible XPath-based Query Language.Electr. Notes Theor. Comput.Sci.282:3–18, 2012.

[ALM12b] J. M. Almendros-Jiménez, A. Luna, G. Moreno. A XPath Debugger Based on FuzzyChance Degrees. InOn the Move to Meaningful Internet Systems: ProceedingsOTM 2012 Workshops, Rome, Italy, September 10-14. Pp. 669–672. Springer Ver-lag, LNCS 7567, 2012.

[ALM13] J. Almendros-Jiménez, A. Luna, G. Moreno. Annotating Fuzzy Chance Degreeswhen Debugging XPath Queries. InAdvances in Computational Intelligence - Proc

Analyzing Fuzzy Logic Computations with Fuzzy XPath 14 / 15

Page 150: y V Taller de Programación Funcional (TPF)

of the 12th International Work-Conference on Artificial Neural Networks, IWANN2013 (Special Session on Fuzzy Logic and Soft Computing Application), Tenerife,Spain, June 12-14. Pp. 300–311. Springer Verlag, LNCS 7903, Part II, 2013.

[BBC+07] A. Berglund, S. Boag, D. Chamberlin, M. Fernandez, M. Kay, J. Robie, J. Siméon.XML path language (XPath) 2.0.W3C, 2007.

[BMP95] J. F. Baldwin, T. P. Martin, B. W. Pilsworth.Fril- Fuzzy and Evidential Reasoningin Artificial Intelligence. John Wiley & Sons, Inc., 1995.

[GMV04] S. Guadarrama, S. Muñoz, C. Vaucheret. Fuzzy Prolog: A New Approach UsingSoft Constraints Propagation.Fuzzy Sets and Systems144(1):127–150, 2004.

[KMP00] E. Klement, R. Mesiar, E. Pap.Triangular Norms. Trends in logic, Studia logicalibrary. Springer, 2000.http://books.google.es/books?id=rIyqcjfKMN4C

[KS92] M. Kifer, V. Subrahmanian. Theory of generalized annotated logic programmingand its applications.Journal of Logic Programming12:335–367, 1992.

[Llo87] J. Lloyd. Foundations of Logic Programming. Springer-Verlag, Berlin, 1987.

[MCS11] S. Muñoz-Hernández, V. P. Ceruelo, H. Strass. RFuzzy: Syntax, semantics andimplementation details of a simple and expressive fuzzy tool over Prolog.Inf. Sci.181(10):1951–1970, 2011.

[MM08] P. Morcillo, G. Moreno. Programming with Fuzzy LogicRules by using theFLOPER Tool. In al. (ed.),Proc of the 2nd. Rule Representation, Interchangeand Reasoning on the Web, International Symposium, RuleML’08. Pp. 119–126.Springer Verlag, LNCS 3521, 2008.

[MMPV10] P. Morcillo, G. Moreno, J. Penabad, C. Vázquez. A Practical Management of FuzzyTruth Degrees using FLOPER. In al. (ed.),Proc. of 4nd Intl Symposium on Rule In-terchange and Applications, RuleML’10. Pp. 20–34. Springer Verlag, LNCS 6403,2010.

[MMPV11] P. Morcillo, G. Moreno, J. Penabad, C. Vázquez. Fuzzy Computed Answers Col-lecting Proof Information. In al. (ed.),Advances in Computational Intelligence -Proc of the 11th International Work-Conference on Artificial Neural Networks,IWANN 2011. Pp. 445–452. Springer Verlag, LNCS 6692, 2011.

[MOV04] J. Medina, M. Ojeda-Aciego, P. Vojtáš. Similarity-based Unification: a multi-adjoint approach.Fuzzy Sets and Systems146:43–62, 2004.

[SS83] B. Schweizer, A. Sklar.Probabilistic Metric Spaces. Courier Dover Publ., 1983.http://books.google.es/books?id=8LUd6Txuu5sC

[Voj01] P. Vojtáš. Fuzzy Logic Programming.Fuzzy Sets and Systems124(1):361–370,2001.

Analyzing Fuzzy Logic Computations with Fuzzy XPath 15 / 15

Page 151: y V Taller de Programación Funcional (TPF)

Automatic Proving of Fuzzy Formulae with Fuzzy LogicProgramming and SMT

Miquel Bofill1, Gines Moreno2, Carlos Vazquez2 and Mateu Villaret1

1 [email protected], [email protected] of Computer Science, Applied Mathematics and Statistics

University of Girona17071 Girona (Spain)

2 [email protected], [email protected] of Computing SystemsUniversity of Castilla-La Mancha

02071 Albacete (Spain)

Abstract: In this paper we deal with propositional fuzzy formulae containing sev-eral propositional symbols linked with connectives defined in a lattice of truth de-grees more complex than Bool. We firstly recall an SMT (Satisfiability ModuloTheories) based method for automatically proving theorems in relevant infinitely-valued (including Łukasiewicz and Godel) logics. Next, instead of focusing on sat-isfiability (i.e., proving the existence of at least one model) or unsatisfiability, ourinterest moves to the problem of finding the whole set of models (with a finite do-main) for a given fuzzy formula. We propose an alternative method based on fuzzylogic programming where the formula is conceived as a goal whose derivation treecontains on its leaves all the models of the original formula, by exhaustively inter-preting each propositional symbol in all the possible forms according the whole setof values collected on the underlying lattice of truth-degrees.

Keywords: Fuzzy Logic Programming; Automatic Theorem Proving; SMT

1 Introduction

Research on SAT (Boolean Satisfiability) and SMT (Satisfiability Modulo Theories) [BSST09]represents a successful and large tradition in the development of highly efficient automatic theo-rem solvers for classic logic. More recently there also exist attempts for covering fuzzy logics, asoccurs with the approaches presented in [ABMV12, VBG12]. Moreover, if automatic theoremsolving supposes too an starting point for the foundations of logic programming as well as oneof its important application fields [Llo87, Sti88, Fit96, Apt90, Bra00], in this work we will showsome preliminary guidelines about how fuzzy logic programming can face the automatic provingof fuzzy theorems.

Let us start our discussion with an easy motivating example. Assume that we have a verysimple digital chip with just a single input port and just one output port, such that it revertson Out the signal received from In. The behaviour of such chip can be represented by thefollowing propositional formula F : (In′ ∧Out)∨ (In∧Out ′). Depending on how we interpret

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 1 / 15

Page 152: y V Taller de Programación Funcional (TPF)

Figure 1: Interpreting a formula with two values for signals/propositions In and Out.

each propositional symbol, we obtain the following final set of interpretations for the wholeformula:

I1 : In = 0,Out = 0 ⇒ F = 0 I2 : In = 0,Out = 1 ⇒ F = 1I3 : In = 1,Out = 0 ⇒ F = 1 I4 : In = 1,Out = 1 ⇒ F = 0

A SAT solver easily proves that F is satisfiable since, in fact, it has two models (i.e., inter-pretations of the propositional variables In and Out that assign 1 to the whole formula) repre-sented by I2 and I3. An alternative way for explicitly obtaining such interpretations consistsin using the fuzzy logic environment FLOPER developed in our research group [MMPV10,MMPV11, MMPV12, JMM+13] (http://dectau.uclm.es/floper/). As we will explainin the rest of the paper, when FLOPER executes the following goal (representing formula F)“(@not(i(In)) & i(Out)) | (i(In) & @not(i(Out)))” with respect to a fuzzy

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 2 / 15

Page 153: y V Taller de Programación Funcional (TPF)

Figure 2: Interpreting a formula with three values for signals/propositions In and Out.

logic program composed by just two rules: “i(1) with 1” and “i(0) with 0”, it drawsthe tree shown in Figure 1, where models I2 and I3 appear in the two central leaves of the tree in-side a blue box. Each branch in the tree starts by interpreting variables In and Out and continueswith the evaluation of operators appearing in F .

Advice that whereas formula F describes the behaviour of our chip in an “implicit way”,the whole set of models I2 and I3 “explicitly” describes how the chip successfully works (anyother interpretation not being a model, represents an abnormal behaviour of the chip), hence theimportance of finding the whole set of models for a given formula.

Assume now that we plan to model an “analogic” version of the chip, where both the inputand output signals might vary in an infinite range of values between 0 and 1, such that Out willsimply represent the “complement” of In. The new behaviour of the chip can be expressed againby the same previous formula, but taking into account now that connectives involved in F couldbe defined in a fuzzy way as follows (see also Figure 3 afterwards):

x′ = 1− x Product logic’s negationx∧ y = min(x,y) Godel logic’s conjunctionx∨ y = min(x+ y,1) Łukasiewicz logic’s disjunction

Here we could use an SMT solver to prove that F is satisfiable. Following the approach of thework in [ABMV12], it can be easily checked that F is satisfiable1 with the following SMT-LIBscript, encoding the previous connectives into SAT modulo linear real arithmetic:

1 The formula has infinite models of the form In = x,Out = y such that x+ y = 1.

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 3 / 15

Page 154: y V Taller de Programación Funcional (TPF)

; Set logic: Quantifier Free Linear Real Arithmetic(set-logic QF_LRA)

; min(x,y)(define-fun min ((x Real) (y Real)) Real

(ite (> x y) y x))

; x’ = 1 - x(define-fun agr_not ((x Real)) Real

(- 1 x))

; &G(x,y) = minx,y(define-fun and_godel ((x Real) (y Real)) Real

(min x y))

; |L(x,y) = minx+y,1(define-fun or_luka ((x Real) (y Real)) Real

(min (+ x y) 1))

; Declaration of variables(declare-fun x () Real)(declare-fun y () Real)

; Ordering relation(assert (>= x 0))(assert (<= x 1))(assert (>= y 0))(assert (<= y 1))

; Formula to check(assert (= (or_luka (and_godel (agr_not x) y)

(and_godel x (agr_not y)))1))

; Check for satisfiability(check-sat)

It is easy to understand the SMT-LIB syntax of the previous code. Just in case, we recall thatthe ite expression corresponds to the if-then-else construct. Note that all necessary connectivesare easily encoded as is done in [ABMV12]. It is worth noting that, apart from proving satisfia-bility of a formula, SMT solvers can be used to prove that a formula is a theorem, by checkingunsatisfiability of its negation.

On the other hand, Figure 2 shows too three models in the tree depicted by FLOPER whenconsidering only three kinds of values (that is, 0, 0.5 and 1) for interpreting In and Out. Suchmodels include, apart of I2 and I3 seen before, the interpretation In = 0.5,Out = 0.5 since, as

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 4 / 15

Page 155: y V Taller de Programación Funcional (TPF)

&P(x,y)≜ x∗ y ∣P(x,y)≜ x+ y− x∗ y ←P (x,y)≜ min(1,x/y)

&G(x,y)≜ min(x,y) ∣G(x,y)≜ maxx,y ←G (x,y)≜

1 if y≤ xx otherwise

&L(x,y)≜ max(0,x+ y−1) ∣L(x,y)≜ minx+ y,1 ←L (x,y)≜ minx− y+1,1Figure 3: Conjunctors, disjunctors and implications from Product, Godel and Łukasiewicz logics.

we can see in the detailed computations performed along the middle branch of the tree, we have:

(0.5′∧0.5)∨ (0.5∧0.5′) = ((1−0.5)∧0.5)∨ (0.5∧0.5′) = (0.5∧0.5)∨ (0.5∧0.5′)= min(0.5,0.5)∨ (0.5∧0.5′) = 0.5∨ (0.5∧0.5′) = 0.5∨ (0.5∧ (1−0.5))= 0.5∨ (0.5∧0.5) = 0.5∨min(0.5,0.5) = 0.5∨0.5= min(0.5+0.5,1) = min(1,1) = 1

Similarly, we can check for instance in the second branch of the tree that In = 1,Out = 0.5 isnot a model (in fact, our chip can not return a signal of value 0.5 when its input is 1) since:

(1′∧0.5)∨ (1∧0.5′) = ((1−1)∧0.5)∨ (1∧0.5′) = (0∧0.5)∨ (1∧0.5′) =min(0,0.5)∨ (1∧0.5′) = 0∨ (1∧0.5′) = 0∨ (1∧ (1−0.5)) =0∨ (1∧0.5) = 0∨min(1,0.5) = 0∨0.5 =min(0+0.5,1) = min(0.5,1) = 0.5

2 MALP, FLOPER and Automatic Theorem Proving

In what follows we describe a very simple subset of the MALP2 language (see [MOV04, JMP09]for a complete formulation of this framework), which in essence consists in a first-order lan-guage, L , containing variables, constants, function symbols, predicate symbols, and several(arbitrary) connectives to increase language expressiveness: implication connectives (denotedby ←1,←2, . . .); conjunctive connectives (∧1,∧2, . . .), disjunctive connectives (∨1,∨2, . . .), andhybrid operators (usually denoted by @1,@2, . . .), all of them are grouped under the name of“aggregators”. Although these connectives are binary operators, we usually generalize themas functions with an arbitrary number of arguments. So, we often write @(x1, . . . ,xn) insteadof @(x1, . . . ,@(xn−1,xn)). By definition, the truth function for an n-ary aggregation operator[[@]] : Ln→ L is required to be monotonous.

Additionally, our language L contains the values of a lattice (L,≤) and a set of connectivesinterpreted over such lattice. In general, L may be the carrier of any complete bounded latticewhere a L-expression is a well-formed expression composed by values of L, as well as variablesymbols, connectives and primitive operators (i.e., arithmetic symbols such as ∗,+,min, etc.).In what follows, we assume that the truth function of any connective @ in L is given by itscorresponding connective definition, that is, an equation of the form @(x1, . . . ,xn)≜ E, where Eis a L-expression not containing variable symbols apart from x1, . . . ,xn. For instance, some fuzzyconnective definitions in the lattice ([0,1],≤) are presented in Figure 3 (from now on, this lattice

2 Multi-Adjoint Logic Programming.

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 5 / 15

Page 156: y V Taller de Programación Funcional (TPF)

will be called V along this paper), where labels L, G and P mean respectively Łukasiewicz logic,Godel logic and product logic (with different capabilities for modeling pessimistic, optimisticand realistic scenarios, respectively).

This subset of MALP is intended to cope with fuzzy propositional formulae like P∧Q→P∨Q, where propositions P and Q are interpreted as values of the lattice. To this end, a programis defined as a set of rules (also called “facts”) of the form “H with v”, where H is an atomicformula or atom (usually called head), and v is its associated truth degree (i.e., a value of L).More precisely, in our application, heads have always the form “i(v)” and each program rulelooks like “i(v) with v”. It is noteworthy to point out that even when we use the same names forconstants (building data terms) and truth degrees, the Herbrand Universe of each program andthe carrier set of its associated lattice should never be confused, since they are in fact disjointsets.

A goal is a formula built from atomic formulas B1, . . . ,Bn (n ≥ 0 ), truth values of L, con-junctions, disjunctions and aggregations, submitted as a query to the system. In this subset ofMALP, the atomic formulas of a goal have always the form “i(P)”, being P a variable symbol.In this way, when running a simple goal like “i(P)” (as done in Figure 4), we could obtain severalanswers meaning something like “when P = v, then the resulting truth degree is v”, representingall possible interpretations in L for proposition P in the original formula.

The procedural semantics of this subset of the MALP language consists on an operationalphase (based on admissible steps that exploits the atoms in the goal), followed by an interpretivephase (that performs arithmetic operations to interpret the resulting formula on the lattice). Inthe following, C [A] denotes a formula where A is a sub-expression which occurs in the –possiblyempty– context C []. Moreover, C [A/A′] means the replacement of A by A′ in context C [].

Definition 1 (Admissible Step) Let Q be a goal and let σ be a substitution. The pair ⟨Q;σ⟩is a state. Given a program P , an admissible computation is formalized as a state transitionsystem, whose transition relation→AS is defined as the least one satisfying:

⟨Q[A];σ⟩ →AS ⟨(Q[A/v])θ ;σθ⟩

where A is the selected atom in Q, θ = mgu(H = A)3 and “H with v” in P . An admissiblederivation is a sequence ⟨Q; id⟩→AS ⋅ ⋅ ⋅→AS⟨Q′;θ⟩.

If we exploit all atoms of a given goal, by applying admissible steps as much as needed duringthe operational phase, then it becomes a formula with no atoms (a L-expression) which can bethen interpreted w.r.t. lattice L as follows.

Definition 2 (Interpretive Step and Fuzzy Computed Answer) Let P be a program, Q a goaland σ a substitution. Assume that [[@]] is the truth function of connective @ in the lattice (L,≤)associated to P , such that, for values r1, . . . ,rn,rn+1 ∈ L, we have that [[@]](r1, . . . ,rn) = rn+1.Then, we formalize the notion of interpretive computation as a state transition system, whosetransition relation→IS is defined as the least one satisfying:

⟨Q[@(r1, . . . ,rn)];σ⟩ →IS ⟨Q[@(r1, . . . ,rn)/rn+1];σ⟩3 Here mgu(E) denotes the most general unifier of an equation set E [LMM88].

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 6 / 15

Page 157: y V Taller de Programación Funcional (TPF)

An interpretive derivation is a sequence ⟨Q;σ⟩→IS ⋅ ⋅ ⋅→IS⟨Q′;σ⟩. When Q′ = r ∈ L, the state⟨r;σ⟩ is called a fuzzy computed answer (f.c.a.) for that derivation.

2.1 The Fuzzy Logic Programming Environment FLOPER

Figure 4: A work-session with FLOPER solving goal i(P).

The parser of our FLOPER tool [MMPV10, MMPV11] has been implemented by using the Pro-log language. Once the application is loaded inside a Prolog interpreter, it shows a menu whichincludes options for loading/compiling, parsing, listing and saving MALP programs, as well asfor executing/debugging fuzzy goals. Moreover, in [MMPV10] we explain that FLOPER hasbeen recently equipped with new options, called “lat” and “show”, for allowing the possibilityof respectively changing and displaying the lattice associated to a given program.

A very easy way to model truth-degree lattices for being included into the FLOPER tool isalso described in [MMPV10], according the following guidelines. All relevant components ofeach lattice are encapsulated inside a Prolog file which must necessarily contain the definitionsof a minimal set of predicates defining the set of valid elements (member/1 predicate), thetop and bottom elements (top/1 and bot/1 predicates), the full or partial ordering establishedamong them (leq/2 predicate), as well as the repertoire of fuzzy connectives which can be usedfor their subsequent manipulation. If we have, for instance, some fuzzy connectives of the form&label1 (conjunction), ∣label2 (disjunction) or @label3 (aggregation) with arities n1, n2 and n3 re-

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 7 / 15

Page 158: y V Taller de Programación Funcional (TPF)

member(X) :- number(X),0=<X,X=<1. members([0,0.5,1]).leq(X,Y) :- X=<Y. bot(0). top(1).

and_luka(X,Y,Z) :- pri_add(X,Y,U1),pri_sub(U1,1,U2),pri_max(0,U2,Z).and_godel(X,Y,Z):- pri_min(X,Y,Z).and_prod(X,Y,Z) :- pri_prod(X,Y,Z).

or_luka(X,Y,Z) :- pri_add(X,Y,U1),pri_min(U1,1,Z).or_godel(X,Y,Z) :- pri_max(X,Y,Z).or_prod(X,Y,Z) :- pri_prod(X,Y,U1),pri_add(X,Y,U2),

pri_sub(U2,U1,Z).

agr_aver(X,Y,Z) :- pri_add(X,Y,U),pri_div(U,2,Z).agr_not(X,Y) :- pri_sub(1,X,Y).

pri_add(X,Y,Z) :- Z is X+Y. pri_min(X,Y,Z) :- (X=<Y,Z=X;X>Y,Z=Y).pri_sub(X,Y,Z) :- Z is X-Y. pri_max(X,Y,Z) :- (X=<Y,Z=Y;X>Y,Z=X).pri_prod(X,Y,Z) :- Z is X * Y. pri_div(X,Y,Z) :- Z is X/Y.

Figure 5: Prolog code for representing lattice V , which models truth degrees in the real interval[0,1] with standard fuzzy connectives.

spectively, we must provide clauses defining the connective predicates “and label1/(n1+1)”,“or label2/(n2+1)” and “agr label3/(n3+1)”, where the extra argument of each predicateis intended to contain the result achieved after the evaluation of the proper connective. Finally,for the purposes of the current work, we also require for each lattice a Prolog fact of the formmembers(L) being the L a list containing the set of truth degrees belonging to the modeledlattice (or at least a representative subset of them when working with infinite lattices) for be-ing used when interpreting propositional variables of fuzzy formulae. For instance, a latticedefining the simplest notion of binary lattice should implement predicate member/1 with factsmember(0) and member(1) (including also members([0,1])) and the boolean conjunc-tion could be defined by the pair of facts and bool(0, ,0) and and bool(1,X,X).

Following the Prolog style regulated by the previous guidelines, in Figure 5, we show the setof clauses modeling the more flexible lattice V , which enables the possibility of working withtruth degrees in the infinite space of the real numbers between 0 and 1, offering too a wide rangeof conjunction and disjunction operators recasted from the three typical fuzzy logics describedbefore (i.e., the Łukasiewicz, Godel and product logics), as well as a useful description for thehybrid aggregator average and the negation connective. Note that we have included the fact“members([0,0.5,1]).” which implies that in our application, propositional variablesinvolved in fuzzy formulae to be proved, only three values (i.e., real numbers 0, 0.5 and 1,collected from the infinite unit interval) should be considered for interpreting such formulas, asshown in Figure 2.

Note also that we have included definitions for auxiliary predicates, whose names alwaysbegin with the prefix “pri ”. All of them are intended to describe primitive/arithmetic operators(in our case +, −, ∗, /, min and max) in a Prolog style, for being appropriately called from

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 8 / 15

Page 159: y V Taller de Programación Funcional (TPF)

γ

/ ∖

α β

∖ /

member(bottom). member(alpha).member(beta). member(gamma).member(top).members([bottom,alpha,beta,gamma,top]).leq(bottom,X). leq(X,X). leq(alpha,gamma).leq(beta,gamma). leq(X,top). l(X,X) :- !.l(X,Y):-leq(X,Y),!. l(X,Y):-leq(X,Z),l(Z,Y).and godel(X,Y,Z) :- pri inf(X,Y,Z).or godel(X,Y,Z) :- pri sup(X,Y,Z).agr impl(X,Y,Z) :- (l(Y,X),!,Z=top ; Z=X).pri inf(X,Y,X):- l(X,Y), !.pri inf(X,Y,Y):- l(Y,X), !.pri inf( , ,bottom).pri sup(X,Y,X):- l(Y,X), !.pri sup(X,Y,Y):- l(X,Y), !.pri sup( , ,gamma).

Figure 6: The finite, partially ordered lattice F modeled in Prolog.

the bodies of clauses defining predicates with higher levels of expressivity (this is the case forinstance, of the three kinds of fuzzy connectives we are considering: conjunctions, disjunctionsand aggregations).Since till now we have considered two classical, fully ordered lattices (with a finite and infi-nite number of elements, respectively), we wish now to introduce a different case coping with avery simple lattice where not always any pair of truth degrees are comparable. So, consider thefollowing partially ordered lattice F in the diagram of Figure 6, which is equipped with conjunc-tion, disjunction and implication connectives based on the Godel logic described in Figure 3, butwith the particularity that now, in the general case, the Godel’s conjunction must be expressed as&G(x,y)≜ in f (x,y), where it is important to note that we must replace the use of “min” by “inf ”in the connective definition (and similarly for the disjunction connective, where “max” must besubstituted by “sup”).

To this end, observe in the Prolog code accompanying the graphic in Figure 6 that we haveintroduced clauses defining the primitive operators “pri inf/3” and “pri sup/3” which areintended to return the infimum and supremum of two elements. Related with this fact, we mustpoint out the following aspects:

∙ Note that since truth degrees α and β are incomparable, then any call to goals of the form“?- leq(alpha,beta).” or “?- leq(beta,alpha).” will always fail.

∙ A goal of the form “?- pri inf(alpha,beta,X).”, instead of failing, successfullyproduces the desired result “X=bottom”.

∙ Note anyway that the implementation of the “pri inf/3” predicate ismandatory for coding the general definition of “and godel/3” (a similar reasoning fol-lows for “pri sup/3” and “or godel/3” ).

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 9 / 15

Page 160: y V Taller de Programación Funcional (TPF)

Figure 7: A work-session with FLOPER solving formula P∨Q (25 interpretations, 9 models).

2.2 Some Examples

This subset of the MALP language suffices for developing a simple fuzzy theorem prover, whereit is important to remark that our tool can cope with different lattices (not only the real interval[0,1]) containing a finite number of elements -marked in “members”- maintaining full or partialordering among them. Hence, we can use FLOPER for enumerating the whole set of interpreta-tions and models of fuzzy formulae. To this end, only a concrete lattice L is required in order toautomatically build a program composed by a set of facts of the form “i(α) with α”, for eachα ∈ L. For instance, the MALP program associated to lattice F in Figure 6 looks like:

i(top) with top.i(gamma) with gamma.i(alpha) with alpha.

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 10 / 15

Page 161: y V Taller de Programación Funcional (TPF)

Figure 8: Full proof tree for formula P∧ (P∨P) with 1 model among 5 interpretations.

i(beta) with beta.i(bottom) with bottom.

Once the lattice and the residual program have been loaded into FLOPER, the formula to beevaluated is introduced as a goal to the system following some conventions:

∙ If P is a propositional variable in the original formula, then it is denoted as “i(P)” in thegoal F .

∙ If & is a conjunction of a certain logic “label” in the original formula, then it is denoted as“&label” in goal F .

∙ For disjunctions, negations and implications, use respectively “∣label”, “@no label”and “@im label” in F .

∙ For other aggregators use “@label” in F .

In what follows we discuss some examples related with the lattice shown in Figure 6 and itsresidual MALP program just seen before. Firstly, if we execute goal “i(P)” into FLOPER,we obtain the five interpretations for P shown in Figure 4. On the other hand, consider now thepropositional formula P∨Q, which is translated into the MALP goal “(i(P) | i(Q))” andafter being executed with FLOPER, the tool returns a tree4 whose 25 leaves represent the wholeset of interpretations (9 of them -inside blue clouds- are models) as seen in Figure 7. See alsoFigure 8 associated to formula P∧ (P∨P).

4 Each state contains its corresponding goal and substitution components and they are drawn inside yellow circles.Admissible steps, colored in blue, are labeled with the program rule they exploit. Finally, those blue circles annotatedwith word “is”, correspond to interpretive steps. Sometimes we include blue circles labeled with “result” whichrepresents a chained sequence of interpretive steps.

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 11 / 15

Page 162: y V Taller de Programación Funcional (TPF)

Consider now the more involved formula P∧Q→ P∨Q which becomes into the MALP goal“(i(P) & i(Q)) @impl (i(P) | i(Q))”. When interpreted by FLOPER, the systemreturns the list of answers displayed in Figure 9, having all them the maximum truth degree“top”, which proves that this formula is a tautology, as wanted.

Figure 9: Full proof tree for tautology P∧Q→ P∨Q (25 models).

2.3 Some Hints on Cost Measures

We wish to finish this section by providing some comments about cost measures and efficiency.So, given a lattice L, a formula F and its associated proof tree T , we define the following values:

∙ v is the number of distinct variables in F .

∙ v′ is the number of occurrences (including repetitions) of variables in F .

∙ c is the number of connectives in F .

∙ r is the number of (marked) elements in lattice L given by predicate “members”.

And now we have that:

∙ The width of the tree T , or total number of interpretations of F , is rv.

∙ The number of admissible steps performed on a single branch of T is v′.

∙ The number of interpretive steps performed on a single branch of T is c.

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 12 / 15

Page 163: y V Taller de Programación Funcional (TPF)

Figure 10: Behaviour of the method

∙ The depth of T , or number of computational (admissible/interpretive) steps for each pos-sible interpretation of F is v′+ c.

∙ An upper bound for the total number of admissible steps in T is ∣as∣ ≤ (v′− v)rv +v

∑i=1

ri.

∙ An upper bound for the total number of interpretive steps in T is ∣is∣ ≤ crv.

∙ An finally, an upper bound for the total number of computational (admissible and interpre-

tive) steps is ∣T ∣ ≤ (c+ v′− v)rv +v

∑i=1

ri.

Let us come back again to tautology P∧Q→ P∨Q for which FLOPER displays the whole setof models seen in Figure 9, and assume now a more general version with the following shapeP1∧ . . .∧Pn→ P1∨ . . .∨Pn for which we have studied its behaviour in the table of Figure 10. Inthe horizontal axis we represent the number n of different propositional variables appearing in theformula, whereas the vertical axis refers to the number of seconds5 needed to obtain the wholeset of interpretations (all them are models in this case) for the formula. Both the red and bluelines refers to the method just commented along this paper, but whereas the red line indicates thatthe derivation tree has been produced by performing admissible and interpretive steps accordingDefinitions 1 and 2, respectively, the blue line refers to the execution of the Prolog code obtained

5 The benchmarks have been performed using a computer with processor Intel Core Duo, with 2 GB RAM andWindows Vista.

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 13 / 15

Page 164: y V Taller de Programación Funcional (TPF)

after compiling with FLOPER the MALP program and goal associated to our intended formula.The results achieved in the figure show that our method has a nice behaviour in both cases, evenfor formulae with a big number of propositional variables. Of course, the method does nottry to compete with SAT techniques (which are always faster and can deal with more complexformulae containing many more propositional variables), but it is important to remark again thatin our case, we face the problem of finding the whole set of models for a given formula, insteadof only focusing on satisfiability.

3 Conclusions and Future Work

In this paper we have focused on two different, but related problems regarding the automaticproving of propositional fuzzy formulae. In particular, whereas an SMT solver has been usedfor checking satisfiability, an alternative technique based on fuzzy logic programming has beenintroduced for finding the whole set of interpretations which are models for a given formula.In the future we plan to introduce improvements on both methods, regarding the set of truthdegrees collected in the lattice used for interpreting a given formula. In the case of SMT, we planto investigate how to cope with lattices equipped with partial ordering among their elements,whereas for the method based on fuzzy logic programming, it is important to design a muchmore flexible technique for dealing with infinite lattices than the one we have used in this paper(based on “pointing out” just a few number of truth degrees in the infinite space). In this lastsense, some halting rules and branch cuts should be needed (maybe through alfa cuts) or even itcould be interesting to study how to obtain all models of a formula by a constraint (as x+ y = 1for the example given in the Introduction about the analogical chip) or a set of constraints.

Acknowledgements: Carlos Vazquez and Gines Moreno received grants for International mo-bility from the University of Castilla-La Mancha (CYTEMA project and “Vicerrectorado deProfesorado”). Miquel Bofill and Mateu Villaret are partially suported by the Ministerio deEconomıa y Competitividad research project HeLo (ref. TIN2012-33042).

Bibliography

[ABMV12] C. Ansotegui, M. Bofill, F. Manya, M. Villaret. Building Automated TheoremProvers for Infinitely-Valued Logics with Satisfiability Modulo Theory Solvers. InProceedings of the 42nd IEEE International Symposium on Multiple-Valued Logic,ISMVL 2012. Pp. 25–30. 2012.

[Apt90] K. R. Apt. Logic Programming. In Leewen (ed.), Handbook of Theoretical Com-puter Science. Volume B: Formal Models and Semantics, chapter 10, pp. 493–574.MIT Press, Massachusetts Institute of Technology, USA, 1990.

[Bra00] I. Bratko. Prolog Programming for Artificial Intelligence. Addison Wesley, Septem-ber 2000.

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 14 / 15

Page 165: y V Taller de Programación Funcional (TPF)

[BSST09] C. W. Barrett, R. Sebastiani, S. A. Seshia, C. Tinelli. Satisfiability Modulo Theo-ries. In Handbook of Satisfiability. Frontiers in Artificial Intelligence and Applica-tions 185, pp. 825–885. IOS Press, 2009.

[Fit96] M. Fitting. First-order logic and automated theorem proving. Springer Verlag,1996.

[JMM+13] P. Julian, J. Medina, P. Morcillo, G. Moreno, M. Ojeda-Aciego. An Unfolding-Based Preprocess for Reinforcing Thresholds in Fuzzy Tabulation. In Advances inComputational Intelligence - Proc of the 12th International Work-Conference onArtificial Neural Networks, IWANN’13. Pp. 647–655. Springer Verlag, LNCS 7902,PART I, 2013.

[JMP09] P. Julian, G. Moreno, J. Penabad. On the Declarative Semantics of Multi-AdjointLogic Programs. In Proceedings of the 10th International Work-Conference on Arti-ficial Neural Networks, IWANN’09. Pp. 253–260. Springer, Lecture Notes in Com-puter Science 5517, Salamanca, 2009.

[Llo87] J. Lloyd. Foundations of Logic Programming. Springer-Verlag, Berlin, 1987. Sec-ond edition.

[LMM88] J. L. Lassez, M. J. Maher, K. Marriott. Unification Revisited. In Minker (ed.), Foun-dations of Deductive Databases and Logic Programming. Pp. 587–625. MorganKaufmann, Los Altos, California, 1988.

[MMPV10] P. Morcillo, G. Moreno, J. Penabad, C. Vazquez. A Practical Management of FuzzyTruth Degrees using FLOPER. In al. (ed.), Proceedings of 4th Intl Symposium onRule Interchange and Applications, RuleML’10. Washington, USA, October 21–23.Pp. 119–126. Springer Verlag, Lecture Notes in Computer Science 6403, 2010.

[MMPV11] P. Morcillo, G. Moreno, J. Penabad, C. Vazquez. Fuzzy Computed Answers Col-lecting Proof Information. In al. (ed.), Advances in Computational Intelligence.Proceedings of the 11th International Work-Conference on Artificial Neural Net-works, IWANN’11. Pp. 445–452. Springer Verlag, Lecture Notes in Computer Sci-ence 6692, 2011.

[MMPV12] P. J. Morcillo, G. Moreno, J. Penabad, C. Vazquez. Dedekind-MacNeille comple-tion and Cartesian product of multi-adjoint lattices. Int. J. Comput. Math. 89(13-14):1742–1752, 2012.

[MOV04] J. Medina, M. Ojeda-Aciego, P. Vojtas. Similarity-based Unification: a multi-adjoint approach. Fuzzy Sets and Systems 146:43–62, 2004.

[Sti88] M. E. Stickel. A Prolog technology theorem prover: Implementation by an extendedProlog compiler. Journal of Automated reasoning 4(4):353–380, 1988.

[VBG12] A. Vidal, F. Bou, L. Godo. An SMT-Based Solver for Continuous t-norm BasedLogics. In Proceedings of the 6th International Conference on Scalable UncertaintyManagement. Lecture Notes in Computer Science 7520, pp. 633–640. 2012.

Automatic Proving of Fuzzy Formulae with Fuzzy Logic Programming and SMT 15 / 15

Page 166: y V Taller de Programación Funcional (TPF)

Sesión 5: Logic and Theory

166

Page 167: y V Taller de Programación Funcional (TPF)

Sesión 5: Logic and Theory

9.00–9.30 Javier Álvez, Paqui Lucio, and German Rigau: Adimen-SUMO: Reengineering an Ontology for First-Order Rea-soning

9.30–10.00 Francisco J. Galán and Ahmed Riveras: Semantic Web Ser-vices in a Transactional Context

10.00–10.30 María Alpuente, Santiago Escobar, and Javier Espert: De-tecting Modular ACU Structural Symmetries

167

Page 168: y V Taller de Programación Funcional (TPF)

Adimen-SUMO: Reengineering an Ontology for First-OrderReasoning

Javier Alvez, Paqui Lucio and German Rigau

Department of Languages and Information SystemsUniversity of the Basque Country

Abstract: In this paper, we present Adimen-SUMO, an operational ontology to beused by first-order theorem provers in intelligent systems that require sophisticatedreasoning capabilities (e.g. Natural Language Processing, Knowledge Engineering,Semantic Web infrastructure, etc.). Adimen-SUMO has been obtained by automat-ically translating around 88% of the original axioms of SUMO (Suggested UpperMerged Ontology). Our main interest is to present in a practical way the advantagesof using first-order theorem provers during the design and development of first-orderontologies. First-order theorem provers are applied as inference engines for reengi-neering a large and complex ontology in order to allow for formal reasoning. Inparticular, our study focuses on providing first-order reasoning support to SUMO.During the process, we detect, explain and repair several important design flaws andproblems of the SUMO axiomatization. As a by-product, we also provide generaldesign decisions and good practices for creating operational first-order ontologiesof any kind.

Keywords: Ontologies, First-order Logic, Automated Reasoning, Knowledge En-gineering, Linked Open Data

Acknowledgements: This work has been partially supported by the European project News-Reader (FP7-ICT-2011-8-316404), the Spanish projects SKaTer (TIN2012-38584-C06-02) andFORMALISM (TIN2007-66523), and the Basque Projects LoRea (GIU-12/26), LoReaCo (SAI-12/219) and BAILab (UFI 11/45).

Adimen-SUMO: Reengineering an Ontology for First-Order Reasoning 1 / 1

Page 169: y V Taller de Programación Funcional (TPF)

Semantic Web Services in a Transactional Context

Francisco J. Galan and Ahmed Riveras

Dept. of Languages and Computer Systems.Faculty of Computer Science. Av. Reina Mercedes s/n. 41012, Seville, Spain.

[email protected]

Abstract: In an open context where databases and web services can evolve by sepa-rate, we formalize a class of service requests that specify not only the set of desirablestates but the sequence of relevant states for reaching them. For satisfying these re-quests, we formalize a class of semantic web services called transactional semanticweb services which include in their specifications a logic transaction for describingthe possible sequences of relevant states the service can reach at runtime. Every rel-evant state must satisfy the invariant defined for the database under consideration;otherwise the transaction is undone. Finally, we propose a tractable solution to theproblem of service matchmaking. To the best of our knowledge, this work is thefirst one which aims to integrate databases, services and requests in a semantic webwhere the concept of state change is a key requirement.

Keywords: invariant, pre/post specification, semantic web service, service match-making, service request, state, transaction logic.

1 Introduction

The Web is an enormous container of resources which have been developed in a distributedmanner. To make possible the combination of these resources, a huge variety of integrationmechanisms is being developed [WSMO08]. In this paper, the Web is viewed as an open contextwhere databases and services can evolve in an independent way. According to this vision, aweb service is not an artifact to be used with a specific database but an artifact to be integratedat runtime with a database. We translate this vision to the Semantic Web. In the SemanticWeb, a service request is a description of the outputs and effects a web client want to achieveand a web service is a computational resource that is invocable over the Internet through aninterface describing a functional capability. There are different definitions of what the functionalcapability of a semantic web service should be. For example, in [HZB06], a semantic webservice can provide information but can not change the state of the web. However, in otherproposals [KLP05, SKL07], a semantic web service not only can provide information but alsochange the state of the web. Among the different forms of specification, we focus on the so-calledpre/post specifications. A pre/post specification of a web service is a specification based on twodescriptions: the set of states from which the service is allowed to begin its execution (pre-condition) and the set of states reached at the end of its execution (post-condition). An exampleof language based on this form of specification is Web Service Modeling Language (WSML)[WSML08]. Recently, alternative forms of specification based on process models are beingconsidered for improving precision in tasks such as service matchmaking [GuY10]. Followingthis line, we are interested in a class of service requests that specify not only the set of desirablestates but the sequence of intermediate relevant states for reaching them. These requests contain

Semantic Web Services in a Transactional Context 1 / 15

Page 170: y V Taller de Programación Funcional (TPF)

pre-conditions (Pre), intermediate conditions (Int) and post-conditions (Post). For example, aclient might be interested in buying a product in stock with delivery before invoicing. Formally,

//Buy a product in stock with delivery before invoicing.Service Request : buy1(p,c)Pre : product(p)∧ stock(p) Int1 : product(p)∧ customer(c)∧delivery(p,c)Post : product(p)∧ customer(c)∧delivery(p,c)∧ invoice(p,c)

By definition, the pre/post specification can not express intermediate states. Therefore, its useis not adequate for covering service requests with intermediate states such as buy1. To palliatethis lack of expressivity, we propose the use of a particular class of semantic web services calledtransactional semantic web services. This kind of services includes in its specification a logictransaction for describing the sequences of relevant states the web service can reach at runtime.For illustrating it, suppose the following transactional semantic web service where add/del areprimitive updates of Transaction Logic [BK95, BK98] for adding/deleting tuples to/from theextension of a predicate, ∧ is the so-called parallel conjunction for concatenating actions in asame state and ⊗ is the so-called serial conjunction for sequencing actions in different states.

//Sell a product in stock with delivery before invoicing.Service : sell1(p,c)Pre : product(p)∧ stock(p)Transaction : sell1(p,c)⇐ add(customer(c)) ⊗ (add(delivery(p,c))∧del(stock(p)))⊗

(add(invoice(p,c))∧add(sold(p)))Post : product(p)∧ sold(p)∧ customer(c)∧delivery(p,c)∧ invoice(p,c)

Semantically, the transaction in sell1 defines a sequence of four possible relevant states. Everytransaction has its origin in a first state. From this, a second state is reached by adding a tuple<c> to the extension of customer. From this, a third state is reached by adding a tuple <p,c>to (the extension of) delivery and by deleting simultaneously a tuple <p> from stock. Finally, afourth state is reached by adding tuples <p,c> and <p> to invoice and sold respectively.

As we said at the beginning of this section, a semantic web service is an artifact to be integratedat runtime with a database. We will assume that any database includes in its specification, apartfrom data, a data invariant. We show in what follows the data invariants of two databases whichmay potentially be used with service sell1.

Data Invariant : inv1//For every sold product must exist a customer, a delivery and an invoice.1. ∀p(product(p)∧ sold(p)⇒∃c(customer(c)∧delivery(p,c)∧ invoice(p,c)))//Every product which has been delivered can not be in stock.2. ∀p,c(product(p)∧delivery(p,c)∧ stock(p)⇒ f alse)//Customers and products are disjoint sets of individuals.3. ∀x(product(x)∧ customer(x)⇒ f alse)

Semantic Web Services in a Transactional Context 2 / 15

Page 171: y V Taller de Programación Funcional (TPF)

Data Invariant : inv2//For every sold product must exist a customer, a delivery and an invoice.1. ∀p(product(p)∧ sold(p)⇒∃c(customer(c)∧delivery(p,c)∧ invoice(p,c)))//Every product which has been delivered can not be in stock.2. ∀p,c(product(p)∧delivery(p,c)∧ stock(p)⇒ f alse)//Customers and products are disjoint sets of individuals.3. ∀x(product(x)∧ customer(x)⇒ f alse)//Every product has a price.4. ∀p(product(p)⇒∃x(price(p,x)))//Every product with a high price is directly supplied by an external provider.5. ∀p,x(product(p)∧ price(p,HIGH)⇒∃s(provider(s)∧ supplies(s, p)))//Every product with a low price is stored.6. ∀p,x(product(p)∧ price(p,LOW )⇒ stock(p))//Providers and products are disjoint sets of individuals.7. ∀x(product(x)∧ provider(x)⇒ f alse)

A relevant execution of a semantic web service is a sequence of relevant states which sat-isfy the data invariant under consideration. Among the relevant executions of a transactionalsemantic web service, we highlight the so-called canonical execution. A canonical executionis an execution composed of canonical states only. Every formula representing a set of statessuch as precondition, intermediate condition or postcondition can be regarded as a symbolicdatabase instance called canonical state. Roughly, the canonical state is obtained by regardingeach atom defined on a predicate symbol r as a tuple of r where variables are replaced by la-belled nulls [DNR08]. For instance, the canonical state corresponding to product(p)∧ stock(p)is product(p),stock(p) where p is a labelled null. For instance, the canonical execution ofsell1 specifies the following sequence of canonical states:

state1 = product(p),stock(p)state2 = product(p),stock(p),customer(c)state3 = product(p),customer(c),delivery(p, c)state4 = product(p),customer(c),delivery(p, c), invoice(p, c),sold(p)

As we can verify, this canonical execution satisfies inv1 but not inv2.In a similar way, the formulae used in the specification of a service request can also be viewed

as canonical states. For instance, the canonical execution of buy1 specifies the following se-quence of canonical states:

state1 = product(p),stock(p)state2 = product(p),customer(c),delivery(p, c)state3 = product(p),customer(c),delivery(p, c), invoice(p, c)

Once known the sequences of canonical states for a pair (service request, service execution),we can construct an inclusion matrix. Each row in that matrix is indexed by a canonical statein the service request and each column by a canonical state in the canonical execution of thetransactional semantic web service. Each element in the matrix encodes the existence (i.e. ⊆) ornot (i.e. 6⊆) of inclusion between the involved states. For instance, the inclusion matrix for thepair (buy1, sell1) is as follows:

Semantic Web Services in a Transactional Context 3 / 15

Page 172: y V Taller de Programación Funcional (TPF)

(buy1,sell1) state1 state2 state3 state4

state1 ⊆ ⊆ 6⊆ 6⊆state2 6⊆ 6⊆ ⊆ ⊆state3 6⊆ 6⊆ 6⊆ ⊆

An analysis of the inclusion matrix allows us to infer that sell1 satisfies the canonical executionof buy1 because state3 in the canonical execution of buy1 is contained in state4 in the canonicalexecution of sell1. By removing column state4 and row state3 in the inclusion matrix, we havethat state2 in the canonical execution of buy1 is contained in state3 in the canonical executionof sell1. Again, by removing column state3 and row state2 in the inclusion matrix, we have thatstate1 in the canonical execution of buy1 is contained either in state1 or in state2 in the canonicalexecution of sell1.

Could we extend the concept of service request satisfaction to a class of executions differentto the canonical ones?

To give an answer to this question, we need to introduce the concept of similarity betweenground relevant execution and canonical execution of a transactional semantic web service. Aground relevant execution is a relevant execution composed of ground relevant states only.

Roughly, for a transactional semantic web service, a ground relevant execution is similar to acanonical execution if every state in the canonical execution can be contained in the correspond-ing state in the ground relevant execution. For instance, the ground relevant execution of sell1shown below

s1 = product(PC),stock(PC), product(TV ),customer(RB)s2 = product(PC),stock(PC),customer(JN), product(TV ),customer(RB)s3 = product(PC),delivery(PC,JN),customer(JN), product(TV ),customer(RB)s4 = product(PC),delivery(PC,JN),customer(JN), invoice(PC,JN),sold(PC),

product(TV ),customer(RB)

is similar to the canonical execution of sell1 with substitution σ = p/PC, c/JN:

state1σ = product(PC),stock(PC)state2σ = product(PC),stock(PC),customer(JN)state3σ = product(PC),customer(JN),delivery(PC,JN)state4σ = product(PC),customer(JN),delivery(PC,JN), invoice(PC,JN),sold(PC)

As we can see, state1σ ⊆ s1,state2σ ⊆ s2,state3σ ⊆ s3,state4σ ⊆ s4.The class of ground relevant executions allows to define the following sufficiency condition:

if the canonical execution of a transactional semantic web service, state1, ...,staten ,satisfiesthe canonical execution of a service request (inclusion matrix) then the service request can besatisfied by a ground relevant execution of the transactional semantic web service, s1, ...,sn, if(1) there exists a substitution σ such that state1σ ⊆ s1, ...,statenσ ⊆ sn and (2) every groundrelevant state si, with i = 1..n, satisfies the data invariant under consideration.

It is important to remark that conditions (1) and (2) can be solved in a tractable way. This pointwill be relevant in order to solve the problem of service matchmaking in real-world scenarios.We outline the manner of doing it in Section 4.

The rest of the paper is organized as follows. In Section 2, we give a set of preliminarydefinitions. Section 3 defines a formal syntax and semantics for service request and transactional

Semantic Web Services in a Transactional Context 4 / 15

Page 173: y V Taller de Programación Funcional (TPF)

semantic web service. In Section 4, we revisit the problem of service matchmaking within ourformalism and finally we close with related work and conclusions.

2 Preliminaries

This section includes a set of preliminary definitions for helping reader to understand the formal-ization proposed in Section 3.

A relevant state s is a finite set of atoms. The domain of a relevant state is the set of val-ues (constants) which appear in s. We consider relevant states with two types of values only:constants and labelled nulls. If a relevant state contains no labelled nulls, we say it is ground.As notational convention, constants are written in uppercase (for instance, PC), labelled nulls inbar-lowercase (for instance, p) and variables in lowercase (for instance, p). Intuitively, a labellednull can be used as a placeholder for an unknown constant. For example, product(p) can be usedto represent an undetermined product.

Let σ be a substitution of labelled nulls by constants. We say that a ground relevant state s2is σ -similar to a relevant state s1, denoted by s1∼σ s2, iff there exists an injective σ such thats1σ ⊆ s2.

For instance, product(p),stock(p)∼σ product(PC),stock(PC), being σ = p/PC. By con-trast, product(p), product(q),stock(p) 6∼σ product(PC),stock(PC) due to the impossibility ofconstructing an injective σ .

A relevant execution is a sequence of relevant states. A ground relevant execution is an exe-cution where all its relevant states are ground.

Similarity can be extended to relevant executions in a natural way. We say that a groundrelevant execution e2 is σ -similar to a relevant execution e1, denoted by e1∼σ e2, iff (a) thenumber of states in e1 is equal to the number of states in e2 and (b) for each pair of states si ∈ e1and ti ∈ e2, si∼σ ti. For instance, e1∼σ e2

e1 : s1 = product(p),stock(p)s2 = product(p),customer(c),delivery(p, c)s3 = product(p),customer(c), invoice(p, c)

e2 : t1 = product(PC),stock(PC), product(TV ),customer(RB)t2 = product(PC),customer(JN),delivery(PC,JN), product(TV )t3 = product(PC),customer(JN), invoice(PC,JN),sold(PC),customer(RB)

with σ = p/PC, c/JN.Given a relevant execution e and substitution σ , we can write the expression eσ for denoting

the relevant execution which results from applying σ to each state in e. For instance, for arelevant execution e:

state1 = product(p),stock(p)state2 = product(p),stock(p),customer(c)state3 = product(p),customer(c),delivery(p, c)state4 = product(p),customer(c),delivery(p, c), invoice(p, c),sold(p)

Semantic Web Services in a Transactional Context 5 / 15

Page 174: y V Taller de Programación Funcional (TPF)

and substitution σ = p/PC, c/JN, the expression eσ denotes the relevant execution:

state1σ = product(PC),stock(PC)state2σ = product(PC),stock(PC),customer(JN)state3σ = product(PC),customer(JN),delivery(PC,JN)state4σ = product(PC),customer(JN),delivery(PC,JN), invoice(PC,JN),sold(PC)

Let e1 be a relevant execution with k states and let e2 be a ground relevant execution with kstates. We say that a ground execution e2(e1σ) is the supplementary execution of e2 wrt e1σ iff(a) e1 ∼σ e2 and for each ti ∈ e2(e1σ), ti = ti− siσ , being ti ∈ e2, si ∈ e1 and i = 1..k.

For instance, the supplementary execution e2(e1σ) with

e1 : s1 = product(p),stock(p)s2 = product(p),customer(c),delivery(p, c)s3 = product(p),customer(c), invoice(p, c)

e2 : t1 = product(PC),stock(PC), product(TV ),customer(RB)t2 = product(PC),customer(JN),delivery(PC,JN), product(TV )t3 = product(PC),customer(JN), invoice(PC,JN),sold(PC),customer(RB)

and σ = p/PC, c/JN is the following execution:

e2(e1σ) : t1 = product(TV ),customer(RB)t2 = product(TV )t3 = sold(PC),customer(RB)

3 The Formalism

This section formalizes the two main concepts in our proposal: service request and transactionalsemantic web service.

A relevant state is a set of atoms. At runtime, all relevant states are assumed to be ground.A set of relevant states can be represented by a FOL formula with free variables of the form∃Y (ψ(X ,Y )) where ψ is a conjunction of atoms (including equalities), X is a set of free variablesand Y a set of existentially quantified variables. For instance, ∃s(supplies(s, p)∧ product(p))can be used to represent the state: “there exists a supplier s of a product p”. A formula F canbe translated to the so-called canonical state by regarding each atom defined on a predicate r asa tuple of r where all variables are replaced by labelled nulls. We denote this transformation asC (F). For instance,

C (∃s(supplies(s, p)∧ product(p))) = supplies(s, p), product(p)

where p and s are labelled nulls representing unknown constants.An invariant is formalized by a set of FOL formulae of the form ∀X(φ(X)⇒ ∃Y (ψ(X ,Y )))

where φ and ψ are conjunctions of atoms (including equalities), X is a set of universally quanti-fied variables and Y a set of existentially quantified variables. It is important to remark that theinvariant is not a resource for completing states but for checking them. For instance, the state product(TV ),sold(TV ) is not a model of inv1 but product(TV ),stock(TV ) is.

Semantic Web Services in a Transactional Context 6 / 15

Page 175: y V Taller de Programación Funcional (TPF)

A relevant execution is formalized by an expression <state1, ...,staten>inv denoting a finitesequence of relevant states all satisfying a data invariant inv. A canonical execution is a relevantexecution composed of canonical states. A ground relevant execution is a relevant executioncomposed of ground relevant states only.

As a notational convention, we will use <state1, ...>inv to denote a relevant execution whichstarts from a particular state (i.e. state1 is the starting state) and <...,staten>inv to denote a relevantexecution which ends in a particular state (i.e. staten is the ending state).

From a syntactical point of view, a service request is a sequence of FOL formulae, beingeach formula of the form ∃Y (ψ(X ,Y )) where ψ is a conjunction of atoms (including equalities),X is a set of free variables and Y a (possibly empty) set of existentially quantified variables.The first formula in a service request is known as the service request pre-condition (Pre), thelast formula as the service request post-condition (Post) and the remaining ones as the servicerequest intermediate conditions (Inti). In schematic form, a service request is:

Service Request : gPre Int1 ... Int j Post

An example of service request is:

//Buy a product with booking, delivery and invoicing in this order.Service Request : buy2(p,c)Pre : product(p) Int1 : product(p)∧ customer(c)∧booking(p,c) Int2 : product(p)∧ customer(c)∧delivery(p,c)Post : product(p)∧ customer(c)∧ invoice(p,c)

From a semantic point of view, a service request can be formalized as an execution entailmentas follows:

<state1,state2, ...,state j+1,state j+2>|= C (g)being state1 = C (Pre),state2 = C (I1), ...,state j+1 = C (I j),state j+2 = C (Post)

It is important to note that relevant executions for service requests are not contextualized by datainvariants. For instance, the canonical execution of buy2 is:

<state1,state2,state3,state4>|= buy2(p, c) beingstate1 = product(p)state2 = product(p),customer(c),booking(p, c)state3 = product(p),customer(c),delivery(p, c)state4 = product(p),customer(c), invoice(p, c)

A transaction is a set of Transaction Logic formulae [BK95, BK98, Bon97] of the form r(X)⇐∃Y (ψ(X ,Y )), where r is a relation symbol, X is a set of free variables, ψ a formula recursivelywritten from the following resources: (a) primitive consult consult for consulting the extensionof a predicate, (b) primitive update add for adding a tuple to the extension of a predicate, (c)primitive update del for deleting a tuple from the extension of a predicate, (d) (restricted) parallelconjunction ∧, (e) serial conjunction ⊗, (f) (restricted) transaction invocation, (g) (restricted)existential quantification and (h) negation.

Operationally, a formula r(X)⇐∃Y (ψ(X ,Y )) means: “to execute r(X), it is sufficient to execute∃Y (ψ(X ,Y ))” [BK95].

Semantic Web Services in a Transactional Context 7 / 15

Page 176: y V Taller de Programación Funcional (TPF)

In relation to their effects, we distinguish two classes of transactions: (a) transactions that cannot change the starting state and (b) transactions that can change it. For instance, the followingtransaction, called productInStock, is a transaction of the first class:

productInStock(p)⇐ consult(product(p))∧ consult(stock(p))

By contrast, the following transaction, called sell2, belongs to the second class. This transactionis composed of two formulae what means that it describes two classes of relevant executions. Thefirst one describes the selling of a product with an initial provision. The second one describesthe selling of a product in stock.

sell2(p,c)⇐¬productInStock(p)⊗∃s(consult(provider(s))⊗ (add(provision(p,s))∧add(stock(p)))⊗ sell1(p,c))

sell2(p,c)⇐ productInStock(p)⊗ sell1(p,c)

As we said, the writing of a transaction has some restrictions.In relation to parallel conjunction ∧, we consider only those conjunctions which produce

the same result for any execution order of its constituents. For example, a transaction suchas add(stock(PC))∧ del(stock(PC)) does not produce the same result for any execution order ofits constituents. The execution of add(stock(PC)) adds the tuple stock(PC) to the starting stateand then the execution of del(stock(PC)) deletes this tuple thus resulting again the starting state.However, an execution in reverse order produces an extension of the starting state with the tuplestock(PC). On the other side, a transaction such as add(delivery(PC,JN))∧del(stock(PC)) producesthe same result for any execution order of its constituents.

In relation to transaction invocation, it is important to remark that this resource may lead toinfinite executions. For instance, a transaction which invokes to itself in a non-terminating way.In this paper, we are not interested in such executions. We are only interested in transactionalsemantic web services whose executions are finite.

In relation to existential quantification, a safeness condition is considered: every quantifiedvariable has to be bound to some value (non-deterministically) computed by some consult beforeusing that variable in a primitive update. For instance, in a transaction ∃s(consult(provider(s))⊗add(provision(p,s))∧ add(stock(p))), variable s is in the scope of a consult and its value is com-puted before executing add(provision(p,s)). However, in a transaction ∃s(add(provision(p,s))∧add(stock(p))), s is not in the scope of any consult. Finally, in a transaction ∃s(consult(provider(s))∧add(provision(p,s))∧ add(stock(p))), s is in the scope of a consult but its value is not computedbefore executing add(provision(p,s)). These two latter transactions have not semantics in ourproposal.

The semantics of a transaction φ is formalized by executional entailments of the form:

<state1, ...,staten>inv|= φ

1. Consult (ground case): Let φ be a query of the form consult(r(C)) where r(C) is a ground atom.

<state>inv|= φ iff r(C) ∈ state

2. Consult (non-ground case): Let φ be a query of the form ∃X(consult(r(X))) where X is a set ofvariables.

<state>inv|= φ iff r(C) ∈ state for some substitution of X with constants C

Semantic Web Services in a Transactional Context 8 / 15

Page 177: y V Taller de Programación Funcional (TPF)

3. Primitive update (delete case): Let φ be a primitive update of the form del(r(C)) where r(C) is aground atom.

r(C) ∈ state1⇒ <state1,state2>inv|= φ iff state2 = state1−r(C)r(C) 6∈ state⇒ <state>inv|= φ

4. Primitive update (add case): Let φ be a primitive update of the form add(r(C)) where r(C) is aground atom.

r(C) 6∈ state1⇒ <state1,state2>inv|= φ iff state2 = state1∪r(C)r(C) ∈ state⇒ <state>inv φ

5. Serial conjunction ⊗: Let φ be a serial conjunction of the form φ1⊗ ...⊗φn.

<state1, ...,staten+1>inv|= φ iff<state1,state2>inv|= φ1 and <state2, ...,staten+1>inv|= φ2⊗ ...⊗φn

6. Parallel conjunction ∧: Let φ be a parallel conjunction of the form φ1∧ ...∧φn. Let φπ(1)⊗ ...⊗φπ(n)be the serial conjunction which results from a permutation π of the constituents of φ .

<state1,staten+1>inv|= φ iff for every π ,<state1, ...>inv|= φπ(1)⊗ ...⊗φπ(n) and <...,staten+1>inv|= φπ(1)⊗ ...⊗φπ(n)

7. Transaction invocation: Let φ be a transaction invocation of the form r(C) for a transaction definedas r(X)⇐∃Y (ψ(X ,Y )) and a set of constants C.

<state1, ...,staten>inv|= φ iff <state1, ...,staten>inv|= ∃Y (ψ(C,Y ))

8. Existential quantification: Let φ be a transaction of the form ∃X(ψ(X)).

<state1, ...,staten>inv|= φ iff <state1, ...,staten>inv|= ψ(C)being C a set of contants whose computation satisfies the safeness condition.

9. Negation: Let φ be a transaction of the form ¬ψ .

<state1, ...,staten>inv|= φ iff <state1, ...,staten>inv 6|= ψ

From a syntactical point of view, a transactional semantic web service is a pre/post specifi-cation extended with a transaction. Pre-condition and post-condition are formulae of the form∃Y (ψ(X ,Y )), where ψ is a conjunction of atoms (including equalities). The schematic form ofa transactional web service is:

Service : rPreTransaction : r⇐ φ1, ... ,r⇐ φn Post

From a semantic point of view, a transactional semantic web service is the set of all groundrelevant executions associated to its specification. Formally,

<state1, ...,statek(i)>inv|= φi for every i = 1..n and for every ground relevant state1 such thatstate1 |= Pre and statek(i) |= Post

Semantic Web Services in a Transactional Context 9 / 15

Page 178: y V Taller de Programación Funcional (TPF)

Some examples of transactional semantic web service are:

//Sell a product that may or not be in stock. If not, a provision must be done.Service : sell2(p,c)Pre : product(p)∧∃s(provider(s))Transaction :

sell2(p,c)⇐¬productInStock(p)⊗∃s(consult(provider(s))⊗ (add(provision(p,s))∧add(stock(p)))⊗ sell1(p,c))

sell2(p,c)⇐ productInStock(p)⊗ sell1(p,c)Post : product(p)∧ sold(p)∧ customer(c)∧delivery(p,c)∧ invoice(p,c)

//Sell a product in stock with bookingService : sell3(p,c)Pre : product(p)∧ stock(p)Transaction :

sell3(p,c)⇐ (add(customer(c))∧add(booking(p,c)))⊗ sell1(p,c)Post : product(p)∧booking(p,c)∧ sold(p)∧ customer(c)∧delivery(p,c)∧ invoice(p,c)

4 Service MatchmakingService matchmaking is the mechanism which maps appropriate services to service requests[KlK08, KlK12]. In our proposal, a service request describes not only the set of desirable statesbut the sequence of relevant states for reaching them. Therefore, a transactional semantic webservice is said to satisfy a service request when its execution reaches the sequence of statesrequired by the service request. For the purpose of clarifying our proposal, we will follow aconcrete example. Suppose we are interested in matching service sell2 (see specification inSection 3) with service request buy1 (see specification in Section 1). To do it, we propose a firstcomparison between buy1 and sell2 based on their canonical executions. This comparison is keyto know whether a service may satisfy a request. For instance, the canonical execution generatedby the first formula in the transaction of sell2 is as follows:

state1 = product(p), provider(s)state2 = product(p), provider(s), provision(p, s),stock(p)state3 = product(p), provider(s), provision(p, s),stock(p),customer(c))state4 = product(p), provider(s), provision(p, s),delivery(p, c),customer(c)state5 = product(p), provider(s), provision(p, s),delivery(p, c),customer(c),

invoice(p, c),sold(p)

The inclusion matrix for the pair (buy1, sell2,1), where sell2,1 represents the canonical executioncorresponding to the first formula in the transaction of sell2, is as follows:

(buy1,sell2,1) state1 state2 state3 state4 state5

state1 6⊆ ⊆ ⊆ 6⊆ 6⊆state2 6⊆ 6⊆ 6⊆ ⊆ ⊆state3 6⊆ 6⊆ 6⊆ 6⊆ ⊆

Semantic Web Services in a Transactional Context 10 / 15

Page 179: y V Taller de Programación Funcional (TPF)

As we can verify, there is a possible matching between buy1 and sell2,1: state3 in buy1 is includedin state5 in sell2,1, state2 in buy1 is included in state4 in sell2,1 and there are two possibleinclusions for state1 in buy1 (state2 or state3 in sell2,1).

The analysis of the inclusion matrix for each pair (service request, service execution) allowsus to construct a canonical satisfaction matrix. The canonical satisfaction matrix will serve fordescribing potential satisfactions between service requests and service executions:

canonical satisfaction matrix buy1 buy2

sell1 yes nosell2 yes nosell3 yes yes

In our example, according to the canonical satisfaction matrix, if a web client poses a servicerequest buy2(TV,RB), we know in advance that only service sell3 may satisfy it. However, if aweb client poses a service request buy1(PC,JN), we know in advance that services sell1, sell2and sell3 may satisfy it.

Once selected a subset of services which may satisfy a service request from the informationsupplied by the canonical satisfaction matrix, we focus on determining which of these servicescan develop some ground relevant execution that satisfy the service request. The following suffi-ciency condition is considered: A service request can be satisfied by a ground relevant executione2 of a transactional semantic web service r in the context of a data invariant inv if (1) thereexists a substitution σ for the canonical execution e1 of r such that e1 ∼σ e2 and (2) for everystate si ∈ e2, we have that si |= inv.

Returning to our example, suppose we want to know whether a service request buy1(PC,JN)can be satisfied by the following ground relevant execution e2 of sell1 in the context of a datainvariant inv1:

e2 : s1 = product(PC),stock(PC), product(TV ),customer(RB)s2 = product(PC),stock(PC),customer(JN), product(TV ),customer(RB)s3 = product(PC),customer(JN),delivery(PC,JN), product(TV ),customer(RB)s4 = product(PC),customer(JN),delivery(PC,JN), invoice(PC,JN),sold(PC),

product(TV ),customer(RB)

According to the sufficiency condition, we must find a substitution σ for instantiating the canon-ical execution e1 of sell1 such that e1 ∼σ e2. The canonical execution of sell1 is the following:

e1 : state1 = product(p),stock(p)state2 = product(p),stock(p),customer(c)state3 = product(p),customer(c),delivery(p, c)state4 = product(p),customer(c),delivery(p, c), invoice(p, c),sold(p)

Therefore, it is easy to see that σ exists and it is equal to p/PC, c/JN.Once satisfied condition (1) in the sufficiency condition, we have to verify whether every

state in the ground relevant execution under consideration is a model of the data invariant. Incomputational terms, this task is expensive. To reduce its cost, we propose a solution inspiredby the RETE algorithm [For82]. We will take into account the form of each rule in the datainvariant. By definition, each rule in the data invariant is of the form ∀X(φ(X)⇒∃Y (ψ(X ,Y )))

Semantic Web Services in a Transactional Context 11 / 15

Page 180: y V Taller de Programación Funcional (TPF)

where φ and ψ are conjunctions of atoms. In our example,

Invariant : inv1//For every sold product must exist a customer, a delivery and an invoice.1. ∀p(product(p)∧ sold(p)⇒∃c(customer(c)∧delivery(p,c)∧ invoice(p,c)))//Every product which has been delivered can not be in stock.2. ∀p,c(product(p)∧delivery(p,c)∧ stock(p)⇒ f alse)//Customers and products are disjoint sets of individuals.3. ∀x(product(x)∧ customer(x)⇒ f alse)

We calculate the minimal set of atoms we need to add to each state in the instantiation of thecanonical execution in order to satisfy the antecedent of some rule in the invariant. The resultof this calculation is a matrix called reevaluation matrix. For instance, the instantiation of thecanonical execution e1 with substitution σ = p/PC, c/JN, e1σ , is:

e1σ : state1σ = product(PC),stock(PC)state2σ = product(PC),stock(PC),customer(JN)state3σ = product(PC),customer(JN),delivery(PC,JN)state4σ = product(PC),customer(JN),delivery(PC,JN), invoice(PC,JN),sold(PC)

As we can see, the addition of sold(PC) to state1σ will make true the antecedent of rule 1 ininv1. By proceeding in a similar way with all remaining states and rules in the invariant, we havethe following reevaluation matrix:

rule 1 rule 2 rule 3

s1 sold(PC) delivery(PC,JN) customer(PC)s2 sold(PC) delivery(PC,JN) customer(PC),product(JN)s3 sold(PC) stock(PC) customer(PC),product(JN)s4 stock(PC) customer(PC),product(JN)

In order to known which rules in the invariant has to be reevaluated, we have to calculate thesupplementary execution of the ground relevant execution under consideration with respect tothe instantiated canonical execution. In our example, this supplementary execution is:

e2(e1σ) : t1 = product(TV ),customer(RB)t2 = product(TV ),customer(RB)t3 = product(TV ),customer(RB)t4 = product(TV ),customer(RB)

If some element in the reevaluation matrix has a set of atoms which is contained in the corre-sponding state of the supplementary execution then the corresponding rule in the invariant has tobe reevaluated upon that state. In our example, no rules have to be evaluated in the execution un-der consideration because, for s1, sold(PC) 6⊆ t1, delivery(PC,JN) 6⊆ t1, customer(PC) 6⊆t1, for s2, sold(PC) 6⊆ t2, delivery(PC,JN) 6⊆ t2, customer(PC) 6⊆ t2, product(JN) 6⊆ t2and so on until covering all elements in the reevaluation matrix.

Once satisfied the sufficiency condition for our example, we can conclude that the servicerequest buy1(PC,JN) is satisfied by the ground relevant execution under consideration.

It is pertinent to recall that if the reevaluation of some rule in the invariant result false thenthe ground relevant execution under consideration can not be used to satisfy the service requestand therefore its effect must be undone restoring the web to its initial state.

Semantic Web Services in a Transactional Context 12 / 15

Page 181: y V Taller de Programación Funcional (TPF)

5 Related Work

The literature contains multiple proposals of different nature. Some proposals conceive semanticweb services as artifacts specified by means of sequences of states but these specifications are ofconceptual nature. For instance, in [KLP05] a conceptual frame is proposed for locating semanticweb services. The absence of formal languages for expressing the involved concepts obstructs itsformal interpretation and therefore its programming. Other proposals are incomplete in the sensethat only cover certain kinds of services. For instance, in [HZB06], a formalism is proposed fordescribing and reasoning about stateless services only. For instance, in [LiH04], web servicesand service requests are modeled as description logic classes. Matchmaking is viewed as theintersection of a web service with a service request, being this intersection computed by a DL-reasoner. Such proposals fail to reason about the dynamic of web services since DL reasonerscan only work with “static” knowledge bases. Other proposals are mainly interested in findingpractical solutions to particular problems but their expressive capabilities are quite limited. Forinstance in [JAS10], the main motivation is not to specify expressive semantic web services but tomake a clear distinction between semantic web services and service requests in order to define apractical semantic web service discovery. In [GuY10], the dynamics of web services is expressedin a restricted way in order to allow an effective processing by a model checker (Promela/SPIN).This restriction impedes the materialization of states and therefore the use of data invariants.

6 Conclusion

We have formalized a class of service requests that specify not only the set of desirable statesbut the sequence of relevant states for reaching them. For satisfying these requests, we haveformalized a class of services called transactional semantic web services which include a logictransaction for describing the possible sequences of relevant states the service can reach at run-time. The expressivity of the proposal is extended with the integration of databases at runtime.Databases contain invariants for constraining the set of possible states during the service execu-tion. Finally, we propose a solution to the problem of service matchmaking. A transaction mustbe undone if the data invariant is not satisfied at some point in the service execution. The formal-ism is original because (1) it integrates in a declarative way both the interface and the processof a web service, (2) its expressivity allows to describe state changes upon databases containingexpressive data invariants, (3) the formalism is intended to integrate web services and databasesat runtime and (4) it proposes a tractable solution to the problem of service matchmaking. To thebest of our knowledge, our work is the first one which aims to integrate databases, services andrequests in a semantic web where the concept of state change is a key requirement.

In relation to future work, we plan to extend this work with alternative forms of service requestsatisfaction. In practice, a transactional service may be useful for solving a particular service re-quest but may not adjust exactly to what is required by this (partial satisfaction). To characterizealternative forms of satisfaction will constitute our next step.

Semantic Web Services in a Transactional Context 13 / 15

Page 182: y V Taller de Programación Funcional (TPF)

Bibliography

[BK95] A. Bonner and M. Kifer. Transaction Logic Programming. (or, A Logic of Procedu-ral and Declarative Knowledge). Technical Report CSRI-323. November 1995. ComputerSystem Research Institute. University of Toronto.

[BK98] A. Bonner and M. Kifer. A Logic for Programming Database Transactions. In J.Chomicki and G. Saake, editors, Logics for Databases and Information Systems, chapter 5.Kluwer Academic Publishers, March 1998.

[Bon97] A.J. Bonner. Transaction Datalog: a Compositional Language for Transaction Pro-gramming. In Proceedings of the Sixth International Workshop on Database ProgrammingLanguages (DBPL), Estes Park, Colorado, August 1997. Lecture Notes in Computer Sci-ence, volume 1369, Springer-Verlag, 1998, pages 373-395.

[DNR08] A. Deustch, A. Nash and J. Remmel. The Chase Revisited. PODS’08 June, 2008Vancouver, Canada.

[For82] Charles R. Forgy. Rete: A Fast Algorithm for the Many Pattern/ManyObject PatternMatch Problem. Artificial Intelligence, 19 (1982) 17-37.

[GuY10] A. Gunay, P. Yolum. Service matchmaking revisited: An approach based on modelchecking. Journal of Web Semantics, 8 (2010) pp.292-309.

[HZB06] D. Hull, E. Zolin, A. Bovykin, I. Horrocks, U. Sattler and R. Stevens. Deciding Se-mantics Matching of Stateless Services. AAAI 2006. AAAI Press 2006.

[JAS10] M. Junghans, S. Agarwal and R. Studer. Towards a Practical Semantic Web ServiceDiscovery. ESWC 2010. LNCS 6089, pp 15-29, Springer-Verlag 2010.

[KLP05] U. Keller, R. Lara, A. Polleres and D. Fensel. Automatic Location of Services. ESWC2005. LNCS 3532 Springer 2005.

[KlK08] M. Klusch and F. Kaufer. WSMO-MX: A Hibrid Semantic Web Service Matchmaker.Web Intelligence and Agent Systems: An International Journal 5, 2008 1-5. IOS Press.

[KlK12] M. Klusch and P. Kapahnke. The iSeM matchmaker: A Flexible Approach for Adap-tive Hybrid Semantic Service Selection. Journal of Web Semantics: Science, Services andAgents an the World Wide Web 15 (2012) 1-14. Elsevier.

[LiH04] L. Li and I. Horrocks. A Software Framework for Matchmaking based on SemanticWeb Technology. Int. J. Electronic Commerce 8(4), 39-60, 2004.

[SKL07] M. Stollberg, U. Keller, H. Lausen and S. Heymans. Two-phase Web Service Discov-ery based on Rich Functional Descriptions. In Proc. 4th European Semantic Web Confer-ence (ESWC 2007).

[WSML08] The WSML working group members. WSML Language Reference.http://www.wsmo.org/wsml, 2008

Semantic Web Services in a Transactional Context 14 / 15

Page 183: y V Taller de Programación Funcional (TPF)

[WSMO08] The WSMO working group members. Web Service Modelling Ontology (WSMO).http://www.wsmo.org/ 2008

Semantic Web Services in a Transactional Context 15 / 15

Page 184: y V Taller de Programación Funcional (TPF)

Detecting Modular ACU Structural Symmetries

M. Alpuente1∗, S. Escobar2, J. Espert3†

[email protected] [email protected] [email protected], Universitat Politecnica de Valencia, Spain

Abstract: We present an efficient encoding of order-sorted modular ACU termsinto colored directed graphs. Then, by computing the automorphism groups of theencoded graphs, we are able to extract modular ACU structural symmetries bothinside a term and across a set of terms. Finally, we show how the computed symme-tries can be applied to the optimization of the equational generalization algorithmsfor modular ACU theories.

Keywords: equational least general generalization, equational least general anti-unification, ACU theories

1 Introduction

Generalization (also known as anti-unification) is the dual of unification [Plo70]. Roughly speak-ing, the generalization problem for two terms t1 and t2 means finding their least general general-ization (lgg), i.e., the least general term t such that both t1 and t2 are instances of t under appropri-ate substitutions. While studying order-sorted modular ACU1 generalization in [AEEMar], wefound that our algorithm spends a large amount of time performing computations that, althoughdifferent from previous ones, are somehow symmetrical to them and lead to equivalent (and thusredundant) results. Since this problem cannot be mitigated with mere memoization, we set outto find a way of preprocessing the terms to detect symmetries and instrument our algorithm toexploit them. This paper presents that ongoing work; in particular, we present a technique todetect modular ACU symmetries among a set of terms. We formulate an injective encoding oforder-sorted modular ACU terms in flat normal form into graphs with colored nodes. Then,we extract useful term redundancies from the automorphism groups of these graphs, which canthemselves be computed using efficient, well-known algorithms [JK07, Tor04]. By imposing anarbitrary order among equivalent subterms based on the automorphism groups, we avoid gener-ating many redundant computations in the equational least general generalization algorithm thatwe formulated in [AEEMar].

Let us illustrate the problem with some equational generalization examples. Let f be anassociative and commutative function symbol over natural numbers2. Consider the least general∗ M. Alpuente, S. Escobar, and J. Espert have been partially supported by the EU (FEDER) and the SpanishMEC/MICINN under grant TIN 2010-21062-C02-02, and by Generalitat Valenciana PROMETEO2011/052.† J. Espert has also been supported by the Spanish FPU grant FPU12/06223.1 Modular ACU generalization supports any combination of associative (A), commutative (C), and unity (U) equa-tional attributes for the function symbols of a given signature. By ACU (not qualified by modular) we refer to theorieswith the three types of equational attributes. In the same way, AC generalization refers to theories that satisfy asso-ciativity and commutativity properties, but not unity.2 Ignore Peano or other notations for now, just think of each number as a different constant.

Detecting Modular ACU Structural Symmetries 1 / 6

Page 185: y V Taller de Programación Funcional (TPF)

generalization problem of the terms f (0,1,2,3,4) and f (0,5,6,7,8). This problem has a singlesolution: f (0,x,y,z,u), where x, y, z, and u are fresh variables of sort Nat because the constant0 is the only term that is shared by both terms and the other constants have the same sort (Nat)and only appear in one of the two given terms.

Let us consider now the least general generarization of f (0,0,1,1,2,2,3,3,4,4) andf (0,0,5,5,6,6,7,7,8,8), where the different constants occur twice each; in this case, their leastgeneral generalizer is the term f (0,0,x,x,y,y,z,z, t, t). Observe that, like in the previous exam-ple, we do not care which non-zero number each variable of the generalizer refers to; i.e., thechoice between non-zero constants in this example is indifferent w.r.t. term structure.

However the problem becomes more involved if we have different symbols with possibly dif-ferent equational attributes as in the case of the least general generalization problem for the termsf (0,1,2,g(0,1),g(1,2),g(2,0)) and f (3,4,5,g(3,4),g(4,5),g(5,3)), where g is a commutative,but not associative symbol. The least general generalizer for this problem is f (x,y,z,g(x,y),g(y,z),g(z,x)). It is interesting to note how the possible generalizer substitutions reveal thesesymmetries: from the least general generalizer, we can obtain the first termf (0,1,2,g(0,1),g(1,2),g(2,0)) by applying any of the substitutions x→ 0,y→ 1,z→ 2, x→ 1,y→ 0,z→ 2, x→ 2,y→ 1,z→ 0, etc. In other words, the only requirement is thatthe mapping from x,y,z to 0,1,2 introduced by the substitution be bijective; the mappingitself is irrelevant, since 0, 1, and 2 are structurally equivalent.

2 Graph automorphisms

Isomorphisms of graphs [GGL95] are bijections of the vertex sets preserving adjacency as wellas non-adjacency. In the case of directed graphs, orientations must be preserved; in the case ofgraphs with colored edges and/or vertices, colors must also be preserved. Automorphisms of thegraph X = (V,E) are X → X isomorphisms; they form the subgroup Aut(X) of the symmetricgroup Sym(V ). Automorphisms of directed graphs are defined analogously.

The connection between graph isomorphisms and terms with equational attributes has beenpreviously explored. In [Bas94], Basin shows that AC term equivalence under variable renam-ing can be reduced to graph isomorphism and proves that both problems have the same com-plexity. In [AP01], Avenhaus and Plaisted formulate a technique to reduce the search space inequational inference problems; they prove that this technique has the same complexity as graphisomorphisms. The study of algorithms for the computation of isomorphisms and automorphismgroups and their computational implementation is a mature but active area of research. We relyon Bliss—a state-of-the-art automorphism group computation tool [JK07]—for our prototypicalimplementations.

3 The encoding

In this paper, we define an encoding of order-sorted modular ACU terms [CDE+07] in flat normalform (see [AEEMar]) into colored directed graphs that satisfy the following properties:

1. Every well-formed term can be encoded into a valid graph.

Detecting Modular ACU Structural Symmetries 2 / 6

Page 186: y V Taller de Programación Funcional (TPF)

(a) f is commutative (b) f is not commutative

Figure 1: Encoding of f (t1, . . . , tn)

2. The resulting graphs preserve the equational properties of the original term.

3. That information that we extract from the automorphisms of the encoded graphs alwayscorrespond with valid structural symmetries of the original terms.

We assume the existence of a mapping color(x) from Σ∪X to the set of the natural numbers.The elements of the image set of this mapping are the possible colors of the nodes. This mappingcan be any one that obeys the following rules:

1. Variables with the same sort are mapped to the same number.

2. Constants with the same sort are mapped to the same number.

3. Function symbols with non-zero arity are mapped to a unique number that is not sharedwith any other symbol, regardless of its sort.

4. Two symbols are not mapped to the same number, unless they verify one of the previousconditions.

Our encoding codomain has two classes of graph nodes: nodes that are labelled with a functionsymbol and unlabelled auxiliary nodes. Auxiliary nodes are always connected by an outgoingarc to a labelled node (child node) and by an ingoing arc to a different labelled node (parentnode). Auxiliary nodes whose parent node is labelled with a non-commutative (free, A, U, orAU) symbol can have additional links among them; this allows us to enforce ordering constraints.All auxiliary nodes share the same, special color. We formulate our encoding as follows:

1. Each variable is encoded into a unique node that is shared by all occurrences of the vari-able.

2. Each constant is encoded into a unique node that is shared by all occurrences of the con-stant.

Detecting Modular ACU Structural Symmetries 3 / 6

Page 187: y V Taller de Programación Funcional (TPF)

3. Let f be a commutative (C, AC, CU, or ACU) symbol and f (t1, . . . , tn) be a term. Theroot symbol f is encoded as a node with outgoing arcs pointing to the root symbols ofthe encoded subterms t1, . . . , tn, using fresh auxiliary nodes as intermediaries. Figure 1adepicts the structure of this transformation.

4. Let f be a non-commutative (free, A, U, or AU) symbol and f (t1, . . . , tn) be a term. Theroot symbol f is encoded as a node. Similarly to the commutative case, the root symbolf is encoded as a node with outgoing arcs pointing to the root symbols of the encodedsubterms t1, . . . , tn, using fresh auxiliary nodes as intermediaries. The difference with thepreceeding case is that each auxiliary node has an outgoing arc to the auxiliary node of thenext subterm (except for the last term), which allows us to express ordering constraints.Figure 1b depicts the structure of this transformation.

The reader might think that the auxiliar nodes are redundant in the commutative cases (C, AC,CU, and ACU). However, the resulting, simplified encoding would be incompatible with termsharing. Consider the term f (0,0,1), where f is an AC function symbol and 0 are 1 constants ofthe sort Nat. The encoded graph would have two identical arcs from f to the node that representsthe encoding of the constant 0, which would be an invalid graph. Note that the duplication of thenode associated to the constant 0 would not lead to a valid representation either, because then theencoded form would not be able to distinguish among constants that belong to the same sort, asis the case for the constants 0 and 1.

The U axioms are ignored for encoding purposes. In flat normal form, the U axioms lead tocompact representations (minimum length) that do not introduce structural redundancies. Hence,we can detect the symmetries for ACU function symbols as if they were AC, AU symbols as ifthey were A, CU symbols as if they were C, and U symbols as if they were free.

4 Applications

By extending our signature with a fresh commutative symbol t with an appropriate sort signa-ture, we can combine the encodings of a set of terms t1, . . . , tn to deliver the encoding of theterm t(t1, . . . , tn). This simple trick allows us to detect modular ACU symmetries across termsas well as internal symmetries that are consistent across all the given terms. These symmetriesare relevant for the equational generalization of modular ACU theories. Table 1 shows how thesymmetries can avoid a large number of computations in the computation of AC-decompositions,a critical part of our equational generalization algorithm. For this experiment we have used twoterms of the form f (0, . . . ,(n−1)) and f (n, ...,(2n−1)) where f is an associative-commutativefunction symbol and the numbers represent different constants. This configuration appears fre-quently when the input terms, or part of them, represent sets. In Table 1, row (S) indicatesthe original size (number of symbols) of the terms, row (U) represents the number of AC-decompositions that must be checked by the original, unoptimized algorithm and row (O) standsfor the number of AC-decompositions that must be checked after using our symmetry-basedtransformation. Note that the achieved speedup (U/O) grows exponentially with the size of theterms.

As an example, Figure 2 shows the encoding for the (unsorted) generalization problem Γ of

Detecting Modular ACU Structural Symmetries 4 / 6

Page 188: y V Taller de Programación Funcional (TPF)

Table 1: AC-decompositions with and without preprocessing

size (S) 8 10 12 14 16

unoptimized (U) 15 184 2945 63756 (error)optimized (O) 5 29 209 1909 20801ratio (U/O) 3 6.3 14.4 33 -

terms f (g(a,b),g(b,c)) and f (g(b,c),g(c,b)), where a, b, and c are constants, f is an associative-commutative function, and g is an associative but not commutative function. The dashed lineslink structurally equivalent nodes, as computed by the technique. Observe that this generalizationproblem is symmetric, because the top-level symbols of both terms are linked. We can transformone term into the other by swapping constants a and c and applying equational axioms. Thisproperty halves the number of cases to consider in the generalization algorithm.

Figure 2: Encoding of the generalization problem Γ

Finally, we would like to remark that although this technique has been developed to optimizethe computation of lggs, the technique itself is agnostic w.r.t. to generalization and we believethat it might be useful in other domains—such as equational unification—that might benefit fromdiscovering the structural symmetries introduced by equational attributes. As future work, weplan to study the relationship between the symmetries than can be detected and exploited in equa-tional AC-unification by following our methodology compared to more conventional equationalunification algorithms based on diophantine encoding.

Detecting Modular ACU Structural Symmetries 5 / 6

Page 189: y V Taller de Programación Funcional (TPF)

Bibliography

[AEEMar] M. Alpuente, S. Escobar, J. Espert, J. Meseguer. A Modular Order-sorted EquationalGeneralization Algorithm. Information and Computation, To appear.

[AP01] J. Avenhaus, D. A. Plaisted. General algorithms for permutations in equational in-ference. IFIP Trans. A. 26:2001, 2001.

[Bas94] D. A. Basin. A Term Equality Problem Equivalent to Graph Isomorphism. Inf. Pro-cess. Lett. 51(2):61–66, 1994.

[CDE+07] M. Clavel, F. Duran, S. Eker, P. Lincoln, N. Martı-Oliet, J. Meseguer, C. Talcott.All About Maude - A High-Performance Logical Framework. Springer-Verlag NewYork, Inc., Secaucus, NJ, USA, 2007.

[GGL95] R. L. Graham, M. Grotschel, L. Lovasz (eds.). Handbook of combinatorics (vol. 2).MIT Press, Cambridge, MA, USA, 1995.

[JK07] T. Junttila, P. Kaski. Engineering an efficient canonical labeling tool for large andsparse graphs. In Proc. ALENEX07. Pp. 135–149. SIAM, 2007.

[Plo70] G. D. Plotkin. A note on inductive generalization. Mach. Intell. 5:153–163, 1970.

[Tor04] J. Toran. On the Hardness of Graph Isomorphism. SIAM J. Comput. 33(5):1093–1108, May 2004.

Detecting Modular ACU Structural Symmetries 6 / 6

Page 190: y V Taller de Programación Funcional (TPF)

Sesión 6: Invited Talk

190

Page 191: y V Taller de Programación Funcional (TPF)

Sesión 6: Invited Talk

11.00-12.30 Olaf Chitil: Typed Lazy Contracts

191

Page 192: y V Taller de Programación Funcional (TPF)

Charla Invitada: Typed Lazy Contracts

Olaf ChitilUniversity of Kent, [email protected]

Pre- and post-conditions have been important tools for developing correctprograms since the early days of programming. Contracts combine pre- andpost-conditions. Contracts are usually checked at runtime. If the pre-conditionof a function does not hold, then execution is aborted and the caller of thefunction is blamed for violating the contract. If the post-condition of a functiondoes not hold (but the pre-condition does), then the function itself is blamed.

The runtime-checked assertions that many programming languages such asC and Java provide are precursors of language support for contracts. Since1986 Bertrand Meyer advocates programming by contract for object-orientedprogramming languages. In 2002 Robby Findler and Matthias Felleisen es-tablished contracts for higher-order functional programming languages. Theyshowed how properties of functional arguments can be checked at runtime andhow to provide correct blaming for functional arguments. Since then Schemeprogrammers have been using contracts.

Until recently the functional language Haskell had no support for contracts.In contrast to Scheme, Haskell has a sophisticated static type system and isbased on lazy, demand-driven evaluation. The main challenge is that a defi-nition of contracts can easily break the semantics of a lazy language. Hencewe start a contract system for Haskell by identifying a few axioms. We de-fine a weak disjunction combinator and together with a conjunction combinatorcontracts form a bounded distributive lattice. We derive an implementationfrom the axioms. For a truly useful contract library for Haskell we still haveto consider further issues such as non-invasiveness, informative error messagesand general ease of use. Reducing complexity, some expressivity and giving upsome equivalences, we obtain a practical contract library for Haskell.

1

Page 193: y V Taller de Programación Funcional (TPF)

Sesión 7: Model and Bisimilarity Checking

193

Page 194: y V Taller de Programación Funcional (TPF)

Sesión 7: Model and Bisimilarity Checking

16.00–16.30 María Martos-Salgado and Fernando Rosa-Velardo: On theDecidability of Model Checking LTL Fragments in Mono-tonic Extensions of Petri Nets

16.30–17.00 Laura Panizo and María-del-Mar Gallardo: Verifying Hy-brid Systems with Explicit Model Checkers

17.00–17.30 Fernando Orejas, Artur Boronat, Ulrike Golas, and NikosMylonakis: Checking Bisimilarity for Attributed GraphTransformation

194

Page 195: y V Taller de Programación Funcional (TPF)

On the decidability of model checking LTL fragments in monotonicextensions of Petri nets

Mar ıa Martos-Salgado1 and Fernando Rosa-Velardo2∗

1 [email protected] Complutense de Madrid

2 [email protected] Complutense de Madrid

Abstract: We study the model checking problem for monotonic extensions of PetriNets, namely for two extensions of Petri nets: reset nets (nets in which places can beemptied by the firing of a transition with a reset arc) andν-Petri nets (nets in whichtokens are pure names that can be matched with equality and dynamically created).We consider several fragments of LTL for which model checking is decidable forP/T nets. We first show that model checking those logics is undecidable forresetnets. We transfer those results to the case ofν-PN. In order to cope with these neg-ative results, we define a weaker fragment of LTL, in which negation is not allowed.We prove that model checking that fragment is decidable both for reset nets andν-PN, though with a non primitive recursive complexity. Finally, we prove that modelchecking a version of that fragment with universal interpretation is undecidable evenfor P/T nets.

Keywords: LTL, model checking, Petri nets, decidability, complexity

1 Introduction

Temporal logics [4] have been established as a very expressive formalism for the specification ofproperties of computational concurrent systems. The model checking problem is the problem ofchecking if a given system satisfies a given formula.

For infinite state systems the model checking problem is undecidable in general [15]. A verywell known formalism for infinite state concurrent systems are Petri nets [6]. Place/Transitionnets (P/T nets) are potentially infinite state, but their expressive power is below Minsky machines(e.g., reachability is decidable for them [8]). Decidability and complexity of the model checkingproblem for P/T nets are well studied, and the corresponding decidability frontiers are well set-tled [13, 9, 12, 8]. Roughly speaking, model checking any branching-time logic is undecidablefor them, while for linear time logics, “event-based” LTL is decidable, though “state-based” LTLis undecidable.

In the last two decades, several monotonic extensions of Petri nets haveappeared in the lit-erature. These extensions usually consist either on the extension of the firing rule of P/T nets,

∗ Authors partially supported by the MEC Spanish project DESAFIOS10 TIN2009-14599-C03-01, and Comunidadde Madrid program PROMETIDOS S2009/TIC-1465.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets 1 / 15

Page 196: y V Taller de Programación Funcional (TPF)

or on the use of colors, that is, distinguishable tokens. We consider two simple extensions ofP/T nets, one in each group: reset nets [7] andν-Petri nets (ν-PN) [21]. In reset nets the firingof a transition can empty some places. Their modeling capabilities are discussedfor instancein [14]. Tokens inν-PNs are pure names, that can be created fresh, moved along the net andused to restrict the firing of transitions with name matching. Names can be seen as processidentifiers [19], so thatν-PN can serve as the basis of models in which an unbounded numberof components (which are in turn unbounded) synchronize. For example, they can be used tomodel resource-constrained workflow nets, an extension of workflownets in which an arbitrarynumber of instances of the workflow can be executed concurrently [11]. In [5], they are used togive a semantics to an extension of BPEL [16] with instance isolation.

In this paper we study the decidability of the model checking problem for these models. Moreprecisely, we consider the logics for which model checking is decidable for P/T nets, and westudy their decidability for the two extensions. In particular, we studyLTLf , which is the frag-ment of LTL that uses onlyfirst as basic predicate [9], L (F), the fragment of LTL in whichnegation is only applied to basic predicates (not to operators), and the operators areX (next),F(eventually),∧ and∨ [12]; andL (GF), which is the fragment of LTL in which the only allowedcomposed operator isGF (globally future), the operators areF, ∨ and∧ and negation is onlyapplied to basic predicates [13].

Unfortunately, we conclude that the decidability results for P/T nets cannotbe adapted, sothat model checking any of the logics considered is undecidable. In particular, we reduce modelcheckingLTLf for lossy inhibitor nets, which is undecidable, to model checkingLTLf for resetnets. Moreover, we prove that repeated coverability and reachability, which are undecidable forreset nets, can be expressed inL (GF) andL (F) respectively.

As a first step to mitigate the previous undecidability result, we consider a fragment of LTLweaker than all the logics considered so far in which, in particular, we do not allow negations.We call that logicFcov. We prove that model checking this logic is decidable for both models.

In some of the subclasses of LTL considered in the literature [13, 12] a formula is said to besatisfied if there exists one run that satisfies it, as opposed to the more standard definition of LTLin which all runs are required to satisfy the formula. Even though the two interpretations areequivalent when negation can be used without restriction, this is not the case for those subclassesof LTL, neither forFcov. We justify this definition by proving that already for P/T nets, modelcheckingFcov is undecidable under the universal interpretation.Outline: The rest of the paper is structured as follows. Section2 presents some basic results andnotations we use throughout the paper. Section3 proves undecidability of model checking theconsidered logics for reset nets andν-PN. Section4 definesFcov and proves decidability of themodel checking problem for reset nets andν-PN, and undecidability for P/T nets in the universalcase. In Section5 we present our conclusions.

2 Preliminaries

A quasi order(qo) is a reflexive and transitive binary relation. For a qo≤, we writea < b ifa≤ b andb 6≤ a.

Labelled transition systems.A transition systemis a tupleS = (S,L,→,s0), whereSis a (pos-

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets 2 / 15

Page 197: y V Taller de Programación Funcional (TPF)

sibly infinite) set of states,L is a set of labels,s0 ∈ S is the initial state and→⊆ S×L×S. Wewrite s1

a→ s2 instead of(s1,a,s2) ∈→, and we denote by→∗ the reflexive and transitive closure

of → and by→+ the transitive closure of→. A run π of S is any sequences0a0→ s1

a1→ s2... suchthatsi

ai→ si+1 for i ≥ 0. Thereachability problemconsists in deciding for a given statesf whethers0 →

∗ sf . If S is endowed with a qo≤ we can define thecoverability problem, that consists indeciding, givensf ∈ S, whether somes≥ sf , is reachable. Then, we say thatscoverssf . There-peated coverability problemis the problem of deciding whether a given state is covered infinitelyoften in some infinite run, that is, if givenm there is an infinite runm0 →

+ m1 →+ m2 →

+ ...such thatm≤ mi for all i ≥ 1.

Multisets. Given a (possibly infinite) arbitrary setA, we denote byA⊕ the set of finite multisetsof A, that is, the mappingsm : A→ N for which supp(m) = a∈ A | m(a) > 0 is finite. Whenneeded, we identify each conventional set with the multiset defined by its characteristic function,and use set notation for multisets when convenient. Given two multisetsm1,m2 ∈ A⊕ we denoteby m1+m2 the multiset defined by(m1+m2)(a) = m1(a)+m2(a). We define multiset inclusionas follows:m1 ⊆ m2 if m1(a)≤ m2(a) for all a∈ A. If m1 ⊆ m2, we can definem2−m1, taking(m2−m1)(a) = m2(a)−m1(a). We denote by /0∈ A⊕ the empty multiset, given by /0(a) = 0 forall a∈ A.

Petri nets. A Petri net is a tupleN = (P,T,F,R, I) whereP is a finite set of places,T isa finite set of transitions (withP∩ T = /0), F : (P× T)∪ (T ×P) → N is the flow function,R⊆ P×T andI ⊆ P×T are two relations containing the so calledreset arcsandinhibitor arcs(also called zero tests), respectively. Givent ∈ T, the multiset of preconditions oft is •t ∈ P⊕

given by(•t)(p) = F(p, t). Analogously, the postconditions oft are given by(t•)(p) = F(t, p).A marking is anym∈ P⊕. For Petri nets we consider the order between markings given bymultiset inclusion. This order defines the standard coverability problem forPetri nets.

We say that a transitiont is enabled at a markingm if for eachp∈ P, m(p)≥ F(p, t) and foreach(q, t) ∈ I , m(q) = 0. In that case,t can be fired fromm, reaching a new markingm′, which

is denoted bymt→ m′, wherem′ is given by:

m′(p) =

(m(p)−F(p, t))+F(t, p) if (p, t) /∈ RF(t, p) if (p, t) ∈ R

Notice that if(p, t) ∈ I thenp must be empty in order to firet (hence, it is a zero test). Noticealso that if(p, t) ∈ R andF(t, p) = 0 (i.e., t does not put any token inp) then p has no tokensafter the firing oft (hencep is reset). APlace/Transition net(P/T net for short) is a Petri netwith I = R= /0. The reachability, the coverability and the repeated coverability problemsare alldecidable for P/T nets [8].

A reset netis a Petri net withI = /0, that is, a P/T net possibly with some reset arcs. Reacha-bility and repeated coverability are no longer decidable for reset nets, though coverability is stilldecidable [7].

Example1 Focus on Fig.1. The double arc represents a reset arc from placer to t, that is,(r, t) ∈ R. Then, transitiont is enabled in the marking represented in the net in the left-hand sideof the figure, and it can be fired, reaching the marking depicted in the right.All tokens in place

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets 3 / 15

Page 198: y V Taller de Programación Funcional (TPF)

• •a

ab••

p q

r

t

→• •a

ab

p q

r

t

Figure 1: The firing of a transition in a reset net.

ab ab

a

bc be

p1 p3

p2 p4

xy xν1

y ν1ν2

→aa ad

a

c de

(d,e fresh)

p1 p3

p2 p4

xy xν1

y ν1ν2

Figure 2: A simpleν-PN

r has been consumed in the firing oft due to the presence of the reset arc. As there is not apriority order over transitions, note that from the marking represented in the left-hand side, theother transition could have been fired instead oft, reaching a marking with a token in each placeof the net.

An inhibitor net is a Petri net withR= /0, that is, a P/T net with inhibitor arcs1. Inhibitor netswith two inhibitor arcs are already Turing complete [15], though,interestingly, inhibitor nets withonly one inhibitor arc are not [18].

ν-PN. Another way in which P/T nets are extended in the literature is by considering distin-guishable tokens. Perhaps the most simple extension of P/T nets with (arbitrarilymany) distin-guishable tokens areν-PN [21], that encompass unboundedly many names (via a mechanism forfresh name creation) and the unbounded occurrence of each name.

LetVar be a set of variables, andϒ ⊂Var a set of special variables for fresh name creation. Aν-PN is a tupleN = (P,T,F), whereP andT are finite disjoint sets, andF : (P×T)∪ (T×P)→Var⊕ labels every arc by a multiset of variables. We denotepre(t) =

p∈Psupp(F(p, t)) (the setof variables in pre-arcs) andpost(t) =

p∈Psupp(F(t, p)) (the set of variables in post-arcs). Wealso takeVar(t) = pre(t)∪post(t).

Let Id be an infinite set of names. Amarkingof a ν-PN is a mappingM : P→ Id⊕ assigningto each place the bag of tokens currently in it. We takeId(M) =

p∈Psupp(M(p)), that is, theset of names inM.

Given a transitiont ∈ T of aν-PN, amodefor t is any injectionσ : Var(t)→ Id. Being modesinjections, we can match names with equality (just by using the same variable more than once)and with inequality (by using different variables). We say that a transitiont is enabled with amodeσ for a markingM, if for all p∈ P, σ(F(p, t))⊆ M(p) and if ν ∈ ϒ, thenσ(ν) /∈ Id(M).Then,t can be fired, and a new markingM′ is reached, given byM′(p) = (M(p)−σ(F(p, t)))+

1 Actually, it is straightforward to simulate a reset arc using inhibitor arcs, in away preserving reachability, cover-ability and repeated coverability.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets 4 / 15

Page 199: y V Taller de Programación Funcional (TPF)

σ(F(t, p)) for all p∈ P. In that case we writeMt→ M′.

Example2 Fig. 2 depicts theν-PN N given byN = (p1, p2, p3, p4,t,F) with F(p1, t) =x,y, F(p2, t) = y, F(t, p3) = x,ν1, F(t, p4) = ν1,ν2, andF(n,m) = /0 elsewhere. Weassume thatν1,ν2 ∈ ϒ. The initial marking is given byM0(p1) = a,b, M0(p2) = b,c andM0(pi) = /0 for i = 3,4. The transition is fired with respect to a modeσ given byσ(x) = a,σ(y) = b, σ(ν1) = d andσ(ν2) = e. Note that namesd ande are not in the initial marking, andtherefore they are created new.

Intuitively, each name in a marking of aν-PN represents a different process running in thesame net. Therefore, we can represent the synchronization between processes and the creationof new ones.

We say thatM ⊑ M′ ⇔ there is a renamingM1 of M such thatM1(p) ⊆ M′(p) for all p ∈P. With this order, coverability is decidable forν-PN, though reachability is undecidable forthem [21].

Example3 The markingM given byM(p1) = /0, M(p2) = /0, M(p3) = a,d,M(p4) = a,cis covered by the markingM1 on the right-hand side of Fig.2. Note that, although there is not atoken of namea in placep4, with the order we have defined,M is covered byM1 by consideringthe renamingα , such thatα(a) = d, α(d) = a andα(e) = c.

Finally, note that both models induce a labelled transition system in the obvious way.

3 Model checking Petri net extensions

Temporal logics are used to specify dynamic properties of systems. They consider a set of atomicformulae (which express atomic properties) and several temporal operators and path quantifiers,which allow us to express temporal properties. There are mainly two kinds oftemporal logics:linear time logics and branching time logics. The properties that are expressed in branching timelogics are about the computation tree [1], while the ones expressed in linear time logics are aboutthe runs [17]. In this paper we focus on linear time logics because model checking P/T nets withbranching time logics is undecidable, even for very simple fragments [9].

The basic temporal operators used in temporal logics areX, F andU2. The most representativeexample of a linear time logic is LTL.

Definition 1 An LTL formula is either an atomic formula or a formula of the form¬ϕ , ϕ ∧ψ ,ϕ ∨ψ , Xϕ , Fϕ , or ϕUψ , whereϕ andψ are LTL formulae.

We explain the semantics of the temporal operators informally. For more details see e.g. [4].LTL formulae are interpreted over maximal runs, i.e., runs that are either infinite, or end in adeadlock state. Letϕ be an LTL formula,S a transition system andπ a maximal run starting ins. We writeS ,π ϕ to denote thatπ satisfiesϕ :

2 Even thoughF can be defined in terms ofU, we prefer to include it as a primitive temporal quantifier, since we willlater disallowU.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets 5 / 15

Page 200: y V Taller de Programación Funcional (TPF)

• S ,π Xϕ (next) holds if the propertyϕ holds in the state that followss in π.

• S ,π Fϕ (eventually) holds if the propertyϕ holds in some state ofπ.

• S ,π ϕUψ (until) holds if there is a state of the pathπ such thatψ holds in that state,andϕ holds at every preceding state on the path.

We also defineG (globally) asGϕ =¬F¬ϕ , so thatS ,π Gϕ holds ifϕ holds in every stateof π. The atomic formulae usually considered for P/T nets, are given by the following predicates:

• cov(m), wherem is a marking:cov(m) holds inπ if the first marking inπ coversm.

• first(t), wheret is a transition:first(t) holds inπ if the first transition fired inπ is t.

Some works consider the atomic predicatesge(p,n) anden(t). The first one expresses thatthere are at leastn tokens in placep, and the second states thatt is enabled. We will not considerthem since they are equivalent tocov(

np, ..., p) andcov(•t), respectively.

According to the standard definition, a systemS satisfies an LTL formulaϕ, denoted byS |= ϕ iff every maximal run of the system satisfies it (universal interpretation).The modelchecking problem consists in deciding, givenS andϕ , whetherS |= ϕ . The model checkingproblem is equivalent to deciding the existence of one run satisfying the formula (existential in-terpretation), provided negation can be used without restriction, sinceS|= ϕ (under the universalinterpretation) iffS 6|= ¬ϕ (under the existential interpretation).

We consider different LTL fragments, built depending on which predicates and operators weconsider.

Definition 2 We consider the following fragments of LTL:

• LTLf , the fragment of LTL that uses onlyfirst as basic predicate [9],

• L (F), the fragment of LTL in which negation is only applied to basic predicates (not tooperators), and the operators areX, F, ∧ and∨ [12],

• L (GF), the fragment of LTL in which the only allowed composed operator isGF, theoperators areF, ∨ and∧ and negation is only applied to basic predicates [13].

Example4 • The formulaFfirst(t), which expresses thatt is eventually fired, is inL (F),butGfirst(t) = ¬F¬first(t), which expresses thatt is always fired, is not.

• The formulafirst(t)→ GFfirst(t) is in L (GF), butFfirst(t)→ GFfirst(t) = ¬Ffirst(t)∨GFfirst(t), which expresses that ift is eventually fired, then it is fired infinitely often, isnot.

In LTLf negation can be used without restriction, so that the universal and the existential inter-pretations are equivalent (i.e., their model checking decision problems areequivalent). However,this is not the case forL (F) andL (GF). Actually, they are defined using the existential inter-pretation in [12, 13]. For the subclasses of LTL considered, we have the following results.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets 6 / 15

Page 201: y V Taller de Programación Funcional (TPF)

• Model checking LTL is undecidable (with bothfirst andcov), but model checkingLTLf isdecidable (withcovonly) [9].

• Model checkingL (F) is decidable [12] (with existential interpretation),

• Model checkingL (GF) is decidable [13] (with existential interpretation).

3.1 Model checking reset nets

Let us see that the three logics which are decidable for P/T nets become undecidable for resetnets. Let us first considerLTLf . In [3] the model checking problem ofLTLf is studied forlossy vector addition systems (lossy VAS) with tests for zero, which is proved to be undecidable.Let us see that we can adapt that result for reset nets. Let us first define the lossy version of atransition system in general.

Definition 3 Given a transition systemS = (S,→,s0) and a quasi-order≤ over S, the lossyversionof S is Sl = (S,→l ,s0), wheres1 →l s2 if and only if s1 ≥ s′1 → s2. A lossy Petri netisthe lossy version of some Petri net.

In the lossy version of a transition system, states can be spontaneously decreased. In the caseof Petri nets, tokens may be lost just before a transition is fired. Reset nets can simulate lossyinhibitor nets, as we prove next.

Proposition 1 Model checking LTLf is undecidable for reset nets.

Proof. We reduce model checkingLTLf for lossy inhibitor nets, which is undecidable [3], tothe same problem for reset nets. LetN = (P,T,F, I) be an inhibitor net. We define the reset netN′ = (P,T,F, I). Notice that sinceN′ is a reset net, checks for zero have been replaced by resets.The following holds:

• m1t→m2 in N ⇒ there is anm′

2 ≥ m2 such thatm1t→m′

2 in N′: the preconditions and effectsof the firings oft in N andN′ are the same, except for the lossiness and the inhibitor arcs.Therefore, ift has no inhibitor arc, andm1

t→m2 in N, t is enabled atm1 in N′, and it can

be fired reaching a marking greater or equal thanm2, because some token may have beenlost in the firing inN.

Now, suppose thatt has some inhibitor arcs, andm1t→m2 in N. First of all, note that if a

marking is enabled inN, it is enabled inN′. As t is enabled atm1 in N, it is enabled inN′ too. Moreover, the places with inhibitor arcs leading tot are empty in that marking.Therefore, whent is fired fromm1 in N′, the places that are reset by reset arcs, and alreadyempty, and therefore, the only difference in the effects of the firing oft in both nets is thelossines. Then, sincet may loose tokens inN, but not inN′, m1

t→m′

2 in N′, with m′2 ≥ m2.

• m1t→m2 in N′ ⇒ m1

t→m2 in N: In particular, ifN′ resets a place,N can first loose tokens,

thus emptying it, and then test for zero in that place. Therefore, the transition is fireablein N (because the preconditions of the firings oft in N andN′ are the same, except for thelossiness and the inhibitor arcs) and the place is empty at the end of both firings.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets 7 / 15

Page 202: y V Taller de Programación Funcional (TPF)

Therefore, there is a surjective homomorphism between the runs ofN andN′ that preserves thesequence of labels of runs. Since the only atomic predicate inLTLf is first, N |= ϕ iff N′ |= ϕand we conclude.

Let us now focus on the two other fragments of LTL. The case forL (GF) is straightforward:

Proposition 2 Model checkingL (GF) for reset nets is undecidable.

Proof. It is enough to consider thatGFcov(M), which is a formula inL (GF), expresses therepeated coverability problem, which is undecidable for reset nets [2].

However, not only that fragment, but the weaker fragmentL (F), which is decidable for P/Tnets [12], is undecidable for reset nets. The following proof uses ideas from [12], in which modelcheckingL (F) is reduced to reachability for P/T nets.

Proposition 3 Model checkingL (F) for reset nets is undecidable.

Proof. We reduce reachability, which is undecidable for reset nets [2], to model checking someformula inL (F). Let N = (P,T,F,R) be a reset net andm a marking ofN. We can computethe set of the least markings greater thanm.3 Indeed, that set is justmp | p∈ P, wheremp isgiven bymp(q) = m(q) for q 6= p andmp(p) = m(p)+1. Then,m is reachable inN iff there is areachable markingm′ that coversm, but does not cover anymp, because this would imply that ineach placep, m′ have exactlyp tokens (because it does not covermp). Therefore,m is reachablein N iff the formulaF(cov(m)∧

p∈P¬cov(mp)) is satisfied.

The previous proof is based on obtaining a formula which expresses the reachability problem.In order to obtain this formula, there is an important property that reset netssatisfy: Given amarkingm, we are able to compute a finite set of markingsS= m1, . . . ,mn such that for eachmi ∈ S, mi ⊃ mand ifm′ ⊃ m, then there ismi ∈ Ssuch thatm′ ⊇ mi . Intuitively, we can computethe finite set of “the smallest markings greater thanm”. As we can build that set, a markingmf

coincides withm if and only if mf coversm andmf does not cover any marking ofS.

3.2 Model checkingν-PN

We first recall from [21] how ν-PN can simulate reset nets (see Fig.3). For each placep of N weconsider a new placep′ in N′. The main idea of the construction is to store in placep′ a singletoken of the colour that we consider valid in this marking. That is, the tokens inp of the colourof the token inp′ will be considered valid, and the rest of the tokens inp will be consideredgarbage. For example, in theν-PN of Fig.3, there are two valid tokens in placer, because thecolour of the token inr ′ is b.

The construction ofN′ guarantees thatp′ contains a single token at any time. The firing of anytransition ensures that the token being used inp coincides with that inp′ (by labelling both arcswith the same variablexp). Every time a transition resets a placep, the token inp′ is replaced bya fresh one, so that no token remaining inp can be used from then on. For example, suppose we

3 In order theory that set is called the cover ofm, though we prefer not to overload that term here.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets 8 / 15

Page 203: y V Taller de Programación Funcional (TPF)

• •a

ab••

p q

r

t→

a aa

a ccbbb

a

p q

r

p′

r ′q′

txp xq

xp xq

xr ν

xr

xq

xq

xr

Figure 3: A reset net and the correspondingν-PN. The double arrow represents a reset arc

fire transitiont in Fig. 3. Then, a new colour is set tor ′, and therefore the tokens of nameb in rcannot be used anymore.

Therefore, this simulation can introduce some garbage tokens (those inp when p is reset).Moreover, given a markingm we definem′ by arbitrarily choosing a different nameap ∈ Id

for eachp∈ P, and takingm′(p′) = ap, andm′(p) = ap,m(p)... ,ap. Then, ifm0 is the initial

marking ofN, N′ with initial marking m′0 simulatesN. The previous simulation preserves all

behavioral properties. Then, the following is a straightforward consequence of Prop.1.

Corollary 1 Model checking LTLf is undecidable forν-PN.

The previous simulation also preserves coverability. More precisely, if a marking m is cover-able in the reset netN, then the markingm′ of N′ defined above is coverable too. The markingsin the simulation may contain some garbage, which is created when we simulate the firing of areset, because instead of removing all tokens of some placep, we change the name of the tokenin p′, making all tokens inp become garbage. However, the presence of that garbage is irrelevantfor coverability. In particular, we have the following.

Proposition 4 Repeated coverability is undecidable forν-PN.

Proof. It is enough to consider that repeated coverability is undecidable for reset nets [2], andthat the previous simulation preserves repeated coverability. Indeed,mcan be repeatedly coveredfrom m0 in N iff M′ can be repeatedly covered fromM′

0 in N′. Indeed, ifm is repeatedly coveredthere is a runm0 →

+ m1 →+ m2 →

+ ... of N such thatmi ≥ m for all i ≥ 1. By constructionof N′, there is a runm′

0 →+ M1 →

+ M2 →+ ... of N′ such thatMi ≥ m′

i ≥ m′ for all i ≥ 1, som′ is repeatedly covered. Moreover,Mi coincides withm′

i when considering only the “validtokens” ofMi (and after possibly renaming the names carried by the tokens). The converse isanalogous.

Once we know that repeated coverability is undecidable, undecidability of model checkingL (GF) is trivial.

Corollary 2 Model checkingL (GF) for ν-PN is undecidable.

Next, we see the undecidability of model checkingL (F) for ν-PN.

Proposition 5 Model checkingL (F) for ν-PN is undecidable.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets 9 / 15

Page 204: y V Taller de Programación Funcional (TPF)

p0

t1

p1 p2t2

paux

t3

M1 M2

Figure 4: Construction of Prop.6

Proof. The proof is analogous to the one of the same result for reset nets. We reduce reachabilityin ν-PN, which is undecidable [21], to model checking some formula inL (F). LetN= (P,T,F)be aν-PN. Given a markingM, we can compute the finite set of the least markings greater thanM. Indeed, givenp∈ P andc∈ Id(M)∪b, with b /∈ Id(M), we defineMpc given byMpc(q) =M(q) if p 6= q andMpc(p) = M(p)+ c. Then,Mpc | p ∈ P, c ∈ C∪b is the set of leastmarkings greater thanM. Therefore,M is reachable inN iff N |= F(cov(M)∧

p,c¬cov(Mpc)),and we conclude.

4 A decidable fragment

In the previous section we have proved the undecidability of model checking reset nets andν-PNfor some logics, whose model checking problem is known to be decidable for P/T nets. In thissection we define a restriction ofL (F), thus obtaining a fragment that is less expressive than allthe logics considered here.

Definition 4 Fcov is the fragment ofL (F) in which negation is not allowed.

In this logic we can express bounded repeated coverability. However,Fcov cannot expressproperties like¬cov(M). In particular, the formulaF(cov(M)∧

p∈P¬cov(Mp)) which ex-presses reachability, is not a formula ofFcov. As forL (F), we consider existential interpretation,so that a formula is satisfied if some maximal run satisfies it. We will see that model checkingFcov is decidable both for reset nets and forν-PN. Later, we will consider∀Fcov, the version ofFcov with universal interpretation, and we will prove that model checking∀Fcov is undecidableeven for P/T nets.

Proposition 6 Model checking the fragmentFcov is decidable for reset nets.

Proof. Let N = (P,T,F,R) be a reset net andφ a formula inFcov. We proceed by induction onthe nesting of operatorsF in φ . If φ is a boolean combination of formulae of the formcov(m), itis trivial to decide whetherφ is satisfied because multiset inclusion is decidable.

Let us suppose that we can check each formula with at mostn > 0 nestedF operators. Letφ be a boolean combination of formulae of the formcov(m) and Fϕ , whereϕ has at most

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets10 / 15

Page 205: y V Taller de Programación Funcional (TPF)

n nestedF operators, and let us see that we can decide whether each of those formulaeFϕis satisfied (and hence, whetherφ is satisfied). Using standard techniques, we can writeFϕasF(

i((∧

j cov(mi j ))∧ (∧

k Fϕik))), whereϕik are formulae ofFcov with at mostn−1 nestedoperators. That formula is equivalent to the formula

i F((∧

j cov(mi j ))∧ (∧

k Fϕik)), that is, adisjunction of formulae of the formF(cov(m1)∧ ...∧cov(mq)∧Fϕ1∧ ...∧Fϕr), whereq andrare not simultaneously zero, and eachϕk has at mostn−1 nested operators. Let us distinguishthe following two cases:(a) If q= 0 the formula is of the formF(Fϕ1∧ ...∧Fϕr), which is equivalent toFϕ1∧ ...∧Fϕr .Hence, we can apply the induction hypothesis to eachFϕk and we are done.(b) If q > 0, we modifyN, thus obtainingN′, by adding transitionst1, ..., tq, tq+1 and placesp0, p1, ..., pq. We addp0 as precondition/postcondition of every transition inN. Moreover,timoves a token frompi−1 to pi , providedmi is covered. Finally,tq+1 can be fired only one time(for which we add a new place with a single token initially, as precondition oftq+1), setting againa token inp0, and havingpq as precondition and postcondition. This construction is representedin Fig.4, for q= 2. Then,N′ behaves asN, but when everymi can be covered, it can sequentiallyfire t1, ..., tq, tq+1. Hence, everymi can be simultaneously covered inN iff pq can be covered inN′. We consider the following two sub-cases:(b.1) If r = 0 then the formula is of the formF(cov(m1)∧ ...∧cov(mq)) and hence equivalent toFcov(pq), which expresses a coverability problem, so that it can be decided.(b.2) For any formulaϕ , we defineϕ ′ as follows:

• If ϕ = cov(m) thenϕ ′ = cov(m+pq).

• If ϕ = ϕ1∧ϕ2 thenϕ ′ = ϕ ′1∧ϕ ′

2. Analogously, ifϕ = ϕ1∨ϕ2 thenϕ ′ = ϕ ′1∨ϕ ′

2.

• If ϕ = Fϕ1 thenϕ ′ = Fϕ ′1.

Then,F(cov(m1)∧ . . .∧cov(mq)∧Fϕ1∧ . . .∧Fϕr) holds inN iff F(Fϕ ′1∧ . . .∧Fϕ ′

r) holds inN′. Notice that the number of nestedF operators is the same forϕk andϕ ′

k. Then, by (a) we aredone.

The proof of the same result forν-PNs is analogous to the previous one.4

Proposition 7 Model checkingFcov is decidable forν-PN.

Since in particularFcov allows us to express coverability, which has a non primitive recursivecomplexity for reset nets [22] and forν-PN [21], we have the following:

Proposition 8 The complexity of model checkingFcov is non primitive recursive for reset netsand forν-PN.

To conclude, let us see that the version ofFcov with universal interpretation, that we denoteby ∀Fcov, is undecidable even for P/T nets. Intuitively, formulae in∀Fcov are global properties

4 Actually, the same is true for any model that belongs to the class of Well Structured Transitions Systems, with fairlyminor conditions.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets11 / 15

Page 206: y V Taller de Programación Funcional (TPF)

of some trace, or equivalently, eventuality properties of every trace. For instance,Fcov(M)expresses that every run eventually coversM.

We reduce control-state reachability for Two Counter Machines, which is undecidable [15]. ATwo Counter Machine(TCM for short) is a tupleC= (Q,c1,c2, Ins,q0), whereQ is a finite setof control states,c1 andc2 are the two counters,Ins is a set of instructions andq0 ∈Q is the initialstate. An instruction can be of the following three forms:Inc(p, i,q), Dec(p, i,q) or Zero(p, i,q),wherep,q∈ Q andi ∈ 1,2, for the increasing of the counterci , the decreasing ofci , or checkfor zero ofci . A configuration ofC is given by a tuple〈q,c1 = n1,c2 = n2〉, whereq∈ Q is thecurrent state, andn1,n2 ∈ N are the current values of the counters. The initial configuration is〈q0,c1 = 0,c2 = 0〉.

In a configuration〈p,c1 = n1,c2 = n2〉, we may executeInc(p, i,q) ∈ Ins, reaching〈q,c1 =n′1,c2 = n′2〉, wheren′i = ni + 1 andn′3−i = n3−i . If ni > 0 we may executeDec(p, i,q) ∈ Ins,reaching〈q,c1 = n′1,c2 = n′2〉, wheren′i = ni − 1 andn′3−i = n3−i . Finally, if ni = 0, we canexecuteZero(p, i,q) ∈ Ins, reaching〈q,c1 = n1,c2 = n2〉. The control-state reachability problemconsists in deciding, givenq ∈ Q, whether a configuration of the form〈q,c1 = n1,c2 = n2〉 isreachable. It is well-known that this is an undecidable problem [15].

We consider only deterministic TCM, that is, TCM such that at each reachable configura-tion there is at most one instruction that can be executed. Moreover, withoutloss of generalitywe assume that ifZero(p, i,q) ∈ Ins then there is no other instruction of the formInc(p′, j,q),Dec(p′, j,q) or Zero(p′, j,q) in Ins, that is,q can only be reached by that instruction (†). In-deed, for each instructionI = Zero(p, i,q) ∈ Ins we can add two statesq1,q2, and replaceI byZero(p, i,q1), Inc(q1, i,q2), Dec(q2, i,q).5 The control-state reachability problem for determin-istic TCM is still undecidable.

Proposition 9 Model checking∀Fcov is undecidable for P/T nets.

Proof. We reduce the control-state reachability problem for deterministic TCM to the modelchecking problem of a formula in∀Fcov. Let C = (Q,c1,c2, Ins,q0) be a deterministic TCMand pend ∈ Q. We use the standard simulation of a TCM by means of a P/T net. We defineN = (Q∪c1,c2, Ins,F), where:

• F(p, Inc(p, i,q)) = 1, F(Inc(p, i,q),q) = 1, and

F(Inc(p, i,q),ci) = 1 (a token is moved fromp to q, and a token is added toci).

• F(p,Dec(p, i,q)) = 1, F(Dec(p, i,q),q) = 1, andF(ci ,Dec(p, i,q)) = 1 (a token is movedfrom p to q, and a token is removed fromci).

• F(p,Zero(p, i,q)) = 1 andF(Zero(p, i,q),q) = 1 (a token is moved fromp to q).

Moreover,F(n,m) = 0 elsewhere, and the initial marking ofN is q0. In N, the number oftokens inci represent the value of the counterci in C. Increasing and decreasing transitions aresimulated faithfully. However, the simulation of a transitionZero(p, i,q) can “cheat”, wheneverit is fired with tokens inci . In that case, notice that the markingci ,q can be covered. Moreover,

5 If we allow instructions that do not modify the counter then it is enough to adda single stateq1 and an instructionchanging the state fromq1 to q.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets12 / 15

Page 207: y V Taller de Programación Funcional (TPF)

P/T Reset ν-PN

LTL - [9] - -LTLf + [9] - [3] -

L (GF) + [13] - -L (F) + [12] - -

Fcov + + +∀Fcov - - -

Table 1: Summary of results

becauseq cannot be reached using a different instruction (requirement (†) above), we know thatif such marking is covered then the current simulation has cheated.

We considerϕ =F(cov(pend)∨∨

m∈J cov(m)), whereJ= ci ,q |Zero(p, i,q)∈ Ins. Noticethat all the cheating runs satisfyϕ . We prove thatpend can be reached inC if and only if N |= ϕ .For the if part, ifC reachespend then the non-cheating run ofN eventually coverspend, so thatit satisfiesϕ . Since cheating runs always satisfyϕ , every run ofN satisfiesϕ . Conversely, ifCdoes not reachpend then the non-cheating run ofN does not satisfyϕ .

5 Conclusions and future work

Table1 summarizes the results on model checking P/T nets, reset nets andν-PNs. By “+” (resp.-) we denote that model checking the considered logic is decidable (resp. undecidable). If thereferences of the results are not given, then the result is either new orfollows directly from otherresults of the table. In particular, in this work we have proved the undecidability of the fragmentsLTLf , L (GF) andL (F) for reset nets andν-PN.

We have definedFcov, a very simple restriction of LTL that does not allow negations, forwhich model checking reset nets andν-PN is decidable. Actually, we claim this is the case forany model in the class of Well Structured Transition Systems [10] under fairly minor conditions,since model checking can be reduced to a finite number of coverability problems. Moreover, wehave proved that if we require that every run satisfies a formula, then even for the simple case ofFcov and P/T nets, the corresponding model checking problem is undecidable.

Further study, in order to define more expressive logics for which the model checking problemis decidable, is needed. A possible direction in such study could be the definition of logics withatomic predicates that are more specific of the particular model. Such directionlinks with the socalled Yen’s logics for P/T nets. In the case ofν-PN, the corresponding logic should be able toexpress properties about the names in the marking.

Language theory was used to prove the difference of expressiveness between reset nets andν-PNs in [20]. In this sense, it would certainly be interesting to find a logic which distinguishesbetween reset nets andν-PNs.

Finally, we have proved that the complexity of model checkingFcov is non primitive recursivefor reset nets and forν-PN. However, it would be interesting to perform a finer complexityanalysis.

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets13 / 15

Page 208: y V Taller de Programación Funcional (TPF)

Bibliography

[1] M. Ben-Ari, Z. Manna and A. Pnueli.“The Temporal Logic of Branching Time”. ActaInformatica 20, 207-226(1983).

[2] R. Bonnet.“Theory of Well-Structured Transition Systems and Extended Vector-AdditionSystems”. These de doctorat, Laboratoire Specification et Verification, ENS Cachan,France (2013).

[3] A. Bouajjani and R. Mayr.“Model Checking Lossy Vector Addition Systems”. Interna-tional Symposium on Theoretical Aspects of Computer Science, LNCS vol. 1563, 323-333(1999).

[4] E. M. Clarke, O. Grumberg, and D. A. Peled.“Model Checking”. MIT Press Cam-bridge(1999).

[5] G. Decker, M. Weske.“Instance Isolation Analysis for Service-Oriented Architectures”.Proceedings of the 2008 IEEE International Conference on ServicesComputing, 1, 249-256 (2008).

[6] J. Desel and W. Reisig.Place/transition petri nets.Lectures on Petri Nets I: Basic Models,LNCS vol. 1491, pp.122–173. Springer, 1998.

[7] C. Dufourd, A. Finkel, and Ph. Schnoebelen.“Reset Nets Between Decidability and Unde-cidability” . International Colloquium on Automata Languages and Programming, LNCSvol. 1443, 103-115 (1998).

[8] J. Esparza and M. Nielsen.“Decidability Issues for Petri Nets”. BRICS Report Series,RS-94-8 (1994).

[9] J. Esparza.“On the decidability of model checking for severalµ-calculi and Petri nets”.Colloquium on Trees in Algebra and Programming, LNCS vol. 787, 115-129(1994).

[10] A.Finkel, and P.Schnoebelen.Well-Structured Transition Systems Everywhere!TheoreticalComputer Science 256(1-2):63-92 (2001).

[11] K. van Hee, A. Serebrenik, N. Sidorova and M. Voorhoeve.Soundness of Resource-Constrained Workflow Nets.Applications and Theory of Petri Nets, LNCS vol. 3536, 250-267 (2005)

[12] R. Howell, L. Rosier and H. Yen.“A taxonomy of fairness and temporal logic problems forPetri nets”. Theoretical Computer Science 82, 341-372 (1991).

[13] P. Jancar. “Decidability of a Temporal Logic Problem for Petri Nets.”. Theoretical Com-puter Science 74, 71-93 (1990).

[14] C. Lakos, S. Christensen.A General Systematic Approach to Arc Extensions for ColouredPetri Nets.Applications and Theory of Petri Nets. LNCS vol. 815, pp. 338-357 (1994)

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets14 / 15

Page 209: y V Taller de Programación Funcional (TPF)

[15] M. L. Minsky. “Computation: Finite and Infinite Machines”Prentice-Hall (1967).

[16] OASIS Web Services Business Process Execution Language Version 2.0. OASIS Standard(2007).http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf

[17] A. Pnueli.“The Temporal Semantics of Concurrent Programs”Theoretical Computer Sci-ence, 13, 1-20(1981).

[18] Klaus Reinhardt.“Reachability in Petri Nets with Inhibitor Arcs”Electr. Notes Theor.Comput. Sci. 223: 239-264 (2008).

[19] F. Rosa-Velardo and D. de Frutos-Escrig. Name creation vs. replication in Petri Net sys-tems.Fundamenta Informaticae88(3). IOS Press (2008) 329-356.

[20] F. Rosa-Velardo and G. Delzanno.“Language-based Comparison of Nets with Black To-kens, Pure Names and Ordered Data.”. International Conference on Language and Au-tomata Theory and Applications, LNCS vol. 6031, pp. 524-535. Springer(2010)

[21] F. Rosa-Velardo and D. de Frutos-Escrig.Decidability and Complexity of Petri Nets withUnordered Data.Theoretical Computer Science 412(34): 4439-4451 (2011)

[22] Ph. Schnoebelen.“Revisiting Ackermann-Hardness for Lossy Counter Machines and ResetPetri Nets”. Theoretical Computer Science, LNCS vol. 6281, pp. 616,628 (2010).

On the decidability of model checking LTL fragments in monotonic extensions of Petri nets15 / 15

Page 210: y V Taller de Programación Funcional (TPF)

Verifying Hybrid Systems with Explicit Model Checkers

Laura Panizo1, Marıa-del-Mar Gallardo2

1 [email protected] [email protected]

University of Malaga, Malaga

Abstract: In previous papers, we have studied how to finitely deal with hybrid sys-tems to enable their analysis with standard explicit model checkers such as SPIN

and JPF. We have concentrated on those systems that are representable by means ofthe so-called initialized rectangular hybrid automata. From this, we have defined ageneral semantics-based framework where hybrid systems are seen as discrete sys-tems, the variables of which represent rectangular polyhedra. The transformation ofhybrid systems into their corresponding discrete systems is independent of the par-ticular language with which the hybrid system is described and the input language ofthe model checker under consideration. In this paper, we define this general frame-work and study its correctness. In addition, we prove that even though the state spacedefined by the hybrid system is non-enumerable, the standard explicit model check-ing algorithms are guaranteed to finish when analyzing the finite representation ofthe hybrid system proposed here.

Keywords: Hybrid systems, initialized rectangular hybrid automata, model check-ing

1 Introduction

A hybrid system is a dynamical system with continuous and discrete variables. Hybrid sys-tems are useful for the design and analysis of embedded control systems. They have beenused to verify the correct behavior of many industrial applications, such as automotive con-trollers [BBB+00, LPN11], avionic systems [PC09] or manufacturing systems [Feh99]. Hybridsystems present continuous and discrete behaviors, which are closely related. On the one hand,continuous variables represent continuous magnitudes that evolve over time following ordinarydifferential equations (ODE). On the other hand, there are discrete states, called locations, thatdefine the different control modes of the system. Each location allows the continuous variablesto evolve with different dynamics. In addition, when a transition between two locations occurs,the value of the continuous variables may be updated.

In the context of computer science, it is common to use hybrid automata [Hen96] to representhybrid systems. Hybrid automata extend the notion of automata by adding continuous variablesto discrete states. The continuous variables may continuously evolve following an ODE. Modelchecking is not decidable for general hybrid automata. However, there are some subclasses ofhybrid systems that can be abstracted in a way that preserves some kinds of properties [AHLP00].These subclasses are usually obtained by restricting the flows of the continuous variables orrestricting the jumps. Initialized Rectangular Hybrid automata [Kop96, HKPV98] (IRHA) are a

Verifying Hybrid Systems with Explicit Model Checkers 1 / 15

Page 211: y V Taller de Programación Funcional (TPF)

Figure 1: Architecture of the approachsubclass of hybrid automata that define the evolution of continuous variables by Rn-intervals, andthat force the initialization, in discrete transitions, of those continuous variables, the continuousdynamics of which change. The LTL model checking problem is decidable for IHRA. Theyconstitute the maximal class of hybrid automata with a model checking decidable problem. Inaddition, they are a very interesting class because their dynamics can naturally approximate moregeneral dynamics [HHW98].

In previous work [GP10, PG12a, PG12b], we proposed a methodology to extend explicit dis-crete model checkers to analyze IRHA in a non-intrusive way (see Figure 1). Our methodology isbased on the discretization of the continuous state space of IRHA using convex polyhedra to ab-stract the continuous behavior. The abstraction is transparent for the finite-state model checker,which only observes the discretized version of the system. In this way, the finite-state modelchecker can analyze hybrid systems without being modified. Finally, using the methodology, wedeveloped two prototypes that extended SPIN and JPF for hybrid system analysis.

In this paper, we present the formalization of the aforementioned methodology. Then, westudy the effects of analyzing a discretized version of the hybrid system against a set of proper-ties. Finally, we formally prove that the analysis always terminates for IRHA. Here, we assumethat the analysis is carried out by an on-the-fly model checking algorithm, such as the one imple-mented by SPIN.

The paper is organized as follows. Section 2 introduces hybrid systems and some basic defi-nitions. Section 3 presents the formalization of how our methodology discretizes the state spaceby means of convex polyhedra. Then, Section 4 provides some results regarding preservation ofproperties. In Section 5 we prove that the analysis with traditional model checking algorithmsalways terminates for IRHA. Finally, Section 6 presents some conclusions and future work.

2 Preliminaries

This section introduces some definitions that constitute the basis of hybrid system theory. First,we present the hybrid automaton, an extension of finite-state automata that includes continuousvariables that can evolve following ODEs. Then, the initialized rectangular hybrid automaton isdefined. This subclass of hybrid automaton constrains the dynamics to rectangular sets.

Definition 1 (Hybrid automaton) A hybrid automaton H is a tuple 〈Loc,T,Σ,X , Init, Inv,Flow,Jump〉 where:

• Loc is a finite set of discrete states (locations) of the automaton.

Verifying Hybrid Systems with Explicit Model Checkers 2 / 15

Page 212: y V Taller de Programación Funcional (TPF)

• T ⊆ Loc×Loc is a finite set of transitions.

• Σ is the set of event names, equipped with a labeling function lab : T → Σ.

• X = x1, · · · ,xn is a finite set of real-valued variables. The set X = x1, · · · , xn representsthe first derivative of the elements of X during the continuous evolution in a location. Inaddition, the set X ′ = x′1, · · · ,x′n corresponds to updates of variables when a transitiont ∈ T takes place.

• Init, Inv and Flow are functions that assign predicates to each location. Thus, Init(loc)defines the possible initial values of the variables in X . Inv(loc) gives the conditions onvariables in X that must be true while the system stays at location loc. Flow(loc) is apredicate over X ∪ X that defines the evolution of the variables in loc.

• The function Jump assigns each transition t ∈ T to the guards that enable the transitionand to the updates of variables before transiting to the new location.

Let [X → R] be the set of all maps from X to R. If p is a predicate over X , then [[p]] denotesall functions v ∈ [X →R] that satisfy p. Similarly, we define the meaning of a predicate over X ′,X ∪X ′ or X ∪ X . Finally, the same notion may be extended to sets of predicates such as Init, Invor Jump.

A hybrid state of H is a pair (loc,v), where loc ∈ Loc is a location of the automaton, andv ∈ [X → R] is a valuation of variables such that v ∈ [[Inv(loc)]]. A hybrid automaton behaveslike a timed transition system. Intuitively, given loc, loc′ ∈ Loc, two valuations v,v′ ∈ [X → R],and δ ∈R≥0, (loc,v)→δ (loc,v′) means that the continuous variables evolve from v into v′ in δ

time units, and (loc,v) σ→d (loc′,v′) means that the hybrid state (loc,v) evolves instantaneouslyto (loc′,v′).

Definition 2 (Initialized Rectangular Hybrid Automata) A rectangular hybrid automaton is ahybrid automaton H that satisfies the following constraints:

• For every location loc ∈ Loc, the set Init(loc) and Inv(loc) are rectangular sets. In addi-tion, Flow(loc) restricts the evolution over time of the continuous variables to a rectangu-lar set.

• For every transition t = (loc, loc′)∈ T the guard is a rectangular set, and the variables maybe non-deterministically set to a value from a rectangular set.

Let update(t) = xi1 , · · · ,xik denote the set of variables of X that are updated in t. A rectangularautomaton is initialized when, for every transition t ∈ T , if xi 6∈ update(t), then Flow(loc) =Flow(loc′) for variable xi.

In other words, an initialized rectangular hybrid automaton satisfies that if the flow of vari-able xi changes after a transition, its value has to be reinitialized non-deterministically to avalue within a fixed interval. This characteristic ensures the decidability of LTL model check-ing [HKPV98].

Now, we continue with the definition of trajectory. This definition is given for general hybridautomata, but also applies to IRHA.

Verifying Hybrid Systems with Explicit Model Checkers 3 / 15

Page 213: y V Taller de Programación Funcional (TPF)

Definition 3 (Trajectories) Given a hybrid automaton H = 〈Loc,T,Σ,X , Init, Inv,Flow,Jump〉,transitions of H are either:

• Discrete transitions: given t = (loc, loc′) ∈ T and lab(t) = σ , (loc,v) σ→d (loc′,v′), iffv,v′ ∈ [X → R], and (v,v′) ∈ [[Jump(t)]]. To simplify the notation, we drop the label σ

from the discrete transitions and simply use→d .

• Continuous transitions: for each δ ∈ R≥0, (loc,v)→δ (loc,v′) iff there exists a differen-tiable function fv : [0,δ ]→ Rn, fv : [0,δ ]→ Rn being its first derivative, such that:

– fv(0) = v, fv(δ ) = v′.

– ∀r ∈ [0,δ ], fv(r) ∈ [[Inv(loc)]] and ( fv(r), fv(r)) ∈ [[Flow(loc)]].

Thus, a trajectory is a (possible infinite) sequence of hybrid states such as (loc0,v0)→λ0 · · ·(loc j,v j)→λ j · · · , where vi ∈ [[Inv(loci)]], i = 0,1 · · · , λi ∈ R∪d and v0 ∈ Init(loc0).

Observe that in this definition, the states store a unique real value for each continuous variable,which makes the definition of trajectory very intuitive. However, the resulting state space isnon-enumerable and the analysis of these trajectories can quickly lead to state space explosionproblems.

The next definition describes the operational semantics of hybrid automaton as the set of allpossible trajectories.

Definition 4 (Operational Semantics) Given an automaton H, the operational semantics of His O(H) = (loc0,v0)→λ0 · · · |loc0 ∈ Loc,v0 ∈ [[Init(loc0)]], where i≥ 0, λi ∈ R≥0∪d.

3 Discretization of the hybrid system

This section formally presents how a hybrid automaton can be discretized by means of ab-straction. Evidently, in the literature, there are other approaches which deal with the problemof discretizing the state space of hybrid automata (see [HKPV98, HK99, AHLP00, Ho95]).However, the formalization presented here completely fits in with our methodology and theprototypes implemented in previous work. It is worth noting that the class of hybrid sys-tem to be analyzed and type of abstraction carried out are not relevant in the discussion thatfollows. However, to simplify the presentation, it is assumed that states are abstracted usingconvex polyhedra. In addition, we assume that there is a unique underlying hybrid automatonH = 〈Loc,T,Σ,X , Init, Inv,Flow,Jump〉 (that could be the product of different automata [Fre05])with n continuous variables X = x1, · · · ,xn.

Our goal is to construct a discrete abstraction of the original automaton that can be analyzedby finite-state model checking tools. First, we define two abstract relations→α

δand→α

d , which

correctly simulate the two original transition relations→δ and→d , and then a new relation−→α

dis built. This relation generates discrete execution paths which are correct simulations of theoriginal trajectories.

Verifying Hybrid Systems with Explicit Model Checkers 4 / 15

Page 214: y V Taller de Programación Funcional (TPF)

Definition 5 (Abstract states) An abstract state is a pair 〈loc,P〉 such that loc ∈ Loc and P is anon-empty convex polyhedron in Rn which satisfies the invariant Inv(loc), that is, P ⊆ Inv(loc).The abstract state 〈loc,P〉 is an abstraction of a hybrid state (loc,v) iff v ∈ P. The notation(loc,v) ∈ 〈loc,P〉 denotes that 〈loc,P〉 is an abstraction of (loc,v).

The abstraction relation between hybrid and abstract states will permit the simulation of thetrajectories in O(H) allowed by the hybrid automaton H with sequences of abstract states. Giventransition relations→δ and→d of Definition 3, we assume that there are two abstract transitionrelations→α

δ,→α

d⊆ (Loc,Pol)×(Loc,Pol), where Pol is the set of all possible convex polyhedrain Rn, that relate abstract states and constitute a simulation of→δ and→d in the following way:

1. if (loc,v1)→δ (loc,v2) and 〈loc,P1〉 is an abstraction of (loc,v1), there exists an abstractstate 〈loc,P2〉 such that 〈loc,P1〉 →α

δ〈loc,P2〉, and 〈loc,P2〉 is an abstraction of (loc,v2).

2. if (loc1,v1)→d (loc2,v2) and 〈loc1,P1〉 is an abstraction of (loc1,v1), there exists an ab-stract state 〈loc2,P2〉 such that 〈loc1,P1〉→α

d 〈loc2,P2〉, and 〈loc2,P2〉 is an abstraction of(loc2,v2).

3. Given loc ∈ Loc, ∀v ∈ Init(loc) there exists P ∈ Pol such that (loc,v) ∈ 〈loc,P〉.

Definition 6 (Abstract trajectory) An abstract trajectory is a (possibly infinite) sequence of ab-stract states such as 〈loc0,P0〉→α

λ0〈loc1,P1〉→α

λ1· · · , i≥ 0, λi ∈R≥0∪d and P0⊆ Init(loc0).

Given a hybrid automaton and two abstract relations →α

δ,→α

d that simulate →δ and →d ,Oα(H) denotes the set of all possible abstract trajectories allowed by H, that is, Oα(H) =〈loc0,P0〉 →α

λ0· · · |P0 ⊆ Init(loc0).

Theorem 1 Given tra j = (loc0,v0)→λ0 · · · ∈O(H), there exists an abstract trajectory tra jα =〈loc0,P0〉 →α

λ0· · · ∈ Oα(H) such i≥ 0, (loci,vi) ∈ 〈loci,Pi〉.

Proof. To prove this, it is sufficient to define the initial polyhedron as P0 = Init(loc0), and usethe fact that→α

δ,→α

d simulate→δ and→d , respectively.

Observe that this theorem proves that each trajectory tra j of O(H) is simulated step by stepby an abstract trajectory tra jα of Oα(H) which means that Oα(H) is a correct abstraction ofO(H). In what follows, the simulation relation between tra j and tra jα is written as tra j ∈ tra jα

and, similarly, O(H)⊆Oα(H) denotes the relation between O(H) and Oα(H).Now, the abstract trajectories are transformed into discrete abstract traces. This transformation

will be used to prove the simulation relation between trajectories and discrete abstract traces.First, we define the accumulated (time) successor of a polyhedron, which is later used to define

a new labeled transition relation−→α

d from→α

δand→α

d .

Definition 7 (Accumulated successors) Given an abstract state 〈loc,P〉, the set of all possiblesuccessors of P at loc is defined as Sucac(loc,P) = v ∈ Rn|∃(loc,v0)→δ 0 · · · →δ i−1 (loc,vi),i ≥ 0, v0 ∈ P, and vi = v.

Verifying Hybrid Systems with Explicit Model Checkers 5 / 15

Page 215: y V Taller de Programación Funcional (TPF)

Definition 8 (Discrete abstract transition) Given two abstract states 〈loc,P0〉 and 〈loc′,P′0〉,

and a polyhedron A = Sucac(loc,P0) then 〈loc,P0〉A→α

d 〈loc′,P′0〉 iff there exists a sequence oftransitions 〈loc,P0〉 →α

δ 0 · · · →α

δ i 〈loc,Pi〉 →αd 〈loc′,P′0〉.

Observe that the new relation−→α

d compacts a number of continuous transitions plus a discretetransition into a discrete transition labeled with a polyhedron which contains all the real valuesreached by the continuous variables during the continuous transitions.

Let Oαd (H) be defined as the set of all possible abstract traces which may be constructed by

collapsing the abstract trajectories as described in Definition 8, that is, Oαd (H)= 〈loc0,P0〉

A0

→αd · · ·

| P0 ⊆ Init(loc0).

Theorem 2 Given a trajectory of a hybrid system

tra j = (loc0,v00)→δ 1

0· · · →

δi00(loc0,v

i00 )→d (loc1,v0

1)→δ 11· · ·

there exists a sequence of abstract states

tra jαd = 〈loc0,P0〉

A0

→αd 〈loc1,P1〉

A1

→αd · · ·

such that for all k ≥ 0,Ak = Sucac(lock,Pk) and for all 0≤ l ≤ ik, vlk ∈ Ak.

Proof. The theorem is proved by considering the relation between each trajectory tra j with anabstract trajectory tra jα given by Theorem 1 and the procedure for constructing the discreteabstract trace given in Definition 8.

Theorem 2 establishes that Oαd (H) is a correct discrete abstraction of O(H). The relation

between O(H) and Oαd (H) is denoted as O(H)⊆ Oα

d (H).

3.1 A Running example: a water tank thermostat

To illustrate the behavior of a hybrid automaton, we use the example shown in Figure 2. It con-sists of a water tank thermostat described as a rectangular hybrid automaton. The objective is tomaintain the water within a given range of temperatures using a burner that the thermostat canswitch on or off. The automaton locations model the mode of the burner (On, SwitchOn, Off andSwitchOff ). Observe that SwitchOn and SwitchOff represent the process of switching the burneron or off, which can take up to 5 units of time. The controller has two continuous variables.Variable temp represents the evolution of the water temperature, which evolves at different ratesdepending on the automaton location, and clock c, which is used to measure how much time haselapsed since the last time the burner was switched on or off. Assuming that the burner is initiallyoff, the water temperature is between 30 and 40 degrees, and the clock c is set to 0, an allowed tra-jectory of this automata could be (Off ,(0,35))→δ=1 (Off ,(1,34))→d (SwitchOn,(0,34))→δ=1(SwitchOn,(1,33))→d On,(0,33))→δ=60 On,(60,93)) . . . , but of course there are many more,possibly infinite, trajectories. Thus, the verification of this example may be infeasible usinghybrid states.

Verifying Hybrid Systems with Explicit Model Checkers 6 / 15

Page 216: y V Taller de Programación Funcional (TPF)

Figure 2: Water tank controller

Figure 3: Discrete abstract trajectory computation

We construct an abstract discrete trajectory tra jαd of this system using convex polyhedra to ab-

stract the continuous behavior. Given the initial conditions, shown in Figure 2, we can constructa discrete abstract trajectory

tra jαd = 〈Off ,P0〉

A0

→αd 〈SwitchOn,P1〉

A1

→αd 〈On,P2〉

A2

→αd 〈SwitchOff ,P3〉

A3

→αd 〈Off ,P4〉 · · ·

where polyhedra Pi and Ai are worked out as shown in Figure 3. Note that this kind of abstractdiscrete trajectory represents a set of trajectories, such as the one given in the previous paragraph.In addition, it is worth mentioning that the automaton is non-initialized since variable tempchanges its flow without being reset. This means that the analysis of this system is undecidable.

4 Dealing with Properties

Section 3 describes how a hybrid automaton may be analyzed by transforming its trajectoriesinto discrete execution paths. This transformation is carried out on-the-fly; that is, the abstracttraces are constructed while they are being analyzed.

Verifying Hybrid Systems with Explicit Model Checkers 7 / 15

Page 217: y V Taller de Programación Funcional (TPF)

Now, we present two results concerning the preservation of properties between the abstracttraces analyzed and the trajectories allowed by the initial automaton. These results provide amethodology for interpreting the answers obtained when the abstract traces are analyzed bymodel checking. Now, we assume that the properties are specified using the LTL logic. Themain reason is that, as proved by Alur et al. [AHLP00] and Henzinger et al. [HMR05], theanalysis of LTL properties is decidable for IRHA, whenever the atomic propositions refer toautomaton location or comprise a rectangular set. In addition, LTL is the specification languageof SPIN, which is the underlying model checker of one of our prototypes. In fact, in Section 5,we prove that an algorithm like that of SPIN for analyzing LTL properties, always finishes whenanalyzing IRHA. In this section, it is assumed that the syntax and semantics of LTL logic areknown (for instance Moller [Mol96]).

4.1 Preservation of Properties.

In order to analyze properties of the trajectories in O(H), we analyze the properties of the abstracttraces in Oα

d (H). However, abstraction implies loss of information, which means that satisfactionof properties on Oα

d (H) cannot always be transferred to O(H). The rest of the section is devotedto discussing this aspect. First, the set of non-blocking trajectories is defined.

Definition 9 (Blocked trajectory) Given a trajectory tra j = (loc0,v0)→λ0 (loc1,v1)→λ1 · · · ,with λi ∈ R≥0 ∪ d, it is said that tra j is a blocked trajectory if there exists a state in thesequence such that (loci,vi) 6→λ ,∀λ ∈ R≥0∪d. Abstract blocked traces may be defined simi-larly. Onb(H)⊆O(H) denotes the subset of non-blocking trajectories allowed by H.

Assume that Prop is a set of atomic propositions to be evaluated on hybrid states of automatonH. Thus, given a state (loc,v), and a proposition p ∈ Prop, (loc,v) |= p denotes that (loc,v)satisfies p. Operator |= can be extended to (non-blocking) trajectories and LTL formulae asusual. Thus, given a trajectory tra j ∈O(H) (or tra j ∈Onb(H)), and an LTL formula f , tra j |= fdenotes that tra j satisfies f (with the semantics of logic LTL). Similarly, O(H) |= ∀ f denotesthat ∀tra j ∈ O(H).tra j |= f , and O(H) |= ∃ f iff ∃tra j ∈ O(H).tra j |= f . Similar definitionscan be written with Onb(H).

Now consider an abstract state 〈loc,P〉. There are two different ways of defining when 〈loc,P〉satisfies a proposition p:

1. It is said that 〈loc,P〉 under-satisfies p, and denotes this with 〈loc,P〉 |=u p iff ∀v ∈Sucac(loc,P), (loc,v) |= p.

2. It is said that 〈loc,P〉 over-satisfies p, and denotes this with 〈loc,P〉 |=o p iff ∃v∈ Sucac(loc,P),(loc,v) |= p.

Thus, 〈loc,P〉 |=u p means that all hybrid states reachable from P at loc, that is Sucac(loc,P),satisfy p. Similarly, 〈loc,P〉 |=o p means that at least one hybrid state reachable from P at locsatisfies p. Clearly, 〈loc,P〉 |=u p⇒ 〈loc,P〉 |=o p.

Operators |=u and |=o can be extended to abstract traces and LTL formulae. Given an abstracttrace tra jα

d ∈ Oαd (H) and an LTL formula f , tra jα

d |=u f and tra jαd |=o f respectively denote

Verifying Hybrid Systems with Explicit Model Checkers 8 / 15

Page 218: y V Taller de Programación Funcional (TPF)

that tra jαd under-satisfies or over-satisfies f . Similarly, Oα

d (H) |=u ∀ f denotes that ∀tra jαd ∈

Oαd (H), tra jα

d |=u f , and Oαd (H) |=o ∃ f denotes that ∃tra jα

d ∈ Oαd (H), tra jα

d |=o f .The following proposition, proved by Gallardo et al. [GMP02], establishes the results of prop-

erty preservation between trajectories and abstract traces.

Proposition 1 Given a hybrid automaton H, and an LTL formula f :

1. if Oαd (H) |=u ∀ f then Onb(H) |= ∀ f

2. if Oαd (H) 6|=o ∃ f then Onb(H) 6|= ∃ f

In other words, abstraction is useful to prove universal formulae (if they are under-approximated)or to refute existential properties (if they are over-approximated). Otherwise, the counterexam-ple obtained must be analyzed to check whether or not it corresponds to a real behavior of theautomaton.

Observe that in Proposition 1, all the abstract trajectories allowed by automaton H are ana-lyzed, but the conclusion only applies to the non-blocking trajectories (Onb(H)). This is becauseabstraction may discard some blocking trajectories allowed by the original automaton in whichthe formula f does not hold (case 1) or does hold (case 2). Deadlock is explicitly studied in thefollowing section.

There are some formulae for which under and over satisfaction of properties coincide. Forinstance, assume that p is an atomic proposition describing property “automaton is at locationloc”. It is trivial to prove that 〈loc,P〉 |=u p ⇐⇒ 〈loc,P〉 |=o p, which means that properties,which only contain atomic propositions like p, may be proved or refuted using both preservationresults in Proposition 1.

For instance, in the water tank thermostat, we can check LTL properties such as

(90≤ temp≤ 100→ ♦loc = SwitchOff )

which states that when the temp is between 90 and 100 degrees, we will always eventually reachthe location SwitchOff . If the property is satisfied over the abstract discrete trajectory, then wecan affirm that it is also satisfied over the non-blocking real trajectories.

4.2 Analyzing Deadlock.

Now, we present the preservation results for deadlock analysis. Assume that the abstract tran-sition relations→α

δand→α

d are not only a simulation of the original→δ and→d , but are alsocomplete in the following sense:

1. if 〈loc,P1〉→α

δ〈loc,P2〉 and abstract state (loc,v2)∈ 〈loc,P2〉, there exists a state (loc,v1)

such that (loc,v1)→δ (loc,v2), and (loc,v1) ∈ 〈loc,P1〉.

2. if 〈loc1,P1〉 →αd 〈loc2,P2〉 and abstract state (loc2,v2) ∈ 〈loc2,P2〉, there exists a state

(loc1,v1) such that (loc1,v1)→d (loc2,v2), and (loc1,v1) ∈ 〈loc1,P1〉.

Verifying Hybrid Systems with Explicit Model Checkers 9 / 15

Page 219: y V Taller de Programación Funcional (TPF)

Proposition 2 If relations →α

δand →α

d are complete wrt →δ and →d , then relation−→α

d is

complete wrt →α

δand →α

d in the following sense: if 〈loc,P〉A→α

d 〈loc′,P′〉, and (loc′,v′) ∈〈loc′,P′〉, then there exists (loc,v1)→δ 1 · · ·→δ k−1 (loc,vk)→d (loc′,v′), and (loc,v1)∈ 〈loc,P〉.

The following proposition proves that abstraction Oαd (H) may be also used to prove a property

related to deadlock, and to directly transfer the counterexamples returned by the applicationof Proposition 1 to the original hybrid system O(H). To prove the Proposition, an additionalcondition on abstract traces of Oα

d (H) is needed, which is formulated as follows. Given a trace

tra jαd = 〈loc0,P0〉

A0

→αd 〈loc1,P1〉

A1

→αd · · · ∈ Oα

d (H), it is said that tra jαd has a cycle iff there are

two abstract states 〈loci,Pi〉 and 〈loc j,P j〉 such that i < j, loci = loc j and P j ⊆ Pi.The existence of cycles in all abstract traces produced by the polyhedra abstraction will be

proved in Section 5. In fact, these cycles are the key to proving the termination of the modelchecking algorithm on IRHA.

Proposition 3 Let H be an IRHA, and assume that O(H) and Oαd (H) are, respectively, the set

of trajectories and abstract traces allowed by the original transition relations→δ and→d , and

by−→α

d . In addition, it is supposed that the abstract relation−→α

d is a complete simulation of→δ

and→d as defined above, and that all traces in Oαd (H) have a cycle. Then,

1. if there exists tra jαd ∈ Oα

d (H), which does not block, then there exists some trajectorytra j ∈ O(H) which also does not block.

2. Given an LTL property, if there is tra jαd ∈Oα

d (H) such that tra jαd 6|=u f , then Onb(H) 6|= ∀ f .

3. Given an LTL property, if there is tra jαd ∈Oα

d (H) such that tra jαd |=o f , then Onb(H) |= ∃ f .

5 Analysis of discretized hybrid systems

The goal of this section is to justify that the traditional double nested model checking algorithm,implemented, for instance, by SPIN, always terminates when analyzing IRHA. Note that thefollowing results are not valid for general rectangular hybrid automata models, since the variablesare always updated when their flow changes after a discrete transition.

To prove termination, we first should recall how the traditional double nested search algorithmanalyzes the infinite traces produced by the execution of a model. Assume that t = s0→ s1→ ···is one of these paths. The algorithm finishes the analysis of t when the same state is visitedtwice, that is, when a state s j is found such that s j = si and i < j. In this case, it considers thata cycle, si→ ·· · → s j, which may repeat itself forever, has been found, and backtracks trying tofind a different behavior through other execution branches. Obviously, this algorithm is certainto terminate when the system has a finite number of states. However, it is not so easy to provetermination when dealing with polyhedra instead of discrete variables. Assuming that the IRHA

Verifying Hybrid Systems with Explicit Model Checkers 10 / 15

Page 220: y V Taller de Programación Funcional (TPF)

model only has continuous variables, the traces generated during its execution are of the form

tra jαd = 〈loc0,P0〉

A0

→αd 〈loc1,P1〉

A1

→αd · · · , where loci is an automaton location, Pi is the initial

polyhedron at loci, and Ai is the accumulated polyhedron obtained by the continuous transitionsat loci. Thus, proving the termination of the model checking algorithm on IRHA models is equalto proving that each trace like tra jα

d has a cycle or, equivalently, that it has a repeated state.However, in this case, the meaning of repeated states is a bit more relaxed than usual. In thecontext of hybrid systems, the state 〈loc j,P j〉 is considered already visited when there exists aprevious state 〈loci,Pi〉 such that loci = loc j and P j ⊆ Pi. It is clear that if all values in P j are inPi, they have already been analyzed, and the model checking algorithm may continue the searchthrough a different path.

Thus the purpose of this section is to prove that each path such as tra jαd = 〈loc0,P0〉

A0

→αd

〈loc1,P1〉A1

→αd · · · has at least one repeated state in the aforementioned sense.

Recall that in Definition 7, Sucac(loc,P) denotes the set of all points reachable from anyvalue of P through continuous transitions. Moreover, recall that, by definition, all points inSucac(loc,P) satisfy invariant Inv(loc).

Function Sucac makes it explicit that the accumulated polyhedron calculated in a given location

loc only depends on the initial polyhedron P which reaches loc. Thus if tra jαd = 〈loc0,P0〉

A0

→αd

〈loc1,P1〉A1

→αd · · · is a discrete trajectory, then ∀i≥ 0, Ai = Sucac(loci,Pi).

Function Sucac has two immediate properties.

Proposition 4 Given a location loc,

1. Sucac(loc,−) is a monotonically increasing function.

2. Sucac(loc,P) = Sucac(loc,Sucac(loc,P))

The next definition characterizes the function updatet .

Definition 10 (Function updatet) Assume that automaton H has n continuous variables X =x1, · · · ,xn. Suppose that a given transition t updates a number 0≤ k≤ n of variables update(t)=xi1 , · · · ,xik⊆X with new real intervals. For each xi j ∈ update(t), Ri j denotes the correspondingnew interval. Now, given a polyhedron P ∈ Rn, the function updatet(P) is defined as

updatet(P) = (r′1, · · · ,r′n)|∃(r1, · · · ,rn) ∈ P∧ ((xi ∈ update(t)∧ r′i ∈ Ri)∨ (xi 6∈ update(t)∧ r′i = ri))

that is, the i-component of each point of P is updated with a value of Ri, if xi ∈ var(t). Sinceeach Ri is a real-valued interval, updatet(P) is also a polyhedron.

Observe that given a transition t = (loc, loc′), from state 〈loc,P〉 to state 〈loc′,P′〉, then poly-hedron P′ is completely determined by the guard and update functions of t, the invariant of thetarget location, and the source polyhedron P as follows:

P′ = updatet(Sucac(loc,P)∩guard(t))∩ Inv(loc′)

The next proposition proves that the reachable polyhedra in a subsequence of a given executiontrace, cannot grow if no continuous variable is reset.

Verifying Hybrid Systems with Explicit Model Checkers 11 / 15

Page 221: y V Taller de Programación Funcional (TPF)

Proposition 5 Assume that the hybrid automaton H under analysis only has continuous vari-

ables which are never reset. Let tra jαd = 〈loc0,P0〉

A0

→αd 〈loc1,P1〉

A1

→αd · · · be an infinite trace

allowed by H. If ti = (loci, loci+1) denotes a discrete transition from location loci to loci+1, then∀i≥ 0, k > 1,

Pi+k ⊆ Sucac(loci+k−1,Sucac(loci,Pi))∩guard(ti+k−1)∩ Inv(loci+k) (1)

Proof. The proof of this proposition can be found in [GP13].

From now on, in order to simplify the presentation, trajectories such as 〈loc0,P0〉A0

→αd · · · are

represented as sequences of transitions seq = t0 · t1 . . . , each ti being the transition (loci, loci+1).The next definition characterizes a type of subsequence useful for proving termination. They

are called n-cycles.

Definition 11 Let Sn = s1, · · · ,sn be a finite set of symbols. A finite sequence seqn of symbolsof Sn is said to have a repeated n-cycle, if either

1. there exist two equal subsequences in seq containing all the symbols in Sn, or

2. seq contains two consecutive equal sequences (not necessarily with all the symbols of Sn)

Given Sn a finite set of n symbols, denote with Seq(Sn) the set of finite sequences of elementsof Sn without repeated n-cycles.

Given Sn a set of symbols, let |Sn| denotes the number of elements of S. The following re-sults are used to prove Theorem 4. The next proposition considers sequences of transitions assequences of generic symbols.

Proposition 6 For all n≥ 1, if Sn is a set of n symbols, Seq(Sn) is finite.

Proof. The proof of this proposition is in [GP13].

Corollary 1 If there exists an infinite sequence seq of symbols of Sn then seq contains repeatedn-cycles.

Proof. By contradiction, assume that seq = w1 ·w2· is an infinite sequence of symbols of Sn

without repeated n-cycles. Then, an infinite number of different subsequences w1 · . . . ·wi,w2 ·. . . ·wi, . . . ,wi can be constructed, which are elements of Seq(Sn), which contradicts that Seq(Sn)is finite.

The results of Proposition 6 and Corollary 1 can be applied to the set of transitions T of a hy-brid automaton, where the infinite sequence represents an infinite trace allowed by the automaton.The following theorem relates the previous results with the infinite traces of an automaton.

Theorem 3 Let seq = t0 · t1 · · · be an infinite sequence of transitions that represents an infinitetrajectory allowed by automaton H. Let T ∞ = R∪S ⊆ T denote the finite set of transitions that

Verifying Hybrid Systems with Explicit Model Checkers 12 / 15

Page 222: y V Taller de Programación Funcional (TPF)

appear infinitely often in seq, and R and S are, respectively, the finite sets of transitions in T ∞

that update, or not, the continuous variables of H. Then, either

1. there are two subsequences in seq

ti · . . . · ti+k−1︸ ︷︷ ︸ · ti+k · . . . · ti+2k−1︸ ︷︷ ︸such that ∀l ∈ 0, . . .k−1 ti+l = ti+k+l ∈ T , or

2. there are at least two subsequences in seq

ti · . . . · ti+k−1︸ ︷︷ ︸ . . . t j · . . . · t j+k−1︸ ︷︷ ︸where ∀l ∈ 0, . . .k−1 ti+l = t j+l ∈ T and both subsequences contain all the transitionsof R.

Proof. The proof checks that if case 1 does not hold, then case 2 must be true. Consider thatT ∞ contains n transitions that appear infinitely often in seq. Seq(T ∞) denotes the set of finitesubsequences without n-cycles. By Corollary 1, there are two subsequences seqi, seq j, i≤ j inseq such that seqi = seq j ∈ Seq(T ∞). These sequences are not consecutive because case 1 doesnot hold. Since all transitions in T ∞ appear infinitely often, the repeated sequence has to containall the transitions, including those that update the continuous variables.

Now, the termination result is proven.

Theorem 4 For each execution trace

tra jαd = 〈loc0,P0〉

A0

→αd 〈loc1,P1〉

A1

→αd · · ·

allowed by the automaton H, there exists j ≥ 0 such that for some 0 ≤ i < j, loci = loc j andP j ⊆ Pi.

Proof. The proof is based on the results of Theorem 3, Proposition 6 and Corollary 1. Givena finite set of n > 0 transitions that appear infinitely often in an infinite trajectory, there is arepeated n-cycle. Now, the relationship between the polyhedra visited in the infinite trajectoryis analyzed, taking into account that there are repeated n-cycles. Assume that seq is an infinitesequence of transitions that represents tra jα

d . Three different cases can be distinguished:

Case 1: There are two equal consecutive subsequences in seq that contain only non updatingtransitions

seq = . . . · ti0 · . . . · tik︸ ︷︷ ︸ · ti0 · . . . · tik︸ ︷︷ ︸ · . . .where ti0 = (loci0 , loci1) transits from state 〈loci0 ,Pi0〉 to 〈loci1 ,Pi1〉 the first time, and from〈loci0 ,P

′i0〉 to 〈loci1 ,P

′i1〉 the second time. Location loc′ is reached twice without updating

any continuous variable in the intermediate transitions. By definition

Pi1 = Sucac(loci0 ,Pi0))∩guard(ti0)∩ Inv(loci1)

Verifying Hybrid Systems with Explicit Model Checkers 13 / 15

Page 223: y V Taller de Programación Funcional (TPF)

and by Proposition 5

P′i1 ⊆ Sucac(loci0 ,Sucac(loci0 ,Pi0))∩guard(ti0)∩ Inv(loci1)

Then, applying Proposition 4 (2), obtains P′i1 ⊆ Pi1 .

Case 2: There are two equal consecutive subsequences in seq that update 0 < l ≤ n continuousvariables

seq = . . . · ti0 · . . . · tik︸ ︷︷ ︸ · ti0 · . . . · tik︸ ︷︷ ︸ · . . .where tik = (loci0 , loci1) transits from state 〈loci0 ,Pi0〉 to 〈loci1 ,Pi1〉 the first time, andfrom 〈loci0 ,P

′i0〉 to 〈loci1 ,P

′i1〉 the second time. Let ti j be the last transition that updates

the variable j. Each time ti j is executed, the resulting polyhedron coincides in the j-component. Each time transition tik is executed in each subsequence, the components ofPi1 and P′i1 that represent the updated variables coincide. In addition, by Proposition 5, therest of the components of both polyhedra satisfy Case (1), thus P′i1 ⊆ Pi1 .

Case 3: There are two equal subsequences in seq that update the n continuous variables of theautomaton. In this case, the sequences are not consecutive.

seq = . . . · ti0 · . . . · tik︸ ︷︷ ︸ . . . ti0 · . . . · tik︸ ︷︷ ︸ · . . .where tik = (locik , locik+1) transits from state 〈locik ,Pik〉 to 〈locik+1 ,Pik+1〉 the first time,and from 〈locik ,P

′ik〉 to 〈locik+1 ,P

′ik+1〉 the second time. Since all continuous variables are

updated in the subsequence, all components of Pik+1 and P′ik+1coincides and thus Pik+1 =

P′ik+1.

6 Conclusions

In this paper, we have presented the formalization of our approach to extend finite-state modelcheckers for hybrid system analysis. The methodology extends an existing finite-state modelchecker in a non-intrusive way to analyze IRHA. We have explained how to construct a dis-cretized version of the hybrid system that can be analyzed without modifying the underlyingmodel checking algorithm. Moreover, we have demonstrated that the termination of the analysisis guaranteed if the system is described as an initialized rectangular hybrid automaton.

Future work will focus on applying, if it is possible, the methodology to analyze hybrid sys-tems with more complex dynamics, such as Linear Hybrid automata. Since model checking isnot decidable for more complex hybrid systems, the challenge is to introduce some mechanismsin our approach that guarantee the termination of the model checking algorithm without drasti-cally reducing the performance of the prototypes, or introducing a lot of errors in the results.

Acknowledgements: This work has been funded by Spanish projects TIN 2008-05932 andIPT-2011-1034-370000, by the Andalusian project P11-TIC-7659 and ERDF from the EuropeanCommission.

Verifying Hybrid Systems with Explicit Model Checkers 14 / 15

Page 224: y V Taller de Programación Funcional (TPF)

Bibliography[AHLP00] R. Alur, T. Henzinger, G. Lafferriere, G. Pappas. Discrete Abstractions of Hybrid Systems.

In Procs. of the IEEE. Volume 88(2), pp. 971–984. 2000.

[BBB+00] A. Balluchi, L. Benvenuti, M. D. Benedetto, C. Pinello, A. Sangiovanni-Vincentelli. Auto-motive Engine Control and Hybrid Systems: Challenges and Opportunities. In Procs. of theIEEE Special issue on Hybrid Hystems. Volume 88(7), pp. 888–912. 2000.

[Feh99] A. Fehnker. Scheduling a Steel Plant with Timed Automata. In Real-Time Computing Systemsand Applications, Int. Workshop on. Volume 0, pp. 280–286. IEEE Computer Society, 1999.

[Fre05] G. Frehse. Compositional verification of hybrid systems using simulation relations. IPA dis-sertation series. 2005.

[GMP02] M. Gallardo, P. Merino, E. Pimentel. Refinement of LTL Formulas for Abstract Model Check-ing. In SAS. Pp. 395–410. 2002.

[GP10] M. Gallardo, L. Panizo. An approach to verify hybrid systems with SPIN. In X Jornadassobre Programacion y Lenguajes, (PROLE). Pp. 67–80. Gaceta grupo editorial, Madrid, Oct.2010.

[GP13] M. M. Gallardo, L. Panizo. Extending Model Checkers for Hybrid System Verification: thecase study of SPIN. Software Testing, Verification and Reliability, p. Accepted, Jan. 2013.

[Hen96] T. Henzinger. The theory of Hybrid Automata. In Procs. of the 11th Annual IEEE Symposiumon Logic in Computer Science. LICS ’96, pp. 278–292. IEEE Computer Society, 1996.

[HHW98] T. Henzinger, P.-H. Ho, H. Wong-toi. Algorithmic Analysis of Nonlinear Hybrid Systems.IEEE Transactions on Automatic Control 43:540–554, 1998.

[HK99] T. Henzinger, P. Kopke. Discrete-Time Control for Rectangular Hybrid Automata. Theor.Comput. Sci. 221(1-2):369–392, 1999.

[HKPV98] T. Henzinger, P. Kopke, A. Puri, P. Varaiya. What’s decidable about hybrid automata? J.Comput. Syst. Sci. 57:94–124, 1998.

[HMR05] T. A. Henzinger, R. Majumdar, J.-F. Raskin. A classification of symbolic transition systems.ACM Trans. Comput. Logic 6(1):1–32, Jan. 2005.

[Ho95] P.-H. Ho. Automatic analysis of hybrid systems. PhD thesis, Ithaca, NY, USA, 1995. UMIOrder No. GAX95-42473.

[Kop96] P. Kopke. The Theory of Rectangular Hybrid Automata. Technical report, Cornell University,Ithaca, NY, USA, 1996.

[LPN11] S. M. Loos, A. Platzer, L. Nistor. Adaptive Cruise Control: Hybrid, Distributed, and NowFormally Verified. In FM. Pp. 42–56. 2011.

[Mol96] F. Moller. Logics for Concurrency: Structure Versus Automata. ACM Comput. Surv.28(4es):50, 1996.

[PC09] A. Platzer, E. M. Clarke. Formal Verification of Curved Flight Collision Avoidance Maneu-vers: A Case Study. In Procs. of the 2nd World Congress on Formal Methods. FM ’09,pp. 547–562. Springer-Verlag, 2009.

[PG12a] L. Panizo, M. Gallardo. Analyzing hybrid systems with JPF. In XII Jornadas sobre Progra-macion y Lenguajes (PROLE). Pp. 235–249. Universidad de Almerıa, Sept. 2012.

[PG12b] L. Panizo, M. Gallardo. An Extension of Java PathFinder for Hybrid Systems. ACM Comput-ing Surveys 37(6):1–5, Nov. 2012.

Verifying Hybrid Systems with Explicit Model Checkers 15 / 15

Page 225: y V Taller de Programación Funcional (TPF)

Checking Bisimilarity for Attributed GraphTransformation

Fernando Orejas ?1, Artur Boronat ??12, Ulrike Golas3, and Nikos Mylonakis1

1 Universitat Politecnica de Catalunya, Spainorejas, [email protected]

2 University of Leicester, [email protected]

3 Konrad-Zuse-Zentrum fur Informationstechnik Berlin, [email protected]

Abstract. Borrowed context graph transformation is a technique developed byEhrig and Koenig to define bisimilarity congruences from reduction semanticsdefined by graph transformation. This means that, for instance, this techniquecan be used for defining bisimilarity congruences for process calculi whose op-erational semantics has been defined by graph transformation, like the AmbientCalculus or the π-Calculus. Moreover, given a set of graph transformation rules,the technique can be used for checking bisimilarity of two given graphs. Unfor-tunately, we can not use these ideas to check if attributed graphs are bisimilar, i.e.graphs whose nodes or edges are labelled with values from some given data al-gebra and where graph transformation involves computation on that algebra. Theproblem is that, in the case of attributed graphs, borrowed context transformationmay be infinitely branching. In this paper, based on borrowed context transforma-tion of what we call symbolic graphs, we present a sound and relatively completeinference system for checking bisimilarity of attributed graphs. In particular, thismeans that, if using our inference system we are able to prove that two graphs arebisimilar then they are indeed bisimilar. Conversely, two graphs are not bisimilarif and only if we can find a proof saying so, provided that we are able to provesome formulas over the given data algebra. Moreover, since the proof system iscomplex to use, we also present a tableau method based on the inference systemthat is also sound and relatively complete.

Key words: Attributed graph transformation, symbolic graph transformation,borrowed contexts, bisimilarity.

? This work has been partially supported by the CICYT project (ref. TIN2007-66523) and bythe AGAUR grant to the research group ALBCOM (ref. 00516)

?? Supported by a Study Leave from University of Leicester

Page 226: y V Taller de Programación Funcional (TPF)

Sesión 8: Database Theory

226

Page 227: y V Taller de Programación Funcional (TPF)

Sesión 8: Database Theory

9.00–9.30 Fernando Sáenz-Pérez: Towards Bridging the Expressive-ness Gap Between Relational and Deductive Databases

9.30–10.00 Gabriel Aranda, Susana Nieva, Fernando Sáenz-Pérez, andJaime Sánchez-Hernández: R-SQL: An SQL Database Sys-tem with Extended Recursion

10.00–10.30 Rafael Caballero, Yolanda García-Ruiz, and FernandoSáenz-Pérez: Declarative Debugging of Wrong and Miss-ing Answers for SQL Views

227

Page 228: y V Taller de Programación Funcional (TPF)

Towards Bridging the Expressiveness Gap BetweenRelational and Deductive Databases

Fernando Saenz-Perez1∗

Grupo de programacion declarativa (GPD),Dept. Ingenierıa del Software e Inteligencia Artificial,

Universidad Complutense de Madrid, Spain1

Abstract: SQL technology has evolved during last years, and systems are beingmore powerful and scalable. However, there exist yet some expressiveness limita-tions that can be otherwise overcome with inputs from deductive databases. Thispaper focuses on both practical and theoretical expressiveness issues in current SQLimplementations that are overcome in the Datalog Educational System (DES), adeductive system which also includes extended SQL queries with respect to theSQL standard and current DBMS’s. Also, as external database access and inter-operability are allowed in DES, results from the deductive field can be tested oncurrent DBMS’s. For instance: Less-limited SQL formulations as non-linear recur-sive queries, novel features as hypothetical queries, and other query languages asDatalog and Extended Relational Algebra. In addition, some notes on performanceare taken.

Keywords: Relational Databases, Deductive Databases, SQL, Datalog, Expressive-ness

1 Introduction

Deductive database systems extend (“relational”) database management systems (DBMS’s) byincluding a more powerful query language based on logic. Datalog (and its extensions as Dat-alog with negation, uninterpreted function symbols, disjunctive heads, constraints, . . . [RU93])became the de-facto deductive query language. This language has been extensively studied andnowadays is regaining an increased interest in different database application areas [Got12].

Motivations for researching in deductive databases include clean semantics of logic-basedapproaches, neat formulations, and expressiveness gains. Provided that the deductive data model(function-free case) meets the relational one with respect to the data structures, it is possible toquery the same database (either intensional or extensional, and either deductive or relational)with different languages, as Datalog, SQL, and Relational Algebra (RA).

Language expressiveness can be seen from two points of view: Expressive power (theoreticalexpressiveness), and concisely and readily (practical expressiveness). Nowadays, one can faceseveral obstacles when formulating SQL queries because of a number of reasons, including, e.g.:parsing requirements and restricted syntax constructions for practical expressiveness, and limited

∗ This author has been partially supported by the Spanish projects STAMP (TIN2008-06622-C03-01), Prometidos-CM (S2009TIC-1465) and GPD (UCM-BSCH-GR35/10-A-910502)

Towards Bridging the Expressiveness Gap 1 / 15

Page 229: y V Taller de Programación Funcional (TPF)

set of operators and recursion limitations for theoretical expressiveness. Whereas the user canwork around practical expressiveness obstacles, usually contrived formulations are reached. Onthe other hand, theoretical expressiveness even makes impossible to formulate a given query.

In this work, we present an ongoing work that enables more powerful and less restrictive formsof SQL queries (w.r.t. current DBMS’s) in the deductive system DES (Datalog EducationalSystem) [SCG11], a system targeted at teaching SQL, RA and Datalog at class rooms. It canbe argued that less restrictive SQL queries enable students a more rapid learning curve becauseless problems arise in writing such queries. Also, we consider extended SQL, RA and Dataloglanguages with novel features which have not been presented before as functional dependencies,the division (relational algebra) operator, SQL hypothetical queries, and Datalog hypotheticalqueries and rules. Along the paper, for some SQL queries, there are presented equivalent Datalogand RA queries which highlight equivalent formulations is these languages. In this paper we alsopresent for the first time persistence and database interoperability as supported by DES, whichallows to test new language features (less-limited SQL recursion, hypothetical queries, divisionoperator, . . . ) in current relational database systems. Although this is not the first deductivedatabase implementing persistence (cf. [TLLP08, AOT+03]), it develops a seamless integrationin a truly interactive system with external DBMS’s.

Organization of this paper is as follows. In Section 2, DES is briefly introduced. Next, Section3 describes the various scenarios for accessing external DBMS’s and mixed query solving inDES. Section 4 focuses mainly on the limitations of state-of-the-art SQL-based DBMS’s, whichcan be overcome with a deductive database, also illustrating equivalent formulations in Datalogand RA, and introducing hypothetical queries as an addendum from deductive databases. Al-though DES is not geared towards performance, Section 5 briefly analyzes some benchmarksthat illustrate that a competitive system might be achieved. Finally, Section 6 concludes andpoints out some future work.

2 Datalog Educational System

DES is a free, open-source, interactive, multiplatform, portable, Prolog-based implementationof a deductive database system. DES 3.2 [SP13] is the current implementation, which enjoysDatalog, (extended) Relational Algebra (RA) and SQL query languages, persistence, full re-cursive evaluation with tabling, full-fledged arithmetic, strong constraints, stratified negation asdescribed in [Ull88] with safety checks [Ull88, ZCF+97], ODBC connections, and novel ap-proaches to Datalog and SQL declarative debugging [CGS12, CGS11, CGS08], test case gener-ation for SQL views [CGS10], duplicates, null values and outer join support [SP12a], aggregatepredicates and functions [SP12b], and hypothetical queries and rules. It is a live system experi-encing many downloads (>45K) and used all over the world both for teaching and research (cf.DES Facts at [SP13], and Quotes for feedback from students and teachers).

Interacting with DES is possible via either an OS command shell or GUI applications, as theJava-based IDE ACIDE [SP07], Crimson Editor, Emacs and others. As the system is imple-mented on top of Prolog, it can be run from a state-of-the-art Prolog interpreter (currently, lastversions of SWI-Prolog and SICStus Prolog are supported) on any OS supported by such Pro-log interpreter. Portable executables (i.e., they do not need installation and can be run from any

Towards Bridging the Expressiveness Gap 2 / 15

Page 230: y V Taller de Programación Funcional (TPF)

directory they are stored) have been also provided for Windows, Linux, and Mac OS X.There is available a wide set of commands for dealing with the system (in-memory database,

ODBC connections, debugging and test case generation, OS interaction, persistence, etc.) Theyare preceded by a slash to isolate command execution from query solving. Assertions are alsoprovided, as, e.g., type constraints, so that one can type Datalog predicates and make themavailable for SQL to be queried (whereas Datalog is not a strong typed language, SQL is).

Datalog as supported by DES mainly follows Prolog ISO standard [ISO00] (considering itssyntax as a subset of Prolog), whilst SQL follows SQL:2008 ISO standard [ISO08], and RAfollows [Cod72] extended with recursion, nulls, outer joins and aggregates (syntax is borrowedfrom [Die01]). Their concrete syntax can be found at [SP13]. All of these query languages canaccess the very same database, which is implemented with both an in-memory Prolog databaseand external relational databases (cf. Section 3).

Evaluation of Datalog recursive queries is ensured to be terminating as long as no infinitepredicates/operators are considered. Currently, only the infix operator ‘is’ represents an infiniterelation and can deliver unlimited pairs (other built-ins, as comparison operators, demand theirarguments to be ground). For instance, let’s consider the rules p(0). and p(X) :- p(Y),X is Y+1. Then, the query p(X) is not terminating since its meaning is infinite (p(0),p(1), ...). Note, however, that a Datalog novel top-N query can be submitted, analogouslyto some current DBMS’s, as top(10,p(X)), which does terminate.

Datalog temporary views allow to write compound queries on the fly (as, e.g., conjunctionsand disjunctions). A temporary view is a rule which is added to the database, and its head issubmitted as a query and executed. Afterwards, the rule is removed. For instance, given therelations a/1 and b/1, the temporary view d(X) :- a(X), not(b(X)) computes the setdifference between the instance relations a and b.

As it will be explained in the next section, SQL statements can be either compiled to Datalogprograms and executed by the deductive engine, or sent to and solved by an external DBMS.Also, SQL statements can be the result of compiling Datalog persistent predicates in order to beexternally solved by a DBMS.

3 Enabling Interoperability

DES

Datalog SQL

Deductive Engine

Cache

In-memory Prolog

DB

ODBC (MySQL, Access, SQL Server, Oracle, DB2,...)

RA

Figure 1: System Archi-tecture

Figure 1 depicts the system architecture of DES supporting thisfunctionality. Datalog queries are solved by the deductive enginerelying on a cache to store results from fixpoint computations byusing a tabling technique [Die87]. The deductive engine is able tosolve such queries and to pass SQL queries (as input by the user oras a result of predicate persistence) to external DBMS’s. Next, thedifferent scenarios for in-memory, external, and mixed query solv-ing are presented.

3.1 In-Memory Database

First alternative for dealing with SQL statements is to use the very same Prolog database. SQLrow-returning queries for the in-memory database are compiled to and executed as Datalog pro-

Towards Bridging the Expressiveness Gap 3 / 15

Page 231: y V Taller de Programación Funcional (TPF)

grams by the deductive engine (basics can be found in [Ull88]), and relational metadata for DDL(Data Definition Language) statements are kept. Submitting a DML (Data Manipulation Lan-guage) row-returning query amounts to 1) parse it, 2) compile to a Datalog program includingthe relation answer/n with as many arguments as expected from the SQL statement and in-cluding the compiled Datalog form corresponding to the SQL statement, 3) assert this program,and 4) submit the Datalog query answer(X1, . . . ,Xn), where Xi : i ∈ 1, . . . ,n are n fresh vari-ables. After its execution, this Datalog program is removed. On the contrary, if a DDL statementdefining a view is submitted, its translated Datalog program and metadata do persist. This allowsDatalog programs to seamlessly use tables and views created at the SQL side. Note that SQLmetadata (column names and types) are stored as Datalog assertions, and consistency constraintsas primary keys and referential integrity constrains are also supported as Datalog assertions.

As an example of a DDL statement, let’s consider:

create table employee(name varchar, dept varchar, salary integer);

which is equivalent (and can be interchangeably used) to the following Datalog assertion (whichis denoted by a preceding neck symbol :-):

:-type(employee(name:varchar, dept:varchar, salary:integer)).

Also, integrity constraints can be stated, as the following primary key assertion (or added as aeither a column or table constraint in the former create table statement):

:-pk(employee,[name]).

As the result of submitting the former inputs, we can inspect metadata for the current database(here, the in-memory, default database $des) with:

DES> /db_schemaInfo: Database ’$des’Info: Table(s):* employee(name:string(varchar),

dept:string(varchar),salary:number(integer))- PK: [name]

Info: No views.Info: No integrity constraints.

Inserting tuples can be done with either an SQL insert statement or a command:

insert into employee values(’Smith’,’Sales’,15000);/assert employee(’Smith’,’Sales’,15000).

Selecting tuples can be performed with either an SQL select, or a Datalog query, or a RAquery. In the following example, employees with a salary over 10,000 are requested for thesequery languages, resp.:

DES> select * from employee where salary > 10000;answer(employee.name:string(varchar),employee.dept:string(varchar),employee.salary:number(integer)) ->

Towards Bridging the Expressiveness Gap 4 / 15

Page 232: y V Taller de Programación Funcional (TPF)

answer(’Smith’,’Sales’,15000)

DES> employee(N,D,S), S>10000

employee(’Smith’,’Sales’,15000)

DES> select salary>10000 (employee)answer(employee.name:string(varchar),employee.dept:string(varchar),employee.salary:number(integer)) ->

answer(’Smith’,’Sales’,15000)

As DES Datalog implementation follows Prolog syntax, variable names start with uppercase(as N, D, and S in the query) and user identifiers start with lowercase (as employee). This alsoapplies to RA variable and user identifier names.

Although this in-memory approach is not truly understood as a persistent database, it is stillpossible to save the contents of the current database to a file and afterwards recover them withthe commands /save ddb, and /restore ddb, resp. Next two sections deal with otherapproaches relying on external DBMS’s.

3.2 Connecting to External Databases

An ODBC connection is identified by a name defined at the OS level, and opening a connectionin DES means to make it the current database. Any relation defined in the external DBMS asa view or table is allowed as any other relation (predicate) in the deductive database. So, thissecond alternative to dealing with SQL statements is to use the ODBC bridge to access externaldatabases: Each SQL relation (table or view) is understood as a predicate and therefore can beseamlessly accessed from either a Datalog or a RA query. Contents of SQL relations are re-trieved (possibly involving query processing in the case of views) from the current open externalDBMS, and SQL queries are directly sent to and processed by such DBMS. As both Datalog andRA queries can refer to SQL relations, therefore, computing such a query can involve computa-tions both in the deductive inference engine and in the external SQL engine. For instance, let’sconsider the external table manager(mgr varchar, emp varchar) stating that mgr isthe direct manager of emp. The following Datalog query computes all managers (both direct andindirect):

DES> /open_db mysqlDES> create table manager(mgr varchar(10), emp varchar(10));DES> insert into manager values (’E1’, ’E2’), (’E2’, ’E3’), (’E2’, ’E4’);DES> managers(M,E) :- manager(M,E) ;

manager(M,M2), managers(M2,E).Info: Processing:

managers(M,E)in the program context of the exploded query:

managers(M,E) :- manager(M,E).managers(M,E) :- manager(M,M2), managers(M2,E).

managers(’E1’,’E2’), managers(’E1’,’E3’), managers(’E1’,’E4’),

Towards Bridging the Expressiveness Gap 5 / 15

Page 233: y V Taller de Programación Funcional (TPF)

managers(’E2’,’E3’), managers(’E2’,’E4’)

This is a Datalog temporary view which recursively computes the outcome as the union (ex-pressed with the semicolon) of direct managers manager(M,E) and managers which has alsoother managers manager(M,M2), managers(M2,E). Note also that the system informsabout how this is translated to a query (managers(M,E)) and a set of rules (exploded query).Whereas the Datalog engine is responsible of computing the transitive closure, the external SQLengine provides the data source for the relation manager. Note that in this example the exter-nal computation is rather light, but consider that this relation can be a complex view or we arelooking for a concrete employee managers. In this last case, e.g., the submitted SQL query tothe external engine would include the where condition.

Concluding, opening an ODBC connection allows the user to integrate external relations inDatalog queries, but in this setting it is not possible to integrate Datalog predicates in externalSQL queries, as the external database is not aware of Datalog relations. To make it possible,another alternative is presented next.

3.3 Persisting Predicates

Persisting a predicate in DES allows durability for deductive programs by relying on currentrelational DBMS’s as persistent media. We have proposed an assertion as a basic declaration formaking a predicate to persist, similar to [CGC+04] (which is for a Prolog system and moreoveris not able to persist intensional predicates, but only facts, as DES does allow). The general formof a persistence assertion at the command prompt is as follows:

:- persistent(PredSpec[,Connection]).

where persistent is the keyword for enabling persistence, PredSpec is a predicate schemaspecification and the optional argument Connection is an ODBC connection identifier. Suchschema specification can be either PredName/Arity or PredName(Schema), where Schemacan be either ArgName1, . . . , ArgNamen or ArgName1:Type1, . . . , ArgNamen:Typen. If aconnection name is not provided, the current open database is used (the local, default database$des cannot be used to persist). With this assertion, we allow for: First, persisting both anempty predicate (i.e., with no defining rules) and an already defined predicates (with definingrules). And, second, for persisting both an untyped or already typed predicate.

The following example makes persistent the predicate employee, as already defined in thedeductive database in the previous subsection. The second argument (mysql) is the name of theODBC connection (in this case, MySQL is the target DBMS) to map the predicate.

:- persistent(employee/3,mysql).

Any rule belonging to the definition of a predicate p which is being made persistent is ex-pected, in general, to involve calls to other predicates. Each callee (such other called predicate)can be:

• An existing relation in the external database.• An already persisted predicate which is loaded in the local database.

Towards Bridging the Expressiveness Gap 6 / 15

Page 234: y V Taller de Programación Funcional (TPF)

• An already persisted predicate which is not yet loaded in the local database.• A predicate which has not been made persistent yet.

For the first two cases, besides making p persistent, nothing else is performed when processingits persistence assertion. For the third case, a persistent predicate is automatically restored inthe local database, i.e., it is made available to the deductive engine. For the fourth case, eachnon-persistent predicate is automatically made persistent if types match; otherwise, an error israised. This is needed in order for the external database to be aware of a predicate which is onlyknown by the deductive engine so far, as this database will eventually compute the meaning ofp.

However, not all persistent rules are processed by the external DBMS because it does notsupport some features, and the translations of some built-ins are not supported yet. In the cur-rent state of the implementation, the following conditions must hold for a rule to be externallyprocessed:

• The rule does not contain calls to built-ins but comparison operators.• The rule is not included in a recursive cycle.

Anyway, such rules are stored as metadata information for their persistence. But this does notmean a loss of expressiveness as such are also kept in the in-memory database for computingthe meaning of the predicate when needed. This is performed by the deductive engine, whichcouples the processing of the external database with its own processing to derive the meaning ofthe predicate. Therefore, all the deductive computing power is preserved although the externalpersistent media lacks some features as, for instance, recursion. Further releases might containrelaxed conditions for this compilation stage as for, e.g., allowing to project those recursive SQLqueries that are supported by the external DBMS.

4 Extending DBMS Expressiveness

This section shows some limits of both expressiveness types (theoretical and practical) in currentDBMS’s and which are otherwise overcome with DES. All (SQL, Datalog and RA) queries havebeen actually computed in this system. This, coupled with interoperability, can allow users totest new features with their DBMS of choice.

4.1 Overcoming Contrived Formulations

Some parsers require to write extended formulations even when it would not be strictly needed.For instance, selecting all arguments from an autojoin is not possible in Access and MySQL as:

select * from t,t;

and table renamings must be added (MySQL requires each derived table to have its own alias).Some DBMS’s as Sybase, MySQL and Access do not include all the outer join versions. Let’s

consider a full outer join:

select * from s full join q on s.sno=q.sno;

Towards Bridging the Expressiveness Gap 7 / 15

Page 235: y V Taller de Programación Funcional (TPF)

Therefore, to compute a full outer join one must resort to add more code, as, e.g.:

select * from s left join q on s.sno=q.snounion allselect * from s right join q on s.sno=q.sno;

If relations s and q are queries instead relations, this becomes worse as one has to eitherduplicate code for them or create new views (with associated issues as changing the database,administration privileges, and hiding original queries).

Also, many nested uses of outer joins are rejected for a number of reasons (including issuesrelated to univocally identify relations and columns in correlations) in different DBMS’s (Access,DB2, MySQL, Oracle, PostgreSQL, SQL Server and Sybase) such as:

select * from s left join(select * from q right join sp on q.sno=sp.sno where q.qname<sp.pname)on s.sno=q.sno where s.name=q.qname;

Finally, the absence of operators as EXCEPT (cf. MySQL, Access) makes the formulation ofseveral queries more cumbersome and less efficient. However, DES does support it and allow allthe above neater formulations.

4.2 Recursive SQL

Let’s consider a classical transitive closure problem: Given a graph defined by the relationedge(ori,des), find all paths. A possible, simple, recursive SQL formulation follows:

with recursive path(ori,des) asselect edge.*,1 from edge

unionselect path.ori,edge.des from path,edge where path.des=edge.ori

select * from path;

But it is rejected in DB2, Oracle, PostgreSQL and SQL Server because they disallow therecursive keyword and/or require union all, and parentheses around the local view def-inition (in turn, neither Access nor MySQL supports SQL recursion). In fact, union all is arequisite in standard SQL because of discarding duplicates. However, DES does not require thisand both a set or multiset answer can be requested. Also, thanks to the support of Datalog, thefollowing neater formulation is allowed:

path(Ori,Des) :-edge(Ori,Des);edge(Ori,Int), path(Int,Des).

Note that, as the former SQL with formulation, this Datalog rule is also a query (a temporaryview) which can be submitted at the command prompt. In contrast to current DBMS’s, this SQLquery can be included in a simplified view declaration in DES as follows, avoiding the use of thewith clause and additional relation names:

create view path(ori,des) asselect edge.* from edge

unionselect path.ori,edge.des from path,edge where path.des=edge.ori;

Towards Bridging the Expressiveness Gap 8 / 15

Page 236: y V Taller de Programación Funcional (TPF)

Another problem with this SQL query in current DBMS’s is when the graph includes a re-cursive cycle. Oracle simply rejects such queries even when they can be actually computed,PostgreSQL enters an infinite loop, and DB2 shows top-500 results by default (requiring all tu-ples also yields to non-termination). Note that DES, even when enabling duplicates, is able toterminate (duplicate sources are both extensional and intensional definitions [SP12a]) because,in contrast to those systems, checks termination along fixpoint computation.

Current DBMS’s show another limitation: Linear recursion is required, which means thatonly one recursive call is allowed in a recursive definition. The following system session shows,first, how relations edge and path are made persistent and, second, that non-linear recursionis allowed in DES. To this end, processing of the recursive, non-linear rule is conducted by thedeductive engine.

:-persistent(edge(a:int,b:int),mysql).:-persistent(path(a:int,b:int),mysql).with recursive path(a, b) as

select * from edgeunionselect p1.a,p2.b from path p1, path p2 where p1.b=p2.a

select * from path;

This example follows previous ones and, as seen, can be formulated as linear-recursive. How-ever, without non-linearity, several queries cannot be expressed, as for instance some graph al-gorithms [ZCF+97]. Also, recursive SQL queries involving EXCEPT, NOT IN, and aggregatesare not allowed in current DBMS as termination is neither ensured nor detected. But deductivesystems implementing XY-stratification can solve some of them, as LDL++ [AOT+03].

Mutual recursion is appealing to formulate some relations, as the hubs and authorities exampleor the following classical definition for even and odd relations:

witheven(x) as select 0 union select odd.x+1 from odd,odd(x) as select even.x+1 from even

select top 20 x from odd;

Note that select 0 is a from-less SQL statement as accepted in several DBMS’s, whichsimply returns a tuple as specified in the projection list (in this case: (0)). However, mutualrecursion is not allowed in current DBMS’s but otherwise allowed in DES.

4.3 The Division RA Operator

An overlooked, but important, relational algebra operator is division, as found in the original pro-posal of Codd [Cod72]. No current DBMS includes this operator, which identifies the attributevalues from a relation that match with all of the values from another relation. There are severalapproaches to solve this kind of queries [McC03], but they resort to cumbersome formulationsthat can be avoided if this operator was made available. DES includes a novel syntax for allowingthe division operator in SQL by extending the form that a relation may take as follows (in BNF):

Relation ::= ... | Relation DIVISION Relation

Towards Bridging the Expressiveness Gap 9 / 15

Page 237: y V Taller de Programación Funcional (TPF)

Consider the subset of Date’s [Dat09] famous SuppliersPartsProjects schema p(pno, pname,color, weight, city) and spj(sno, pno, jno, qty), for parts and suppliers pro-viding parts, where sno and pno stand for supplier and part identifiers, respectively. We areinterested in the query [McC03]: “Find the sno values of the suppliers that supply all partsof weight equal to 17.” This can be easily formulated in DES (as opposed to the lengthly anderror-prone equivalent formulations in [McC03]) as:

select * fromselect sno,pno from spjdivisionselect pno from p where weight=17;

One can compare this neater formulation to those (contrived ones) found in [McC03]. Thisoperator is also available in both RA and Datalog as a novelty, and the very same query can beissued in both languages, resp., as:

DES> (project sno,pno (spj)) division (project pno (select weight=17 (p)))

DES> spj(SNO,PNO,_,_,_) division p(PNO,_,_,17,_)

A couple of notes in this example are: First, the division operator in Datalog refers to variablenames, instead of column names in a schema. And, second, whereas in RA and SQL, projectionis needed to build the appropriate schema of involved operands of the division operator, in Dat-alog it suffices to denote non-relevant variables as anonymous. This discards those non-relevantvariables from the schema of the operands for the division operator.

4.4 Functional Dependencies

Functional dependencies are key concepts in learning normalization, but neither standard SQLnor any current DBMS provide a way to enforcing them. Only DB2 supplies the constructionDETERMINED BY as either a table or column constraint for data cubes. However, such func-tional dependency is only used to produce an optimized query plan, but it is not possible toenforce it yet. DES follows the syntax in DB2 allowing its enforcing with the following syntax,where type ctr is a type constraint, and colfi and colti are column names:

colf1 type_ctr determined by colt2 -- column constraint(colf1,...,colfnl) determined by (colt1,...,coltm) -- table constraint

which is equivalent to the also supported Datalog assertion syntax:

:-fd(Relation,[colf1,...,colfn],[colt1,...,coltm])

4.5 Hypothetical SQL Queries

As a novel feature, DES includes hypothetical SQL queries (absent in the standard) for solving”what-if” scenarios. Date [Dat09] explains this idea (firstly proposed in [SK80]) which broadlymeans that data can be assumed for a given query without actually modifying its source relations.DES includes a novel syntax for allowing such assumptions in the form of:

Towards Bridging the Expressiveness Gap 10 / 15

Page 238: y V Taller de Programación Funcional (TPF)

assume SQL stmt1 in Rel1 [, ...,SQL stmtN in RelN]

SQL query;

which allows to assume the result of SQL stmti in Reli when processing SQL query. Thissyntax for hypothetical SQL clauses follows the syntax of with clauses, but using assumeinstead of with. Indeed, while a with clause allows to define new temporary relations withqueries, an assume clause allows to modify the semantics of already-defined relations.

Referring to the former example about recursive paths, one might be interested in assumingthat a given edge (say (3,1)) is in the relation edge in order to know the new transitive closureof path without resorting to update edge. Following the syntax above, this can be formulatedas follows, which assumes another (extensional) edge in the path recursive view as definedbefore:

assume select 3,1 in edge select * from path;

Also, intensional, recursive rules can be assumed, as in the following query, which computesthe transitive closure of edge (the relation path is not used):

assumeselect e1.ori, e2.des from edge e1, edge e2 where e1.des=e2.ori

in edgeselect * from edge;

Although the current version of DES restricts the use of hypothetical SQL statements toqueries at the top-level, a forthcoming release will relax this restriction and allows to both createviews with assume and also nested uses of assumptions.

4.6 Hypothetical Datalog Queries and Rules

A recent and novel addition to DES has been hypothetical Datalog queries and rules. This ap-proach is based on an intuitionistic semantics [NSS08, McC88, MG12]. As in the former section,extensional as well as intensional data can be assumed and, in addition, hypothetical rules areallowed. Hence, in a forthcoming release it is expected to compile hypothetical SQL queries toDatalog queries, and SQL hypothetical views to Datalog rules. The syntax of an hypotheticalliteral is as follows:

Rule1 /\ ... /\ RuleN => Goal

which means that, assuming that the current database is augmented with the rules Rulei (1 ≤i ≤ N), then Goal is computed with respect to the current database which is augmented withthese rules. Such query is also understood as a literal in the context of a rule, so that any rule cancontain hypothetical goals, as in a :- b => c. In turn, any Rulei can contain hypotheticalgoals. Variables in Rulei are local to Rulei (i.e., they are neither shared with other rules northe goal). Moreover, a hypothetical literal does neither share variables with other literals northe head of the rule in which it occurs. Also, assumed rules must be safe (in the sense of thesafety conditions in [Ull88]). Borrowing an example from [Bon88], the question ”Which are thestudents (S) which would be eligible to graduate (grad/1) if taking (take/2) his and lp wasenough to graduate?” can be issued as:

Towards Bridging the Expressiveness Gap 11 / 15

Page 239: y V Taller de Programación Funcional (TPF)

(grad(S) :- take(S,his), take(S,lp)) => grad(S’)

This query amounts to assume a new rule only in the context of solving the goal grad(S’).Note that the syntax of this rule follows the syntax of Datalog rules. A logical equivalent querywould be: ∃S′grad(S′)⇐∀S((take(S,his)∧ take(S, l p))⇒ grad(S)).

5 A Note on Performance

Although DES has not been designed under any performance directive, some numbers can betaken to analyze its behavior w.r.t. other systems. Here, we consider the logic programming sys-tem XSB 3.2, as an example of an efficient open-source, in-memory, tabled deductive database,and the system IBM DB2 10.1.0, as a commercial, persistent, relational database system. Thesesystems are compared with the DES in-memory system and also with the persistent approach asdescribed in Section 3.3. In this last case, DB2 is the target system providing persistence via anODBC connection.

As tests, we consider the cost of computing the Cartesian product of a table with itself, de-pending on the table size (benchmark instances). We focus therefore in retrieving to the mainmemory the result but without actually displaying the result in order to elide the display time.Each test has been run 10 times, the maximum and the minimum numbers have been discarded,and then the average has been computed. All benchmarks are given in milliseconds and havebeen run on an Intel Core2 Quad CPU at 2.4GHz and 3GB RAM, running Windows XP 32bitSP3. DB2 was accessed through the IBM DB2 ODBC driver version 10.01.00.872.

Table 1 collects such time data expressed as milliseconds. Also, the benchmark instance isdenoted in column Tuples, which shows the number of tuples in the table. The column Resultshows the number of tuples in the result set which will be retrieved to main memory. ColumnsXSB, DES, DB2, and P-DES show the computation times for retrieving into main memory theresult of the Cartesian product for XSB, DES for the in-memory database, DB2, and DES withthe table as a persistent predicate mapped to DB2.

Tuples XSB DES DB2 P-DES Result200 197 135 360 816 40,000400 283 557 1,459 3,035 160,000600 416 1,266 3,270 6,740 360,000800 572 2,287 5,783 11,912 640,000

1,000 768 3,646 9,100 18,590 1,000,000

Table 1: Performance Data

Figure 2 graphically collects these numbers for the same range of tuples as in the table, andshown in the horizontal axis. In turn, vertical axis shows computation times expressed in mil-liseconds. The number computed tuples are also represented (which has been scaled down (50times) to compare with the time to compute them) and it is depicted in the top curve. As illus-trated, the ranking of computing times are in this order, from the best to the worst: XSB, DES,DB2, and P-DES.

Towards Bridging the Expressiveness Gap 12 / 15

Page 240: y V Taller de Programación Funcional (TPF)

0

5,000

10,000

15,000

20,000

200 400 600 800 1,000

XSBDESDB2P-DESResult (1/50)

Figure 2: Performance Curves

A first observation from the figures is that the worst case corresponds to DES with persistentpredicates, and its curve follows a similar slope to the number of computed tuples, meaningthat the time complexity is linear in this number. A second observation is that the curve forthe in-memory DES system performs better than DB2. This is clearly expected as DB2 takesmore tasks than DES to compute such tuples. For instance, first, tables are not in-memory datastructures, but otherwise rely on the OS file system. Nevertheless, it features an efficient buffermanager that tries to keep all data in main memory. And, second, it has to deal with transactionalbehavior, although not with logging as there are no updates in the tests. Finally, XSB achievesthe best numbers as it is a C implementation which compiles the predicates and indexes tabledresults with tries.

Therefore, given these numbers, it can be expected to develop an efficient deductive system,in particular as fast as DB2, for solving these tests because the computation time due to the in-memory XSB system is negligible with respect to the persistence requirements for retrieving only1,000 tuples from the external DBMS. This would be needed to read the table before actuallycomputing the Cartesian product.

6 Conclusions

This paper has shown an ongoing educational project dealing with SQL expressiveness issuesand allowing to project computations to external DBMS’s. By providing a less-limited parserfor practical expressiveness and projecting results from deductive databases for theoretical ex-pressiveness, a better SQL language has been achieved. Although this is not the single systemproviding such features, it is the only one which includes altogether all the ones presented in thispaper. In addition, no other one include outer joins, intensional rule duplicates, SQL functional

Towards Bridging the Expressiveness Gap 13 / 15

Page 241: y V Taller de Programación Funcional (TPF)

dependencies, the division operator, and hypothetical queries, where some of these features arereported here for the first time (other interesting features include SQL algorithmic debugging,which are out of the scope of this paper). However, as an educational tool, it cannot competewith state-of-the-art systems w.r.t. performance. So, one of the obvious steps to continue thiswork is to apply known techniques to enhance performance (tabling trie-based indexing, nativecompilation, . . . ) and even to target to efficient tabled systems as XSB.

Bibliography

[AOT+03] F. Arni, K. Ong, S. Tsur, H. Wang, C. Zaniolo. The Deductive Database SystemLDL++. TPLP 3(1):61–94, 2003.

[Bon88] A. Bonner. Hypothetical Datalog: Complexity and Expressibility. Theoretical Com-puter Science 76:144–160, 1988.

[CGC+04] J. Correas, J. M. Gomez, M. Carro, D. Cabeza, M. V. Hermenegildo. A Generic Per-sistence Model for (C)LP Systems (and Two Useful Implementations). In Jayaraman(ed.), PADL. LNCS 3057, pp. 104–119. Springer, 2004.

[CGS08] R. Caballero, Y. Garcıa-Ruiz, F. Saenz-Perez. A Theoretical Framework for theDeclarative Debugging of Datalog Programs. In International Workshop on Seman-tics in Data and Knowledge Bases. LNCS 4925, pp. 143–159. Springer, 2008.

[CGS10] R. Caballero, Y. Garcıa-Ruiz, F. Saenz-Perez. Applying Constraint Logic Program-ming to SQL Test Case Generation. In Proc. International Symposium on Functionaland Logic Programming (FLOPS’10). LNCS 6009. 2010.

[CGS11] R. Caballero, Y. Garcıa-Ruiz, F. Saenz-Perez. Algorithmic Debugging of SQLViews. In Eigth Ershov Invormatics Conference, PSI’11. Pp. 204–210. June 2011.

[CGS12] R. Caballero, Y. Garcıa-Ruiz, F. Saenz-Perez. Declarative Debugging of Wrong andMissing Answers for SQL Views. In Eleventh International Symposium on Func-tional and Logic Programming (FLOPS’12). LNCS 7294. Springer, 2012.

[Cod72] E. Codd. Relational Completeness of Data Base Sublanguages. In Rustin (ed.), Database Systems. Courant Computer Science Symposia Series 6. Englewood Cliffs, N.J.Prentice-Hall, 1972.

[Dat09] C. J. Date. SQL and relational theory: how to write accurate SQL code. O’Reilly,Sebastopol, CA, 2009.

[Die87] S. W. Dietrich. Extension Tables: Memo Relations in Logic Programming. In IEEESymp. on Logic Programming. Pp. 264–272. 1987.

[Die01] S. Dietrich. Understanding Relational Database Query Languages. Prentice Hall,2001.

Towards Bridging the Expressiveness Gap 14 / 15

Page 242: y V Taller de Programación Funcional (TPF)

[Got12] G. Gottlob. Second Datalog 2.0 Workshop. Austria, Vienna, 2012.

[ISO00] ISO/IEC. ISO/IEC 132111-2: Prolog Standard. 2000.

[ISO08] ISO/IEC. SQL:2008 ISO/IEC 9075(1-4,9-11,13,14):2008 Standard. 2008.

[McC88] L. T. McCarty. Clausal Intuitionistic Logic I - Fixed-Point Semantics. J. Log. Pro-gram. 5(1):1–31, 1988.

[McC03] L. I. McCann. On Making Relational Division Comprehensible. In ASEE/IEEE Fron-tiers in Education Conference. 2003.

[MG12] D. Miller, N. Gopalan. Programming with Higher-Order Logic. Cambridge Univer-sity Press, 2012.

[NSS08] S. Nieva, F. Saenz-Perez, J. Sanchez. Formalizing a Constraint Deductive DatabaseLanguage based on Hereditary Harrop Formulas with Negation. In FLOPS’08, Pro-ceedings. LNCS 4989, pp. 289–304. Springer-Verlag, Ise, Japan, 2008.

[RU93] R. Ramakrishnan, J. Ullman. A survey of research on Deductive Databases. JLP23(2):125–149, 1993.

[SP07] F. Saenz-Perez. ACIDE: An Integrated Development Environment Configurable forLaTeX. The PracTeX Journal 2007(3), August 2007. http://acide.sourceforge.net.

[SP12a] F. Saenz-Perez. Tabling with Support for Relational Features in a DeductiveDatabase. In XII Jornadas sobre Programacion y Lenguajes (PROLE’12). 2012.

[SP12b] F. Saenz-Perez. Outer Joins in a Deductive Database System. Electronic Notes inTheoretical Computer Science 282(0):73 – 88, 2012.

[SP13] F. Saenz-Perez. Datalog Educational System 3.2. February 2013. http://des.sourceforge.net/.

[SCG11] F. Saenz-Perez, R. Caballero, Y. Garcıa-Ruiz. A Deductive Database with Datalogand SQL Query Languages. In Yang (ed.), APLAS. LNCS 7078, pp. 66–73. Springer,2011.

[SK80] M. Stonebraker, K. Keller. Embedding Expert Knowledge and Hypothetical DataBases into a Data Base System. In Proceedings of the 1980 ACM SIGMOD Interna-tional Conference on Management of Data. SIGMOD ’80, pp. 58–66. ACM, NewYork, NY, USA, 1980.

[TLLP08] G. Terracina, N. Leone, V. Lio, C. Panetta. Experimenting with recursive queries indatabase and logic programming systems. TPLP 8(2):129–165, Mar. 2008.

[Ull88] J. D. Ullman. Database and Knowledge-Base Systems, Vols. I (Classical DatabaseSystems) and II (The New Technologies). Computer Science Press, 1988.

[ZCF+97] C. Zaniolo, S. Ceri, C. Faloutsos, R. T. Snodgrass, V. S. Subrahmanian, R. Zicari.Advanced Database Systems. Morgan Kaufmann, 1997.

Towards Bridging the Expressiveness Gap 15 / 15

Page 243: y V Taller de Programación Funcional (TPF)

R-SQL: An SQL Database System with Extended Recursion∗

Gabriel Aranda1, Susana Nieva1, Fernando Saenz-Perez2 andJaime Sanchez-Hernandez1

1 Dept. Sistemas Informaticos y Computacion, UCM, Spain2 Dept. Ingenierıa del Software e Inteligencia Artificial, UCM, Spain

[email protected], [email protected], [email protected], [email protected]

Abstract:

The relational database language SQL:1999 standard supports recursion, but this ap-proach is limited to the linear case. Moreover, mutual recursion is not supported, andnegation cannot be combined with recursion. The language R-SQL was designed toovercome these limitations. In addition, it improves termination properties in re-cursive definitions. We have developed an implementation of R-SQL, that can beintegrated into existing commercial SQL database systems, extending such systemswith the aforementioned benefits of R-SQL. In this paper we describe a concreteinstance, implemented using Python as host language and PostgreSQL as databasesystem.

Keywords: Databases, SQL, Recursion, Fixpoint Semantics

1 Introduction

Recursion is a powerful tool nowadays included in almost all programming systems. However,for current implementations of the declarative programming language SQL, this tool is heavilycompromised or even not supported at all (MySQL, MS Access, . . . ) Those systems includingrecursion suffer from several drawbacks. Linearity is required, so that relation definitions withcalls to more than one recursive relation are not allowed. Mutual recursion, and query solvinginvolving an EXCEPT clause are not supported. In general, termination is manually controlledby limiting the number of iterations instead of detecting that there are no further opportunitiesto develop new tuples. Duplicate discarding is not supported and, so, queries that are actuallyterminating are not detected as such.

Starburst [MP94] was the first non-commercial RDBMS to implement recursion whereas IBMDB2 was the first commercial one. ANSI/ISO Standard SQL:1999 included for the first time re-cursion in SQL. Today, we can find recursion in several systems: IBM DB2, Oracle, MS SQLServer, HyperSQL and others with the aforementioned limitations. In [ANSS13] we proposed anew approach, called R-SQL, aimed to overcome these limitations and others, allowing in partic-ular cycles in recursive definitions of graphs and mutually recursive relation definitions. In orderto combine recursion and negation, we applied ideas from the deductive database field, such asstratified negation, based on the definition of a dependency graph between the relations involved

∗ This work has been partially supported by the Spanish projects TIN2008-06622-C03-01 (FAST-STAMP),S2009/TIC-1465 (PROMETIDOS), and GPD-UCM-A-910502.

R-SQL: An SQL Database System with Extended Recursion 1 / 13

Page 244: y V Taller de Programación Funcional (TPF)

db ::= R sch := sel stm; ... ;R sch := sel stm;sch ::= (A T, ...,A T)

sel stm ::= SELECT exp, ...,exp [FROM R, ...,R [WHERE wcond]]| sel stm UNION sel stm | sel stm EXCEPT R

exp ::= C | R.A | exp opm exp | −exp

wcond ::= TRUE | FALSE | exp opc exp | NOT(wcond) | wcond [AND | OR] wcondopm ::= + | − | / | ∗opc ::= = | <> | < | > | >= | <=

R stands for relation names, A for attribute names, T for standard SQL typesand C for constants belonging to a valid SQL type.

Figure 1: A Grammar for the R-SQL Language

in the database [Ull95]. We developed a formal framework following the original relational datamodel [Cod70], so avoiding both duplicates and nulls (as encouraged by [Dat09]). We used astratified fixpoint semantics and introduced a proof-of-concept implementation.

In this work, we present the R-SQL database system, a prototype implementing such formalframework, in further detail. Also, we recall the syntax, and the meaning of database definitions.The system can be downloaded from https://gpd.sip.ucm.es/trac/gpd/wiki/GpdSystems/RSQL.

Related academic approaches include DLV DB [TLLP08], LDL++ [AOT+03] (now abandonedand replaced by DeAL, which does not refer to SQL queries up to now), and DES [SP13]. Thefirst one, resulting of a spin-off at Calabria University, is the closer to our work as it producesSQL code to be executed in the external database with a semi-naıve strategy, but lacks formalsupport for its proposal, and it does not describe non-linear recursion. Last two ones also allowconnecting to external databases, but processing of recursive SQL queries are in-memory.

2 Introducing R-SQL

In this section, we present an overview of the language R-SQL, which is focused on the incor-poration of recursive relation definitions. The idea is simple and effective: A relation is definedwith an assignment operation as a named query (view) that can contain a self reference, i.e., arelation R can be defined as R sch := SELECT. . .FROM . . . R . . ., where sch is the relation schema.

2.1 The Definition Language of R-SQL

The formal syntax of R-SQL is defined by the grammar in Figure 1. In this grammar, productionsstart with lowercase letters whereas terminals start with uppercase (SQL terminal symbols usesmall caps). Optional statements are delimited by square brackets and alternative sentences areseparated by pipes.

The language R-SQL overcomes some limitations present in current RDBMS’s following

R-SQL: An SQL Database System with Extended Recursion 2 / 13

Page 245: y V Taller de Programación Funcional (TPF)

SQL:1999. These languages use NOT IN and EXCEPT clauses to deal with negation, and WITH

RECURSIVE to engage recursion. As it is pointed out in [GUW09], SQL:1999 does not allow anarbitrary collection of mutually recursive relations to be written in the WITH RECURSIVE clause.

A bundle of R-SQL database examples can be found with the system distribution. Next, wepresent some of them, to show the expressiveness of the definition language.

Mutual Recursion Although any mutual recursion can be converted to direct recursion byinlining [KRP93], our proposal allows to explicitly define mutual recursive relations, which isan advantage in terms of program readability and maintenance. For instance, the following R-SQL database defines the relations even and odd, as the classical specification of even and oddnumbers up to a bound (100 in the example):

even(x float) := SELECT 0 UNION SELECT odd.x+1 FROM odd WHERE odd.x<100;

odd(x float) := SELECT even.x+1 FROM even WHERE even.x<100;

Nonlinear Recursion The standard SQL restricts the number of allowed recursive calls to beonly one. Here we show how to specify Fibonacci numbers in R-SQL1:

fib1(n float, f float) := SELECT fib.n, fib.f FROM fib;

fib2(n float, f float) := SELECT fib.n, fib.f FROM fib;

fib(n float, f float) := SELECT 0,1 UNION SELECT 1,1 UNIONSELECT fib1.n+1,fib1.f+fib2.f FROM fib1,fib2WHERE fib1.n=fib2.n+1 AND fib1.n<10;

Duplicates and Termination Non termination is another problem that arises associated to re-cursion when coupled with duplicates. For instance, the following standard SQL query (thatconsiders a finite relation t) makes current systems either to reject the query or to go into aninfinite loop (some systems allow to impose a maximum number of iterations as a simple termi-nation condition, as DB2):

WITH RECURSIVE v(a) AS SELECT * FROM t UNION ALL SELECT * FROM vSELECT * FROM v

Nevertheless, the fixpoint computation for the corresponding R-SQL relation:v(a float) := SELECT * FROM t UNION SELECT * FROM v;

guarantees termination because duplicates are discarded2 and v does not grow unbounded. Thevery same termination problem also happens in current RDBMS’s with the basic transitive clo-sure over graphs including cycles, but not in R-SQL which ensures termination for finite graphs.

1 The relations fib1 and fib2 simply represent two aliases for fib, which are necessary because, for simplicity,we have not added support for renamings in R-SQL FROM clauses.2 Note that UNION does not require ALL, as current RDBMS’s do.

R-SQL: An SQL Database System with Extended Recursion 3 / 13

Page 246: y V Taller de Programación Funcional (TPF)

2.2 The meaning of an R-SQL database definition

In [ANSS13] we formalized an operational semantics for the language R-SQL based on stratifiednegation and fixpoint theory, here we summarize the main ideas.

Stratification is based on the definition of a dependency graph DGdb for an R-SQL databasedb that is a directed graph whose nodes are the relation names defined in db, and the edges,that can be negatively labelled, are determined as follows. A relation definition of the formR sch := sel stm in db produces edges in the graph from every relation name inside sel stm

to R. Those edges produced by the relation name that is just to the right of an EXCEPT arenegatively labelled.

If there are n relations defined in db, and we denote by RN the set of the relation names definedin db, a stratification of db is a mapping str : RN→ 1, . . . ,n, such that for every two relationsR1, R2 ∈ RN it satisfies:

• str(R1)≤ str(R2), if there is a path from R1 to R2 in DGdb,

• str(R1) < str(R2) if there is a path from R1 to R2 in DGdb with at least one negativelylabelled edge.

An R-SQL database db is stratifiable if there exists a stratification for it. We denote by numStrthe maximum stratum of the elements of RN. And, for every i, 1 ≤ i ≤ numStr, RNi denotes theset of relation names R ∈ RN, such that str(R) = i.

Intuitively, a relation name preceded by an EXCEPT operator plays the role of a negated pred-icate (relation) in the deductive database field. A stratification-based solving procedure ensuresthat when a relation that contains an EXCEPT in its definition is going to be calculated, the mean-ing of the inner negated relation has been completely evaluated, avoiding nonmonotonicity, as itis widely studied in Datalog [Ull95].

We say that an interpretation I is the relationship between every relation R name and its in-stance I(R). Interpretations are classified by strata; an interpretation belonging to a stratum igives meaning to the relations of strata less or equal to i. The meaning of every sel stm w.r.t.an interpretation I can be understood as the set of tuples (in the current instance representedby I) associated to the corresponding equivalent RA-expression, denoted by [sel stm]I . ThisRA-expression is defined as follows: 3

• [SELECT exp1, . . . ,expk FROM R1, . . . ,Rm WHERE wcond]I =πexp1,...,expk

(σwcond(I(R1)× . . .× I(Rm)))

• [sel stm1 UNION sel stm2]I = [sel stm1]

I ∪ [sel stm2]I

• [sel stm EXCEPT R]I = [sel stm]I− I(R)

Example 1 Consider the definitions of the relations odd and even of Section 2. Let us assume aconcrete interpretation I such that I(even)= (0),(2) and I(odd)= /0. Hence, the interpretationof the select statement that defines the relation odd w.r.t. I is:

3 Notice that arithmetic expressions are allowed as arguments in projection (π) and select (σ ) operations.

R-SQL: An SQL Database System with Extended Recursion 4 / 13

Page 247: y V Taller de Programación Funcional (TPF)

[SELECT even.x+1 FROM even WHERE even.x< 100]I =(even.x+1)[a/even.x] | (a) ∈ I(even),(even.x< 100)[a/even.x] is satisfied= (1),(3).

The case of the relation even is analogous:[SELECT 0 UNION SELECT odd.x+1 FROM odd WHERE odd.x< 100]I =[SELECT 0]I ∪ [SELECT odd.x+1 FROM odd WHERE odd.x< 100]I =(0) ∪(odd.x+1)[a/odd.x] | (a) ∈ I(odd), (odd.x< 100)[a/odd.x] is satisfied= (0).

Notice that the interpretation I defined by:I(even) = (0),(2), . . . ,(100) and I(odd) = (1),(3), . . . ,(99) satisfies:I(even) = [SELECT 0 UNION SELECT odd.x+1 FROM odd WHERE odd.x< 100]I .I(odd) = [SELECT even.x+1 FROM even WHERE even.x< 100]I .

So, to give meaning to a database definition, we are interested in an interpretation, called f ix,such that for every R ∈ RN, if sel stm is the definition of R, then f ix(R) = [sel stm] f ix. Inthe previous example f ix will be I. Since R can occur inside its definition, for every stratum i,the appropriate interpretation f ixi that gives the complete meaning to each relation of stratumi is the least fixpoint of a continuous operator. These fixpoint interpretations are sequentiallyconstructed from stratum 1 to numStr. f ix represents the fixpoint of the last stratum and providesthe semantics for the whole database.

For every i, 1 ≤ i ≤ numStr, we define the continuous operator Ti that transforms interpreta-tions belonging to a stratum i as follows:

- Ti(I)(R) = I(R), if str(R)< i.- Ti(I)(R) = [sel stm]I , if str(R) = i and R sch := sel stm is the definition of R in db.- Ti(I)(R) = /0, if str(R)> i.The operator T1 has a least fixpoint, which is

⊔n≥0 T n

1 ( /0), where /0(R) = /0 for every R ∈ RN.We will denote

⊔n≥0 T n

1 ( /0) by f ix1, i.e., f ix1 represents the least fixpoint at stratum 1.Consider now the sequence T n

2 ( f ix1)n≥0 of interpretations of stratum 2, greater than f ix1.Using the definition of Ti and the fact that f ix1(R) = /0 for every R such that str(R)≥ 2, it is easyto prove, by induction on n≥ 0, that this sequence is a chain:

f ix1 v2 T2( f ix1)v2 T2(T2( f ix1))v2 . . . ,v2 T n2 ( f ix1), . . .

T n2 ( f ix1)n≥0 is a chain that has as least upper bound,

⊔n≥0 T n

2 ( f ix1), which is the leastfixpoint of T2 containing f ix1. We denote this interpretation by f ix2. By proceeding successivelyin the same way it is possible to find f ixnumStr. In [ANSS13] we have proved that f ixnumStr is theinterpretation f ix we are looking for, that associates the set of tuples denoted by its definition toevery relation of the database .

3 The R-SQL System

In this section we introduce the R-SQL system, based on the fixpoint construction of the pre-vious section. Once the system is loaded in SWI Prolog (see the readme file of the dis-tribution for details) a database definition dbDef.sql can be processed with the command?- process(dbDef). First, the system parses the input R-SQL database definition, then itbuilds the dependency graph and the stratification if exists (it aborts, otherwise); finally, it pro-

R-SQL: An SQL Database System with Extended Recursion 5 / 13

Page 248: y V Taller de Programación Funcional (TPF)

duces a Python script that will create the SQL database in a RDBMS. After this process, the usercan connect to PostgreSQL in order to query or modify the database. Although we are refer-ring to PostgreSQL in this paper, the implementation can be straightforwardly applied to othersystems. In fact, the distribution also includes a MySQL implementation. The main differencewhen adapting to a particular system is the concrete SQL dialect of such a system. For instance,we use EXCEPT in PostgreSQL and NOT IN in MySQL, as it lacks a set difference operator.

Next we present a database for flights to illustrate the process and also will be the workingexample for the rest of the section. As usual, the information about direct flights can be composedof the city of origin, the city of destination, and the length of the flight. Cities (Lisbon, Madrid,Paris, London, New York) will be represented with constants (lis, mad, par, lon, ny, resp.).The relation reachable consists of all the possible trips between the cities of the database,maybe concatenating more than one flight. The relation travel is analogous but also givestime information about alternative trips.

flight(frm varchar(10), to varchar(10), time float) :=SELECT ’lis’,’mad’,1.0 UNION SELECT ’mad’,’par’,1.5 UNIONSELECT ’par’,’lon’,2.0 UNION SELECT ’lon’,’ny’,7.0 UNIONSELECT ’par’,’ny’,8.0;

reachable(frm varchar(10), to varchar(10)) :=SELECT flight.frm, flight.to FROM flight UNION

SELECT reachable.frm, flight.toFROM reachable,flight WHERE reachable.to = flight.frm;

travel(frm varchar(10), to varchar(10), time float) :=SELECT flight.frm, flight.to, flight.time FROM flight UNIONSELECT flight.frm, travel.to, flight.time+travel.time

FROM flight, travel WHERE flight.to = travel.frm;

Both reachable and travel represent transitive closures of the relation flight. Noticethat if flight has a cycle, then the relation travel that includes times for each trip is infinite,while reachable is not. As pointed before, reachable can be finitely computed in oursystem. But, as travel would produce an infinite set of different tuples, some computationlimitation would have to be imposed (as the maximum time for a travel, for example). How-ever, this is not a drawback of our approach, but an issue due to using infinite relations (builtwith arithmetic expressions). The relation madAirport contains travels departing or arrivingin Madrid, while avoidMad contains the possible travels that neither begin, nor end in Madrid.

madAirport(frm varchar(10), to varchar(10)) :=SELECT reachable.frm, reachable.to FROM reachableWHERE (reachable.frm = ’mad’ OR reachable.to = ’mad’);

avoidMad(frm varchar(10), to varchar(10)) :=SELECT reachable.frm, reachable.to FROM reachable EXCEPT madAirport;

This definition includes negation together with recursive relations. This combination can notbe expressed in SQL:1999 as it is shown in [FMMP96]. The dependency graph of this databaseis depicted in Figure 2, where negatively labelled edges are annotated with ¬. Then, the systemassigns stratum 1 to flight, reachable, travel, madAirport, and stratum 2 toavoidMad.

R-SQL: An SQL Database System with Extended Recursion 6 / 13

Page 249: y V Taller de Programación Funcional (TPF)

Figure 2: DGdb of the working example.

3.1 The Generic Algorithm to Compute the Database Fixpoint

Let db be a stratifiable database definition R1 sch1 := sel stm1; . . . ; Rn schn := sel stmn. Inorder to create the corresponding SQL database we have to generate the appropriate SQL state-ments for building the expected relations (corresponding to the fixpoint of db) when processedby a RDBMS. The algorithm in Figure 3 produces such SQL statements. This algorithm com-

1 str:=12 while str ≤ numStr do3 for all R ∈ RNstr do4 CREATE TABLE R sch;5 end for6 change := true7 while change do8 size := rel size sum(RNstr)9 for all R ∈ RNstr do

10 INSERT INTO R SELECT * FROM sel stmR11 EXCEPT SELECT * FROM R;12 end for13 change = (size 6= rel size sum(RNstr))14 end while15 str:=str+116 end while

Figure 3: Algorithm to compute the database fixpoint

putes f ix(R) for each relation R of the database and stores the corresponding tuples in a SQLtable with the same name R. Relations are computed by strata, from stratum 1 to the last onenumStr, by the while loop at lines 2-16. Each iteration obtains f ixstr for the current stratum str.Within this loop, first of all, the for at lines 3-4 creates an empty table with the correspondingattributes for each relation R in stratum str. Then the while loop at lines 7-14 at the n-iterationcomputes T n

str( f ixstr−1). This is done by performing repeatedly the INSERT statements at lines10-11 for each relation R in the current stratum, that add the tuples resulting from the statementsel stmR that defines such relation. Assuming that the current database instance coincides withthe value of the interpretation T n−1

str ( f ixstr−1), the set of tuples that satisfy that SQL statement

R-SQL: An SQL Database System with Extended Recursion 7 / 13

Page 250: y V Taller de Programación Funcional (TPF)

coincides with [sel stm]Tn−1

str ( f ixstr−1). And this is T nstr( f ixstr−1)(Ri). The tuples already present in

the table are excluded to avoid duplicates by means of the EXCEPT clause at line 11. In this way,T n

str( f ixstr−1)(R) is obtained for every R of stratum str. Finally, the expression rel size sum(RNstr)at lines 8 and 13 denotes ∑R∈RNstr |R|, where |R| stands for the number of tuples of the table cor-responding to R. Therefore, the variable change controls changes on the table sizes in order tostop the process when the fixpoint for a stratum is reached.

3.2 Python Code Generation

The concrete implementation of this algorithm can be done in a number of ways. We have chosenPython as the host language mainly because is multiplatform and it provides easy connectionswith different database systems such as PostgreSQL, MySQL, or even via ODBC, which allowsconnectivity to almost any RDBMS. The additional features required for the host language arebasic: Loops, assignment and basic arithmetic.

Below, we show the result of executing our proposed algorithm for the working example offlights. We detail some parts of the code generated stratum by stratum. For stratum 1, we have:

change := Truewhile change dosize := rel_size_sum(R_str)

INSERT INTO flight (SELECT ’lis’,’mad’,1 UNION SELECT ’mad’,’par’,1UNION SELECT ’par’,’lon’,2 UNION SELECT ’lon’,’ny’,7UNION SELECT ’par’,’ny’,8) EXCEPT SELECT * FROM flight;

INSERT INTO reachable (SELECT flight.frm, flight.to FROM flightUNION SELECT reachable.frm, flight.to WHERE reachable.to = flight.frm)EXCEPT SELECT * FROM reachable;

INSERT INTO travel (SELECT * FROM flight UNIONSELECT flight.frm, travel.to, flight.time+travel.time FROM flight,travelWHERE flight.to = travel.frm) EXCEPT SELECT * FROM travel;

INSERT INTO madAirport (SELECT travel.frm,travel.toFROM travel) EXCEPT SELECT * FROM madAirport;

change = (size != rel_size_sum(R_str))end while

In the first iteration of this loop, we obtain all the tuples for flight and madAirportrelations. But the recursive definitions for reachable and travel need more iterations. Asmentioned before, those iterations correspond to the successive applications of T1. The tuplesadded for travel at each iteration are shown in Figure 4. After five iterations, the loop stopsand the first stratum is completed. In the second stratum we consider the avoidMad relation:

INSERT INTO avoidMad (SELECT travel.frm,travel.to FROM travelEXCEPT SELECT * FROM madAirport) EXCEPT SELECT * FROM avoidMad;

This second loop ends after two iterations. This completes f ix2 for our db, i.e., it obtains thesemantics of the working example database.

R-SQL: An SQL Database System with Extended Recursion 8 / 13

Page 251: y V Taller de Programación Funcional (TPF)

T n1 ( /0)(travel) Set of tuples

T 11 ( /0)(travel) (lon,ny,7.0),(par,lon,2.0),(par,ny,8.0),

(mad,par,1.5),(lis,mad,1.0)T 2

1 ( /0)(travel) (lis,par,2.5),(par,ny,9.0),(mad,ny,9.5),(mad,lon,3.5)T 3

1 ( /0)(travel) (lis,ny,10.5),(lis,lon,4.5),(mad,ny,10.5)T 4

1 ( /0)(travel) (lis,lon,4.5),(mad,ny,10.5),(lis,ny,11.5)

Figure 4: Obtaining f ix1(travel)

The values for flight, madAirport and avoidMad tables are illustrated in the graph inFigure 5. Direct flights will be represented in blue color and labeled with their correspondingtime. Paths for madAirport relation will be represented in red color and path for avoidMadrelation will be represented in black color. The whole database resulting tables are included inAppendix A.

3.3 The System in Action and Future Improvements

Once an R-SQL database definition has been processed, the tables obtained are stored as adatabase instance in PostgreSQL. Then, the user can formulate queries that will be solved usingthose tables (without performing any further fixpoint computation).

Notice that the modification of a relation of the database from the PostgreSQL system cancause inconsistencies since the tables are not recomputed. For instance, after processing thedatabase for flights, if the user adds or deletes a tuple for the relation flight, then the relationtravel will become inconsistent according to its R-SQL definition. But this is the commonRDBMS behavior, when dealing with materialized views. R-SQL has been designed to computethe meaning of a database definition and then to query this database. A future direction in orderto fully integrate R-SQL into a RDBMS is to have the possibility of restoring the consistenceof the database (using triggers for instance), as well as to define additional (possibly recursive)views. This restoring involves the recomputation of the database fixpoint. But, using the de-pendency graph, it is easy to determine the subset of relations that must be calculated, insteadof computing the whole fixpoint for the database. Moreover, those relations may not need to be

Figure 5: Graphical representation of resulting values of the working example.

R-SQL: An SQL Database System with Extended Recursion 9 / 13

Page 252: y V Taller de Programación Funcional (TPF)

recomputed from scratch. In addition, it is straightforward to modify the algorithm introduced inSection 3.1 to get a lazy evaluation of such relations, performing iterations only when new val-ues are demanded. Efficiency can also be improved by indexing (e.g., tries [SW12] and BDD’s[WACL05]) temporary relations during fixpoint computations, and identifying tuple seeds in re-lation definitions that do not need to be recomputed. To seamlessly integrate this into a RDBMS,we can profit from the fourth-generation languages (e.g., SQL PL in IBM DB2 and PL/SQL inOracle). The current implementation of R-SQL must be understood as a prototype, which weplan to enhance as just noted and then compare it with other systems.

Bibliography

[ANSS13] G. Aranda, S. Nieva, F. Saenz-Perez, J. Sanchez-Hernandez. Formalizing a BroaderRecursion Coverage in SQL. In PADL’13. LNCS 7752. 2013. In Press.

[AOT+03] F. Arni, K. Ong, S. Tsur, H. Wang, C. Zaniolo. The Deductive Database SystemLDL++. TPLP 3(1):61–94, 2003.

[Cod70] E. Codd. A Relational Model for Large Shared Databanks. Communications of theACM 13(6):377–390, June 1970.

[Dat09] C. J. Date. SQL and relational theory: how to write accurate SQL code. O’Reilly,Sebastopol, CA, 2009.

[FMMP96] S. J. Finkelstein, N. Mattos, I. S. Mumick, H. Pirahesh. Expressing RecursiveQueries in SQL. Technical report, ISO, 1996.

[GUW09] H. Garcia-Molina, J. D. Ullman, J. Widom. Database systems - the complete book(2. ed.). Pearson Education, 2009.

[KRP93] O. Kaser, C. R. Ramakrishnan, S. Pawagi. On the conversion of indirect to directrecursion. ACM Lett. Program. Lang. Syst. 2(1-4):151–164, Mar. 1993.

[MP94] I. S. Mumick, H. Pirahesh. Implementation of magic-sets in a relational databasesystem. SIGMOD Rec. 23:103–114, May 1994.

[SP13] F. Saenz-Perez. Towards Bridging the Expressiveness Gap Between Relational andDeductive Databases. In PROLE2013. 2013.

[SW12] T. Swift, D. S. Warren. XSB: Extending Prolog with Tabled Logic Programming.TPLP 12(1-2):157–187, 2012.

[TLLP08] G. Terracina, N. Leone, V. Lio, C. Panetta. Experimenting with recursive queries indatabase and logic programming systems. TPLP 8(2):129–165, 2008.

[Ull95] J. Ullman. Database and Knowledge-Base Systems Vols. I (Classical Database Sys-tems) and II (The New Technologies). Computer Science Press, 1995.

[WACL05] J. Whaley, D. Avots, M. Carbin, M. S. Lam. Using Datalog with binary decisiondiagrams for program analysis. In In APLAS’05. 2005.

R-SQL: An SQL Database System with Extended Recursion 10 / 13

Page 253: y V Taller de Programación Funcional (TPF)

Figure 6: Resulting tables of the working example.

A Appendix: Results for the Working Example

This appendix includes the full Python code generated by the R-SQL system for the workingexample of the paper. The actual implementation of R-SQL introduces some improvements inthe code. For example, the code generated for flight table differs from the one explained inthe article, in order to save data from the cursor. In addition, the final values for all the tables areillustrated in Figure 6.

import psycopg2

try:conn = psycopg2.connect("dbname=’test’ user=’postgres’

host=’localhost’ password=’123456’")

except:print "I am unable to connect to the database"

cursor=conn.cursor()

# Code generated for Stratum 1cursor.execute("drop table if exists flight;")cursor.execute("create table flight

(ori varchar(10),des varchar(10),time float);")cursor.execute("drop table if exists reachable;")cursor.execute("create table reachable

(ori varchar(10),des varchar(10));")cursor.execute("drop table if exists travel;")

R-SQL: An SQL Database System with Extended Recursion 11 / 13

Page 254: y V Taller de Programación Funcional (TPF)

cursor.execute("create table travel(ori varchar(10),des varchar(10),time float);")

cursor.execute("drop table if exists madAirport;")cursor.execute("create table madAirport

(ori varchar(10),des varchar(10));")

ch = Truewhile ch:

size1 = 0size2 = 0ch = Falsecursor.execute("select * from flight;")res=cursor.fetchall()size1= size1 + len(res)cursor.execute("insert into flight select ’lis’,’mad’,1

except select * from flight;")cursor.execute("insert into flight select ’mad’,’par’,1.5

except select * from flight;")cursor.execute("insert into flight select ’par’,’lon’,2

except select * from flight;")cursor.execute("insert into flight select ’lon’,’ny’,7

except select * from flight;")cursor.execute("insert into flight select ’par’,’ny’,8

except select * from flight;")

cursor.execute("select * from flight;")res=cursor.fetchall()size2= size2 + len(res)

cursor.execute("select * from reachable;")res=cursor.fetchall()size1= size1 + len(res)cursor.execute("insert into reachable

select flight.ori,flight.des from flightunion (select reachable.ori,flight.desfrom reachable,flightwhere reachable.des = flight.oriexcept select * from reachable;")

cursor.execute("select * from reachable;")res=cursor.fetchall()size2= size2 + len(res)

cursor.execute("select * from travel;")res=cursor.fetchall()size1= size1 + len(res)cursor.execute("insert into travel

select * from flightunion select flight.ori,travel.des,flight.time+travel.timefrom flight,travel where flight.des = travel.oriexcept select * from travel;")

cursor.execute("select * from travel;")res=cursor.fetchall()

R-SQL: An SQL Database System with Extended Recursion 12 / 13

Page 255: y V Taller de Programación Funcional (TPF)

size2= size2 + len(res)

cursor.execute("select * from madAirport;")res=cursor.fetchall()size1= size1 + len(res)cursor.execute("insert into madAirport

select reachable.ori,reachable.desfrom reachablewhere reachable.ori=’mad’ or reachable.des=’mad’)except select * from madAirport;")

cursor.execute("select * from madAirport;")res=cursor.fetchall()size2= size2 + len(res)

ch = (size1 != size2)

# Code generated for Stratum 2cursor.execute("drop table if exists avoidMad;")cursor.execute("create table avoidMad

(ori varchar(10),des varchar(10));")

ch = Truewhile ch:

size1 = 0size2 = 0ch = Falsecursor.execute("select * from avoidMad;")res=cursor.fetchall()size1= size1 + len(res)cursor.execute("insert into avoidMad

select reachable.ori,reachable.desfrom reachable)except select * from madAirport where trueexcept select * from avoidMad;")

cursor.execute("select * from avoidMad;")res=cursor.fetchall()size2= size2 + len(res)

ch = (size1 != size2)

R-SQL: An SQL Database System with Extended Recursion 13 / 13

Page 256: y V Taller de Programación Funcional (TPF)

Declarative Debugging of Wrong and MissingAnswers for SQL Views ?

Rafael Caballero†, Yolanda García-Ruiz†, and Fernando Sáenz-Pérez‡

†Departamento de Sistemas Informáticos y Computación‡Dept. de Ingeniería del Software e Inteligencia Artificial

Universidad Complutense de Madrid, Spainrafa,[email protected] and [email protected]

Abstract. This paper presents a debugging technique for diagnosingerrors in SQL views. The debugger allows the user to specify the errortype, indicating if there is either a missing answer (a tuple was expectedbut it is not in the result) or a wrong answer (the result contains an un-expected tuple). This information is employed for slicing the associatedqueries, keeping only those parts that might be the cause of the error.The validity of the results produced by sliced queries is easier to deter-mine, thus facilitating the location of the error. Although based on theideas of declarative debugging, the proposed technique does not use com-putation trees explicitly. Instead, the logical relations among the nodesof the trees are represented by logical clauses that also contain the infor-mation extracted from the specific questions provided by the user. Theatoms in the body of the clauses correspond to questions that the usermust answer in order to detect an incorrect relation. The resulting logicprogram is executed by selecting at each step the unsolved atom thatyields the simplest question, repeating the process until an erroneous re-lation is detected. Soundness and completeness results are provided. Thetheoretical ideas have been implemented in a working prototype includedin the Datalog system DES.

1 Introduction

SQL (Structured Query Language [18]) is a language employed by relationaldatabase management systems. In particular, the SQL select statement is usedfor querying data from databases. Realistic database applications often containa large number of tables, and in many cases, queries become too complex tobe coded by means of a single select statement. In these cases, SQL allows theuser to define views. A SQL view can be considered as a virtual table, whosecontent is obtained executing its associated SQL select query. View queries canrely on previously defined views, as well as on database tables. Thus, complexqueries can be decomposed into sets of correlated views. As in other program-ming paradigms, views can have bugs. However, we cannot infer that a view is? Work partially supported by the Spanish projects STAMP (TIN2008-06622-C03-01),Prometidos-CM (S2009TIC-1465) and GPD (UCM-BSCH-GR35/10-A-910502)

Page 257: y V Taller de Programación Funcional (TPF)

2 Rafael Caballero†, Yolanda García-Ruiz†, and Fernando Sáenz-Pérez‡

incorrectly defined when it computes an unexpected result, because it might bereceiving erroneous input data from other database tables or views. Given thehigh-abstraction level of SQL, usual techniques like trace debugging are difficultto apply. Some tools as [2, 13] allow the user to trace and analyze the stored SQLprocedures and user defined functions, but they are of little help when debuggingsystems of correlated views. Declarative Debugging, also known as algorithmicdebugging, is a technique applied successfully in (constraint) logic programming[16], functional programming [12], functional-logic programming [5], and in de-ductive database languages [3]. The technique can be described as a generaldebugging schema [11] which starts when an initial error symptom is detectedby the user, which in our case corresponds to an unexpected result producedby a view. The debugger automatically builds a tree representing the erroneouscomputation. In SQL, each node in the tree contains information about both arelation, which is a table or a view, and its associated computed result. The rootof the tree corresponds to the initial view. The children of a node correspondto the relations (tables or views) occurring in the definition of its associatedquery. After building the tree, it is navigated by the debugger, asking to the userabout the validity of some nodes. When a node contains the expected result,it is marked as valid, and otherwise it is marked as nonvalid. The goal of thedebugger is to locate a buggy node, which is a nonvalid node with valid chil-dren. It can be proved that each buggy node in the tree corresponds to eitheran erroneously defined view, or to a database table containing erroneous data.A debugger based on these ideas was presented in [4]. The main criticism thatcan be leveled at this proposal is that it can be difficult for the user to check thevalidity of the results. Indeed, even very complex database queries usually aredefined by a small number of views, but the results returned by these views cancontain hundreds or thousands of tuples. The problem can be easily understoodby considering the following example:

Example 1. The loyalty program of an academy awards an intensive course forstudents that satisfy the following constraints:- The student has completed the basic level course (level = 0).- The student has not completed an intensive course.- To complete an intensive course, a student must either pass the all in onecourse, or the three initial level courses (levels 1, 2 and 3).

The database schema includes three tables: courses(id,level) contains informa-tion about the standard courses, including their identifier and the course level;registration(student,course,pass) indicates that the student is in the course, withpass taking the value true if the course has been successfully completed; and thetable allInOneCourse(student,pass) contains information about students regis-tered in a special intensive course, with pass playing the same role as in registra-tion. Figure 1 contains the SQL views selecting the award candidates. The firstview is standard, which completes the information included in the table Regis-tration with the course level. The view basic selects those standard students thathave passed a basic level course (level 0). View intensive defines as intensive stu-dents those in the allInOneCourse table, together with the students that have

Page 258: y V Taller de Programación Funcional (TPF)

Declarative Debugging of SQL Views 3

create or r ep l a c e view standard ( student , level , pass ) asselect R. student , C. level , R. passfrom cour s e s C, r e g i s t r a t i o n Rwhere C. id = R. course ;

create or r ep l a c e view bas i c ( student ) asselect S . studentfrom standard Swhere S . level = 0 and S . pass ;

create or r ep l a c e view i n t e n s i v e ( student ) as( select A. student from al l InOneCourse A where A. pass )union( select a1 . studentfrom standard A1 , standard A2 , standard A3where A1 . student = A2 . student and A2 . student = A3 . student

anda1 . level = 1 and a2 . level = 2 and a3 . level = 3) ;

create or r ep l a c e view awards ( student ) asselect student from bas i cwhere student not in ( select student from i n t e n s i v e ) ;

Fig. 1. Views for selecting award winner students

completed the three initial levels. However, this view definition is erroneous: wehave forgotten to check that the courses have been completed (flag pass). Finally,the main view awards selects the students in the basic but not in the intensivecourses. Suppose that we try the query select * from awards;, and that in the re-sult we notice that the student Anna is missing. We know that Anna completedthe basic course, and that although she registered in the three initial levels, shedid not complete one of them, and hence she is not an intensive student. Thus,the result obtained by this query is nonvalid. A standard declarative debuggerusing for instance a top-down strategy [17], would ask first about the validityof the contents of basic, because it is the first child of awards. But suppose thatbasic contains hundreds of tuples, among them one tuple for Anna; in order toanswer that basic is valid, the user must check that all the tuples in the resultare the expected ones, and that there is no missing tuple. Obviously, the questionabout the validity of basic becomes practically impossible to answer.

The main goal of this paper is to overcome or at least to reduce this drawback.This is done by asking for more specific information from the user. The questionsare now of the type “Is there a missing answer (that is, a tuple is expected but itis not there) or a wrong answer (an unexpected tuple is included in the result)?”With this information, the debugger can:

Page 259: y V Taller de Programación Funcional (TPF)

4 Rafael Caballero†, Yolanda García-Ruiz†, and Fernando Sáenz-Pérez‡

- Reduce the number of questions directed at the user. Our technique considersonly those relations producing/losing the wrong/missing tuple. In the example,the debugger checks that Anna is in intensive. This means that either awards iserroneous or Anna is wrong in intensive. Consequently, the debugger disregardsbasic as a possible error source, reducing the number of questions.- The questions directed at the user about the validity in the children nodes canbe simplified. For instance, the debugger only considers those tuples that areneeded to produce the wrong or missing answer in the parent. In the example,the tool would ask if Anna was expected in intensive, without asking for thevalidity of the rest of the tuples in this view.

Another novelty of our approach is that we represent the computation treeusing Horn clauses, which allows us to include the information obtained from theuser during the session. This leads to a more flexible and powerful framework fordeclarative debugging that can now be combined with other diagnosis techniques.We have implemented these ideas in the system DES [14, 15].

Next section presents some basic concepts used in the rest of the paper.Section 3 introduces the debugging algorithm that constitutes the main contri-bution of our paper, including the theoretical results supporting the proposal.The implementation is discussed in Section 4. Finally, Section 5 presents theconclusions and proposes future work.

2 Preliminaries

This section introduces some basic concepts about databases, interpretations andtypes of errors which are used in the rest of the paper. A table schema has theform T (A1, . . . , An), with T being the table name and Ai the attribute names fori = 1 . . . n. We refer to a particular attribute A by using the notation T.A. Eachattribute A has an associated type. An instance of a table schema T (A1, . . . , An)is determined by its particular tuples. Each tuple contains values of the correcttype for each attribute in the table schema. The notation t i represents the i -thelement in the tuple. In our setting, partial tuples are tuples that might containthe special symbol ⊥ in some of their components. The set of defined positionsof a partial tuple s, def(s), is defined by p ∈ def(s) ⇔ sp 6=⊥. Tuples s withdef(s) = ∅ are total tuples. Membership with partial tuples is defined as follows:if s is a partial tuple, and S a set of total tuples with the same arity as s, wesay that s ∈ S if there is a tuple u ∈ S such that up = sp for every p ∈ (def(s)∩ def(u)). Otherwise we say that s /∈ S.

A database schema D is a tuple (T ,V), where T is a finite set of tables and Va finite set of views. Views can be thought of as new tables created dynamicallyfrom existing ones by using a SQL query. The general syntax of a SQL view is:create view V(A1, . . . , An) as Q, with Q a query and V.A1, . . . V.An the names ofthe view attributes. A database instance d of a database schema is a set of tableinstances, one for each table in T . The notation d(T ) represents the instance ofa table T in d. The dependency tree of any view V in the schema is a tree with Vlabeling the root, and its children the dependency trees of the relations occurring

Page 260: y V Taller de Programación Funcional (TPF)

Declarative Debugging of SQL Views 5

awards

basic intensive

allInOneCoursestandard

courses registrationstandard

courses registration

standard

courses registration

standard

courses registration

Fig. 2. Example of Computation Tree

in its query. Figure 2 shows the dependency tree for our running example. Ingeneral, the name relation refers to either a table or a view. The syntax of SQLqueries can be found in [18]. We distinguish between basic queries and compoundqueries. A basic query Q contains both select and from sections in its definitionwith the optional where, group by and having sections. For instance, the queryassociated to the view standard in the example of Figure 1 is a basic query. Acompound query Q combines the results of two queries Q1 and Q2 by means ofset operators union [all], except [all] or intersect [all] (the keyword all indicatesthat the result is a multiset). For convenience, our debugger transforms basicqueries into compound queries when necessary. We also assume that the queriesdefining views do not contain subqueries. Translating queries into equivalentdefinitions without subqueries is a well-known transformation (see for instance[6]). For instance, the query defining view awards in the Figure 1 is transformedinto:

select student from bas i cexceptselect student from i n t e n s i v e ;

The semantics of SQL assumed in this paper is given by the Extended RelationalAlgebra (ERA) [10], an operational semantics allowing aggregates, views, andmost of the common features of SQL queries. Each relation R is defined as amultiset of tuples. The notation |R|t refers to the number of occurrences of thetuple t in the relation R, and ΦR represents the ERA expression associated to aSQL query or view R, as explained in [8]. A query/view usually depends on pre-viously defined relations, and sometimes it will be useful to write ΦR(R1, . . . , Rn)indicating that R depends on R1, . . . , Rn. Tables are denoted by their names,that is, ΦT = T if T is a table. The computed answer of an ERA expression ΦR

with respect to some schema instance d is denoted by ‖ ΦR ‖d, where:– If R is a database table, ‖ ΦR ‖d= d(R).– If R is a database view or a query and R1, . . . , Rn the relations defined inR, then ‖ ΦR ‖d= ΦR(‖ ΦR1

‖d, . . . , ‖ ΦRn‖d).

Page 261: y V Taller de Programación Funcional (TPF)

6 Rafael Caballero†, Yolanda García-Ruiz†, and Fernando Sáenz-Pérez‡

The parameter d indicating the database instance is omitted in the rest of thepresentation whenever is clear from the context.

Queries are executed by SQL systems. The answer for a query Q in animplementation is represented by SQL(Q). The notation SQL(R) abbreviatesSQL(select * from R). In particular, we assume in this paper the existenceof correct SQL implementations. A correct SQL implementation verifies thatSQL(Q) = ‖ ΦQ ‖ for every query Q. In the rest of the paper, D representsthe database schema, d the current instance of D, and R a relation defined inD. We assume that the user can check if the computed answer for a relationmatches its intended answer. The intended answer for a relation R w.r.t. d, isa multiset denoted as I(R) containing the answer that the user expects for thequery select * from R in the instance d. This concept corresponds to the ideaof intended interpretations employed usually in algorithmic debugging. We saythat SQL(R) is an unexpected answer for a query R if I(R) 6= SQL(R). An un-expected answer can contain either a wrong tuple, when there is some tuple t inSQL(R) s.t. |I(R)|t < |SQL(R)|t, or a missing tuple, when there is some tuple tin I(R) s.t. |I(R)|t > |SQL(R)|t. For instance, the intended answer for awardscontains Anna once, which is represented as |I(awards)|(Anna) = 1. However, thecomputed answer does not include this tuple: |SQL(awards)|(Anna) = 0. Thus,(’Anna’) is a missing tuple for awards. In order to define the key concept oferroneous relation we need the following auxiliary concept. Let R be either aquery or a relation. The expectable answer for R w.r.t. d, E(R), is defined as:

1. If R is a table, E(R) = d(R), with d the database schema instance.2. If R is a view, then E(R) = E(Q), with Q the query defining R.3. If R is a query E(R) = ΦR(I(R1), . . . , I(Rn)) with R1, . . . , Rn the relations

occurring in R.

Thus, in the case of a table, the expectable answer is its instance. In the case ofa view V , the expectable answer corresponds to the computed result that wouldbe obtained assuming that all the relations Ri occurring in the definition of Vcontain the intended answers. Then, I(R) 6= E(R) indicates that R does notcompute its intended answer, even assuming that all the relations it dependson contain their intended answers. Such relation is called erroneous. In ourrunning example, the real cause of the missing answer for the view awards is theerroneous definition of the view intensive.

3 Debugging Algorithm

In this section we present the algorithm that defines our debugging technique, de-scribing the purpose of each function. Although the process is based on the ideasof declarative debugging, this proposal does not use computation trees explicitly.Instead, our debugger represents computation trees by means of Horn clauses,denoted as H ← C1, . . . , Cn, where the comma represents the conjunction, andH, C1, . . . , Cn are positive atoms. As usual, a fact H stands for the clause H← true. Next, we describe the functions that define the algorithm, although the

Page 262: y V Taller de Programación Funcional (TPF)

Declarative Debugging of SQL Views 7

Code 1 debug(V)Input: V: view nameOutput: A list of buggy views1: A := askOracle(all V)2: P := initialSetOfClauses(V, A)3: while getBuggy(P)=[ ] do4: LE := getUnsolvedEnquiries(P)5: E := chooseEnquire(LE)6: A := askOracle(E)7: P := P ∪ processAnswer(E,A)8: end while9: return (getBuggy(P))

code of some basic auxiliary functions is omitted for the sake of space. This is thecase of getSelect, getFrom, getWhere, and getGroupBy which return the differentsections of a SQL query. In getFrom, we assume that every relations has an alias.The result is a sequence of elements of the form R as R’. A Boolean expressionlike getGroupBy(Q)=[] is satisfied if the query Q has no group by section. Func-tion getRelations(R) returns the set of relations involved in R. It can be appliedto queries, tables and views: if R is a table, then getRelations(R) = R, if R isa query, then getRelations(R) is the set of relations occurring in the definitionof the query, and if R is a view, then getRelations(R) = getRelations(Q), withQ the query defining R. The function generateUndefined(R) generates a tuplewhose arity is the number of attributes in R containing only undefined values(⊥, . . . ,⊥).

The general schema of the algorithm is summarized in the code of functiondebug (Code 1). The debugger is started by the user when an unexpected answeris obtained as computed answer for some SQL view V. In our running example,the debugger is started with the call debug(awards). Then, the algorithm asks theuser about the type of error (line 1). The answer A can be simply valid, nonvalid,or a more detailed explanation of the error, like wrong(t) ormissing(t), indicatingthat t is a wrong or missing tuple respectively. In our example, A takes the initialvalue missing((’Anna’)). During the debugging process, variable P keeps a listof Horn clauses representing a logic program. The initial list of clauses P isgenerated by the function initialSetofClauses (line 2). The purpose of the mainloop (lines 3-8) is to add information to the program P, until a buggy viewcan be inferred. The function getBuggy returns the list of all the relations Rsuch that buggy(R) can be proven w.r.t. the logic program P. The clauses in Pcontain enquiries that might imply questions to the user. Each iteration of theloop represents the election of an enquiry in a body atom whose validity has notbeen established yet (lines 4-5). Then, an enquiry about the result of the queryis asked to the user (line 6). Finally, the answer is processed (line 7). Next, weexplain in detail each part of this main algorithm.

Code 2 corresponds to the initialization process of line 2 from Code 1. Thefunction initialSetofClauses gets as first input parameter the initial view V. This

Page 263: y V Taller de Programación Funcional (TPF)

8 Rafael Caballero†, Yolanda García-Ruiz†, and Fernando Sáenz-Pérez‡

Code 2 initialSetofClauses(V, A)

Input: V: view name, A: answerOutput: A set of clauses

1: P := ∅2: P := initialize(V)3: P := P ∪ processAnswer((all V), A)4: return P

initialize(R)Input: R: relationOutput: A set of clauses

1: P := createBuggyClause(R)2: for each Ri in getRelations(R) do3: P := P ∪ initialize(Ri)4: end for5: return P

createBuggyClause(V)Input: V: view nameOutput: A Horn clause

1: [R1, . . . , Rn] := getRelations(V)2: return buggy(V)← state((all V), nonvalid),

state((all R1), valid), . . . , state((all Rn), valid)).

view has returned an unexpected answer, and the input parameter A containsthe explanation. The output of this function is a set of clauses representing thelogic relations that define possible buggy relations with predicate buggy. Initiallyit creates the empty set of clauses and then it calls the function initialize (line 2),a function that traverses recursively all the relations involved in the definitionof the initial view V, calling createBuggyClause with V as input parameter.createBuggyClause adds a new clause indicating the enquiries that must hold inorder to consider V as incorrect: it must be nonvalid, and all the relations itdepends on must be valid. Next is part of the initial set of clauses generated forthe running example of this paper:buggy(awards) :- state(all(awards),nonvalid),

state(all(basic),valid), state(all(intensive),valid).buggy(basic) :- state(all(basic),nonvalid), state(all(standard),valid).buggy(intensive) :- state(all(intensive),nonvalid),

state(all(allInOneCourse),valid), state(all(standard),valid).. . .

The correlation between these clauses and the dependency tree is straightfor-ward. Finally, in line 3, function processAnswer incorporates the informationthat can be extracted from A into the program P. The information about thevalidity/nonvalidity of the results associated to enquiries is represented in oursetting with predicate state. The first parameter is an enquiry E, and the secondone can be either valid or nonvalid. Enquiries can be of any of the followingforms: (all R), (s ∈ R), or (R’ ⊆ R) with R, R’ relations, and s a tuple with thesame schema as relation R. Each enquiry E corresponds to a specific questionwith a possible set of answers and an associated complexity C(E):- If E ≡ (all R). Let S = SQL(R). The associated question asked to the useris “Is S the intended answer for R?” The answer can be either yes or no. Inthe case of no, the user is asked about the type of the error, missing or wrong,

Page 264: y V Taller de Programación Funcional (TPF)

Declarative Debugging of SQL Views 9

Code 3 processAnswer(E,A)Input: E: enquiry, A: answer obtained for the enquiryOutput: A set of new clauses1: if A ≡ yes then2: P := state(E,valid).3: else if A ≡ no or A ≡ missing(t) or A ≡ wrong(t) then4: P := state(E,nonvalid).5: end if6: if E ≡ (s ∈ R) then7: if (s ∈ SQL(R) and A ≡ no) then8: P:= P ∪ processAnswer((all R),wrong(s))9: else if (s/∈ SQL(R) and A ≡ yes) then10: P:= P ∪ processAnswer((all R),missing(s))11: end if12: else if E ≡ (V ⊆ R) and (A ≡ wrong(s)) then13: P:= P ∪ processAnswer((all R), A)14: else if E ≡ (all V) with V a view and (A ≡ missing(t) or A ≡ wrong(t)) then15: Q := SQL query defining V16: P := P ∪ slice(V,Q,A)17: end if18: return P

giving the possibility of providing a witness tuple t. If the user provides thisinformation, the answer is changed to missing(t) or wrong(t), depending on thetype of the error. We define C(E) = |S|, with |S| the number of tuples in S.

-If E ≡ (R’ ⊆ R). Let S = SQL(R’). Then the associated question is “Is Sincluded in the intended answer for R?” As in the previous case the answerallowed can be yes or no. In the case of no, the user can point out a wrong tuplet ∈ S and the answer is changed to wrong(t). C(E) = |S| as in the previous case.

- If E ≡ (s ∈ R). The question is “Does the intended answer for R include a tuples?” The possible answer can be yes or no. No further information is requiredfrom the user. In this case C(E) = 1, because only one tuple must be considered.

In the case of wrong, the user typically points to a tuple in the result R. Inthe case of missing, the tuple must be provided by the user, and in this casepartial tuples, i.e., tuples including some undefined attributes are allowed. Theanswer yes corresponds to the state valid, while the answer no corresponds tononvalid. An atom state(q,s) occurring in a clause body, is a solved enquiry if thelogic program P contains at least one fact of the form state(q, valid) or state(q,nonvalid), that is, if the enquiry has been already solved. The atom is calledan unsolved enquiry otherwise. The function getUnsolvedEnquiries (see line 4 ofCode 1) returns in a list all the unsolved enquiries occurring in P. The functionchooseEnquiry (line 5, Code 1) chooses one of these enquiries according to somecriteria. In our case we choose the enquiry E that implies the smaller complexityvalue C(E), although other more elaborated criteria could be defined withoutaffecting the theoretical results supporting the technique. Once the enquiry has

Page 265: y V Taller de Programación Funcional (TPF)

10 Rafael Caballero†, Yolanda García-Ruiz†, and Fernando Sáenz-Pérez‡

been chosen, Code 1 uses the function askOracle (line 6) in order to ask for theassociated question, returning the answer of the user. We omit the definitions ofthese simple functions for the sake of space.

The code of function processAnswer (called in line 7 of Code 1), can be foundin Code 3. The first lines (1-5) introduce a new logic fact in the program withthe state that corresponds to the answer A obtained for the enquiry E. In ourrunning example, the fact state(all(awards), nonvalid) is added to the program.The rest of the code distinguishes several cases depending on the form of theenquiry and its associated answer. If the enquiry is of the form (s ∈ R) withanswer no (meaning s /∈ I(R)), and the debugger checks that the tuple s is inthe computed answer of the view R (line 7), then s is wrong in the relation R.In this case, the function processAnswer is called recursively with the enquiry(all R) and wrong(s) (line 8). If the answer is yes and the debugger checks thats does not belong to the computed answer of R (line 10), then s is missing inthe relation R. For enquiries of the form (V ⊆ R) and answer wrong(s), it canbe ensured that s is wrong in R (line 13). If the enquiry is (all V) for some viewV, and with an answer including either a wrong or a missing tuple, the functionslice (line 16) is called. This function exploits the information contained in theparameter A (missing(t) or wrong(t)) for slicing the query Q in order to produce,if possible, new clauses which will allow the debugger to detect incorrect relationsby asking simpler questions to the user. The implementation of slice can be foundin Code 4. The function receives the view V, a subquery Q, and an answer A as

Code 4 slice(V,Q,A)Input: V: view name, Q: query, A: answerOutput: A set of new clauses1: P := ∅; S= SQL(Q); S1= SQL(Q1); S2= SQL(Q2)2: if (A ≡ wrong(t) and Q ≡ Q1 union [all] Q2) or

(A ≡ missing(t) and Q ≡ Q1 intersect [all] Q2) then3: if |S1|t = |S|t then P:= P ∪ slice(V, Q1, A)4: if |S2|t = |S|t then P:= P ∪ slice(V, Q2, A)5: else if A ≡ missing(t) and Q ≡ Q1 except [all] Q2 then6: if |S1|t = |S|t then P:= P ∪ slice(V, Q1, A)7: if Q ≡ Q1 except Q2 and t ∈ S2 then P :=P∪ slice(V,Q2,wrong(t))8: else if basic(Q) and groupBy(Q)=[ ] then9: if A ≡ missing(t) then P := P ∪ missingBasic(V, Q, t)10: else if A ≡ wrong(t) then P := P ∪ wrongBasic(V, Q, t)11: end if12: return P

parameters. Initially, Q is the query defining V, and A the user answer, but thissituation can change in the recursive calls. The function distinguishes severalparticular cases:- The query Q combines the results of Q1 and Q2 by means of either the operatorunion or union all, and A is wrong(t) (first part of line 2). Then query Q produces

Page 266: y V Taller de Programación Funcional (TPF)

Declarative Debugging of SQL Views 11

too many copies of t. Then, if any Qi produces as many copies of t as Q, we canblame Qi as the source of the excessive number of t ’s in the answer for V (lines3 and 4). The case of subqueries combined by the operator intersect [all], withA ≡ missing(t) is analogous, but now detecting that a subquery is the cause ofthe scanty number of copies of t in SQL(V).- The query Q is of the form Q1 except [all] Q2, with A ≡ missing(t) (line 5).If the number of occurrences of t in both Q and Q1 is the same, then t is alsomissing in the query Q1 (line 6). Additionally, if query Q is of the particularform Q1 except Q2, which means that we are using the difference operator onsets (line 7), then if t is in the result of Q2 it is possible to claim that the tuplet is wrong in Q2. Observe that in this case the recursive call changes the answerfrom missing(t) to wrong(t).- If Q is defined as a basic query without group by section (line 8), then eitherfunction missingBasic or wrongBasic is called depending on the form of A.

Both missingBasic and wrongBasic can add new clauses that allow the sys-tem to infer buggy relations by posing questions which are easier to answer.Function missingBasic, defined in Code 5, is called (line 9 of Code 4) when Ais missing(t). The input parameters are the view V, a query Q, and the missing

Code 5 missingBasic(V,Q,t)Input: V: view name, Q: query, t: tupleOutput: A new list of Horn clauses1: P := ∅; S := SQL(SELECT getSelect(Q) FROM getFrom(Q) )2: if t /∈ S then3: for (R AS S) in (getFrom(Q)) do4: s = generateUndefined(R)5: for i=1 to length(getSelect(Q)) do6: if ti 6=⊥and member(getSelect(Q),i) = S.A, A attrib., then s.A = ti7: end for8: if s /∈ SQL(R) then9: P := P ∪ (buggy(V) ← state((s ∈ R), nonvalid).) 10: end if11: end for12: end if13: return P

tuple t. Notice that Q is in general a component of the query defining V. Foreach relation R with alias S occurring in the from section, the function checksif R contains some tuple that might produce the attributes of the form S.A oc-curring in the tuple t. This is done by constructing a tuple s undefined in allits components (line 4) except in those corresponding to the select attributes ofthe form S.A, which are defined in t (lines 5 - 7). If R does not contain a tuplematching s in all its defined attributes (line 8), then it is not possible to obtainthe tuple t in V from R. In this case, a buggy clause is added to the program

Page 267: y V Taller de Programación Funcional (TPF)

12 Rafael Caballero†, Yolanda García-Ruiz†, and Fernando Sáenz-Pérez‡

Code 6 wrongBasic(V,Q,t)Input: V: view name, Q: query, t: tupleOutput: A set of clauses1: P := ∅2: F := getFrom(Q)3: N := length(F)4: for i=1 to N do5: Ri as Si := member(F,i)6: relevantTuples(Ri,Si,Vi, Q, t)7: end for8: P := P ∪ (buggy(V) ← state((V1 ⊆ R1), valid), . . . , state((Vn ⊆ Rn), valid).) 9: return P

Code 7 relevantTuples(Ri,R’,V,Q,t)Input: Ri: relation, R’: alias,

V: new view name, Q: Query, t: tupleOutput: A new view in the database schema1: Let A1, . . . , An be the attributes defining Ri

2: SQL(create view V as(select Ri.A1, . . . , Ri.An from Ri)

intersect all(select R’.A1, . . . , R’.An from getFrom(Q)where getWhere(Q) and eqTups(t,getSelect(Q))))

eqTups(t,s)Input: t,s : tuplesOutput: SQL condition1: C := true2: for i=1 to length(t) do3: if ti 6= ⊥ then4: C:= C AND ti = si5: end for6: return C

P (line 9) meaning that if the answer to the question “Does the intended answerfor R include a tuple s?” is no, then V is an incorrect relation.

The implementation of wrongBasic can be found in Code 6. The input pa-rameters are again the view V, a query Q, and a tuple t. In line 1, this functioncreates an empty set of clauses. In line 2, variable F stands for the set containingall the relations in the from section of the query Q. Next, for each relation Ri ∈F (lines 4 - 7), a new view Vi is created in the database schema after calling thefunction relevantTuples (line 6), which is defined in Code 7. This auxiliary viewcontains only those tuples in relation Ri that contribute to produce the wrongtuple t in V. Finally, a new buggy clause for the view V is added to the programP (line 8) explaining that the relation V is buggy if the answer to the questionassociated to each enquiry of the form Vi ⊆ Ri is yes for i ∈ 1 . . . n.

The following theoretical results guarantee that the technique is reliable.

Theorem 1. Let R be a relation. Then:Correctness: If the call debug(R) returns a list L, then all relation names con-tained in L are erroneous relations.Completeness: Let A be the answer obtained after the call to askOracle(all R)in line 1 of Code 1. If A is of the form nonvalid, wrong(t) or missing(t), thenthe call debug(R) (defined in Code 1) returns a list L containing at least onerelation.

Page 268: y V Taller de Programación Funcional (TPF)

Declarative Debugging of SQL Views 13

Thus, the algorithm always stops pointing to some user view (completeness)which is incorrectly defined (correctness).

4 Implementation

The algorithm presented in Section 3 has been implemented in the Datalog Ed-ucational System (DES [14, 15]). The debugger is started when the user detectsthat Anna is not among the (large) list of student names produced by viewawards. The command /debug_sql starts the session:

1: DES-SQL> /debug_sql awards2: Info: Debugging view ’awards’: 1 - awards(’Carla’), ... 3: Is this the expected answer for view ’awards’? m’Anna’4: Does the intended answer for ’intensive’ include (’Anna’) ? n5: Does the intended answer for ’standard’ include (’Anna’,1,true) ? y6: Does the intended answer for ’standard’ include (’Anna’,2,true) ? y7: Does the intended answer for ’standard’ include (’Anna’,3,false)? y8: Info: Buggy relation found: intensive

The user answer m’Anna’ in line 3 indicates that (’Anna’) is missing in theview awards. In line 4 the user indicates that view intensive should not include(’Anna’). In lines 5, 6, and 7, the debugger asks three simple questions involvingthe view standard. After checking the information for Anna, the user indicatesthat the listed tuples are correct. Then, the tool points out intensive as thebuggy view, after only five simple questions. Observe that intermediate viewscan contain hundreds of thousands of tuples, but the slicing mechanism helpsto focus only on the source of the error. Next, we describe briefly how thesequestions have been produced by the debugger.

After the user indicates that (’Anna’) is missing, the debugger executes a callprocessAnswer(all(awards),missing((Anna))). This implies a call to slice(awards,Q1 except Q2, missing((’Anna’))) (line 16 of Code 3). The debugger checksthat Q2 produces (’Anna’) (line 7 of Code 4), and proceeds with the recursivecall slice(awards, Q2, wrong((’Anna’))) with Q2 ≡ select student from inten-sive. Query Q2 is basic, and then the debugger calls wrongBasic(awards, Q2,(’Anna’)) (line 10 of Code 4)). Function wrongBasic creates a view that selectsonly those tuples from intensive producing the wrong tuple (’Anna’) (functionrelevantTuples in Code 7):

create view i n t e n s i v e_ s l i c e ( student ) as( select ∗ from i n t e n s i v e )intersect a l l( select ∗ from i n t e n s i v e I where I . s tudent = ’Anna ’ ) ;

Finally the following buggy clause is added to the program P (line 8, Code 6):buggy(awards) :- state(subset(intensive_slice,intensive),valid).

By enabling development listings with the command /development on, the logicprogram is also listed during debugging. The debugger chooses the only bodyatom in this clause as next unsolved enquiry, because it only contains one tuple.

Page 269: y V Taller de Programación Funcional (TPF)

14 Rafael Caballero†, Yolanda García-Ruiz†, and Fernando Sáenz-Pérez‡

The call to askOracle returns wrong((’Anna’)) (the user answers ’no’ in line4). Then processAnswer(subset(intensive_slice,intensive), wrong((’Anna’))) iscalled, which in turn calls to processAnswer(all(intensive),wrong((’Anna’))) re-cursively. Next call is slice(intensive, Q, wrong((’Anna’))), with Q ≡ Q3 unionQ4 the query definition of intensive (see Figure 1). The debugger checks thatonly Q4 produces (’Anna’) and calls to slice(intensive, Q4, wrong((’Anna’))).Query Q4 is basic, which implies a call to wrongBasic(intensive, Q4, (’Anna’)).Then relevantTuples is called three times, one for each occurrence of the viewstandard in the from section of Q4, creating new views:

create view s t anda rd_s l i c e i ( student , level , pass ) as( select R. student , R. level , R. pass from standard as R)

intersect a l l( select A1 . student , A1 . level , A1 . passfrom standard as A1 , standard as A2 , standard as A3where (A1 . student = A2 . student and A2 . student = A3 . student

and A1 . level = 1 and A2 . level = 2 and A3 . level = 3)and A1 . student = ’Anna ’ ) ;

for i = 1 . . . 3. Finally, the clause:buggy(intensive) :- state(subset(standard_slice1,standard),valid),

state(subset(standard_slice2,standard),valid),state(subset(standard_slice3,standard),valid).

is added to P (line 8, Code 6). Next, the tool selects the unsolved question withless complexity that correspond to the questions of lines 5, 6, and 7, for whichthe user answer yes. Therefore, the clause for buggy(intensive) succeeds and thealgorithm finishes.

5 Conclusions

We have presented a new technique for debugging systems of SQL views. Ourproposal refines the initial idea presented in [4] by taking into account informa-tion about wrong and missing answers provided by the user. Using a techniquesimilar to dynamic slicing [1], we concentrate only in those tuples produced bythe intermediate relations that are relevant for the error. This minimizes themain problem of the technique presented in [4], which was the huge numberof tuples that the user must consider in order to determine the validity of theresult produced by a relation. Previous works deal with the problem of trackingprovenance information for query results [9, 7], but to the best of our knowledge,none of them treat the case of missing tuples, which is important in our setting.

The proposed algorithm looks for particular but common error sources, liketuples missed in the from section or in and conditions (that is, intersect com-ponents in our representation). If such shortcuts are not available, or if the useronly answers yes and no, then the tools works as a pure declarative debugger.

A more general contribution of the paper is the idea of representing a declar-ative debugging computation tree by means of a set of logic clauses. In fact, thealgorithm in Code 1 can be considered a general debugging schema, because it is

Page 270: y V Taller de Programación Funcional (TPF)

Declarative Debugging of SQL Views 15

independent of the underlying programming paradigm. The main advantage ofthis representation is that it allows combining declarative debugging with otherdiagnosis techniques that can be also represented as logic programs. In our case,declarative debugging and slicing cooperate for locating an erroneous relation.It would be interesting to research the combination with other techniques suchas the use of assertions.

References1. H. Agrawal and J. R. Horgan. Dynamic program slicing. SIGPLAN Not., 25:246–

256, June 1990.2. ApexSQL Debug , 2011. http://www.apexsql.com/sql_tools_debug.aspx/.3. R. Caballero, Y. García-Ruiz, and F. Sáenz-Pérez. A theoretical framework for the

declarative debugging of datalog programs. In SDKB 2008, volume 4925 of LNCS,pages 143–159. Springer, 2008.

4. R. Caballero, Y. García-Ruiz, and F. Sáenz-Pérez. Algorithmic Debugging of SQLViews. In Proceedings of the 8th International Andrei Ershov Memorial Conference,PSI 2011, volume 7162. Springer LNCS, 2012.

5. R. Caballero, F. López-Fraguas, and M. Rodríguez-Artalejo. Theoretical Founda-tions for the Declarative Debugging of Lazy Functional Logic Programs. In Proc.FLOPS’01, number 2024 in LNCS, pages 170–184. Springer, 2001.

6. S. Ceri and G. Gottlob. Translating SQL Into Relational Algebra: Optimization,Semantics, and Equivalence of SQL Queries. IEEE Trans. Softw. Eng., 11:324–345,April 1985.

7. Y. Cui, J. Widom, and J. L. Wiener. Tracing the lineage of view data in a ware-housing environment. ACM Trans. Database Syst., 25:179–227, June 2000.

8. H. Garcia-Molina, J. D. Ullman, and J. Widom. Database Systems: The CompleteBook. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2008.

9. B. Glavic and G. Alonso. Provenance for nested subqueries. In Proceedings ofthe 12th International Conference on Extending Database Technology: Advances inDatabase Technology, EDBT ’09, pages 982–993, New York, NY, USA, 2009. ACM.

10. P. W. Grefen and R. A. de By. A multi-set extended relational algebra: a formalapproach to a practical issue. In ICDE’94, pages 80–88. IEEE, 1994.

11. L. Naish. A Declarative Debugging Scheme. Journal of Functional and LogicProgramming, 3, 1997.

12. H. Nilsson. How to look busy while being lazy as ever: The implementation ofa lazy functional debugger. Journal of Functional Programming, 11(6):629–671,2001.

13. Rapid SQL Developer Debugger, 2011. http://docs.embarcadero.com/products/rapid_sql/.

14. F. Sáenz-Pérez. Datalog Educational System v3.0, March 2012. http://des.sourceforge.net/.

15. Fernando Sáenz-Pérez, Rafael Caballero, and Yolanda García-Ruiz. A deduc-tive database with Datalog and SQL query languages. In 9th Asian Symposium,APLAS 2011, LNCS 7078. Springer, 2011.

16. E. Shapiro. Algorithmic Program Debugging. ACM Distiguished Dissertation. MITPress, 1982.

17. J. Silva. A survey on algorithmic debugging strategies. Advances in EngineeringSoftware, 42(11):976–991, 2011.

18. SQL, ISO/IEC 9075:1992, third edition, 1992.

Page 271: y V Taller de Programación Funcional (TPF)

Sesión 9: Languages and Systems

271

Page 272: y V Taller de Programación Funcional (TPF)

Sesión 9: Languages and Systems

11.00–11.30 Ignacio Castiñeiras and Fernando Sáenz-Pérez: Improvingthe Search Capabilities of a CFLP(FD) System

11.30–12.00 Ricardo J. Rodríguez, Lars-Åke Fredlund, and Ángel Her-ranz: From UML State-Machine Diagrams to Erlang

12.00–12.30 Ana-Rosario Espada, María-del-Mar Gallardo, and DamiánAdalid: DRAGONFLY: Encapsulating Android for Instru-mentation

272

Page 273: y V Taller de Programación Funcional (TPF)

Improving the Search Capabilities of a CFLP(FD) System∗

Ignacio Castineiras1, Fernando Saenz-Perez2

[email protected], [email protected]. Sistemas Informaticos y Computacion 1

Dept. Ingenierıa del Software e Inteligencia Artificial 2

Universidad Complutense de Madrid, Spain

Abstract: In this work we focus on the CFLP system T OY (FD), implemented inSICStus Prolog and supporting FD constraints by interfacing the external CP(FD)solvers of Gecode and ILOG Solver. We extend T OY (FD) with new searchprimitives, in a setting easily adaptable to other Prolog CLP or CFLP systems. Wedescribe the primitives from a solver-independent point of view, pointing out somenovel concepts not directly available in any CP(FD) library we are aware of, aswell as how to specify some search criteria at T OY (FD) level and how easilythese strategies can be combined to set different search scenarios. We describe theimplementation of the primitives, presenting an abstract view of the requirementsand how they are targeted to the Gecode and ILOG libraries. We evaluate the result-ing T OY (FD) architecture and we use some benchmarks to prove that the use ofthe search strategies improve its solving performance.

Keywords: CFLP, FD Search Strategies, Solver Integration

1 Introduction

The use of ad hoc search strategies has been identified as a key point for solving Constraint Sat-isfaction Problems (CSP’s) [Tsa93], allowing the user to interact with the solver in the searchof solutions (exploiting its knowledge about the structure of the CSP and its solutions). Differ-ent paradigms provide different expressivity for specifying search strategies: Constraint LogicProgramming CLP(FD) [JM94] and Constraint Functional Logic Programming CFLP(FD)[Han07] provide a declarative view of this specification, in contrast to the procedural one of-fered by Constraint Programming CP(FD) [MS98] systems (which make the programming ofa strategy to depend on low-level details associated to the constraint solver, and even on the con-crete machine the search is being performed). Also, due to their model reasoning capabilities,CLP(FD) and CFLP(FD) treat search primitives as simple expressions, making possible to:(1) Place a search primitive at any point of the program, (2) Combine several primitives to de-velop complex search heuristics, (3) Intermix search primitives with constraint posting, and (4)Use indeterminism to apply different search scenarios for solving a CSP.

The main contribution of this paper is to present a set of search primitives for CLP(FD) andCFLP(FD) systems implemented in Prolog, and interfacing external CP(FD) solvers with a

∗ This work has been partially supported by the Spanish projects TIN2008-06622-C03-01, UCM-BSCH-GR58/08-910502, and S2009TIC-1465

Improving the Search Capabilities of a CFLP(FD) System1 1 / 15

Page 274: y V Taller de Programación Funcional (TPF)

C++ API. The motivation of this approach is to take advantage of: (i) The high expressivityof CLP(FD) and CFLP(FD) for specifying search strategies, and (ii) The high efficiency ofCP(FD) solvers. The paper focuses on the CFLP(FD) system T OY (FD) [FHSV07], moreprecisely in the system versions T OY (FDg) and T OY (FD i) [CS12], interfacing the ex-ternal CP(FD) solvers (with C++ API) of Gecode 3.7.3 [STL12] and IBM ILOG Solver 6.8[IBM10], resp. T OY (FD) is completely developed in SICStus Prolog [Mat12]. Their pro-grams follow a syntax mostly borrowed from Haskell [PJ02], with the remarkable exceptionthat program and type variables begin with upper-case letters whereas data constructors, typesand functions begin with lower-case. Instead of using an abstract machine for running byte-code or intermediate code from compiled programs, the T OY compiler uses SICStus Prologas an object language [LLR93]. Regarding search, T OY (FD) offers two possibilities up tonow: (1) Defining a new search from scratch at T OY (FD) level (with a T OY (FD) func-tion that use reflection functions to represent the search procedure), and, (2) Using the searchprimitive labeling, which simply relies on predefined search strategies already existing inGecode and ILOG, resp. The use of external CP(FD) solvers (with C++ API) opens a thirdpossibility, which we exploit in this paper: Enhancing the search language of T OY (FDg) andT OY (FD i) with new parametric search primitives, implementing them in Gecode and ILOGby extending their underlying search libraries.

The paper is organized as follows: Section 2 presents an abstract description of the new pa-rameterizable T OY (FD) search primitives, pointing out some novel concepts not directlyavailable in any CP(FD) library we are aware of, as well as how to specify some search criteriaat T OY (FD) level and how easily these strategies can be combined to set different searchscenarios. Section 3 describes the implementation of the primitives in T OY (FD), presentingan abstract view of the requirements, how they are targeted to the Gecode and ILOG librariesand a evaluation of the resulting architecture of the system. Section 4 presents some prelimi-nary although encouraging case studies, showing that the use of the search strategies improvethe solving performance of both T OY (FDg) and T OY (FD i). Finally, Section 5 presentssome conclusions and future work.

2 Search Primitives Description

This section presents eight new T OY (FD) primitives for specifying search strategies, allow-ing the user to interact with the solver in the search for solutions. These primitives bridge thegap between the other two classical approaches available in T OY (FD): Defining a wholesearch procedure at T OY level (by using reflection functions), and relying on the set of pre-defined search strategies available in the solver library. Each primitive has its own semantics,and it is parameterizable by several basic components. The search primitives are considered bythe language as simple expressions, so intermixing search strategies with the regular posting ofconstraints is allowed. The section describes the primitives and their components (including itstype declaration) from an abstract, solver independent point of view. It emphasizes: (1) Somenovel search concepts arisen, which are not available in the predefined search strategies of anyCP solver, (2) How easy and expressive it is to specify some search criteria at T OY (FD)level, and (3) The appealing possibilities T OY (FD) offers to apply different search strategiesfor solving a CP problem.

Improving the Search Capabilities of a CFLP(FD) System2 2 / 15

Page 275: y V Taller de Programación Funcional (TPF)

2.1 Labeling Primitives

Primitive lablab :: varOrd -> valOrd -> int -> [int] -> bool

This primitive collects (one by one) all possible combination of values satisfying the set of con-straints posted to the solver. It is parameterized by four basic components. The first and secondones represent the variable and value order criteria to be used in the search strategy, resp. To ex-press them we have defined in T OY the enumerated datatypes varOrd and valOrd, coveringall the predefined criteria available in the Gecode documentation [STL13]. They also include alast case (userVar and userVal, resp.) in which the user implements its own variable/valueselection criteria at T OY (FD) level. The third element N represents how many variables ofthe variable set are to be labeled. This represents a novel concept not available in the predefinedsearch strategies of any CP solver. The fourth argument represents the variable set S. Thus, thesearch heuristic uses varOrd to label just N variables of S.

Next T OY (FD) program (top) and goal (bottom) show how expressive, easy and flexi-ble is to specify a search criteria in T OY (FD). In the example, the search strategy of thegoal uses the userVar and userVal selection criteria (specified by the user in the functionsmyVarOrder and myValOrder, resp.) The lab search strategy computes partial solutions tothe T OY (FD) goal domain [X,Y, Z] 0 4, Y /= 1, Y /= 3, Z /= 2. Then, “restof T OY (FD) goal” is processed to compute complete solutions. Our search strategy acts overthe set of variables [X,Y,Z], but it is only expected to label one of them.

myVarOrder:: [int] -> intmyVarOrder V = fst (foldl cmp (0,0) (zip (take (length V) (from 0))

(map (length . get_dom) V)))%myValOrder:: [[int]] -> int | from:: int -> [int]myValOrder D = head (last D) | from N = [N | from (N+1)]%cmp:: (int,int) -> (int,int) -> (int,int)cmp (I1,V1) (I2,V2) = if (V1 >= V2) then (I1,V1) else (I2,V2)----------------------------------------------------------------------TOY(FD)> domain [X,Y,Z] 0 4, Y /= 1, Y /= 3, Z /= 2,

lab userVar userVal 2 [X,Y,Z], ... (REST OF TOY(FD) GOAL)

The function myVarOrder selects first the variable with more intervals on its domain. Itreceives the list of variables involved in the search strategy, returning the index of the selectedone. To do so it uses: (i) The auxiliary functions from and cmp. (ii) The predefined functionsfst, foldl, zip, take, length, map, head, last and (.) (all of them with an equivalentsemantics as in Haskell). (iii) The reflection function get dom, which accesses the internal stateof the solver to obtain the domain of a variable (this domain is presented as a list of lists, whereeach sublist represents an interval of values).

The function myValOrder receives as its unique argument the domain of the variable, re-turning the lower bound of its upper interval. So, in conclusion, the first two (partial) solutionsobtained by the lab strategy are: (X in 0..4, Y -> 4, Z -> 3) and (X in 0..4,Y -> 4, Z -> 4).

Improving the Search Capabilities of a CFLP(FD) System3 3 / 15

Page 276: y V Taller de Programación Funcional (TPF)

2

3

5

6

1

4

Board

Figure 1: Applying labB and fragB to the n-queens problem

Primitive labBlabB :: varOrd -> valOrd -> int -> [int] -> bool

This primitive uses the same four basic elements as lab. However, its semantics is different,as it follows the varOrd and valOrd criteria to explore just one branch of the search tree, withno backtracking allowed. Let us explain it by using the 4-queens example.

Using lab unassignedLeftVar smallestVal 0 [X1,X2,X3,X4] (where 0 inthe third argument stands for labeling all the variables) we obtain two solutions: X1 -> 1,X2 -> 3, X3 -> 2, X4 -> 4 and X1 -> 2, X2 -> 4, X3 -> 1, X4 -> 3. However,if we use labB unassignedLeftVar smallestVal 0 [X1,X2,X3,X4] the strategy fails,getting no solutions. Left hand side of Fig. 1 (4× 4 square Board and tree) shows the com-putation process. First, the selected criteria assigns X1 -> 1 at root node (1), leading to node2. Propagation reduces search space to (X2 in 3..4, X3 in 2 ∨ 4, X4 in 2..3),pruning nodes 3 and 4. Then, computation assigns X2 -> 3 (leading to node 5), and propaga-tion leads to an empty domain for X3. So, the explored tree path leads to no solutions, and so itdoes the computation. As we have seen, propagation during search modifies the intended branchto be explored (in our example, it explores the branch 1-2-5 instead of the 1-2-3).

Primitive labWlabW :: varOrd -> bound -> int -> [int] -> boolThis primitive performs an exhaustive breadth exploration of the search tree, storing the satis-fiable leaf nodes achieved to further sort them by a specified criteria. Let us consider a firstexample to understand the semantics of labW. The following T OY (FD) goal has four vari-ables, where two implication constraints relate X and Y with V1 and V2, resp.

TOY(FD)> domain [X,Y] 0 1, post_implication X (#=) 1 V1 (#>) 1,domain [V1,V2] 0 3, post_implication Y (#=) 0 V2 (#>) 0,labW unassignedLeftVar smallestSearchTree 2 [X,Y,V1,V2], ...

If we had used a lab unassignedLeftVar smallestVal 2 [X,Y,V1,V2] strategy(instead of the labW one) to label the first two unbound vars of [X,Y,V1,V2], then the searchwould have explored the search tree obtaining (one by one) the next four feasible solutions:X -> 0, Y -> 0, X -> 0, Y -> 1, X -> 1, Y -> 0 and X -> 1, Y -> 1. Fig3 represents the exploration of the search tree for obtaining those four solutions, where eachblack node represents a solution, and the triangle it has below represents the remaining size ofthe search space (product of cardinalities of V1 and V2). As we see, whereas the first solutioncomputed by lab leads to compute the “rest of the T OY (FD) goal” from a 12 candidatessearch space, the third solution leads to a 6 candidates one.

The primitive labW explores exhaustively the search tree in breadth, storing in a data structureDS each feasible node leading to a solution. Once the tree has been completely explored, the

Improving the Search Capabilities of a CFLP(FD) System4 4 / 15

Page 277: y V Taller de Programación Funcional (TPF)

X = 1 X = 0

1st

2nd 3rd 4th

Y == 1 Y = 0 Y = 0 Y == 1

6

812 16

Figure 2: Search Tree

solutions are obtained (one by one) by using a criteria to select and remove the best node fromDS. In the example, the selected criteria smallestSearchTree selects first the node withsmaller product of cardinalities of V1 and V2 (returning first the solution of the 6 candidates).The order in which the labW strategy of the goal delivers the solutions is presented in Fig. 2.

Coming back to the definition of labW, the first parameter represents the variable selectioncriteria (no value selection is necessary, as the search would be exhaustive for all the values of theselected variables). The second parameter represents the best node selection criteria. To expressit we have defined in T OY the enumerated datatype ord, ranging from the smallest/largestremaining search space of the product cardinalities of the labeling/solver-scope variables. Again,a last case (userBound) allows to specify the bound criteria at T OY (FD) level. The thirdparameter sets the breadth level of exhaustive exploration of the tree (represented as a horizontalblack line in Fig. 2). Finally, as usual, the last parameter is the set of variables to be labeled.

Next T OY (FD) program (top) and goal (bottom) presents a second example, with a boundcriteria specified in the user function myBound. The best node procedure selection traversesall the obtained nodes in DS, selecting first the one with minimal bound value. In this context,the user criteria specified in myBound assigns to each node (minus) the number of its singletonvalue search variables. Once again, the function myBound also relies on auxiliary, preludeand reflection functions. The first two obtained solutions are (X -> 1, Y -> 1, A -> 0,B -> 0, C -> 0) and (X -> 2, Y -> 1, A in 0..1, B -> 0, C -> 0), resp.

isBound:: [[int]] -> boolisBound [[A,A]] = trueisBound [[A,B]] = false <== B /= AisBound [[A,B] | RL] = false <== length RL > 0%myBound:: [int] -> intmyBound V = - (length (filter isBound (map get_dom V)))----------------------------------------------------------------------TOY(FD)> domain [X,Y] 1 2, domain [A,B,C] 0 5, A #< X, B #< Y, C #< Y,

labW unassignedLeftVar userBound 2 [X,Y,A,B,C]

In summary, labW represents a novel concept not available in the predefined search strategiesof any CP solver. However, it must be used carefully, as exploring the tree very deeply can leadto a explosion of feasible nodes, producing memory problems for DS and becoming very ineffi-cient (due to the time spent on exploring the tree and selecting the best node).

Primitive labOlabO :: optType -> varOrd -> valOrd -> int -> [int] -> bool

This primitive performs a standard optimization labeling. The first parameter optType contains

Improving the Search Capabilities of a CFLP(FD) System5 5 / 15

Page 278: y V Taller de Programación Funcional (TPF)

the optimization type (minimization/maximization) and the variable to be optimized. The otherfour parameters are the same as in the lab primitive.

2.2 Fragmentize Primitives

frag :: domFrag -> varOrd -> intervalOrd -> int -> [int] -> boolfragB :: domFrag -> varOrd -> intervalOrd -> int -> [int] -> boolfragW :: domFrag -> varOrd -> bound -> int -> [int] -> boolfragO :: domFrag->optType->varOrd->intervalOrd->int->[int]->bool

These four new primitives are mate to the lab* ones, but each variable is not labeled (bound)to a value, but fragmented (pruned) to a subset of the values of their domain. Let us consider anintroductory example to motivate the usefulness of these new primitives. We suppose that: (i)A goal contains V variables and C constraints, with V’ ≡ V1, V2, V3 a subset of V, (ii) Theconstraint domain V’ 1 9 belongs to C, (iii) No constraint of C relates the variables of V’by themselves, but some constraints relate V’ with the rest of variables of V.

The left and right hand sides of Fig. 3 present the search tree exploration achieved by frag*and lab* search primitives, resp. In the case of frag*, the three variables of V’ have beenfragmented into the intervals (1,. . .,3), (4,. . .,6) and (7,. . .,9), leading to exponentially less leafnodes (27) that the lab* exploration (729). On the one hand, if it is known that there is onlyone solution to the problem, the probabilities of finding the right combination of V’ values isthus bigger in frag* than in lab*. On the other hand, the remaining search space of the leafnodes of lab* are expected to be exponentially smaller than the ones of frag*, due to themore propagation in V’ (also expecting to lead to more pruning in the rest of V variables). Thus,the frag* search strategies can be seen as a more conservative technique, where there are lessexpectations of highly reducing the search space, as variables are not bound, but there is moreprobability of choosing a subset containing values that lead to solutions (in what can be seen asa sort of generalization of the first-fail principle [MS98]).

Coming back to the definition of each frag* primitive, two differences arise w.r.t. itsmate lab* primitive: (1) It contains as an extra basic component (first argument) the datatypedomFrag, which specifies the way the selected variable is fragmented. The user can choosebetween partition n and intervals. The former fragments the domain values of thevariable into n subsets of the same cardinality. The latter looks for already existing inter-vals on the domain of the variables, splitting the domain on them. For example, let us sup-pose that a goal computes domain [X] 0 16, X /= 9, X /= 12. Whereas applying

… …

V3

1

1 2 3

5 9 6 1 4

16 18 27 17 … …

1 81

1 9

V3

V2

V1

729 1 450

V1

V2

Figure 3: frag vs lab Search Tree

Improving the Search Capabilities of a CFLP(FD) System6 6 / 15

Page 279: y V Taller de Programación Funcional (TPF)

partition 3 to X fragments the domain in the subsets S1 ≡ 0. . .4, S2 ≡ 5. . .8∪10and S3 ≡ 11∪13. . .16, applying intervals fragments the domain in the subsets S1’ ≡0. . .8, S2’ ≡ 10. . .11 and S3’ ≡ 13. . .16. (2) An enumerated datatype intervalOrd(replacing the lab* argument valOrd), to specify the order in which the different intervalsshould be tried: First left, right, middle or random interval.

In summary, we claim the frag* primitives to be an interesting tool, to be taken into accountin the context of search strategies as an alternative or a complement to the use of exhaustivelabelings. Also, its use in T OY (FD) represents a novel concept not available in the predefinedlibrary of any CP solver.

2.3 Applying Different Search Scenarios

T OY (FD) supports non-deterministic functions, with possibly several reductions for given,even ground, arguments. The rules are applied following their textual order, and both failure anduser request for a new solution trigger backtracking to the next unexplored rule. In this setting,different search strategies can be sequentially applied for solving a CP problem. For example,after posting V and C to the solver, the T OY (FD) program (top) and goal (bottom) presentedbelow uses the non-deterministic function f to specify three different scenarios for the solvingof the CP problem described in Section 3.5. Each scenario ends with an exhaustive labeling ofthe set of variables V. However, the search space s this exhaustive labeling has to explore can behighly reduced by the previous evaluation of f.

f:: [int] -> boolf [V1,V2,V3] = true <==

fragB (partition 4) unassignedLeftVar random 0 [V1],labB unassignedLeftVar smallestVal 0 [V2,V3]

f [V1,V2,V3] = true <==fragW (partition 4) unassignedLeftVar smallestTree 0 [V1],labB unassignedLeftVar smallestTotalVars 0 [V2,V3]

f [V1,V2,V3] = true--------------------------------------------TOY(FD)> Post of (V,C), f V’, lab userVar userVal 0 V

Scenario 1: The first rule of f performs the search heuristic h1 over V’ ≡ V1,V2,V3. (1)h1 fragments the domain of V1 into 4 subsets, selecting one randomly. If propagation succeeds,(2) then h1 bounds V2 and V3 to their smallest value. If propagation succeeds (with a remainingsearch space s1), (3) then h1 succeeds, and the exhaustive labeling explores s1. If propagationfails in (1) or (2), or the exhaustive labeling does not find any solution in s1, then h1 completelyfails (as so the first rule of f), as both the labB and fragB primitives just explore one branch.

Scenario 2: The second rule of f is tried, performing the heuristic h2 over V’. Here a fragWprimitive is first applied. So, if further either labB of h2 or the exhaustive lab (acting over s2)fails, backtracking is done over fragW, providing the next best interval of V1 (according to thesmallest search tree criteria, as in Fig. 2). If, after trying all the intervals a solution is not found,then h2 completely fails (as so the second rule of f).

Scenario 3: If both h1 and h2 fail, the third rule of f trivially succeeds, and the exhaustivelabeling is performed over the original search space obtained after posting V and C to the solver.

Improving the Search Capabilities of a CFLP(FD) System7 7 / 15

Page 280: y V Taller de Programación Funcional (TPF)

3 Search Primitives Implementation

The integration of the eight new search primitives into T OY (FD) is based on the scheme pre-sented in [CS12], which supported the coexistence in the goal computations of T OY (FDg)and T OY (FD i) of multiple labeling primitives (using the predefined search strategiesprovided in Gecode and ILOG) interleaved with the posting of constraints. To achieve the inte-gration, the scheme: (1) Uses the Prolog-C++ connection provided by SICStus, to gain accessfrom the Prolog predicate which manages the labeling primitive to the C++ function whichimplements the search (by accessing to the API of Gecode and ILOG). (2) Relies on a vector ofauxiliary search managers ss1 . . . ssl to perform the search of the labelings l1 . . . ll arisenalong the goal computation. This includes synchronizing the constraint store of the main solverwith ssi before performing li for first time, and vice versa each time ssi finds a solution.

In this work we reuse this scheme, but, instead of relying on the predefined search strategies ofGecode and ILOG, we use their underlying search mechanisms to model new search strategiesimplementing the intended behavior of the primitives. As the implementation of a new searchstrategy is different in Gecode and ILOG, we present first an abstract specification of the require-ments the new search strategies must fulfill, and then we present separately the adaptation of thisspecification to the technological framework provided by each library. The current versions ofT OY (FDg) and T OY (FD i) are available at: http://gpd.sip.ucm.es/ncasti/TOY(FD).zip

3.1 Abstract Specification of the Search Strategy

We specify a single entry point (C++ function) for the different primitives. Its proposed algo-rithm is parameterizable by the primitive type and its basic components. It fulfills the followingrequirements: (1) The algorithm explores the tree by iteratively selecting a variable var and avalue v, creating two options: (a) Post var == v. (b) Post var /= v to continue the explo-ration taking advantage of the previously explored branch, recursively selecting another value toperform again (a) and (b). (2) For frag* strategies it selects an interval i instead of a value,posting in (a) both var #>= i.min and var #<= i.max. However, the (b) branch can nottake advantage by posting var #< i.min and var #> i.max, as the constraint store wouldbecome inconsistent. Thus, (b) just removes i from the set of intervals, and continue the searchby selecting a new interval. (3) For labB and fragB strategies only the (a) option is tried. (4)For labO and fragO strategies branch and bound techniques are used to optimize the search.(5) Specific functions are devoted to: (i) Variable and (ii) value/interval selection strategies, aswell as to (iii) the bound associated to a particular solution found by labW and fragW. Thosefunctions include the possibility of accessing Prolog, to follow the criteria the user has speci-fied at T OY (FD) level (using T OY (FD) functions compiled to mate Prolog predicates).(6) The primitives labW and fragW perform the breadth exploration of the upper levels of thesearch tree, storing all the satisfiable leaf nodes to further give them (one by one) on demand.Thus, ss contains: (i) An entity performing the search, (ii) A vector DS (cf. Section 2.3) contain-ing the solutions. The notion of solution is abstracted as the necessary information to performthe synchronization from ss to the main constraint solver. (iii) A status indicating whether theexploration has finished or not. (7) The algorithm finishes (successfully) as it founds a solution,except for labW and fragW strategies, where it stores the solution node and triggers an explicit

Improving the Search Capabilities of a CFLP(FD) System8 8 / 15

Page 281: y V Taller de Programación Funcional (TPF)

Search Concept Gecode ILOG SolverSearch trigger Search Engine IloGoal stack

Tree node Space IloGoal attributesNode exploration Brancher Commit IloGoal executionChild generation Brancher Choice IloGoal constructorSolution check Brancher Status Stack with no pending IloAnd

Solution abstraction Space Tree path (var,value) vector register

Table 1: Different Search Concept Abstractions in Gecode and ILOG Solver

failure, continuing the breadth exploration of the tree. (8) A counter is used to control that onlythe specified amount of variables of the variable set is labeled/pruned.

Next two sections adapt this specification to Gecode and ILOG Solver, resp. Table 1 summa-rizes the different notions provided by both libraries.

3.2 Gecode

We have selected Gecode 3.7.3 as the external solver for T OY (FDg) as it is a free softwareconstraint solver with state-of-the-art performance. Search strategies in Gecode are specifiedvia Branchers, which are applied to the constraint solver (Space) to define the shape of thesearch tree to be explored. The Space is then passed to a Search Engine, whose execu-tion method looks for a solution by performing a depth-first search exploration of the tree. Thisexploration is based on cloning Spaces (two Spaces are said to be equivalent if they con-tain equivalent stores) and hybrid recomputation techniques to optimize the backtracking. AsSpaces constitute the nodes of the search tree, a solution found by the Search Engine isa new Space. The library allows to create a new class of Brancher by defining three classmethods: (1) status, which specifies if the current node is a solution, or their children mustbe generated, to continue with their exploration. (2) choice, which generates an object o con-taining the number of children the node has, as well as all the necessary information to performtheir exploration. (3) commit, which receives o and the concrete children identifier to performits exploration (generating a new Space to be placed at that node).

Adaptation to the Specification. The search strategies are implemented via two layers: (I)A new class of Brancher MyGenerate, which carries out the tree exploration by the combi-nation of the status, choice and commit methods. As each node of the tree is a Space,the methods are applied to it. (II) A Search Engine, controlling the search by receiving theinitial Space and making the necessary clones to traverse the tree. Regarding (1), the choicemethod deals with the selection of: (i) The variable var and (ii) The value v, creating an objecto with them as parameters, as well as the notion of having two children. The variable selec-tion must rely on an external register r, being controlled by the Search Engine and thusindependent on the concrete node (Space) the choice method is working with. The registeris necessary to ensure that, whether a father generates its right hand child by posting var /=v, this child will reuse r to select again var (as a difference to the left hand child, which re-moves the r content to select a new variable). Regarding (2), for frag* strategies, instead of

Improving the Search Capabilities of a CFLP(FD) System9 9 / 15

Page 282: y V Taller de Programación Funcional (TPF)

passing val to o, the choice method generates a vector with all the different intervals to betried, and the size of this vector is passed as its number of children. Regarding (3), for labBand fragB only one child is considered. Regading (4), for labO and fragO we use a spe-cialized branch and bound Search Engine provided by Gecode. Regarding (6), the searchentity is the Search Engine and the notion of solution is a Space. Regarding (7), for labWand fragW the Search Engine uses a loop, requesting solutions one by one until no moreare found (the breadth exploration of the search tree has finished). Regarding (8), only the lefthand child of lab* strategies increments the counter value, and the status method checks thecounter to stop the search at the precise moment.

3.3 ILOG Solver

We have selected IBM ILOG Solver 6.8 as the external solver for T OY (FD i) as it is an indus-trial market leader for solving generic FD problems. It belongs to the ILOG CP 1.6 package,which contains the ILOG Concert 12.2 modeling library and two other solver libraries for spe-cific scheduling and routing problems. Thanks to the IBM academic initiative these products arefree for academic purposes. Search strategies in ILOG Solver are performed via the executionof IloGoals. An IloGoal is a daemon characterized by its constructor and its executionmethod. The constructor creates the goal, initializing its attributes. The execution method trig-gers the algorithm to be processed by the constraint solver (IloSolver), and can include morecalls to goal constructors, making the algorithm processed by IloSolver to be the conse-quence of executing several IloGoals. We say that an IloGoal fails if IloSolver be-comes inconsistent by running its execution method; otherwise the goal succeeds. The libraryallows to create a new class of IloGoal by defining its constructor and execution method.Four basic goal classes are provided for developing new goals with complex functionality. GoalsIlcGoalTrue and IlcGoalFalse make the current goal succeed and fail, resp. GoalsIlcAnd and IlcOr, both taking two subgoals as arguments, make the current goal succeeddepending on the behavior of its subgoals. While IlcAnd succeeds only if its two subgoalssucceed, IlcOr creates a restorable choice point which executes its first subgoal, restores thesolver state at the choice point on demand, and executes its second subgoal.

Adaptation to the Specification. The search strategies are implemented via the new IloGoalclasses MyGenerate and MyInstantiate. Whereas the former deals with the selection of avariable, the latter deals with its binding/prunning to a value/interval. Regarding (1), the controlof the tree exploration is carried out by MyGenerate, which selects a variable and uses the re-cursive call IlcAnd(MyInstantiate, MyGenerate) to bind it and further continue pro-cessing a new variable. In MyInstantiate, the alternatives (a) and (b) are implemented withan IlcOr(var == val, IlcAnd(var /= var, MyInstantiate)). Regarding (2),it dynamically generates a vector with the available intervals on each different MyGeneratecall. Regarding (3), only the goal var == val is tried. Regarding (4), we explicitly imple-ment the branch and bound. Thus, before selecting each new variable, we check if the currentoptimization variable can improve the bound previously obtained; otherwise an IloGoalFailis used to trigger backtracking (as well as if, after labeling the required variables, the obtainedsolution does not bind the optimization variable). Regarding (6), the entity performing the searchis an IloSolver. Also, the notion of solution is given by: (i) A vector of integers, representing

Improving the Search Capabilities of a CFLP(FD) System10 10 / 15

Page 283: y V Taller de Programación Funcional (TPF)

the indexes of the labeled/pruned variables. (ii) A vector of pairs, representing the assigned valueor bounds of these variables. This explicit solution entity is built towards the recursive calls ofMyGenerate, which adds on each call the index of the variable being labeled. Once found thesolution, it stores (i) and (ii) in DS. Regarding (7), after storing a solution in labW or fragW anIloGoalFalse is used, triggering backtracking to continue the breadth exploration. Regard-ing (8) each call to MyGenerate increments the counter value.

3.4 TOY(FD) Architecture

The resulting T OY (FD) architecture supporting the search primitives is presented in Fig. 4.It contains five different layers:

(1) The T OY (FD) interpreter. It allows to impose the user commands. In Fig. 4 thegoal proposed in Section 3.1 is to be solved. Besides its FD constraints domain and /=,there is a lab strategy. The user is specifying its own variable and value selection criteria by

TOY(FD)> domain [X,Y,Z] 0 4, Y /= 1,Y /= 3, Z /= 2, lab userVar userVal 2 [X,Y,Z]

TOY

SICStus

C++

bool post_constraint(…) … bool start_search(…) … bool get_next_solution (…) …

MyProgram.toy

from:: int [int]myVarOrder:: [int] intmyValOrder:: [[int]] int

FD.toy

domain:: [int] int int bool lab:: varOrd valOrd int [int] boolget_dom:: int [[int]]

PROMPT

MyProgram.pl

myVarOrder(…) :- get_dom … .

FD.pl

get_dom ( …) :- p1, pl_get_dom, … p2.

solver.pl

pl_domain cpp_domainpl_get_dom cpp_get_dompl_search_strategy cpp_search_strategy

….

solver.cpp

void cpp_domain( … ) … void cpp_get_dom( … ) … void cpp_search_strategy( … ) …

solver_glue.c ….

solver_glue.h ….

int selectVar(…) … int selectVal(…) … int get_best_node(…) …

Solver Search Methods

SOLVER API

Figure 4: T OY (FD i) Architecture

Improving the Search Capabilities of a CFLP(FD) System0 11 / 15

Page 284: y V Taller de Programación Funcional (TPF)

using the functions myValOrder and myVarOrder, resp., which rely on auxiliary, preludeand reflection functions (as, for example, from, get dom and map, respectively).

(2) The T OY (FD) files defining the language. They include: (i) A file Prelude.toy,to specify the prelude functions (as map), (ii) A devoted file FD.toy, specifying the set of FDconstraints supported, and (iii) A file MyProgram.toy with the user definitions (includingfrom and myVarOrder).

(3) The SICStus implementation of T OY (FD). It includes Prolog mate files for (i), (ii)and (iii), implementing all the T OY (FD) datatypes, functions and operators supported by thesystem and defined by the user. The file solver.pl supports the communication from SICStusto C++ by specifying the set of SICStus predicates S being implemented in C++ functions.

(4) The C++ interface to the solver. It includes: (a) The file solver.cpp, containing theset of C++ functions implementing S, and (b) The auxiliary files containing the extra C++ func-tions, data structures and new solver specific classes extending the library (needed to implementS). This includes the new C++ class MyGenerate in Gecode and ILOG Solver (the latter alsoincluding MyInstantiate). They are devoted to implement the lab strategy, and containmethods for the variable and value selection. Fig. 4 shows how these methods can access eitherto the solver API (if a predefined criteria is being selected), or (focusing on the variable selec-tion criteria) come back to the SICStus file MyProgram.pl, executing the SICStus predicatemyVarOrder (implementing the user T OY (FD) function myVarOrder). In our example,the latter case holds, and we can see how the execution traverses the SICStus and C++ layers, as acycle is performed between the SICStus predicate myVarOrder, its auxiliary SICStus predicateget dom (which belong to S) and its C++ implementation in solver.cpp.

(5) The C++ API of the solver. Accessed by the C++ methods interfacing the solver. In thecase of Gecode, this layer also includes the proper solver implementation, as it is open software.

4 Performance Analysis

In this section we present a preliminary although encouraging performance analysis of theT OY (FD) search primitives, devoting a specific case study for each novel concept alreadypresented. On each case we select a constraint satisfaction/optimization problem (either a pureclassical CP(FD) benchmark from the CSPLib [CSP12] or a real-life problem) and we describehow the use of a concrete search strategy increases the solving efficiency of the problem.

labB: n-magic sequence. When n ≥ 9 the sequence follows the pattern: L ≡ [(n− 4),2,1,0,0, . . . ,1,0,0,0]. Although the use of first-fail (labeling [ff] L) turns the solving of anyn-sequence into ' 0ms, the initial search space this search departs from can be huge. Forexample, n = 9 contains an initial search space of 77,760 candidates. In this context, foreach n ≥ 9, applying before labB unassignedRightVar smallestVal 3 L, labBunassignedRightVar largestVal 1 L captures the last four variable 1,0,0,0 pattern,whose propagation lead to L≡ [(n−4),A,B,C,0, . . . ,1,0,0,0] (with A in 1..3, B in 0..1 and C in0..1), dramatically reducing the search space the labeling has to deal with. However, we areinterested in examples in which search space reduction (because of the application of our searchstrategies) also implies a better solving efficiency for the problem.

Employee Timetabling Problem. The real-life problem [CS13] optimizes the timetabling ofa department. Relying on the seed approach presented in [R. 07] for solving a former non-

Improving the Search Capabilities of a CFLP(FD) System11 12 / 15

Page 285: y V Taller de Programación Funcional (TPF)

optimization version of the problem, we use now the labB strategy to find an optimal seed, i.e.,a variable-subset-binding (a different one for each of the independent subproblems being solved)which matches the one of the optimal timetabling solution. For example, for the 21 timetablinginstance of the [CS13] T OY (FD) model, applying labB unassignedLeftVar small-estVal 2 (extract TCal) before performing the labeling of each subproblem: (1)Finds an optimal seed, (2) Reduces the solving time of the problem to a 94% in Gecode.

labW: langford’s number problem. A deep breath exploration of the search tree with labWsupposes a tradeoff between: (1) Obtaining an ordered hierarchy of interesting intermediate tree-level nodes and (2) The computational effort to obtain such this hierarchy. In this context, apply-ing labW smallestMinValueVar smallestSearchTree 3 L to langFord (2,4)directly finds a solution, i.e., not even a further labeling is necessary. However, the timelabW spends is bigger than the one of running labeling to the whole search tree, so the useof labW does not pay-off. Fortunately it does when applying labW largestMinRegretVarsmallestSearchTree 2 L to langFord (3,19), where the use of labW does not finddirectly a solution, but the sum of time for obtaining the hierarchy and applying the labelingto the remaining space takes a 65% of time less in Gecode than applying straight the labeling.

fragB: n-queens. The formulation of the n-queens problem based on global (all di f f erent)constraints becomes much more efficient than the one using single disequality constraints, withsome n-queens instances for which the former finds a solution in a few seconds whereas the lat-ter can not find anyone after hours. The right hand side of Fig. 1 (cf. Section 2.1) presents anintuitive way for reducing the initial search space of the problem: (1) Split the n variables intok variable sets (vs1,vs2, . . . ,vsk) (where consecutive variables are placed in different variablesets), (2) Split the initial domain 1 . . .n into k different intervals (1..(n/k), . . . ,(n/k) ∗ (i− 1)+1..(n/k)∗ i, . . . ,(n/k)∗ (k−1)+1..n), (3) Assign the variables of vsi to the ith interval. The ap-plication of split into 3 L ([],[],[]) == (K1,K2,K3), fragB (partition 3)unassignedLeftVar firstRight 0 K1, fragB (partition 3) unassigned-LeftVar firstMiddle 0 K2, fragB (partition 3) unassignedLeftVar first-Left 0 K3 implements the approach with k = 3 sets, solving the 75-queens instance in just onesecond in Gecode (whereas it is not solved after twelve hours without using the strategy).

fragW: n-Golomb rulers. The classical formulation of the problem leads to a huge initialsearch space. The initial domain of the last three rulers in 11-Golomb is H in 36..1020, I in45..1021 and J in 55..1023 (with know optimal solution 64, 70 and 72, resp.) whereas the one ofthe first three rulers is 0, A in 1..977 and B in 3..987 (with know optimal solution 0, 1 and 4, resp.)In this context, an intuitive way of reducing the initial search space is by reducing so much the up-per bound of these variables. Applying fragW (partition 3) unassignedRightVarsmallestSearchTree 3 L, fragW (partition 15) unassignedLeftVar larg-estSearchTree 2 L fragments first the last three variables and then the first three. Note that,whereas the former selects as best intermediate node the one minimizing the remaining searchspace, the latter select the one maximizing it (which intuitively makes sense, as the smaller in-terval is the one pruning the less the upper bound of the first three variables). The use of thesestrategies reduces the solving time of the problem to a 88% in Gecode.

Results: The obtained results are summarized in Table 2. The first column represents theproblem being solved. Next two blocks of three columns represent respectively the results ofGecode and ILOG: Elapsed time (measured in milliseconds) without/with using the strategy and

Improving the Search Capabilities of a CFLP(FD) System12 13 / 15

Page 286: y V Taller de Programación Funcional (TPF)

Problem G G* G*/G I I* I*/I G/I G*/I*ETP 24,710 1,465 0.06 54,351 4,570 0.08 0.45 0.32

Langford 624 218 0.35 1,014 827 0.82 0.62 0.26Golomb 42,869 5,320 0.12 75,365 9,687 0.13 0.57 0.55Queens - 1,622 ' 0.00 - 4,306 ' 0.00 ' 0.00 ' 0.00

Table 2: Case Studies of T OY (FD) Search Strategies Application

slow-down of the latter w.r.t. the former, resp. Finally, columns 8 and 9 represent the slow-downof Gecode w.r.t. ILOG Solver without/with using the search strategy, resp.

The results show that the use of the search strategies improve the solving performance of thecase studies both in Gecode and ILOG Solver (making them from 1.25 to 20 times faster, or evensolving instances that were not possible before). However, the impact of the search strategiesis not the same in both systems, i.e., Gecode is faster than ILOG Solver both with/without thesearch strategies, but the ratio is bigger when using the search strategies. As both systems arerunning exactly the same T OY (FD) model, we claim that the approach Gecode offers toextend the library with new search strategies is more efficient than the ILOG Solver one.

Benchmarks are run in a machine with an Intel Dual Core 2.4Ghz processor and 4GB RAMmemory. The OS used is Windows 7 SP1. The SICStus Prolog version used is 3.12.8. Mi-crosoft Visual Studio 2008 tools are used for compiling and linking the T OY (FD i) andT OY (FDg) C++ code. The different models being used as case studies are available at:http://gpd.sip.ucm.es/ncasti/models.zip.

5 Conclusions and Future Work

We have described the integration of new parametric search primitives in the systems T OY (FDg)and T OY (FD i). Our approach benefits both from the high expressivity of T OY (FD) andof the high efficiency of Gecode and ILOG Solver, and can be easily adapted to other CLP orCFLP systems implemented in Prolog and interfacing external CP(FD) solvers with a C++ API.

We have described the primitives, pointing out novel concepts they include, as perform anexhaustive breadth exploration of the search tree further sorting the satisfiable solutions by anspecified criteria, fragment the variables pruning each one to a subset of its domain values insteadof binding it to a single value, and applying the labeling or fragment strategy only to a subsetof the variables involved. We have seen how expressive, easy and flexible it is to specify somesearch criteria at T OY (FD) level, as well as how easy is to combine some search strategiesto set different search scenarios. We have described an abstract view of the eight requirementsneeded to integrate the search strategies in T OY (FD). We have presented the implementationin Gecode and ILOG Solver, by matching each abstract concept to the concrete one providedin the library. We have seen the resulting architecture of the system, pointing out its five layersand the interaction between them. We have presented five case studies (using classical CP(FD)benchmarks and a real-life problem) to point out that the use of the search strategies improve theT OY (FDg) and T OY (FD i) solving performance, and that the approach Gecode offers toextend the library with new search strategies is more efficient than the ILOG Solver one.

Improving the Search Capabilities of a CFLP(FD) System13 14 / 15

Page 287: y V Taller de Programación Funcional (TPF)

As future work, we will use scripting for applying the search strategies to classical CP(FD)benchmarks under multiple and very precisely controlled scenarios. We will use data miningtechniques over the obtained results, to find out some patterns about the relation between thestructure of a problem and the concrete search strategies to be applied.

Bibliography

[CS12] I. Castineiras, F. Saenz-Perez. Improving the Performance of FD Constraint Solvingin a CFLP System. In FLOPS’12, 88–103. LNCS 7294. Springer, 2012.

[CS13] I. Castineiras, F. Saenz-Perez. Applying CP(FD), CLP(FD) and CFLP(FD) to a Real-Life Employee Timetabling Problem. Procedia Computer Science 18(0):531 – 540,2013.

[CSP12] CSPLib. A Problem Library for Constraints. 2012. http://www.csplib.org/.

[FHSV07] A. J. Fernandez, T. Hortala-Gonzalez, F. Saenz-Perez, R. del Vado-Vırseda. Con-straint Functional Logic Programming over Finite Domains. In TPLP 7, 5, 537–582.Cambridge University Press, 2007.

[Han07] M. Hanus. Multi-Paradigm Declarative Languages. In ICLP’07, 45–75. LNCS 4670.Springer, 2007.

[IBM10] IBM ILOG CP 1.6. 2010. http://www-947.ibm.com/support/entry/portal/Overview/Software/WebSphere/IBM ILOG CP.

[JM94] J. Jaffar, M. Maher. Constraint Logic Programming: A Survey. In The Journal of LogicProgramming, 19–20. 503–581. Elsevier, 1994.

[LLR93] R. Loogen, F. Lopez-Fraguas, M. Rodrıguez-Artalejo. A Demand Driven ComputationStrategy for Lazy Narrowing. In PLILP’93, 184–200. LNCS 714, 1993.

[Mat12] Mats Carlsson et. al. SICStus Prolog User’s Manual. 2012. http://www.sics.se/.

[MS98] K. Marriott, P. J. Stuckey. Programming with Constraints. MIT Press, 1998.

[PJ02] S. Peyton-Jones. Haskell 98 Language and Libraries: the Revised Report. 2002. http://www.haskell.org/onlinereport/.

[R. 07] R. Gonzalez-del-Campo and F. Saenz-Perez. Programmed Search in a TimetablingProblem over Finite Domains. In ENTCS, 177, 253–267. Elsevier, 2007.

[STL12] C. Schulte, G. Tack, M. Z. Lagerkvist. Gecode 3.7.3: Generic Constraint DevelopmentEnvironment. 2012. http://www.gecode.org/.

[STL13] C. Schulte, G. Tack, M. Z. Lagerkvist. Modeling and Programming with Gecode.2013. http://www.gecode.org/doc-latest/MPG.pdf.

[Tsa93] E. Tsang. Foundations of constraint satisfaction. Academic Press, 1993.

Improving the Search Capabilities of a CFLP(FD) System14 15 / 15

Page 288: y V Taller de Programación Funcional (TPF)

From UML State-Machine Diagrams to Erlang∗

Ricardo J. Rodrıguez, Lars-Ake Fredlund, Angel Herranz

Babel Group, DLSIIS, Facultad de InformaticaUniversidad Politecnica de Madrid, Spain

rjrodriguez, lfredlund, [email protected]

Abstract: The Unified Modelling Language (UML) is a semi-formal modellinglanguage useful for representing architectural and behavioural aspects of concur-rent and distributed systems. In this paper we propose a transformation from UMLState-Machine diagrams to Erlang code. Erlang is a functional language, with strictevaluation, single assignment, and dynamic typing, and with good support for con-currency and distribution. The contribution of this transformation is twofold: it canreduce development time, and moreover it permits us to validate UML diagrams atan early development stage through the use of Erlang-based model checking tech-niques.

Keywords: UML, Erlang, automatic code generation

1 Introduction

The Software Development Life-Cycle (SDLC) [GJM02] is a process methodology that definesthe phases involved for developing and maintaining software systems and software code. Oneof these phases is thedeployment and maintenancephase, where the software is deployed intoproduction and it is maintained to cope with possible faultsor minor changes on current require-ments. To verify the correctness of the developed software before it is deployed into productioncan save efforts as problems are detected before arise. A widely used approach for the formalverification of software is model checking [CGP99, BBF+10]. Model checking automaticallyprovides complete proofs of correctness, and explains using counter-examples why a softwaresystem or software code is not correct.

In this paper, we provide an approach to be able to verify a software design during design phasethrough model-checking techniques (more precisely, by using Erlang-based model-checkingtechniques). This early verification step would improve theSDLC, as design problems can bedetected during design phase and not at the end of the process, thus saving efforts and economiclosses due to redesign and/or reimplementation. This approach is based in a transformation fromUML diagrams (namely, UML State-Machine diagrams (UML-SMs)) to Erlang code. Since anumber of effective verification and validation tools are available for Erlang, e.g., the QuviqQuickCheck random testing tool [AHJW06] and the McErlang model checker [FS07], we canuse these tools to verify the transformed UML diagram. The well-known dining philosophersproblem is used as a motivation example in this paper.

∗ This work was partially supported by ARTEMIS Joint Undertaking nSafeCer under grant agreement no. 295373and from National funding.

From UML State-Machine Diagrams to Erlang 1 / 12

Page 289: y V Taller de Programación Funcional (TPF)

The UML (Unified Modelling Language) [OMG05] is a standardde factomodelling language,commonly used by software engineers for high-level system design. UML provides several typesof diagrams which allow to capture different aspects and views of the system. A UML modelof a system consists of several diagrams which represent thefunctionality of the system, itsstatic structure, the dynamic behaviour of each system component and the interactions amongthe system components.

Erlang [Arm97] is a functional and concurrent programming language commonly used forthe development of distributed, fault-tolerant, soft-real-time, and non-stop applications [Wik94,AVWW96, Lar09].

The contribution of this transformation is twofold: firstly, it can minimise development timeas it automatically generates Erlang code from UML-SMs, andsecondly it enables us to applyErlang-based model-checking techniques to UML specifications. This transformation can saveefforts and future costs produced by a redesign and/or reimplementation of a designed softwareat the end of its SDLC. Besides, to the best of our knowledge, our proposal is the first one thethat provides an automatic generation of Erlang code from UML-SMs.

The remainder of this paper is as follows. Section2 introduces some concepts in more de-tail, such as UML-SMs and the Erlang programming language. Then, Section3 introduces ourapproach to transform a UML-SM into Erlang code. Section4 discusses some approaches inthe literature relevant to our work. Lastly, Section5 provides concluding remarks and futureresearch directions.

2 Background

In this section we provide some background needed to follow the rest of this paper. In first place,we introduce the UML State-Machine diagrams (UML-SMs). Finally, the Erlang programminglanguage is introduced.

2.1 UML State-Machine Diagrams

The Unified Modelling Language (UML) [OMG05] provides several types of diagrams that al-low to capture different aspects and views of the system. UMLdiagrams can be categorisedin: static diagrams, which are intended to model the structure (logical and architectural) of thesystem;behavioural diagrams, which are intended to describe system dynamics (its dynamicbehaviour and the interactions among the system components); and organisational diagrams,which allows to reduce the complexity of the system by organising it in a modular way.

In this paper, we focus on UML State-Machine diagrams (UML-SMs) that model the dynamicbehaviour of a system through finite state-transitions. We assume that such a system is composedof several components intercommunicated among them by sending asynchronous messages. TheUML-SM semantics is the one proposed by Harel in [Har87] for state-charts. Graphically, aUML-SM is a directed graph in which nodes denote states and connectors denote state transi-tions. A state is represented by a rounded rectangle labelled with a state name, while transitionsare represented by arrows labelled with the triggered events followed (optionally) by effects. Atransition can optionally have a guard, indicated between brackets. The initial transition origi-

From UML State-Machine Diagrams to Erlang 2 / 12

Page 290: y V Taller de Programación Funcional (TPF)

Figure 1:Dining philosophers: A UML State-Machine diagram (UML-SM) of a philosopher.

nates from a solid circle and sets the default state where system begins. The final transition endsin a solid circle surrounded by an empty circle.

Figures1 and2 show UML-SMs describing the behaviour of a philosopher and afork of the“dining philosophers” example. We assume that the thinkingtime of each philosopher is equalto 1000 units of time. We also assume that each philosopher first grabs his left fork, and thenhe waits holding it until his right fork can be acquired. Notethat this “eating protocol” leadsto a deadlock, i.e., a situation where philosophers are waiting for some event which will neverhappen.

The initial transition of a philosopher in Figure1 needs two parameters,fL andfR, which rep-resents respectively his left and right forks. Note that in the corresponding UML class diagramPhilosopher class would have a double association withFork class, thus this initial param-eters would be not longer needed. The first state of a philosopher isThinkingstate. This state hasa do action, which sets a timeout of a duration equal to 1000 units of time. The single exit tran-sition of this state has a guard that indicates the timeout has expired, and an effect of sending anasynchronousacquire(self) message tofL. After sending such a message, a philosophermoves toHungry state. From this state he moves toWaiting state when an eventacquiredis received, and sends also anacquire(self) message tofR. Once theacquired eventis received, a philosopher enters toEatingstate, where starts theeatSpaghetti() do activ-ity. When this activity has finished, therelease() message is sent to bothfL andfR beforeexisting the state and move toThinkingstate, starting the cycle again.

The behaviour of a fork, depicted in Figure2 is much simpler. It starts inIdle state, and movesto BeingUsedwhen it receives anacquire(p) event. This parameterp is the philosopher whotriggers the event. When entering in theBeingUsedstate, it sends anacquired event top, asindicated by theentry activity. The statementacquire / defer in BeingUsedindicatesthat allacquire events received in this state are deferred, i.e., stored forlater handling. Whentherelease event is received, a fork moves toIdle state, starting its cycle again. Note that adeferred event could trigger immediately the transition totheBeingUsed state.

2.2 The Erlang Programming Language

Erlang [AVWW96] is a functional concurrent programming language created by the Ericssoncompany in the 1980s. Ericsson is still maintaining the mainErlang implementation, but it isavailable as open source since 1998. The chief strength of the language is that it provides excel-

From UML State-Machine Diagrams to Erlang 3 / 12

Page 291: y V Taller de Programación Funcional (TPF)

entry / p.acquired()

acquire / defer

BeingUsedIdle

release

acquire(p)

Figure 2:Dining philosophers: A UML State-Machine diagram (UML-SM) of a fork.

lent support for concurrency, distribution and fault tolerance on top of a dynamically typed andstrictly evaluated functional programming language. Concurrency is achieved by lightweightprocesses communicating through asynchronous message passing. Although Erlang is not a newlanguage, it has experienced considerable growth in users in recent years. This is due in most partto its focus on message passing instead of variable sharing as the main communication mecha-nism, which enables programmers to write robust and clean code for modern multiprocessor anddistributed systems.

Today Erlang is used by Ericsson and many other companies (T-Mobile (UK), and manysmaller start-up companies such as e.g. Interoud in Spain and Klarna in Sweden) to developindustrial applications, often implementing crucial internet server-side applications. Examplesinclude a high-speed ATM switch developed at Ericsson with over a million lines of Erlangcode which had to meet very challenging requirements on software reliability and overall systemavailability [BRA+99, WAB02], parts of Facebook chat, Apache CouchDB – a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSONAPI, etc.

3 A Transformation Approach

This section introduces the transformation approach from UML State-Machine diagrams (UML-SMs) to Erlang code. The aim of this section is to show how our approach works. Basically, foreach UML-SM, an Erlang module is generated following the steps described in Algorithm1.

The transformation algorithm of the approach is described in Algorithms1 and2, as pseudo-code. As input, it receives a UML-SMD . As output, it returns an Erlang moduleE with thesame behaviour asD .

Let us recall how this transformation algorithm works by means of the running example as de-fined by the UML-SMs depicted in Figures1 and2. The Erlang code generated by Algorithms1and2 is listed in Code1 and2.

First, let us consider the UML-SM in Figure1 that describes the behaviour of a philosopher.In the translation, the two initial parametersfL, fR of the initial transition are stored in a setP.The setP is passed along as a parameter tostart and of all other Erlang functions. In the setE we collect all the events of the UML-SM that is being transformed. This is needed because,unlike Erlang messages, UML events sent between different UML-SMs are lost if they are nothandled in the current state of a UML-SM. Then, themodule andexport Erlang compilerattributes are output. Each UML-SM transformed to Erlang has a dedicated functionstartwhich is used to create a new Erlang process executing the (translated) state machine.

The first state is theThinking state. An Erlang function is defined with that name, and re-

From UML State-Machine Diagrams to Erlang 4 / 12

Page 292: y V Taller de Programación Funcional (TPF)

Input : A UML-SM D

Output : An Erlang source fileE

1 Store inP the parameters of the initial transition inD2 Create a module named asD and anexport declaration ofstart function3 Create astart function with parametersP and invoke the first stateS of D

4 Create a set of eventsE containing all trigger events inD5 forall the stateS of D do6 Create a functionF with parametersP named as stateS7 Execute Algorithm2 with entry activity as input (if any), and invoke the result8 Execute Algorithm2 with do activity (if any)9 if stateS has not ado activity calledsetTimeout then

10 Execute Algorithm2 with do activity, and invoke the result11 end12 if stateS has output transitionsthen13 if some output transition has a guard and/or a triggered eventthen14 Create an Erlang receive skeleton15 forall the output transitionO of S triggered by an eventdo16 Map the event ofO to an Erlang message reception17 Create awhen clause if output transitionO has a condition guard18 Execute Algorithm2 with output transitionO, and invoke the result19 Invoke the Erlang function that represents theexit action (if any)20 Invoke the functionF ′ representing the destination ofO

21 end22 if exists some event inE not deferred inS and not handledthen23 Create an Erlang code to ignore such an event by invokingF

24 end25 if stateS has ado activity calledsetTimeout and an output transitionO is

triggered when the timeout has expiredthen26 Create anafter clause27 Execute Algorithm2 with output transitionO, and invoke the result28 Invoke the Erlang function that represents theexit action (if any)29 Invoke the functionF ′ representing the destination ofO

30 end31 end32 Invoke the Erlang function that represents theexit action (if any)33 Invoke the functionF ′ representing the destination ofO

34 else35 Invoke the Erlang function that represents theexit action (if any)36 end37 end

Algorithm 1: A transformation from UML State-Machine diagrams to Erlangcode.

From UML State-Machine Diagrams to Erlang 5 / 12

Page 293: y V Taller de Programación Funcional (TPF)

Input : A stateS and an activityAOutput : A piece of Erlang code

1 if A concerns another state machineS M ′ then2 Send a message with the mappedA (and parameters) to the Erlang process

corresponding to state machineS M ′

3 else4 MapA to Erlang code5 end

Algorithm 2: Transformation of any activity to Erlang code.

Code 1: Erlang code generated from basic UML-SM in Figure1.-module(philosopher).-export([start/2]).

start(FL, FR) ->spawn(fun() -> thinking(FL, FR) end).

thinking(FL, FR) ->receive

X -> thinking(FL, FR)after 1000 -> FL!acquire, self(), hungry(FL, FR)

end.

hungry(FL, FR) ->receive

acquired -> FR!acquire, self(), waiting(FL, FR)end.

waiting(FL, FR) ->receive

acquired -> eating(FL, FR)end.

eating(FL, FR) ->eatSpaghetti(),FL!release,FR!release,thinking(FL, FR).

From UML State-Machine Diagrams to Erlang 6 / 12

Page 294: y V Taller de Programación Funcional (TPF)

Code 2: Erlang code generated from basic UML-SM in Figure2.-module(fork).-export([start/0]).

start() ->spawn(fun() -> idle() end).

idle() ->receive

acquire, P -> beingUsed(P);X -> idle()

end.

beingUsed(P) ->P!acquired(),receive

release -> idle()end.

ceiving the parameters contained inP. Thedo activity setTimeout and the conditional exittriggerTOUT expired are assumed to represent a timeout activation and expiration in UML-SMs, and generate areceive clauseafter with a timeout corresponding to the parameterof thesetTimeout activity. As there are events that are not handled in this state and it hasoutput transitions triggered by events, areceive clause receives any value and recurses. TheeffectfL.acquire(self) is transformed to a signalcquire, self()acquire, self()

sent tofL in Erlang code. Finally the function that represents theHungrystate is called. Thisstate has only an exit transition triggered by theacquired event; the construct is translatedinto areceive clause receivingacquired. The effect of this event sends a signalcquire,

self()acquire, self() to fR and calls the function that represents theWaiting state. Aspreviously, areceive clause is output where receivingacquired results in a call to the func-tion corresponding to theEating state. Finally, thedo andexit activities are transformedto their equivalent Erlang code. More precisely, the exit activity that involves invocations ofrelease() method infL andfR are transformed toFL!release andFR!release in Er-lang.

Let us consider now the UML-SM of the behaviour of a fork (Figure 2). The set ofparameters of the initial transition (none) is stored inP. Then, module(fork) andexport([start/0]) compiler attributes are created in Erlang code. After this,thestartfunction spawns a new process which behaves as the initial state of the state machine (theIdlestate). As before, all the events of this UML-SM are stored ina setE (in this case,acquireandrelease).

The UML-SM depicted in Figure2 has two states,Idle andBeingUsed. Let us focus first onthe Idle state. A functionidle() is created, without parameters, representing this state. Thisstate does not have anentry activity, nor ado activity. It has just an output transition triggeredby an eventacquired(p), that is mapped to the reception of a message with a parameterP.

From UML State-Machine Diagrams to Erlang 7 / 12

Page 295: y V Taller de Programación Funcional (TPF)

When received, it invokes the functionbeingUsed(), which represents the other state ofD .As the eventrelease is not handled in this state, an clause that handles any message is outputinvoking itself.

Theentry action ofBeingUsedis mapped to a sending of anacquired message toP, asidentified by Algorithm2). As before, it has an output transition triggered by thereleaseevent. When received, it invokes theidle() function, returning to the initial state. In thiscase, as theacquire event is deferred, there is no need to include a clause receiving any othermessage.

Finally, note how theabsenceof an aquire / defer statementinidle gives rise to anErlang receive clauseX ->idle() in Idle, whereas theoccurrenceof an aquire /defer statement in the stateBeingUsed results in the absence of the corresponding receiveclauseX ->beingUsed(). Thus a signalcquire,P’acquire,P’ that arrives in the stateBeingUsed is not thrown away butdeferred, i.e., stored and later handled in theIdle state.

The Erlang code resulting from the transformation can be checked using theMcErlangmodel checker [FS07] without modifications. We can for example compose a system of N

philosophers in Erlang using the function callrun(N) below (located in the moduledining):

run(N) ->Forks = lists:map (fun (_) -> fork:start() end, lists:seq(1,N)),lists:foreach

(fun (L,R) -> philosopher:start(L, R) end, adjacent(Forks)).

adjacent([]) -> [];adjacent([X|Xs]) -> lists:zip([X] ++ Xs, Xs ++ [X]).

InvokingMcErlang to check whether a configuration of two philosphers is deadlock free hasthe following result:

$ erl> mce:start

(#mce_optsprogram=fun () -> dining:run(2) end,monitor=mce_mon_deadlock).

...

*** Monitor failedmonitor error:deadlock

As we commented in Section1, the dining philosophers problem modelled as illustrated inFigures1 and2 has a deadlock problem which evidently was detected by theMcErlangmodelchecker.

4 Related Work

Automatic code generation from formal specifications is considered one of the silver bullet ofsoftware engineering. In this respect, state machines is one of the most successful formalismsince its semantics is directly executable. UML state-charts is a variation of state machines so itis not strange that countless automatic code generation approaches can be found in the literature.

From UML State-Machine Diagrams to Erlang 8 / 12

Page 296: y V Taller de Programación Funcional (TPF)

The single-threaded approach is simple and theinherent synchronousview of operations isrelatively straightforward to compile into ordinary programming language constructs: case state-ments and function calls [HG96].

Here we restrict the consideration of related works to the more complex problem of automaticcode generation for state-charts with multi-threaded behaviour and asynchronous communication(signals).

Most of such works rely on the implementation of a general interpreter that captures the exe-cutable semantics of a particular specification language. Given a set of concrete state machineswritten in a specification language, a translator compiles them into structures to represent states,nodes and transitions that the general interpreter operates on. Relevant works following thisroad are for example [PM03, AFL+10] (C code from extended finite state machines with a syn-chronous semantics for the moment), [NT03, KNNZ00] (asynchronous semantics with a statetable to reacts to events), [TKUY01] (based on design pattern forms implementing state ma-chines), [KM02] (with a Java thread per state-chart and Java objects to represent event queues).

All these works relies on the ability of the interpreter to manage multi-threading and eventqueues, two aspects where the Erlang programming language is particularly strong. As a con-sequence of the excellent support available in an Erlang run-time system for multiprogramming,in our approach no such interpreter is needed. Instead state-machine concepts such as machines,state, nodes and transitions are directly compiled into Erlang efficient constructs: processes, callby value function calls, efficient message passing, and event queues. As a result we expect ourimplementation of UML state-machines in Erlang to be very high-performing with regards toperformance criteria such as the maximum number of messagessent per seconds, the maximumnumber of concurrent state machines supported, etc. We aim at performing some experimentsfor comparing performance results as future work.

Other works that worth to be mentioned transform state-charts to other models that are ver-ifiable, such as [GLM99, LMM99, CEC12]. In [GLM99], a branching time model-checkingapproach is presented for automatically verify the correctness of UML-SMs using JACK as ver-ification environment. The work in [LMM99] introduces an approach where linear-time modelchecking of UML-SMs is addressed by translating them to PROMELA, the modelling languageof the SPIN model-checker. In [CEC12], UML class diagrams, UML-SMs and UML Commu-nication diagrams are considered and automatically transformed to a model that can be verifiedby means of Maude LTL model checker.

5 Conclusions

The Unified Modelling Language (UML), ade factostandard as semi-formal modelling lan-guage, provides several types of diagrams that can capture different aspects and views of a mod-elled system. For instance, UML is useful for representing architectural and behavioural aspectsof concurrent and distributed systems.

This paper explores the idea of automatic transformation from UML State-Machines diagrams(UML-SMs), which describe the dynamic behaviour of a system, to the Erlang programming lan-guage. Erlang is a functional language, with strict evaluation, single assignment, and dynamictyping, and with good support for concurrency and distribution. The contribution of this trans-

From UML State-Machine Diagrams to Erlang 9 / 12

Page 297: y V Taller de Programación Funcional (TPF)

formation can be summarized:

• It can reduce development time by automatically generatingErlang skeleton code fromUML diagrams; and

• it enables validation of UML-SMs at an early development stage through the use of Erlang-based model checking and testing techniques.

Besides, this transformation also provides an alternativebehavioural code pattern comple-menting frequently used Erlang code patterns (libraries) such as e.g. the generic server librarygen_server and the finite-state machine librarygen_fsm.

As future work, we plan also to significantly extend the scopeof the transformation to providesupport for additional UML-SM constructs. For example, we would like to provide supportfor preemptive UML-SM activities in Erlang. Moreover, supporting UML-SM constructs suchas e.g. sub-states, entry, exit or alternative points, and call actions would be highly beneficial.Lastly, we aim at developing a plugin for some UML CASE tool (such as Papyrus, MagicDrawor ArgoUML) to package the transformation.

Bibliography

[AFL+10] D. Arney, S. Fischmeister, I. Lee, Y. Takashima, M. Yim. Model-Based Program-ming of Modular Robots. InProceedings of the 13th IEEE International Sym-posium on Object/Component/Service-Oriented Real-Time Distributed Computing(ISORC). Pp. 66–74. 2010.

[AHJW06] T. Arts, J. Hughes, J. Johansson, U. Wiger. Testingtelecoms software with QuviqQuickCheck. InProceedings of the 2006 ACM SIGPLAN Workshop on Erlang(ERLANG). Pp. 2–10. ACM, New York, NY, USA, 2006.

[Arm97] J. Armstrong. The development of Erlang.ACM SIGPLAN Notices32(8):196–203,Aug. 1997.

[AVWW96] J. Armstrong, R. Virding, C. Wikstrom, M. Williams. Concurrent Programming inErlang. Prentice Hall, 2nd edition, 1996.

[BBF+10] B. Berard, M. Bidoit, A. Finkel, F. Laroussinie, A. Petit, L. Petrucci, P. Schnoe-belen.Systems and Software Verification: Model-Checking Techniques and Tools.Springer Publishing Company, Incorporated, 1st edition, 2010.

[BRA+99] S. Blau, J. Rooth, J. Axell, F. Hellstrand, M. Buhrgard, T. Westin, G. Wick-lund. AXD 301: A new generation ATM switching system.Computer Networks31(6):559–582, 1999.

[CEC12] W. Chama, R. Elmansouri, A. Chaoui. Model Checking and Code Generation forUML Diagrams using Graph Transformation.International Journal of SoftwareEngineering & Applications (IJSEA)3(6):39–55, December 2012.

From UML State-Machine Diagrams to Erlang 10 / 12

Page 298: y V Taller de Programación Funcional (TPF)

[CGP99] E. M. Clarke, O. Grumberg, D. Peled.Model Checking. The MIT Press, 1999.

[FS07] L.-A. Fredlund, H. Svensson. McErlang: a model checker for a distributed func-tional programming language.ACM SIGPLAN Notices42(9):125–136, 2007.

[GJM02] C. Ghezzi, M. Jazayeri, D. Mandrioli.Fundamentals of Software Engineering.Prentice Hall PTR, Upper Saddle River, NJ, USA, 2nd edition,2002.

[GLM99] S. Gnesi, D. Latella, M. Massink. Model Checking UMLStatechart Diagramsusing JACK. InProceedings of the 4th IEEE International Symposium on High-Assurance Systems Engineering. Pp. 46–55. 1999.

[Har87] D. Harel. Statecharts: A visual formalism for complex systems.Sci. Comput.Program.8(3):231–274, June 1987.

[HG96] D. Harel, E. Gery. Executable object modeling with statecharts. InProceedings ofthe 18th International Conference on Software Engineering(ICSE). Pp. 246–257.IEEE Computer Society, Washington, DC, USA, 1996.

[KM02] A. Knapp, S. Merz. Model checking and code generationfor UML state machinesand collaborations.Proceedings of 5th Workshop on Tools for System Design andVerification, Technical Report11:59–64, 2002.

[KNNZ00] H. J. Kohler, U. Nickel, J. Niere, A. Zundorf. Integrating UML diagrams forproduction control systems. InProceedings of the 22nd International Conferenceon Software Engineering (ICSE). Pp. 241–251. ACM, New York, NY, USA, 2000.

[Lar09] J. Larson. Erlang for Concurrent Programming.Communications of the ACM52(3):48–56, March 2009.

[LMM99] D. Latella, I. Majzik, M. Massink. Automatic Verification of a Behavioural Subsetof UML Statechart Diagrams Using the SPIN Model-checker.Formal Aspects ofComputing11(6):637–664, 1999.

[NT03] I. A. Niaz, J. Tanaka. Code Generation From Uml Statecharts. InProceedings of the7th IASTED International Conference on Software Engineering and Application(SEA). Pp. 315–321. 2003.

[OMG05] OMG. Unified Modelling Language: Superstructure. Object Management Group,July 2005. Version 2.0, formal/05-07-04.

From UML State-Machine Diagrams to Erlang 11 / 12

Page 299: y V Taller de Programación Funcional (TPF)

[PM03] G. Pinter, I. Majzik. Automatic Code Generation Based on Formally AnalyzedUML Statechart Models. In Tarnai and Schnieder (eds.),Formal Methods for Rail-way Operation and Control Systems (Proceedings of the FORMS-2003 Confer-ence). Pp. 45–52. LHarmattan, Budapest, Hungary, May 15-16 2003.

[TKUY01] T. Tomura, S. Kanai, K. Uehiro, S. Yamamoto. Object-Oriented Design PatternApproach for Modeling and Simulating Open Distributed Control System. InPro-ceedings of the 2001 IEEE International Conference on Robotics and Automation(ICRA). Pp. 211–216. IEEE, 2001.

[WAB02] U. Wiger, G. Ask, K. Boortz. World-class product certification using Erlang.SIGPLAN Not.37:25–34, December 2002.

[Wik94] C. Wikstrom. Distributed Programming in Erlang. In Proceedings of the 1st In-ternational Symposium on Parallel Symbolic Computation (PASCO). Pp. 412–421.1994.

From UML State-Machine Diagrams to Erlang 12 / 12

Page 300: y V Taller de Programación Funcional (TPF)

DRAGONFLY : Encapsulating Android for Instrumentation

Ana-Rosario Espada1, Marıa-del-Mar Gallardo2, Damian Adalid3

1 [email protected] [email protected] [email protected]

Dpto. of Lenguajes y Ciencias de la ComputacionUniversity of Malaga

Abstract: Smart-phones have increased in popularity over the last few years, theplatform ANDROID being one of the smart-phone operative systems preferred byusers. ANDROID has a complex architecture oriented to support many and very dif-ferent applications which are executed concurrently. As other smart-phone operativesystems, ANDROID strongly controls the use of limited mobile resources. In addi-tion, to manage the execution of the applications, it defines a strict life cycle foreach one of its components. We have developed the tool DRAGONFLY to analyzethe correctness of ANDROID systems. DRAGONFLY is based on runtime verificationtechnology. It has two central modules, the first is in charge of constructing a modelthe behavior of which is consistent with that of the ANDROID system being ana-lyzed. The second module is devoted to the dynamic verification of the instrumentedmodel using different observers, each one representing a particular correctness re-quirement. In this paper, we describe how the instrumented model is constructedand how its behavior is formally related with the behavior of the original ANDROID

system.

Keywords: Android Verification, Runtime Verification, Android Debugging

Acknowledgements: This work has been partially funded by grants P11-TIC7659 (Andalusia),UMA-Agilent Technologies 808/47.3868- 4Green and the AUIP as sponsor of the ScholarshipProgram Academic Mobility

1 Introduction

Smart phones are everywhere. Nowadays, we can find people using them not only for calling,but also to send emails, to navigate the Internet, to play media content, to play complex userinterface games, etc. In addition, smart phones are also being used for critical activities. Forinstance, there are medical applications [19] able to accept and manage ultrasound data fromother devices [20]. In fact, these applications have even been approved by the Food and DrugAdministration (FDA) in the USA.

As computational systems, smart phones are very complex, since they involve the execution ofmany different applications which are interdependent. Smart phones behave as open and event-directed systems. Each application in the system may accept user events, device events, and

1 / 14

Page 301: y V Taller de Programación Funcional (TPF)

Figure 1: ANDROID architecture

even events fired by other applications that execute simultaneously. For this reason, when a newapplication is being developed, it is necessary to test not only that it is correct with respect toits expected behavior, but also, that it correctly coexists with the rest of the applications execut-ing on the phone. However, although each smart operating system vendor provides emulatorsand testing tools, currently these tools have a limited functionality which means that developersoften face a number of indecipherable problems, once the application is running in a mobile de-vice. There are different approaches to deal with the problem of analyzing the behavior of smartphones. Some of them use testing techniques [1, 5], others model checking techniques [4], orruntime verification techniques [7, 8, 9].

Figure 1 shows the basic layered ANDROID architecture [3]. Applications are in the top level,while the LINUX operating system resides in the lowest. In the intermediate levels, we find theJava libraries of the ANDROID framework, and the DALVIK machines in charge of executing thehigh level Java applications. Thus, to analyze an ANDROID device, we have to take into accountall layers of its architecture, mainly the highest and the lowest levels.

We may consider two different scenarios to carry out the verification tasks on smart phones.On the one hand, we may decide to execute the verification on the mobile itself, which haslimited resources. Alternatively, we may decide to realize the analysis externally. However, inthis case, we take the risk of losing important information from the device. In our research,we have decided to follow the second scenario, using runtime verification techniques [11] toanalyze ANDROID-based smart phones. We are in the process of developing an external mon-itor, called DRAGONFLY, which executes asynchronously with the device. In order to extractas much information from the device as possible, we use debugging and profiling techniques.More specifically, DRAGONFLY is able to capture the actual sequence of events executed on anANDROID device. Then, these data are encapsulated into a model on which the verification tasksare carried out.

In this paper, we describe the relationship between the model constructed and analyzed byDRAGONFLY, and the actual ANDROID device in execution. We first formalize the high levelbehavior of an ANDROID system, and then we describe the model implemented in DRAGONFLY

that follows the semantics presented. The model built by DRAGONFLY has two parts. Thefirst part is a generic monitor engine which defines the abstract functionality needed to extractinformation from any kind of device. The second part represents a specific monitor engine, ableto extract information from ANDROID devices. The data extracted from these devices can be

2 / 14

Page 302: y V Taller de Programación Funcional (TPF)

static or dynamic. The static data could refer to the status of the device ports, I/O, battery, etc.The dynamic data refer to the particular actions executed by the device. To do this, we use adebugging-based technique which explores, step by step, all the methods, together with theirarguments, executed by the ANDROID operating system. In particular, we use tools DDMLib [2,12] and JDI [15] provided by ANDROID and Java, respectively.

The content of this paper is organized as follows. Section 2 formally describes the executionand architecture of ANDROID devices using operational semantic rules. Section 3 presents theDRAGONFLY tool overview. Section 4 describes the generic model mentioned above. Section 5presents the static monitor and its relationship with the description given in Section 2. Section 6describes the dynamic monitor, and finally, related work, conclusions and future work are given,respectively, in Sections 7 , 8.

2 Formalization of ANDROID systems

This section introduces the ANDROID architecture which is the subject of our proposal.Figure 1 shows the basic ANDROID architecture [3]. As is usual in computer systems, each

layer of the architecture makes use of the services provided by the layer below, and providesservices to be used by the layer above. The lowest layer corresponds to the Linux Kernel op-erative system. Although this layer is completely hidden from the user and from the high levelapplications, it is worth noting that the management of processes, memory and GUI details iscarried out by this level. Thus, the Kernel contains the native libraries, written in C or C++ ,which are specific to each specific hardware. The ANDROID Runtime DALVIK Virtual Machineis also located at this level. DALVIK is an optimized Java Virtual Machine which executes .dexfiles. These files are optimized .class files, built at compile time, and adapted to low resourceenvironments. The next layer is the Application Framework (ANDROID SDK) which providesthe basic functionality from which Android applications are constructed. Finally, the highestlayer contains the applications installed in the mobile. Applications show up through the so-called activities, which are the visual windows with embedded components (buttons, text files,etc.) used to communicate with the user.

2.1 Configuration of an ANDROID System

The behavior of an ANDROID system is determined by the execution of several applications.Let App denote the set of applications installed in an ANDROID system S. The state of S isrepresented by the states of the applications in execution A1|| · · · ||An, with Ai ∈ App,∀1≤ i≤ n.

Each application is composed of different components, which belong to one of the following:

1. Activities. An activity is a visual screen for the user. An application may have severalindependent activities that allow the user to realize different tasks.

2. Services. A service is a particular task embedded inside a specific application. Servicesmay be called by an activity of this application, by an activity of another one, if it haspermission to do so, or by the Linux system.

3 / 14

Page 303: y V Taller de Programación Funcional (TPF)

Figure 2: ANDROID System

3. Content providers. Content providers represent the data managed by the system. Data maybe stored in a SQLite data base, in xml, etc.

4. Broadcast receivers. Broadcast receivers manage the messages sent to the system by theuser or by system events.

Each ANDROID application is implemented by a Linux process which is executed by a differentDALVIK virtual machine. Each application has, in general, a unique identifier, managed by theoperating system, that defines those system files accessible by the application. The executionof each application is directed by the so-called application main thread to which, in general,application components are subscribed, when they are created. The main thread contains aninfinite loop which iteratively deals with events placed in the event queue. Events fired throughapplication components are stored in this queue. When an event is extracted by the main thread,the related components are notified so that they do the corresponding task. Only when a serviceinvolves a long execution, may it be given a new thread, different from the main thread to avoidthe suspension of the application.

Figure 2 describes the structure of an ANDROID system during execution. Applications cor-respond to LINUX processes. Each application may comprise several components, most of themexecuting in the main thread of the application.

We consider that applications may be in one of the following states during execution:

1. Inactive: The application is installed in the phone, but the main thread does not yet ex-ist, because none of its components has been called, or because all the components havealready been destroyed by the kernel.

4 / 14

Page 304: y V Taller de Programación Funcional (TPF)

2. Active: The main thread of the application has been initialized, and, at least, one of itsservices or activities is active.

3. Paused: The main thread of the application has been initialized but none of its componentsis active.

Let us define set State = Inactive,Active,Paused.The configuration of an Android application A is given by a tuple A = 〈id× state× eventQ×

comp∗〉 where A.id ∈ N is the application identifier, A.state ∈ State is its state, and A.eventQis its event queue, and finally, A.comp∗ = [c1, · · · ,ciA ] is the list of the configurations of itscomponents (to be defined below). In the rules below, non-empty event queues A.eventQ arerepresented as lists of the form [event|RE]. Each event may be directed to one, or several,components of a system application. Thus, to represent this, we denote events as event =ev([(i1, ji1 ,actioni1), · · · ,(ik, jik ,actionik)]) where each 3-tuple (is, jis ,action jis ) indicates that com-ponent jis of application is must carry out action actionis . In addition, there are other events whichare realized by the operating system such as the event to create new applications newApp(type)or the event to destroy an existing application destroyApp(id).

We now define the state of application components. Let Act,Serv,Cont and Broad be theset of activities, services, content providers and broadcast receivers, respectively. Let Comp =Act ∪ Serv∪Cont ∪Broad. We assume that given a component C ∈Comp, function type(C) ∈act,serv,cont prod,br rec gives us the type of component.

In consequence, the configuration of a given component c has a specific parameter that definesits current state, that is, c = 〈state,eventQ〉, where the value of state C.state depends on the typeof the component type(c). Thus,

1. if type(c) = act then Statec = created,active, paused,stopped,destroyed2. if type(c) = serv then Statec = created,active,destroyed,

3. and if type(c) ∈ cont prod,br rec then Statec = active.

The state of an application A is determined by the states of its components. If none of thecomponents of A is active, application A is inactive. If some of its components evolve to stateactive, then the application also evolves to active. Thus, we assume that function fst : App →State assigns the correct state to each application.

Finally, C.eventQ represents the specific event queue of C, if C is a service, which is its properevent queue. Otherwise we assume that C.eventQ is always empty [].

2.2 Formalizing the Behavior of ANDROID Systems

In this section, we describe by means of transition rules the behavior of ANDROID systems. Asdescribed above, each ANDROID system is determined by the set of applications in execution.For the sake of simplifying the following semantic rules, we assume that there exists a specificapplication L which is always Active and represents the operating system. In consequence, thesystem configuration is given by L||A1|| · · · ||An. Thus, the evolution of the system is given by theevolution of some of its applications, as the following rules establish.

5 / 14

Page 305: y V Taller de Programación Funcional (TPF)

In the following two subsections, we give the high level semantic rule of the ANDROID behav-ior. We assume that for each component c ∈ Comp, there exists a transition rule event−−−→C whichmodel its evolution. Assuming the existence of these transition rules, we define the evolutionof applications by means of event−−−→A, and the evolution of the system by means of event−−−→S. AsANDROID is an event-directed system, the sequence of events fired direct the execution of thesystem, as described in the rules. Note that we follow a top-down methodology to present therules. We first deal with the event managed by the operating system.

2.2.1 Creating and destroying applications

When the operating system (L) receives a create event, it creates a new application. To do this,assume that function newComp(type) creates the initial components of a given application, andthat function newApp(type) creates the component as a tuple〈id, Inactive, [],newComp(type)〉,where newComp(type) are the initial components of the new application.

L = 〈id,active, [createApp(type)|RE], [c1, · · · ,cn]〉L||A1|| · · · ||An

createApp(type)−−−−−−−−−→S〈id,active,RE, [c1, · · · ,cn]〉||A1|| · · · ||An||newApp(type)The following rule describes how applications are removed from an ANDROID device. The

operating system accepts a destroy event, and as a consequence the application referred to, iseliminated.

L = 〈id,active, [destroyApp(id)|RE], [c1, · · · ,cn]〉,A j.id = id

L||A1|| · · · ||A j|| · · · ||AndestroyApp(A j)−−−−−−−−→S〈id,active,RE, [c1, · · · ,cn]〉||A1|| · · · ||A j−1||A j+1|| · · · ||An

2.2.2 Dealing with events

The following two rules describe the way events are managed and distributed through the AN-DROID system. The first rule fires when an event arrives at the event queue of a given applicationAi. The event may involve the execution of tasks by components of Ai and/or other applicationcomponents. Thus, once all these components have carried out their corresponding tasks, thesystem configuration is updated.

Ai.eventQ = [ev([(i1, ji1 ,action ji1), · · · ,(is, jis ,action jis )])|RE],

Ai1

ev( ji1 ,action ji1)

−−−−−−−−−→AA′i1 , · · · ,Ais

ev( jis ,action jis)−−−−−−−−→AA′is ,∀ j 6∈ i1, · · · , is,A′j = A j

L||A1|| · · · ||Anev([(i1, ji1 ,actioni1 )]),··· ,(i1, ji1 ,actioni1 )−−−−−−−−−−−−−−−−−−−−−−→SL||A′1|| · · · ||〈A′i.id, fst(A′i),RE,A′i.comp〉|| · · · ||A′n

Once the event has arrived at the event queue, it is distributed to the corresponding compo-nents.

c jev(action)−−−−−→Cc′j

〈id,state,EventQ, [c1, · · · ,c j, · · · ,ck]〉 ev( j,action)−−−−−−→A〈id,active,EventQ, [c1, · · · ,c′j, · · · ,ck]〉

6 / 14

Page 306: y V Taller de Programación Funcional (TPF)

Figure 3: DRAGONFLY Architecture

3 The DRAGONFLY tool overview

In this section we give an overview of tool DRAGONFLY. DRAGONFLY is a RV-based frameworkfor verifying ANDROID applications. Figure 3 shows its architecture. As it can be observed, itcontains two main modules. The source module with the ANDROID applications to be analyzedare shown on the left hand side. Applications may be running on a smart-phone or on emulators.

On the right hand side of Figure 3, we may find the monitor module which carries out the ver-ification tasks. This module has three main components: the application manager, the monitorengine, and the observers. The goal of the application manager is to send random events to thesource module, to keep applications alive. Thus, this module and the applications constitute aclosed system with autonomous behavior the correction of which can be analyzed.

Observers behave as state machines, each one specifying a particular desirable property to beanalyzed. Each time an event is fired by the monitor/model, all observers which are involved withthe event (i.e. the event is related with the property that the observer implements) are notifiedin such a way that each observer may update its internal state properly. Thus, for instance, if anincorrect event is registered by an observer, it can fire an alert message.

Now we describe how observers are implemented, and how they are embedded in the code ofthe ANDROID device model. We call instrumentation the process of connecting observers withthe model.

Figure 4 shows the class diagram of an generic observer ActivityObserver of activi-ties, and an instance of this class LifeCycleLambda that represents the property “Activitiesimplement their cycle life correctly”.

In addition, the figure shows class ActivityInstrumentation which is in charge ofnotifying interested observers when a related event has been fired. Each observer is only inter-ested in one type of event or, equivalently, it has only one point of view. In contrast, each pointof view may be interesting for several observers, all of them being instance of the same abstractclass (which represents the point of view).

The methods implemented by ActivityInstrumentation class are embedded into AN-DROID model following the aspect oriented paradigm (AOP).With AOP, it is possible to jointlydeal with different functions called in multiple code points of an application which are semanti-cally related. Typically, these functions, referred to as cross-cutting concerns, are conceptually

7 / 14

Page 307: y V Taller de Programación Funcional (TPF)

Figure 4: Instrumentation and Observers classes

Figure 5: On Create Method verification

separated from the application’s business logic, and may be used to define an aspect to be ob-served. In our context, aspects are the afore-mentioned points of view of the observers.

For verifying the life cycle of activities, we have defined a generic observer with the classActivityObserver which is an activity observer model containing all the methods andevents which can happen in activities life cycle. Next, we define LifeCycleLambda as theobserver class which extends ActivityObserver and overrides all the activity methods. Fi-nally, we include the rule that corresponds to the verification property in each method. Figure 5shows the method onCreate of class LifeCycleLambda.

The property “Activities implement their cycle life correctly” means that, every time an eventonCreate creates a new activity, it is given the state Active, both when the activity does notexist, and also when the activity already exists and it is in state Destroyed or Stopped. Fig-ure 5 shows the specification of this behavior in LAMBDAJ. The rule takes into account bothpossibilities:

1. when no activity exists (selectedComponnents.size() ==0), or

2. when there exists an activity (selectedComponnents.size() !=0) and a

component (AndroidComponent.class) is selected (select(...)) with state

(having(... getState())) equals to destroyed (equalTo(...Destroyed)) or to

stopped ( or(...equalTo(...Stopped)).

Otherwise an error message is sent.

8 / 14

Page 308: y V Taller de Programación Funcional (TPF)

Figure 6: Generic monitor

4 The DRAGONFLY Generic Model

In this section, we describe the generic model which is part of our tool.As stated in the Introduction, in this paper, we focus on the monitor engine component of

DRAGONFLY. The task of the monitor engine is to listen to the events and methods executedby the source, and to construct a system model which can be analyzed by observers. Observersimplement the properties to be verified.

The monitor engine includes a main abstract class that implements the monitor behavior athigh level. This abstract class is generic with respect to the type of source analyzed, and theparticular properties to be analyzed in the source. This means that the class has abstract methodswhich deal with the trace of generic events produced by an abstract source, and with its abstractproperties defined by the abstract observers.

Figure 6 shows the abstract class of the monitor engine. Class Monitor has abstract meth-ods such as Connect, Stop, RegisterDevice, etc. to be implemented in the specific monitors. Forinstance, in the ANDROID implementation of class Monitor, methods Stop and Connect areimplemented with calls to object AndroidDebugBridge, provided by the ANDROID plat-form. The monitor engine has a device list List < T > of a generic type T which inherits fromthe generic model described in Figure 7.

Figure 7 shows the diagram class of the generic model of a device. The main interface isIMonitoringDevice, which represents any kind of standard smart-phone device. This classhas methods to get the serial number, the actual state, the battery level, etc. It also defines alist of applications, and a list of threads. The IApplication interface represents any kind ofsmart-phone application, IApplication defines the methods to obtain the application name,the application state, and a list of application components.

The interface to represent components related with an application is IComponent. It definesmethods to obtain the application and thread in which the component is embedded. IComponenthas also a list of events, methods and exceptions used by the dynamic monitor.

Classes DeviceException, Method and Event model exceptions, methods, and eventsof components, respectively.

All the aforementioned interfaces are used to extract and manage the static data of the smart-phone. In contrast, the classes described are used to extract and manage the dynamic data.

9 / 14

Page 309: y V Taller de Programación Funcional (TPF)

Figure 7: Device generic model

5 Static Monitor

In this section, we describe how DRAGONFLY extracts the static data from an ANDROID smart-phone. Static data are properties or values from:

• from the smart-phone, like the battery status, the serial number, etc,

• from the I/O devices, like the GPS status, the camera status, signal strength etc,

• from the applications, like identifiers, names, main threads, etc,

• from the components, like types, states, etc.

Figure 8 shows the class diagram of the ANDROID model. This model inherits its classes fromthe generic model given in Figure 7. The main class of the diagram, SmartPhoneDevice,represents the ANDROID system to be analyzed. Following the formalization of ANDROID givenin Section 2, this class is composed of the list of applications which are executing in the phone. Inconsequence, there exists a class, apk, which implements the Interface IApplication , andwhich is used to model each ANDROID application . In addition, class ApkThread representsthe ANDROID threads embedded in applications. Thus, class apk has a list of ApkThreadsand a list of IComponents, as described in Figure 2. Similarly, class AndroidComponentimplements interface IComponents and is used to model each ANDROID component.

ANDROID components may belong to four different types. Figure 8 shows the four types ofcomponents, each one inheriting from AndroidComponent, i. e., classes ContentProvider,Activity, BroadcastReciber, and Service. Each component has their own state se-quence that is controlled internally.

It is worth noting that Figure 2 and Figure 8 present similar structures. Both have a main devicewhich contains a set of applications, each one with components and threads. Consequently, eachcomponent belongs to a particular application and thread.

DRAGONFLY extracts the static information from an ANDROID device, using tool DDMLIB

[12], and constructs the model described. Properties extracted are attached to each class if theyare needed to check the properties specified. For instance, if the application to be analyzed usesa camera, we should store the camera status, but maybe, in this case, it is not necessary to save

10 / 14

Page 310: y V Taller de Programación Funcional (TPF)

Figure 8: Android Model

Figure 9: Android Monitor

the red signal status. Clearly, if we store a lot of static properties and values of applications, wewill be able to analyze more correctness properties.

6 Dynamic Monitor

This section describes how tool DRAGONFLY extracts dynamic data of the ANDROID applicationunder analysis. Dynamic data correspond to the sequence of events fired by the system or bythe user. As described in Section 2, the events fired may provoke changes in several ANDROID

components. We define three types of events. First, we have the events that involve the actionsof listeners. ANDROID system includes several listeners dedicated to the control of the state ofcomponents. For instance, when an activity evolves to state active, a listener of ANDROID systemdetects the change, and makes the rest of activities evolve to onPause. Broadcast receiversalso act as listeners registering the changes in the device such as the connection of the GPS,the occurrence of a software updating, etc. Secondly, we have the events that involve calls tomethods, and finally the events that occur when exceptions are thrown. With these three typeof events DRAGONFLY can store all the information regarding the ANDROID trace that is beingexecuted, which can be restored in the ANDROID model.

All devices (the source) are connected to the monitor by a USB port or by wireless. The sourceresponds to a sequence of events which are randomly fired by tool MONKEY [13]. The reactionof the system to each event is to broadcast of the event to all components involved, as describedin Section 2. The events may be predefined ANDROID events, which are fired, for instance, to

11 / 14

Page 311: y V Taller de Programación Funcional (TPF)

open, close or destroy activities and services. Events may also depend on applications.Tool DRAGONFLY extracts the events fired during an execution by debugging the ANDROID

system. Thus, internally, DRAGONFLY makes use of the Java Debugging Interface (JDI) [15],which is able to detect all events that are being fired by the ANDROID system.

DRAGONFLY uses an internal ANDROID monitor which inherits from the generic monitor en-gine such as Figure 9 shows. This instanced monitor simulates the behavior of the source ap-plications. Thus, we can interpret it as the model against which the properties are analyzed.For instance, for ANDROID applications, this monitor/model is called ANDROID monitor engine.The ANDROID monitor is able to recognize the events produced by any ANDROID application.Thus, dynamically the ANDROID monitor reads the events occurred in the real system, and firesinstrumented events in the model, thus allowing the model to behave as the ANDROID originalsystem.

Evidently, the type of events to be read by the ANDROID monitor highly depends on the prop-erties to be analyzed, that is, if some events do not intervene in the analysis of a property, wecan filter them and, consequently, the ANDROID monitor may skip them. Thus, we may definedifferent levels of granularity when dealing with the real events. Currently, DRAGONFLY onlyconsiders the high level events produced by the applications. In the future, we will also take intoaccount low level events fired by the ANDROID operative system which will allow us to verify,for instance, security properties.

7 Related work

There exist, in the literature, some other approaches that make use of debugging techniquesto extract information from smart-phones. Most of these approaches deal with profiling, andbootstrapping energy issues [16, 17, 18].

For instance, in [16], the authors study the possible errors that can occur in the phone dueto fails in the operative system. They consider three different operating systems: WINDOWS

PHONE, IOS, and ANDROID. The study first proposes a spatial spreading of the properties to beverified in a large set of smart-phones to improve the verification capabilities. In addition, theyuse statistical inference to learn about the behavior of the erroneous traces, which allow them topredict future errors and to direct the verification towards those trace with a higher probabilityof failure.

The other two references are highly related. The goal now is to detect energy bugs [17, 18].Both papers analyze the possible error sources. They study the execution trace generated by asmart-phone (mainly, ANDROID) to predict the errors that occur when an application involvesthe loss of an extra amount of battery. When the energy lost could be due to a software problem,they debug the output to diagnose the source problem.

In our proposal, we do something similar. We also analyze the output of the debugging.However we do not use this output directly, but we instrument it, writing it in a high level format.Since the sequence of events really analyzed is written in a more expressive language, we canuse also a high level specification language to describe the properties.

12 / 14

Page 312: y V Taller de Programación Funcional (TPF)

8 Conclusions and Future Work

This paper shows the formalization of part of ANDROID. We have used it to build tool DRAGON-FLY which includes a model of the ANDROID systems the correction of which can be analyzed.We have constructed this model using the decorator pattern which will allow us to extend it toother platforms such as IOS, Windows Phone, etc. Tool DRAGONFLY uses the ANDROID modelto store static and dynamic information of the execution of an ANDROID system. Dynamic datarefer to the events fired by the applications, and ANDROID data refer to the static values of theexecution such as battery level, wireless and GPS status, etc.

In this paper, we have shown how these data are extracted and how they relate with a realANDROID device. DRAGONFLY is able to analyze high level properties regarding the sequence ofevents produced by applications. Currently, we are extending our tool to extract lower level datawhich will allow us to analyze properties regarding the events fired by the operating system. Themodeling framework that has been described in the paper is helping us to write more high levelrules for specifying properties that can be easily extended. In the paper, we have emphasized therelationship between the actual behavior of ANDROID systems, and the behavior of the modelproposed.

As for future work, we are working on the use of different filtering techniques to extract eventsat different granularity levels depending on the property under analysis.

Bibliography[1] Cuixiong Hu and Iulian Neamtiu. 2011. Automating GUI testing for Android appli-

cations. In Proceedings of the 6th International Workshop on Automation of SoftwareTest (AST ’11). ACM, New York, NY, USA, 77-83. DOI=10.1145/1982595.1982612http://doi.acm.org/10.1145/1982595.1982612.

[2] ddms http://developer.android.com/tools/debugging/ddms.html.

[3] Android developer http://developer.android.com/.

[4] Heila van der Merwe, Brink van der Merwe, and Willem Visser. 2012. Verifying android ap-plications using Java PathFinder. SIGSOFT Softw. Eng. Notes 37, 6 (November 2012), 1-5.DOI=10.1145/2382756.2382797 http://doi.acm.org/10.1145/2382756.2382797.

[5] Amalfitano, D.; Fasolino, A.R.; Tramontana, P., A GUI Crawling-Based Technique for AndroidMobile Application Testing, Software Testing, Verification and Validation Workshops (ICSTW),2011 IEEE Fourth International Conference on , vol., no., pp.252,261, 21-25 March 2011. doi:10.1109/ICSTW.2011.77.

[6] Mahmood, R.; Esfahani, N.; Kacem, T.; Mirzaei, N.; Malek, S.; Stavrou, A., A whitebox approachfor automated security testing of Android applications on the cloud, Automation of Software Test(AST), 2012 7th International Workshop on , vol., no., pp.22,28, 2-3 June 2012. doi: 10.1109/I-WAST.2012.6228986.

[7] Machigar Ongtang, Stephen McLaughlin, William Enck, and Patrick McDaniel. 2009. SemanticallyRich Application-Centric Security in Android. In Proceedings of the 2009 Annual Computer SecurityApplications Conference (ACSAC ’09). IEEE Computer Society, Washington, DC, USA, 340-349.DOI=10.1109/ACSAC.2009.39 http://dx.doi.org/10.1109/ACSAC.2009.39.

13 / 14

Page 313: y V Taller de Programación Funcional (TPF)

[8] Ylies Falcone and Sebastian Currea. 2012. Weave droid: aspect-oriented programming on Androiddevices: fully embedded or in the cloud. In Proceedings of the 27th IEEE/ACM International Con-ference on Automated Software Engineering (ASE 2012). ACM, New York, NY, USA, 350-353.DOI=10.1145/2351676.2351744 http://doi.acm.org/10.1145/2351676.2351744.

[9] Bauer, A., Kster, J.-C., Vegliach, G.: Runtime Verification Meets Android Security. In: Goodloe,A.E., Person, S. (eds.) NFM 2012. LNCS, vol. 7226, pp. 174180. Springer, Heidelberg (2012).

[10] Mehlitz, P.; Tkachuk, O.; Ujma, M., JPF-AWT: Model checking GUI applications, Automated Soft-ware Engineering (ASE), 2011 26th IEEE/ACM International Conference on , vol., no., pp.584,587,6-10 Nov. 2011 doi: 10.1109/ASE.2011.6100131.

[11] Martin Leucker. 2011. Teaching runtime verification. In Proceedings of the Second internationalconference on Runtime verification (RV’11), Sarfraz Khurshid and Koushik Sen (Eds.). Springer-Verlag, Berlin, Heidelberg, 34-48.

[12] ddmlib http://sourceforge.net/apps/trac/android4maven/wiki/ddmlib.

[13] Monkey http://developer.android.com/tools/help/monkey.html.

[14] William Enck, Peter Gilbert, Byung-Gon Chun, Landon P. Cox, Jaeyeon Jung, Patrick McDaniel,and Anmol N. Sheth. 2010. TaintDroid: an information-flow tracking system for realtime privacymonitoring on smartphones. In Proceedings of the 9th USENIX conference on Operating systemsdesign and implementation (OSDI’10). USENIX Association, Berkeley, CA, USA, 1-6.

[15] JDI Reference http://docs.oracle.com/javase/6/docs/jdk/api/jpda/jdi/index.html.

[16] Sharad Agarwal, Ratul Mahajan, Alice Zheng, and Victor Bahl. 2010. Diagnosing mobile applica-tions in the wild. In Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks(Hotnets-IX). ACM, New York, NY, USA, , Article 22 , 6 pages. DOI=10.1145/1868447.1868469.

[17] Abhinav Pathak, Y. Charlie Hu, and Ming Zhang. 2011. Bootstrapping energy debugging on smart-phones: a first look at energy bugs in mobile devices. In Proceedings of the 10th ACM Work-shop on Hot Topics in Networks (HotNets-X). ACM, New York, NY, USA, , Article 5 , 6 pages.DOI=10.1145/2070562.2070567.

[18] Ravi, N.; Scott, J.; Lu Han; Iftode, L., Context-aware Battery Management for Mobile Phones,Pervasive Computing and Communications, 2008. PerCom 2008. Sixth Annual IEEE InternationalConference on , vol., no., pp.224,233, 17-21 March 2008 doi: 10.1109/PERCOM.2008.108.

[20] Ultrasound application http://ultrasound.engineering.wustl.edu/index.php/Cell Phone SDK.

[19] mHealth conference in Washington D.C., November 2010.http://abcnews.go.com/Test/video/mhealth-summit-12917581?&clipId=12917581&cid=embedded.

14 / 14