PIE06-102

La corrección automática en asignaturas de programación

Francisco Durán

Francisco Gutiérrez (pacog@lcc.uma.es)

Ernesto Pimentel

E.T.S.I. en Informática

Palabras Clave: autoevaluación, tutorización virtual.

Resumen

Muchas son las herramientas profesionales dedicadas a la corrección de software, que ofrecen al programador la posibilidad de descubrir los errores que contienen sus programas. Sin embargo, en el ámbito de la enseñanza en asignaturas de introducción a la programación de computadores, una herramienta de este tipo debería permitir al alumno no sólo conocer los errores de sus programas sino además obtener información sobre cómo resolverlos. Es deseable también obtener una valoración del trabajo que se ha realizado de manera que el alumno se motive y pueda avanzar de forma inmediata y autónoma. Esto es particularmente importante dentro del contexto del Espacio Europeo de Educación Superior (EEES) donde esta autonomía en la realización y valoración de prácticas permite que el alumno pueda disponer de un gran número de ellas a lo largo del curso académico. Con este objetivo nace JCap, una herramienta que ha sido probada en el contexto de la asignatura "Laboratorio de Tecnologías de Objetos" de la E. T. S. Ingeniería Informática de la Universidad de Málaga, con resultados que muestran su utilidad docente.

1. Objetivos En este trabajo se describe una herramienta para la corrección y valoración de prácticas de

laboratorio en asignaturas de programación denominada JCap. Aunque está orientada al lenguaje de programación Java, su adecuación a cualquier otro lenguaje orientado a objetos sería bastante directa. La herramienta constituye un buen soporte al profesor cuando éste tiene grupos numerosos que impiden un adecuado seguimiento de las prácticas. Al mismo tiempo, permiten que el alumno pueda desarrollar su trabajo con cierta independencia, obteniendo de la herramienta una respuesta rápida sobre los posibles fallos que pueda cometer, así como una valoración sobre el nivel del cumplimiento de objetivos. Esto suele redundar positivamente en la motivación del alumno, tanto por la “tutorización virtual” recibida, como por la inmediatez de la misma.

2. Descripción de la experiencia Aprender a programar, como aprender a escribir o a leer, requiere mucha práctica. Un buen

1

programador necesita desarrollar muchas aplicaciones durante su periodo de formación, ponerse en muchas situaciones distintas y conocer muchos algoritmos, estructuras de datos, herramientas, metodologías, etc. para saber escoger la mejor opción en cada momento. El objetivo fundamental de todo este proceso no es otro que el de adquirir unas habilidades bastante concretas, que les servirán posteriormente para avanzar en su formación y después para desarrollarse profesionalmente. No es por tanto suficiente con hacer los programas, ni siquiera con que funcionen. Durante el proceso de aprendizaje, sobre todo en las primeras etapas, es necesario disponer de unas pautas muy claras y ser guiados muy de cerca por personal con conocimiento y experiencia, tanto en programación como en el aprendizaje de la programación, que les permitan adquirir los conceptos necesarios y llevarlos a la práctica de forma adecuada.

La situación en nuestras aulas, aunque va mejorando, dista bastante de la situación ideal; con el gran número de alumnos por profesor y la sobrecarga de este último nos hemos encontrado en demasiadas ocasiones con que había muchos alumnos a los que el profesor no les había visto nunca un programa de ordenador hasta el día del examen final, incluso alumnos que nunca habían desarrollado por sí mismos un programa antes de dicho examen final. Por otra parte, la complejidad de estos programas hace que su revisión lleve demasiado tiempo, lo cual convierte en una pretensión totalmente irreal intentar corregir una o más prácticas a todos los alumnos. Esto, cuando lo deseable es que el alumno realizara decenas, si no cientos, de programas dista demasiado del ideal.

Con el objetivo de mejorar esta situación los profesores de la asignatura “Laboratorio de Tecnología de Objetos” hemos venido desarrollando diferentes propuestas. En muchas ocasiones nos dábamos cuenta de que los alumnos empezaban haciendo un esfuerzo que pronto decaía por falta de respuesta o por demora en la misma. En muchos casos empezaban a hacer un trabajo que, o daban por bueno sin preocuparse de comprobarlo, o no eran capaces de interpretar. Les cuesta en ocasiones entender por qué algo que han hecho está mal. No es suficiente con ver una respuesta correcta, es preciso indicarles qué falla y cuál es el motivo. Tras un par de sesiones cada vez era más frecuente encontrar alumnos que ni siquiera intentaban hacer los ejercicios propuestos, sino que directamente esperan a que el profesor dé la solución.

