correctores automáticos de programas: implantación realista en...

Correctores Automáticos de Programas: Implantación Realista en la Docencia Universitaria

Luis Llana Díaz, Enrique Martín Martín, Cristóbal Pareja Flores

Depto. De Sistemas Informáticos y Computación Universidad Complutense de Madrid

{llana, cpareja}@sip.ucm.es, [email protected]

Resumen. El enfoque primero-las-pruebas (test first) se ha defendido repetidamente, para la enseñanza de la programación y la ingeniería del software, así como para el desarrollo profesional del software. Por otro lado, los correctores automáticos de programas han consolidado su uso, tanto en concursos de programación como en la enseñanza cotidiana. En este capítulo tratamos sobre el uso de correctores en la práctica usual de la programación. Analizamos las ventajas e inconvenientes de adoptar este enfoque, desde el punto de vista técnico y didáctico, así como los logros alcanzados y el camino que aún queda por recorrer en ambos sentidos.

Palabras clave: programación, enseñanza de la programación, corrección automática de programas, pruebas de caja negra, colecciones de problemas.

1 Introducción

Abogamos por la utilización de correctores automáticos en la enseñanza cotidiana de la programación. Estas herramientas nos ofrecen múltiples beneficios [5]: agilizan el proceso de corrección; proporcionan retroalimentación inmediata a los estudiantes, facilitando que progresen a su propio ritmo; efectúan una calificación; más objetiva y homogénea; permiten un acceso permanente al laboratorio, sin limitaciones de tiempo y espacio; facilitan la enseñanza a distancia y fomentan el autoaprendizaje; son adecuadas para grupos grandes [9] o para situaciones en que se necesita una revisión frecuente [6], y fomentan el enfoque de desarrollo dirigido por los casos de prueba.

Nuestra propuesta se basa en los siguientes elementos: la presencia de las pruebas en la enseñanza y práctica de la programación, y el desarrollo de prácticas con ayuda de correctores automáticos en el laboratorio. Para que el enfoque propuesto tenga éxito, creemos que es necesario hacer algunas consideraciones pedagógicas y otras de tipo práctico igualmente importantes. Introducimos seguidamente los aspectos planteados uno a uno.

2 Actas de SITIAE 2008

1.1 Programación Orientada a las Pruebas

El enfoque del diseño dirigido por los casos de prueba (test-driven design, TDD) [3, 22] se basa en el uso de casos de prueba como un modo informal pero preciso de especificar el comportamiento que se espera de un programa. Consecuentemente, el diseño de un programa según el enfoque TDD empieza escribiendo un conjunto apropiado de tests para la nueva pieza de código, antes de diseñar la propia pieza. Obsérvese que, en este contexto, el principal papel de los tests es la especificación, quedando la función de validación relegada a un segundo plano.

En los últimos años, este enfoque se ha consolidado en el mundo académico [17] y en el profesional [3, 22]. En el primero, el diseño de casos de prueba ayuda al programador en formación a comprender y modelar mejor la tarea que un programa debe desempeñar, a prevenir todas las situaciones posibles que dicho programa podría encontrar, y a mejorar, en resumen, su rendimiento como futuro programador. En el mundo profesional, y por dar un simple ejemplo, la metodología eXtreme Programming (XP) para el desarrollo del software proclama la práctica del enfoque TDD como uno de sus principios básicos, aduciendo que exige al programador el considerar de manera fehaciente las necesidades que ha de atender el programa, por estar los requisitos firmemente ligados a las pruebas.

Por otra parte, con el uso de los correctores automáticos no se persigue que los alumnos diseñen los casos de prueba, ya que la inmensa mayoría de los correctores en uso actualmente requieren que los tests estén elaborados previamente, junto a los enunciados propuestos, de forma que la preparación de dichos tests corresponde al mismo profesor que ha propuesto cada problema. Pero la lectura de dichos datos por el estudiante lo habitúa a pensar en dichos tests como parte del enunciado, y por tanto antes que en el programa, propiciando una actitud positiva hacia el enfoque TDD.

1.2 Correctores Automáticos

Básicamente, un corrector examina un programa, que es una solución presunta para un problema planteado, y lo evalúa bajo diversos criterios (v. Fig. 1).

Fig. 1. Funcionamiento básico de un corrector automático.

Correctores automáticos de programas 3

El sistema corrector compila el programa y lo ejecuta, para ponerlo a prueba con unos pocos juegos de datos, esta vez ocultos, comparando el resultado del programa con el previsto. Actualmente, estas herramientas se usan tanto en concursos de programación, donde son esenciales, como cada vez más en la enseñanza cotidiana.

1.3 Aspectos Pedagógicos

El tercer ingrediente que debemos tener en cuenta es la preparación de los problemas en sí. La corrección automática impone una disposición fija del problema. En efecto, los problemas de concursos de este tipo tienen el siguiente formato invariablemente: enunciado; descripción de la entrada y la salida; un ejemplar de entrada y salida correspondiente (v. Fig. 2). El vector de pruebas ejemplo permite a los concursantes o alumnos comprobar el funcionamiento de su programa antes de entregarlo.

Fig. 2. Esquema típico de un enunciado preparado para que la solución sea evaluada por un corrector automático.

Puede quizás objetarse que el formato de los problemas es, al menos aparentemente, muy restringido. Sin embargo, esta disposición supone una ventaja más que una restricción, y encaja con el fomento del enfoque de desarrollo de programas orientado por las pruebas, como veremos.

