hacia una arquitectura para sistemas de e- learning...

Title— Towards a PoEML-based Architecture for E-learning

Systems.

Abstract—The current panorama of Learning Technologies is

composed of not interoperable technological domains. Thus, there

are web-based systems, m-learning systems, and the recent

concept of t-learning systems. In this paper we present a proposal

of architecture to support the interoperability of e-learning

systems, independently of the access technologies used by

participants. That architecture enables the collaboration between

participants in the same learning process, which is formalized by

using the PoEML Educational Modeling Language.

Index Terms—e-learning, ubiquitous computing, Computer

Supported Collaborative Learning, interoperability

I. INTRODUCCIÓN

URANTE los últimos años, las Tecnologías del Aprendizaje se han convertido en un sector estratégico

tanto para empresas como para universidades. E-learning es una palabra que engloba numerosos conceptos tales como aprendizaje a distancia, aprendizaje asistido por ordenador, y muchos otros. A pesar de los recientes avances en la estandarización de las Tecnologías del Aprendizaje, los sistemas de e-learning, tanto propietarios como open-source, son desarrollados sin el suficiente soporte para la interoperabilidad. Las consecuencias de este enfoque son que cada nuevo sistema es desarrollado desde cero, los sistemas no son compatibles, los Contenidos Educativos no son portables entre sistemas y, lo que es peor, las Tecnologías del Aprendizaje no evolucionan al siguiente nivel de desarrollo.

Como en todo ámbito tecnológico que alcanza un cierto estado de desarrollo han aparecido ciertos estándares de facto que intentan hacer compatibles las diferentes tecnologías y unificar esfuerzos. La mayor parte de estas especificaciones se centran en los contenidos de los sistemas de e-learning

Roberto Pérez Rodríguez está en el Departamento de Ingeniería

Telemática, Universidad de Vigo, 36310 Vigo, España (e-mail: [email protected])

Manuel Caeiro Rodríguez está en el Departamento de Ingeniería Telemática, Universidad de Vigo, 36310 Vigo, España (e-mail: [email protected])

Luis Anido Rifón está en el Departamento de Ingeniería Telemática, Universidad de Vigo, 36310 Vigo, España (e-mail: [email protected])

DOI (Digital Object Identifier) Pendiente

(tutoriales, lecciones, ejemplos, exámenes, etc.), definiendo estándares de clasificación, creación y distribución de dichos contenidos.

En los últimos años ha aparecido un nuevo enfoque en cuanto a las especificaciones de diseño centrado en el proceso educativo (o de aprendizaje atendiendo a la denominación en inglés de learning process). El proceso educativo se refiere a la realización y coordinación de las diferentes actividades de una unidad pedagógica (e.g. seminario, jornada, curso académico), en los que no es suficiente con describir los contenidos sino que hay que especificar, por ejemplo, qué tienen que hacer los alumnos, el orden en el que hay que realizar los contenidos, etc.

En la actualidad, la arquitectura de los sistemas de e-learning es dependiente de la tecnología de acceso. De esta manera tenemos sistemas inter-departamentales que dependen de la tecnología de la intranet corporativa, sistemas basados en Web, sistemas basados en la televisión digital, y sistemas basados en dispositivos móviles. Cada uno de estos sistemas presenta habitualmente un diseño monolítico que hace virtualmente imposible su extensión para soportar una tecnología de acceso distinta.

XML es el estándar de mayor utilización para la representación de información de forma independiente de su presentación. Las aplicaciones, al proveer interfaces basadas en XML, pueden ofrecer su funcionalidad independientemente de la tecnología final utilizada por el usuario para acceder a ellas. De esta manera, los Escenarios Educativos pueden contener recursos consumibles desde varias tecnologías de acceso.

En este artículo se presenta una propuesta de arquitectura para sistemas de e-learning que no depende de la tecnología de acceso empleada. Para ello se ha optado por una Arquitectura Basada en Componentes, en la cual cada componente del sistema tiene una funcionalidad independiente y realiza una o varias interfaces bien definidas. De esta manera, el soporte de una nueva tecnología de acceso se logra añadiendo el componente que realice la nueva funcionalidad, permaneciendo el resto del sistema sin cambios.

En nuestra propuesta, un motor de ejecución de procesos educativos es expuesto como un Servicio Web. De esta manera, la lógica de control de los procesos educativos está centralizada, siendo la misma independientemente de la tecnología de acceso empleada por cada participante.

Hacia una arquitectura para sistemas de e-learning basada en PoEML