La situación de los grupos en los que se ha aplicado la experiencia piloto de Convergencia al Espacio Europeo de Educación Superior en las titulaciones de Informática de la Universidad de Málaga, y en particular, en la asignatura “Laboratorio de Tecnología de Objetos”, hacen difícil un seguimiento personalizado de los alumnos con los recursos de profesorado con los que se ha contado hasta el momento, que no han diferido de los de cursos anteriores. Más de 200 alumnos se han visto involucrados, con cinco profesores, y el contenido, fundamentalmente práctico, relativo a temas de programación, agravan esta situación.

Con objeto de conseguir el efecto motivador, el trabajo continuo y la revisión de temas no asimilados que un seguimiento personal del profesor suele producir sobre el alumno, durante este curso se ha hecho un uso sistemático del Campus Virtual de la Universidad de Málaga, y éste se ha complementado con la aplicación de una herramienta desarrollada por los profesores de la asignatura, denominada JCap, para informar al alumno sobre los errores detectados en las prácticas desarrolladas de forma minuciosa y automática, y notificar de la superación de las mismas. La coordinación de los profesores participantes ha sido fundamental en la experiencia, además de utilizar material común (notas de clase, transparencias, prácticas, etc.), hemos tenido una única asignatura en el Campus Virtual para los seis grupos (de las tres titulaciones), las fechas de entrega de los ejercicios y el proceso de corrección también ha estado unificado.

Aparte del esfuerzo que se requería, la dificultad para obtener una herramienta como la desarrollada, la efectividad del sistema, etc., uno de los mayores riesgos al que nos enfrentábamos era el de poder garantizar la autoría de los ejercicios entregados. De forma selectiva podemos corregir algunos ejercicios, pero esto se hace más para proporcionar información adicional y para confirmar que la respuesta dada por JCap es válida que para detectar posibles copias. Para evitar

2

este problema el uso de JCap se ha complementado con el uso de herramientas para la detección de plagio, en concreto la herramienta JPlag [7], desarrollada por Guido Malpohl.

Entre las propiedades más interesantes de JCap se puede destacar la emisión de informes al alumno, indicando las fases superadas en la práctica y los errores cometidos. La inmediatez y detalles de la información facilitada, además de motivar al alumno, le permiten evolucionar de forma independiente en aquellas situaciones donde no tenga acceso directo o inmediato al profesor. Además, la herramienta ofrece al profesor una automatización del proceso de valoración de prácticas, asignando niveles distintos de superación de objetivos.

La herramienta está estructurada de manera que los profesores sólo han de desarrollar las pruebas concretas de la práctica en cuestión, siendo el motor que pasa las pruebas y genera los informes común a todas las prácticas.

La asignatura de “Laboratorio de Tecnología de Objetos” se imparte en la Escuela Técnica Superior de Ingeniería Informática de Málaga dentro de sus dos especialidades técnicas, Sistemas y Gestión, y en la ingeniería superior. Dentro del currículo, se sitúa en el segundo cuatrimestre del segundo curso con 6 créditos, con un gran peso de clases prácticas, desarrolladas en su mayoría en laboratorios. También tiene un contenido teórico importante, necesario para dominar la tecnología, que se introduce por primera vez en esta asignatura. La necesidad de introducir gran cantidad de conceptos nuevos hace que se reduzca el tiempo dedicado al trabajo en el laboratorio. Las prácticas de la asignatura se realizan utilizando como lenguaje de programación Java.

En su momento, los profesores de la asignatura afrontaron la necesidad de incluir prácticas adicionales a las tutorizadas en clase de laboratorio, para que los alumnos las desarrollaran como parte de su trabajo personal (contabilizado en los créditos ECTS), sin presencia del profesor. Si bien los alumnos se felicitaron de esta idea, la realización de las mismas resultaron algo frustrante para ellos porque cierto tipo de dificultades les obligaba a consultar al profesor antes de proseguir con el trabajo, impidiendo la continuidad del mismo. Observamos que muchos de los estudiantes realizaban las prácticas en días no lectivos (fines de semana, festivos, Semana Santa, etc.), por lo que esa consulta no tenía lugar hasta la reanudación del período lectivo. Esto frustraba enormemente al alumno, frenando su iniciativa y por tanto su aprendizaje.

Con objeto de resolver en parte ese problema, decidimos introducir una herramienta de apoyo al aprendizaje del alumno, de manera que cuando se producía esa parada, pudiera informársele de la situación anómala en la que se encontraba, es decir de los fallos que estaba cometiendo y que le impedían seguir con la práctica. Además, era necesario que la herramienta fuera capaz de ofrecer una valoración justificada al alumno del trabajo realizado en la práctica de manera que pudiera ir mejorando esa valoración atendiendo a las indicaciones que la herramienta proporciona.

