El RTE de SCORM

== RTE (Run-Time Environment) == El objetivo de SCORM es que los recursos de aprendizaje sean reusables e interoperables entre múltiples LMS. Para que esto pueda ser posible, debe existir: Una forma común para iniciar recursos de aprendizaje (Launch - lanzar). 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 un API común. Un mecanismo común para que 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 SCO. Un lenguaje predefinido (vocabulario) que forme las bases de la comunicación (Data Model). En su forma más simple, el "modelo de datos" 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 sólo estos elementos predefinidos para garantizar el reuso en diversos sistemas, que cumplan con la especificación de SCORM. LAUNCH Como está presente en el CAM de SCORM, el "Modelo de Contenido" de SCORM está conformado de los Assets, de los SCOs y de las "agregaciones de contenido". De ellos, los Assets y los SCOs pueden ser "iniciados" (lauched) por un LMS, y los procedimientos y las responsabilidades para el establecimiento de la comunicación entre los recursos de contenido y el LMS varian dependiendo del tipo de recurso de contenido. Asset: El "modelo de iniciamiento" de SCORM exige que un LMS inicie un Asset usando el protocolo HTTP. Dado que al asset no se le hace seguimiento, no necesita comunicarse y por lo tanto no hace uso del API ni del modelo de datos. SCO: El "modelo de iniciamiento" de SCORM exige que: El LMS lance uno y sólo un SCO al tiempo. El LMS es el único que puede iniciar un SCO. El LMS debe iniciar un SCO en la ventana de un browser que es una ventana hija o un frame hijo de la ventana del LMS que el Adpatador del API expone como un objeto del DOM. El adaptador del API debe ser proporcionado por el LMS. Es respondabilidad del SCO buscar recursivamente el padre hasta que el adptador del API sea encontrado para poder iniciar la comunicación con el LMS. API El uso de un API común satisface muchos de los requerimientos de más alto nivel de SCORM para la reusabilidad y la interoperabilidad. Proporciona un forma estandarizada a los SCO para comunicarse con los LMS, encapsulando la implementación de la comunicación del desarrollador. El adaptador del API es una pieza de software funcional, implementado por el LMS, que implementa las funciones del API y por medio de interfaces las hace disponibles a los clientes SCO. Una vez la comunicación entre el SCO y el LMS se establece, el SCO puede obtener y fijar información en el LMS. Toda la comunicación entre el adaptador del API y el SCO es iniciada por el SCO. Las funciones del adaptador del API pueden ser agrupados en tres grupos básicos: Ejecución del estado de un SCO: que permite iniciar y finalizar la ejecucicion de un SCO. Gestión del estado de un SCO: usadas para manejar errores. Transferencia de datos: usadas para transferir datos, obteniendo y fijando información. La comunicación entre el adaptador del API y el SCO pasa por una serie de estados bien determinados en tiempo de ejecución. Los estados son: No inicializado, Inicializado y Finalizado. No inicializado: El estado después de que el SCO ha sido "lanzado" y justo antes de sea inicializado (es decir, antes de que sea invocada la funcion de inicialización del API). Durante este estado es labor del SCO encontrar el Adaptador del API. Inicializado: Estado en el que se encuentra despues de ser inicializado y antes de ser terminado (silly?). Puede usar todos las funcioens del API, excepto la de inicialización. Finalizado: Es es estado en que se encuentre el SCO despues de invocar la funcion de terminacion. Puede acceder a las funciones de obtencion y manejo de errores, si el metodo de finalizacion no se llevo a cabo satisfactoriamente. Rol del LMS: SCORM exige que el LMS implemente un adaptador del api que implemente el API, haciendo uso de la encapsulación de forma que el SCO no tenga acceso a los los detalles de implementación. Las responsabilidades del adaptador del API son: El LMS debe lanzar el SCO en una ventana del browser que debe ser una venta o un frame hijo de la ventana del LMS el cual contiene el adpatador. El adaptador debe ser suministrador por el LMS. El único mecanismo permitido para la interacción entre el API y el SCO es a través de llamadas ECMAScript. El adaptador del api debe ser accesible por medio del DOM como un objeto llamado "API". El adapatador puede estar implementado en diversos lenguajes de programación como Java (haciendo uso de applets, por ejemplo) o C++ (como un plug-in del browser). La implementación del adaptador es responsabilidad del LMS. Rol del SCO Lo mínimo que debe hacer un SCO es invocar los métodos de inicialización y finalización del API. Para poder hacerlo, el contenido debe poder ubicar el adaptador. Es pues deber del contenido encontrar y establecer comunicación con el adaptador. MODELO DE DATOS La necesidad de definir un modelo de datos común es aseguranos que a un conjunto definido de información sobre un SCO se le puede hacer seguimiento sin importar el LMS en el que esté operando. Hay un número de modelo de datos bajo desarrollo en varios comités y organizaciones. Hasta la versión 1.2 de Scorm, el modelo de datos corresponde a una versión borrador (draft) de un modelo de datos. El modelo da datos del RTE: Para identificar el modelo de datos en uso, a las primeras palabras de los elementos que lo conforman. Todos los elementos utilizados por el modelo que utiliza SCORM fueron creados por el AICC CMI, por ellos es que todos los elementos comienzan con la palabra "cmi". Hay que aclarar una cosa y es que un SCO no puede acceder a los elementos de datos de otro SCO. Los elementos del modelo datos se clasifican en dos grandes grupos, que son la "obligada" y la "opcional". Todos los elementos "obligados" deben ser implementados por todos los LMS que cumplan con SCORM. Todo LMS está obligado a soportar: Todos los métodos y elementos del CORE (id, nombre, Ubicación de la lección, estado de la lección, etc) Todos los métodos y elementos que indiquen el desempeño del estudiante ("the raw", tiempo acumulado total, indicadores sobre como o por que se abandona un SCO, duracion de la ultima sesion, etc.) Los datos de suspensión y lanzamiento de un SCO.