visor de paquetes scorm para la plataforma educativa

VISOR DE PAQUETES SCORM PARA LA PLATAFORMA EDUCATIVA
ZERA
SCORM PACKAGE VIEWER FOR ZERA EDUCATIONAL PLATFORM
Pedro Ernesto Matos Santana1, Adriel Alfaro Castro2, Susana Vidal Cabezas3, Amado Lázaro
Sola Santana4
1 Fortes. Centro de Tecnologías para la Formación. Universidad de las Ciencias Informáticas,
pedroernesto@uci.cu, 837-2266
2 Fortes. Centro de Tecnologías para la Formación. Universidad de las Ciencias Informáticas,
adriel@uci.cu, 690-4601
3 Fortes. Centro de Tecnologías para la Formación. Universidad de las Ciencias Informáticas,
scabezas@uci.cu, 860-3534
4 Fortes. Centro de Tecnologías para la Formación. Universidad de las Ciencias Informáticas,
amado@uci.cu, 837-3106
La Habana, Octubre 2013
RESUMEN
Para el desarrollo de los procesos educativos actuales se conciben tecnologías que
rompen con los estereotipos tradicionales del proceso de enseñanza-aprendizaje, tal es
el caso de los Sistemas de Gestión de Aprendizaje (LMS). La heterogeneidad presente
en estos sistemas permite la utilización de estándares que garantizan la reutilización y
comunicación de recursos y contenidos, tal es el caso del Modelo de Referencia de
Contenidos Compartibles (SCORM). Los elementos presentes en un paquete de
contenidos SCORM pueden ser utilizados como recursos independientes, o mostrarse
al usuario como un todo (curso SCORM), en cuyo caso sería necesaria una
herramienta para su visualización. La presente investigación muestra el desarrollo de
un sistema que permita la visualización de los cursos contenidos en los paquetes
SCORM en la Plataforma Educativa ZERA y que logre la interacción de los usuarios
con dichos cursos. Para el desarrollo de la solución se analizaron los elementos que
deben ser implementados en un visor de paquetes SCORM así como las herramientas
utilizadas para concebirlos, todo sobre la base del Proceso Unificado de Rational
(RUP). Se realizó un levantamiento bibliográfico de los conceptos asociados al objeto
de estudio y se describen las clases y archivos principales que sustentan el sistema. El
resultado de la investigación, muestra un módulo que permite visualizar los cursos
contenidos en los paquetes SCORM, garantiza además el establecimiento de sesiones
de comunicación entre los usuarios de la Plataforma y estos cursos, en las que se
genera y modifica información referente a esta interacción.
Palabras Clave: curso, SCORM, visor, estándares, LMS, interacción
ABSTRACT
Current technologies are designed for the development of educational processes and
to break traditional stereotypes of the teaching-learning process, as in the case of the
Learning Management Systems (LMS). The heterogeneity present in these systems
allows the use of standards that guarantee the reuse and communication of resources
and contents, such is the case of Shareable Content Reference Model (SCORM). The
elements present in a SCORM content package can be used as independent resources,
or displayed to the user as a whole (SCORM course), in which case it would require a
tool for viewing them. This research shows the development of a system to display
SCORM courses content in packages, in ZERA educational platform and achieve the
interaction of users with these courses. For the development of the solution were
analyzed elements that should be implemented on a SCORM package viewer and the
tools used to conceive it, all based on the Rational Unified Process (RUP). The literature
of the concepts associated to the investigation was thoroughly analyzed and the main
classes and files that support the system are described. The result of the research
shows a module that displays courses content in SCORM packages. This module also
guarantees the establishment of communication sessions between users of the platform
and the courses, which generates and modifies information concerning this interaction.
KeyWords: course, SCORM, viewer, standards, LMS, interaction
1. INTRODUCCIÓN
Los procesos educativos actuales utilizan en gran medida las Tecnologías de la
Información y las Comunicaciones (TIC). La influencia de estas en la enseñanza ha
logrado una mayor comunicación e interacción entre docentes y estudiantes, así como
la construcción distribuida de crecientes fuentes de información. Han sido superadas las
barreras de espacio y tiempo así como las limitantes geográficas y los estereotipos
tradicionales del proceso de enseñanza-aprendizaje, dando lugar a un modelo que se
define como e-learning1.
El desarrollo de estos procesos, ha dado al traste con el surgimiento y evolución de
herramientas denominadas Sistemas de Gestión de Aprendizaje (LMS, por sus siglas
en inglés). Estos sistemas para el manejo de la enseñanza virtual basados en la web,
permiten la gestión de usuarios, contenidos y recursos, además de la administración de
materiales y actividades para el aprendizaje.
La Universidad de las Ciencias Informáticas tiene entre sus propósitos el desarrollo
de proyectos de carácter informático para Cuba y el resto del mundo. Específicamente
en el Centro de Tecnologías para la Formación (FORTES), de la Facultad 4, se
encuentra el proyecto Alfaomega, inmerso en el desarrollo y soporte de la Plataforma
Educativa ZERA, producto que tiene entre sus objetivos la gestión de contenido
educativo para el aprendizaje.
La Plataforma Educativa ZERA se apoya en el estándar Modelo de Referencia de
Contenidos Compartibles (SCORM, por sus siglas en inglés), en su tercera edición
publicada en el año 2004. SCORM es un conjunto de normas técnicas y
especificaciones para el desarrollo, empaquetamiento y distribución de material
educativo en cualquier momento y lugar, permitiendo un producto que garantice la
reusabilidad2, accesibilidad3, interoperabilidad4 y durabilidad5.
1
Educación electrónica.
Es la flexibilidad de incorporar componentes educativos en múltiples aplicaciones y contextos.
3
Es la capacidad para localizar y acceder a componentes de aprendizaje situados en una localización remota y
suministrarlos a otras localizaciones.
4
Es la habilidad de poder utilizar en distintas plataformas componentes educativos creados con diferentes
herramientas y desde cualquier ubicación.
5
Es la capacidad de un componente educativo de hacer frente a los cambios tecnológicos sin un rediseño,
2
1
A través del proceso de desarrollo de la Plataforma, se han llevado a cabo varias
investigaciones que han abordado las principales necesidades o carencias que
afloraban en la misma, y le han dado solución a muchas de ellas. Entre las deficiencias
identificadas resaltaba la necesidad de lograr la interoperabilidad e intercambio de
contenidos y recursos entre plataformas que cumplieran con el estándar SCORM 2004
en su tercera edición. Como solución se desarrollaron funcionalidades que permiten la
exportación e importación de recursos educativos, acorde a lo establecido por el
estándar. Pese a esto, los paquetes SCORM solo son usados para importar recursos a
la Plataforma, perdiéndose la intención didáctico-pedagógica con la que fueron creados
y el objetivo principal del estándar (importar y exportar cursos, para su reutilización en
diferentes plataformas). Una vez importado el paquete a la Plataforma, no existe la
posibilidad de visualizar el contenido del curso que este posee, según su estructura
inicial. En busca de una solución, se desarrolló el análisis y diseño de un visor de
paquetes SCORM, que sentó las bases para la posterior implementación de un visor
que cumpliese con las especificaciones dictadas por el estándar.
Han surgido además otras limitantes que no se tuvieron en cuenta en los estudios
realizados anteriormente, específicamente nuevas vías de importación de los paquetes
por diferentes roles de la Plataforma y configuraciones afines, otras alternativas para la
visualización de los cursos contenidos en los paquetes SCORM, así como algunas
deficiencias referentes a la aplicación de los requisitos del estándar, por todo esto se
han realizado modificaciones sobre el análisis y diseño existente con el fin de optimizar
el funcionamiento del sistema.
2. CONTENIDO
Existe un grupo de conceptos cuyo dominio es necesario para comprender y
desarrollar la siguiente investigación. Se enfoca el estudio que se brinda a continuación
en un análisis de las diferentes herramientas encargadas de la visualización de
paquetes SCORM en plataformas educativas y las características que estas pueden
brindar para la pesquisa. Se hace mención además de los lenguajes, tecnologías y
reconfiguración o sobrescribir el código.
2
herramientas empleadas.
2.1 Estándares y especificaciones
Los términos “estándar” y “especificación” presentan cierta dependencia o similitud
entre sí. Si pretendemos referirnos a un patrón, una tipificación o una norma sobre
cómo realizar algo, entonces estamos en presencia de un estándar. Podemos
clasificarlos en: estándares de jure, si estos provienen de una organización acreditada
que certifica una especificación, y estándares de facto, si la especificación es adoptada
por un grupo mayoritario de individuos. Regularmente de una especificación deriva un
estándar, de un conjunto de declaraciones detalladas y exactas de los requisitos
funcionales y particularidades de lo que quiere construirse, instalarse o manufacturarse.
Otros criterios a considerar para definir el término estándar se muestran a
continuación.
"Los
estándares
son
acuerdos
(normas)
documentados
que
contienen
especificaciones técnicas u otros criterios precisos para ser usados consistentemente
como reglas, guías, o definiciones de características para asegurar que los materiales,
productos, procesos y servicios se ajusten a su propósito”. [1]
2.2
SCORM
SCORM es un estándar de e-learning que permite la creación y empaquetado de
contenidos educativos digitales, está encaminado además a lograr la accesibilidad,
durabilidad, interoperabilidad y la compatibilidad entre diversos sistemas. Fija una serie
de normas o políticas a cumplir por los materiales educativos y por las plataformas
encargadas del uso de estos de forma que ambos puedan comunicarse, interactuar y
funcionar en conjunto.
El contenido de un paquete SCORM está compuesto por diferentes elementos, y la
estructura en que se organizan los mismos está definida en el manifiesto (metadatos,
organizaciones, recursos y submanifiestos), un archivo XML que contiene la descripción
de los contenidos encapsulados. Más argumentos pueden ser encontrados en la
investigación precedente. [2]
2.3
SCO
Un Objeto de Contenido Compartible (SCO, por sus siglas en inglés) es la unidad
3
mínima de la que se puede componer un curso SCORM. Lo habitual es que el curso
esté integrado por un conjunto de SCO organizados de forma jerárquica (por ejemplo
módulos y capítulos).
El SCO incluye el código de programación necesario para establecer la
comunicación con el LMS. Dicha comunicación se establece a través de la API, y el
SCO debe tener los mecanismos necesarios para encontrarle e iniciar y terminar la
sesión de comunicación. Además, es posible pero no obligación, que entre el SCO y el
LMS se intercambie información, como por ejemplo, los detalles del progreso del
alumno y tiempo de interacción con dicho SCO. [3]
2.4
Interfaz de Programación de Aplicaciones (API)
La API es la encargada de controlar y administrar la experiencia del aprendizaje de
un curso SCORM, estableciendo una comunicación entre los SCO y el LMS; está
compuesta por un conjunto de funciones JavaScript que se agrupan en:
z
Métodos de sesión: son los que inicializan y terminan la comunicación entre el SCO
y el LMS.
z
Métodos de soporte: son los que manejan errores en la comunicación.
z
Métodos de transferencia: son los que intercambian valores del modelo de datos
entre un SCO y el LMS.
Estas funciones se detallan en el Anexo 1. [4]
2.5
Modelo de datos del entorno de ejecución
El modelo de datos es el lenguaje común que designa un conjunto de elementos que
se pueden usar para comunicar información desde un SCO al LMS. Este conjunto de
datos incluye información sobre el estudiante, sus interacciones con el LMS,
información del objetivo y el estado de éxito y conclusión de la actividad. [4]
Está estructurado por un grupo de
campos con un identificador, valores y un
comportamiento establecidos. Con el fin de diferenciarlos, todos los elementos del
modelo empiezan con "cmi.", y emplean el caracter "punto" (.) para apartar las distintas
unidades semánticas. Con la inclusión de la secuenciación y navegación, a partir de
SCORM 2004, se añadió un nuevo valor, inicializado este por el sufijo “adl”.
4
2.6
Secuenciación y navegación
SCORM 2004 aporta el requisito de la secuenciación, que se refiere a un conjunto de
reglas que describen el orden de la presentación de los contenidos según la navegación
hecha por el usuario. Es posible así la comunicación entre los diferentes SCO que
forman parte del curso, y gracias a las normas que el diseñador del curso puede
establecer, entonces dicho curso ofrecerá diferentes rutas para la consecución de los
objetivos pedagógicos marcados. Además se define un entorno de comunicación entre
el contenido y el sistema gestor que permite realizar el seguimiento del usuario.
El uso de secuenciación y navegación es opcional. Si no se especifican las reglas en
el paquete SCORM, la configuración por defecto será una experiencia pasiva para el
alumno, sin interacción con el contenido.
En SCORM 2004, la secuenciación y la especificación de navegación se apoyan en
la secuenciación simple (IMS Simple Sequencing, del inglés Global Learning
Consortium). La IMS SS define un método para representar el comportamiento deseado
de una experiencia de aprendizaje prediseñada como una secuencia discreta de
actividades. La especificación incorpora reglas que describen el flujo instruccional a
través de una serie de contenidos y sus posibles ramificaciones conforme al resultado
de la interacción del usuario con los contenidos. Por lo tanto, IMS SS permite una forma
clásica de realizar modelos de diseño de aprendizaje. [5]
2.7
Curso SCORM
Para armar el curso SCORM, son empaquetados los SCO y los ASSET (objetos más
elementales que aparecen en el curso: textos, imágenes, páginas web, documentos,
multimedia, etc.) en la estructura que los agrupa y organiza, el paquete SCORM, con el
fin de ser visualizados como un todo, no como recursos independientes.
2.8
Visor
Asociado a la rama de la informática, el término visor se refiere a una aplicación
encaminada a mostrar imágenes digitales, videos, recursos o archivos. Los visores de
paquetes SCORM, específicamente, deben presentar un grupo de características
acorde al contenido que muestran: árbol de contenido, navegabilidad a través del curso
y otros cursos asociados, recibir los mensajes que los contenidos proporcionen y
5
almacenar las estadísticas derivadas del uso del contenido, entre otras.
2.9
Visores de paquetes SCORM en plataformas educativas
Cumplido todo el proceso de creación de un paquete SCORM, en una herramienta
de autor o en una plataforma educativa, se necesita un medio para la visualización y
navegación de su contenido. Los visores de paquetes SCORM son los encargados de
realizar esta función.
En la actualidad los visores existen tanto como aplicaciones de escritorio, como
módulos integrados a repositorios de objetos de aprendizaje o en plataformas
educativas. A continuación se muestra un estudio realizado a los visores de algunas
plataformas, específicamente Sakai, Moodle, Blackboard y Dokeos, evaluándose
elementos como: soporte brindado a las versiones de SCORM, almacenamiento de
estadísticas (se refiere a la durabilidad de la información que se genera en la
interacción entre el usuario y el curso SCORM), opciones para la navegación brindadas,
uso de la API común y las funciones para esta definidas por el estándar, etc.
2.2.1 Icodeon SCORM Player (Sakai)
Es un visor robusto, de configuración flexible y sencillez de adaptación. Permite subir
un paquete SCORM y lo registra en Icodeon, luego haciendo clic en el nombre del
recurso se lanza el player SCORM. Una funcionalidad importante es que Icodeon
registra eventos en las tablas de Sakai, aunque todavía no existen informes ni otras
características que aprovechen esta información. Brinda soporte para SCORM 2004 y
está diseñado para integrarse en sistemas e-learning nuevos o existentes. [6] Los
objetos SCORM tienen un ciclo de vida durante una sesión de comunicación con
Icodeon SCORM Player. El ciclo de vida está caracterizado por tres operaciones de
“transferencia de datos” de la SCORM JavaScript API. Estas son:
z
Initialize: Los datos de seguimiento de una sesión previa se envían desde el
servidor al cliente.
z
Commit: Los datos de seguimiento que se han grabado y almacenado en caché se
envían al servidor.
z
Terminate: Se calcula el tiempo de la sesión y los datos de seguimiento que se han
registrado y almacenado en caché se envían al servidor.
6
2.2.2 Flex SCORM Player
Cuenta con las siguientes características:
z
Interfaz muy atractiva.
z
Tiene una navegación sencilla, con tan poco como sea posible en la pantalla, en
cualquier momento.
z
Implementación básica del modelo de datos.
z
Implantación del adaptador API.
z
Brinda soporte para SCORM 2004.
z
Basado en la web, corre en línea en el servidor web, dentro de un marco, o de forma
independiente.
z
Desarrollado como un módulo CMS para los distintos sistemas de código abierto,
como Moodle.
z
Proporciona una prueba básica con el LMS.
2.2.3 SCORM Engine Content Player (Blackboard)
El Content Player Building Block tiene entre sus características:
z
Permite a un instructor agregar contenidos que se ajusten a SCORM 1.2 y 2004.
z
Cuando un artículo del libro de calificaciones se asocia con el elemento de contenido
SCORM, el instructor podrá ver los datos relacionados con las interacciones de los
usuarios con el contenido. Esto se conoce como datos de intento. Los detalles
pueden incluir el tiempo total
que
el
usuario
ha
visto
cada
objeto
de
aprendizaje, el estado de finalización, las respuestas a las preguntas contenidas
en el paquete y si la respuesta era correcta. El propósito de los datos de intento es
ayudar al instructor en la determinación de la evaluación.
z
Cuenta con controles de navegación que permiten la inclusión de botones, barras y
otros elementos para apoyarse durante la navegación.
z
Cuenta con varias categorías que incluyen en su configuración elementos como:
secuencia rudimentaria, configuraciones de compatibilidad (para las versiones de
7
SCORM que utiliza) y opciones de depuración para el tratamiento de errores durante
la sesión de comunicación.
2.2.4 SCORM Cloud (Dokeos)
Presenta entre sus características:
z
Es funcional para SCORM 2004 y 1.2, brindando para estas versiones las opciones
de importar y exportar paquetes SCORM, secuencias de cursos y compatibilidad con
casi cualquier contenido.
z
Cuenta con una herramienta de informes que permite ver el historial de los alumnos,
el tiempo que pasaron en los cursos y qué preguntas han contestado correcta o
incorrectamente.
z
Permite la importación y exportación de cursos.
2.10
Resultados del estudio de los visores de paquetes SCORM
Los visores analizados arrojaron aspectos que se deben tener en cuenta en el
desarrollo de la presente pesquisa:
z
Validación de la estructura del paquete SCORM así como su contenido.
z
Opciones de navegación a través del curso de fácil manipulación y comprensión
para el usuario, que brinden un entorno sencillo.
z
API con las funciones para el intercambio de información definidas por el estándar.
z
Utilización del modelo de datos que brinda SCORM.
z
Visualización de mensajes de error, definidos por el estándar, que puedan ocurrir
durante el flujo de información.
z
Utilización de un gestor de bases de datos robusto que brinde soporte para el
almacenamiento de toda la información y estadísticas que se generan durante la
interacción del usuario con el curso SCORM.
2.11
Entorno para la visualización de un curso SCORM
Con el fin de lograr la interoperabilidad y reusabilidad, SCORM fija un grupo de
principios que rigen la utilización del estándar, estos principios van a definir cómo lograr
8
la visualización de los cursos contenidos en los paquetes a través de una herramienta:
[7]
z
Forma común para iniciar recursos de aprendizaje (launch6). Este mecanismo define
los procedimientos y las responsabilidades para el establecimiento de la
comunicación entre el recurso de aprendizaje y el LMS. El protocolo de
comunicación está estandarizado a través del uso de una API común.
z
Un mecanismo común para comunicarse con el LMS (API). La comunicación gira en
torno al estado del recurso de aprendizaje (inicializado, terminado, condición de
error) y además permite obtener y fijar datos (puntajes, límites, etc.) entre el LMS y
el paquete de contenidos.
z
Un lenguaje predefinido (vocabulario) que forme las bases de la comunicación, o
sea, un modelo de datos. En su forma más simple, este define elementos que tanto
el LMS como el SCO están esperando conocer. El LMS debe mantener el estado de
los elementos requeridos a través de sesiones, y el contenido de aprendizaje debe
utilizar solo estos elementos predefinidos para garantizar la reusabilidad en diversos
sistemas, que cumplan con la especificación de SCORM.
2.12
Herramientas, metodología y tecnologías para el desarrollo
Tabla I: Herramientas, metodologías y tecnologías para el desarrollo
Metodología de desarrollo de software
Rational Unified Process (RUP)
Lenguaje de Modelado
UML 2.0
Herramienta CASE
Visual Paradigm for UML 8.0 Enterprise
Edition
Lenguaje del lado del servidor
PHP 5.2
Lenguajes del lado del cliente
JavaScript 1.5, CSS2, Ajax, HTML 5.0
Framework de desarrollo
Symfony 1.4.20
Framework para entorno anfitrión
JQuery 1.9
Servidor de aplicación
Apache 2.4.3
6
Lanzamiento, se refiere a mostrar el curso en un navegador web.
9
IDE de desarrollo
NetBeans 7.2
Sistema gestor de base de datos relacional
PostgreSQL 9.1
Otras herramientas
Kdesvn
2.13
Resultados
La herramienta permite la visualización de los cursos contenidos en los paquetes
SCORM, navegar por su contenido y permitir la comunicación de estos con la
plataforma. Para navegar a través del contenido del paquete, se debe seleccionar
previamente el curso, para que sea lanzado el reproductor, después de su visualización
se puede acceder a otros cursos asociados al programa de estudio, guardándose el
estado de ejecución del curso que se abandona. Desde que se ejecuta el visor hasta su
cierre, se establece la comunicación con la plataforma mediante la API de SCORM,
almacenándose los datos resultantes de la interacción entre el usuario y el curso. Se
ofrecen opciones de navegación que estarán disponibles siempre que la secuenciación
de contenidos lo permita, es decir, el usuario no podrá abandonar una actividad
mientras no haya cumplido los objetivos de la misma ni navegar libremente por dichas
actividades. Todos los usuarios de la plataforma tienen acceso al visor. Se muestra
además un árbol de contenidos que podrá ser ocultado para una mejor utilización del
espacio, dicho árbol muestra la estructura del curso.
Como resultado de la aplicación de la metodología de desarrollo RUP se generaron
y/o modificaron los artefactos definidos por esta para cada una de sus fases e hitos,
estos se muestran a continuación:
Tabla II: Artefactos generados y/o modificados
Nombre
Cantidad
Requisitos no funcionales
6
Requisitos funcionales
6
Casos de usos
5
Modelo de dominio
1
Diagrama de casos de uso
1
10
Diagrama de clases del análisis
5
Diagrama de iteración
5
Diagrama de clases del diseño
5
Diagrama de componentes
1
Diagrama de despliegue
1
Modelo entidad relación
1
Se aplicaron un conjunto de patrones de diseño o buenas prácticas que propone el
framework Symfony para llevar a cabo un proceso de desarrollo eficiente:
Tabla III: Patrones de diseño empleados en la propuesta de solución
Patrones GRASP
Patrones GoF
Experto
Decorador
Creador
Registro
Controlador
Alta cohesión
Bajo acoplamiento
2.14
Descripción de las principales clases y archivos utilizados
Se describen las clases y archivos que intervienen directamente en el funcionamiento
del sistema, así como las funciones y métodos que contienen.
scormPlayerUtils: clase encargada de inicializar un conjunto de elementos por parte
del LMS que posteriormente son solicitados por el SCO, esta inicialización ocurre si no
existe una relación entre los elementos implicados en la interacción (el usuario y el
paquete SCORM):
z
function initializeCMI: inicializa datos sobre la actividad que se realizará, algunos
son: versión del cmi (especificada por el LMS), estado de completitud de la
actividad, estado de satisfacción para la actividad, modo de evaluación, ubicación
del usuario dentro de la actividad.
11
z
function initializeObjectives: inicializa los objetivos a cumplir por el usuario dentro
de una actividad.
z
function initializeInteractionsObjectives: inicializa los objetivos a cumplir por el
usuario dentro de una actividad para registrar la cantidad de interacciones con dicha
actividad.
Esta clase recibe además las solicitudes de almacenamiento o devolución de
información (la información solicitada por el SCO que transita a través de la API y es
redireccionada hasta aquí), utiliza para ello las siguientes funciones:
z
function getFromDM: encargada de devolver la información referente al elemento
del modelo de datos de SCORM solicitado por el SCO.
z
function setFromDM: encargada de almacenar la información referente al
elemento del modelo de datos de SCORM enviado por el SCO.
scormplayerCommand: clase encargada de transformar el elemento del modelo de
datos de SCORM solicitado o enviado por el SCO, con el fin de hacerlo entendible para
el sistema. A partir de este elemento determina la entidad (tabla) en la que se almacena
la información correspondiente.
analizeSequencingAndNavegation: clase encargada de determinar si una solicitud
de navegación (Siguiente o Anterior) procede.
scormAPI (API): archivo de código JavaScript con las funciones destinadas a
establecer la comunicación y el flujo de información entre el curso SCORM y el LMS. A
continuación se explican las principales funciones:
z
Initialize: inicializa la sesión de comunicación con el LMS.
z
Terminate: termina la sesión de comunicación con el LMS.
z
GetValue: encargada de solicitar información al LMS sobre el elemento enviado por
el SCO.
z
SetValue: encargada de enviar al LMS el elemento a almacenar, así como la
información correspondiente a este.
z
Commit: la información que se desea almacenar en el LMS puede ser guardada en
caché y ser enviada antes de finalizar la sesión de comunicación, en este caso se
utilizará la función Commit (no utilizada puesto que la información es enviada
12
directamente mediante el uso de las funciones SetValue y GetValue).
z
GetDiagnostic, GetErrorString, GetLastError: encargadas de identificar y
devolver los errores ocurridos durante la sesión de comunicación.
z
error_strings: almacena los errores que pueden ocurrir durante la sesión de
comunicación.
z
_valueNameCheckReadOnly: chequea que el SCO no envié solicitudes de Set
(almacenamiento) sobre elementos de solo lectura.
z
_checkRunning: chequea el estado de ejecución de la sesión (No Inicializado,
Terminado o Corriendo) para determinar si una solicitud de las funciones Terminate,
GetValue, Commit o SetValue procede.
3. CONCLUSIONES
La investigación arrojó como resultado principal un módulo para la Plataforma
Educativa ZERA que posibilita la visualización de los cursos contenidos en los paquetes
SCORM. Se permite de esta forma que los usuarios interactuen con dichos cursos y se
archive la información que se genera durante la interacción, cumpliéndose las reglas y
especificaciones del estándar. Se generó y/o modificó toda la documentación
correspondiente a la metodología de desarrollo RUP durante el proceso, diseñando e
implementando un conjunto de clases que dan cumplimiento a los requisitos funcionales
y no funcionales asociados a los casos de uso, aplicando un conjunto de patrones,
convenciones de código y buenas prácticas. Fueron analizados para lograr este
resultado, un grupo de soluciones similares y documentación con el fin de dominar los
principales términos asociados a la pesquisa.
4. RECOMENDACIONES
Con el objetivo de perfeccionar la aplicación y lograr una mayor explotación de sus
potencialidades se recomienda:
z
Extender el alcance del visor a otras versiones de SCORM.
z
Concebirlo como un plugin que pueda ser añadido en otras aplicaciones construidas
13
sobre Symfony.
z
Concebir una vía para visualizar la información guardada como resultado de la
interacción entre el usuario y el curso SCORM.
5. REFERENCIAS BIBLIOGRÁFICAS
1. Martínez,
E.
“Estándares
y
organizaciones”,
24
de
julio
2007;
http://www.eveliux.com/mx/estandares-y-organizaciones.php
2. Verdecia Espinosa, R. “Análisis y Diseño de un visor de paquetes para la Plataforma
Educativa Zera” Tesis de ingeniería. Dept. de Componentes. Facultad 4. Universidad de
las Ciencias Informáticas. La Habana, Cuba, 2012.
3. Rodríguez,
O.M.
“Unidad
3:
El
estándar
SCORM”,
5
de
enero
2010;
http://ocw.unia.es/innovaciondocente_formacionprofesorado/diseno-de-contenidoseducativos-multimedia/contenidos_ud3/skinless_view
4. UAM.
“Informe
4”,
5
de
abril
2011;
http://ixil.izt.uam.mx/pd/doku.php/ib:cd:resdev:informes:informe_4
5. UOC.
“IMS
Simple
Sequencing”,
2
de
junio
2012;
2010;
http://moodle-vs-
http://cv.uoc.edu/app/mediawiki25/wiki/IMS_Simple_Sequencing
6. Darolmar.
“Sakai
y
SCORM”,
31
de
enero
sakai.blogspot.com/2010/01/sakai-y-scorm.html
7. Mambru. “El RTE de SCORM”, 21 de febrero 2005;
http://latesis.blogspot.com/2005/02/el-rte-de-
scorm.html
14
6. ANEXOS
ANEXO 1
Tabla IV: Funciones de la API de SCORM 2004
Métodos de sesión (Funciones de estado de ejecución)
Initialize()
Descripción: esta función indica a la API que el SCO se va a comunicar con el LMS. Es
obligatorio que el SCO llame primero a esta función antes que a ninguna otra del LMS.
Sintaxis: Initialize(parámetro)
parámetro: una cadena vacía.
Valor devuelto: devuelve una cadena que representa un valor booleano:
* True: indica que Initialize() se ha iniciado con éxito.
* False: indica que Initialize() no se ha iniciado con éxito. El SCO no ha sido bien
identificado por el LMS y cualquier llamada adicional a una función de la API no será
procesada por el LMS.
Terminate()
Descripción: el SCO debe llamar a esta función cuando determine que ya no necesita
comunicarse más con el LMS. Esta llamada asegura que:
* El SCO puede asegurarse que cualquier dato usado por la función SetValue() ha sido
manejado por el LMS.
* El SCO ha finalizado su comunicación con el LMS.
Sintaxis: Terminate(parámetro)
parámetro: una cadena vacía.
Valor devuelto: devuelve una cadena que representa un valor booleano:
* True: indica que la función se ha ejecutado con éxito. Una vez devuelto este valor el
SCO no puede llamar a otras funciones de la API.
* False: indica que la función no se ha ejecutado con éxito. El LMS está en un estado
desconocido y que cualquier llamada al LMS puede o no puede ser ejecutada.
Métodos de transferencia (Funciones de transferencia de datos)
GetValue()
Descripción: esta función permite al SCO obtener información desde el LMS. Se usa
15
para
determinar:
* Valores para varias categorías (grupos) y elementos en el modelo de datos.
* La versión de modelo de datos soportada.
* Si una categoría o elemento específico es soportado o no.
* El número de elementos que en un momento dado hay en un arreglo o una matriz.
Sintaxis: GetValue(parámetro)
parámetro: debe ser el nombre completo de la variable cuyo valor actualizado
queremos obtener. Dicho valor es devuelto por la función en forma de string.
Valor devuelto: todos los valores devueltos son cadenas.
SetValue()
Descripción: esta función permite al SCO enviar información al LMS. El adaptador
API puede ser diseñado para remitir la información al LMS o a otro diseño relacionado
con él. Se usa además la función para poner los valores actuales de varias categorías o
grupos y elementos en el modelo de datos.
Sintaxis: SetValue(parámetro, valor)
parámetro: el nombre del modelo de datos y su grupo se da como primer parámetro
de la función. El argumento es case-sensitive (diferencia entre letras mayúsculas y
minúsculas) y
debe ser una cadena encerrada en comillas.
valor: el valor del parámetro se da como segundo argumento de la función. En cada
llamada a la función solo se puede enviar un valor.
Valor devuelto: se devuelve una cadena representando un valor booleano:
* True: indica que la función se ha ejecutado con éxito
* False: indica que la función no se ha ejecutado con éxito.
Commit()
Descripción: si el adaptador API está cogiendo valores recibidos del SCO vía la
función SetValue(), una llamada a Commit() hace que cualquier valor no guardado en
disco se almacene, es decir, que sea persistente.
16
En algunas implementaciones, el adaptador API guarda los datos según los recibe y
por tanto no los almacena en el caché del cliente. En estas implementaciones no sería
necesario utilizar esta función.
Sintaxis: Commit(parámetro)
parámetro: una cadena.
Valor devuelto: cadena representando un valor booleano:
* True: indica que la función se ha ejecutado con éxito.
* False: indica que la función no se ha ejecutado con éxito. El LMS se encontraría en
un estado desconocido y cualquier otra llamada a una función de la API podría o no ser
procesada por el LMS.
Métodos de soporte (Funciones de estado de ejecución de errores)
GetLastError()
Descripción: el SCO debe tener una forma de saber si las funciones llamadas han
sido ejecutadas correctamente y si no lo han sido, saber por qué han fallado. Esta función
devuelve los códigos de error que resultan de la anterior llamada a una función de la API.
Cada vez que se llama a una función de la API el código de error se borra y se reinicia
pero si no se hace ninguna llamada a la API el código de error permanece.
Sintaxis: GetLastError(parámetro)
parámetro: ninguno.
Valor devuelto: los valores devueltos son cadenas que se pueden convertir en
números enteros que identifican errores según las siguientes categorías:
0: "No error"
101: "Excepción general"
102: "Fallo general de inicialización"
103: "Ya está inicializado"
104: "La sesión ya terminó"
111: "Fallo general en la finalización"
112: "Se intentó finalizar antes de inicializar"
17
113: "La sesión ya estaba finalizada"
122: "Recogida de datos antes de inicializar"
123: "Recogida de datos después de finalizar"
132: "Grabación de datos antes de inicializar"
133: "Grabación de datos después de finalizar"
142: "Se intentó commit antes de inicializar"
143: "Se intentó commit después de finalizar"
201: "Error general en argumento"
301: "Fallo general en get"
351: "Fallo general en set"
391: "Fallo general en commit"
401: "Elemento no definido en el modelo de datos"
402: "Elemento no implementado en el modelo de datos"
403: "Valor del elemento no inicializado"
404: "El elemento es de solo lectura"
405: "El elemento es de solo escritura"
406: "Tipo de dato incorrecto"
407: "Valor de elemento fuera de rango"
408: "Dependencia no establecida en el modelo de datos"
GetErrorString()
Descripción: esta función obtiene una descripción textual del error representado por
el código de error.
Sintaxis: GetErrorString(parámetro)
parámetro: un número entero representando un código de error.
Valor devuelto: una cadena representando la descripción del error.
GetDiagnostic()
Descripción: esta función activa las descripciones contenidas en el LMS para
18
solucionar el error. De esta forma se obtiene mayor documentación para solucionar el
error.
Sintaxis: GetDiagnostic(parámetro)
parámetro: el parámetro puede tomar una de estas dos formas:
* Un número entero representando un código de error. Esto pide más información
sobre el error consultado.
* “” - una cadena vacía - Esto pide más información sobre el último error ocurrido.
Valor devuelto: el valor devuelto es una cadena que representa cualquier información
sobre el error.
19