Empirical Tests and Preliminary Results with the Krakatoa Tool for Full Static Program Verification

Ramírez-deLeón Edgar Darío¹, Chávez-Bosquez Oscar², Francisco-León Julián Javier³

¹ División Académica de Informática y Sistemas, Universidad Juárez Autónoma de Tabasco. Correo: msc-dar_ram@hotmail.com.

³ División Académica de Informática y Sistemas, Universidad Juárez Autónoma de Tabasco. Correo: juljav_fl@hotmail.com.

Recibido: mayo de 2012
Reevaluado: junio de 2013
Aceptado: septiembre de 2013

Resumen

XJML (Ramírez et al., 2012) es una plataforma modular externa para la verificación y validación de clases Java empleando el lenguaje de modelado de Java (JML, Java Modeling Language) a través de contratos escritos en XML. Uno de los problemas que se enfrentaron durante el desarrollo de XJML fue la integración de la técnica de verificación denominada Full Static Program Verification (FSPV). En este artículo se presentan los experimentos y resultados que permitieron definir qué herramienta se integra en XJML para ejecutar FSPV.

Descriptores: verificación de modelos, verificación y validación, JML, XML, Java, Runtime Assertion Checking, Extended Static Checking, Full Static Program Verification.

Abstract

XJML (Ramírez et al., 2012) is a modular external platform for Verification and Validation of Java classes using the Java Modeling Language (JML) through contracts written in XML. One problem faced in the XJML development was how to integrate Full Static Program Verification (FSPV). This paper presents the experiments and results that allowed us to define what tool to embed in XJML to execute FSPV.

Keywords: model checking, verification and validation, JML, XML, Java, Runtime Assertion Checking, Extended Static Checking, Full Static Program Verification.

Introducción

JML fue creado por Gary T. Leavens y es el Behavioral Interface Specification Language (BISL) más popular para Java (Chalin et al., 2008; Chalin et al., 2007), soportando Runtime Assertion Checking (RAC), Extended Static Checking (ESC) y Full Static Program Verification (FSPV), de hecho, es el único BISL soportado por estas tres tecnologías de verificación (Chalin et al., 2008; Chalin et al., 2007).

Desde la concepción de JML se han efectuado múltiples avances en el desarrollo de herramientas para su soporte. Esto nos conduce a una gran cantidad de herramientas, duplicación de trabajo (esfuerzos) y una alta y colectiva sobrecarga para el mantenimiento de JML y sus herramientas de soporte. Sin embargo, la evolución de Java como lenguaje de programación, y las mejoras aplicadas a las herramientas y aplicaciones de JML, obliga a la comunidad de JML a mantenerse al día, que es una tarea difícil en donde se producen muchas variantes y alternativas de dichas herramientas y aplicaciones.

Estas razones y el hecho de que aún no existe una herramienta que brinde soporte total a RAC, ESC y FSPV tal como se presenta en Ramírez et al. (2012) fue lo que impulsó el diseño y desarrollo de XJML. XJML es, hasta donde sabemos, la primera propuesta para embeber un contrato para una clase Java usando JML y XML. XJML 1.0 logra integrar:

]]> a) RAC empleando como base JML4 (Chalin et al., 2008), sobre todo los componentes jml4c y jml4rt

b) ESC a través de ESC/Java2 (Flanagan et al., 2002), versión 2.0.5

Si bien la integración de estas herramientas soportadas a través de XML representó un reto interesante, fue aún mayor el problema que se encontró al integrar FSPV en XJML 1.0. Dicho esto, el objetivo de este trabajo es presentar los experimentos y resultados que permitieron determinar la herramienta que da soporte a FSPV en XJML 1.0, FSPVRunner como se denomina a dicho componente en XJML 1.0 (Ramírez et al., 2012).

Marco referencial

Como se ha indicado en la sección anterior, JML es un lenguaje para la verificación de clases Java que soporta las técnicas de Verificación de Aserciones en Tiempo de Ejecución (RAC, Runtime Assertion Checking), Verificación Estática Extendida (ESC, Extended Static Checking) y la Verificación de Programas Completamente Estática (FSPV, Full Static Program Verification). Pero, ¿qué son estas técnicas de verificación, cuál es su función u objetivo primordial?