Un asunto clave en evaluación es la naturaleza de los ejercicios propuestos a los alumnos [6]. Esta tarea tiene un coste nada despreciable por distintos motivos. En


primer lugar la evaluación tiene una doble función, meramente evaluadora y formativa, y los problemas planteados han de atender a ese doble objetivo. En segundo lugar, es deseable que la colección de problemas sea completa, en el sentido de cubrir las distintas etapas, niveles de dificultad y técnicas que se consideran necesarias en el aprendizaje de la programación. Por último, cada ejercicio ha de estar preparado sólidamente, en el sentido de proporcionar todo el material necesario para su resolución, de un modo coherente: enunciado, casos de prueba, cotas de tiempo y espacio, etc. La mera experiencia e intuición puede ser insuficiente para elaborar una colección de calidad, que contemple las observaciones anteriores.

Una herramienta conceptual de gran utilidad en este sentido es la taxonomía de Bloom [4], que atiende por separado tres dominios: afectivo, psicomotor y cognitivo. En el aprendizaje de la programación, éste último es el más importante, y consiste básicamente en una jerarquía de objetivos de aprendizaje por niveles. Aunque otros autores han hecho revisiones de esta taxonomía [2], podemos considerarla como un marco de trabajo ampliamente aceptado, útil para valorar el nivel alcanzado por los estudiantes y para diseñar una secuencia de contenidos o actividades, o incluso un plan de estudios completo. En este capítulo adoptamos la propuesta de diseño de actividades efectuada en [8], y describimos su puesta en práctica, con un conjunto de colecciones adecuado para un primer curso de programación, equivalente a CS1 y CS2.

1.4 Otras Consideraciones de Tipo Práctico

Además de las consideraciones de diseño esbozadas en la introducción, existen otras, de tipo más pragmático. Entre ellas, debemos destacar el (ingente) esfuerzo real necesario para preparar cada ejercicio, una colección (equivalente a una “hoja de problemas”) o un conjunto de colecciones coherente y completo con respeto a un conjunto de objetivos planteado, como es por ejemplo, una asignatura de programación concreta. Otra tarea que se ha de considerar es la planificación y puesta en práctica en un grupo.

2 Verificación y Comprobación mediante Pruebas

El objetivo de la evaluación es valorar la calidad de un programa, ya sea con fines formativos (produciendo la retroalimentación) o acumulativos en la nota de los estudiantes. El objetivo de la enseñanza de la programación podría enunciarse, resumidamente, así: “Capacitar a los alumnos para construir metódicamente programas correctos, fáciles de mantener y reutilizar y eficientes”.


La facilitad de mantenimiento y reutilización son aspectos estáticos del software, cuya revisión requiere una inspección del código fuente, ya sea manual o mediante un analizador sintáctico al menos. En el apartado siguiente examinaremos algunos de estos aspectos, analizados por distintos correctores automáticos; pero la revisión de los mismos no puede llevarse a cabo fácilmente mediante pruebas y, en todo caso, su implementación práctica depende en gran medida del lenguaje de programación empleado.

Debido a estas complicaciones fundamentalmente, los correctores que evalúan todos estos aspectos se hayan limitado al uso por parte de sus creadores o poco más, salvo contadas excepciones.

2.1 Verificación Formal

La corrección es el aspecto principal. La verificación es una técnica importante y de gran difusión en el mundo académico para garantizar la corrección de un programa con respecto a su especificación. La garantía viene dada por una demostración matemática, cuyo desarrollo es, en ocasiones, al menos tan difícil como el del programa en sí, y tan propensa a errores como lo es un programa [5].

Pongamos un ejemplo para resaltar un aspecto más de las dificultades de la verificación. Planteamos el diseño de un programa que numere el primer cuadrante del plano discreto como indica la Fig. 3, esto es rellenando diagonales.

Fig. 3. Una numeración del primer cuadrante del plano discreto.

Este problema se puede plantear en los inicios de la programación, ya que su resolución únicamente requiere el manejo de asignaciones y expresiones sencillas. Verificarlo formalmente exige dar una especificación del problema: num (0 , 0) = 0 num (i+1, 0) = num (i, 0) + i + 1 num (i , j) = num (i+1, j-1) + 1


Vemos que especificar formalmente un problema no está exento de dificultades, con frecuencia mayores que los conceptos de programación requeridos en el programa solución, como es la recursividad en el ejemplo presentado. Estas dificultades se añaden a las de efectuar la demostración formal de la corrección, asunto ya comentado, y tan propenso a errores como puede serlo el desarrollo del programa mismo, lo que sugiere inquietantemente la necesidad de validar la propia verificación…

2.2 Comprobación mediante Casos de Prueba

Nos queda la validación de un programa mediante casos pruebas. Un primer enfoque es el de las pruebas de caja blanca (clear box): los casos de prueba diseñados han de cubrir todo el código fuente, mostrando que cada fragmento es útil y funciona adecuadamente para alguna situación. Este enfoque requiere el código fuente, tarea que resulta costosa de forma automática. Las pruebas de caja negra (black box) comprueban la corrección funcional, esto es, que el programa propuesto funciona adecuadamente, es decir, que produce los resultados esperados para cada posible juego de datos previsto en el enunciado. Esto exige preparar casos de prueba que cubran cada caso posible, incluyendo las situaciones típicas y atípicas, poniendo en juego valores singulares (por ejemplo, el 0 y 1 como índices de un vector), no definidos (fuera de rango: negativos o demasiado grandes), fuera de los límites de precisión, etc.

