medea: metodologÍas y herramientas para el … medea: metodologías y herramientas para el...

Departamento de Lenguajes y Ciencias de la Computación

Universidad de Málaga

Tesis Doctoral

MEDEA: METODOLOGÍAS Y HERRAMIENTAS PARA EL DESARROLLO DE ENTORNOS INTELIGENTES DE ENSEÑANZA

Y APRENDIZAJE

Presentada por: Dª. Mónica Trella López,

para optar al grado de Doctor por la Universidad de Málaga.

Dirigida por:

el Dr. D. Ricardo Conejo Muñoz, Profesor Titular de Universidad del Área de Lenguajes y Sistemas Informáticos.

Málaga, septiembre de 2006

Departamento de Lenguajes y Ciencias de la Computación

Universidad de Málaga

El Dr. D. Ricardo Conejo Muñoz, Profesor Titular de Universidad del Área de Lenguajes y Sistemas Informáticos de la E.T.S. de Ingeniería Informática de la Universidad de Málaga,

CERTIFICA

Que Dª. Mónica Trella López, Ingeniera en Informática, ha realizado en el Departamento de Lenguajes y Ciencias de la Computación de la Universidad de Málaga, bajo su dirección, el trabajo de investigación correspondiente a la tesis doctoral titulada:

MEDEA: MEtodologías y herramientas para el Desarrollo de entornos inteligentes de Enseñanza y Aprendizaje

Revisado el presente trabajo, estima que puede ser presentado al tribunal que ha de juzgarlo, y autoriza la presentación de esta tesis doctoral en la Universidad de Málaga.

Málaga, septiembre de 2006

Fdo.: Ricardo Conejo Muñoz Profesor Titular de Universidad del

Área de Lenguajes y Sistemas Informáticos.

A Antonio, a mis hijos Emilio y Antonio y a mis padres

AGRADECIMIENTOS

Sirvan estas líneas para dejar constancia pública de mi sincera gratitud a todas aquellas personas que de un modo u otro han contribuido generosa y desinteresadamente a que este trabajo vea la luz.

Al director de esta tesis, Ricardo Conejo, quisiera agradecerle su constante disponibilidad y la dedicación con la que a lo largo de todos estos años ha trabajado para que este proyecto saliera adelante con éxito. Sus conocimientos, ideas y opiniones han sido siempre de gran ayuda. Su voluntad de hacer las cosas lo mejor posible y su visión ingenieril de la informática han supuesto en numerosas ocasiones un incentivo para la búsqueda de nuevas soluciones.

A José Luis Pérez de la Cruz, por su actitud siempre solícita cada vez que he requerido su ayuda. Sus vastos conocimientos, su pragmatismo y sus oportunos y acertados consejos han sido muy útiles.

No quisiera dejar pasar la oportunidad de agradecerles a ambos que confiaran en mí hace ya algunos años abriéndome la primera puerta dentro de la Universidad así como su apoyo durante este tiempo. Muchas cosas buenas han sucedido en mi vida gracias a ese gesto.

A Eduardo Guzmán y Eva Millán por su amistad y su apoyo más allá de lo estrictamente académico. Ambos han puesto sin condiciones su tiempo a mi disposición cada vez que lo he necesitado y han compartido conmigo cada artículo, libro o información que ha llegado a sus manos y ha podido serme de utilidad. Sin el trabajo de Edu esta tesis no sería lo que es, su paciencia infinita arrancando, configurando, instalando...y su habilidad como programador han supuesto una ayuda muy importante. Gracias a Eva por sus útiles consejos a la hora de escribir artículos y por el cariño con el que ha corregido mis trabajos cada vez que se lo he pedido.

A David Bueno, le agradezco su trabajo, sus ideas y su colaboración en las muchas reuniones de proyecto que han contribuido a dar forma a esta tesis. A Gonzalo gracias por sus ánimos y su contagioso optimismo. Me gustaría mencionar al resto de mis compañeros del grupo de STI de IA2 Cristina, Lawrence, Mavi y a todas las personas que han trabajado directa o indirectamente en MEDEA a lo largo de su desarrollo: Alfredo, M. Carmen, Bea, Antonio y Sonia. Gracias a Francisco Triguero por el esfuerzo y apoyo dedicado al grupo de IA2.

Quisiera agradecer a Beatriz Barros la minuciosa revisión de esta memoria. Sus interesantes puntos de vista y sus sugerencias han contribuido a mejorar el resultado final.

Sin duda mi familia ha sido tan importante para llevar a buen término esta empresa como mis compañeros. A mis padres les debo lo que soy y las armas que tengo para andar por el mundo. Con su ejemplo me han enseñado como con trabajo, tesón, voluntad, honradez y respeto a uno mismo es posible alcanzar casi cualquier meta. Su apoyo moral ha sido decisivo para afrontar en ocasiones la tentación de tirar la toalla. Su inestimable ayuda ha permitido que haya podido dedicarle a este trabajo todas las horas que me ha demandado.

A mis hermanos Marta, Lourdes, Antonio y Eva, a sus familias y en especial a mi sobrina Lucía y su (futuro) hermanito Germán. A todos ellos que me alegran los días y me alivian las cargas. Todo lo que os debo no cabe en estas líneas.

Por último, pero muy especialmente quiero agradecer a Antonio, mi marido, su cariño, su comprensión, su buen humor y su optimismo. Gracias por compartir conmigo tus ingeniosas ideas. Algunas de ellas se reflejan en esta tesis. Mis niños, Emilio y Antonio, han sido mi fuente de energía, ellos me enseñan cada día cosas mucho más importantes que las que se aprenden entre libros.

La Real Academia Española define gratitud como el sentimiento que nos obliga a estimar el beneficio o favor que se nos ha hecho o ha querido hacer, y a corresponder a él de alguna manera. Me haría inmensamente feliz tener en esta vida la oportunidad de corresponderos a cada uno de vosotros como os merecéis.

INDICE

INDICE ...............................................................................................................1

CAPÍTULO 1 INTRODUCCIÓN................................................................................... 1

1.1 Motivación.......................................................................................... 2

1.2 Objetivos ............................................................................................. 4

1.3 Estructura de la memoria ................................................................. 6

CAPÍTULO 2 SISTEMAS TUTORES INTELIGENTES................................................... 8

2.1 De los Sistemas de Enseñanza Asistida por Ordenador a los Sistemas Tutores Inteligentes........................................................... 8

2.2 Arquitectura de un Sistema Tutor Inteligente............................. 10 2.2.1 Módulo experto o del dominio.............................................. 11 2.2.2 Módulo del alumno .............................................................. 14 2.2.3 Módulo instructor o pedagógico........................................... 18

2.2.3.1 Planificación de la instrucción................................................... 21 2.2.4 Módulo de comunicación o entono....................................... 26

2.3 Revisión de arquitecturas de Sistemas Tutores Inteligentes ..... 26 2.3.1 SCHOLAR........................................................................... 26 2.3.2 WHY .................................................................................... 28 2.3.3 SOPHIE ............................................................................... 29 2.3.4 WEST................................................................................... 31 2.3.5 WUSOR............................................................................... 33 2.3.6 GUIDON ............................................................................. 35 2.3.7 BUGGY................................................................................ 38 2.3.8 IDE....................................................................................... 38 2.3.9 IRIS ...................................................................................... 40 2.3.10 REEDEM ............................................................................. 43 2.3.11 RIDES .................................................................................. 45 2.3.12 EON ..................................................................................... 46 2.3.13 Resumen ............................................................................... 48

i

2.4 Conclusiones.....................................................................................52

CAPÍTULO 3 SISTEMAS EDUCATIVOS EN LA WEB .................................................54

3.1 Sistemas convencionales de enseñanza virtual ...........................55 3.1.1 WebCT ..................................................................................55 3.1.2 Blackboard.............................................................................56 3.1.3 Resumen ...............................................................................57

3.2 Los sistemas inteligentes en la web...............................................57 3.2.1 Arquitectura de los sistemas educativos inteligentes para la

web ........................................................................................57 3.2.2 CALAT .................................................................................60 3.2.3 DCG......................................................................................61 3.2.4 InterBook...............................................................................63 3.2.5 ELM-ART.............................................................................65 3.2.6 MetaLinks .............................................................................66 3.2.7 AHA .....................................................................................69 3.2.8 WEAR...................................................................................70 3.2.9 Resumen ...............................................................................71

3.3 Los sistemas inteligentes distribuidos en la web ........................73 3.3.1 QUIZ ....................................................................................74 3.3.2 Arquitectura de Girard, Gauthier y Levesque......................75 3.3.3 LANCA.................................................................................75 3.3.4 LeCS......................................................................................77 3.3.5 Baghera .................................................................................78 3.3.6 I-HELP .................................................................................78 3.3.7 Resumen ...............................................................................80

3.4 Integración de diversos sistemas inteligentes en la web............81 3.4.1 Arquitectura de Ritter y Koedinger......................................82 3.4.2 Integración de Interbook y PAT Online ...............................83 3.4.3 Intelligent Tutoring Applets (ITA) ......................................84 3.4.4 ActiveMath...........................................................................84 3.4.5 KnowledgeTree .....................................................................85 3.4.6 Resumen ...............................................................................86

3.5 Conclusiones.....................................................................................87

CAPÍTULO 4 TÉCNICAS PARA EL DESARROLLO DE SISTEMAS INTELIGENTES DISTRIBUIDOS EN LA WEB..................................................................91

4.1 Modelos y herramientas para el desarrollo de sistemas distribuidos abiertos ........................................................................92 4.1.1 Servicios web.........................................................................95 4.1.2 Sistemas Multi-Agentes .......................................................99

ii

4.2 Estándares para el desarrollo de aplicaciones educativas para la web................................................................................................... 100 4.2.1 Advanced Distributed Learning Initiative (ADL)............. 101

4.2.1.1 Shareable Courseware Object Reference Model (SCORM) . 102 4.2.2 Instructional Management System (IMS)......................... 105 4.2.3 IEEE Learning Technology Standars Commitee (IEEE

LTSC) ................................................................................. 108 4.2.3.1 Learning Object Metadata (LOM)........................................... 109 4.2.3.2 Learning Technology Systems Architecture (LTSA) ............ 110

4.3 Ontologías en los sistemas inteligentes para la web ................ 111 4.3.1 Lenguajes de especificación de ontologías .......................... 112

4.3.1.1 RDF y RDFS ............................................................................... 113 4.3.1.2 XOL ............................................................................................. 113 4.3.1.3 SHOE........................................................................................... 113 4.3.1.4 OIL............................................................................................... 114 4.3.1.5 DAML+OIL................................................................................ 114 4.3.1.6 OWL............................................................................................ 115 4.3.1.7 OXML.......................................................................................... 115 4.3.1.8 Comparativa .............................................................................. 117

4.4 Conclusiones .................................................................................. 119

CAPÍTULO 5 METODOLOGÍA DE DESARROLLO DE ENTORNOS DE APRENDIZAJE INTELIGENTES DISTRIBUIDOS Y ABIERTOS PARA LA WEB ............. 121

5.1 Introducción a la metodología y sus elementos........................ 123

5.2 Capa 0. El núcleo ........................................................................... 125 5.2.1 Modelo del dominio ............................................................ 126 5.2.2 Modelo del alumno ............................................................. 126 5.2.3 Planificador de instrucción ................................................ 127 5.2.4 Interfaz ............................................................................... 128

5.3 Capa 1. Recursos de instrucción.................................................. 128 5.3.1 El concepto de recurso de instrucción ................................ 129 5.3.2 Tipos de recursos de instrucción ........................................ 130 5.3.3 Registro de recursos de instrucción ................................... 131

5.3.3.1 Descripción funcional de un RI ............................................... 131 5.3.3.2 Descripción semántica de un RI .............................................. 132

5.3.4 Servicios de un recurso de instrucción............................... 135 5.3.5 Protocolo de actuación para el técnico............................... 135

5.4 Capa 2. Conocimiento de instrucción......................................... 136 5.4.1 Protocolo de actuación para el experto ............................... 137 5.4.2 Protocolo de actuación para el profesor ............................. 137

5.5 Capa 3. El aprendizaje................................................................... 139

5.6 Conclusiones .................................................................................. 142

iii

CAPÍTULO 6 MARCO DE TRABAJO PARA LA CONSTRUCCIÓN DE ENTORNOS DE APRENDIZAJE INTELIGENTES PARA LA WEB ...................................144

6.1 Capa 0. El núcleo. ...........................................................................145 6.1.1 Modelo del dominio.............................................................146

6.1.1.1 Atributos..................................................................................... 147 6.1.1.2 Relaciones ................................................................................... 147

6.1.2 Modelo del alumno .............................................................149 6.1.2.1 Modelo de conocimiento .......................................................... 150 6.1.2.2 Modelo de aptitudes ................................................................. 152 6.1.2.3 Historial de acciones ................................................................. 152 6.1.2.4 Actualización del modelo del alumno.................................... 153

6.1.3 Planificador de instrucción.................................................155 6.1.3.1 Algoritmo de planificación....................................................... 158

6.1.4 Interfaz................................................................................162

6.2 Capa 1. Integración de recursos de instrucción.........................162 6.2.1 Gestión de comunicaciones .................................................162 6.2.2 Creación de los RI: implementación de servicios ................164 6.2.3 Integración de los RI: descripción funcional ......................165 6.2.4 Algunos recursos de instrucción ........................................169

6.2.4.1 Mostrar Contenidos: SIGUE..................................................... 170 6.2.4.2 Test de auto-aprendizaje y Test de evaluación: SIETTE ...... 171 6.2.4.3 Evaluación de expresiones en C: WADEIn II ........................ 174

6.3 Conclusiones...................................................................................175

CAPÍTULO 7 CONSTRUCCIÓN DE ENTORNOS DE APRENDIZAJE INTELIGENTES PARA LA WEB POR USUARIOS NO ESPECIALIZADOS.......................179

7.1 Capa 2. Conocimiento de instrucción: construcción de un WILE............................................................................................................180 7.1.1 Creación del dominio ..........................................................180 7.1.2 Selección del dominio..........................................................181 7.1.3 Selección de los recursos de instrucción .............................181 7.1.4 Adaptación de cada tarea a los perfiles del alumno ............182 7.1.5 Aplicación de distintos estilos de enseñanza ......................184 7.1.6 Creación de nuevo material didáctico .................................186

7.1.6.1 Material didáctico del recurso SIGUE: páginas web ............ 186 7.1.6.2 Material didáctico del recurso SIETTE: tests ......................... 186

7.1.7 Actualización y mantenimiento del entorno de aprendizaje............................................................................................188

7.2 Entornos de aprendizaje inteligentes basados en MEDEA......189 7.2.1 Lógica..................................................................................189 7.2.2 Economía Agraria...............................................................191

7.3 Capa 3. Aprendizaje. .....................................................................193

7.4 Conclusiones...................................................................................194

iv

CAPÍTULO 8 PRUEBAS Y EVALUACIÓN DE LA PROPUESTA ................................. 196

8.1 Introducción al proceso de evaluación de MEDEA.................. 196

8.2 Ciclos de desarrollo del marco de trabajo.................................. 200 8.2.1 Primer prototipo................................................................. 200 8.2.2 Segundo prototipo .............................................................. 202 8.2.3 Tercer prototipo.................................................................. 204 8.2.4 Cuarto prototipo................................................................. 207 8.2.5 Quinto prototipo ............................................................... 209

8.3 Comparación TEA / TEA-MEDEA ............................................ 209 8.3.1 Funcionalidad..................................................................... 209 8.3.2 Costes de desarrollo y mantenimiento................................ 212

8.4 Conclusiones .................................................................................. 215

CAPÍTULO 9 CONCLUSIONES............................................................................... 217

9.1 Resultados y aportaciones............................................................ 218 9.1.1 Metodología de desarrollo................................................... 218 9.1.2 Implementación de MEDEA.............................................. 220

9.2 Limitaciones ................................................................................... 221

9.3 Líneas futuras................................................................................. 222

REFERENCIAS ...........................................................................................................223

APÉNDICE 1 DOMINIOS DE LÓGICA Y ECONOMÍA AGRARIA............................. 236

v

RESUMEN

MEDEA: MEtodologías y herramientas para el Desarrollo de entornos inteligentes de Enseñanza y Aprendizaje

Los Sistemas Tutores Inteligentes (STI) son aplicaciones educativas basadas en el aprendizaje instructivo (Weber and Specht, 1997). Estos sistemas guían al alumno estructurando, adaptando y supervisando su aprendizaje y no permiten explorar libremente los conocimientos. En la última década los investigadores en este campo han tratado de adaptar las técnicas de los STI a la Web. Esta nueva generación de sistemas se conoce como Entornos de Aprendizaje Inteligentes para la Web (WILE, Web-based Intelligent Learning Environment) (Brusilovsky, 2000). La mayoría de estos sistemas se construyen desde cero. Los procesos de desarrollo son largos y costosos teniendo en cuenta su carácter multidisplinar (en su desarrollo intervienen técnicos, expertos en el domino y pedagogos) y el resultado suelen ser sistemas muy específicos en los que el conocimiento y la forma de presentarlo están estrechamente relacionados.

La comunidad internacional aboga, para la construcción de entornos de aprendizaje, por la reutilización de lo que se ha dado en llamar LO. Los LO, según la definición dada por la IEEE, son una “entidad digital o no digital que puede ser usada, reutilizada o referenciada durante el aprendizaje basado en tecnología (technology-supported learning)” (IEEE, 2005). Numerosas organizaciones de estandarización inciden en la importancia de crear materiales reutilizables y por lo tanto, independientes de la plataforma que los genera y mantiene (Wiley, 2000). Sin embargo los LO están orientados al desarrollo de sistemas “no inteligentes” que carecen de las ventajas de un aprendizaje individualizado proporcionada por los WILE.

Esta tesis se propone aunar las ventajas de ambos enfoques definiendo una metodología para el desarrollo de entornos inteligentes de aprendizaje para la web basada en la integración de sistemas educativos. Asimismo se ha construido un marco de trabajo que la sustenta y facilita la construcción de WILE por usuarios no especializados, de modo que se permita la utilización de programas educativos externos como LO de entornos inteligente aplicados a diversos dominios. Esta propuesta pretende competir con los LMS reduciendo los costes de desarrollo e incrementando la oferta de LO, sin renunciar a la aplicación de técnicas inteligentes.

MEDEA, como metodología, articula el proceso de desarrollo en función de los tipos de usuario involucrados en un sistema educativo y las necesidades que se plantean en su contexto, apostando por la integración de desarrollos anteriores. La metodología propuesta es independiente de la implementación. Como consecuencia, su aplicación no depende de dominios, estrategias educativas y métodos de diagnóstico ni está condicionada por ninguna tecnología de desarrollo. Esta metodología es una apuesta por la integración permitiendo que se utilicen desarrollos anteriores completos (tanto el contenido como la forma de presentarlo), es decir, permite reutilizar no sólo material didáctico sino “la inteligencia” de otros sistemas

.

Capítulo 1 INTRODUCCIÓN

Desde su aparición hasta nuestros días la web se ha convertido en una herramienta fundamental para el desarrollo de sistemas educativos. Los primeros sistemas para la web se limitaban a reproducir los escenarios tradicionales de educación, usando este medio como plataforma para la distribución de material. Sin embargo, sus características para el desarrollo y difusión de aplicaciones abrieron en seguida nuevas expectativas en el campo de la enseñanza asistida por ordenador.

Desde un prisma meramente educativo la web se adapta fácilmente a aplicaciones con un enfoque constructivista del aprendizaje, proporcionando acceso inmediato a grandes cantidades de información y favoreciendo mecanismos para que el alumno explore el dominio de estudio según diferentes criterios y necesidades. En un sistema hipermedia el papel del tutor entendido como orientador desaparece, siendo el alumno el que elige su camino a través del conocimiento. A esta ventaja se une la posibilidad de llegar a miles de alumnos conectados entre sí lo que permite recibir ayuda y colaborar con otros estudiantes, participar en foros, etc. (Webb, 1997), además de asegurar que todos los alumnos tienen acceso al mismo material. A pesar de estas ventajas los sistemas educativos para la web presentan importantes limitaciones pedagógicas, inherentes al hipertexto, como son la desorientación (desubicación en el hiperespacio) y la sobrecarga cognitiva (exceso de información) (Kinshuk and Patel, 1997b).

En contraposición, los Sistemas Tutores Inteligentes (STI) son aplicaciones educativas basadas en el aprendizaje instructivo (Weber and Specht, 1997). Estos sistemas guían al alumno estructurando, adaptando y supervisando su aprendizaje y no permiten explorar libremente los conocimientos.

En la última década se han realizado trabajos que han representado un salto cualitativo en el desarrollo de los sistemas educativos para la web. Los investigadores en este campo han tratado de paliar los efectos negativos del

1

Capítulo 1

aprendizaje basado en el hipertexto adoptando técnicas de los STI. Esta nueva generación de sistemas se conoce como Entornos de Aprendizaje Inteligentes para la Web (WILE, Web-based Intelligent Learning Environment) (Brusilovsky, 2000). La principal aportación es la gestión inteligente del conocimiento encaminada a ofrecer al alumno una enseñanza personalizada aplicando técnicas de planificación de la instrucción y adaptación de contenidos sin coartar la libre exploración del espacio de conocimientos (Urretavizcaya, 2001).

Esta nueva generación de sistemas se beneficia de las facilidades que ofrece la web para difundir el conocimiento, reutilizar materiales y para comunicar a los usuarios, pero supone un esfuerzo de reformulación de sus arquitecturas para poder aprovechar al máximo las posibilidades que ofrece. Dentro de este campo, y con ánimo de mejorar los procedimientos asociados al desarrollo de materiales educativos y su explotación con alumnos, se plantea el desarrollo de esta investigación que, como se verá a lo largo de la memoria, ha involucrado tanto a profesores, como alumnos y tecnólogos, con el objetivo de favorecer la creación, puesta en marcha y evaluación de entornos adaptativos para enseñanza y aprendizaje a través de la web.

1.1 Motivación

El objetivo de los sistemas educativos inteligentes es transmitir a un alumno los conocimientos acerca de un dominio de forma individualizada tratando de emular a un profesor humano en el proceso de aprendizaje.

Diversos estudios realizados durante las dos últimas décadas (véase por ejemplo (Bloom, 1984)) han demostrado la eficacia de una instrucción personalizada frente a los métodos convencionales de enseñanza (un profesor para un grupo y pruebas de nivel de conocimiento periódicas). Estos resultados sirven como argumentos a favor del uso de los sistemas tutores inteligentes convirtiendo la adaptación de la instrucción a las características particulares de cada alumno es su principal valor. El bagaje acumulado en los más de treinta años de vida de los STI confirman su validez pedagógica para el aprendizaje de aquellos dominios a los que se aplican.

Sin embargo, otras propuestas “no inteligentes”, como los Sistemas de Gestión de Aprendizaje (LMS, Learning Management Systems), cuentan con mayor aceptación entre la comunidad educativa (Weber and Brusilovsky, 2001). Estos sistemas, a pesar de no poseer mecanismos para la adaptación de la instrucción, suelen ser genéricos (adaptables a distintos dominios) y ofrecen tanto a alumnos como profesores una amplia variedad de materiales estructurados y metadocumentados, que se han denominado objetos de aprendizaje (LO, Learning Objects). Los LO, según la definición dada por la IEEE, son una “entidad digital o no digital que puede ser usada, reutilizada o referenciada durante el aprendizaje basado en tecnología (technology-supported learning). Ejemplos de LO incluyen contenidos multimedia, contenido de instrucción, objetivos de aprendizaje, software de instrucción y herramientas software, así como personas, organizaciones o eventos referenciados durante el aprendizaje”(IEEE, 2005). La forma en que deben crearse y presentarse estos

2

Introducción

3

materiales es objeto de estudio en la actualidad en varios organismos de estandarización así como en proyectos de investigación (IMS Global Learning Consortium (IMS, 2004), Learning Object Metadata Working Group of the LTSC (LTSC, 2004), PROMETEUS (PROMETEUS, 2005), entre otros). Todos estos trabajos inciden en la importancia de crear materiales reutilizables y por lo tanto, independientes de la plataforma que los genera y mantiene (Wiley, 2000). Esta separación entre las fuentes de los datos y los sitios donde se almacenan ha dado lugar a otro campo de estudio dentro de esta área de investigación que son los llamados Repositorios de Objetos de Aprendizaje (Learning Objects Repository) en el que se trabaja en la búsqueda de soluciones eficientes para el almacenamiento y recuperación de información de las estructuras complejas que guardan los LO.

Los WILE, al contrario que los LMS, se centran normalmente en un único dominio y ofrecen al alumno un número muy reducido de clases de LO. Para el desarrollo de esta tesis se han analizado numerosos sistemas. La mayoría de ellos poseen unos sólidos fundamentos teórico-pedagógicos, han sido estudiados en entornos reales y han probado su eficacia en la mejora de los procesos de aprendizaje. Su construcción es una tarea multidisciplinar que implica a desarrolladores software, expertos en el dominio y pedagogos y son, en la mayoría de los casos, el resultado de años de investigación . Sin embargo, existen limitaciones comunes a un número importante de estos sistemas: a) han sido desarrollados para un dominio concreto; b) se centran en la aplicación de una única estrategia de enseñanza, c) el conocimiento y la forma de presentarlo están estrechamente relacionados y d) tienen unos elevados costes de desarrollo.

Todo esto implica que el conocimiento y material que contienen no sea reutilizable, hecho que se opone diametralmente al concepto de LO. La reutilización supone separar los contenidos de la forma en que éstos se enseñan, siendo necesario para ello una reformulación de los contenidos así como de las arquitecturas. En muchos casos los costes de esta separación hacen que este planteamiento sea inviable.

El problema que se deriva de lo anteriormente expuesto es cómo construir sistemas que conjuguen la versatilidad de los sistemas de gestión de cursos con la calidad de los WILE con unos costes de desarrollo aceptables.

En esta tesis se propone como solución la definición una metodología para el desarrollo de entornos inteligentes de aprendizaje para la web basada en la integración de sistemas educativos. Asimismo se plantea la construcción de un marco de trabajo que la sustente y facilite la construcción de WILE por usuarios no especializados, de modo que se permita la utilización de programas educativos externos como LO de entornos inteligente aplicados a diversos dominios. Esta propuesta pretende competir con los LMS reduciendo los costes de desarrollo e incrementando la oferta de LO, sin renunciar a la aplicación de técnicas inteligentes. Se trata, en definitiva, de aprovechar las ventajas de cada enfoque para obtener mejores resultados para el alumno.

Capítulo 1

1.2 Objetivos

Siguiendo la propuesta para la construcción de sistemas basados en el conocimiento de (Newell, 1982) el objetivo de esta tesis es establecer los niveles de conocimiento y simbólico para entornos de aprendizaje inteligentes para la web basados en la reutilización de programas educativos externos. Según Newell un sistema basado en el conocimiento se puede describir definiendo una jerarquía de niveles. En el nivel superior de la jerarquía se encuentra el nivel del conocimiento que se centra en identificar las acciones y áreas de conocimiento que explican el comportamiento inteligente del sistema (¿qué hace?, ¿qué sabe?). El siguiente es el nivel simbólico que utiliza lenguajes de programación para describir procedimientos y estructuras de datos. En él se toman las decisiones necesarias para construir un modelo que se comporte conforme a la descripción del nivel de conocimiento.

Según esto el principal objetivo de esta tesis, tal y como se ilustra en la Fig. 1, es definir y diseñar:

Una metodología de desarrollo de un entorno de aprendizaje inteligente mediante la integración de sistemas educativos externos. Para ello será necesario identificar los elementos y actores que intervienen en el proceso de construcción de un WILE cuyo fin último es instruir de forma personalizada a un alumno en un dominio concreto.

Un marco de trabajo que de soporte a la metodología definida y que facilite la construcción de entornos inteligentes de aprendizaje para la web (Trella et al., 2001), entendiendo por marco de trabajo “una aplicación semi-completa y reutilizable que puede ser especializada para producir aplicaciones a medida” (Johnson and Foote, 1988) o “el esqueleto de una aplicación que puede ser personalizada por un desarrollador” (Johnson , 1997). El marco de trabajo cumplirá las siguientes especificaciones:

- Reutilización de sistemas educativos, debe permitir la reutilización de sistemas educativos completos (conocimiento y funcionalidad), favoreciendo la interoperabilidad de los mismos.

- Versatilidad, los sistemas susceptibles de ser reutilizados constituirán un conjunto razonablemente completo de LO que puedan ser usados para la construcción de distintos entornos de aprendizaje inteligentes.

- Heterogéneo, compuesto de sistemas de diversas naturalezas.

- Carácter abierto, debe ser extensible, permitiendo la inserción y eliminación dinámica de LO.

- Carácter distribuido, todos sus componentes pueden estar localizados en distintas computadoras de Internet.

- Carácter genérico, debe permitir la creación de WILE para un amplio rango de dominios y tipos de alumnos.

4

Introducción

5

- Bajo coste de desarrollo, la construcción de entornos de aprendizaje inteligentes debe llevarse a cabo en un tiempo razonable y sin la necesidad de intervención de un numeroso grupo de expertos.

Nivel simbólico

Nivel del conocimiento

Metodología de desarrollo de un entorno de aprendizaje inteligente para la web

Marco de trabajo

Implementación

Fig. 1 Niveles de descripción de un entorno de aprendizaje para la web (basado en (Newell, 1982))

Estos objetivos se materializan en MEDEA (MEtodologías y herramientas para el Desarrollo de entornos inteligentes de Enseñanza y Aprendizaje) (Trella et al., 2002). MEDEA comprende a) una metodología de desarrollo que se sustenta en la integración de sistemas educativos externos y que se corresponde con el nivel del conocimiento de Newell y b) un marco de trabajo para la construcción de WILE. La concreción de los detalles relativos a las estrategias de instrucción, estilos de aprendizaje, así como la gestión de los modelos del alumno y del dominio, pertenecen al marco de trabajo que se sitúa en el nivel simbólico. Esta separación permite la construcción de distintos marcos de trabajo basados en la misma metodología de desarrollo. La instanciación del marco de trabajo para un dominio concreto dará lugar a un entorno de aprendizaje inteligente para la web.

En MEDEA se da forma a las ideas propuestas en el nivel del conocimiento acerca de la construcción de entornos educativos inteligentes y se proporcionan las herramientas necesarias para que los profesores puedan construir sus propios entornos para un dominio concreto, integrando otros programas educativos (LO).

El objetivo de esta tesis no es tanto observar el comportamiento de MEDEA desde el punto de vista del alumno, como comprobar que la metodología en la que se basa es válida para proporcionar una instrucción personalizada en un contexto web y que el marco de trabajo cumple con los objetivos marcados, principalmente en términos de interoperabilidad, permitiendo la reutilización de software educativo y reduciendo los costes de desarrollo de entornos de aprendizaje inteligentes para la web. El análisis de la validez pedagógica de MEDEA excede los objetivos de esta tesis ya que factores como la calidad del material de enseñanza, los estilos de enseñanza, los modelos de diagnóstico de los sistemas externos, etc. dependen directamente del entorno concreto que cada profesor construya a partir de MEDEA.

Capítulo 1

1.3 Estructura de la memoria

Esta memoria se estructura en nueve capítulos. El primero y el último se corresponden respectivamente con esta introducción y la exposición de conclusiones.

El capítulo segundo, presenta los fundamentos teóricos de los Sistemas Tutores Inteligentes, desde sus orígenes y evolución, pasando por la descripción detallada de cada uno de los módulos que componen su arquitectura y concluye con una revisión de los STI más representativos desde su aparición hasta nuestros días.

El tercer capítulo muestra el estado actual de los sistemas educativos para la web. La revisión comienza con una presentación de los sistemas convencionales (“no inteligentes”) para dar paso a la descripción de la arquitectura de los sistemas inteligentes de enseñanza. Se han estudiado en detalle algunos sistemas considerados de interés para este trabajo por sus aportaciones, así como distintas propuestas orientadas en la línea de trabajo de esta tesis, desde los primeros sistemas distribuidos hasta las tendencias actuales para la integración de sistemas educativos independientes.

El capítulo cuarto realiza un recorrido por las tecnologías necesarias para el desarrollo de sistemas educativos inteligentes abiertos y distribuidos. En primer lugar se muestra la oferta de modelos y herramientas para el desarrollo de software basado en componentes sobre la web, haciendo especial énfasis en los servicios web, empleados para la construcción de MEDEA. Asimismo se ofrece una visión de conjunto de los trabajos que actualmente están siendo llevando a cabo por distintos organismos internacionales en el terreno de la definición de estándares para el desarrollo de aplicaciones educativas sobre la web. El capítulo concluye con el análisis de los lenguajes de especificación de ontologías para la web, que son la base para la definición y representación del conocimiento en los sistemas educativos inteligentes.

En el capítulo cinco se describe una metodología para el desarrollo de entornos inteligentes de enseñanza para la web que integren sistemas educativos como LO (nivel de conocimiento). En este capítulo se identifican los componentes de un entorno inteligente de aprendizaje para la web, las tareas y fuentes de conocimiento de cada uno, las interacciones entre los distintos componentes y el proceso de construcción de un entorno de aprendizaje inteligente mediante la integración de sistemas educativos externos. El resultado está formado por a) un conjunto de especificaciones que definen la estructura de un WILE y b) la descripción del conjunto de acciones y los actores que participarán en cada una de las fases que conducen a la creación de un WILE.

El capítulo seis presenta el marco de trabajo MEDEA, una implementación que cumple las especificaciones dadas en el capítulo cinco (nivel simbólico). A través de MEDEA se muestra como el modelo definido permite reutilizar sistemas ya construidos e integrarlos dinámicamente. Para ello se han usado tres sistemas existentes, SIGUE, SIETTE y WADEIn-II, como LO del marco de

6

Introducción

7

trabajo. Estos sistemas han sido desarrollados con anterioridad a esta tesis y usados independientemente con alumnos reales.

El capítulo siete muestra dos entornos de aprendizaje inteligentes para la web construidos a partir de MEDEA. Estos sistemas versan respectivamente sobre los dominios de Lógica y Economía Agraria y han sido construidos reutilizando sistemas y material educativo existente.

El capítulo ocho describe la evaluación de MEDEA. Se ha llevado a cabo una evaluación formativa basada en la construcción iterativa de prototipos. Como parte de la evaluación se ha comparado el proceso de desarrollo de un sistema sobre Economía Agraria realizado en el año 1996 con el construido siguiendo las directrices de MEDEA.

Finalmente en el capítulo nueve, se detallan las aportaciones que realiza esta tesis, las limitaciones y ámbitos de aplicación de los resultados obtenidos. Asimismo se indican las líneas de investigación que se abren a partir de este trabajo.

Capítulo 2 SISTEMAS TUTORES INTELIGENTES

Los Sistemas Tutores Inteligentes (STI) son programas cuya misión es transmitir a un alumno el conocimiento y habilidades relacionadas con determinada materia. El objetivo principal de los STI es realizar una enseñanza personalizada, adaptada a las necesidades del alumno, intentando emular la forma en que lo haría un tutor humano.

El desarrollo de STI es una tarea compleja que requiere la participación de profesionales de áreas muy diversas como la Inteligencia Artificial, la Ingeniería del Software, la Pedagogía, la Psicología Cognitiva y los campos propios del dominio de enseñanza.

En la actualidad, este campo ha evolucionado hacia una nueva generación de STI, los Entornos Inteligentes de Aprendizaje para la Web (WILE, Web-based Intelligent Learning Environments), sobre los que versa esta tesis. Por ello se ha considerado de interés acercarnos a sus orígenes realizando una revisión de algunos de los STI desarrollados en las últimas décadas, como ejemplo de los principios y técnicas sobre los que se sustentan estos nuevos entornos de aprendizaje inteligentes.

En este se tema se introduce el concepto de STI, el estudio de su arquitectura profundizando en cada uno de sus módulos, así como la descripción y clasificación de algunos de los STI más significativos por sus aportaciones a esta disciplina.

2.1 De los Sistemas de Enseñanza Asistida por Ordenador a los Sistemas Tutores Inteligentes

La Enseñanza Asistida por Ordenador (EAO), también conocida como Computer- Assisted Intruction (CAI) o Computed- Assisted Learning (CAL), ha evolucionado desde sus orígenes hasta nuestros días gracias al desarrollo de diversas técnicas dentro del campo de las Ciencias Cognitivas, de las Ciencias de la Computación y de las Tecnologías de la Información.

8

Sistemas Tutores Inteligentes

9

Los primeros sistemas de EAO empezaron a desarrollarse durante los años 50 y 60. La arquitectura de los programas de EAO tradicionales básicamente se puede resumir en a) un conjunto de textos, ejercicios y cuestionarios o exámenes y b) un conjunto de reglas que representan la experiencia pedagógica de uno o varios profesores. El funcionamiento de estos sistemas suele ser el siguiente: el programa presenta al alumno un bloque de información y a continuación evalúa la correcta asimilación de estos contenidos. La respuesta del alumno es usada para decidir, en función de las reglas programadas, la siguiente acción instructiva. Si la respuesta es correcta se presentarán nuevos contenidos y en caso contrario se reincidirá sobre los contenidos actuales presentando el mismo o nuevo material (texto, imágenes, ejercicios, etc.) hasta que el alumno demuestre que ha asimilado esos conocimientos.

El principal problema de los sistemas de EAO tradicionales es su rigidez y su falta de adaptación a las necesidades particulares de los alumnos (Wenger, 1987a). Todas las decisiones pedagógicas tomadas a lo largo de la instrucción están predefinidas en el sistema, que es incapaz de responder ante estímulos no previstos y de ofrecer respuestas diferentes a alumnos diferentes. Las decisiones se toman sólo en función de qué se responde a una pregunta o problema y no se tiene en cuenta quién responde.

Como ejemplo de los trabajos de EAO desde su aparición hasta los 80 podemos destacar el proyecto el NDPCAL (National Development Program for Computer Assisted Learning) de Gran Bretaña (Hooper, 1977), los sistemas desarrollados en el marco de los proyectos TICCIT y PLATO (Alderman et al., 1978), ambos con importantes dotaciones económicas del gobierno de Estados Unidos, así como los proyectos de EAO de Stanford (Suppes, 1981).

El NDPCAL (National Development Programme for Computer Assisted Learning) fue un programa de investigación y desarrollo cuyo objetivo era la integración de los ordenadores en todas las ramas de la educación incluyendo colegios, institutos, universidades y centros de entrenamiento industrial. Este programa abarcó un periodo de cinco años (1973-1978) que terminó justo cuando los primeros micro-ordenadores llegaron al mercado. El NDPCAL incubó numerosas ideas para la educación asistida por ordenador que impulsaron el desarrollo de software educativo para micro-ordenadores.

El sistema PLATO (Programmed Logic for Automated Teaching Operations) fue desarrollado en la Universidad de Illinois en 1960 y ha sido uno de los sistemas educativos más grandes y sofisticados que se han diseñado: tenía cerca de mil terminales en distintas localidades de Estados Unidos y otros países proporcionando a cada uno acceso a una biblioteca central de lecciones. El sistema se creó para proporcionar instrucción individualizada sobre una gran variedad de temas (desde álgebra hasta zoología) a alumnos de escuelas y universidades de diversos lugares. A mitad de los 70 PLATO fue comercializado por Control Data Corporation.

TICCIT (Time-Shared Interactive Computer Controlled Information Television) fue desarrollado en las Universidades de Tejas y Brigham Young. El objetivo de

Capítulo 2

TICCIT era usar micro-ordenadores y tecnología televisiva para distribuir cursos por computador y programas educativos de inglés y matemáticas a la comunidad educativa. Las lecciones de TICCIT se mostraban en pantallas de televisión a color conectados a un teclado y un ordenador local donde los alumnos podían responder. Con TICCIT se intentó comprobar la efectividad de la enseñanza asistida por ordenador frente a la enseñanza tradicional en el aula.

El Instituto para el Estudio de las Matemáticas en las Ciencias Sociales de la Universidad de Standford (Institute for Mathematical Studies in the Social Sciences, IMSSS) empezó a usar los computadores con fines educativos impartiendo cursos de lógica y matemáticas a alumnos de la escuela primaria. En 1968 comenzaron a trabajar en el ámbito universitario desarrollando cursos de Lógica y Teoría de Conjuntos. Suppes (Suppes, 1981) diseñó un software educativo con retroalimentación, ramificación de lecciones y almacenamiento de registros de los alumnos.

A partir de los años 70 se comienzan a usar técnicas de Inteligencia Artificial en el campo de la EAO surgiendo así los llamados Sistemas Inteligentes de Enseñanza Asistida por Ordenador (IEAO) que han evolucionado hasta lo que hoy conocemos como Sistemas Tutores Inteligentes (STI). Algunos autores como Wenger (Wenger, 1987a) no establecen ninguna diferencia entre STI y IEAO. Sleeman y Brown (Sleeman and Brown, 1982) hablan de sistemas de EAO generativos como los precursores de los STI (o IEAO). Estos sistemas ofrecen alguna adaptación generando, por ejemplo, problemas de distintos niveles de dificultad, pero lo que establece de algún modo la línea de separación entre ambos es la representación de las diferentes clases de conocimiento que intervienen en el proceso de enseñanza. En palabras de Wenger, no se trata de que los expertos puedan representar sus decisiones en forma de programa sino de capturar el conocimiento que permite a los expertos componer estas decisiones.

En este punto podemos definir un Sistema Tutor Inteligente como un programa cuya tarea es transmitir a un alumno los conocimientos sobre una materia de forma individualizada intentando emular a un profesor humano en el proceso de aprendizaje, para lo cual necesitará manejar conocimiento sobre el dominio, el alumno y estrategias de instrucción, o lo que es lo mismo sobre qué se va a enseñar, a quién se va a enseñar y cómo se va a enseñar.

De esta definición se desprende el carácter multidisciplinar del campo de los Sistemas Instructores Inteligentes que abarca la Inteligencia Artificial (en áreas como la representación del conocimiento, el diagnóstico, el procesamiento del lenguaje natural, etc.), la Pedagogía, la Psicología Cognitiva y los campos propios del dominio de enseñanza.

2.2 Arquitectura de un Sistema Tutor Inteligente

La arquitectura de un STI viene determinada por su propia definición, y es que un STI debe contener elementos que representen el conocimiento del dominio,

10


11

del alumno y pedagógico, y otros que manejen todo este conocimiento para generar y controlar la(s) sesión(es) de instrucción.

La arquitectura básica de un STI no ha variado sustancialmente desde los comienzos de la investigación en este campo hasta nuestros días (Polson and Richardson, 1988; Self, 1999). Está formada por cuatro módulos que son: del dominio o experto, del alumno, instructor o pedagógico y de comunicación o entorno (Fig. 2).

El módulo del dominio contiene el conocimiento sobre la materia que se pretende enseñar, el módulo del alumno está relacionado con el nivel de conocimiento del alumno acerca de la materia así como con sus aptitudes y preferencias frente al estudio. El módulo pedagógico se encarga de tomar las decisiones pedagógicas y planificar las sesiones de instrucción y por último el entorno se encarga de controlar la interacción del alumno con el sistema.

Módulo del

dominio

Módulo pedagógico

Módulo del alumno

Módulo de comunicaciones

Fig. 2 Arquitectura de un Sistema Tutor Inteligente

En los siguientes epígrafes se analiza cada uno de estos módulos. Los sistemas referenciados en este apartado para ilustrar algunas características de los componentes de un STI se describen en detalle en el apartado 2.3.

2.2.1 Módulo experto o del dominio

El módulo experto o del dominio contiene el conocimiento de la materia que se pretende enseñar. Sus funciones fundamentales son presentar el material de estudio al alumno, generar explicaciones, cuestiones y sus respuestas, problemas y sus soluciones, y responder a eventuales preguntas del alumno.

Anderson clasifica los módulos expertos en tres grupos atendiendo a los principios de diseño: modelos de caja negra, de caja de cristal y cognitivos (Anderson, 1988).

Los modelos de caja negra pueden generar y resolver problemas pero los pasos seguidos para obtener la solución o no están disponibles o tienen una representación no apta para propósitos tutoriales. Un ejemplo muy común es un tutor de ajedrez que realiza jugadas buscando entre millones de

Capítulo 2

movimientos posibles. El hecho de que el sistema muestre como ha llegado a esa solución no serviría para enseñar al alumno a jugar mejor ya que los humanos no razonamos del mismo modo. En esta línea, el sistema WEST (Barr and Feigenbaum E.A., 1982b; Wenger, 1987d), que enseña a los niños un juego que consiste en avanzar un determinado número de casillas resultantes de realizar operaciones aritméticas simples, utiliza un modelo de caja negra para explorar los posibles movimientos en cada jugada y determinar el óptimo.

Los modelos de caja de cristal, al contrario que los de caja negra, utilizan una representación del conocimiento del dominio que permita ofrecer al alumno explicaciones razonadas sobre el modo de obtener la solución a un problema. El diseño de estos modelos se realiza siguiendo técnicas de ingeniería del conocimiento para extraer y representar el conocimiento de un dominio del mismo modo que se hace en la construcción de un sistema experto. El ejemplo más significativo de este tipo de modelos es el usado en el sistema GUIDON (Barr and Feigenbaum E.A., 1982b; Wenger, 1987c) basado en el sistema MYCIN (Shortliffe, 1976), que diagnosticaba una enfermedad infecciosa a partir de sus síntomas. GUIDON utiliza el sistema de reglas de MYCIN complementándolo con otras (t-rules, tutorial rules) que incluyen conocimiento necesario para llevar a cabo una acción instructiva. Sin embargo, MYCIN utiliza a veces reglas demasiado complejas para principiantes en el dominio y desarrolla razonamientos difíciles de justificar. De esta experiencia se deduce la importancia de la representación del conocimiento en un STI. Es fundamental a la hora de modelar un dominio para un STI no perder de vista la finalidad pedagógica del mismo. Esto influirá en dos sentidos: por un lado en la inclusión de conocimiento pedagógico (como las t-rules de GUIDON) en el modelo del dominio que permita guiar al alumno de forma adecuada a lo largo de la instrucción, y por otro, en el refinamiento del modelo. Como dice Anderson, a veces modelar fielmente un dominio puede resultar una carga computacionalmente innecesaria e irrelevante para el propósito tutorial, como en el caso de GUIDON.

Las limitaciones de los modelos de caja negra y caja de cristal han llevado a los investigadores en STI a estudiar y desarrollar modelos cognitivos. Estos modelos intentan representar las estructuras cognitivas y el modo de razonar sobre ellas de un humano. El problema de estos modelos es el tiempo necesario para su desarrollo, lo que puede llegar a hacer inviable la construcción del sistema. Por otro lado no todas las componentes psicológicas que intervienen en un proceso de razonamiento humano son necesarias desde el punto de vista tutorial. Es tarea de los diseñadores decidir cuáles se deben tener en cuenta a la hora de construir el modelo.

Otro punto importante en el diseño de un modelo cognitivo es el tipo de conocimiento que se va a representar. Podemos establecer la siguiente clasificación: conocimiento procedimental, declarativo y cualitativo.

El conocimiento procedimental es conocimiento sobre cómo desarrollar una tarea. La representación para este tipo de conocimiento suele ser un sistema de reglas de producción que está estrechamente ligado al dominio, como el

12


13

empleado en el sistema BUGGY (Barr and Feigenbaum E.A., 1982b; Wenger, 1987b). Cada regla es una unidad de conocimiento que puede comunicarse al alumno independientemente del resto del problema. Esto implica que cuando un alumno comete un error se puede saber cual ha sido conociendo qué regla no ha aplicado. Una de las ventajas de la aproximación basada en reglas es que hace posible realizar un seguimiento de las acciones del alumno y detectar que se ha separado del camino correcto en el mismo instante en que cometa un error.

El conocimiento declarativo se expresa en forma de un conjunto de hechos organizados adecuadamente sobre los que se puede razonar. El esquema de representación más extendido para este tipo de conocimiento es el de redes semánticas en las que los nodos representan conceptos o unidades de conocimiento y los arcos las relaciones entre ellos. SCHOLAR (Barr and Feigenbaum E.A., 1982b; Wenger, 1987f), con la geografía sudamericana, es el primer ejemplo de STI que modela un dominio declarativo. Una ventaja de los dominios declarativos es la posibilidad de usar representaciones independientes del dominio, buena prueba de ello son las arquitecturas genéricas para STI tales como DGC (Vassileva, 1997), IRIS(Arruarte et al., 1997) o EON (Murray, 1998), que emplean redes semánticas en la construcción de sus modelos declarativos.

Por último, el conocimiento cualitativo está relacionado con la habilidad mental para simular y razonar sobre relaciones espaciales y procesos dinámicos, y por lo tanto con la capacidad de razonar sobre la estructura causal de un dispositivo y detectar problemas en su funcionamiento. Este tipo de conocimiento es de gran importancia en los sistemas de diagnóstico. La construcción de un modelo causal implica la representación de la estructura del dispositivo y la simulación del proceso en ese modelo. SOPHIE (Barr and Feigenbaum E.A., 1982b; Wenger, 1987e) es un ejemplo de sistema que modela este tipo de conocimiento. Este STI enseña a los alumnos a encontrar averías en un circuito electrónico y se sirve para ello de un modelo matemático del comportamiento del circuito (entre otros elementos).

La siguiente tabla ofrece una clasificación de los modelos del domino de los sistemas estudiados en el apartado 2.3 en cada una de las categorías descritas. Destaca el hecho de que la mitad de los sistemas estudiados presentan un modelo cognitivo declarativo modelado utilizando una red semántica de conceptos.

MODELOS COGNITIVOS MODELOS DE CAJA NEGRA

MODELOS DE CAJA DE CRISTAL DECLARATIVOS PROCEDIMENTALES CAUSALES

SCHOLAR X

WHY X

SOPHIE X X X

WEST X

Capítulo 2

MODELOS COGNITIVOS MODELOS DE MODELOS DE CAJA NEGRA CAJA DE

CRISTAL DECLARATIVOS PROCEDIMENTALES CAUSALES

WUSOR X

GUIDON X

BUGGY X

IDE X X

IRIS X X

REEDEM X

RIDES

DGC X

EON X

Tabla 1 Clasificación de los modelos del dominio de algunos STI.

2.2.2 Módulo del alumno

El modelo del alumno representa el conocimiento del alumno acerca del dominio de enseñanza así como otros parámetros que influyen en el proceso de aprendizaje (preferencias en el modo de interacción con el programa, nivel de habilidad, velocidad de progreso, motivación, aptitudes frente al aprendizaje, estados de ánimo, etc.). El estudio de algunos de parámetros recae en el área de la psicología educativa y son difíciles de representar, estimar y medir computacionalmente, por lo que la mayoría de los STI se centran en la representación del conocimiento del alumno acerca del dominio.

La misión del modelo del alumno es inferir el conocimiento que el alumno posee del dominio a partir de su interacción con el sistema de modo que el módulo pedagógico pueda tomar decisiones acerca de la estrategia de instrucción óptima para cada alumno basándose en el estado actual de conocimiento del alumno. Este proceso de inferencia es conocido como diagnóstico. Para tomar estas decisiones pedagógicas no es necesario incluir en el modelo todos los estados mentales por los que pasa el alumno en su proceso de aprendizaje. Debe existir un compromiso entre la precisión y completitud del modelo del alumno, lo que implica esfuerzo computacional, y la ganancia pedagógica.

El modelado del alumno consiste, pues, en seleccionar a) qué información se va a incluir en el modelo, b) la estructura de datos más apropiada para representarla y c) el procedimiento de diagnóstico adecuado para manejar dicha estructura.

Los tipos de modelo del alumno utilizados en los STI se diferencian en qué conocimiento del alumno sobre el dominio se va a representar. Básicamente podemos distinguir entre:

14


15

Modelo de superposición (overlay model): el conocimiento del alumno es un subconjunto del conocimiento del módulo experto. Este enfoque supone que todas las diferencias entre el comportamiento del alumno y el del experto se explican como una falta de conocimiento del alumno.

Los modelos de superposición pueden estar compuestos de uno o varios niveles (o capas) que representan diferentes vistas del conocimiento del alumno sobre el dominio. En sistemas como GUIDON (Barr and Feigenbaum E.A., 1982b; Wenger, 1987c), IRIS (Arruarte, 1998; Arruarte et al., 1997) o EON (Murray, 1998) se modela al estudiante como el conjunto de elementos del dominio asociando a cada uno un valor que representa el grado de conocimiento acerca de dicho elemento, ya sea un hecho, concepto, regla, etc. En cada uno de estos sistemas se representan diferentes capas según el significado de dichos valores. Por ejemplo, en GUIDON se almacena una vista del modelo del alumno que almacena factores de certeza que representan el conocimiento que el alumno tiene de cada regla, otra capa que indica la capacidad del alumno para aplicar cada regla y por último un nivel que indica si el alumno usaría o no cada regla en la justificación de sus hipótesis. En EON se divide el modelo del alumno en cinco capas que representan el conocimiento del alumno de las lecciones, los conceptos, los niveles de los conceptos, los contenidos y los eventos.

Modelo diferencial (differential model): divide el conocimiento del alumno en dos categorías a) conocimiento que el alumno debería poseer y b) conocimiento que no puede esperarse que el alumno tenga pero que el experto sí posee (missing conception). A diferencia del modelo de superposición, el modelo diferencial reconoce y trata de representar explícitamente tanto el conocimiento del alumno como las diferencias alumno / experto. En este modelo se asume que el alumno no razona como lo haría el experto. El sistema WEST (Barr and Feigenbaum E.A., 1982b; Wenger, 1987d) usa un modelo diferencial para modelar al alumno comparando cada acción del alumno con el comportamiento del experto y representando las diferencias.

Modelo de perturbación (pertubation model): este modelo, al igual que el anterior, también representa dos categorías de conocimiento: aquel que el alumno debería poseer y conocimiento que el alumno posee pero no el experto (misconception y bugs). Es decir, en el modelo anterior se representan las carencias del alumno respecto al experto y aquí los conceptos erróneos que el alumno posee. El sistema BUGGY (Barr and Feigenbaum E.A., 1982b; Wenger, 1987b) es el más representativo dentro de esta categoría de modelos siendo capaz de representar un elevado número de posibles errores cometidos por los alumnos al desarrollar operaciones aritméticas básicas.

Biblioteca de errores: tanto el modelo diferencial como el de perturbación se pueden considerar como un modelo de superposición más una biblioteca de carencias del alumno (missing conceptions), errores de conceptos (misconceptions) y fallos comunes de los alumnos (bugs). La construcción del

Capítulo 2

catálogo de errores puede hacerse recolectándolos de la literatura educativa relacionada con el dominio, haciendo un análisis manual del comportamiento de los alumnos, intentando predecirlos basándose en una teoría del aprendizaje para el dominio (VanLehn, 1988), o generándolos a partir de otras bibliotecas ya existentes.

Modelo basado en restricciones: en este modelo el conocimiento se representa mediante una lista de restricciones sobre el estado de los problemas y el modelo del alumno está formado por las restricciones que el alumno ha transgredido en el proceso de resolución del problema. En SQL-Tutor (Mitrovic and Ohlsson, 1999), un STI para enseñar el lenguaje de consulta de bases de datos SQL, se han identificado un total de 392 restricciones analizando el dominio y comparando soluciones a problemas correctas e incorrectas. Cada restricción tiene dos condiciones: importancia y satisfacción, una lista de problemas a los que se aplica la restricción y un mensaje de error que se ofrece como ayuda al alumno cuando infringe la restricción. El modelo del alumno indica cuantas veces se usó cada restricción, cuantas de esas veces era importante para el problema y cuántas fue usada correctamente.

En la actualidad existen algunas entidades internacionales, entre las que destacan ADL (Advanced Distributed Learning Initiative), IMS (Instructional Management System) e IEEE LTCS (IEEE Learning Technology Standars Commitee), que están trabajando en estándares para la educación. Algunas de estas especificaciones están orientadas a los modelos del alumno. Las más destacadas a nivel internacional son IMS LIP (Learner Information Package) e IEEE PAPI (Public And Private Information). Aunque estos modelos, que se explican con más detalle en el apartado 4.2, no se ajustan totalmente a las necesidades de los sistemas inteligentes o basados en el conocimiento, actualmente se tiende a incluir extensiones de los estándares que permitan realizar diagnóstico del alumno y adaptación de la instrucción a la vez que reutilizar y compartir el máximo de información posible con otros sistemas (Razmerita et al., 2003; Sampson et al., 2002; Stash et al., 2005).

En la siguiente tabla se han clasificado los modelos del alumno de los sistemas estudiados en el apartado 2.3 dentro de las categorías descritas en este apartado. Todos los sistemas, salvo algunas excepciones, implementan un modelo de superposición, asignando algún tipo de valoración a los conceptos definidos en el modelo del dominio que indique el conocimiento que el alumno posee acerca de los mismos.

MODELOS DE SUPERPOSICIÓN

MODELOS DIFERENCIALES

MODELOS DE PERTURBACIÓN

MODELOS BASADOS EN RESTRICCIONES

SCHOLAR X

WHY

SOPHIE X

WEST X

16


17

WUSOR X

GUIDON X

BUGGY X

IDE X

IRIS X

REEDEM X

RIDES X

EON X

SQL-Tutor X

Tabla 2 Clasificación de los modelos del alumno de algunos STI.

El proceso de diagnóstico se encarga de mantener y actualizar la información del modelo del alumno que se usará para tomar decisiones durante el proceso de enseñanza. Para ello debe ser capaz de inferir qué se esconde detrás de una respuesta correcta o incorrecta del alumno: ¿el alumno no entiende el concepto?, ¿ha marcado por error la respuesta incorrecta?, ¿ha acertado al azar la respuesta correcta?, ¿no ha leído bien la pregunta?, ¿existe un conocimiento previo que el alumno ha asimilado incorrectamente?, etc. Esta tarea es muy complicada debido a la presencia de ruido en las fuentes de evidencia necesarias para realizar el diagnóstico. En (Barr and Feigenbaum E.A., 1982a) se citan como fuentes principales a) las implícitas, el comportamiento observable del alumno en la resolución de problemas; b) las explícitas, preguntas directas al alumno; c) las históricas, basadas en la experiencia del alumno y d) las estructurales que proceden de la medida de la dificultad del dominio. Estas fuentes de datos se ven alteradas por varios aspectos tales como el hecho de que la representación usada en el modelo del alumno es una simplificación de complejas estructuras y procesos mentales o la inconsistencia en el comportamiento de los alumnos debido a diversas razones como distracciones, falta de concentración o el azar en sus respuestas. Todo esto hace que sea difícil determinar por qué un alumno ha respondido correcta o incorrectamente.

El problema del modelado del alumno ha sido uno de los más estudiados a lo largo de la historia de los STI, por lo que existe una gran variedad de métodos de diagnóstico que se han probado con mayor o menor éxito en sistemas reales o de investigación. En (VanLehn, 1988) se establece una clasificación de los métodos de diagnóstico desarrollados hasta el año 1988 según dos parámetros: el tipo de conocimiento que maneja el sistema (declarativo, procedimental representado en una estructura jerárquica o en una base de conocimientos no jerarquizada) y el tipo de fuente de evidencia (bandwitdh). Varios de estos métodos están basados en la traza del modelo (model tracing) que consiste en monitorizar a un alumno mientras está resolviendo un problema. En cada paso de la resolución el sistema genera un conjunto de posibles reglas que el alumno podría aplicar obteniendo los estados a los que el

Capítulo 2

alumno podría pasar a partir del anterior. Si efectivamente el alumno alcanza uno de estos estados se supone que conoce la/s reglas que se debían aplicar, dato que se anota en el modelo del alumno. Existen variaciones de la traza del modelo que obtienen una cadena de reglas aplicables entre dos estados (path finding) o que inducen reglas que el modelo experto no contempla (condition induction).

Existe otro conjunto de métodos en los que la información de la que se dispone para realizar el diagnóstico es sólo el estado final o la respuesta y no un conjunto de pasos o estados mentales como en las anteriores (decision trees, generate and test, interactive diagnosis).

Por otra parte, en (Millán, 2000) se ofrece una completa revisión de los métodos de diagnóstico basados en la aplicación de diversas técnicas de razonamiento aproximado en Inteligencia Artificial (IA) tales como los sistemas basados en reglas, la lógica difusa, las redes bayesianas y la teoría de Dempster-Shafer.

2.2.3 Módulo instructor o pedagógico

La misión del módulo instructor dentro de un STI es la de planificar y controlar la instrucción del alumno, es decir, es el encargado de personalizar o adaptar la enseñanza que el alumno recibe. Este cometido se concreta en dos tareas que Halff (Halff, 1988) define como currículo e instrucción, o lo que es lo mismo, la secuenciación del material que se va a presentar al alumno y la selección del método de presentación más adecuado.

El desarrollo del módulo instructor de un STI está basado en la aplicación de los fundamentos de las Teorías del Aprendizaje y de la Instrucción. Las teorías sobre el aprendizaje describen el modo en el que se produce el conocimiento, es decir, qué sucede en la mente del alumno cuando aprende mientras que las teorías de la instrucción intentan describir metodologías y estrategias para facilitar la adquisición de conocimientos y las situaciones en las que éstas son aplicables.

Existen dos grandes tendencias dentro del campo de la Psicología del Aprendizaje: la conductista y la cognitiva. El conductismo se basa en definir el aprendizaje como la modificación del comportamiento del sujeto mediante la repetición de patrones de conducta, mientras que la rama cognitiva entiende el aprendizaje como las relaciones entre un conjunto de fenómenos externos (cultura, contexto del aprendizaje, entorno,...) y los procesos cognitivos (selección, codificación, organización y recuperación de la información) y estructuras internas que se producen en el sujeto. Aparte de estas dos líneas, cabe destacar una tercera: el aprendizaje constructivista. El constructivismo puede ser considerado como un paradigma dentro del cognitivismo aunque existen autores que lo clasifican como una teoría con entidad propia (Martorell and Prieto, 2002). Los constructivistas defienden que el individuo es capaz de construir conceptos a través de sus propias experiencias, conocimientos previos, creencias, motivaciones, etc. Según esto cada individuo tiene su propia

18


19

percepción de la realidad y desarrolla sus esquemas mentales particulares. Frente al constructivismo individual, basado en las ideas de Piaget, surge el constructivismo social de Vygotsky que considera al individuo como el resultado del proceso histórico y social donde el lenguaje desempeña un papel esencial. Para Vygotsky el conocimiento es un proceso de interacción entre el sujeto y el medio social y cultural.

Las diferentes tendencias en el campo de la teoría del aprendizaje han tenido una influencia directa en el terreno de la instrucción o diseño educativo. En (Gros, 1997) se muestra como se han concretado estas teorías en teorías de la instrucción y aplicado al diseño de programas educativos.

El diseño de la instrucción basado en la teoría conductista está influido principalmente por los trabajos de Skinner (Skinner, 1954) y sus colaboradores que sustentaron las bases de la denominada Enseñanza Programada. Skinner establece el concepto de objetivo conductista según el cual el objetivo del aprendizaje es cuantificable y sugiere medir la efectividad de éste en términos de resultados. Posteriormente diversos investigadores intentan clasificar estos objetivos de acuerdo a diversos tipos de aprendizaje observables, aunque la mayor parte de ellos los clasifica en tres ámbitos diferentes: cognitivo, afectivo y motriz. Las teorías de la instrucción se basan principalmente en el ámbito cognitivo (desarrollo de la memorización y de habilidades procedimentales) (Reigeluth, 2000). Los diferentes teóricos educativos han propuesto diversas taxonomías para los tipos de aprendizaje en el ámbito cognitivo. Entre las más conocidas (Tabla 3) se encuentran las de Bloom (Bloom et al., 1956), Gagné (Gagné, 1985), Ausubel (Ausbel, 1968) y Anderson (Anderson, 1983).

BLOOM GAGNÉ AUSUBEL ANDERSON

Conocimiento Aprendizaje rutinario Conocimiento declarativo

Comprensión

Información verbal

Aprendizaje significativo

Conocimiento procedimental

Aplicación Técnica Intelectual

Análisis Síntesis Evaluación

Estrategia cognitiva

Tabla 3 Taxonomías educativas. (Adaptado de (Reigeluth, 2000) ).

Skinner postulaba que el material debía ser presentado al alumno de forma fraccionada para poder introducir refuerzos en cada uno de los fragmentos. La secuenciación del material era fijada de antemano y las respuestas del alumno a las preguntas propuestas al final de cada fragmento no influían de ningún modo en la presentación del material, ya que según Skinner si el diseñador del programa lo había hecho bien el alumno no tenía por qué fallar. Siguiendo esta metodología todos los alumnos reciben la misma instrucción, es decir, no es una instrucción personalizada. Los primeros sistemas de EAO están basados en las ideas conductistas de la enseñanza programada.

Capítulo 2

Las teorías del aprendizaje cognitivo introducen en la instrucción algunos conceptos fundamentales. Por un lado la suposición básica de que el aprendizaje da como resultado la organización de la memoria en estructuras cognitivas o conceptuales y por otro la creencia de que el aprendizaje depende del ambiente o contexto educativo en el que se lleve a cabo. Psicólogos como Gagné (Gagné and Briggs, 1979) o Merrill con su CDT (Component Display Theory) (Merrill, 1983) realizan importantes aportaciones al campo del diseño de la instrucción. Gagné, aún con influencias conductistas, establece las condiciones internas y externas que intervienen en el aprendizaje y establece un conjunto de fases que completan el proceso de aprendizaje (motivación, comprensión, retención, recuerdo, generalización, ejecución y retroalimentación). Gagné define un conjunto de eventos o acciones instructivas que pueden ayudar al sujeto en su paso por cada una de las fases de aprendizaje (informar al alumno del objetivo, dirigir la atención con cambios de voz o subrayando conceptos importantes, proporcionar realimentación, etc.).

La CDT de Merrill establece las relaciones entre los tipos de contenidos de aprendizaje (hechos, conceptos, procedimientos y principios) y sus niveles de ejecución (encontrar, usar, recordar generalidades y recordar ejemplos) y describe los tipos de estrategias más adecuadas para conseguir dichos aprendizajes.

Existen numerosas teorías de instrucción cognitivas recogidas en (Reigeluth, 2000). Todas ellas conforman lo que se ha dado en llamar aprendizaje instructivo (Pérez et al., 2001) cuya principal característica es la relevancia del papel del tutor, que guía el proceso de enseñanza encargándose de la estructuración y presentación del conocimiento así como de la supervisión del aprendizaje del alumno. Los STI clásicos están basados en el aprendizaje instructivo. En ellos el alumno juega un papel pasivo limitándose a seguir las indicaciones del tutor.

Por último se presentan los principios de instrucción basados en el constructivismo. Estos se sustentan en los modelos de procesamiento de información cognitivos (la organización de los conocimientos se realiza en forma de redes) y en el hecho de que los alumnos aprenden por sí mismos dirigiendo sus capacidades hacia ciertos contenidos y construyendo ellos mismos el significado de esos contenidos. Para los constructivistas las estrategias de aprendizaje son individuales mientras que para los cognitivos es posible encontrar estrategias generalizables. Los sistemas hipermedia son el paradigma de un sistema educativo constructivista, puesto que el alumno tiene total libertad para navegar dentro de un espacio de conocimiento. La presencia del tutor en estos sistemas es inversamente proporcional al grado de libertad del alumno, puede ir desde simplemente proporcionar el contenido del curso hasta establecer límites a la información de que dispone el alumno y a la forma de accederla. En el capítulo 3 se ofrece una revisión de este tipo de sistemas.

Como se mencionaba anteriormente, existen algunos autores que defienden la interacción social en el aprendizaje concediendo gran importancia al conocimiento adquirido a través de la negociación con los demás. El

20


21

constructivismo social sienta las bases de los sistemas colaborativos que ofrecen un escenario de cooperación en el que los alumnos pueden cuestionarse y construir su conocimiento (Urretavizcaya, 2001). En este tipo de sistemas el papel del tutor está limitado a la de seguimiento y motivación de los alumnos. La función de este tipo de sistemas es ofrecer mecanismos de ayuda a la toma de decisiones, organizar y gestionar el conocimiento compartido que se genera durante el desarrollo de las tareas y ofrecer herramientas que permitan la comunicación entre los alumnos (hojas de notas, videos, animaciones, etc.). En la última década ha habido una notable evolución en este campo con el desarrollo de sistemas como CSILE (Scardamalia and Bereiter, 1994), CLARE (Wan and Johnson, 1994) o DEGREE (Barros and Verdejo, 2001).

2.2.3.1 Planificación de la instrucción

Como ya se ha mencionado al principio de este apartado, la tarea principal del módulo pedagógico es planificar la secuencia de instrucción más adecuada para cada alumno. La planificación es un problema ampliamente estudiado en la Inteligencia Artificial. En (Le et al., 1998) se define como “un conjunto de funciones que, cuando son llevadas a cabo, proporcionan un plan de acción que será ejecutado por un agente para hacer evolucionar a un objeto desde un estado inicial hasta uno final (el objetivo) en un contexto dado (entorno); este plan asegura que el objetivo sea alcanzado mientras se cumplan las restricciones impuestas [...]”.

En el campo de la instrucción automática el objeto es el alumno al que el sistema (agente) debe guiar desde un estado inicial de conocimiento acerca de una materia hasta que alcance el objetivo de la instrucción (aprender determinados conceptos de la materia). La estrategia/s o teoría/s de instrucción seleccionadas por el diseñador determinarán el contexto (sistema hipermedia, entorno multimedia interactivo, entorno colaborativo, etc.) y las restricciones que se deben cumplir a lo largo del proceso.

La aplicación de las técnicas clásicas de planificación usadas en Inteligencia Artificial (Barr and Feigenbaum E.A., 1982d) a los STI es una tarea complicada debido a varios factores:

Inexactitud del modelo del alumno. Normalmente los planes se aplican a un entorno (real o simulado) cuyos cambios de estado son observables. Sin embargo, en un STI un plan se emplea para cambiar el conocimiento de un alumno acerca de una materia. Este proceso de cambio es interno al sujeto que recibe la instrucción y no puede ser directamente observado ni medido, tan sólo es posible establecer una estimación sometiendo al alumno a algún método de evaluación y, aún así, la información que se maneja en el modelo del alumno puede ser inexacta.

Incertidumbre del efecto de las acciones del plan sobre el alumno. En muchos campos en los que se aplican técnicas de planificación (p.ej. robótica) el resultado de la ejecución de un plan es totalmente predecible si se cumplen una serie de condiciones, no ocurre lo mismo en el terreno de la educación, dónde las acciones pueden tener efectos indeterminados debido

Capítulo 2

a causas externas que escapan al control del sistema (no haber entendido la explicación del profesor, distracción, conocimientos erróneos previos sobre el tema, etc.).

El alumno es un agente inteligente. Esto puede provocar cambios de estados inesperados que no obedecen a ningún paso del plan debidos a procesos internos del alumno o a estímulos externos no controlables por el sistema y que pueden invalidar el plan en algún punto de su ejecución.

El objetivo de la instrucción en un STI puede ser alcanzado, además de planificando las actividades de la instrucción, reconociendo las oportunidades para intervenir en la sesión (ofreciendo alguna ayuda, pista, consejo, etc.) (Wenger, 1987a). Este tipo de monitorización se conoce como control oportunista o de oportunidad (opportunistic control) y es usada en entornos de simulación que entrenan en el manejo de algún sistema o en STI que guían al alumno en la resolución de problemas como WEST o GUIDON, cuyo módulo pedagógico contiene reglas que deciden cuando intervenir en la sesión de instrucción.

Wenger destaca el hecho de que los profesores humanos intercalan la planificación con el control oportunista, por lo que el módulo pedagógico de un STI deberá definir, además de una estrategia de planificación global que secuencie el currículo y el material, una estrategia local que decida cuando interrumpir a un alumno mientras realiza su tarea (Woo, 1991). Siguiendo con el ejemplo de GUIDON, entre las reglas de instrucción (t-rules) de su módulo pedagógico se encuentran, además de las ya mencionadas, reglas para seleccionar el material que va a ser presentado y decidir el modo de presentación.

En la planificación de la instrucción se ha de tener en cuenta el hecho de que el estado cognitivo del alumno cambia a lo largo de la instrucción, por lo que la planificación debe ser dinámica, es decir, debe intercalarse la planificación y la ejecución de acciones. Tras la conclusión de cada acción planificada para el alumno, el planificador deberá decidir, teniendo en cuenta las modificaciones en el modelo del alumno, la siguiente tarea.

En (Peachey and McCalla, 1986) se describe una técnica de planificación dinámica que consiste en generar un plan inicial construido a partir de un objetivo y la definición de unos operadores de enseñanza, por ejemplo TEACH-X. Para cada operador se ha definido una lista de precondiciones y se han especificado los efectos esperados del operador por medio de una lista de expresiones lógicas que deben ser añadidas o eliminadas del modelo del alumno tras la ejecución de dicho operador, por ejemplo SK(X) (Student Knows topic X) o ¬SK(X). Cada paso del plan está formado por un concepto del dominio y un operador que indica qué acción realizar. El módulo encargado de ejecutar el plan (Executor) observa después de cada acción si existe alguna diferencia entre el resultado esperado y el obtenido. En caso afirmativo se vuelve a invocar al generador de planes (Planner) que modificará el plan adaptándose a la nueva situación. El plan se representa como un gráfico acíclico

22


23

dirigido cuyos arcos definen un orden parcial irreflexivo entre los nodos. Los nodos son instancias de operadores y expresiones lógicas que se esperan alcanzar ejecutando los operadores. Los planes se generan a partir del objetivo, buscando un operador que tenga como resultado esperado dicho objetivo. Si las precondiciones de dicha acción no se cumplen se toman como nuevos objetivos de aprendizaje y se procede del mismo modo.

Otro ejemplo interesante de planificación dinámica es el trabajo realizado por Murray (Murray, 1989; Wasson, 1990) que presenta un planificador dinámico que puede generar, monitorizar y revisar acciones pedagógicas a lo largo de una sesión de instrucción. Este modelo está basado en la arquitectura de control de pizarra BB1 de Hayes-Roth (1983) (Macmillan et al., 1988). La arquitectura de control BB1 permite a una aplicación usar un método de razonamiento uniforme (basado en el disparo de eventos y el control oportunista de las operaciones de razonamiento) para construir y modificar planes para su propio comportamiento en tiempo de ejecución. El funcionamiento de este modelo se basa en tres principios básicos: a) todos los elementos generados durante la ejecución se almacenan en una estructura global llamada pizarra; b) los elementos que son solución de un problema son almacenados en la pizarra por procesos independientes llamados fuentes de conocimiento y c) en cada ciclo de realización de una tarea un mecanismo de planificación elige una única fuente de conocimiento para ser ejecutada (estructura de control).

En el sistema de Murray la pizarra contiene el modelo del alumno (su historial y un modelo de superposición del currículo). Las fuentes de conocimiento representan acciones de instrucción (cuya ejecución afecta al alumno) y acciones de control de la instrucción (planes de instrucción). Cada paso del plan está formado por un verbo y un sustantivo que especifican la acción a realizar y la categoría a la que se aplica. Murray define una taxonomía de verbos (TEACH, PLAN, ACT,PRESENT, SIMULATE, RESPOND, ASESS, etc.) y un conjunto de categorías (TOPIC, CASE, FAULT, STRATEGY, TUTORIAL, etc.). Cuando un evento activa una fuente de conocimiento se almacenan en una estructura llamada agenda las acciones de dicha fuente y el contexto de ejecución.

Murray define cuatro tipos de planes de instrucción: estrategias del objetivo de la lección que controlan la elección y secuenciación de temas; estrategias de presentación que presentan el tema seleccionado; estrategias de discurso que regulan las reacciones del planificador ante reacciones inesperadas y meta-planes de lección que se encargan de elegir entre las distintas estrategias posibles. El plan se genera en dos niveles de refinamiento: primero se selecciona el tema que se va a enseñar (mediante heurísticos) y después se elige una estrategia de presentación basándose en preferencias.

Un enfoque más teórico y que se aparta un poco de los usados habitualmente en la construcción de STI es el ofrecido por (Matsuda and VanLehn, 2000) dónde se considera la planificación de la instrucción como un problema de planificación bajo incertidumbre modelado como un proceso de

Capítulo 2

decisión de Markov en el que un estado viene dado por un estado de conocimiento del alumno, una reacción esperada del alumno e información proveniente de las acciones llevadas a cabo; las acciones son las interacciones de los alumnos con el sistema y los eventos son acciones inesperadas que pueden provocar una transición de estado. Las incertidumbres asociadas al problema (debilidad sensorial, salida incierta y evento inesperado) son formalizadas representando el efecto de una instrucción como una distribución de probabilidades sobre los estados sucesores y calculando la acción óptima como un máximo de la utilidad esperada de los estados. Una vez definidos todos los estados se crea una tabla que representa la acción óptima desde cada estado. En el proceso de instrucción el planificador selecciona la acción óptima, la ejecuta y compara la respuesta del alumno con la esperada, determinando así el nuevo estado del alumno.

Además de las técnicas de planificación comentadas en este apartado y otras descritas en la literatura sobre este tema (véase (Stern and Woolf, 1998; Wasson, 1990; Woo, 1991; Zhou et al., 1996)) se ha considerado de interés concluir la revisión sobre la planificación en la instrucción con el análisis del tratamiento que, sobre este particular, realizan las arquitecturas de STI descritas en el apartado 2.3.

El módulo pedagógico de un sistema es el encargado de maximizar su rendimiento desde el punto de vista didáctico, aplicando las teorías de la instrucción y las estrategias de enseñanza más adecuada para cada alumno, orientadas a obtener un proceso de aprendizaje óptimo. El diseño de la instrucción no es una ciencia exacta, no existe unanimidad entre los investigadores en este campo acerca de cuál es la mejor forma de enseñar a un tipo de alumno concreto en una situación determinada. Son muchos los parámetros que influyen en el proceso de aprendizaje y existe una gran dificultad para establecer criterios claros para medir la eficacia de los procesos de aprendizajes. Todo esto se refleja en la diversidad de técnicas y criterios de planificación que se han utilizado en los STI. Al analizar algunos STI desarrollados a lo largo de las dos últimas décadas destaca el hecho de que la mayoría de ellos están basados en heurísticos y reglas extraídas de la experiencia de tutores humanos. Algunos realizan la planificación basándose en las relaciones de secuenciación (prerrequisito, tema, subtema, etc.) que los profesores establecen entre los conceptos del dominio, lo que podría considerarse también como “experiencia humana” aunque no explícitamente representada en acciones concretas.

Algunos sistemas como WEST, GUIDON e IDE basan sus técnicas de planificación en principios pedagógicos reflejados implícitamente en sus reglas o representados de forma explícita como en el caso de IDE.

El análisis de estos sistemas pone de manifiesto el hecho de que la mayoría combinan el control de oportunidad con la planificación. Algunos como SCHOLAR, WEST, WUSOR o GUIDON tienen como estrategia global el control de oportunidad, es decir, mientras el alumno interactúa con el sistema, el módulo pedagógico se encarga de decidir cuando realizar una intervención

24


25

didáctica. Una vez que se ha decidido intervenir se aplican reglas de planificación para establecer el foco de la instrucción. Por el contrario, cuando el control de oportunidad se aplica de forma local, el sistema primero decide el foco de instrucción y luego puede encomendar al alumno alguna tarea en la que éste deba ser monitorizado (ejercicio, juego, etc.) y el sistema pueda intervenir ocasionalmente para corregirlo, darle algún consejo, etc.

Como se comentó al principio de este apartado, Halff divide el proceso de planificación en dos tareas: currículo e instrucción, pero algunos STI establecen un número mayor de niveles dentro del proceso de planificación. Así en IRIS se organiza el Plan Instruccional en seis niveles donde los cinco primeros corresponden al nivel de decisión pedagógica del tutor y el último (nivel ejecutivo) se corresponde con las acciones del tutor directamente ejecutables. EON, por ejemplo, establece cinco niveles de decisión: Lesson, Topic, Topic Level, Presentation y Events.

En la Tabla 4 se han representado las características más destacables de los planificadores de instrucción que incluyen las arquitecturas de STI estudiadas en este capítulo.

PLANIFICACIÓN

CO

NTR

OL

DE

OPO

RTU

NID

AD

CO

MO

ES

TRA

TEG

IA G

LOBA

L

PLA

NES

CO

N V

AR

IOS

NIV

ELES

DE

REF

INA

MIE

NTO

REG

LAS

BASA

DA

S EN

LA

EX

PER

IEN

CIA

DE

TUTO

RES

HU

MA

NO

S

REG

LAS

BASA

DA

S EN

PR

INC

IPIO

S PE

DA

GÓ

GIC

OS

BASA

DA

EN

LA

S

REL

AC

ION

ES D

E LA

RED

SE

MÁ

NTI

CA

DEL

D

OM

INIO

BASA

DA

EN

EL

DIÁ

LOG

O

IND

EPEN

DIE

NTE

DEL

D

OM

INIO

PREE

STA

BLEC

IDA

PO

R E

L A

UTO

R D

EL S

ISTE

MA

SCHOLAR X X X X

WHY X X X

SOPHIE X

WEST X X X X

WUSOR X X

GUIDON X X X X X

BUGGY

IDE X X X X X

IRIS X X X

REEDEM X X X

RIDES X

EON X X

Tabla 4 Características de los planificadores de instrucción de algunos STI.

Capítulo 2

2.2.4 Módulo de comunicación o entono

Este módulo es el encargado de la interacción del tutor con el alumno. A través de él el tutor transmite órdenes, sugerencias, respuestas a preguntas, etc. al alumno y éste realiza las tareas encomendadas por el tutor, realiza preguntas, etc.

Burton (Burton, 1988) realiza un interesante estudio acerca de las cuestiones más importantes a tener en cuenta en el diseño del entorno: 1) qué es lo que se quiere enseñar, 2) nivel de abstracción en la representación del conocimiento, 3) fidelidad de la representación (física, visual, de comportamiento y conceptual), 4) orden de presentación de los contenidos, 5) herramientas de ayuda proporcionadas por el entorno y 6) nivel de control ejercido por la herramienta.

La investigación en este aspecto de la arquitectura de los STI está marcada por los avances en áreas como el procesamiento de lenguaje natural en IA, y el potencial que ofrecen tecnologías hipermedia y multimedia. Existen cada vez más ejemplos de sistemas educativos que se desarrollan para Internet (ver capítulo 3), adaptando el estilo de comunicación con el alumno a las posibilidades que ofrece este medio.

2.3 Revisión de arquitecturas de Sistemas Tutores Inteligentes

En esta sección se revisan algunos de los Sistemas Tutores Inteligentes más representativos. En primer lugar se presentan los sistemas desarrollados durante los primeros años de investigación en el campo de los STI, la década de los 70. Todos estos sistemas han sido pioneros en el estudio y aplicación de distintas técnicas de la Inteligencia Artificial a la educación como el aprendizaje basado en el diálogo (SCHOLAR, WHY), en modelos causales (SOPHIE), modelos de procedimientos incorrectos (bugs), estrategias de intervención (WEST, WUSOR) o sistemas de diagnóstico (GUIDON).

El siguiente avance cualitativo viene dado por el intento de desarrollo de arquitecturas genéricas y herramientas de autor para la construcción de sistemas tutores (IDE, IRIS, REEDEM, RIDES, EON).

Se intenta ofrecer una visión de estos sistemas desde el punto de vista la arquitectura clásica de los STI, para lo cual se describen brevemente la representación del dominio, el modelo del alumno, el módulo pedagógico y el entorno de cada sistema.

2.3.1 SCHOLAR

SCHOLAR (Barr and Feigenbaum E.A., 1982b; Carbonell, 1970; Wenger, 1987f) es el primer sistema instructor que empleó técnicas de IA. Es un sistema basado en el diálogo en el que tanto el tutor como el alumno pueden tomar la iniciativa de la conversación y hacer preguntas. El dominio de enseñanza es la geografía sudamericana aunque tanto el esquema de representación del dominio como las estrategias de enseñanza usadas en el sistema son aplicables a otros dominios. Modelo del dominio.

26


27

El conocimiento del dominio en SCHOLAR se representa en una red semántica donde cada nodo representa un concepto con un nombre y un conjunto de atributos asociado. Los arcos son relaciones específicas del dominio tales como superconcepto (ej. Perú es un país), superatributo (ej. fértil se refiere a la tierra) y superparte (ej. Perú es parte de Sudamérica). Cada atributo tiene un valor que representa su importancia y que será usado por el sistema para medir la importancia de un nodo con respecto al foco de la instrucción. Modelo del alumno

Se emplea un modelo de superposición. Carbonell usa el modelo del dominio completo para representar al estudiante perfecto y progresivamente va eliminando y modificando nodos y enlaces para reflejar el estado actual de conocimiento del alumno. Módulo pedagógico

SCHOLAR basa su estrategia de enseñanza en el diálogo. El profesor intenta detectar mediante preguntas las lagunas de conocimiento del alumno para a continuación centrar la conversación en el/los conceptos problemáticos intentando que sea el alumno el que se dé cuenta de sus propios errores.

Las estrategias de instrucción utilizadas para conseguir su objetivo están basadas en la selección de nodos de la red. Ante una pregunta o respuesta del alumno SCHOLAR debe determinar qué nodos son relevantes en ese contexto ya sea para responderle o para evaluar su respuesta y actualizar el modelo del alumno. Con este fin el sistema debe realizar algunas inferencias en la red de conocimientos. Algunas de las estrategias usadas son:

búsqueda de la intersección, para responder a preguntas de la forma “¿Puede X estar en Y?” o “¿Está X en Y?” se busca un concepto común a X e Y siguiendo la relación superparte hasta encontrar una intersección, si coincide con Y las respuesta es “Sí”, si coincide con X la respuesta es “No”;

superordenada común, en el caso anterior si el nodo común no es ni X ni Y, se examinan los hijos, si son nodos contradictorios la respuesta es “No”, si no, es “No lo sé”. Para responder a la pregunta “¿Es X un Y?”, se sigue el mismo proceso usando la relación superconcepto;

conjuntos cerrados y abiertos, los conjuntos resultantes de buscar todos los nodos que satisfacen una condición, por ejemplo: “¿Cuántas X están en Y?”, son etiquetados como abiertos (si no contienen todos los ítem que se buscan) o cerrados (en caso contrario). Las preguntas sobre conjuntos abiertos necesitan un tratamiento especial;

distancia entre nodos, cuando el alumno dice “Dime algo sobre X”, para buscar los nodos relevantes en ese contexto, se determina la importancia de unos nodos con respecto a otros usando el valor de importancia asociado a los atributos de cada nodo.

Un dato a destacar es que estas estrategias de inferencia son independientes del dominio y manejan conocimiento incompleto empleando un modo de razonamiento que intenta simular al humano.

Capítulo 2

Módulo de comunicaciones Como ya se ha mencionado, una parte importante de SCHOLAR son los

diálogos. El procesamiento de lenguaje natural en SCHOLAR está basado en un sistema de gramática de casos. El lenguaje es un subconjunto restringido del inglés, limitado a sentencias simples. El texto es generado usando plantillas de frases y preguntas que se rellenan con datos obtenidos de la red semántica. El análisis de las preguntas del alumno se hace igual pero en sentido inverso mientras que el análisis de las respuestas se hace mediante búsqueda de patrones de palabras clave en una lista generada dinámicamente a partir de la red semántica y la pregunta.

El alumno puede elegir entre tres modos diferentes de control del diálogo: sólo responder preguntas, sólo hacer preguntas o un modo mixto.

Debido a que SCHOLAR no planea un conjunto de preguntas para alcanzar un objetivo, la continuidad en los diálogos es débil.

2.3.2 WHY

El sistema WHY (Barr and Feigenbaum E.A., 1982b; Stevens and Collins, 1977; Wenger, 1987f) continúa la línea de investigación de SCHOLAR centrándose sobre todo en el estudio del método Socrático para enseñar a razonar a través de diálogos. Los trabajos de Stevens y Collins se centraron en la identificación de las reglas del método socrático y en su aplicación a un sistema de enseñanza automático. Para este propósito los dominios declarativos no parecían los más adecuados (sólo tienen hechos), era necesario un dominio donde las relaciones causales y temporales entre los conceptos fueran importantes, por lo que se eligió el proceso geofísico de la lluvia. WHY enseña a sus alumnos a determinar las causas de la lluvia. Modelo del dominio.

El conocimiento sobre la lluvia se modela en guiones (scripts) que representan estereotipos de secuencias de eventos, por ejemplo: “El agua primero se evapora de un océano o mar, luego la masa de aire es llevada sobre la tierra por el viento, por lo que el aire se enfría, [...]”. Esta representación captura las relaciones causales y temporales entre eventos. Existe una jerarquía de guiones que comienza con una descripción general de un proceso y se desgrana en descripciones más detalladas.

El modelo del dominio evolucionó desde la presentación del sistema WHY hacia una perspectiva funcional, en la que los elementos implicados en un proceso son vistos como actores, describiendo el papel que juegan en dicho proceso. Los actores tienen asociados atributos o factores que indican el alcance de la función del actor dentro del proceso. Además, se definen relaciones funcionales entre factores que explican los resultados de los procesos. De esta forma se representan diferentes puntos de vista del mismo proceso. Modelo del alumno

28


29

WHY no construye un modelo del alumno global, su capacidad de diagnóstico está limitada a evaluaciones independientes de respuestas del alumno. Módulo pedagógico

Collins centró parte de su investigación en el análisis de diálogos reales y en la recopilación de un conjunto de reglas o heurísticos para controlar la interacción del estudiante y el sistema. El antecedente de las reglas viene dado por la comparación de la última respuesta del alumno y el conocimiento del experto y el consecuente es la siguiente acción que el tutor debería realizar, por ejemplo:

SI el alumno da como explicación de una dependencia causal uno o más factores innecesarios

ENTONCES seleccionar un contraejemplo con el valor erróneo del factor y preguntar al alumno por qué la dependencia causal que él estableció no se cumple en este caso

Un ejemplo de aplicación sería que el alumno diera la lluvia como una causa del crecimiento del arroz, a lo que el sistema respondería: “¿Por qué crece arroz en Egipto si allí no llueve mucho?”. En 1977 el sistema WHY contaba con un conjunto de veinticuatro reglas que llegaron a ser sesenta en 1982. Estas reglas se pueden extrapolar a cualquier dominio sobre el que el alumno deba adquirir habilidades de razonamiento causal.

Aunque sólo desde una perspectiva teórica, Stevens y Collins analizaron, además de las reglas mencionadas, los objetivos a largo plazo o globales que observaron en tutores humanos, como por ejemplo “Aclarar un error antes de pasar a otro”, que representan las motivaciones para el uso de una regla concreta. Módulo de comunicaciones

Al igual que SCHOLAR, WHY se comunica con el alumno a través de un diálogo en inglés. El sistema le plantea al alumno una pregunta y, aplicando las reglas del módulo pedagógico, a través de sus respuestas el sistema le va planteando sucesivas preguntas que le hagan reflexionar sobre las causas de la lluvia.

2.3.3 SOPHIE

SOPHIE (SOPHisticated Intructional Environment) (Barr and Feigenbaum E.A., 1982b; Brown et al., 1975; Wenger, 1987e)es un STI cuyo objetivo es enseñar a un alumno a encontrar averías en un circuito electrónico. El sistema proporciona un diagrama del circuito y establece un diálogo en el que el alumno puede realizar medidas y proponer hipótesis acerca de la localización del fallo. Cuando el alumno propone una posible causa del fallo el sistema se asegura, haciéndole preguntas, de que la suposición es correcta. Modelo del dominio

Capítulo 2

SOPHIE incluye en el sistema tres tipos diferentes de representación del dominio de averías en circuitos electrónicos: a) basada en simulación, con un modelo matemático del circuito; b) procedimental, con expertos de caja negra que usan el modelo y simulan el comportamiento del circuito y c) declarativo, con una red semántica de hechos. Modelo del alumno

SOPHIE no realiza ninguna estrategia pedagógica para intentar detectar carencias en el conocimiento del alumno acerca del dominio y poner remedio por lo que no tiene modelo del alumno. Módulo pedagógico

Las tareas pedagógicas que realiza el sistema son:

responder a preguntas hipotéticas del tipo “¿qué pasaría si...?”;

evaluar hipótesis, el sistema no evalúa si la hipótesis es correcta o no solamente comprueba si la afirmación es consistente con las medidas tomadas por el alumno en el circuito. Para ello el sistema clasifica las medidas como contradictorias, secundarias o independientes de la hipótesis actual;

generar todas las posibles hipótesis consistentes con las medidas basándose en heurísticos;

evaluar la redundancia de las medidas propuestas por el alumno, para lo que el sistema genera todas las hipótesis consistentes con la nueva medida y sin ella, si los dos conjuntos son diferentes la nueva medida no es redundante.

Todas estas tareas de razonamiento están basadas en el uso de un simulador del circuito para realizar inferencias. Esto tiene inconvenientes desde el punto de vista didáctico debido a la falta de representación explícita de los procesos causales subyacentes en las inferencias realizadas que impide al sistema dar explicaciones a los estudiantes sobre qué es lo que está pasando o porqué se ha llegado a una determinada conclusión. Módulo de comunicaciones

Una de las principales contribuciones de SOPHIE es su tratamiento del lenguaje natural. El sistema utiliza las gramáticas semánticas que clasifican las palabras en categorías semánticas propias del dominio (conceptos conocidos por el sistema) en vez de en categorías sintácticas (nombre, verbo, etc.). Esto tiene la desventaja de que el dominio debe ser limitado y estar bien definido pero como contrapartida las expresiones se ajustan más al dominio (no a un idioma en general) y el analizador es capaz de reconocer términos extraños o la ausencia de palabras o frases. Además, si no se reconoce una palabra se puede obviar e intentar encontrar sentido al resto de la frase, aunque para evitar interpretaciones erróneas de preguntas el sistema contesta con frases completas que indican qué es lo que ha entendido.

30


31

2.3.4 WEST

WEST (Barr and Feigenbaum E.A., 1982b; Burton and Brown, 1979; Wenger, 1987d) es un entorno de entrenamiento para el desarrollo de habilidades aritméticas simples. El sistema viene presentado como un juego en el que dos alumnos realizan una carrera para alcanzar una ciudad en el menor número de tiradas posible. Para ello, en cada turno el sistema genera tres números aleatorios, el jugador debe componer una expresión aritmética que implique dos operadores diferentes y cuyo resultado indicará el número de casillas que puede avanzar. No siempre la mejor tirada es el mayor número, existen atajos y premios que pueden hacer que se avance un número de casillas mayor. Además, si un jugador cae en la casilla donde está su oponente, éste debe retroceder dos posiciones. Modelo del dominio.

El sistema combina un experto de caja negra y un modelo declarativo formado por un conjunto de temas que representan habilidades matemáticas básicas, habilidades necesarias para jugar a WEST y habilidades generales sobre el juego. Asociados a los conceptos se almacenan un conjunto de explicaciones (speakers) usadas por el módulo pedagógico en sus intervenciones.

En un instante determinado del juego el experto se encarga de generar posibles movimientos. Con el fin de optimizar la ordenación de estos movimientos (de mejor a peor) el experto emplea por defecto la estrategia de juego de maximizar la distancia delante del oponente. El alumno podría estar usando otra estrategia debería ser adoptada por el sistema si fuese válida. En el modelo del dominio se incluyen varios temas o conceptos que representan estrategias de juego (Max Delta, Max Dist, Max Number, Specials, Other). En WEST es posible considerar un conjunto concreto de estrategias porque su dominio es limitado y es fácil identificar todas las posibles estrategias de juego que un alumno podría seguir.

Esta combinación de experto de caja negra y representación explícita del conocimiento del dominio permite analizar lo que hace el experto y proporcionar explicaciones que los justifiquen. Modelo del alumno

El modelo del alumno es un modelo diferencial. Cuando el alumno hace una tirada el sistema genera una lista de posibles movimientos. Si el movimiento del alumno no coincide con el considerado óptimo por el experto, comienza el proceso de diagnóstico. Este proceso es realizado por el reconocedor y el evaluador. El reconocedor analiza el comportamiento del alumno para averiguar qué habilidades ha puesto en evidencia o cuáles no ha usado (comparándolo con las acciones del experto) y construye el modelo del alumno. El evaluador interpreta el modelo para determinar las debilidades del alumno.

Existen algunas fuentes que pueden introducir ruido en el modelo:

Capítulo 2

si el alumno no hace un movimiento óptimo pueden ocurrir que haya varios conceptos del dominio que puedan ser la causa del error, en este caso la culpa se reparte entre todos;

el sistema no tiene en cuenta el proceso completo que una persona realiza hasta generar un movimiento así que el conjunto de conceptos que se derivan de él es incompleto;

la otra fuente de ruido es inherente al proceso de aprendizaje. Mientras va jugando el alumno va aprendiendo pero esos cambios no se reflejan en el modelo del alumno (alto coste computacional). Para evitarlo WEST elimina del modelo los conceptos o temas que el alumno ha usado en los últimos tres movimientos asumiendo que los sabe.

Módulo pedagógico WEST utiliza una teoría de entrenamiento llamada Temas y Ejemplos (Issues

and Examples) cuyo objetivo básico es conseguir que las intervenciones del tutor sean significativas y útiles. El proceso de entrenamiento es el siguiente:

1. se analiza el movimiento del alumno para ver qué conceptos intervienen en el movimiento;

2. a continuación se analizan todos aquellos movimientos generados por el experto que son mejores que el del alumno y se crea una lista de conceptos débiles (el alumno falló al aplicarlos);

3. se evalúa el modelo diferencial para buscar en cuales de los anteriores conceptos se sabe que el alumno falla;

4. por último, si el tutor decide intervenir, de entre ellos se selecciona un concepto y un movimiento que lo ilustre. Para llevar a cabo esta elección se pueden aplicar diferentes principios de enseñanza:

- Focus strategy: se escoge el concepto visitado más recientemente. Esta estrategia se basa en insistir sobre un concepto hasta que el alumno lo aprenda.

- Breath strategy: se tiende a elegir los conceptos no discutidos recientemente. Esta estrategia minimiza el aburrimiento y asegura una buena cobertura de los conceptos.

- Conceptos ordenados según el currículo Uno de los puntos más importantes de este módulo pedagógico es

precisamente decidir si intervenir o no en una determinada situación. El tutor no debe ser demasiado “pesado” porque podría provocar que el alumno se desanimara y abandonara el juego. Burton y Brown plantearon una serie de principios generales aplicables en un entorno de aprendizaje:

antes de intervenir asegurarse de que el alumno no se sabe el concepto;

si el alumno está a punto de perder, interrumpirlo sólo con movimientos que eviten que pierda;

no intervenir en dos movimientos consecutivos;

32


33

el experto siempre debe jugar la mejor partida posible;

cuando se muestra un concepto erróneo, ilustrar con un ejemplo sólo cuando el resultado es mucho mejor que el del alumno;

si el alumno hace un movimiento muy bueno, felicitarlo;

si el alumno pide ayuda, proporcionar diferentes niveles de ayuda.

Estos principios no están explícitamente representados en WEST sino que están embebidos en el módulo pedagógico Módulo de comunicaciones

El experto en WEST no tiene ningún control sobre el entorno, aunque sería deseable en este tipo de sistemas de entrenamiento que el tutor tuviese poder para modificar el entorno con el fin de crear condiciones óptimas de aprendizaje. Fischer, Burton y Brown propusieron un paradigma para el diseño de entornos óptimos de aprendizaje: micromundos cada vez más complejos. La idea es comenzar con un entorno simplificado e ir añadiéndole elementos más complejos conforme avance el proceso de aprendizaje.

2.3.5 WUSOR

WUSOR (Barr and Feigenbaum E.A., 1982b; Carr and Goldstein, 1977; Wenger, 1987d) es un sistema para enseñar a jugar a WUMPUS, un juego en el que hay que atrapar y matar al malvado Wumpus que se esconde en una cueva dentro de un laberinto. El sistema enfrenta al jugador a diversas dificultades que debe ir superando. El juego se pierde si se cae en un foso, se entra caminando en la guarida de Wumpus o se dispara todas las flechas disponibles sin dar en la diana. El jugador debe poner en práctica conocimientos y habilidades sobre lógica, probabilidad, teoría de la decisión y geometría. Modelo del dominio.

El modelo del dominio es el conjunto de reglas que el experto necesita para jugar. Existen veinte reglas cuyo fin es inferir el riesgo que se corre al visitar una nueva cueva. Algunos ejemplos de estas reglas son:

Regla de la evidencia positiva, cuando estamos en una cueva, una advertencia acerca de peligros en las cavernas vecinas indica que existe un peligro en alguna cueva vecina.

Regla de la evidencia negativa, la ausencia de una advertencia implica que no existe peligro en los vecinos.

Regla de eliminación, si estando en una cueva el sistema advierte de un peligro en los vecinos y se sabe que todos menos uno de los vecinos son seguros el peligro está en la que queda.

El experto (Expert) analiza todos los movimientos posibles y presenta los mejores con una lista asociada a cada uno que contienen las habilidades necesarias para llevarlo a cabo. Modelo del alumno

Capítulo 2

Es un modelo de superposición en el que se representa la creencia que tiene el sistema de que el alumno sabe aplicar o no las reglas del modelo del dominio. Para ello, entre otros datos, se almacena el porcentaje de veces que cada regla ha sido usada correctamente. El modelo del alumno es un indicativo del nivel de juego que puede esperarse de un alumno (principiante, novato, amateur,...).

El módulo de diagnóstico (Psychologist) aplica un conjunto de reglas de evidencia para hacer hipótesis acerca de lo que sabe el alumno:

si el alumno manifiesta explícitamente conocimiento o desconocimiento de una habilidad, incrementa o disminuye respectivamente la creencia acerca de que el alumno posea dicha habilidad;

si el comportamiento del alumno pone de manifiesto de forma implícita una habilidad incrementa la creencia acerca de que la posee. Del mismo modo, si el alumno no la manifiesta en una situación en la que el experto cree que hubiese sido apropiada, disminuye dicha creencia;

si hace mucho tiempo que el alumno manifestó una habilidad y no se ha vuelto a obtener confirmación de la misma, disminuye la creencia acerca de ella.

Módulo pedagógico WUSOR no sigue ninguna estrategia de enseñanza que regule cuando debe

intervenir. El tutor interviene cada vez que el alumno no ha elegido el movimiento óptimo de acuerdo con la clasificación del experto.

Las reglas del modelo del dominio clasifican los posibles movimientos en diferentes categorías. Asociadas a cada categoría y a cada regla hay un conjunto de explicaciones que serán presentadas al alumno. El módulo pedagógico (Tutor) usa reglas de explicación para seleccionar el concepto apropiado para enseñar al jugador y elegir la forma de la explicación:

Reglas de simplificación, que cogen una frase compleja y la reducen a una simple. Estas reglas son fundamentales para que el alumno no sea abrumado por las explicaciones del tutor.

Reglas de retórica, que codifican estrategias de explicación alternativas. Los dos extremos son explicaciones en términos de una regla general y explicaciones en términos de una instancia concreta.

Módulo de comunicaciones El tutor se comunica con el alumno a través de un diálogo en el que el que

las intervenciones del alumno sólo son para indicar el siguiente movimiento y las del profesor para ofrecer explicaciones cuando el alumno hace un movimiento erróneo.

Se realizaron esfuerzos para ofrecer una interfaz visual que el alumno pudiese usar para recordar toda la información que se le va suministrando a lo largo de la partida (advertencias acerca de peligros próximos, explicaciones, movimientos anteriores, etc.)

34


35

2.3.6 GUIDON

GUIDON (Barr and Feigenbaum E.A., 1982b; Clancey, 1979; Wenger, 1987c)es un STI para enseñar a resolver problemas de diagnóstico de enfermedades infecciosas basado en el sistema MYCIN (Barr and Feigenbaum E.A., 1982c). GUIDON establece con el alumno un diálogo sobre un paciente que tiene una infección, mostrándole los datos clínicos y del laboratorio más relevantes y enseñándole como usarlos para diagnosticar el organismo causante de la infección.

Los objetivos que persigue GUIDON son: evaluar la utilidad pedagógica de la base de conocimientos de MYCIN, descubrir el conocimiento adicional que necesitaría un sistema tutor, e intentar definir estrategias de enseñanza independientes del dominio. Modelo del dominio.

Está compuesto por:

La base de conocimiento de MYCIN que contiene un conjunto de reglas para el diagnóstico de enfermedades infecciosas.

Unos 100 casos reales de pacientes.

Extracto de casos (case syllabus): contiene información acerca de la importancia relativa de los temas o conceptos y sirve para determinar los futuros temas que deben ser cubiertos.

Modelo del alumno Es un modelo de superposición en el que el conocimiento del alumno se

representa como un subconjunto de la base de conocimientos de MYCIN. Tiene tres componentes:

USE-HISTORY: registro acumulativo de las reglas que el alumno conoce. Se almacena un factor de certeza acerca del conocimiento que el alumno tiene de cada regla. Se inicializa usando el nivel de experiencia que el alumno dice antes de comenzar que posee. Cada regla está etiquetada con un nivel de dificultad.

STUDENT-APPLIED: guarda la creencia que tiene el programa acerca de que el estudiante es capaz de aplicar la regla al caso dado. Existe una diferencia entre conocer una regla y saber aplicarla.

USED?: almacena la creencia que tiene el programa acerca de que el alumno podría mencionar una regla si se le pidiera que respaldara (o argumentara) una solución parcial.

Módulo pedagógico La estrategia de presentación pedagógica seguida por GUIDON es el

método de casos, que consiste en mantener un diálogo con el alumno de iniciativa mixta basado en casos específicos y cuyo objetivo es transmitir a los alumnos las reglas de MYCIN en un contexto realista de resolución de problemas. Este método tiene algunas características del método socrático y otras del método de temas y ejemplos (issues and examples). GUIDON intenta guiar el razonamiento

Capítulo 2

del alumno (método socrático) y usa las 450 reglas de MYCIN como temas que se presentan por medio de ejemplos concretos relativos al caso de estudio. Las reglas de MYCIN no son suficiente para los propósitos pedagógicos por lo que cada regla tiene asociadas unas anotaciones que son trozos de texto justificando inferencias o que hacen referencia a publicaciones médicas.

El módulo pedagógico de GUIDON está formado por unas 200 reglas de enseñanza (t-rules o tutorial-rules) que incluyen métodos para: guiar el diálogo, construir el modelo del alumno, responder a las iniciativas del alumno, determinar cuando intervenir, seleccionar el material para presentar al alumno (reglas de diagnóstico de MYCIN) y presentarlo. Estas reglas son independientes del dominio por lo que nunca hacen ninguna referencia a un elemento concreto de MYCIN.

SI

- este objetivo no ha sido discutido y hay reglas que tienen relación con él,

- el número de reglas que tienen relación con este objetivo y ha tenido éxito es 1, y

- hay una fuerte evidencia de que el usuario ha aplicado esta regla ENTONCES enuncia la regla y su conclusión (procedureXXX)

SI

- el número de factores que aparecen en la regla del dominio que se necesita pedir al alumno es 0 y

- el número de sub-objetivos que queda por ser determinado antes de que la regla del dominio pueda ser aplicada es 1

ENTONCES

- di: “subgoal suggestion”

- discute el sub-objetivo con el alumno de forma orientada al objetivo (goal-directed mode) (procedure001)

- resume la discusión del dominio que está siendo considerada (procedure017)

Tabla 5 Ejemplos de t-rules de GUIDON

Las t-rules de GUIDON representan de forma implícita un estilo pedagógico guiado por los siguientes principios de instrucción:

Ser claro: seguir una estrategia de presentación económica, proporcionar transiciones lúcidas y ceñirse a patrones de discurso convencionales,

Proporcionar orientación a nuevas tareas por refinamiento de arriba a abajo (top-down): dar al alumno un esquema organizado de reflexiones que él debería hacer sin revelar la solución del problema y así desafiar al alumno a examinar su conocimiento de forma constructiva

Guiar el diálogo de forma estricta: decir cuando los temas se han acabado y cuando las inferencias se han completado.

No asumir métodos o estrategias alternativas: explicar claramente qué es impropio desde el punto de vista del tutor.

36


37

Cuando se está respondiendo a una solución parcial del alumno, probar su conocimiento si no se está seguro de lo que sabe. En otro caso directamente confirmar o corregir la solución.

Proporcionar ayuda de forma metódica introduciendo pequeños pasos que contribuyan a la solución del problema:

- la ayuda debería ser primero general para recordar al alumno métodos y soluciones que él ya conoce

- la ayuda debería animar al alumno a avanzar hacia la solución usando datos del caso que él ya conoce

- Examinar el conocimiento del alumno e introducir nueva información siempre que haya oportunidad de hacerlo.

Módulo de comunicaciones La comunicación entre GUIDON y el alumno está basada en el diálogo.

Cuando se propone un caso a un alumno, MYCIN elabora sus propios razonamientos que les son comunicados a GUIDON en forma de un árbol AND/OR con la traza completa de las inferencias realizadas y los objetivos cumplidos para cada regla. Este árbol es la base para guiar el diálogo.

Los diálogos en GUIDON siguen el siguiente esquema general:

GUIDON describe un caso.

El alumno hace preguntas para obtener más datos y formula hipótesis.

GUIDON interviene cuando el alumno pide ayuda o cuando sus hipótesis (comparadas con las de MYCIN) no son buenas.

Un aspecto fundamental de la gestión de diálogos de GUIDON es permitir al alumno que se exprese, por lo que debe existir previsión para cada tipo de iniciativa por parte del alumno (referirse a un tema ya hablado, cambiar de tema...). El sistema entiende frases cortas y opciones predefinidas (ayuda, detalles, justifica, resume,...).

GUIDON ofrece un menú de unas 30 opciones para petición de datos de casos, pedir la evaluación de MYCIN del problema, determinar el contexto del diálogo (qué regla se está discutiendo), cambiar de tema, pedir ayuda y transmitir lo que se sabe (plantear una hipótesis). Cada opción disponible tiene un procedimiento (discourse procedure) asociado que determinan la secuencia de acciones a realizar bajo condiciones determinadas por la complejidad del material, la comprensión del alumno del material y los objetivos de la sesión. Estos procedimientos son activados por las t-rules.

Las frases de salida son construidas a partir de un conjunto de frases primitivas almacenadas. GUIDON sigue el rastro del contexto global del diálogo en un conjunto de registros (focus record) para asegurar cierta continuidad.

Capítulo 2

2.3.7 BUGGY

La función de BUGGY (Barr and Feigenbaum E.A., 1982b; Brown and Burton, 1978; Wenger, 1987b) es identificar los errores conceptuales (bugs) de un alumno sobre habilidades aritméticas básicas. El sistema proporciona un mecanismo para explicar por qué un alumno está cometiendo un error aritmético. Modelo del dominio.

BUGGY representa las habilidades que debe adquirir un alumno como un conjunto de sub-habilidades. Cada una de ellas tiene un procedimiento asociado que simula el comportamiento correcto de una alumno. Los procedimientos se unen entre sí formando redes de procedimientos que representan una habilidad aritmética. Modelo del alumno

Está formado por una red de procedimientos que representan el comportamiento (correcto o incorrecto de un alumno). Los procedimientos defectuosos son el resultado de los errores sistemáticos cometidos por el alumno. El modelo se construye reemplazando los subprocedimientos correctos del modelo del dominio por sus variantes incorrectas.

Para el desarrollo de BUGGY se han identificado alrededor de 330 procedimientos incorrectos (bugs), cada uno con una descripción asociada. Módulo pedagógico

El objetivo de BUGGY no es la enseñanza de las habilidades aritméticas sino el diagnóstico de errores conceptuales del alumno, aunque el sistema incluye un módulo para enseñar a los profesores a analizar errores de los alumnos. Esta modalidad del sistema funciona instanciando un bug del modelo del alumno y pidiéndole al profesor que lo detecte. Módulo de comunicaciones

El entrenamiento de los profesores se realiza a través de un diálogo en el que BUGGY va presentando ejercicios incorrectos al profesor y este debe determinar qué tipo de error se ha cometido.

2.3.8 IDE

IDE (Russell, 1988; Russell et al., 1988) es un sistema de para ayudar a los diseñadores de instrucción en la tarea de diseño de cursos, estructuración de los contenidos y creación de secuencias de instrucción para la distribución del material.

La Tabla 6 tabla muestra las entradas y salidas de IDE. En el proceso que va desde la entrada a la salida el diseñador deberá tomar decisiones sobre:

el dominio del conocimiento que va a ser enseñado (epistemology),

cómo aprenderá el alumno la habilidad o conocimiento que se le presente. Es decir, como alcanzar los objetivos del curso dentro de las restricciones puestas por el diseñador y guiados por las decisiones epistemológicas (cognition) y,

38


39

cómo se va a enseñar el curso (presentation).

ENTRADAS SALIDAS

- Objetivos del curso - Restricciones externas (habilidades de los

alumnos, medios disponibles de distribución del material, cantidad de tiempo disponible, etc.)

- Principios (referencias a teorías de aprendizaje y la instrucción)

- Modelo del dominio (KS, Knowledge Structure)

- Modelo del alumno (MOS, Model Of Student)

- Control del curso (course control, estrategias pedagógicas y tácticas)

- Material del curso (IU, Instructional Units)

Tabla 6 Entradas y salidas de IDE

Modelo del dominio. Una KS es una estructura de conceptos que representa el contenido del

curso (conceptos, habilidades, errores conceptuales, errores en habilidades) y las relaciones entre ellos. El diseño del curso final enseñará algún subconjunto de este modelo.

Las relaciones más comunes son: subconcepto, subhabilidad, prerrequisito y error. Modelo del alumno

El MOS almacena el conocimiento del alumno sobre los conceptos, errores conceptuales típicos, estilos de aprendizaje más comunes, condiciones de instrucción, etc.

Para actualizar el MOS se analiza un registro de las interacciones entre el alumno (History List) y las IU: cómo se respondió a una pregunta, cómo se usó una simulación, etc. Módulo pedagógico

Está formado por lo que se da en llamar control del curso (course control) que guarda el conocimiento necesario para guiar la instrucción del contenido del curso. Se representa en forma de reglas (crean objetivos de instrucción) y restricciones (restringen el modo en el que esos objetivos pueden ser implementados) que describen como se realiza la instrucción. Existen tres tipos de reglas:

Pedagogy cards: codifican la secuenciación de temas y la información que se debe incluir en ellos.

Strategy cards: codifican las estrategias generales de instrucción. Ejemplos: “instruye y practica”, “presenta tres conceptos y después pon un test” o “monitoriza la solución de un alumno a un problema e intervén tan pronto como el alumno se salga del camino de la solución”.

Tactics cards: especifican la información a bajo nivel sobre el estilo y la forma de implementar la instrucción. Aclaran cómo implementar un objetivo de instrucción en un entorno particular y para un tipo concreto de estudiante.

El módulo pedagógico también cuenta con el área de principios (principles area) que es una librería de principios y técnicas de instrucción. El usuario

Capítulo 2

puede adaptarla a sus necesidades (añadir, borrar o reorganizar elementos). IDE puede analizar cursos creados por IDE y actualizar basándose en ellos el área de principios.

El intérprete de IDE (IDE Interpreter) usa las estructuras de conocimiento producidas por IDE (KS, reglas de instrucción e IU) para crear un plan de instrucción. Tiene cuatro módulos:

Instructional Problem Solver (IPS): crea el plan de instrucción. Usa las Strategy y Pedagogy cards para generar nuevos objetivos, crear la estructura del plan y modificarlo cuando haga falta. Las Pedagogy cards se usan para la selección y secuenciación de conceptos, mientras que las Strategy cards intervienen en la elección del enfoque y estilo de instrucción generales.

Instructional Units Selector: el IPS crea un objetivo de instrucción en cada ciclo, hay que elegir una IU relacionada con dicho objetivo, para lo que se usan las Tactical cards que seleccionan la IU que mejor implementa el objetivo.

Instructional Unit Applier: se encarga de presentar al alumno la IU seleccionada y de guardar todas las interacciones en un registro (History List).

MOS Update: módulo que actualiza el modelo del alumno y comunica al IPS los cambios devolviéndole el control.

Módulo de comunicaciones Las IU (Instructional Units) son las unidades con las que el alumno

interactuará (trozo de video, simulación, entorno de aprendizaje,...) y que se encargan de transmitir los conceptos del KS. Cada IU está formada por:

el contenido de la presentación,

los conceptos con los que está relacionado,

una lista de pares atributo/valor representando las propiedades de la IU (modo de presentación, nivel de detalle, nivel de dificultad,..)

las correspondencias de preguntas y respuestas en conceptos y errores.

El IDE Interpreter tiene un módulo que muestra la IU al alumno y almacena todas las interacciones del alumno y la UI en la base de datos History List.

2.3.9 IRIS

IRIS (Arruarte, 1998; Arruarte et al., 1997) es un entorno para la construcción de STI. A continuación se resume la arquitectura de los STI construidos con IRIS. Modelo del dominio.

El modelo del dominio en IRIS se representa en dos niveles:

Nivel concreto: hace referencia a la representación de los elementos propios del dominio que se representan mediante las Unidades Básicas de Aprendizaje (UBA). El sistema permite representar los cuatro tipos de elementos descritos en la CDT de Merrill:

40


41

- hecho: registro de un acontecimiento,

- concepto: conjunto de objetos, eventos o símbolos que tienen ciertas características comunes

- procedimiento: conjunto de acciones ordenadas dirigidas a la consecución de una meta,

- principio: enunciados que describen relaciones causa-efecto. Nivel pedagógico: se centra en la representación de las habilidades que se

quieren conseguir en el estudiante y en la organización pedagógica de la materia de aprendizaje. Se representa mediante Objetivos de Instrucción (OI) y relaciones entre las UBA.

NIVEL CONCRETO NIVEL PEDAGÓGICO

Conocimiento

Comprensión

Hecho

Aplicación

Análisis

Síntesis

Concepto

OI (Objetivos de Instrucción)

(Bloom)

Evaluación

Prerrequisito

Correquisito

Post-requisito

Procedimiento

Secuenciación

Siguiente

Conceptuales

Procedurales

UBA (Unidades Básicas de

Aprendizaje) (Merrill)

Principio

Relaciones entre UBA

(Reigeluth)

Estructurales

Teóricas

Tabla 7 Modelo del dominio de IRIS

Cada OI viene representado por un nivel de dificultad, el tiempo estimado para su consecución y el material necesario para la consecución del objetivo (texto, ejemplo, analogía, gráfico, test, etc.). El diseñador puede crear OI de cualquiera de los seis tipos de la taxonomía de Bloom: conocimiento, comprensión, aplicación, análisis, síntesis y evaluación. Los OI están asociados a las UBA del nivel concreto.

En cuanto a las relaciones, las que permite establecer el sistema son: de requisito o secuenciación (prerrequisito, correquisito, post-requisito y siguiente) y estructurales (conceptuales: tipos y partes; procedurales: de orden y de decisión; teóricas o de principios: causa-efecto, prescriptivas). Estas relaciones están definidas en la teoría de la elaboración de Reigeluth. Modelo del alumno

El modelo del alumno está formado por el modelo permanente y el temporal. En el modelo permanente se mantiene durante todo el proceso de

Capítulo 2

instrucción del alumno y se va actualizando sesión a sesión. Almacena información relativa a:

características personales: nombre, edad, etc.,

características de aprendizaje: tipo de alumno (novel, medio, experto),

el conocimiento que posee del dominio: representado por un modelo de superposición en el que se incorporan nuevos atributos a las UBA tales como el nivel adquirido, la fecha de adquisición de dicho nivel, los prerrequisitos conocidos, los siguientes conocidos, etc.,

los errores que ha cometido: se almacena el concepto implicado y el número de veces que se cometió,

el material didáctico que ha utilizado: textos, tests y escenarios (ejercicios),

la historia del aprendizaje: se almacenan datos relativos a la última sesión (objetivos de instrucción alcanzados y pendientes, errores cometidos, peticiones realizadas, evaluaciones realizadas, textos vistos, tests realizados y escenarios operados) y a la historia de todo el proceso de instrucción que está formada por una colección de textos que relata lo que ha sucedido en cada sesión.

El modelo temporal guarda datos que son manejados por el resto de los componentes del tutor durante el tiempo de ejecución. Está dividido en dos componentes:

características de la sesión: guarda los datos referentes a la sesión actual,

ejecución del alumno, guarda información detallada sobre las interacciones del estudiante: recursos usados (textos, tests,...).

Módulo pedagógico Está basado en el modelo CLAI (Cognitive Learning from Automatic

Instruction) que está formado por tres niveles: Procesos Cognitivos (PC), Eventos Instruccionales (EI) y Acciones Instruccionales (AI). El nivel de PC representa los procesos que tienen lugar en la mente del alumno durante el proceso de aprendizaje. El nivel de EI está formado por eventos que ejecuta el sistema para activar en el estudiante el PC apropiado. Los EI se refinan en AI concretas que finalmente ejecutará el tutor. El módulo pedagógico de IRIS contiene una biblioteca de AI clasificadas en dos grupos:

Dependientes del dominio: acciones para promover la adquisición de conocimiento (introducir contenido, repasar, ejercicio y práctica, sintetizar,...), acciones para evaluar y para corregir.

Independientes del dominio: acciones de control (para iniciar y finalizar la comunicación entre el alumno y el sistema) y de motivación (captar atención, estimular, animar,...).

El Plan Instruccional (PI) se genera mediante la aplicación de las Reglas de Decisión Pedagógica. Cada plan tiene cinco niveles, y por cada nivel existe un conjunto de reglas. En el primer nivel se selecciona el siguiente contenido del

42


43

dominio (UBA) que se va a enseñar al alumno, después se determina el OI que sobre ese contenido se va a tratar de alcanzar durante la sesión (conocimiento, comprensión, aplicación, análisis, síntesis o evaluación), a continuación se establece el conjunto de PC asociados a cada OI y se determinan los EI necesarios para cada PC y por último se refinan los EI en AI concretas que el tutor ejecutará.

Las reglas se obtuvieron analizando diferentes protocolos de enseñanza y a través de entrevistas con instructores expertos en diversos dominios.

El módulo pedagógico está formado por tres subcomponentes:

Instructor Didáctico: se encarga de generar el PI

Ejecutor Didáctico, aplica, de acuerdo con las características y conocimiento del alumno y con los contenidos del dominio, las acciones necesarias para llevar a cabo el plan,

Supervisor Didáctico, se encarga de volver a planificar la sesión cuando se produzcan situaciones que así lo requieran.

Módulo de comunicaciones Todas las actuaciones del alumno se ajustan a los formatos previstos por el

sistema (Objetivos del Alumno) que se clasifican en tres grupos:

Control de la sesión: dormir la sesión, continuar la sesión y acabar la sesión,

Plan de desarrollo de la sesión: petición de información (pedir explicación, información sobre valores de variables, evaluación,...), petición de actividad (repetir explicación, ejercicio, cambiar de nivel, simular un procedimiento,...) y respuesta evaluable (resolución de un ejercicio, confirmación positiva, confirmación negativa).

Control sobre técnicas de aprendizaje: ventana de notas, ventana resumen, ventana esquemas y subrayado.

2.3.10 REEDEM

REEDEM (Major et al., 1997) es un conjunto de herramientas para generar STI formado por tres módulos principales: catálogos de cursos (courseware catalogues), herramientas de autor y entorno de instrucción (instructional shell). A continuación se describe la arquitectura para los STI considerada en REDEEM. Modelo del dominio.

El modelo del dominio está formado por una red semántica para describir el material de enseñanza. La unidad básica del dominio son las páginas. Una página contiene material relativo a uno o varios elementos de un dominio. Para cada página se definen una serie de características como: dificultad, introductoria/final, general/específica, pasiva/activa, respuestas deducidas/respuestas dadas o nivel de ayuda. Además se enumeran las páginas relacionadas con una dada y se definen cuestiones para esa página. Existen varios tipos de relaciones entre páginas (prerrequisto, análoga, etc.).

Capítulo 2

Las páginas se pueden agrupar en secciones. Las secciones tienen las mismas propiedades que una página, pudiéndose también establecer relaciones entre secciones. Modelo del alumno

REDEEM utiliza un modelo de superposición que almacena el conocimiento que el alumno tiene del dominio. La unidad básica de conocimiento es la página. Los valores del modelo se actualizan cuando el alumno ve nuevo material o cuando responde a preguntas.

Los alumnos son clasificados dentro de alguna de las categorías definidas por el profesor. Las categorías de alumnos pueden ser asignadas a diferentes estrategias de instrucción. Módulo pedagógico

Los ITS generados por REDEEM basan su estrategia de instrucción en los siguientes principios:

todos los alumnos pueden acabar su tarea con éxito,

se le presentaran continuamente problemas ni muy fáciles ni muy difíciles,

cuando el alumno está en dificultades hay que proporcionarle una ayuda específica,

si un alumno tiene éxito después de haber usado ayuda de un determinado nivel, el tutor debería proporcionar una instrucción menos específica en la próxima intervención,

el nivel de dificultad óptimo es el que está en la zona del alumno de próximo desarrollo.

En REDEEM una estrategia de enseñanza viene definida por un conjunto de parámetros:

Estilos de enseñanza: presentación, demostración, analogía o resolución de problemas,

Estilos de tests: múltiple elección, rellena blancos, categoría, verdadero/falso,

Otras características que tienen tres posibles valores discretos:

- grado de libertad del alumno,

- enseñanza vs. tests,

- presentar tests juntos o intercalados,

- las respuestas se deducen o se dan,

- cantidad de pistas,

- cantidad de retroalimentación,

- tareas con el ordenador o no. REDEEM ofrece la posibilidad al profesor de decidir cuando aplicar una

estrategia u otra. Para ello se le plantean al profesor una serie de situaciones (el

44


45

alumno va bien, va mal, conoce este contenido, cambio de página, el contenido es difícil, etc.) que el profesor puede relacionar con una o varias estrategias (p.ej. aquellas que plantean tests).

Aunque gran parte del conocimiento pedagógico es ofrecido por el profesor a través de las herramientas de autor, REEDEM contiene conocimiento de estrategias y meta-estrategias de enseñanza usadas para las secuenciación del currículo. Este conocimiento ha sido adquirido a través de entrevistas a profesores y resultados conocidos de experimentos en el campo del diseño de instrucción. Ejemplos de las reglas del sistema son:

elegir antes material fácil que difícil, introductorio que final, familiar antes que no familiar,

las páginas de la misma sección deben ser enseñadas juntas,

los prerrequisitos deben ser enseñados en el orden correcto,

cuando los estudiantes están fallando aumentar la cantidad de ayuda y si están teniendo éxito entonces disminuirla.

La misión de las meta-estrategias (macro nivel de adaptación) es cambiar, cuando sea conveniente, las reglas de decisión que se van a aplicar. El modelo de estrategia de enseñanza usado en cada ciclo de la interacción con el alumno no tiene porqué ser el mismo que en los ciclos anteriores o posteriores. Módulo de comunicaciones

Para generar el entorno de los ITS se usa la herramienta Toolbook.

2.3.11 RIDES

RIDES (Munro et al., 1997) es una aplicación para crear y ejecutar simulaciones gráficas interactivas. RIDES genera tutores que enseñan a los estudiantes cómo operar con dispositivos. Con RIDES los autores pueden construir modelos gráficos interactivos de dispositivos u otros sistemas complejos y construir lecciones en el contexto de esos modelos gráficos. Modelo del dominio

DIAG es otro sistema de autor que sirve para la creación del modelo del dominio de RIDES. DIAG pide al autor juicios cualitativos acerca de los posibles síntomas (señales de diagnóstico) producidos por los fallos de los equipos. Aplicando la teoría de conjuntos difusos a esos juicios DIAG crea una tabla para que los alumnos puedan realizar tareas de diagnósticos sobre fallos del equipo.

La instrucción en RIDES está basada en modelos gráficos. Las escenas de simulación consisten en un conjunto de objetos gráficos en una ventana. Las escenas proporcionan el contexto para la instrucción. Cada objeto tiene asociado una lista de atributos con sus valores y sus reglas. Modelo del alumno

Está basado en los objetivos del curso. Para cada objetivo se guarda el número de intentos y la puntuación.

Capítulo 2

Módulo pedagógico El autor del tutor puede crear un curso que estará formado por una serie de

objetivos de enseñanza. Los objetivos se enlazan con lecciones, que indican cómo se debe enseñar ese objetivo. Las lecciones pueden ser expuestas a los alumnos de tres modos: modo demo, modo práctica y modo test (no se corrige a los alumnos mientras realizan el ejercicio). Se pueden establecer relaciones de prerrequisito entre objetivos. El profesor puede establecer el porcentaje de prerrequisito que debe superar el alumno para poder avanzar.

La información textual se introduce en unidades de conocimiento que pueden ser asociadas a modelos de objetos. Módulo de comunicaciones

Al alumno se le presenta una interfaz de usuario creado por el autor del tutorial. El sistema presentado tendrá un error que el alumno debe intentar diagnosticar. RIDES proporciona realimentación y consejos.

2.3.12 EON

EON (Murray, 1998) es un sistema de autor para generar STI. A continuación se comenta la arquitectura de STI en la que está basado el sistema EON. Modelo del dominio.

Es una red semántica de unidades de conocimiento llamadas temas (topics). El autor del STI deberá crear la una ontología de topics definiendo:

los tipos de topics que podrá contener el modelo del dominio (hechos, conceptos, principios, componente físico, no especificado, etc.),

las propiedades de los topics (importancia, dificultad, etc.),

los conjuntos de valores que podrá tomar cada una de las propiedades definidas,

las relaciones que se van a permitir entre los topics (prerrequisito, parte-de, es–un, contexto-para, etc.),

los niveles de los topics: especifican diferentes aspectos o usos para el topic (introducción, resumen, muestra test, nivel de principiante, nivel de dificultad, etc.).

Modelo del alumno El modelo del alumno en EON es una variante del modelo de

superposición. El modelo está dividido en capas (Fig. 3) ya que los valores acerca del conocimiento del alumno son inferidos en diferentes niveles de decisión: lección, topic, nivel de topic, contenidos de presentación y eventos. Los objetos en cada nivel están compuestos de objetos del siguiente nivel más bajo y tienen un valor determinado por las reglas de diagnóstico del modelo del alumno para ese nivel (Tabla 8). Estas reglas especifican la dependencia de los valores de un nivel con el nivel inmediatamente inferior.

46


47

Lesson

Topic 1 Topic 2 Topic 3

BegginingTeach Introduction

Content 1 Content 2 Content 3

Event 2 Event 1

Lección

Topic

Nivel de topic

Presentación

Eventos Fig. 3 Niveles del modelo del alumno de EON

El conjunto de valores que puede tomar cada nodo (KNOWN, CORRECT,...) es configurable a través de una de las herramientas de autor.

REGLA PARA INFERIR EL VALOR DE UN NODO DEL NIVEL “TOPIC” A PARTIR DEL NIVEL

“NIVEL DE TOPIC”

REGLA PARA INFERIR EL VALOR DE UN NODO DEL NIVEL “NIVEL DE TOPIC” A PARTIR DEL

NIVEL “PRESENTACIÓN”

my Teach Level is KNOWN OR all of my Parts are KNOWN KNOWN

greater than 80% of my Presentation Contents are CORRECT KNOWN

Tabla 8 Ejemplo de reglas de diagnóstico de EON

Módulo pedagógico La secuenciación del currículo en cada STI generado por EON es diferente.

En algunos sistemas es determinada dinámicamente en tiempo de ejecución usando un procedimiento de red transversal definido por el autor. Estas secuencias son llamadas por el autor líneas de flujo (flowlines).

En otros tutores el autor puede definir directamente la secuenciación, por ejemplo: “presentar n veces los mismos m topics haciendo preguntas más difíciles en cada pasada”.

El material de enseñanza se introduce en EON a través de tres herramientas:

Editor de interacciones: el sistema ofrece al autor elementos gráficos básicos (botones, textos, dibujos, transparencias, videos, tablas, diálogos de multi-elección, etc.) hasta un total de 26 que serán usados para componer una pantalla de interacción con el usuario u otros elementos gráficos más complejos que puede añadir a la librería. Estos elementos tienen dos tipos de atributos: opciones y propiedades. A través del editor de interacciones se le pueden dar valores a las opciones que permanecen a lo largo de las sesiones de enseñanza y son relativas a las características propias del elemento (nombre, eventos, color, tamaño, tipo de letra, etc.).

Editor de contenidos: el editor de contenidos permite dar valores a las propiedades de los elementos gráficos. Las propiedades son los atributos relativos a la entrada del alumno o al contenido de la instrucción (por ejemplo, en una pregunta de test el texto de la pregunta y las respuestas correctas e incorrectas). Las propiedades pueden tener un valor fijo, un valor calculado por un script o proceder de una plantilla que se rellena con diferentes objetos. A cada nivel de cada topic se le asignan varios objetos de

Capítulo 2

contenido. Estos objetos normalmente se presentan de forma secuencial, pero la tarea de selección y secuenciación de los contenidos puede también venir dada por una estrategia de enseñanza.

Editor de flowlines o editor de estrategias: los flowlines son como procedimientos en lenguajes de programación. Pueden tener parámetros de entrada, variables locales y devolver valores. Existe una herramienta para representar de forma gráfica estos flowlines. El flujo de control va avanzando a través de iconos, que representan diferentes acciones, y se ramifica hacia la derecha para representar algún otro tipo de icono. Los iconos disponibles para construir flowlines son:

- sonido,

- message box: para mostrar de forma rápida texto al alumno

- script: scripts arbitrarios que pueden referir a variables locales del flowline,

- erase/remove: ocultan o muestran elementos gráficos,

- run: invoca o otro flowline,

- home: vuelve desde un flowline devolviendo un valor si fuese necesario,

- decision: bucles, if-then, etc.,

- branch: bifurcaciones de decisión individual,

- interaction: plantea una pantalla de interacción y responde a los eventos del widget generados por el alumno,

- copy data: transfiere datos desde una localización a otra,

- animate: widgets animados,

- composite: un subflowline. Editor de meta-estrategias: los sistemas de enseñanza necesitan múltiples

estrategias de enseñanza y meta-estrategias para elegir entre ellas, de modo que sea capaz de responder ante una variedad de condiciones de aprendizaje y tipos de conocimiento.

Para definir meta-estrategias en EON lo que se hace es definir parámetros en los flowlines que representan variables globales que tomarán valores durante la sesión de enseñanza y determinaran el camino a seguir para la instrucción.

Módulo de comunicaciones La interacción del usuario se realiza a través de las pantallas (objetos de

contenido) definidos por el autor.

2.3.13 Resumen

El epígrafe 2.2 contiene comparaciones entre todos los sistemas presentados en las que se muestran las diferencias y similitudes de cada uno de los módulos de

48


49

sus arquitecturas. La siguiente tabla incluye un resumen de todos estos sistemas (por orden cronológico) resaltando sus principales características.

Como se avanzó al principio del capítulo, aunque existen muchos STI interesantes, se han elegido los más conocidos por sus aportaciones al campo.

SCHOLAR, considerado como el primer STI, usa el diálogo como estrategia de enseñanza realizando inferencias sobre la red de conocimientos. WHY continua con esta línea y realiza aportaciones interesantes acerca del método socrático de enseñanza pero utilizando en vez de un dominio declarativo como SCHOLAR, un dominio causal. SOPHIE profundiza en el estudio de modelos causales y BUGGY en modelos de errores para conseguir el diagnóstico de errores conceptuales de un alumno. WEST, WUSOR y GUIDON exploran la monitorización e intervención como estrategia de enseñanza en lugar de (o además de) la planificación de actividades de instrucción y secuenciación del currículum. Una vez sentadas las bases de la arquitectura de un STI y obtenidos resultados teóricos sólidos, algunos investigadores desviaron su atención a solucionar el problema de la reducción de costes de desarrollo intentando buscar soluciones y modelos genéricos aplicables a un amplio rango de dominios. Los sistemas IDE, IRIS, REEDEM, RIDES y EON apuntan en esa dirección.

SCHOLAR (1970)

Descripción

(Wenger, 1987f)Es el primer sistema instructor que empleó técnicas de IA. Es un sistema basado en el diálogo en el que tanto el tutor como el alumno pueden tomar la iniciativa de la conversación y hacer preguntas. El esquema de representación del dominio y las estrategias de enseñanza usadas en el sistema son aplicables a otros dominios.

M. del dominio

El dominio es la geografía sudamericana Es un modelo cognitivo de conocimiento declarativo. Red semántica de conceptos. Relaciones entre conceptos: superconcepto, superparte, superatributo

M. del alumno Modelo de superposición

M. pedagógico

Enseñanza basada en el diálogo. La estrategia de instrucción se basa en la ubicación del foco de instrucción sobre un nodo de la

red. Para ello se emplean unas reglas de inferencia sobre la red semántica. Las estrategias de instrucción son independientes del dominio. Manejan conocimiento incompleto.

M. de comunicaciones

Procesamiento del lenguaje natural basado en un sistema de gramática de casos. Existen tres modos de interacción con el alumno: sólo responder, sólo contestar, modo mixto

SOPHIE (1975)

Descripción

(Wenger, 1987e)Su objetivo es enseñar a un alumno a encontrar averías en un circuito electrónico, para ello el sistema proporciona al alumno un entorno de simulación del funcionamiento del circuito en el que el alumno puede realizar medidas y proponer hipótesis acerca de la localización del fallo.

Modelo del dominio

El dominio es circuitos electrónicos. Contiene varias representaciones diferentes del dominio: modelo de caja negra en el que se

representan procedimientos; modelo cognitivo con dos tipos de representación (simulación, basada en un modelo matemático del circuito, y declarativo, red semántica de hechos).

Modelo del alumno No tiene

Módulo pedagógico

El alumno debe aventurar una hipótesis acerca de dónde se encuentra la avería del sistema. El módulo pedagógico hace uso del simulador para: responder a preguntas, evaluar hipótesis y evaluar medidas propuestas por el alumno.

No razona sus conclusiones.


Procesamiento del lenguaje natural basado en gramáticas semánticas.

Capítulo 2

WHY (1977)

Descripción Continúa la línea de investigación de SCHOLAR centrándose sobre todo en el estudio del método Socrático para enseñar a razonar a través de diálogos. WHY enseña a sus alumnos a determinar las causas de la lluvia.

Modelo del dominio

El dominio es el proceso geofísico de la lluvia. Es un modelo cognitivo causal. El modelo de representación es una jerarquía de scripts que describen las relaciones causales

entre los eventos.

Modelo del alumno No tiene

Módulo pedagógico

Emplea el método socrático de enseñanza que consiste en conseguir a partir de preguntas que en alumno razone y deduzca la solución a un problema o cuestión.

Emplea reglas y heurísticos obtenidos a partir del análisis de diálogos reales.


El modo de interactuar con el alumno es a través de un diálogo en inglés en el que el sistema pregunta y el alumno responde.

WUSOR (1977)

Descripción

Es un entrenador para enseñar a jugar a WUMPUS, un juego en el que hay que atrapar y matar al malvado Wumpus que se esconde en una cueva dentro de un laberinto. El jugador debe poner en práctica conocimientos y habilidades sobre lógica, probabilidad, teoría de la decisión y geometría.

Modelo del dominio

Modelo de caja de cristal que analiza todos los movimientos posibles y presenta los mejores basándose en una representación basada en reglas de las habilidades del experto.

Modelo del alumno Modelo de superposición. Existe un conjunto de reglas de evidencia para hacer hipótesis acerca de lo que el alumno

sabe.

Módulo pedagógico

No existe estrategia de enseñanza para decidir cuando intervenir. El sistema interviene cada vez que el alumno falla (no selecciona la mejor opción según el experto).

Existe un conjunto de reglas de explicación que indican al sistema como generar una explicación al alumno cuando falla.


Se mantiene un diálogo entre el sistema y el alumno. El alumno indica el siguiente movimiento, si falla el sistema ofrece explicaciones.

Hay una interfaz visual donde se resume lo que va ocurriendo a lo largo de la partida.

WEST (1979)

Descripción Es un entorno de entrenamiento para el desarrollo de habilidades aritméticas simples. El sistema viene presentado como un juego en el que dos alumnos realizan una carrera para alcanzar una ciudad en el menor número de tiradas posible.

Modelo del dominio

El dominio son las cuatro operaciones aritméticas básicas. Contiene dos representaciones del dominio: modelo de caja negra que es capaz de calcular los

posibles movimientos en un instante dado y modelo cognitivo declarativo modelado como una red de conceptos más un conjunto de explicaciones asociadas. Este modelo incluye habilidades matemáticas básicas y habilidades para el juego del WEST.

Modelo del alumno

Modelo diferencial. El proceso de diagnóstico se realiza a través de: un reconocedor que compara el conocimiento

del alumno con el del experto y construye el modelo del alumno, y un evaluador que interpreta el modelo del alumno.

Módulo pedagógico

Teoría de entrenamiento Issues and examples. Detecta en qué falla el alumno y entonces aplica reglas para decidir si interviene o no, y reglas

para seleccionar sobre qué concepto se va a ofrecer ayuda y ejemplos.


Panel de juego. El experto no tiene control sobre el entorno.

BUGGY (1978)

Descripción E(Wenger, 1987b)s un programa para determinar los errores conceptuales (bugs) de un alumno sobre habilidades aritméticas básicas. El sistema proporciona un mecanismo para explicar por qué un alumno está cometiendo un error aritmético.

Modelo del dominio Modelo cognitivo procedimental construido con redes de procedimientos.

Modelo del alumno 330 procedimientos correctos e incorrectos, cada uno de los cuales tiene una descripción asociada.

Módulo pedagógico

BUGGY no se usa para enseñar, sólo para diagnosticar errores de los alumnos aunque tiene un módulo de entrenamiento para profesores.

50


51


Presentación de ejercicios.

GUIDON (1979)

Descripción

Es un programa para enseñar a resolver problemas de diagnóstico. Está basado en las reglas del sistema de consulta MYCIN. GUIDON establece con el alumno un diálogo sobre un paciente que tiene una infección, mostrando los datos clínicos y del laboratorio más relevantes y cómo usarlos para diagnosticar el organismo causante de la infección.

Modelo del dominio

Modelo de caja de cristal basado en la base de conocimiento de MYCIN (450 reglas). Modelo cognitivo declarativo formado por 100 casos reales y una red semántica de temas y

conceptos.

Modelo del alumno Modelo de superposición de tres niveles sobre la base de conocimiento de MYCIN.

Módulo pedagógico

Se emplea el método de casos, basado en un diálogo de iniciativa mixta, que es una mezcla del método socrático y la estrategia de Issues and examples de WEST.

Contiene 200 reglas de instrucción (t-rules) independientes del dominio, para guiar al alumno, responder a sus iniciativas, determinar cuando intervenir, seleccionar y presentar material.


El esquema de los diálogos es: 1) el sistema describe un caso, 2) el alumno pide datos, 3) el alumno formula hipótesis y 4) el sistema interviene.

Existe un menú con 30 opciones para que el alumno intervenga.

IDE (1988)

Descripción Es un sistema para ayudar a los diseñadores de instrucción en la tarea de creación de cursos, estructuración de los contenidos y la creación de secuencias de instrucción para la distribución del material estándar o adaptable.

Modelo del dominio

Modelo cognitivo declarativo y procedimental. Red de conceptos y habilidades que incluye errores conceptuales típicos (KS, Knowledge

structure) . Las relaciones entre nodos son subconcepto, subhabilidad, prerrequisito y bug.

Modelo del alumno

Modelo de superposición que almacena el conocimiento de los alumnos acerca de los conceptos y habilidades.

Errores conceptuales típicos. Estilos de aprendizaje más comunes para el alumno. Condiciones de instrucción para el alumno.

Módulo pedagógico

Contiene conocimiento para guiar la instrucción. El autor debe establecer reglas pedagógicas, estratégicas y tácticas.

Librería de principios y técnicas de instrucción.


El autor del STI define unas IU que son las unidades con las que interactúa el alumno. Cada IU está formada por contenido, conceptos relacionados, algunas propiedades como dificultad, etc. y preguntas y respuestas.

IRIS (1997)

Descripción Es un shell para la construcción de STI. La arquitectura subyacente es INTZIRI que hereda y amplía la de dos STI construidos anteriormente TUTOR e INTZA.

Modelo del dominio

Modelo cognitivo declarativo y procedimental construido en dos niveles: concreto y pedagógico.

Modelo del alumno Dividido en dos niveles: 1) permanente (modelo de superposición más algunas características de los alumnos) y 2) temporal: guarda la traza de las sesiones del alumno.

Módulo pedagógico

El plan de instrucción se genera mediante la aplicación de reglas de decisión pedagógicas. Cada plan tiene cinco niveles. Existen reglas diferentes para cada uno de los niveles: 1)

seleccionar el siguiente contenido, 2) determina el objetivo de instrucción que sobre ese contenido se va a tratar de alcanzar en esa sesión, 3) se establecen los procesos cognitivos asociados a cada objetivo, 4) se determinan los eventos de instrucción necesarios para alcanzar cada proceso cognitivo y 5) se refinan los eventos en acciones de instrucción concretas.

Las reglas han sido obtenidas a partir de entrevistas con instructores y analizando diversos protocolos de enseñanza.


Las acciones del alumno se ajustan a los formatos previstos por el sistema que se clasifican en tres grupos: 1) control de sesión, 2) plan de desarrollo de la sesión y 3) control sobre técnicas de aprendizaje.

REEDEM (1997)

Descripción Es un conjunto de herramientas para generar STI.

Capítulo 2

Modelo del dominio

Modelo cognitivo declarativo en dos niveles: páginas, que contienen material relativo a uno o varios elementos del dominio y secciones de páginas.

Se pueden establecer diversas relaciones entre páginas y entre secciones (prerrequisito, análoga,...).

Modelo del alumno Modelo de superposición sobre las páginas del dominio. Los alumnos se clasifican en categorías.

Módulo pedagógico

Existen varios tipos de estrategias: 1) las determinadas por el autor del ITS a través de la definición de parámetros y la asociación de cada estrategia a una situación de instrucción. y 2) las definidas en el sistema (estrategias para secuenciar los contenidos, obtenidas de entrevistas y experimentos, y meta-estrategias para decidir cuando cambiar de estrategia.


Interfaz creado con la herramienta toolbook.

RIDES (1997)

Descripción

Es una aplicación para crear y ejecutar simulaciones gráficas interactivas y tutoriales dentro del contexto de las simulaciones. RIDES genera tutores que enseñan a los estudiantes como operar con dispositivos. Con RIDES los autores pueden construir modelos gráficos interactivos de dispositivos u otros sistemas complejos y construir lecciones interactivas en el contexto de esos modelos gráficos.

Modelo del dominio

Basado en modelos gráficos. El autor representa escenas de simulación que contienen objetos que son las unidades básicas del dominio..

Modelo del alumno Para cada alumno se guarda el número de intentos y una puntuación para cada objetivo del curso.

Módulo pedagógico

El autor define un curso con varios objetivos estableciendo relaciones de prerrequisitos entre ellos.

Cada objetivo se enlaza con una lección que puede ser del tipo demo, práctica o test.


Interfaz gráfico con circuito.

EON (1998)

Descripción Es un sistema de autor para generar STI.

Modelo del dominio

Modelo cognitivo declarativo construido por una red semántica de unidades de conocimiento. Los tipos de nodos de la red y las relaciones son definidos por el autor del sistema.

Modelo del alumno

Modelo de overlay que puede contener una librería de errores comunes. Está dividido en cinco niveles: lección, topic, nivel de topic, contenidos de presentación y

eventos. Contiene reglas para determinar el valor de cada nodo del modelo.

Módulo pedagógico

La secuenciación del contenido puede ser: 1) en tiempo de ejecución, mediante la definición de unos flujos de control (flowlines) con bifurcaciones y decisiones que dependen de variables que se instancian en tiempo de ejecución y 2) directamente definida por el autor.

Existen meta-estrategias que permiten seleccionar entre estrategias de enseñanza.


Pantallas definidas por el autor.

Tabla 9 Resumen de los STI revisados en este capítulo.

2.4 Conclusiones

Los STI son el resultado de la aplicación de diversas técnicas de inteligencia artificial a la enseñanza asistida por ordenador. Estos sistemas han evolucionado para adaptarse a las nuevas tecnologías de la información, derivando en lo que se ha dado en llamar Entornos Inteligentes de Aprendizaje para la Web (WILE, Web-based Intelligent Learning Environments), estudiados con detalle en el siguiente capítulo.

Con el fin de tener una visión global de los principios de diseño de un sistema educativo inteligente se ha analizado un grupo de sistemas considerado de interés por sus aportaciones en el desarrollo de STI. Para cada sistema se

52


53

han presentado las principales características de sus modelos del dominio, del alumno, de los módulos pedagógicos y de comunicaciones.

A la hora de evaluar los sistemas educativos uno de los aspectos más importantes es la eficiencia de las teorías de instrucción aplicadas. En efecto, un sistema que se dice “inteligente” debe mejorar el rendimiento de un alumno frente a un sistema convencional. La mayoría de los sistemas presentados en este capítulo han demostrado su validez pedagógica revelándose como herramientas útiles para el aprendizaje de aquellos dominios a los que se aplican.

Si embargo, desde el punto de vista de la creación y gestión tanto de material como de métodos de instrucción es deseable que un sistema educativo sea aplicable a diversos dominios (uno de los objetivos de MEDEA). Tras el análisis realizado en este capítulo se aprecia la dificultad para encontrar técnicas de planificación de la instrucción y estrategias de enseñanzas genéricas. La mayoría de los sistemas estudiados basan su instrucción en reglas heurísticas obtenidas de la experiencia de profesores de un dominio muy concreto. Los únicos que establecen estrategias basadas en principios más o menos genéricos son aquellos que utilizan una representación del dominio basado en redes semánticas ya que suelen usar en la secuenciación del currículum relaciones pedagógicas como prerrequisito, tema/subtema, etc.

Otro de los objetivos de MEDEA es la reutilización de software educativo. La mayoría de los sistemas revisados en este capítulo poseen unos sólidos fundamentos teórico-pedagógicos, han sido estudiados en entornos reales y han probado su eficacia en la mejora de las procesos de aprendizaje, por lo que sería deseable poder aplicar todo este conocimiento en la construcción de otros sistemas. Sin embargo, su análisis pone de manifiesto que suelen poseer una arquitectura monolítica y cerrada que impide reutilizar parte del conocimiento que contienen en otras aplicaciones.

De estas reflexiones se desprende la necesidad de construir sistemas más modulares y flexibles que sean capaces de reutilizar el conocimiento, las estrategias, el material, etc. de otros STI que ya hayan sido desarrollados y probados.

Capítulo 3 SISTEMAS EDUCATIVOS EN LA WEB

En la última década la web se ha convertido en un medio fundamental para el desarrollo de sistemas educativos de enseñanza a distancia y autoaprendizaje.

La web posee una serie de características que la convierten en una tecnología de amplio potencial para la educación. A las ventajas que ofrece un sistema hipermedia tradicional se une la posibilidad de llegar a miles de alumnos conectados entre sí.

Para el usuario, utilizar la web como plataforma de distribución y uso tanto de material como de herramientas educativas, tiene la ventaja de contar con un software permanentemente actualizado y con una interfaz sencilla que no requiere muchos conocimientos técnicos.

Pese a estas ventajas, durante el proceso educativo se evidencian importantes limitaciones como son la desorientación y la sobrecarga cognitiva. Se hace patente, pues, la necesidad de aplicaciones para la web que proporcionen al alumno apoyo y guía a lo largo de la instrucción. Es por ello que diversos investigadores han tratado de adaptar a este nuevo medio las técnicas y conocimientos aplicados con éxito en el desarrollo de STI (Brusilovsky, 1995; Nakabayashi et al., 1997), que evolucionan de forma natural hacia lo que se ha dado en llamar Entornos de Aprendizaje Inteligentes para la Web (WILE, Web-based Intelligent Learning Environment).

Estos sistemas heredan algunas de las críticas que tradicionalmente se le han imputado a los STI, principalmente en lo referente a su alto coste de desarrollo y su especialización, que hace difícil su reutilización y extensión a otros dominios o situaciones de aprendizaje.

Además, la comunidad educativa demanda entornos que integren una amplia variedad de recursos pedagógicos (Learning Objects (IEEE, 2005)), que normalmente los WILE, centrados en una tarea, dominio y/o estrategia de instrucción, no ofrecen. Se hace por tanto evidente la necesidad de conjugar por un lado la versatilidad de sistemas “no inteligentes” de enseñanza con las técnicas “inteligentes” de instrucción de los WILE.

54

Sistemas Educativos en la web

55

La solución más natural, defendida en esta tesis, pasa por reutilizar los sistemas educativos inteligentes, normalmente fruto de años de investigación y en cuyo desarrollo han intervenido equipos multidisciplinares de expertos, para obtener un entorno de aprendizaje cuyo desarrollo se reduzca en la medida de lo posible a combinar distintos recursos educativos ya creados. En este capítulo se muestra, a través de la revisión de distintos sistemas educativos para la web, la evolución de los sistemas inteligentes hacia esta propuesta.

En primer lugar se presentan los Sistemas de Gestión de Aprendizaje (LMS, Learning Management Systems), herramientas “no inteligentes” para la educación a través de la web, con el fin de ofrecer una perspectiva de hacia donde están evolucionando los sistemas educativos inteligentes: hacia sistemas versátiles, genéricos y flexibles como los LMS pero sin renunciar a la inteligencia de los WILE.

A continuación se describen algunos de los sistemas educativos inteligentes para la web más representativos de la última década.

El siguiente epígrafe ilustra los esfuerzos encaminados a la creación de arquitecturas más flexibles, modulares y descentralizadas que faciliten la reutilización del conocimiento (material, modelos del dominio, datos del alumno, estrategias pedagógicas, etc.).

Por último se muestran algunos trabajos que apuestan, al igual que esta tesis, por la integración de sistemas externos para construir entornos de aprendizaje inteligentes.

3.1 Sistemas convencionales de enseñanza virtual

Los sistemas usados tradicionalmente para la enseñanza en la web son los llamados sistemas de gestión de aprendizaje (LMS, Learning Management Systems). Los LMS son conjuntos de herramientas para la creación, seguimiento y administración de cursos a través de la web. Entre las funciones más comunes que ofrece un LMS se incluyen programas de cursos, calendario, gestión de contenidos, comunicación (foros, correo, chat, etc.), exámenes, test y recursos del alumno.

Existe una gran variedad de LMS. En (WCET (Western Cooperative for Educational Telecommunications), 2004) el lector puede consultar una completa comparativa entre muchos de estos sistemas.

Aunque su carácter comercial hace difícil el acceso a información relativa a detalles de su implementación (arquitectura, tecnología, plataforma de desarrollo, etc.), en este apartado se describen a modo de ejemplo WebCT y Blackboard, dos de los LMS más usados en el desarrollo de cursos para la web.

3.1.1 WebCT

WebCT (Goldberg et al., 1996; WebCT, 2004) es un sistema de gestión de cursos para la web. Fue creado en el departamento de Ciencias de la Computación de la University British Columbia y posteriormente adquirido por Universal

Capítulo 3

Learning Technology TM. (actualmente WebCT, Inc.), que se ocupa de su comercialización y desarrollo.

WebCT está formado por un conjunto de herramientas educativas para construir y gestionar el entorno de un curso web que se pueden clasificar dentro de cuatro categorías:

aprendizaje, comunicación y colaboración,

organización del material del curso,

utilidades administrativas y

herramientas para la creación de cursos.

Un curso con WebCT puede ser creado desde cero o usando materiales adaptables al usuario desarrollados en formato WebCT (e-packs), como animaciones de videos, test, glosarios, etc.

Entre las herramientas de WebCT podemos destacar las de evaluación del alumno, organización y distribución del contenido e información del alumno.

El motor de evaluación de WebCT proporciona una amplia selección de tipos de preguntas (elección múltiple, respuesta corta, correspondencia, calculada y composición). Todos los tipos pueden incluir imágenes y multimedia. La base de datos almacena información y estadísticas sobre el rendimiento de preguntas y alumnos a lo largo del tiempo permitiendo al profesor evaluar la idoneidad de determinadas preguntas. WebCT permite almacenar ficheros de los alumnos, presentaciones, mensajes, datos de acceso a cursos e información de traza de las páginas a través del entorno de enseñanza. Estos ficheros pueden ser exportados como texto y usados para crear recursos de aprendizaje como FAQ. El profesor puede examinar los foros de discusión y los correos y agregar esta información a los datos de evaluación del alumno.

En cuanto a la organización del contenido, WebCT maneja unidades llamadas módulos de contenido, que son páginas unidas en secuencias lineales y jerárquicas a herramientas de navegación integradas. Dentro de esos módulos el profesor puede incluir herramientas y recursos que contengan referencias y hebras de discusión que pertenezcan a una página concreta. WebCT permite al profesor analizar cómo se mueven los alumnos a través del contenido.

Otra característica destacable de WebCT es su flexibilidad a la hora de presentar el contenido de un curso, lo que le permite personalizar el entorno de aprendizaje ajustándose a las necesidades de un alumno o grupo de alumnos.

3.1.2 Blackboard

Blackboard (Yaskin and Everhart, 2002) es un sistema de aprendizaje para el desarrollo, seguimiento y administración de cursos sobre la web desarrollado por Blackboard, Inc. Sus principales características son:

una gestión de contenidos basada en currículo,

sistema de evaluación que permite el desarrollo de test y cuestionarios,

56


57

expediente (gradebook) con una interfaz integrada que permite al profesor gestionar la asignación de tareas electrónicamente,

permite colaboración y comunicación entre alumnos a través de paneles de discusión y clases virtuales,

herramientas de administración,

está construido sobre la arquitectura Blackboard Building Blocks que permite la personalización, extensión e integración de la plataforma,

cumple las especificaciones SCORM 1.2 de ADL.

3.1.3 Resumen

Los LMS son sistemas estáticos, es decir, carecen de inteligencia en el sentido de que no son capaces de adaptar el material al alumno a lo largo de la instrucción. En estos sistemas el profesor puede diseñar un curso personalizado para un grupo de alumnos (o incluso para un alumno en particular) pero éste no modificará su aspecto ni su contenido según la evolución que vaya sufriendo el alumno, es decir, no se contempla el modelado del alumno ni sus aplicaciones.

A pesar de esto, los LMS ofrecen dos ventajas importantes: 1) numerosos LO (Learning Objects) disponibles tanto para profesores como para alumnos; 2) la posibilidad de construir cursos mediante la reutilización de estos LO.

3.2 Los sistemas inteligentes en la web

Los entornos de aprendizaje inteligentes para la web constituyen una nueva generación de STI. Son sistemas constructivistas que intentan incorporar los beneficios del aprendizaje guiado al aprendizaje basado en la libre exploración del espacio de conocimientos. Su objetivo es orientar al alumno a lo largo del proceso de enseñanza sin coartar la libertad de navegación característica de los sistemas hipermedia.

Estos sistemas mantienen la arquitectura tradicional de los STI pero presentan algunas particularidades derivadas del hecho de estar orientados a la web. Estos principios se describen brevemente en el epígrafe 3.2.1. A continuación se realiza una revisión de los sistemas más representativos de la última década describiendo su arquitectura, funcionamiento y tecnología de desarrollo. Esta exposición concluye con un resumen en el que se comparan todos los sistemas descritos y se resaltan sus aportaciones más significativas al campo.

3.2.1 Arquitectura de los sistemas educativos inteligentes para la web

El uso principal que se le dio a la web en sus comienzos fue el de almacén de documentos en hipertexto, y en esa línea surgieron los primeros sistemas educativos para la web que no eran más que libros electrónicos en los que el usuario podía navegar a través de los enlaces del índice y los contenidos en las propias páginas.

Capítulo 3

La principal ventaja de estos sistemas es la de favorecer un aprendizaje constructivo (Martorell and Prieto, 2002), concebido por los teóricos de la educación como un proceso en el que el alumno fabrica su propio conocimiento basándose en sus experiencias y habilidades. En un sistema hipermedia el papel del tutor como guía del aprendizaje desaparece y es el alumno el que elige su propio camino accediendo de forma totalmente libre a la información.

Sin embargo, aparecen así una serie de problemas inherentes al hipertexto que podríamos llamar desorientación y la sobrecarga cognitiva. En estos sistemas es fácil que un alumno en un momento dado no sea capaz de ubicar los conceptos que está estudiando o de encontrar determinada información. Asimismo, el usuario de un hipertexto puede en ocasiones sentirse abrumado por la gran cantidad de información a su alcance.

Como modo de paliar estos inconvenientes, algunos investigadores han tratado de exportar hasta esta nueva plataforma algunas de las técnicas desarrolladas a lo largo de las últimas décadas en el campo de los STI tradicionales (Brusilovsky, 1999). Estos esfuerzos han dado lugar a una nueva generación de STI conocidos como Entornos de Aprendizaje Inteligentes para la Web (WILE, Web-based Intelligent Learning Environment). Estos sistemas intentan ofrecer al alumno ayuda inteligente y personalizada orientándolo y asistiéndolo en su navegación a través del hipertexto.

Sin embargo, aparecen así una serie de problemas inherentes al hipertexto que podríamos llamar desorientación y la sobrecarga cognitiva. En estos sistemas es fácil que un alumno en un momento dado no sea capaz de ubicar los conceptos que está estudiando o de encontrar determinada información. Asimismo, el usuario de un hipertexto puede en ocasiones sentirse abrumado por la gran cantidad de información a su alcance.

Como modo de paliar estos inconvenientes, algunos investigadores han tratado de exportar hasta esta nueva plataforma algunas de las técnicas desarrolladas a lo largo de las últimas décadas en el campo de los STI tradicionales (Brusilovsky, 1999). Estos esfuerzos han dado lugar a una nueva generación de STI conocidos como Entornos de Aprendizaje Inteligentes para la Web (WILE, Web-based Intelligent Learning Environment). Estos sistemas intentan ofrecer al alumno ayuda inteligente y personalizada orientándolo y asistiéndolo en su navegación a través del hipertexto.

La arquitectura de los WILE está formada por un modelo del dominio, un modelo del usuario y un módulo pedagógico (De Bra et al., 1999). El módulo de comunicaciones o interfaz viene dado por el navegador. En (Brusilovsky, 2003) se describen de forma detallada las diferentes formas que pueden adoptar cada uno de los elementos de la arquitectura.

El modelo del dominio está formado por dos redes interconectadas: una red semántica de conceptos relacionados y una red de páginas de hipertexto conteniendo el material educativo. Los conceptos representan unidades de conocimiento y suelen ser descritos por un nombre y un conjunto de atributos asociado. En

58


59

cuanto a las relaciones, la más común es la de “prerrequisito”, sin olvidar otras relaciones semánticas como “es un” y “parte de”.

El diseño de la estructura del hiperespacio es independiente de la red de conceptos, y puede ser desde un sistema no estructurado, pasando por una estructuración jerárquica, conversacional (enlaces asociados a preguntas) o una combinación de varias estructuras.

Brusilovsky determina como punto clave del diseño de un sistema hipermedia educativo la conexión de estas dos redes. Este proceso es conocido como indexación y es fundamental para la posterior aplicación de técnicas de adaptación. Existen varias formas de indexar el hiperespacio:

Indexación basada en conceptos: es usada en sistemas que tienen una única página por cada concepto del dominio. Los enlaces entre conceptos constituyen los principales caminos entre los nodos del hiperespacio. Una versión mejorada de esta forma de indexación es cuando un concepto es descrito por varias páginas. Cada concepto se conecta con una página a partir de la cual se puede navegar por las demás.

Indexación de páginas: una página se conecta con un concepto si éste está contenido en la página, por tanto una página puede estar relacionada con múltiples conceptos.

Indexación de fragmentos: es el método más preciso. Cada página se divide en fragmentos que serán conectados con todos los conceptos contenidos en dicho fragmento.

En cuanto al modelo del usuario la mayoría de los sistemas usan el modelo de superposición de conocimiento (muy común en los STI), en el que se considera el conocimiento del alumno como un subconjunto del conocimiento del experto. Este modelo se suele acompañar de información acerca del comportamiento del alumno en el sistema (páginas visitadas, tiempo empleado en cada página, enlaces más utilizados, etc.).

El módulo pedagógico es el encargado del proceso de instrucción de un alumno. En un STI tradicional el objetivo de la instrucción puede ser alcanzado planificando las actividades de la instrucción o monitorizando al alumno para determinar la conveniencia de intervenir en la sesión, mientras que los WILE están limitados, por la propia naturaleza de la web, a la aplicación de técnicas de adaptación (procedentes de los sistemas hipermedia adaptativos). Las técnicas de adaptación pueden clasificarse en dos grupos: técnicas de adaptación de la presentación y técnicas de ayuda a la navegación adaptativa. Para la adaptación de la presentación se insertan, eliminan, ordenan, atenúan y/o modifican fragmentos de una página. Para la ayuda a la navegación se aplican métodos como la guía directa y la ordenación, ocultación, anotación y/o generación de enlaces. Estas técnicas pueden ser consideradas como una generalización de las técnicas de secuenciación de currículos en los STI tradicionales. En (Brusilovsky, 2000) se ofrece una detallada revisión de estas tecnologías.

Capítulo 3

3.2.2 CALAT

CALAT (Nakabayashi et al., 1997) es un sistema que presenta al estudiante un curso organizado de forma jerárquica con un objetivo global y sub-objetivos. Las páginas del curso pueden ser de tres tipos: explicación, ejercicio y simulación.

Las páginas de explicación presentan material educativo relacionado con un concepto. Las páginas de ejercicios plantean preguntas al alumno cuyas respuestas se utilizan para actualizar el modelo del alumno. Por último, las páginas de simulación proporcionan un entorno de simulación interactivo para adquirir conocimiento procedimental. Arquitectura

CALAT presenta una arquitectura modular basada en la web. En la parte del servidor existe un proceso al que se conectan los usuarios a través de sus navegadores y que lanza un proceso STI por alumno. Además en el servidor se encuentra un catálogo del curso (courseware) (Fig. 4) que contiene las páginas de explicación, ejercicios y simulación de un curso.

El proceso STI (Fig. 4) está formado por un modelo del alumno de superposición y un sistema experto tutor (CAIRNEY) que, haciendo uso de los resultados de los ejercicios y simulaciones, determina el siguiente objetivo que debe ser explicado y por ende la siguiente secuencia de páginas de explicación que se le va a mostrar al alumno.

Para generar un catálogo de un curso para CALAT es necesario definir las dependencias entre los objetivos de aprendizaje y entre estos y las páginas.

Fig. 4 Arquitectura del proceso STI y el catálogo de cursos (Nakabayashi et al., 1997)

Tecnología

Como ya se ha mencionado, los cursos de CALAT pueden tener tres tipos de páginas: explicación, ejercicios y simulación.

Las páginas de explicación pueden contener cualquier tipo de dato HTML (imagen, texto, video, audio, applets de Java,...) y aplicaciones plug-in como VRLM y Shockware. El curso puede apuntar a páginas residentes en cualquier servidor web. El acceso y carga de la página web correspondiente a una explicación se realiza ejecutando en el cliente el procedimiento JavaScript que

60


61

haya indicado el servidor CALAT tras determinar el sub-objetivo de aprendizaje siguiendo la lógica pedagógica del sistema tutor.

Una página de ejercicios es un formulario HTML que se genera dinámicamente a partir de unas plantillas. Cada pregunta de la plantilla está asociada a un sub-objetivo de aprendizaje. Cuando el proceso STI decide que el alumno debe volver a intentar el ejercicio se incluye en el formulario un mensaje de voz de advertencia.

Una página de simulación consiste en una máquina de transición de estados (STM) que se ejecuta en el servidor y un programa de animación especial en el cliente. Este programa se ejecuta como un visor externo o como un programa embebido en el navegador y puede contener los elementos típicos de un interfaz gráfico de usuario. La STM se define como una colección de estados, un conjunto de eventos de entrada y un conjunto de acciones de salida que actúan sobre la interfaz gráfica. Todas las comunicaciones entre la STM y el programa de animación se realizan sobre HTTP (la acción del alumno como una petición GET al STM y la respuesta del STM como un dato multimedia).

3.2.3 DCG

DCG (Dynamic Course Generator) (Vassileva, 1997; Vassileva and Deters, 1998) es una herramienta para crear cursos adaptativos para la web. DCG genera cursos individuales basándose en los objetivos y conocimientos previos del alumno y lo adapta dinámicamente a partir de los logros del alumno durante el desarrollo del mismo. Arquitectura

Los principales componentes de la arquitectura de DCG (Fig. 5) son: una base de datos del dominio, un modelo del alumno, un generador de cursos, un componente pedagógico y una herramienta de autor.

La base de datos del dominio está formada por una estructura de conceptos del domino y un conjunto de materiales de enseñanza.

Los materiales de enseñanza contienen presentaciones y unidades de test. Cada uno está centrado en un concepto o relación del dominio y puede tener asociado un conjunto de diferentes características pedagógicas (introducción, explicación, ayuda, etc.).

La estructura de conceptos es un grafo AND/OR de conceptos conectados entre sí por distintos tipos de relaciones semánticas (agregación, generalización, analogía, implicación, etc.). Cada concepto tiene asociado un conjunto de materiales de enseñanza de diferentes tipos.

El modelo del alumno de DCG tiene tres partes: un modelo del conocimiento del alumno de superposición sobre el modelo del dominio, un histórico y un modelo de características y preferencias del alumno.

El componente pedagógico contiene representaciones de métodos y tareas de instrucción y un conjunto de reglas de enseñanza. Las jerarquías de los

Capítulo 3

métodos y tareas y su descomposición en sub-tareas se representan mediante grafos AND/OR similares a los del dominio. Existe un conjunto de tareas y métodos genéricos predefinidos que puede ser extendido con otros más específicos del dominio.

Las reglas de enseñanza controlan la selección de métodos, tareas y material de enseñanza. Existen varios tipos de reglas de enseñanza: de discurso (controlan la elección del plan al nivel de conceptos), de selección de estrategia, de selección de método y de selección del material de enseñanza.

El generador del curso es el componente que crea el curso, lleva a cabo la interacción con el alumno y mantiene el modelo del alumno. Tiene dos componentes: el planificador y el ejecutor. El planificador genera una secuencia de los conceptos que deben ser cubiertos por el curso para alcanzar el objetivo del mismo y una secuencia de tareas para enseñar dichos conceptos. Para realizar su tarea se sirve de las reglas de enseñanza. El algoritmo de planificación es una modificación del AO*. El ejecutor invoca al planificador para generar un plan que le ayude a alcanzar el objetivo de enseñanza y el conjunto de tareas necesarias para ello. Si el alumno no logra aprender un concepto se vuelve a planificar local o globalmente.

Fig. 5 Arquitectura de DCG (Vassileva and Deters, 1998)

Por último, la herramienta de autor está formada por un editor de material de enseñanza, un editor de estructura de conceptos y un editor de tareas y métodos de instrucción. Funcionamiento

El autor de un curso debe crear el material de enseñanza y asociarlo a un concepto o relación del modelo del dominio. Además el autor debe clasificar dicho material en su categoría pedagógica y asignarle una cuota de tiempo. Al menos una unidad de test debe ser creada para cada nodo y enlace del dominio. Asimismo, debe asociarse a cada pregunta un vector de probabilidades que indique las probabilidades condicionadas de que el estudiante se sepa el concepto implicado habiendo respondido bien o mal a la pregunta.

62


63

Una vez creado el curso, el alumno envía una petición a DCG indicando el dominio y el objetivo de instrucción. Si el alumno es nuevo debe realizar un pequeño test para inicializar su modelo. Después el alumno recibe un plan individualizado (secuencia de conceptos y relaciones que debe aprender). El ejecutor carga en la máquina del cliente materiales de enseñanza alternativos para cada concepto del plan.

Las reglas de selección de estrategia determinara, antes de que comience a ejecutarse el plan, basándose en el perfil del alumno si seguirá una estrategia estructurada (el alumno será guiado por el sistema) o no estructurada (el alumno puede navegar libremente).

Si el material de enseñanza contiene enlaces a documentos que pertenecen a conceptos no incluidos en el plan, el alumno puede visitarlos pero no se tendrán en cuenta para actualizar su modelo.

El ejecutor puede presentará un test a petición del alumno o cuando el material para un concepto se haya agotado. Si el alumno no pasa el test el ejecutor vuelve a intentar enseñarle el concepto haciendo una planificación local y si vuelve a fallar se llama al planificador para que rehaga el plan. Tecnología

DCG está implementado sobre una arquitectura cliente servidor usando C++ y OpenScript. Toolbook es la herramienta usada para desarrollar el material.

En la parte del servidor se encuentran el planificador, el modelo del dominio y los modelos del alumno.

En el cliente se descarga durante cada sesión una copia del proceso ejecutor (programa en Java) que instala en la máquina todo el material para cada concepto del plan. También se carga en el cliente el plan y una copia del modelo del estudiante que será la que se vaya actualizando. Cuando finaliza la sesión el modelo del alumno se vuelca al servidor.

3.2.4 InterBook

InterBook (Brusilovsky et al., 1998) es una herramienta de creación y distribución de libros de texto electrónicos adaptativos para la web. InterBook permite crear los libros a partir de texto plano convirtiéndolo en HTML con anotaciones. Para poner los libros a disposición de los usuarios InterBook cuenta con un servidor HTTP propio. Para cada usuario registrado, un servidor de InterBook mantiene un modelo individual del conocimiento del alumno y lo usa para proporcionar guía, ayuda para la navegación y ayuda adaptada a las necesidades del usuario. Arquitectura

InterBook representa el material educativo como un conjunto de libros de texto electrónicos. Cada uno es estructurado jerárquicamente en varios niveles: unidades, secciones y sub-secciones. Cada nivel hoja en el árbol es una presentación atómica, un ejemplo, un problema o un test.

Capítulo 3

Los libros de texto electrónicos generados con InterBook tienen dos partes: un glosario y el libro de texto propiamente dicho.

El glosario es el núcleo del libro y representa una visualización del modelo del dominio. Dicho modelo está formado por una red de conceptos (piezas de conocimiento) del dominio y las relaciones entre los mismos. Cada nodo de la red representa un nodo del hiperespacio y cada relación un enlace entre dos nodos del hiperespacio.

Para conectar el libro con el glosario se indexan las unidades del libro con los conceptos del modelo del dominio. Cada unidad tiene asociada una lista de conceptos (espectro de la unidad) y el rol que cada uno representa en la unidad. InterBook permite dos roles: salida o prerrequisito. Un concepto es de salida si alguna parte de la unidad presenta la pieza de conocimiento que representa dicho concepto. Un concepto es prerrequisito si un alumno debe conocerlo para entender el contenido de la unidad.

Por último, la arquitectura de InterBook incluye un modelo del alumno de superposición que almacena: el nivel de conocimiento del alumno para cada concepto del dominio, las acciones realizadas por el alumno (páginas visitadas, problemas resueltos y preguntas contestadas) y los objetivos de aprendizaje. Un objetivo de aprendizaje es un conjunto de conceptos que el alumno debe aprender. Funcionamiento

Cada página que el alumno ve de un libro desarrollado con InterBook contiene, como cualquier libro de texto electrónico, el material correspondiente a la sección que esté visitando (texto, test, ejercicio) y una barra de navegación que muestra la estructura del curso con enlaces a todas los capítulos y secciones del libro.

Además de estos contenidos básicos, una página de InterBook contiene una barra de conceptos en la que se muestran los conceptos de salida y prerrequisitos de la sección que se está visitando y un conjunto de botones de ayuda a la navegación.

InterBook aplica varias técnicas de adaptación de contenidos:

Navegación avanzada. El sistema permite navegación secuencial, jerárquica y directa y genera enlaces entre el glosario y el libro de texto.

Guía directa y ayuda a la navegación adaptada. El sistema usa elementos visuales para mostrar el tipo y el estado de cada enlace (conocido por el alumno, listo para ser aprendido, no debe ser aprendido todavía) y es capaz de sugerir al alumno la siguiente parte del material que debe ser aprendida aplicando varios heurísticos.

Ayuda basada en prerrequisitos. El sistema ofrece una lista de enlaces a los prerrequisitos de la sección que está siendo visitada y que el alumno aun no ha aprendido.

Tecnología

64


65

La implementación de InterBook está basada en el servidor web CL-HTTP (Common Lisp Hypermedia Server). Este servidor está completamente implementado en LISP y proporciona soporte para CGI (Common Gateway Interface).

3.2.5 ELM-ART

ELM-ART (ELM Adaptive Remote Tutor) (Weber and Brusilovsky, 2001) es un sistema educativo inteligente e interactivo para la enseñanza de la programación en LISP desarrollado para la web. Está basado en un sistema anterior (ELM-PE), un entorno de aprendizaje inteligente que ofrece soporte para la programación basada en ejemplos, el análisis inteligente de las soluciones de problemas, así como la evaluación mediante test y la depuración de programas. Arquitectura

ELM-ART es un libro de texto inteligente con un entorno integrado de resolución de problemas. Los elementos principales de su arquitectura son: el modelo del dominio, el modelo del alumno, el material del curso, un conjunto de técnicas adaptativas de apoyo a la navegación, un módulo de resolución de problemas, un módulo de test y un conjunto de herramientas de adaptación.

El modelo del dominio de LISP se representa por una red de conceptos y relaciones pedagógicas (es_un, parte_de, prerrequisito) entre los mismos. Se establecen relaciones entre los conceptos del dominio y las páginas de texto, los ejemplos y los problemas en los que estos se explican.

El modelo del alumno es un modelo de superposición en cuatro niveles (visitado, aprendido, inferido, conocido) que representa el nivel de conocimiento del alumno para cada concepto del dominio. El alumno puede consultar y editar su modelo en cualquier momento a lo largo de la instrucción.

El material del curso se compone de un libro de texto y un manual de referencia. El libro de texto es una versión electrónica de un libro de LISP. Está estructurado en capítulos, secciones y subsecciones. Cada una de estas unidades se muestra al alumno en una página web que contiene información acerca del ítem (texto y gráficos) y enlaces a páginas relacionadas. Además de esta estructura jerárquica, el sistema establece relaciones de prerrequisito entre las unidades del libro. Las páginas del libro son generadas dinámicamente.

El manual de referencia actúa a modo de glosario e índice del libro incluyendo en cada página una explicación de uno de los conceptos del dominio y enlaces a las unidades en las que estos se explican.

En el curso se presentan al alumno dos tipos de enlaces diferentes: de jerarquía, (representando las relaciones jerárquicas del libro) y basados en contenidos (enlaces desde las páginas del libro a las páginas del manual).

Las técnicas de adaptación utilizadas son: anotación adaptativa, que consiste en usar pistas visuales para indicar al alumno el tipo de un enlace y su estado

Capítulo 3

de conocimiento del nodo que hay tras el enlace; ordenación adaptativa, los enlaces se ordenan por orden de importancia respecto a los conceptos que se están estudiando.

ELM-ART permite al alumno la programación basada en ejemplos. El sistema es capaz de predecir la forma en la que un alumno va a resolver un determinado problema y encontrar el ejemplo más apropiado para él. ELM-ART permite al alumno evaluar las soluciones de los problemas y, si éste no es capaz de encontrar los errores, puede pedir ayuda al sistema.

Además de estos módulos, ELM-ART incluye herramientas para la comunicación directa con un tutor humano y para la discusión con otros alumnos: correo electrónico, chat y listas de discusión. Funcionamiento

Desde el punto de vista del usuario ELM-ART es un libro de texto electrónico inteligente que permite varios modos de navegación (secuencial, jerárquica y por el glosario). ELM-ART es capaz de construir el camino de aprendizaje para cada alumno indicando en cada paso la actividad más adecuada. El algoritmo de planificación está basado en los prerrequisitos definidos en el modelo del alumno.

Las páginas incluyen actividades interactivas: expresiones LISP que se pueden evaluar (en modo simple o paso a paso), ejemplos de resolución de problemas, preguntas (adaptadas al nivel de conocimiento del alumno) y problemas para resolver. El sistema evalúa las respuestas y proporciona realimentación inmediata. Con esta información se construye el modelo del alumno.

En el módulo de ejercicios de programación al usuario se le planteará un problema de LISP. Una vez que haya introducido la solución y tras haber sido evaluada por el sistema el alumno puede pedir que se le muestre un ejemplo, pedir pistas y mensaje de ayuda o ver la solución. Tecnología

ELM-ART está desarrollado sobre el servidor CL-HTTP (Common Lisp Hypermedia Server). Este servidor está completamente implementado en Common Lisp y es capaz de gestionar peticiones HTTP via CGI.

3.2.6 MetaLinks

MetaLinks (Murray, 2003) es una herramienta de autor y un servidor web para libros de hipertexto adaptativos. Los objetivos que persigue el sistema son: proporcionar un aprendizaje dirigido por exploración, conceptualizar el contenido en forma de red (jerárquica y narrativa) y mejorar problemas como la desorientación, sobrecarga cognitiva, etc. Arquitectura

66


67

MetaLinks tiene una arquitectura cliente/servidor (Fig. 6). En el servidor se encuentra un servidor de base de datos que contiene información acerca de los elementos necesarios para construir un libro de hipertexto: páginas, enlaces a páginas, conceptos del glosario, elementos multimedia y datos sobre el usuario. Con estos datos MetaLinks genera las páginas HTML que se piden desde el cliente, a partir de plantillas de HTML dinámico que se encuentran en el servidor, adaptadas al usuario.

Fig. 6 Arquitectura de MetaLinks (Murray, 2003)

En MetaLinks un libro está compuesto de páginas modulares de pequeño tamaño que se consideran unidades temáticas. Los enlaces en MetaLinks son de página a página (no de texto a página) y representan relaciones semánticas entre unidades de conocimiento.

Los libros están organizados de forma jerárquica con relaciones de padre a hijo. No existe la relación más común en libros de hipertexto que es la de capítulos y secciones. Lo que para un usuario puede ser una sección, para otro con menos nivel puede ser un capítulo.

Las páginas padre son consideradas resúmenes o introducciones genéricas de sus páginas hijas. Cada página hija profundiza un poco más en los conceptos de sus predecesores.

Además de esta estructura jerárquica MetaLinks permite relacionar unas páginas de la jerarquía con otras a través de relaciones temáticas que pueden ser creados por el autor del libro (fenómenos relacionados, trasfondo histórico, etc.).

MetaLinks proporciona al usuario las siguientes herramientas de navegación:

Tabla de contenidos anotada (TOC), que muestra al usuario la estructura jerárquica del libro marcándole las páginas que ha visitado.

Texto de ampliación. Los ejemplos y aclaraciones sobre texto o gráficos incluidos en la página se pueden añadir en forma de cuadros de texto resaltado que aparecen al pasar el botón por el concepto al que se refiere.

Herramienta de búsqueda.

Capítulo 3

Características de control de profundización personalizada (explicar más, siguiente página, botones de retorno, etc.)

Ir a otros conceptos relacionados con el actual (padre, hermano anterior o siguiente, directo, hijo). En MetaLinks la página siguiente por defecto es la página hermana a la actual. El paso de un padre a un hijo es para profundizar sobre un concepto.

Glosario.

Enlaces a páginas relacionadas (no jerárquicamente).

Histórico.

Títulos-pregunta. Además del título de cada página, el autor puede enunciar una pregunta a la que esa página responda y que se incluya en la lista de enlaces a páginas relacionas por si el usuario siente curiosidad por esa pregunta.

Funcionamiento

Cuando un usuario accede a un libro de hipertexto generado con MetaLinks puede ver una pantalla principal con la barra de navegación, el contenido de la página (texto, figuras, etc.), botones de control de navegación adaptados y una lista de enlaces a páginas hijas de la actual. Además, en pantallas independientes, puede acceder al índice de contenidos, herramientas de búsqueda, el glosario y el historial de navegación. El usuario puede configurar el aspecto de la pantalla (diseño, fondo, estilo, etc.).

Los aspectos de MetaLinks adaptables al alumno son:

Las anotaciones en la tabla de contenidos acerca de las páginas visitadas por el alumno.

Cuando el usuario salta a una página que no es la siguiente en el flujo narrativo que estaba siguiendo el sistema, incluye un párrafo de introducción al principio de la página.

La función y disponibilidad de los botones de navegación cambia si el usuario elige el control de profundidad o si salta a una página tangencial.

Los enlaces en el histórico se anotan con los tipos de enlaces a través de los cuales la página fue visitada.

Tecnología

Los contenidos de MetaLinks están almacenados en una base de datos relacional (FileMaker Pro Server). El sistema tiene bases de datos separadas para las páginas, enlaces, glosario, elementos multimedia (que opcionalmente pueden estar en el cliente) y datos del usuario. El material de enseñanza está formado por plantillas de HTML dinámico (DHTML) que permiten personalizar su contenido usando información sobre el usuario y los datos almacenados en el servidor.

68


69

3.2.7 AHA

AHA (Adaptive Hypermedia Architecture) (De Bra and Calvi, 1998) es un software para desarrollar sistemas de hipermedia adaptativos de varios tipos: sistemas de información on line, sistemas de ayuda on line, hipermedia educativa, hipermedia institucional y vistas personalizadas. Arquitectura

La construcción de un curso se basa en un modelo del dominio que consiste simplemente en una lista de conceptos.

Para realizar la adaptación de sus páginas AHA se basa en un modelo del usuario formado por pares concepto-valor que indican si el usuario conoce o no un concepto. Esta información se obtiene a través de las páginas visitadas y los test realizados por el alumno. Los conceptos en AHA se usan además de para representar unidades de información elemental de un dominio para indicar preferencias del usuario acerca de determinados aspectos del sistema. En este caso los valores pueden ser distintos de verdadero o falso.

Además de este modelo de conocimiento, el sistema AHA almacena el tiempo que el usuario permanece en cada página y la puntuación de los test.

AHA incluye en su arquitectura un fichero de dependencias que contiene pares de nombres de páginas y expresiones. Cada línea indica las condiciones que se deben cumplir para que pueda existir un enlace a esa página. Funcionamiento

Los alumnos que usen un curso generado con AHA deberán primero leer una página de instrucciones donde se les indica como usar el contenido del curso y como configurar su navegador. Este enlace es muy visible al principio del curso y después se pasa al final de la página.

AHA ofrece dos tipos de adaptación:

De contenidos: el autor de las páginas incluye las condiciones bajo las cuales se insertará un determinado texto en la página.

De enlaces: AHA ofrece al autor de un curso la posibilidad de ocultar enlaces y la de mostrar enlaces anotados. La anotación de enlaces se realizan mediante clases de enlaces que se convierten en distintos colores a través de una hoja de estilos en cascada. La ocultación de enlaces se realiza eligiendo el color negro para un enlace que de este modo no puede distinguirse del texto próximo.

Tecnología

Las páginas HTML generadas con AHA tienen cuatro partes que son ensambladas mediante un CGI:

Una cabecera generada que contiene la definición de la hoja de estilos.

Una cabecera creada por el autor que se incluye automáticamente en cada página.

Capítulo 3

El contenido propiamente dicho.

Un pie de página creado por el autor e incluido automáticamente.

AHA implementa la adaptabilidad del sistema mediante un preprocesador de páginas HTML que se vale de sentencias condicionales escritas en comentarios. Éste reconoce tres tipos de enlaces: externos (URL absoluta), incondicionales (siempre se incluyen) y condicionales (si la expresión asociada se evalúa a cierto entonces se incluye).

3.2.8 WEAR

WEAR (Moundridou and Virvou, 2002; Moundridou and Virvou, 2002; Moundridou and Virvou, 2003; Virvou and Moundridou, 2001)es una herramienta de autor para generar STI para la web, en dominios relacionados con el álgebra, que proporcionan a los alumnos una navegación adaptada anotando dinámicamente los enlaces a módulos de cursos. Arquitectura

WEAR permite al profesor la construcción de problemas, de libros de texto electrónicos y de tests de múltiples opciones. El dominio se describe en términos de variables, ecuaciones, unidades de medida, relaciones entre las variables, y toda la información necesaria para construir un problema (variables conocidas, incógnitas, nivel de dificultad,...). Los problemas serán clasificados según su nivel de dificultad, el dominio del álgebra al que está asociado y la categoría de alumnos a la que va dirigido el problema. Los libros de texto están formados por temas entre los que se establecen las relaciones es_prerrequisito_de y está_relacionado_con y se asocian a las variables del dominio.

El profesor puede definir dos tipos de problemas:

No numéricos: este tipo de problemas evalúa el conocimiento de las ecuaciones implicadas en el problema y la capacidad del alumno para decidir la influencia de cada variable sobre las otras.

Numéricos: el sistema pide al alumno el valor de una variable desconocida. Los valores de las variables de las que depende son introducidos por el instructor.

El modelo del alumno está formado por dos módulos:

A largo plazo: representa el conocimiento del alumno en el dominio que está siendo enseñado y en la resolución de ecuaciones lineales. Es un modelo de superposición formado por pares conjunto-valor en el que los conceptos son relativos a los elementos del dominio y los valores son una estimación del nivel de conocimiento para ese elemento (pobre, medio, bueno). Este modelo es actualizado en cada intervención del alumno con el sistema.

Student Modeller: es el módulo encargado de encontrar las causas de los errores de los alumnos. Cuando un alumno intenta resolver un problema el sistema le proporciona un entorno para representar la solución paso a paso. Para detectar un error se compara la solución del alumno con la generada

70


71

por el Problem Solver (soluciona ecuaciones lineales). Los errores reconocidos por el Student Modeller son:

- De dominio: errores debido al desconocimiento del dominio. Estos errores ocurren cuando el alumno introduce una ecuación diferente de la que se necesita para resolver un problema. Si la ecuación es parecida a la neceasria (p.ej. u=d*t en vez de u=d/t) entonces el error se clasifica como “relaciones erróneas entre variables.

- Matemáticos: errores debido al desconocimiento de la resolución de ecuaciones. Pueden ser errores de cálculo, al despejar la variable desconocida, etc.

Los conceptos que no puedan ser evaluados mediante problemas serán evaluados mediante tests.

El módulo pedagógico está compuesto por una herramienta que resuelve sistemas de ecuaciones lineales (Problem Solver) y otra que proporciona al estudiante ayuda y consejos durante la resolución de ejercicios (Advice Generator) Funcionamiento

WEAR tiene una interfaz que opera de dos modos: instructor y co-estudiante. En ambos casos hay un agente antropomórfico (animado) que proporciona mensajes hablados al alumno. La diferencia radica en que en el modo instructor los mensajes son más formales que en el modo co-estudiante.

WEAR genera STI para la web que no ofrecen al alumno ninguna planificación de tareas. El alumno es libre de seleccionar la siguiente acción (hacer un problema, leer un texto del libro o hacer un test). Para facilitarle esta elección el sistema cuenta con técnicas de anotación de enlaces. Al lado de cada enlace aparece un icono que indica al alumno el estado actual de los problemas disponibles y de los temas.

El módulo pedagógico interviene cuando la situación lo requiere para ofrecer al alumno ayuda o pistas durante la resolución de ejercicios. Tecnología

La implementación del sistema está basada en una arquitectura cliente-servidor en la que tanto alumnos como profesores interactúan a través de un navegador. Todos los componentes, excepto el Problem Solver que está hecho en Prolog, están desarrollados con Java.

3.2.9 Resumen

Los sistemas analizados presentan una serie de similitudes relativas a su arquitectura. Todos incluyen una red semántica de conceptos en las que se representan diferentes relaciones y una red de hipertexto (esquema de un libro de texto). La forma más común de indexación es por páginas (una página incluye varios conceptos). Todos los sistemas estudiados (excepto ELM-ART y WEAR) son genéricos, es decir, han sido diseñados para cualquier dominio.

Capítulo 3

A pesar de estas coincidencias existen algunos aspectos que los hacen sustancialmente diferentes desde el punto de vista del usuario. Uno de ellos hace referencia a los recursos educativos de los que dispone el usuario. Todos los sistemas analizados incluyen un libro de hipertexto, estructura básica que, junto con una red de conceptos, conforma el modelo del dominio. Acompañando al libro la mayoría de los sistemas incluyen alguna herramienta para la evaluación del alumno, bien sean tests, problemas o algún entorno de simulación, cuyos resultados son usados para la actualización del modelo del alumno y por lo tanto para aplicar las técnicas de adaptación. En la Tabla 10 se observa que tan sólo MetaLinks carece de herramienta de evaluación y en consecuencia tampoco gestiona ningún modelo de conocimiento del usuario. Su modelo del alumno es un histórico que utiliza para mostrar al usuario una tabla de contenidos anotada (marcando las páginas visitadas).

Todos los sistemas analizados, excepto ELM-ART, carecen de herramientas de comunicación con un tutor humano y/o con otros usuarios (correo, chat y foros de discusión, etc.) que, por el contrario, suelen estar presente en la mayoría de los LMS.

Los modelos de conocimiento del alumno son de superposición. Algunos sistemas, como ELM-ART, incluyen modelos de varias capas y abiertos. Es usual que algunos sistemas (DCG, InterBook, MetaLinks, AHA) completen los datos del alumno con información acerca de las páginas visitadas (orden, tiempo, frecuencia, etc.). Basándose en los datos del modelo del alumno los sistemas adaptan al usuario tanto el material proporcionado en cada página (presentación) como los enlaces a otras páginas (ayuda a la navegación).

En cuanto a las técnicas de adaptación y planificación aplicadas en estos sistemas, se podrían establecer dos grupos: 1) reglas basadas en las relaciones del modelo del dominio (prerrequisito principalmente) y 2) reglas heurísticas extraídas de la experiencia de profesores y que basan sus decisiones en las notas de los alumnos y su interacción con el sistema (páginas visitadas, principalmente). El sistema DGC representa una excepción al utilizar como algoritmo de planificación una modificación del AO*.

En resumen, podría mencionarse como una de las principales carencias de la mayoría de los WILE la escasez de servicios ofrecidos a los usuarios. Además, los recursos incluidos en ellos, desde el material pasando por las herramientas de adaptación, evaluación, etc., están tan acoplados que son difícilmente reutilizables, este hecho se aparta de las tendencias actuales dentro del campo de los sistemas educativos de crear materiales independientes de la plataforma que los genera y mantiene, y se opone diametralmente al concepto de LO ((IEEE, 2005)) aceptado por la comunidad internacional. Esta falta de flexibilidad es debida a que suelen ser sistemas monolíticos estrechamente dependientes de la estructura del dominio y la presentación del material lo que condiciona las estrategias pedagógicas usadas.

Tabla 10 Características de algunos WILE. (las casillas en blanco indican que el sistema no posee esa característica, las marcadas con ~ indican que no se tienen detalles acerca de su implementación).

72


73

RECURSOS EDUCATIVOS MODELO DEL DOMINIO

MODELO DEL

ALUMNO

TÉCNICAS DE

ADAPTACIÓN

TECNOLOGÍAS DE

DESARROLLO

lect

ura

Ej

erci

cios

Te

st

Ayu

da

Sim

ulac

ión

Com

unic

ació

n

Red

sem

ántic

a

Red

de

hipe

rtex

to

Gen

éric

o

Inde

xaci

ón

Con

ocim

ient

o H

istó

rico

Apt

itude

s

Pres

enta

ción

Ayu

da a

la

nave

gaci

ón

ELM-ART X X X Xes_un parte_de prerrequisito

X Fragmentos X X X CL-HTTP CGI

DCG X X

and/or agregación generalización analogía implicación

X X Páginas X X X X

C++ OpenScript ToolBook Java

CALAT X X X sub-objetivo X X Páginas ~ X X

CGI HTML Applets Java VRLM Shockware

InterBook X X X ~ X X Páginas X X X X CL-HTTP CGI

MetaLinks X X X X X X FileMaker Pro Server DHTML

AHA X X lista de conceptos X X ~ X X X X CGI

WEAR X X X

variables, incógnitas, unidades de medida... prerrequisito está_ relacionado_con

X X X Java Prolog

3.3 Los sistemas inteligentes distribuidos en la web

El afán por crear sistemas educativos inteligentes más modulares y flexibles, en contraposición a las compactas arquitecturas tradicionales, junto con el auge de la web como plataforma de desarrollo y distribución de sistemas educativos, ha llevado a numerosos investigadores a plantearse el desarrollo de sistemas distribuidos, entendiendo como tal aquellos en el que entidades software comunican y coordinan sus acciones mediante paso de mensajes.

Los trabajos en esta línea abarcan desde la utilización de lenguajes, modelos y herramientas de programación distribuida para el desarrollo de sistemas educativos hasta la aplicación de técnicas de Inteligencia Artificial Distribuida para la construcción de sistemas educativos multi-agentes (SMA) (véase capítulo 4).

Capítulo 3

A continuación se describen algunos de los trabajos de la última década orientados a la construcción de sistemas educativos distribuidos, compuestos por entidades software más o menos independientes. Los dos primeros apartados no son sistemas web, pero se han incluido en esta revisión ya que representan los primeros intentos por descomponer la arquitectura de un STI en módulos independientes. El resto de sistemas son ejemplos de sistemas multi-agentes para la web.

3.3.1 QUIZ

QUIZ (Futtersack and Labat, 1992) es un STI distribuido para enseñar a envidar en el bridge a jugadores de cualquier nivel y experiencia. Este sistema plantea una situación de aprendizaje en la que el alumno interactúa con un equipo de profesores (agentes), cada uno especializado en una tarea pedagógica, que cooperan para lograr un objetivo común. Aunque los autores emplean el término ‘agente’ en su artículo en realidad es usado para denominar a módulos o componentes software que realizan una tarea concreta sin que se aprecien en ellos ninguna de las características propias de los agentes inteligentes.

Fig. 7 Arquitectura de QUIZ (Futtersack and Labat,

1992)

Fig. 8 Estructura interna de un ‘ agente’ de

QUIZ (Futtersack and Labat, 1992)

Todos los agentes tienen una arquitectura común: una estructura para almacenar las señales recibidas de otros agentes, un grupo de buzones donde están disponibles los datos para los demás agentes, programas que representan el comportamiento del agente y un controlador que define su funcionamiento interno. QUIZ tiene cuatro agentes: un planificador pedagógico, dos sistemas expertos para resolver problemas y generar explicaciones y un generador de problemas. Los agentes usan distintos lenguajes de representación del conocimiento y paradigmas de razonamiento.

El modelo de comunicación de los agentes de QUIZ es un mecanismo de dos fases. La primera es la configuración de la red de comunicación: los agentes que desean comunicarse se reconocen entre sí enviándose señales, aunque los autores no especifican cómo son esas señales ni como deben ser interpretadas

74


75

por cada agente. La segunda fase es la comunicación propiamente dicha: el intercambio de datos entre agentes.

3.3.2 Arquitectura de Girard, Gauthier y Levesque

En (Girard et al., 1992) se aborda el desarrollo de STI definiendo una arquitectura formada por tres agentes: planificador, tutor y micromundo. De nuevo, aunque los autores empleen el término ‘agente’, éstos no se corresponden con la definición de agente inteligente sino más bien representan a una entidad software.

Fig. 9 Diagrama de interacciones entre los ‘ agentes’ (Girard et al., 1992)

Cada uno de los agentes tiene una parte de responsabilidad en el correcto desarrollo de las fases del proceso de enseñanza: planificación y evaluación. La interfaz del sistema con el profesor es el planificador (se comunican a través del currículo) mientras que el alumno se interrelaciona con el micromundo. En el proceso de planificación, el planificador, bajo demanda del profesor, fija el contenido de un curso y devuelve un currículo (que puede ser modificado por el profesor), el tutor selecciona el material didáctico y el micromundo da la forma final a las actividades de aprendizaje. En el proceso de evaluación, el micromundo traduce las acciones y reacciones del alumno. Después de ser analizadas por el tutor, éste produce un informe que envía al planificador para que se actualice el currículo. El STI almacena conocimiento acerca del dominio pedagógico y del alumno. Cada agente usa una vista parcial y con distinta representación de cada uno de estos modelos.

3.3.3 LANCA

La metodología clásica de desarrollo de sistemas basados en el conocimiento separa las fases de adquisición de conocimiento y uso del sistema. En (Frasson et al., 1996) se defiende que el aprendizaje es un proceso constructivo que implica a varios sujetos y objetos (alumno, profesor, dominio, estrategias, etc.), por lo que el proceso de adquisición de conocimiento está en constante evolución. Según Frasson et al., el desarrollo de un STI desde esta perspectiva se puede afrontar introduciendo agentes inteligentes en su arquitectura. Estos agentes, además de poseer las características básicas de un agente anteriormente mencionadas, deben ser cognitivos, esto es, deben ser capaces de aprender y descubrir nuevos hechos y/o mejorar su conocimiento. El

Capítulo 3

aprendizaje se puede alcanzar aplicando diversos métodos como algoritmos genéticos, aprendizaje automático, etc. Los tres principales componentes de un STI: el modelo del alumno, el modelo del dominio y el módulo pedagógico pueden ser construidos en forma de agentes inteligentes.

LANCA (Frasson et al., 1998) es una arquitectura para el aprendizaje a distancia basada en agentes cognitivos conectados a la red. El sistema se basa en la idea de que es prácticamente imposible cubrir todos los perfiles de alumno existentes y adaptar las estrategias de aprendizaje para cada caso. En esta arquitectura se adopta una estrategia constructiva que refleja la tendencia en educación según la cual el conocimiento debería ser el resultado de la interacción del alumno con su entorno. Además, las preguntas y soluciones relacionadas con un problema dado pueden ser útiles a otros alumnos construyendo un banco de datos común.

La arquitectura contempla cuatro tipos de agentes cognitivos: pedagógico, de diálogo, de negociación y moderador.

El agente pedagógico proporciona al alumno una estrategia pedagógica para ayudarle en una situación de resolución de un problema. Este agente pedagógico almacena las acciones de los alumnos para mejorar en el futuro la ayuda a un determinado tipo de alumno. Para ello usa: 1) un modelo del alumno; 2) un proceso STI que interpreta las acciones del alumno y las compara con un conjunto de posibles soluciones y 3) distintas estrategias de aprendizaje (libro, tutor, compañero y examinador de problemas) que pueden ser activadas por el agente pedagógico o por el alumno. El libro es un conjunto de índices del curso; el tutor, es una estrategia en la cual el sistema, a petición del alumno, le ofrece respuestas o consejos; el compañero (companion) es un homólogo virtual capaz de discutir con el alumno, darle consejos o hacer preguntas para centrar el foco de atención en algún punto y el generador de problemas (troublemaker) es un compañero especial (llamado “falso amigo”), que le propone al alumno soluciones a problemas que pueden ser erróneas, con objeto de hacer reflexionar al alumno y despertar en él una actitud crítica.

El agente de diálogo se encarga de proporcionar ayuda adicional al alumno cuando la explicación del agente pedagógico es inadecuada. Sus principales funciones son: 1) gestionar las sesiones de aprendizaje individuales y colectivas; 2) en modo síncrono, comunicarse con los alumnos a través de los agentes pedagógicos usando un chat; 3) en modo asíncrono, acceder a la base de conocimiento a través de la interfaz web; 4) dirigir las peticiones al agente negociador para pedir ayuda de otros alumnos que hayan resuelto problemas similares y 5) interrogar a los alumnos sobre qué parte de la explicación fue decisiva para alcanzar la solución y la almacenarla junto con el perfil del alumno.

El agente negociador gestiona una base de explicaciones complementarias almacenadas por los agentes de diálogo. Cada agente negociador tiene asociado un perfil de estudiante que contiene información que indica al negociador que

76


77

su alumno puede ofrecer una explicación a un agente de diálogo o a otro alumno.

Fig. 10 Arquitectura de LANCA (Frasson et al., 1998)

El agente moderador intenta valorar y mejorar el funcionamiento global del sistema. Para ello selecciona de entre todas las explicaciones dadas a los alumnos las que fueron efectivas y las almacena junto con el perfil del alumno. Además se encarga de fijar el precio de las explicaciones para los agentes negociadores y decide qué nuevas explicaciones se pueden transferir de la base de explicaciones complementarias a la base de explicaciones para poder ser ofrecidas de forma automática. La evaluación de la eficiencia de las explicaciones es realizada por un tutor humano.

3.3.4 LeCS

LeCS (Rosatelli et al., 2000) es un sistema colaborativo de estudio de casos a través de la web. El método de aprendizaje consiste en introducir un problema a través de un caso que se presenta a un grupo de alumnos que deben discutirlo y solucionarlo. El instructor del caso debe guiar el proceso.

La arquitectura de LeCS está basada en agentes y se organiza en un sistema federado. Las comunicaciones de los agentes están basadas en ACL (Agent Communication Language) y los mensajes intercambiados entre los agentes tienen formato KQLM (Knowledge Query and Manipulation Language).

Las comunicaciones entre los agentes se realizan a través de un agente facilitador, un programa especial que almacena la información sobre cada agente del sistema y encamina los mensajes.

Además de este, la arquitectura incluye otros tres tipos de agentes: de interfaz, de información y asesor. Existe un agente interfaz por cada usuario conectado. Todas las intervenciones del sistema (invitar a los usuarios a participar, controlar los límites de tiempo establecidos para resolver una parte del problema, etc.) son realizadas a través de estos agentes. El agente información

Capítulo 3

almacena el material didáctico (páginas HTML, imágenes y texto) y bases de conocimiento (dominio y representaciones de las soluciones a los casos). Por último, el agente asesor se encarga de monitorizar a los usuarios y detectar situaciones en las que el agente interfaz debería intervenir.

Fig. 11 Arquitectura LeCS (Rosatelli et al., 2000)

3.3.5 Baghera

La plataforma Baghera (Webber et al., 2001) es una arquitectura multi-agente para entornos de aprendizaje que proporciona apoyo individualizado en la resolución de problemas.

Los agentes han sido implementados usando JatLite y extendidos con un módulo que proporciona soporte para la gestión de protocolos entre agentes. La comunicación entre agentes está basada en la teoría de actos de habla del estándar FIPA-ACL.

Cada alumno tiene asignado tres agentes artificiales. El agente compañero (companion), se encarga de monitorizar las acciones del alumno y notificar a otros agentes cuando se necesita acceso a los recursos del sistema. El agente tutor toma decisiones didácticas basadas en el diagnóstico del alumno. El agente mediador selecciona un módulo que resuelva determinados problemas y le envía las soluciones del alumno.

Cada profesor es ayudado por dos agentes. Un agente compañero (companion) que realiza tareas de interfaz relacionadas con la comunicación con otros agentes artificiales o humanos como la edición y distribución de nuevas actividades a los alumnos y la supervisión de su trabajo. El agente asesor ayuda al profesor en las trareas de creación y distribución de nuevo material.

3.3.6 I-HELP

I-Help (Vassileva et al., 2003) es un entorno colaborativo, multi-agente y distribuido, que proporciona a los alumnos acceso a diferentes recursos de ayuda (de compañeros, expertos, foros de discusión, FAQ, etc.)

La arquitectura de I-Help está basada principalmente en dos tipos de agentes: personales (de usuarios humanos) y aplicaciones (de aplicaciones software). Estos agentes usan una ontología común y un lenguaje de

78


79

comunicación. Cada agentes gestiona los recursos del usuario o la aplicación a la que representan. Los agentes comparten una taxonomía para indexar los recursos de información basados en conceptos y eventos (laboratorios, tareas y exámenes).

Fig. 12 Arquitectura de I-Help (Vassileva et al., 2003)

Los agentes personales mantienen modelos parciales del usuario al que representan. Estos modelos contienen características cuyos valores son establecidos explicítamente por el usuario. Durante la negociación un agente personal crea modelos de los demás agentes y tiene en cuenta las relaciones previas entre los usuarios.

Los agentes de aplicación construyen sus propios perfiles de usuario representando características relevantes del usuario en el contexto de la aplicación basándose en la interacción con el usuario y usando técnicas tradicionales de modelado de usuario.

Los agentes de diagnóstico son un tipo especial de agente de aplicación que crea modelos de usuario en un área de conocimiento particular, para un propósito específico, y con una determinada estructura. Por ejemplo un agentes que monitoriza las acciones del alumno, otro que propone exámenes o formularios de auto-evaluación.

El agente intermediario (matchmaker o broker) gestiona colecciones de modelos de usuarios para determinada población de usuarios. Este agente se encarga de localizar a los agentes que poseen los recursos relativos a un determinado concepto o a los usuarios que saben acerca de ese tema.

Cuando un usuario necesita ayuda acerca de un tema se la solicita al agente intermediario (a través de su agente personal) que intenta localizar algún recurso electrónico. Si esta búsqueda no da resultado, el intermediario genera

Capítulo 3

una lista ordenada de los usuarios que están conectados y que saben algo del tema. El agente personal negociará con los agentes personales de los usuarioas de la lista. Si la negociación tiene éxito se abrirá un chat entre los usuarios. Cuando acaban cada alumno evalúa al otro y esta información se almacena en los agentes personales de ambos y en el intermediario.

3.3.7 Resumen

Aunque existen otras propuestas, en este apartado se han descrito a modo de ejemplo seis sistemas educativos distribuidos desarrollados durante la última década. La Tabla 11 es un compendio de sus características más relevantes.

Los primeros STI desarrollados en esta línea (QUIZ y la arquitectura Girard et. al.) eran sistemas modulares pero cerrados, es decir, no extensibles. Los módulos que conforman ambos sistemas han sido específicamente diseñados para su arquitectura y no pueden funcionar fuera de ella ni reutilizarse en otro sistema.

Los sistemas LeCS y Baguera son SMA (Sistemas Multi-Agentes) que distribuyen entre varios agentes las tareas propias de un STI. LANCA e I-Help presentan una aportación más destacable al campo de los STI: el uso de agentes cognitivos (Frasson et al., 1996), capaces de aprender y descubrir nuevos hechos y/o mejorar su conocimiento utilizando las acciones de los alumnos y sus opiniones acerca de su funcionamiento.

LeCS e I-Help son sistemas colaborativos. El primero de ellos utiliza el aprendizaje basado en casos que debe ser guiado por un instructor. El papel de los agentes es controlar las sesiones (invitar a los usuarios a participar, obligar a respetar los límites de tiempo para la resolución de un problema, etc.). En I-Help la tarea de los agentes es gestionar las ayudas cuando el usuario la solicita, localizando dentro del sistema la más adecuada a cada situación. Los alumnos colaboran libremente y no se aplica ningún tipo de adaptación ni control de la instrucción.

LANCA centraliza todas las tareas de instrucción en un tipo de agente al que denomina pedagógico. Ese agente encapsula cuatro tipos de tareas educativas que va proponiendo al alumno basándose en el modelo que él mismo almacena. Del mismo modo que I-Help, el sistema cuenta con otros agentes que proporcionan al alumno ayuda adicional cuando las explicaciones del agente pedagógico son inadecuadas.

Todos estos sistemas, excepto I-Help, son SMA centralizados, con los inconvenientes que este hecho conlleva. Son sistemas cerrados en los que la adición de nuevos agentes puede exigir un rediseño del sistema. Todos ellos, incluido I-Help, ofrecen escasas alternativas desde el punto de vista pedagógico en cuanto a funcionalidad, diversidad de tareas educativas y estrategias de instrucción.

80


81

Tabla 11 Características de algunas arquitecturas para STI basadas en agentes (X indica que el sistema posee la característica correspondiente y ~ que no existen detalles acerca de su implementación)

DOMINIO AGENTES O

COMPONENTES SOFTWARE

RECURSOS EDUCATIVOS

ABI

ERTO

ES

PEC

IFIC

AC

IÓN

DEL

PR

OTO

CO

LO D

E C

OM

UN

ICA

CIÓ

N

PRO

TOC

OLO

DE

CO

MU

NIC

AC

IÓN

BA

SAD

O

EN...

ESPE

CÍF

ICO

GEN

ÉRIC

O

NÚ

MER

O

TIPO

CO

GN

ITIV

OS

LEC

TUR

A

PRO

BLEM

AS

EVA

LUA

CIÓ

N

AYU

DA

CA

SOS

CO

MU

NIC

AC

IÓN

QUIZ X X 4

Pedagógico Explicaciones Generador de ejercicios Ejecutor de problemas

X X

GIRARD, GAUTHIER & LEVESQUE

X X 3 Planificador Tutor Micro mundo

LANCA ~ X 4

Pedagógico Diálogo Negociación Moderador

X X X X

LeCS ~ FIPA/ACL

KQLM X 3

Interfaz Información Asesor

X X

Baguera ~ KQLM X 5 Compañero Tutor Mediador

X

I-Help X ~ KQLM X 4

Personales Aplicación Diagnóstico Intermediario

X X

3.4 Integración de diversos sistemas inteligentes en la web

El desarrollo de aplicaciones educativas es complejo y costoso. Esta tarea es multidisciplinar y requiere la colaboración de expertos en el dominio que se va a enseñar, en la tecnología de desarrollo y en pedagogía. Todo esto hace que afrontar la construcción de un entorno inteligente de aprendizaje sobre la web desde cero resulte una tarea de enormes dimensiones. El objetivo principal de esta tesis es aportar una solución a este problema proponiendo una metodología y un marco de trabajo para el desarrollo de WILE basados en la integración y reutilización de sistemas ya construidos.

Los sistemas educativos inteligentes son, en muchos casos, el resultado de años de investigación centrados en el desarrollo de una tarea pedagógica, el estudio de un dominio concreto o la aplicación de determinada estrategia de enseñanza. Por ejemplo, ELM-ART (Brusilovsky et al., 1996) es un curso adaptativo de LISP que incluye un módulo para la realización de problemas de

Capítulo 3

programación en LISP o AlgeBrain Tutor (Alpert et al., 1999) es un sistema que ofrece un entorno para la práctica y el desarrollo de habilidades algebraicas. Uno de los objetivos que se plantea en esta tesis es la posibilidad de reutilizar este tipo de software, de gran calidad y con sólidos fundamentos teóricos, para la construcción de nuevos sistemas. Por ejemplo, un profesor podría desarrollar un curso de LISP usando DCG (Dynamic Course Generation) (Vassileva and Deters, 1998) para generar las páginas de teoría; ELM-ART para la realización de problemas y CATGlobal (Promissor, 2003) para evaluar al alumno.

Dada la imposibilidad de reutilizar material incluido en algunos sistemas separado de los procedimientos para su presentación, algunos investigadores han centrando sus esfuerzos en desarrollar arquitecturas que permitan la reutilización de programas educativos completos, es decir, que traten un sistema educativo como un LO que pueda ser reutilizado e integrado en distintos entornos de aprendizaje. El primer paso fue la integración de dos sistemas autónomos ya existentes que colaboraran entre sí para alcanzar un fin común, como la arquitectura de (Ritter and Koedinger, 1996) y la integración de los sistemas InterBook y PAT Online realizada por (Brusilovsky et al., 1997). Los trabajos más recientes se centran en la construcción de marcos de trabajo que permitan componer un entorno de aprendizaje integrando un número indeterminado de aplicaciones educativas externas. En esta línea se desarrollan los proyectos ActiveMath (Melis et al., 2001) y KnowledgeTree (Brusilovsky and Nijhavan, 2002).

3.4.1 Arquitectura de Ritter y Koedinger

Ritter y Koendinger (Ritter and Koedinger, 1996) describen un STI (no web) que es capaz de insertarse dentro de un entorno de aprendizaje “no inteligente” como un componente más de la aplicación proporcionando al alumno guía y ayuda a lo largo del proceso de aprendizaje. En su trabajo presentan dos prototipos de STI integrados en entornos de aprendizaje preexistentes y, basándose en el proceso de desarrollo y los resultados obtenidos, generalizan y describen una arquitectura estándar para la creación de este tipo de sistemas que posee cuatro módulos:

Herramienta (Tool): es un programa educativo usado para realizar una determinada tarea para un dominio particular (un entorno gráfico para resolver problemas de geometría, una hoja de cálculo para resolver problemas de álgebra, etc.). Es el entorno de aprendizaje “no inteligente” en el que se insertará el STI. Para establecer la comunicación con el tutor, es necesario que la herramienta pueda emitir eventos semánticos correspondientes a todas las acciones del usuario, es decir, debe ser capaz de describir el significado de cada acción.

Agentes Tutores (Tutor Agents): piezas de software que monitorizan las acciones del usuario. Su tarea es reconocer errores durante la ejecución de un problema y dar ayuda al alumno. El tutor debe ser capaz de evaluar y responder a las acciones del alumno. No tienen interfaz, sus funciones son accesibles a través de un menú integrado en la propia herramienta.

82


83

Gestor del Curriculum (Curriculum Manager): es responsable de decidir qué problema se le presenta al alumno.

Traductor (Translator): gestiona las comunicaciones entre el tutor y la herramienta de modo que ambos puedan ser diseñados sin necesidad de conocer los detalles del otro. El traductor intercepta las acciones del usuario, las traduce en triplas selección-acción-entrada y se las envía al tutor. Asimismo, intercepta los mensajes del tutor al alumno y los interpreta conforme a las capacidades de la herramienta que es quien debe mostrar el resultado.

Fig. 13 Arquitectura general (Ritter and Koedinger, 1996)

El estándar definido por Ritter y Koendinger incluye la definición de los mensajes que se intercambian el tutor y la herramienta. Los recibidos por el tutor indican qué acción pedagógica debe realizar: comenzar-problema, procesar-acción-herramienta, proceso-ayuda, proceso-hecho, siguiente-paso y reproducir-estado-herramienta. Los mensajes enviados por el tutor se usan para comunicarse con el usuario en respuesta a una petición de ayuda o una acción concreta: verificar, establecer-señal (flag), quitar-señal (unflag), apuntar (point-to), deshacer (undo), enviar-mensaje, seleccionar, actualizar-evaluación, comenzar-actividad, realizar-acción-usuario y obtener-valor-usuario. El gestor del curriculum es el encargado de aceptar el método actualizar-evaluación para actualizar el modelo del alumno.

3.4.2 Integración de Interbook y PAT Online

Otra propuesta interesante es la realizada en (Brusilovsky et al., 1997). Los autores llevan a cabo una aproximación a un STI distribuido integrando dos sistemas adaptativos: InterBook (ver 3.2.4) y PAT Online (sistema que resuelve

Capítulo 3

problemas de álgebra). La interacción entre estos dos sistemas se basa en el intercambio de dos tipos de información: datos acerca de la evaluación de los alumnos y material educativo. La definición del protocolo de comunicación intenta alcanzar dos objetivos: el diseño de cada sistema no debe asumir que los alumnos pueden acceder al otro, y el protocolo debe ser lo bastante genérico como para permitir interactuar con otros entornos.

3.4.3 Intelligent Tutoring Applets (ITA)

Kinshuk y Patel (Kinshuk and Patel, 1997a; Kinshuk and Patel, 1997b) proponen un marco de trabajo basado en el concepto de ITT (Intelligent Tutoring Tool). Los ITT son ITS que abarcan un único concepto (topic) o un pequeño cluster de conceptos relacionados con un nivel de inteligencia rudimentario que puede ser mejorado combinando un ITT con un TST (Teaching Support Tool) como Marker Software. El ámbito de un ITT puede ser ampliado combinando varios de ellos en una red de ITT. Podría decirse que un ITT es una herramienta educativa fine-grained que mantiene un diálogo simple con el alumno proporcionando un refuerzo a un nivel de detalle adecuado en vez de intentar construir mensajes de retroalimentación complejos. Los principales componentes de un ITT son: una base de conocimiento, un modelo del alumno, un módulo experto, un módulo tutor, un generador de preguntas aleatorio y un selector del modo de aplicación (student, lecturer, course administrator).

El desarrollo de algunos ITTs proporcionó a sus creadores la información necesaria para formular una metodología para construir un generador de sistemas tutores de propósito general. El generador ayuda a los profesores a producir ITA (Intelligent Tutoring Applets) para cualquier disciplina numérica. Los ITA construidos formarán parte de un almacén de conocimiento y pueden ser unidos en distintas configuraciones para crear ITS.

3.4.4 ActiveMath

ActiveMath (Melis et al., 2001) es un sistema para la web que genera cursos de matemáticas adaptados a los objetivos, preferencias, capacidades y conocimiento del alumno. El dominio está representado por una red semántica de conceptos (definiciones, axiomas, asertos, etc.) relacionados entre sí por las relaciones dependencia matemática, prerrequisito pedagógico y referencia. Cada concepto tiene ítems asociados (ejemplos, ejercicios, motivaciones y prueba de un aserto). ActiveMath usa una representación del conocimiento basada en XML (una extensión de OMDoc, Open Markup format for Mathematical Documents).

ActiveMath, además de componentes internos al sistema (planificador, modelo del alumno, etc.), integra sistemas matemáticos externos como el sistema de álgebra MAPLE o el planificador de pruebas ΩMEGA. Los sistemas se conectan a través de un representante (proxy) y el agente (broker) Mathweb. Cada vez que un usuario solicita la realización de un ejercicio, se eleva una petición a un modulo llamado gestor de sesión (session-manager) que crea un

84


85

objeto Proxy. Dicho objeto se encarga de conectarse al sistema matemático correspondiente, intercambiar mensajes entre éste y la interfaz de usuario, recoger los resultados del ejercicio y enviárselos al modelo del alumno (Libbrecht et al., 2001). Los sistemas que quieran formar parte de ActiveMath deberán abstraer la funcionalidad de las conexiones y ofrecer acceso remoto a través de la arquitectura broker Mathweb.

Fig. 14 Arquitectura de ActiveMath (Melis et al., 2001)

Mathweb (Franke and Kohlhase, 1999) es un sistema software que conecta diversos servicios matemáticos a través de un bus común: Mathweb-SB (Zimmer et al., 2003). Mathweb proporciona la funcionalidad para convertir sistemas de pruebas de teoremas en servicios integrados de forma homogénea en un entorno de desarrollo de pruebas. La implementación del bus se realiza sobre un modelo parecido a CORBA en el que un agente (broker) central proporciona información de encaminamiento y autenticación a los servicios matemáticos. Mathweb especifica la interfaz de los servicios.

3.4.5 KnowledgeTree

Como último ejemplo, mencionar KnowledgeTree (Brusilovsky and Nijhavan, 2002), una arquitectura distribuida de aprendizaje adaptativo sobre la web basada en la reutilización de actividades educativas. La arquitectura cuenta con tres módulos principales: servidor de actividades (activity server), un portal de aprendizaje (learning portal) y un servidor del modelo del alumno (student model server). El portal de aprendizaje, permite a un profesor diseñar un curso y gestionar la interacción del alumno con el curso. El servidor de actividades almacena y distribuye actividades adaptativas y permite a los portales conectarse y usar aquellas seleccionadas por los alumnos. El servidor del modelo del alumno recopila datos acerca del rendimiento del alumno de cada portal y de cada servidor que pueden ser usados por las actividades adaptativas para personalizar su comunicación con el alumno.

Actualmente el sistema cuenta con cuatro servidores de actividades tres de ellos para el dominio de la programación.

Capítulo 3

Fig. 15 Arquitectura de KnowledgeTree (Brusilovsky and Nijhavan, 2002)

3.4.6 Resumen

Cuando hablamos sobre el desarrollo de entornos de aprendizaje la reutilización de herramientas educativas como LO, la independencia del dominio, la interoperabilidad entre los sistemas y la capacidad de extensión (carácter abierto) son características fundamentales.

Es obvio que la independencia del dominio es necesaria si se quiere desarrollar un marco de trabajo que permita la construcción de distintos entornos de aprendizaje. Por otro lado si se pretende la integración dinámica de programas externos, la interoperabilidad de los mismos se convierte en un punto clave del diseño, haciendo necesario el desarrollo de protocolos de comunicación estándares y genéricos que permitan a cualquier sistema integrarse en el marco de trabajo sin que ello afecte al resto de elementos. Este es el punto más débil de los sistemas analizados.

El tutor plug-in, de Ritter y Koendinger, y la interconexión de PAT Online e InterBook, de Brusilovsky et. al., constituyen los primeros intentos de integrar dos aplicaciones independientes para formar un único sistema educativo. Ambos tratan de construir un sistema instructor a partir de herramientas existentes y de establecer un protocolo genérico de comunicación. Aunque las dos propuestas se reducen a dos componentes y no se pueden extender, especifican de forma detallada el intercambio de mensajes entre los componentes.

Recientemente se están desarrollando sistemas como ActiveMath o KnowledgeTree que tratan de definir marcos de trabajo en los que diferentes componentes puedan ser integrados para generar un WILE. Estos dos sistemas son definidos por sus autores como abiertos, aunque en ninguno de los trabajos se muestra cómo insertar y eliminar LO del sistema, obviándose importantes detalles al respecto.

ActiveMath cuenta con entidades software distribuidas y autónomas no genéricas, pertenecen al dominio de las matemáticas y utilizan un lenguaje específico (OMDoc) para la representación de objetos matemáticos. Aunque los autores describen en parte el protocolo de comunicación que deben seguir los

86


87

componentes, ActiveMath sólo se comunica con Mathweb, sistema en el que delega la tarea de integración de sistemas y todos los problemas relativos a la comunicación con los mimos. A pesar de que Mathweb actualmente gestiona diversos servicios matemáticos, no cuenta con un protocolo estándar para la integración de cualquier componente que quisiera formar parte del sistema. El sistema es poco flexible, no es aún una arquitectura plug and play.

KnowledgeTree proporciona protocolos para comunicar sus servidores de actividades con los portales y el modelo del alumno, pero estos han sido diseñados específicamente para esta plataforma y están lejos de poder ser aplicables a cualquier tipo de componente existente en la web.

En cuanto a la variedad de recursos educativos ofertados por estos sistemas los más comunes son páginas con contenido, módulos para la resolución de problemas y generación de ayuda y explicaciones. Ritter y Koendinger no concretan el tipo de actividad, aunque la limitan a una sola. El único sistema que parece permitir un número indeterminado de tipos de actividades es KnowledgeTree, aunque sus autores no mencionan la implementación ni uso de ningún ejemplo concreto.

Tabla 12 Características de algunas arquitecturas para STI basadas en componentes (X significa que el sistema posee la característica correspondiente y ~ que no existen detalles acerca de su implementada)

MODELO DEL ALUMNO DOMINIO COMPONENTES RECURSOS

EDUCATIVOS

WEB

ABI

ERTO

ESPE

CIF

ICA

CIÓ

N D

EL

PRO

TOC

OLO

DE

CO

MU

NIC

AC

IÓN

PRO

TOC

OLO

DE

CO

MU

NIC

AC

IÓN

BA

SAD

O

EN...

CEN

TRA

LIZA

DO

DIS

TRIB

UID

O

ESPE

CÍF

ICO

GEN

ÉRIC

O

REU

TILI

ZABL

ES

DIS

TRIB

UID

OS

AU

TÓN

OM

OS

LEC

TUR

A

PRO

BLEM

AS

EVA

LUA

CIÓ

N

AYU

DA

SI

MU

LAC

IÓN

C

OM

UN

ICA

CIÓ

N

(Ritter and Koedinger, 1996)

X Applet-events X X X X

(Brusilovsky et al., 1997) X X X X X X X X X

ITA X X ~ X X

ACTIVEMATH X ~ ~ XML-RPC

CORBA X X X X X X X

KNOWLEDGETREE X ~ ~ HTTP X X X X X X

3.5 Conclusiones

Los sistemas educativos inteligentes no constituyen la totalidad de la oferta educativa para Internet. Existen sistemas de gestión de cursos comerciales (LMS, Learning Management Systems) de amplia aceptación en la comunidad educativa. Los LMS ofrecen herramientas para la creación y gestión de un entorno de aprendizaje integral, desde la matriculación de alumnos, las tareas

Capítulo 3

administrativas, la creación y mantenimiento de material, tutorías, exámenes, etc., pero no proporcionan técnicas de adaptación de la instrucción. El profesor es el que define el currículum, la secuencia de instrucción y selecciona el material educativo. A pesar de esta importante carencia, en la actualidad son las aplicaciones más usadas para la educación a través de la web. En (Weber and Brusilovsky, 2001) se apunta como principal motivo su versatilidad. Sistemas como WebCT y BlackBoard son capaces de ofrecer casi cualquier función que se pueda dar en un entorno de enseñanza (exámenes, material avanzado, sistemas de comunicación para profesores y alumnos como chats, foros de discusión o correo electrónico, herramientas para monitorizar el estado de los alumnos, etc.), cubriendo las necesidades reales de profesores, alumnos y administradores.

Los WILE, al contrario que los LMS, son sistemas que personalizan de forma automática el proceso de enseñanza, adaptando el material y las técnicas pedagógicas del sistema a las características particulares de un alumno. Estos sistemas ofrecen una instrucción de mayor calidad que los LMS gracias a la aplicación de las técnicas desarrolladas en el campo de los STI. El problema es que rara vez un sistema inteligente iguala la oferta de LO de un LMS.

Otro de los principales obstáculos en la expansión de los WILE es su elevado coste de desarrollo, tanto en recursos humanos como en tiempo. Para la creación de un sistema educativo eficiente es necesario contar con un equipo interdisciplinar formado por expertos en el dominio, pedagogos y técnicos. El resultado obtenido suele ser un sistema: a) de gran calidad y con sólidas bases teórico-pedagógicas y b) estrechamente ligado al dominio de enseñanza y a la experiencia de los profesores participantes en la fase de adquisición de conocimiento, lo que lo hace poco flexible y difícilmente aplicable a un dominio, grupo de alumnos, o estrategia de enseñanza diferentes de para los que fue creado.

De estas reflexiones se puede extraer un conjunto de características que serían deseables en una marco de trabajo para la construcción de entornos de aprendizaje:

- Adaptación de la instrucción al alumno, el sistema debe proporcionar técnicas y herramientas para la adaptación de la instrucción.

- Reutilización de sistemas educativos, debe permitir la reutilización de sistemas educativos completos (conocimiento y funcionalidad).

- Versatilidad, los sistemas susceptibles de ser reutilizados constituirán un conjunto razonablemente completo de LO que puedan ser usados para la construcción de distintos entornos de aprendizaje inteligentes.

- Carácter abierto, debe ser extensible, permitiendo la inserción y eliminación dinámica de LO.

- Carácter distribuido, todos sus componentes pueden estar localizados en distintas computadoras de Internet.

88


89

- Carácter genérico, debe permitir la creación de WILE para un amplio rango de dominios y tipos de alumnos.

- Bajo coste de desarrollo, la construcción de entornos de aprendizaje inteligentes debe llevarse a cabo en un tiempo razonable y sin la necesidad de intervención de un numeroso grupo de expertos.

Esta tesis defiende el desarrollo de marcos de trabajo para la construcción de entornos de aprendizaje que permitan reutilizar e integrar otros sistemas educativos completos (sin separar el material de los métodos de presentación). Por ejemplo, existen sistemas eficientes, como los ya mencionados ELM-ART (curso adaptativo de LISP) o AlgeBrain Tutor (problemas de álgebra), que quizá son demasiado específicos, pero que se pueden integrar con otros para formar parte de un mismo entorno de aprendizaje. De este modo se pretende unir lo mejor de ambos enfoques: por un lado la calidad de una enseñanza personalizada y por otro la amplia oferta de servicios y recursos educativos de los LMS, además de la posibilidad de reutilizar los mismos recursos para la construcción de distintos entornos de aprendizaje.

Los primeros trabajos en esta línea, como por ejemplo el sistema QUIZ o la arquitectura de Girard et. al., se enfocaron en la distribución de las tareas propias de un STI en módulos que interactuaran entre sí. De este modo se pretendía descomponer en módulos lo más independientes posible las monolíticas arquitecturas que, hasta principios de los noventa, habían caracterizado a los sistemas educativos inteligentes.

Siguiendo esta línea nos encontramos con ejemplos interesantes en el campo de la Inteligencia Artificial Distribuida (IAD). En este capítulo se han revisado algunas aplicaciones de los Sistemas Multi-Agentes (SMA) al área de los STI. Según (Canut et al., 1999) algunas de las razones que justifican la adopción de la tecnología multi-agente en el desarrollo de arquitecturas de STI son: a) en un STI el proceso de adquisición de conocimiento debe ser dinámico y evolucionar a lo largo del tiempo; b) un STI necesita una representación distribuida del conocimiento y c) la diversidad de expertos necesaria para su construcción.

Los SMA se han usado con éxito en entornos colaborativos (LeCS, I-Help), que defienden la interacción social en el aprendizaje concediendo gran importancia al conocimiento adquirido a través de la negociación con los demás. En estos sistemas cada alumno es representado por un agente inteligente que negocia con el resto de agentes del sistema las interacciones del alumno con los demás y en los que todos cooperan para alcanzar un determinado objetivo de aprendizaje.

Otra aportación interesante radica en la capacidad de los agentes de aprender y descubrir nuevos hechos. En un sistema educativo, la interacción de los agentes con alumnos y profesores puede ayudar a mejorar sensiblemente el conocimiento global del sistema.

Sin embargo, casi todos los sistemas analizados en este capítulo no permiten la entrada y salida de nuevos agentes, característica importante si queremos tener un marco de trabajo que compita con los LMS en el número de servicios

Capítulo 3

ofertados. Esto quizá sea debido a que el desarrollo e implementación de este tipo de sistemas es aún bastante costoso. A pesar de los avances en el desarrollo de estándares (FIPA, KQLM, etc.) y marcos de trabajo (FIPA-OS, JADE, etc.) integrar cualquier tipo de recurso educativo (sea o no agente) existente en la web, independientemente de su naturaleza e implementación es, en la práctica, un objetivo difícil de conseguir.

A partir de los 90, comienzan a aparecer tecnologías que permiten el desarrollo de aplicaciones distribuidas y basadas en componentes software, entendidos como unidades binarias de producción, adquisición y desarrollo independientes que interactúan para formar un sistema en funcionamiento. Estas tecnologías se empezaron a aplicar en la construcción de plataformas educativas que integrasen diversos sistemas educativos independientes. Los primeros intentos consistieron en integrar dos sistemas ya construidos (una herramienta educativa “no inteligente” con un STI o PAT Online e InterBook) y a partir de ahí generalizar los protocolos de comunicación necesarios. Los sistemas ActiveMath y KnowledgeTree se encuentran en la línea de trabajo planteada en esta tesis pero presentan dos importantes limitaciones. En primer lugar no proporcionan mecanismos para la inserción y eliminación de recursos de forma dinámica. En segundo lugar, no definen protocolos estándares y genéricos de comunicación que permitan la interoperabiliad de los recursos.

90

Capítulo 4 TÉCNICAS PARA EL DESARROLLO DE SISTEMAS INTELIGENTES DISTRIBUIDOS EN LA WEB

Una aplicación distribuida se define como un conjunto de procesos que están distribuidos entre los nodos de un sistema distribuido y trabajan conjuntamente como un todo para resolver un problema común, entendiendo por sistema distribuido una colección de ordenadores independientes conectados en red que se muestra a los usuarios como un sistema simple coherente. Un sistema distribuido (hardware o software) fácilmente extensible se denomina sistema abierto (open system).

El estudio realizado en el Capítulo 3 revela que las últimas tendencias en el campo de los sistemas educativos inteligentes para la web apuntan a la creación de entornos de aprendizaje que integren distintos sistemas ya construidos. Desde el punto de vista de la implementación, este tipo de WILE son aplicaciones distribuidas y abiertas sobre la web (sistema distribuido) formada por un conjunto de aplicaciones educativas externas y objetos de aprendizaje cuyo objetivo es llevar a cabo la instrucción personalizada de un alumno acerca de un dominio.

En esta tesis se definen e implementan los procesos e interacciones necesarios para construir un entorno de estas características por lo que se ha considerado de interés abordar en este capítulo una revisión de las tecnologías para el desarrollo de sistemas distribuidos abiertos. La Ingeniería del Software en Sistemas Distribuidos y la Inteligencia Artificial Distribuida han desarrollado a lo largo de las dos últimas décadas modelos, técnicas y herramientas para el desarrollo de sistemas abiertos que sean capaces de integrar entidades software independientes (componentes y agentes respectivamente). La implementación de MEDEA se basa en el uso de Servicios Web.

Una vez salvada la barrera tecnológica se observa que el desarrollo de entornos educativos abiertos para la web se enfrenta a aspectos relacionados con el uso de ontologías y estándares internacionales para la educación.

91

Capítulo 4

El aspecto semántico de la comunicación entre los elementos de un WILE plantea numerosos interrogantes: ¿Cómo pueden dos sistemas independientes compartir el mismo conocimiento?, ¿Cómo puede un recurso educativo “entender” lo que quiere decir el otro cuando se refiere a un concepto o a una relación del dominio? ¿Cómo pueden intercambiar material educativo o datos acerca del alumno?.

A lo largo de los últimos años han sido numerosos los esfuerzos realizados por diversas organizaciones internacionales en la creación de estándares para el desarrollo de aplicaciones educativas, desde estándares para la descripción de datos (metadatos), de modelos del alumno o elementos de evaluación (tests) hasta aspectos como la estructura y secuenciación de cursos o la propia arquitectura de los sistemas. Sin embargo, estos estándares están más orientados a la definición de LMS que de sistemas inteligentes.

En Inteligencia Artificial, la solución a este problema pasa por la creación de ontologías que describan el significado de los conceptos y relaciones del dominio y demás conocimiento implicado en el sistema. Numerosos grupos de investigación están desarrollando sus trabajos en este campo, buena prueba de ello son las sesiones del taller de trabajo “Aplicaciones de la web Semántica al aprendizaje electrónico” (Applications of Semantic web Technologies for E-Learning) (SW-EL, 2001) que se vienen celebrando en los congresos ICCE (International Conference on Computers in Education), AH (Adaptive Hipermedia), ITS (Intelligent Tutoring Systems) e ISWC (International Semantic Web Conference) a lo largo de los tres últimos años.

En relación con este campo se han dedicado importantes esfuerzos al desarrollo de lenguajes para la definición de ontologías, algunos de ellos especializados para la web, que vienen pugnando por convertirse en estándares universales.

Determinados aspectos relativos a los recursos educativos y el modelo del alumno de la metodología de desarrollo definida en esta tesis se ciñen en la medida de lo posible a los estándares más ampliamente aceptados por la comunidad internacional. Asimismo en el marco de trabajo MEDEA se usa el lenguaje OXML para la descripción de los modelos del dominio.

4.1 Modelos y herramientas para el desarrollo de sistemas distribuidos abiertos

Un sistema distribuido es aquél en el que los componentes hardware o software, localizados en computadores unidos a través de una red, comunican y coordinan sus acciones mediante paso de mensajes. Una de las características destacables en este tipo de sistemas es su carácter abierto (openess), que permite extender el sistema añadiendo y/o eliminando componentes software heterogéneos de forma dinámica.

La Programación Orientada a Objetos es el modelo usado para la construcción de sistemas cerrados sin embargo es insuficiente para los abiertos. La Programación Orientada a Componentes es una extensión de la orientación a

92

Técnicas para el desarrollo de sistemas inteligentes distribuidos en la web

93

objetos para los sistemas abiertos. Los componentes software son unidades binarias de producción, adquisición y desarrollo independientes que interactúan para formar un sistema en funcionamiento. Construir software basado en componentes, mejora la calidad e incrementa la velocidad de desarrollo y de adaptación a los cambios (Szypersky, 1999).

Para el desarrollo de un mercado de componentes es necesario definir estándares de componentes. Los estándares son útiles para establecer modelos e interfaces comunes que permitan la composición e interoperabilidad de sistemas basados en componentes. Hasta no hace mucho, la interoperabilidad entre sistemas estaba limitada a llamadas binarias al nivel de procedimientos. Cada sistema operativo define unas convenciones para las llamadas que deben ser respetadas por las implementaciones de los distintos lenguajes. Para interacciones entre procedimientos los sistemas operativos usan distintos mecanismos de IPC (Inter-Process Communication). Estos mecanismos se pueden extender fácilmente a las redes pero trabajan al nivel de bytes por lo que implementar interacciones complejas sobre ellos resultaba complicado. Como alternativa en 1984 surge el concepto de RPC (Remote Procedure Call), mecanismo ampliamente usado en comunicación distribuida que permite a una función remota ser invocada como si fuese local (Birrell and Nelson, 1984).

Sun Microsystems fue una de las pioneras en el uso de RPC cuando en 1987 desarrolló el mecanismo básico de comunicación para su sistema de ficheros en red: ONC (Open Network Computing). En ese mismo año, Apollo Computer creó el sistema RPC para su sistema operativo: NCS (Network Computing System). Dos años más tarde, en 1989, la OSF (Open Software Foundation, hoy conocida como The Open Group) recibió el reto de crear un sistema RPC. De esta propuesta, y basado en NCS, surgió DCE (Distributed Computing Environment) como mecanismo para su entorno de computación distribuida.

En paralelo al nacimiento de DCE, se funda el OMG (Object Management Group), un consorcio sin ánimo de lucro (formado por más de setecientas empresas) que produce y mantiene especificaciones para aplicaciones interoperables de empresas. El OMG se formó con el objetivo de establecer un mercado de software basado en componentes mediante la creación de especificaciones independientes del lenguaje y la plataforma. Ese mismo año, OMG comienza el desarrollo de CORBA (Common Object Request Broker Architecture), una plataforma de objetos distribuidos.

Los elementos básicos de la arquitectura CORBA son: un conjunto de interfaces de invocación (en los programas clientes del objeto remoto), un ORB (Object Request Broker) y un conjunto de adaptadores de objetos (en el lado del objeto servidor). Las especificaciones de interfaces remotos, tanto del lado cliente como servidor, se hacen en IDL (Interface Definition Language).

Un ORB es una capa de software que reside entre la aplicación y los sistemas operativos, protocolos y hardware subyacente y que encapsula los mecanismos de bajo nivel para comunicaciones. El ORB entrega las peticiones a los objetos destino (locales o remotos) y devuelve las respuestas a los clientes

Capítulo 4

que hicieron las peticiones, de modo que hace transparente la localización e implementación de un objeto, su estado de ejecución y los mecanismos de comunicación con el mismo.

El objetivo inicial de CORBA era permitir la interconexión abierta de una amplio rango de lenguajes, implementaciones y plataformas, por lo que OMG nunca estableció estándares binarios. CORBA especifica la interfaz que ha de proporcionar todo ORB pero no como ha de implementarse. Como consecuencia, implementaciones de productos subordinados al estándar CORBA no podían interoperar a nivel binario de forma eficiente y se hacía necesario el desarrollo de costosos protocolos de alto nivel. En 1996 el OMG define el IIOP (Internet Inter ORB Protocol), protocolo basado en TCP/IP que especifica como deben comunicarse los ORB de los distintos componentes.

Microsoft se une a esta carrera tecnológica tomando como punto de partida una versión modificada de DCE para el desarrollo de COM (Component Object Model), una especificación e implementación que proporciona un marco para la integración de componentes. Para que dos componentes puedan interactuar se deben ajustar a la estructura binaria especificada por Microsoft. Los procesos COM pueden ejecutarse sobre la misma máquina pero en diferentes espacios de direcciones.

DCOM (Distributed COM) es una extensión de COM que permite la interacción de componentes dispersos sobre una red. COM y DCOM están unidos en un único entorno de ejecución que proporciona tanto acceso local como acceso remoto. Mientras que COM/DCOM proporcionan la tecnología a bajo nivel que permite la interacción de componentes, OLE, ActiveX y MTS representan los servicios de aplicación de alto nivel construidos sobre COM/DCOM. OLE es usado en la creación de documentos generados desde fuentes distintas, ActiveX permite a los componentes ser embebidos en páginas web y MTS extiende COM con servicios de negocio, como transacciones y seguridad.

COM+ es el sucesor de DCOM, con características mucho más cercanas al modelo CORBA. COM+ integra servicios MTS y colas de mensajes y consigue que la programación COM sea mucho más fácil a través de lenguajes de Microsoft como Visual Basic, Visual C++ y J++.

En 1997 Sun incluyó en la distribución JDK 1.1 la especificación RMI (Remote Method Invocation). RMI proporciona la funcionalidad de un ORB. A diferencia de CORBA, el ORB de RMI está completamente integrado con Java y su entorno de ejecución, de modo que, mientras las interfaces de CORBA son descritas usando un lenguaje independiente de la arquitectura (IDL), las de RMI son descritas usando Java. Posteriormente Sun integró RMI con IIOP en su J2EE (Java 2 Platform Enterprise Edition) haciendo más fácil la interacción entre los sistemas Java y CORBA.

94


95

Tabla 13 Historia de la computación distribuida

AÑO EVENTO ORGANIZACIÓN

1984 Definición del mecanismo RPC (Birrell and Nelson, 1984)

Aparece ONC Sun Microsystems 1987

Aparece NCS Apollo Computer

Comienza el desarrollo de las especificaciones de DCE

OSF

1989 Comienza el desarrollo de las especificaciones de CORBA

OMG

1990 Comienza el desarrollo de su iniciativa RPC sobre una versión modificada de DCE

Microsoft

Aparición de DCE 1.0 OSF 1991

Aparición de CORBA 1.0 OMG

1993 Aparición de MQSeries IBM

Aparece DCOM Microsoft 1996 Aparece CORBA 2.0 incluyendo como parte de su

especificación IIOP OMG

Aparición de RMI en la distribución JDK 1.1 Sun Microsystems 1997

Aparece COM+, sucesor de DCOM Microsoft

1998

Comienza la elaboración de SOAP Miembros de W3C como Compaq, Hewlett Packard, Lotu, Microsoft, etc. con IBM como coautor

Aparición de J2EE, integrando RMI e IIOP Sun Microsystems

1999 Aparición de SOAP 1.0 Miembros de W3C como

Compaq, Hewlett Packard, Lotus, Microsoft, etc. con IBM como coautor

SOAP 1.1 es enviado a la W3C que anuncia su intención de trabajar en el área de los protocolos XML

Miembros de W3C como Compaq, Hewlett Packard, Lotus, Microsoft, etc. con IBM como coautor 2000

UDDI 1.0 OASIS

Aparece el primer borrador de SOAP 1.2 W3C 2001

WSDL 1.1 W3C

2002 UDDI 2.04 OASIS

2003 Recomendación SOAP 1.2 W3C

4.1.1 Servicios web

La principal barrera para el progreso de los estándares de componentes tradicionales ha sido la gestión centralizada de los mismos. Cualquier cambio en uno de ellos debía ser aprobado por su propietario por lo que el resto de la comunidad, al tener poco control sobre la tecnología, ha trabajado e influido

Capítulo 4

poco en su evolución. Otro problema importante ha sido que los dos principales estándares desarrollados, CORBA y DCOM, sean incompatibles entre sí.

Por el contrario, el trabajo de organizaciones abiertas como Linux, Apache y W3C y la amplia aceptación de estándares como HTTP para el intercambio de datos y XML para la representación de los mismos, han propiciado el nacimiento de protocolos RPC basados en XML para la web, fundamento de los servicios web.

Un servicio web es un componente software accesible a través de protocolos estándar de Internet, como HTTP, FTP, SMTP, etc., que basan su comunicación con otras aplicaciones en protocolos XML frente a los protocolos binarios propietarios de las tecnologías mencionadas en el anterior apartado.

La primera generación de protocolos XML estaban basados en XML 1.0, como ejemplos caben desatacar WDDX (web Distributed Data Exchange), creado por Allaire Corporation en 1998 o XML-RPC definido por Userland ese mismo año. Los servicios web están basados en un protocolo XML de segunda generación: SOAP (Simple Object Access Protocol). Este difiere de sus predecesores en que incorpora XML Namespaces y XML Schema.

SOAP especifica cómo transportar datos XML sobre diversas tecnologías de Internet como FTP, SMTP o HTTP, con el fin de intercambiar información estructurada en un entorno distribuido y descentralizado.

Un mensaje SOAP es un documento XML que define una unidad de comunicación en un entorno distribuido y está formado por los siguientes elementos:

Sobre (envelope): que identifica el documento XML como un mensaje SOAP. Contiene al resto de elementos.

Cabecera (header): elemento opcional que contiene información específica de la aplicación. No existe ninguna convención acerca de lo que debe ir en la cabecera, es un mecanismo para hacer a SOAP extensible. Los emisores y receptores del mensaje deberán ponerse de acuerdo sobre qué elementos van en la cabecera y qué significan. Por ejemplo, en el protocolo ebXML Message Service (MS), construido sobre SOAP, la cabecera es usada para definir elementos específicos como los campos from, to, o messageId de un correo electrónico.

Cuerpo (body): es el núcleo del mensaje SOAP y puede contener XML para representar RPC (información sobre la llamada y la respuesta), XML para el manejo de errores o cualquier fragmento de un documento XML.

Fallo (fault): proporciona errores que ocurridos durante el procesamiento del mensaje.

El mensaje SOAP incluye información adicional acerca del protocolo sobre el que viaja, por ejemplo, en el caso de HTTP incluirá la cabecera MIME.

SOAP es un esquema formal de intercambio de mensajes unidireccional (one-way) y sin estado (stateless) lo que no impide a las aplicaciones crear

96


97

patrones de interacciones más complejas como petición / respuesta, petición / múltiples respuestas, etc. Una llamada RPC es una especialización en la que se combinan múltiples mensajes unidireccionales en una petición / respuesta. SOAP proporciona, por tanto, mecanismos para comunicación entre procesos síncrona, mediante RPC, y asíncrona, basada en mensajes.

POST /axis/services/urn:ServicioFechaHora HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.1RC2 Host: localhost Cache-Control: no-cache Pragma: no-cache SOAPAction: "" Content-Length: 431 <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <ns1:fecha soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1=" <in0 xsi:type="xsd:int"> in0> </ns1: </soapenv:Body> </soapenv:Envelope>

urn:ServicioFechaHora">1</

fecha>

Fig. 16 Mensaje SOAP-RPC sobre HTTP de petición de un servicio

HTTP/1.1 200 OK Content - Type: text/xml; charset=utf-8 Date: Sat, 17 May 2003 10:08:20 GMT Server: Apache Coyote/1.0 Connection: close <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <ns1:fechaResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="urn:ServicioFechaHora"> <fechaReturn xsi:type="xsd:string">17 de Mayo de 2003</fechaReturn> </ns1:fechaResponse> </soapenv:Body> </soapenv:Envelope>

Fig. 17 Mensaje SOAP-RPC sobre HTTP de respuesta a un cliente

En las Fig. 16 y Fig. 17 se muestra un ejemplo de un mensaje SOAP-RPC de una petición a un servicio y su respuesta utilizando como medio de transporte el protocolo HTTP. El servicio exporta un método fecha que devuelve la fecha en diversos formatos dependiendo del valor de su parámetro de entrada. Se observa que al principio del mensaje se incluye la cabecera MIME de HTTP y a continuación un sobre SOAP. En el cuerpo del mensaje va codificada en XML la llamada al método fecha, incluyendo sus parámetros de entrada. La respuesta

Capítulo 4

(Fig. 17) incluye también la cabecera MIME y un elemento XML etiquetado con el nombre del método seguido de la palabra Return que contiene el valor de retorno del método invocado.

Al igual que los componentes CORBA usan IDL para especificar sus interfaces remotas, los servicios web usan un lenguaje basado en XML para tal fin: WSDL (web Service Description Language). Un documento WSDL describe la sintaxis de la invocación a un servicio especificando: 1) qué hace: los métodos y operaciones que proporciona; 2) cómo se puede acceder a él: detalles sobre los formatos de los datos y los parámetros de las llamadas a los métodos y 3) dónde se localiza: detalles sobre la dirección de red específica del protocolo (por ejemplo una URL).

WSDL proporciona un mecanismo para describir la interacción con un determinado servicio separando la definición abstracta del servicio de los mensajes del protocolo concreto usado para conectarse a un puerto de red con un formato determinado de mensaje. En la Fig. 18 se muestra la descripción WSDL correspondiente al método fecha del servicio comentado anteriormente.

Fig. 18 Descripción WSDL de un servicio web

<wsdl:definitions targetNamespace="urn:ServicioFechaHora" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" ...> <wsdl:message name="fechaResponse"> <wsdl:part name="fechaReturn" type="xsd:string"/> </wsdl:message> <wsdl:message name="fechaRequest"> <wsdl:part name="in0" type="xsd:int"/> </wsdl:message> <wsdl:portType name="DateServer"> <wsdl:operation name="fecha" parameterOrder="in0"> <wsdl:input message="impl:fechaRequest" name="fechaRequest"/> <wsdl:output message="impl:fechaResponse" name="fechaResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="urn:ServicioFechaHoraSoapBinding" type="impl:DateServer"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="fecha"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="fechaRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServicioFechaHora" use="encoded"/> </wsdl:input> <wsdl:output name="fechaResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServicioFechaHora" use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="DateServerService"> <wsdl:port binding="impl:urn:ServicioFechaHoraSoapBinding" name="urn:ServicioFechaHora"> <wsdlsoap:address location="http://localhost/axis/services/urn:ServicioFechaHora"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

Tipos de datos

Definición abstracta del servicio

Definición concreta del servicio

Localización del servicio

98


99

Además de SOAP y WSDL, existe un tercer estándar, UDDI (Universal Description, Discovery and Integration), que forma, junto con los anteriores, el núcleo de estándares XML en el que se basan los servicios web.

UDDI es el nombre de un grupo de registros web que publican información acerca de un servicio y sus interfaces técnicas (API). Estos registros se encuentran operativos en múltiples Operator Sites y su objetivo es proporcionar a las empresas una plataforma estándar e interoperable para descubrir de forma sencilla las interfaces técnicas necesarias para usar dinámicamente los servicios web que existan en Internet. El registro almacena información acerca de:

Quién ha desarrollado el servicio. En las llamadas páginas blancas se almacena información de contacto de la empresa.

Qué servicio se ofrece. Esta información, que componen las páginas amarrillas del registro, describe el servicio empleando diferentes taxonomías. La información para clasificar los servicios incluye códigos y clasificaciones de productos procedentes de la industria.

Dónde se puede localizar. Para ello se registra la información sobre la URL o cualquier otra dirección a través de la cuál el servicio puede ser accedido.

Cómo puede ser accedido. Esta información forma parte de las páginas verdes del registro (junto con los datos acerca de la localización). Se almacenan referencias a información sobre la interfaz del servicio y otras propiedades técnicas que describen como funciona un determinado software, como por ejemplo un documento WSDL.

4.1.2 Sistemas Multi-Agentes

La idea de construir sistemas educativos integrando piezas de software independientes y distribuidas que cooperen para alcanzar un objetivo de instrucción común no es nueva. La Inteligencia Artificial Distribuida (IAD), cuyo nacimiento se remonta a 1980, fue quizá el primer área de conocimiento que planteó la construcción de sistemas en los que distintas entidades software independientes (agentes) colaboraran en la solución de un problema.

Un agente es una entidad computacional situada en algún entorno que es capaz de desarrollar una acción autónoma adaptativa con el fin de cumplir sus objetivos de diseño (Wooldridge, 1995; Wooldridge, 1999). De esta definición se desprenden tres propiedades interesantes que caracterizan a un agente: situación, un agente recibe entradas de su entorno y actúa basándose en ellas pudiendo modificarlo; autonomía, el sistema puede aprender de la experiencia y adaptación, el agente debe ser reactivo (responde a cambios en el entorno), pro-activo (puede tomar la iniciativa) y social (debe ser capaz de interactuar con otros agentes y humanos).

Un sistema multi-agente (SMA) es una red débilmente acoplada de agentes que interactúan para resolver problemas que estén más allá de las capacidades individuales o de los conocimientos de cada uno de ellos (Durfee and Lesser, 1989). El afán por crear sistemas educativos más modulares y flexibles ha

Capítulo 4

llevado a numerosos investigadores a aplicar las técnicas de SMA al campo de la educación. Estos sistemas permiten una ejecución distribuida y están construidos por entidades software independientes (agentes). Además, los SMA permiten compartir conocimientos, representar el conocimiento de múltiples expertos, desarrollar las aplicaciones de forma modular y la reutilización.

Existen dos tipos de SMA: centralizados y abiertos. Los primeros son aquellos en los que los agentes tienen objetivos comunes y cooperan. Son sistemas diseñados de forma central en los que tanto sus componentes como los protocolos y el lenguaje de interacción son conocidos a priori. Esto los hace poco flexibles y su interacción con otros sistemas es generalmente dificultosa. La adición de nuevos agentes puede exigir un rediseño del sistema. Por el contrario, en los sistemas abiertos, los agentes normalmente existen antes de que surja la tarea común y pueden entrar y salir en cualquier momento.

El diseño y construcción de SMA es un problema difícil ya que a los problemas de construcción de sistemas distribuidos se unen dificultades debidas a las complejas interacciones que se producen entre los agentes. Es necesario resolver cuestiones técnicas para facilitar la difusión de las soluciones basadas en SMA. De este modo, paralelamente a la teoría de agentes han evolucionado a) estándares para la interacción e interoperabilidad de agentes y b) marcos de trabajo que permitan la implementación de SMA compatibles con los estándares.

En (Belmonte, 2002) se ofrece al lector una detallada revisión de los estándares (KQLM, OMG MASIF y FIPA) y marcos de trabajo (FIPA-OS, ZEUS y JADE) más conocidos.

4.2 Estándares para el desarrollo de aplicaciones educativas para la web

En los últimos años numerosas entidades, tanto públicas como privadas, han dedicado importantes esfuerzos al desarrollo de material educativo para la web. El siguiente paso en la evolución de la educación a distancia es la creación de plataformas y entornos de aprendizaje capaces de localizar y reutilizar todos estos recursos de forma automática. La consecución de este objetivo pasa por la definición de un conjunto de estándares para la educación.

Existen programas e iniciativas internacionales trabajando desde principios de los 90 en estándares para definición de recursos de aprendizaje (metadatos), de modelos del alumno, de estructuras de cursos, de elementos para la evaluación de los alumnos (test e ítem) y de arquitecturas de aplicaciones educativas. Este proceso está abierto y son numerosos los grupos de trabajo implicados y las propuestas existentes al respecto. En (Anido et al., 2001) se ofrece al lector una interesante revisión acerca de los distintos campos de la educación que son objeto de estandarización.

100


101

Tabla 14 Organizaciones dedicadas a la creación de estándares para la enseñanza y sus principales aportaciones.

ADL CAM (Content Aggregation Model) RTE (Runtime Environment) SN (Sequencing & Navigation)

IMS

RDCO (Reusable Definition of Competency or Educational Objective) CP (Content Packaging) DRI (Digital Repositories Interoperability) Enterprise LIP (Learner Information Package) LD (Learning Design) Metadata QTI (Questions and Tests Interoperability) SS (Simple Sequencing)

IEEE LTSC

LTSA (Learning Technology System Architecture) LOM (Learning Object Metadata) CMI (Computing Managed Instruction) DREL (Digital Rights Expression Language) PAPI (Public and Private Information Package Specification)

En los siguientes apartados se describen las organizaciones más destacadas dedicadas a la creación de estándares así como las líneas de investigación abiertas en cada una de ellas y los resultados obtenidos hasta la fecha (ver resumen Tabla 14 y Tabla 15).

Tabla 15 Estándares clasificados según el área del software educativo del que se ocupan.

ADL IMS IEEE LTSC AICC

DESCRIPCIÓN DE DATOS (METADATA)

CAM Metadata LOM

MODELO DEL ALUMNO

LIP PAPI

ESTRUCTURA Y SECUENCIACIÓN DE CURSOS

CAM SN

SS CMI CMI

TESTS QTI

ARQUITECTURA RTE LTSA CMI

4.2.1 Advanced Distributed Learning Initiative (ADL)

La OSD (Office of the Secretary of Defense) de Estados Unidos patrocina la iniciativa ADL (Advanced Distributed Learning Initiative) (ADL, 2004). El objetivo de ADL es definir un entorno de aprendizaje distribuido que permita la interacción entre herramientas de aprendizaje y el intercambio de contenidos de cursos. El DoD (Department of Defense) de EEUU está promoviendo el desarrollo y uso de herramientas y especificaciones que cumplan los siguientes requisitos:

Accesible desde lugares remotos a través de estándares de metadatos y empaquetado.

Capítulo 4

Adaptable a las necesidades de instrucción de organizaciones e individuos.

Asequible, incrementado la eficiencia en el proceso de aprendizaje y la productividad y reduciendo el tiempo y los costes.

Resistentes a revisiones de software y del sistema operativo.

Capaces de intercambiar información a través de múltiples herramientas y plataformas.

Reutilizables.

ADL pretende acelerar el proceso de desarrollo de software educativo mediante la definición de un esquema técnico común para el aprendizaje por computador que fomentará la creación de contenido reutilizable (objetos de instrucción).

4.2.1.1 Shareable Courseware Object Reference Model (SCORM)

SCORM (Shareable Courseware Object Reference Model) (SCORM, 2004) es un modelo de referencia (desarrollado por ADL) que define las relaciones entre los elementos de un curso, los modelos de datos y los protocolos de modo que los objetos de contenido educativo puedan ser compartidos por todos los sistemas que se ajusten al modelo. Uno de los objetivos básicos de SCORM es describir un conjunto de utilidades para la enseñanza a través de la web que permita interoperabilidad, accesibilidad y reusabilidad de contenidos de aprendizaje.

SCORM es una colección de especificaciones y estándares agrupados en tres categorías (libros en la terminología empleada por ADL): 1) CAM (Content Aggregation Model), 2) RTE (Run Time Environment) y 3) SN (Sequencing & Navigation). SCORM integra tecnologías desarrolladas por otras asociaciones e instituciones en un único modelo de referencia con el fin de proporcionar especificaciones de implementaciones consistentes que puedan ser usadas por toda la comunidad educativa vía web. Las aportaciones de otras entidades adoptadas por ADL son:

CAM:

- Metadata, de IEEE LOM 1484.12.

- Content Structure, de AICC

- Content Packaging, de IMS

- Sequencing Simple, de IMS RTE

- IEEE API 1484.11.2.

- IEEE Data Model 1484.11.1. SN

- Sequencing Simple, de IMS. Los aspectos cubiertos por cada uno de estos libros son:

102


103

CAM: describe los elementos usados en un proceso de aprendizaje, cómo empaquetarlos para poder intercambiarlos entre sistemas y cómo definir las reglas que secuencien su presentación. También define los requisitos para construir agregaciones de contenidos (cursos, lecciones, módulos, etc.).

Los componentes de CAM son:

- Assets, representación electrónica de un medio educativo (texto, imágenes, preguntas, audio, etc.).

- Activities, unidades de instrucción.

- SCOs (Sharable Content Objects), colección de uno o más assets. Un SCO representa el recurso de aprendizaje más pequeño susceptible de ser utilizado por un sistema de aprendizaje (LMS, Learning Management System) que utiliza el entorno de ejecución definido por ADL (RTE, Runtime Environment) para comunicarse con él. Son funciones de un SCO iniciar y terminar la comunicación con el LMS.

- Content Organization, mapa que representa el uso que se quiere hacer del material de aprendizaje mediante la descripción de actividades. Tiene tres componentes: una jerarquía de contenidos que representa la organización lógica de los recursos educativos; metadatos, que describen la organización y, opcionalmente, un conjunto de reglas para controlar la navegación y la presentación de los recursos al alumno. Estas reglas se definen siguiendo las indicaciones del libro SN.

RTE: describe los requisitos necesarios para implementar un sistema de gestión de aprendizaje (LMS). El propósito del RTE es proporcionar métodos para la comunicación entre un LMS y los SCO del modelo CAM.

Un LMS implementará diversos servicios como la gestión de cursos, la evaluación del alumno, la secuenciación de contenidos, etc.. Mientras el alumno interactúa con los objetos de contenido a través del navegador, el LMS evalúa su rendimiento y las peticiones de navegación definidas en el modelo CAM y selecciona una actividad que tendrá asociado un objeto de contenido (SCO). RTE define un modelo que arranca en el momento en el que un objeto de contenido ya ha sido seleccionado para ser enseñado al alumno y el LMS debe cargarlo en el navegador (Fig. 19). En la Fig. 20 se observa la relación temporal entre un LMS y un SCO. Cuando un alumno se conecta al LMS, éste elige una actividad para el alumno. Un intento (Learner Attempt) es el esfuerzo que el alumno realiza por completar una actividad y puede implicar más de una sesión (Learner Session). Una sesión de comunicación (Communication Session) representa una conexión activa entre un SCO y un LMS. Cuando se está realizando una actividad es responsabilidad del LMS manejar la secuencia entre actividades, es decir, es el LMS el que debe determinar la siguiente actividad del alumno basándose en la información de secuenciación definida en el CAM (especificación en el libro SN).

Capítulo 4

Cada vez que el alumno inicia un intento el LMS creará un conjunto de datos de ejecución (definidos en el RTE Data Model), que serán accedidos y usados por el SCO asociado a la actividad. Lo que el LMS hace con los datos de intentos previos está fuera del ámbito de SCORM. Existe un modelo asociado a cada SCO. Podría decirse que los modelos de datos de todas las SCO serían el equivalente al modelo del alumno en los sistemas inteligentes y adaptativos.

Fig. 19 Modelo de un LMS (Learning Mnagement System) en SCORM (SCORM, 2004)

Fig. 20 Relación temporal de un SCO y un LMS

El modelo contiene información diversa acerca de la identidad del alumno (nombre, id, preferencias), su nivel de conocimiento (medida del progreso realizado hasta completar la SCO, puntuación obtenida, estado (superada o no), etc.), y otros como el tiempo máximo permitido para cada intento, la localización de la SCO, etc. Un campo interesante son las interacciones, que son respuestas del alumno a preguntas o tareas que el SCO puede pasar al LMS. La especificación no contempla el uso que el LMS pueda hacer de ellas. En el estándar de IEEE se definen al menos 250 conjuntos de datos para las interacciones. El API definido en RTE y que los LMS deben implementar es el que se muestra en la Fig. 21, donde las funciones se dividen en tres categorías:

- Métodos de sesión: usados por el SCO para marcar el comienzo y el fin de la comunicación: Inicialize(), Terminate().

104


105

- Métodos de transferencia de datos: se usan para intercambiar valores del modelo de datos (RTE Data Model): GetValue(), SetValue(), Commit() (para datos persistentes).

- Métodos de auxiliares: se usan par comunicaciones auxiliares: GetLastError(), GetErrorString() y GetDiagnosis().

SN: describe como el material de aprendizaje puede ser secuenciado a partir de eventos iniciados por el alumno o por el sistema. El flujo del contenido puede ser descrito por un conjunto predefinido de actividades (Activity Tree) normalmente definidas en tiempo de diseño. El Activity Tree se deriva del Content Organization (libro CAM) correspondiéndose cada ítem del mismo con una actividad de aprendizaje.

Cada item puede tener asociado un conjunto de reglas que definen la secuencia de presentación de los contenidos de la actividad. El diseñador de contenidos puede definir desde una secuencia fija hasta una adaptativa basada en el estado de ciertos SCO, en preferencias del usuario o en resultados de evaluaciones. Existen tres tipos de reglas: preCondition, usadas para determinar si la actividad debe ser seleccionada; postCondition, se aplican cuando la actividad intenta finalizar y exitCondition, se consultan después de finalizar el intento de una actividad o alguno de sus descendientes. Cada una de ellas tiene un conjunto de condiciones que se deben cumplir para su activación y una acción. Para cada tipo de regla existe un conjunto diferente de posibles acciones que van desde pasar al siguiente o al anterior (continue o previous) a terminar (exit), volver a intentar (retry), etc

Fig. 21 API de RTE.

4.2.2 Instructional Management System (IMS)

IMS (Instructional Management System) Global Learning Consortium (IMS, 2004) es una organización sin ánimo de lucro que desarrolla y promueve el uso de especificaciones técnicas abiertas para tecnologías relacionadas con el aprendizaje capaces de intercambiar y usar información. IMS está relacionado con estándares para servidores y contenidos de aprendizaje y su integración.

Capítulo 4

Los miembros de IMS provienen de diversos sectores de la comunidad global de aprendizaje electrónico distribuido (distributed e-learning) tales como empresas de HW y SW, instituciones educativas, gubernamentales, etc.

Las especificaciones que se están desarrollando en IMS son:

Definiciones de capacidades: las especificaciones IMS RDCEO (Reusable Definition of Competency or Educational Objective) han sido creadas para describir las capacidades y aptitudes que forman parte del plan de aprendizaje de una carrera profesional, tales como prerrequisitos o resultados. La IEEE/LTSC ha adoptado la especificación IMS RDCEO como base para la definición de un estándar de aptitudes.

Empaquetado de contenidos: CP (Content Packaging) proporciona la funcionalidad para describir y empaquetar materiales de aprendizaje como cursos individuales o una colección de cursos en un paquete susceptible de ser distribuido e intercambiado con otros entornos de aprendizaje. El empaquetado de contenidos se encarga de la descripción, estructura y localización de materiales de aprendizaje on-line y la definición de algunos tipos de contenidos. Esta especificación ha sido adoptada por ADL para su especificación del modelo de contenidos (CAM).

Repositorios digitales: el propósito de la especificación DRI (Digital Repositories Interoperability) es proporcionar recomendaciones para las funciones más comunes de catálogos digitales. Las recomendaciones dadas deberán ser implementadas a través de servicios que presenten una interfaz común. Esta especificación está pensada para utilizar esquemas ya definidos en algún otro estándar más que para definir nuevos esquemas.

DRI define un catálogo digital como una colección de recursos accesibles a través de una red sin ningún conocimiento previo de la estructura de la colección.

Empresa: el objetivo de esta especificación es facilitar la interoperabilidad entre los sistemas de gestión del aprendizaje (Learning Management Systems, LMS) y otros tipos de sistemas que funcionan en una empresa: Sistemas de Recursos Humanos, Sistemas de Gestión de los Estudiantes (planifican las clases, el control de asistencia, etc.), Sistemas de Gestión de los Cursos (gestionan la matriculación de los alumnos en cada curso, la asignación de profesores, etc.) y Sistemas de Gestión de Bibliotecas. Estos sistemas deben residir en la misma empresa u organización, ya que la especificación no contempla problemas como la integridad de datos, comunicación, seguridad, etc. que pueden surgir cuando se intercambian datos con distintas empresas.

Información del alumno: el LIP (Learner Information Package) es una colección de información sobre un alumno, un grupo de alumnos o un proveedor de contenidos. El objetivo es definir un conjunto de paquetes que puedan ser usados para importar y exportar datos del alumno. Esta especificación define el modo de interactuar de un sistema de gestión de alumnos y un entorno de aprendizaje sobre la web. Las estructuras que

106


107

forman el LIP son: accesibilidad, actividad, afiliación, competencia, objetivo, identificación, intereses, capacitación, certificados y licencias, relaciones, claves de seguridad y transcripciones.

Diseño de aprendizaje: proporciona un lenguaje genérico y flexible que permite representar una gran variedad de estrategias de enseñanza. El lenguaje fue desarrollado por la Universidad Abierta de los Países Bajos.

Se especifican tres niveles de implementación: nivel A, contiene el vocabulario básico necesario para esta diversidad pedagógica; nivel B, añade propiedades y condiciones al nivel A que permiten elaborar una secuencia de interacciones personalizadas basadas en las características de un alumno; nivel C, añade notificaciones al nivel B.

Metadatos: describe datos (nombres, definiciones, organizaciones y descripciones) acerca de los elementos de IMS (alumnos, tests, etc.). Los metadatos permiten describir y catalogar un recurso de modo que este pueda ser buscado, encontrado y utilizado. Este trabajo está basado en la especificación LOM (Learning Object Metadata) de la IEEE. Describe un conjunto de diecinueve de los ochenta y seis elementos que se incluyen en LOM. El resto forman la IMS SEL (Standard Extension Library).

Preguntas y test: la especificación QTI (Questions and Tests Interoperability) describe un lenguaje estándar en XML para describir preguntas y test. Permite el intercambio de contenidos entre sistemas de evaluación.

Shareable State Persistence: describe una extensión de entornos de ejecución, como por ejemplo SCORM, que permite el almacenamiento y el acceso compartido a la información del estado de objetos de contenido, de modo que pueda ser recuperada más tarde por sí mismo o por otro objeto.

Secuenciación simple: define la funcionalidad necesaria para representar secuencias de actividades de aprendizaje. Incorpora reglas que describen ramificaciones o flujos de instrucción a través del contenido de acuerdo con los resultados obtenidos de la interacción con el alumno. Este estándar ha sido incluido en el modelo de datos (CAM) del estándar SCORM de ADL.

La palabra “simple” en el nombre de la especificación indica que incluye un número limitado de formas de secuenciación. No contempla secuenciación basada en técnicas de inteligencia artificial, ni de planificación, ni la utilización de datos o servicios externos (por ejemplo de simulaciones) ni el aprendizaje colaborativo ni adaptativo. Tampoco contempla la sincronización de actividades de aprendizajes paralelos. Sin embargo, la secuenciación simple proporciona una representación externa, por medio de extensiones al empaquetado de contenidos (CP) de IMS, para intercambiar descripciones de secuencias entre diferentes entornos de ejecución. La estructura de las interfaces de comunicación y de control entre los alumnos y los entornos de aprendizaje no forman parte de esta especificación.

Capítulo 4

Intercambio de definiciones de vocabularios: el IMS VDEX (Vocabulary Definition Exchange) define una gramática para el intercambio de listas de valores de varias clases. VDEX define una gramática para definir los valores junto con información que pueda ayudar a un humano a entender la aplicabilidad de los términos. VDEX puede ser usado para expresar la validez de datos para su uso en instancias de IEEE LOM, IMS Metadata, IMS LIP, ADL SCORM, etc.

4.2.3 IEEE Learning Technology Standars Commitee (IEEE LTSC)

El LTSC (Learning Technology Standars Commitee) (LTSC, 2004) ha sido creado por IEEE Computer Society Standards Activity Board (IEEE SAB) para desarrollar estándares técnicos acreditados, prácticas recomendadas y guías para la tecnología del aprendizaje.

Los estándares más relevantes son:

Learning Technology System Architecture (LTSA): este estándar especifica una arquitectura a alto nivel de sistemas de entrenamiento y aprendizaje. Este estándar es independiente del contenido, la estrategia de enseñanza y la plataforma.

Digital Rights Expression Language (DREL): el propósito de este proyecto es facilitar la creación, gestión y distribución de contenido digital para aprendizaje electrónico (eLearning) usando tecnologías que implementen lenguajes de expresiones de derechos digitales. Actualmente está en fase de desarrollo.

Computing Managed Instruction (CMI): este estándar cubre los siguientes aspectos: a) describir que hay en un curso, b) organizar y secuenciar lecciones individuales (unidad asignable), c) ejecutar unidades asignables desde un software de gestión de cursos (CMI software), d) comunicar información entre un programa que gestiona un curso y las lecciones de ese curso, e) describir los objetivos de un curso y relacionarlos con lecciones y grupos de lecciones y f) comunicar el rendimiento del alumno y relacionarlo cono los objetivos.

Learning Object Metadata (LOM): este estándar especificará la sintaxis y la semántica de los metadatos de los objetos de aprendizaje.

Reusable Competency Definitions: este estándar aún no ha sido definido. Estará basado en la especificación IMS RDCEO y su objetivo principal será definir los elementos obligatorios y opcionales que constituyen una definición de aptitudes para ser usada por LMS.

Public And Private Information (PAPI): describe registros de alumnos portables e independientes de la implementación. Los registros están organizados en seis categorías: personal, información administrativa sobre el alumno; relations, relaciones con profesores, otros alumnos, etc.; security, credenciales de seguridad del alumno; preference, preferencias del alumno

108


109

que pueden mejorar su interacción con la máquina; performance, almacena el historial del alumno y portfolio, colección de trabajos del alumno.

4.2.3.1 Learning Object Metadata (LOM)

El objetivo de LOM (LOM, 2004) es facilitar la búsqueda, evaluación, adquisición y uso de objetos de aprendizaje (LO), entendiendo por tales entidades, digitales o no, que pueden ser usadas, reutilizadas o referenciadas durante un proceso de aprendizaje por computador. Ejemplos de objetos de aprendizaje podrían ser contenido multimedia, de instrucción, herramientas software, personas, organizaciones o eventos.

El estándar LOM se encarga de determinar el mínimo conjunto de atributos necesario para poder gestionar, localizar y evaluar los objetos de aprendizaje. Una instancia de un metadato para un objeto de aprendizaje describe características relevantes del mismo que pueden ser agrupadas en nueve categorías (Tabla 16).

Tabla 16 Categorías que agrupan las características que describen un objeto de aprendizaje en LOM.

CATEGORÍAS DESCRIPCIÓN CARACTERÍSTICAS

General Información general que describe el objeto como un todo.

Identificador, catálogo, entrada de catálogo, título, idioma, descripción, clave, cobertura, estructura, nivel de agregación

Ciclo de vida

Agrupa las características relacionadas a la historia y el estado actual del objeto y a todo lo que ha afectado al objeto durante su evolución.

Versión, estatus, contribución, papel, entidad, fecha

Meta-metainformación

Información sobre la propia instancia.

Identificador, catálogo, entrada de catálogo, contribución, papel, entidad, fecha, esquema de metadata, idioma

Técnica Requisitos y características técnicas del objeto.

Formato, tamaño, ubicación, requisitos técnicos necesarios para el uso del objeto (tipo, nombre, versión mínima, versión máxima), instrucciones de instalación, otro SW y HW necesario, duración.

Educativo Características pedagógicas y educativas del objeto.

Tipo de interactividad, tipo de recurso de aprendizaje, nivel de interactividad, densidad semántica, usuario principal, contexto, edad, dificultad, tiempo previsto de aprendizaje, descripción, idioma.

Derechos Derechos de propiedad intelectual y condiciones de uso del objeto.

Coste, copyright y otras restricciones, descripción.

Relación Relaciones entre el objeto y otros recursos

Tipo, recurso, identificador, catálogo, entrada, descripción.

Anotaciones

Comentarios sobre el uso del objeto. Información relativa al autor y fecha de creación del objeto.

Entidad, fecha, descripción.

Capítulo 4

CATEGORÍAS CARACTERÍSTICAS DESCRIPCIÓN

Clasificación

Describe un objeto de aprendizaje con relación a un sistema particular de clasificación.

Finalidad, taxonomía, fuente, identificador, entrada, descripción, clave

4.2.3.2 Learning Technology Systems Architecture (LTSA)

El grupo de trabajo Architecture and Reference Model de LTSC ha definido la especificación LTSA (Learning Technology Systems Architecture) (LTSA, 2001).

LTSA representa un modelo conceptual aplicable a un amplio rango de escenarios de aprendizaje. Define cinco niveles de refinamiento (Fig. 22) pero el estándar sólo fija el conjunto de normas correspondiente al tercer nivel:

1. Interacciones del entorno y el alumno.

2. Características de diseño relacionadas con el alumno.

3. Componentes del sistema.

4. Prioridades y perspectiva de implementación.

5. Interoperabilidad de componentes.

En el nivel tres se describen los procesos, datos y flujos de una arquitectura basada en componentes. Los procesos se describen en términos de restricciones, entradas, funcionalidad y salidas. Los datos son descritos por el tipo de información y por los métodos de búsqueda, recuperación y actualización de los mismos. Por último los flujos vienen definidos por el tipo de conectividad (unidireccional, bidireccional, conexiones estáticas, dinámicas, etc.) y el tipo de información que se envía de un lado a otro.

LTSA identifica cuatro procesos: Delivery (D), Learner Entity (LE), Evaluation (E) y Coach (C); dos bancos de datos: Learning Resources (LR) y Learner Records (R) y trece flujos de información entre procesos y bancos de datos.

Fig. 22 Arquitectura LTSA

El proceso LE es la abstracción de un alumno o grupo de alumnos. Este proceso tiene como entrada una presentación multimedia y como salida el

110


111

comportamiento observado del alumno. Las preferencias del alumno son negociadas con C.

El proceso de evaluación (E) procesa el comportamiento del alumno y produce información acerca de la evaluación del alumno.

El encargado de seleccionar y localizar el material adecuado es el proceso Coach (C). Para ello recupera y procesa todos los datos acerca del alumno existentes en el sistema.

Por último se describe el proceso dedicado a localizar y recuperar el material de LR y transformarlo en una presentación multimedia.

En cuanto a los bancos de datos el registro del alumno (R) almacena información sobre el estado pasado (historia), presente (evaluación) y futuro (objetivos) del alumno. Los recursos del alumno (LR) representan conocimiento, información, presentaciones, tutoriales, herramientas, etc., es decir, todos aquellos recursos que el alumno usa en su proceso de aprendizaje.

4.3 Ontologías en los sistemas inteligentes para la web

Para que dos sistemas inteligentes puedan compartir y reutilizar conocimiento es necesario definir el vocabulario común que usarán para representar dicho conocimiento. Una ontología es la especificación del vocabulario de representación del dominio compartido, es decir, es una definición de conceptos, relaciones, funciones y otros objetos que forman el dominio.

Una de las definiciones de ontología más citadas dentro del campo de la representación del conocimiento es la dada por Gruber en (Gruber, 1993): “una ontología es una especificación explícita de una conceptualización”, entendiendo por conceptualización un modelo abstracto y simplificado de algún fenómeno en algún mundo obtenido a través de la identificación de conceptos relevantes de dicho fenómeno. El término explícita indica que el tipo de conceptos usados y las restricciones acerca de su uso se representan explícitamente. Borst (Borst, 1997) amplía la definición de Gruber y sostiene que una ontología es una “especificación explícita y formal de una conceptualización compartida”, donde el término formal indica que una ontología es una organización teórica de términos y relaciones usada para el análisis de los conceptos de un dominio de modo que pueda ser entendida por una máquina, mientras que el hecho de ser compartida implica que una ontología captura conocimiento consensual y es aceptada por una parte relevante de la comunidad científica.

Las ontologías son una pieza fundamental en sistemas que intercambian y comparten algún tipo de conocimiento. En el campo de los sistemas educativos inteligentes se ha impuesto un modelo de arquitectura que podríamos denominar orientada a conceptos (concept-oriented), en la que el modelo del dominio se separa claramente del contenido y se representa como una red semántica de conceptos y relaciones. Dicho modelo puede considerarse una conceptualización de un dominio, y por tanto una ontología, usada con el

Capítulo 4

propósito específico de transmitir el conocimiento relativo al dominio que representa.

El uso de ontologías en los sistemas educativos proporciona un vocabulario común acerca del dominio y el alumno que hace posible el intercambio y reutilización de material educativo y favorece la interoperabilidad de componentes educativos heterogéneos.

4.3.1 Lenguajes de especificación de ontologías

El desarrollo de aplicaciones basadas en el conocimiento sobre la web y fundamentalmente la llegada de la tercera generación de la web, la web semántica, han hecho necesaria la creación de lenguajes para la especificación de ontologías basados en estándares web como XML (eXtensible Markup Language) o RDFS (Resource Description Language Schema).

XML (W3C) define sintaxis para documentos estructurados impone restricciones semánticas al significado de esos documentos

OWL (W3C) es una revisión de DAML+OIL

RDF Schema (W3C) vocabulario para describir propiedades y clases de RDF proporciona una semántica para establecer jerarquías degeneralización de clases y propiedades

XML Schema (W3C) restringe la estructura de documentos XML extiende XML con tipos de datos

RDF (W3C) modelo de datos para recursos (objetos) y relaciones entre ellos semántica simple para este modelo de datos puede ser representado en XML

DAML (DARPA Agent Markup Language project) + OIL (On-To-Knowledge) DAML+OIL es similar a RDFS pero más potente permite definir clases más complejas que RDFS permite restricciones cualificadas del tipo “como máximotres de los hijos de X son del tipo Y”

Fig. 23 Evolución desde XML a OWL

En el contexto de los WILE los lenguajes de representación de ontologías son aplicables en la definición del dominio de conocimiento. Es importante destacar la finalidad pedagógica de estos modelos, en los que tan sólo es necesario representar explícitamente aquellas relaciones y conceptos del dominio que se desee enseñar al alumno. Sin embargo, es necesario incluir otras relaciones (como por ejemplo prerrequisito), heredadas del dominio de la pedagogía, necesarias en un proceso de aprendizaje.

112


113

En la Fig. 23 se muestra la evolución de estos lenguajes dentro de la W3C, desde XML hasta el nacimiento de OWL. En este apartado se ofrece al lector una revisión de estos lenguajes en la que se incluyen otras propuestas paralelas a las de la W3C. La comparación que se realiza de todos ellos está basada en los criterios de análisis establecidos en (Gómez-Pérez and Corcho, 2002) y (Corcho and Gómez-Pérez, 2000).

4.3.1.1 RDF y RDFS

RDF (Resource Description Framework) (Miller et al., 2004) fue creado por la W3C para describir recursos web. Este lenguaje permite la especificación de la semántica de los datos en XML de una forma estándar e interoperable y proporciona mecanismos para representar explícitamente servicios, procesos y modelos de negocio. El objetivo de RDF es describir los recursos sin hacer suposiciones sobre el dominio de una aplicación particular ni sobre la estructura de un documento.

El modelo de datos de RDF está basado en redes semánticas y contiene tres tipos de objetos: recursos, que representan una dirección web; propiedades, que definen características de un recurso y sentencias, que asignan un valor a una propiedad de un recurso.

El modelo de datos RDF no proporciona mecanismos para declarar propiedades ni para definir las relaciones entre las propiedades y otros recursos. Esta es la tarea de RDFS (Brickley and Guha, 2004). Un documento RDFS define no sólo las propiedades de un recurso sino también los tipos de recursos que están siendo descritos, además, permite la descripción de jerarquías de recursos. Sin embargo, RDFS es demasiado débil para describir recursos con el suficiente detalle y presenta dificultades para el razonamiento automático.

4.3.1.2 XOL

XOL (XML Based Ontology Exchange Language) (Karp et al., 1999) fue diseñado por la comunidad bioinformática de Estados Unidos para el intercambio de definiciones de ontologías entre un conjunto heterogéneo de sistemas de software. Está basado en los lenguajes Ontolingua y OML, uniendo la capacidad expresiva de OKBC-Lite (subconjunto del protocolo Open Knowledge Based Connectivity) y la sintaxis de OML.

4.3.1.3 SHOE

SHOE (Simple HTML Ontology Extensions) (Luke and Heflin, 2000) es un lenguaje desarrollado en la Universidad de Maryland como una extensión de HTML con el fin de añadir conocimiento semántico a los documentos HTML de forma que puedan ser entendidos por una máquina. Posteriormente a su creación la sintaxis de SHOE fue adaptada a XML.

El objetivo de SHOE es hacer posible que los agentes puedan extraer información útil de las páginas web mejorando así los mecanismos de búsqueda

Capítulo 4

y obtención de conocimiento. Para ello es necesario definir una ontología y anotar las páginas HTML con la información de la ontología de modo que se describan a sí mismas y a otras páginas.

4.3.1.4 OIL

OIL (Ontology Inference Layer) (OIL, 2004) es un lenguaje que permite la interoperabilidad semántica entre recursos web. Está desarrollado en el marco del proyecto On-To-Knowledge cuyo objetivo es el desarrollo de herramientas y métodos para la gestión de conocimiento basadas en ontologías reutilizables y susceptibles de ser compartidas. Este proyecto está siendo llevado a cabo por un grupo de empresas y universidades como BT (British Telecom), CongIT, Aidministrator, Universidad de Vrije (Amsterdam), Instituto AIFB (University of Karlsruhe, Alemania), Swiss Life, Enersearch y Onto Text lab.

OIL está basado en RDFS y proporciona primitivas de modelado usadas en el enfoque de ingeniería ontológica basada en marcos (frame-based) y métodos de razonamiento de lógicas de descripción (subconjunto de la lógica de primer orden que mantiene un alto poder expresivo junto con un mecanismo de inferencia eficiente).

OIL está construido en capas o estratos: Core OIL comprende las primitivas que tienen una correspondencia directa con las de RDFS, por lo que un agente RDFS sería capaz de procesar una ontología OIL y extraer parte del conocimiento que contiene; Standard OIL es el modelo OIL completo en el que se usan más primitivas de las que proporciona RDFS; Instance OIL añade instancias de conceptos al nivel anterior; Heavy OIL es el nivel para futuras extensiones.

4.3.1.5 DAML+OIL

El proyecto DAML (DARPA Agent Markup Language) (DAML, 2004), financiado por el gobierno estadounidense desde agosto de 2000, tiene como principal objetivo proporcionar los fundamentos para la tercera generación de la web: la web semántica. El proyecto trata de desarrollar lenguajes, herramientas y técnicas que faciliten a las máquinas entender el contenido de la web.

Este proyecto dio como fruto DAML-ONT, un lenguaje para definir clases RDF más sofisticadas de lo que RDFS permite. DAML-ONT adolece de una especificación semántica débil lo que puede llegar a provocar conflictos entre humanos y máquinas acerca del significado preciso de algún término de una ontología.

En paralelo, y con los mismos objetivos que DAML_ONT, surgió el lenguaje OIL (ver 4.3.1.4). Sin embargo, OIL cuenta con una semántica formal que se puede especificar a través de la lógica de descripción. Ambos proyectos se unieron creando DAML+OIL (DAML+OIL, 2004). Una ontología DAML+OIL contiene un conjunto de axiomas que restringen el significado de las clases y propiedades del dominio.

114


115

4.3.1.6 OWL

OWL (Bechhofer et al., 2004) es el lenguaje propuesto por la W3C como estándar para la especificación de ontologías de la web semántica. Lenguajes anteriores ser compatibles con la arquitectura de la World Wide Web en general, y la Web Semántica en particular. OWL rectifica esto proporcionando un lenguaje que utiliza la conexión proporcionada por RDF para añadir a las ontologías capacidad de ser distribuidas a través de varios sistemas, escalable a las necesidades de la Web, compatible con los estándares Web de accesibilidad e internacionalización y abierto y extensible.

Las experiencias en el diseño y aplicación de DAML+OIL fueron el punto de partida para la creación de OWL cuyo primer borrador fue publicado en diciembre del 2003, aprobándose la primera versión definitiva en febrero de 2004.

OWL está construido en tres capas o niveles para usuarios que no necesiten la funcionalidad completa del lenguaje:

OWL Lite permite representar jerarquías de conceptos y restricciones simples.

OWL DL (Description Logic) está basado en lógicas de descripción, con completitud y decibilidad computacional.

OWL Full tiene máxima expresividad (como RDFS) pero sin garantías computacionales.

4.3.1.7 OXML

OXML (Erdman, 2002) es el lenguaje de representación de ontologías usado por el Knowledge Management Group de la Universidad de Karlsruhe (Alemania) y por la empresa ontoprise GmbH para OntoEdit, un entorno de desarrollo de ontologías. El lenguaje de especificación formal usado en su núcleo es F-Logic (Kifer et al., 1995), un lenguaje de bases de datos orientado a objetos y deductivas.

OXML viene definido mediante un XML-Schema (Fig. 24) lo que facilita la tarea de validación de los dominios creados desde la propia herramienta de autor de MEDEA. Este XML Schema define los mecanismos básicos para describir una ontología, sus meta-datos y especialmente sus componentes: conceptos, relaciones y/o axiomas.

El elemento raíz de un documento OXML es <ontology>. OXML dispone de ocho elementos para definir ontologías: conceptos (<concept>), relaciones (<relation>), instancias (<instance>), axiomas (<axiom>), predicados (<predicate>), instancias de predicados (<predicateInstance>) y modulos (<modules>). Además, OXML dispone de los nodos <about>, que contiene metadatos acerca de la ontología (título, versión, dominio, autor, etc.) e <import>, usado para poder referenciar a recursos localizados en otras ontologías.

http://www.w3.org/TR/2004/REC-rdf-primer-20040210/

Capítulo 4

El elemento <concept> en OXML tiene dos atributos: id y abstract. El primero es el identificador único del concepto dentro de la ontología y el segundo puede tomar los valores true y false indicando si el concepto en cuestión puede ser instanciado o no. Se puede indicar que un concepto forma parte de una jerarquía a través del elemento <subConceptOf>. El elemento <disjointWith> se usará para indicar que dos conceptos no pueden tener ninguna instancia en común.

Fig. 24 XML Schema del lenguaje OXML

Los conceptos de una ontología pueden ser asociados entre sí mediante relaciones. En OXML, cada una de ellas es definida por un elemento <relation> que contiene los atributos domain y range para representar, respectivamente, los conceptos origen y destino de la relación. La cardinalidad de la relación puede ser establecida por los atributos minCard y maxCard, que restringen el número de relaciones de este tipo en las que una instancia del concepto dado por domain puede participar.

116


117

El álgebra relacional define un conjunto básico de propiedades para las relaciones. OXML permite establecer las propiedades que posee una relación de entre las siguientes: simétrica, reflexiva, transitiva, antisimétrica, asimétrica, irreflexiva o intransitiva.

Otras figuras usuales en la definición de una ontología son las relaciones inversas (por ejemplo padre e hijo, mayor y menor, etc.) y la composición de relaciones que pueden ser expresadas en OXML mediante los elementos <inverseRelationOf> y <composedOf>.

OXML permite definir una estructura jerárquica de relaciones usando el elemento <subRelationOf>, de forma análoga a la establecida entre los conceptos a través de <subConceptOf>.

4.3.1.8 Comparativa

A la hora de analizar este tipo de lenguajes, según el esquema definido para la evaluación de los mismos en (Corcho and Gómez-Pérez, 2000), es necesario distinguir entre conocimiento del dominio y mecanismos de inferencia. En este apartado se analizan sólo los aspectos relativos a la representación del conocimiento.

El conocimiento en una ontología puede ser especificado usando cinco componentes: conceptos (organizados en taxonomías), relaciones, funciones, axiomas e instancias.

Para cada uno de ellos se han identificado un conjunto de características necesarias para su completa representación. En la Tabla 17 se listan y describen estas características (primera y segunda columna respectivamente), marcando cuales de ellas cumple cada uno de los lenguajes mencionados en este apartado.

Tabla 17 Comparativa de los lenguajes de representación de ontologías para la web (‘x’ indica que el lenguaje posee la característica, en blanco que no la posee y ‘~’ que no está contemplada en el lenguaje

pero podría gestionarse), adaptada de (Corcho and Gómez-Pérez, 2000)

CONOCIMIENTO DEL DOMINIO

CONCEPTOS XOL SHOE RDF(S) OIL DAML+OIL OWL OXML

Cuestiones generales

Particiones ¿Se pueden definir conjuntos disjuntos de conceptos? x x x x

Documentación ¿Es posible definir la documentación de un concepto? x x x x x x

Atributos ¿Permite el lenguaje definir atributos de conceptos del tipo...

De instancias Su valor podría ser diferente para cada instancia del concepto x x x x x x x

De clases Su valor está asociado al concepto (es el mismo para todas las instancias)

x

x x x x

Ámbito local Tienen el mismo nombre para diferentes conceptos x x x x x x x

Capítulo 4

Ámbito global Pueden ser aplicados a todos los conceptos de la ontología. x x x x x x

Facetas ¿Proporciona el lenguaje las siguientes propiedades predefinidas para los atributos?:

Valor por defecto

Usado para asignar un valor al atributo en caso de que no haya ningún valor definido explícitamente.

x x

Tipo o Rango Usado para restringir el tipo del atributo. x x x x x x x

Restricciones de cardinalidad

Para restringir el número máximo y mínimo de valores x x x x x

Documentación Definición en lenguaje natural para el atributo x x x x x x

TAXONOMÍAS XOL SHOE RDF(S) OIL DAML+OIL OWL OXML

Subclase de Especializa los conceptos x x x x x x x

Descomposiciones disjoint

Pueden existir instancias de una clase que no sean instancias de ninguna de sus subclases.

x x x x

Descomposiciones exahustiva

Cualquier instancia de una clase debe ser instancia de alguna de sus subclases.

x x x

No subclase de Indica que un concepto no es una especialización de otro. x x x

RELACIONES Y FUNCIONES XOL SHOE RDF(S) OIL DAML+OIL OWL OXML

Relaciones/funciones n-arias

¿Se pueden definir? ~ x ~ ~ ~ ~ x

Restricciones de tipo

¿Se puede restringir el tipo de los argumentos? x x x x x x x

Restricciones de integridad

Para comprobar la corrección de los valores de los argumentos. ~ ~

Definiciones funcionales

Para inferir valores de argumentos con procedimientos, fórmulas o reglas o para definir su semántica usando axiomas o reglas.

AXIOMAS XOL SHOE RDF(S) OIL DAML+OIL OWL OXML

Lógica de primer orden

¿Se pueden definir axiomas en lógica de primer orden? ~ ~ ~ x x

Lógica de segundo orden

¿Se pueden definir axiomas en lógica de segundo orden?

Axiomas independientes

¿Se pueden definir axiomas como elementos independientes de la ontología?

Axiomas embebidos

¿Se pueden definir axiomas dentro de la definición de otros elementos (conceptos, relaciones,...)?

INSTANCIAS XOL SHOE RDF(S) OIL DAML+OIL OWL OXML

Instancias de conceptos

¿Se pueden definir? x x x x x x x

Hechos ¿Se pueden definir instancias de relaciones? x x x x x x x

118


119

Asertos ¿Se pueden definir afirmaciones sobre hechos? x ~ ~ ~ x

En (Gómez-Pérez and Corcho, 2002) se distingue entre ontologías ligeras (lightweight) y pesadas (heavyheight) diferenciándose porque estas últimas, además de conceptos, relaciones y funciones, contienen axiomas. La elección del lenguaje de definición de ontologías está supeditada a las necesidades de uso. Para definir ontologías ligeras cualquier lenguaje de los mostrados en este apartado sería válido. En el caso de que se deseen definir ontologías pesadas es necesario sopesar cuáles de las características descritas en la Tabla 17 serían deseables y elegir en consecuencia. Otros aspectos que podrían tenerse en cuenta en la elección son la existencia de motores de inferencia y de herramientas de edición.

4.4 Conclusiones

En esta tesis se define una metodología de desarrollo para la construcción de un WILE mediante la reutilización de otros sistemas educativos y se implementa un marco de trabajo que da soporte a la metodología facilitando la construcción de entornos inteligentes de aprendizaje para la web. Desde el punto de vista de la implementación estos sistemas son aplicaciones distribuidas abiertas, por lo que en este capítulo se ha realizado una revisión de las tecnologías existentes para el desarrollo de este tipo de aplicaciones en los campos de la Ingeniería del Software y la Inteligencia Artificial.

Además de los aspectos técnicos para la interoperabilidad de sistemas a bajo nivel es necesario resolver los problemas de comunicación a alto nivel propios de los sistemas educativos inteligentes. En este sentido se han presentado dos líneas de trabajo, una basada en el desarrollo de estándares para la construcción de sistemas educativos (material, arquitecturas, modelado del alumno, etc.) y otra en el uso de ontologías como forma para la representación del conocimiento contenido en un sistema educativo (dominio, alumno y pedagógico).

Los objetivos marcados en esta tesis han condicionado la elección de las técnicas y herramientas para el desarrollo e implementación de MEDEA.

Entre estos objetivos está la creación de un marco de trabajo que permita construir WILE mediante la integración de aplicaciones educativas externas. Este objetivo pone de manifiesto la heterogeneidad de las entidades software implicadas en un WILE y por tanto la necesidad de favorecer la interoperabilidad entre las mismas, así como de minimizar los efectos de insertar y/o eliminar dichas aplicaciones (openness). Estas necesidades justifican la elección de los servicios web como tecnología para la integración de sistemas, debido principalmente al hecho de basar su comunicación con otras aplicaciones en protocolos XML (accesibles a través de protocolos estándar de Internet) frente a los protocolos binarios propietarios de otras tecnologías.

Uno de los objetivos prioritarios de MEDEA es favorecer la reutilización de software educativo, esto y su carácter distribuido y abierto han determinado la

Capítulo 4

utilización, en la medida de lo posible, de estándares educativos definidos por la IEEE LTCS (para la descripción del modelo del alumno y de los LO), además de OXML como lenguaje para la definición de los dominios en el marco de trabajo. Aunque actualmente el lenguaje OWL (desarrollado por la W3C) está más extendido, la aparición de la primera especificación estable del mismo (en febrero de 2004) fue posterior a la implementación del modelo del dominio de MEDEA.

120

Capítulo 5 METODOLOGÍA DE DESARROLLO DE ENTORNOS DE APRENDIZAJE INTELIGENTES DISTRIBUIDOS Y ABIERTOS PARA LA WEB

Según el análisis realizado en los capítulos previos, el avance de los sistemas educativos inteligentes para la web (WILE) no ha sido el esperado en comparación al de los sistemas de gestión de cursos tradicionales (LMS), usados por numerosas entidades educativas. Esto es debido principalmente a que los WILE son demasiado específicos en lo que al dominio y a los métodos de enseñanza se refiere. A esto hay que añadir su elevado coste de desarrollo, que normalmente implica a expertos de distintas disciplinas. Como contrapartida, existen estudios como el de (Bloom, 1984) que demuestran que los resultados obtenidos por los alumnos mejoran sensiblemente si se aplican métodos de instrucción individualizados, por lo tanto, desde el punto de vista pedagógico los WILE son superiores a los sistemas de gestión de cursos tradicionales.

El problema que se plantea es como desarrollar sistemas que conjuguen la versatilidad de los LMS con la calidad de los WILE, disminuyendo los costes de desarrollo.

Tras el análisis del Capítulo 3 observamos que existen numerosos ejemplos de sistemas inteligentes para la web avalados por estudios que demuestran su eficacia en la instrucción. La mayoría de estos sistemas son el resultado de años de investigación centrados en el desarrollo de una tarea educativa, en el estudio de un dominio concreto o en la aplicación de una determinada estrategia de aprendizaje. Como ejemplos podemos citar a ELM-ART (Brusilovsky et al., 1996) que se centra en el dominio de LISP y en la tarea de ejercicios de programación o AlgeBrain Tutor (Alpert et al., 1999) en problemas de álgebra. En muchos casos sería interesante reutilizar parte de su conocimiento y aprovechar la calidad de sus contenidos y estrategias. El problema es que estos sistemas suelen tener arquitecturas monolíticas en las que los contenidos y la forma de presentarlos están estrechamente relacionados y el coste de su separación hace inviable la reutilización de todo o parte del sistema.

121

Capítulo 5

Esto ha llevado a algunos investigadores a pensar en la posibilidad de construir entornos de aprendizaje inteligentes integrando algunas de estas herramientas como un todo. Por ejemplo, se podría desarrollar un WILE para LISP usando DCG (Dynamic Course Generation) (Vassileva and Deters, 1998) para generar las páginas de teoría; ELM-ART para la realización de problemas y CATGlobal (Promissor, 2003) como herramienta de auto-evaluación. En el Capítulo 3 se citan algunos de los trabajos desarrollados en esta línea. Entre los primeros intentos destacan las propuestas de (Ritter and Koedinger, 1996), (Brusilovsky et al., 1997) o (De Bra et al., ) que tratan de conectar dos sistemas independientes definiendo protocolos estándares de comunicación. Actualmente se están desarrollando arquitecturas y plataformas, como ActiveMath (Melis et al., 2001) o KnowledgeTree (Brusilovsky and Nijhavan, 2002) que agrupan distintos recursos educativos. Dos características importantes de este tipo de plataformas deberían ser su capacidad de extensión y permitir la interoperabilidad de sus componentes. Ninguna de las soluciones presentadas en el Capítulo 3 cuentan con mecanismos para la inserción y eliminación de recursos ni protocolos lo suficientemente estándares, como para que los costes de integración sean aceptables.

Por otro lado, la estrecha relación existente en la mayoría de sistemas inteligentes entre contenidos y presentación implica que tanto profesores como técnicos dependan unos de otros a lo lago del proceso de desarrollo. La construcción de herramientas de autor, que permitan a usuarios no especializados (profesores principalmente) el desarrollo de sistemas educativos, ha sido un problema al que se han dedicado notables esfuerzos a lo largo de la última década (Murray, 1999)

El objetivo que se persigue en esta tesis es doble. Por un lado proporcionar una metodología de desarrollo de WILE que reduzca en la medida de lo posible los costes de integración y reutilización de sistemas externos. La base de esta propuesta consiste en construir entornos distribuidos y abiertos (entendiendo por abierto un sistema extensible que permita la inserción y eliminación dinámica de recursos de instrucción) que proporcione secuenciación del currículum, técnicas de diagnóstico del alumno y selección de tareas educativas, delegando la ejecución de esas tareas en los recursos de instrucción. Se pretende competir con los LMS reduciendo los costes de desarrollo e incrementando la oferta de recursos educativos, entendidos como objetos de aprendizaje (LO, (IEEE, 2005)), sin renunciar a la aplicación de técnicas inteligentes.

En segundo lugar, se pretende permitir la construcción de WILE por usuarios no especializados, ofreciendo soluciones a algunos de los problemas comunes a cualquier sistema inteligente (gestión de modelo del usuario, secuenciación del currículum, etc) de modo que el docente pueda construir sistemas educativos concentrándose en la “forma de enseñar y en el cómo”.

Esta propuesta se concreta en MEDEA: MEtodologías y herramientas para el Desarrollo de entornos inteligentes de Enseñanza y Aprendizaje (Trella et al., 2001; Trella et al., 2002; Trella et al., 2003). Siguiendo el enfoque de (Newell, 1982), se ha planteado el desarrollo de sistemas inteligentes para la educación en dos

122

Metodología de desarrollo de entornos de aprendizaje inteligentes distribuidos y abiertos para la web

123

niveles. Según Newell un sistema basado en el conocimiento se puede describir definiendo una jerarquía de niveles. En el nivel superior se encuentra el nivel del conocimiento que se centra en identificar las acciones y áreas de conocimiento que explican el comportamiento inteligente del sistema (¿qué hace?, ¿qué sabe?). El siguiente es el nivel simbólico que utiliza lenguajes de programación para describir procedimientos y estructuras de datos. En él se toman las decisiones necesarias para construir un modelo que se comporte conforme a la descripción del nivel de conocimiento. En MEDEA el nivel correspondiente al nivel del conocimiento de Newell viene dado por una metodología de desarrollo para WILE basada en la integración de recursos de instrucción. En el siguiente nivel (nivel simbólico) se ha construido un marco de trabajo que se comporta conforme a la metodología definida y que permite la construcción de WILE por usuarios no especializados, mediante la utilización de programas educativos externos. Esta separación permite la construcción de distintos marcos de trabajo basados en la misma metodología de desarrollo.

Este capítulo se centra en la descripción de la metodología de desarrollo. La concreción de los detalles relativos a las estrategias de instrucción, estilos de aprendizaje, así como la gestión de los modelos del alumno y del dominio, pertenecen al marco de trabajo (Capítulo 6).

La instanciación del marco de trabajo para un dominio concreto dará lugar a un entorno de aprendizaje inteligente para la web. En el Capítulo 7 se describen dos WILE construidos a partir de MEDEA para los dominios de Lógica y Economía Agraria.

5.1 Introducción a la metodología y sus elementos

Una metodología de desarrollo define un conjunto de métodos, procedimientos, técnicas y herramientas que faciliten la construcción de un sistema. Para determinar el contenido de una metodología de desarrollo será necesario analizar el tipo de sistema que se quiere obtener como resultado de su aplicación y en base a esto establecer los elementos y acciones necesarios para alcanzar dicho objetivo.

En las disciplinas de Ingeniería del Software (IS) e Ingeniería del Conocimiento (IC) existen metodologías para la producción y mantenimiento sistemático de productos software. Estas ofrecen a los programadores métodos para la construcción de software, procesos que definen secuencias de aplicación de esos métodos y herramientas que proporcionan soporte automático o semiautomático para su uso. Algunas de las más conocidas son RUP (Rational Unified Process) o Métrica 3 en IS y CommonKADS (Schreiber et al., 1999) en IC. En el campo de la Inteligencia Artificial Distribuida se han diseñado extensiones de algunas de estas metodologías que se ajustan a los problemas específicos del desarrollo de sistemas multi-agentes. Como ejemplos destacan GAIA (Wooldridge et al., 2000) y Agent UML (Bauer et al., 2001) basadas en metodologías de IS y MAS-CommonKADS (Iglesias et al., 1997) y DESIRE (Brazier et al., 1997) en la IC. Pero no existe ninguna solución orientada a los Sistemas Tutores Inteligentes en general o a los WILE en particular. En este

Capítulo 5

capítulo se presenta una metodología para el desarrollo de WILE mediante la reutilización de recursos externos basada en las tesis de Newell para el desarrollo de sistemas inteligentes.

Según Newell, la descripción de un sistema al nivel del conocimiento se centra en identificar las áreas de conocimiento que explican su comportamiento inteligente. Su estructura vendría dada por un conjunto de acciones para dialogar con el mundo exterior, un cuerpo de conocimiento y un conjunto de metas u objetivos. En nuestro caso particular el cuerpo de conocimiento de un sistema inteligente de aprendizaje viene en parte determinado por el paradigma de los Sistemas Tutores Inteligentes, que establece que un sistema de enseñanza estará formado por cuatro componentes: un modelo instruccional, un modelo del dominio, un modelo del alumno y un modelo de diálogo (Wenger, 1987a) (a partir de este momento nos referiremos a estos módulos como el núcleo del cuerpo de conocimiento). Sin embargo, nuestro objetivo es la construcción de un tipo especial de WILE que integre sistemas externos, por lo que será necesario a) fijar algunas características del núcleo para que se ajuste a nuestras necesidades y b) ampliar el cuerpo de conocimiento de modo que incluya los elementos adicionales necesarios para explicar el comportamiento de nuestro sistema.

Una vez concretados los elementos que definen un WILE es preciso establecer el conjunto de acciones que habrá que llevar a cabo para construir dichos elementos. En el proceso de desarrollo de un WILE participan distintos actores, cada uno de ellos directamente implicado en la creación una parte del sistema. Se han identificado los siguientes roles:

Desarrollador del núcleo, representa al programador que construye los elementos propios de un sistema de aprendizaje inteligente.

Personal técnico, uno de los objetivos principales de esta tesis es la construcción de WILE que integren sistemas educativos externos como parte de su propia arquitectura. Según esto, es necesaria la participación de programadores que implementen estos sistemas y otros (que pueden ser los mismos o no) que se encarguen de integrarlos haciéndolos compatibles con el resto de componentes.

El experto del dominio, estructura el conocimiento acerca de un determinado dominio.

El docente, modela el sistema (WILE) haciendo uso de los dominios definidos y los recursos educativos disponibles.

El alumno, es el usuario final del sistema y, a través de un conjunto de acciones predefinidas, interactúa con él para aprender acerca de una determinada materia.

Teniendo esto en cuenta, la descripción del nivel de conocimiento (metodología de desarrollo) se ha dividido en varias capas según el tipo de actor que interviene en cada una. En la Fig. 25 se muestra para cada capa el tipo de actor que interviene y los elementos del cuerpo de conocimiento que se fijan

124


125

en dicha capa, esto es, cuál es el resultado de aplicar los métodos y acciones correspondientes a esa capa de la metodología.

CAPA 0. NÚCLEO

CAPA 1. RECURSOS DE INSTRUCCIÓN

CAPA 2. CONOCIMIENTO INSTRUCCIONAL

CAPA 3. WILE

técnico

profesor experto del dominio

alumno

Mecanismos que definen el paradigma STI

Herramientas para enseñar

Particularización de un dominio y de una forma de enseñar

Particularización para un alumno concreto

+

N

IVEL

D

E G

ENER

ALI

DA

D

-

desarrollador

Fig. 25 Nivel del conocimiento de un WILE. A la izquierda de cada capa se listan los tipos de usuarios

involucrados y a la derecha los elementos del cuerpo de conocimiento que se fijan en dicho capa.

Según esto, la capa 0 se corresponde con el núcleo del sistema. El técnico o programador de la capa 1 se encargará de implementar soluciones a problemas educativos e integrarlas de forma que sean compatibles con los elementos de la capa 0. La capa 2 se corresponde con el conocimiento de instrucción en el que el experto se encargará de estructurar el conocimiento de un determinado dominio y el profesor de seleccionarlo y ponerlo en correspondencia con los recursos de la capa 1. Por último el alumno es el usuario final del sistema que llevará a cabo el aprendizaje de un determinado dominio.

A lo largo de este capítulo se detallan los aspectos relativos a cada una de estas capas definiendo los protocolos de actuación que, aplicados a los elementos de la capa inferior generan los elementos necesarios para desarrollar la siguiente capa.

La metodología aquí definida junto con el marco de trabajo que da soporte a la misma y que se describe en el Capítulo 6, conforman MEDEA (MEtodologías y herramientas para el Desarrollo de entornos inteligentes de Enseñanza y Aprendizaje).

5.2 Capa 0. El núcleo

Los WILE representan la evolución de los STI hacia la web (Brusilovsky, 1995), y por tanto su arquitectura (epígrafe 3.2.1) es el resultado de adaptar la arquitectura tradicional de los STI (Polson and Richardson, 1988) a este nuevo medio. (Self, 1999)Está formada por cuatro módulos que son: del dominio o experto, del alumno, instructor o pedagógico y de comunicación o entorno. Estos módulos, imprescindibles en cualquier sistema educativo inteligente, forman el núcleo de MEDEA (Fig. 26) y sientan las bases del comportamiento del sistema que se pretende construir y que irá tomando forma a medida que se avance de capa. La concreción de los detalles relativos a las estrategias de instrucción, estilos de aprendizaje, así como la gestión de los modelos del

Capítulo 5

alumno y del dominio, pertenecen al marco de trabajo que se presenta en el siguiente capítulo.

Planificador de

instrucción

CAPA 0 Núcleo

Interfaz Modelo del alumno

Modelo del dominio

CAPA 1. Recursos de instrucción

CAPA 2. Conocimiento de instrucción

CAPA 3. WILE

Fig. 26 Elementos del núcleo de MEDEA

5.2.1 Modelo del dominio

Nuestro objetivo es definir la arquitectura de un WILE que incluya a otros sistemas educativos (algunos de ellos inteligentes). Una parte de esa integración se basa en que los sistemas sean capaces de compartir el conocimiento de su dominio. Teniendo en cuenta que los sistemas educativos para la web, tal y como se describe en el epígrafe 3.2.1, suelen incluir en su dominio una red semántica de conceptos relacionados, parece lógico definir nuestro dominio como un conjunto de conceptos de forma que se puedan establecer correspondencias entre las unidades de conocimiento de uno y otro modelo.

En el marco de trabajo se concretará la estructura del modelo cuya complejidad se puede incrementar definiendo el conjunto de atributos usados para representar un concepto (dificultad, peso,...) y los tipos de relaciones que se pueden establecer entre los mismos (prerrequisito, parte_de,...). La interpretación semántica de las relaciones y de los atributos vendrá determinada por las necesidades del planificador de instrucción implementado en el marco de trabajo. Este particular permite que, dado un marco de trabajo, distintos planificadores puedan coexistir, de modo que cada uno use un subconjunto determinado de atributos y/o relaciones del dominio interpretándolas de forma diferente.

El contenido concreto de un modelo será determinado durante el proceso de construcción de un WILE para un dominio específico (ver 5.4.1).

El modelo del dominio se comunica con el resto de elementos del núcleo y con los recursos de instrucción a través de los servicios Consultar conceptos y Consultar relaciones.

5.2.2 Modelo del alumno

El modelado del alumno consiste en seleccionar la información se va a incluir en el modelo, la estructura de datos más apropiada para representarla y

126


127

determinar el procedimiento para inferir el conocimiento del alumno (diagnóstico).

Siguiendo un razonamiento análogo al empleado en la definición de modelo del dominio, se utiliza como modelo del alumno un modelo de superposición. A pesar de que existen otros modelos más completos que permiten una adaptación más precisa de la instrucción, este modelo es sencillo y favorece la integración con otros sistemas.

El modelo contendrá una lista de conceptos con un valor asociado que representa el nivel de conocimiento del alumno. Partiendo de estas especificaciones mínimas el marco de trabajo podría ampliar la estructura del modelo incluyendo cualquier otro tipo de información que satisfaga las necesidades del planificador de instrucción.

Además de un modelo de conocimientos, la mayoría de los sistemas educativos incluyen en sus modelos del alumno un modelo de aptitudes formado por un conjunto de características que definen distintos aspectos del perfil del alumno (académico, emocional, administrativo,...). De nuevo corresponde al marco de trabajo determinar el conjunto de variables y valores que lo conforman.

Existen dos operaciones básicas que se pueden realizar sobre el modelo del alumno: Consultar modelo y Actualizar modelo. La actualización del modelo se corresponde con el procedimiento de diagnóstico y su implementación depende del marco de trabajo.

5.2.3 Planificador de instrucción

La misión del módulo instructor o pedagógico en un WILE es la de planificar y controlar la instrucción del alumno. Este cometido se concreta en dos tareas: secuenciación del currículo y presentación del conocimiento (fases de currículo e instrucción según Halff (Halff, 1988) o de microadaptación y macroadaptación según la terminología introducida por Shute en (Shute and Towle, 2003)). Según esto, en un sistema de enseñanza inteligente, el módulo instructor es el encargado de determinar qué unidad de conocimiento debe ser seleccionada como objeto de aprendizaje o foco de instrucción y cómo debe ser presentado dicho conocimiento.

La función principal del planificador de instrucción es determinar en cada paso de la instrucción, el concepto del dominio más adecuado para ser aprendido por un alumno y la tarea que debería realizar para maximizar el aprendizaje de dicho concepto. La presentación del material asociado a una determinada tarea, así como el control, monitorización y, dado el caso, evaluación de la misma es responsabilidad de los recursos de instrucción. Dicho de otro modo, el planificador es el encargado de llevar a cabo la fase de microadaptación mientras que la macroadaptación se delega en los recursos de instrucción (capa 1).

Capítulo 5

El planificador se comunica con el resto de elementos del sistema a través de los siguientes servicios:

Concepto objetivo: seleccionará el concepto más adecuado para ser aprendido por el alumno en el momento actual del proceso de instrucción. Para tomar esta decisión analiza los modelos del alumno y del dominio.

Recurso objetivo: determinará el recurso de instrucción más apropiado para que un alumno aprenda un concepto dado. Esta decisión se basará en el estado actual del modelo del alumno y en las descripciones de los recursos de instrucción.

5.2.4 Interfaz

Es el componente a través del cual el alumno interactúa con el sistema. La interfaz viene dada por un conjunto de controles (botones y enlaces) que se insertan en una página en el navegador y a través de los cuales el alumno puede:

Seleccionar y ejecutar un recurso de instrucción: el alumno podrá realizar cualquiera de las tareas integradas en el WILE como RI.

Solicitar un plan de instrucción: el alumno tiene libertad para elegir cualquier tarea pero también puede delegar la elección de la misma en el planificador de instrucción.

Consultar y modificar el modelo del alumno: el alumno podrá inspeccionar su modelo y modificar aquellos datos que considere necesario.

5.3 Capa 1. Recursos de instrucción

Los recursos de instrucción (RI) representan tareas educativas que ayudan al alumno en el aprendizaje de los conceptos del dominio. Los datos necesarios para la localización y ejecución de un RI se almacenan en el registro de recursos de instrucción. Son elementos integrables dentro de la arquitectura del sistema siempre que sigan un conjunto de prerrequisitos que define MEDEA. En el marco de trabajo se determinarán las técnicas y procedimientos para gestionar físicamente el intercambio de datos y las llamadas a servicios entre los RI y los elementos del núcleo.

Los técnicos de la capa 1 representan a los desarrolladores de software encargados de implementar soluciones a problemas educativos siguiendo unas normas que lo hacen compatible con los elementos del núcleo. A lo largo de esta sección se describirán las características particulares que tendrá un elemento definido a esta capa y la forma en que se integra en el sistema.

128


129

CAPA 1 Recursos de instrucción

RIinteligenteestimativo

RIno

inteligente

RI inteligente

de diagnóstico

Registro de RI


CAPA 3. WILE

CAPA 0. Núcleo

Fig. 27 Elementos del nivel 1: los recursos de instrucción

5.3.1 El concepto de recurso de instrucción

Se define un recurso de instrucción (RI) como una entidad software cuyo cometido consiste en ejecutar una tarea educativa que ayude al alumno a alcanzar el aprendizaje de las unidades de conocimiento que forman parte de un dominio. La presentación del material asociado a la tarea, el control y monitorización de su ejecución y la evaluación de los resultados son responsabilidad del recurso.

La idea subyacente a este concepto no es nueva. A lo a largo de la historia teóricos de la educación, como Gagné o Merril, han usado en sus teorías conceptos como eventos de instrucción (Gagné and Briggs, 1979) o niveles de ejecución (Merrill, 1983) que representan de algún modo acciones instructivas que ayudan al sujeto a lograr el aprendizaje de una materia.

En el campo de los STI se ha aplicado este concepto bien implícitamente, en sistemas como WEST, WUSOR o SOPHIE, a través de juegos o entornos de simulación, bien explícitamente como IDE con sus unidades de instrucción (IU, Instructional Units) o IRIS con sus unidades básicas de aprendizaje (UBA). Asimismo en sistemas para la web, como DGC o ELM-ART, nos encontramos con ejercicios, problemas, preguntas de tests y otros tipos de tareas educativas.

El IEEE LTCS, en su afán por definir estándares que faciliten el desarrollo, mantenimiento e interoperabilidad de sistemas educativos por computador (computer-based education), ha desarrollado el concepto de objeto de aprendizaje (LO, Learning Object) (IEEE, 2005). Un LO se define como “entidad digital o no digital que puede ser usada, reutilizada o referenciada durante el aprendizaje basado en tecnología (technology-supported learning). Ejemplos de LO incluyen contenidos multimedia, contenido de instrucción, objetivos de aprendizaje, software de instrucción y herramientas software, así como personas, organizaciones o eventos referenciados durante el aprendizaje”.

Según esta definición, podría decirse que un RI es un LO que se ciñe a la categoría de “software de instrucción y/o herramientas software” y que añade al concepto tradicional de tarea, entendido como “unidad de instrucción”, el

Capítulo 5

hecho de poder ser “reutilizado y referenciado” por otros sistemas. Pero el concepto de RI va más allá, no se refiere sólo a un objeto que se pueda usar en un proceso de aprendizaje sino que el propio objeto incluye el modo en el que se enseña. Existen numerosos ejemplos de sistemas que, independientemente del dominio y el enfoque educativo, se ajustan a esta definición la definición de RI (Carmona et al., 2002; Conejo et al., 2004; Eliot et al., 1997; Loboda and Brusilovsky, 2005-2006; Tong and Agius, 1999; Trella et al., 2000)

5.3.2 Tipos de recursos de instrucción

Se ha definido un RI como una entidad software cuyo cometido consiste en ejecutar una tarea educativa. Las aplicaciones educativas para la web, siguiendo la clasificación propuesta en el Capítulo 3, se dividen en dos grandes grupos: inteligentes y no inteligentes. Según esto se establecen las siguientes categorías de recursos de instrucción:

RI inteligente: son aplicaciones educativas inteligentes para la web que mantienen sus propios modelos del alumno y del dominio. Para que una aplicación pueda ser considerada como un RI inteligente debe cumplir: a) que su modelo del dominio esté formado por un conjunto de conceptos y b) que su modelo del alumno sea un modelo de superposición. La justificación de estas restricciones es que para que dos sistemas inteligentes se comuniquen no es suficiente con establecer una comunicación a bajo nivel sino que ambos sistemas deben poder compartir su conocimiento. Para ello será necesario establecer una correspondencia entre los dominios del RI y del entorno de aprendizaje en el que este se integre. Un porcentaje bastante representativo de sistemas educativos presentan dominios basados en redes de conceptos y modelos de superposición (Brusilovsky, 2003) por lo que se ha considerado que estas restricciones no excluyen, como candidatos a RI, a un número muy elevado de sistemas.

Las aplicaciones educativas inteligentes para la web mantienen su propio modelo del alumno. Según el estudio realizado en el epígrafe 3.2, estos sistemas basan la gestión de sus modelos en el análisis de la interacción del alumno con el sistema o bien aplican alguna técnica de evaluación (tests, ejercicios, ...). Por ello agrupamos los RI inteligentes en dos categorías, según el tipo de gestión de su modelo del alumno:

- de diagnóstico: evalúan los resultados obtenidos por el alumno en la ejecución de su tarea y, a través de algún proceso de diagnóstico, establecen su nivel de conocimiento.

- estimativo: estiman el nivel de conocimiento del alumno a través de heurísticos que se basan principalmente en la observación de su interacción con el sistema. Normalmente, este tipo de RI usa parámetros como el número de páginas visitadas, el tiempo invertido en el desarrollo de una actividad, el número de veces que un alumno revisa una página ya visitada, etc.

130


131

La diferencia entre los RI de diagnóstico y estimativo radica en los métodos empleados para crear y mantener sus modelos del alumno: métodos formales de diagnóstico y heurísticos respectivamente.

RI no inteligente: aplicaciones educativas que no poseen un modelo del alumno propio. La realización de estas tareas no proporciona ninguna información acerca del nivel de conocimiento del alumno.

El IEEE LTSC, con el fin de facilitar la búsqueda, evaluación, adquisición y uso de LO, ha definido el estándar LOM (Learning Object Metadata) (LOM, 2004). Una instancia de un metadato de un LO describe características relevantes del mismo. El estándar LOM es usado y referenciado en otros estándares como el SCORM de ADL o el Metadata de IMS (ver 4.2). LOM establece categorías para los LO según distintos criterios. Con el fin de aproximarnos a los estándares internacionales para la descripción de LO se han establecido otras clasificaciones para los RI que representan sus características pedagógicas:

Tipo de tarea de aprendizaje, según este criterio los RI pueden pertenecer a uno o varios de los siguientes grupos: ejercicio, simulación, test, diagrama, figura, gráfico, índice, trasparencia, tabla, texto narrativo, examen, experimento, problema, auto-evaluación o lectura.

Tipo de interactividad, indica el modo de aprendizaje que predomina en el RI. Según esto un RI puede ser:

- Activo, este tipo de RI incita al alumno a realizar alguna acción cuya realización implique el uso de parte de conocimiento del dominio.

- Expositivo, el trabajo del alumno consiste principalmente en absorber el contenido que se le muestra.

- Mixto, el RI intercala aprendizaje activo y expositivo.

5.3.3 Registro de recursos de instrucción

El registro de recursos de instrucción almacena los datos necesarios para la localización y ejecución de un RI agrupándolos en dos documentos: 1) una descripción funcional, que contiene los datos técnicos necesarios para la ejecución del recurso y 2) una descripción semántica que guarda información para el intercambio de conocimiento entre distintos sistemas. El registro de RI representa lo que en otros sistemas es conocido por repositorio o a las páginas blancas en la terminología de sistemas no inteligentes.

5.3.3.1 Descripción funcional de un RI

Los estándares para metadocumentar objetos de aprendizajes como LOM, SCORM o IMS, están orientados a los LMS, que ofrecen tanto a alumnos como profesores una amplia variedad de materiales estructurados y metadocumentados, pero carecen de expresividad suficiente para definir ciertos elementos y características de un sistema inteligente.

Capítulo 5

Sin embargo, teniendo presente que el objetivo principal de esta tesis es construir sistemas inteligentes heterogéneos, formados a base de integrar otras aplicaciones, se ha considerado de interés seguir las tendencias de la comunidad educativa en cuanto a descripción de LO y ajustar la descripción funcional de los RI al estándar LOM en la medida de lo posible. El estándar LOM contiene un conjunto del orden de ochenta atributos organizados en nueve categorías que sirven para describir un objeto de aprendizaje (Tabla 16, epígrafe 4.2.3.1). De este modo, además de los datos técnicos necesarios para la ejecución del recurso (principalmente localización del recurso y nombre y tipo de los parámetros) se han añadido otros atributos a modo de meta-documentación del recurso.

A continuación se muestra una tabla con los atributos de la descripción funcional de un RI en la que se incluye el nombre y descripción del atributo y se indica su pertenencia o no al estándar. La tabla indica los valores que puede tomar un atributo y si este es un subconjunto o una extensión de los valores correspondientes definidos en LOM.

ATRIBUTO DESCRIPCIÓN CATEGORÍA LOM

VALORES

Identifier Etiqueta que identifica el RI General

Parameters Parámetros de ejecución del RI (nombre y tipo)

Location URL en la que se usada para acceder al RI Technical

Language Idioma del interfaz del RI General

Description Texto que describe la tarea asociada al RI General

Version Life Cycle

Status El estado de terminación del RI Life Cycle

draft final revised unavailable

Entity Identificación de los creadores del RI Life Cycle

Date Fecha de creación del RI Life Cycle

Format Tipos de datos del contenido del RI (p.e. video/mpeg, image/gif, text/html...) Technical Tipos MIME

RI type Tipo de estimación del nivel del conocimiento del alumno.

intelligent/estimative intelligent/diagnostic non intelligent

Tabla 18 Atributos de la descripción funcional de un RI

5.3.3.2 Descripción semántica de un RI

La descripción semántica incluye una descripción pedagógica del RI usada para planificar la instrucción y los datos necesarios para establecer una

132


133

comunicación entre sistemas educativos inteligentes a nivel semántico (Tabla 19).

Algunos RI son sistemas educativos inteligentes que, por lo tanto, tienen sus propios modelos del dominio y del alumno. Para poder usar un sistema de este tipo desde un entorno de aprendizaje inteligente no es suficiente con información técnica acerca de como localizarlo y ejecutarlo (descripción funcional) también es necesario establecer una comunicación a nivel semántico, conociendo el significado de los datos intercambiados (descripción semántica).

Un WILE se usará para instruir al alumno acerca de un dominio específico. Las herramientas usadas para la enseñanza serán diversas tareas educativas (encarnadas por los RI). Por lo tanto, un WILE debe “conocer” cada uno de los modelos del dominio sobre los que se está desarrollando la instrucción del alumno y los resultados obtenidos en la realización de cada tarea. El problema de determinar cómo los sistemas pueden compartir el conocimiento ha sido estudiado, entre otros, dentro del campo de la Ingeniería Ontológica (Mizoguchi. R. and Bourdeau, 2000), los Sistemas Multi-Agentes y las organizaciones internacionales de definición de estándares (IEEE LTSC, IMS, etc.). Este es un problema complejo que aún no ha sido resuelto. Para que dos sistemas se comuniquen a este nivel es necesario que compartan una ontología y un lenguaje o protocolo de comunicación. A pesar de los avances en el desarrollo de estándares multi-agentes (FIPA, KQLM, etc.) y marcos de trabajo (FIPA-OS, JADE, etc.) integrar cualquier tipo de recurso educativo (sea o no agente) existente en la web, independientemente de su naturaleza e implementación es, en la práctica, un objetivo difícil de conseguir.

En esta tesis se ha optado por una solución intermedia, alejada de los sistemas multi-agentes, pero factible desde el punto de vista de la integración real de sistemas, basada en utilizar el concepto como unidad mínima para el intercambio de conocimiento.

Modelo del dominio definido por el profesor en el nivel 2

Modelo del dominio del RI

Fig. 28 Correspondencia entre los conceptos de un dominio definido para MEDEA y un dominio

perteneciente a un RI

En el problema que nos ocupa los WILE deben compartir conocimiento acerca del alumno y del dominio. La definición de RI inteligente indica que su modelo del dominio está formado por un conjunto de conceptos (no se imponen

Capítulo 5

restricciones acerca de las relaciones entre conceptos) y que su modelo del alumno es un modelo de superposición. Del mismo modo se han definido los modelos del dominio y del alumno del núcleo (capa 0). Según esta definición, para compartir conocimiento del dominio tan sólo sería necesario establecer las correspondencias entre ambos dominios tal y como se muestra en la ¡Error! No se encuentra el origen de la referencia.. Estas conexiones sólo podrán ser establecidas una vez que el experto haya definido la estructura de un dominio concreto, por lo que esta tarea corresponde a la siguiente capa de la metodología. En el epígrafe 5.4 se hace referencia a este punto.

En cuanto al modelo del alumno ya se ha apuntado que, tanto en los RI como en el núcleo, viene dado por un modelo de superposición que contendrá un subconjunto de conceptos del dominio con un valor asociado representando el nivel de conocimiento del alumno. Para compartir los datos entre uno y otro modelo será necesario conocer la escala de valores usada por cada RI para medir al alumno y poder de ese modo interpretar los niveles alcanzados por un alumno en la realización de una tarea. Por ejemplo un RI podría evaluar al alumno con un valor binario del tipo: “Se lo sabe- No se lo sabe”, “0-1” o “apto-no apto”, o bien con un valor numérico en un intervalo discreto: “5.6 en una escala de 1 a 10” o un valor perteneciente a un conjunto de valores: “A, B, C, D”, “alto, medio, bajo” o “bien, mal, regular”. El programador del RI es quien conoce este dato (atributo Mark Type)y será por tanto el encargado de proporcionarlo. El grado de compatibilidad de los RI con el WILE del que formen parte dependerá de las escalas de valores admitidas en la capa 0, estos detalles forman parte del marco de trabajo que implemente la metodología.


VALORES

Interactivity type Modo de aprendizaje dominante en el RI Educational

active expositive mixed

Learning Resource Type

Tipo de material de aprendizaje predominante en el RI Educational

exercise simulation questionnaire diagram figure graph index slide table narrative text exam experiment problem statement self assessment lecture

Interactivity level

Grado de interactividad del alumno con el RI Educational

very low low

134


135


VALORES

medium high very high

Context Entorno idóneo para aplicar el RI Educational

school high school training other

Typical Age Range

Rango de edad del usuario al que va dirigido el RI Educational

Difficulty Grado de dificultad para trabajar con el RI Educational

very easy easy medium difficult very difficult

Mark Type Escala de valores con la que el RI mide el conocimiento del alumno

Ej. [0, 10] {A, B, C, D, E} {Bien, Regular, Mal}

Tabla 19 Atributos de la descripción semántica de un RI

5.3.4 Servicios de un recurso de instrucción

Los RI se comunican con los WILE en los que se integren a través del siguiente conjunto de servicios:

Inicio de la ejecución: inicia la ejecución de una sesión con el RI.

Fin de la ejecución: concluye la ejecución de la actividad a petición del usuario o del WILE devolviendo, en caso de tratarse de un RI inteligente, el modelo de conocimiento del alumno.

Nuevo usuario: crea un nuevo modelo de usuario en el RI y lo asocia al perfil de usuario del WILE. Si el RI tiene capacidad de ejecutar sesiones anónimas no es necesario usar este servicio.

Exportar modelo del alumno: devuelve el modelo de un alumno.

Exportar modelo del dominio: devuelve la lista de conceptos que forman parte del dominio.

5.3.5 Protocolo de actuación para el técnico

Una vez definidos los elementos que forman el cuerpo de conocimiento de la capa 1 (recursos de instrucción y sus descripciones), es necesario establecer las acciones que debe llevar a cabo un técnico para crear un RI e integrarlo en la arquitectura de un WILE.

1. Implementación del RI

Capítulo 5

Un RI es una entidad software que puede usarse como herramienta independiente, pero en caso de que se quiera integrar como parte de un WILE MEDEA (sistema resultante de aplicar la metodología de desarrollo MEDEA), el desarrollador deberá proporcionar los servicios que se exigen a un recurso de instrucción, a través de los cuales se comunica con el resto de módulos del núcleo (ver 5.3.4): Inicio de la ejecución, Fin de la ejecución, Nuevo usuario, Exportar modelo del alumno y Exportar modelo del dominio. Los detalles acerca de la implementación de estos servicios dependerán de la tecnología empleada por el marco de trabajo en su módulo gestor de comunicaciones. En el Capítulo 4 se ha realizado un recorrido por las técnicas disponibles actualmente para el desarrollo de sistemas inteligentes distribuidos en la red.

2. Integración del RI

Una vez implementado un RI de modo que sea compatible con los elementos del núcleo, se debe proporcionar la descripción funcional del recurso que incluirá los datos necesarios para su localización y ejecución (URL, nombre de los servicios, parámetros, etc.). Además de esta información el técnico debe proporcionar, como parte de la descripción semántica del RI, la escala (o escalas) de valores con las que el RI mide el conocimiento de un alumno (“un número del 0 al 10”, “A, B, C o D”, etc.).

En el siguiente capítulo se describe el procedimiento seguido para la integración de los sistemas SIGUE (Carmona et al., 2002), SIETTE (Conejo et al., 2004) y WADEIn-II (Loboda and Brusilovsky, 2005-2006) como RI de un WILE.

5.4 Capa 2. Conocimiento de instrucción

Uno de los objetivos de la metodología que se está definiendo es permitir la construcción de WILE por usuarios no especializados: los profesores. Un WILE basado en esta metodología delega la fase de macroadaptación o instrucción en los recursos de instrucción. Esto significa que el RI será el encargado de plantear al alumno una tarea que le conduzca a la adquisición de determinados conocimientos. Por tanto, un entorno de aprendizaje no podrá ser construido si el marco de trabajo no proporciona al menos un RI que pueda ser usado para la instrucción del alumno.

Una vez integrado el primer RI el marco de trabajo está preparado para ser usado por los profesores para crear sus entornos de aprendizaje. A partir de aquí la incorporación de nuevos recursos puede realizarse en cualquier momento de la vida del marco de trabajo, es decir, este proceso se puede simultanear con el resto de fases del proyecto teniendo en cuenta que hasta que un RI no esté integrado no podrá ser usado por un profesor para construir un WILE y en consecuencia tampoco los alumnos tendrán acceso al mismo.

En esta capa hay dos tipos de usuario, el experto en el dominio y el profesor, aunque es habitual en el desarrollo de sistemas educativos que una misma persona encarne ambos roles. La construcción de un entorno de aprendizaje se llevará a cabo en dos fases diferenciadas: 1) el experto crea el

136


137

dominio (5.4.1) y 2) el profesor modela un entorno de aprendizaje haciendo uso de los dominios definidos y los RI disponibles (5.4.2).

En la Fig. 29 se muestra un ejemplo de instanciación de la capa 2 en el que el profesor ha definido un entorno de aprendizaje para el dominio de Lógica e incluido los RI SIGUE, SIETTE y WADEIn-II como tareas para que las realicen sus alumnos.

CAPA 2 Conocimiento de instrucción


CAPA 3. WILE

Modelo del dominio X

CAPA 0. Núcleo

Estrategias de

enseñanza

Fig. 29 Ejemplo de instanciación de recursos de instrucción (capa 1) y elementos del núcleo (capa 0)

5.4.1 Protocolo de actuación para el experto

Para poder construir un entorno de aprendizaje es necesario modelar el dominio sobre el que versará. Esta tarea corresponde a un experto que deberá estructurar el dominio en un conjunto de conceptos, entendidos como unidades básicas de conocimiento.

El experto tiene libertad para establecer la granularidad de su dominio pero está sujeto a algunas restricciones, impuestas por el marco de trabajo específico sobre el que se esté desarrollando el sistema, que determinarán a) el conjunto de atributos que se puede usar para definir un concepto (por ejemplo nombre, identificador, dificultad, tipo, etc.) y b) las relaciones que pueden ser usadas para conectar los conceptos (por ejemplo “prerrequisito”, “es un”, “sirve para”, etc.).

5.4.2 Protocolo de actuación para el profesor

El profesor es el encargado de dar forma a un entorno de aprendizaje. Esta tarea implica el diseño de la instrucción del alumno dotando al sistema de contenidos y definiendo sus estrategias de enseñanza.

El marco de trabajo le proporciona la funcionalidad propia de un STI, definida en el núcleo, permitiéndole abstraerse de detalles propios de la gestión de modelos del alumno y planificación.

Además, el profesor cuenta con los recursos de instrucción integrados en la capa 1. Este hecho le permite reutilizar no sólo contenidos sino toda la

Capítulo 5

inteligencia asociada a cada RI, ahorrándole un trabajo que de otra forma recaería sobre él, como por ejemplo definir los detalles acerca de la realización de un ejercicio, los métodos para evaluar una determinada habilidad, la forma de presentar una secuencia de textos, etc. El profesor concentrará su esfuerzo en establecer una estrategia global de adaptación de la instrucción: qué debe estudiar y qué herramientas utilizar para ello.

Por último el profesor contará para diseñar su WILE con los dominios definidos por el experto.

El procedimiento para la creación de un entorno de aprendizaje se resume en los siguientes pasos:

1. Selección del dominio

El profesor deberá seleccionar uno de entre todos aquellos dominios incluidos en el marco de trabajo que modelen la materia sobre la que versará su entorno de aprendizaje.

2. Selección de los RI

2.1. El profesor debe definir su estrategia de enseñanza y para ello determinará qué tareas (RI) podrá realizar el alumno con el fin de ayudarle en su aprendizaje. Cada tarea lleva asociados sus propios contenidos y métodos de presentación. Sólo podrán añadirse nuevos contenidos (por ejemplo preguntas de tests, ejercicios, textos,...) si el RI correspondiente ofrece esa posibilidad. En ese caso, la inserción de nuevo material se hará a través de su herramienta de autor.

2.2. Tal y como se adelantó en la descripción de la capa 1, un requisito importante de esta fase es establecer la correspondencia entre el dominio seleccionado y el de cada RI que se vaya a usar en el entorno (¡Error! No se encuentra el origen de la referencia.). Estas relaciones formarán parte de la descripción semántica del RI. Sin esta información el RI será incapaz de comunicarse con los elementos del núcleo.

3. Adaptación de las tareas a los perfiles del alumno

El profesor puede establecer, como parte de su estrategia de enseñanza, qué tareas son mas adecuadas que otras para un determinado tipo de alumno, asociando un perfil de alumno a un perfil de RI (Fig. 30) o a un conjunto de parámetros de ejecución (Fig. 31). Así un profesor podría decir, por ejemplo, que para un alumno de “nivel bajo” pero con “alta capacidad de concentración” es mejor usar un RI del tipo “texto narrativo” y un “nivel de interactividad medio” mientras que otro con “nivel de concentración bajo” debería usar mejor un “experimento” con un “alto nivel de interactividad” que sea capaz de acaparar su atención. La adaptación de la instrucción a cada alumno dependerá, además del

conocimiento de instrucción aportado por el profesor en esta capa, de las estrategias de planificación y de la gestión del modelo del alumno implementadas en el marco de trabajo.

138


139

Fig. 30 Asociación de un conjunto de propiedades de un RI a un parfil de un alumno

Fig. 31 Asociación de un conjunto de parámetros de ejecución de un RI a un parfil de un alumno

5.5 Capa 3. El aprendizaje

La ejecución de los procedimientos de actuación de las capas inferiores dan como resultado un WILE que está formado por los elementos que se muestran en la Fig. 32. Una vez construido un entorno de aprendizaje el alumno podrá utilizarlo para estudiar un dominio.

Los STI se basan en la enseñanza individualizada, que se erige, según demuestran los trabajos de Bloom (Bloom, 1984), en una de las formas más efectivas de garantizar el aprendizaje. Sin embargo, según apunta Reigeluth (Reigeluth, 1996) existen otras estrategias apropiadas para un situación de aprendizaje a distancia, como es el caso que nos ocupa, que se podrían usar en un entorno de aprendizaje inteligente y que incluyen la instrucción centrada en el alumno pero combinando orientación y guía con auto-aprendizaje de forma que los alumnos puedan elegir entre distintos métodos (problemas, aprendizaje basado en proyectos, simulaciones, etc.).

Por otro lado, el aprendizaje en la web a través de un sistema hipermedia tradicional es un ejemplo de aprendizaje constructivista en el que se favorece la libre exploración del espacio de conocimientos. El uso masivo de estos sistemas, que crearon grandes expectativas en el campo de la educación, puso en evidencia importantes limitaciones que se pueden resumir en desorientación (el alumno “se pierde” en el hiperespacio) y sobrecarga cognitiva (exceso de información) (Kinshuk and Patel, 1997b). El uso de técnicas de adaptación y planificación de la instrucción en sistemas para la web tiene por objeto paliar estas dificultades pero sin traicionar las bases del aprendizaje constructivista.

Características de un RI Perfil de un alumno

Tipo de recurso = trasparencia

Tipo de interactividad = mixta

Rango de edad = 30-35

Dificultad= fácil

Desarrollo cognitivo = medio

Motivación = alta

Edad = >=30

Parámetros de ejecución del RI SIETTE Perfil de un alumno

Critselection = 2

Viewcorrection = 0 Desarrollo cognitivo = medio

Motivación = alta

Edad = >=30

Capítulo 5

MEDEA se sustenta en estos principios y permite a los alumnos establecer su propia estrategia de instrucción (dentro de los límites dictados por el profesor) y elegir entre distintos métodos de enseñanza (representados por los RI), ofreciéndole al mismo tiempo asesoramiento en esta tarea.

CAPA 3 WILE RI

inteligente estimativo:

SIGUE

RIinteligente

de diagnóstico:

SIETTE


Modelo del dominio: Lógica

Modelo de usuario i

CAPA 0. Núcleo

Planificador de

instrucción

Interfaz


Estrategias de

enseñanza

Fig. 32 Elementos de un WILE obtenido tras la aplicación de los protocolos de actuación de las capas

inferiores de la metodología de desarrollo

El proceso de aprendizaje es una secuencia de tareas (Shute and Towle, 2003) de macroadaptación y microadaptación en las que el alumno sucesivamente va seleccionando un concepto del currículum (microadaptación) y una tarea que le ayude a asimilarlo (macroadaptación). MEDEA actúa como un asesor indicando al alumno cuál sería el siguiente paso más adecuado en su proceso de instrucción. Quizá la mejor forma de ilustrar el comportamiento de MEDEA es compararlo con el comportamiento de un tutor personal. Supongamos que un alumno desorientado llega a un centro educativo donde se le asigna un tutor personal. El alumno mantiene una entrevista con su tutor en la que muestra sus intereses, sus conocimientos previos, sus estilos preferidos de aprendizaje y cualquier otra información que su tutor considere relevante. Con todos estos datos el tutor selecciona la asignatura más adecuada para él y busca el profesor con el que, en su opinión, su alumno obtendrá un mejor rendimiento. El tutor realiza un seguimiento de su alumno manteniendo una comunicación constante con el profesor. La Tabla 20 compara ambos procedimientos e identifica los actores encargados de cada tarea y establece las entradas y salidas de cada uno de los pasos de instrucción.

APRENDIZAJE TRADICIONAL ENTORNO DE APRENDIZAJE INTELIGENTE

PASO DE INSTRUCCIÓN ACTOR ENTRADA SALIDA ACTOR ENTRADA SALIDA

Pedir asesoramiento para estudiar una asignatura

Alumno Temario Alumno Modelo del dominio

140


141

APRENDIZAJE TRADICIONAL ENTORNO DE APRENDIZAJE INTELIGENTE

PASO DE INSTRUCCIÓN ACTOR ENTRADA SALIDA ACTOR ENTRADA SALIDA

Expediente académico

Modelo de conocimiento del alumno Seleccionar el

tema más apropiado

Tutor Características

personales del alumno

Siguiente tema a estudiar

Planificador de instrucción Modelo de

aptitudes del alumno

Siguiente tema a estudiar

Seleccionar la tarea de aprendizaje más adecuada

Tutor

Estilos preferidos Plantilla de profesores

Un profesor

Planificador de instrucción

Perfil del alumno Registro de RI

Un recurso de instrucción

Nota del tutor incluyendo el tema que debe estudiar y cualquier otra información relevante.

Mensaje del planificador incluyendo el objetivo de instrucción y cualquier otra información relevante.

Material de aprendizaje del profesor

Material de aprendizaje del RI

Temario Modelo del dominio del RI

Ejecución de la instrucción

Profesor

Conocimientos previos del alumno

Resultados del alumno

Recurso de instrucción

Modelo del alumno del RI

Modelo del alumno del RI

Actualización del estado de conocimiento del alumno

Tutor

Rendimiento del alumno según su profesor

Expediente académico actualizado

Gestor del modelo del alumno

Modelo del alumno parcial del RI

Modelo del alumno actualizado

Tabla 20. Educational advising in traditional learning and in MEDEA.

Resumiendo, el alumno entra en el sistema y sus acciones en él son las siguientes:

1. Solicitar ayuda al planificador que determinar el concepto y RI más adecuado.

2. Elegir un concepto del dominio

3. Elegir un RI y realizar la tarea asociada

El alumno puede seguir las indicaciones del planificador o su propio criterio según estime oportuno.

Capítulo 5

5.6 Conclusiones

En este capítulo se presenta una propuesta para el desarrollo de entornos de aprendizaje mediante la integración de piezas de software independientes que cooperen para alcanzar un objetivo común de instrucción, apoyados por la metodología MEDEA.

MEDEA, como metodología, plantea una forma de trabajo que considera los tipos de usuario involucrados en un sistema educativo y las necesidades que se plantean en su contexto. MEDEA ofrece un compromiso entre las formas rígidas de trabajo, que no dan opción a la creatividad y reutilización de elementos externos, y la absoluta libertad en la forma de definir un sistema, que es lo más parecido a empezar a desarrollar un sistema desde cero, y no permite la reutilización de sistemas y herramientas anteriores. Por otro lado, esta metodología es una apuesta por la integración en varios aspectos: 1) permite que se utilicen desarrollos anteriores; 2) plantea un marco en la que el docente se ocupa de la “forma de enseñar y en el cómo” porque el “qué” ya se le da preparado y 3) ofrece un marco interesante para observar los procesos de enseñanza y aprendizaje desde varias perspectivas, que son las que se corresponden con los actores descritos anteriormente.

En la Tabla 21 se resumen todas las capas de la metodología:

CAPA ACTOR TAREAS DESCRIPCIÓN

0 Desarrollador del núcleo

0. Implementación de los elementos del núcleo

Se sientan las bases del WILE construyendo sus modelos del alumno y del dominio, su planificador de instrucción y definiendo su interfaz.

1 Creador del recurso de instrucción

1. Integración de recursos de RI 1.1. Implementación del RI 1.2. Integración del RI

En esta capa los RI se incorporan al marco de trabajo.

2. Construcción de UN WILE 2

Experto del dominio 2.1. Creación dominio

El experto estructura el conocimiento acerca de un determinado dominio.

142


143

CAPA ACTOR TAREAS DESCRIPCIÓN

Profesor

2.2. Construcción de un entorno de aprendizaje (WILE) 2.2.1. Selección del dominio 2.2.2. Selección de los RI

2.2.2.1. Determinar la tarea (o tareas) que ayudarán al alumno a estudiar cada concepto del dominio.

2.2.2.2. Establecer la correspondencia entre el dominio seleccionado y el dominio de cada RI.

2.2.3. Adaptación de cada tarea a los perfiles de los alumnos

El profesor modela un WILE haciendo uso de los dominios definidos en el marco de trabajo y los RI disponibles.

3 Estudiante

3. Aprendizaje. Mientras dure el proceso:

3.1. Solicitar ayuda al planificador 3.2. Elegir concepto del dominio 3.3. Elegir RI y realizar la tarea

asociada

Los alumnos harán uso del WILE para adquirir conocimientos acerca de un determinado dominio.

Tabla 21 Proceso de enseñanza y aprendizaje mediante un WILE basado en la integración de aplicaciones educativas.

Para poner en práctica esta metodología es necesario contar con un marco de trabajo que la implemente. El siguiente capítulo versa sobre este punto y en él se explican con detalle cada uno de las acciones necesarias para integrar sistemas externos y utilizarlos para la creación de un nuevo WILE. Este proceso tratará de mostrar que tanto la metodología aquí definida y la arquitectura sobre la que se sustenta cumple las siguientes características:

Reutilización de software, todos los WILE creados podrán usar y compartir los recursos incluidos en el marco de trabajo.

Bajo coste de desarrollo, una vez creado un marco de trabajo el desarrollo de sistemas educativos inteligentes se reduce a la definición del dominio de enseñanza y a la selección de los RI que formarán parte del nuevo WILE.

Carácter genérico, el marco de trabajo permite el desarrollo de WILE sobre distintos dominios y la utilización de distintas estrategias de enseñanza

Capítulo 6 MARCO DE TRABAJO PARA LA CONSTRUCCIÓN DE ENTORNOS DE APRENDIZAJE INTELIGENTES PARA LA WEB

Esta tesis se enfrenta al problema del desarrollo de entornos de aprendizaje inteligentes para la web (WILE). La solución que se propone consiste en integrar sistemas externos incrementando de ese modo la versatilidad de los sistemas actuales y disminuyendo los costes de desarrollo. Esta propuesta se concreta en MEDEA (MEtodologías y herramientas para el Desarrollo de entornos inteligentes de Enseñanza y Aprendizaje).

El planteamiento de MEDEA se basa en las tesis de Newell que sostienen que un sistema basado en el conocimiento puede verse como una jerarquía de niveles. En el nivel superior se encuentra el nivel del conocimiento que se centra en identificar las acciones y áreas de conocimiento que explican el comportamiento inteligente del sistema (¿qué hace?, ¿qué sabe?). El siguiente es el nivel simbólico que utiliza lenguajes de programación para describir procedimientos y estructuras de datos. En él se toman las decisiones necesarias para construir un modelo que se comporte conforme a la descripción del nivel de conocimiento. MEDEA comprende una metodología de desarrollo (nivel del conocimiento) y un marco de trabajo para la construcción de WILE (nivel simbólico).

En el capítulo anterior se ha descrito en el nivel del conocimiento que trata de identificar los distintos elementos que conforman un sistema de estas características, los métodos y técnicas necesarios para su construcción y los distintos actores que intervienen en este proceso. Todo esto configura una metodología de desarrollo en cuatro capas. Los elementos de la capa 0 vienen definidos por el paradigma de los STI (modelo del alumno, del dominio, modelo de instrucción e interfaz) y sientan las bases del WILE que se pretende construir. La capa 1 añade los recursos de instrucción (RI), entidades software encargadas de ejecutar una tarea educativa. En la capa 2 un experto será el encargado de modelar el dominio y un profesor dará forma al entorno de

144

Marco de trabajo para la construcción de entornos de aprendizaje inteligentes para la web

aprendizaje haciendo uso de los dominios definidos y los RI disponibles. La capa 3 corresponde al proceso de aprendizaje llevado a cabo por el alumno.

Una vez establecida una metodología es necesario construir un modelo que se le ajuste. Este modelo ha sido implementado en un marco de trabajo, entendido como “una aplicación semi-completa y reutilizable que puede ser especializada para producir aplicaciones a medida” (Johnson and Foote, 1988), que permite la construcción de WILE por usuarios no especializados. Este capítulo se centra en la descripción del mismo.

Es importante resaltar que el objetivo de esta tesis no es demostrar la eficacia de las estrategias de instrucción implementadas. La efectividad pedagógica de los entornos generados a partir de MEDEA dependen en gran medida del dominio concreto para el que se han construido y del conocimiento de instrucción aportado por el profesor, por lo que la evaluación de los resultados obtenidos con alumnos debería llevarse a cabo con cada WILE en particular. La construcción del marco de trabajo atiende a la necesidad de mostrar la validez de la metodología definida en el Capítulo 5, teniendo en cuenta que debe permitir reutilizar sistemas educativos con unos costes de desarrollo aceptables. Por lo tanto las estrategias de instrucción, estilos de aprendizaje y la gestión de los modelos del alumno y del dominio descritos en este capítulo deben ser vistos como un ejemplo de implementación, cualquiera de estos módulos podría ser sustituido por otro siempre que se ajuste a las especificaciones de la metodología. Este enfoque permite la construcción de distintos marcos de trabajo basados en la misma metodología de desarrollo.

Este capítulo se centra en la descripción de la implementación de las capas 0 y 1 de la metodología. En primer lugar se presentan los elementos del núcleo (interfaz, modelo del alumno, planificador de instrucción, modelo del dominio). A continuación se muestra el proceso de integración de los recursos de instrucción SIGUE (Carmona et al., 2002), SIETTE (Conejo et al., 2004) y WADEIn II (Loboda and Brusilovsky, 2005-2006) de los que el profesor hará uso en la capa 3 para dar forma a un entorno de aprendizaje. Las fases de conocimiento de instrucción y aprendizaje (capas 2 y 3) se abordan en el siguiente capítulo.

6.1 Capa 0. El núcleo.

La metodología de desarrollo MEDEA define el núcleo como un conjunto de cuatro módulos (del dominio o experto, del alumno, instructor o pedagógico y de comunicación o entorno) que vienen determinados por el paradigma de los STI (Fig. 26). En el epígrafe 5.2 se describe el conjunto de especificaciones mínimo que deben cumplir los elementos del núcleo para que sea posible la integración de otros sistemas como componentes del marco de trabajo. Partiendo de estas especificaciones, la implementación de un marco de trabajo fijará los detalles relativos a las estructuras y gestión de los modelos del dominio y del alumno, así como las estrategias de planificación.

145

Capítulo 6

6.1.1 Modelo del dominio

Para que dos sistemas inteligentes puedan comunicarse deben ser capaces de compartir su conocimiento. El estudio realizado en el Capítulo 3 sobre los sistemas educativos inteligentes, pone en evidencia el hecho de que numerosos sistemas educativos para la web suelen incluir en su dominio una red semántica de conceptos relacionados. Con el fin de facilitar la integración de sistemas externos, MEDEA especifica que un dominio debe venir dado como un conjunto de conceptos, permitiendo de este modo establecer correspondencias entre las unidades de conocimiento de uno y otro modelo (epígrafe 5.2).

La metodología no establece ninguna restricción acerca de las relaciones permitidas entre conceptos ni de los atributos que se usarán en la definición de los mismos. La interpretación de ambos vendrá determinada por las necesidades del planificador de instrucción incluido dentro del marco de trabajo. Por tanto, en esta sección tan sólo se definen los atributos y relaciones que configurarán el modelo, dejando para el planificador (6.1.3) el uso que de los mismos se haga dentro del proceso de instrucción.

Para la definición de un modelo en un sistema instructor es necesario tener en cuenta la finalidad pedagógica del mismo. Este hecho influye en dos aspectos importantes: por un lado en el nivel de descomposición del dominio (granularity) y por otro en la necesidad de incluir conocimiento pedagógico en el modelo (Murray, 1998), es decir, información que, de modelarse el dominio con otro propósito que no fuese la instrucción, no se incluiría, como por ejemplo la dificultad para aprender un determinado concepto o una relación de prerrequisito que indica el orden en el que dos conceptos deben aprenderse.

Respecto a la primera cuestión, y coincidiendo con Anderson (Anderson, 1988), es necesario tener en cuenta que a veces modelar fielmente un dominio puede resultar una carga computacional innecesaria e irrelevante para el propósito tutorial. De cualquier modo, la decisión de hasta qué punto debemos descomponer las unidades de conocimiento en unidades más simples, está estrechamente relacionada con el dominio concreto que se esté modelando y, por lo tanto, no corresponde a la capa de la que se ocupa este epígrafe. Esta tarea corresponde a la capa 2 (7.1.1) y es responsabilidad del profesor dotar de contenido la estructura que aquí se define.

Las ontologías constituyen una conceptualización explícita de un dominio de conocimiento (Gruber, 1993). Según (Mizoguchi. R. and Bourdeau, 2000), se presentan como una herramienta válida para el diseño de entornos educativos, no sólo en la representación de un dominio particular sino en el establecimiento de un vocabulario común para el dominio de la educación y la instrucción, lo que supone un primer paso hacia la estandarización. Mizoguchi define tres niveles de ontologías. El primero de ellos representa una colección estructurada de términos. El lenguaje XML permite al usuario definir sus propias etiquetas y representar de este modo, no sólo información estructural sobre un documento sino también semántica. Según Mizoguchi, un conjunto de etiquetas XML pueden considerarse un tipo de ontología de primer nivel. Quizá por ello, y

146


debido en gran parte al auge de aplicaciones basadas en el conocimiento sobre la web, se han desarrollado en los últimos tiempos lenguajes para la descripción de ontologías basados en XML (ver epígrafe 4.3.1). Para definir ontologías ligeras o de primer nivel (no contienen axiomas) cualquiera de estos lenguajes sería válido. OXML (4.3.1.7), ha sido el elegido para representar el conocimiento del dominio en MEDEA. Aunque actualmente existen otros lenguajes más extendidos, principalmente OWL (desarrollado por la W3C), no existían especificaciones estables de ninguno de ellos en las fechas en las que se estaba implementando este módulo del marco de trabajo.

6.1.1.1 Atributos

Murray (Murray, 1998) defiende la importancia de incluir conocimiento pedagógico en el modelo del dominio para poder guiar al alumno de forma adecuada a través de las unidades de conocimiento. Parte de este conocimiento pedagógico se ha incluido en este modelo en forma de atributos de conceptos. La elección de los mismos recae enteramente en el proceso de implementación del núcleo del marco de trabajo y es responsabilidad de los diseñadores del mismo. El marco de trabajo que se describe en este capítulo define los siguientes atributos:

Dificultad: representa la noción intuitiva de dificultad intrínseca para aprender el concepto y es estimada por el profesor. Se contemplan tres niveles de dificultad: alta, media y baja.

Nota mínima: es el umbral que establece el profesor por debajo del cuál el concepto se considera no aprendido.

Tipo de evaluación: el modelo del alumno de MEDEA es un modelo de superposición. Cada concepto tiene una magnitud asociada que indica el nivel de conocimiento del alumno. El atributo tipo de evaluación representa el tipo o formato de representación de esta magnitud. Se contemplan tres de los tipos más usados en el campo del modelado del alumno:

- Enumerado: el concepto puede tomar como magnitud un elemento de la lista asociada al mismo, por ejemplo “bien, regular, mal”.

- Real: el valor del concepto será un número real dentro de un intervalo fijado por el profesor.

- Distribución: sus valores se expresan en forma de pares etiqueta/probabilidad indicando la probabilidad de que un alumno tenga la nota dada por la etiqueta. Por ejemplo si el valor del concepto A es {A/0.2, B/0.3, C/0.4, D/0.1} existe una probabilidad 0.2 de que el nivel de conocimiento del alumno sea A, 0.3 de que sea B, etc.

6.1.1.2 Relaciones

El análisis de sistemas educativos que utilizan redes semánticas para representar el conocimiento del dominio (capítulos 2 y 3) nos lleva a la conclusión de que, aunque algunas de las relaciones que se establecen entre los

147

Capítulo 6

conceptos dependen directamente del dominio que se esté representando (por ejemplo las relaciones causales y temporales de WHY), la mayoría de los sistemas utilizan relaciones más o menos genéricas que permiten seleccionar y secuenciar los elementos de sus modelos. Algunos ejemplos los encontramos en IDE (sub-concepto, sub-habilidad, prerrequisito), EON (prerrequisito, parte-de, es–un, contexto-para), IRIS (prerrequisito, es-un, parte-de, es-efecto-de,...) o ELM-ART (es_un, parte_de, prerrequisito). La mayoría de estas relaciones recaen en las dos primeras categorías, de las cuatro establecidas por Reigeluth en la Teoría de la Elaboración (de requisito, conceptuales, prodedurales, teóricas) (Reigeluth, 1983). Algunos sistemas como DGC, InterBook o el modelo cognitivo descrito en (Rodríguez, 2000), incluyen en el dominio, además de conceptos, páginas, actividades u otro tipo de material, lo que implica el establecimiento de relaciones entre ambos como es_ejemplo_de, analogía, explica_a, se_realiza_sobre etc.

IMPLEMENTACIÓN DEL MODELO DEL DOMINIO(MARCO DE TRABAJO)

CONCEPTO i NombreDificultad Nota mínima Tipo de evaluación

CONCEPTO k

....

CONCEPTO m

....

CONCEPTO l

.... CONCEPTO n ....

prerrequisito parte_dees_un

pertenece_a

ESPECIFICACION DEL MODELO DEL DOMINIO (METODOLOGÍA DE DESARROLLO)

CONCEPTO i CONCEPTO k

CONCEPTO m

CONCEPTO l

CONCEPTO n

Fig. 33 Modelo del dominio básico especificado en la metodología de desarrollo y extensión realizada para

la implementación del marco de trabajo

El modelo del marco de trabajo define dos tipos de relaciones, estructurales y pedagógicas, que se ajustan a las categorías de requisito y conceptuales de Reigeluth. Las relaciones estructurales son aquellas que se usan habitualmente en una ontología de primer nivel y sirven para definir una colección estructurada de términos. Las pedagógicas son las que indican que el conocimiento que el alumno tiene de un concepto influirá de algún modo en el aprendizaje de los que se relacionen con él. Las relaciones definidas de cada tipo son:

Estructurales: el conocimiento ontológico se organiza en taxonomías principalmente a través de relaciones de generalización/especialización y de composición (Mizoguchi. R., 1998).

148


- A es un B o A subconcepto de B: el concepto A hereda las propiedades del concepto B. Establece una jerarquía entre los conceptos de una ontología y se usa para determinar los tipos de un determinado concepto del dominio (por ejemplo jilguero y gorrión respecto a pájaro).

- A parte de B: B es un concepto compuesto por otros entre los que está A. Representa la relación de composición relacionando las partes de un concepto.

Pedagógicas: estas relaciones establecen las dependencias, desde el punto de vista didáctico, entre los conceptos del dominio. Sostienen, junto con los atributos de los conceptos, el conocimiento pedagógico necesario para la instrucción incluido en el modelo del dominio.

- A prerrequisito de B: para aprender el concepto B es necesario conocer el concepto A.

- A pertenece a B: el concepto A está incluido dentro del tema B. Representa la jerarquía de temas-subtemas que la mayoría de los docentes establecen en los currículum.

Al crear un dominio, cada relación que se establezca entre dos conceptos tendrá asociado un peso (entre 0 y 1) que representa una medida de la influencia de esa relación en el nivel de conocimiento de los conceptos asociados.

6.1.2 Modelo del alumno

Compartir el conocimiento es fundamental si tenemos presente que el fin último de este marco de trabajo es permitir la integración de sistemas inteligentes. Parte del conocimiento de un entorno de aprendizaje reside en su modelo del alumno y por esta razón su estructura estará supeditada al objetivo de la integración. Haciendo referencia de nuevo a los capítulos 2 y 3, vemos que a lo largo de las últimas décadas se han estudiado y desarrollado modelos teóricos y métodos de diagnóstico basados en técnicas de Inteligencia Artificial que permiten una adaptación bastante precisa de la instrucción (Millán, 2000).

La metodología de desarrollo de MEDEA define el modelo del alumno como un modelo de superposición que, aunque menos preciso que otros, es más sencillo y favorece la integración con los recursos de instrucción. Partiendo de esta base, y con el fin de presentar un modelo capaz de contener información más exacta acerca de lo que el alumno sabe se ha desarrollado en este marco de trabajo un modelo de superposición basado en capas o niveles (multi-layered approach). Este enfoque ha sido usado en sistemas como ELM-ART (Weber and Brusilovsky, 2001), NetCoach (Weber et al., 2001), I-Help (Vassileva et al., 2003) o CIMEL-ITS (Wei F. et al., 2005). La idea subyacente es organizar el conocimiento que el sistema tenga acerca de “lo que sabe” el alumno según la fuente, esto es, según dónde o cómo se haya obtenido esa información (de las páginas visitadas, el propio alumno, tests o ejercicios, otros sistemas etc.). El modelo de conocimiento de este marco de trabajo está compuesto por cuatro capas

149

Capítulo 6

o niveles: comprobado, estimado, inferido por prerrequisitos e inferido por granularidad.

Tradicionalmente el modelado del alumno se ha centrado en intentar representar con exactitud aspectos cognitivos del alumno, principalmente el conocimiento, sin embargo en los últimos años se ha incrementado el interés por modelar de algún modo el estado mental del alumno (gustos, emociones, miedos, estados de ánimo, etc.), y estudiar el grado y tipo de influencia que estos factores puedan ejercer sobre el proceso de aprendizaje, estos modelos se conocen como modelos afectivos. Las sesiones de trabajo que se vienen realizando desde 1999 en el seno de la conferencia sobre modelado de usuario (User Modeling Conference) (Carberry and Rosis, 2005; Conati, 2003; Rosis, 1999; Rosis, 2001) y la red de excelencia HUMAINE (Human-Machine Interaction Network on Emotion) creada en 2004 (The HUMAINE Consortium., 2004), aglutinan diversos trabajos sobre este tema. El marco de trabajo de MEDEA se aproxima de forma muy somera a esta línea del modelado de usuario incluyendo un modelo descriptivo de aptitudes del alumno.

Entre los STI clásicos existen algunos que basan su instrucción en monitorizar exhaustivamente al alumno con el fin de determinar una oportunidad de intervención (por ejemplo los sistemas de simulación o algunos sistemas de resolución de problemas). Los WILE, debido a las limitaciones del medio (protocolos no orientados a la conexión, poco control sobre las acciones del usuario) no suelen basar sus estrategias de instrucción en el control del alumno, aunque algunas técnicas de adaptación de la instrucción usan las acciones del alumno en algunos de sus algoritmos (Brusilovsky, 1996). Con el propósito de servir de ayuda a la toma de decisiones por parte del planificador de instrucción, se ha decidido ampliar el modelo del alumno con un historial de acciones.

En los siguientes epígrafes se describen en detalle el contenido del modelo de conocimientos, el de aptitudes y el historial de acciones que se resumen en la Fig. 34.

Según la metodología de desarrollo existen dos operaciones que se pueden realizar sobre el modelo del alumno: Consultar modelo y Actualizar modelo. La actualización del modelo se corresponde con el procedimiento de diagnóstico y su implementación depende del marco de trabajo. Este epígrafe concluye con la descripción de los métodos para actualizar cada una de las partes del modelo.

6.1.2.1 Modelo de conocimiento

Como ya se ha adelantado el modelo de conocimiento de este marco de trabajo es un modelo de superposición en cuatro niveles. Representa un subconjunto del modelo del dominio en el que cada concepto lleva asociado un valor que indica el nivel de conocimiento del alumno acerca del mismo.

La interacción del alumno con el sistema se realiza principalmente a través de los recursos de instrucción (ejercicios, tareas, etc.) siendo ésta, por lo tanto, la principal fuente de información del modelo. Con el objetivo de mantener

150


separados los datos procedentes de distintas tareas educativas y favorecer de este modo una planificación más flexible se almacena el conocimiento en cuatro capas o niveles. Cada una de estas capas se actualizará de forma independiente:

1. Nivel de conocimiento comprobado: contiene los niveles de conocimiento obtenidos a través de los recursos de instrucción inteligentes de diagnóstico. La información que recogen estos recursos acerca del alumno ha sido obtenida por medio de métodos formales de diagnóstico.

2. Nivel de conocimiento estimado: recoge los niveles de conocimiento provenientes de los recursos de instrucción inteligentes estimativos. El objetivo de este nivel es almacenar el conocimiento “incierto” que se tiene acerca de lo que sabe el alumno, ya que los recursos de instrucción estimativos evalúan al alumno basándose en heurísticos y métodos no formales.

3. Nivel de conocimiento inferido por prerrequisitos: contiene el conocimiento inferido por una red bayesiana que modela la relación de prerrequisito entre conceptos.

4. Nivel de conocimiento inferido por granularidad: contiene el conocimiento inferido por una red bayesiana que modela la relación pertenece a.

En (Carmona et al., 2005) se presenta una descripción de las redes usadas en los niveles inferidos y una evaluación empírica realizada con estudiantes simulados.

MODELO DEL ALUMNO DEL MARCO DE TRABAJO MODELO DE CONOCIMIENTO

CONCEPTO i

CONCEPTO k

....

CONCEPTO m

....

prerrequisito parte_deNivel de conocimiento = 1

Nivel estimado

MODELO DE APTITUDES • Desarrollo cognitivo • Motivación • Estilo de aprendizaje • Progreso• Experiencia con el ordenador• Velocidad de conexión

HISTORIAL DE ACCIONES RI i (param1, param2, ...) RI k (param1, param2,...)

CONCEPTO i

CONCEPTO k ....

CONCEPTO m ....

Veces seleccionado por el alumnoVeces seleccionado por el planificadorVeces rechazado

CONCEPTO i

CONCEPTO k ....

CONCEPTO m ....

prerrequisito Nivel de conocimiento= 7

Nivel inferido por prerrequisitos

CONCEPTO i

CONCEPTO k

....

CONCEPTO m

....

prerrequisito parte_deNivel de conocimiento = 4

Nivel comprobado

CONCEPTO i

CONCEPTO k ....

CONCEPTO m ....

Nivel de conocimiento=2

Nivel inferido por granularidad

parte_de

Fig. 34 Modelo del alumno implementado en el marco de trabajo.

151

Capítulo 6

6.1.2.2 Modelo de aptitudes

El modelo de aptitudes representa el perfil del alumno y es una aproximación a los modelos afectivos. Sin embargo, el modelo aquí presentado es menos ambicioso ya que no incluye métodos de reconocimiento y/o interpretación del estado afectivo del alumno, integración de aspectos afectivos y no afectivos o la incidencia de los mismos en la actualización del modelo. Simplemente se trata de almacenar ciertos aspectos relativos al usuario que puedan ayudar al planificador en la toma de algunas decisiones y al profesor en la aplicación de distintos estilos de aprendizaje (epígrafe 7.1.5).

Existen algunas organizaciones internacionales de estándares que tratan de especificar qué información debe contener el perfil de alumno. Entre los mas representativos encontramos LIP (Learner Information Package) de IMS (IMS Global Learning Consortium, 2005) o PAPI (Public and Private Information Package Specification) de IEEE LTSC (IEEE LTSC , ) (ver 4.2). Ninguno de ellos trata la representación de aspectos pedagógicos tales como estilo de aprendizaje, motivación, etc., por lo que no son aplicables al desarrollo de entornos inteligentes de enseñanza.

La siguiente tabla muestra los parámetros que incluye el modelo, su descripción y los valores que puede tomar cada uno de ellos.

CARACTERÍSTICA DESCRIPCIÓN VALORES

Desarrollo cognitivo Habilidad para comprender conceptos abstractos o formalizaciones

Alto Medio Bajo

Motivación Disposición de ánimo con la que se enfrenta al desarrollo de la tarea de aprendizaje con interés y diligencia.

Alta Media Baja

Estilo de aprendizaje Forma preferida de afrontar el aprendizaje de un tema.

Teoría Práctica

Progreso Representa la velocidad de aprendizaje del alumno.

Bueno Regular Malo

Experiencia con el ordenador

Indica el grado de pericia del alumno en el manejo de un ordenador.

Mucha Poca Ninguna

Velocidad de conexión Ofrece una estimación sobre la velocidad de la conexión a Internet con la que el alumno va a interactuar con el sistema.

Alta Media Baja

Tabla 22 Parámetros que se incluyen en el modelo de aptitudes del alumno

6.1.2.3 Historial de acciones

La aplicación de algunas técnicas de adaptación y el carácter constructivo del aprendizaje a través de la web justifican la inclusión de un historial de acciones en el modelo del alumno que tome nota de la interacción del alumno con el

152


sistema. Principalmente estos datos son usados por el planificador para detectar alumno discrepa de sus consejos y tener en cuenta su opinión para futuras sugerencias. Por ejemplo, el sistema anotará cuantas veces ha usado un recurso de instrucción concreto para, en caso de duda, seleccionar aquél por el que el alumno parece mostrar cierta preferencia.

El historial de acciones almacena los siguientes datos:

una lista de todas las tareas realizadas por el alumno, o lo que es lo mismo de todos los recursos de instrucción ejecutados, incluyendo los valores de sus parámetros de ejecución.

para cada concepto del modelo de conocimiento:

- el número de veces que ha sido seleccionado por el alumno para ser estudiado,

- el número de veces que lo eligió el planificador y

- cuántas veces fue elegido por el planificador y rechazado por el alumno.

6.1.2.4 Actualización del modelo del alumno

Según la metodología de desarrollo existen dos operaciones básicas que se pueden realizar sobre el modelo del alumno: consultar modelo y actualizar modelo. El funcionamiento interno de estos servicios depende de la estructura del modelo y por tanto debe ser determinado durante la creación del marco de trabajo.

El método para la consulta del modelo del alumno debe permitir examinar cada uno de los datos incluidos en él. Este servicio incluye un conjunto de métodos para acceder a cada uno de los parámetros del modelo del alumno.

La operación de actualización del modelo debe ser capaz de acceder y modificar cada uno de los datos incluidos en el mismo.

Actualizar modelo de conocimientos

Las tareas que el alumno realiza durante la instrucción son la fuente de información necesaria para mantener actualizado el modelo de conocimiento. Según se definió en el apartado 5.3.2, existen dos tipos de RI capaces de proporcionar información acerca del alumno: de diagnóstico y estimativos. Los primeros emplean métodos formales de diagnóstico para obtener el nivel de conocimiento del alumno mientras que los segundos emplean heurísticos. Por tanto las capas comprobada y estimada del modelo de conocimientos se alimentan de los RI de diagnóstico y estimativos respectivamente. Cuando un alumno da por concluida la realización de su tarea, haya llegado o no hasta el final, se solicita al RI el nivel de conocimiento del concepto(s) implicado(s) en ese paso de la instrucción y se actualiza el nivel correspondiente.

Cada vez que se produce algún cambio en el nivel comprobado se ponen en marcha unos procesos de inferencia sobre las capas de prerrequisitos y granularidad (Carmona and Conejo, 2004; Carmona et al., 2005). Para llevar a

153

Capítulo 6

cabo estas inferencias se usan sendas redes bayesianas obtenidas a partir de las relaciones prerrequisito y pertenece a del modelo del dominio. Cada nodo de la red Ci puede tomar un valor xik de entre un número finito de posibles valores que representan los distintos niveles de conocimiento del alumno para el concepto i (por ejemplo bien, regular, mal). Para inicializar la red es necesario estimar las probabilidades condicionadas de cada nodo. Estos valores indican la probabilidad de que el alumno tenga un nivel de conocimiento determinado en un concepto dado el conocimiento que posee para otros conceptos de la red. El problema es que para el profesor esta magnitud es difícil de determinar por lo que, en vez de solicitárselas directamente, el sistema las calcula a partir de la dificultad de los conceptos y los pesos de las relaciones.

Aunque pueda parecer que este hecho establece un vínculo de dependencia del modelo del alumno respecto del dominio, el hecho de que ambos cumplan las especificaciones dadas por la metodología de desarrollo garantiza una funcionalidad mínima que permitirá al sistema seguir ejecutándose si el modelo del dominio fuese sustituido por otro. En nuestro ejemplo, si el modelo del dominio fuese reemplazado por otro que no contenga las relaciones de prerrequisito y parte de, o el atributo dificultad, los niveles inferidos estarían vacíos. En el peor caso, el modelo del alumno estaría formado tan sólo por una lista de conceptos y en consecuencia, la única parte operativa del modelo sería la comprendida por los niveles comprobado y estimados.

En el caso de la relación pertenece a el peso wij de una relación entre los conceptos Ci y Cj indica lo importante que Ci es para Cj. La suma de los pesos de todos los conceptos que pertenecen a uno dado debe ser 1. En el caso de un prerrequisito un peso menor que 1 representa un prerrequisito débil mientras que un peso 1 indica que es fuerte, es decir, es necesario que el alumno alcance el nivel mínimo exigido para el prerrequisito antes de aprender el concepto.

A continuación se detalla el proceso de inferencia para cada uno de los niveles afectados.

Actualizar nivel inferido por prerrequisitos: en el caso de la red de prerrequisitos la probabilidad de tener un nivel de conocimiento y para un concepto Ci, dado que el nivel de conocimiento de sus prerrequisitos Ci ... Ck es xi ... xk ,vendría dada por la expresión:

( )⎪⎪⎩

⎪⎪⎨

⎧

>−

≤−

+====

)x,...,xmin(yifNW

)x,...,xmin(yifNW

)x,...,xmin(W

xC,...,xCyCPk

kkkki

1

11

11 1

1

donde:

- W = max(w1i,...wki) es el máximo de las relaciones entre C1...Ck y Ci

- N es el número de todos los posibles valores que un concepto puede tener.

Esta fórmula se basa en la suposición de que la probabilidad de conocer un concepto antes que sus prerrequisitos es baja. Si un alumno tiene un nivel de

154


conocimiento x en un prerrequisto, la probabilidad de tener un nivel en el concepto menor que x será elevada y homogénea para todos los niveles, pero la probabilidad de saberlo con un nivel mayor que x será baja.

Actualizar nivel inferido por granularidad: en el caso de la red de granularidad la probabilidad de que el concepto Ci tenga un nivel de conocimiento y dado que el nivel de conocimiento de sus sub-conceptos Ci ... Ck, que pertenecen a Ci , es xi ... xk vendría dada por la expresión:

( )⎩⎨⎧ ++=

====casootroen

)xw...xw(redondeoyifxC,...,xCyCP kkii

kki 01 11

11

donde:

- w1i,...wki son los pesos de las relaciones pertenece a entre C1...Ck y Ci respectivamente.

- N es el número de todos los posibles valores que un concepto puede tener.

- redondeo(x) devuelve la parte entera de x. Esta función representa la idea de que el conocimiento que un alumno tenga de un concepto dependerá del conocimiento ponderado que tenga de los conceptos que le pertenecen.

Actualizar modelo de aptitudes

Existe un conjunto de métodos para actualizar cada uno de los parámetros incluidos en el modelo de aptitudes. Esta parte del modelo es modificada directamente por el usuario a través del entorno.

Actualizar historial de acciones

Cada vez que se ejecuta un recurso de instrucción todos los datos referentes al inicio de la ejecución se almacenan en el historial de acciones. Además se modifican los parámetros referentes a las veces que el alumno ha tenido en cuenta los consejos del planificador.

6.1.3 Planificador de instrucción

La metodología de desarrollo de MEDEA establece que la función principal del planificador de instrucción es determinar en cada paso de la instrucción, el concepto del dominio más adecuado para ser aprendido por un alumno y la tarea que debería realizar para maximizar el aprendizaje de dicho concepto. La presentación del material asociado a una determinada tarea, así como el control, monitorización y, dado el caso, evaluación de la misma se delega en los recursos de instrucción. Es decir, el planificador ofrece técnicas de secuenciación del currículo mientras que la implementación de tareas pedagógicas determinadas (exámenes, enseñanza basada en ejemplos, razonamiento basado en diálogos,...), es responsabilidad de los recursos de instrucción. Según esto el planificador es el encargado de llevar a cabo la fase de microadaptación mientras

155

Capítulo 6

que la macroadaptación se delega en los recursos de instrucción (Shute and Towle, 2003).

En el proceso de construcción del marco de trabajo es necesario concretar las técnicas de secuenciación del currículo. Las técnicas de adaptación de los WILE pueden ser consideradas como una generalización de las técnicas de secuenciación de currículos en los STI tradicionales (Brusilovsky, 2000).

Según el análisis de los STI realizado en el Capítulo 2, no existe un consenso respecto a los métodos de planificación mas adecuados. Aunque existen trabajos que tratan de determinar procedimientos de planificación universales (Matsuda and VanLehn, 2000; Murray, 1989; Peachey and McCalla, 1986), en la práctica nos encontramos con un conjunto heterogéneo de técnicas fuertemente ligadas al dominio de la aplicación y a teorías pedagógicas muy concretas (ver 2.2.3.1). La mayoría de ellas están basadas en reglas y heurísticos extraídos de la experiencia de profesores y educadores (por ejemplo WEST, WUSOR, REEDEM y otros). Sin embargo, existe un amplio consenso por parte de educadores y pedagogos acerca de la validez de un conjunto de principios de carácter general que se aplican en la mayoría de sistemas revisados para el desarrollo de esta tesis:

La relación de prerrequisitos es la más usada por los profesores a la hora de establecer la secuencia de un currículo. Esta relación indica que un concepto no debería ser estudiado antes que sus prerrequisitos.

Es frecuente definir conceptos dentro de un dominio por el conjunto de partes que lo forman. Cuando el dominio ha sido modelado con propósitos educativos, se debe tener en cuenta que el conocimiento que el alumno tenga sobre las partes influye en el conocimiento del concepto global.

Intervenir en exceso en el proceso de aprendizaje para evaluar al alumno puede provocar desánimo y aburrimiento (Barr and Feigenbaum E.A., 1982d). En esta implementación de MEDEA se ha optado por evaluar al alumno sólo cuando exista una diferencia importante entre el nivel de conocimiento del nivel estimado y del nivel comprobado. La evaluación correrá a cargo de los recursos de instrucción inteligentes de diagnóstico.

Existen dos estrategias opuestas aplicables a la hora de establecer una secuencia de instrucción: insistir sobre un concepto hasta que el alumno lo aprenda o seleccionar conceptos que no hayan sido estudiados recientemente. La primera puede llegar a bloquear el proceso de aprendizaje y provocar el abandono del alumno. La segunda evita el aburrimiento pero puede generar desorientación al dispersar en exceso el foco de instrucción. En el planificador de esta instancia de MEDEA se intenta llegar a un consenso entre ambas estrategias aplicando los siguientes criterios: a) el ámbito del foco de instrucción debe circunscribirse al tema que esté estudiando el alumno (entiéndase tema como el conjunto de conceptos unidos por la relación pertenece a); b) se debe insistir en un concepto sólo si el alumno está a punto de alcanzar el mínimo exigido para superar el concepto

156


y c) se debe tener en cuenta el interés que el alumno haya demostrado sobre un determinado concepto.

El algoritmo de planificación propuesto para la secuenciación del currículo ha sido diseñado bajo la premisa de este conjunto de principios. Para realizar su tarea, el planificador usará la información disponible en el modelo del dominio y del alumno. Se establecen por tanto unas dependencias inevitables entre estos recursos. En el caso de ser sustituidos estos modelos por otros, que carecieran de los datos usados por el algoritmo de planificación para determinar la secuencia de instrucción, éste debería ser adaptado a los nuevos modelos. Si por el contrario, los modelos del dominio y del alumno se extienden el planificador podría seguir funcionando ignorando la nueva información. Este es el caso de la relación estructural es un, para la que el planificador no establece ninguna semántica pero cuya existencia no impide que el resto del sistema funcione coherentemente.

A lo largo del desarrollo de esta tesis se ha sopesado la posibilidad de que en un futuro el marco de trabajo disponga de múltiples planificadores de instrucción y que, de forma análoga a lo que ocurre con los recursos de instrucción, el profesor pueda seleccionar aquél que mas se ajuste a sus prioridades.

Antes de presentar el algoritmo de planificación, es necesario describir la semántica formal de las relaciones del dominio que se usarán para la secuenciación de la instrucción así como algunos predicados, funciones y parámetros empleados en su definición.

Predicados

- Prerrequisito(a,b): predicado que indica que existe una relación prerrequisito entre el concepto a (origen) y el concepto b (destino) en el modelo del dominio.

- Parte(a,b): predicado que indica que existe una relación parte de entre el concepto a (origen) y el concepto b (destino) en el modelo del dominio.

- Pertence(a,b): predicado que indica que existe una relación pertence a entre el concepto a (origen) y el concepto b (destino) en el modelo del dominio.

Funciones

- nota(a,c): función que devuelve el nivel de conocimiento del alumno sobre el concepto a en la capa c del modelo del alumno.

- peso(a,b): función que devuelve el peso de la relación establecida en el modelo del dominio entre los conceptos a y b.

- umbral(a): nota mínima para considerar superado el concepto a. Parámetros

- límite: representa el margen permitido por el profesor, entre las estimaciones y las comprobaciones del nivel de conocimiento del alumno, para proceder a realizar un proceso de evaluación.

157

Capítulo 6

Semántica de las relaciones prerrequisito y parte de

- Prerrequisito: para poder estudiar un concepto un alumno debe conocer todos sus prerrequisitos. El profesor puede relajar esta condición estableciendo un peso, entre 0 y 1, para cada relación de prerrequisito. Un peso de 0 equivaldría a la anulación del prerrequisito mientras que un peso de 1 lo convertiría en un prerrequisito indispensable. La función pre(x) devuelve 1 si el alumno ha superado todos sus prerrequisitos (según los pesos establecidos por el profesor) y 0 en caso contrario.

( )[ ]⎩⎨⎧ ⋅>⇒∀

=casootroen

)y(umbral)y,x(peso)c,y(nota)x,y(ePr/ysi)x(pre

01

- Parte de: cuando un concepto representa un todo formado por varias partes (por ejemplo los conceptos tablero, patas y cajón son partes del concepto mesa) el alumno estará más preparado para aprenderlo cuanto más conozca acerca de las partes que lo integran. Para representar esta circunstancia, la función part(x) devuelve 0 si el alumno no supera el conocimiento necesario acerca de las partes que componen el concepto x (según los pesos establecidos por el profesor de forma análoga a la explicada para la relación de prerrequisitos), 1 si lo supera para todas ellas y un número entre 0 y 1 si este conocimiento es superado sólo en algunos casos.

Sean los conjuntos: { }{ })y(umbral)y,x(peso)c,y(nota)x,y(Parte/y)x(P

)x,y(Parte/y)x(P

n ⋅<∧==

definimos part(x) como:

( )

( )⎪⎪⎪⎪

⎩

⎪⎪⎪⎪

⎨

⎧

−⋅

>⎟⎟⎠

⎞⎜⎜⎝

⎛−⋅

∅=

=

∑

∑

)x(P

)x(P

n

casootroen)c,y(nota)y(umbral)y,x(peso

c,y(nota)y(umbral)y,x(pesosi

)x(Psi

)x(part

1

00

1

6.1.3.1 Algoritmo de planificación

El algoritmo de planificación debe decidir qué va a estudiar el alumno (foco de instrucción) y con qué recurso de instrucción (microadaptación). A partir de ahí será el propio recurso el que decida los contenidos que le va a presentar y cómo (macroadaptación).

Los resultados de las tareas que el alumno realiza durante las instrucción son la fuente de información que mantiene actualizado el modelo de conocimiento. El planificador se basa principalmente en dicho modelo para tomar sus decisiones.

158


Según se definió en el apartado 5.3.2, existen dos tipos de RI capaces de proporcionar información acerca del alumno: de diagnóstico y estimativos. Los RI de diagnóstico suelen evaluar al alumno mediante algún tipo de prueba (test, examen, ejercicio,...) y, aplicando métodos formales de diagnóstico, calculan su nivel de conocimiento. Esta información será usada para actualizar la capa comprobada del modelo de conocimientos. Los RI estimativos actualizan el modelo estimado con datos obtenidos a partir de heurísticos. Por tanto la información contenida en la capa comprobada puede considerarse más fiable que la estimada, es decir, se aproxima más al valor real del conocimiento del alumno. Sin embargo, y según los principios pedagógicos expuestos al principio, muchos profesores consideran que no es bueno realizar frecuentes evaluaciones del alumno, a pesar de que sean necesarias si se quiere conocer de forma precisa el nivel del alumno.

Por otro lado, aunque se ha dicho que la primera tarea del planificador es seleccionar el foco de instrucción, éste depende de si el alumno va a ser evaluado o no. En efecto, un profesor tendría en cuenta distintos parámetros a la hora de seleccionar un tema según fuese para enseñar o para examinar. Por tanto, el planificador, antes de seleccionar el foco de instrucción, debe decidir si procede o no realizar algún proceso de evaluación (Fig. 35). Esta resolución se basa en la diferencia entre el modelo estimado y el comprobado. Se evaluará al alumno cuando la diferencia entre lo que el planificador cree que el alumno sabe (modelo estimado) y lo que está seguro que el alumno sabe (modelo comprobado), sea significativa. Para ello calcula la media de las diferencias de las notas de cada concepto en las capas estimada y comprobada del modelo del alumno. Si este valor es mayor que un cierto límite establecido por el profesor el planificador determina que el alumno debe ser evaluado (Fig. 36).

Una vez tomada esta decisión, pasará a determinar el foco de instrucción y la tarea concreta que debe realizar. Estas dos acciones se corresponden con las funciones concepto_objetivo y RI_objetivo que se describen en detalle en las Fig. 37 y Fig. 38. Si se ha decidido que el alumno se evalúe se seleccionará un RI de diagnóstico, en otro caso, uno estimativo o no inteligente.

ALGORITMO planificación necesita_evaluación = necesita_evaluación?( ) concepto = concepto_objetivo (necesita_evaluación) RI = RI_objetivo (concepto, necesita_evaluación)

Fig. 35 Algoritmo de planificación

FUNCIÓN necesita_evaluación( ) /* c representa cada concepto perteneciente al dominio */ diferencia = Ε (nota(c,estimado)-nota(c,comprobado)) SI (diferencia > limite) DEVUELVE cierto SI NO DEVUELVE falso

Fig. 36 Función necesita evaluación()

Si el alumno debe ser evaluado, la siguiente decisión que debe tomar el planificador es cuál es el concepto sobre el que el alumno debería examinarse (Fig. 37, línea 1). Para ello se seleccionan conceptos que figuran como

159

Capítulo 6

aprendidos en el modelo estimado y no aprendidos en el comprobado (un concepto se considera aprendido si su nivel de conocimiento es superior a la nota mínima establecida por el profesor). De todos ellos se eligen los que pertenezcan al último concepto estudiado, con el fin de mantener, siempre que sea posible, el foco de instrucción dentro del tema sobre el que el alumno está trabajando. Por último se elige aquel concepto del tema en cuestión para el que la diferencia entre la nota estimada y la comprobada sea la más elevada. Si existen varios que presentan la misma diferencia se elige uno cualquiera de ellos.

Si por el contrario, el sistema decide que el alumno debe seguir aprendiendo (Fig. 37, línea 10) el planificador usará tan sólo la información del nivel estimado para la selección de un nuevo concepto. Primero se selecciona el conjunto de conceptos del dominio que están listos para ser estudiados. Estos conceptos se han llamado candidatos. Un concepto candidato es todo aquel que cumple las siguientes condiciones (Fig. 37, línea 14):

el concepto nunca ha sido estudiado,

el concepto ha sido estudiado pero el alumno no ha obtenido el mínimo nivel de conocimiento requerido,

- el alumno ha superado todos los prerrequisitos del concepto y

- si existe alguna relación parte de con otros conceptos del dominio, estos han sido superados al menos en un alto porcentaje (part(concepto) >0).

A todos los conceptos candidatos se les aplica una función de valoración que ordena los conceptos candidatos de modo que la elección se ajuste en la mayor medida posible a los principios pedagógicos en los que se basa este planificador (Fig. 37, línea 21). La función “premia” a aquellos conceptos que:

pertenecen al tema que el alumno está estudiando y

cuyo nivel de conocimiento (estimado) está próximo a alcanzar el mínimo exigido,

por el contrario, se penaliza a aquellos que:

han sido seleccionados en anteriores ocasiones y

han sido rechazados alguna vez por el alumno cuando fue recomendado por el sistema.

El concepto elegido por el planificador será aquel candidato que obtenga una mayor puntuación. Si existen varios con la misma puntuación se elige uno cualquiera de ellos.

Por último, el planificador seleccionará el recurso de instrucción más adecuado para estudiar el concepto elegido (Fig. 38). Si el sistema ha decidido evaluar al alumno el recurso seleccionado será inteligente de diagnóstico. En otro caso el recurso será inteligentes estimativo o no inteligente. Para realizar esta selección el planificador utiliza las descripciones funcionales de los recursos de instrucción, el modelo de aptitudes y las estrategias de enseñanza definidas por el

160


profesor, tal y como se especifica en la capa 2 de la metodología (5.4.2). El profesor puede establecer a la hora de crear un WILE qué tareas son mas adecuadas que otras para un determinado tipo de alumno. Para ello hará corresponder un tipo de RI con un tipo de alumno a través de las características que definen a cada uno de ellos (la descripción funcional y el modelo de aptitudes respectivamente). El planificador comparará el modelo de aptitudes con los perfiles establecidos por el profesor, teniendo en cuenta que cada perfil ha sido asociado a un RI, y elegirá aquel que presente un número mayor de coincidencias. Si no existe ninguno adecuado se elige uno cualquiera.

FUNCIÓN concepto_objetivo (necesita_evaluación)1. SI (necesita_evaluación)

maximo = 0; i = 0 MIENTRAS (modelo_dominio ≠ ∅) diferencia = nota(c i ,estimado)-nota(ci,comprobado)

SI [ Pertenece(c i , ultimo_concepto_estudiado) ∧ nota(ci, estimado) > umbral(c i ) ∧ nota(ci, comprobado) < umbral(ci)) ∧ diferencia > máximo ] i++

máximo = diferencia concepto_objetivo = ci SI NO /* el alumno no necesita_evaluación*/

i = 0 MIENTRAS ( modelo_dominio ≠ ∅)

SI [(c i ∉ modelo_alumno_estimado ∨ nota(ci,estimado) < umbral(ci)) ∧ pre(c i ) ∧ part(c i )>0]

c i ⊂ conjunto_conceptos_candidatos mayor = 0

MIENTRAS (conjunto_conceptos_candidatos ≠ ∅) rechazado = número_veces_sugerido_y_rechazado(ci) elegido = número_veces_elegido(ci) conocimiento = umbral(c i ) -nota(ci, estimado) p = Pertenece(c i ,ultimo_concepto_estudiado)

SI (función_valoración > mayor) mayor = función_valoración

concepto_objetivo = c i

5.

10.

15.

20. p + + part (ci) funcion_valoración=

1 conocimiento

num_veces_rechazado + num_veces_elegido

Fig. 37 Función que selecciona el concepto más adecuado para el siguiente paso de la instrucción

FUNCIÓN RI_candidato(concepto, necesita_evaluación) SI (necesita_evaluación) conjunto_RI = RI_inteligentes_diagnóstico SI NO conjunto_RI = RI_inteligentes_estimativos + RI_no_ inteligentes mayor = 0 MIENTRAS (conjunto_RI ≠ ∅) coincidencias=comparar(modelo_aptitudes_alumno, perfiles(RI) ) SI (coincidencias > mayor) mayor = coincidencias candidato = RI

Fig. 38 Función que selecciona el recurso de instrucción más adecuado para el siguiente paso de la instrucción

161

Capítulo 6

6.1.4 Interfaz

Es el componente a través del cual el alumno interactúa con el sistema. Tal y como especifica la metodología, la interfaz debe permitir al alumno seleccionar y ejecutar un recurso de instrucción, solicitar un plan de instrucción y consultar y modificar el modelo del alumno. Al tratarse de entornos para la web, la interfaz vendrá dada por un navegador y un conjunto de páginas con enlaces, formularios y botones de control.

En este caso el entorno de aprendizaje está formado por dos marcos principales. En uno de ellos el alumno ejecuta las tareas de enseñanza y en el otro se muestra el dominio, información acerca de su nivel de conocimiento y botones para acceder a las tareas y al planificador. En el Capítulo 7 se ofrecen más detalles acerca de este elemento.

6.2 Capa 1. Integración de recursos de instrucción

Este capítulo describe un marco de trabajo que da soporte a la metodología de desarrollo definida en el capítulo anterior y cuyo objetivo principal es permitir la construcción de entornos de aprendizaje inteligente mediante la integración de sistemas educativos externos. Estos “sistemas externos” son los recursos de instrucción, definidos en la capa 1 de la metodología (5.3), y se integrarán en la arquitectura para, junto con los elementos del núcleo, proporcionar una instrucción personalizada al alumno.

Para que los RI y los elementos del núcleo puedan comunicarse y compartir conocimiento es necesario 1) que ambos se ajusten a las especificaciones de MEDEA y 2) que el marco de trabajo proporcione una capa de software que permita gestionar físicamente la comunicaciones entre ambos. MEDEA establece que un técnico especializado implemente cada RI de acuerdo a los prerrequisitos establecidos por la propia metodología. Para ello, cada RI deberá proporcionar un conjunto de servicios (Inicio de la ejecución, Fin de la ejecución, Nuevo usuario, Exportar modelos del alumno y Exportar modelo del dominio) a través de los cuales se comunicará con el resto del sistema. Será responsabilidad del técnico integrar cada RI dentro del marco de trabajo.

En este epígrafe se describe en primer lugar la tecnología empleada para gestionar las comunicaciones en este marco de trabajo. A continuación se ilustra el proceso de construcción e integración de un recurso de instrucción mediante la inclusión de los sistemas SIGUE (Carmona et al., 2002), SIETTE (Conejo et al., 2004) y WADIn II (Loboda and Brusilovsky, 2005-2006) como RI del marco de trabajo.

6.2.1 Gestión de comunicaciones

El marco de trabajo es el encargado de gestionar las comunicaciones entre los distintos recursos de instrucción y los elementos del núcleo. Una de las primeras decisiones de implementación es determinar la tecnología empleada como soporte de las comunicaciones. Entre los objetivos marcados al principio

162


de esta tesis se señala el carácter distribuido y abierto (extensible) del marco de trabajo. Según se discutió en el Capítulo 4, existen dos tendencias en el desarrollo de sistemas educativos inteligentes y distribuidos: los sistemas multi-agente y las aplicaciones basadas en componentes.

El principal escollo en la aplicación de la tecnología multi-agente al desarrollo de WILE es la dificultad en la construcción de sistemas abiertos que permitan integrar y eliminar agentes de distinta naturaleza en tiempo de ejecución. Los ejemplos que nos ofrece la literatura son, en la mayoría de casos, arquitecturas cerradas con un número determinado de agentes. A esto hay que añadir la necesidad de emplear ontologías y lenguajes estándares para establecer una comunicación a alto nivel. El hecho de estar tratando con un problema específico (los sistemas educativos) nos permite alejarnos de las herramientas genéricas de los SMA (FIPA-OS, JADE,...) y definir un marco de trabajo propio que se ajuste a las necesidades concretas de los WILE.

A partir de los 90, comienzan a aparecer tecnologías que permiten el desarrollo de aplicaciones distribuidas. Para este marco de trabajo se ha optado por los servicios web, una tecnología estándar, ampliamente extendida y de libre distribución. Un servicio web es un componente software accesible a través de protocolos estándar de Internet como HTTP, FTP, SMTP, etc., que basa su comunicación con otras aplicaciones en protocolos XML frente a los protocolos binarios propietarios de otras tecnologías como CORBA, DCOM o RMI.

Para el desarrollo del gestor de comunicaciones se ha empleado WSIF (Web Services Invocation Framework), un API de Java para la invocación de servicios web a través de su descripción WSDL (Duftler et al., 2001; The Apache Software Foundation, 2003). WSIF permite desarrollar clientes de servicios web sin tener en cuenta cómo han sido implementados y cómo se acceden. WSIF da la posibilidad a los programadores de interactuar con la representación abstracta de los servicios web a través de su descripción WSDL en vez de trabajar directamente con el API de SOAP (Simple Object Access Protocol). De este modo las invocaciones a los servicios son completamente dinámicas y no necesitan de la instalación de ningún código en el cliente para la invocación remota (stubs, skeletons), las llamadas se construyen en tiempo de ejecución y se basan en los meta-datos que describen los servicios. Asimismo, el API WSIF es independiente del protocolo XML empleado, permitiendo integrar implementaciones de distintos protocolos XML-RPC. La elección de uno u otro se puede posponer hasta el momento de la ejecución. Para este desarrollo se ha usado AXIS 1.1., una implementación distribuida por Apache de la especificación de SOAP emitida por la W3C para el desarrollo de servicios web en Java (Axis Development Team, 2002). AXIS incluye la infraestructura para desplegar implementaciones de servicios web en un servidor y encaminar los mensajes entre los clientes y dichas implementaciones.

163

Capítulo 6

6.2.2 Creación de los RI: implementación de servicios

Para que un sistema educativo pueda integrarse como recurso de instrucción de un marco de trabajo basado en la metodología MEDEA debe contar con una API (Application Programming Interface) que pueda ser invocada por los elementos del núcleo y la interfaz del WILE durante la instrucción. La interfaz de un RI está formada por los servicios especificados en la metodología (5.3.4). En la siguiente tabla se detallan los parámetros de entrada, de salida y la tarea asignada a cada servicio:

SERVICIO TAREA PARÁMETROS DE ENTRADA

PARÁMETROS DE SALIDA

Inicio de la ejecución Ejecuta una sesión con el RI

alumno concepto [parámetros propios de la aplicación]

Fin de la ejecución Concluye la ejecución de la actividad a petición del usuario o del WILE.

alumno lista de pares concepto/valor correspondiente al modelo de conocimientos del alumno

Nuevo usuario Crea un nuevo modelo de usuario en el RI y lo asocia al perfil de usuario del WILE.

alumno clave

alumno clave

Exportar modelo del alumno

Pide al RI el modelo de un alumno.

alumno lista de pares concepto/valor correspondiente al modelo de conocimientos del alumno

Exportar modelo del dominio

Pide la lista de conceptos que forman parte de un dominio.

dominio lista de nombres de conceptos

Tabla 23 API de un recurso de instrucción

La implementación de la API vendrá dada por un conjunto de servicios web. El uso de esta tecnología nos permite: 1) que se pueda usar cualquier lenguaje de programación para su desarrollo y 2) que la descripción para la especificación de la misma pueda ser descrita en el estándar WSDL (Web Service Description Language). Tal y como se explica en el apartado 4.1.1, un documento WSDL describe la sintaxis de la invocación a un servicio especificando qué hace, cómo se puede acceder a él y dónde se localiza.

Las llamadas a los servicios han sido implementadas, como se indica en el apartado anterior, usando el API WSIF (Web Services Invocation Framework). Esto nos garantiza la extensibilidad del marco de trabajo y la inserción y eliminación dinámica de recursos. En efecto, para insertar un recurso en el sistema bastará con proporcionar su descripción WSDL y éste podrá ser invocado sin necesidad de recompilar el núcleo ni ningún otro módulo del marco de trabajo.

164


6.2.3 Integración de los RI: descripción funcional

Para que un recurso de instrucción pueda ser usado por un alumno en una sesión de instrucción es necesario: 1) que el recurso haya sido integrado en el marco de trabajo y 2) que haya sido seleccionado para formar parte del WILE y su dominio puesto en correspondencia con un dominio del marco de trabajo. Estas dos tareas se corresponden respectivamente con las capas 1 y 2 de la metodología de desarrollo.

La información necesaria para la localización y ejecución de un RI se almacena en el registro de recursos de instrucción. Estos datos se reparten entre la descripción funcional (aquellos necesarios para determinar el formato exacto de la llamada) y la descripción semántica (información referente al significado de los datos intercambiados). El integrador es la persona encargada de proporcionar la descripción funcional y algunos datos de la descripción semántica, mientras que será el profesor el que deberá determinar la mayor parte de la descripción semántica cuando decida incluir el RI como componente de su WILE.

Como se adelantó en el apartado anterior, el uso de los servicios web para la construcción del API de un RI, sumado al empleo de WSIF para la invocación de los mismos, permite que la integración de recursos de instrucción se reduzca prácticamente a la definición de un fichero WSDL que especificará cómo acceder al servicio. Este modo de proceder permite que:

No sea necesario recompilar el marco de trabajo para integrar un recurso.

Un recurso esté disponible para la construcción de WILE (capa 2) desde el mismo momento en el que se proporciona su descripción funcional.

Los elementos del núcleo (modelo del dominio, del alumno y planificador de instrucción) no se vean afectados por la inserción y/o eliminación de nuevos RI.

MEDEA especifica que la descripción funcional de un recurso de instrucción debe incluir todos los detalles necesarios para su invocación: nombre, ubicación y parámetros de ejecución. Un servicio web se describe en WSDL mediante su definición abstracta, su definición concreta y su localización (4.1.1, Fig. 18). En la definición abstracta se indica su nombre y tipo de cada uno de sus parámetros de entrada y de salida y en la concreta los formatos y tipos de datos que se utilizarán en la invocación de los mismos.

En la capa 1 de la metodología se especifica que, además de la información relativa a la ejecución de los servicios, es necesario describir la escala de valores que usa el RI para medir el conocimiento del alumno (estos datos forman parte de la descripción semántica) (ver 5.3.1). Esta información se corresponde con el tipo del parámetro de salida del servicio Fin de la ejecución. WSDL permite la definición de tipos de datos en XML Schema, lo que introduce cierta flexibilidad a la hora de determinar, por ejemplo, el rango de valores de un parámetro o incluso sus valores por defecto. De este modo podría definirse en un fichero WSDL un tipo XML Schema que indique que el método Fin de la ejecución

165

Capítulo 6

devuelve, por ejemplo, una lista de valores que deben estar en el rango [0,10] o un valor de un tipo enumerado [Bien, Mal, Regular].

En la Fig. 39 se muestra el esquema de la definición abstracta de un hipotético servicio servicio_1 de un recurso de instrucción de nombre RI_X. Cada elemento part representa un parámetro con su nombre (name) y su tipo (type). Los parámetros de entrada se agrupan en el elemento message de nombre servicio_1_Request y los de salida en el de nombre servicio_1_Response. El elemento operation se usa para indicar qué listas de parámetros de entrada y de salida pertenecen al servicio. Si el message al que se hace referencia tiene más de un parámetro se puede definir el orden que cada uno debe ocupar en la llamada al servicio con el atributo parameterOrder.

<message name="servicio_1_Request"> <part name="..." type="..."/> [...] <part name="..." type="..."/> </message> <message name="servicio_1_Response"> <part name="..." type="..."/> [...] <part name="..." type="..."/> </message> [...] <portType name="RI_X"> <operation name="servicio_1" parameterOrder = ”... ... ...”> <input message="servicio_1_Request" name="servicio_1_Request"/> <output message="servicio_1_Response" name="servicio_1_Response"/> </operation> [...] </portType>

Fig. 39 Fragmento WSDL de la descripción funcional de un servicio correspondiente a su definición abstracta

La definición concreta indica los formatos de datos y protocolos que se usarán en la invocación de los servicios previamente definidos. Los protocolos contemplados en la implementación de MEDEA son HTTP y SOAP. En las Fig. 40 y Fig. 41 se muestra la sintaxis de definición concreta para un servicio servicio_1 en cada uno de los casos.

<binding name="Servicio_1_Binding" type=”Servicio_1_PortType”>

< soap :binding style=" rpc " transport="http://schemas.xmlsoap.o rg/soap/http"/> <operation name=" servicio_1 "> <input> <soap:body use="literal" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://www.lcc.uma.es/”>

</input> <output> <soap:body use="literal" encodingStyle="ht tp://schemas.xmlsoap.org/soap/encoding/" namespace="http://www.lcc.uma.es/”>

</output> </operation> </binding>

Fig. 40 Fragmento WSDL de la descripción concreta de un servicio correspondiente a su definición concreta siendo el protocolo usado SOAP

166


<binding name="Servicio_1_Binding" type=”Servicio_1_PortType”> <http:binding verb="POST"/> <operation name="servicio_1"> <http:operation location="...."/> <input> <http:urlEncoded/> </input> <output> <mime:content type="text/html"/> </output> </operation> </binding>

Fig. 41 Fragmento WSDL de la descripción concreta de un servicio correspondiente a su definición concreta siendo el protocolo usado HTTP

La información relativa a la localización del servicio se expresa como atributo del elemento address con los prefijos http o soap según se muestra en las Fig. 42 y Fig. 43.

<service name="servicio_1"> <port name="servicio1_Port" binding="servicio_1_Binding"> <soap:address location="http://www.lcc.uma.es/axis/services/ejemplo"/> </port> </service>

Fig. 42 Fragmento WSDL de la descripción concreta de un servicio correspondiente a su localización siendo el protocolo usado SOAP

<service name="servicio_1"> <port name="servicio1_Port" binding="servicio_1_Binding"> <http:address location="http://www.lcc.uma.es/"/> </port> </service>

Fig. 43 Fragmento WSDL de la descripción concreta de un servicio correspondiente a su localización siendo el protocolo usado HTTP

Por último es importante reseñar que la función Inicio de la ejecución, que solicita al RI que instruya al alumno acerca de un tema concreto (este tema es el foco de instrucción, es decir, el concepto seleccionado bien por el alumno, bien por el planificador de instrucción durante la fase de microadaptación.), además de los parámetros alumno y concepto, probablemente necesitará otros parámetros propios de la aplicación. Algunos de ellos estarán directamente relacionados con la tarea educativa que desarrolle, por ejemplo si se trata de test a lo mejor se necesitan algunos datos de entrada como el número máximo de preguntas, si se muestran o no las soluciones, etc.

El integrador del recurso deben proporcionar unos valores por defecto para aquellos parámetros que la aplicación (RI) demande como obligatorios (se fijaran en el fichero WSDL). Podría ocurrir que para una misma herramienta se proporcionen distintas descripciones funcionales que difieran en los valores asignados a estos parámetros. Esto significaría que el mismo sistema externo se ha integrado más de una vez y que, por lo tanto, podemos disponer de varios RI asociados a la misma aplicación.

167

Capítulo 6

Esta circunstancia se ilustra en el proceso de integración del recurso SIETTE. SIETTE posee un parámetro de ejecución (viewcorrection) que indica si se permitirá al alumno ver o no las soluciones de los tests una vez realizado. Se han proporcionado dos descripciones funcionales para el sistema, en una de ellas se fija este parámetro a 1 (se verán las soluciones) y en otra a 0 (no se pueden ver). De este modo el marco de trabajo dispone de dos tareas educativas (RI) distintas, que han sido definidas respectivamente como Test de auto-aprendizaje y Test de evaluación y que están asociadas con la misma aplicación (SIETTE). Estos dos RI estará disponibles, de forma independiente, para el profesor que esté construyendo un entorno de aprendizaje.

El profesor puede, al definir un WILE, modificar estos valores y asociarlos o no a un perfil. Si el nuevo valor no se asocia a ningún perfil se aplicará a todos los alumnos que usen el WILE, en caso contrario, sólo a aquellos que se ajusten al perfil (al resto se les aplicará el valor por defecto). Por ejemplo, el integrador ha podido decidir que el valor por defecto para el parámetro modoOp de SIGUE (que se explica en el siguiente epígrafe) es 4 (no hay restricciones en la navegación), y el profesor, al definir el WILE podrá determinar, por ejemplo, que para los alumnos con un desarrollo cognitivo bajo y con poca experiencia con el ordenador este parámetro tomará el valor 2 (no se permiten accesos a enlaces externos al curso). En cualquier caso, esta tarea se circunscribe a la capa 2 de la metodología de desarrollo y será abordada en el próximo capítulo.

Resumiendo todo lo expuesto en este apartado, para integrar un sistema como RI del marco de trabajo es necesario escribir un fichero WSDL que incluya:

La descripción funcional del recurso. Para cada servicio del API es necesario conocer:

- nombre, teniendo en cuenta que los nombres proporcionados por la metodología son nombres genéricos, por ejemplo, el servicio inicio de ejecución, podría llamarse execute para un RI, inicioSesion para otro, etc.

- parámetros de ejecución, es necesario indicar el nombre y tipo de cada parámetro de entrada y salida.

- ubicación, es necesario proporcionar la URL de cada servicio. La parte de la descripción semántica correspondiente a los tipos de evaluación

del alumno, es decir, las escalas numéricas o los tipos enumerados que cada RI utiliza para establecer el nivel de conocimiento de un alumno.

Para aclarar el proceso de integración que acabamos de describir, en el siguiente apartado se detalla la integración en el marco de trabajo de los sistemas SIGUE (muestra páginas con contenidos adaptándolas al usuario) y SIETTE (realiza test adaptativos) y WADEIn II (permite evaluar expresiones de C paso a paso).

168


6.2.4 Algunos recursos de instrucción

La mayoría de sistemas educativos para la web analizados para esta tesis poseen como recursos educativos al menos un libro electrónico y alguna herramienta de evaluación. Para cubrir la funcionalidad básica de un WILE se ha considerado integrar en el marco de trabajo los sistemas SIGUE (Carmona et al., 2002) y SIETTE (Conejo et al., 2004), desarrollados en el seno del grupo de investigación IA2 (Departamento de Lenguajes y Ciencias de la computación (Universidad de Málaga), 2006). Además de SIGUE y SIETTE, se ha integrado el sistema WADEIn II (Loboda and Brusilovsky, 2005-2006) desarrollado e integrado desde el laboratorio PASW (Personalized Adaptive Web Systems) en la Universidad de Pittsburgh.

SIGUE es una herramienta de autor para el desarrollo y distribución de cursos usando páginas web ya creadas. SIGUE proporciona una interfaz para el alumno y almacena en su modelo las páginas visitadas. Este sistema no evalúa formalmente a los alumnos sino que realiza estimaciones de su conocimiento basándose en el porcentaje de páginas visitadas por cada concepto del dominio. El modelo del dominio de SIGUE es una jerarquía de conceptos relacionados con las relaciones prerrequisito y subtema_de.

SIETTE es un sistema de evaluación para la web que implementa tests adaptativos computerizados (CAT, Computer Adaptive Test). En este sistema, la decisión de cuando finalizar el test, el criterio de selección de ítems y la estimación del nivel de conocimiento del alumno se basan en una teoría psicométrica llamada Teoría de Respuesta al Item (IRT, Item Response Theory). SIETTE proporciona una herramienta de autor para desarrollar ítems y construir tests y una herramienta para la realización de los tests a través de la web.

SIGUE y SIETTE son sistemas que se han desarrollado como proyectos independientes de MEDEA por otros equipos del grupo IA2 (Investigación y Aplicaciones en Inteligencia Artificial). Estos sistemas están operativos desde antes de la construcción de MEDEA y se vienen utilizando de forma sistemática para el desarrollo de cursos web y de tests en diversas asignaturas de la Universidad de Málaga.

WADEIn II permite a los alumnos explorar el proceso de evaluación de expresiones en C paso a paso con gráficos y explicaciones detalladas. También ayuda a entender el orden de ejecución y la semántica de los operadores. Puede trabajar en dos modos exploration y knowledge evaluation. En el primero el sistema presenta visualizaciones complejas (animaciones, códigos de colores) acompañadas de textos explicativos. Conforme el alumno progresa aumenta la velocidad de las animaciones y disminuye el número de explicaciones. El alumno puede navegar a través de la evaluación paso a paso u operador a operador. En el modo knowledge evaluation el sistema presenta una serie de preguntas para evaluar el conocimiento del alumno acerca de los operadores de C.

169

Capítulo 6

6.2.4.1 Mostrar Contenidos: SIGUE

Tal y como se ha descrito en el apartado anterior, para integrar un RI, una vez proporcionada el API mínima exigida por MEDEA, es necesario construir un fichero WSDL que incluya los datos necesarios para la localización y ejecución de los distintos servicios del recurso. Los datos correspondientes a SIGUE se muestran en la siguiente tabla:

DESCRIPCIÓN SEMÁNTICA

Tipo evaluación double [0.0, 1.0]

DESCRIPCIÓN FUNCIONAL

Servicio Inicio de la ejecución Nombre Mostrar contenidos Parámetros de entrada alumno

concepto modoOp (4)

string string enumerado [1,2,3,4]

Parámetros de salida - - Ubicación http://castor.lcc.uma.es/sigue/Sigue

Servicio Fin de la ejecución Nombre endExecute Parámetros de entrada alumnoID

conceptoID string string

Parámetros de salida endExecuteReturn array de pares concepto: string valor: [0.0, 1.0]

Ubicación http://castor.lcc.uma.es/axis/services/SigueWS Servicio Nuevo usuario

Nombre newUser Parámetros de entrada alumno

alumnoClave string string

Parámetros de salida alumno clave

string string

Ubicación http://castor.lcc.uma.es/axis/services/SigueWS Servicio Exportar modelo del alumno

Nombre endExecute

Parámetros de entrada alumno alumnoClave

string string


string string

Ubicación http://castor.lcc.uma.es/axis/services/SigueWS Servicio Exportar modelo del dominio

Nombre getCourses

Parámetros de entrada curso string

170


Parámetros de salida getCoursesReturn array de strings con los nombres de los conceptos

Ubicación http://castor.lcc.uma.es/axis/services/SigueWS

Tabla 24 Datos para la integración del sistema SIGUE cono el RI “Mostrar contenidos” del marco de trabajo. . Entre paréntesis se muestran los valores por defecto de los parámetros.

SIGUE necesita para su ejecución, además de los parámetros alumno y concepto, el parámetro modoOP que representa uno de los cuatro posibles modos de operación de SIGUE. Los cursos de SIGUE están construidos a partir de URLs de páginas de la web. El modo de operación en SIGUE indica el grado de libertad del alumno para navegar a través de los enlaces que aparecen en esas páginas. Existen cuatro modos distintos: a) modo 1, se eliminan todos los enlaces externos de las páginas de modo que el sistema controla la navegación del alumno, b) modo 2, elimina sólo los enlaces que no estén registrados como parte del curso, c) modo 3, sólo se muestran aquellos enlaces que el alumno esté preparado para aprender en base a su modelo del alumno y d) modo 4, se habilitan todos los enlaces de las páginas. En la Fig. 44 se muestra a modo de ejemplo el código WSDL que describe este parámetro.

<simpleType name=" modoOP">

<restriction base="xsd:int"> <enumeration value=" 1 "/> <enumeration value=" 2 "/> <enumeration value=" 3 "/> <e numeration value=" 4 "/> </restriction> </simpleType>

<message name=" executeRequest “>

<part name=" alumno " type="xsd:string"/>

<part name=" concepto " type="xsd:string"/>

<part name=" modoOP " type="tns:modoOP"/></message><message name=" executeResponse"/><portType name=" SIGUE "> <operation name=" iexecute "> < input message="executeRequest"/>

< output message="executeResponse"/>

</operation> [...] </portType>

<xsd:element name="modoOP" type="impl:modoOP" default="4"/>

Fig. 44 Parámetros adicionales del recurso SIGUE

6.2.4.2 Test de auto-aprendizaje y Test de evaluación: SIETTE

En SIETTE, además de la identificación del alumno (usuario y clave) y del foco de instrucción (idtest) se pueden configurar diversos aspectos relativos al desarrollo y presentación de los tests a través de los parámetros:

request, indica el tipo de acción que está intentando hacer el alumno: autentificación si quiere verificar el usuario y la contraseña; alta si se quiere

171

Capítulo 6

dar de alta en el sistema y test, si desea realizar un test. El valor por defecto es test.

selectioncritic, representa el criterio de selección de los ítems de un test. El sistema puede elegir los items de forma aleatoria (ramdom), a través de métodos basados en parámetros y probabilidades asociados a las preguntas (adaptive, bayesian) o seguir una secuencia fija establecida por el profesor (ordered).

viewcorrection, que indica si se permitirá al alumno ver o no las soluciones de los tests.

La Fig. 45 muestra el fragmento del fichero WSDL que recoge la definición de estos parámetros.

<simpleType name="request"> <restriction base="xsd:string"> <enumeration value="register"/> <enumeration value="test"/> </restriction> </simpleType> <simpleType name="selectioncrit"> <restriction base="string"> <enumeration value="random"/> <enumeration value="adaptive"/> <enumeration value="bayesian"/> <enumeration value="ordered"/> </restriction> </simpleType> <simpleType name="viewcorrection"> <restriction base="xsd:int"> <enumeration value="0"/> <enumeration value="1"/> </restriction> </simpleType> <message name="inicioEjecucion_Request"> <part name="user" type="xsd:string"/> <part name="idtest" type="xsd:string"/> <part name="pwd" type="xsd:string"/> <part name="request" type="tns:request"/> <part name="selectioncrit" type="tns:selectioncrit"/> <part name="viewcorrection" type="tns:viewcorrection"/> </message> <message name="inicioEjecución_Response"/> <portType name="SIETTE"> <operation name="inicioEjecucion”> <input message="inicioEjecucion_Request"/> <output message="inicioEjecucion_Response"/> </operation> [...] </portType>

Fig. 45 Fragmento del fichero WSDL que recoge la definición de algunos parámetros de ejecución del sistema SIETTE

Con el fin de ilustrar la versatilidad de MEDEA se han incluido en el registro dos descripciones funcionales distintas del sistema SIETTE, de modo que el mismo recurso se muestre al alumno como dos tareas educativas

172


diferentes. En la primera de ellas se ha establecido el valor por defecto del parámetro viewcorrection a 1 pasándose a denominar la tarea Test de auto- aprendizaje. El alumno podrá de este modo, ejecutar un test y ver la solución a cada pregunta después de realizarla con lo que a la vez que auto-evalúa sus conocimientos puede ir aprendiendo de sus respuestas. En la segunda descripción funcional, el valor de este parámetro se ha establecido a 0 denominándose la tarea Test de evaluación. Con esta definición el alumno no podrá ver las soluciones del test. Tanto si selecciona la tarea Test de auto-aprendizaje como Test de evaluación el alumno estará ejecutando el recurso SIETTE. La única diferencia entre ambas radica en el valor asignado al parámetro viewcorrection, 1 y 0, respectivamente. La Tabla 25 muestra los datos comunes a ambas definiciones proporcionados por el técnico encargado de la integración del SIETTE. En las tablas y Tabla 27 se muestra la definición del servicio Inicio de ejecución para cada uno de los RI.


Tipo evaluación double [0.0, 1.0]


Servicio Fin de la ejecución Nombre obtenerEstimaciones Parámetros de entrada usuario

clave string string

Parámetros de salida obtenerEstimacionesReturn array de pares concepto: string valor: [0.0, 1.0]

Ubicación http://castor.lcc.uma.es/axis/services/SigueWS Servicio Nuevo usuario

Nombre altaUsuario Parámetros de entrada alumno



string string

Ubicación http://castor.lcc.uma.es/axis/services/SigueWS Servicio Exportar modelo del alumno

Nombre obtenerEstimaciones Parámetros de entrada alumno



string string

Ubicación http://castor.lcc.uma.es/axis/services/SigueWS Servicio Exportar modelo del dominio

Nombre getCourses

Parámetros de entrada curso string

173

Capítulo 6

Parámetros de salida getCoursesReturn array de strings con los nombres de los conceptos

Ubicación http://castor.lcc.uma.es/axis/services/SigueWS

Tabla 25 Datos comunes para la integración del sistema SIETTE cono los RI “Test de auto-aprendizaje” y “Test de evaluación” del marco de trabajo

Servicio Inicio de la ejecución Nombre Test de auto-aprendizaje Parámetros de entrada usuario

idtema clave selectioncrit viewcorrection (1)

string string string enumerado [random, adaptive, bayesian, ordered] enumerado [0,1]

Parámetros de salida - - Ubicación http://polux.lcc.uma.es/siette/siette

Tabla 26 Definición del servicio “Inicio de ejecución” del RI “Test de auto-aprendizaje” asociado a SIETTE. Entre paréntesis se muestran los valores por defecto de los parámetros.

Servicio Inicio de la ejecución Nombre Test de aprendizaje Parámetros de entrada usuario

idtema clave selectioncrit viewcorrection (0)

string string string enumerado [random, adaptive, bayesian, ordered] enumerado [0,1]

Parámetros de salida - - Ubicación http://polux.lcc.uma.es/siette/siette

Tabla 27 Definición del servicio “Inicio de ejecución” del RI “Test de evaluación” asociado a SIETTE. Entre paréntesis se muestran los valores por defecto de los parámetros.

6.2.4.3 Evaluación de expresiones en C: WADEIn II

WADEIn II es un recurso específico para una parte muy concreta del dominio de programación en C: las expresiones y para una estrategia de enseñanza claramente definida: visualizaciones explicativas. Por lo tanto, al contrario de lo que ocurre en SIETTE, el sistema es poco flexible y son muy pocos los aspectos que se pueden configurar. En concreto existe sólo un parámetro de ejecución, aparte de el usuario y el concepto, llamado m que indica el modo en el que el applet debe ser arrancado, el valor 1 significa modo Evaluación. A continuación se muestran los datos correspondientes a la definición de lrecurso WADEIn II:


Tipo evaluación real [0.0, 1.0]


Servicio Inicio de la ejecución

174


Nombre WADEIn II Parámetros de entrada alumno

concepto m (1)

string string string

Parámetros de salida - - Ubicación http://kt1.exp.sis.pitt.edu:8080/wadein/servlet/wadein.Dispatcher

Servicio Fin de la ejecución Nombre endExecute Parámetros de entrada alumnoID

conceptoID string string

Parámetros de salida endExecuteReturn array de pares concepto: string valor: [0.0, 1.0]

Ubicación http://kt1.exp.sis.pitt.edu:8080/axis/services/WADEInWS Servicio Nuevo usuario

Nombre newUser Parámetros de entrada alumno



string string

Ubicación http://kt1.exp.sis.pitt.edu:8080/axis/services/WADEInWS Servicio Exportar modelo del alumno

Nombre endExecution

Parámetros de entrada alumno alumnoClave

string string


string string

Ubicación http://kt1.exp.sis.pitt.edu:8080/axis/services/WADEInWS Servicio Exportar modelo del dominio

Nombre getDomains

Parámetros de entrada dominio string Parámetros de salida getCoursesReturn array de strings con los nombres de los

conceptos Ubicación http://kt1.exp.sis.pitt.edu:8080/axis/services/WADEInWS

Tabla 28 Datos para la integración del sistema WADEIn II cono RI del marco de trabajo. Entre paréntesis se muestran los valores por defecto de los parámetros.

6.3 Conclusiones

La metodología de desarrollo para WILE definida en el capítulo anterior aborda el proceso de construcción de entornos de aprendizaje desde distintos prismas teniendo en cuenta los diferentes tipos de usuario que intervienen en él, analizando sus necesidades particulares y el papel que cada uno juega dentro de la tarea global del desarrollo. La metodología divide este proceso en cuatro

175

Capítulo 6

capas. La capa 2 corresponde al profesor, al que se le proporciona la funcionalidad básica de un STI (capa 0) y un conjunto de recursos de instrucción (capa 1) que le permiten reutilizar tanto los contenidos como la inteligencia asociada a los mismos (forma de presentar esos contenidos), de modo que el docente pueda concentrarse en el diseño instructivo del WILE (cómo desea enseñar). Para que esto sea posible es necesario un marco de trabajo que, ajustándose a las especificaciones de la metodología, implemente todas las capas proporcionando a cada usuario la funcionalidad completa de la capa anterior y las herramientas necesarias para construir la capa que le corresponde.

En este capítulo se describe una implementación de las capas 0 y 1 del marco de trabajo. El objetivo de este desarrollo es ejemplificar todo lo expuesto en el capítulo anterior. Este marco de trabajo no es válido para demostrar la eficacia de las estrategias de planificación, la gestión de los modelos del alumno y del dominio así como de los recursos integrados. Factores como el dominio o las tareas y contenidos elegidos por el profesor determinan en gran parte su idoneidad para un entorno particular, por lo que cada WILE construido debería ser evaluado de forma independiente.

Las comunicaciones entre el núcleo y los RI están basadas en la tecnología de servicios web. El API de cada RI se describe mediante un documento WSDL (Web Service Description Language) que se corresponde en gran parte con lo que en la metodología se define como descripción funcional de un RI.

Los elementos del núcleo están supeditados al objetivo de su integración con otros sistemas inteligentes. Para alcanzar este fin es necesario compartir conocimiento. El concepto se ha tomado como unidad mínima de conocimiento de modo que los modelos del dominio y del alumno están formados por un conjunto de conceptos, acompañados, en el caso del modelo del alumno, por un valor que indica el nivel de conocimiento. Los atributos que definen un concepto en el dominio, así como la existencia o no de relaciones, su tipo e interpretación son decisiones que se toman durante la construcción del marco de trabajo. En la Tabla 29 se muestra la estructura final del dominio y del modelo del alumno para el marco desarrollado. El planificador de instrucción, haciendo uso de estos modelos y del registro de recursos de instrucción, es el encargado de seleccionar en cada paso de la instrucción a) el concepto del dominio más adecuado para ser aprendido por el alumno y b) el RI más apropiado para aprenderlo. El algoritmo elegido es un heurístico basado en principios pedagógicos bastante generales y aplicables a cualquier dominio. Los elementos del núcleo descritos en este capítulo podrían sustituirse por cualquier otro que cumpla las especificaciones dadas por la metodología.

Red semántica de conceptos MODELO DEL DOMINIO

Atributos de conceptos

Dificultad Nota mínima Tipo de evaluación (Enumerado, real o distribución)

176


Relaciones entre conceptos

Estructurales (es_un, parte_de) Pedagógicas (prerrequisito, subtema_de)

Modelo de superposición multi-nivel

Modelo de conocimiento

Nivel de conocimiento comprobado Nivel de conocimiento estimado Nivel de conocimiento inferido por prerrequisitos Nivel de conocimiento inferido por granularidad

Modelo de aptitudes

Desarrollo cognitivo Motivación Estilo de aprendizaje Progreso Experiencia con el ordenador Velocidad de conexión

MODELO DEL ALUMNO

Historial de acciones

Tareas realizadas Para cada concepto: - Número de veces que ha sido elegido por el alumno - Número de veces que ha sido elegido por el

planificador - Número de veces que ha sido elegido por el

planificador y rechazado por el alumno.

PLANIFICADOR DE INSTRUCIÓN

Heurístico basado principalmente en un conjunto de principios pedagógicos. Toma sus decisiones en base a las relaciones establecidas en el modelo del dominio y al contenido del modelo del alumno.

INTERFAZ Dos marcos principales. En uno de ellos el alumno ejecuta las tareas de enseñanza y en el otro se muestra el dominio, información acerca de su nivel de conocimiento y botones para acceder a las tareas y al planificador.

Tabla 29 Núcleo del marco de trabajo

Además de los elementos del núcleo el marco de trabajo debe proporcionar un conjunto de tareas educativas que puedan ser usadas por el profesor para la construcción de sus sistemas. Estas tareas son los llamados recursos de instrucción, aplicaciones externas que se integran en el marco de trabajo con el fin de reutilizar desarrollos anteriores.

En este marco de trabajo se han integrado dos sistemas educativos que ya se venían usando de forma independiente en diversas asignaturas de la Universidad de Málaga, SIGUE y SIETTE, cuyas tareas son respectivamente, el desarrollo de cursos usando páginas web existentes y la realización de tests adaptativos computerizados a través de la web. Estos sistemas han dado origen a tres recursos de instrucción Mostrar contenidos (asociado a SIGUE) y Test de auto-aprendizaje y Test de evaluación (asociado a SIETTE). A ellos se ha unido un tercer sistema, WADEIn II, un recurso que ayuda al alumno a evaluar expresiones en C.

Tras la presentación de este marco de trabajo es necesario hacer hincapié en que el objetivo de esta tesis no es construir un planificador o un modelo del alumno, etc. que representen un valor añadido a otros modelos ya existente en el campo de los sistemas educativos inteligentes. El interés de esta investigación

177

Capítulo 6

se centra en arquitectura y organización de todo el conjunto y principalmente en el establecimiento de una metodología de desarrollo que permita construir de forma sistemática entornos de aprendizaje capaces de reutilizar otros sistemas educativos. Por lo tanto los elementos del núcleo descritos en este capítulo se consideran como un ejemplo de implementación y no se evalúan en esta tesis.

Tras todo lo expuesto, y retomando los objetivos marcados en el 0, queda patente que el marco de trabajo construido: a) permite la reutilización de sistemas educativos completos, no sólo el material y los contenidos sino su “inteligencia”, el conocimiento acerca de “cómo enseñar”; b) es distribuido, pudiendo estar sus elementos repartidos entre distintos sitios de la red y c) es de carácter abierto, es decir, permite la inserción y eliminación de forma “dinámica” de RI, sin necesidad de recompilar el sistema y/o modificar el resto de elementos.

En el Capítulo 7 se describe el proceso de creación de un WILE (capa 2) usando el marco de trabajo descrito en este capítulo. Para ilustrar dicho proceso se han desarrollado dos entornos de aprendizaje para los dominios de Lógica y Economía Agraria. Su desarrollo junto con las pruebas realizadas por técnicos y profesores para integrar RI y construir WILE (Capítulo 8) ponen en evidencia el carácter genérico de la propuesta (válido para un amplio rango de dominios), la reducción de los costes de desarrollo y la versatilidad respecto a otros sistemas inteligentes.

178

Capítulo 7 CONSTRUCCIÓN DE ENTORNOS DE APRENDIZAJE INTELIGENTES PARA LA WEB POR USUARIOS NO ESPECIALIZADOS

El objetivo de esta tesis es proporcionar una solución viable al problema del desarrollo de entornos de aprendizaje inteligentes. Tal y como se expresó en capítulos anteriores, esta propuesta se concreta en MEDEA (MEtodologías y herramientas para el Desarrollo de entornos inteligentes de Enseñanza y Aprendizaje). Según la jerarquía de niveles de Newell para sistemas basados en el conocimiento, podríamos decir que MEDEA cuenta con una metodología de desarrollo que se corresponde con el nivel del conocimiento y un marco de trabajo que constituye el nivel simbólico.

El Capítulo 5 describe la metodología de desarrollo, que articula varias capas en virtud de los distintos actores que intervienen en este proceso. La capa 0 representa los elementos comunes a cualquier sistema instructor inteligente y la capa 1 modela los recursos externos que se integran con los anteriores para proveer al alumno de una instrucción personalizada reutilizando material y software educativo. Ambas sientan las bases para que los docentes, actores de la capa2, puedan centrarse en “cómo enseñar” completando la construcción de un WILE. La capa 3 modela el proceso de aprendizaje.

Para mostrar la validez de esta metodología se ha construido un marco de trabajo. El Capítulo 6 describe la implementación de las capas 0 y 1 (dicho desarrollo se considera un ejemplo de implementación, cualquiera de estos módulos podría ser sustituido por otro siempre que se ajuste a las especificaciones de la metodología). Basándose en esta implementación, el presente capítulo describe los detalles de creación (capa 2) y uso (capa 3) de un WILE. Para ilustrar tanto la construcción del entorno como el proceso de aprendizaje se han desarrollado a modo de ejemplo dos sistemas que versan sobre Lógica y Economía Agraria respectivamente.

179

Capítulo 7

7.1 Capa 2. Conocimiento de instrucción: construcción de un WILE.

El núcleo del marco de trabajo (capa 0) contiene los elementos propios de todo STI: un modelo del dominio, un modelo del alumno, un módulo de instrucción y una interfaz. Durante el proceso de aprendizaje el alumno irá seleccionando conceptos del currículo y realizando tareas que le ayuden a asimilarlo. La construcción de un entorno de aprendizaje consistirá básicamente en determinar qué materia se va a estudiar y cómo. Para ello será necesario 1) modelar el dominio, 2) seleccionar los RI que formarán parte del entorno, 3) establecer para qué conceptos del dominio es válido cada RI, es decir, qué tareas se podrán realizar para estudiar cada tema y 4) las tareas más adecuadas para un determinado tipo de alumno.

7.1.1 Creación del dominio

Esta tarea corresponde a un experto que debe estructurar el dominio, es decir, descomponerlo en unidades de conocimiento (conceptos) y establecer las relaciones entre ellas. El marco de trabajo establece el conjunto de atributos disponibles para definir cada concepto (nombre, dificultad, nota mínima y tipo de evaluación) así como los tipos de relaciones disponibles (es_un, parte_de, prerrequisito y pertenece_a).

Con el propósito de facilitar esta tarea, se ha construido una herramienta de edición de dominios, DOM-EDIT, que permite definir un dominio utilizando un entorno visual y generar el fichero OXML correspondiente a partir de un grafo. La Fig. 46 muestra el aspecto de la interfaz de DOM-EDIT. En primer plano podemos ver una red de conceptos y en la esquina inferior derecha el fichero OXML que se genera a partir de la misma.

Fig. 46 DOM-EDIT: herramienta para la edición de dominios

180

Construcción de entornos de aprendizaje inteligentes para la web por usuarios no especializados

181

7.1.2 Selección del dominio

El profesor seleccionará uno de los dominios ya creados para construir su entorno de aprendizaje. Éste constituirá la base sobre la que se irá configurando la estrategia de enseñanza y las distintas tareas que puede realizar el alumno.

7.1.3 Selección de los recursos de instrucción

Como parte de su estrategia de enseñanza, el docente debe asignar a cada concepto del dominio una lista con las tareas que el alumno puede llevar a cabo. La realización de una de ellas provoca la ejecución del recurso de instrucción correspondiente. En este punto surge el problema del aspecto semántico de la comunicación entre dos sistemas inteligentes.

Un RI inteligente se define como una aplicación externa e independiente que posee su propio modelo del dominio. En MEDEA no se establece ningún vocabulario común al núcleo y al RI, es decir, no se comparte ninguna ontología del dominio, de modo que, si el alumno solicita realizar una tarea sobre un concepto concreto el RI no será capaz de entender acerca de qué le están pidiendo que le enseñe. Del mismo modo, cuando el RI comunique los resultados obtenidos, el modelo del alumno del núcleo no será capaz de interpretarlos. Por ejemplo, supongamos un entorno de aprendizaje para operaciones aritméticas simples cuyo dominio contiene el concepto multiplicación. Supongamos también que existe un recurso de instrucción que permite realizar operaciones simples cuyo dominio está formado por los términos suma, resta, producto y división. Es evidente que para que el recurso pueda usarse a través del entorno alguien debería indicarle que cuando se dice multiplicación en realidad se quiere decir producto.

Para solucionar esto es necesario establecer una equivalencia de términos entre ambos dominios (estas relaciones constituyen el grueso de la descripción semántica (5.3.3.2)). Como primer paso el profesor solicita al RI, a través del servicio Exportar modelo del dominio, la lista de términos que componen su dominio. A continuación establecerá las correspondencias con los conceptos de su propio dominio. Por ejemplo, en el dominio de Lógica creado por el experto se incluye el término NOT que es equivalente al concepto Negación que aparece en el dominio de SIGUE. Al realizar esta tarea pueden presentarse distintas situaciones que pasamos a analizar.

En primer lugar puede ocurrir que para un concepto no exista su homólogo en el dominio del recurso de instrucción. En este caso el concepto no podría ser estudiado usando esa tarea. Por ejemplo, en un dominio de Programación en C disponemos de un recurso que muestra una representación gráfica de distintos arrays de estructuras y una lista de códigos para que el alumno relacione cada gráfica con su código. Este RI reduce su dominio a los conceptos estructuras de datos, estructuras y arrays y por tanto el concepto bucle for del dominio del docente no podrá ponerse en correspondencia con ninguno de ellos. Esta tarea no podría ser asignada como una de las tareas útiles para estudiar el bucle for.

Capítulo 7

Puede darse la situación inversa, que exista un concepto en el dominio del RI para el que no haya uno equivalente en el dominio del WILE. En este caso existiría material del RI que nunca se mostraría al alumno por estar fuera del alcance o el ámbito del dominio de su instrucción.

Otra circunstancia que puede darse es que no exista una correspondencia clara uno a uno, sino que un término del dominio sea equivalente a varios del RI o viceversa (1-n, n-1). Por ejemplo en el entorno de Lógica que se describe más adelante, el experto definió el concepto Introducción que mas tarde el profesor asoció a los términos de SIETTE Índice, Prolegómenos, Verdad y validez y Los lenguajes lógicos. Como ejemplo del caso contrario encontramos como el profesor puso en correspondencia los términos Proposición, Proposición atómica y Proposición molecular de su dominio con el término Proposiciones del dominio de SIGUE.

Una vez seleccionado los RI y establecidas las correspondencias entre dominios, el entorno de aprendizaje estará disponible para su uso. En este punto del desarrollo las estrategias de instrucción son comunes a todos los alumnos. El profesor puede refinar el conocimiento de instrucción estableciendo distintas estrategias para distintos perfiles de alumnos. En el siguiente epígrafe se aborda esta cuestión.

7.1.4 Adaptación de cada tarea a los perfiles del alumno

Un RI es usado por un alumno para estudiar un concepto del dominio. Así pues, tal y como se explicó en la sección 6.2.3, la función Inicio de la ejecución del API de un RI tiene como parámetros de entrada el alumno y el concepto que se va a estudiar. Además de estos parámetros, comunes a todos los RI, cada aplicación contará con un conjunto particular de parámetros adicionales. Puede que algunos de ellos sirvan para configurar aspectos relativos al desarrollo de la tarea y por lo tanto tengan influencia en la estrategia de enseñanza. El integrador del recurso proporciona para cada uno un valor por defecto que, de no indicarse lo contrario, será el empleado por todos los alumnos.

El paso 3 de la capa 2 de la metodología de desarrollo reza que “el profesor puede establecer, como parte de su estrategia, qué tareas son mas adecuadas que otras para un tipo determinado de alumno”. Para ello el profesor establecerá correspondencias entre una instancia del modelo de aptitudes y un conjunto de valores de los parámetros de ejecución o un conjunto de atributos de la descripción semántica de un RI (Learning Type,...). Para aclarar este punto en la siguiente tabla se muestran dos ejemplos de adaptación realizados respectivamente en el entorno de Lógica para el recurso Mostrar contenidos (asociado al programa SIGUE) y en el de Economía Agraria para el recurso Test de aprendizaje (asociado al programa SIETTE).

DOMINIO RECURSO DE INSTRUCCIÓN PERFIL

CONJUNTO DE PARÁMETRO /

VALOR

Lógica Mostrar contenidos

Desarrollo cognitivo = Bajo ModoOp = 2

182


183

(SIGUE) Experiencia con el ordenador = Poca

Economía Agraria

Test de aprendizaje (SIETTE)

Desarrollo cognitivo = Alto Motivación = Alta

Selectioncritic= Adaptive

Tabla 30 Ejemplos de adaptación de tareas a perfiles para los entornos de Lógica y Economía Agraria

SIGUE adapta páginas existentes en la web para que el alumno estudie una materia. Estas páginas poseen enlaces que pueden ser externos o apuntar a otras páginas que pertenecen al mismo curso. SIGUE permite regular el grado de libertad de navegación a través de esos enlaces usando el parámetro modoOP, que tomará valores de 1 a 4 que van desde la anulación de dichos enlaces hasta la plena libertad de navegación. El profesor, al construir el entorno de Lógica determinó que para los alumnos con un desarrollo cognitivo bajo y con poca experiencia con el ordenador este parámetro tomará el valor 2 (no se permiten accesos a enlaces externos al curso). La justificación pedagógica es que alumnos poco acostumbrados a navegar por la web y que además no conocen mucho el dominio de instrucción corren un riesgo elevado de perderse en el hiperespacio y por lo tanto necesitan que el sistema les limite el número de caminos.

Por su parte, SIETTE permite elegir el criterio de selección de ítems en un test a través del parámetro criterio de selección (selectioncrit). Esta elección puede ser a) aleatoria (ramdom), b) a través de métodos basados en parámetros y probabilidades asociados a las preguntas (adaptativo (adaptive) o bayesiano (bayesian)) o c) seguir una secuencia fija establecida por el profesor (ordered). Para el entorno de Economía Agraria el profesor ha establecido que los alumnos con un desarrollo cognitivo alto y una motivación baja usen el método de selección de preguntas adaptativo. La justificación de esta elección es que para aquellos alumnos cuya habilidad para comprender conceptos abstractos sea elevada pero estén poco motivados, se disminuye el riesgo de aburrimiento y abandono si realizan tests adaptativos que reducen sensiblemente el número de preguntas respecto a los test tradicionales.

El número de relaciones perfil-parámetro(s) no está limitado a uno, por ejemplo el profesor podría establecer en el caso de SIETTE, qué tipo de alumnos harán tests adaptativos, cuál será el perfil para los tests aleatorios y qué otro se ceñirá al orden establecido por el profesor. Si el perfil de un alumno no coincide con ninguno de los prototipos definidos usará los valores por defecto.

El resultado de este proceso de adaptación depende del modelo de aptitudes del alumno, de la documentación aportada por el creador del recurso y de la experiencia del docente. En efecto, la precisión con la que el modelo de aptitudes permita describir a un alumno así como una exacta descripción de los parámetros de ejecución de un recurso, facilitarán una mejor adaptación. Que duda cabe que la experiencia docente del profesor le permitirá manejar toda esta información y aplicar sus conocimientos en favor de una adaptación lo más precisa posible de la instrucción.

Capítulo 7

7.1.5 Aplicación de distintos estilos de enseñanza

La forma en que diferentes alumnos procesan la información y aprenden una materia varía en función de sus preferencias y habilidades. Es lo que conocemos como estilos de aprendizaje. Un modelo de estilos de aprendizaje establece un conjunto de categorías relativas al modo en el que un alumno procesa la información, clasificándolo de acuerdo con sus preferencias a la hora de aprender (sensitivos/intuitivos, inductivos/deductivos, etc.). Existen distintos modelos basados en diversas teorías psicológicas como las de Jung (Jung, 1994), Gardner (Gardner, 1983) o Bloom (Bloom et al., 1956). De forma paralela a los modelos de aprendizaje se han desarrollado modelos de estilos de enseñanza que determinan las técnicas de instrucción que mejor se ajustan a cada estilo de aprendizaje (Felder and Silverman, 1988; Kolb, 1984).

En este epígrafe se presentan algunos de los estilos más usados en el campo de los sistemas inteligentes. MEDEA permite a los autores ajustarse a cualquiera de ellos e incluso simultanear varios. A continuación se describe el modo de enfocar el proceso de creación de sistemas inteligentes (según lo visto en los apartados anteriores) para aplicar cada uno de los modelos presentados.

Aprender haciendo (Learning by doing) (Schank et al., 1999). El objetivo de esta teoría es fomentar el desarrollo de habilidades y el aprendizaje de hechos en el contexto de cómo serán usados. Para ello se deben presentar al alumno actividades relacionadas con los objetivos de aprendizaje y en las que el alumno pase la mayor parte del tiempo practicando las habilidades que se esperan desarrollar. Existen diversas aproximaciones a este estilo de enseñanza como por ejemplo:

- Aprendizaje basado en problemas (Problem-Based Learning) (Barrows and Tamblyn, 1980). Es el aprendizaje que resulta del proceso de trabajar en la resolución de un problema.

Para crear un entorno basado en este estilo de aprendizaje usando MEDEA sería necesario: 1. Definir un dominio cuyos conceptos representen los distintos

problemas que el alumno debe resolver para alcanzar un determinado objetivo de aprendizaje.

2. Integrar herramientas para la resolución de los distintos tipos de problemas del dominio.

3. Asociar a cada nodo del dominio el/los recursos apropiados para resolver el problema que representan.

- Aprender explorando (Learning by exploring) (Schank and Cleary, 1995). Cuando un alumno está desarrollando una tarea y se implica en el aprendizaje genera preguntas y aprende de ellas. Esta teoría se basa en responder a esas preguntas conforme el alumno se las va haciendo y a la vez presentar ejemplos, explicaciones, etc. relacionadas con las respuestas a las preguntas para que el alumno vaya recorriendo el espacio de conocimiento según sus necesidades.

184


185

Para crear un sistema exploratorio con este marco de trabajo el profesor debería: 1. Definir un dominio que incluya, además de conceptos propios del

espacio de conocimientos, nodos que representen preguntas frecuentes.

2. Crear páginas (con SIGUE, por ejemplo) cuyo contenido sean respuestas a esas preguntas, ejemplos que justifiquen las respuestas, explicaciones que las complementen, etc.

3. Asociar esas páginas a los conceptos del dominio correspondientes.

- Aprendizaje basado en proyectos (Project-Based Learning). Es un método de instrucción centrado en el alumno. A través de la construcción de un objeto significativo para el alumno (un juguete, una presentación multimedia, un poema, etc.) los alumnos representan lo que han aprendido. Para ello se le plantea al alumno una tarea cuyo resultado es la construcción de un objeto que puedan compartir con otros alumnos y se le facilitan recursos para llevarla a cabo (libros, herramientas, etc.)

La traslación de este método de enseñanza al proceso de creación es prácticamente inmediata, quedando como sigue: 1. El dominio representaría el guión de desarrollo del proyecto. La

granularidad del mismo podría variar desde un único nodo que represente la tarea a desarrollar hasta un conjunto detallado de pasos que hay que completar para lograr el objetivo.

2. A cada nodo se le asociarán los recursos necesarios para llevar a cabo esa parte del proyecto.

Aprendizaje basado en casos (Case-Based Learning) (Schank and Cleary, 1995). La idea de esta teoría es proporcionar al alumno la información que necesita en el momento que la necesita para que pueda aprender de sus errores. El alumno es ubicado en una situación concreta. Cuando el instructor detecta que se ha bloqueado o ha cometido un fallo deduce que está listo para aprender e interviene. Los alumnos pueden pedir ayuda cuando lo necesiten. El aprendizaje basado en casos complementa el estilo de aprender haciendo (Learning by doing) proporcionando al alumno las tareas que deber ir realizando.

La implementación de esta estrategia no es inmediata. La capa 3 de la metodología de desarrollo indica que el alumno puede realizar la tarea que desee en el momento que considere más oportuno a lo largo de su proceso de instrucción. El sistema no tiene control sobre las acciones del alumno ni está preparado para intervenir en un momento concreto. Sin embargo, durante la ejecución de una tarea se cede el control al recurso de instrucción asociado a la misma. De este modo, el profesor podría integrar recursos que implementen el aprendizaje basado en casos y asociarlo a aquellos conceptos de su dominio para los que considere que sería útil la aplicación de este método de enseñanza.

Capítulo 7

7.1.6 Creación de nuevo material didáctico

Los sistemas educativos inteligentes suelen tener arquitecturas fuertemente acopladas y poco modulares. Esto impide en muchas ocasiones reutilizar sólo el material didáctico ya que éste separado del resto del sistema carece de sentido. Esta es una de las razones por las que MEDEA se plantea como uno de sus principales objetivos integrar sistemas completos como partes de otro reutilizando, no sólo el material, sino las estrategias de enseñanza diseñadas alrededor de ese material.

Existen recursos de instrucción para la enseñanza de dominios específicos, como ELM-ART de LISP, Algebrain-Tutor de álgebra o Medtec (Eliot et al., 1997) de anatomía y otros genéricos (aplicable a varios dominios), como AHA, CALAT o CATGlobal. Independientemente de esto, los recursos pueden contener material ya creado por otros profesores y, en algunos casos, herramientas de autor para el desarrollo de nuevo material. En cualquier caso la creación de material didáctico es un proceso externo a MEDEA.

El marco de trabajo descrito en el capítulo anterior incluye cuatro recursos de instrucción basados en tres aplicaciones: Mostrar contenidos (programa SIGUE), Test de aprendizaje y Test de evaluación (programa SIETTE) y Evaluación de expresiones en C (WADEIn II). SIETTE y SIGUE poseen sus propias herramientas para la creación de material. WADEIn II no ofrece la posibilidad de añadir y/o modificar material alguno.

7.1.6.1 Material didáctico del recurso SIGUE: páginas web

SIGUE es un sistema para la construcción de cursos web mediante la indexación de páginas ubicadas en Internet. En la Fig. 47 se muestra la interfaz de la herramienta de autor del sistema SIGUE (Carmona et al., 2002).

En SIGUE el modelo del dominio es una jerarquía de conceptos con una o varias URL asociadas. El sistema permite establecer prerrequisitos entre los conceptos. El profesor puede definir distintos grados de libertad en la navegación del alumno. Para ello puede a) deshabilitar todos los enlaces de las páginas incluidas en el curso, de modo que el alumno sólo pueda navegar a través del árbol de conceptos; b) dejar todos los enlaces contenidos en las páginas, permitiendo al alumno navegar libremente y c) habilitar sólo los enlaces que hacen referencia a páginas que pertenecen al curso.

7.1.6.2 Material didáctico del recurso SIETTE: tests

SIETTE es un sistema para la creación y desarrollo de tests adaptativos a través de la web (Conejo et al., 2004). El sistema cuenta con una herramienta de autor para la definición de ítems y tests (Fig. 48). Un test en SIETTE tiene una estructura jerárquica formada por tests, temas e ítems, donde un test incluye uno o más temas, cada uno de los cuales contiene un conjunto de ítems. Un tema puede pertenecer a más de un test y una pregunta a diferentes temas.

186


187

Fig. 47 Herramienta de autor del sistema SIGUE

Fig. 48 Herramienta para la creación de preguntas del sistema SIETTE

SIETTE permite definir distintos tipos de preguntas (respuesta única, respuesta múltiple, respuesta libre, etc.) así como configurar algunas características de los tests referentes a su presentación, modo de evaluación y método de selección de ítems. La mayoría de esas variables son parámetros del servicio Inicio de ejecución invocado desde MEDEA. Al llamar a este servicio,

Capítulo 7

SIETTE genera y muestra el test del concepto del dominio seleccionado por el alumno desde el entorno de aprendizaje.

7.1.7 Actualización y mantenimiento del entorno de aprendizaje

Un entorno de aprendizaje siempre está sujeto a mejoras y modificaciones. Estas actualizaciones pueden afectar a cualquiera de los elementos creados por los actores que intervienen en el proceso de desarrollo: modelo del dominio, material, recursos de instrucción seleccionados y estrategias educativas resultado de la adaptación de tareas.

Actualización del material docente.

La creación y/o modificación de material docente debe realizarse a través de las herramientas de autor de cada recurso, en caso de que estos lo permitan.

Si el profesor modifica y/o crea material acerca de un concepto del dominio puesto en correspondencia con un concepto del recurso, la actualización es inmediata. Cualquier alumno que seleccione el recurso para estudiar el tema afectado dispondrá del nuevo material al momento.

Si por el contrario, el profesor crea nuevo material para un concepto que en un principio no fue relacionado con otro del recurso, es necesario establecer esa correspondencia si se quiere que el alumno pueda acceder a dicho material.

Integración y/o eliminación de recursos de instrucción

MEDEA permite la integración de recursos en el marco de trabajo de forma dinámica. Basta proporcionar su descripción funcional (fichero WSDL) y automáticamente estará disponible para aquellos docentes que deseen añadirlo a sus entornos siguiendo el proceso descrito en 7.1.3. Para eliminar completamente un recurso de un entorno sólo será necesario desvincularlo del mismo sin que esto afecte a su disponibilidad para otros entornos.

Asignación de tareas a temas

El profesor puede modificar en cualquier momento las relaciones entre los términos de su dominio y los del dominio de un determinado recurso. Como consecuencia de ello el alumno podrá realizar nuevas tareas para estudiar algunos conceptos o dejará de tener a su disposición otras, según se añadan o eliminen correspondencias.

Por ejemplo podría ocurrir que el alumno tuviese a su disposición un test sobre “Proposiciones atómicas” en el curso de “Lógica” que desaparecería del sistema si se elimina la relación de este concepto con su equivalente en el sistema SIETTE. Por el contrario, si no existía ningún test sobre “Proposiciones atómicas”y el profesor establece una relación con un concepto del dominio de SIETTE el test pasaría a estar disponible.

Modificación del dominio

188


189

La modificación del dominio puede afectar al modelo del alumno y por supuesto a las correspondencias establecidas con los dominios de algunos recursos.

Si se eliminan conceptos del dominio, la información relativa a los mismos será eliminada de los modelos de los alumnos. Del mismo modo serán eliminadas de la descripción semántica todas aquellas relaciones en las que dicho concepto participe.

Por otro lado, si se añaden conceptos al dominio, el modelo del usuario no se verá afectado ya que la información relativa a los mismos se irá construyendo durante el proceso de aprendizaje. En cuanto a las descripciones semánticas, el profesor deberá establecer las correspondencias necesarias si desea que los nuevos conceptos tengan tareas asignadas dentro de su sistema.

7.2 Entornos de aprendizaje inteligentes basados en MEDEA

En los epígrafes anteriores se ha desgranado el proceso para la construcción de un entorno de aprendizaje inteligente haciendo uso del marco de trabajo descrito en el Capítulo 6. Para ilustrar el protocolo de actuación del experto y el docente se han construido dos WILE sobre los dominios de Lógica y Economía Agraria que se describen a continuación.

El desarrollo de estos sistemas, junto con las pruebas que se presentan en el próximo capítulo, evidencian el carácter genérico del trabajo realizado (válido para un amplio rango de dominios), la reducción de los costes de desarrollo de un WILE y una mayor versatilidad en comparación con otros sistemas inteligentes.

7.2.1 Lógica

Profesores del área de Lógica y Filosofía de la Ciencia (Departamento de Filosofía) de la Universidad de Málaga desarrollaron durante los años 2000-2001 un conjunto de tests y páginas web para el seguimiento de una asignatura de Lógica de primer ciclo universitario usando los sistemas SIETTE y SIGUE respectivamente. Este material se ha usado para construir un entorno de aprendizaje inteligente sobre Lógica usando el marco de trabajo de MEDEA. A continuación se describen las tareas llevadas a cabo para su creación.

1. Creación y selección del dominio

Este dominio está formado por treinta y siete conceptos y setenta relaciones. Existen seis conceptos principales que representan los temas del currículum: Introducción, Sintaxis Formal, Semántica Formal, Simbolización, Argumentos y Cálculo. El resto de conceptos establecen una relación de pertenencia (pertence_a) con alguno de ellos. En el Apéndice 1 se muestra un esquema del modelo.

2. Integración de recursos de instrucción

Capítulo 7

Una vez definido el dominio, el profesor debe decidir los recursos de instrucción que desea utilizar para su entorno. El proceso de integración se realiza proporcionando las correspondencias entre el dominio propio y el del recurso. Tras el establecimiento de estas relaciones, el recurso de instrucción pasa a formar parte del entorno de aprendizaje. A partir de ese momento el alumno puede hacer uso del mismo invocándolo a través de la interfaz.

El marco de trabajo proporciona tres recursos de instrucción: Mostrar contenidos (asociado a la aplicación SIGUE) y Test de auto-aprendizaje y Test de evaluación (asociados a SIETTE). Para este entorno se han usado sólo los dos primeros.

Mostrar Contenidos: en este entorno de aprendizaje se ha reutilizado el material existente para un curso web de lógica diseñado con SIGUE. Según el procedimiento descrito en 7.1.3, el profesor debe poner en correspondencia el dominio de Lógica del recurso SIGUE con el definido para su entorno. Tal y como se explicó, en caso de que algún concepto quede huérfano (no se establezca una relación para él), el alumno no dispondrá de ninguna página web con contenidos acerca del mismo.

Test de aprendizaje: el recurso Test de aprendizaje, asociado al sistema SIETTE se usa para realizar tests adaptativos permitiendo al alumno ver la respuesta correcta a cada una de las preguntas, de modo que pueda ir aprendiendo de ellas. La descripción semántica de este recurso contiene la correspondencia de ambos dominios, establecida de forma análoga a la del recurso Mostrar contenidos.

3. Adaptación del recurso a los perfiles del alumno

Cuando se realiza una invocación a un recurso se usan por defecto los valores establecidos por el técnico para sus parámetros de ejecución. El profesor puede modificar estos valores adaptando las distintas opciones o modos de ejecución de un recurso a distintos perfiles del alumno.

SIGUE posee un parámetro de ejecución (modoOP) que, tal y como se explicó en 7.1.4, controla el grado de libertad en la navegación a través de los enlaces de las páginas. Su valor por defecto es 1, lo que significa que todos los enlaces que no se correspondan con páginas incluidas en el dominio serán eliminados. Los profesores han decidido no modificar esta opción.

Del mismo modo los profesores no han modificado los valores establecidos por el técnico integrador para el recurso Test de aprendizaje, a saber: request = test, selectioncritic = random y viewcorrection=1.

190


191

Fig. 49 Ejemplo de ejecución del recurso “Mostrar contenidos” (SIGUE) acerca del concepto

“Proposiciones” en el WILE de Lógica

7.2.2 Economía Agraria

TEA (Belmonte et al., 1996) es un sistema instructor sobre Economía de la Empresa Agraria en cuyo desarrollo colaboraron profesores del Departamento de Lenguajes y Ciencias de la Computación de la Universidad de Málaga y del Departamento de Economía Agraria de la Universidad de Córdoba. Este sistema es un libro electrónico organizado en una estructura jerárquica de capítulos, cada uno de los cuales concluye con un conjunto de preguntas de test acerca del contenido del tema. El sistema, uno de los primeros de enseñanza a través de la web, no gestiona ningún modelo del alumno, tan sólo contiene ayuda a la navegación con hiperenlaces a otros capítulos para que el alumno pueda consultar y aclarar algunos conceptos incluidos en el tema que esté estudiando.

El material tanto teórico como práctico fue reutilizado posteriormente para construir por un lado un curso web usando la herramienta SIGUE y por otro, un test adaptativo usando el sistema SIETTE. El sistema SIGUE aporta al TEA original navegación adaptada al alumno y el sistema SIETTE la inteligencia propia de aplicar las teorías psicológicas de respuesta al ítem, de modo que tanto el número de preguntas de un test como su presentación se adapten al nivel de conocimiento del alumno. El inconveniente de este nuevo enfoque es que ahora el alumno tiene dos herramientas distintas para el estudio de su asignatura, cuando lo deseable sería contar con un único entorno para el desarrollo de todas sus actividades y un único modelo del alumno que compile los resultados obtenidos de las diversas tareas realizadas.

En este apartado se describe un WILE sobre Economía Agraria (TEA-MEDEA) creado a partir del curso desarrollado con la herramienta SIGUE y los test incluidos en SIETTE.

1. Creación y selección del dominio

Capítulo 7

Este dominio está formado por ciento diez conceptos y ciento veintiséis relaciones. El currículum, que se muestra en el Apéndice 1, está estructurado en catorce temas habiéndose establecido prerrequisitos entre conceptos de distintos temas.

2. Integración de recursos de instrucción

Una vez definido el dominio el profesor debe decidir qué recursos usar en su sistema y establecer las correspondencias de términos entre su dominio y el de los recursos seleccionados.

Mostrar contenidos: la integración del recurso SIGUE para este WILE ha sido análoga a la realizada en el entorno de Lógica. El autor ha reutilizado material preexistente, por lo que su única tarea ha consistido en establecer la correspondencia de los dominios. Las opciones de ejecución son las mismas.

Test de aprendizaje: del mismo modo que en el entorno de Lógica, los docentes han incluido la tarea Test de aprendizaje que consiste en realizar tests a través de SIETTE viendo tras cada pregunta la respuesta correcta

Test de evaluación: el recurso Test de evaluación está también asociada a la aplicación SIETTE. En este caso en la descripción funcional se indica, a través del parámetro viewcorrection =0, que los alumnos no podrán ver las soluciones a las respuestas hasta el final del test (ver 6.2.4.2). Esta tarea ha sido introducida con el único fin de evaluar los conocimientos de los alumnos.

3. Adaptación del recurso a los perfiles del alumno

En el apartado 7.1.4 se describe como el docente puede adaptar la ejecución de un recurso a un determinado perfil del alumno modificando el valor de sus parámetros de ejecución.

Para este sistema se ha modificado el valor del parámetro selectioncritic de modo que los alumnos con un desarrollo cognitivo = alto y una motivación = baja usen el método de selección de preguntas adaptativo (adaptive). La justificación de esta elección es que aquellos alumnos cuya habilidad para comprender conceptos abstractos sea elevada pero estén poco motivados, realicen tests adaptativos (que reducen sensiblemente el número de preguntas respecto a los test tradicionales) disminuyendo así el riesgo de abandono si el test llega a ser demasiado largo.

Para los alumnos cuyo desarrollo cognitivo es bajo los profesores han decidido que es mejor que puedan ver la respuesta correcta a cada pregunta (viewcorrection = 1), considerándose como un refuerzo que puede serles de utilidad para asimilar el concepto. Para estos mismos alumnos los docentes han decidido establecer una secuencia fija de preguntas de cada test por lo que sus invocaciones a SIETTE contendrán en su llamada el valor ordered para el parámetro seleccioncritic.

192


193

Fig. 50 Ejemplo de realización de un Test de auto-evaluación sobre el concepto “Empresario riesgo” del

WILE de Economía Agraria

7.3 Capa 3. Aprendizaje.

La metodología desarrollada en el Capítulo 5 establece el modo en el que se llevará a cabo el aprendizaje en un WILE una vez construido. Según esto, a lo largo del proceso de aprendizaje el alumno irá seleccionando conceptos del currículum (microadaptación) y realizando tareas que le ayuden a asimilarlo (macroadaptación). Para ello contará con la ayuda del planificador de instrucción que en cada momento le recomendará el concepto y la tarea más adecuados para él, basándose principalmente en su modelo de conocimientos. Éste será actualizado después de cada tarea. Las actualizaciones se reflejan en la interfaz por el color de los iconos que acompañan a cada concepto del árbol curricular: el rojo, indica que el alumno no está preparado para abordar el aprendizaje de un concepto; el color verde quiere decir que el alumno tiene los conocimientos suficientes para empezar a aprender el concepto y el azul significa que el sistema cree que el alumno ya ha aprendido el concepto.

A pesar de que MEDEA permite a los alumnos ignorar las indicaciones del sistema y seguir su propio camino durante la instrucción, todas sus acciones están supeditadas a la estrategia global establecida por el profesor durante el proceso de construcción del entorno. Estas directrices se reflejan en:

1. El alumno sólo podrá usar aquellos recursos de instrucción que hayan sido integrados como parte del entorno, independientemente de los que estén disponibles en el marco de trabajo.

2. Cada concepto tendrá asociada una lista de recursos. Esta lista estará compuesta por aquellos recursos para los que el profesor ha establecido un vínculo entre un concepto de su dominio y el susodicho. Los alumnos que deseen estudiar este concepto sólo podrán realizar una tarea de las que aparecen en esa lista.

Capítulo 7

3. El diseño del entorno, principalmente el dominio y los recursos seleccionados por el profesor, pueden marcar implícitamente un estilo de enseñanza (aprendizaje basado en problemas, en casos, por exploración, etc.) tal y como se explicó en el apartado 7.1.5.

4. Cada recurso de instrucción inteligente es responsable de su material didáctico y de la forma en que se presenta, es decir, cada uno implementa sus propias estrategias de enseñanza. Es responsabilidad del profesor elegir los más adecuados.

El conocimiento de instrucción aportado por el profesor durante la construcción del WILE influirá en mayor medida en el grado de satisfacción del alumno que las estrategias de planificación del núcleo, dado que estas sólo proporcionan ayuda y guía.

7.4 Conclusiones

El capítulo anterior describe la implementación de las capas 0 y 1 de un marco de trabajo basado en la metodología de desarrollo propuesta en el Capítulo 5. Estas capas se corresponden con la funcionalidad básica de un STI (modelo del dominio, del alumno y módulo instructor) y un conjunto de recursos de instrucción (aplicaciones educativas externas que se integran como parte del marco de trabajo). Estos elementos constituyen la base sobre la que el profesor, siguiendo el protocolo de actuación establecido en la capa 2 de la metodología, podrá construir un entorno inteligente de aprendizaje para la web. En este capítulo se ha descrito este proceso y, haciendo uso de los elementos implementados, se han construido dos entornos de aprendizaje para los dominios de Lógica y Economía Agraria.

El desarrollo de estos sistemas pone de manifiesto que la metodología es aplicable a un amplio rango de dominios. El modelo del dominio se estructura como un conjunto de conceptos. El marco de trabajo especifica como se van a describir estos conceptos (atributos) y las relaciones que se pueden establecer entre ellos. En el marco implementado para esta tesis se han definido relaciones muy genéricas (es_un, parte_de, prerrequisito y pertenece_a) aplicables a la mayoría de los dominios. La inclusión de relaciones más especificas, no limita el espectro de dominios, por el contrario, lo amplía. Aunque existan algunas relaciones imprescindibles para modelar ciertos dominios, para la mayoría este factor no es determinante. En efecto, el marco de trabajo es lo suficientemente flexible como para permitir modelar no sólo modelos declarativos (como los de Lógica y Economía Agraria), sino también habilidades o procedimientos. Para describir, por ejemplo, algún experimento de laboratorio (químico, físico, etc.) bastaría con identificar las acciones que el alumno debe conocer para poder desarrollar el experimento. Cada una de ellas sería considerada un concepto y, mediante la relación de prerrequisitos, podría establecerse la secuencia de acciones correcta para alcanzar el objetivo. Cualquier dominio susceptible de descomponerse en unidades de conocimiento podría usarse para construir un WILE siguiendo nuestra metodología de desarrollo. En última instancia el grado de generalidad depende del marco de trabajo que se implemente.

194


195

Uno de los objetivos marcados al comienzo de esta tesis era proporcionar una solución viable a uno de los principales escollos en la construcción de sistemas educativos inteligentes: su elevado coste de desarrollo. En efecto, y según se deduce de la revisión realizada en los Capítulo 2 y Capítulo 3, la mayoría de aplicaciones educativas inteligentes se construyen desde cero e implican a numerosos desarrolladores, muchos de ellos técnicos que intentan aplicar los conocimientos proporcionados por los docentes y los expertos en el dominio. Para paliar estos inconvenientes la metodología propuesta en esta tesis aboga por la reutilización de sistemas ya construidos como medio para permitir a) reducir los costes de creación de material e implementación de estrategias educativas y b) la construcción de WILE por personal no especializado. Tomando como ejemplo el desarrollo de los WILE de Lógica y Economía Agraria podemos avanzar que el marco de trabajo proporciona a los docentes la posibilidad de aplicar sus conocimientos en la construcción de entornos de enseñanza sin necesidad de apoyarse en personal técnico alguno, y a los técnicos poner a disposición de los docentes herramientas existentes de modo que puedan ser reutilizadas en nuevos entornos de aprendizaje. En el capítulo siguiente se ahonda en esta cuestión mediante la presentación de algunas pruebas que arrojan resultados clarificadores.

La reutilización de código proporciona ventajas que atañen no sólo al proceso de desarrollo, sino también al resultado desde el punto de vista del alumno. Es evidente que la posibilidad de usar otras herramientas, incrementa la riqueza del entorno y permite aprovechar sistemas existentes acerca de un dominio que han sido desarrollados ad hoc y que representan un compendio del conocimiento de numerosos expertos.

Para la construcción de los WILE de Lógica y Economía Agraria se ha usado el marco de trabajo descrito en el capítulo anterior. Éste proporciona un conjunto de estrategias de planificación y métodos para la gestión de los modelos del alumno y del dominio y un conjunto de recursos de instrucción. De la implementación de estos elementos, así como del uso que de los mismos haga el profesor, depende la eficacia del entorno de aprendizaje desde el punto de vista del alumno. Por lo tanto la evaluación de cuestiones que atañen a la capacidad pedagógica de los WILE desarrollados depende de cada uno en particular y escapa al interés general de este trabajo.

Capítulo 8 PRUEBAS Y EVALUACIÓN DE LA PROPUESTA

La propuesta presentada en esta tesis para el desarrollo de entornos inteligentes de aprendizaje sobre la web (WILE) consta de 1) una metodología de desarrollo estructurada en cuatro etapas, según los distintos actores que intervienen en el proceso de construcción de un WILE (desde el desarrollo de los elementos básicos de un sistema inteligente hasta el propio proceso de aprendizaje) y 2) un marco de trabajo que sustenta todos los elementos y procedimientos definidos en la metodología.

Este capítulo se centra en la evaluación de esta propuesta, cuya finalidad es valorar el grado de satisfacción en el cumplimiento de los objetivos marcados al principio de este trabajo.

8.1 Introducción al proceso de evaluación de MEDEA

Una evaluación es un proceso por el cual se recogen datos y se transforman en información para la toma de decisiones (Cooley and Lohnes, 1976). Un gran número de autores defienden la distinción que Scriven (Scriven, 1967) hace entre evaluación formativa y sumativa (Ainsworth et al., 1999; Barros, 1999; Guzmán, 2005; Mark and Greer, 1993; Shute and Regian, 1993).

La evaluación formativa se centra en el diseño del sistema y su objetivo principal es detectar problemas y realizar las modificaciones necesarias para solventarlos a lo largo del proceso de desarrollo, en definitiva, mejorar el funcionamiento del sistema y asegurar que el resultado final cumple con los requisitos de diseño. La evaluación sumativa se orienta al resultado final y trata de probar algún aspecto formal del sistema. Según (Littman and Soloway, 1988), la evaluación formativa se enfrenta a la pregunta: “¿Cuál es la relación entre la arquitectura del sistema y su comportamiento?”, mientras que la sumativa trata de responder: “¿Cuál es el impacto educativo del sistema en el alumno?”.

Las técnicas formales se usan habitualmente en evaluaciones sumativas, mientras que las informales se suelen asociar a las formativas. En (Twidale, 1993) y en (Ainsworth, 2005) se apuntan numerosas razones por las que es

196

Pruebas y evaluación de la propuesta

197

deseable desarrollar evaluaciones formales de los sistemas. Destaca el hecho de contar con medidas objetivas relativas a la efectividad del sistema, lo que se ajusta al paradigma científico de objetividad y reproducibilidad. Ainsworth señala razones como incrementar la aceptación del usuario, comparar sistemas alternativos, mejorar la eficiencia o vender el sistema, entre otras. Ambos autores destacan el hecho de que las evaluaciones formales contribuyen al desarrollo del campo de investigación.

Sin embargo, no en todos los casos es viable el desarrollo de una evaluación sumativa. En (Twidale, 1993) se analizan algunos de sus inconvenientes. En primer lugar una evaluación está condicionada por los objetivos marcados y por los recursos disponibles. En efecto, un experimento formal sólo mide un número pequeño de variables independientes y en un sistema educativo existen numerosos ítem susceptibles de ser evaluados, en su mayoría variables dependientes. También hay que tener en cuenta que es habitual que la acción de dos o más variables causen un efecto superior a la suma de los efectos individuales (sinergia).

Por otro lado, un experimento formal consume numerosos recursos. Es necesario contar con un número suficiente de sujetos con los conocimientos adecuados y con un equipo de trabajo multidisciplinar capaz de lleva a cabo los experimentos que, además, suelen prolongarse en el tiempo. Esto obliga en ocasiones a plantear la evaluación como un proyecto independiente del desarrollo.

Uno de los motivos que justifican en parte la escasez de evaluaciones sumativas entre los sistemas educativos es la rápida evolución del hardware y el software. Si el proceso de evaluación es demasiado largo puede que para cuando acabe el sistema esté ya obsoleto debido a la aparición de nuevas tecnologías capaces de mejorar algunos de los aspectos que estaban sometidos a evaluación.

La aplicación de técnicas informales de evaluación es una buena alternativa para obtener datos que ayuden a entender el sistema y a mejorar ciertos aspectos del mismo. Las principales ventajas de usar técnicas informales son su rapidez y simplicidad.

Ainsworth propone organizar el proceso de evaluación de un sistema del siguiente modo (Ainsworth, 2005): 1) determinar para qué se va a usar la información obtenida y según eso decidir si procede realizar evaluación formativa o sumativa; 2) determinar las variables dependientes que se van a medir (ganancia en el aprendizaje, eficiencia o velocidad de aprendizaje, características del sistema usadas en la práctica, ahorro de costes, etc.); 3) elegir un método de evaluación adecuado para nuestros objetivos; 4) diseñar los experimentos; 5) determinar el modelo de comparación que se va a usar, es decir, cómo y con qué se va a comparar nuestro sistema y 6) elegir el contexto de las pruebas, que puede variar en diferentes grados desde el laboratorio hasta un entorno real de uso. Siguiendo este esquema la evaluación de MEDEA se plantea del siguiente modo:

Capítulo 8

1. Tipo de evaluación

Teniendo en cuenta que el interés de este trabajo se centra en el proceso de desarrollo y no en el de aprendizaje, la construcción del marco de trabajo de MEDEA responde al intento de arrojar luz a las siguientes cuestiones relativas a la construcción de entornos inteligentes de aprendizaje:

¿Es posible sistematizar el proceso de construcción de un WILE?

¿Podría ser llevado a cabo por docentes sin un perfil técnico?

¿Se pueden reutilizar tanto el material como la “inteligencia” de otros sistemas?

En caso afirmativo, ¿cómo debería llevarse a cabo el proceso de integración?, ¿qué coste de implementación conlleva?

La información obtenida en la evaluación se empleará para refinar el diseño del marco de trabajo hasta conseguir que se aproxime lo máximo posible a los objetivos iniciales, por lo tanto se realizará una evaluación formativa.

2. Variables que se van a observar

La evaluación de marcos de trabajo y/o herramientas de autor presenta algunas particularidades respecto a los entornos de aprendizaje convencionales. Estos sistemas pueden ser evaluados desde la perspectiva del alumno, desde la del profesor y desde la de los técnicos, variando en cada caso el conjunto de parámetros observables. Criterios como la diversidad de dominios, los estilos de enseñanza que abarque o la facilidad para la reutilización de material son relevantes para el docente. La rapidez y flexibilidad en la reutilización, modificación e integración de recursos externos serán importantes para los técnicos. Para los alumnos, las principales cuestiones son las relacionadas con la eficacia del aprendizaje. Como se ha apuntado anteriormente este trabajo se centra en el proceso de desarrollo y su evaluación se centra en los siguientes aspectos:

- Carácter distribuido de los WILE generados.

- Versatilidad.

- Rango de dominios abordable.

- Reutilización de sistemas

Completos (conocimiento y funcionalidad).

Heterogéneos (de distinta naturaleza y procedencia).

Abierta (procesos de inserción y eliminación dinámicos).

- Costes de desarrollo de los WILE. Los WILE de Lógica y Economía Agraria descritos en el Capítulo 7, ponen de manifiesto el cumplimiento de algunos de los objetivos enumerados en este epígrafe. En efecto, los WILE generados son sistemas distribuidos referentes a dominios dispares que reutilizan dos sistemas inteligentes SIGUE y SIETTE. El proceso de integración descrito en el apartado 6.2 pone

198


199

de relieve cómo el marco de trabajo permite reutilizar sistemáticamente sistemas educativos completos, siempre que se ajusten a las especificaciones dadas por la metodología.

3. Método de evaluación

Existen distintos métodos de evaluación aplicables a los sistemas de aprendizaje. En (Mark and Greer, 1993), los autores realizan una interesante recopilación, que incluye algunos de los mas usados en los campos de los sistemas expertos, la educación y la psicología, determinando la aplicabilidad de los mismos a los STI y el tipo de evaluación (formativa o sumativa) al que se ajustan mejor. Según esto, las técnicas más adecuadas para la evaluación formativa de STI completos o de algunos de sus componentes consisten en observar el comportamiento de sujetos representativos del grupo potencial de usuarios reales del sistema para detectar posibles problemas (Pilot Testing). El método de evaluación usado para MEDEA se basa en las evaluaciones de los sistemas DEGREE (aprendizaje colaborativo) (Barros, 1999; Barros and Verdejo, 2001) y SIETTE (test adaptativos) (Guzmán, 2005), que ponen en práctica las recomendaciones de Murray (Murray, 1993) para el diseño de sistemas educativos inteligentes:

- Diseño iterativo: partiendo de un prototipo inicial la funcionalidad del sistema se va probando y refinando en sucesivas iteraciones.

- Diseño participativo: con el fin de asegurar que el sistema resultante sea utilizable se involucra a los usuarios en su desarrollo.

- En contraposición al enfoque cuantitativo de la evaluación, que intenta encontrar las causas y las consecuencias de las características del sistema, se ha realizado un enfoque cualitativo, tratando simplemente de identificar esas características. Para ello se documentan todos los cambios realizados en cada una de las iteraciones del diseño: las motivaciones de esos cambios, los resultados y cualquier otro aspecto encontrado durante el estudio.

4. Diseño de los experimentos

En cada uno de los ciclos de diseño se ha construido un prototipo basado en los resultados de la evaluación del anterior. En cada fase los experimentos han estado orientados a probar un aspecto diferente del sistema, siempre teniendo presentes los objetivos generales del punto 2. En el epígrafe 8.2 se describen cada uno de los prototipos construidos y los experimentos realizados.

5. Modelo de comparación

Uno de las cuestiones más recurrentes en el campo de los sistemas educativos es probar las ventajas del aprendizaje por computador frente a los métodos tradicionales de enseñanza. Los experimentos más habituales consisten en analizar el comportamiento de alumnos que aprenden un determinado dominio, unos en clase y otros usando el sistema. En

Capítulo 8

ocasiones se cruzan algunos alumnos de uno y otro grupo a lo largo del proceso de aprendizaje. Es habitual también establecer comparaciones con otros entornos de similares características. En el caso de MEDEA el interés se centra en determinar si la metodología de desarrollo propuesta en el Capítulo 5 mejora sustancialmente la construcción de sistemas ad hoc para un dominio concreto. En este caso los sujetos de los experimentos serían técnicos y docentes. Idealmente y por analogía con lo expuesto anteriormente, los experimentos deberían consistir en establecer distintos grupos que construyeran el mismo sistema unos usando MEDEA y otros por sus propios medios y analizar todo el proceso. El tiempo necesario para su desarrollo y la escasez de herramientas de autor similares disponibles hacen muy difícil poner en práctica estas ideas. Sin embargo se ha considerado de interés comparar un sistema ya construido con otro de características similares construido usando MEDEA. Este proceso se ilustra el epígrafe 8.3.

6. Contexto de las pruebas

Las pruebas han sido llevadas a cabo en el laboratorio con sujetos reales.

8.2 Ciclos de desarrollo del marco de trabajo

En los siguientes apartados se van a describir en detalle los distintos prototipos del marco de trabajo de MEDEA así como los experimentos que se realizaron con cada uno de ellos y los resultados obtenidos.

8.2.1 Primer prototipo

El primer prototipo del marco de trabajo contiene los elementos principales del núcleo: planificador de instrucción, modelo del dominio y modelo del alumno y se corresponde con la implementación de la capa 0 de la metodología. Este prototipo se construye basándose en una arquitectura inicial (Trella et al., 2000) en la que se han identificado todos los elementos de un STI pero para la que aún no se ha definido cómo se va a realizar la integración de los RI (llamados componentes tutoriales en las primeras versiones).

La planificación se plantea en dos etapas de microadaptación (selección de un concepto del currículum y de una tarea) y macroadaptación (selección del material adecuado). En este primer prototipo sólo se incluye la fase de secuenciación del currículum.

El modelo del domino se definió desde el principio como un conjunto de conceptos. Cada concepto tenía asociado un nombre y una nota de corte. Una vez superada esta nota el concepto se considera aprendido. Se incluyeron las relaciones de prerrequisito y de subtema (o pertenece_a) y es_un. Las dos primeras son usadas por el planificador para secuenciar el currículo. Se definió un conjunto de etiquetas XML para la definición de dominios. Para la construcción de este modelo se exploró el dominio de la morfología de especies forestales. Este es un dominio declarativo jerárquico que se puede generalizar para

200


201

muchos campos que utilizan taxonomías de clasificación en varios niveles (geología, otras especies animales y vegetales,...).

El modelo del alumno, de una sola capa, contenía un conjunto de conceptos con un valor asociado entre 0 y 1. De forma análoga al dominio se definió un conjunto de etiquetas XML para su representación.

En este prototipo se usa una rudimentaria interfaz para el alumno que permite hacer el seguimiento del planificador pero sin contenidos (aun no se pueden integrar recursos) y, por lo tanto, el alumno no puede hacer actividades ni acceder a ningún tipo de material. El modo de interactuar con el sistema es a través de un applet que muestra de forma gráfica la jerarquía de temas del currículum y que va marcando los distintos conceptos según su estado en el modelo del alumno (superado, puede ser estudiado, no debe ser estudiado aún y recomendado).

En lo referente a la implementación, la funcionalidad del sistema se desarrolló en Java mientras que los datos acerca de los dominios y los alumnos se guardan en ficheros XML. Se desarrolló una arquitectura cliente/servidor en la que la planificación se realizaba en el applet del cliente.

Objetivos de los experimentos

Observar el correcto comportamiento del núcleo teniendo en cuenta que el marco de trabajo es un ejemplo de implementación desarrollado para probar una metodología. Según esto, los datos obtenidos en los experimentos no van encaminados al desarrollo de estrategias de planificación óptimas, se trata de obtener un núcleo que se ajuste en líneas generales a lo que un profesor humano haría, atendiéndose más a los aspectos relacionados con la interoperabilidad y comunicación con los futuros recursos que se añadirán al marco de trabajo.

Comprobar si los modelos del alumno y del dominio contienen información suficiente para poder realizar una instrucción adecuada ya que, al tener siempre presente el objetivo de la integración, desde un principio se intentó definir modelos lo más simples y genéricos posible.

Experimentos realizados

Para evaluar este prototipo se contó con dos profesores de Lógica. El experimento consistió en desarrollar el currículum de una asignatura de Lógica de primer curso usando los atributos y relaciones permitidas en el dominio. Sus conocimientos informáticos llegaban a nivel de usuario por lo que un técnico se encargó de transcribir su representación al lenguaje creado para tal propósito.

Una vez creado el dominio los profesores debían supervisar la planificación del sistema. Su tarea consistió en observar las recomendaciones del planificador dados distintos modelos del alumno, que se iban modificando manualmente.

Capítulo 8

Resultados

Tras realizar las pruebas pertinentes los profesores elaboraron un informe. De él se extrajeron las siguientes conclusiones:

Una de las principales dudas respecto al modelo del dominio era si las relaciones definidas serían suficientes para representar dominios heterogéneos. El experimento reveló que los profesores en el proceso de modelado no tienen en cuenta la naturaleza del dominio sino el fin último de éste que es la instrucción. Así, los profesores tienden a establecer para el currículum una estructura jerárquica de temas-subtemas propia de la enseñanza tradicional y una red paralela de prerrequisitos que, en el caso del dominio de Lógica, determinaba tres recorridos principales alternativos a través del currículum.

Son necesarias herramientas para crear y editar los modelos del dominio y del alumno.

Los profesores expresaron el deseo de poder definir personalmente la escala de medición para cada concepto sin tener que ceñirse a un intervalo real entre 0 y 1.

La planificación resultó bastante simple. El planificador seguía la jerarquía del currículum de forma descendente y comprobaba que los requisitos hubiesen sido superados. Uno de los profesores hizo notar que, dado que el sistema da libertad de navegación, aunque el alumno sistemáticamente evitara un concepto el planificador insistía en recomendar siempre el mismo entrando en un bucle a partir del cuál el alumno se quedaba sin guía.

Las principales críticas iban dirigidas a la interfaz. La navegación resultaba excesivamente lenta y el seguimiento normal de una sesión prácticamente imposible. Esto es debido a que el alumno interactúa a través de un applet y la planificación se realiza en el cliente, por lo que se cargan numerosas clases además de los modelos del dominio y del alumno. Las actualizaciones de los ficheros XML de los clientes estaban sujetas a las restricciones de seguridad del applet produciendo algunas inconsistencias entre los datos almacenados en el cliente y en el servidor.

8.2.2 Segundo prototipo

En este segundo prototipo se intentaron mejorar las deficiencias observadas en el primero, para lo que:

Se intentó solucionar el problema de la interfaz estableciendo una arquitectura cliente/servidor basada en un modelo en tres capas: (1) un applet Java se carga en el navegador del cliente y se comunica con (2) un servlet que corre en la máquina servidora. El servlet actualiza los (3) ficheros XML directamente en el servidor.

Se crea una nueva versión del planificador aplicándose los siguientes criterios: a) el concepto seleccionado por el planificador debe circunscribirse al tema que esté estudiando el alumno para evitar oscilaciones entre temas

202


203

muy dispares; b) se debe insistir en un concepto sólo si el alumno está a punto de alcanzar el mínimo exigido para superar el concepto y c) se debe tener en cuenta el interés que el alumno haya demostrado sobre un determinado concepto, de modo que, si lo ha evitado en varias ocasiones el sistema trate de centrar el interés del alumno en otra parte del currículum.

Se incluyen en el modelo del dominio los atributos dificultad y tipo de evaluación. El sistema da la posibilidad al profesor de establecer un intervalo real o un rango enumerado como escala para medir el nivel de conocimiento.

Además de solucionar los problemas detectados, se intenta mejorar la gestión del modelo del alumno, prácticamente inexistente en el primer prototipo. MEDEA se limita a copiar en su modelo del alumno los resultados de cada tarea, por lo que, conceptos aprobados en alguna ocasión pasan a estar suspensos más adelante. Se introduce el concepto de modelo multi-nivel (multilayered approach). Se define un nuevo modelo de conocimientos en cuatro capas y dos tipos principales de recursos: de diagnóstico y estimativos. Los primeros emplean técnicas formales para el diagnóstico del alumno y los segundos se basan en heurístico para determinar sus niveles de conocimiento. Dos de los niveles se hacen corresponder con cada uno de los tipos de recursos de modo que unos actualizaran el primer nivel y los otros el segundo. Las otras dos capas realizan inferencias sobre el nivel de conocimientos de los alumnos basándose en sendas redes bayesianas que modelan las relaciones de prerrequisito y pertenece_a.


Probar si los nuevos criterios de planificación resolvían el problema del bloqueo en un concepto.

Probar el funcionamiento de la nueva interfaz y, en general, de la nueva arquitectura del sistema.


En esta fase se incorpora al grupo de pruebas un becario de último curso. Dado que no se le ha añadido ningún elemento nuevo al sistema se repiten los experimentos llevados a cabo con el primer prototipo.

Resultados

Las deficiencias señaladas en el primer prototipo en relación con el modelo del dominio son superadas estableciéndose su estructura como definitiva. Los profesores solicitan de nuevo una herramienta visual para poder crear y modificar sus dominios sin tener que solicitar la ayuda de un técnico.

Respecto a la nueva versión del planificador los usuarios consideran que teniendo en cuenta su carácter genérico (debe ser válido para un amplio rango de dominios) la secuenciación del currículum es aceptable.

Capítulo 8

La interfaz ha mejorado sustancialmente y aunque el peso del procesamiento recae ahora en el servidor sigue siendo lenta y entorpece bastante el seguimiento del curso.

8.2.3 Tercer prototipo

Los dos prototipos anteriores se corresponden con la implementación de la capa 0. Lo que procede en este tercer prototipo es abordar la cuestión de la integración de sistemas (capa 1). Una vez conseguido, el docente contará con la infraestructura necesaria para construir sus propios entornos de aprendizaje. Para ello se estudia el proceso de instrucción establecido por la metodología con el fin de identificar los puntos de comunicación entre los elementos del núcleo y los recursos de instrucción para poder determinar el protocolo de comunicación.

Modelo del alumno

Modelo del dominio

Recursos de iinstrucción

Macroadaptación (Recurso)

1) Enseña el concepto seleccionado Actualización del modelo del

alumno (

Microadaptación (Planificador)

1) Selección de un concepto2) Selección de un componente

CICLO DE INSTRUCCIÓN

Se invoca a un recurso

Se devuelve el resultado

(alumno, concepto)

(alumno, notas)

Fig. 51 Ciclo de instrucción en MEDEA.

Una vez identificada la secuencia de llamadas y los parámetros de las mismas se estudian las distintas opciones de implementación. Dado que la implementación está en Java, se contempla la posibilidad de hacerlo con RMI. Los principales inconvenientes de esta opción son que se limita la naturaleza de los recursos a programas Java y que no se puede hacer una integración totalmente independiente ya que el cliente de los recursos (en este caso el núcleo de MEDEA) necesitaría, por cada recurso que se integrara, instalar algunas clases (stubs y skeletons) en su máquina. El objetivo es que aquellos usuarios que deseen integrar sus recursos en MEDEA puedan hacerlo por sí solos y sin necesidad de contar con los desarrolladores del marco de trabajo, es decir, que no sea necesario ni recompilar ningún módulo de MEDEA ni instalar ninguna clase en el servidor.

La opción para lograr una integración dinámica y lo más estándar y genérica posible pasa por usar HTTP. Para ello se define un protocolo específico de comunicación en el que los comandos se invocan a través de URL. Asimismo se crea un lenguaje propio para la definición de los recursos que permita describir las direcciones, parámetros y demás datos necesarios para localizar y ejecutar un recurso. Este lenguaje está basado en XML de modo que los elementos del núcleo de MEDEA puedan componer en tiempo de ejecución la

204


205

llamada para la invocación a un recurso a partir de la información contenida en su descripción. Se decide centralizar en una clase (Gestor de comunicaciones) todas las ejecuciones de comandos del protocolo (llamadas a diversos servicios de los recursos).


Comprobar si la integración de programas externos en el marco de trabajo es factible.

Determinar el grado de acoplamiento con los elementos del núcleo.

Comprobar si los servicios (API) exigidos a cada recurso son suficientes para llevar a cabo un proceso de instrucción.

Averiguar el tiempo y esfuerzo que un técnico no familiarizado con la implementación del núcleo debe realizar para integrar un componente.

Observar el proceso de construcción de un WILE a partir de un conjunto de recursos previamente integrados. Comprobar si, tal y como se espera, un docente con unos conocimientos a nivel de usuario, es capaz de construir su propio entorno sin necesidad de contar con la ayuda de un técnico.


La evaluación de este prototipo se centra en la integración de recursos educativos externos. Para ello es necesario contar con algunos sistemas que integrar y con material docente. Se eligen dos sistemas desarrollados en el seno del grupo de investigación que han sido usados en algunas asignaturas y que cubren la funcionalidad básica de un entorno de aprendizaje: páginas de teoría y un mecanismo de evaluación. El experimento consiste en crear material docente para cada una de estas herramientas (SIGUE y SIETTE) e integrarlas en el dominio de Lógica ya creado. Para probar la integración es necesario crear un entorno de aprendizaje completo que pueda ser usado.

El diseño del experimento se ciñe a las fases de la metodología. Para ello es necesario contar con al menos una persona que se ajuste a cada uno de los perfiles o actores que se identifican en la metodología. Según esto se constituye un grupo de usuarios compuesto por:

Un técnico que se encarga de implementar los servicios mínimos exigidos por la metodología y de integrar SIGUE y SIETTE proporcionando las descripción funcional de cada uno de ellos. Esta descripción es un fichero XML escrito en el lenguaje de definición creado para tal propósito.

Un profesor de Lógica de la Universidad de Málaga y una alumna de Filosofía de último curso que asumen el rol de profesor. La alumna será la encargada de introducir el material necesario bajo la supervisión del profesor. Éste crea dos nuevos dominios de Lógica uno para SIGUE y otro para SIETTE. Se le pide al profesor que estos dominios presenten diferencias con el definido para MEDEA con el fin de que el experimento se aproxime lo máximo posible a una situación real en la que un profesor construye un

Capítulo 8

entorno de programación reutilizando material creado por otros profesores para otros sistemas. Para completar la creación del WILE debe establecer las correspondencias entre los dominios. El resultado se describe en detalle en 7.2.1.

Dos alumnos de proyecto fin de carrera que usarán los WILE creados por el profesor.

Resultados

El resultado más inmediato es la necesidad de crear una interfaz web para que cada uno de los actores pueda realizar su tarea sin necesidad de que el técnico responsable de MEDEA deba estar recopilando el trabajo de cada uno y poniendo esta información en el directorio adecuado del servidor para que todo funcione.

Las deficiencias detectadas por los distintos actores participantes en el experimento fueron:

Técnicos:

- Para integrar un recurso es necesario aprender el lenguaje de descripción. Con el fin de hacer esta tarea más asequible sería necesario crear una herramienta que obtenga del técnico los datos necesarios a través de formularios web y genere de forma automática la descripción del recurso. Aparte de estas consideraciones relacionadas con el marco de trabajo no se hace ninguna reseña al proceso de integración tal y como está descrito en la metodología.

- Al ser interrogados por la dificultad en la programación del API o conjuntos de servicios de SIGUE y SIETTE se observa que:

o Algunos de los métodos necesarios ya estaban construidos. Cómo las llamadas se hacían a través de HTTP fue necesario implementar servlets que sirvieran de puente entre MEDEA y las clases correspondientes de cada aplicación.

o Fue necesario duplicar métodos que ya existían sólo para cambiarles su nombre y el de sus parámetros por los nombres establecidos por MEDEA. Tras hacer esta observación se convino en añadir al lenguaje de descripción etiquetas para que estos datos fuesen configurables.

- Aparte de los detalles de funcionamiento necesarios para establecer la comunicación con el núcleo, no es posible dar una descripción del recurso a más alto nivel que haga referencia a sus características pedagógicas, por ejemplo, el modo en el que se comunica con el alumno, el tipo de tarea que realiza, el material didáctico que contiene, etc.

Profesores:

- El profesor señala la rigidez del sistema que no permite ningún tipo de adaptación de los recursos. El profesor señala que le hubiese gustado

206


207

poder configurar la herramienta de tests con unas características distintas según el nivel de conocimiento inicial del alumno y del curso. Tal y como está el sistema las tareas que se asocian a un concepto son las mismas para todos los alumnos. Al profesor le hubiese gustado poder asignar tareas distintas según el perfil de cada alumno.

Alumnos:

- Los alumnos señalan los mismos problemas en la interfaz que ya habían sido detectados en el prototipo anterior y que aun no han sido corregidos.

8.2.4 Cuarto prototipo

Podría decirse que este es el prototipo de la “estandarización”. A lo largo de los últimos años y en paralelo con el desarrollo de MEDEA el interés por la creación de estándares internacionales para la educación ha ido en aumento.

El estándar más ampliamente usado por la comunidad educativa internacional es LOM. La definición del modelo de tatos LOM fue publicada en 2002 por IEEE. Su propósito es facilitar la búsqueda, evaluación, adquisición y uso de objetos de aprendizaje (LO). Los LO se definen como entidades, digitales o no, que pueden ser usadas, reutilizadas o referenciadas durante un proceso de aprendizaje. Sin embargo, su estudio nos reveló que tanto LOM como la mayoría de los estándares desarrollados por organizaciones internacionales están enfocados a sistemas de gestión de cursos convencionales (no inteligentes) y, por lo tanto, carecen de la expresividad suficiente para adoptarlos de una forma plena en el desarrollo de WILE.

En MEDEA los recursos son los elementos equivalentes a los LO y la descripción funcional se correspondería con los “datos de los datos” definidos por la IEEE (Learning Object Metadata), por lo tanto se aplicaron algunos de los campos definidos en el estándar LOM a la descripción de un recurso (ver 5.3.3.1). De este modo se cubría en parte la carencia señalada por los técnicos en el sentido de poder describir un recurso más allá de los parámetros de ejecución.

Otro cambio importante fue sustituir el lenguaje de definición del dominio propio de MEDEA por un lenguaje para la definición de ontologías de primer nivel. El elegido fue OXML. Se construyó DOM-EDIT, una herramienta gráfica para la edición de dominios que genera ficheros OXML a partir de un grafo de conceptos.

Una de las novedades más importantes en esta fase del diseño fue la incorporación de la tecnología de servicios web. Los recursos se definen como servicios web, empleándose para las llamadas a métodos remotos el protocolo SOAP sobre HTTP. Asimismo se desplaza el lenguaje creado para la descripción de recursos para MEDEA en favor de WSDL (Web Services Description Lenguage).

Capítulo 8

Además de estas nuevas características, se intentan mejorar los aspectos negativos puestos al descubierto por la evaluación del anterior. Estos cambios afectan también a la metodología. Se revisa el protocolo de actuación del profesor. Se añade el paso Adaptación de las tareas a los perfiles del alumno.

Se habilitan páginas web para las tareas de integración de recursos y para la creación de WILE. Con estas interfaces y DOM-EDIT se elimina la manipulación manual de ficheros.


Comprobar si la adopción de los servicios web como tecnología de software distribuido mejora el proceso de integración.

Probar la nueva herramienta de edición de dominios.

Comprobar si la adaptación de los recursos mejora sustancialmente el resultado de los WILE generados.

Probar si con las nuevas interfaces el docente es capaz de desarrollar un WILE sin ayuda de un técnico.


El grueso de los experimentos coincide con los realizados en la fase anterior. El interés sigue centrado en el proceso de integración. Se vuelven a implementar las APIS de SIGUE y SIETTE y se despliegan como servicios web. Se proporciona para cada una el fichero WSDL correspondiente.

A partir de aquí, los mismos usuarios que participaron en la etapa anterior realizan las mismas tareas. El modo en el que las comunicaciones con los recursos estén implementados debe ser transparente al docente. Dado que el material ya está creado su trabajo consiste en repetir los pasos establecidos en la metodología para la creación de WILE, incluyendo la nueva tarea de adaptar el recurso a los perfiles del alumno.

Dado que ni la interfaz de usuario, ni el material, ni el planificador han sido modificados los alumnos no intervienen en esta fase.

Resultados

El proceso de integración se agiliza ya que los métodos de los recursos se pueden invocar directamente (RPC) y no es necesario crear servlets o cualquier otro tipo de scripts para ejecutarlos a través de HTTP. El uso de un lenguaje especialmente creado para la descripción de servicios (WSDL) facilita la tarea de obtener y organizar los datos necesarios para la ejecución de recursos. Del mismo modo la existencia de librerías que implementan SOAP (en nuestro caso AXIS de Apache) y de otras capaces de invocar un servicio en tiempo de ejecución a partir de su descripción WSDL (WSIF, también de Apache) simplifican bastante el Gestor de comunicaciones.

El éxito de la adaptación de los recursos al usuario depende de la calidad de la descripción, tanto semántica como del significado de sus parámetros, que el integrador haya hecho. En efecto, al intentar los profesores configurar un

208


209

determinado modo de ejecución para un recurso se encontraron con que los técnicos tan sólo proporcionaban el nombre de cada uno y un conjunto de posibles valores. Se le pidió a los técnicos que proporcionaran descripciones exhaustivas de cada parámetro así como el significado de cada uno de los valores que ese podía tomar. Una vez hecho esto, los profesores se animaron a fijar el valor de algunos parámetros de ejecución sobre todo del sistema SIETTE.

8.2.5 Quinto prototipo

Este prototipo trata de mejorar el aspecto del sistema más criticado desde las primeras versiones: la interfaz del alumno. Para ello se elimina el applet que mostraba el árbol curricular y se sustituye por una marco que contiene una página JSP con un árbol de conceptos. De cada nodo del árbol se cuelgan las tareas que el profesor ha elegido para trabajar ese concepto de modo que el alumno tenga toda la información accesible a un golpe de vista.

Objetivo de los experimentos

El único objetivo de este experimento fue valorar la nueva interfaz.


Un grupo de tres alumnos trabajó durante varios días sobre el curso de Lógica.

Resultados

Los alumnos, que no fueron instruidos sobre el uso del sistema no encontraron ningún problema en navegar a través del material. Destacaron como ventaja poder acceder a SIETTE y a SIGUE desde la misma interfaz y poder usarlas como parte de un mismo curso sin tener que abrir ventanas aparte y conectarse en cada sistema por separado.

8.3 Comparación TEA / TEA-MEDEA

Se ha considerado de interés comparar la metodología de desarrollo basada en MEDEA con el proceso de construcción de un sistema ad hoc. Para ello se ha construido, usando MEDEA, un sistema con el mismo material que el sistema TEA (Belmonte et al., 1996), un sistema educativo “no inteligente” para la web sobre el dominio de Economía Agraria. Se ha analizado la funcionalidad de los sistemas construidos y realizando una medida aproximada de los costes de desarrollo.

8.3.1 Funcionalidad

TEA es un sistema educativo “no inteligente” para la web, formado por un libro electrónico y un test para cada tema. No posee capacidad de adaptación al usuario, tan sólo proporciona ayuda a la navegación por medio de hiperenlaces a partes relacionadas del currículum.

Para suplir estas carencias y convertirlo en un sistema “inteligente” se utilizó el mismo material para construir un curso teórico con el sistema SIGUE y

Capítulo 8

un conjunto de tests adaptativos con la herramienta SIETTE. De este modo se consiguió una navegación guiada a través de los contenidos basándose en la gestión del alumno de SIGUE y una evaluación del nivel de conocimiento según los métodos de estimación del sistema SIETTE. Además SIETTE ofrece una amplia variedad de tipos de preguntas (respuesta libre, múltiple, única, etc.) frente a las preguntas de respuesta única de TEA.

El resultado de este nuevo enfoque es que el alumno dispone de dos herramientas independientes para el aprendizaje del dominio, cada una con su modelo del alumno y su modelo del dominio. Sin embargo, lo que alumnos y profesores demandan son plataformas de gestión de cursos, al estilo de los LMS, desde las que se pueda acceder a todos los recursos y que proporcionen una gestión centralizada tanto del modelo del alumno como del proceso de instrucción.

De la primera a la segunda versión se gana en inteligencia y calidad pedagógica pero se pierde el sentido de integración y la visión del sistema de enseñanza como un todo. La integración de ambos mediante MEDEA (TEA-MEDEA) aporta ambas cosas, por un lado una capacidad instructora y de planificación que complementa los métodos de enseñanza de SIGUE y SIETTE, estableciendo una instrucción en dos niveles: secuenciación del currículum y realización de tareas. Por otro lado, MEDEA ofrece a los alumnos una única vista del currículum y de sus modelos de conocimiento, de modo que la gestión e integración de los distintos modelos que intervienen en la instrucción (SIGUE y SIETTE) sea transparente al usuario.

En muchos casos es imposible separar en los sistemas educativos inteligentes el conocimiento de la forma de usarlo, es interesante por tanto destacar que MEDEA permite reutilizar sistemas íntegramente (conocimiento más funcionalidad) aprovechando tanto el material (no es necesario volverlo a editar) como su capacidad de instrucción y adaptación.

La Tabla 31 resume las características principales del sistema TEA original, del curso de Economía Agraria de SIGUE y el test de Economía Agraria de SIETTE (SIGUE+SIETTE) y el sistema TEA-MEDEA. Como ya se ha mencionado, el primer sistema es “no inteligente” careciendo de capacidad de adaptación, planificación de la instrucción y gestión del modelo del alumno. Las versiones posteriores han heredado tanto el modelo del dominio como el material, ligeramente adaptado. Este material una vez introducido en SIGUE y SIETTE es susceptible de modificaciones a través de las herramientas de autor de estos sistemas.

210


211

Tabla 31 Comparativa de los sistemas TEA(columna TEA), la reimplementación del curso de Economía Agraria usando los sistemas SIGUE y SIETTE(columna SIGUE + SIETTE) y la reimplementación del

sistema TEA desarrollado con MEDEA (columna TEA-MEDEA)

TEA SIGUE + SIETTE TEA- MEDEA

Material

Páginas web - No adaptativas - No configurables

Test - No configurables - No adaptativos - Número fijo de

preguntas - No modificables

por el profesor - Preguntas de

respuesta única

Páginas web - No adaptativas - Configurables

Test - Configurables - Adaptativos - Número variable

de preguntas - Varios tipos de

preguntas (respuesta única, múltiple, libre, etc.)

Páginas web - No adaptativas - Configurables

Test - Configurables - Adaptativos

Número variable de preguntas

Herramientas de autor

Ninguna SIGUE - construcción del

dominio - configuración de

enlaces SIETTE

- construcción del dominio

- edición de preguntas

- configuración del test

SIGUE - construcción del

dominio - configuración de

enlaces SIETTE

- construcción del dominio

- edición de preguntas

- configuración del test

MEDEA - edición del

dominio - integración y

configuración de tareas

- acceso a herramientas de autor externas

Tareas Lectura Test

Lectura Test

Lectura Test

Estrategias de enseñanza

Ninguna Estrategias de SIGUE para la lectura de contenidos (prerrequisitos) Estrategias de SIETTE para la evaluación.

Estrategias de SIGUE para la lectura de contenidos Estrategias de SIETTE para la evaluación. Configuración de los sistemas SIGUE y SIETTE, p-ej.: Estimulación de la motivación utilizando el método adaptativo

Capítulo 8

de selección de preguntas

Ayuda a la navegación

Hiperenlaces a temas relacionados

Navegación supervisada

- se filtran enlaces externos

Navegación supervisada de SIGUE Orientación en la selección de conceptos y tareas

Planificación de la instrucción

Ninguna Guiada por - prerrequisitos - modelo del alumno

Guiada por: - prerrequisitos - relación parte_de - equilibrio entre

enfoque y dispersión del foco de instrucción

- modelo del alumno

Modelo del dominio

Conceptos Relación subtema

SIGUE: - conceptos - relaciones de

prerrequisito y subtema

SIETTE - tests - temas - ítems

MEDEA: - conceptos - atributos de

conceptos - relaciones de

prerrequisito, subtema, parte_ de y es_un

Modelo del alumno

No existe modelo del alumno

SIGUE: - superposición

(porcentaje sobre páginas visitadas)

SIETTE - superposición

(niveles de conocimiento)

- varios métodos de estimación del conocimiento

MEDEA: - modelo de

aptitudes - modelo de

conocimientos por superposición en cuatro niveles

- Inferencia del nivel de conocimiento según: - tareas evaluativas - tareas no

evaluativas - red bayesiana de

prerrequisitos - red bayesiana de

agregación

8.3.2 Costes de desarrollo y mantenimiento

En este apartado se analizan los procesos de desarrollo de los sistemas TEA y TEA-MEDEA para intentar establecer las diferencias entre ambos y comprobar las ventajas de la reutilización de recursos proporcionada por MEDEA en relación a los costes de desarrollo.

El sistema TEA está compuesto por un índice de catorce temas con sus correspondientes subtemas. Cada nodo del índice tiene una página web

212


213

asociada y cada nodo del primer nivel (que no es subtema de ningún otro) tiene asociado un test con preguntas de respuesta única. Su proceso de desarrollo consistió en: a) estructuración y organización del contenido del libro “Introducción a la Economía de la Empresa Agraria” (Berbel, 1991), b) desarrollo de páginas web con el contenido de cada nodo del índice y c) construcción de las preguntas de los tests. Cada pregunta está asociada a un programa cgi que analiza la respuesta y devuelve si es o no correcta. En este proceso intervinieron dos expertos en el dominio y dos programadores y desarrolladores de páginas web.

El proceso de desarrollo de TEA-MEDEA (7.2.2) puede resumirse en los siguientes pasos: a) desarrollo del material con SIGUE y SIETTE, b) definición del dominio y c) descripciones semánticas de los recursos (correspondencias entre dominios y configuración de parámetros).

Con el fin de reducir al mínimo las diferencias entre ambos sistemas se ha mantenido el diseño curricular inicial, de modo que los dominios en SIGUE, SIETTE y MEDEA tuviesen el mismo número de conceptos que nodos el índice de TEA. A este dominio se le han añadido relaciones de prerrequisito (SIGUE y MEDEA) y atributos de conceptos (MEDEA). Del mismo modo el material no ha sido modificado, las páginas web han sido insertadas en SIGUE y las preguntas reeditadas con la herramienta de autor de SIETTE.

Para analizar los procesos de desarrollo de ambos sistemas se han comparado los tiempos de desarrollo de: a) el dominio, b) las páginas web, c) las preguntas de test y d) la integración de recursos.

El tiempo de definición del dominio depende del número de nodos, relaciones y atributos por concepto (ver Tabla 32). El currículum de TEA es más simple que los de SIGUE, SIETTE y MEDEA debido a que sólo existe la relación subtema_de y los conceptos no tienen atributos. En TEA-MEDEA el autor ha establecido numerosos prerrequisitos y definido valores para tres atributos por concepto (dificultad, nota mínima y tipo de evaluación). Si se tiene en cuenta la definición de los dominios para el curso de SIGUE y el test de SIETTE, el tiempo de creación del dominio de TEA-MEDEA sería tres veces superior que el empleado en TEA.

El contenido teórico del sistema supuso en TEA la edición de numerosas páginas web (1 por concepto). Posteriormente fue necesario establecer manualmente los enlaces entre dichas páginas y definir los hiperenlaces contenidos en las mismas.

En TEA-MEDEA el contenido del curso está accesible a través del sistema SIGUE. SIGUE tiene una herramienta de autor que permite asociar páginas ya construidas a nodos del currículum. El índice del curso y los enlaces se generan automáticamente. Al disponer de las páginas de TEA el tiempo de desarrollo del curso se reduce sensiblemente.

Los tests en TEA se realizaron en dos fases. Primero se escribieron formularios HTML con el texto de las preguntas y respuestas y posteriormente se programó el motor para la evaluación de las preguntas. Éste está formado

Capítulo 8

por un cgi por pregunta que indica la respuesta correcta. El problema de este sistema es que cada cgi es específico para una pregunta. En caso de que se desee modificar alguna de ellas será necesario contar con un programador que modifique el código del cgi correspondiente, los compile y lo instale en el servidor HTTP.

Tabla 32 Parámetros que afectan a los procesos de desarrollo de TEA y TEA-MEDEA

TEA TEA- MEDEA

Conceptos 110 MEDEA – 110

SIGUE – 110 SIETTE - 110

Relaciones

94 subtema_de MEDEA - 94 subtema_de - 32 prerrequisitos

SIGUE - 94 subtema_de - 18 prerrequisitos

SIETTE - 94 subtema_de

Dominio

Atributos 0 MEDEA- 3 atributos/concepto

SIGUE - 0 SIETTE - 0

Páginas 1 por concepto SIGUE – 1 por concepto

Preguntas de test 87 formularios HTML con los enunciados 87 cgi

SIETTE – 87 ítem

Descripción funcional

SIGUE – 4 parámetros de ejecución SIETTE– 6 parámetros de ejecución

Integración de recursos

Descripción semántica

SIGUE – 110 conceptos SIETTE - 110 conceptos - 1 parámetro modificado

Los tests para TEA-MEDEA han sido desarrollados con la herramienta de autor del sistema SIETTE. En este caso no es posible extraer el texto de las preguntas de los formularios HTML de TEA por lo que el autor tuvo que reeditarlas. Una vez hecho esto el profesor puede editar las opciones de SIETTE para configurar un test o aceptar los valores por defecto. El sistema SIETTE proporciona un motor para la generación y evaluación de tests. En caso de modificaciones el profesor puede editar el contenido de cualquier pregunta a través de una sencilla interfaz web.

Por último, hay que considerar el tiempo necesario para la integración de los recursos. Éste se divide entre las descripciones funcionales y semánticas. Las primeras serán proporcionadas por los creadores de los recursos mientras que el resto es tarea del profesor.

214


215

Para la descripción funcional tan sólo es necesario proporcionar la localización de los servicios del recurso y el nombre, tipo y valor por defecto de los parámetros de ejecución.

Para la descripción semántica es necesario tener en cuenta las tareas de establecer las correspondencias entre dominios y la de configuración de los parámetros de ejecución para adaptarlos a determinados perfiles de alumnos. La segunda tarea consume un tiempo muy inferior a la primera por lo que lo que más influye en la integración de un recurso es el tamaño del dominio.

Si consideramos d, p y q los tiempos de desarrollo del dominio, una página web y una pregunta de test para el sistema TEA y dm, ps y qs los tiempos de creación del dominio en MEDEA, construcción de una página web con SIGUE, siendo de una pregunta de test con SIETTE y de integración de un recurso, tenemos que:

El tiempo de desarrollo de un dominio es:

nctanatrnrtcnctd ⋅⋅+⋅+⋅=

donde nc, nr y na representan la cantidad de conceptos, relaciones y atributos del dominio y tc, tr, y ta los tiempos de creación de cada uno de estos elementos, luego tc110d ⋅= y 110ta3tr)94112126(tc110dm ⋅⋅+⋅+++⋅= y por tanto dmd <

, ya que las páginas para el curso de SIGUE ya estaban construidas y tan sólo hubo que asociarlas al nodo del currículum correspondiente. Además los enlaces en TEA hay que establecerlos manualmente.

psp >

El tiempo de construcción depende del tiempo de edición y de tiempo de programación del proceso de evaluación. En el caso de SIETTE el motor de corrección de las preguntas viene dado por el sistema luego . qsq >

Estas consideraciones nos llevan a afirmar que aunque la definición de los dominios en cada una de las herramientas utilizadas es una tarea más costosa que para un único sistema, la creación del material es más sencilla. Además, este análisis no tiene en cuenta ni los costes de mantenimiento, claramente inferiores para TEA-MEDEA ni la superioridad funcional de TEA-MEDEA respecto a TEA. Si los autores quisieran ampliar TEA para obtener las mismas prestaciones, serían necesarios varios meses para implementar un módulo que imite el sistema de planificación de SIGUE y el motor de generación de tests de SIETTE. Es imposible reutilizar el software ya hecho. Sin embargo con la metodología de TEA-MEDEA no sólo se ha reutilizado de forma dinámica y sencilla sino que el sistema queda abierto a posibles ampliaciones que no afectaran a la parte ya construida.

8.4 Conclusiones

En este capítulo se ha descrito el proceso de evaluación formativa de MEDEA. El método de evaluación se basa en las recomendaciones de Murray (Murray, 1993) para el diseño de sistemas educativos inteligentes que postulan la

Capítulo 8

conveniencia de realizar un diseño iterativo que, partiendo de un prototipo inicial, vaya probando y refinando la funcionalidad del sistema en sucesivas iteraciones. En total se han desarrollado cinco prototipos. Para cada uno de ellos se han descrito los aspectos que mejorados en base a los resultados de las evaluaciones previas y los experimentos realizados con el fin de incluir sus conclusiones en el diseño del prototipo siguiente.

El marco de trabajo ha sido evaluado desde el punto de vista del desarrollo de sistemas centrándose en aspectos como la reutilización de sistemas educativos completos, el coste de esta reutilización y el carácter genérico de la propuesta. El proceso de integración de los recursos SIGUE, SIETTE y WADEIn II (apartado 6.2) así como los WILE de Lógica y Economía Agraria (Capítulo 7) evidencian la capacidad del marco de trabajo para generar sistemas distribuidos, abarcar dominios diversos y reutilizar sistemas externos siempre que se ajusten a las especificaciones dadas por la metodología.

Con el fin de observar en un caso real la mejora en el tiempo de desarrollo de un sistema se ha realizado una comparación del proceso de desarrollo del WILE TEA-MEDEA, construido siguiendo las directrices de la metodología, con el sistema TEA original construido desde cero sin seguir ninguna metodología de desarrollo. De esta comparación se extraen algunas conclusiones que nos llevan a afirmar que la reutilización de material reduce sensiblemente los costes de desarrollo de un sistema y la reutilización de la “inteligencia” de otros sistemas representan un valor añadido.

216

Capítulo 9 CONCLUSIONES

A lo largo de las últimas décadas se ha puesto de manifiesto la validez del paradigma de los Sistemas Tutores Inteligentes. A pesar de ello, las propuestas “no inteligentes” copan la mayor parte de la oferta educativa para la web. Las principales razones que justifican este hecho son su versatilidad en lo referente a los recursos educativos ofertados y el esfuerzo de las principales plataformas por adaptarse a los estándares internacionales, favoreciendo de este modo la creación de material reutilizable, independiente de la plataforma que los genera y mantiene.

Los WILE, nueva generación de STI para la web, son sistemas en los que el material y la forma en la que éste se presenta al usuario están estrechamente relacionados siendo muy difícil reutilizar todo o parte del conocimiento y recursos que contienen. A esto se une su especificidad (normalmente se restringen a un domino y a una estrategia pedagógica concreta) y, sobre todo, su elevado coste de desarrollo que se prolonga a lo largo de años e implica a expertos en el dominio, técnicos y docentes que deben trabajar conjuntamente.

El objetivo general de este trabajo ha sido aunar las ventajas de ambos enfoques proponiendo una metodología para la construcción de WILE que permita reutilizar sistemas inteligentes completos. De este modo se proporcionan al alumno las ventajas del aprendizaje basado en STI a la vez se incrementa la oferta de recursos, reduciendo los costes de desarrollo.

La solución propuesta en esta tesis se ha concretado en MEDEA (MEtodologías y herramientas para el Desarrollo de entornos inteligentes de Enseñanza y Aprendizaje). MEDEA comprende una metodología para el desarrollo de entornos inteligentes de aprendizaje para la web basada en la integración de sistemas educativos y un marco de trabajo basado en dicha metodología. El marco de trabajo permite la utilización de programas educativos externos como LO de entornos inteligente aplicados a diversos dominios.

MEDEA, identifica los tipos de usuario involucrados en el desarrollo de un sistema educativo y las necesidades que se plantean en su contexto. Según esto,

217

Capítulo 9

la metodología define un conjunto de cuatro capas, en cada una de ellas interviene un actor y genera los elementos necesarios para poder completar la siguiente capa. La capa 0 se corresponde con el núcleo del sistema. El técnico o programador de la capa 1 se encargará de implementar soluciones a problemas educativos e integrarlas de forma que sean compatibles con los elementos de la capa 0. La capa 2 se corresponde con el conocimiento de instrucción en el que el experto se encargará de estructurar el conocimiento de un determinado dominio y el profesor de seleccionarlo y ponerlo en correspondencia con los recursos de la capa 1. Por último el alumno es el usuario final del sistema que llevará a cabo el aprendizaje de un determinado dominio (capa 3).

A partir de estas especificaciones se ha implementado el marco de trabajo descrito en los Capítulo 6 y Capítulo 7. Se han construido los elementos del núcleo (interfaz, modelo del alumno, planificador de instrucción, modelo del dominio) y se han integrado tres sistemas externos como recursos de instrucción (SIGUE (Carmona et al., 2002), SIETTE (Conejo et al., 2004) y WADEIn II (Loboda and Brusilovsky, 2005-2006)). Como base para la comunicación se han usado servicios web. Para completar el ciclo de desarrollo se han construido dos WILE para los dominios de Lógica y Economía Agraria que hacen uso de los RI.

9.1 Resultados y aportaciones

Las aportaciones de esta tesis pueden enmarcarse en dos contextos diferentes: el proceso de desarrollo de WILE y la implementación del marco de trabajo. A continuación se resumen los aspectos más desatacados en cada uno de estos apartados.

9.1.1 Metodología de desarrollo

MEDEA, como metodología, articula el proceso de desarrollo en función de los tipos de usuario involucrados en un sistema educativo y las necesidades que se plantean en su contexto, apostando por la integración de desarrollos anteriores. Sus principales aportaciones desde el punto de vista del desarrollo de sistemas educativos inteligentes para la web pueden resumirse en los siguientes puntos:

Sistematización del proceso de desarrollo de Sistemas Tutores Inteligentes

La mayoría de los WILE son desarrollados ad hoc para cubrir unos objetivos concretos en cuanto al dominio, las estrategias de enseñanza, el alumnado al que va dirigido, etc., con los consiguientes problemas asociados a esta forma desestructurada de crear sistemas. Al abordar la construcción de programas de envergadura es necesario contar con metodologías que asistan a los desarrolladores en todas las fases del ciclo de vida del sistema. Tanto en la Ingeniería del Software (IS) como en la Ingeniería del Conocimiento (IC) existen metodologías de desarrollo de sistemas (RUP, Métrica 3, CommonKADS, etc.). Algunas de ellas se han adaptado a desarrollo de sistemas multi-agentes (GAIA, Agent UML, MAS-CommonKADS, DESIRE, etc.). En el campo de los STI se han llevado a cabo

218

Conclusiones

219

intentos por establecer arquitecturas genéricas (Alpert et al., 1999; Nakabayashi et al., 1997; Ritter et al., 1998), principios de diseño (Gagné and Briggs, 1979), patrones SW (Devedzic and Harrer, 2005) y herramientas de autor (Murray, 1999). Sin embargo, como pone en evidencia el estudio realizado en el Capítulo 3, no existe una metodología específica para este tipo de sistemas. Con MEDEA se ha conseguido sistematizar el proceso de desarrollo de un Sistema Instructor Inteligente. El Capítulo 5 describe de forma precisa los elementos y métodos para la construcción de un WILE así como las secuencias de aplicación de dichos métodos. No se intenta sustituir a otras metodologías sino completarlas proporcionando una descripción a alto nivel de los elementos específicos de un WILE.

Generalización

La metodología propuesta es independiente de la implementación. Como consecuencia, su aplicación no depende de dominios, estrategias educativas y métodos de diagnóstico. El Capítulo 5 describe cada una de las capas de desarrollo (cuerpo de conocimiento, servicios y protocolos de actuación) sin hacer referencia a estos detalles que se fijarán durante la construcción del marco de trabajo que de soporte a la misma. Esta metodología tampoco está condicionada por ninguna tecnología para el desarrollo de aplicaciones distribuidas. A lo largo de su descripción no se hace referencia explícita a ninguna técnica concreta, estando abierta a cualquiera de las referenciadas en el Capítulo 4.

Separación de roles

MEDEA identifica los distintos roles que intervienen en el desarrollo de un WILE separando claramente el cuerpo de conocimiento que depende de cada uno de ellos y los protocolos de actuación correspondientes. Esto permite crear el sistema de forma escalada, de forma que cada participante pueda ir desarrollando su parte si necesidad de que el sistema completo esté construido, como ilustran los procesos de construcción de los sistemas de Lógica y Economía Agraria (Capítulo 7). Los docentes participantes en el proyecto pudieron ir desarrollando su currículum y el material didáctico en paralelo al proceso de integración llevado a cabo por los técnicos. Esta forma de trabajar permite a los docentes enriquecer sus sistemas incorporando aquellos recursos que, con el tiempo, se vayan añadiendo al marco de trabajo. Asimismo, este enfoque proporciona un marco en el que observar los procesos de enseñanza y aprendizaje desde varias perspectivas, que son las que se corresponden con los actores descritos en el Capítulo 5.

Esta metodología es una apuesta por la integración permitiendo que se utilicen desarrollos anteriores completos (tanto el contenido como la forma de presentarlo), es decir, permite reutilizar no sólo material didáctico sino “la inteligencia” de otros sistemas. Como prueba de ello se presentan los sistemas SIGUE, SIETTE y WADEIn-II desarrollados de forma totalmente

Capítulo 9

independiente e integrados con éxito en el marco de trabajo descrito en el Capítulo 6.

9.1.2 Implementación de MEDEA

El marco de trabajo constituye un ejemplo de aplicación de la metodología. El objetivo de este desarrollo presentado en el Capítulo 6 es ilustrar todo lo expuesto en el capítulo anterior. Este marco de trabajo no es válido para demostrar la eficacia de las estrategias de planificación, la gestión de los modelos del alumno y del dominio o de los recursos integrados. Su finalidad es mas bien corroborar que es factible el desarrollo de WILE siguiendo nuestra metodología de desarrollo, y en particular que es posible la integración real, y no sólo teórica, de recursos externos. Las principales aportaciones de esta implementación se enumeran a continuación:

Permite la reutilización de sistemas educativos completos (conocimiento + inteligencia), como constatan las integraciones de los sistemas SIGUE, SIETTE y WADEIn-II descritas en el epígrafe 6.2.4.

MEDEA proporciona, no sólo un marco de trabajo, sino un conjunto de herramientas web de autor que facilitan la creación de WILE a usuarios no especializados.

El marco de trabajo constituye, además, una herramienta útil para probar y analizar distintas cuestiones relacionadas con los STI (modelo del domino, alumno, planificador, teorías educativas...), ya que, como se ha probado con los desarrollos de los sistemas de Lógica y TEA, permite no sólo construir de forma más o menos rápida un WILE, sino también modificarlo, añadiendo y quitando componentes, modificando el dominio, los parámetros de los recursos y la asignación de tareas a conceptos entre otras. De este modo el profesor puede probar fácilmente distintas configuraciones de su WILE y extraer conclusiones que le ayuden a una mejor adaptación de contenidos y estrategias.

Para el desarrollo de este marco de trabajo se han tenido en cuenta en la medida de lo posible los estándares más extendidos en cada uno de los campos que se han abordado durante su construcción:

- Software distribuido: se utiliza como tecnología base para la comunicación entre los distintos elementos del marco de trabajo los servicios web. Se usa el protocolo SOAP para la llamada a procedimientos remotos y el lenguaje WSDL para la descripción de servicios.

- Definición de recursos educativos. Se ha realizado un esfuerzo de adaptación al estándar LOM de la IEEE para descripción de los RI, que ha sido usado para modelar aquellas características propias de los sistemas inteligentes que escapan a su ámbito.

- Modelado del dominio. Se ha empleado el lenguaje OXML para la definición de ontologías

220

Conclusiones

221

El marco de trabajo permite la construcción de sistemas distribuidos, desacoplados y escalables. Los sistemas de Lógica y TEA usan componentes y recursos repartidos entre distintas máquinas de la web.

Aunque para integrar un recurso es necesario realizar un pequeño trabajo de programación implementando los servicios de la API definida en la metodología, el marco de trabajo es abierto y permite la inserción y eliminación de forma “dinámica” de RI sin necesidad de recompilar el sistema y/o modificar el resto de elementos.

El tiempo de desarrollo de un WILE se reduce sensiblemente. Por un lado el marco de trabajo proporciona los elementos comunes a todo STI (capa 0) por lo que no es necesario comenzar el sistema desde cero. Si además existen recursos disponibles que se adecuan al dominio del WILE que se pretende desarrollar, se reduce el tiempo de preparación de material por parte del profesor y el de programación por parte de los técnicos. Si se quisiera desarrollar un curso de programación en C, disponemos actualmente de un sistema que hace ejercicios de evaluación de expresiones y de un banco de preguntas sobre C. El profesor tan sólo tiene que poner en correspondencia su dominio con el de estos de recursos, y automáticamente dispone de todo el material además de la funcionalidad para ofrecer a sus alumnos. El estudio comparativo del desarrollo de TEA siguiendo la metodología MEDEA con el desarrollo original avala esta afirmación 8.3.

9.2 Limitaciones

Las soluciones para problemas tan generales como la construcción de WILE no son absolutas. Durante su desarrollo son muchas las decisiones tomadas referentes a temas tan dispares como los sistemas distribuidos, las ontologías, el modelado del usuario, teorías educativas, lenguajes de programación, arquitecturas cliente-servidor, etc. Estas decisiones no están siempre avaladas por estudios formales que apunten a una u otra opción. En algunas ocasiones es necesario llegar a un compromiso entre distintos parámetros de diseño.

MEDEA presenta una arquitectura centralizada. El núcleo proporciona los servicios básicos de un STI y concentra la gestión del modelo del alumno. Los datos del modelo central son accesibles a todos los recursos pero los éstos no pueden compartir la información de sus alumnos, es decir, los RI sólo se pueden comunicar con el núcleo, no entre sí. De esta forma se pierde expresividad pero se gana capacidad de integración.

Construir una metodología genérica en diversos aspectos (dominio, estrategias, planificación) permite abarcar un mayor rango de WILE, mayor flexibilidad en el enfoque pedagógico de los sistemas, libertad en la definición de los dominios y capacidad para reutilizar otros desarrollos. Por el contrario se pierde control sobre el proceso de aprendizaje y capacidad para aplicar estrategias de planificación que han demostrado ser eficaces en dominios concretos.

Capítulo 9

Aunque es indudable que la reutilización de sistemas tiene ventajas que han sido expuestas a lo largo de esta memoria, existen todavía algunas deficiencias sobre todo en lo referente a la comunicación de sistemas inteligentes a alto nivel. El problema de determinar cómo los sistemas pueden compartir el conocimiento es un problema complejo que aún no ha sido resuelto. Para que dos sistemas se comuniquen a este nivel es necesario que compartan una ontología y un lenguaje o protocolo de comunicación. En esta tesis se ha primado la puesta en práctica de una solución real y se ha optado por delegar en una persona (en nuestro caso el docente) el trabajo de establecer conexiones entre términos de dos ontologías (currículums) diferentes, de este modo es responsabilidad del profesor la coherencia de la semántica de dichas correspondencias.

La apuesta por la integración de sistemas de MEDEA redunda en perjuicio de la expresividad de los modelos del dominio y del alumno. Las redes semánticas y los modelos de superposición son menos precisos que otros pero más sencillos favoreciendo la integración con los recursos de instrucción.

9.3 Líneas futuras

El trabajo desarrollado en esta tesis abre otras líneas de investigación que se enumeran a continuación:

Extensión de la metodología y el marco de trabajo para que admitan varias instancias de cada uno de los elementos del núcleo. Del mismo modo que el docente tiene a su disposición un conjunto de recursos de instrucción, sería deseable que dispusiera de igual modo de una biblioteca de planificadores de instrucción y modelos del dominio y del alumno de modo que pudiese seleccionar aquellos que mejor se adapten a sus necesidades. De este modo podrían ofrecerse soluciones particulares para un dominio o tipo de alumno concreto multiplicando las posibilidades de adaptación del sistema.

Extender el marco de trabajo incluyendo servicios de búsqueda e integración automática de recursos educativos en la Web. Para esto sería interesante ahondar en el estudio y aplicación de modelos y lenguajes para la descripción semántica de servicios.

Implementar MEDEA como un sistema multi-agente abierto de modo que los recursos/agentes puedan comunicarse entre sí. Estos agentes serían cognitivos en el sentido dado por Frasson (Frasson et al., 1998), esto es, deben ser capaces de aprender y descubrir nuevos hechos y/o mejorar su conocimiento. El aprendizaje se puede alcanzar aplicando diversos métodos como algoritmos genéticos, aprendizaje automático, etc.

Integrar herramientas de aprendizaje colaborativo como recursos de instrucción.

Usar intensivamente los sistemas construidos con MEDEA con alumnos reales para extraer conclusiones que puedan mejorar la metodología de desde la óptica de la enseñanza y el aprendizaje.

222

REFERENCIAS

ADL . Advanced Distributed Learning. [Web Page]. Accessed 2004 Mar. Available at: http://www.adlnet.org.

Ainsworth, S. Tutorial: Evaluation Methods for Learning Environments. AIED 2003 (11th. International onference on Artificial Intelligence in Education); 2005.

Ainsworth, S., Underwood, J. and Grimshaw, S. (1999). Formatively Evaluating REDEEM - An Authoring Environment for ITSs. In Lajoie, S.,Vivet, M.,Artificial Intelligence in Education. pp. 93-100.: IOS Press.

Alderman, D. L., Appel. L. R. and Murphy, R. T. (1978). PLATO and TICCIT: An evaluation of computer-assisted instruction in the community college. Educational Technology. Vol. 18 (4), pp.40-45.

Alpert, Sherman R., Singley, Mark K. and Fairweather, Peter G. (1999). Deploying Intelligent Tutors on the Web: An Architecture and a Example. International Journal of Artificial Intelligence in Education. Vol. 10, pp.183-197.

Anderson, J. R. (1983). The arquitecture of cognition. Cambridge: Harvard University Press.

Anderson, J. R. (1988). The Expert Module. In Polson, M. C.,Richardson, J. J.,Foundations of Intelligent Tutoring Sytems. Lawrence Elrbaum.

Anido, L., Llamas, M., Fernández, M. J., Santos, J. and Caeiro, M. (2001). The Next Step in Computer Based Education: the Learning Technologies Standardization. In Ortega, M.,Bravo, J.,Computers and Education. Towards and Interconnected Society. pp. 71-80.: Kluwer Academic Publishers.

Arruarte, A. (1998). Fundamentos y diseńo de IRIS: un entorno de programación de Sistemas de Enseńanza Inteligente. PhD thesis, Universidad del País Vasco.

Arruarte, A., Fernández-de-Castro, I., Ferrero, B. and Greer, J. (1997). The IRIS shell: How to build ITSs from pedagogical and design requisites. International Journal of Artificial Intelligence in Education. Vol. 8 (3-4), pp.341-381.

Ausbel, D. P. (1968). The psychology of meaningful verbal learning. New York: Grune y Stratton.

Axis Development Team (2002). WebServices - Axis [Web Page]. Accessed 2004 Jun. Available at: http://ws.apache.org/axis/.

Barr, A. and Feigenbaum E.A. (1982a). Applications-oriented AI Research: Education. In Barr, A.,Feigenbaum E.A.,The Handbook of Artificial Intelligence. v. 2) : Pitman.

Barr, A. and Feigenbaum E.A. (1982b). Applications-oriented AI Research: Education. Intelligent CAI Systems. In Barr, A.,Feigenbaum E.A.,The Handbook of Artificial Intelligence. v. 2) : Pitman.

223

Referencias

Barr, A. and Feigenbaum E.A. (1982c). Applications-oriented AI Research: Medicine. Medical systems. In Barr, A.,Feigenbaum E.A.,The Handbook of Artificial Intelligence. v. 2) : Pitman.

Barr, A. and Feigenbaum E.A. (1982d). Planning and Problem Solving. In The Handbook of Artificial Intelligence. v. 3) : Pitman.

Barros, B. (1999). Aprendizaje colaborativo en enseńanza a distancia: entorno genérico para configurar, realizar y analizar actividades en grupo. Universidad Politécnica de Madrid.

Barros, B. and Verdejo, M. F. (2001). Entornos para la realización de actividades de aprendizaje colaborativo a distancia. Revista Iberoamericana De Inteligencia Artificial. Vol. 3 (12), pp.39-49.

Barrows, H. S. and Tamblyn, R. M. (1980). Problem-Based Learning: An Approach to Medical Education. N.Y.: Springer Publishing Company.

Bauer, B., Müller, J. P. and Odell, J. (2001). Agent UML: A Formalism for Specifying Multiagent Interaction. Ciancarini, P.,Wooldridge, M.,Agent-Oriented Software Engineering. pp. 91-103.Berlin: Springer.

Bechhofer, S., van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D. L., Patel-Schneider, P. F., Stein, L. A. and Olin, F. W. (2004 Feb 10). OWL Web Ontology Language Reference. W3C Recommendation [Web Page]. Accessed 2004 Apr. Available at: http://www.w3.org/TR/2004/REC-owl-ref-20040210/.

Belmonte, M. V. (2002). Formación de coaliciones en sistemas multi-agente: una aproximación computacionalmente tratable basada en teoría de juegos. Universidad de Málaga.

Belmonte, M. V., Berbel, J. and Conejo, R. (1996). TEA: An Agrarian Economy Instructor System. In Third International Conference on Computer Aided Learning and Instruction in Science and Engineering, CALISCE'96. pp. 322-330.San Sebastián.

Berbel, J. Introducción a la Economía de la Empresa Agraria. Ediciones A.S.C.; 1991.

Birrell, A. D. and Nelson, B. J. (1984). Implementing remote procedure calls. ACM Transactions on Computer Systems (TOCS). Vol. 2 (1), pp.39-59.

Bloom, B. S. (1984). The 2 sigma problem: the search methods of group instruction as effective as one-to-one tutoring. Educational Researcher. Vol. 13 (6), pp.4-16.

Bloom, B. S., Engelhart, M. D., Murst, E. J., Hill, W. H. and Drathwohl, D. R. (1956). Taxonomy of Educational Objetives: The Cognitive Domain. Longmans.

Borst, P. (1997). Construction of Engineering Ontologies for Knowledge Sharing and Reuse. PhD thesis, Universiteit Twente.

Brazier, F. M. T., Dunin-Keplicz, B. M., Jennings, N. R. and Treur, J. (1997). DESIRE: Modelling Multi-Agent Systems in a Compositional Formal Framework. International Journal of Cooperative Information Systems. Vol. 6 (1), pp.67-94.

Brickley, D. and Guha, R. V. (2004 Feb). RDF Vocabulary Description Language 1.0: RDF Schema [Web Page]. Accessed 2004 May. Available at: http://www.w3.org/TR/rdf-schema/.

Brown, J. S. and Burton, R. (1978). Diagnostic models for procedural bugs in basic mathematical

224

Referencias

skills. Cognitive Science. Vol. 2, pp.155-192.

Brown, J. S., Burton, R. and Bell, A. G. (1975). SOPHIE. A step towards a reactive learning environment. International Journal of Man-Machine Studies. Vol. 7, pp.675-696.

Brusilovsky, P. (1995). Intelligent tutoring systems for World-Wide Web. R. Holzapfel,Poster proceedings of Third International WWW Conference. pp. 42-45.

Brusilovsky, P. (1996). Methods and techniques of adaptive hipermedia. User Modeling and User Adapted Interaction. Vol. 6 (2-3), pp.87-129.

Brusilovsky, P. (1999). Adaptive and Intelligent Technologies for Web-based Education. Künstliche Intelligenz, Special Issue on Intelligent Systems and Teleteaching. Vol. 4, pp.19-25.

Brusilovsky, P. (2000). Adaptive Educational Systems on the World-Wide-Web: A Review of Availiable Technologies. <25 Page(s)>.

Brusilovsky, P. (2003). Developing adaptive educational hypermedia systems: From design models to authoring tools. In Murray, T. et al.,Authoring Tools for Advanced Technology Learning Environment. Dordrecht: Kluwer Academic Publishers.

Brusilovsky, P., Eklund, J. and Schwarz, E. (1998). Web-based Education for All: A Tool for Development Adaptive Courseware. In Computer Networks and ISDN Systems (Proceedings of Seventh International World Wide Web Conference). v. 30) pp. 291-300.

Brusilovsky, P. and Nijhavan, H. (2002) A Framework for Adaptive E-Learning Based on Distributed Re-usable Learning Activities. In: Druscoll, M. and Reeves, T. C., Proceedings of World Conference on E-Learning

Brusilovsky, P., Ritter, S. and Schwarz, E. (1997) Distributed intelligent tutoring on the Web, Proceedings of the 8th World Conference of the AIED Society

Brusilovsky, P., Schwarz, E. and Weber, G. (1996) ELM-ART: An Intelligent Tutoring System on World Wide Web, Intelligent Tutoring System Springer VerlagLecture Notes in Computer Science

Burton, R. (1988). The Environment Module of Intelligent Tutoring Systems. In Polson, M. C.,Richardson, J.,Intelligent Tutoring System . Lawrence Erlbaum.

Burton, R. and Brown, J. S. (1979). An investigation of computer coaching for informal learning activities. International Journal of Man-Machine Studies. Vol. 11, pp.5-24.

Canut, M. F., Gouardères, G. and Sanchis, E. (1999). The Systemion: A New Agent Model to Design Intelligent Tutoring System. In Artificial Intelligence in Education. Frontiers in Artificial Intelligence and Applications . v. 50) pp. 54-63.: IOS Press.

Carberry, S. and Rosis, F. (2005). Workshop on Adapting the Interaction Style to Affective Factors [Web Page]. Available at: http://www.di.uniba.it/intint/UM05/WS-UM05.html.

Carbonell, J. (1970). AI in CAI: An Artificial Intelligence Approach to Computer Aided Instruction. IEEE Transactions on Man-Machine Systems. Vol. 11 (4), pp.190-202.

Carmona, C., Bueno, D., Guzmán, E. and Conejo, R. (2002). SIGUE: Making Web Courses Adaptive . In Proceedings of the AH2002 Second International Conference on Adaptive Hypermedia and Adaptive Web-Based Systems. Lecture Notes in Computer Science . v.

225

Referencias

2347 ) pp. 376-379.: Springer-Verlag.

Carmona, C. and Conejo, R. (2004) A Learner Model in a Distributed Environment, AH2004 (Doctoral Consortium)

Carmona, C., Millan, E., Perez-de-la-Cruz, J. L. , Trella, M. and Conejo, R. (2005) Introducing prerequisite relations in a multi-layered Bayesian student model. In : UM2005 User Modeling: Proceedings of the Tenth International Conference Springer-VerlagLeture Notes in Computer Science

Carr, B. and Goldstein, I. P. (1977). Overlays: A theory of modeling for computer aided instruction. AI Memo 406. AI Laboratory, Massachusetts Institute of Technology.

Clancey, W. J. (1979). Transfer of rule-based expertise through a tutorial dialogue. PhD thesis, Stanford University.

Conati, C. (2003). 3rd Workshop on Affective and Attitude User Modeling (UM' 03) [Web Page]. Available at: http://www.cs.ubc.ca/~conati/um03-affect/affectum.html.

Conejo, R., Guzmán, E., Millan, E., Perez-de-la-Cruz, J. L. and Trella, M. (2004). SIETTE: A Web-Based Tool for Adaptive Testing. International Journal of Artificial Intelligence in Education. Vol. 14, pp.29-62.

Cooley, W. and Lohnes, P. R. (1976) Evaluation research in education. New York: John Wiley.

Corcho, O. and Gómez-Pérez, A. (2000). A Roadmap to Ontology Specification Languages. Lecture Notes in Artificial Intelligence. EKAW00, International Conference on Knowledge Engineering and Knowledge Management. Vol. 1937, pp.80-96.

DAML . DARPA Markup Language [Web Page]. Accessed 2004 Apr. Available at: http://www.daml.org.

DAML+OIL Accessed 2004 Apr. Available at: http://www.w3.org/Submission/2001/12/.

De Bra, P. and Calvi, L. (1998) AHA: a Generic Adaptive Hipermedia System. In : Proceedings of the 2nd Workshop on Adaptive Hypertext and Hypermedia HYPERTEXT'98

De Bra, P., Houben, G. J. and Wu, H. (1999) AHAM: A Dexter-based Reference Model for Adaptive Hypermedia. In: Proceedings of the ACM Conference on Hypertext and Hypermedia

De Bra, P., Santic, T. and Brusilovsky, P. AHA meets Interbook and more. Proceedings of World Conference on E-Learning (ELEARN-2003). pp. 57-64.2003.

Departamento de Lenguajes y Ciencias de la computación (Universidad de Málaga) (2006). Investigación y Aplicaciones en Inteligencia Artificial [Web Page]. Available at: http://iaia.lcc.uma.es/.

Devedzic, V. and Harrer, A. 2005 (2005). Software Patterns in ITS Architectures. Vol. 15, pp.63-94.

Duftler, M. J., Mukhi, N. K., Slominski, A. and Weerawarana, S. (2001) Web Services Invocation Framework (WSIF). In: Workshop on Object-Oriented Web Services (OOPSLA'01, ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications)

226

Referencias

Durfee, E. H. and Lesser, V. (1989). Negotiation Task Descomposition and Allocation Using Partial Global Planning. Gasser, L.,Huhns, M. E.,Distributed Artificial Intelligence. v. 2) pp. 229-244.San Francisco: Mogan Kaufmann.

Eliot, Christopher R., Neiman, Daniel E. and LaMar, Michelle M. (1997) Medtec: A Web-Based Intelligent Tutor for Basic Anatomy , WebNet'97

Erdman, M. (2002). The OXML Tutorial (Ontoprise GmbH) [Web Page]. Accessed 2004 Apr. Available at: http://www.ontoprise.de/documents/tutorial_oxml2.0.pdf.

Felder, R. M. and Silverman, L. K. (1988). Learning and Teaching Styles. Engineering Education. Vol. 78 (7), pp.674-681.

Franke, A. and Kohlhase, M. (1999) System Description: MathWeb, an Agent-Based Communication Layer for Distributed Automated Theorem Proving, 16th International Conference on Automated Deduction. CADE'99.

Frasson, C., Martin, L., Gouardères, G. and Aïmeur, E. (1998). LANCA: A Distance Learning Architecture Based on Networked Cognitive Agents. Intelligent Tutoring Systems. 4th International Conference, ITS' 98. Lecture Notes in Computer Science . v. 1452) pp. 594-603.

Frasson, C., Mengelle, T., Aïmeur, E. and Gouardères, G. (1996). An Actor-based Architecture for Intelligent Tutoring Systems. Intelligent Tutoring Systems. Third International Conference, ITS'96. Lecture Notes in Computer Science . v. 1086) pp. 57-65.: Springer Verlag.

Futtersack, M. and Labat, J.-M. (1992). QUIZ, a distributed intelligent tutoring system. Proceedings of 4th International Conference, ICCAL'92, pp.225-237.

Gagné, R. M. (1985). The conditions of learning. New York: Holt, Rinehart & Wiston.

Gagné, R. M. and Briggs, I. J. (1979). Principles of instructional design. Holt, Rinehart and Wiston.

Gardner, H. (1983). Frames of mind: the theory of multiple intelligences. New York: Basic Books.

Girard, J., Gauthier, G. and Levesque, S. (1992). Une architecture multiagent. Intelligent Tutoring Systems. Lecture Notes in Computer Science. Vol. 608, pp.172-182.

Goldberg, M. W., Salari, S. and Swoboda, P. (1996). World Wide Web - Course Tool: An Environment fro Building WWW-Based Courses. Computer Networks and ISDN Systems. Vol. 28 (7-11), pp.1219-1231.

Gómez-Pérez, A. and Corcho, O. (2002). Ontology Languages for the Semantic Web. IEEE Intelligent Systems. Vol. 17 (1), pp.54-60.

Gros, B. (1997). Diseño y programas educativos. Ariel Educación.

Gruber, T. (1993). A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition. Vol. 5 (2), pp.199-220.

Guzmán, E. (2005). Un modelo de evaluación cognitiva basado en tests adaptativos informatizados para el diagnóstico en Sistemas Tutores Inteligentes. Universidad de Málaga.

Halff, H. M. (1988). Curriculum and Instruction in Automated Tutors. In Polson, M. C. ,Richardson, J.,Foundations of Intelligent Tutoring Sytems. Hillsdale, New Jersey:

227

Referencias

Lawrence Erlbaum.

Hooper, R. (1977). An introduction to the National Development Programme in Computer Assisted Learning. British Journal of Educational Technology. Vol. 8 (3), pp.165-175.

IEEE (2005 May). The Learning Object Metadata standard [Web Page]. Accessed 2005 Nov. Available at: http://ieeeltsc.org/wg12LOM/lomDescription.

IEEE LTSC . PAPI, Public and Private Information Package Specification [Web Page]. Available at: http://edutool.com/papi/.

Iglesias, C. A., Garijo, M., González, J. C. and Velasco, J. R. (1997) MAS-CommonKADS: A comprehensive agent-oriented methodology, Proceedings of the 11th International Conference On Mathematical and Computer Modelling and Scientific Computing.

IMS . Open Specifications for Interoperable Learning Technology [Web Page]. Accessed 2004 Mar. Available at: http://www.imsglobal.org/.

IMS Global Learning Consortium, Inc. (2005 Jan). Learner Information Package Specification [Web Page]. Available at: http://www.imsglobal.org/profiles/.

Johnson , R. (1997). Frameworks = Components + Patterns. Communications of the ACM. Vol. 40 (10), pp.39-42.

Johnson , R. and Foote, B. (1988). Designing Reusable Classes. Journal of Object-Oriented Programming. SIGS. Vol. 1 (5), pp.22-35.

Jung, C. G. (1994). Tipos psicológicos. Barcelona: Edhasa.

Karp, P. D., Chaudhri, V. K. and Thomere, J. (1999 Jul). XOL: An XML-Based Ontology Exchange Language [Web Page]. Accessed 2004 May. Available at: ftp://smi.stanford.edu/pub/bio-ontology/xol.doc.

Kifer, M., Lausen, G. and Wu, J. (1995). Logical foundations of object-oriented and frame-based languages. Journal of De ACM. Vol. 42 (4), pp.741-843.

Kinshuk and Patel, A. (1997a). A Conceptual Framework for Internet based Intelligent Tutoring Systems. in Behrooz, A.,Knowledge Transfer. v. II) pp. 117-124.London, UK.: pAce.

--- (1997b) Intelligent Tutoring Tools on the Internet extending the scope of distance education, International Conference on Distance Education (ICDE'97)

Kolb, D. A. (1984). Experiential Learning: Experience as the Source of Learning and Development. N.J.: Prentice-Hall.

Le, Tang-Ho, Gauthier. G. and Frasson, C. (1998). The process of planning for an intelligent tutoring system. In 4th World Conference on Experts Systems: Applicaton of Advanced Information Technologies. pp. 704-714.Mexico.

Libbrecht, P., Frischauf, A., Melis, E., Pollet, M. and Ullrich, C. (2001). Integration of Mathematical Systems into the ActiveMath Learning Environment. <25 Page(s)>.

Littman, D. and Soloway, E. (1988). Evaluating ITSs: The cognitive science perspective. En Polson, M. C.,Richardson, J. J.,Foundations of Intelligent Tutoring Sytems. pp. 209-242.: Lawrence Erlbaum Associates, Inc.

228

Referencias

Loboda, T. and Brusilovsky, P. (2005). WADEIn II [Web Page]. Available at: http://www2.sis.pitt.edu/~paws/system_wadein.htm.

LOM . Learning Object Metadata [Web Page]. Accessed 2004 Mar. Available at: ltsc.ieee.org/doc/wg12/LOMv4.1.htm.

LTSA (2001). Learning Technology Systems Architecture [Web Page]. Accessed 2004 Apr. Available at: http://ltsc.ieee.org/wg1/files/IEEE_1484_01_D09_LTSA.pdf.

LTSC . Learning Technology Standards Committee [Web Page]. Accessed 2004 Apr. Available at: http://ltsc.ieee.org/.

Luke, S. and Heflin, J. (2000 Apr). SHOE 1.01 [Web Page]. Accessed 2004 May. Available at: http://www.cs.umd.edu/projects/plus/SHOE/spec.html.

Macmillan , S. A., Enme, D. and Berkowitz, M. (1988). Instructional Planner: Lessons Learned. In Psotka , J et al.,Intelligent Tutoring System: Lessons Learned. pp. 229-256.Hillsdale, New Jersey: Lawrence Erlbaum.

Major, N., Ainsworth, S. and Wood, D. (1997). REDEEM: Exploiting Symbiosis Between Psychology and Authoring Environments. International Journal of Artificial Intelligence in Education. Vol. 8, pp.317-340.

Mark, M. A. and Greer, J. (1993). Evaluation Methodologies for Intelligent Tutoring Systems. International Journal of Artificial Intelligence in Education: Special Issue on Evaluation. Vol. 4 (2/3), pp.129-153.

Martorell, J. L. and Prieto, J. L. (2002). Fundamentos de la psicología. Editorial Centro de Estudios Ramón Areces. Colección de Psicología.

Matsuda, N. and VanLehn, K. (2000). Decision Theoretic Intructional Planner for Intelligent Tutoring Systems. In Workshop Proceedings on Modeling Human Teaching Tactics and Strategies, ITS'00. pp. 72-83.

Melis, E., Andres, E., Franke, A., Frischauf, A., Goguadse, G., Libbrecht, P., Pollet, M. and Ullrich, C. (2001). ActiveMath: A Generic and Adaptive Web-Based Learning Environment. International Journal of Artificial Intelligence in Education. Vol. 12, pp.385-407.

Merrill, M. D. (1983). Component Dysplay Theory. In Reigeluth, C. M.,Instructional Design and Models: An overview of their current status. pp. 279-333.: Lawrence Erlbaum Associates.

Miller, E., Swick, R. and Brickley, D. (2004 Mar). Resource Description Framework (RDF) [Web Page]. Accessed 2004 May. Available at: http://www.w3.org/RDF/.

Millán, E. (2000). Sistema bayesiano para el modelado del alumno. PhD thesis, Universidad de Málaga.

Mitrovic, A. and Ohlsson, S. (1999). Evaluation of a Constraint-Based Tutor for a Database Language. International Journal of Artificial Intelligence in Education. Vol. 10, pp.238-256.

Mizoguchi. R. (1998). A Step Towards Ontological Engineering (Translation of the paper presented at the 12th National Conference on AI of JSAI). pp. 24-31.

Mizoguchi. R. and Bourdeau, J. (2000). Using Ontological Engineering to Overcome Common AI-ED Problems. International Journal of Artificial Intelligence in Education. Vol. 11,

229

Referencias

pp.107-121.

Moundridou, M. and Virvou, M. (2002). WEAR: A Web Based Authoring Tool for Building Intelligent Tutoring Systems. In 2nd Hellenic Conf. on AI, SETN-2002. pp. 203-214.

Moundridou, M. and Virvou, M. (2003). Analysis and design of a Web-based authoring tool generating intelligent tutoring systems. Computers & Education. Vol. 40, pp.157-181.

Munro, A., Johnson, M. C., Pizzini, Q. A., Surmon, D. S., Twone, D. M. and Wogulis, J. L. (1997). Authoring Simulation-Centered Tutors with RIDES. International Journal of Artificial Intelligence in Education. Vol. 8, pp.284-316.

Murray, T. (1993). Formative qualitative evaluation for 'exploratory' ITS research. International Journal of Artificial Intelligence in Education: Special Issue on Evaluation. Vol. 4 (2/3), pp.179-207.

Murray, T. (1998). Authoring Knowledge-Based Tutors: Tools for Content, Intructional Strategy, Student Model, and Interface Design. The Journal of Learning Sciences. Vol. 7 (1), pp.5-64.

Murray, T. (1999). Authoring Intelligent Tutoring Systems: an analysis of the state of the art. International Journal of Artificial Intelligence in Education. Vol. 10, pp.98-129.

Murray, T. (2003). MetaLinks: Authoring and Affordances for Conceptual and Narrative Flow in Adaptive Hyperbooks. International Journal of Artificial Intelligence in Education. Vol. 13, pp.199-233.

Murray, W. R. (1989). Control for intelligent tutoring systems: a blackboard-based dynamic instructional planner. In Artificial Intelligence and Education. pp. 150-168.: IOS.

Nakabayashi, K., Maruyama, M., Koike, Y., Kato, Y., Hirofumi, T. and Fukuhara, Y. (1997) Architecture of an Intelligent Tutoring System on the WWW., AIED'97

Newell, A. (1982). The knowledge level. Artificial Intelligence. Vol. 18 (1), pp.87-127.

OIL . Ontology Inference Layer [Web Page]. Accessed 2004 Apr. Available at: http://www.ontoknowledge.org/oil/.

Peachey, D. R. and McCalla, G. I. (1986). Using planning techniques in intelligent tutoring systems. International Journal of Man-Machine Studies. Vol. 24, pp.77-98.

Polson, M. C. and Richardson, J. (1988). Foundations of Intelligent Tutoring Sytems. Hillsdale, N.J.: Lawrence Erlbaum.

PROMETEUS . PROMETEUS: PROmoting Multimedia Access to Education and Training in EUropean Society [Web Page]. Accessed 2005 Dec. Available at: http://www.prometeus.org/.

Promissor. CatGlobal [Web Page]. Accessed 2003 Apr. Available at: http://www.CATGlobal.com.

Pérez, T. A., Gutiérrez, J., López, R., González, A. and Vadillo, J. A. (2001). Hipermedia, adaptación, constructivismo e instructivismo. Inteligencia Artificial, Revista Iberoamericana De Inteligencia Artificial. Vol. 12, pp.29-38.

Razmerita, L., Angehrn, A. and Maedche, A. (2003). Ontology-based User Modeling for Knowledge Management Systems. User Modeling 2003. (Lecture Notes in Artificial

230

Referencias

Intelligence. v. 2702) pp. 213-218.: Springer-Verlag.

Reigeluth, C. M. (1983). Instructional-Design Theories and Models: An overview of their current status. Lawrence Erlbaum Associates.

Reigeluth, C. M. (1996). What Is the New Pradigm of Instructional Theory. [Web Page]. Accessed 2006 Mar. Available at: http://itech1.coe.uga.edu/itforum/paper17/paper17.html.

Reigeluth, C. M. (2000). Diseńo de la instrucción. Teorías y modelos. Un nuevo paradigma de la teoría de la instrucción. Madrid: Aula XXI. Santillana.

Ritter, S, Brusilovsky, P. and Medvedeva, O. (1998). Creating more versatile intelligent learnbing environments with a component-based architecture. In Lecture Notes in computer science. v. 1452) pp. 554-563.: Springer-Verlag.

Ritter, S and Koedinger, K. R. (1996). An architecture for plug-in tutor agents. International Journal of Artificial Intelligence in Education. Vol. 7 (3-4), pp.315-347.

Rodríguez, M (2000). Una arquitectura cognitiva para el diseńo de entornos telemáticos de enseńanza y aprendizaje. Universidad Nacional de Educación a Distancia.

Rosatelli, M. C., Self, J. and Thiry, M. (2000). LeCS: a collaborative case study system. Intelligent Tutoring Systems. 5th International Conference, ITS 2000. Lectures Notes in Computer Science . v. 1839) pp. 242-251.: Springer Verlag.

Rosis, F. (1999). 1st. workshop on Attitude, Personality and Emotions in User-Adapted Interaction (UM'99) [Web Page]. Available at: http://www.cs.usask.ca/UM99/w3.shtml.

Rosis, F. (2001). 2nd Workshop on Attitude, Personality and Emotions in User-Adapted Interaction (UM'01) [Web Page]. Available at: http://www.di.uniba.it/intint/HTMLpages/ws-um01.html.

Russell, D. M. (1988). IDE: The interpreter. In Psotka , J et al. ,Intelligent Tutoring System: Lessons Learned. pp. 323-349.Hillsdale, New Jersey: Lawrence Erlbaum.

Russell, D. M., Moran, T. P. and Jordan, D. S. (1988). The instructional-Design Environment. In Psotka , J et al.,Intelligent Tutoring System: Lessons Learned. pp. 203-228.: Lawrence Erlbaum.

Sampson, D., Karagiannidis, C. and Cardinali, F. (2002). An Architecture for Web-based e-Learning Promoting Re-usable Adaptive Educational e-Content. Educational Technology & Society. Vol. 5 (4), pp.27-37.

Scardamalia, M. and Bereiter, C. (1994). Computer Support for Knoledge-Building Communities. The Journal of Learning Sciences. Vol. 3 (3), pp.265-283.

Schank, R. C., Berman, T. R. and Macpherson, K. A. (1999). Learning by doing. Reigeluth, C. M.,Instructional-Design Theories and Models. Volume II. N.J.: Lawrence Erlbaum Associates.

Schank, R. C. and Cleary, C. (1995). Engines for Education. Erlbaum, Lawrence Associates.

Schreiber, G., Akkermans, H., Anjewierden, A., Hoog, R, Shadbolt, N., Van de Velde, W and Wielinga, B. (1999). The CommonKADS Methodology. The MIT Press.

231

Referencias

SCORM . Sharable Content Object Reference Model. [Web Page]. Accessed 2004 Mar. Available at: http://www.adlnet.org/index.cfm?fuseaction=DownFile&libid=648&bc=false.

Scriven, M. (1967). The methodology of evaluation. Stake, R. E.,Curriculum evaluation. Chicago: Rand-McNally.

Self, J. (1999). The defining characteristics of intelligent tutoring sytems research: ITSs care, precisely. International Journal of Artificial Intelligence in Education. Vol. 10, pp.350-364.

Shortliffe, E. H. (1976). Computer-based medical consultations: MYCIN. American Elsevier.

Shute, V. and Regian, J. W. (1993). Principles for Evaluating Intelligent Tutoring Systems. International Journal of Artificial Intelligence in Education: Special Issue on Evaluation. Vol. 4 (2/3).

Shute, V. and Towle, B. (2003). Adaptive E-Learning. Educational Psychologist. Vol. 38 (2), pp.105-114.

Skinner, B. F. (1954). The science of learning and the art of teaching. Harvard Educational Review. Vol. 24 (2), pp.86-97.

Sleeman, D. and Brown, J. S. (1982). Intelligent Tutoring Systems. Academic Press.

Stash, N., Cristea, A. and De Bra, P. (2005) Explicit Intelligence in Adaptive Hypermedia: Generic Adaptation Languages for Learning Preferences and Styles, International Workshop on Combining Intelligent and Adaptive Hypermedia Methods/Techniques in Web-Based Education Systems (in conjunction with the Sixteenth ACM Conference on Hypertext and Hypermedia)

Stern, Mia K. and Woolf, B. (1998). Curriculum Sequencing in a Web-based Tutor. Proceedings of the 4th International Conference on Intelligent Tutoring Systems. Lecture Notes in Computer Science . v. 1452) pp. 574-583.

Stevens, A. L. and Collins, A. The goal structure of a socratic tutor. Cambridge: Bolt Beranek and Newman, Inc.; 1977; 3923.

Suppes, P. (1981). University-level computer-assisted instruction at Stanford: 1968-1980. Stanford University, Institute for mathematical studies in the social sciences.

SW-EL (2001). 2nd International Workshop on Applications of Semantic Web Technologies for E-Learning [Web Page]. Accessed 2004 Oct. Available at: http://wwwis.win.tue.nl/SW-EL04/.

Szypersky, C. (1999). Component Software. Addison-Wesley.

The Apache Software Foundation (2003). WSIF: Web Services Invocation Framework [Web Page]. Accessed 2004 Jun. Available at: http://ws.apache.org/wsif/index.html.

The HUMAINE Consortium. (2004). Network of Excellence HUMAINE [Web Page]. Available at: http://emotion-research.net/aboutHUMAINE/.

Tong, Amelia K. Y. and Agius, Harry W. (1999). ARISTOTLE: A Multimedia-Based Intelligent Tutoring System for Zoology. Journal of Intelligent Systems. Vol. 9 (2), pp.107-133.

Trella, M., Conejo, R. and Bueno, D. (2001). MEDEA: una arquitectura basada en componentes para el desarrollo de Sistemas Tutores Inteligentes en Internet. Actas de la Conferencia

232

Referencias

Espańola para la Inteligencia Artificial: CAEPIA-2001. pp. 469-478.

Trella, M., Conejo, R., Guzmán, E. and Bueno, D. (2003). An Educational Component Based Framework for Web ITS development. Web Engineering. International Conference, ICWE 2003. Lecture Notes in Computer Science . v. 2722) pp. 134-143.: Springer-Verlag.

Trella, M., Conejo, R. and Guzmán, E. (2000). A Web-Based Socratic Tutor for Tree Recognition. Brusilovsky, P. et al.,Adaptive Hypermedia and Adaptive Web-Bases Systems. Lecture Notes in Computer Science . v. 1892) pp. 239-249.New York: Springer-Verlag.

Trella, M., Conejo, R. and Guzmán, E. (2002). An authonomous component architecture to develop WWW-ITS. In Adaptive Systems for Web based education, AH2002. pp. 69-80.

Twidale, M. (1993). Redressing the balance: the advantages of informal evaluation techniques for intelligent learning environments. International Journal of Artificial Intelligence in Education: Special Issue on Evaluation . Vol. 4 (2/3), pp.155-178.

Urretavizcaya, M. (2001). Sistemas Inteligentes en el ámbito de la educación. Inteligencia Artificial, Revista Iberoamericana De Inteligencia Artificial. Vol. 12, pp.5-12.

VanLehn, K. (1988). Student Modeling. In Polson, M. C.,Richardson, J.,Intelligent Tutoring System . Lawrence Erlbaum.

Vassileva, J. (1997) Dynamic Course Generation on the WWW, AIED'97.

Vassileva, J. and Deters, R. (1998). Dynamic courseware generation on the WWW. British Journal of Educational Technology. Vol. 29 (1), pp.5-14.

Vassileva, J., McCalla, G. I. and Greer, J. (2003). Multi-Agent Multi-User Modelling in I-Help. User Modelling and User Adapted Interaction. Special Issue on User Modelling and Intelligent Agents. Vol. 13 (1), pp.179-210.

Virvou, M. and Moundridou, M. (2001). Adding an Instructor Modellin Component to the Architecture of ITS Authoring Tools. International Journal of Artificial Intelligence in Education. Vol. 12, pp.185-211.

Wan, D. and Johnson, P. (1994). Experiences with CLARE: a computer-supported collaborative learning environment. International Journal of Human-Computer Studies. Vol. 41, pp.851-859.

Wasson, B. (1990). Determining the focus of instruction: content planning for Intelligent Tutoring Systems. PhD thesis, University of Saskatchewan.

WCET (Western Cooperative for Educational Telecommunications) (2004). Edu-tools [Web Page]. Accessed 2004 Aug. Available at: http://www.edutools.info/course/compare/.

Webb, G. (1997) A Theoretical Framework for Internet -Based Training at Sydney Institute of Technology. in: AusWeb 97: The Third Australian World Wide Web Conference

Webber, C., Bergia, L., Pesty, S. and Balacheff, N. (2001). Baghera Project: a Multi-Agent Architecture for Human Learning. Workshop on Multi-Agent Architectures Supporting Distributed Learning in a Wired and Wireless Future. (AIED'01) .

WebCT Accessed 2004 Aug . Available at: http://www.webct.com/.

Weber, G. and Brusilovsky, P. (2001). ELM-ART: An adaptive versatile system for Web-based

233

Referencias

instruction. Special Issue on Adaptive and Intelligent Web-based Educational Systems. International Journal of Artificial Intelligence in Education. Vol. 12 (4), pp.351-384.

Weber, G., Kuhl H.C. and Weibelzahl, S. (2001). Developing Adaptive Internet Based Courses with the Authoring System NetCoach. In Hypermedia: Openness, Structural Awareness and Adaptivity. (Reich, Siegfried , Tzagarakis, Manolis M., and De Bra, Paul M. E. Eds. Lecture Notes in Computer Science pp. 226-238.Berlin: Springer.

Weber, G. and Specht, M. (1997). User Modeling and Adaptive Navigation Support in WWW-based Tutoring Systems. In WWW-based tutoring systems. pp. 289-300.Wien: Jameson, A., PAris, C., & Tasso, C., User Modeling. Springer-Verlag.

Wei F., Moritz S.H., Parvez, S. M. and Blank G.D. (2005). A student model for object-oriented design and programming. Journal of Computing Sciences in Colleges. Vol. 20 (5), pp.260-273.

Wenger, E. (1987a). Artificial Intelligence and Tutoring Systems. Los Altos: Morgan Kaufmann.

Wenger, E. (1987b). Bugs in procedural skills: the 'buggy repair steps' story. In Wenger, E.,Artificial Intelligence and Tutoring Systems. Los Altos: Morgan Kaufmann.

Wenger, E. (1987c). GUIDON: the epistemology of an expert system. In Wenger, E.,Artificial Intelligence and Tutoring Systems. Los Altos: Morgan Kaufmann.

Wenger, E. (1987d). Learning environments: coaching ongoing activities. In Wenger, E.,Artificial Intelligence and Tutoring Systems. Los Altos: Morgan Kaufmann.

Wenger, E. (1987e). SOPHIE: form quantitative to qualitative simulation. In Wenger, E.,Artificial Intelligence and Tutoring Systems. Los Altos: Morgan Kaufmann.

Wenger, E. (1987f). Tutorial dialogues: from semantics nets to mental models. In Wenger, E.,Artificial Intelligence and Tutoring Systems. Los Altos: Morgan Kaufmann.

Wiley, D. A. (2000). Connecting learning objects to instructional design theory: A definition, a metaphor, and a taxonomy. In The Instructional Use of Learning Objects.

Woo, C. (1991). Instructional Planning in an Intelligent Tutoring System: combining global lesson plans with local discourse control. PhD thesis, Illinois Institute of Technology.

Wooldridge, M. (1995). This is MyWorld: The Logic of an agent-oriented tested for DAI. Wooldridge, M.,Jennings, N. R.,Intelligent Agents: Theories, Architectures and Languages. v. 890) pp. 160-178.Germany: Springer-Verlag.

Wooldridge, M. (1999). Intelligent Agents. Weiss, G.,Multiagent Systems. A Modern Approach to Distributed Artificial Intelligence. pp. 27-77.London: The MIT Press.

Wooldridge, M., Jennings, N. R. and Kinny, D. (2000). The GAIA methodology for Agent-Oriented Analysis and Design. Journal of Autonomous Agents and Multi-Agent Systems. Vol. 3 (3), pp.285-312.

Yaskin, D. and Everhart, D. (2002). Blackboard Learning System (Release 6). Product Overview White Paper. [Web Page]. Available at: http://www.blackboard.com/docs/wp/LSR6WP.pdf.

Zhou, Gang, Wang, Jason T. L. and Ng, Peter A. (1996 Oct). Curriculum knowledge representation and manipulation in knowledge-based tutoring systems. IEEE

234

Referencias

Transactions on Knowledge and Data Engineering. Vol. 8 (5), pp.679-689.

Zimmer, J., Franke, A. and Kohlhase, M. (2003 Sep). MATHWEB-SB: A Software Bus for MathWeb [Web Page]. Accessed 2004 Nov. Available at: http://www.mathweb.org/mathweb/.

235

Apéndice 1 DOMINIOS DE LÓGICA Y ECONOMÍA AGRARIA1

Introducción

Proposición

Conectiva

Objeto de la lógica

Proposición atómica

Proposición molecular

NOT AND OR IF..THEN IFF

DOMINIO DE LÓGICA

Sintaxis formal

Lenguaje formal Fórmula

Subfórmula Semántica formal

Tautología Interpretación

Tabla de verdad Reducción Equivalencia lógica Metadefinición de conectivas

Simbolización

Argumentos

Argumento

Validez de argumentos

Cálculo

Deducción

Deducción en CDN

CDN Derivación en CDN Demostración en CDN

Regla básica de inferencia

Concepto de cálculo

Regla de inferencia

Regla de inferencia en CDN

1 Las líneas continuas representan la relación pertenece_a y las discontinuas la de prerrequisito

236

Dominios de lógica y economía agraria

237

La empresa

La empresa y su función

La empresa y su entorno

Los factores que integran la empresa

Marxismo Neocapitalismo Socialdemocracia

DOMINIO DE ECONOMÍA AGRARIA

Patrimonio, balance y beneficio

La empresa y la obtención de beneficio

El empresario y el riesgo

El problema de comercializar

Objetivos de la empresaLa explotación: instrumento al servicio de la empresa

Tipos de empresas

La empresa según distintas ideologías

Doctrina de la Iglesia

La empresa agraria Problemas con los que se enfrenta el empresario agrario

El papel del estado en la agricultura

Patrimonio empresarial El balance Estructura del activo

Estructura del pasivoLa financiación propia El beneficio como las variaciones en el propio Cash Flow

El objetivo de la empresa Rentabilidad y medida del beneficioBeneficio, ventas y capital

Empresario riesgo Beneficio y riesgo Concepto de riesgo

Que es la comercializaciónEl proceso de comercialización Formas de venta

Los costes de la empresa

Actuación colectiva en la ventaVender para sobrevivir

Introducción Clasificación de costes Imputación y prorrateo de costes

Curvas de costes e ingresos Impuestos Amortización

Cuentas de costes

Margen bruto (1) (2) (3)

Apéndice 1

La función de la producción

Productividad y factor humano

Las funciones de la dirección

Planificar Organizar Crear equipo Dirigir Coordinar Informar

Técnicas y factores La función de producción

Óptimo económico

Máximo técnico

¿Qué es la productividad? El factor humano

Medición del trabajo Sistemas de retribución del trabajo

Introducción Funciones del directivo

Presupuestar

Control de la gestión Control de los resultados Relaciones humanas en la empresa

Financiación de la empresa (I)

Financiación de la empresa (II)

El sistema financiero y la empresa

La financiación de la empresa Clasificación de la financiación

Capital circulante

La letra de cambio

Periodo de maduración

Crédito bancario

El proceso de compra

Introducción Préstamos bancarios

Ampliación de capital

Empréstitos (obligaciones)

Autofinanciación

El leasing

Apalancamiento de la empresa

Sistema financiero El Banco de España y el crédito oficial

Otras entidades de financiación

Cajas de Ahorro y Cajas Rurales

La bolsa

Banca privada

Financiación bancaria para las empresas

Productividad media y marginal

Estudio del trabajo: principios fundamentales Mejora de métodos

(1) (2) (3)

(4)

238

Dominios de lógica y economía agraria

239

Selección de inversiones

El problema del tiempo

Definiciones

Criterios de evaluación de inversiones

Flujos de caja

La tasa interna de rendimiento

Introducción al análisis de balances

Ratios económicos

Introducción

Ratios financieros

Relación entre los ratios financieros y los económicos

Análisis dinámico

(4)