La detección de errores es un tema crucial en el proceso de desarrollo de software, y son varias las herramientas existentes en la actualidad dedicadas a verificar la corrección de programas [3,4]. Entre éstas podemos destacar JUnit [5] y TestNG [1], centradas ambas en el lenguaje Java, y adecuadas por proporcionar una comprobación de la corrección de cada aplicación que se desarrolla. Para usar este tipo de herramientas, el programador debe generar lo que se denominan clases de prueba, una por cada clase que necesite verificar. Cada uno de estos elementos debe verificar la corrección de todos los métodos (funciones) que incluye la clase (módulo en un lenguaje orientado a objetos). Así, se genera una batería de pruebas que puede lanzarse de forma automática cada vez que se produce un cambio en la implementación que se está desarrollando.

Cuando una de esas pruebas detecta un error, se informa al usuario mostrando el punto donde se ha producido y el motivo que lo ha provocado. Esto no detiene al resto de pruebas, que siguen ejecutándose proporcionando al final un informe con los resultados obtenidos en cada prueba. Sobre JUnit y TestNG se han desarrollado otras herramientas que ofrecen una interfaz más amigable de manera que el usuario va siguiendo la evolución de las pruebas que la herramienta va ejecutando sobre sus clases.

3

En el ámbito de la docencia, una herramienta como JUnit también puede resultar de ayuda tanto para el alumno como para el profesor. Para el alumno porque unas clases de prueba le ayudan a comprobar que cualquier modificación o implementación realizada satisface las especificaciones. Además, si es el profesor el que proporciona las clases de prueba el alumno se siente corroborado en su trabajo. Para el profesor porque puede obtener información sobre la funcionalidad de los ejercicios entregados por sus alumnos.

Dado que herramientas como JUnit y TestNG tienen un enfoque claramente orientado a la Ingeniería del Software, se encuentran ciertas dificultades cuando se intenta utilizar en el ámbito educativo. Enumeramos a continuación algunas de estas dificultades:

• JUnit y TestNG son adecuadas para ejecutar las pruebas sobre un conjunto de clases, pero es el profesor el que debe hacer esto con cada alumno. JCap automatiza este proceso.

• La integración de JUnit o TestNG con las clases a verificar se hace sobre el código fuente. Esto es, las clases de prueba que definen se compilan junto con las clases que se quieren verificar. Esto significa que, si por cualquier razón, las clases a verificar no compilan, no es posible ejecutar la prueba. Podríamos desarrollar herramientas para utilizar simplemente los compilados de las clases de prueba; sin embargo, en ese caso, la información sobre si las clases del alumno compilan o no, estarían fuera de la prueba en sí, y no podrían ser tenidas en cuenta en el informe emitido y la valoración final.

• Si un método produce ejecuciones que no terminan (error típico y habitual en alumnos de este nivel), JUnit no se detiene, ni advierte esta situación, por lo que necesitaría de la intervención del profesor. Si lo hace, se detiene la ejecución de todas las pruebas, pero en el ambiente docente puede que esta circunstancia aparezca con frecuencia como consecuencia de un mal diseño. Evidentemente se debe advertir de este problema al alumno, pero el resto de pruebas no debería detenerse por ello. Aún no entrando en ejecuciones que no terminan, es deseable fijar tiempos máximos para realizar las pruebas de manera que si se supera ese tiempo en alguna prueba se interrumpa su ejecución, informando nuevamente de que el algoritmo utilizado sobrepasa los requisitos temporales considerados. La última versión disponible de TestNG proporciona esta facilidad.

• Ni JUnit ni TestNG son capaces de valorar el grado de cumplimiento de las especificaciones. Es decir, simplemente informan de que algo ha ido mal pero no valoran el que haya ido bien. En el contexto de una actividad docente es de sumo interés valorar el trabajo del alumno atendiendo a cómo ha cumplido los objetivos y, si es necesario, penalizando las situaciones anómalas que aparezcan: ejecuciones que no terminan, provocar excepciones no esperadas, problemas de compilación, etc.

Como ya se ha mencionado, algunos de los problemas identificados se pueden resolver con cierta facilidad utilizando JUnit o TestNG. No obstante, otros, quizás los más interesantes desde el punto de vista docente, no tienen fácil solución. En este sentido sería deseable disponer de una herramienta que resuelva esas carencias.

Así nace JCap, una herramienta para la corrección automática de prácticas. JCap resuelve todos los problemas mencionados anteriormente, y en particular, valora el trabajo realizado por cada alumno permitiendo tener en cuenta malas prácticas de diseño.