Pongamos un ejemplo simple para valorar el trabajo de generar un conjunto completo de pruebas de caja negra: el problema es resolver ecuaciones de la forma a x2 + b x + c = 0 con coeficientes reales. Un intento de programa, consistente en la mera aplicación de la fórmula conocida para una ecuación de segundo grado, queda desmontado al considerar la casuística posible de un modo exhaustivo:

Ecuaciones 0 0 0 Infinitas soluciones de grado 0 0 1 Sin solución menor que 2 0 2 -1 Una solución Ecuaciones 1 2 0 Dos soluciones reales de 1 2 1 Una solución doble segundo grado 1 1 1 Dos soluciones imaginarias

Iniciamos así una solución más completa. Pero las pruebas de caja blanca pueden, por ejemplo, poner al descubierto comprobaciones (discriminante positivo, por ejemplo) no usadas por ser comprobaciones ya efectuadas en ese punto, siendo así redundantes.

La necesidad de elaborar pruebas de calidad no es una propuesta nueva sino que tiene ya tres décadas. La medida TER1 (Test Effectiveness Ratio 1) por ejemplo


data ya de los años ochenta [21]: se trata de la medida más estándar de evaluación de la calidad de las pruebas, que examina básicamente si un conjunto de tests obliga al programa a usar todos sus fragmentos de código, al menos una vez; recíprocamente, para un juego de datos completo, un buen programa ha de emplear todo su código; de lo contrario, tiene código superfluo.

2.3 Evaluación del Coste

Otro aspecto de la calidad de los programas, además de la corrección, es la eficiencia. Nuevamente, el cálculo analítico de la complejidad de un programa, tanto en tiempo como en espacio, requiere examinar el código fuente. En cambio, en la prueba con tests nos limitamos a cronometrar el tiempo y a medir el espacio de memoria empleado por cada ejecución de un programa, mediante simples llamadas al sistema operativo. De nuevo, es necesario buscar juegos de datos minuciosamente para que atiendan a toda la casuística posible, atendiendo ahora al rendimiento del programa.

2.4 Conclusión

Tanto la verificación formal como la generación de casos de prueba adecuados son tareas minuciosas que requieren su tiempo, aunque este trabajo corre por cuenta del profesor en el caso de los correctores automáticos. Precisamente éste es el un pago que debemos estar dispuestos a pagar por seguir este enfoque: la carga de tiempo necesario para la preparación de prácticas con sus correspondientes casos de prueba, para un corrector automático concreto.

3 Aspectos de un Programa Evaluables Automáticamente

El papel de un corrector automático es examinar distintos aspectos de un programa, averiguar si están bien o mal desarrollados e informar de ello. Algunos de los aspectos revisables automáticamente son estáticos, en el sentido de que el programa no necesita entrar en funcionamiento; otros son dinámicos, esto es, su revisión requiere ejecutar el programa. Revisaremos ambos seguidamente.

3.1 Aspectos Estáticos Revisables Automáticamente

En este apartado pasamos de puntillas por los aspectos de los programas que se pueden revisar automáticamente. Los artículos [1, 6] son estudios más completos y bastante recientes: ambos se publicaron en 2005. Los criterios de evaluación


recogidos en dichos trabajos están actualmente en plena vigencia y, aunque los ejemplos de jueces que proponemos nosotros (apartado 3.4) son posteriores, desde el punto de vista tecnológico no aportan prestaciones realmente novedosas. Los aspectos estáticos se examinan atendiendo al código fuente del programa. Son los siguientes:

− Un primer grupo de aspectos son los recogidos informalmente bajo el nombre de estilo; tienen que ver con los hábitos en la organización del código (número y tamaño de módulos y subprogramas, número de parámetros, ámbito de las declaraciones, etc.) y la documentación y no siempre se reflejan en el funcionamiento, sino que contribuyen en general a que un programa sea mantenible. Su valoración es establecida por el profesor de un modo laxo.

− La complejidad del programa no está relacionada con el coste, sino que examina la estructura sintáctica del programa (reparto en módulos, organización de estructuras y su anidamiento, complejidad del árbol asociado a las expresiones, etc.) y genera un árbol cuya estructura nos interesa. Por ejemplo, un problema podría resolverse con un par de bucles anidados o con uno solo, dando lugar a una complejidad menor. La métrica más conocida es el número ciclomático de McCabe [14]. Una de las aplicaciones de la complejidad es la comparación de programas buscando coincidencias excesivas, de cara a determinar si ha habido fraude o no, probablemente. La principal dificultad para evaluar algunos de estos aspectos es que su

implementación depende del lenguaje, y requieren diseñar procesadores de lenguaje específicos para cada lenguaje y cada una de las tareas. Otra limitación importante es la falta de generalidad, porque algunos de los aspectos no son correctos o incorrectos en términos absolutos, o bien no existe unanimidad en su revisión, como ocurre con muchos de los aspectos de estilo relacionados con la disposición del código, sino que frecuentemente dependen de pautas o recomendaciones más bien flexibles. El trabajo para describir el criterio propio de cada profesor, así como la forma de evaluarlos, es bastante subjetivo y por tanto difícilmente reutilizable.

3.2 Aspectos Dinámicos Revisables Automáticamente

