Reflexiones y experiencias sobre la enseñanza de POO como único paradigma D. Gayo Avello, A. Cernuda del Río, J.M. Cueva Lovelle, M. Díaz Fondón, A. García.

Presentación del tema: "Reflexiones y experiencias sobre la enseñanza de POO como único paradigma D. Gayo Avello, A. Cernuda del Río, J.M. Cueva Lovelle, M. Díaz Fondón, A. García."— Transcripción de la presentación:

1 Reflexiones y experiencias sobre la enseñanza de POO como único paradigma D. Gayo Avello, A. Cernuda del Río, J.M. Cueva Lovelle, M. Díaz Fondón, A. García Fuente y J.M. Redondo López Universidad de Oviedo

2 Introducción La introducción de POO en titulaciones universitarias en informática no es un debate nuevo (ni “tranquilo”). Dos posturas: –Primero programación estructurada, luego POO. –La OO puede introducirse desde el “primer día”. Ambas presentan inconvenientes… Sin embargo, hay que elegir una y asumir sus inconvenientes… Este trabajo pretende: –Explicar por qué hemos optado por un enfoque “temprano” de enseñanza de POO. –Describir cómo lo estamos haciendo. –Exponer unos resultados provisionales. –Extraer unas mínimas conclusiones de esta experiencia. 5%

3 En primer lugar… ¿Es útil la OO? La OO es considerada por los profesionales del desarrollo del software como el mejor paradigma disponible. Sin embargo: –La OO no puede resolver todos los problemas de la programación. –Es un paradigma aún en evolución. –Los lenguajes disponibles no son los mejores lenguajes OO posibles. –La programación sigue siendo una tarea difícil. Aún así… “La Orientación a Objetos es como el dinero: No lo es todo, pero es mucho mejor que las otras opciones.” (G.L. Steele – Sun Microsystems) 10%

4 Si es útil… ¡Los alumnos la necesitan! Aun cuando la OO (lenguajes, metodologías y herramientas) no son óptimos son la mejor herramienta disponible. El mercado demanda profesionales de la OO. Por tanto, la universidad debe incluir OO en los planes de estudio. Computing Curricula 2001 (ACM/IEEE): –POO, AOO y DOO deben formar parte de cualquier plan de estudios en informática. –Son posibles varios enfoques de enseñanza. Por ejemplo: Primero imperativo. Primero objetos. 14%

5 ¿Por qué objetos desde el primer día? El debate actual se centra en esa pregunta  Sin embargo, está incompleta, debiendo formularse: ¿Por qué objetos desde el primer día sabiendo que OO es una competencia fundamental para un titulado en informática? La primera pregunta (incompleta) puede suscitar polémica… La segunda no debiera. Si se acepta la utilidad de OO y la necesidad de su dominio por parte de los titulados creemos que es imprescindible comenzar su enseñanza lo antes posible. 19%

6 Inconvenientes de cada enfoque Primero objetos: –Sobrecarga de conceptos teóricos o sobresimplificación (extremos “viciosos”). –Utilización abusiva de bibliotecas de clases. –Desarrollo de ejercicios con interfaces gráficos o empleo de entornos artificiosos. Objetos más tarde: “cambio de paradigma”. –El tristemente famoso problema del “cambio de paradigma”. ¡La OO no es una extensión del paradigma procedimental! –A pesar de las apariencias… ¡La OO no es una extensión del paradigma procedimental! Los problemas del primer enfoque, aunque habituales, son evitables. 24%

7 Nuestro “mantra” “Si el objetivo es que nuestros alumnos dominen la OO debemos comenzar con OO.” 29%

8 “Plan nuevo, enfoque nuevo” Aprovechando la entrada del plan renovado en la EUITIO se construye una asignatura de introducción a la programación basada en el enfoque “primero objetos”. Objetivo primordial de “Introducción a la Programación”: Proporcionar a los alumnos conocimientos y estrategias básicas para: –Enfrentarse a problemas reales (sencillos) susceptibles de una solución informática, –determinar las clases que modelarían dicha solución, –describir de manera precisa tal modelo, –e implementar ese modelo mediante un lenguaje OO. 33%

9 Parámetros para la nueva asignatura Seguir las propuestas “objetos primero” de ACM/IEEE. Lograr que el alumno aprenda POO y no las peculiaridades del lenguaje de programación elegido. Ordenar los contenidos teóricos para facilitar su comprensión y el desarrollo de ejercicios prácticos desde el primer momento. Minimizar el impacto de la herramienta de desarrollo en la realización de los ejercicios. Presentar a los alumnos técnicas básicas de AOO y DOO así como los elementos mínimos de la notación UML. Evitar los problemas habituales en este tipo de iniciativas: –utilización de entornos artificiosos, –énfasis en el desarrollo de aplicaciones gráficas, –abuso de bibliotecas de clases. 38%

