El enunciado del examen está acá: http://www.di-mare.com/adolfo/cursos/2004-1/p2-ea-1.htm Este examen de 4 preguntas toma prestadas 3 preguntas de exámenes anteriores. Parece que la buena costumbre que existía entre los alumnos de resolver exámenes viejos ya se ha perdido; a mí me gustaría que eso cambiara y se volviera a adoptar prácticas académicas saludables. 1) La tendencia generalizada para redactar la especificación es explicar cómo funciona el procedimiento, cuando lo correcto es decir qué hace: - BUENO ==> QUÉ hace - Malo ==> Cómo lo hace. http://www.di-mare.com/adolfo/binder/#c03.htm#k1-especificacion No entiendo de dónde sale esa idea generalizada de explicar cómo funciona una rutina, en lugar de decir simplemente qué es lo que hace. También algunas personas sustituyeron la especificación por un algoritmo escrito en pseudo-código... que es algo que nunca les he pedido que hagan, ni en clase ni en las tareas programadas. También les he dado muchos ejemplos de especificaciones, como es el caso de los métodos Copy() y Move() que discutimos en Clases: http://www.di-mare.com/adolfo/binder/c04.htm#sc05 http://www.di-mare.com/adolfo/binder/c04.htm#sc07 Yo bien sé que es difícil redactar en español técnico una especificación que sea "Completa", "Correcta" y "No ambigua", por lo que he tratado de no ser extricto en cuanto al lenguaje. Sin embargo, algunos de ustedes comenten errores de redacción tan grandes que resulta imposible entender qué escribieron. Por eso, es muy importante que lean de nuevo, por lo menos 5 veces, lo que escriben. Otro error desconcertante y muy común es no incluir el prototipo o firma de la rutina en la especificación. Algunos decidieron hablar en la especificación de los "nodos" de la lista. Por supuesto, esto es incorrecto, pues la existencia de los nodos concierne únicamente a la implementación de la lista, y no a su especificación. De hecho, es posible almacenar los valores de una lista sin usar nodos si se usa un vector. Por eso, es totalmente incorrecto mencionar a "nodos" o "punteros" en la especificación de cualquier método u objeto público de la lista. Para implementar la solución es necesario considerar varios casos diferentes. Es desalentador ver que muchas personas no pudieron identificarlos. Esa incapacidad de hecho muestra que son malos programadores. Si no mejoran sustancialmente, lo mejor será que no se graduén de bachilleres o licenciados, porque de hacerlo sería desprestigio para el buen nombre de la ECCI y de la UCR. Me extrañó también que muchas personas contestaron una pregunta de valor 0 (cero). Me imagino que lo hicieron por no leer el enunciado. Esto también es desastroso, porque si ni siquiera entienden qué se les pregunta, con menor razón podrán hilar una respuesta coherente y correcta. Para corregir la pregunta 1.c) implementé la lista circular, y luego usé el computador para ver el resultado de usar la implementación de cada uno de ustedes, usando como datos de prueba un a lista con 0,1,2 y 3 valores almacenados. *L._last->next,r *L._last->next->next,r *L._last->next->next->next,r *L._last,r 2) Aquí se repiten mucho los errores que cometieron en la pregunta 1), particularmente en lo que toca a especificaciones. Un error común fue que varias personas incluyeron la palabra "palíndromo" en su especificación sin definir ese concepto, presumiendo que quien lee automáticamenta "sabe" de qué se está hablando. Este es un error recurrente de los programadores, que muchas veces creen que quien lee inmediatamente tiene una visión de aquello en que el programador estaba pensando cuando escribió su especificación o documentación. Resulta para mí desalentador que varias personas no saben para qué se usa el archivo "Tdef.h". Más aún, cuando les toca hacer un diagrama muestran que no entienden lo que significa en C++ la directiva #include... y eso me hace preguntarme si realmente participaron eficazmente en la solución de las tareas programadas, pues cometen errores que delatan su ignorancia de las técnicas básicas de programación. Yo espero que todos ganen el curso, pero sí sentiría que yo he fallado si alguno pasa sin saber programar... Otro error se manifiesta en esa manía de incluir sentencias para desplegar valores en el medio de los métodos, como si emitir un mensaje como cout << "No está alineado el Palíndromo" << endl; tuviera alguna utilidad. Esas sentencias lo que hacen es romper con la especificación, pues en la descripción de las funciones de la rutina nunca está dicho que, de pronto, "despliega rótulos" que corresponden a la idea de condición de error que tiene el programador. Si un método o función dice en su especificación que "graba en la salida estándar... (algo)", no es incorrecto que en la implementación aparezcan montones de cout's. Sin embargo, si en la especificación no está incluida esa serie de salidas, cada vez que se generan el resultado será desconcertante, tanto para quien usa el programa (usuario final), como para el programador (programador cliente). Por eso, dejar montones de cout's regados por ahí es incorrecto e impropio. 3) Se nota que la mayor parte de las personas que contestaron esta pregunta no resolvieron la tarea programada #5. Peor aún, se nota que no tienen idea de cómo hace el compilador para producir el código objeto para un programa. También es extraño que nadie recordara qué es un error reportado por el editor de eslabonamiento (linker), como el que se obtiene cuando uno no incluye el archivo que contiene el procedimiento inicial main()... Algunos alumnos no contestaron la pregunta porque hablaron mucho de las etapas de compilación, omitiendo lo esencial que es que cada archivo de implementación .cpp produce un archivo objeto .obj, que el editor de eslabonamiento se encarga de juntar para obtener el archivo compilado final. 4) La mayor parte de los estudiantes escogieron NO contestar esta pregunta. Quienes lo hicieron, omitieron usar la clase ADH_map y el archivo Tdef.h para definir cuál es la llave del diccionario y cuál es el valor asociado a la llave. Además, no hicieron la implementación para extraer las palabras del flujo de texto de entrada, y tampoco identificaron el caso especial para la letra "CH".