Sobre las tareas y controles Lenguajes de Programación Reglas del juego Mauricio Araya [email protected] Roberto Bonvallet [email protected] Jorge Valencia [email protected] Jorge Avarias [email protected] Norman Saez [email protected] Tomás Staig [email protected] Martes 20 de marzo Primer semestre de 2007 1. Introducción Dada la relevancia de las tareas y controles en el ramo de Lenguajes de Programación, es necesario explicar una metodologı́a de trabajo y corrección clara para evitar problemas posteriores. El objetivo de este documento es contar con una piedra angular donde se describan las reglas del juego y de esta forma realizar un trabajo armónico entre evaluadores y evaluados. 2. Sobre las evaluaciones El conjunto de evaluaciones que integran las tareas y controles será considerado en la evaluación final con una poderación del 35 %. Este conjunto está determinado por 5 tareas obligatorias y 2 controles obligatorios con la misma ponderación cada ı́tem. En resumen: Nt = Tarea 1 + Tarea 2 + Tarea 3 + Tarea 4 + Tarea 5 + Control 1 + Control 2 7 En el caso de que el estudiante no cuente con todas las evaluaciones necesarias (tanto de forma justificada como no), es responsabilidad del estudiante (y 1 sólo del estudiante) acercarse a los ayudantes o al profesor a aclarar el problema. En caso contrario, aquella evaluacion será considerada con nota 0. Cualquier intento o efecto de fraude o copia, será automáticamente evaluado con nota 0. 2.1. Sobre los controles Se considerará 2 controles de lectura de carácter individual para cubrir algunos temas de difı́cil evaluación práctica mediante tareas. Estos controles serán realizados en los últimos 30 minutos de las catedras del ramo. Las fechas de los controles serán informados oportunamente por los canales oficiales. Existirá un control y un certamen recuperativo, pero estas instancias son sólo para estudiantes que falten a alguna evaluación. No se podrá asistir al recuperativo para borrar, ponderar o cambiar alguna nota de las evaluaciones anteriores. 2.2. sobre las tareas Se considerará 5 tareas prácticas de programación (una por cada paradigma de programación), las cuales deberan cumplir las siguientes restricciones: 2.2.1. Entrega Las tareas son de caracter individual, es decir en grupos de a lo más una sola persona. Las tareas tienen una fecha lı́mite de entrega, la que será especificada con cada tarea. En el caso de que el curso solicite aplazamiento y éste sea concedido, las fechas de publicación y entrega de la siguiente tarea no serán modificada bajo ninguna circunstancia. El formato de entrega es rol-tareaX.tar.gz1 siendo rol el número único designado por la Universidad, y X el número de tarea que se está entregando. Por ejemplo, la primera tarea del ayudante Jorge Avarias [email protected] serı́a 2273020-7-tarea1.tar.gz. La información que debe contener se especifica en cada tarea, dentro de un directorio llamado tareaX (en nuestro ejemplo, tarea1). Si no se sigue este formato, se penalizará con un descuento en la nota final de la tarea. El método de entrega es mediante el uso de la plataforma de e-learning del Departamento de Informática: .LRN http://dotlrn.inf.utfsm.cl. Cada tarea debe ser depositada en la carpeta correspondiente a la tarea, por ejemplo: La tarea 1 debe ser depositada en la carpeta denominada Tarea1, y asi con las demás. Si por cualquier motivo la tarea no se encontrase en su lugar correspondiente, ella no será corregida. 1 Lea el manual en linea de tar(1) 2 El atraso de entrega de tareas será penalizado con 20 puntos por dı́a, incluyendo sábados y domingos, hasta llegar a una nota 0 la cual no será recompensable, cambiable o eliminable. En caso de que no entregar una tarea, esto deberá indicarse explı́citamente a los ayudantes dentro del plazo de entrega. La entrega de multiples versiones de la misma tarea no esta permitido. Si el estudiante desea hacer algun cambio debe realizarlo sobre la copia ya entregada y no agregar una nueva copia a la carpeta de tareas. De omitir esto, el afectado se arriesga a un descuento de por lo menos 20 puntos y a la corrección de la ultima versión de la tarea entregada. 2.2.2. Contenido Los tarballs de entrega (archivos rol-tareaX.tar.gz) deben contener el código fuente completo, un archivo Makefile2 , un archivo README y cualquier otro archivo necesario para la compilación y ejecución de la tarea. El archivo Makefile debe generar mediante make(1) los binarios o ejecutables especificados en cada tarea. Estos binarios/ejecutables deben tener exactamente los mismos nombres especificados en cada tarea. En el caso de lenguajes interpretados, el Makefile debe preparar la tarea para su limpia ejecución. El archivo README deberá contener toda la información del autor y programa, ademas de los supuestos necesarios. Se deberá describir la estrategia utilizada para solucionar el problema. Se indicará precisamente los formatos de entrada y salida de cada una de las tareas, y se dará entradas y salidas de ejemplo. Programas que no respeten estos formatos serán automáticamente consideradas incorrectas. 2.2.3. Corrección El Laboratorio destinado para trabajar en estas tareas es el Laboratorio de Computación del Departamento de Informática3 , por lo que las herramientas de corrección, ejecución y compilación a utilizar serán las provistas por este laboratorio. Es responsabilidad de cada uno verificar que la tarea compile y se ejecute correctamente en este ambiente. En caso de no ocurrir ası́, la tarea se considerará incorrecta automáticamente. El formato de interacción de las tareas intentará ser el más sencillo posible, y se describirá en cada tarea. En consecuencia, utilizarán archivos 2 Lea el manual en lı́nea de make(1) en el piso 0 del edificio F 3 Ubicado 3 (generalmente entrada y salida estándares, o archivos con nombres predefinidos). Tareas con menúes interactivos o interfaces gráficas automáticamente serán consideradas incorrectas por no respetar el formato. Existirán dos métodos de evaluación de una tarea determinada, que se elegirán para cada uno en forma “aleatoria”: 1. El programa se compilará y ejecutará con un conjunto de casos de prueba, aplicándose la pauta de corrección general indicada más adelante. 2. Mediante una interrogación oral en el computador, en la cual el estudiante deberá explicar cómo desarrolló el programa que entregó, y su comprensión de los conceptos involucrados. En cada caso, el plazo para apelar será de una semana después de entregar las notas. 3. Pauta de corrección de tareas La pauta de evaluación de tareas consta de los siguientes conceptos: Compilación y ejecución (30 %) • Compila y ejecuta sin warnings (5 %) Compila (con -Wall en el caso de C) sin ningún tipo de aviso o se ejecuta sin lanzar errores • Correctitud (25 %) El programa funciona correctamente con los casos de prueba provistos en la tarea y con casos de prueba que el estudiante desconoce. No se probarán datos no válidos, por lo que no es necesario el chequeo de los valores de entrada. Evaluación del código4 (70 %) • Organización (20 %) El código es modular, manejable, lógico y ordenado. Las funciones, tipos, estructuras, condiciones, etc. estan coherentemente definidas. • Indentación (5 %) El código esta indentado en forma consistente. Se recomienda revisar el comando indent(1), en particular el estilo Kernighan y Ritchie. • Comentarios (5 %) El código está debidamente comentado, es decir, se explican aquellas secciones que pueden ser un tanto confusas, claro que código confuso en sı́ descontará puntos. Si el comentario y el código no coinciden se 4 Se recomienda visitar http://www.doc.ic.ac.uk/lab/secondyear/cstyle/cstyle.html, y el archivo Documentation/CodingStyle del núcleo de Linux 4 considerará que ambos están malos. Deberı́a ir un comentario corto explicando cada función, dar el nombre de cada archivo y su objetivo, etc. La forma de comentar es consistente (encabezados similares para cada archivo, descripciones de cada función, etc.). Nótese que comentarios excesivos o inútiles llevarán a descontar puntos por este concepto. • Nombres de variables y funciones (10 %) El espacio de nombres, y en particular de variables, estructuras, y funciones, son descriptivos y coherentes con el contexto/dominio del problema. • Uso del lenguaje (25 %) Se utiliza correctamente las sentencias, operadores, bibliotecas, parámetros, constantes, macros, etc. del lenguaje. • Archivo README (5 %) Se evaluará en conjunto con el codigo, la breve (no más de 20 lı́neas) reseña incluı́da en el archivo README (texto plano) sobre la estrategia utilizada para resolver el problema, poniendo especial énfasis en la congruencia de su estrategia con el código de fuente entregado. MA/JA/LATEX 5