Roberto Pérez Rodríguez, Manuel Caeiro Rodríguez, Member, IEEE, Luis Anido Rifón, Member, IEEE

D

230 IEEE-RITA Vol. 4, Núm. 3, Ago. 2009

ISSN 1932-8540 © IEEE

Los módulos de integración siguen un enfoque Orientado a Aspectos [1], ya que en puntos bien definidos de la ejecución en la capa de presentación se ejecuta código relativo a diferentes asuntos o aspectos. De esta manera se encapsulan las llamadas desde las capas de presentación a los Web Services de interacción con el motor de ejecución. Estos asuntos guardan relación con las Perspectivas de PoEML (Perspective-oriented Educational Modelling Language) [2][3], el Lenguaje de Modelado Educativo en el cual está basado este sistema de e-learning.

II. PROPUESTA

Nuestra propuesta de arquitectura está basada en el empleo del Lenguaje de Modelado Educativo PoEML. Los EMLs (Educational Modelling Languages) fueron propuestos hace algunos años con el propósito de dar soporte a la creación de modelos de unidades educativas con independencia del enfoque pedagógico. La principal característica de PoEML en su enfoque basado en la separación de asuntos. En lugar de intentar dar soporte al modelado de unidades educativas con un conjunto completo de elementos y relaciones, PoEML considera los diferentes asuntos implicados en las unidades educativas y ofrece diferentes conjuntos de elementos y relaciones para modelar cada asunto.

La propuesta PoEML completa es bastante extensa, ya que comprende 17 asuntos distintos, agrupados en 13 perspectivas y 4 aspectos. Las perspectivas y los aspectos son dos tipos de asuntos ortogonales. A pesar del gran número de perspectivas y aspectos, una propiedad capital de la propuesta PoEML es que las perspectivas y los aspectos pueden ser utilizados de una manera modular. En la práctica, existe sólo una perspectiva que necesita ser siempre considerada en las unidades educativas, el resto son opcionales y se pueden utilizar cuando sea requerido.

El Escenario Educativo es el elemento de construcción básico para crear modelos de unidades educativas. La Figura 1 muestra la estructura de un Escenario Educativo. Básicamente, un Escenario Educativo es un elemento que agrega elementos, especificaciones y expresiones:

• Los elementos representan las entidades contenidas en el Escenario Educativo. Para el propósito de este artículo es suficiente con tener en cuenta que un Escenario Educativo puede incluir: (i) uno o más objetivos que indican qué tiene que ser realizado de un modo declarativo; (ii) uno o varios roles que indican las funciones de los participantes que tienen que ver con la consecución de los objetivos; (iii) uno o varios entornos conteniendo los recursos que pueden ser utilizados por los participantes para desarrollar su trabajo. Cada uno de esos elementos puede incluir otros elementos, tales como elementos de datos, representando propiedades, parámetros o variables. Adicionalmente, un Escenario Educativo puede contener otros Escenarios Educativos agregados jerárquicamente, llamados Subescenarios

Educativos. Es importante destacar que los objetivos de un Escenario Educativo pueden estar relacionados con los objetivos de los Subescenarios que lo componen.

• Las especificaciones representan controles en tiempo de ejecución que tienen que ser aplicados para manejar los elementos contenidos en un Escenario Educativo. En este artículo, las especificaciones principales son la temporal y la de orden.

• Las expresiones implican descripciones correspondientes con los aspectos de PoEML. Representan cuestiones que pueden afectar al comportamiento de los elementos y las especificaciones. Por ejemplo, una expresión de condición determina su resultado de acuerdo con el valor de ciertos elementos de datos.

Figura 1. Estructura de un Escenario Educativo

Para tener un sistema de e-learning en el estado del arte es

suficiente con considerar 4 de las perspectivas de PoEML: • La perspectiva estructural define la estructura de una

unidad educativa en Escenarios y Subescenarios educativos. Esta estructura es análoga al sistema de directorios en un sistema operativo.

• La perspectiva funcional define una estructura de objetivos y subobjetivos. Cada Escenario Educativo debe contener al menos un objetivo. En la Figura 2 se muestra un ejemplo con relaciones entre objetivos y subobjetivos.

• La perspectiva de orden define el orden de realización de los subescenarios contenidos en un cierto Escenario Educativo.

• La perspectiva temporal permite definir instantes concretos de tiempo para la realización de un Escenario Educativo.

Esta estructura permite la descripción de las cuestiones englobadas en los Escenarios Educativos. Es importante