RAC consiste en la verificación en tiempo de ejecución de las aserciones expresadas en algún lenguaje de especificación (para el caso de este trabajo, en JML). Las aserciones son una de las técnicas automatizadas más usadas para la detección de fallos en sistemas computacionales a la vez que proveen información sobre su localización, inclusive para fallas (faults) que se producen durante la ejecución, pero no conducen a errores significativos (failures).

Las aserciones tienen una larga y distinguida historia en los anales de la ingeniería de software y el diseño de lenguajes de programación. Inicialmente se desarrollaron como un medio para expresar las propiedades deseadas de un programa como un paso necesario en la construcción de pruebas formales y deductivas para la corrección de programas.

Las aserciones han tenido muchas otras aplicaciones en la ingeniería de software a través de los años (Clarke y Rosenblum, 2006), aunque primordialmente en las etapas posteriores de desarrollo, en particular en el desarrollo y ejecución del código fuente. Son un elemento importante de la verificación de modelos (model checking), una técnica alternativa y activamente estudiada de la verificación de programas (program verification), en el cual el espacio de estados resultante de la ejecución de un programa se verifica contra aserciones lógicas que expresan propiedades de seguridad temporal (temporal safety) y de tiempo de vida o vitalidad de un programa (liveness) (Clarke y Rosenblum, 2006).

ESC es la verificación estática de las aserciones expresadas en JML. Es una técnica experimental de verificación de programas en tiempo de compilación (Flanagan et al., 2002). Una de las herramientas más conocidas para esta verificación en Java es ESC/Java, la cual emplea un generador de condiciones de verificación (verification-condition generation) y técnicas de demostración automática de teoremas (Flanagan et al., 2002). Provee a los programadores, a través de un lenguaje simple de anotaciones, decisiones de diseño que pueden expresarse formalmente.

FSPV es una técnica de verificación que emplea demostradores de teoremas (theorem provers) (Karabotsos et al., 2008). Esta técnica de verificación de programas puede emplear demostradores automáticos de teoremas, como por ejemplo¹: Alt-ergo, Simplify, Z3, Yices, CVC3, CVCL, Gappa, Eprover, haRVey, Zenon, SPASS, Vampire y veriT, o bien, emplear asistentes o demostradores interactivos (requieren la intervención humana) de teoremas, tales como¹ Coq, PVS, Isabelle/HOL, HOL 4, HOL Light y Mizar.

La demostración automática de teoremas (ATP, automated theorem proving) que también puede llamarse deducción automatizada, es actualmente el sub-campo más desarrollado del razonamiento automático, y se encarga de la demostración de teoremas matemáticos mediante programas de ordenador.

Así, un demostrador automático de teoremas (automatic theorem prover) es un programa de cómputo desarrollado para la deducción automática de teoremas, ampliamente estudiado y utilizado en la verificación y validación de sistemas de cómputo.

Por otro lado, un asistente de pruebas (proof assistant) o demostrador interactivo de teoremas (interactive theorem prover) es una herramienta de software para asistir en el desarrollo de demostraciones formales mediante la colaboración hombre-máquina. Esto involucra algún tipo de editor interactivo de demostraciones, o alguna otra interfaz, con la cual un humano puede guiar la búsqueda de demostraciones.

Se preguntará: ¿qué tiene que ver todo esto con XJML o incluso con este trabajo?, ¿qué es Krakatoa, qué relación y cuál es su importancia en este trabajo?

XJML 1.0 adopta la plataforma Why para efectuar FSPV, ya que esto es posible gracias al complemento (plug -in) Krakatoa que forma parte de la plataforma Why. Krakatoa es una herramienta de FSPV para clases Java anotadas con JML (Karabotsos et al., 2008) y es similar a FSPV Theory Generator (FSPV TG) (James y Chalin, 2009, Chalin et al., 2008), (Karabotsos et al., 2008), en el sentido que traduce programas Java a un programa intermedio. Sin embargo, los programas en Why se traducen en una teoría específica usando el compilador Why escrito en Objective CAML.

XJML 1.0 soporta Why 2.30 y Why3. Why 2.30 es una plataforma para la verificación de software que contiene varias herramientas²:

• Why, un Generador de Verificación de Condición (VCG, Verification Condition Generator) de propósito general, el cual se utiliza como herramienta de fondo (back-end) por otras herramientas de verificación (Krakatoa y Caduceus) pero también puede usarse de manera directa para la verificación programas.

]]> • Krakatoa³, una herramienta para la verificación de programas Java.