10 “IP” a grandes rasgos… Primer cuatrimestre de primer curso. 3 créditos de teoría, 1 crédito de tablero, 2 créditos de laboratorio. Contenidos teóricos: –Antecedentes. –Introducción a la POO. –Estado de los objetos. –Comportamiento de los objetos. –Estructuras de control. –Clasificación de objetos. –Estructuras de datos fundamentales. Lenguaje de programación: Java. Evaluación: –Teoría (40%) mediante examen final escrito. –Práctica (60%) mediante dos ejercicios prácticos voluntarios o examen final práctico (evitable con la entrega de los ejercicios). 436 alumnos matriculados. 43%

11 Resultados Control teórico Tras seis semanas de clase se llevó a cabo un control teórico voluntario que abarcó los tres primeros bloques del temario: –Antecedentes. –Introducción a la POO. –Estado de los objetos. 48%

12 Resultados Evaluación de la primera práctica La parte práctica tiene un peso del 60% en la calificación final. El alumno puede superar la parte práctica mediante un examen práctico o presentando dos ejercicios prácticos a lo largo del cuatrimestre. El objetivo del primer ejercicio es consolidar dos conceptos básicos de la POO como son estado y comportamiento. Para ello el alumno debe completar y ampliar una clase (proporcionada por los profesores) que implementa una sencilla mascota virtual (el alumno no tiene control sobre el aspecto visual de la mascota, sólo sobre el comportamiento de la misma). 52%

13 Resultados Examen escrito de la convocatoria ordinaria de febrero El examen escrito constó de una prueba objetiva y de tres ejercicios de dificultad creciente que no sólo precisaban de conocimientos de POO y Java sino la utilización de técnicas básicas de AOO y DOO y un dominio mínimo de la notación UML. Cada una de las pruebas requería una puntuación mínima para la calificación del examen. 57%

14 Resultados Evaluación de la segunda práctica en la convocatoria ordinaria de febrero Aunque la segunda práctica fue entregada por los alumnos poco antes del examen escrito sólo fue defendida por aquellos que superaron dicho examen. En esta práctica el alumno debía desarrollar una aplicación completa con varias clases. Podía optar por implementar su propio modelo de clases o bien ampliar uno de los distintos modelos propuestos por los profesores. 62%

15 Resultados Examen práctico de la convocatoria ordinaria de febrero Al examen práctico sólo se presentaron aquellos alumnos que superaron el examen escrito pero no pasaron la defensa de alguno de los ejercicios prácticos. 67%

16 Resultados Calificaciones finales en la convocatoria ordinaria de febrero Los resultados de la primera convocatoria de la nueva asignatura no fueron especialmente satisfactorios. 71%

17 Resultados Examen escrito de la convocatoria ordinaria de junio El examen escrito de la convocatoria de junio tuvo una estructura idéntica y dificultad análoga a la del primer examen escrito. En esta ocasión el número de presentados fue sensiblemente inferior al del primer examen y los resultados del mismo ligeramente mejores. 76%

18 Resultados Evaluación de la segunda práctica en la convocatoria ordinaria de junio Aquellos alumnos que aprobaron el examen escrito en junio y habían superado la defensa de la primera práctica en febrero pudieron defender la segunda práctica que habían entregado originalmente. 81%

19 Resultados Examen práctico de la convocatoria ordinaria de junio El examen práctico de junio tuvo como único enunciado un diagrama de clases UML aunque la dificultad era similar a la del examen práctico de febrero. A este examen sólo podían presentarse alumnos que hubiesen superado la teoría en febrero o en junio y no hubiesen superado la defensa de las prácticas ni el examen práctico de febrero. 86%

20 Resultados Calificaciones finales de la evaluación en la convocatoria ordinaria de junio Los resultados de la segunda convocatoria han sido algo más alentadores. 90%

21 Resultados Situación actual en la asignatura En estos momentos 1/3 de los alumnos matriculados en la nueva asignatura han conseguido aprobarla. Parece razonable esperar que un 45% de los matriculados superen finalmente la asignatura en su primer año (entre las convocatorias de febrero, junio y septiembre). Ese 45% se correspondería aproximadamente al 70% de los alumnos que asistieron habitualmente a clase. 95%

22 Algunas conclusiones A falta aún de la convocatoria de septiembre, creemos que los resultados (aunque mejorables) son esperanzadores. A la vista de las prácticas desarrolladas y los resultados obtenidos en las mismas parece que la POO no resulta más difícil que la programación “clásica”. El grado de satisfacción del alumnado con el enfoque, el lenguaje elegido y la herramienta de desarrollo es elevado. ¿Factores motivadores? –El alumno aprende un lenguaje que sabe se emplea en la industria. –El alumno utiliza una versión reducida de una herramienta profesional. –¿OO más sencilla/intuitiva que programación estructurada? ¡No! Pero es más potente para enfrentarse a problemas reales. El alumno percibe esa potencia en el paradigma, lo que le anima a su aprendizaje. 100%

23 ¿Alguna pregunta? Reflexiones y experiencias sobre la enseñanza de POO como único paradigma