PÉREZ RODRÍGUEZ et al.: HACIA UNA ARQUITECTURA PARA SIST. DE E-LEARNING BASADA EN POEML 231

ISSN 1932-8540 © IEEE

señalar que cada una de las cuestiones englobadas en un Escenario Educativo se incluye como una entidad separada. De esta manera, se facilita la modificación de Escenarios Educativos mediante el reemplazo de elementos específicos, especificaciones o expresiones, facilitando de esta manera la reutilización. Además, durante el tiempo de ejecución es necesario crear instancias de los Escenarios Educativos y de sus elementos. El número de instancias a crear puede ser determinado estáticamente durante el tiempo de diseño o dinámicamente durante el tiempo de ejecución de acuerdo con el resultado proporcionado por expresiones específicas.

Figura 2. Agregación de Escenarios Educativos y objetivos

III. ARQUITECTURA

La Figura 4 muestra un diagrama con la arquitectura del sistema. En las siguientes subsecciones se detalla dicha arquitectura.

A. La máquina de procesos educativos: PoEML Engine

El motor de ejecución de procesos educativos es el componente central del sistema de e-learning [4]. En él se almacena la información relativa a los Escenarios Educativos, participantes, objetivos, y resto de elementos, haciendo evolucionar el estado del sistema dependiendo de los eventos, tanto externos al motor como internos a él, que se producen.

El motor de ejecución se integra en el sistema de e-learning a través de una interfaz bien definida basada en Web Services, garantizando el requisito de la conectividad. Al mismo tiempo, los componentes de presentación deben estar lo más desacoplados que sea posible respecto al motor de ejecución, esto implica utilizar un sencillo conjunto de APIs. La escalabilidad también es un requisito fundamental, al ser el motor de ejecución el componente central del sistema de e-learning.

Eventos generados por el participante: • Comenzar un ES • Finalizar un ES • Intentar un objetivo • Darse de alta/darse de baja

Eventos generados por el motor de ejecución: • Instanciar un ES

• Instanciar un objetivo • Dar por finalizado un objetivo • Hacer accesible/no accesible un ES • Hacer intentable/no intentable un objetivo

Los componentes de presentación también pueden acceder al motor de ejecución de una manera pasiva simplemente para recuperar información, tanto sobre los Escenarios Educativos como sobre los objetivos. Esta recuperación de información está asociada a la navegación por los Escenarios Educativos:

• Conseguir la información relativa a un Escenario Educativo

• Conseguir la información de los subescenarios de un cierto ES

Un Escenario Educativo tiene que ser instanciado para que un usuario pueda acceder a él. Este caso es similar a la instanciación en un lenguaje de programación orientado a objetos, donde un objeto tiene que ser instanciado antes de poder acceder a sus atributos y métodos. En el caso que nos ocupa, un Escenario Educativo puede estar también en los estados Iniciado y Finalizado. La Figura 3 muestra todos los posibles estados de ejecución en que puede estar un Escenario Educativo.

Un evento externo al motor de ejecución como el acceso a un Escenario Educativo puede desencadenar varios eventos internos al motor de ejecución como la instanciación de sus Subescenarios Educativos. Al mismo tiempo, se impone la restricción de que dichos Subescenarios Educativos tengan un objetivo propuesto. Este comportamiento es un problema bien conocido, que se resuelve mediante reglas Evento-Condición-Acción:

• Evento: un participante accede a un Escenario Educativo

• Condición: que el Subescenario tenga un objetivo propuesto

• Acción: instanciar el Subescenario

Figura 3. Posibles estados de ejecución de un Escenario Educativo

De una manera similar, el motor de ejecución tiene que manejar los eventos relativos a los objetivos de los Escenarios Educativos. El participante puede generar el evento de intentar objetivo, con los posibles resultados de éxito y fracaso. Este evento genera en el motor de ejecución los eventos de


ISSN 1932-8540 © IEEE

instanciación de los objetivos que presentan una relación de completitud con el objetivo intentado.

En resumen, la interacción entre los componentes de presentación y el motor de ejecución puede ser tanto la

recuperación pasiva de información relativa a los Escenarios Educativos como la comunicación de eventos generados por el participante.

Figura 4. Arquitectura del sistema de e-learning

A. La capa de middleware

Para facilitar que los Servicios Web sean accesibles desde los módulos de presentación se hace uso de las funcionalidades que provee un motor SOAP. De esta manera los módulos de presentación tienen una interacción desacoplada con el motor de ejecución de procesos educativos.