• Caduceus⁴, herramientas para la verificación de programas hechos en el lenguaje C; sin embargo Caduceus es ahora obsoleto y en su lugar, los usuarios deben cambiar a Frama-C⁵.

Por otra parte, Why3⁶ es la siguiente generación de la plataforma Why para la verificación de software. Separa claramente la parte puramente lógica de la especificación y la generación de verificación de condiciones de los programas.

Why3 se desarrolla en el proyecto de equipo ProVal⁷, el cual está conformado por INRIA Saclay -Île-de-France, en conjunto con el Laboratorio de Investigación en Informática de París (Laboratoire De Recherche En Informatique) y la Universidad del Sur de París (University of Paris Sud).

En este trabajo se presenta un conjunto de experimentos que ayudaron a determinar la herramienta que da soporte a FSPV en XJML 1.0, FSPVRunner como se denomina a dicho componente en XJML 1.0 (Ramírez et al., 2012) y que pueden considerarse como una extensión dentro del proyecto XJML.

Para concluir con esta sección resta describir, de manera breve, qué es FSPVRunner. FSPVRunner es un componente del subsistema Runners de XJML, que se encarga de ejecutar FSPV a través de la herramienta Krakatoa de la plataforma Why. La plataforma XJML es descrita con mayor detalle en Ramírez et al. (2012).

El nombre FSPVRunner se conforma por el prefijo FSPV, el cual corresponde a dicha técnica de verificación, y el sufijo Runner se debe a que FSPVRunner es un componente que forma parte del subsistema lanzadores (Runners) de XJML 1.0. Dicho esto, FSPVRunner se encarga de ejecutar FSPV y su arquitectura y funcionamiento es descrito con mayor detalle en Ramírez et al. (2012).

Método

Todos los experimentos se llevaron a cabo en un equipo de cómputo con las siguientes características en hardware y software:

• Notebook Dell Vostro 1520

• Procesador Intel(R) Core(TM) 2 Duo CPU T6670 a 2.20 Ghz

• Memoria RAM de 4 GB

• Sistema Operativo GNU/Linux Ubuntu 10.04 (lucid) de 32 bits, núcleo Linux 2.6.32-34- generic con GNOME 2.30.2

• Java Development Kit 6.0 update 29

• Eclipse SDK versión 3.7.0, build id I20110613-1736

Se otorgaron 30 segundos para la ejecución de cada experimento y el proceso para determinar la herramienta que da soporte a FSPV en XJML 1.0 consistió, primero en probar los módulos FSPV para JML4, JMLEclipse y OpenJML, los cuales son los últimos esfuerzos de la comunidad de JML para desarrollar un entorno integrado de verificación (integrated verification environment) (Chalin et al., 2010). Respecto a JML4 FSPV TG Theory Generator (James y Chalin, 2009; Chalin et al., 2008; Karabotsos et al., 2008), se descartó debido a su inestabilidad observada en las pruebas al momento de instalar y configurar los módulos requeridos⁸.

Las conclusiones sobre la inestabilidad y etapa de desarrollo de JML4 y JMLEclipse están fundamentadas en las páginas Web principales de los respectivos proyectos⁹. Puede observarse cómo en dichas páginas se menciona que el lanzamiento de una primera versión oficial (no beta) está pendiente por determinarse.

Otra herramienta con la que se efectuaron pruebas fue OpenJML. OpenJML es la siguiente generación del núcleo de JML y será soportado por Java 1.7. Está basada en OpenJDK, por lo que desafortunadamente la instalación fallará (Cok, 2011) si la VM de Java no es una versión compatible con Java 1.7. Además, aún hay mucho trabajo por hacer respecto a OpenJML y sus características como un plug -in de Eclipse aún no están definidas (Cok, 2011). En resumen, OpenJML tampoco está listo para utilizarse de manera estable.

Para su mejor comprensión se describe a continuación cada leyenda de las filas de la tabla 1.

• Maintained : indica si a la herramienta aún se le da soporte o se mantiene en desarrollo

• Open source: indica si la herramienta es de código abierto.

• Proven sound: indica si se ha demostrado que la herramienta es consistente¹⁰.

• Proven complete: indica si se ha demostrado que la herramienta es completa (nos referimos a la completitud en el campo de lógica computacional).