Los aspectos dinámicos atienden al funcionamiento del programa, por lo que se requiere que el entorno de ejecución proporcione unas condiciones mínimas de seguridad para que el programa no produzca, al ejecutarse, efectos perniciosos sobre el sistema de prueba: un banco de pruebas controladas como el descrito se llama sandbox. Otro aspecto es la ejecución multihebra de los programas, especialmente importante cuando el tiempo de envío y calificación juega un papel


importante. Finalmente, un programa que no para (i.e., funciona un tiempo superior a una cota establecida) o que reclama un espacio de memoria excesivo, se debe detener por razones de seguridad, y también por ser inaceptable como solución del problema planteado.

La funcionalidad básica se ha explicado ya: ejecución del programa con un juego “completo” de datos preparado y su comparación con el resultado previsto por los jueces. Por poner un ejemplo concreto, en Mooshak [11] estas comprobaciones generan un mensaje de la siguiente lista:

Evaluating Requires reevaluation Program Size Exceeded Invalid submission Compile Time Error Runtime Error Time Limit Exceeded Memory Limit Exceeded Output Limit Exceeded Wrong Answer Presentation Error Accepted

Fig. 4. Gama de veredictos que puede emitir el juez Mooshak.

Algunos sistemas pasan distintas baterías de datos, con un grado de generalidad incremental, y cada una de ellas ofrece una información distinta. En otros, se examinan también los juegos de datos preparados por el usuario, y comprueban si las baterías de datos supuestamente preparadas por los estudiantes son exhaustivas (pruebas adecuadas, de caja blanca). La mayoría admiten que los resultados pueden diferir en ciertos aspectos (blancos, marcas de fin de línea, etc.), emitiendo un mensaje como “Presentation Error”. Otros, únicamente piden fragmentos de programa: una declaración, instrucción o módulo, completando el resto.

Una conclusión de tipo práctico importante es la necesidad de que el profesor aporte una solución operativa o varias, en los lenguajes de programación permitidos, con dos finalidades distintas. Por un lado, asegurarse de que la descripción aportada en el enunciado tiene todas sus piezas (enunciado en sí, descripción y ejemplos de los juegos de datos y resultados) en perfecto estado, incluso habiendo ejecutado dicho programa para generar las salidas ocultas a partir de sus entradas, etc. Por otro lado, la estimación del tiempo y espacio empleados es difícil sin una ejecución práctica.

Por último, también se ha de tener en cuenta que el coste depende del lenguaje de programación empleado. Java y Haskell, por poner un par de ejemplos, exhiben un coste mucho mayor que C/C++ o Pascal.


3.3 Tareas Administrativas

Además de la revisión técnica propiamente dicha, la mayor parte de los sistemas correctores desempeñan algunas tareas administrativas por nosotros: facilita el envío, incluso remotamente, 24 horas al día. Técnicamente, la mayoría permiten el mantenimiento de la base de datos de los alumnos y grupos y por supuesto de las colecciones de ejercicios (enunciados en varios formatos, casos de prueba y posiblemente soluciones). Estas facilidades necesitan obviamente el trabajo natural: se ha de alimentar el sistema con dicha información (como ocurre con WebCT o Moodle); y de nuevo surge un inconveniente: la poca estandarización, por lo que esta información no puede exportarse ni importarse sencillamente desde otras plataformas o aplicaciones.

3.4 Revisión de Algunos Sistemas como Ejemplo

Actualmente, hay cientos de sistemas automáticos de corrección de programas, por lo que no podemos pretender ser exhaustivos, ni es ése nuestro objetivo en este capítulo. Como decíamos, el lector interesado puede consultar los estudios [1] y [6], sobre los principales sistemas hasta 2005. En este apartado nos centramos únicamente en un par de herramientas que están actualmente en uso y que nos permiten ejemplificar algunas de las características más interesantes entre las mencionadas.

Veamos algunos ejemplos de estas prestaciones en algunos sistemas concretos recientes. En la Fig. 5 pueden verse algunas prestaciones de Mooshak [11] de tipo técnico y algunas administrativas. Se trata de un sistema de libre distribución que admite distintos tipos de usuarios: como administrador, juez, concursante y público. Con respecto a los usuarios, es cerrado, en el sentido de que su uso está restringido a quienes el administrador autorice explícitamente. La figura recoge una pantalla abierta por un concursante, que está previamente registrado con su historial correspondiente. Ésta es su ventana de trabajo principal: le informa de los problemas planteados (A, B); puede consultar los enunciados (view), plantear preguntas a los jueces (ask), consultar las preguntas planteadas por cualquiera de los demás miembros, añadir una solución nueva (submit) en cualquiera de los lenguajes admitidos o examinar el ranking actual. Este sistema también nos da una estadística general de respuestas, con información sobre los problemas y soluciones por equipos. Finalmente, el administrador puede incluir lenguajes nuevos, gestionar la lista de usuarios y equipos, crear concursos, etc.


Fig. 5. Interfaz gráfico de Mooshak. Instantánea vista por un alumno.