La funcionalidad que provee el motor de ejecución de procesos educativos se publica en un archivo WSDL. Los métodos de servicio son tanto para la recuperación pasiva de información como para la comunicación de eventos generados por el participante.

B. Los módulos de presentación dependientes de l dominio tecnológico

Cada Servidor de Presentación se describe como un componente multicapa:

• La capa de middleware consiste en una implementación del protocolo SOAP, para acceder desde cada Servidor de Presentación al motor de ejecución de procesos educativos.

• La capa de aspectos contiene el código de integración, encapsulando las invocaciones a los Web Services del motor de ejecución en aspectos.

• La capa iTV/Web/dispositivo móvil contiene el código dependiente de cada dominio tecnológico.

IV. CASOS DE APLICACIÓN

A. Moodle

En nuestro estudio de los sistemas de e-learning nos hemos encontrado con que los sistemas open-source tienen cada vez

una aceptación mayor. Moodle [5] es el Sistema de Gestión del Aprendizaje (Learning Management System, LMS) más utilizado, con millones de usuarios (moodlers) a lo largo de todo el mundo. Su licencia GPL, su estabilidad, y la gran comunidad de usuarios y desarrolladores, son los principales motivos de su popularidad.

Moodle sigue un enfoque constructivista. Los estudiantes no son solamente consumidores de contenidos de aprendizaje, sino creadores de contenidos también. De esta manera, el conocimiento es construido por la comunidad. Para dar soporte al enfoque constructivista, Moodle cuenta con herramientas colaborativas que ponen en contacto a los participantes entre sí y con los contenidos.

Hemos evaluado a Moodle descomponiendo el problema siguiendo el principio de separación de asuntos como sigue:

• Desde un punto de vista estructural, la manera en la que Moodle estructura los contenidos es muy rígida, ya que sólo permite diseñar cursos compuestos de secciones sobre las que se agregan los recursos educativos. La estructura de contenidos es una jerarquía: curso, sección, recurso.

• Desde un punto de vista temporal, Moodle permite liberar contenidos semanalmente. No permite definir instantes arbitrarios de tiempo en los que liberar contenidos.

• Desde un punto de vista de orden de realización, Moodle no permite definir secuencias ordenadas de realización de contenidos educativos.

En la actualidad estamos trabajando en el desarrollo de la capa de aspectos para la integración de Moodle con el motor


ISSN 1932-8540 © IEEE

de ejecución de procesos educativos [6]. El enfoque para esto está basado en la programación orientada a aspectos. El Desarrollo Software Orientado a Aspectos (Aspect-oriented Software Development) es un paradigma que permite modularizar asuntos entrecruzados (crosscutting concerns), esto es, código que no puede ser capturado en módulos utilizando el mecanismo de descomposición presente en el lenguaje de programación empleado. En el caso de Moodle, las unidades de modularización son scripts PHP, y los nuevos asuntos entrecruzan multitud de scripts PHP pertenecientes al código fuente de Moodle. El procedimiento para añadir un nuevo asunto a Moodle es:

• Listar los puntos la ejecución de Moodle donde ese asunto tiene que ser tenido en cuenta. Esos puntos se definen como joinpoints

• Un pointcut se define como un conjunto de joinpoints

• El último paso es definir el código advice a ejecutar en cada pointcut. El código advice encapsula las llamadas a los Web Services del motor de ejecución de procesos

B. iTV

Consideramos que la experiencia de los participantes en los sistemas de t-learning sería enriquecida al integrar un motor de ejecución de procesos educativos no perteneciente al dominio de la iTV (Interactive Television).

Se utiliza un servidor DVB (Digital Video Broadcasting) para el streaming, mientras que los Web Services que provee el motor de ejecución controlan el proceso de aprendizaje. El participante debe contar con un receptor MHP (Multimedia Home Protocol).

C. M-learning

Se llama m-learning al aprendizaje a través del uso de dispositivos móviles. Estos dispositivos móviles son una de las tecnologías más prometedoras para el soporte del aprendizaje, ya que el participante puede acceder al sistema en cualquier tiempo y lugar. Este enfoque se ajusta especialmente bien en escenarios colaborativos, donde los participantes pueden colaborar entre sí mediante el uso de un dispositivo móvil.

Cuando se accede a un Escenario Educativo desde un dispositivo inalámbrico móvil, el sistema tiene que saber cómo ensamblar los contenidos para posteriormente enviarlos al dispositivo móvil. Además, la información relativa a un Escenario Educativo debe ser formateada para ajustarse a dicho dispositivo.