• Above two proofs done: indica en qué herramienta, técnica o método fue demostrada la consistencia y completitud de la herramienta.

]]> • VC generation done in prover: indica si la herramienta es capaz de generar sus propias condiciones de verificación (VC es acrónimo de verification-condition).

• Termination of recursive functions: indica si la herramienta tiene la capacidad de tratar con funciones recursivas.

Con la determinación de la plataforma Why para dar soporte a FSPV en XJML 1.0, fue necesario delimitar qué versión de la plataforma Why soportaría XJML 1.0, así como cuáles demostradores automáticos de teoremas (Automatic Theorem Provers)se utilizarían para verificar el comportamiento de FSPV en XJML 1.0.

Se efectuaron pruebas con Why 2.30 (Christophe, 2003) y Why3 0.71 (Bobot et al., 2011) que son las versiones disponibles hasta el momento de la redacción de este trabajo. Para cada versión de la plataforma Why se realizaron experimentos con sus respectivos demostradores automáticos de teoremas soportados, de acuerdo con la documentación disponible para cada versión de Why (Christophe, 2011).

Los experimentos consistieron en verificar la clase Isqrt.java (figura 1), la cual es una implementación que calcula la raíz cuadrada de un número entero.

La implementación de la clase Isqrt es breve, pero a la vez creemos que fue lo suficientemente completa para emitir la conclusión que permitió seleccionar las herramientas que dieron soporte a FSPV en XJML 1.0. Así, la clase Isqrt contiene al menos una precondición (línea 10 de la figura 1), postcondición (línea 11, figura 1), invariante de clase (líneas 2 a 8 en la figura 1) y de ciclo (líneas 16 a 18, figura 1), las cuales son los tipos de aserciones más comunes en la verificación y validación de sistemas computacionales.

Será necesario presentar los distintos demostradores automáticos de teoremasy demostradores interactivos de teoremas (proof assistant o interactive theorem prover)que se usaron para realizar los experimentos con la clase Isqrt, mismos experimentos que permitieron seleccionar qué versión de la plataforma Why, demostradores automáticos de teoremas y demostradores interactivos de teoremas emplear para efectuar los experimentos con el módulo FSPV de XJML 1.0. Se efectuaron experimentos con Why 2.30 y Why3 0.71 con los demostradores automáticos de teoremas:

• Alt-ergo 0.93

• Simplify 1.5.4

]]> • Z3 2.2 y 3.2

• Yices 1.0.17 y 1.0.31

• CVC3 versión development y 2.4.1

• CVCL versión development y 2.4.1

• Gappa 0.12.0 y 0.15.1

• Eprover 1.4 Namring

• haRVey 0.5.10

• Zenon 0.6.3

• SPASS 3.7

• Vampire 0.6

]]> • veriT 201107

Se efectuaron experimentos con Why 2.30 y Why3 0.71 empleando los siguientes demostradores interactivos de teoremas

• Coq 7.4 y 8.3pl2

• PVS 5.0

• Isabelle/HOL 2011-1

• HOL 4 (Kananaskis 7)

• HOL Light 100110

• Mizar 7.12.01

Al igual que con los demostradores automáticos de teoremaslistados, la lista de los demostradores interactivos de teoremasse obtuvo de la documentación y páginas Web de Why 2.30 y Why3 0.71, por lo que es posible que existan más de estos, con los cuales no fue posible efectuar experimentos debido a que no se encuentran en la lista de lossoportados por Why.

Resultados y discusión

Las tablas 2 y 3 muestran la URL de descarga de los demostradores automáticos de teoremas y demostradores interactivos de teoremas empleados en los experimentos.

Ahora bien, las tablas 4 y 5 muestran, respectivamente, los distintos demostradores automáticos de teoremas y demostradores interactivos de teoremas utilizados para efectuar experimentos iniciales con el fin de observar el comportamiento de Why 2.30 y Why3 0.71 con cada uno de ellos y posteriormente experimentar con la clase Isqrt.

Las columnas de las tablas 4 y 5 se describen a continuación:

• Plataforma Why. Versión de la plataforma Why en la que se utilizó el demostradorautomático de teoremas o el demostrador interactivo de teoremas.

• Versión. Versión del demostrador automático de teoremaso demostrador interactivo de teoremas.

• Versión recomendada. De acuerdo con la documentación de la plataforma Why, se indica la versión que se recomienda para el demostrador automático de teoremaso demostrador interactivo de teoremas.