En la Universidad de Valladolid se halla actualmente el mayor repositorio de problemas de concurso que hay desarrollado [19], y tiene habilitado un juez, el “Online Judge”. Este juez es abierto, en el sentido de que los usuarios no necesitan la intervención del administrador para registrarse y usar el laboratorio. El repositorio consta de más de 2000 problemas, y ha revisado más de 6 millones de envíos de problemas, de más de 70000 usuarios, y albergado 196 concursos. Este laboratorio ofrece información adicional, sobre la actividad de cada usuario (número de envíos exitoso o fallidos, etc.) o del conjunto de ellos como puede ser el uso estadístico de lenguajes de programación a lo largo del tiempo. Los repositorios disponibles en la Universidad de Wisconsin-Parkside [18] y en la de Pekín [16] son similares. Los tres están dedicados a problemas de concurso de programación de alto nivel. Los problemas son accesibles, pero sólo el juez disponible de ellos es el de Pekín, para Windows.

En la URL http://sqlzoo.net se encuentra otro servidor con un juez abierto (v. Fig. 6), con una colección de problemas (e información teórica) pero únicamente sobre SQL. En éste, las posibles respuestas del juez con las siguientes: error de sintaxis (información sobre la posición aproximada), respuesta errónea (número de filas y columnas + contenido), respuesta correcta. Su principal cualidad es quizá su sencillez; no hace falta registrarse ni identificarse siquiera para practicar.


Fig. 6. Ventana del corrector de SQL disponible en http://sqlzoo.net.

4 Consideraciones Pedagógicas y de Tipo Práctico

Una vez perfilada la estructura de los ejercicios y el resto de la información que se ha de proporcionar (casos de prueba, una solución ejecutable), nos disponemos a crear una colección de ejercicios, digamos, para una asignatura concreta habitual. En nuestro caso, la asignatura es Introducción a la Programación, un curso completo de primero de cualquier Ingeniería de Informática, Ciencias Matemáticas o Estadística. Surge entonces la necesidad de cubrir los distintos temas de dicha asignatura, de regular la dificultad de los ejercicios, yendo de lo fácil a lo difícil y procurando satisfacer las necesidades de los distintos perfiles de alumnos que esperamos encontrar en cualquier curso. La colección de ejercicios ha de responder a criterios didácticos, en resumen.

4.1 Consideraciones Pedagógicas

La taxonomía de Bloom [4] es una sistematización genérica de objetivos de aprendizaje, que establece una medida del grado de aprendizaje. Dicho grado se mide de manera distinta en los tres dominios siguientes: el cognitivo, referido al entrenamiento mental, esto es, al conocimiento y a las habilidades mentales; el psicomotor se refiere a las habilidades físicas y al desarrollo psicomotor; y el afectivo, que se centra en el mundo de las emociones.


El dominio cognitivo (v. Fig. 7) es el que más nos importa en la enseñanza de la programación. Dentro de él, la taxonomía establece seis niveles, con un grado de complejidad ascendente:

Conocimiento: Nombrar o recordar términos o definiciones.

Comprensión: Entender el significado de dichos términos o conceptos, así como de expresiones nuevas.

Aplicación de técnicas (un teorema) a situaciones concretas nuevas.

Análisis: Identificar y examinar elementos componentes en un modelo.

Síntesis: Unir estructuras menores para lograr una estructura de mayor complejidad.

Evaluación: Emitir juicios sobre la adecuación de técnicas a situaciones concretas.

Fig. 7. Categorías en el dominio cognitivo de la taxonomía de Bloom, según la versión original y una versión revisada.

Inicialmente se aceptó que los niveles superiores cubren y asumen los inferiores,

aunque hay versiones de la taxonomía (por ejemplo, la de Anderson [2], que muestra la Fig. 7 a la derecha) en que los tres superiores son independientes entre sí. Existen estudios sobre la aplicación de esta taxonomía a distintos campos, con distintos fines:

− Ayudar a diseñar un plan de estudios, de forma que cada nivel esté realmente cubierto antes de exigirse los niveles superiores

− Evaluar el grado de complejidad de una asignatura En el mundo de la informática, también existen estudios sobre las distintas

actividades formativas, referidas a los distintos niveles. Reflexionar sobre la existencia de los niveles permite a los profesores pensar si hay aspectos del


aprendizaje poco cubiertos o saltos bruscos en los requisitos que exigimos a los alumnos. Por ejemplo, la inmensa mayoría de las actividades planteadas, tanto en el período de formación universitaria como durante el ejercicio de la profesión de Informática, se sitúa en el nivel de aplicación [7, 10]. Esta observación puede llevarnos a reflexionar sobre la necesidad de cubrir los niveles inferiores, especialmente en los primeros cursos.

Algunos de los niveles de la tabla no pueden plantearse fácilmente en el contexto de los correctores automáticos, siendo ciertamente actividades que juegan un papel importante en programación. Por ejemplo, aunque la evaluación y calificación de un ejercicio de programación recae especialmente en un programa diseñado, lo cierto es que podría atender a muchos factores, e incluso es razonable que la evaluación global sea positiva incluso fallando algunas funcionalidades básicas como la compilación.

Sin embargo, es también posible plantear actividades “de programación”, referidas a los distintos niveles de esta taxonomía, y con el requisito obligatorio de que se ha de producir un programa ejecutable, para que pueda beneficiarse de la corrección automática.

En [8] se caracterizan las actividades de programación en los niveles de comprensión, aplicación, análisis y síntesis, dentro de la taxonomía de Bloom. En dicho trabajo se concreta cada nivel de la taxonomía particularizado para el ámbito específico de la programación. Ahora, resumimos los tipos de actividades propuestas para los niveles mencionados.