Con nuestro enfoque, dispondríamos de un módulo de presentación para m-learning capaz de comunicarse con los dispositivos móviles utilizando los protocolos de comunicación empleados en las redes inalámbricas. Este módulo de presentación consumiría los Web Services que provee el motor de ejecución de PoEML. Así, el funcionamiento es muy similar a un sistema basado en Web, ya que hacemos separación del código dependiente del dominio tecnológico (web, dispositivos móviles, iTV) del

código independiente del dominio (el motor de ejecución de procesos educativos).

V. LA EXTENSIÓN DE MOODLE

La extensión que hemos desarrollado se compone de un nuevo tipo de curso con tres vistas: la vista en tiempo de ejecución (run-time), la herramienta de autoría, y la vista de monitorización. En esta sección detallaremos estas tres vistas.

Antes de detallar los diferentes entornos, es importante describir el concepto de descripción del curso, así como el de instancia de curso. Una descripción de curso es análoga a una clase en la Programación Orientada a Objetos: una guía a partir de la cual los objetos son creados. De esta manera, múltiples instancias de curso pueden ser creadas a partir de una descripción de curso: una por estudiante.

En los cursos Moodle actuales, se necesita simplemente un esquema de base de datos para guardar la descripción de cursos. En nuestro caso, necesitamos un esquema de base de datos para las descripciones de cursos y otro para las instancias de cursos en tiempo de ejecución.

A. El entorno de autoría

El proceso de autoría consiste en una serie de operaciones atómicas. En el conjunto de operaciones posibles hay algunas como:

• Añadir/editar/borrar un Escenario • Añadir/editar/borrar un Objetivo • Añadir/editar/borrar un recurso/actividad

Los cambios atómicos son validados para asegurar que son consistentes con el diseño general del curso. Después de haber verificado su consistencia, el cambio atómico se compromete contra el esquema de base de datos que contiene las descripciones de cursos. El nivel de granularidad puede ser fijado como se desee: una operación atómica puede consistir en añadir un Objetivo con todos sus campos constituyentes, o puede ser editar un Objetivo previamente creado y cambiar sólo un campo. El proceso de autoría consistente en cambios atómicos presenta algunas ventajas valorables:

• Los cambios atómicos son inmediatamente vistos por otros co-autores

• No hay necesidad de un chequeo de la consistencia como el que se necesita al importar un archivo que contiene una descripción de un curso completo

El chequeo de la consistencia es aún necesario para el soporte de la interoperabilidad. Las descripciones de cursos siguen el modelo de datos de PoEML. Por los tanto, las descripciones de cursos pueden ser exportadas desde su esquema de base de datos a archivos XML. Así, un archivo XML que contiene una descripción de curso puede ser importado en otro LMS compatible con PoEML.

La Figura 5 muestra el proceso de autoría de varios expertos trabajando en el mismo diseño. Los co-autores realizan cambios atómicos en el diseño del curso, y esos cambios son comprometidos contra el esquema de base de datos de las descripciones de cursos. El diseño del curso puede ser testeado


ISSN 1932-8540 © IEEE

''al vuelo'' creando una nueva instancia de curso y testeándola en el entorno de tiempo de ejecución. La figura también muestra que los archivos que contienen descripciones de cursos pueden ser importados y exportados en la base de datos del LMS Engine.

Figura 5. Nuestro enfoque para la autoría de cursos

B. El entorno de tiempo de ejecución

La Figura 6 muestra una captura de pantalla del entorno de tiempo de ejecución para un participante en un curso. Consiste en cuatro vistas de curso: vista Estructural, vista de Escenarios en árbol, vista de Objetivos, y vista Funcional. Comenzamos la exposición con la vista Estructural.

Cuando un participante es enrolado en un curso, se le asigna una instancia de curso. En ese momento, la vista estructural del curso se presenta en el navegador. Las partes principales de esa página son la barra de navegación (hilo de Ariadna), los Objetivos, los Entornos y los Subescenarios.

La barra de navegación o hilo de Ariadna muestra en cada momento el nivel de agregación en el cual está el participante. La caja de Objetivos muestra todos los Objetivos para el Escenario actual. El color de cada Objetivo es una indicación de su estado. Los posibles estados son: No Propuesto, No Intentable, Intentable, Pendiente, Completado, y Fallido. Cada caja de Objetivo puede ser expandida para ver la información sobre las restricciones de entrada/salida, así como los parámetros de entrada/salida.

Los recursos y actividades educativos están contenidos en una caja de Entornos. Un entorno contiene recursos y