JCap es un marco en el que se pueden configurar las pruebas. Se ofrece como una librería, de manera que el profesor se basa en ella para realizar las pruebas. JCap está contruida sobre TestNG, con lo que hemos conseguido simplificar en parte nuestra tarea.

Para la corrección de los ejercicios realizados es necesario que el profesor facilite las pruebas que han de realizarse sobre los ejercicios de los alumnos. La sintaxis en que se han de proporcionar dichas pruebas es la misma que la de TestNG, con algunas etiquetas adicionales. Dado que TestNG descarta las etiquetas que no conoce, esto nos permite tener la posibilidad de desarrollar las pruebas

4

para TestNG, con sus facilidades de programación, e incluso probarlos con TestNG en un primer momento, para a continuación, una vez que estamos satisfechos con las clases de prueba desarrolladas, utilizarlas dentro del contexto de JCap. La figura 6 muestra las clases que componen una prueba concreta.

Una vez tenemos estas clases de prueba es necesario proporcionar un fichero de configuración escrito en XML que permita seleccionar las pruebas a realizar así como definir los parámetros globales, puntuaciones de cada pregunta, etc. Para facilitar la creación del fichero XML también se ha desarrollado otra herramienta que, partiendo de las pruebas, extrae la información necesaria de manera que sea simple su configuración. La figura 5 muestra una imagen de su uso.

Una vez desarrolladas las pruebas, podemos ejecutarlas sobre la práctica del alumno utilizando una de las dos herramientas desarrolladas, una con vista a que sea el propio alumno el que la utilice, y otra para que sea el profesor. El núcleo de estas dos herramientas es el mismo, radicando la principal diferencia en que la versión del profesor evalúa sistemáticamente todas las prácticas en un directorio especificado, mientras que la del alumno corrige una sola práctica en cada ejecución.

Cuando el alumno ejecuta la prueba sobre su trabajo, la aplicación le informa de los pasos que se van ejecutando, si se va superando o no, y en qué grado se supera. Al final, el alumno obtiene un informe de los fallos detectados y de la puntuación obtenida. Esto permite al alumno modificar su trabajo según lo observado y volver a realizar la prueba, tantas veces como lo crea conveniente hasta la superación total. Las figuras 1 y 2 muestran el aspecto de la aplicación de alumno ejecutadas con un programa de prueba sin y con detalles, respectivamente. Del banco de pruebas disponible es posible seleccionar aquellas que se desea se realicen sobre el ejercicio. En la figura 2 la puntuación es menor que en la figura 1 porque se han seleccionado menos pruebas a realizar.

Fig. 1. Aplicación del alumno tras ejecutar un test sin detalles.

5

Fig. 2. Aplicación del alumno tras ejecutar un test con detalles.

La aplicación para el profesor está enfocada a la ejecución de las pruebas sobre un conjunto de alumnos recopilando información de los fallos y las puntuaciones obtenidas. Como resultado se obtiene un informe de cada alumno y un resumen general. La figura 3 muestra el aspecto de la aplicación de profesor. Obsérvese cómo la misma valora todas las prácticas dadas y muestra los informes generados.

6

Fig. 3. Aplicación de profesor (los nombres de los alumnos han sido parcialmente tachados).

La figura 4 muestra de forma simplificada el conjunto de clases e interfaces desarrolladas dentro del paquete JCap.

Como decíamos, durante el curso 2006-2007, hemos llevado a cabo una experiencia educativa utilizando la herramienta que estamos aquí contemplando en la asignatura “Laboratorio de Tecnología de Objetos” de las tres titulaciones de Informática. A lo largo del curso, les proponemos a nuestros alumnos que resuelvan dos prácticas, una de las cuales era de mayor envergadura que la otra. Para cada práctica, les damos un plazo de entrega de su solución. Una vez entregada, les proporcionamos el programa de pruebas con el que ellos mismos descubren sus errores. Ahora, le volvemos a permitir hacer una segunda entrega pero sólo si han conseguido superar completamente las pruebas proporcionadas. En ese caso, la calificación que obtiene en la práctica es la nota de la primera entrega más 2.5. Si no se hace segunda entrega, la nota es la obtenida en la primera. Si no se hace primera, la nota es 2.5. Cada práctica, tiene una calificación mínima para aprobar e influyen en la calificación final. La práctica de mayor envergadura convalida parte del examen final mientras que las otras suman calificaciones.

7

Figura 4. Clases del paquete8

Figura 5. Creación de XML

9

Figura 6. Una prueba para Árboles

10