• Compilado. Indica si el demostrador automático de teoremas o demostrador interactivo de teoremas fue compilado en la misma máquina donde se realizaron los experimentos.

]]> • Binario. Si el demostrador automático de teoremas o demostrador interactivo de teoremas no fue compilado en la misma máquina donde se realizaron los experimentos, entonces, se utilizó una versión pre-compilada del mismo. Se trata de una versión compilada en otro equipo, distinto al que fue utilizado para realizar los experimentos.

• Información mostrada. Se incluye la salida presentada por cada versión de la plataforma Why al detectar los demostradores automáticos de teoremaso demostradores interactivos de teoremas soportados.

De acuerdo con los resultados presentados en las tablas 4 y 5 se seleccionaron los demostradores automáticos de teoremasy demostradores interactivos de teoremasdonde el valor de la columna Información mostrada sea Ok o None (sin ninguna nota informativa o de advertencia). La tabla 6 muestra la codificación utilizada para tabular los resultados de las tablas 7 y 8, las cuales presentan los demostradores interactivos de teoremasy demostradores automáticos de teoremas,respectivamente, que se emplearon para probar la clase Isqrt.java. Estos experimentos permitieron seleccionar con qué versión de la plataforma de Why, con cuáles demostradores automáticos de teoremasy cuáles demostradores interactivos de teoremasse realizaron los experimentos para verificar el módulo FSPVRunner de XJML 1.0.

Conclusiones

Los experimentos y resultados presentados pueden servir como base para investigadores que deseen obtener información sobre el comportamiento de la plataforma Why 2.30 y Why3 0.71, con sus respectivos demostradores automáticos de teoremasy demostradores interactivos de teoremas. Por otro lado, y sin olvidar el objetivo que da origen a este trabajo, los resultados permitieron determinar qué versión o versiones de la plataforma Why soportaría XJML 1.0.

Finalmente, la versión de la plataforma de Why así como los demostradores automáticos de teoremasy demostradores interactivos de teoremasfueron seleccionados de acuerdo con los criterios mostrados en la tabla 9.

Debido a la gran discrepancia de resultados entre las dos versiones de la plataforma Why con distintos demostradores automáticos de teoremas (tablas 6 y 7), se decidió realizar los experimentos con ambas versiones de la plataforma Why empleando únicamente aquellos demostradores automáticos de teoremassoportados por ambas versiones lo que permitió emitir conclusiones sobre dichas discrepancias en los resultados.

Dicho esto, XJML 1.0 soporta, a través de FSPVRunner, las siguientes versiones de la plataforma Why: Why 2.30 y Why3 0.71.

Actualmente se trabaja con experimentos, empleando la clase CuentaBancaria (Oriat, 2005). La clase será verificada en XJML 1.0 empleando las técnicas de verificación: RAC, ESC y FSPV. Después de esto, nos aseguraremos que no existan alteraciones entre los resultados presentados por XJML 1.0 y los resultados de cada técnica de verificación, ejecutadas por separado.

Trabajos relacionados

El lenguaje de modelado de java (JML) es quizás el lenguaje mejor conocido para el modelado de clases Java. Ha evolucionado a través de los años, pasando de JML2, JML3, JML4, JML5, JMLEclipse, y OpenJML, el cual es, hasta donde sabemos, el último esfuerzo de la comunidad de JML para producir un Entorno Integrado de Verificación.

Respecto a JMLEclipse, el primer lanzamiento (release) oficial aún está por determinarse¹¹ Por otra parte, OpenJML, que es la siguiente generación de herramientas del núcleo de JML y soporta Java 1.7, está basado en OpenJDK y desafortunadamente la instalación falla si la máquina virtual de Java (JVM) no es la adecuada versión 1.7¹². Por ello, existe mucho trabajo por hacer, y las características u opciones de la interfaz gráfica de usuario (GUI) del complemento (plug -in) de Eclipse aún no están definidas¹³.

XJML emplea el Lenguaje de Marcas Extensible (XML, Extensible Markup Language) como lenguaje para escribir el contrato para una clase Java. El uso de XML se debe a su importante papel en el intercambio de una gran variedad de datos. En este sentido, PiXL (Protocol Interchange using XML Languages) (Del-Mar et al., 2007) es un claro ejemplo de cómo las tecnologías y estándares basados en XML pueden utilizarse para la integración de herramientas de análisis. Sin embargo, PiXL no tiene soporte para JML.