actividades nativos de Moodle, tales como cuestionarios, foros y wikis. Al fondo de la página se presentan los Subescenarios.

En la vista Funcional, el participante puede ver el estado de los Objetivos y una lista de todos los Entornos necesarios para completar cada Objetivo. Dependiendo del Objetivo en el cual esté trabajando el participante, se muestran los Entornos.

La vista de Escenarios en árbol (Figura 7) y la vista de Objetivos muestran un mapa del estado actual de los Escenarios y Objetivos para una cierta instancia de curso. Esas dos vistas pueden resultar de ayuda para ver qué Objetivos han sido completados y cuáles permanecen pendientes.

Figura 6. Captura de pantalla del entorno de tiempo de ejecución

Figura 7. Vista en árbol de la jerarquía de Escenarios

C. El entorno de monitorización

La característica de monitorización del curso está disponible para el rol de profesor. Esta característica se divide en dos vistas diferentes:

• Monitorización por elemento de curso (dirigida por elemento)

• Monitorización de todos los elementos por estudiante (dirigida por estudiante)


ISSN 1932-8540 © IEEE

La Figura 8 muestra la monitorización de un objetivo. En la parte superior de la página, podemos ver los posibles estados de un Objetivo y el número de estudiantes por estado. Se usa un histograma para mostrar esa información de una manera gráfica. En la parte inferior de la página, podemos ver una tabla detallando el estado de cada Objetivo para cada estudiante enrolado en el curso.

Las Variables y las Expresiones de Datos pueden ser también monitorizadas. Las Variables pueden servir para expresar la nota de un estudiante en un cierto cuestionario. Las Expresiones de Datos sirven para componer decisiones que dependen del rendimiento del alumno, por ejemplo, una decisión que depende de la nota de un alumno en un cuestionario.

La otra vista de monitorización disponible es la dirigida por estudiante. Esa vista es apropiada para monitorizar la progresión de un alumno a través de los itinerarios del curso.

Figura 8. Captura de pantalla del entorno de monitorización.

VI. TRABAJO RELACIONADO

A. CopperCore

CopperCore [7] es la implementación de referencia de un IMS Learning Design engine y también provee un player basado en ese engine. El objetivo fue proporcional una fuente de información para implementar otros players compatibles con LD. En la práctica ha sido visto como el player de referencia y herramienta para ejecutar diseños y para validar otras herramientas de LD tales como editores, herramientas de autoría, etc.

Los objetivos de CopperCore incluían testear si el diseño de la API permitía que un thin client fuese construido encima del engine a un coste reducido; y dar una indicación de la funcionalidad que se esperaba de los IMS-LD players. Rendimiento y escalabilidad no son contempladas por CopperCore, aunque se espera que sea uno de los objetivos de los IMS-LD players en producción.

A nivel interno CopperCore utiliza una máquina de estados finita (FSM - Finite State Machine) para evaluar propiedades y secuenciar condicionalmente el contenido. Por cada UoL importada se crea una FSM y un árbol de actividades es adjuntado a cada estado y mostrado al usuario cuando tal estado es alcanzado.

Los siguientes players utilizan CopperCore: • SLED [8], Service-based Learning Design system.

Está enfocado en el uso de web services: la comunicación entre el engine y el player es realizada usando web services. Herramientas adicionales y para usuarios finales (e.g. sistemas de conferencia) fueron construidas orientadas a web services. SLeD presenta mayor funcionalidad que el básico CopperCore engine. Por ejemplo, el CopperCore engine sólo es capaz de indicar que el diseño de aprendizaje necesita un foro, mientras que SLeD muestra el foro, ejecutándolo a través del servicio de conferencia.

• El incluido en el proyecto Reload [9]. Este proyecto provee una familia de herramientas relacionadas con las especificaciones IMS, desde el ampliamente utilizado IMS-CP packager hasta un IMS-LD editor. Su implementación está basada en las plataformas Java y JBoss. Su funcionalidad incluye: importar/borrar de Learning Designs en el CopperCore engine con una simple interfaz gráfica, leer automáticamente un Learning Design y poblar el engine con un usuario activo por cada rol encontrado dentro del manifiesto (pueden ser añadidos usuarios a medida también), etc.

B. GRAIL

