Reflexiones y experiencias sobre la ense

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 dineroNo
  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
• El tristemente famoso problema del cambio de
  paradigma.
• 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
ResultadosControl 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
ResultadosEvaluació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
ResultadosExamen 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
ResultadosEvaluació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
ResultadosExamen 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
ResultadosCalificaciones finales en la
convocatoria ordinaria de febrero

• Los resultados de la primera convocatoria de la
  nueva asignatura no fueron especialmente
  satisfactorios.

71
17
ResultadosExamen 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
ResultadosEvaluació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
ResultadosExamen 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
ResultadosCalificaciones 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
ResultadosSituació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
Reflexiones y experiencias sobre la enseñanza de
POO como único paradigma

• Alguna pregunta?