VIII Jornadas de Enseñanza Universitaria de la Informática Cáceres ...

los niveles de aprendizaje para cada núcleo teóricode la planificación. Por ejemplo, para la docenciade las estructuras de control de ejecución:• Conocimiento: sintaxis y semántica de lasestructuras• Comprensión: dados unos pequeños bloquesde código, extraer el control de flujo deejecución y sus efectos sobre el entorno(variables, periféricos, etc.)• Aplicación: escribir las estructuras quesatisfacen unos requisitos específicos• Análisis: dados unos bloques de código,extraer su organización para comprender losrequisitos que satisfacen• Síntesis: dada una aplicación incompleta,dotarla de la funcionalidad deseada• Evaluación: contrastar soluciones alternativas,con estructuras y sin estructuras –por ejemplocon sentencia goto- y, por otro lado, presentarsoluciones “inadecuadas” con 100 líneas decódigo de estructuras anidadas, evidenciandolas bondades y carencias de las estructuras decontrol de flujo de ejecución en términos delos conceptos recurrentes: complejidad,ordenación en el espacio, evolución, nivelesde abstracción, etc.Para la consecución de los objetivosconsideramos vitales los dos últimos niveles.• Síntesis: el alumno incorpora código enaplicaciones motivadoras, con interfacesgráficos de usuario, bibliotecas, sistemas decomunicaciones, etc. Todo ello, resaltando laaplicabilidad del material aprendido en el“mundo real”, pero, evitando la exposición ymanejo de conceptos avanzados• Evaluación: permite al alumno reconocer, encada núcleo, el hilo conductor en nuevasconcreciones de los conceptos recurrentes yjustifica, visualizando las limitaciones, lanecesidad de evolucionar a nuevosconstructores del lenguaje.4.3. HerramientasLas herramientas necesarias para laconcreción del enfoque diacrónico responden,paralelamente, a los niveles cognitivos de Bloom:• Intérpretes para la visualización del softwareque apoyen los niveles de conocimiento ycomprensión: enlace estático de tipos aexpresiones, orden de evaluación deoperadores en las expresiones; orden deejecución de las estructuras; comunicación porel paso de parámetros; desencadenamiento deinstancias y mensajes en objetos; etc.• Depuradores para el nivel de aplicación.• Herramientas CASE e ingeniería inversa paraextraer la organización de software en el nivelde análisis: diagramas de jerarquías deestructuras, subprogramas, módulos, clases…adecuados al núcleo que se está impartiendo.• Entornos de desarrollo con bibliotecas,compilador,… y herramientas que bloqueen laedición del código de una aplicación exceptoen los ámbitos a codificar, para la fase desíntesis: codificar el cuerpo de unsubprograma, la implantación de un módulo oun TAD, etc.• Métricas del software para el nivel deevaluación que exhiban la complejidad yconsumo de memoria; acoplamiento ycohesión de módulos, TAD’s o clases; etc. delas soluciones implementadas.Todas estas herramientas deben configurarsecon un lenguaje evolutivo que incorpore e inhibareglas sintáctico-semánticas, adecuándose a lasecuencia de núcleos expuestos en laplanificación.5. ConclusionesCon la incorporación de la OO en los planes deestudio han surgido inconvenientes, tanto en suasimilación por parte de los alumnos, como en lalocalización de recursos adecuados por parte delprofesor (disponibilidad de textos, ejemplos queencajen en una sesión docente, incluso eleccióndel lenguaje).El enfoque, procedimental en primero y OOen segundo, evidenció el problema del"desplazamiento de paradigma". Posteriormente,el enfoque contrapuesto, OO en primero, trajo lasobrecarga inicial de conceptos para los alumnosy, en algunos casos, la inadecuación de loslenguajes a los paradigmas.Hacemos una propuesta docente, no orientadaa paradigmas, que elimina los inconvenientes delas anteriores, utilizando un enfoque diacrónico,que consiste en la exposición justificada de cadaconstructor de los lenguajes de programación, através de su evolución histórica, motivada por los