GRAIL (Gradient-lab RTE for Adaptative IMS-LD in .LRN) es el entorno de ejecución de IMS-LD implementado en .LRN. Ha sido concebido para ser utilizado dentro del contexto de una comunidad .LRN, un conjunto de usuarios compartiendo recursos tales como documentos, foros, calendarios, etc. Un curso es simplemente una instancia de una de esas comunidades. Como suele ser el caso, y IMS-LD no es una excepción, las especificaciones no incluyen detalles de cómo debe ser implementado el RTE (Run-Time Environment). Esto normalmente se traduce en un amplio conjunto de decisiones que tiene que tomar el equipo de diseño. Tienen que ver con importantes aspectos de la usabilidad y efectividad del entorno de ejecución y por lo tanto tienen que ser cuidadosamente consideradas.

Otros entornos de ejecución de IMS-LD como CopperCore utilizan un modelo de máquina de estados finitos (FSM) para evaluar propiedades y secuenciar el contenido condicionalmente. Para cada Unidad de Aprendizaje (UOL- Unit Of Learning) importada, una máquina de estados finitos es creada y un árbol de actividades es creado para cada estado y mostrado al usuario cuando el estado es alcanzado.

La evaluación de una condición debe conducir a un árbol de actividades nuevamente calculado, conteniendo sólo aquellos


ISSN 1932-8540 © IEEE

recursos visibles para un usuario y/o un rol. Propiedades y condiciones pueden estar relacionadas con dependencias arbitrariamente complejas. Cuando el valor de una propiedad es cambiado, todas las condiciones referidas a ella necesitan ser reevaluadas. Tal evaluación puede desencadenar nuevos cambios de valor en más propiedades. Como consecuencia, el entorno de ejecución aplica esos pasos iterativamente hasta que no cambia el valor de ninguna propiedad más, esto es, alcanzando el nuevo estado. Este proceso tiene el riesgo de entrar en un bucle infinito (los cambios de valor en las propiedades no alcanzan un estado estacionario, sino que oscilan) lo cual denotaría una Unidad de Aprendizaje (UOL) incorrecta, pero el entorno de ejecución necesita proporcionar algún mecanismo para evitarlo.

La aproximación tomada en GRAIL es ligeramente diferente de una máquina de estados. No se definen estados predefinidos cuando se carga la UoL, en su lugar son calculados bajo demanda cuando la UoL es ejecutada. El entorno de ejecución almacena la relación de dependencia entre propiedades y condiciones. El valor inicial de todas las condiciones se obtiene cuando se instancia una nueva ejecución de la UoL. Desde ese punto, cuando una propiedad cambia de valor solamente se reevalúan las condiciones relacionadas. Para evitar bucles infinitos el sistema deja de evaluar condiciones si una propiedad cambia de valor más veces que un límite dado, el cual debe ser elegido suficientemente alto.

En build-time, las condiciones son guardadas en la base de datos tal y como se definen en la descripción de la UoL, con su código XML. La evaluación de condición significa parsear este XML reemplazando propiedades por sus valores correspondientes. Este esquema facilita una hipotética edición de condiciones cuando un error es detectado.

Las siguientes entidades utilizan .LRN: • MIT Sloan School of Management .LRN aloja sobre

11000 usuarios y sobre 3000 sesiones concurrentes. Se estima que .LRN fue desplegado y mantenido con aproximadamente el 25% del coste de soluciones basadas en software comercial.

• Harvard Univ. Executive Education Project. • Vienna Univ. of Economics and Business Admin. Es

una de las instancias de .LRN mayores. Sirve alrededor de 20000 usuarios, contiene 26000 recursos educativos y soporta de media unas 600 conexiones.

• Universidad de Valencia. Esta universidad requería una plataforma para soportar 40000 usuarios. Después de estudiar plataformas como Moodle, Atutor, WebCT y ILIAS, su elección fue .LRN debido a su combinación de escalabilidad y extensibilidad.

VII. CONCLUSIONES

El uso de un lenguaje de modelado nos proporciona el marco conceptual para desarrollar un sistema de e-learning. Al

modelar las unidades educativas de una manera independiente de la tecnología logramos que los participantes puedan colaborar en el mismo proceso de aprendizaje independientemente de la tecnología de acceso que cada participante use para conectarse al sistema de e-learning.

El uso de estándares como XML y los Web Services nos proporciona el necesario desacoplamiento entre la lógica de control del proceso de aprendizaje y la tecnología empleada para la presentación final de los contenidos al participante.

Debido a que todo participante en un proceso de aprendizaje debe ver el mismo estado se hace necesario centralizar el motor de ejecución de procesos.