Comprensión: Una de las clases de programas más simples pide que se efectúe un cálculo mediante una fórmula conocida, esto es, escribir un programa ejecutable a partir de una descripción algorítmica, como es el seudocódigo, un diagrama de flujo o incluso mediante el propio lenguaje natural. Una segunda clase de ejercicios ofrece en el enunciado una pequeña gama de fragmentos de código para que el alumno elija el que encaja en un hueco de un programa incompleto, o para que reordene dichos fragmentos en un programa completo que ha de desempeñar una tarea conocida.

Aplicación: Aplicar una formula o método conocido en una situación nueva. Los estudiantes tienen un modelo de programa (Pitágoras por ejemplo), y su tarea es producir otros, para distintos fines (el área de un círculo, paso de Fahrenheit a Celsius, resolución de una ecuación de segundo grado, etc.)

Análisis: A medida que aumenta la complejidad de los problemas, lo hace igualmente la necesidad de un proceso de refinamiento progresivo, descomponiendo un problema en tareas más simples, descritas como una subestructura del programa o como un subprograma, módulo o método. Esta actividad se complementa con la siguiente tarea, ya que una mera descomposición no conduce a un programa si las partes no se ensamblan adecuadamente. Esta idea es específicamente apoyada por la taxonomía revisada [2].


Síntesis: Diseñar un programa para un problema nuevo. La dificultad es mayor que en los niveles anteriores: no se trata únicamente de escribir una formula o refinar un programa con muchas componentes, sino en la naturaleza sutil del propio problema, y se necesita mayor dominio y experiencia para lograr una solución aceptable.

Evaluación: Valorar la corrección de un programa, evaluar su eficiencia o la adecuación de las técnicas de diseño (algoritmos y estructuras de datos) empleadas.

El nivel de conocimiento es difícil de cubrir por excesivamente elemental: el

estudiante sólo debe recordar piezas simples de información, y la pregunta ha de ser bastante literal, siendo la dificultad únicamente memorística. Esta limitación ha dejado este nivel fuera de juego en programación, porque las actividades planteadas son demasiado simples para tener interés. No obstante, en los primeros pasos en esta materia se ha de poner en juego también la memoria: escribir un programa elemental en un lenguaje concreto pasa por recordar las librerías que se han de incluir, el protocolo básico de cabeceras, identificadores e instrucciones mínimas usadas. Una actividad posible en este nivel es escribir de nuevo un programa ya estudiado.

4.2 Estado Actual de la Colección en Curso

Ahora describimos cómo se concretan todas las consideraciones anteriores en una colección de problemas concreta, para la asignatura mencionada de Introducción a la Programación.

Entre las herramientas disponibles hemos instalado Mooshak en el servidor http://problem-g.estad.ucm.es, aunque la colección se está desarrollando por bloques, que no se introducirán a dicho servidor hasta tenerlos en su estado final o hasta que se escoja una pequeña colección de problemas para ser planteados en una práctica de laboratorio. La colección se divide en cinco bloques de veinticinco o veintiséis problemas cada uno, asumiendo una secuencia de contenidos que sucesivamente presenta los siguientes temas:

Expresiones: Problemas que se ciñen al uso de instrucciones básicas (lectura, escritura y asignación), expresiones con los tipos de datos básicos (enteros, reales, caracteres y lógicos) más cadenas de caracteres, usadas de un modo elemental.

Instrucciones estructuradas: En la resolución de estos problemas se pueden usar instrucciones de selección (condicional y por casos) e iterativas (bucles for, while y repeat o do-while).

Subprogramas: Muchos de los problemas de este bloque pueden resolverse con los mecanismos del anterior, pero el tamaño de los problemas propuestos aquí


aumenta, así como su complejidad, de forma que la descomposición en subprogramas es ahora más necesaria.

Tipos de datos definidos: Vectores, matrices y registros principalmente.

Ordenación y búsqueda sobre vectores. En cada bloque hay cinco niveles de dificultad, cada uno con unos cinco

problemas: la categoría más sencilla es de problemas triviales, cuya resolución sólo requiera un simple de los mecanismos del lenguaje propios de dicho tema; la categoría superior entraña una gran dificultad algorítmica o requiere el empleo de los recursos técnicos disponibles de un modo sutil. En ocasiones, la dificultad de un problema desaparecería si se permitiera usar más mecanismos que los puestos en juego en dicho tema, por lo que la recomendación de ceñirse a dichos mecanismos es importante. Deseablemente, todos los alumnos de una asignatura deberían poder resolver los problemas de la primera categoría, y sólo los alumnos más brillantes (los de sobresaliente o matrícula de honor) deberían poder resolver los últimos. La finalidad de esta graduación es permitir a la normal diversidad de alumnos presentes en un grupo plantearse retos a su medida y según su ritmo de progreso particular. Para concretar, relacionamos los títulos de los problemas de la primera colección (expresiones) en el apéndice.

A su vez, preparar cada problema conlleva generar el siguiente material: un archivo html y otro LaTeX con su enunciado, estructurado como se ha descrito; un directorio (tests) con varios subdirectorios, uno por cada par de archivos de entrada y salida; la solución en, al menos, uno de los lenguajes permitidos. Además, algunos ejercicios proporcionan un applet de Java, un fragmento de Javascript con una demostración del funcionamiento esperado (ej.: DNI), una animación (Recorridos de árboles) o alguna otra pieza de información complementaria.