Existe una comunidad de JML experimentando con el lenguaje, y los últimos esfuerzos se centran en construir un Entorno Integrado de Verificación (Chalin et al., 2008), el cual soporte e integre RAC, ESC y FSPV.

De estas tres técnicas de verificación, FSPV parece ser la más difícil de integrar y el último intento por lograr esto (OpenJML) aún no está listo. Creemos que XJML es el primero en su tipo, donde las expresiones del lenguaje pueden ser embebidas en un archivo XML (el contrato) para una clase Java, en lugar de la misma clase. Además, hasta donde sabemos XJML es la primera herramienta que integra RA, ESC y FSPV, y es este último el componente de interés en este trabajo, y que a diferencia de JML4 y JMLEclipse, XJML emplea la plataforma Why gracias al componente FSPVRunner del subsistema Runners de XJML.

En este último aspecto, creemos que este es el primer trabajo donde se realizan experimentos y se analizan los resultados del componente FSPVRunner de XJML y que puede ser el primero de una serie de experimentos para verificar la eficiencia y eficacia de XJML, con el fin de identificar puntos débiles o áreas de trabajo que apoyen en la verificación de programas Java.

Actualmente se trabaja en experimentos con la clase CuentaBancaria y el componente FSPVRunner. Después de esto se analizarán y compararán los resultados asegurando que no existan alteraciones entre los resultados y la ejecución de FSPV a través de la plataforma Why.

Respecto a XJML 1.0 cabe destacar que soporta precondiciones, poscondiciones e invariantes de clase, así que se espera que en las siguientes actualizaciones de XJML podamos ofrecer soporte para más expresiones de JML. La tercera cosa por hacer es construir una Interfaz Gráfica de Usuario para XJML.

Respecto a FSPVRunner y las pruebas presentadas en este trabajo, se ejecutarán los experimentos en al menos un equipo más, con más de 4 GB de RAM, un microprocesador con más de dos núcleos y velocidad mayor de 2.20 GHz.

Para los experimentos deberá asignarse un tiempo mayor a 30 segundos, que fue el tiempo asignado en este trabajo, por lo que se recomienda se ejecuten primordialmente en Why3 0.71 con Alt-ergo 0.93, debido a que fueron los de mayor éxito en FSPV.

Agradecimientos

Este trabajo fue parcialmente patrocinado por el proyecto: Desarrollo de una infraestructura tecnológica como apoyo a la Comisión de Derechos Humanos del Estado de Tabasco, usando herramientas de software de vanguardia en atención a grupos vulnerables, en atención a un proyecto de Fondos Mixtos y en atención a la convocatoria del CONACYT 2008. Clave del proyecto: TAB–2008–C03–95740.

Queremos agradecer también a Gary T. Leavens, Kuat Yessenov, Greg Dennis, y Homero Alpuín por todo su apoyo, respuestas de correo electrónico, sugerencias y más.

Bobot-François, Christophe-Filliâtre J., Marché-Claude, Paskevich-Andrei. Why3: Shepherd your Herd of Provers, Boogie 2011: First International Workshop on Intermediate Verification Languages (1er, 2011, Wroclaw, Poland). BOOGIE 2011, first International Workshop on Intermediate Verification Languages, Wroclaw, Poland, Microsoft Research, 2011, pp. 53-64 [en línea]. Disponible en: http://research.microsoft.com/en-us/um/people/moskal/boogie2011/boogie_2011_all.pdf.         [ Links ]

Chalin P., Chalin P.R., James P.R., Lee J., Karabotsos G. Towards an Industrial Grade IVE for Java and Next Generation Research Platform for JML. International Journal on Software Tools for Technology Transfer (STTT) volumen 12 (número 6), noviembre de 2010 [fecha de consulta: 06 de mayo 2012] [en línea]. Disponible en:  http://formal.korea.ac.kr/~jlee/papers/sttt10.pdf.         [ Links ]

Chalin P., James P.R., Karabotsos G. VSTTE '08 Proceedings of the 2nd International Conference on Verified Software: Theories, Tools, Experiments, USA, Springer Berlin–Heidelberg, 2008, cap. 9, JML4: Towards an Industrial Grade IVE for Java and Next Generation Research Platform for JML [fecha de consulta: 06 de mayo 2012] [en línea]. Disponible en: http://www.springerlink.com/content/t28606827773492v/fulltext.pdf.         [ Links ]

