ON-Blog

Este weblog estaba dedicado exclusivamente a publicaciones relativas al proyecto de software libre que participó en el primer concurso de software libre de Castilla-La Mancha.

Como habéis podido ver, los dos últimos post publicados son dos meras pruebas ininteligibles, o mejor dicho inexplicables para los que de vez en cuando pasabáis por aquí o para el que cae por primera vez en estos lares. Así que creo que es menester explicar brevemente que significan estas dos últimas publicaciones. Son pruebas de una aplicación en desarrollo llamado ON-Blog.

ON-Blog es una aplicación creada para el sistema Android para ayudar a gestionar publicaciones en blogs compatibles con la API MetaWeblog. Esta aplicación ha sido realizado por José Manuel Nieto Sánchez.

Especificación IMS QTI v2.1 Results Reporting

La especificación sobre los informes de resultados de los candidatos pertenece al borrador IMS QTIv2.1. Es el primer documento que se publica sobre este tema, ya que la especificación 2.0 no menciona nada al respecto. Esta especificación pretende establecer un modelo para almacenar y compartir resultados obtenidos en elementos evaluativos (tests, conjuntos de preguntas, etc.).

Según la especificación el resultado de una evaluación, será el informe sobre un test o simplemente un conjunto de preguntas. Se creará un identificador sobre qué sistema realizo el informe (SessionIdentifier). Cada resultado estará asociado a un estudiante. Esta información se expresará según la especificación que ya comenté hace unos días (learner information package). Si se trata de un test, se deberá añadir información de cuando se registró el resultado de tal test y de forma optativo cualquier otro parámetro sobre el resultado del test y su duración. De forma obligatoria, hay que registrar los resultados de los elementos que componen la evaluación, de forma obligatoria se registra la fecha en la que se calificó el elemento y un estado de sesión de la misma, que sirve para interpretar las variables(itemVariable) de este elemento. Las variables pueden contener los valores de las variables incorporadas numAttempts, duration y completionStatus. Además, puede contener algún comentario del estudiante.

Las variables tienen un identificador, una cardinalidad y opcionalmente un tipo base. Diversos tipos de variables heredan de ésta: responseVariable, outcomeVariable y templateVariable(no implementada en SDocente). ResponseVariable deberá contener la respuesta del estudiante y, opcionalmente la respuesta correcta y también se puede informar, si se trata de un elemento de elección, si se han desordenado los elementos al presentarlos al estudiante. OutcomeVariable puede almacenar la información sobre el elemento outcomedeclaration de un examen (puntuación mínima, máxima normalizada, o puntuación mínima para considerar que un elemento está “aprobado”) y sobre quién tiene la posibilidad de ver toda esta información. De este modo, cuando el sistema que representa el informe de evaluación sabe a quién lo debe hacer visible. Todos los elementos de outcomeVariable son opcionales.

Aquí os muestro el diagrama de clases de SDocente a la hora de implementar esta especificación.

Informe de resultados
Informe de resultados

Regreso con más especificaciones

Tras unos meses sin postear, pero sin que el desarrollo del proyecto se detuviera, vuelvo para comentar en este y post sucesivos cosillas realizadas, así como nuevas especificaciones que han entrado en juego.

Hoy os comentaré de forma breve qué es y qué integración ha tenido en el proyecto la especificación IMS Learner Information Packaging.

La especificación IMS Learner Information Packaging pretende detallar un modelo de datos que describe las características de un estudiante necesarias para almacenar y gestionar su historial, objetivos y de logros de aprendizaje.

Como cualquier especificación se consigue la interoperabilidad, es decir, que varios sistemas puedan funcionar/entender los datos que cumplen esta especificación, respetando la privacidad y protección de los datos.

La especificación contempla una gran cantidad de información que puede recoger, almacenar y/o almacenar. La información del estudiante se divide en 11 categorías:

  1. Identificación
  2. Objetivo
  3. Calificaciones, Certificaciones y licencias (qcl)
  4. Actividad
  5. Transcripción
  6. Interés
  7. Competencia
  8. Afiliación
  9. Accesibilidad
  10. Código de seguridad
  11. Relación

En un sistema de información de estudiantes podrían entrar en juego muchos actores como el propio estudiante, la escuela, empleados, publicadores, etc. recavando información de muchos medios.

Se escapa ell uso amplio de esta especificación para este proyecto, por lo que se ciñe sólo al uso reducido de la categoría identificación.

La estructura de datos de esta categoría no contiene campos obligatorios de primer nivel, es decir, ninguna de las estructuras que represetan la identificación del alumno es obligatoria, pero sí son obligatorios algunos campos si opta por ciertas estructuras. Por ejemplo, el uso de la estructura formname, que sirve para almacenar un nombre ya formateado, no es obligatoria pero si se usa esta estructura deberá de forma obligatoria rellenar su campo text.

La estructura de datos de identificación contiene estructuras como:

  • Nombre
  • Dirección
  • Información de contacto
  • Datos demográficos
  • Agentes (información de las personas que pueden actuar en nombre del estudiante.
  • Extensión (estructura para facilidar la extensión de la información del estudiante).

A continuación muestro un diagrama de como quedaría en SDocente la integración con las estructuras necesarias.

Learning Information Package en SDocente
Learning Information Package en SDocente

Aplicación extensible = Plugable

La nueva idea en desarrollo es que la amplicación sea lo más extensible posible sin realizar esfuerzos muy costosos. La intención es poder agregar paquetes para poder añadir nuevos tipos de preguntas a la aplicación, incluyendo sólo unos determinados ficheros, sin modificar en la aplicación en sí. De este modo, se permitirá crear nuevos tipos de preguntas sin tener que recodificar el core de la aplicación. Cada paquete de nueva pregunta o plugin tendrá que incluir:

Controlador: Se encargará de la interacción con la gui de la pregunta, controles de la gui, recuperación de datos, etc.

Validador: Validará los datos que recogió el controlador.

Clase Pregunta: La nueva pregunta tendrá una lógica de negocio que quedará recogida en esta clase.

Render: Para que la pregunta puede visualizarse de algún modo, deberá crearse una clase que se encargué de mostrarla, por ejemplo en HTML, LaTeX, etc.

Código Base de Datos: Se tendrán que añadir un par de funciones para posibilitar tanto el almacenamiento como la recuperación de este tipo de preguntas.