trabajo fin de grado toradocu – generacion...
Post on 26-Sep-2018
217 Views
Preview:
TRANSCRIPT
Graduado en Ingeniería Informática
Universidad Politécnica de Madrid
Escuela Técnica Superior deIngenieros Informáticos
TRABAJO FIN DE GRADO
ToraDocu – Generacion automática de casos de test conoráculos: Precondiciones y postcondiciones.
Autor: Sergio Delgado
Director: Damiano Zanardini
Director empresa: Alessandra Gorla
MADRID, JUNIO DE 2017
ÍNDICE1. Introducción 1
2. Estado del arte 22.1. Automatización de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Generación automática de tests . . . . . . . . . . . . . . . . . . . . . . . 2
2.3. Generación automática de oráculos . . . . . . . . . . . . . . . . . . . . . 3
3. ToraDocu 43.1. Extractor de Javadoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Traductor de condiciones . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Generador de oráculos . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Plataforma de Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Funcionalidades añadidas 114.1. Soporte para los Param tags . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Análisis de patrones . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Extracción y traducción de @param . . . . . . . . . . . . . . . . 13
4.1.3. Modificación de la plataforma de test y mejoras del análisis . . . 14
4.2. Soporte para los Return tags . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Análisis de patrones . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Extracción y traducción de @return . . . . . . . . . . . . . . . . 17
4.2.3. Modificación de la plataforma de test y mejoras . . . . . . . . . . 18
5. Evaluación y test 195.1. Estado previo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Estado actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3. Caso real: Uso de ToraDocu . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Trabajo futuro 24
7. Conclusiones 25
I
ÍNDICE DE FIGURAS1. Esquema general de ToraDocu . . . . . . . . . . . . . . . . . . . . . . . 4
2. Condiciones del @param en Commons Collections . . . . . . . . . . . . 20
3. Condiciones del @throws en Commons Collections . . . . . . . . . . . . 20
4. Condiciones del @return en Commons Collections . . . . . . . . . . . . 21
5. Condiciones del @param en Commons Math3 . . . . . . . . . . . . . . . 21
6. Condiciones del @throws en Commons Math3 . . . . . . . . . . . . . . 21
7. Condiciones del @return en Commons Math3 . . . . . . . . . . . . . . . 22
8. Condiciones del @param en Plume Lib . . . . . . . . . . . . . . . . . . 23
9. Condiciones del @throws en Plume Lib . . . . . . . . . . . . . . . . . . 23
10. Condiciones del @return en Plume Lib . . . . . . . . . . . . . . . . . . . 23
ÍNDICE DE TABLAS
II
Resumen
Normalmente, los desarrolladores documentan su código con comenta-
rios semiestructurados, como son los JavaDoc. Esos comentarios son los que
describen el funcionamiento del programa, así como en la gran mayoría de
casos, propiedades y condiciones a cumplir de parámetos de entrada y salida.
El objetivo del proyecto es usar dicha información y analizarla para generar
de forma automática aserciones y test con oráculo. Así pues, con estos ele-
mentos, seríamos capaces de generar los test de dicha clase Java, únicamente
basándonos en los comentarios que tenemos, sin tener que programarlos ma-
nualmente, ahorrando en tiempo y costes.
Palabras clave: testing, oráculos de test, JavaDoc, aserciones.
Abstract
Usually, the developers in a project documents their code with semi-
structured comment, such as JavaDoc. Those comments are the ones that
describes the program behavior, and in almost every time, the properties and
conditions that the input and output parameters have to pass. The main pur-
pose of the project is, using and analyzing this information, to generate auto-
matically assertions and oracle test. With this elements, we would be able to
generate the tests of that Java class only with the comments we have in the
JavaDoc part, without having to programming those tests manually, saving
time and costs.
Keywords: testing, oracle tests, JavaDoc, assertions.
III
1. INTRODUCCIÓNHoy en día, el problema del testeo de software es de las partes más importantes en
todo proyecto. Llevar a cabo las operaciones de testeo del software creado (O en proceso
de), requiere de tres recursos básicos:
Tiempo: No hay un tiempo límite establecido en el que el software termine de estar
testeado. Dichas pruebas se realizan durante y después de dicho proyecto, e incluso
después de sacar el producto a los consumidores. Cuanto más tarde se identifica
un error en el programa, mayor es el tiempo que éste requiere para ser arreglado,
aumentando así aún más los costes. Por eso es importante identificar los errores tan
pronto como sea posible.
Dinero: Es una de las actividades que más incrementa su porcentaje en cuanto a
gastos globales del proyecto software. Según informes recientes [1], estas cifras
ascenderían hasta el 40 % en 2018. Esto reafirma la importancia que tiene esta parte
dentro del desarrollo de software, y la necesidad de abaratar costes.
Recursos humanos: De forma habitual, esta tarea se lleva a cabo a mano, ya que sin
las aserciones necesarias, no se puede comprobar el comportamiento del programa.
Dado el alto coste de esta tarea, se han creado herramientas que facilitan el testeo de
dicho software, pero habitualmente no incluyen las aserciones (oráculo) que describen el
resultado final de la ejecución del programa.
Los oráculos son una parte esencial de los casos de test, ya que determinan si el com-
portamiento ha sido correcto o no. Éstos contienen el comportamiento intencionado del
software, por tanto, han de ser generados por un humano, o generados gracias a la infor-
mación dada por un humano, como pueden ser especificaciones formales.
Este proyecto pretende generar oráculos mediante la información que los desarrolla-
dores normalmente escriben en lenguaje natural. Partiendo de los comentarios semies-
tructurados que se encuentran en los JavaDocs de las clases java, se intenta transformar
estos comentarios en oráculos de test, y usarlos en combinación con generadores de pa-
rámetros de entrada aleatorios para generar automáticamente casos de test completos que
expongan los defectos del programa.
ToraDocu se ha centrado en el comportamiento excepcional, analizando únicamente la
parte del @throws. En este trabajo se incluye el funcionamiento en profundidad de la he-
rramienta, las labores de mejora realizadas referidas a los otros comentarios del JavaDoc
(@param y @return) así como otras mejoras, los experimentos y pruebas establecidas y
llevadas a cabo.
1
2. ESTADO DEL ARTEComo se ha comentado anteriormente, existen varias herramientas que facilitan la
tarea del test de programas y aplicaciones. Aquí se hablará brevemente de dichas herra-
mientas, qué función cumplen y cómo la llevan a cabo.
2.1. Automatización de testsEn la gran mayoría de casos, los tests tienen dos elementos fundamentales básicos, a
saber: Parámetros de entrada para la función, aserciones para los parámetros de salida.
El principal framework que se utiliza en Java es JUnit [2]. JUnit es un conjunto de
clases (framework) que permite realizar la ejecución de clases Java de manera controlada,
para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se com-
porta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor
de retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá
que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado
sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el
método correspondiente.
1 @Test
2 p u b l i c vo id t e s t M u l t i p l y E x c e p t i o n ( ) {
3 MyClass t e s t e r = new MyClass ( ) ;
4 a s s e r t E q u a l s ( " R e s u l t " , r e s u l t , t e s t e r . m u l t i p l y (m1 , m2) ) ;
5 }
Listing 1: Ejemplo de JUnit
JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando
una parte del código ha sido modificado y se desea ver que el nuevo código cumple con
los requerimientos anteriores y que no se ha alterado su funcionalidad después de la nueva
modificación.
2.2. Generación automática de testsEn la actualidad, existen varias herramientas generadoras de input aleatorio. Su labor
consiste en, dada una función en lenguaje Java, analizar los parámetros de entrada, y
generar de forma masiva ejecuciones de dicho método.
EvoSuite [3]. y Randoop [4]. son un ejemplo de estas herramientas.
Randoop genera tests usando feedback obtenido de tests aleatorios. Con ésta técnica
son capaces de generar aserciones para capturar cómo funciona el programa. Esto permi-
te crear pruebas de regresión, pero no pruebas que testeen el correcto funcionamiento del
programa, sólo comprueban que los cambios introducidos en el programa no cambian el
comportamiento anterior.
2
Evosuite produce para los test generados, sugerencias de posibles oráculos, añadien-
do pequeñas aserciones que resumen el comportamiento del programa. Dichas aserciones
sirven para detectar desviaciones del comportamiento esperado, y para capturar el com-
portamiento actual para así compararlo con los futuros y posibles cambios en el programa
que hagan que las cosas no funcionen. De nuevo, no hay gran diferencia entre Randoop y
Evosuite, ya que ambos lo que hacen es capturar una imagen de un programa para com-
probar que funciona como ha de funcionar en el futuro, pero no comprueban ni crean
oráculos que prueben que el programa funciona como ha de funcionar en el presente.
2.3. Generación automática de oráculosAdemás de ToraDocu, existen herramientas que sean capaz de generar oráculos de
forma automática. @tComment [5] trabaja sobre programas Java, al igual que ToraDocu,
centrándose específicamente en las condiciones referidas a valores nulos de los paráme-
tros. En primer lugar, analizan el texto en inglés del Javadoc de la clase para crear un
conjunto de propiedades de un método. En segundo lugar, se generan de forma aleatoria
test para ese método. Con esto, al ejecutar los test, se comprueban las propiedades previa-
mente descritas en el paso uno, y se reportan las inconsistencias.
ToraDocu [6], a diferencia de @tComment, trabaja con todo tipo de condiciones ade-
más de las referidas a valores nulos. ToraDocu usa comparaciones directas entre el sujeto
de la oración y los elementos de código que han de ser comprobados y predicados con
patrones predefinidos o métodos que comprueban propiedades. Por tanto, y a diferencia
de @tComment, el comentario “@throws NullPointerException if the list is empty” sería
traducible y se podría relacionar con el método que comprobara dicha condición y que tu-
viera un nombre similar, y por tanto se invocaría el método "isEmpty()" de la clase "list"
en la instancia del objeto para comprobar si está vacía o no y si se lanza la excepción.
3
3. TORADOCUToraDocu es un programa que se lanza por línea de comandos.
Los parámetros que recibe como mínimo son:
–target-class: Nombre completo con los paquetes de la clase objetivo.
–class-path: Directorio que contiene los binarios de la clase. (La clase java ya com-
pilada).
–source-dir: Directorio donde se localiza la clase.
Código aanalizar
Extractorde Javadoc
Traductorde condi-
ciones
Generadorde oráculos
Casos detest
Figura 1: Esquema general de ToraDocu
Como resume la figura, ToraDocu está dividido en tres grandes bloques:
Extractor de Javadoc: Este módulo es el encargado de extraer los comentarios de la
clase seleccionada. Los transforma y convierte a un tipo de estructura propio y que
posteriormente será manejado por el Traductor de condiciones.
Traductor de condiciones: Es el encargado de generar árboles sintácticos y semán-
ticos para analizar las frases y crear las condiciones booleanas Java necesarias para
la creación de los tests.
Generador de oráculos: El módulo que se ocupará de transformar las condiciones
en oráculos, como se explicará más adelante, usando clases jAspect.
Este proceso de ejecución está dirigido por el main, que se encarga de usar el resto de
módulos e interconectarlos entre sí. A continuación se procede a la explicación de dichos
módulos.
4
3.1. Extractor de JavadocEl javadoc son comentarios semiestructurados escritos en lenguaje natural que especi-
fican las características de un elemento del código, como puede ser un método, una clase
o paquete.
A continuación, se muestra un ejemplo de la estructura de un javadoc.
1 /**2 * Creates a new aspect for the given {@code method}.3 *4 * @param method method for which an aspect will be created5 * @param aspectName name of the file where the newly created aspect is saved6 * @throws NullPointerException if {@code method} or {@code aspectName} is null7 */8 p r i v a t e s t a t i c vo id c r e a t e A s p e c t ( DocumentedMethod method , S t r i n g aspectName )
Listing 2: Ejemplo de comentario JavaDoc
Esta tarea se lleva a cabo gracias a la API que proporciona el javadoc para extraer
dichos comentarios[7]. Ha de ser indicado que, en caso de ser un método con el JavaDoc
heredado, el JavaDoc que se analizará será el del padre, pero con los datos del hijo (Nom-
bre de método, parámetros, etc).
Por ejemplo, el tag @param indica información sobre los parámetros del método, El
@return especifica características y condiciones de los valores que devuelve el método,
y finalmente, el @throws y el @exception dan pautas e información sobre el comporta-
miento excepcional.
Una vez llamamos a nuestro extractor de javadoc, esta información se extrae y se guar-
da en las clases personalizadas creadas para ella.
La primera de ellas es el throws tag, donde se almacena el tipo de excepción el
comentario y posteriormente la condición que éste generará.
El segundo tipo de dato que se almacenará son los parámetros de la función, de los
que se guardarán nombre , tipo y su posibilidad de ser NULL.
Finalmente, el tercer y último tipo de dato que se almacenará será el método en sí,
del que se guardara tanto el nombre de dicho método como su valor de return, así
como los comentarios throws asociados y sus parámetros de entrada.
5
3.2. Traductor de condicionesEl traductor de condiciones es el encargado de transformar los comentarios en len-
guaje natural a condiciones booleanas en Java, utilizando técnicas de procesamiento del
lenguaje natural[8] y comparación de patrones.
Por ejemplo, el traductor de condiciones convertiría las condiciones “if b is grea-
ter than 0” en b>0, “if sampleList is null or is empty” en sampleList==null || sample-
List.isEmpty()==true, y "if both a and b are negative" en a<0 && b<0.
A continuación se explican las fases por las que pasa el comentario para ser traducido:
1. Eliminación de elementos redundantes:
En esta fase del traductor, se eliminan los elementos que puedan entorpecer a la hora
de generar árboles semánticos, para así darle sentido a la frase y que ésta pueda ser
analizada de forma correcta.
En este caso concreto, y para el Throws, se eliminan tanto la excepción como el "if"
inicial de la frase, transformando el comentario de ejemplo "NullPointerException
if sampleList is null or is empty" en "sampleList is null or is empty".
Esto nos permite, aparte de darle un mejor sentido a la oración, simplificarla y darle
significado, ya que la excepción se usará en el generador de oráculos (El tipo de
excepción que lanza) y el "if" hace que la oración en inglés carezca de sentido
como tal, al ser una oración condicional incompleta.
2. Separación de las oraciones presentes en el comentario:
Dado que en un comentario se pueden encontrar más de una oración separada por
puntos, éstas se analizan de manera individual, de tal forma que el grafo semántico
resultante no sea tan grande y sea más fácil de manejar.
3. Reconocimiento previo de patrones:
En los comentarios, es normal ver cierto tipo de patrones comunes para referirse
a mismas condiciones. Un ejemplo de esto puede ser la condición anteriormente
citada, "if b is greater than 0".
Estos patrones son previamente reconocidos por el programa para ser sustituidos
por lo que llamamos Placeholders. Son los que "guardan" el sitio a dichos patrones.
El motivo reside en que el Stanford Parser no es capaz de hacer traducciones lite-
rales de muchos de estos patrones, no sabiendo qué son cláusulas como esas. Por
tanto, "greater than 0" se verá encapsulado y guardado antes de realizar el árbol se-
mántico, y posteriormente sustituido en el predicado resultante del Stanford Parser.
6
4. Generación de árboles semánticos para cada oración:
En esta fase, el Stanford Parser genera el árbol semántico correspondiente a cada
oración, quedando éstos almacenados para su posterior procesamiento. Respecto a
la fase anterior, los Placeholders ocupan la misma función semántica que lo que
sustituyen, por lo que no se ve modificada ninguna de las funciones semánticas del
resto de palabras existentes en la oración.
5. Identificación del sujeto:
Tras haber generado el árbol semántico, se extraen de él las funciones de cada
palabra/conjunto de palabras. Lo primero a lo que se procede es a la identificación
del sujeto y a su comparación con el resto del código, para asignarle uno de éstos.
La asignación del sujeto a un código del elemento se lleva a cabo de la siguiente
forma:
Se reúnen todos los elementos del código visibles desde el punto de vista de
la función. Parámetros, métodos, constructores, clases y variables globales.
Se comparan, uno a uno, sujeto y elemento del código, mediante una distancia
de Levensthein (Diferencias entre adiciones, eliminaciones y sustituciones,
tanto de letras como de palabras enteras).
La distancia máxima que se contempla en estos casos es de 2, siendo el valor
de cada adición o eliminación 1, y el valor de eliminar palabras también de
uno. Por ejemplo, la distancia de "aaa" a "aa", sería de una, mientras que la
distancia de "contains the specified vertex" a "containsVertex", sería de 2, ya
que habría que eliminar "the specified" para realizar la asignación.
Al realizar este análisis para un elemento del código, no sólo se tiene en cuenta
la distancia de Levensthein, sino su tipo. Por tanto, se establecen prioridades
entre tipos, siendo la más alta de todas ellas los parámetros, es decir, en el hi-
potético caso de que se tengan dos elementos de código de la misma distancia
Levensthein cuyos tipos son parámetro y método, de estos dos se realizará la
asignación al que sea del tipo parámetro. Se tomó esta decisión en base a la
experiencia de los casos estudiados.
Finalmente, se asigna de forma definitiva al sujeto un elemento del código.
Éste será, en el gran número de casos, la parte izquierda de la condición java
que más adelante se generará.
En caso de que no se halle un sujeto en el árbol semántico, simplemente esa oración
no se traduce, ni produce condición alguna.
7
6. Identificación y traducción del predicado:
Antes de nada, en el predicado se sustituye cada Placeholder por su expresión o
patrón correspondiente.
Acto seguido, se procede a la realización de las siguientes acciones:
Primero, se realiza una separación del predicado. Muchas veces, este contiene
las cláusulas "and" y/o "or", indicando que el predicado está partido, y que han
de analizarse las cláusulas izquierda y derecha por separado, y posteriormente
unirlas con ese "and"/"or".
Tras tener el predicado lo más partido y desmenuzado posible, éste se some-
te a una comparación simple. Esta comparación simple consta de todos los
predicados y patrones que se deducen directamente del texto plano. Es decir,
que si el texto contiene "is positive", la condición directa resultante de aplicar
la comparación simple, será ">0". Estas comparaciones son el resultado de la
experiencia y el análisis de dichos patrones en los @throws analizados previa-
mente durante el desarrollo de la aplicación, y se han ido añadiendo a medida
que se iban descubriendo y estudiando.
Si falla la comparación simple, se pasa a la comparación léxica. Aquí, se deci-
de qué elemento de código asignar al predicado de la misma forma que hacía-
mos en el sujeto: Se realiza la distancia de Levensthein con los elementos del
código y se asignan prioridades según el tipo. Sólo se tienen en cuenta varia-
bles y métodos booleanos que no reciben argumento, debido a la complejidad
de dichas cláusulas en lenguaje natural que son difíciles de traducir.
Al igual que en el sujeto, si se falla la traducción, se deja sin traducir y no se produce
condición.
7. Creación de la condición:
Tras la realización de los pasos previos, tenemos las traducciones del sujeto y del
predicado, no necesitando más que unirlos.
Para el ejemplo del Listing 2 de la sección 3.1, la traducción quedaría de la forma
"args[0]==null || args[1]==null". Los parámetros de entrada de la función siempre
se catalogarán de la forma args[i], siendo i la posición que ocupan en la entrada del
método. También se puede comprobar que se inserta la unión entre ambas cláusulas
debido al "or" presente en el comentario y sustituido con un "||".
Así, finalizaría la labor del traductor de condiciones, y daría paso al generador de
oráculos.
8
3.3. Generador de oráculosEn este punto, los comentarios @throws ya han sido traducidos a expresiones boolea-
nas. Concretamente, el producto obtenido del traductor de condiciones es una tupla del
tipo (método m, excepción e, expresiónBooleana c) para cada comentario que se haya
traducido, en el que se identifica el método junto con la excepción que se ha de lanzar
cuando la condición booleana se cumple.
El generador de oráculos convierte esta salida en un oráculo de test y lo inserta en
cualquier caso de test que invoque m, de tal forma que, antes de ejecutar el caso de test,
se comprueba si la condición c se cumple y, en dicho caso, se lanza la excepción.
ToraDocu emplea AspectJ[9], que se encarga de generar un aspecto para ese caso de
test concreto,en el que modifica el bytecode de dicho caso de test para insertar las compro-
baciones previas mencionadas antes. Si no se ha conseguido generar ninguna condición,
el resultado de ToraDocu sería la creación de un aspecto vacío y que no modificaría el
caso de test.
En caso contrario, se generaría dicho test modificado. A la hora de ejecutar dicho
test, se comprueban las condiciones booleanas antes de lanzar el método. En caso de
cumplirse una, se esperará el lanzamiento de la excepción. Si se lanza, el test pasará. En
caso contrario, pueden suceder dos cosas, (i) que no se halla lanzado la excepción, o que
(ii) se halla lanzado otra excepción diferente, en donde, por tanto, se ha podido dar o un
fallo en el programa, o una inconsistencia entre código y comentario.
3.4. Plataforma de TestExisten dos tipos de test posibles en ToraDocu:
Pruebas unitarias: Estas pruebas comprueban el correcto funcionamiento de las di-
versas clases de ToraDocu, como pueden ser el Matcher, el JavadocExtractor, Th-
rowsTag o DocumentedMethod. Son pruebas que aseguran el manejo de datos y su
transformación.
Pruebas de sistema: Estas pruebas son más complejas. Son tests de regresión que se
miden mediante Precision and Recall. Comprueban que ToraDocu ha creado con-
diciones y, además, que estas son correctas.
Estas pruebas se realizan por sistema, de los cuales se han elegido ciertas clases,
ya sea por su complejidad o por su contenido en cuanto a comentarios complicados
y/o difíciles de procesar. Para ello, ToraDocu, a la salida de cada ejecución, crea un
json con la información de la clase, en donde se guarda toda la información de cada
método analizado en la clase.
9
2 {
3 " s i g n a t u r e " : " mu t a t e ( o rg . apache . commons . math3 . g e n e t i c s . Chromosome o r i g i n a l ) " ,
4 " name " : " m u t a t e " ,
5 " c o n t a i n i n g C l a s s " : {
6 " q u a l i f i e d N a m e " : " o rg . apache . commons . math3 . g e n e t i c s . B i n a r y M u t a t i o n " ,
7 " name " : " B i n a r y M u t a t i o n " ,
8 " i s A r r a y " : f a l s e9 } ,
10 " t a r g e t C l a s s " : " o rg . apache . commons . math3 . g e n e t i c s . B i n a r y M u t a t i o n " ,
11 " i s V a r A r g s " : f a l s e ,
12 " r e t u r n T y p e " : {
13 " q u a l i f i e d N a m e " : " o rg . apache . commons . math3 . g e n e t i c s . Chromosome " ,
14 " name " : " Chromosome " ,
15 " i s A r r a y " : f a l s e16 } ,
17 " p a r a m e t e r s " : [
18 {
19 " t y p e " : {
20 " q u a l i f i e d N a m e " : " o rg . apache . commons . math3 . g e n e t i c s . Chromosome " ,
21 " name " : " Chromosome " ,
22 " i s A r r a y " : f a l s e23 } ,
24 " name " : " o r i g i n a l "
25 }
26 ] ,
27 " th rowsTags " : [
28 {
29 " e x c e p t i o n " : {
30 " q u a l i f i e d N a m e " : " o rg . apache . commons . math3 . e x c e p t i o n .
M a t h I l l e g a l A r g u m e n t E x c e p t i o n " ,
31 " name " : " M a t h I l l e g a l A r g u m e n t E x c e p t i o n " ,
32 " i s A r r a y " : f a l s e33 } ,
34 " codeTags " : [
35 " o r i g i n a l " ,
36 " BinaryChromosome "
37 ] ,
38 " comment " : " i f o r i g i n a l i s n o t an i n s t a n c e o f BinaryChromosome . " ,
39 " k ind " : "THROWS" ,
40 " c o n d i t i o n " : " ( a r g s [ 0 ] i n s t a n c e o f BinaryChromosome ) == f a l s e "
41 }
42 ]
43 }
Listing 3: Ejemplo de JSON generado por ToraDocu
Para la realización de las pruebas, previamente se ha ejecutado ToraDocu para ge-
nerar dichos json. Estos se han almacenado y analizado uno por uno, cambiando el
campo "condition" presente dentro del @throws, que se utilizará para comparar el
generado con el esperado, y calcular así los valores de Precision and Recall.
El valor Precision es el resultante de calcular condiciones correctas entre todas las
condiciones:correctas
correctas+ incorrectas.
10
El valor Recall es el resultante de calcular condiciones generadas correctas entre las
correctas y no correctas (Además de las condiciones que no aparecen):
correctas
correctas+ incorrectas+ faltantes.
4. FUNCIONALIDADES AÑADIDASEn este punto se procede a la explicación del trabajo realizado, en donde se descri-
birán las tareas que se han llevado a cabo para aumentar la funcionalidad de ToraDocu,
y así no sólo limitarse al estudio del @throws, sino al del @param y el @return, pasan-
do de sólo analizar el comportamiento excepcional a extenderlo a las precondiciones y
postcondiciones, haciendo posible el testeo completo de un método.
4.1. Soporte para los Param tagsLos @param son los comentarios de Javadoc que expresan información sobre los pa-
rámetros de la función a la que describen. Suelen ser precondiciones las que vienen ex-
presadas en dichos tags.
Su estructura es la siguiente:
1 ∗ @param nombreDelParamet ro D e s c r i p c i o n D e l P a r a m e t r o .
Listing 4: Estructura de un @param
Gracias al análisis de estos tags, no sólo conseguimos comprobar las precondiciones,
sino que además, a la hora de generar input aleatorio para testear la función, conseguire-
mos reducir el número de fallos, ya que podremos cribar en base a estas precondiciones.
4.1.1. Análisis de patrones
A la hora de traducir los predicados de los comentarios @param, se partía de la base
ya adquirida gracias a los @throws.
Para esta tarea fue necesario la extracción de todos los comentarios @param presentes
en los cinco sistemas que se estudian en ToraDocu: Guava, Apache Commons Collec-
tions4 y Commons Math3, Freecol y Jgrapht.
11
Una vez extraídos todos los comentarios, se fueron analizando uno a uno su viabilidad,
catalogada de 1 a 3:
Catalogado a 1: Comentarios fácilmente traducibles, de patrón claro y que no dan
lugar a equivocación. Un ejemplo sería "@param:fraction Fraction to multiplyby, must not be @code null.", en el que se reconoce claramente la condición "must
not be null".
Catalogado a 2: Comentarios que no serían traducibles por ToraDocu a no ser que
se realizaran grandes cambios en el programa. Ejemplo de este tipo de comentarios
sería "@param:index index of the equation, must be between 0 included andgetNumberOfEquations (excluded)", en donde se extraería la condición descrita
por el intervalo.
Catalogado a 3: Comentarios que ToraDocu no puede traducir, ni a corto ni a largo
plazo, o que carecen de información que utilizar a la hora de generar los tests.
Los ejemplos serían "@param:handler event handler" y "@param:primaryarray containing the current value of the primary state vector", donde se ve
que el primero no da precondición alguna sobre el parámetro, y el segundo tiene
una complejidad muy alta como para ser utilizado en un caso de test.
Tras finalizar el estudio, se comprobó que el 2 % de estos casos eran traducibles sin
tener que modificar mucho ToraDocu, mientras que el segundo caso ocupaba el 10 %,
siendo el 88 % comentarios de gran dificultad o que no proporcionan información útil pa-
ra la creación de tests.
Al realizar las primeras ejecuciones de la herramienta sin modificar (Es decir, con
el mismo traductor de condiciones que tenía el @throws) para saber cómo ToraDocu se
comportaba ante los comentarios del @param, se vio que ToraDocu no era capaz de tra-
ducir el 10 % de los casos catalogados con 1. Es por ello que, al analizar los comentarios,
se tuvo que identificar patrones y causas por las que fallaba el programa.
Se vio que ToraDocu no era capaz de traducir los patrones existentes en @param
debido a que los predicados distaban bastante en cuanto a forma de escribir. Mientras que
en el @throws se veía que el comentario era una fórmula condicional, en el @param era
una fórmula imperativa, en donde se utilizaban diferentes formas verbales (Un ejemplo de
un tipo de patrón, sería el "Must be [condición]", donde, a diferencia de los comentarios
del throws, la forma verbal del verbo "be" es el infinitivo, y no conjugada en singular o
plural.
12
4.1.2. Extracción y traducción de @param
Tras dicha tarea de análisis de patrones, se procedió a realizar la infraestructura y la
modificación de clases que permite manejar estos tags.
Se creó la clase ParamTag. Ésta es la que sostendría la información de los @pa-
ram, tanto nombre del parámetro como sus atributos, así como el comentario y la
condición que posteriormente producirá dicho comentario.
Hubo que modificar el extractor de Javadoc para poder extraer los @param del Java-
doc. Debido a que los tipos que devuelve la API son diferentes de los que nosotros
manejamos, también hubo que realizar extracción de información de dichos tipos
para manejarla de forma correcta. Además, en esta parte se introdujo un tipo de
control específico para comprobar que todos los nombres de los parámetros en los
@param estuvieran presentes en el método, y en caso contrario, reportar un error.
La clase DocumentedMethod se modificó también para almacenar de cada método
los @param correspondientes.
Tras realizar esos cambios en la estructura, se continuó con la parte más importante,
el traductor de condiciones. Como se mencionó previamente, las diferencias entre los dos
tipos de tags que se iban a analizar hacían difícil la reutilización del trabajo ya hecho, por
lo que había que cambiar el modo de análisis en los @param.
Uno de los problemas al que nos enfrentábamos era a la falta de sujeto en muchas
de las oraciones, ya que se daba por hecho que se trataba del parámetro en cuestión. Sin
embargo, el Stanford Parser no podía crear condiciones de oraciones sin sujeto, por lo que
hubo que insertarlo manualmente en cada oración.
Identificando patrones, se comprobó que un gran número eran imperativos, por lo que
seguían la siguiente forma:
(Must/n’t|Could/n’t|Should/n’t) be (condition)
Debido a esto, en la fase previa al traductor, se hubo de insertar en el comentario de
forma manual el parámetro, para que el Stanford Parser lo reconociera.
En este punto, y gracias al previo análisis, pensamos que ya teníamos cubiertos la gran
parte de los casos del @param, por lo que posteriormente se continuó con el testeo de la
parte dedicada a estos tags.
13
4.1.3. Modificación de la plataforma de test y mejoras del análisis
Al concluir las labores de análisis de patrones y extracción y traducción de @param,
se procedió a la selección de clases para trabajar, mantener y mejorar el @param en To-
raDocu. Se escogieron alrededor de 30 clases de entre todos los paquetes seleccionados,
más las clases ya existentes para poder trabajar con el tag.
Dado que el json esperado no contenía el campo ParamTag, se tuvo que realizar una
fusión entre los anteriores y los nuevos jsons generados por ToraDocu, para poder man-
tener el sistema de Precision and Recall que existía con el @throws. También se hizo
cambios en las bases de datos que ToraDocu almacena con los resultados de cada méto-
do, añadiendo los campos correspondientes a los valores del @param.
Tras la correspondiente fusión, se fue por cada json colocando la condición esperada
en cada uno de los campos correspondientes.
Al concluir esto, se obtuvo unos resultados ligeramente negativos, en el que el valor
de Precision en el programa rondaba el 65-70 %, y el valor de Recall un 50 %.
Dados los resultados iniciales, se procedería a la resolución de los problemas existen-
tes con los @param que teníamos en los casos de análisis. Esta tarea a día de hoy sigue
vigente, con unos resultados bastante más favorables, en los que se obtiene un valor del
98 % de Precision y un 88 % en Recall gracias a las tareas de mejora realizadas.
Mejoras:
De la misma forma que se hubo de insertar el sujeto en unas partes, a causa del ca-
rácter restrictivo que deseábamos que tuvieran las precondiciones escritas en el @param,
hubo que eliminar ciertas precondiciones que expresaban posibilidad y no restricción, pe-
ro que ToraDocu interpretaba como restrictivas. Un ejemplo de esto es la cláusula "May
be", que no expresa más que la posibilidad de.
Otro de los problemas que se solucionó fue la falta de sujeto y verbo en la frase.
@param list The list to fill. Not null, not empty
Como se puede ver en el ejemplo, la segunda cláusula de la oración no tiene ni sujeto
ni verbo, dado que ambos están omitidos, y sólo se tiene una frase. Al no poder generar
un árbol semántico satisfactorio, se decidió incluir como patrón especial tanto "not null"
como "not empty", dada la cantidad de comentarios de este tipo. Con este patrón, se
añade tanto sujeto como verbo de forma previa al "not", de tal forma que la frase queda
totalmente aislada de la cláusula anterior y pudiendo así generar el árbol semántico con
el parámetro como sujeto y el verbo "be" conjugado.
14
4.2. Soporte para los Return tagsLos @return son los comentarios de Javadoc que expresan información sobre el valor
de salida de la función en cuestión. Suelen ser postondiciones las que vienen expresadas
en dichos tags.
La estructura más común encontrada es la siguiente:
1 ∗ @return v a l o r D e R e t o r n o s i c o n d i c i o n A C u m p l i r P a r a E l l o c a s o C o n t r a r i o
v a l o r D e R e t o r n o E n C a s o C o n t r a r i o .
Listing 5: Estructura de un @return
Gracias al análisis de estos tags, conseguimos comprobar el valor de salida de la fun-
ción. La importancia del análisis de estos tags viene dada por la gran ventaja que ésto
supone: Poder ser capaces de testear un método de forma completa sin necesidad de pro-
gramar el test por nosotros mismos.
Así pues, y gracias a ésto, ToraDocu cumple su objetivo.
4.2.1. Análisis de patrones
A la hora de traducir los predicados de los comentarios @return, se partía de la base
ya adquirida gracias a los @throws y parte de los @param.
Para esta tarea fue necesario la extracción de todos los comentarios @return presentes
en los cinco sistemas que se estudian en ToraDocu.
15
Una vez extraídos todos los comentarios, al igual que en @param, se fueron analizan-
do uno a uno su viabilidad, catalogada de 1 a 3:
Catalogado a 1: Comentarios fácilmente traducibles, de patrón claro y que no dan
lugar a equivocación. Un ejemplo sería "@return true.", en el que se reconoce
claramente que la función siempre retornará verdadero. Otro ejemplo de estos casos
podría ser "@return true if a is less than 0; otherwise false, en donde se ve que
el valor de retorno es verdadero si se cumple la condición a<0, y falso en el caso
contrario.
Catalogado a 2: Comentarios que no serían traducibles por ToraDocu a no ser que
se realizaran grandes cambios en el programa. Ejemplo de este tipo de comentarios
sería "@return the first prime number of the array", en donde se entendería
que el valor de salida sería el primer número primo del array, teniendo que recorrer
todos los componentes del array hasta encontrar el primer primo.
Catalogado a 3: Comentarios que ToraDocu no puede traducir, ni a corto ni a largo
plazo, o que carecen de información que utilizar a la hora de generar los tests. Los
ejemplos serían "@return a list" y "@return an iterator positioned in the 5thposition if the count is greater than 6 in runtime.", donde se ve que el primero no
da postcondición alguna, y el segundo tiene una complejidad muy alta como para
ser utilizado en un caso de test.
Tras finalizar el estudio, se comprobó que el 0,5 % de estos casos eran traducibles
sin tener que modificar mucho ToraDocu, mientras que el segundo caso ocupaba el 5 %,
siendo el 94,5 % comentarios de gran dificultad o que no proporcionan información útil
para la creación de tests.
Al realizar las primeras ejecuciones de la herramienta sin modificar (Es decir, con
el mismo traductor de condiciones que tenía el @throws y con las modificaciones per-
tinentes realizadas en el @param) para saber cómo ToraDocu se comportaba ante los
comentarios del @return, se vio que ToraDocu no era capaz de traducir siquiera el 5 % de
los casos catalogados con 1. Al igual que con el @param, se procedió a la revisión de los
patrones y formas características del @return.
Se vio que ToraDocu no era capaz de traducir los patrones existentes en @return de-
bido a que la estructura era la más compleja de todas. Aun siendo similar al @throws,
se daba el caso de que los predicados aumentaban en complejidad mucho más que en los
anteriores tags.
Se identificó un patrón común a la gran mayoría de comentarios, y es el que se mues-
tra como ejemplo en el Listing 5. Los comentarios ahora tenían varias partes de la frase
que ser analizadas. Antes, todo el comentario era dado al Stanford Parser para que pudie-
ra generarnos los árboles semánticos. Ahora, había que separar la frase en tres pedazos
diferentes, para poder analizarlos de forma independiente.
16
Valor de Retorno: Es la característica que cumple el valor de retorno en caso afir-
mativo.
Condición a cumplir para el primer valor de retorno: Condición que ha de cumplirse
para que se pueda aplicar la característica indicada en el primer valor de retorno.
Caso contrario: Campo que identifica la negación de la primera cláusula,
Valor de Retorno en caso contrario: Característica del valor de retorno que se da al
no cumplirse la primera condición.
4.2.2. Extracción y traducción de @return
Tras dicha tarea de análisis de patrones, se procedió a realizar la infraestructura y la
modificación de clases que permite manejar estos tags.
Se creó la clase ReturnTag. Ésta es la que sostendría la información de los @re-
turn, tanto nombre del parámetro como sus atributos, así como el comentario y la
condición que posteriormente producirá dicho comentario.
Hubo que modificar el extractor de Javadoc para poder extraer los @return del
Javadoc. Esta parte fue más fácil de manejar y mucho menos liosa, ya que el return
carece de información específica tal como parámetros o excepciones a lanzar: Es
un comentario en bruto, y de ahí su dificultad para ser analizado.
La clase DocumentedMethod se modificó también para almacenar de cada método
los @return correspondientes y las condiciones que estos generarían.
Como en el anterior tipo de tag, se procedió a los cambios más importantes y compli-
cados en el programa, los cambios en el traductor de condiciones.
Para este caso especial, se separó el return en tres partes. La primera de ellas sería la
correspondiente al valor de retorno descrito anteriormente. El segundo sería la primera
condición de retorno. Y finalmente, la tercera parte sería la correspondiente al caso nega-
tivo, la tercera y cuarta partes juntas.
En el análisis de la primera, se contempló que los valores de retorno sólo podrían ocu-
par los valores de "true" o "false". Por tanto, se hizo la asumpción de que estos valores
sólo tendrían esas dos posibilidades, decidiendo así en una primera instancia limitar To-
raDocu a funciones booleanas, por definición.
La segunda parte se conseguía tras partir la frase por el primer " if " que se encontraba
en esta, separando el valor de retorno y la condición. La condición se traduce de la misma
forma que se traduce en el @throws.
17
Finalmente, la tercera parte que aparecía de forma opcional, se obtenía partiendo la
oración gracias a palabras claves como "otherwise", o por la aparición de ";" en la oración,
y su análisis es igual que la segunda parte.
Al concluir la traducción, todas las condiciones se juntan en una sola, dando lugar a
un tipo de condición característico del @return:
1 c o n d i t i o n : " Cond ic ion ? R e s u l t a d o S i C o n d i c i o n T r u e [ : R e s u l t a d o S i C o n d i c i o n F a l s e ]
Listing 6: Estructura de la condición en el @return
La condición es la parte Java que se evaluará a verdadero o falso, y en base a ese valor,
se determinará una característica para el valor de return.
4.2.3. Modificación de la plataforma de test y mejoras
Al concluir las labores de análisis de patrones y extracción y traducción de @return,
al igual que en el param, se procedió a la selección de clases para trabajar, mantener y
mejorar el @return en ToraDocu. Se escogieron alrededor de 20 clases de entre todos los
paquetes seleccionados, más las clases ya existentes (del @throws y del @param) para
poder trabajar con el tag.
Dado que el json esperado no contenía el campo ReturnTag, de la misma forma que
se realizó con el @param, se tuvo que realizar una fusión entre los anteriores y los nuevos
jsons generados por ToraDocu, para poder mantener el sistema de Precision and Recall.
También se hizo cambios en las bases de datos que ToraDocu almacena con los resultados
de cada método, añadiendo los campos correspondientes a los valores del @return.
Tras la correspondiente fusión, se fue por cada json colocando la condición esperada
en cada uno de los campos correspondientes.
Al concluir esto, se obtuvo unos resultados nefastos, en el que el valor de Precision en
el programa rondaba el 50 %, y el valor de Recall un 5 %.
Debidos a estos malos resultados, se procedió a realizar mejoras en el análisis.
Una de ellas fue la contemplación de la existencia de sólo una característica del valor
de return, sin necesidad de que éste fuera verdadero o falso, es decir, que se cumple siem-
pre. Estas son las condiciones del tipo "@return: a sorted bag", en donde se determina
que directamente la característica que se produce sería la de "result.isSorted()".
Otra de las mejoras vino producida por los fallos de ToraDocu a la hora de reconocer
el sujeto. Para ello se implementó un POSTagger. La función de este módulo es la de
catalogar, sin necesidad de pasar por el Stanford Parser, el sujeto.
18
Esto no funciona con todos los comentarios @return debido a que se fundamenta en
la existencia de @code tags rodeando al elemento del código al que se refiere el @return
como se puede ver a continuación:
1 @return a s o r t e d bag i f {@code e l e m e n t } does n o t c o n t a i n s any n u l l v a l u e .
Listing 7: Ejemplo de @code en @return
Con esta técnica lo que se consigue es que el Stanford Parser se adapte a nuestro tag
personalizado, traduciendo directamente el predicado sobre él.
5. EVALUACIÓN Y TESTEn esta sección se evaluará y medirán los resultados de los test arrojados por ToraDocu
antes y después de las mejoras.
5.1. Estado previoComo se ha explicado anteriormente, ToraDocu antes de este TFG, sólo manejaba los
comentarios del tipo @throws.
Los resultados de los test fueron de una Precision del 82 % y un Recall del 52 %, con-
templando un total de 289 métodos en estudio.
Los predicados comprendidos no iban más allá de lo simple, contemplando condicio-
nes sencillas como "is null", "is > than" o "is true", así como el reconocimiento de algunas
funciones como "isEmpty()".
5.2. Estado actualA día de hoy, y gracias a este TFG, ToraDocu se ha expandido a los @param y a los
@return.
Los resultados de los test fueron de una Precision del 95 % y de un Recall del 76 %,
en el caso global, contemplando 430 métodos en total, y en concreto, los del @throws
mejoraron hasta una Precision del 95 % y un Recall del 75 %.
Los otros dos tags registraron unos resultados finales de una Precision del 98 % y un
Recall del 88 % para el @param, y un 84 % y 54 % para el @return, respectivamente.
5.3. Caso real: Uso de ToraDocuA pesar de ser un trabajo de investigación y estar aún en desarrollo, a continuación se
muestra un estudio realizado con ToraDocu.
19
En él se ha realizado la ejecución de ToraDocu sobre todas las clases de los sistemas
Commons Collections4[10], Commons Math3[11] y PlumeLib[12]
Figura 2: Condiciones del @param en Commons Collections
Figura 3: Condiciones del @throws en Commons Collections
Como se puede comprobar en los gráficos de @throws y @param de Collections [Fi-
guras 1 y 2], en más de la mitad de predicados se produce al menos una condición. Ade-
más, se puede observar que el porcentaje de reconocimiento de condiciones tanto en los
@param como en los @throws se obtiene el mismo porcentaje, debido a que existe una
fuerte correlación entre dichos tags, dado que en la gran mayoría de los casos una viola-
ción de las precondiciones provoca una excepción.
20
Figura 4: Condiciones del @return en Commons Collections
En cambio, en el @return de Collections [Figura 3] vemos cómo ToraDocu sólo pro-
porciona condiciones de aproximadamente un 15 % de estos tags, debido a su estado
menos avanzado y la complejidad de dichos tags.
Figura 5: Condiciones del @param en Commons Math3
Figura 6: Condiciones del @throws en Commons Math3
21
De la misma forma que se observó esa estrecha correlación en Collections, en @th-
rows y @param de Math3 también se puede observar esta propiedad [Figuras 4 y 5]
Figura 7: Condiciones del @return en Commons Math3
En Math3, notamos cómo el ratio de @return que produce condición aumenta [Figura
6], probablemente debido a la cantidad de predicados aritméticos que contiene y que To-
raDocu es capaz de traducir.
22
Figura 8: Condiciones del @param en Plume Lib
Figura 9: Condiciones del @throws en Plume Lib
Figura 10: Condiciones del @return en Plume Lib
Y para finalizar vemos que, al igual que en los dos sistemas anteriores, en Plume Lib
también existe esa estrecha correlación entre @param y @throws [Figura 7 y 8], y que el
ratio de @return también aumenta respecto a los dos anteriores [Figura 9].
23
6. TRABAJO FUTUROCaso real de ToraDocu: Control sobre la programación del desarrollador.
Como se ha visto en el punto 5.3, se pueden realizar con ToraDocu controles sobre
la calidad de la documentación de sistemas y/o clases. Esto aplicado a una em-
presa, serviría para realizar cribas entre los desarrolladores que no documenten su
código con X calidad, siendo la calidad el porcentaje de condiciones que debería
de producir los tags del JavaDoc de la clase que se programe, y pudiendo avisar al
desarrollador de dichos fallos para que los pueda corregir, aumentando así la calidad
de la documentación.
Analizador semántico
En el futuro, se plantea además del uso del analizador sintáctico que ahora mismo
se tiene, la implementación de un analizador semántico, que nos permitiría eliminar
la distancia de Levensthein para relacionar elementos del código con los sujetos/-
predicados para sustituirla con sinónimos entre palabras. Es decir, que ya no sólo
se compararía por distancia de Levensthein, sino que se haría uso de un diccionario
de sinónimos para poder relacionar ambos elementos. Ésto ayudaría a la identifica-
ción del sujeto en caso de que el desarrollador haya utilizado un nombre distinto al
elemento del código en la documentación.
Plataforma online de integración continua
Como se ha visto anteriormente, ToraDocu puede ser una herramienta perfecta de
control de documentación. Además de ésto, también cabe la posibilidad de hacer
que ToraDocu, con un funcionamiento similar a Travis CI[13], sirva de herramienta
de integración continua, generando los tests de las clases que se decidan subir a
dicha plataforma y testeándolas online, sin necesidad de ejecutar ToraDocu en tu
ordenador.
Machine learning
Aprendiendo de los casos buenos y de los casos malos, ToraDocu podría aumentar
su eficacia si se utilizara esta técnica, en donde el programa podría aprender qué
elementos comunes tienen ciertos tipos de condiciones, y aumentando así el ratio
de documentación que ToraDocu podría traducir a condiciones.
24
7. CONCLUSIONESSe ha de resaltar que este trabajo ha sido en su mayor parte de investigación. Es por
ello que muchas de las dudas y problemas que han surgido no han podido más que intentar
esclarecer y resolver de la mejor forma posible, con mucha prueba y error.
Debido al hecho anterior, se resalta la necesidad de tener una mente abierta y mucha
creatividad a la hora de desarrollar el software para que éste funcione como es necesario.
Gracias a este trabajo, he comprendido la necesidad de la documentación y el gran
potencial que tiene en este campo, así como lo útil que resultan algunas herramientas
NPL como el Stanford Parser. He podido probar de primera mano lo que es el estar en un
proyecto de investigación y he aprendido cómo se manejan las cosas en este entorno.
Finalmente decir que, a pesar de que los resultados del proyecto aún no son perfectos
y aún queda mucho por mejorar en ToraDocu, el proyecto apunta alto, no sólo como he-
rramienta de testing, sino como herramienta de traducción de lenguaje natural a lenguaje
de programación, y que sus trabajos futuros, aunque se hayan citado anteriormente sólo
algunos, éstos son cuasi infinitos.
25
REFERENCIAS[1] C. Saran, “Application testing costs set to rise to 40 of it budget”, 2015. dirección:
http://www.computerweekly.com/news/4500253336/Application-testing-costs-set-to-rise-to-40-of-IT-budget.
[2] E. G. y Kent Beck, “Junit”, 2017. dirección: http://junit.org/junit4/.
[3] G. Fraser y A. Arcuri, “Evosuite: automatic test suite generation for object-oriented
software”, 2011. dirección: http://www.evosuite.org/.
[4] C. Pacheco y M. D. Ernst, “Randoop: feedback-directed random testing for java”.
dirección: http://doi.acm.org/10.1145/1297846.1297902.
[5] S. H. Tan, D. Marinov, L. Tan y G. T. Leavens, “@tcomment: testing javadoc
comments to detect comment-code inconsistencies”, en In Proc. 5th ICST, 2012,
págs. 260-269.
[6] A. Goffi, A. Gorla, M. D. Ernst y M. Pezzè, “Automatic generation of oracles for
exceptional behaviors”, 2016.
[7] “Javadoc api”. dirección: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html.
[8] “Stanford parser library”. dirección: https://nlp.stanford.edu/software/lex-parser.shtml.
[9] “Aspectj”. dirección: https://eclipse.org/aspectj/.
[10] “Commons collection4”. dirección: https : / / commons . apache . org /proper/commons-collections/.
[11] “Commons math3”. dirección: https://commons.apache.org/proper/commons-math/.
[12] “Plume lib”. dirección: https://github.com/mernst/plume-lib.
[13] “Travis ci”. dirección: https://travis-ci.org/.
26
Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,
C=ES
Fecha/Hora Wed Jun 07 14:18:02 CEST 2017
Emisor delCertificado
EMAILADDRESS=camanager@fi.upm.es, CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES
Numero de Serie 630
Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)
top related