Chalin P., James P.R., Karabotsos. Proceedings of the 2007 Conference on Specification and Verification of Component-Based Systems: 6th Joint Meeting of the European Conference on Software Engineering and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, New York, NY, USA, Association for Computing Machinery, 2007, cap. 6, An Integrated Verification Environment for JML: Architecture and Early Results [fecha de consulta: 06 de mayo 2012] [en línea]. Disponible en: Links ]encs.concordia.ca/~chalin/papers/2007-SAVCBS-Chalin-James-Karabotsos-IVE-for-Jml.pdf" target="_blank">.

Christophe-Filliâtre J. The WHY Verification Tool. Tutorial and Reference Manual, France, INRIA Saclay & Laboratoire de Recherche en Informatique, 2011, 40 p. [en línea]. Disponible en: http://why.lri.fr/manual/manual.ps.         [ Links ]

Christophe-Filliâtre J. y Marché C. Proceedings of the 19th International Conference on Computer Aided Verification, USA, Springer Berlin-Heidelberg, 2007, cap. 21, The Why/Krakatoa/Caduceus Platform for Deductive Program Verification [fecha de consulta. 06 de mayo 2012] [en línea]. Disponible en: http://www.lri.fr/~filliatr/ftp/publis/cav07.pdf.         [ Links ]

Christophe-Filliâtre J. Why: a Multi-Language Multi-Prover Verification Tool, Paris, Laboratoire de Recherche en Informatique, Université Paris Sud, 2003, Research Report 1366.         [ Links ]

Clarke L.A. y Rosenblum D.S. A Historical Perspective on Runtime Assertion Checking in Software Development. ACM SIGSOFT Software Engineering Notes, volumen 31 (número 3), mayo de 2006 [fecha de consulta: 06 de mayo 2012]. [en línea]. Disponible en: http://dl.acm.org/citation.cfm?id=1127900&CFID=62138933&CFTOKEN=88416605.         [ Links ]

Cok David R. The OpenJML User Guide, USA, jmlspecs, 2011, 20 p. [en línea]. Disponible en: http://jmlspecs.sourceforge.net/OpenJMLUserGuide.pdf.         [ Links ]

Del-Mar-Gallardo M., Martínez J., Merino P., Nuñez P., Pimentel E. PiXL: Applying XML Standards to Support the Integration of Analysis Tools for Protocols. Science of Computer Programming Journal, volumen 65 (número 1), marzo de 2007 [fecha de consulta: 06 de mayo 2012] [en línea]. Disponible en: http://www.lcc.uma.es/pedro/publications/pixl_gallardo.pdf.         [ Links ]

Flanagan C., Leino K.R., Lillibridge M., Nelson G., Saxe J.B., Stata R. Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design and Implementation, New York, NY, USA, Association for Computing Machinery, 2002, cap. 21, Extended Static Checking for Java [fecha de consulta: 06 de mayo 2012] [en línea]. Disponible en: http://research.microsoft.com/en-us/um/people/leino/papers/krml103.pdf.         [ Links ]

James P. R. y Chalin P. Proceedings of the 2009 ACM Symposium on Applied Computing, New York, NY, USA, Association for Computing Machinery, 2009, cap. 9, Extended Static Checking in JML4: Benefits of Multiple Prover Support [fecha de consulta: 06 de mayo 2012] [en línea].Disponible en: http://users.encs.concordia.ca/~chalin/papers/JamesChalin09-ACM-SAC-SVT09-preprint.pdf.         [ Links ]

Karabotsos G., Chalin P., James P.R. y Giannas L. Total Correctness of Recursive Functions using JML4 FSPV, Seventh International Workshop on Specification and Verification of Component-Based Systems (7o, 2008, Atlanta, Georgia, USA). International Workshop on  Specification and Verification of Component-Based Systems, Atlanta, Georgia, USA, School of Electrical Engineering and Computer Science, University of Central Florida, 2008, pp.19-26 [en línea]. Disponible en: http://www.eecs.ucf.edu/SAVCBS/2008/papers/Karabotsos-etal.pdf.         [ Links ]

