Modelo básico de docap
Calificar de básico este modelo equivale a decir que es concreción del docap tipo 2 visto en [esta entrada]; decir docap incide en el uso de OOo Basic como lenguaje de referencia. Al estar en la sección Evaluación concretamos que este docap es un intento de automatización de los procedimientos de evaluación, con las especificaciones que realizamos en la [entrada que precede] a la actual.
Aclaro en primer lugar que me limito al docap-modelo el de tipo 2 por ser el de uso más frecuente también en el ámbito de la evaluación, pero también por similitud con el soporte básico de recogida de datos que veremos la sección Análisis.
Entrando ya en materia y completando lo indicado en la entrada citada al inicio de ésta, el docap-modelo que presento ahora no se diferencia demasiado del presentado [en esta entrada] respecto al trabajo con documentos. Salvando algunas diferencias (que puede haberlas), la mayor y más significativa es que el docap actual añade una base de datos a los componentes del docap; el resto de no tiene por qué ser diferente, aunque sí lo será el procedimiento de análisis. No obstante, como este análisis no será abordado detenidamente en esta entrada por los mismos motivos (más otros añadidos) (1) que en aquel caso, las diferencias reales entre ambos soportes, en términos de código, se reducen significativamente, por lo que no resultará demasiado complicado explicar y entender lo que a continuación voy a exponer: en gran medida será suficiente con repetir lo ya visto.
Para concretar un docap-modelo de evaluación primero se debe especificar en que nivel se recoge los datos, ya que es posible diferenciar tres: respuestas del alumno, puntuaciones obtenidas por ítem y puntuación total de la prueba. Considero que para que resulte realmente operativo (en términos de automatización) se debe entender como nivel básico el segundo, aunque en función de los objetivos de esta entrada yo trabajaré desde el primer nivel: recogida de las respuestas, que implica que la puntuación de las mismas se debe resolver en el docap.
Una segunda cuestión, aunque se refiere al análisis de datos y dije antes que en esto no iba a ser abordado en esta entrada, es con qué referentes se van a calificar los resultados. Esta cuestión requiere aclarar previamente qué tipo de evaluación se propone: normativa, criterial o mixta. Estas cuestiones no corresponden a esta entrada, ya que es necesario clarificar el significado concreto de esos conceptos y sus implicaciones, por eso opto aquí por una solución de compromiso simplificada (2).
La primera fase del proyecto es, como en los modelos documentales, el trabajo con la hoja de cálculo, empezando por la creación del formulario (hoja Form) (3). Este podría ser el resultado:
No he pretendido hacer nada complicado, por lo que es mejorable (también a nivel estético), pero sirve para nuestro objetivo actual: recoger la información de forma eficiente sin sobrepasar el nivel de complejidad técnica básico, que por ahora consiste en el uso de funcionalidades de formulario de Calc. No obstante presenta algunas diferencias respecto al nivel más elemental de trabajo con documentos, y lo explico a continuación:
- En el formulario se diferencian tres partes, frente a las dos de los modelos anteriores: a parte de los botones de comando, los controles de entrada se diferencian por su función: los tres primeros son para datos de identificación y los restantes para la recogida de las respuestas de los ítem.
- Esta diferencia se reproduce en la asignación de esos controles a celdas: los controles de datos de identificación se asocian a tres celdas de la columna I, y los de los controles de ítem a siete celdas de la columna J.
- Esta diferenciación por columnas puede no ser necesaria, pero sí la diferenciación en el acceso a cada uno de los dos tipos de datos, como veremos en el código correspondiente. Después explicaré el motivo.
Además, y esa es la principal diferencia con los docap-modelo documentales, deberemos crear una segunda hoja (Datos) donde crearé la tabla de datos, concretamente los encabezamientos de las columnas que sirven para identificar sus campos.
Una vez preparado el documento Calc, corresponde desarrollar el código que nos permite acceder a los datos introducidos por el usuario. Para ello declaro las variables (4) y accedo al documento y a la hoja Form, siguiendo el procedimiento ya conocido...
Dim oHoja As Object, oCelda As Object
Dim mDatosper() As String, mCeldasi() As String
Dim mResp() As String, mCeldasj () As String, mAcierto() As String
Dim mPtos() As Integer, PD As Integer
Dim n1 As Integer, nj As Integer
Dim Md As Single, Dt As Single, Pz As Single, Pc As Single
oHoja = ThisComponent.getSheets().getByName("Form")
Observa que he declarado dos matrices para contener los datos (mDatosper() y mResp()), ya que me interesa trabajar de forma independiente con cada uno de los dos bloques. Como dije antes, esta diferenciación obedece al diferente tratamiento que tendrán los datos de identificación y los de respuestas a los ítem: los primeros no presentan novedad respecto a otras ocasiones, pero los segundos sí: sobre ellos realizaremos operaciones específicas, como tendremos ocasión de ver en su momento. Repito: con los datos personales nos limitamos acceder a ellos, pero los datos de respuesta a los ítem serán usados para generar los elementos de la tercera matriz (mPtos()), que contendrá la puntuación de los ítem, que resulta de la corrección de la prueba; los referentes para la corrección de los ítem están contenidas en una cuarta matriz (mAcierto()).
Por ello, el acceso a las respuestas del alumno, con la que finaliza la primera fase del script principal Main se resuelve de forma similar a cómo se resolvió el acceso a los datos personales, mediante un bucle For (For i = 0 To UBound(mResp()))
ni = 2
ReDim mDatosper(ni)
mCeldasi= Array("I1","I2","I3")
For i = 0 To UBound(mDatosper())
oCelda = oHoja.getCellRangeByName(mCeldasi(i))
mDatosper(i) = oCelda.getString()
Next
A continuación entramos en la segunda fase de Main, en la que corregimos las respuestas dadas por el alumno. En este caso el sistema es muy sencillo, pero puede ser mucho más laborioso de no trabajar con una matriz específica de respuestas, de ahí que sea recomendable diferenciarla de la de datos de identificación, como indiqué en su momento.
Para realizar esta corrección damos contenido a la matriz que contiene las respuestas correctas (mAcierto() = Array("A","B","C","D","E","F","G")) y mediante un nuevo bucle (For i = 0 To UBound(mResp())) y un condicional (If mResp(i) = mAcierto(i) Then) recorremos la matriz mResp() y comparamos su contenido con el esperado (mResp(i) = mAcierto(i)), asignando la puntuación que corresponde a cada ítem según se cumpla o no dicha condición. Aprovecho este mismo bucle para calcular el sumatorio de las puntuaciones del alumno (PD = PD + mPtos(i)), lo que supone entrar en la tercera fase del script.
mAcierto() = Array("A","B","C","D","E","F","G")
For i = 0 To UBound(mResp())
If mResp(i) = mAcierto(i) Then
Como dije, este sumatorio constituye el inicio de la tercera fase, la cual está dedicada a realizar los cálculos que nos permitirán calificar los resultados que obtiene el alumno: el porcentaje de aciertos, en función del tamaño del test y su puntuación directa (Pc = (PD/(nj+1))*100), y la puntuación típica (Pz = (PD - Md)/Dt), en función de supuestos valores de media (Md = 5.38) y la desviación típica (Dt = 0.47) (5).
A continuación se desarrolla la cuarta fase del script principal (Main) que tiene como objetivo construir con los datos parciales anteriores una matriz única de datos con la que trabajaremos en las subrutinas a las que se llama al final de Main (PasarDatos(mDatos()) y Info(mDatos())) (quinta fase).
Aunque podríamos ahorrarnos esta cuarta fase, por los motivos que dije en su momento puede no ser la mejor opción; pero, en todo caso, sí es conveniente crear una matriz única con todos los datos necesarios, ya que será muy útil para el correcto funcionamiento de las subrutinas que veremos más adelante.
Para crear esta matriz-síntesis recurriré de nuevo a los bucles como medio para automatizar la asignación de contenidos, aunque es necesario asignar de forma directa algunos de ellos, como puedes comprobar en el código que sigue:
For i = 0 To UBound (mDatosper())
For i = 0 To UBound( mResp())
For i = 0 To UBound(mPtos())
Primero redimensionamos la matriz-resumen (ReDim mDatos(19)) y después vamos asignando los datos, empezando por los personales (mDatos(i) = mDatosper(i)), siguiendo por las respuestas del alumno (mDatos(i+3) = mResp(i)), después los resultantes de la corrección de la prueba (mDatos(i+10) = mPtos(i)), finalizando con los datos-resumen, resultantes de los cálculos (vg. mDatos(17) = PD) (6).
Paso ahora a explicar los dos procedimientos que restan y que se ejecutan de forma independiente del script principal, mediante dos subrutinas:
- La primera (Sub PasarDatos(Datos() As Variant)) está pensada para construir la base de datos, trasladando los datos de la matriz-resumen (mDatos()) a la tabla creada en la hoja Datos.
- La segunda (Sub Info(Datos() As Variant)), ya conocida de [esta entrada], sirve para crear el informe (sobre Writer).
Estas subrutinas constituyen una especie de "externalización de procedimientos" del algoritmo, pero esto, además de ejemplificar el uso del principio de la programación modular, resulta necesario explicarlos con detalle, dada la relativa complejidad de ambos subprocesos y su independencia respecto al objetivo principal del script Main.
Dado que la segunda subrutina ya es conocida desde la publicación de [esta entrada], me limitaré a explicar la primera. Con ella automatizamos la creación de la tabla o base de datos, dotando a nuestro docap de un potencial muy interesante: recopilar los resultados de las aplicaciones individuales de una prueba, lo que facilita el posterior análisis de dichos datos (7).
Sub PasarDatos(Datos() As Variant)
Dim oHojaBD As Object, oCeldaInicio As Object, oCeldaNuevoRegistro As Object, oCeldaId As Object
Dim i As Integer, a As Integer, b As Integer, c As Integer, d As Integer
oHojaBD = ThisComponent.getSheets().getByName("Datos")
oCeldaInicio = oHojaBD.getCellRangeByName("A" & CStr(i+2))
If oCeldaInicio.getValue() = 0 Then
MsgBox "Id de la nueva entrada: " & d
'Escritura de los datos en el registro vacío
oCeldaId = oHojaBD.getCellRangeByName("A" & CStr(a))
For b = 0 To UBound(Datos())
oCeldaNuevoRegistro = oHojaBD.getCellByPosition(b+1,a-1)
oCeldaNuevoRegistro.setString(Datos(b))
Esta subrutina cuenta con un argumento que remite a la matriz-resumen (PasarDatos(Datos() As Variant)) de los datos del script principal Main, resultando ahora evidente la necesidad de su creación: gracias a ellos se simplifica la escritura de esos datos en la tabla.
Pero antes de dar ese paso debemos acceder a la hoja Datos (oHojaBD = ThisComponent.getSheets().getByName("Datos")) y posicionarnos adecuadamente en la primera fila no escrita (8) mediante un bucle condicionado
oCeldaInicio = oHojaBD.getCellRangeByName("A" & CStr(i+2))
If oCeldaInicio.getValue() = 0 Then
Cuando encontramos la celda de la columna A (oCeldaInicio = oHojaBD.getCellRangeByName("A" & CStr(i+2))) que cumple la condición (oCeldaInicio.getValue() = 0) asignamos el valor de inicio a la variable-contador que nos van a permitir recorrer las diferentes columnas de la tabla (a = i + 2) y de captura el valor Id de la fila A que precede a la que no cumple el criterio del condicional (d = i + 1). Después interrumpimos el bucle.
Después volvemos a posicionarnos en la celda de la columna A localizada mediante el bucle anterior (oCeldaId = oHojaBD.getCellRangeByName("A" & CStr(a))) y escribimos en ella el valor Id que corresponde (oCeldaId.setValue(d)) y de nuevo, mediante un bucle dimensionado en base a la matriz-resumen (For b = 0 To UBound(Datos())), recorremos ahora las columnas (campos) que se corresponden con la fila (oCeldaNuevoRegistro = oHojaBD.getCellByPosition(b+1,a-1)) y trasladamos a cada celda los datos de la matriz (oCeldaNuevoRegistro.setString(Datos(b))).
Documento. Desde este enlace puedes acceder al docap explicado en esta entrada.
NOTAS
(1) Si en el caso de los docap-documento el tema del procesamiento remitía a las dificultades para tratar de forma simplificada el problema del procesamiento, en el caso de los docap-evaluación la problemática se acentúa, ya que de una prueba de evaluación se derivan muchos más datos cuantitativos y de categorización que requieren procesos de análisis de la bifurcación de mayor complejidad. No obstante el tratamiento de la opcionalidad en el caso de los contenidos textuales es realmente más complejo, ya que se ajustan en menor medida que los datos de un test a un planteamiento de tipo algorítmico.
(2) Por lo que no resulta satisfactorio desde ninguna de las perspectiva de análisis, pero tiene la ventaja de incluir referencias a ambos modelos (y al mixto). Además, y es lo que importa, evidencia los mecanismos básicos del análisis desde ambas perspectivas (la normativa y la criterial), aunque de forma muy simplificada.
(3) Dado que el informe se crea sobre un documento en blanco, no es necesario crearlo. También es posible utilizar un documento previamente creado y formateado, con lo que implica de trabajo previo y de modificación del código de acceso. Ver al respecto el modelo básico 2 de docap de documento en [esta entrada] (4) Incluyendo las que serán necesarias para el procesamiento posterior y que explicaré en su momento.
(5) Ambos valores sirve únicamente a efectos del funcionamiento del docap, pero no reflejan valores reales de ninguna prueba en concreto.
(6) Puedes apreciar que los tres primeros bloques se ejecutan mediante bucles (reajustando los valores de los índices de la matriz-resumen) y en los últimos la asignación se realiza de forma directa.
(7) Este análisis es anticipatorio pero diferentes del que nos planteamos en la sección Análisis del Blog. También lo es este docap del que podemos crear dentro de ese campo de trabajo.
(8) Recuerda que una fila de una tabla equivale a un registro en una base de datos. Las columnas de la tabla equivalen a los campos de la base de datos y serán tratadas como variables en el análisis de datos.