A estas alturas, puede estarse intuyendo que la preparación de una colección con todos este material requiere una ingente cantidad de trabajo. Así es en efecto, y eso sin contar con la coordinación de los distintos autores comprometidos en dicho trabajo, la homogeneización del mismo, etc. La contrapartida es el rendimiento que esperamos sacar de dicha colección, utilizándola para varias asignaturas durante los años venideros y compartiéndola con otros compañeros que deseen unirse al proyecto.

5 Discusión

En este capítulo describimos nuestra experiencia en la implantación del enfoque de desarrollo de programas dirigido por las pruebas, junto con herramientas de corrección automática con que hacerlo viable desde el punto de vista práctico. La utilización de tales herramientas en el laboratorio y la adopción del enfoque mismo


no son nuevas en absoluto. Nuestra aportación es el punto de vista docente en el desarrollo de los materiales tratando de cubrir todas las etapas de una asignatura completa de Introducción a la Programación y todos los niveles de dificultad que establece la taxonomía de Bloom.

Nuestro trabajo pretende serle útil a cualquier otro equipo docente que desee utilizar nuestros problemas; por eso hemos tenido un interés especial en que las herramientas subyacentes o al menos las colecciones de problemas estén disponibles libremente.

También podemos declarar que hemos hecho dos pruebas preliminares en el laboratorio, una preliminar entre compañeros y otra con un grupo de alumnos real. Ambas se han desarrollado usando Mooshak. La primera consistió en un ensayo para prever flecos y posibles imprevistos en la segunda. En esta última se planteó una colección de cinco problemas, con dificultades entre 1 y 3, agrupando a los alumnos en equipos de tres. La práctica se desarrolló inicialmente durante una hora, presencialmente en el laboratorio, con el objetivo de que donde los alumnos se familiarizaran con el acceso y manejo de la herramienta y pudieran desarrollar al menos un problema especialmente elegido para ello. Posteriormente, se permitió que los alumnos siguieran desarrollando los demás fuera del horario y del laboratorio, obteniéndose una media de 13 entregas por equipo, o sea, 2’6 intentos por problema. Creemos honestamente que los resultados son altamente positivos desde el punto de vista de los alumnos.

Desde el punto de vista del profesor en cambio, se ha de resaltar el gran esfuerzo necesario para la preparación del material con la calidad debida, y para el desarrollo de cada práctica en sí, por lo que conviene preparar en equipo este material, y por lo que creemos que este trabajo merece la pena si dicho material se reutiliza suficientemente.

Entre nuestros objetivos más inmediatos están los siguientes: terminar la colección y ampliarla a asignaturas típicas de segundo (estructuras de datos) y de tercero (diseño de algoritmos); difundir la colección para que se beneficien e ella otros equipos; efectuar experimentos estadísticos que nos permitan sacar formalmente conclusiones sobre los posibles beneficios de este enfoque, desde el punto de vista del aprendizaje, o detectar las posibles mejoras necesarias; implantar su uso, de forma regular, durante el curso 2008-2009, al menos en las asignaturas de Introducción de Programación de distintas carreras de nuestra universidad. Una línea por explorar es la posible validez de un corrector como herramienta de control de calidad del aprendizaje, empleando distintas técnicas.

Por último, un objetivo a medio plazo es el diseño y desarrollo de un juez abierto, disponible libremente, que albergue esta colección de problemas, la mantenga y permita su crecimiento de forma regular. Pero ésta es otra historia. Agradecimientos. Este trabajo ha sido financiado por el proyecto WEST/FAST TIN2006-15578-C02-01, financiado por el Ministerio de Educación y Ciencia


español, y por el Proyecto de Innovación Educativa PCD08 33, financiado por la Universidad Complutense de Madrid.

Referencias

1. K.M. Ala-Mutka, “A survey of automated assessment approaches for programming assignments”, Computer Science Education, 15(2), June 2005, pp. 83

2. L. W. Anderson and David A. Krathwohl. A Taxonomy for Learning, Teaching, and Assessing: A Revision of Bloom’s Taxonomy of Educational Objectives. Addison-Wesley, 2001.

3. K. Beck, “Aim, fire (test-first coding)”. IEEE Software, num. 18 vol. 5, sept.-oct. 2001, pp. 87-89.

4. B. Bloom, E. Furst, W. Hill, and D.R. Krathwohl: Taxonomy of Educational Objectives: Handbook I, The Cognitive Domain, Addison-Wesley, 1956.

5. C. Daly, and J. Waldron, “Introductory Programming, Problem Solving and Computer Assisted Assessment”, Proceedings of the 6th CAA Conference, Loughborough, 2002.

6. C. Douce, D. Livingstone, and J. Orwell, “Automatic Test-Based Assessment of Programming: A Review”, ACM Journal of Educational Resources in Computing, vol. 5, no. 3, 2005.

7. U. Fuller, C.G. Johnson, T. Ahoniemi, D. Cukierman, I. Hernán Losada, J. Jackova, E. Lahtien, T.L. Lewis, D. McGee Thompson, C. Riedesel, E. Thompson, “Developing a Computer Science-specific Learning Taxonomy”. ACM SIGCSE Bulletin 34(4), pp 152, 170, ACM Press, New York, 2007

8. I. Hernán-Losada, C. Pareja-Flores, J.Á. Velázquez-Iturbide, “Testing-Based Automatic Grading: A Proposal from Bloom’s Taxonomy”. Artículo aceptado en The 8th IEEE International Conference on Advanced Learning Technologies, 2008.

