Guillermo González Talaván, Francisco J. García Peñalvo, Ángeles Mª Moreno Montero.
Octubre de 1999
La educación a distancia ha supuesto, desde su implantación, la posibilidad de realización de estudios para aquellas personas que, por sus circunstancias o preferencias, deciden no acudir a la enseñanza tradicional.
Aunque no existe un acuerdo unánime en lo que se entiende por educación a distancia, algunas características que pueden citarse para delimitar su campo de acción son: separación física entre profesor y alumno, aprendizaje flexible e independiente y comunicación bidireccional generalmente esporádica. Sobre este aspecto bidireccional de la comunicación se ha de hacer especial hincapié (García, 1996). Es precisamente este proceso de realimentación producto de la comunicación bidireccional el que permite al docente "educar" en su sentido etimológico, es decir, conducir al alumno por el camino correcto.
Sin embargo, son las especiales características de la educación a distancia las que dificultan el grado deseable de interacción profesor-alumno. Los avances tecnológicos pueden ayudar a reducir este inconveniente. Cuando se trata de la enseñanza de la Informática, el propio objeto de aprendizaje, el ordenador, es una herramienta muy flexible que facilita la aplicación de nuevas técnicas educativas.
Por otro lado, desde su aparición en 1969 a partir de la red ARPANET estadounidense, Internet ha supuesto un gran avance en el acceso remoto y universal a la información. Con un coste reducido y que probablemente se reduzca aún más, cualquier persona puede consultar información remota o acceder a los servicios que le ofrece la red de redes.
Internet ha supuesto una revolución no sólo tecnológica. La estructura desjerarquizada de la red, cuyo objetivo fue en principio hacer posible la comunicación incluso en el caso de que algunos de los principales centros de comunicación cayeran en poder del enemigo, ha hecho que la comunicación en ella tienda a ser "entre iguales". Supone por lo tanto Internet un medio ideal para el desarrollo de técnicas de aprendizaje colaborativo.
De la fusión de estas y otras ideas, los autores de este artículo han elaborado tres herramientas de fácil aplicación a entornos de enseñanza a distancia o colaborativa.
Con la primera de estas herramientas, la shell de socorro, instalada en dos ordenadores conectados a la red, cualquiera de los usuarios puede prestar ayuda interactiva al otro. La posibilidad de colaboración interactiva de igual a igual entre alumnos que permite esta herramienta abre nuevas posibilidades en la enseñanza a distancia.
Las otras dos herramientas, la emisora y el grabador, son de fácil realización y pueden proponerse como práctica final de una asignatura de Laboratorio de Sistemas Operativos o ser elaboradas y personalizadas según los gustos del propio docente de la asignatura. La emisora consiste en un programa capaz de emitir el resultado de la ejecución de lo que una persona teclea en una shell de Linux a los terminales de otros usuarios. Puede usarse en clases demostrativas y presenta como ventajas sobre el cañón de proyección tradicional su coste cuasinulo, la facilidad de manejo y la posibilidad de enseñanza a distancia, al no verse su uso restringido al espacio físico del aula. El grabador permite llevar a un fichero una sesión sobre la shell para poder reproducirla posteriormente. Puede usarse para la realización de exámenes a distancia o corrección posterior de exámenes de prácticas.
El carácter abierto, la capacidad multiusuario, el compartir una misma máquina de trabajo y la natural adaptación para las comunicaciones hacen de las máquinas UNIX unas excelentes plataformas sobre las que ensayar nuevas técnicas de enseñanza. Es por esto por lo que las herramientas se diseñaron con el objetivo de usarse en el aprendizaje práctico de los Sistemas Operativos sobre Linux. Sin embargo, se adaptan bien a cualquier asignatura que trabaje con una shell de UNIX. Por ejemplo, un alumno puede realizar consultas sobre una base de datos mientras es supervisado por el profesor. Otros dos alumnos pueden colaborar en la realización de una práctica de programación en lenguaje C desde terminales diferentes. Otro alumno puede grabar el modo en que resuelve un ejercicio o prueba de examen que será posteriormente remitido para su corrección. En este último ejemplo, el docente puede evaluar no sólo los resultados que el alumno ofrece, sino el modo en que obtiene sus resultados, o lo que es igual, su capacidad para la resolución de ese tipo de problemas.
Existe a disposición pública una implementación de la shell de socorro en http://tejo.usal.es/~sosh (González, 1999). Se ofrece, además, una guía general para poder realizar las otras dos herramientas de un modo sencillo sobre cualquier plataforma UNIX. Estas herramientas pueden servir de ejemplo para la realización de otras, personalizadas a las necesidades y el gusto de cada usuario.
Las herramientas presentadas en este trabajo están basadas en los pseudoterminales de UNIX. Mientras que en un terminal normal son el teclado y la pantalla quienes, a través del controlador adecuado, proporcionan la entrada y salida a un proceso principal (fig. 1), en un pseudoterminal es otro proceso controlador el que se encarga de proporcionar o leer los datos producidos por el proceso principal (fig. 2).
Figura 1. Proceso que tiene los descriptores de fichero asociados a la entrada estándar (0), salida estándar (1) y error estándar (2) conectados a un terminal.
Se establece una comunicación full-dúplex entre ambos procesos de propiedades parecidas a una tubería de comunicaciones, con la diferencia de que el proceso principal ve al pseudoterminal con las mismas características que un terminal real (modos de funcionamiento, controles del dispositivo, etc.).
Figura 2. El proceso A tiene los descriptores de fichero asociados a la entrada estándar (0), salida estándar (1) y error estándar (2) conectados a un pseudoterminal controlado por el proceso B a través de los descriptores x e y.
Si el proceso principal es una shell de usuario, el proceso controlador tiene a su disposición todos los datos de entrada y de salida de la shell. La propia shell no distinguirá, en principio, dichas entradas y salida de las proporcionadas por un terminal normal. Los datos que se obtienen del trabajo del usuario pueden entonces registrarse, emitirse, transformarse, etc. según sea la aplicación que se haya realizado (fig. 3).
Figura 3. Shell de usuario A controlada por un proceso B mediante un pseudoterminal. El usuario teclea "ls –l" desde su terminal. El proceso B recoge la entrada pudiendo procesarla si así se quiere y se la manda a la shell por el pseudoterminal. La shell ejecuta la orden y manda la salida al proceso B. El proceso B, previo tratamiento opcional, la manda al terminal real.
Comenzando con la realización de herramientas orientadas a la educación y basadas en pseudoterminales, se pensó en la posibilidad de desarrollar completamente una herramienta general. Dicha aplicación debería eliminar la restricción que supone el tener que estar conectado a una misma máquina para poder trabajar en común. La alternativa razonable parecía Internet. La red de redes posibilita el acceso universal a bajo coste a los usuarios y es de prever que en el futuro su popularidad será aún mayor.
Se trataba no sólo de diseñar una aplicación, sino de dar unas especificaciones y un protocolo universal para un sistema de ayuda interpersonal a través de Internet. El resultado es un programa que cumple con los primeros objetivos y aún más. Es altamente adaptable a diferentes entornos y aplicaciones, entre ellos a la educación. Los protocolos empleados son universales y actualmente se dispone de una aplicación que los implementa para Linux. Esta aplicación está disponible públicamente para su uso o mejora (González, 1999).
Figura 4. Shell de socorro en funcionamiento. Abajo a la derecha, el número de puerto al que estamos conectados.
En la figura 4, podemos ver una imagen de la ejecución de la aplicación. La idea es poder trabajar normalmente en la línea de órdenes del sistema operativo hasta el momento en que el usuario se encuentre con una dificultad. En ese momento, puede solicitar ayuda a través de la red. El programa (sosh, o shell de socorro) se encargará (mediante los protocolos diseñados) de buscar a alguien que desee ayudarnos. El usuario prodrá charlar con la persona que le atienda y, finalmente, aceptar o rechazar la conexión. Si se acepta la conexión, el ayudante tomará el control de nuestra shell para resolver la duda. El ayudante, como es lógico, también verá el resultado de las órdenes que teclea. En la figura 5 se puede ver las pantallas de dos personas prestándose ayuda a través de la shell de socorro.
En cualquier momento puede uno u otro hablar con la otra parte y realizar comentarios. Aunque los papeles de ayudante y solicitante de ayuda son diferentes, la misma aplicación permite comportarse de ambos modos (figura 6).
También existe un modo de funcionamiento en el que uno o varios usuarios solicitan ver lo que se está ejecutando en nuestro ordenador. Es en este modo donde la información fluye de uno a muchos y puede ser usado para impartir clases.
Existe la posibilidad de que el ayudante en el caso de que existan varias solicitudes de ayuda simultáneas, les haga esperar o tome nota para poder atenderlas más tarde. En ese caso, el programa automáticamente llamará a la persona que solicitaba ayuda cuando el ayudante se encuentre libre.
La aplicación, debido a que se diseñó de modo general, dispone de mecanismos de seguridad como puede ser un modo en el que se pide confirmación de cada una de las líneas de órdenes que teclea el ayudante antes de su ejecución.
Figura 5. Shell de socorro en modo remoto. La pantalla de ayudante y ayudado es la misma, pues las órdenes se están ejecutando en el ordenador del ayudado. Nótese el número de puerto diferente.
El programa buscador de personas que puedan prestar ayuda es independiente de la propia shell de socorro. Podemos contactar directamente con cualquier persona de la que conozcamos su localización en Internet o solicitar previamente al programa localizador que trate de encontrar alguna. El buscador dota de gran flexibilidad a la aplicación. Se diseñó basado en un protocolo para la búsqueda de posibles ayudantes en Internet. La base de datos sobre la que se realizará dicha búsqueda debe poder actualizarse dinámicamente y la frecuencia de cambios es alta, principalmente porque el tiempo en que una persona puede ofrecer ayuda dependerá del tiempo que permanezca conectada al ordenador. También hay que atender a la posibilidad de crear una red dinámica de servidores de información interconectados. La duración de los registros de la base de datos de localización de estos servidores sí podría tener tiempos de permanencia de la información más altos. El sistema de servidores de nombres de Internet parece, en este caso, una alternativa razonable.
Figura 6. Posibilidad de comunicación en la shell de socorro. Hemos recibido el mensaje "Hola!!" al que estamos respondiendo con "¿Cómo estás?".
Tenidendo en consideración lo anterior, el esquema que se diseñó fue el siguiente: si se desea encontrar a alguien que nos pueda ayudar, primero se debe preguntar al servidor de nombres de nuestra organización por la dirección del "servidor de socorro" que nos corresponde. Es a dicho servidor a quien debemos dirigir nuestras peticiones. El programa servidor dispondrá de un fichero de configuración donde se especificará el modo de realizar la búsqueda. Normalmente, el programa servidor primero localizará a las personas dispuestas a ofrecer ayuda en su propia máquina. Si no se encuentran, puede preguntar a otros servidores cuyas direcciones vendrán dadas en su propio fichero de configuración o puede devolver una referencia a los propios servidores. Se crea así una red de servidores que pueden satisfacer nuestra petición de más cercano a más lejano.
También el servidor de socorro de nuestra organización es el encargado de registrarnos en el caso de ser nosostros los dispuestos a dar ayuda o, de darnos de baja cuando desistamos de ello. Esta información ha de poder actualizarse de modo dinámico.
Este esquema tan general y especialmente diseñado para Internet se puede adaptar o particularizar para casos más concretos. En el caso de un aula virtual con un solo profesor, los alumnos pueden conocer de antemano la dirección del profesor y todo el sistema de localización de ayuda se torna innecesario. En el caso de una organización expresamente dedicada a la enseñanza a distancia, puede haber varios docentes con horarios diferentes que se encarguen de una misma materia. En este caso, puede el alumno conocer directamente la dirección del servidor de socorro de la organización y que sea este el que, en su configuración, dirija a uno u otro su petición. Pudiera ser que los propios alumnos, al estar trabajando sobre una determinada práctica, pudieran colaborar o solucionarse problemas al registrarse en el servidor de socorro de la organización.
Finalmente, en el caso más general, es cuando pedimos la localización del propio servidor de socorro pues no lo conocemos. Nótese, sin embargo, que cuando nos referimos a "organización" y aunque se haya ligado el sistema de búsqueda al sistema de nombres de dominios de Internet, estas organizaciones han de tomarse en un sentido laxo. Puedo muy bien preguntar al servidor de nombres del dominio ".usal.es" por la dirección del servidor de socorro de dicha organización. Una vez proporcionado, es ya el propio servidor el que decide si yo, como usuario de mi dominio, tengo acceso al servicio o no.
La aplicación de este programa como herramienta para la enseñanza a distancia es evidente. El profesor puede estar trabajando en su ordenador durante determinadas horas y atender las cuestiones que le planteen alumnos distantes conectados a través de Internet.
Aunque este es el principal motivo de elaboración de la aplicación, su generalidad permite encontrarle aplicaciones en otros campos. Se puede usar por los servicios informáticos de una organización como manera de proporcionar apoyo técnico a distancia a sus usuarios. También, y unido al método de búsqueda, es posible solicitar ayuda anónima a través de Internet. Esta posibilidad pesó indudablemente en el diseño de la aplicación. Se trató de dotarla de una filosofía abierta y dinámica, sin menoscabar la seguridad.
En el funcionamiento de la shell de socorro cabe diferenciar dos modos: modo local y modo de ayuda remota. En el modo local, el usuario está trabajando sobre su ordenador. La figura 7 muestra el esquema de funcionamiento en este modo. Se puede comprobar que el esquema que se sigue es muy parecido al esquema general que se mostró en la figura 3. Así, se puede ver cómo la shell de usuario A recibe la entrada del terminal real a través del proceso B y del pseudoterminal. La shell manda la salida correspondiente a través del pseudoterminal de vuelta al proceso B que la escribe en el terminal real. El proceso B realiza un pequeño tratamiento sobre la salida. Consiste en interceptar algunos códigos de control del terminal vt100 para evitar que se sobreescriba la zona de pantalla donde se localiza la barra de herramientas.
Figura 7. Esquema de funcionamiento de la shell de socorro actuando en modo local. El proceso A (shell) es controlado por el proceso B a través de un pseudoterminal.
La figura 8 contiene un esquema del funcionamiento de la shell de socorro en modo remoto. Se supone que, tanto el ayudante como la persona que recibe ayuda tienen una copia de la shell corriendo sobre su máquina. Los procesos correspondientes al ayudante se encuentran en la parte inferior de la figura. En la parte superior, los procesos equivalentes de la persona ayudada. Una vez establecida y aceptada la conexión a través del socket, el flujo de información comienza con los caracteres tecleados por el ayudante en su terminal real. Estos caracteres pasan al proceso B' que los transfiere íntegros al proceso B del ayudado a través del socket. El proceso B envía la información a la shell de usuario del ayudado A con la ayuda del pseudoterminal. La orden correspondiente se está ahora ejecutando sobre la máquina remota. La salida que dicha orden produce pasa al proceso B que la escribe por partida doble, primero en el terminal de la persona ayudada y, luego, en socket hacia el proceso B'. El proceso B', finalmente, escribe la información sobre el terminal real del ayudante, que puede así ver el resultado de la ejecución de la orden tecleada sobre la máquina remota.
Figura 8. Esquema de funcionamiento de la shell de socorro actuando en modo remoto. En la parte de arriba, los dos procesos de la persona ayudada. En la de abajo, los del ayudante. El ayudante teclea órdenes que van a ser ejecutadas en la shell de la persona ayudada (línea discontinua). La shell emite entonces el resultado que va hacia la pantalla del ordenador local y también a la pantalla del ordenador del ayudante (línea continua).
El diseño y la construcción de la aplicación constituyó el tema para la elaboración de un proyecto fin de carrera de Ingeniería Técnica en Informática (Gutiérrez, 1998). Se encuentra en fase beta, será mejorada incorporando nuevas características según vayan siendo necesarias. Se puede encontrar una copia de la aplicación en el URL:
http://tejo.usal.es/~sosh (González, 1999).Esta herramienta consta de dos programas: emisor y receptor. El usuario que invoca al programa emisor disprondrá de una shell de usuario habitual. El o los usuarios que invoquen al programa receptor podrán recibir en sus terminales toda la salida que se produzca en la shell del emisor. Podrán, por tanto, ver cómo el primer usuario trabaja en su ordenador.
Las aplicaciones de este sencillo programa son variadas. Se ha usado con éxito en segundo curso de Ingeniería Técnica de Informática de Sistemas de la Universidad de Salamanca permitiendo que el profesor explique y trabaje sobre su propio ordenador, y los alumnos puedan ver en sus terminales el trabajo que realiza.
En cuanto a la enseñanza a distancia, y aunque es necesario que todos los usuarios estén conectados a la misma máquina Linux, se puede montar de manera natural sobre una sesión de telnet o incluso asociando dicha conexión a un usuario público de la máquina, salvando esta restricción. De este modo, el alumno no tiene más que conectarse mediante telnet a una cuenta determinada y recibir automáticamente las emisiones.
También puede usarse, como de hecho se ha hecho, en enseñanza de tipo colaborativo. Una de las prácticas realizadas en la asignatura de Laboratorio de Sistemas Operativos de segundo curso de Ingeniería Técnica consistía en jugar una partida de ajedrez especial sobre un tablero compartido por toda la clase. La práctica iba dirigida a aprender el manejo de las zonas de memoria compartida por varios procesos. Cada alumno diseñó un programa para manejar una ficha de ajedrez que se pudiera mover libremente sobre el tablero común a intervalos de un segundo. El programa se mantiene en funcionamiento mientras que la ficha que representa no sea comida por otra ficha que esté jugando. La estrategia seguida se dejó a la libertad del programador.
El tablero de ajedrez se contruyó como una zona de memoria compartida y su acceso se reguló mediante un semáforo. Existe un único programa que visualiza el contenido del tablero. Es este programa el que, si se ejecuta desde una sesión de la emisora hace que todos los alumnos puedan ver el tablero común, incluso si están trabajando remotamente.
El funcionamiento del programa se describe en la figura 9. Se ve cómo el proceso shell de usuario A no está conectado directamente a su terminal. En lugar de ello, está conectado a un pseudoterminal manejado por otro proceso B. El proceso B sí está conectado al terminal del usuario. Cuando el usuario teclee algo, le llega al proceso B que lo transfiere a la shell. La salida producida por la shell se envía a la pantalla y a todos los receptores que se encuentren en estos momentos conectados.
El proceso B tiene un proceso hijo que se encarga de atender las solicitudes de conexión y desconexión de los usuarios a través de una cola de mensajes. Cuando se recibe una petición, el proceso hijo avisa al padre para que registre el nuevo terminal en la lista de receptores o lo elimine de ella según proceda. Este proceso no se ha incluido en el esquema de la figura por simplicidad.
La emisión se realiza escribiendo directamente en el terminal del usuario receptor. El terminal ha sido preparado por el programa receptor para que la emisora tenga los permisos adecuados.
Figura 9. Esquema de funcionamiento del programa emisora. La salida de la shell de usuario es emitida a todos los receptores conectados.
La última herramienta que presentamos es también sencilla y se puede encargar su realización como práctica final de una asignatura de laboratorio de sistemas operativos de primer ciclo. Consiste en un par de programas: grabador y visor.
Al invocar el primero de ellos sobre una shell de Linux, el usuario no percibirá nada especial y podrá ejecutar todas las órdenes que desee de un modo habitual (editor de textos "vi", visión de páginas de manual, etc.). Sin embargo, la salida de todo lo que realice se irá grabando en un fichero cuyo nombre se habrá introducido previamente en la línea de órdenes. Dicho fichero podrá ser luego reproducido con el programa visor. El programa grabador, al igual que sucedía con la emisora, puede ser arrancado directamente desde una o varias cuentas de la máquina donde se trabaje.
El esquema de funcionamiento del programa grabador se puede ver en la figura 10. De nuevo, la entrada y salida estándares de una shell A se han conectado a sendos descriptores de fichero de un pseudoterminal manejado por un proceso B. B recibe todo lo tecleado desde el teclado del terminal del usuario y se lo pasa a la shell. También el proceso B recibe de la shell su salida, la almacena en el fichero de reproducción y la escribe en el terminal real para que el usuario pueda trabajar en condiciones normales y no aprecie la diferencia con el funcionamiento normal de la shell.
Figura 10. Esquema de funcionamiento del programa grabador. La salida de la shell de usuario es tratada y grabada en un fichero para su posterior reproducción.
Para que el proceso B pueda atender simultáneamente tanto a la salida de la shell como a los caracteres producidos por el teclado del terminal real, se usa la multiplexión de E/S asíncrona proporcionada por la llamada al sistema select de UNIX. Esta llamada permite atender a varios ficheros de dispositivo simultáneamente pues hace que el proceso se bloquee hasta que cualquiera de los dispositivos necesite atención.
Debido al esquema usado, no es difícil guardar en otro fichero la información recibida del teclado, pero esto no suministra datos de mayor interés y supone un riesgo para la seguridad, pues ahí quedarían almacenadas las claves de acceso tecleadas por más que estas no hubieran aparecido en la pantalla.
Como pequeña complicación adicional, es conveniente almacenar la información de sincronismo para que la reproducción respete el ritmo en que se produjo la salida original. Como se trata de una herramienta muy sencilla, se optó por un formato también sencillo para los datos de la grabación. Los caracteres de la salida se escriben en el fichero de grabación tal cual. En el caso de querer especificar una pausa, se escribe el carácter de código 0 seguido de un byte que expresa el número de décimas de segundo de duración de la pausa. Si la salida tiene algún carácter de código 0, se duplica este para conseguir transparencia. La sencillez del formato del fichero no merma la calidad de reproducción y apenas se aprecia diferencia entre lo grabado y lo que originariamente se grabó. Al elegir la escala de tiempos de la décima de segundo se logra un tamaño adecuado de los datos en la grabación. En el caso de que se quieran almacenar grabaciones con un tamaño menor, se puede usar un programa de compresión de datos estándar.
El programa visor que se ha construido es muy sencillo, como el propio formato del fichero de grabación. Actúa como un filtro de UNIX. Recibe por su entrada estándar una grabación y produce por su salida estándar la reproducción correspondiente.
No sería difícil hacer un programa visor con una interfaz más amigable o más funcional. Pudiera ser el típico panel de control de grabadora con sus botones de reproducción, avance, retroceso, avance rápido, retroceso rápido y pausa. Mientras que los avances y la pausa no serían complicados de realizar, las operaciones de retroceso técnicamente sí lo serían al no existir una manera natural de deshacer los cambios producidos en el estado del terminal por las últimas salidas.
Una de las restricciones del programa consiste en que si se usan capacidades específicas de un terminal (número de líneas, columnas, movimiento del cursor, etc.), que se usarán seguro si manejamos programas de edición en pantalla, se ha de reproducir el fichero en un terminal de similares características. Esto no es un problema grave especialmente dada la profusión de terminales o emuladores compatibles con el VT100.
Entre las aplicaciones de este programa cabe destacar:
En este tabajo se han presentado algunas herramientas que pueden ser usadas para la enseñanza de tipo colaborativo o remoto de disciplinas que puedan ser impartidas sobre máquinas Linux. Son especialmente apropiadas para la enseñanza de asignaturas prácticas sobre programación del sistema, manejo de bases de datos, etc. Las últimas dos herramientas son de fácil elaboración y adaptación a las necesidades concretas de cada caso particular. La primera herramienta constituye una aplicación más general. Es de utilidad no sólo para la docencia sino en entornos más generales. Se trata de una aplicación que puede servir como modelo o como punto de partida para la elaboración de otras aplicaciones más específicas.
La segunda herramienta, que consiste en poder emitir a varios receptores lo que se esté tecleando en una shell de Linux, ha sido ya probada este año en las clases de Laboratorio de Sistemas Operativos de segundo curso de Ingeniería Técnica de Informática. Ejemplos de la primera herramienta para Linux están a disposición pública para su uso o mejora. Para facilitar la labor en el caso de querer programarlas uno mismo, se ha dado un esquema de funcionamiento general de todas las herramientas presentadas.
García, L. (1996). La educación a distancia y la UNED. UNED.
González Talaván, Guillermo. (1999). SOSH home page [en línea]. Depto. de Informática y Automática. Universidad de Salamanca. <http://tejo.usal.es/~sosh>. [Consulta: 14 setiembre 1999].
Gutiérrez García, Miguel Ángel. (1998). Diseño de protocolos y aplicaciones necesarias para un sistema de ayuda interpersonal a través de Internet. Proyecto de Fin de Carrera de Ingeniería Técnica en Informática de Sistemas. Depto. de Informática y Automática. Universidad de Salamanca.