3. Resultados y conclusiones En este trabajo se ha descrito una herramienta para la corrección y valoración de prácticas de

laboratorio en asignaturas de programación. Aunque está orientada al lenguaje de programación Java, su adecuación a cualquier otro lenguaje orientado a objetos sería bastante directa. La herramienta constituye un buen soporte al profesor cuando éste tiene grupos numerosos que impiden un adecuado seguimiento de las prácticas. Al mismo tiempo, permiten que el alumno pueda desarrollar su trabajo con cierta independencia, obteniendo de la herramienta una respuesta rápida sobre los posibles fallos que pueda cometer, así como una valoración sobre el nivel del cumplimiento de objetivos. Esto suele redundar positivamente en la motivación del alumno, tanto por la “tutorización virtual” recibida, como por la inmediatez de la misma.

Como trabajo futuro tenemos varias líneas de mejora abiertas.

• Por un lado, planteamos la integración de JCap con Moodle [8] (herramienta de Campus Virtual utilizada en la Universidad de Málaga), de forma que la ejecución de una prueba se pueda establecer como tarea de Moodle, y la valoración generada por la herramienta se incorpore al expediente del alumno en el Campus.

Durante el curso pasado, al no estar disponible JCap en el Campus Virtual de la Universidad de Málaga, lo que hicimos fue colocar JCap y las pruebas en el Campus de forma que los alumnos pudieran instalárselo en sus propias máquinas y así ejecutarlos sin problemas. Todas las prácticas entregadas eran a su vez evaluadas por los profesores de la asignatura utilizando la aplicación del profesor.

Aunque muy cómoda para los alumnos, esta forma de utilizarla tenía varios inconvenientes para el profesor, como bajarse todos los ejercicios y recopilar los comentarios y las calificaciones de los ficheros generados conteniendo los informes facilitados por JCap. La integración en Moodle debe permitir que al subir la práctica esta sea evaluada automáticamente, mostrando al alumno los comentarios y valoración de su ejercicio y almacenando en Moodle la valoración y los comentarios, facilitando así la manipulación de los resultados por parte del profesor.

• En la actualidad no podemos realizar pruebas de aplicaciones con interfaz gráfica de usuario. Aunque hemos empezado a explorar esta posibilidad y ya hemos hecho las primeras pruebas, aún queda bastante trabajo para conseguirlo. Nuestra intención en estos momentos es continuar con nuestra misma filosofía, e intentar integrar herramientas como Abbot [11] o UISpec4J [10] dentro de JCap.

• Existen herramientas muy sofisticadas, como JLint [6] o PMD [2,9] que detectan errores en los programas utilizando técnicas de análisis estático. Creemos muy interesante añadir alguna de estas herramientas, que son capaces de detectar posibles errores, como bloques try/catch/finally/switch vacíos, código muerto (métodos privados, parámetros o variables locales no utilizadas), sentencias if vacías, expresiones demasiado complicadas, código subóptimo (uso inadecuado de String/StringBuilder), clases con complejidad ciclomática demasiado alta, código duplicado, etc.

• Por último, consideramos que las mismas técnicas utilizadas para el caso de Java son perfectamente aplicables a otros lenguajes. En particular, consideramos que adaptar nuestra herramienta a, p. ej., C++, para el que hay disponibles herramientas similares a las utilizadas por JCap, sería una contribución interesante.

Nos gustaría agradecer a la E.T.S.I Informática el esfuerzo que está haciendo para la correcta

11

implantación del EEES en el centro y las facilidades que nos ha proporcionado para la realización de esta experiencia. Nos gustaría también agradecer la colaboración de los compañeros que han colaborado con nosotros en la asignatura LTO: María del Mar Gallardo, Rosa Guerequeta, Juan Miguel Molina y Antonio Vallecillo.

4. Bibliografía

[1] Cédric Beust y Alexandru Popescu. TestNG. http://testng.org . [2] Tom Copeland. PMD Applied. Centennial Books, November 2005. [3] Paul Hamill. Unit Test Frameworks. O’Really. 2004. [4] Andy Hunt y Dave Thomas. Pragmatic Unit Testing. 2003. [5] JUnit. http://www.junit.org. [6] Konstantin Knizhnik y Cyrille Artho, Jlint. http://jlint.sourceforge.net. [7] Guido Malpohl. JPlag. https://www.ipd.uni-karlsruhe.de/jplag [8] Moodle: Course Management System. http://www.moodle.org [9] PMD. http://pmd.sourceforge.net/ [10] UISpec4J, http://www.uispec4j.org [11] Timothy Wall, Abbot, http://abbot.sourceforge.net

12