9. Hunt, F., Moch, J., Nevison, C., Rodger, S., and Zelenski, J., How to develop and grade an exam for 20,000 students (or maybe just 200 or 20). En SIGCSE Technical Symposium on Computer Science Education, ACM Press, pp. 285-286, 2002.

10. C. G. Johnson y U. Fuller, Is Bloom Appropriate for Computer Science? En Anders Berglund and Mattias Wiggberg, editors, Proceedings of the Sixth Baltic Sea Conference on Computing Education Research, volume 2007-006 of Uppsala University Department of Information Technology Technical Reports, pag.s 120-123. Uppsala University, febrero de 2007.

11. J. P. Leal y F. Silva, “Mooshak: a Web-Based multi-site programming contest system”, Software Practice and Experience 33, pp 567-581, marzo 2003.

12. R. Lister, and J. Leaney, “First Year Programming: Let All the Flowers Bloom”, in T Greening & R. Lister (Eds.), Computing Education 2003 Fifth Australasian Computing Education Conference, pp. 221-230, 2003.

13. R. Lister et al, “A multi-national study of reading and tracing skills in novice programmers”, Working Group Reports from ITiCSE on Innovation and Technology in Computer Science Education, ACM Press, New York, NY, USA, 2004.

14. T. A. McCabe, “A complexity measure”, IEEE Transactions on Software Engineering, vol. SE-2, núm. 4, págs. 308-320, 1976.


15. M. McCracken, V. Almstrum, D. Diaz, M. Guzdial, D. Hagan, Y. Kolikant, G. Laxer, L. Thomas, I. Utting, and T. Wilusz, “A multi-national, multi-institutional study of assessment of programming skills of first-year CS students”, ACM SIGCSE Bulletin, 33(4), ACM Press 2001 pp. 125 – 180.

16. Peking University Judge Online for ICPC, http://acm.pku.edu.cn/JudgeOnline/ 17. T. Shepard, M. Lamb and D. Kelly, “More testing should be taught.” Communications

of the ACM 44(6): 103-108, June 2001. 18. USA Computing Olympiad Training Program Gateway, disponible en la dirección

siguiente: http://ace.delos.com/usacogate 19. ACM Online Judge Site, http://acm.uva.es/ 21. M. R. Woodward, D. Hedley y M. A. Hennell, “Experience with path analysis and

testing of programs”, IEEE Transactions on Software Engineering, vol. SE-6, núm. 3, págs. 278-286, 1980.

22. Extreme Programming, http://www.extremeprogramming.org. Última visita, en febrero de 2006.

Apéndice: Un Fragmento de la Colección de Problemas

Nuestra colección se centra actualmente en los dos primeros cursos de programación. Para el primero estamos preparando cinco bloques:

− Expresiones sencillas: operaciones con los tipos de datos básicos

− Estructuras de control: selección condicional y por casos, instrucciones iterativas

− Subprogramas: funciones, procedimientos, recursividad

− Tipos de datos definidos por el programador

− Ordenación y búsqueda

Cada uno de estos bloques tiene problemas con cinco niveles de dificultad, desde el 1, que sólo exige conocer los mecanismos nuevos del lenguaje de dicho bloque, hasta el 5, considerado como el de máxima dificultad algorítmica.

Nos centramos ahora en el bloque de problemas sobre expresiones. En su resolución sólo se permite usar los tipos de datos e instrucciones básicas (enteros, reales, caracteres, lógicos y cadenas de caracteres, asignación, lectura y escritura); no se permite usar bucles, instrucciones de selección, subprogramas, tipos de datos definidos por el programador, como vectores. Con estas limitaciones, el orden de dificultad de dichos problemas es creciente, yendo aproximadamente desde nivel trivial (los cinco primeros) hasta un nivel avanzado (los cinco últimos).

Damos una breve descripción en vez de un título, que sería menos descriptivo posiblemente: 1. Sumar, dando el programa resuelto. 2. Hola Edmundo, similar al típico “Hola Mundo”. 3. Paso de letras a mayúscula. 4. Conversión de temperaturas


Celsius a Fahrenheit. 5. Cambio de monedas. 7. Doble o mitad, dando el programa casi completo. 8. Fibonacci, aplicando una fórmula. 9. Término genérico de una matriz. 10. Numerar el primer cuadrante del plano. 11. Clasificar un ángulo. 12. Números triangulares. 13. Máximo de dos enteros. 14. Un juego de magia, con un cálculo matemático simple. 15. La letra del DNI. 16. Un cuadrado perfecto. 17. Movimiento del caballo en el ajedrez. 18. El beso exacto: fórmula de Soddy. 19. Numeración de las fichas de dominó. 20. Números caracolitos: otra numeración del plano discreto. 21. Barajadura perfecta: una permutación de índices, usada en la FFT. 22. Inorden, preorden: subárboles. Descomposición de dos cadenas de caracteres. 23. Cálculo de un intervalo musical a partir de las frecuencias. 24. N-goros: de la posición de un elemento de una matriz a su valor. 25. Volteretas: de la posición de un elemento de una matriz a su valor. 26. Coordenadas triangulares: otra numeración del plano discreto. 27. Averiguar si una cierta terna de puntos del plano discreto es un triángulo rectángulo.

correctores automáticos de programas: implantación realista en...

Documents