La interacción de los servidores de presentación con el motor de ejecución se realiza a través de una sencilla interfaz mediante la que se recupera información de una manera pasiva y mediante la que se comunican eventos generados por el participante al motor de ejecución de procesos de aprendizaje.

Los módulos de integración de los servidores de presentación con el motor de ejecución siguen un enfoque Orientado a Aspectos.

De esta manera, y siguiendo la descomposición en Perspectivas del lenguaje PoEML, se encapsulan las llamadas a los Web Services que provee el motor de ejecución de procesos de aprendizaje.

AGRADECIMIENTOS

Este trabajo ha sido financiado parcialmente por el programa eContentplus ECP 2007 EDU 417008 (www.aspect-project.org), un programa Comunitario multianual cuyo objetivo es crear contenidos digitales más fácilmente accesibles, usables y explotables.

Igualmente, queremos agradecer al Ministerio de Educación y Ciencia su financiación parcial a este trabajo a través del proyecto TIN2007-68125-CO02-02 (Servicios Adaptativos para E-learning basados en estándares).

REFERENCIAS

[1] R. E. Fillman, T. Elrad, S. Clarke, and M. Aksit, Eds., Aspect-Oriented Software Development. Boston: Addison-Wesley, 2005.

[2] M. Caeiro, Contribuciones a los lenguajes de modelado educativo. Universidad de Vigo, 2007.

[3] M. C. Rodríguez, M. J. Marcelino, M. L. Nistal, L. E. Anido-Rifón, and A.J. Mendes, “Supporting the Modeling of Flexible Educational Units. PoEML: A Separation of Concerns Approach.” J. UCS, vol. 13, no. 7, pp. 980-990, 2007.

[4] R. Perez-Rodriguez, M. Caeiro-Rodriguez, and L. Anido-Rifón, “Basic Perspective Support of a PoEML-conformant Component-based LMS Engine”, in Proceedings of the X Simposio Internacional de

Informática Educativa, 2008. [5] (2009, Mar.) Moodle. [Online]. Available: http://moodle.org [6] R. Perez-Rodriguez, M. Caeiro-Rodriguez, and L. Anido-Rifon,

“Supporting PoEML Educational Processes in Moodle: a Middleware Approach”, in Proceedings of the V Simposio Pluridisciplinar sobre Diseño y Evaluación de Contenidos Educativos Reutilizables, 2008.

[7] (2009, Mar.) Coppercore. [Online]. Available: http://www.coppercore.org

[8] (2009, Mar.) Sled. [Online]. Available: http://www.elearning.ac.uk/features/sledproject

[9] (2009, Mar.) Reload. [Online]. Available: http://www.reload.ac.uk


ISSN 1932-8540 © IEEE

Roberto Pérez Rodríguez es Ingeniero de Telecomunicación (2008) en la especialidad de Telemática por la Universidad de Vigo. Actualmente es estudiante de doctorado en el Departamento de Ingeniería Telemática de la Universidad de Vigo y realiza labores docentes como Profesor Invitado en dicho departamento. Su labor investigadora está centrada en la utilización de Arquitecturas Orientadas a Servicios para proveer servicios de e-learning.

Manuel Caeiro Rodríguez es Ingeniero de Telecomunicación (1999) y Doctor Ingeniero de Telecomunicación (2007) por la Universidad de Vigo. Actualmente es Profesor Contratado Doctor en el Departamento de Ingeniería Telemática de la Universidad de Vigo realizando tareas docentes relacionadas con la ingeniería del software y la arquitectura de ordenadores. En cuanto a la investigación su interés principal se centra en la aplicación de las Tecnologías de la Comunicación y

la Información a la educación, en especial en el marco de los lenguajes de modelado educativo.

Luis Anido Rifón es Ingeniero de Telecomunicación cum laude (1997) en las especialidades de Telemática y Comunicaciones, y Doctor Ingeniero de Telecomunicación cum laude (2001) por la Universidad de Vigo. Actualmente es Profesor Titular de Universidad en el Departamento de Ingeniería Telemática de la Universidad de Vigo y ocupa el puesto de Director del Área de Innovación Educativa de la

Universidad de Vigo. Ha recibido varios premios por el W3C, la Royal Academy of Sciences y la Colegio Oficial de Ingenieros de Telecomunicación. Es autor de más de 180 artículos en revistas y congresos. Es también el director del Programa Gallego de Investigación en TIC, secretario técnico de AENOR CTN71 SC36 y el director de la delegación española de ISO/IEC JTC1 SC36.


ISSN 1932-8540 © IEEE

hacia una arquitectura para sistemas de e- learning...

Documents