Oriat C. Jartege. A Tool for Random Generation of Unit Tests for Java Classes, en Quality of Sofware Architectures and Software Quality, 2nd International Workshop of Software Quality (2o, 2005, Erfurt, Germany). Quality of Sofware Architectures and Software Quality, 2nd International Workshop of Software Quality, Erfurt, Germany, LNCS 3712, 2005, pp. 242-256 [en línea]. Disponible en: http://membres-liglab.imag.fr/oriat/soqua.pdf.         [ Links ]

Ramírez-de-L. E.D., Chávez-Bosquez O., Francisco-L. J.J. Verification and Validation for Java Classes Using Design by Contract. The Modular External Approach. Revista World Academy of Science, Engineering and Technology (WASET), volumen 64 (número 14), abril de 2012 [fecha de consulta: 18 de abril de 2012] [en línea]. Disponible en: http://www.waset.org/journals/waset/v64/v64-14.pdf.         [ Links ]

Notas

¹ En la sección de resultados y discusión encontrará la URL de descarga de cada uno de ellos.

² http://why.lri.fr/.

³ http://krakatoa.lri.fr/.

⁴  http://why.lri.fr/caduceus/.

⁵  http://frama-c.cea.fr/.

⁶ http://why3.lri.fr/.

⁷ http://proval.lri.fr/.

⁹ http://sourceforge.net/apps/trac/jmlspecs/wiki/JML4 y http://sourceforge.net/apps/trac/jmlspecs/wiki/JmlEclipse.

¹⁰ Las propiedades de solidez o consistencia (soundness) y completitud (completness) son las que se piden a cualquier método de validación. La propiedad de solidez nos garantiza que el método solo nos dará conclusiones válidas y la completitud nos garantiza que podremos obtener todas las conclusiones derivables.

¹¹ Como se indica en http://sourceforge.net/apps/trac/jmlspecs/wiki/JmlEclipse.

¹² Vampire 0.6 no siempre arroja los mismos resultados.

¹³ Tomado de The OpenJML User Guide, página 13, disponible en http://jmlspecs.sourceforge.net/OpenJMLUserGuide.pdf.

Este artículo se cita:

Citación estilo Chicago
Ramírez-de León, Edgar Darío, Oscar Chávez-Bosquez, Julián Javier Francisco-León. Pruebas empíricas y resultados preliminares con la herramienta Krakatoa para Full Static Program Verification. Ingeniería Investigación y Tecnología, XV, 04 (2014): 493-504.

Semblanzas de los autores

Edgar Darío Ramírez-de León. Maestro en sistemas computacionales y licenciado en sistemas computacionales por la División Académica de Informática y Sistemas (DAIS) de la Universidad Juárez Autónoma de Tabasco (UJAT). Profesor-Investigador en la DAIS-UJAT. Miembro del Sistema Estatal de Investigadores (SEI) del estado de Tabasco. Ingeniero de Software. Su última colaboración en un proyecto de investigación fue en: "Desarrollo de una infraestructura tecnológica como apoyo a la comisión de Derechos Humanos del Estado de Tabasco usando herramientas de software de vanguardia en atención a grupos vulnerables", patrocinado por el CONACYT. Áreas de interés: verificación y validación de sistemas, model checking, inteligencia de negocios, data warehouse y data mining.

Oscar Chávez-Bosquez. Profesor-investigador de la división académica de informática y sistemas de la Universidad Juárez Autónoma de Tabasco. Maestro en sistemas computacionales, ha escrito diversos artículos tratando temas modelos formales de desarrollo de software, y de optimización combinatoria en el área de metaheurísticas aplicadas a problemas NP-Completos. Ha participado en proyectos con financiamiento externo. Actualmente cuenta con el perfil PROMEP y es miembro del Sistema Estatal de Investigadores.

Julián Javier Francisco-León. Desarrollo y transferencia de tecnología en sectores productivos con necesidades en el área de multimedia. Integrar soluciones tecnológicas utilizando elementos multimedios, animación así como sistemas inmersivos 3D y realidad virtual. Ha participado en proyectos desarrollando sistemas para los museos Parque Museo de La Venta y Museo. Perfil PROMEP y miembro del Padrón Estatal de investigadores.

Nota. Los tres autores participaron, entre otros, en un proyecto de fondos mixtos de CONACYT-UJAT-CEDH titulado: "Desarrollo de una infraestructura tecnológica como apoyo a la comisión de Derechos Humanos del Estado de Tabasco usando herramientas de software de vanguardia en atención a grupos vulnerables", con Julián Javier Francisco-León como director.